[cairo] Spot colors (and CMYK)

[Chris Murphy]

Sat Jan 16 16:30:42 PST 2010 ecir hana ecir.hana at gmail.com wrote:

> On every device which does not have the desired colorant you would
> want to simulate it by mixing some of the available colorants. You can
> either try to build a clever conversion process build around ICC,
> materials, dyes, coatings which would simulate the missing spot color
> automatically - in this case the conversion would be transparent to
> the user, i.e. implicit. Or you could leave that to the user to
> manually specify what colors to use in case of falling back, i.e. a
> user explicitly defines the "tintTransform".

At least in the case of PDF, applications which support the creation of content using spot colors include alternate values for this reason. The alternates for Pantone colors are CMYK based, for a regional printing condition (i.e. the CMYK alternate values for Pantone 180 are not the same in the U.S. as they are in Europe, for example); and the alternates for web publishing apps that support Pantone colors are RGB based (almost invariably these are sRGB).

In both cases, the application must convert CMYK to display RGB in order to display spot colors, and to inkjet RGB in order to print them to essentially all desktop inkjet printers.

Without color management, you will either be able to print spot colors to CMYK printers but not display them, or display them but not print them to CMYK printers. So the either CMYK or RGB, and no color management approach doesn't appear to be workable.

On both Mac OS and Windows, there is a default CMYK and default RGB in place, so PDFs containing spot colors (which contain either CMYK or RGB alternate values for those spot colors), can be both printed and displayed reasonably OK.

Arguably a better solution is to define such colors with LAB alternates, further reducing any ambiguity.


> By saying "using just RGB wont work" I just meant to give a nod
> approval to the post above by Francois Robert, where he says "In
> theory, color management should make it possible to use full RGB or
> even L*a*b* workflows in the printing industry and not care about the
> inks details. In practice, however, this is still not very common and
> many shops are still using CMYK". In other words, I heard a few times
> that all you need is sRGB and some ICC profiles and everything else
> will be taken care of by.....? I mean, even CMYK alone has incredible
> potential.

This is due largely to mechanical realities of printing presses, rather than a color management problem or limitation. If  printing presses had perfect register, for example, we could have an entirely RGB workflow, convert to CMYK on-the-fly at print time. This is exactly how inkjet printing works on all operating systems, some conversion is occurring either by the operating system, or the print driver - there is rarely any correlation between the original values in the document and the numeric values used by the printer to reproduce the document.

Printing companies operating actual lithographic printing presses (or gravure or flexographic presses) do have predominately CMYK only (plus optional spot) workflows. There are some practical reasons why this is the case, but most are legacy reasons.




> Quite the opposide - if you explicitly specify a mapping of how 0% -
> 100% "gold" translates to CMYK values, there would be no need of CMS.
> 
> An example of how to define such mapping:
> 
> http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf
> 
> 3.9.1 Type 0 (Sampled) Functions, p. 169
> 

While you can do this, it guarantees it will be interpreted differently down the road no matter where it goes. CMYK values do not define colors, it is merely a recipe. What you get depends on the ingredients. We've been down this particular road before and what it translates into is a PDF that displays and prints differently on every platform and application because assumptions must be made about those CMYK values.

I'd suggest avoiding making assumptions. There's really no need.



On Sat, Jan 16, 2010 at 11:01 PM, Carl Worth <cworth at cworth.org> wrote:
>>  It's clear to me that starting with a named spot color (or N named spot
>>  colors as in DeviceN) that cairo will need *some* information about how
>>  to render that color for "preview" purposes on devices without the
>>  desired spot colorant. Since this preview color need not be particularly
>>  precise, (by definition it cannot accurately capture the presentation of
>>  the final device), why couldn't this fallback be specified as RGB?

> Exactly. This is an interesting question. My reasoning was that since
> you use spot colors you probably intent to print on subtractive
> device. If that device does not have "gold" it still most probably has
> CMYK.  If you specified RGB fallback you would then also need to
> convert this RGB to CMYK.

It's probably RGB.

Exhibit A: Displays. All content with spot colors will first appear on a display, and it would be nice if the display shows us something that correlates to the spot color. With the advent of wide gamut displays, they can do a pretty good job (better than CMYK equivalents by far, which will force most spot colors to render much less accurately than the actual spot color).

Exhibit B: Most inkjet printers and many laser printers, have an RGB imaging pipeline. Presently the gutenprint drivers for various inkjet printers appear to support both RGB and CMYK pipelines, but on the openicc list recently it was suggested that inkjet printer manufacturers are moving to an entirely RGB  print pipeline, probably sRGB based by default (and maybe it would support another color space for wider gamut printing). Of course the professional printers would continue to support CMYK (more correctly deviceN).

Although this list doesn't deal with Windows or Mac OS, I'll point out on those platforms, all inkjet printers driven by manufacturer drivers are considered RGB devices because the driver itself only receives RGB data. Internally the driver converts to deviceN. The suggestion is that future inkjet printers themselves may do this conversion internally rather than the print driver. This would mean the only way to get data to them would be RGB.

Point being, it's not a good assumption to make that CMYK alternates is the way to go. You'd still have to do conversions from CMYK to RGB for RGB devices, including display, if you specify CMYK fallback (alternates).


>  Another way of looking at this is, for spot
> colors, favoring print intent over screen display. Of course, most
> precise way of doing this would be to specify RGB fallback for screen
> and CMYK fallback for print but I thought that might be an overkill
> for the user.
> 
> To convert from CMYK to RGB I thought one could use the formula from
> the above spec, 6.2.4 Conversion from DeviceCMYK to DeviceRGB, p. 484:
>   red = 1.0 - min(1.0, cyan + black)
> green = 1.0 - min(1.0, magenta + black)
>  blue = 1.0 - min(1.0, yellow + black)

This is a hideously bad idea. If the spot color is defined as CMYK, that's already a major departure from the original color, which is now lost since its encoded as CMYK. By completely ignoring the source CMYK space using a simple inversion formula to get to RGB, you're departing from already departed CMYK values.

The world has already done this in professional publishing applications many years ago, and it diplomatically looked like crap and confused the hell out of graphic designers and printers. It was so confusing, we're still dealing with the aftermath in the industry of this major lie that CMYK values have any correlation to a color, and that it's possible to realistically define Pantone colors with CMYK values. Yet designers persist in asking for this fabrication of reality.

Why repeat this old history? Just because it's easy? Forget it. It's not useful. You might as well just print solid black, or a hatchmark pattern for all spot colors on both display and print if you just want easy.

Use Lab or XYZ for the alternate. You've got a conversion no matter what color model you choose, you might as well choose something that doesn't totally obliterate the original intent with the very first and second step to get it to display on-screen (let alone printed).



Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"