Difference between revisions of "SpecIccForCairo"
Jump to navigation
Jump to search
Line 53: | Line 53: | ||
== Open issues == | == Open issues == | ||
=== Should surface profile/color rendering changes be allowed once the surface is being actively used? === | |||
:Why should we allow this ? Is there any use case ? The ones I can see are: render the same surface with two different profiles at the same time (e.g. on a multihead screen with different profiles, but is'nt X already handling that, batch export of the same file in many different colorspaces) | |||
=== How should gradients work in this regime? === | |||
:What is the issue here ? like we have a set_source_icc_color, we can have a set_stop_icc color, isnt'it ? | |||
=== How should '''cairo_color_profile_t'''s be created/loaded?=== | |||
:lcms provides 2 ways, load from a file or from memory. I think cairo should provide the same ways, I dont see an additional one that could bring some benefit here, appart from direct reuse of a lcms handler for applications already using lcms like inkscape but that's not really clean - makes cairo API depend from lcms API. |
Revision as of 16:35, 26 February 2008
Why
In order for inkscape to produce CMYK PDFs and PSs with cairo, Cairo needs to support ICC. This is an intent to propose a Cairo API that would be suitable with inkscape needs.
Profiles
A set of profiles will apply to the whole Cairo surface. Cairo needs to be able to compute a transform from this set. We can get inspiration from the lcms api [1], in particular the cmsCreateMultiprofileTransform (more generic than cmsCreateTransform that handles only a single pair of color profiles).
So a proposal would be:
typedef enum cairo_color_intent { CAIRO_COLOR_INTENT_PERCEPTUAL, CAIRO_COLOR_INTENT_RELATIVE_COLORIMETRIC, CAIRO_COLOR_INTENT_SATURATION, CAIRO_COLOR_INTENT_ABSOLUTE_COLORIMETRIC } cairo_color_intent_t; typedef struct cairo_color_profile cairo_color_profile_t;
void cairo_surface_set_color_profile_srgb(cairo_surface_t *surf); void cairo_surface_set_color_profile(cairo_surface_t *surf, cairo_color_profile_t *profile); cairo_color_profile_t * cairo_surface_get_color_profile(cairo_surface_t *surf); void cairo_surface_add_profile_mapping(cairo_surface_t *surf, cairo_color_profile_t *in, cairo_color_profile_t *out); void cairo_surface_remove_profile_mappings(cairo_surface_t *surf); void cairo_surface_set_color_intent(cairo_surface_t *surf, cairo_color_intent_t intent); cairo_color_intent_t cairo_surface_get_color_intent(cairo_surface_t *surf); void cairo_set_source_icc_color(cairo_t *cr, cairo_color_profile_t *profile, const double *components, int num_components);
Color transformations would be performed when painting from a pattern to a surface, based on the surface's profile, mappings, intent, etc.
Open issues
Should surface profile/color rendering changes be allowed once the surface is being actively used?
- Why should we allow this ? Is there any use case ? The ones I can see are: render the same surface with two different profiles at the same time (e.g. on a multihead screen with different profiles, but is'nt X already handling that, batch export of the same file in many different colorspaces)
How should gradients work in this regime?
- What is the issue here ? like we have a set_source_icc_color, we can have a set_stop_icc color, isnt'it ?
How should cairo_color_profile_ts be created/loaded?
- lcms provides 2 ways, load from a file or from memory. I think cairo should provide the same ways, I dont see an additional one that could bring some benefit here, appart from direct reuse of a lcms handler for applications already using lcms like inkscape but that's not really clean - makes cairo API depend from lcms API.