[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 17.02.10, 12:49 -0800 schrieb Bill Spitzak:
> Chris Murphy wrote:
>>> 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.

For internal data it is often enough fine to have a application wide fixed 
colour space. Many apps do so. But in the context of cairo we talk about 
the transportation of ICC profile meta data, honouring that data by 
backends and allowing alternate blending spaces.

I can see your special application would not much benefit from the 
proposed changes. You might be happy with fixed input, fixed blending 
space and a image backend for antialised buffers. (Perhaps floating point 
support is on your whish list. On my it is.)
But please understand others want more,

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

Thats a problem with the CM engine, not with CM as a scheme to handle 
colour.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org