[cairo] Spot colors (and CMYK)

[Bill Spitzak]

On Jan 20, 2010, at 1:43 PM, Chris Murphy wrote:

> 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.

THERE IS NO GAMUT LIMITATION because negative numbers are supported.  
Stop saying this!

> 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.

> 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*!

> 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.

>>> 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?

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

> 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.

>>> 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?

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.