[cairo] Spot colors (and CMYK)

[Bill Spitzak]

Chris Murphy wrote:

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

If programA displays shit and programB displays "the correct image", the 
users are going to say "programA is shit". The "fact" that the image 
itself is broken is useless, the user can clearly see that programB does 
"the right thing" and any attempt to explain this by the authors of 
programA is going to be interpreted as "not only are the authors of 
programA idiots, they are also arrogant assholes that refuse to fix 
their mistakes".

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

Sorry I meant exr files, not exif. However we certainly ignore exif data 
in jpeg files, except to attach it as metadata that the user can use as 
wanted.

For exr files we undo YUV and remove the fixed gamma to get linear sRGB. 
The exact math is fixed and cannot be varied by any codes in the exr 
file. Some care has been put into making sure the exr writer does the 
exact opposite conversion. I can assure you this is exactly what users want.

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

I am talking about OBVIOUS color shifts, not compression artifacts. It 
is blatently obvious that the original color image would compress just 
as well. Often the artifact is an *increase* in color saturation which 
compresses worse!