[cairo] Spot colors (and CMYK)

Tue Feb 16 23:34:09 PST 2010

On Feb 17, 2010, at 12:07 AM, Bill Spitzak wrote:

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

So Cairo necessarily needs to either a.) support conversions to such device spaces, or b.) preserve color profile metadata, so that these color spaces can be preserved when producing output files, such as PDF. Otherwise the PDF is limited to sRGB, which is crazy.

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

OS X has never generated JPEG screen shots. There were originally PDF but have been PNG for the last several major releases. You must have been using a 3rd party application.

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

This is going to take longer if I have to qualify twice, what has already been qualified. I did just say if the data is obviously wrong you can make a better assumption. But there is a huge problem with cleaning up other people's messes like this which is that it seriously harms the usefulness of metadata. You do not actually know that the TRC of the image is not 1.0, you're just assuming it, and it just so happens that you assume correctly the vast majority of the time. But now what that means is it's impossible to display images that are legitimately encoded linear.

PNG's chunks related to color and gamma have been rendered unreliable because there are too many lazy developers who are bright enough to know of such chunks, but as yet not bright enough to use them correctly. Suitable punishment is for the images produced by their software to look like shit by honoring the fact their metadata basically is saying "make this image look like shit".

But it's too late for that because too many PNG viewers cleaned up after the mess of lazy developers by ignoring the chunks, rendering them useless.

So now we have the same bullshit happening with ICC profiles? Fuck that. Display the image per the embedded ICC profile AWAYS. If the image looks like shit, FANTASTIC. You get to point the finger at some piece of crap software product and its idiot developer. Then it's up to them whether to fix their mistake or not.

Becoming responsible for other people's mistakes is a great way to ruin useful specifications and workflows. Doing so masks the real culprit.

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

Why is it encoded incorrectly in the first place such that you have to ignore color spaces? It sounds to me you are making the problem worse. EXIF should be honored. If it's wrong, then it's the fault of whatever is writing out that EXIF data. It should be identified, and the culprits ridiculed until they fix their software. Any alternative is double lazy.

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

It's obvious they do not expect this when it comes to compression artifacts - users routinely accept more artifacts if it's going to save them space, and space is their goal. So I refuse the premise that conversion between formats should produce an identical movie. The correct answer is, it depends.

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

I'm clearly not dismissing you. I'm dismissing rather select comments of yours that are from the lunatic fringe.

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

I never said such conversion was impossible, but then that indicates Cairo has full color management capability if it's going to convert from DisplayRGB to sRGB, and then embed sRGB into the screen shot file.

Neither sRGB nor DisplayRGB are arbitrary.

DisplayRGB to sRGB is likewise not fixed, because DisplayRGB is different for each display (or more broadly each display model lot).

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

It's not.

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