SpecIccForCairo - Revision history

Romain2Boss: Add category Proposals

2012-03-31T10:17:49Z

Add category Proposals

← Older revision		Revision as of 10:17, 31 March 2012
Line 73:		Line 73:

	: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.		: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.

			[[Category:Proposals]]

Aubanel: /* Functional spec */

2008-02-27T13:56:09Z

Functional spec

← Older revision		Revision as of 13:56, 27 February 2008
Line 52:		Line 52:

	== Functional spec ==		== Functional spec ==
	~~To render a surface, cairo~~ has several ways to accept color information (e.g. cairo_set_source_rgb).		Cairo has several ways to accept color information (e.g. cairo_set_source_rgb). The cairo back-end produces an output (a file or calls to third party libraries). The colors of this output are only back-end and cairo dependent, and there is no way for the cairo user to specify something different.

			A color management system provides a way to specify input and output color formats (bit orders, meaning of the channels, etc) as well as a way to transform input colors to output ones.

			Cairo needs a ways to permit cairo users to input this information (basically, those would be stored alongside the surface).

			As the format for inputing colors is variable, a color is defined as an array of doubles (size to be specified at each time, each double is a channel). Cairo stores these informations internally.

			At render time, the backend computes the color transformation (typically a call to cmsCreateTransform ) and applies it to every color. Back-end will also use the color output format as a clue to the desired output (e.g. the pdf backend with color output format TYPE_CMYK_8 will generate a CMYK pdf). Each cairo backend will be able to render only some of the output color formats (e.g. X backend does not know how to render CMYK, but would know ho to render RGBA 32, RGB 24). Trying to render to an unsupported color format would trigger an error.

	== Open issues ==		== Open issues ==

Aubanel at 13:35, 27 February 2008

2008-02-27T13:35:44Z

← Older revision		Revision as of 13:35, 27 February 2008
Line 50:		Line 50:
	Color transformations would be performed when painting from a pattern		Color transformations would be performed when painting from a pattern
	to a surface, based on the surface's profile, mappings, intent, etc.		to a surface, based on the surface's profile, mappings, intent, etc.

			== Functional spec ==
			To render a surface, cairo has several ways to accept color information (e.g. cairo_set_source_rgb).

	== Open issues ==		== Open issues ==

Aubanel: /* Open issues */

2008-02-26T16:35:31Z

Open issues

← Older revision		Revision as of 16:35, 26 February 2008
Line 53:		Line 53:
	== Open issues ==		== Open issues ==

	* Should surface profile/color rendering changes be allowed once the surface is being actively used?		=== Should surface profile/color rendering changes be allowed once the surface is being actively used? ===
	* How should gradients work in this regime?
	* How should '''cairo_color_profile_t'''s be created/loaded?		: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.

Mental: /* Profiles */

2008-02-23T19:18:21Z

Profiles

← Older revision		Revision as of 19:18, 23 February 2008
Line 43:		Line 43:

	void		void
	cairo_set_source_icc_color(cairo_color_profile_t *profile,		cairo_set_source_icc_color(cairo_t *cr,
			cairo_color_profile_t *profile,
	const double *components,		const double *components,
	int num_components);		int num_components);

Mental: /* Profiles */

2008-02-23T19:17:33Z

Profiles

← Older revision		Revision as of 19:17, 23 February 2008
Line 46:		Line 46:
	const double *components,		const double *components,
	int num_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 ==		== Open issues ==

Mental: /* Open issues */

2008-02-23T19:15:42Z

Open issues

← Older revision		Revision as of 19:15, 23 February 2008
Line 51:		Line 51:
	* Should surface profile/color rendering changes be allowed once the surface is being actively used?		* Should surface profile/color rendering changes be allowed once the surface is being actively used?
	* How should gradients work in this regime?		* How should gradients work in this regime?
	* How should ~~cairo_color_profile_ts~~ be created/loaded?		* How should '''cairo_color_profile_t'''s be created/loaded?

Mental: /* Profiles */

2008-02-23T19:15:18Z

Profiles

← Older revision		Revision as of 19:15, 23 February 2008
Line 17:		Line 17:

	typedef struct cairo_color_profile cairo_color_profile_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_srgb(cairo_surface_t *surf);~~

	void		void
	cairo_surface_set_color_profile(cairo_surface_t *surf,		cairo_surface_set_color_profile(cairo_surface_t *surf,

Mental: /* Profiles */

2008-02-23T19:15:02Z

Profiles

← Older revision		Revision as of 19:15, 23 February 2008
Line 18:		Line 18:
	typedef struct cairo_color_profile cairo_color_profile_t;		typedef struct cairo_color_profile cairo_color_profile_t;

			void cairo_surface_set_color_profile_srgb(cairo_surface_t *surf);

	void		void
	cairo_surface_set_color_profile(cairo_surface_t *surf,		cairo_surface_set_color_profile(cairo_surface_t *surf,

Mental: /* Open issues */

2008-02-23T19:14:15Z

Open issues

← Older revision		Revision as of 19:14, 23 February 2008
Line 49:		Line 49:
	* Should surface profile/color rendering changes be allowed once the surface is being actively used?		* Should surface profile/color rendering changes be allowed once the surface is being actively used?
	* How should gradients work in this regime?		* How should gradients work in this regime?
			* How should cairo_color_profile_ts be created/loaded?