[cairo] [RFC] Color space API (partial proposal)
spitzak at gmail.com
Mon Feb 22 14:36:36 PST 2010
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
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
More information about the cairo