[cairo] Subtractive API, part 0

[Chris Murphy]

On Jan 28, 2010, at 6:30 PM, ecir hana wrote:
> 
> 
>> ignoring the color meaning of CMYK values is just not useful
> 
> I don't agree. In practise, sometimes it happens that you just know
> nothing about the CMYK values, sometimes it happens that you know all
> about the CMYK values. Sometimes, you get some design manual stating
> just some values for a logotype and all you could possible do is to
> type those values in. Or sometimes you get a picture not tagged with a
> profile and all you can do is to let it print out. On the other hand,
> sometimes, you know precisely well what you are about going to do, you
> know the paper and you want rich black. 40% 30% 30% 100% rich black.

CMYK is completely useless on everything except for the CMYK output device those values were intended for. You can't even display them, absent some kind of assumption of what they mean.

And worse, you will be creating files that contain undefined CMYK values. This has been done and has caused so many problems in the world of printing, now is not the time to bring back relics of the past, now that we have vastly superior ways of handling such things. How do you expect these files to be shared? What happens when a company changes printers and has to unf8ck up all their digital files? Because that's what these proposed files are, they're completely munged. They do not actually communicate a repurposeable intent.

> 
>> I am hopeful that there will be a day when people understand that "half magenta" is not a color.
> 
> Interesting. Do you believe there is "full magenta"?

No.

When referring to "magenta" in a printing context, this is a color that runs from light pink to red in hue, low chroma (high gray component possibly due to media) to high chrome, and variable lightness as well. Magenta is not a color. It's a huge range of colors.

CMYK values are control signals. They do not represent a color at all, absent some reference to a CIE space.


> 
> Perhaps the confusing part of this thread is CMYK. Because it might be
> tempting to want to see it on the screen, therefore converting it to
> other color space and even more tempting is to do it right, i.e. via
> color management. But that was not my intention - the only thing this
> proposal is about is the ability to define multiple spot colors in
> Cairo. Therefore, if I may kindly ask you to stop thinking "CMYK" for
> a while a to think "spot color" instead.

Same problem, except worse. A spot color in printing context is a control signal. It's not a color. To display it, or print it where that spot color is unavailable, requires reference to a CIE space as well. However, we tend to specify the spot color CIE value in relation to a reference medium, not actual printing medium. The effect of how it will print isn't known until it's on that media.

If you start working with tints of this spot color, it gets even more complex.

If you start interacting this spot color with other spot colors, it's even more complex still, because you have all kinds of opacity problems that need to be considered (and ink opacity is rarely a published value, you have to measure it), and print sequence makes a huge difference as well.


> If you were reading the "DeviceN" part at the very top, did it make
> sense to you?

I don't understand the question.

> Do you think it is ok to define one empty DeviceN and to
> subsequently add named colors to it, perhaps some with multiple
> fallbacks? Do you think it covers the usual situations? What is
> missing for your use case? If you were in need to define a spot color
> standing for matte varnish would the above functions be convenient for
> you to use?

Insofar as I'm aware, there's only one product on the market that handles spot colors correctly in all their complexity: the color of the spot ink, the color of the media, the effect of the media color on the spot color, ink behavior on the media in terms of dot gain, ink opacity behavior in relation to other inks, print sequence, ink trapping, etc. All play major roles in the color you'll actually end up with.

Adobe InDesign optionally will use Lab values for spots, and thus show them correctly on-screen at 100% when printed on media white only. When you start to print tints, or interact the inks, all bets are off. Neither Adobe nor Pantone supply ink opacity, and even if it were supplied there isn't an algorithm to effectively use this to improve on-screen display or printed simulations. So the net result of this is that you have to outsource these kinds of proofs, and typically you get overlays, and spend a lot of money on experienced prepress handling in order to get things to print correctly.

If we're talking about deviceN on inkjet printers with an arbitrary inkset, many of these issues still apply, but at least we don't have trapping considerations on top of it.


> I still struggle with how to take the pixel values of
> single-channel image and print a golden color as if they were its tint
> values - perhaps there is a need for function which loads data stream
> coupling it to a certain DeviceN? Something like:
> 
> cairo_image_surface_create_for_data_devicen(*data, format, devicen,
> width, height, stride)
> 
> Finally, I certainly don't want to talk about CMS (at least not for
> now) but if in the above was one additional function, say:
> 
> cairo_devicen_add_spot_color_srgb_icc(*devicen, *name, red, green,
> blue, profile, table)
> 
> would you consider it useful? I mean, is the above extensible in your
> opinion? What exactly would you need to put in "profile" and "table"?


I don't really follow the above. But if you're talking about spot colors such as Pantone solids, you might like to look at a gamut plot showing how much of those colors are outside of sRGB.


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