[cairo] [RFC] Color space API (partial proposal)
ku.b at gmx.de
Tue Feb 23 01:09:19 PST 2010
Am 22.02.10, 14:36 -0800 schrieb 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".
While the numbers change, the appearance shall be preserved. Depending on
the colour space sizes some arrangement has to be defined for out of gamut
colours through the rendering intents. For this there are more options
possible than four rendering intents.
> 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.
That should be the default.
> 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
If a surface is used to blend into an existing document the image colour
space is the input colour space to be converted to the documents blending
colour space. For gradients I found the term interpolating colour space
Imaging the blending colour space as the central space to convert into on
input and convert from on output seems the most plausible to me.
> 4. Colors and images sent to Cairo have a color space attached. This is a
> "source" space.
Yes, or more exactly: they are input colour spaces for blending used as
source colour space ducing the conversion to blending colour space. The
blending colour space is in this particular conversion the destination
> 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).
Yes. "discouraged" meaning not impossible but some more work.
> 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.
Yes, e.g. the Xlib backend.
> 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.
Yes, on write the PNG is written with the blending space embedded. On read
the embedded profile is read and assigned to the image surface for
blending or conversion.
> 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.
For monitors the control is typical provided by the operating system or
its conventions. The print colour space is often set in the app by the
user or to be detected by the local print system.
> 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.
The output space is for many backends the same as the blending space on
that surface. PNG should not alter and just embedd as should PDF.
Xlib should implicitely convert from whatever blending space to the device
space. Xlib might use several ways for that. The Xlib backends fallback
would include to use a intermediate buffer. There are several
optimisations possible. For low power consumtion display devices omitting
the Xlib conversion by setting the display profile to the real sRGB might
be a option. That later decission is outside of cairo.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the cairo