[cairo] Spot colors (and CMYK)
ku.b at gmx.de
Wed Feb 17 01:42:19 PST 2010
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
> 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
> 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
* 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
* 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.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the cairo