[cairo] Color space API

[Kai-Uwe Behrmann]

Am 27.07.12, 13:19 -0700 schrieb Bill Spitzak:
> In your plan, if an on-screen surface is given colorspace X where X is not 
> sRGB, what does this mean? I think this is what leads to a lot of the 
> confusion when color space is discussed.
>
> IMHO the solution is that the numbers in that surface are put unchanged on 
> the screen. Thus no matter what colorspace it is set to, if there is a 5 in 
> the red channel of a pixel, then a 5 is put into the output buffer sent to 
> the screen.

If a other level in the display stack decides to do colour correction,
then your assumtion is simply non valid. Backends in Cairo can only 
properly support existing and future conventions or loose control. That is 
exactly the situation today.

> The way to get color-correct output is to set the destination surface to the 
> colorspace that the screen (or the input to the screen driver) has. Changing 
> the destination colorspace never changes the appearance of that surface on 
> the screen.

The API appears to explicitely discurage changing a surface profile after 
the first draw. So where can a change of the destination colour space 
happen?

> What the colorspace of the destination does is indicate what conversion is 
> done to source colorspaces before compositing. The destination can be set to 
> Y and the source to X, and what happens is the source is run through the X->Y 
> conversion before compositing. However after the numbers come out of the 
> compositing, the setting of Y has NO effect on what happens to those numbers. 
> They go onto the screen or output device unchanged.

In most situations that makes no sense. A ICC tagged PNG from Cairo must 
be colour corrected before displaying and will likely need a different 
conversion during printing. A image put on screen (X11) will likely see 
colour correction on multi monitor setups.

Are you after a disable colour management path alias leave numbers as is?

> Any other interpretation I think results in unworkable difficulties.

I do not see difficulties. Say what you want and need and we can discuss 
that more efficiently.

> Another aspect is "linear" or "gamma corrected" compositing. In this both the 
> source *AND* the destination are converted from their spaces to a "linear" 
> space, composited, and then the result is converted back to the destination 
> space. The linear space is chosen so this conversion is fast (it has the same 
> primaries as the destination).

I think the interaction of gamma and compositing was discussed recently 
for the wayland API, but do not much remember the details or outcome.

kind regards
Kai-Uwe