[cairo] Spot colors (and CMYK)

[Bill Spitzak]

Kai-Uwe Behrmann wrote:

>> However we all agree that unclamped sRGB values can be converted to 
>> all other 3-dimensional color spaces, including XYZ and Lab. So it is 
>> sufficient for all 3D spaces.
> 
> The CMS Oyranos uses end to end colour transforms bypassing the 
> 3-dimansional PCS during colour conversion.

Bypassing is not the same. If I have a transform from 4D to 3D and 
another transform from 3D to 4D, I certainly can multiply them into a 
single 4D->4D transform. That does not cause more than 3D of data to be 
passed, the same points that map together still will. That would be like 
claiming that if you multiply the conversion from Dollars to Pounds and 
Pounds to Euro, you can convert monetary values that cannot be specified 
in Pounds.

ICC describes all devices in a 3D space. Therefore any color management 
based on it can be controlled fully by a 3D color description. However I 
am open to proof of a popular device description that uses more than 3 
dimensions to describe the intermediate color form. But I have not seen 
anything other than "spot colors" which by definition CANNOT be 
transformed to other devices (a 3D simulation can but is 
indistinguishable from that same 3D simulation specified without the 
spot color).

> user can work in Cmyk, while seeing the print simulation on screen and 
> then print the same colours to the intented printer or massage the 
> output with through additional Cmyk to Cmyk conversions.

You are not claiming that Cairo needs to calculate how ink dot coverage 
will work when compositing images, are you? At least I hope not, but it 
sure sounds that way, that is pretty scary!

I absolutely think that "simulate how the printer deposits ink" is a job 
for the application. It can calculate the resulting sRGB value and send 
that to Cairo. Cairo can then produce this simulation with as much 
accuracy as possible on various output devices. To actually control the 
ink deposit the device-specific api must be used, or the application can 
use Cairo to produce color separation images and then draw those 
directly on the device.

> All CMS work like this. Needless to say that sRGB is out of scope for 
> Cmyk editing.

The program can edit in whatever space it wants. It just needs to 
convert to sRGB when sending to Cairo. I can assure you that there are 
editors that keep track of "shapes" or even 3-dimensional models and 
lights, or thousands of channels and operations per pixel, but nobody 
seems too worried that the program has to do some "conversion" before 
sending it to Cairo.

>> independent interpretation is done by reducing to 3D, therefore the 
>> application can do the 3D reduction itself and use the 3D sRGB api.
> 
> Applications should rework cairos backend output? Are you talking about 
> the same cairo: one drawing API ==> multiple outputs?

I don't understand what you are asking about.

If the application has an image in deviceA space and wants to draw it on 
Cairo's deviceB, it converts it to sRGB and sends it. Then Cairo 
converts from sRGB to deviceB.

Now it talks to another Cairo back end for deviceC. Again the 
application converts the image to sRGB and sends it. Then Cairo converts 
from sRGB to deviceC.

THE APPLICATION DOES EXACTLY THE SAME THING IN BOTH CASES!!!

You seem to think that the application should instead send the 
description of deviceA with the image data. The reason if I understand 
it is a belief that there will be more efficiency by Cairo multiplying 
the two descriptions. However in work I have done this fails in 
practice. First of all you have enormously complicated Cairo by adding 
this api and the need for Cairo to interpret this device description. 
Second you have limited the device description to whatever Cairo 
implements portably and without error, which from experience I know is a 
tiny subset even for very expensive commercial software. In particular 
there are huge sets of device descriptions that do not mulitply 
correctly, pretty much forcing us to use a fixed one as the api anyway. 
Also I have yet to work on a piece of software that does not have to 
understand the device description anyway, for instance to show something 
like "what is the XYZ of this pixel".