[cairo] [RFC] Color space API (partial proposal)

[Kai-Uwe Behrmann]

Am 22.02.10, 12:28 +0100 schrieb Andrea Canciani:
> On Mon, Feb 22, 2010 at 11:10 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:

>> cairo_color_t/cairo_t meta data:
>> Rendering intents are defined by the ICC standard. But as the system is
>> evolving several additional arguments are in the queue or will become to
>> that. Think of black point compensation (BPC) typical supported by most
>> colour managed linux graphics applications, or CMM specific options like
>> lcms' preserve black one.
>> So rather than placing this stuff into cairo_t
>> +cairo_public void
>> +cairo_set_render_intent (cairo_t                      *cr,
>> +                        cairo_render_intent_t  render_intent);
>> +
>> I would find it much more adequate to place it into cairo_color_t.
>> cairo_public void
>> cairo_color_set_render_intent (cairo_color_t         *color,
>>                               cairo_render_intent_t  render_intent);
>
> Since rendering intent is actually used only when a color space
> conversion is done,
> basically we can choose whether select a rendering intent for all the sources
> we are going to use (colors, patterns) or for all the destinations
> (cairo_t, gradients (they
> convert color stops to the pattern color space)).

I think now its a "and" and not a "or". On entrance of the blending space 
a conversion has to take place with all options. And on converting to the 
output colour space the same again, but possibly with different options.

So I should correct and say both ways to set colour transform options are 
needed, the per input and the per output options.

>> As well I would expect a means to transport non standard options (BPC) to
>> the final CMM (lcms?). This could then as well help with the spot colour
>> case and bring some flexibility in. Otherwise Cairo will quite often
>> requests about even small adds.
>> The situation is perhaps much like with specific cairo backend functions. A
>> key/value pair sort of API would be good? In my personal view it would fit
>> logical well to the cairo_color_t type of objects.
>
> Non-standard options are not planned yet. They could be added later, if needed.

They wold be rather soon needed. So it would make sense to think already 
about and kept in mind, how can this later be integrated.
If one looks at typical UIs, BPC appears to be already standard there.




>> gradient colour space:
>> Can users specify in which colour space a gradient is created? While mapping
>> to vector output this would mean a desire to switch the actual editing
>> colour space. Or is the cairo_color_space_t specified with
>> +cairo_pattern_create_linear_with_color_space or
>> +cairo_pattern_create_radial_with_color_space the editing space for gradient
>> contruction?
>
> I don't get what you mean by "editing". The color space of a pattern
> is the color space
> in which interpolation between the stops happens (thus also the color
> space of the
> "output" colors). The idea is: stops are converted to the gradient
> color space, then
> they are interpolated.

Wonderful. "editing" was meant as the interpolation colour space.



>> images:
>> just for comleteness; images need a cairo_profile_t assigned.
>
> That is a backend issue, I will add constructors for backends later (plus you
> will probably be able to do that also through create_similar_with_colorspace).

Agreed. It would be around cairo_image_surface_create/_for_data() .


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org