[cairo] Spot colors (and CMYK)

[Bill Spitzak]

Chris Murphy wrote:
> On Feb 18, 2010, at 10:56 AM, Bill Spitzak wrote:
> 
>> Apple and Adobe provide a FIXED conversion from sRGB to the display.
> 
> Define "fixed conversion from sRGB to the display" please. I do not know what you mean by this, in particular by the word "fixed".

Every sRGB color has a 100% defined exact specification for an XYZ 
equivalent. All CMS systems I have ever seen know how to take a given 
XYZ value and turn it into an exact value to put into the display 
hardware. Therefore there is a fixed, never changing, conversion from 
sRGB to the display (unless you change the cms settings of the display, 
but if it is correctly calibrated why should you do that?)

> Adjust the screen how? You mean through the display's OSD? That is completely f|cked up if that's what you mean. This sort of screw up the display to make the image look right is a workflow that was rejected over a decade ago for professional workflows.

I do not understand. Half the time you say "I want the output device to 
alter the image to values  that display the correct color (you do below, 
I will point it out). It seems the whole point of this color management 
argument is so that programs can provide RGB or CMYK values and the 
Cairo backend can do something other than put this data raw into the 
display buffer.

But here you seem to indicate that programs should supply images in 
device space. In fact further experiments with OSX seem to indicate this 
as well, though I am still unable to get it to act like a screen shot 
has an attached profile.

>> Yes there are apis to provide a cms so they can concatenate it with 
>> their internal one. However this is the PROBLEM, not the solution.
> 
> Who is "they" and "their"? What is "internal one"? Why is this a problem?

"They" are Apple. "internal" is what you call the "destination profile" 
below, or I guess the "system profile". I am under the impression the 
only reason for this is so that the two cms transformations can be 
concatenated, so that the resulting transformation can be done faster 
and so no intermediate floating-point image format is needed.

The "problem" is that you need an api to provide the cms description. 
This is obviously more complicated than not having such an api, so there 
needs to be a compelling reason this cannot be done by the application.

> Many of Apple's own applications ask the OS what the current system profile is (the current display profile), which in default cases is a profile built on the fly from the display's EDID. The app then submits data for display, tagged with this display profile, to Quartz. Since source=destination, there is no conversion.

 From my experiments it appears this is the default, not the fixed sRGB. 
If so then I would vote for the Cairo api to be in device space all the 
time, this would completely eliminate the whole question of color 
management (unless you think a Cairo api to provide the device 
description of the output would be useful).

> Any application which does not explicitly set a profile for data to be displayed (or printed) is assumed to be Generic RGB on OS X 10.5 and older, and sRGB on OS X 10.6 and later. From that space, it is converted to the system profile (the profile for the display, or DisplayRGB).

This matches what I was proposing for Cairo, but your claim above is 
that the api defaults to device space. Perhaps this should be done in 
Cairo as well.