[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 12.02.10, 15:30 -0800 schrieb Bill Spitzak:
> 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
> single space.

There is no one colour space. sRGB is one of many.

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

All colour management experts will agree that it is not possible to spcify 
(CMY) K behaviour with RGB or whatever tripples.

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

This approach is inflexible. It might easly end in having such special 
cases for the same task with many backends.

> 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

Broken software needs to be fixed. A screenshot needs the monitors ICC 
profile attached if it has no other means to know about the image data. A 
screenshot with the monitors ICC profile will show equal on the same 
monitor and on monitor with larger gamut. Some shifts for very saturated 
colours can happen on smaller gamut monitors.

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

Of course. Your "solution" does not work on multi monitor situations. As 
screenshots almost always are intented for remote observers, it is clear 
that colour management is the solution for that main use case. The 
question must be: can I produce a screenshot which looks identical on my 
laptop, my desktop computer monitor and on the monitor of others. Non 
broken adn correctly colour managed software together with correctly 
configured hardware can this. The hardware configuration is often enough 
automatic (EDID).

> 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

This is completely wrong. If a program wants a good usage of hardware then 
it needs to supply colours close to the hardwares colour space. sRGB is 
an ideal of less practical use for properly supporting particular 
hardware. Sending sRGB to a wide gamut or low gamut screen is completely 
off. Put both side by side and users will comply once they learned it can 
be done better.

> 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

In the cable?

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

A sRGB colour chooser is nice as a Lab one and others. I would not offer 
linear gamma colour choosers as a primary one.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org