[cairo] Spot colors (and CMYK)

[Bill Spitzak]

Kai-Uwe Behrmann wrote:

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

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.

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

Obviously mathematically a 4D space cannot map to a 3D space without 
multiple values mapping to the same one. However from all the discussion 
here it appears that ALL color management is done by passing through an 
intermediate 3D space, so this loss of data is apparently not a real 
problem.

Therefore the 4D space is only useful for a device-specific api. All 
device independent interpretation is done by reducing to 3D, therefore 
the application can do the 3D reduction itself and use the 3D sRGB api.

>> MAYBE there needs to be a channel to communicate that a specific device
>> color is needed.
> 
> This approach is inflexible. It might easly end in having such special 
> cases for the same task with many backends.

That is EXACTLY what I intended. I want to make absolutely certain that 
none of this crap has to be defined by Cairo. I believe that 100% of the 
use of any such api is "get this stuff I need into the pdf" and 
therefore the closer the api resembles "the stuff in the pdf" the better.

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

You are living in a fantasy world if you believe screen shots have ICC 
profiles attached. This is not true even on OSX.

More importanly, "attached profiles" are NOT WANTED, EVER! I work with 
professional image processing software, and we long ago learned that 
attached profiles are NEVER wanted. We ignore them in png, we ignore 
them is exif files, we ignore them in Red camera data. One of the 
biggest pains at The Foundry is figuring out how to ignore profiles in 
Apple Quicktime files and get the raw data. Please take a look at the 
Nuke release notes if you don't believe me. This crap is occupying at 
least one developer 100% of the time and many other are working on it. 
Currently Nuke is using ffmpeg whenever possible, it reports raw YUV 
values and we do a FIXED and predictable conversion to sRGB. THIS IS 
WHAT USERS WANT!!!!

In real software, "correctly displaying" is a very very very rare 
desire. "lossless in/out" is ENORMOUSLY more important. And I am sorry 
to report, but users think that "strip the profile" and "display with a 
program that ignores the profile" should be lossless operations. No 
arguing from color theorists is going to change this and we have to live 
with that fact and make software that is actually user friendly.

> Of course. Your "solution" does not work on multi monitor situations.

I don't know what you are talking about. My solution is the ONLY way I 
can see to work on multiple monitors. The input to Cairo has to be in a 
defined fixed color space, and then it can be converted as needed 
correctly to each monitor. I do not think any application should have to 
change the data it sends depending on the monitor.

> As 
> screenshots almost always are intented for remote observers, it is clear 
> that colour management is the solution for that main use case.

That is nonsense. Screenshots are used locally. I want to look at a 
pixel with a color picker and know exactly what values software needs to 
communicate to Cairo or whatever to get the same color. I want to paint 
on that screen shot and send it back to the first user and they see the 
same colors they got initially. "color management" makes this impossible.

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

Absolutely you can do this. Cairo will return a "screen shot" as sRGB 
values. You then send it to another screen as sRGB values. And it will 
look "identical". In a perfect world this means that advanced color 
correction will cause the display to emit exactly the photons defined by 
sRGB and all your devices will be emitting these exact same photons.

In the real world you have to remember that "identical" means that if 
there are 256 levels in the image, I better get 256 different output 
levels. If I pick a color off the image and put it into my painting 
program and then display that painting I must get the same color. If 
there is a beautifully dithered smooth gradient in the image, I better 
not see banding or posterization. A ramp that is as smooth as possible 
better not have Mach highlights in it (which would be caused by a lookup 
table that clamps or otherwise does not have a continuous derivative).

I think that color theorists are ignoring the above. Users think that 
huge skews in the emitted photons are "identical" but consider problems 
like I have listed to be unacceptable differences. Color theorists have 
got to learn how the real world works. We are not looking at flat fields 
of color, we are looking at images with tons of information stored in 
the higher frequencies and that information must be preserved!

 >  The hardware configuration is often enough automatic (EDID).

I would agree. If possible Cairo should be using such settings to 
convert sRGB data to emit the correct colors from the screen. However 
this has nothing to do with the Cairo application API.

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

Stop pretending the sRGB data is clamped! It is not and can specify any 
color in any well-known 3D color space.

>> sRGB values must be sent to the display, or color management must be
>> done by hardware between the buffer and the display.
> 
> In the cable?

Yes, if the buffer is only 8 bits then that is the ONLY possibility.

There are only two possible designs:

1. The buffer contains sRGB values and output hardware converts them to 
the display. This is the ONLY solution if the buffer is 8 bits as there 
must be 8 bits of fractional resolution so that images are lossless. If 
your display has a larger gamut then either it cannot display the full 
gamut, or a *SIGNED* format with at least 8 bits of fraction must be 
used (16 bit half is probably best as it has hardware support, if you 
insist on integers than an offset with a range like -.5 to 1.5 is 
needed). Note that unsigned larger than 8 bits is almost useless.

2. The buffer contains values that are linearly related to what the 
hardware requires, this can use clamped integers. As round-trip 
conversion of 8-bit sRGB must be the identity, this requires I believe 
10 bits for Adobe RGB and even more bits for higher gamuts. As 
compositing will be done in this space and this puts serious limits on 
the gamma, it cannot vary too much from sRGB due to applications relying 
on 1-x being perceptually inverted and how partial transparency composites.

Notice that if the buffer is 8 bits and there is no hardware conversion, 
then the only possible implementation is to claim that the buffer 
contains sRGB data. It does not matter how screwed up the display is, 
that is the best you are going to get.