[cairo] Spot colors (and CMYK)
spitzak at gmail.com
Tue Feb 16 14:49:25 PST 2010
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
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
> 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".
More information about the cairo