[cairo] Spot colors (and CMYK)

[Bill Spitzak]

Chris Murphy wrote:

> How do you intend to pass colors which are specific in unclamped sRGB, into file formats which do not support unclamped sRGB? It seems you will necessarily limit the palette to that of sRGB which just seems laughable in 2010. This is not how devices work.

By converting them to some color space the device supports! I think that 
should be pretty obvious.

>> You are living in a fantasy world if you believe screen shots have ICC 
>> profiles attached. This is not true even on OSX.
> 
> It has been true for about a decade, plus or minus a couple of years.

Sorry but I don't see it in jpeg files created from OSX screen shots.

>> We ignore them in png, we ignore 
>> them is exif files, we ignore them in Red camera data.
> 
> Oh my god, this is just painful to read. You must not understand at all what you're doing. There is a case to be made for validating such data and determining if the embedded profile information is obviously wrong (this is done in FireFox, and Photoshop for example), and rejecting it in favor of something else (an assumed source space). But if it's valid data and you're just rejecting it all wholesale? Then that is f|cking high order sabotage, there is no diplomatic way to put it.

Okay exactly what should I do when a png file claims it's gamma is 1.0? 
I'll tell you: ignore it and assume it is sRGB. If your software is 
doing anything different you will quickly find that it will display 
images wrong. Stop claiming falsehoods, everybody ignores png color 
information because they have to.

I wrote Nuke's exif i/o and it uses a fixed YUV to sRGB conversion and 
certainly ignores any color spaces. I can assure you that any other 
implementation would be useless for our users.

> Bull. Users want what they want. They can hardly articulate what they want

Users can articulate what they want: A program that reads a quick time 
and writes it out again should produce an identical movie. Currently 
QuickTime on OS X fails this trivial test, while ffmpeg works.

> You know. I love how you make all of these assumptions based on your own experience and then ridicule other use cases you've never thought of as nonsense. It makes me feel justified in ridiculing your color crippled software ideas, and sabotage of valid color profile metadata by ignoring it in favor of something you randomly prefer. It's ironic. I'm waiting in glee for the next stage of cognitive dissonance.

Ok whatever. I think I actually worked in this field for quite a while 
and have made some important contributions but you can dismiss me if you 
want.

>>> The 
>>> question must be: can I produce a screenshot which looks identical on my 
>>> laptop, my desktop computer monitor and on the monitor of others. Non 
>>> broken adn correctly colour managed software together with correctly 
>>> configured hardware can this.
>> Absolutely you can do this. Cairo will return a "screen shot" as sRGB 
>> values. You then send it to another screen as sRGB values. And it will 
>> look "identical".
> 
> You're the one in a fantasy world, because you assume that displays are all approximately sRGB-like. They aren't. So you need to stop touting sRGB as something that describes real devices. Some manufacturers do a lot of work to ensure their devices do correlate well to sRGB. Most do not. Printers definitely do not. Spot colors do not. CMYK does not.

Why is it impossible for Cairo to convert the screen image to sRGB? You 
seem to think it is trivial to convert an *arbitrary* color space to the 
screen, but somehow dismiss the ability to do a fixed conversion from 
the screen to sRGB!

>> Stop pretending the sRGB data is clamped! It is not and can specify any 
>> color in any well-known 3D color space.
> 
> "sRGB" has been, since inception, and now for a very long time since, been used in vernacular reference to a clamped RGB color space. If you mean something else, then qualification falls on you. Not for the reader to assume.

OK I have tried calling it "unclamped sRGB". There are suggestions that 
it be called "scRGB" but I worry that this also implies the .5 offset 
that Microsoft added.

I tend toward just "sRGB" because I think that should be obvious from 
the floating point api. Nobody complains that the api is not 0-255, that 
is obvious from it being floating point. The unclamped nature should be 
just as obvious.