[cairo] Color space API

[Kai-Uwe Behrmann]

Am 15.10.12, 16:58 -0500 schrieb Behdad Esfahbod:
> On 12-07-27 09:55 AM, Adrian Johnson wrote:
>>   cairo_color_space_t *
>>   cairo_color_space_create_icc_from_memory (const char *data,
>>                                             int length);
>
> Stream constructor please, like other cairo API.
>
>
>> The device_rgb color space is based on the PDF DeviceRGB color
>> space. When both source and destination are in the device_rgb color
>> space no color conversion is performed.
>>
>>   cairo_color_space_t *
>>   cairo_color_space_create_device_rgb (void);
>
> Does it make sense to be able to attach color space to cairo_device_t, and let
> device_rgb mean "inherit from device"?

DeviceRGB is kind of a hack, even though a purposeful. It allows to use 
unaltered values. We see the need for such a thing during profiling, where 
the exact appearance of a raw colour value on a device needs to be 
measured, for early colour management inside applications, where later 
colour conversion is wrong and some more. So it is not exactly "inherit 
from device". It is more a "disable colour conversion, I am responsible 
for the result".

>> The following two color spaces are used by SVG. There is an sRGB color
>> space and a linear color space with the same primaries as sRGB but a
>> linear gamma.
>>
>>   cairo_color_space_t *
>>   cairo_color_space_create_srgb (void);
>>
>>   cairo_color_space_t *
>>   cairo_color_space_create_linear_srgb (void);
>
> What's sRGV about linear_srgb?  Sounds to me linear_rgb.  Also, maybe instead

The colour primaries of sRGB and TV are defined in ITU Rec. 709.
Linear sRGB is appropriate, as it specifies completely the colour space.

> have a generic rgb space that takes a gamma value?

It makes sense to reduce the default colour spaces to as few as possible. 
That allows optimisation of blending operators to the according gamma 
functions. Typical gamma functions are linear gamma and sRGB curve gamma. 
Linear gamma requires eigther floating point precission or 16-bit 
integers to avoid heavy banding during compositing.

>> Some other ideas I have not yet implemented:
>>
>> Spot colors could be implemented with a color space constructor that
>> takes the name of the spot color and returns a 1 component color
>> space. The one component selects the tint value. The constructor also
>> specifies an alternative color space and color to use for surfaces
>> that do not support spot colors. When falling back to using the
>> alternate color the tint value can be used as the alpha of the
>> alternate color.
>>
>>   cairo_color_space_t *
>>   cairo_color_space_create_spot_color (const char *name,
>>                                     cairo_color_space_t *alternate_cs,
>>                                     double *alt_components);
>>
>> 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().
>
> As far as I understand, blending should always happen in linear space.  But
> reading the thread I see that thi cannot be extracted from ICC profiles.
>
>
> One thing I see missing in the API is color intents.  Was that intentional?

Oops, yes. That is completely missing. The API could be added to the 
surface. The rendering intents are photographic, relative colorimetric, 
saturation and absolute colorimetric. The black point compensation is now 
officially supported by the ICC and would be in combination to each of 
the above except absolute colorimetric.

Additionally there could be effect profiles support added. Those allow for 
softproofing, sepia tone and other nice stuff. But that can be delayed for 
later on.

> behdad

kind regards
Kai-Uwe