[cairo] Spot colors (and CMYK)

[Chris Murphy]

On Jan 20, 2010, at 3:15 PM, Bill Spitzak wrote:

> What is needed is "this is a spot color with this id" along with "here is the sRGB alternative". Devices that do not understand spot colors can use the alternative. Drivers that do recognize the spot color can instead allocate another channel (along with RGB) to accumulate it and set RGB to zero. After compositing is done they convert the remaining RGB into ink levels.

sRGB is effectively device-independent, but still has a gamut limitation. There are Pantone (and other spot colors) that lie outside of the sRGB gamut. Given wide gamut display technologies increasingly becoming affordable, I think sRGB alternates is the wrong way to go. It's superior than ICC-Based CMYK, but it's inferior to just using LAB or XYZ.

To get to sRGB alternates, requires that you start out with XYZ or LAB in the first place. Why convert and lose fidelity in the process?

> We do not need Lab or XYZ as the alternate. Because Cairo's api supports negative floating point numbers it can cover any 3D volume of color using any three primaries that are not on a straight line. Staying with the sRGB primaries will make things easier for most back ends and most users. (the real question is how to represent negative values in the non-linear sRGB gamma curve. Microsoft with their scRGB chose to continue the gamma curve past 1 and to mirror-image the positive curve to make the curve for numbers less than 0, so that should be what is used here).

Encoding isn't relevant to users, it shouldn't be made relevant.

I have no issue with using scRGB as a compositing space. But for spot color alternate definition there's no advantage in terms of quality or performance. I disagree that it's easier for backends. It actually complicates things because not all of the present file formats support floating-point. They do support either XYZ or LAB. And floating-point is only recently being discussed at the ICC level, and is not presently in the current ICC specification.

> 
> If Pantone colors come with a CMYK "alternative", this is an approximation already! I see no problem with further approximating it by the simplistic conversion (r=1-c-b, etc in sRGB gamma space).

Well, except that it will look like crap times two, instead of crap times 1. The industry has been there, done it, and rejected it as demonstrated with massive end user confusion. Approximation means mediocre results. 

> The advantage is that this is pretty much reversable (perfectly reversble if the value for b is known). Not only that I would not be suprised if 50% of those "approximations" were done by choosing the values so that this simplistic conversion of sRGB produced the best screen result!
> 
> I previously suggested that if the mapping from spot colors to sRGB values is unique (ie all spot colors map to different sRGB values) then no id needs to be sent, just the "this is a spot color" flag.

It's not guaranteed that all spot colors will map to unique sRGB values. In fact it's certain they won't given the sRGB gamut. 


> I still think this may be a good idea, it would remove all Pantone IP from the interface, allow a fixed-sized color structure (4 floats plus a single enumeration), and would prevent malicious programs from, for instance, asking for the "C" spot color but with 1,1,1 as the sRGB values.

The color of a spot color depends on the kind of paper it's going to be printed on. So if you want to approximate this, whether it's printing on C, M, or U is relevant to getting the color even close to correct, the darker and more saturated the spot color is.



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