[cairo] Color space API

[Andrea Canciani]

On Fri, Jul 27, 2012 at 6:44 PM, Uli Schlachter <psychon at znc.in> wrote:
> Hi,
>
> On 27.07.2012 16:55, Adrian Johnson wrote:
>> In January/February 2010 there was a long thread[1] on adding a color
>> space API to cairo.
> [...]
>> [1] http://lists.cairographics.org/archives/cairo/2009-December/018717.html
>
> Does that link really point at the thread you want it to point to? This thread
> is from December 2009 and has only 3 messages.
>
> [...]
>> To simplify the implementation, my code currently only supports RGB
>> color spaces and only works with the image and PDF surfaces. There is
>> nothing in this API that restricts color spaces to RGB other than the
>> need to add additional color space constructors and image formats to
>> support non RGB color spaces.
>
> Does that mean that other backends (X11, gl, win32, quartz) would have to fall
> back to the image backend whenever a color space is involved?

Quartz has native support for both generic colorspaces and colorspaces
defined by ICC color profiles (with teh minor limitation that it only
supports colorspaces with 1, 3 or 4 components, which anyway covers
grayscale, RGB and CMYK).

Assuming that the drawing model is the same as PDF (and that I
understood it correctly), the colorspace in which the blending is
performed is the same as the destination one.
This means that the only color conversion is from source colorspace to
destination colorspace.
Moreover if they are the same, the conversion is not needed at all and
compositing can be performed forgetting about colorspace and no
fallback is needed even for backends which do not have netive support
for colorspaces.
(Ok, I'm cheating a little, this is only true for separable
compositing/blending operators...)

Adrian, can you check if this is how it's supposed to be?

>
> I think I heard something about color spaces with OpenGL. Does something like
> this exist? If yes, can someone check if the proposed API would work for OpenGL?
> [...]
>> The standard cairo functions for referencing, destroying and obtaining
>> the status and type.
> [...]
>>   unsigned int
>>   cairo_color_space_get_reference_count (
>>                              cairo_color_space_t *color_space);
>
> What's the use case for this function?
>
>>   cairo_status_t
>>   cairo_color_space_status (cairo_color_space_t *color_space);
>
> A color space can only be in an error state when it is created, right? Or is
> there some API which could cause a color space to get a "non-good" status?
>
>>   typedef enum _cairo_color_space_type {
>>     CAIRO_COLOR_SPACE_TYPE_DEVICE_RGB,
>>     CAIRO_COLOR_SPACE_TYPE_ICC,
>>     CAIRO_COLOR_SPACE_TYPE_SRGB,
>>     CAIRO_COLOR_SPACE_TYPE_LINEAR_SRGB,
>>   } cairo_color_space_type_t;
>>
>>   cairo_color_space_type_t
>>   cairo_color_space_get_type (cairo_color_space_t *color_space);
>>
>> ICC color spaces may contain different types of color spaces. It is
>> useful be able to find the type of an ICC color space.
>>
>>   typedef enum _cairo_color_space_class {
>>     CAIRO_COLOR_SPACE_CLASS_RGB,
>>     CAIRO_COLOR_SPACE_CLASS_CMYK,
>>     CAIRO_COLOR_SPACE_CLASS_GRAY,
>>   } cairo_color_space_class_t;
>>
>>   cairo_color_space_class_t
>>   cairo_color_space_get_class (cairo_color_space_t *color_space);
>
> What do these two enums have to do with each other? E.g. I doubt that I can
> combine SRGB with CMYK. So what's the difference between them and why shouldn't
> they be combined into on enum?
>
> Sorry if this was already discussed in 2010.
>
> [...]
>> The cairo_surface_set_color_space function allows setting a color space
>> of a surface (for use as either a source or destination). The default
>> surface color space is device_rgb but if it is to be changed it must
>> be done before any drawing operations.
>
> Just to be clear, if I try to modify the color space of a surface which already
> was painted to, it goes into an error state?
>
> [...]
>> cairo_push_group and cairo_surface_create_similar create a surface with
>> the same color space as the existing surface. The following two functions
>> allow the similar surface to be created with a different color space.
>
> Should there also be a cairo_surface_create_similar_image_with_color_space()?
>
> [...]
>> Antti Lankila has created a pixman patch for linear color space
>> processing[4]. In this case the source and destination are converted
>> from sRGB to linear rgb, composited, then converted back to sRGB
>> before writing to the destination. This could possibly be implemented
>> with a function like cairo_set_compositing_color_space() or
>> cairo_set_blending_color_space().
>
> Which backends (besides image) could implement this without fallback? Does this
> work for PDF, PS and SVG?

PDF and PS should be able to support all of this (with some trickery
because PS does not handle ICC profiles directly AFAIK).
SVG seems to have added some suppport for this:
http://www.w3.org/TR/SVG/color.html
Quartz has native support for color spaces.

>
> Does anyone know how calibrated displays can be used with X11 / Windows / Mac
> OS? I don't and I wonder how this API can be supported for those backends.
>
> Cheers,
> Uli
>
> --
> my $key = "\x49\x03\x93\x08\x19\x94\x96\x94\x28\x93\x83\x04\x68\x28\xa8\xf5".
>           "\x0a\xb9\x94\x02\x45\x81\x93\x1f\xbc\xd7\xf3\xad\x93\xf5\x32\x93";
> my $cipher = Crypt::Rijndael->new( $key, Crypt::Rijndael::MODE_ECB() );
> my $plain = $ciper->decrypt($daten);
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo