[cairo] Spot colors (and CMYK)

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

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.

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

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.

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

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!

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

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

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.