Re: Color space API

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?

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?

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
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo