[cairo] Spot colors (and CMYK)
ku.b at gmx.de
Mon Feb 15 23:49:09 PST 2010
Am 13.02.10, 05:29 +0100 schrieb ecir hana:
> 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.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the cairo