[cairo] [RFC] Color space API (partial proposal)

[Bill Spitzak]

Okay I think I am going to need an EXACT answer to these questions to 
figure out this API. I have to admit I do not understand color managment 
and I think some of the terms are misunderstood.

True or false:

1. "color managment" is able to take any color in color space A, plus 
the descriptions of color space A and color space B, and convert that 
color into a "similar" color in color space B. The answer depends ONLY 
on the color, the two color spaces, and an extra enumeration called 
"rendering intent".

2. This is only efficient if color managment is given both space A and B 
together, converting to a color-space-independent intermediate form is 
too inefficient to consider.

3. It appears that pixel-buffer surfaces such as images and gradients 
have a color space attached. This is a "destination" space. All color 
mixing performed on that surface is done in this destination space, and 
in fact a Cairo implementation that mixes in anything other than 
destination space is incorrect.

4. Colors and images sent to Cairo have a color space attached. This is 
a "source" space.

5. The "destination" space of a pixel buffer surface or a gradient also 
becomes the "source" space when that is used to render onto another 
surface. (ie despite the fact that it would be trivial to implement, 
making these spaces different is purposely discouraged by the api).

6. A correct Cairo backend can be implemented that will IMMEDIATELY (ie 
before the call to set the color or image returns) convert the color or 
image to destination space and throw away irretrievably the "source" space.

7. The png backend will write the destination space description to the 
resuting .png file, and reading a png file will act as though you 
created a surface with the space in the png file. Other backends that 
can read/write files with an attached color space (like pdf) will act 
this way as well.

8. Many backends in fact have no control over the output color space. 
The most obvious is a screen or printer but this is also true of lots of 
file formats. If told to render in some arbitrary destination space such 
backends will do one of two things: display that destination space "raw" 
on the device, or use hardware or an extra buffer to convert from 
destination space to some final display space (it must use a second 
buffer because the destination-space data cannot be destroyed). Which is 
done depends on the backend and there is no control.

9. There is a trivial way to say "the space the device likes". Programs 
can assume the result is a 3-channel RGB-like space (thus this is a 
different API than "the device space" because that could be CMYK). 
Programs can assume that if they use this space everywhere then speed is 
  maximized.