[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 23.02.10, 11:35 -0800 schrieb Bill Spitzak:
> Kai-Uwe Behrmann wrote:
>
>>> 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 address such flaws.
>
> That's great but I still find it dubious to say "we will make Cairo call 
> these libraries" when in my experience those libraries have bugs. Yes bugs

Possibly your app do not want to call lcms1 or any other integer CMM. I 
would thnk that of a use case to switch or hook in a own CMM or to have a 
means to avoid colour transforms. Tagging all input and requested blending 
spaces and output, for image formats, with one single space should get you 
there.

> get fixed but the fact is they were there, in supposedly professional 
> software. Actually open source versions were FAR better than commercial ones, 
> they may have been slower but they did not have any where as many bugs.

I talked about experiences with lcms1 the actual one. Its open source. I 
heard PS had not that issues. I think to have read, that app used early a 
floating point enabled CMM.

> It does seem however that usage of Cairo will be restricted to screen-like 
> color spaces so perhaps these bugs will not be a problem for most users. It 
> is annoying that I cannot use XYZ and other interesting spaces, though.

Floating point image support in Cairo would be of most help for this to 
happen.

>>> 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.
>
> The reason there is color information in the file is misguided programs stuck 
> it there, often with little or no correspondence to the values in the file. 
> Believe me, we HAVE to ignore it or it would be utterly impossible to get 
> images out that users expect and we would be swamped with support requests 
> and very irate complaints that our software sucks.
>
>> 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.
>
> Yes, therefore an api that could accept floating point linear sRGB as input 
> and convert it to the closest possible color on the screen would be useful 
> for us. However the Cairo api proposed does not do this: it only allows 
> integer images which means we must use a gamma-correct space  to avoid 
> posterization, and you are using cms libraries that screw up on linear spaces 
> anyway.

CM and floating point support in Cairo are two different and non exclusive 
goals. If asked, I would vote for both.

> Therefore the proposed Cairo stuff is useless. It is ENORMOUSLY easier for 
> use to convert to non-linear sRGB and send that which is why I was proposing 
> it as the desired api.

I think we are around a vision. Otherwise we could stop discussing 
the future of cairo and simply skip it for many applications.

>> 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.
>
> I don't think you have done customer support if you believe users will really 
> do this.
>
> If the Photoshop overlay composites wrong, then "your software SUCKS!!" No 
> amount of mathematical explanations are going to change their mind. They can 
> clearly see that Photoshop "does the right thing" so you can't claim that it 
> is Photoshop that "sucks" no matter how true that is.

I wonder how it is possible to render a CIE*Lab tagged image as Photoshop 
if the embedded profile is ignored. CIE*Lab and Rgb are so different. The 
same to a somewhat lesser extent for CIE*XYZ.

You guessed right about my customer support experience. But I have here a 
collection of images in very different colour spaces derived from the same 
original. All look nearly identical in apps which honour the embedded 
profile. What looks strange to me are those apps which do not handle to 
embedded ICC profile. So I guess what curstomer support in this case would 
mean. And editing in CIE*Lab for e.g. switching the colour of some 
objects, is completely on toppic. I do this trick since years and others 
even much longer. Its done for fashion catalogs all the time.

A good example of what honouring ICC profiles can mean is demonstrated on 
a test page at color.org:
http://www.color.org/version4html.xalter

My FF version matches in the above page only version 2 ICC profiles.
This is grap and easily a support request.

> And these are PROFESSIONAL digital artists, who work with 3D rendering 
> shaders all the time and have a pretty detailed knowledge of how light works. 
> The home user trying to make a lost-cat flyer is going to be even harder to 
> persuade!

A app, which ignores specified colour will not easily fit into the series 
of tools which honour colourimetry. PS is one of them. Apples Preview in 
SL, as far as I have played with, an other.

>> 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.
>
> Are you saying Cairo should blend in the source color space? What happens if 
> I print two things in different color spaces atop each other?  What if I then 
> print another image atop that? Please answer with a LITERAL description of 
> the resulting match and exactly what ends up in each of the channels of the 
> device and how exactly this works with a finite number of result channels.

I think cairo should have an ide of blending colour spaces. This concept 
would easily support the PDF model, which Francois Robert pointed to.

>> linear CIE*XYZ would be blending space. By controling the in and out 
>> conversions you say what is in blending space.
>
> Linear XYZ will produce the same result as linear sRGB or any other 3D linear 
> space where 0,0,0 is zero energy.

Yes, if the final conversion to screen or other media honours the 
according primaries.

> I don't believe you want linear XYZ as the blending space. As I pointed out 
> before this will break all existing alpha composites, it also will cause 
> white-on-black text and thin lines to look much too thin. But it will also 
> require floating-point intermediate results. I figure the Cairo backend will 
> mix in device space all the time, because I really cannot see any possible 
> practical implementation otherwise.

If cairo supports a user selectable blending space then that will not 
necessarily be the final output space. Output and blending space should be 
considered as different in apps and thus in a CM enabled cairo.

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