[cairo] Spot colors (and CMYK)

[Kai-Uwe Behrmann]

Am 13.02.10, 05:29 +0100 schrieb ecir hana:
> Hello,
> just a quick one: what do you think should happen when you have one
> surface in duotone (or CMYK or any other non-3D space, as Bill Spitzak
> calls them) and you want to paint it over (copy, multiply) 3D color
> space? In other words, what do you think, who should do the conversion
> - Cairo or the application? But perhaps you, or someone else, see
> another possibility?


I guess the input would be all sRGB. But for integer output the colour 
space should be selectable. Otherwise the sRGB input API would remain a 
bottleneck for saturated colours.
E.g. a poster could be layed out for printing including some very 
saturated colours, it would be wrong to clamp to integer sRGB. Instead the 
user should be able to decide which colour space s/he wants to render to. 
This could be ECI-RGBv2, ProPhoto-RGB ...
Performance wise the required floating point input image format is 
debatable. A simple attaching of a ICC profile to smaller integer buffers 
with 8 or 16-bit per channel is memory wise much more efficient I guess.


Further I wold like to add two possibilities for colour managed input 
other than with static sRGB primaries:
a) switch cairos input colour space on request,
allowing to render in that colour space. Backends should support output to 
a additional colour space (PNG, image and PDF surfaces). The display 
surfaces need additional code to convert to the destination device on the 
fly. But that later to monitor conversion can be almost automatic. Colour 
conversions would be kept out of cairos core as blending is done in one 
colour space from one homogenous source colour space.
Applications would need extra code to convert to the decided colour space.
Cairo needs some means to fail in case the contexts input colour space is 
switched during drawing, e.g. return an error while setting the input 
colour space after the first drawing operation.

b) cairo allows for tagging individual graphic elements with ICC profiles
This includes cairos responsibility to convert them to a blending space 
for a flat representation like monitor or PNG. The advantage would be that 
for PDF the graphic elements can be placed with the same numbers, just 
get tagged with the individual ICC profile.


DeviceN could be supported in cairo by converting that DeviceN input for 
backends, which are not capable of blending more than 3 colour channels. 
This would fit to model b). Or applications could use DeviceN only with 
certain backends by allowing them to query the backends capabilities: 
model a). The need to communicate with backends directly for switching 
code during drawing will weaken cairos one input multiple output feature.


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