[Openicc] Creating CMYK and spot colors using Postscript backend

[Craig Ringer]

Graeme Gill wrote:
> 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.

Yep, that was what I was getting at - that without knowing the colour
spaces for the colours (such as by having associated ICC profile data),
operations that combine them are meaningless.

>> 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.

Thanks, that's good to know if they do go for that approach. I'm
increasingly hoping it'll be viable to preserve colours as far through
the rendering process as possible, though, and convert to the target
colour space if any conversion is necessary.

>> 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.

Purely rendering. It may be used by an editing environment to produce
its output, but the editing environment in this case would maintain its
own state rather than working on a model maintained by Cairo.

For example, if Scribus was to use Cairo more directly (currently it
uses cairo only for rendering the GUI canvas by drawing to offscreen
pixmaps then blitting them), it'd maintain its own state and use Cairo
to draw that state to the canvas.

Other output backends, such as PS & PDF, are also supported by Cairo.

> 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.

I suspect which approach is best depends on which Cairo backend you're
rendering to. Some backends target formats like PS and PDF that support
multiple colour formats and ICC based colour natively. It'd be ideal to
retain that information for those formats. However, Cairo also targets
pixel-oriented output formats, and for those converting everything to a
common space immediately seems most sensible.

In other words, I now think that it should try to retain colour
information at least until it reaches the backend, which would make its
own decision as to the most appropriate course.

>> 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.

Very good point, and something I'd missed. It seems it'd be desirable to
be able to indicate to cairo whether the alternative colour is a
realistic representation of the spot or whether it's purely a placeholder.

Thanks for bringing up the issue of differing rendering intents, too. I
agree that some sort of tagging of colours for rendering intent will be
important, especially for spots where the alternative representation
might be substituted.

> 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 ?

At this point I don't think anybody is expecting proof quality output,
but leaving room for the possibility would be ideal, since a
tiff-separation backend or something like that would indeed be useful
for some users.

At this point, my hope is that Cairo will reach the point where it can:

	- Produce accurate and high quality PS and PDF documents
	  that will handle colour issues correcty; and

	- Produce good quality bitmap previews of how those documents
	  should render for on-screen display or output to an
	  image file.

However, with spot colours in particular I'd expect Cairo to treat their
output to targets other than PS or PDF as purely for preview purposes,
rather than accurate proofing.

For one thing, there are potential legal problems surrounding access to
tables for widely recognised spot colour libraries like PANTONE, and
some of those colours can't really be usefully represented in commonly
used output colour spaces anyway. So long as they can be output as
correct named colours in PS/PDF, and the alternative representation used
for other targets, I'd think that would be fine.

> 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.

Interesting point. It sounds like potentially Cairo could in fact handle
accurate spot colour conversions into the target colour space, if it had
device independent representations of those spots available.

While I doubt Cairo could ship such tables, applications could provide
them, or could flag the alternative colour associated with a spot as
being such an accurate device-independent representation of the spot
rather than just a preview.

>> 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.

Thanks very much for that suggestion, I suspect it'll turn out to be
quite important.

>> 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.

That makes sense, and puts more weight behind retaining colours in their
original (tagged, mixed-space) forms as far through Cairo as possible,
so backends can make the best decisions about what to do with them.

> 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.

Indeed - that's something I'm going to have to get into.

Thanks for taking the time to make those very useful comments.

--
Craig Ringer