[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 22.02.10, 13:16 -0800 schrieb 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.

Well I would say then the standard has flaws or the CMM. However I pointed 
out the recent work was done to adress such flaws.

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

Strange, why is it there in the first place? As I read the spec, CIE*XYZ 
is the prefered colour space. What do you do if you get such colours. They 
look hardly like sRGB primary wise.

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

This matches to one usage scenario with CM. Process in a 
blending/compisiting/editing/working space and convert on the fly to 
output. OpenEXR would remain linear Half sRGB and on screen it would be 
matched to EDID primaries + gamma or a more accurate ICC profile.

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

This reads like you are considering colour space conversions more as fixed
encodings. While it preserves you many details and shurely valuable 
control, the cost is a much lower degree of defining what colour should 
mean. Your approach cares much about the details inside a colour space by 
ignoring the over all colour space shape.

Good colour management should provide both, quality and accuracy despite 
of currently possible bugs. This thread is about automatisation mixed with 
a optimism that bug are fixable in CM land. Why not?

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

These CG artists will carefully try out what works and what not. If they 
are tould that only sRGB gamma works they will use that. The point is, can 
a technice allow them to forget about such colour space/gamma issues? CM 
would enable that. A novice trying to CIE*L start kind of gamma would have 
a hard time with your app until s/he reads that only a certain gamma works 
for that particular workflow. In contrary with CM the conversion could be 
automatic, for your app into linear sRGB. So you burden CM knowledge to 
your users by avoiding automated CM.

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

This will become more and more a system issue as CM is intented to work 
system wide. However the colour space used internal to the app is not 
affected. You can blend in whatever you want. If your app limits this 
decission by converting always to linear sRGB on input and from linear 
sRGB on output, this is fine with CM. Your app should behave as you 
intent.

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

The input space is unequal to the blending space.
The blending space is unequal to the output space.
linear CIE*XYZ would be blending space. By controling the in and out 
conversions you say what is in blending space.


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