[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 16.02.10, 14:49 -0800 schrieb 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

Correct.

> based on it can be controlled fully by a 3D color description. However I

No. Its possibly to do major channel magic beside the CIE*XYZ/Lab 
reference with arbitrary channels. Do not ask me how it works. Buts 
possible and to a great success used. lcms has code for it. Its all not 
in the ICC standard but the exchange format - ICC device link profiles.

> 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

The intermediate is a reference. No one is forced to convert pixel to that 
directly.

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

Ink dot coverage? What is that? I am no printer.

> 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

If the sRGB floats to montior RGB conversion is handled in the according 
cairo backend I agree. For printing, some users prefere to supply Cmyk 
directly. No deviceN in Cairo == no way to pass it to PDF.

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

Let me translate to CM terms, this would read: the user needs to specify a 
desired output ICC profile for a particular device if it is not already 
available from the output device itself. sRGB floats are converted then 
from sRGB primaries to the output ICC profile.

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

This rejects the deviceN, including Cmyk case. I do not argue that this 
has to be a first step of providing hooks in cairo for a real CM API 
other then the current toyRGB thing.

For the "sRGB only" model I would ilke to summarise some preconditions for 
a real CM API:
* float support in cairo, to allow negative values with sufficient
   precission
* a CMM which can handle floats precissely, lcms2 is on the path to that
   but not much tested yet
* APIs in cairo to tell a backend which colour space to convert to on
   output
* embedd that ICC profile to the output by the cairo backend

(I am pretty shure to have some cairo terms not correct.)

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

Thats lossy. Colour conversions are to be avoided. Tagging can be so easy.
But admittedly such colour management could work to some extent.

What I really wonder is the suggestion that floats might be no problem to 
implement in cairo but more than 3 channels are. Pretty all blending 
operations work in a single channel plus alpha. From that logic it makes 
a small difference if a image is
gray+alpha, duotone+alpha, rgb+alpha, cmyk+alpha ... deviceN+alpha


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

But it remains a bottleneck compared to sending Cmyk to cairo. A
conversion must be somewhere anyway.

> You seem to think that the application should instead send the
> description of deviceA with the image data. The reason if I understand

Yes, it is called in CM land tagging with a ICC profile.

> 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

Cairo can not do this itself. It can eighter use a external library for 
that, lcms is widely used, or provide hooks to plug-in that CM functions.

> practice. First of all you have enormously complicated Cairo by adding
> this api and the need for Cairo to interpret this device description.

No no. Cairo should not directly interprete ICC profiles. There are 
libraries for that. What I belief is that the code to pass meta data like 
ICC profile can be modular in cairo. As well code to service colour 
conversions can be modular in cairo. For that to work cairo needs a 
concept of when to call the colour conversion hooks. This is typical the 
input to blending space, blending space to output space and input space to 
output space conversion. Admittedly this is a guess and needs to be worked 
out in more detail.

> 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

I cant follow here. Maybe my english. However a device description in form 
of a ICC profile is pretty flexible to convert to nearly any colour space 
which is in practical use today. So I would assume to convert from device 
X to device Y is not a problem for the ICC architecture.

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

By deploying a sRGB float model the colour conversion from input space to 
blending space, in this case a fixed sRGB, is just moved outside cairo. 
The cost for that is no support of deviceN and alternative blending 
spaces. I would never ever think of blending each colour space with each 
other. If thats what you are afraid of, I can only agree. That would not 
be supportable in cairo. But it is not what was suggested.

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