[cairo] Spot colors (and CMYK)

[ecir hana]

On Wed, Feb 17, 2010 at 8:30 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>
> I do not think Cairo should understand color profiles. This is an ENORMOUS
> complication that will only cause grief. This is why I very strongly reject
> any of Kai-Uwe Behrmann's ideas.

I also think CMS is difficult. Chris Murphy says it's a continuum and
matter of deciding of what to do now and what to do then but I think
there is a difference in saying "attach ICC profile and CMS will take
care of most of the problem" and in actually implementing it. This is
also the reason, why I insist someone answers me, who will do the
color conversion. Because it is rather easy to wave a hand and saying
"OS". Who will maintain the platform specific code? ... If that's CMS
is the only possible way of supporting subtractive color space, then
be it but I'm not yet convinced.

> I am also under the impression that "CMYK" means "exactly these inks on this
> specific device". Printer profiles apparently are defined as "here is how to
> turn this CMYK into a matching point in a 3-dimensional color space".
> Therefore I believe that any portable information derived from a CMYK color
> can be conveyed with a 3-dimensional color api.

Unfortunately, this is a bit different, that's what I was trying to
say above. Obviously, you can't go from 3D to 4D. Or more precisely,
you can, in infinitely many ways. In other words, while CMYK might get
a very similar color in LAB (or scRGB) the opposite is not true
because for scRGB(x, y, z) there are many colors in CMYK. What's worse
sometimes you need CMYK(0, 0, 0, 100) which has some scRGB equivalent.
But defining such color just in scRGB would result in CMYK different
than CMYK(0, 0, 0, 100) causing huge problem for text, for instance,
because anything not equal to solid 100% gets printed as raster which
is just a different name for many small dots and holes.

> Therefore my method to fill a shape with an exact CMYK on an output device
> is:
>
> 1. Specify the color in sRGB. If the application only has CMYK information,
> it is the applications responsibility to figure out how to turn it into
> sRGB. An obvious way is to use the device profile to turn it into XYZ and
> from there into unclamped sRGB.

Ok.

> 2. Also specify using a device specific api that this exact spot color is
> wanted. A backend that understands this will use the spot color other than
> the sRGB. Most backends will ignore this information.

This is also easy, except for image surfaces. Because in that case,
you would need to supply the whole original image along with its scRGB
alternative.

> There cannot be any guarantees about compositing of any transparency or
> antialiased edge, but a 100% opaque area should produce exactly that spot
> color on output. The reason we cannot guarantee anything about transparency
> is that the only predictable result would be to convert the composited sRGB
> to the device inks, but this would result in a discontinuity of antialiased
> edges with the enclosed area. I think users would prefer an antialiased edge
> made of the spot color even if the exact composited result is
> device-dependent.

Ok.

> As spot colors tend to be one channel, I am uncertain how to do a CMYK
> separation image. One way would be to draw 4 monochrome images with
> different spot colors (each of C,M,Y,K are a spot color), with the
> compositing operator set to subtract (or maybe multiply or maybe some new
> operator) which is an indication that ink must accumulate. Since Cairo has
> no information about how the colors mix it will be impossible to produce an
> accurate sRGB equivalent. Alternative is to use an N+3 channel image, with
> the sRGB data included so that back ends that do not understand the spot
> colors can use the sRGB fallback. Or an api that takes two different images
> as input. In any case again anything other than 100% opacity is going to
> produce device-dependent results and no color management is going to fix
> that.

That's exactly my point. Use 7 channel images (3 for scRGB + 4 CMYK)
or use two surfaces, ok. But that means, the application needs to hold
two copies of the same image in memory, whereas if there was proper
CMS involved, it could hold just the original and transform it on the
fly. But I'm hopeful there are more possibilities...