[cairo] colour management

[Kai-Uwe Behrmann]

Am 05.03.08, 14:38 -0800 schrieb Carl Worth:
> On Wed, 5 Mar 2008 20:28:11 +0100, "Aubanel MONNIER" wrote:
> > Just to let you know you cairo developers that I setup an inkscape "Blue
> > print" about color management.
> > https://blueprints.launchpad.net/inkscape/+spec/icc-for-cairo
> > It tries to precise use cases and proposes a draft API for cairo. I hope it
> > helps to get this supported quicker.
> > It's a wiki, so feel free to discuss/edit.
> 
> Hello there!
> 
> Thanks so much for sharing this with us.
> 
> I'd definitely love to see cairo pick up the necessary functionality
> so that it can generate PDF suitable for pre-press needs.
> 
> You mentioned elsewhere in this thread that you would expect to see
> cairo grow a dependence on littleCMS. Personally, that sounds like
> exactly the right thing to me. Color management should be a problem
> that is handled well by a separate tool rather than something that
> cairo should try to grow and take over on its own.
> 
> As for platforms that have "native" color management systems, can
> littleCMS sit on top of them already or be made to do so?

littleCMS is a independent colour mathing module (CMM). It is in no way a 
colour management system (CMS). The different is a CMS has to take over 
user preferences (intents, profiles, ...), device configuration a CMM 
framework and provide policies how colour managed applications and pices 
shall interact.

Lcms can not easily be exchanged with a operating system style CMS. Lcms 
is lower level. For instance lcms can not call in ColorSync or ICM.
 
> So the first thing I'm surprised by is that the API proposal so far
> isn't using littleCMS types in the interfaces. Shouldn't things like a
> color profile just be created with existing littleCMS APIs and then
> passed to cairo?
> 
> Oh, and if I haven't made it perfectly clear already, I'm a total
> idiot when it comes to color. In the API proposal so far I see three
> separate notions being proposed to cairo:
> 
> 	color intent

Rendering intents are defined by the ICC (www.color.org) to define colour 
matching between different colour spaces. The problem here is that 
different colour spaces as described in ICC profile maintain different 
sized and formed gamuts. To move a Cmyk cyan colour to something visible 
of your monitors Rgb several strategies are possible particial defined by 
the redenring ICC intents.

> 	color profile

A ICC colour profile colourimetricaly characterises of a colour space.

> 	color profile mapping

Hmm, there are many terms around this. Lcms (littleCMS) uses colour 
transforms, the ICC device link. Mapping can easly easily be confused with 
gamut mapping, which is a term for itself, or tonemapping (used for HDRs).

> And is "color intent" fundamentally separate from "color profile"?

Yes see above.

> That is, is there a reason we couldn't simplify this API down to one
> new concept being added to cairo (a color profile) and then preferably
> just use a littleCMS datatype to express it?

The following would help in characterising the input:
(pseudo user level code):

  cms_profile_t profile = 0
  profile = cms_create_profile_from file( "filename" )
  cairo_image_attach_cms_profile( cairo_image, profile )

optionally, otherwise use CMS defaults:
  cms_options_t options = 0
  cairo_image_attach_cms_options( cairo_image, options )

Then you'd need a concept how to characterise the according output per 
backend (Rgb->Rgb, Rgb->Cmyk, Cmyk->Cmyk, Cmyk->Rgb, Rgb->YUV ...)
The above are a variety of possibilities. They should be generically 
covered by the above and below user side pseudo code.

  cairo_backend_select( "pdf" )
  cairo_backend_colour_space_set( profile, options )

Then Cairo should be able to link the image profile to the backend profile 
using eigther the image or the backend options or fall back to the CMS 
defaults. 

If only one of the image or backend colour space is set, Cairo can simply 
select a default Rgb for the non set side. 

Without any profile, it would be unclear what to do and no colour 
conversion should happen. This is how it is today. So the default Cairo 
behavour remains backward compatibility.


As this is possibly too much of specifics at once, you might read at 
Wikipedia "colour management", "icc_profile", "gamut" and so on.

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