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

[Kai-Uwe Behrmann]

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

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

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 
very nice.
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 
colour 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).

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.


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