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

[Kai-Uwe Behrmann]

Thanks for the proposal. I hope my comments map obvious to your diff.



Blending space:
A intentional once selected then fixed blending colour space makes sense 
to me. The interpretation of output from cairo as well as some internal 
details will be easier. Most apps would take the easy route and avoid 
pitfalls. Its a good barrier.
Users wanting several blending colour spaces would have to do that on 
their own. Beside this overall statement I am not shure how it would be 
possible to construct vector output with changing blending spaces by 
combining cairo output. For flat data that would be trivial.
That said I can well imagine situations where parts of a document is 
rendered in one space, while other elements in an other, e.g. by combining 
documents.
If the API allowes by some not too difficult means to produce mixed 
blending space documents (PDF, SVG?) I think that would be fine.
+cairo_surface_create_similar_with_color_space() ?



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);

The state of rendering intent and so on can be preserved for 
subsequent usage:
cairo_public cairo_color_t *
cairo_color_copy (cairo_color_t *color);
cairo_public void
cairo_color_set_components (cairo_color_t *color,
                            double *components);

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.



rgb(a) equivalents:
+cairo_color_create_rgba( .. )
+cairo_color_create_rgb( .. )
Can this simply be skipped? As I understand the cairo_set_source_rgb/a() 
API would cover these cases already and assign a assumed Rgb 
automatically. A special API for assumed Rgb would be helpful.



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?



images:
just for comleteness; images need a cairo_profile_t assigned.



Ok, enough.

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


Am 22.02.10, 02:29 +0100 schrieb Andrea Canciani:
> but I should thank Adrian Johnson as these changes are heavily based
> on his colorspace branch, on some conversations I had with him,
> Benjamin Otte and Joonas Pihlaja on irc and on the quartz API, which
> seems to do an awesome job about color management.