[cairo] [RFC] Color space API (partial proposal)

[Bill Spitzak]

Okay I think I missed something.

Does a color space define how to mix the channels together? If so what 
should we do about Cairo compositing operations that it does not include?

Or (as I have been assuming) the blending color space is designed such 
that normal linear math of the channels produces the desired result?

I understand that there is another transform between the blending space 
and the final device, though I am concerned about the speed impact if 
this transform is not the identity.

Jon Cruz wrote:
> On Feb 23, 2010, at 12:12 PM, Bill Spitzak wrote:
> 
>>>> 6. A correct Cairo backend can be implemented that will IMMEDIATELY (ie before the call to set the color or image returns) convert the color or image to destination space and throw away irretrievably the "source" space.
>>> Yes, e.g. the Xlib backend.
>> I certainly agree that this is how it MUST be done, but I have to point out that this directly conflicts with most/all of the claims of color management making it possible to replicate a given printer's output. Even if you assume mixing the numbers in the printer's space is the same as printing those quantities of ink (which is demonstratively false), it is certainly not true in a different color space such as the display device.
> 
> That's generally not how a CMS API is used.
> 
> A target profile will help with mixing the device numbers/colors, but then a *display* profile is used to preview that printing result on screen.
> 
> For example, LittleCMS has a cmsCreateTransform() call for normal work, chaining, but then for the display preview there is an explicit cmsCreateProofingTransform() call. So given RGB input of a known colorspace, a transform is built that ends with the target profile of the CMYK printer. *Then* a proofing transform is used to preview that output in display.
>