[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 17.02.10, 19:56 +0100 schrieb ecir hana:
> On Wed, Feb 17, 2010 at 6:44 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>>>
>>> Again, the real question is, how do you supply CMYK image to Cairo and
>>
>>
>> The API is not (yet) existent. Perhaps:
>>
>> typedef enum {
>>  CAIRO_COLOR,                        /* no alpha is present */
>>  CAIRO_COLOR_ALPHA_PREMULTIPLIED,
>>  CAIRO_COLOR_ALPHA_NON_PREMULTIPLIED
>> } cairo_channel_layout_e;
>>
>> /* create a ICC profile container */
>> cairo_profile_t * profile = cairo_profile_create(
>>            cairo_profile_e         CAIRO_ICC_PROFILE,
>>            void                  * blob,
>>            size_t                  blob_size );
>>
>> /* Specify arbitrary, well defined colour data to cairo.
>>  * Care is to be taken for the alpha channel.
>>  * Alpha is specified after color.
>>  */
>> cairo_color_t * color = cairo_color_create(
>>            cairo_profile_t       * cmyk_profile,
>>            float                 * native_channels,
>>            cairo_channel_layout_e  CAIRO_COLOR_ALPHA_NON_PREMULTIPLIED );
>>
>> cairo_set_blending_color_space(
>>            cairo_t               * cr,
>>            cairo_profile_t       * well_behaved );
>>
>> /* replace the cairo_set_source_rgb toy API
>>  * cairo_set_source_rgb() can be handled as it would be sRGB with
>>  * implicite colour space assigment.
>>  */
>> cairo_set_source_color(
>>            cairo_t               * cr,
>>            cairo_color_t         * color );
>>
>>
>> All _rgb and _rgba functions need complementing cairo_color_t versions.
>> As well the image input has to accept a assigned cairo_profile_t container
>> and cairo_channel_layout_e enum.
>>
>> The profile and color references can be reused and afterward freed.
>> The above example requires changes to cairo's core:
>> * CMS hooks or linked in CMS
>> * cmyk is only possible with four or multi channel support
>>
>> Adrian had suggested per colour space constructors for rgb, rgba and later
>> for cmyk and cmyka. I would be afraid that the channels count requirements
>> would grow in some years beyond the cmyka contructor and the API would need
>> to grow further.
>> If checking the colour creation can be a runtime thing as in my above
>> example, Cmyk and more channels can be added later on need.
>>
>>> first, show it on the screen and second, export it to PDF with the
>>
>> a) cairo knows how to use a hooked in CMS or uses a internal one - real
>>   color API:
>>   it will convert cairo_color_t to whatever is required or configured for
>>   intermediate blending and after drawing to the required or
>>   configured output backends colour space
>> b) only cairos PDF backend knows - circumvent cairo toy color API:
>>   glueless
>> c) only cairos Xlib backend knows - circumvent cairo toy color API:
>>   convert in advance to some RGB and configure the backend to know about
>>   your delivered colour space
>>
>>> same set of graphic operators?
>>
>> a) - yes, straight forward
>> b) and c) - not really
>>
>>
>> To honour the threads name, spot colour could be made a property of
>> cairo_color_t with according setters and getters? But I do not have much
>> knowledge about that part.
>
> Thanks.
>
> - Do you think it is necessary to allocate each new color? Some
> surfaces are able to contain more than one color space (e.g. PDF) so
> there's need of attaching a profile to "native_channels". If there was
> "cairo_set_working_profile(cairo_profile_t *profile)" instead of
> "cairo_set_blending_color_space()" you could do without allocating
> each new color - all subsequent operations will assume that space.

I would think of working space and blending space as synonym. It is 
changed only if the blending/editing/working space is different from that 
specified in the CMS or say sRGB. So it can be specified but might not be 
specified and all works nevertheless.

> There problem is, what about spaces you don't have profile for, such
> as Pantone duotones.
> 
> - There's also "d)" - just attach the profile as metadata blob without
> understanding it and supply a callback function which will do the
> conversion from space A to space B. Think of it as how lcms 2.0 works

It reads to me like the hooks I noted above.

> - read and understand ICC elsewhere, query a surface for ICC blob,
> create a function with two arguments (source buffer, output buffer).
> Cairo wont care how you created a transformation, just supply one. And
> always embed ICC to PDF. But I don't really like the idea of calling
> some random callback, just a food for thought...
>
> - And then, there is always this big "if" and "how" I asked several
> times already - who will do the conversion? Cairo? lcms? OS? I asked

Cairo definately not alone. lcms or ColorSync or WCS, each qualifies.

> this several times but saw no conclusive answer. Besides, I still
> believe "display and export CMYK in one go" can be done without CMS in
> Cairo.

"display" would be a colour conversion? Then at least the backend should 
know how to convert.

> - Lastly, it might be easier to come up with API for just one spot
> color first, rather than the whole CMYK, this is why I started
> "Subtractive API, part 1".

Agreed there are different entry points. It would be nice if they just 
fit together and remain extentable.

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