[cairo] Color space API

[Andrea Canciani]

On Sun, Jul 29, 2012 at 2:43 PM, Adrian Johnson <ajohnson at redneon.com> wrote:
> 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.

I guess this confirms what I asked in the previous e-mail.
Sorry, I should have read the whole thread before replying.

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

In the PDF drawing model, to do this you would composite over a
surface whose colorspace is linear.
If you needed the destination to be in another colorspace you would
then paint the previous result on the destination.

Pseudocode:
dest = cairo_create_my_nonlinear_surface();
cr = cairo_create(dest);
cairo_push_with_colorspace (cr, my_linear_colorspace);

/* draw in linear space */

cairo_pop_to_source();
cairo_set_operator(cr, SOURCE);
cairo_paint();

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

In general it will not be possible to extract such a color space,
because ICC profiles can define a color mapping which is almost
completely arbitrary.


>
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo