[cairo] Spot colors (and CMYK)
spitzak at gmail.com
Mon Feb 22 12:50:51 PST 2010
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
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.
More information about the cairo