[cairo] Spot colors (and CMYK)
spitzak at gmail.com
Fri Feb 12 15:30:56 PST 2010
I absolutely agree with this!
If sRGB is unclamped floating point, it can fully specify any point in
any 3-Dimensional color space, including XYZ or any Lab space and any
other triplet of color primaries and any 3-primary ICC profile.
By the "keep it simple" principle this means there is no reason to have
more than 1 3D color space to specify colors, since the application can
convert any other color to it. By the obvious and OVERWHELMING
requirement to specify colors in sRGB it means that sRGB must be this
There also seems to be lots of indications from the color management
experts that all 4 and above dimensional spaces, including CMYK, are
highly device specific, and that all useable methods of converting them
to standard colors involve reducing that space to a 3D intermediate
space. Therefore I cannot see any possible reason to not have the
application do this and use the Cairo sRGB api.
MAYBE there needs to be a channel to communicate that a specific device
color is needed. This includes the CMYK inks. I think the best way to do
this is to examine exactly what PDF users need and add an api
specifically for that, just like there are many other PDF-specific apis
already in there. Most likely a "the current color is actually this spot
color" api that is ignored or unimplemented by other back ends. This is
just another channel composited just like RGB, Cairo does NOT calculate
ink mixtures, and compositing white atop it will just cause less of it
to be printed.
Also for a basic point about "color management": If your program takes a
screen shot and puts it back on the screen, or displays an 8-bit image
produced by another piece of software on that screen, and it looks
different, IT IS BROKEN. I don't care if some color management expert
says that somehow it is correct, I can tell it is broken and it makes
the software either unusable or very unappealing. This is something
Microsoft understands but it seems Apple and a lot of Linux folk do not.
The practical result is that buffers either must have much more than 8
bits or they must store sRGB values. If they are 8 bits then either raw
sRGB values must be sent to the display, or color management must be
done by hardware between the buffer and the display. If you do actually
store non-sRGB values the color space must be significantly close to
sRGB so that composite mixtures do not vary too much in color, in
particular on my work with Nuke I have learned that linear space is too
far away for users and they will complain.
Carl Worth wrote:
> I'm much more interested in optimizing the API than optimizing the
> So if floating-point RGB allows a user to specify exactly what the user
> could specify with LAB or XYZ, then I'm delighted to offer only the RGB
> API in cairo and have the application convert to that.
More information about the cairo