[cairo] Subtractive API, part 0

[Christoph Lindemann]

Hi,

I have not contributed to cairo yet, but have read this thread with much
interest.
The following might read dumb or silly, as I am not very familiar with
color spaces, CMS and the lot. But I will try to come with my ideas and
questions, at least so that I could understand the problem area better.

--------------------------------------------------------
1) Could not the color profile conversion stuff (CMS) simply be provided
by the surface implementation?
Then the surface knows best how to handle the color profiles. 
-The GDI surface for instance, could use the Windows CMS. 
-The PDF surface, could just embed the profiles into the PDF stream,
then the PDF consumer would do the actual CMS. If it is a printer, the
RIP would be responsible, or the print operator could tweak/change the
profiles in his workflow.
-Other surfaces could do the same.

--------------------------------------------------------
2) Can spot colors and similar be expressed in RGB with attached color
profile?
I was thinking, that you could handle (in the code) all color in cairo
with RGB (or whatever is used right now) and for the color handling be
able to attach a color profile.
So the inner workings and API of cairo would not need to be changed, but
would be backwards compatible.

--------------------------------------------------------
3) You could at some API, so you could add an input color profile, and
select an input profile. After you select a profile, the following
drawing operations would uses that profile:

//Following is used to add an external profile
void cairo_add_color_profile(profileName, profileType, profileData,
ProfileDataLength);

//Following is used to get a profile, by its name. The profile
//would need to be added first with cairo_add_color_profile
//or it could be a "standard" profile name like "sRGB" or
//"CIE 1976 L*a*b*"
cairo_color_profile* cairo_get_color_profile(profileName);

//following is used to specify an intended output profile
//for a surface
void cairo_surface_select_output_intend(cairo_surface_t *surface,
cairo_color_profile* profile);

//Following is used to select a profile to use in following graphics
//commands
void cairo_select_color_profile(cairo_t *cr, cairo_color_profile*
profile);


//some example code:

cairo_color_profile *profileLab;
cairo_color_profile *profileSRGB;
cario_color_profile *profilePrnAcmeXYZ;
cairo_surface_t *surface;
cairo_t *cr;

surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 120, 120);

profileLab = cairo_get_color_profile("CIE 1976 L*a*b*");
profileSRGB = cairo_get_color_profile("sRGB"); //system dependend

cairo_add_color_profile("AcmeXYZ",CAIRO_PROFILE_ICC,pProfileData,
cbProfileData);
profilePrnAcmeXYZ = cairo_get_color_profile("AcmeXYZ");

//set output profile
cairo_surface_select_output_intend(surface, profilePrnAcmeXYZ);

cr = cairo_create(surface);

//fill using sRGB
cairo_select_color_profile(cr, profileSRGB);
cairo_set_source_rgb (cr, 0, 0, 0);
cairo_rectangle (cr, 0.25, 0.25, 0.5, 0.5);
cairo_fill (cr);

//draw using CIE 1976 L*a*b*
cairo_select_color_profile(cr, profileLab);
cairo_set_line_width (cr, 0.1);
cairo_set_source_rgb (cr, 0, 0, 0);
cairo_rectangle (cr, 0.25, 0.25, 0.5, 0.5);
cairo_stroke (cr);


--------------------------------------------------------
4) Also cairo should use an >documented< default profile, which could be
something like an "whatever the surface likes today". So the default
input profile would be the surface output profile. So this could be
AdobeRGB for PDF or whatever fits the surface

--------------------------------------------------------
5) If the surface does not implement any CMS functionality or this
functionality is not desired (performance, or other needs). Cairo could
implement a rudimentary fallback CMS for basic color conversion. This
fallback could be linking to an third-party CMS like littleCMS, or
application provided functionality. This could also be used for
application hooking into the color profile part.
-On an embedded platform, you could then just ignore profiles, and do no
mapping at all. This would probably be ok, as you would have full
control of the device and images used.
-An application for print proofing, could implement it's own CMS, which
could take into account press or printer attributes, like RIP software,
ink types, halftone patterns, paper stock....

--------------------------------------------------------

If implemented as above:

a) Application developers could continue to be color management
ignorant, if they so wish. They would not need to change any code.

b) Color management could evolve in cairo at the speed that fits. Cairo
could start by just implementing the API and a dummy "pass through no
conversion" kind of CMS fallback. Surfaces could implement the profile
handling in order of importance. Application developers that would need
CMS functionality here and now, could just hook into cairo and provide
their own CMS.

c) This would not need any huge API extension

d) This depends on 2)


I hope the above makes sense, else please feel free to comment and rip
it apart

Best regards,
Christoph Lindemann