[cairo] Spot colors (and CMYK)

[Chris Murphy]

On Jan 21, 2010, at 1:12 AM, Bill Spitzak wrote:
> However this confirms my understanding that the conversion from "CMYK" to sRGB is fixed and has no "color management" controls. So my argument that no CMYK api is needed still holds: the calling program can do this conversion to get sRGB values to pass to Cairo, which can then do any color management it needs to do. The fact that a spot color was used does need to be sent but that requires fewer api modifications than also having non-sRGB color spaces.

CMYK is a color model. RGB is a color model. sRGB is a color space. 

There is no such thing as conversion from CMYK to sRGB. Some sort of CMYK color space must be assumed to do this. Which one? Are you going to use Pantone supplied CMYK equivalents for Pantone colors in North America? Or the European CMYK equivalents for the exact same spot colors? They're different values because the print conditions differ.

And even outside of a spot color context, how are you going to properly display CMYK content without an API to do this? Or is the application expected to implement such a conversion itself? In which case why wouldn't it be required to just convert spots directly from LAB/XYZ to whatever Cairo requires, presumably scRGB?


On Jan 21, 2010, at 1:30 AM, Bill Spitzak wrote:
> On Jan 20, 2010, at 1:43 PM, Chris Murphy wrote:
>> 
>> They should not be sRGB encoded because many such colors will out out of gamut in sRGB.
> 
> THERE IS NO GAMUT LIMITATION because negative numbers are supported. Stop saying this!

sRGB used by itself is an integer based color space, in most every instance 8bpc precision. If you mean something else, call it something else. sRGB the color space certainly has a limitation. When you say it doesn't, you're referring to a space merely defined by but not limited to the sRGB primaries.


> 
>> 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.
> 
> There is a well-defined conversion from sRGB to LAB. Convert to XYZ and then to Lab. It is irrelevant that tiff files don't support unclamped sRGB directly.

OK.

> 
>> 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".
> 
> If you count updating user interface widgets I think 99.9% is a vast *underestimate*!

There are a lot of CMYK images on the planet, I doubt it's in the 0.01% range. I'll grant that we're probably talking single digit percentages for non-sRGB encoded images combined: Adobe RGB (1998), ProPhoto RGB, ECI-RGB, and all CMYK, and LAB images lumped in together. This despite the fact professional photographers don't go anywhere near sRGB. And by the way I don't know a single one using scRGB or similar space even for HDR work. None. I'm sure there are a few but they're unlikely to be aware of it.

> 
>> 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 don't see the problem. If XYZ is specified then you might have to convert to LAB. We are not saving any steps. Also working in film I have seen an awful lot of color management where either the input or output is sRGB space.
> 
> The conversion from sRGB to XYZ requires a power function and then a multiply by a 3x3 matrix. It should be possible to combine these with the next steps of color management so that little or no extra math steps are done. In particular you can combine with any other 3x3 matrix used to arrive at a new set of primaries.

OK.

>> OK do you really mean unclamped sRGB to XYZ or do you mean scRGB to XYZ?
> 
> I mean unclamped sRGB.
> 
> The term "scRGB" means Microsofts attempt to cram some subrange (about -.5 to 7.5) into an integer. We can and should ignore it. In particular I want 0,0,0 to mean no color, not a negative color like Microsoft has it. However I do recommend we copy how they convert values outside the 0-1 range (they continue the gamma curve greater than 1 and use the -f(-x) for the negative numbers). I'm not sure what to call this, but just "sRGB" is actually pretty accurate. "floating point sRGB" or "unclamped sRGB" may help.
> 
> However I think a number of people are using "scRGB" to mean unclamped sRGB.

I suggest remedying this quickly. Call it CairoRGB v1.0, or CairoRGB for short if you want. Anything but relating it to either sRGB or scRGB. That it shares sRGB primaries in my view doesn't need to go in the name because the primaries are irrelevant. scRGB I think is rather ridiculous and unhelpful name for the Microsoft implementation, but that's what I think of and assume is being talked about when scRGB is brought up. Cairo sRGB makes me think of what Japanese electronics companies have done, whereby they install "Nikon sRGB" and "Epson sRGB" etc. and yet these are all indistinguishable from "sRGB IEC61966-2.1" except the filename and copyright are changed. Very annoying.



> 
>> 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).
> 
> It sounds like the conversion (ie the CMYK source space) is *fixed* however. So there is a defined non-color-management way to convert to sRGB, and from there color management can be used to produce the actual numbers in the display buffer. I guess it is more complex than I thought, but that is just more reason why we don't want to do it and we should require the calling program to convert CMYK to sRGB to specify the alternate color.

Yes, I suppose it's better if an application were to have poor quality, simplistic conversions since it only reflects poorly on that application, rather than an entire graphics library.

That there is a one size fits all, Tonka Toy method of converting from unspecified CMYK encoding to RGB doesn't mean it should ever be used in any serious context. And I'd say supporting spot colors and CMYK implies an attempt to be serious. Do it right, or abandon the idea. A simple conversion will not get you from arbitrary CMYK to sRGB (a rather specific color space with specifically implied XYZ values). 

There is a greater range of CMYK flavors out in the world than RGB flavors. If you want sRGB (specific) then you need to start out with a specific source space for those CMYK values. Otherwise you get pretense that two sets of CMYK values are different colors, when in fact they should map to the same color; or conversely the same set of CMYK values which should map to different colors.

>>> Why approximate when it takes the exact same amount of work to get better results?
> 
> Are you claiming that the XYZ or CMYK is an "exact result of the spot color"? If that was true, then we can just forget about spot colors entirely! However I'm pretty certain that is false, a spot color is in effect another dimension in the color space and cannot be accurately described by XYZ or sRGB or CMYK.
> 
> Therefore the CMKY is an approximation. Lets convert it to another approximation by using that DeviceCMYK you described to get sRGB and then use that in the api.

The XYZ value is an exact representation of a spot color. There is no one CMYK equivalent for a spot color, it depends on the specific CMYK output process you're referring to (it depend on the CMYK primaries, TRC, media white, etc. Just like with an RGB color space.)

A spot color is used in vernacular to mean "not a process color" so not process cyan, magenta, yellow or black. It starts out as a grayscale channel in software, hopefully assigned some numeric value so it can be displayed as something other than black to white (this is where defining it as XYZ or LAB comes in handy). When output, it is that single grayscale channel, completely irrespective of its named color (or tristimulus value), that is used to produce a plate, which is then loaded onto a press, and it suddenly gets the intended color when ink is mixed in a bucket and put into the press ink fountain.

By definition a spot color is definable in either XYZ or LAB values because we can see spot colors. What's the point of defining spot colors with imaginary colors? Zero.

Another way to look at a spot color, is that it's an additional primary, an adjunct to the process colors. These are called bump plates. This when their color is used to boost saturation in photographic (or photo-illustrated) content because the process colors can't achieve the desired effect.


Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cairographics.org/archives/cairo/attachments/20100121/5cf31bcd/attachment-0001.htm