[cairo] Spot colors (and CMYK)
spitzak at gmail.com
Wed Feb 17 12:26:11 PST 2010
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
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
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
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.
More information about the cairo