[cairo] Spot colors (and CMYK)

Bill Spitzak 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  
TWO apis.

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  
>> reals,
>> 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
> http://lists.cairographics.org/mailman/listinfo/cairo

More information about the cairo mailing list