[cairo] Spot colors (and CMYK)

[Bill Spitzak]

Kai-Uwe Behrmann wrote:

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

Possibly I misunderstood. You said "users see the print simulation on 
screen". Unless you are just using Cairo as a way to dump a CMYK image, 
the composited result of Cairo is NOT going to be any kind of 
simulation, unless we actually add compositing operators that are "act 
like you are printing ink here on this device".

A 100% opaque filled shape or a 100% opaque image, except for the 
antialised image, could produce exactly the predicted ink levels 
specified by some CMYK api or from a spot-color interface. But any 
compositing or blending is not going to produce a predictable color. The 
only predictable color would be to use the output CMS to convert the 
composited sRGB image into output inks, but this would produce a 
discontinuity with the solid areas that is unlikely what the user wants 
or expects.

My recommendation (no matter what is done about color management) is to 
say that the results are unpredictable for any result that is not 100% 
some spot color or some CMYK quad. But this means that the on-screen 
image is going to be wrong for these areas.

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

I always said there should be a way to specify the exact CMYK.

All I am doing is requiring the application to supply the sRGB 
alternative, rather than having Cairo calculate it.

> 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

Only the necessary precision to handle the output device space is 
needed. If the output device is sRGB then an 8 bit/channel buffer with 
clamped 0-1 values can be used.

If the output device is not sRGB then 16-bit half floats are probably 
needed, though an offset fixed-point format with a range of -.5 to 1.5 
would probably work well.

> * a CMM which can handle floats precissely, lcms2 is on the path to that
>   but not much tested yet

lcms does have a floating point api, but it is likely the internal 
implementation just uses integers. This is the sort of bug that makes me 
not want Cairo to call such libraries!

As full cms may not be needed (due to one of the targets being the fixed 
sRGB target) it may be practical for an application to use it's own 
library in my scheme.

Probably much more important is the need to support floating point 
images, otherwise the replacement images are all going to be clamped to 
the sRGB gamut.

> * APIs in cairo to tell a backend which colour space to convert to on
>   output

This is backend specific and only needed for backends that do not get 
this information from somewhere else (such as the device or by assuming 
the device is sRGB).

> * embedd that ICC profile to the output by the cairo backend

Again this is backend specific.

I think you are concentrating on "produce a .png with my embedded 
profile" while I am concentrating on "produce the image with maximum 
color accuracy on the output device the back end knows the full details of".

> 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

The problem is simply that anything other than sRGB will require 
information attached to it to specify exactly what it is. From what I 
have seen of color management, this information is much much too 
complicated for a back end to be forced to interpret.

Floats are no problem for modern GPUs. If floats are a problem I believe 
all of color management is a problem and almost certainly not supported 
by the device, which is why I am trying to design the conversion to sRGB 
to be trivial, as this would be used by all simple devices.

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

Yes I understand that the composited operation would be faster.

However in my experience I have needed the device-independent color spec 
anyway. This is needed to produce predictable results or to show 
information to the user, and to talk to back ends other than Cairo. In 
our software this has defeated any such composites, and in fact we have 
to do considerable work to extract half-composites from cms back ends 
(Nuke works in "linear sRGB" which has no gamma curve, and the cms 
libraries are very poorly equipped to handle input that does not follow 
a gamma curve, due to bad design of the 1D lookup tables). We have 
pretty much given up on using cms libraries and now do the conversion 
with our own code.

> No no. Cairo should not directly interprete ICC profiles. There are 
> libraries for that.

There are libraries to choose and render fonts and lay out text too. 
Text just took a few seconds to add to Cairo because of these libraries, 
it was so amazingly easy! And the information required for pdf's was 
just instantly available because of the magic ability of the library 
authors to think about and predict exactly what pdf's needed! Wow, I am 
so impressed with the power of libraries!</sarcasm>

You say there is this new "device link profile" that is "not yet 
supported by lcms or most other cms libraries". Okay, we are off to a 
great start as we are already not supporting something and we haven't 
even written anything yet!

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

All CMS libraries I have ever encountered work with a very tiny subset 
of the possible profiles. In particular they fail in spectacularly bad 
ways when you combine unexpected profiles together (basically any pair 
other than a computer screen and a printer was unreliable, so attempts 
to use these libraries for linear sRGB in particular was useless).

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

Okay that is good to know.