[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 18.02.10, 11:21 -0800 schrieb Bill Spitzak:
> Kai-Uwe Behrmann wrote:
>
>> So you see quality problems with CM in your workflow. Thats interessting. I 
>> had perhaps similiar problems with lcms and CIE*XYZ and other big gamut 
>> differences in colour space conversions. This was really troublesome. 
>> However, I did not exact round trip tests for gamma as I work more with 
>> stills.
>
> Yes, the libraries are often useless due to bugs when presented with color 
> spaces that do not resemble the printers and screens they were designed for.

You possibly mean the gamuts are too different and then a colour matching 
module has a hard time to be precise? At least that was my impression and 
confirmed by internal logic of ICC profile conversions at time as I 
pointed that out.

However most of us mere mortals have not much of a chance to do such 
advanced stuff ourself. So CM is the only grip to the heaven of matching 
colours.

> Though technically spaces like XYZ and linear sRGB can be defined for them, 
> they fail to convert it correctly. This means we end up doing the conversion 
> ourselves using manual code.

Correctly is good. I completely agree in cases there good roundtrip 
behaviour is needed. But CM people have at least developed strategies for 
preserving precission. This is the reason why its always recommended to 
have as few as possible colour conversions in the processing pipe.

Obviously fixed conversion math has not this limitation.

> This is why I am extremely doubtful of any idea that Cairo will call some cms 
> library. I think the result will be the same: you can use the tiny subset 
> that people tested, limited to the parts of the icc definition that the 
> library writer thought were important (ie no device link if you use the 
> current libraries) and you will have to bypass the whole thing anyway as soon 
> as you try to use interesting spaces like XYZ.

In large parts I agree with you about precission and so on. However, I 
have great trust that the demand is there to solve that precission 
problem inside the ICC. ICC had to learn that printing is not the only 
field of CM. And I think they are on the right path with that. Ok, ILM 
thought they need too long.

>> I think ICC has slowly came to adress round trip requirements for motion 
>> pictures in its cinema work group. An other initiative comes from ILM with 
>> the OpenEXR CMS called CTL.  I would expect it to meet the needs of
>> exact colour conversions in the motion picture industry. Did you evaluate 
>> that?
>
> CTL is using an interpreter like a shader language and I doubt is something 
> we want in Cairo. It also is entirely for light-emitting devices (things like 
> paper and viewing space are missing) and many parts of it explicitly say 
> there are 3 channels, therefore I don't think it interests you. This is 
> exactly the sort of design that I think applications should do and where an 
> explicit space (possibly defined by CTL) is used as the Cairo API.

With CMS hooks in cairo ILM's CTL or OpenGTL would be a option to use.

> We ignore CTL, what we are doing is storing linear sRGB in OpenEXR files.

Linear is the recommendation. But the header contains primaries. How does 
you refere to scene values or film look when the data is altered?

You must be allowing users an alternative path to match to screen. Or is 
the header ignored and the colour characteristics stored on a per project 
basis?


Again ICC CM matches much better the still and printing needs.
The energy needed to build a acceptable workflow from camera through 
effects and editing to the colorist and cinema is not small I guess. But 
many photographers need a solution, which is at best automatic. They put 
as well energy in their workflows. But they have not a colour specialist 
in house and must live with some suggestions or a three day course for 
that matter.

What wonders me is why you reject a completely optional feature in cairo, 
which is not much touching your workflow if you want not. I can imagine 
not only your situation where a enforced CM is not desired. A CMS should 
have means to completely bypass colour conversions. But at the same time I 
have the trust that most users want applications with colour management.

> This appears to be the normal solution in most of this industry today. The 
> only other common alternative is to store non-linear sRGB in the files, which 
> I personally hate for actual imagery but the popularity of this is why I 
> think the non-linear sRGB api to Cairo is more important than a linear one.

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