[cairo] [RFC] Color space API (partial proposal)
ku.b at gmx.de
Mon Feb 22 02:10:31 PST 2010
Thanks for the proposal. I hope my comments map obvious to your diff.
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
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_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_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_color_set_render_intent (cairo_color_t *color,
The state of rendering intent and so on can be preserved for
cairo_public cairo_color_t *
cairo_color_copy (cairo_color_t *color);
cairo_color_set_components (cairo_color_t *color,
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.
+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_radial_with_color_space the editing space for
just for comleteness; images need a cairo_profile_t assigned.
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.
More information about the cairo