[cairo] Spot colors (and CMYK)

[Chris Murphy]

On Jan 20, 2010, at 4:07 PM, Bill Spitzak wrote:

> Chris Murphy wrote:
>> 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 is no gamut limitation if negative values are allowed.
> 
>> 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?
> 
> Because any loss of fidelity in 32 bit floats is negligable. The basic problem is that end users DEMAND sRGB api because 99.9% of their data is in this format. So any API must have sRGB. I do not believe APIs should be complicated unless there is absolute necessity and so far I do not see any argument why the color values themselves cannot be sRGB.

They should not be sRGB encoded because many such colors will out out of gamut in sRGB.

They could be scRGB encoded, however e.g. TIFF does support LAB, it doesn't support scRGB. Not directly anyway. I can specify arbitrary, printable colors in LAB using existing software on the market today, I cannot specify them using scRGB. So if you're talking about what users demand, they should hopefully be demanding that they can actually do a thing, rather than asking for something they can't do. Users are certainly not asking for an interface to directly define colors in scRGB, it's not designed for that.

If the context is spot colors and printing, I refuse the premise that 99.9% of those users' data is encoded in sRGB. It's more like 70% is encoded in "U.S. Web Coated (SWOP) v2".

>> Encoding isn't relevant to users, it shouldn't be made relevant.
> 
> The entire reason for this is so that the majority of end users do not have to care about "encoding". They may be able to get "divide by 255 and send that floating point number" and asking for anything else is unreasonable.

If the colors are defined in scRGB, then the color still has to be converted into XYZ or LAB (a PCS) in order to utilize a device profile so that the color can be correctly displayed or printed. I don't see the benefit of encoding, something that's going to have to be converted to a PCS anyway.


> 
>> 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.
> 
> We will define the mapping between unclamped sRGB to XYZ. ICC does define everything in XYZ, therefore by adding this definition we have defined everything in Cairo colorspace.

OK do you really mean unclamped sRGB to XYZ or do you mean scRGB to XYZ?

> 
>>> 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. 
> 
> I do not understand. What exactly do you think EVERY SINGLE PROGRAM IN THE WORLD does with those current CMYK "alternatives" when they draw them on the screen?
> 
> I find it impossible to believe that any program does anything other than the simplistic conversion. Any "smarter" program will instead use the pantone color directly.

Well if you really feel it's impossible to believe, then you might find the following disturbing. Or maybe you'll forget it immediately upon reading it, as though I didn't write it.

All Adobe applications, and QuarkXPress, and CorelDraw, and probably some others, do not work the way you describe. They assume a CMYK source space (most of apps let you change this assume CMYK source color space), which is defined by an ICC profile, and the convert these colors to a destination space, defined also by an ICC profile. For display, it's the display profile set for that system. For a printer, it uses an RGB or CMYK default destination (usually something that can be specified).

If I use the basic Preview application on OS X for example, any PDF containing spot colors has their spot colors converted using ICC based conversions. The CMYK alternates for the spot colors are effectively converted to LAB (not literally since a colorworld is actually create between source and destination, think of it as a kind of devicelink profile) using Apple's "DefaultCMYK" color space and then are converted to the currently set display RGB profile.

It's not a simplistic conversion. It's always an ICC based LUT based conversion. All apps inherit this behavior to some degree on this OS, and Windows is similar.

Simplistic conversions are what we had circa Photoshop 3 and earlier. The previews sucked.


> 
>>> 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.
> 
> As before, out-of-gamut is quite possible. I thought it might be possible to tweak the values slightly in the lower bits so they are all different.

Right and thereby make them even more inaccurate by radically shifting their lightness or (worse) their hue in order to get differentiation. How this is to be done very much depends on the source and destination spaces in question. And if we're going to consider future applications, we should consider color appearance and maybe one day not totally ignoring luminance like we do today.


>> 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.
> 
> That is why the sRGB is an APPROXIMATION. Who cares how accurate it is. Any attempt to make it better should be the responsibility of the programs and drivers, it is a fallback so that drivers do not need to know anything about pantone colors or CMYK.

Why approximate when it takes the exact same amount of work to get better results?
> 
> However I do see it plausable that this means the 1:1 mapping I suggest should not be done. This would allow a program to select a "more correct" alternative color for the spot color depending on other information it knows.


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