[cairo] Spot colors (and CMYK)

[Chris Murphy]

On Jan 21, 2010, at 4:42 PM, Bill Spitzak wrote:

> I think I am not explaining the API I want clearly.
> 
> What would be sent to cairo is "This is the spot color id, and here is an sRGB approximation". This sRGB value would be the Pantone CMYK converted using the DeviceCMYK to sRGB, although not be clamped to the 0-1 range (so outside-sRGB-gamut inks can be approximated).

I would suggest that application developers be encouraged to obtain and utilize XYZ or Lab or spectral data, internal to their application, for any spot colors. And strongly discouraged from using CMYK equivalents, which are a.) confusing, b.) at worst a lie, c.) at best misleading, d.) a waste of time/junk.

And then when submitting data to Cairo, is convert that to wide-gamut HDR space (i.e. unclamped sRGB, or Cairo RGB) directly without ever going through CMYK of any flavor. A conversion through CMYK is a problem. It seriously needs to be purged from present systems, and is a mistake that should be avoided in future systems in a modern world which has hopefully learned from past pain points.

It's a question for your developers whether there is value in Cairo having an API that can receive arbitrary tagged color spaces other than sRGB based ones - such as Adobe RGB (1998) which is quite common, or  ProPhoto RGB which is less common but professional photographers use it, and LAB/LCH. Then not every developer has to reinvent the wheel everytime they want to just do simple conversions. I don't know enough about all the pieces to know if it's "better" for such developers to directly call Oyranos or if Cairo should call Oyranos to implement such capabilities. *shrug* not my area, but hopefully the apps aren't having to do really repetitive stuff.

It's very cool, I would think, for a developer to simply submit to a graphics engine, tagged content, and have that content manipulated correctly for the intended output be it display or print, without having to make additional API calls to first convert each element, normalize it to one space, and then submit it to the graphics engine. Kinda seems ideal, maybe as a longer term goal, to allow a graphics library do this stuff for applications, but maybe that's not a design goal for Cairo - not sure.


> 
> A "smart" driver can ignore the sRGB approximation and do exactly the right thing by using the spot color id.
> 
> A "dumb" driver will ignore the spot color id and is going to get the color wrong.

Both can get it correct if CMYK is uninvolved and the color is defined device-dependent in a color space without an appreciable gamut limitation. In fact, the "dumb" driver will get it correct more often, inclusive of being able to support non-proprietary spot color systems, because it won't ever have a hardwired set of lookup tables for named colors which regularly become obsolete. Been there, done it, we should stop doing that too. 

The dumb driver now becomes the smart driver magically just by making the right choices.  The spot color is defacto defined in CIE space (CairoRGB, unclamped sRGB, whatever), and can be converted to display or print device color space either using proprietary color management or ICC-based color management or whatever else...or even normalize it to sRGB and then hand it off to the driver if it has an sRGB mode. Even that direct convert to conventional sRGB is vastly better than either a.) lookup tables for named colors, or b.) going through a CMYK space as an intermediate, as sRGB clipping isn't as bad as CMYK clipping.


> I have yet to see any kind of argument that somehow the dumb driver is going to do better if given CMYK and a color profile rather than sRGB.

Easy, remove CMYK from the chain. It has no business being used for spot colors anyway.

> That color profile is apparently a constant so it should not be needed.

? It's not a constant in any event. But I don't need to debate this point, just discourage the primary named color library lookup being anything other than XYZ, LAB or spectral. Consideration of CMYK as the primary lookup table should be off the table in my opinion. It's simply disqualifying it's that useless. Exhibits A, B, C, and D.

> The only plausable argument is that there is information in the 4-D CMYK space that is lost when converting to 3-D sRGB but so many of the color experts here say with absolute certainty that XYZ or Lab (both 3-D spaces) will do the job, that it appears this is false.

The 4D issues are a different conversation entirely, and depend on the mechanical behavior of the printer. The way to really handle this is a combination of upstream metadata, that ends up in a portable file like PDF, output agnostic, and the RIP responsible for rasterizing that PDF for a specific output condition determines whether e.g. 4 color black type is a good or bad and renders accordingly. (i.e. black type is a kind of object, usually it's treated black only but there are certain output processes where black only is very light, and yet due to perfect register it's possible to print four color "rich black" type and get a better black. Other processes without perfect register implode with 4 color black text, you get fuzzy text instead almost certainly risking a complete redo of the job, or at least burning new plates.)


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