[cairo] Spot colors (and CMYK)

[Bill Spitzak]

Kai-Uwe Behrmann wrote:
> 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?

No, the CMS literally produced garbage, even though we tried to fool it 
by making fake color spaces like sqrt(XYZ/16) and so on in an attempt to 
make it look more like a video screen. It really did not handle anything 
that was not RGB primaries.

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

We ignore any such header information in EXR files, and do not write it 
on output.

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

Matching to the screen is done as a final step in Nuke, by allowing the 
user to define an arbitrary set of Nuke operations as the "viewer 
process" (in modern usage they typically define a single 3D color lookup 
operator). All internal image processing is done in a single color 
space, and this user-defined conversion to the screen when it is displayed.

It was intended that this space be linear sRGB primaries and file I/O's 
only "color correction" is an assumed sRGB gamma curve when reading and 
writing a number of image formats. More recently an user-controllable 
option has been added to decide which gamma curve is used when 
reading/writing each file, though the primary reason is that we are 
finding far too many floating-point formats that have sRGB gamma baked 
in and there is no way to tell without user input. There are also 
obvious "color space conversions" such as changing a file that is Yuv 
into sRGB before this gamma conversion.

There has never been an attempt to change the color space other than 
this, and I can assure you that there is no request for this from users. 
Even the gamma removal is proving to be a problem, the users do not 
understand why their carefully-painted Photoshop overlays suddenly have 
visible edges when composited in Nuke. These are CG artists who should 
understand this stuff, I shudder to think what will happen if the 
typical computer user gets this sort of problem.

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

How can it be "optional" when it is impossible to figure out what color 
is intended to be displayed when the the image is provided to Cairo? It 
sounds like you want to limit all the input spaces to stuff that is 
"like" sRGB so that a back end that ignores the color gets the "right" 
ones, but this removes all the interesting possibilities such as linear 
spaces and XYZ.