[cairo] Spot colors (and CMYK)

[Chris Murphy]

On Feb 22, 2010, at 1:50 PM, Bill Spitzak wrote:

> 
> 
> 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?)

Every display is different. Calibration doesn't change this fact. Every display has a different display profile.



> 
>> 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.

You haven't answered the questions I posed, that's part of the problem. I don't understand what you stated originally, which is why I asked for clarification. If you don't understand my questions, then yes, we have a problem.




> 
>>> 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.

Inconsistent behavior between applications.


>> 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).

The trend is to move to sRGB as the assumed source, and have Quartz/windowserver do conversions to the actual display color space on -the-fly.


> 
>> 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.

Except that applications on OS X can explicitly set a profile for data to be displayed. It doesn't have to be sRGB at all, nor does data ever end up in sRGB as an intermediate space.



Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"