[Openicc] Creating CMYK and spot colors using Postscript backend

[Graeme Gill]

Craig Ringer wrote:

> 	- Gradients & blends? How do you work with a CMYK -> RGB
> 	  gradient or a layer blend?

This issue has been tackled by others - see the PDF specification
from Adobe for example (section 6, and 7.6 of the V1.7 reference).
Basically the colorspaces used for the blend have to be defined somewhere.

> 	  mixing CMYK and RGB colours. There *IS* no sane RGB<->CMYK
> 	  conversion without some knowledge of the source and target
> 	  devices; the best you can do is assume sRGB and SWOP Coated or
> 	  something like that. That won't get you great results.

A system that is serious about handling color that can be defined
in more than one colorspace will have to have a color profile aware
architecture to facilitate conversion between the colorspaces. See
PostScript, PDF or XPS for examples.

> You could simplify this by converting to a single internal working
> colour space, like L*A*B (white-point corrected XYZ). That's expensive
> for rgb->rgb though, and that's currently the only use Cairo sees.
> 
> Carl Worth mentioned that the Cairo devs are already considering using a
> wide-gamut RGB  space as the sole internal colour representation. My
> understanding is that doing so isn't really any different from
> converting to L*A*B, except that you save in the wide-RBB -> wide-RGB
> case that's the most common use.

Microsoft has gone for a wide gamut RGB space for XPS that is very similar
to a non-gamma sRGB space - scRGB, which is standard IEC 61966-2-2. It has
the same RGB primaries as sRGB, but allows for an extended device value range
of -0.5 to 7.5, covering all visible colors and some degree of high dynamic
range usage using 16 bits per component. In this way there is not much to converting
sRGB to scRGB, and conversion back can be as crude as component wise clipping.

Being a linear light space, scRGB is ideal for anti-aliasing, and (perhaps)
some sorts of blending.

> Another alternative, though, is to preserve colours as far as possible
> through Cairo, and only convert them when an operation or surface cannot
> handle that colour format. This would be ideal in many ways, as it'd
> simplify the handling of spot colours (see below), permit CMYK values to
> be preserved exactly as-is where no conversion is required (again, see
> below), and make it possible to create mixed colour space documents in
> media like PDF/X-3 that support it.

An issue with CMYK is that CMYK->Lab/RGB->CMYK loses information,
that of the black separation. For some purposes this is an unacceptable
loss, for others (where the CMYK is merely defining a color) this may
be acceptable. Certainly conversions to/from real device spaces loose
accuracy and smoothness with each conversion as well. It comes down a bit to
whether cairo is an editing environment or simply a rendering environment.
With the former you need to worry about preserving the original colorspaces
as far as possible, while with the latter they are all just colors, and
could probably be converted to a common format, as long as some of the
intent information is retained.

> Now one more wrinkle pops up: spot colours. (OpenICC folks: yell at me
> if any of this isn't 100% accurate in nitpicking detail please). Spot
> colours are NOT just named CMYK values. A spot colour is a specific
> colour *in* *the* *real* *world*. Your named colour is a placeholder for
> that, and the output device is responsible for reproducing the desired
> colour. This "colour" need not even be a conventional colour - it could
> be gold ink, or a varnish layer. An intensity value makes sense for a
> spot colour in most outputs (corresponding to things like halftoning),
> but blending it with other colours generally does not.

It's pretty useful to have a definition of a spot color (assuming it's not
something exotic like gold/silver etc.) defined in a device independent
fashion (spectral reflectance or L*a*b* for instance). Generally it
will be rendered with a different intent from other colors (absolute
colorimetric), since a side by side match is desired. Blending with
other colors is often encountered in the real world, the expectation generally
being that of whatever happens on a halftone printing press.

> A gradient of a spot colour to, say CMYK(0,50,0,20) doesn't make sense.
> You might say "that spot colour is printed using the CMYK value
> (0,10,0,10) on this device" ...

That's typically a poor imitation of the actual spot color, which
is not often reproducible using process colors.

 > but Cairo won't and *CAN'T* know that.
> In fact, spot colours may be printed as separate press plates using
> specific inks otherwise outside the gamut of the device (think bright
> green on an offset web press) or might even not be conventional colours
> at all.

It comes down to what you are intending to use Cairo for. Is it meant
to be capable of doing the sort of rendering expected of PostScript or
PDF so that multi-plate printing press jobs can be proofed on some
other output device, or is this outside its scope ? It's possible
to handle all this sort of thing by looking up spot colors in a spot
color dictionary, and then handling the resulting device independent
color in the rendering system.

> It's important not to think of spot colours as confined to plate-based
> offset printing. They're also useful and meaningful in digital press
> situations or with any other target that has been calibrated for a
> common spot colour library like PANTONE, and can guarantee that
> PANTONE#553 will really come out just like it looks in the swatch book
> in your hand.

Yes, it's a way of signalling intent, and also of defining a color
that may be outside the gamut of interchange RGB or CMYK spaces, and
should be reproduced as close as possible to the ideal using the
actual output device space.

> If you plan to store and work with colours in different formats/spaces,
> such colours also need to have provision for a colour profile tag as
> part of the colour structure. It'd also be necessary to ensure that the
> rgb for display use was only EVER used for display, not used as a
> convenient pre-converted RGB value for blend operations etc.

You should think about an intent tag as well as profile tag.

> I personally don't think Cairo should have to care about this, as I view
> it as a bit of a relic from before ICC colour management was around. A
> decent profile and software that uses it properly should produce a good
> result when converting such CMYK data from its source colour space to
> the working space and back again for output. However, I'm not an expert,
> and my view is not the only one around.

In terms of color, yes. In printing press land though, there is a need
to more accurately control K. A very simple example, if you're printing
black text you probably want to use K only, to minimize ink usage and
to eliminate issues with plate registration. If you're printing a photograph,
you probably want a composite (CMYK) black to give a better contrast ratio
and image depth. How do you signal this in your rendering architecture ?
You at least need a black tag bit (which is equivalent to an intent bit).
XPS tackles this to some degree. I don't think PDF or PostScript do, apart
from simply allowing specification of such colors in CMYK.

A thorough examination of the PDF and XPS specifications could save
a lot of "reinvention the hard way" when it comes to color handling for
a rendering system.

Graeme Gill.