[cairo] Spot colors (and CMYK)
spitzak at gmail.com
Wed Jan 20 21:59:42 PST 2010
There is a perfectly mathematically-defined conversion from
"scRGB" (unclamped sRGB) to XYZ. It has NOTHING to do with "color
management", the conversion is a fixed math formula: you linearize the
RGB channels and then you multiply by a constant 3x3 matrix, and you
have XYZ. Because the RGB primaries are not in a straight line in XYZ
and the api accepts floating point values with a huge range, the
mappable XYZ space is also huge, far outside the physically possible
colors and with a brightness range from far less than one photon up to
supernova levels. Anything that can be done with XYZ values can be
done with unclamped sRGB by converting first to XYZ and then applying
whatever you planned to do with the XYZ values.
Any argument that "the gamut is not large enough" is bogus. The
"gamut" is approximately infinite.
Lets please stop this misinformed arguing.
My take on this:
Users INSIST that there be a way to specify colors in sRGB, so there
must be an api that accepts such values.
If you need to provide any other color space, you now have at least
By the "zero, one, infinity" rule of API design, this is unacceptable.
You must instead design for an api that takes an infinite number of
color space descriptions (ie add understanding of ICC profiles, etc,
to Cairo). This is complex and therefore there must be a compelling
reason to do this.
I have yet to see one from any of this stuff. Everybody keeps claiming
that XYZ has all the information needed, that means unclamped sRGB has
the information as well.
The only real reason I could see is that CMYK is 4-dimensional, thus
it cannot be converted to sRGB which only has 3 dimensions. However
from the descriptions here this is not considered a problem by color
management, since there are repeated claims that XYZ is acceptable
(other than spot colors which are really an N-dimensional space). But
none of the color management experts here have mentioned the only
mathematically sound argument, so I think it actually is not a problem.
On Jan 20, 2010, at 4:41 PM, Chris Murphy wrote:
> On Jan 20, 2010, at 7:26 PM, James Cloos wrote:
>>>>>>> "Chris" == Chris Murphy <lists at colorremedies.com> writes:
>> Chris> Why scRGB and not OpenEXR? Is this in the archives somewhere?
>> It should be; try searching for scRGB in posts by Carl.
>> The idea is that cairo already asks for doubles for colourant values,
>> scRGB has the same primaries and transform as sRGB when viewed as
>> the doubles are allowed to have any value a double can represent, so
>> therefore the two spaces are identical until conversion to integer
>> values is done.
>> Or at least that is what /I/ got out of the posts.
> I don't know if I find this more compelling compared to RIMM/ROMM,
> especially in an ICC context. There have been more challenges
> testing perceptual sRGB to print conversions, than a compositing/
> intermediate space based on an output medium metric. There's a
> greater difference in the shape of sRGB and output color gamuts,
> compared to a reference input/output medium approach, especially
> considering the sRGB blue primary compared to printers, and even
> today's LCD displays.
> In any event, OpenEXR only came up once in my search and is
> unrelated to this discussion. And scRGB only comes up twice and
> neither explores alternatives. RIMM and ROMM don't come up at all. I
> can see why something needs to be picked as a default, but will it
> be possible to specify something other than scRGB?
> Anyway, for encoding spot colors, I see no meaningful advantage to
> encoding them in scRGB, and every reason why they should be encoded
> as XYZ/LAB or better, spectrally.
> Chris Murphy
> Color Remedies (TM)
> New York, NY
> Co-author "Real World Color Management, 2nd Ed"
> cairo mailing list
> cairo at cairographics.org
More information about the cairo