[cairo] Color space API

[Adrian Johnson]

On 28/07/12 05:49, Bill Spitzak wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> Any other interpretation I think results in unworkable difficulties.
> 
> Correct/incorrect?

That is correct. The destination surface is set to the color space of
the destination device. Source colors are converted to the destination
color space before compositing. If the application wants to do
compositing in a different color space it can create a similar surface
with the different color space, composite to it, then paint it to the
destination surface.

When using the PDF surface, the color space of the destination device is
usually not known. Instead the PDF page is set to the color space that
compositing will be done in. When the PDF is rendered the destination
surface is set to the device color space, a similar surface with the
color space of the PDF page is created then rendered to. The colors will
be transformed to the device color space when the similar surface is
painted to the destination surface.

> 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 believe your proposal has no possible setting that will cause this to
> happen. I think this can be a different setting, independent of the
> destination color space. Either it is a flag on the destination
> surfaces, or it is different compositing operations (ie LINEAR_OVER
> verses OVER). I don't think it is part of the colorspace, because it has
> no effect on how the source is handled.

I don't currently have a proposal for this since looking at the ICC
specification I could not see how to extract this linear space from an
ICC profile.