[cairo] [RFC] Color space API (partial proposal)

[Kai-Uwe Behrmann]

Am 22.02.10, 18:32 +0100 schrieb Andrea Canciani:
> On Mon, Feb 22, 2010 at 3:35 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Am 22.02.10, 12:28 +0100 schrieb Andrea Canciani:
>>>
>>> On Mon, Feb 22, 2010 at 11:10 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>>
>>>> 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_public void
>>>> +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_public void
>>>> cairo_color_set_render_intent (cairo_color_t         *color,
>>>>                               cairo_render_intent_t  render_intent);
>>>
>>> Since rendering intent is actually used only when a color space
>>> conversion is done,
>>> basically we can choose whether select a rendering intent for all the
>>> sources
>>> we are going to use (colors, patterns) or for all the destinations
>>> (cairo_t, gradients (they
>>> convert color stops to the pattern color space)).
>>
>> I think now its a "and" and not a "or". On entrance of the blending space a
>> conversion has to take place with all options. And on converting to the
>> output colour space the same again, but possibly with different options.
>
> It was an "or" (exclusive or, actually). Now I'm sure rendering intent
> should only
> be specified for destinations as (from pdf reference" 11.7.5.3 Rendering Intent
> and Colour Conversions"):
> ...
> The rendering intent influences the conversion from a CIE-based colour
> space to a target colour space, taking
> into account the target space’s colour gamut (the range of colours it
> can reproduce). Whereas in the opaque
> imaging model the target space shall always be the native colour space
> of the output device, in the transparent
> model it may instead be the group colour space of a transparency group
> into which an object is being painted.
> The rendering intent is needed at the moment such a conversion is
> performed—that is, when painting an
> elementary or group object specified in a CIE-based colour space into
> a parent group having a different colour
> space.

Having the blending colour space equal to the output one might be correct 
in a PDF context. That terminology of PDF does not match to Cairos 
situation.

As soon as a cairo user wants to render on screen a conversion has to take 
place from blending colour space, or in PDF terminology from intented 
output, to monitor space:

input:             blending:    output:
Rgb(ScannerRgb) -> Cmyk(Web) -> Cmyk(Web, preceptual for CameraRgb)
Rgb(ScannerRgb) -> Cmyk(Web) -> Rgb(monitor, relative colorimetric for
                                     simulation)

If one opens a image in a graphics app and converts from some mystic 
scanner Rgb to the prefered editing/blending colour space, then this is a 
conversion from input. The output might be some printer. This separation 
will be a output colour conversion. Most graphic applications allow to 
handle both cases with different options.

What you suggest is not yet clear to me. To which colour conversion shall 
your specified options be applied? Input or output or both?

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