[cairo] Spot colors (and CMYK)

[Chris Murphy]

On Jan 20, 2010, at 4:09 PM, Bill Spitzak wrote:
> Jon Cruz wrote:
> 
>> Actually the pantone CMYK "alternatives" are quite an ugly mess, and not nearly sRGB based.
>> Instead they were based on physical efforts to create close results... *however* they are not common CMYK.
>> Instead they are very custom. In order to get closer to their ink values, Pantone had set up those samples to print inks in custom orders with custom screening that is not compatible with the norms used by print houses running CMYK.
> 
> I believe this corresponds to what I suspect.
> 
> A better way of saying it is: Pantone sets the CMYK alternatives so that the simplistic conversion to sRGB produces "correct" results on the screen. Therefore those colors have nothing to do with CMYK inks on any printer.
> 
> This means we will lose nothing by doing the simple conversion to sRGB and putting that in the API.


Except that the understanding is incorrect. The CMYK alternatives currently defined by Pantone are designed to work with specific press conditions defined in their formula guides for each region. That they do not conform to standardized printing conditions such as SWOP or GRACoL is another debate (a useful one but not immediately relevant). The fact is, those CMYK values do correlate to printing press conditions and simple inversion to any RGB will not produce correct results at all on screen.

All you have to do is try it.

And second, for a while now, the actual behavior of displays has been diverging away from sRGB, not toward it. I would not consider sRGB to be reliable, at all, as a cheap means of arriving at deviceRGB based workflow and avoiding full display compensation based on actual (or reasonable estimate thereof) display behavior. Laptop displays do not at all conform to sRGB, all you have to do is model their gamut compared to sRGB. It's radically different. Look at most LCD panels on the market, and they diverge from sRGB in at least one primary, and it depends on who makes the panel.

We do not have the same kind of similarity in device primaries for displays we did with CRT where there were a limited number of primaries, all of which were much closer to each other than what we have in the market today. And the advent of wide gamut display technologies at the high end also substantially departs from sRGB. So no, what we need is to get vendors to include reasonably good estimates of their primaries in the display's EDID, and have operating systems automatically build an ICC display profile on-the-fly based on polled EDID information, and set the display profile and perform display compensation across the board.

Unfortunately how this has played out on Mac OS and Windows so far it that each application must implement display compensation on their own, rather than the window server assuming a color space (such as sRGB) and converting every pixel to the EDID (or custom made) based display profile. Apple has since gone to full display compensation themselves at a window server level which should obviate this need for all general purposes (non-publishing) type applications such as web browsers.

But anyway, point is, sRGB is not something we should be hanging out hats on, to implement workable /devicergb workflow. It works really poorly actually.


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