[cairo] Spot colors (and CMYK)

[ecir hana]

Bill Spitzak, Kai-Uwe Behrmann, and all the others,

I'm very sorry, I'm stupid I don't understand what you just said.
Could you explain to me a few things?

I have a CMYK SWOP picture and want to check it on screen and export to PDF.



> Cairo should mix the sRGB values together using normal math.

That means that *the application* converted my picture to sRGB, right?

> The back end will have a final result of a given sRGB triplet

No color managment in Cairo? Every surface will have at least sRGB
representation, math works as it does now and the fact that doing
blending in sRGB would result in different colors as if the blending
was done in CMYK does matter. Right?

>plus the fact that a given spot color contributed to the result.

In DeviceN terminology, every named color would have attached sRGB
fallback which gets propagated all the way down to the final surface
(destination). In other words, just attach a "const char *" to a sRGB
surface, right?

The problem is, what about pixel surfaces? That would mean, you have
to supply to image surfaces to Cairo - one in sRGB for blending and
the other one the original one in CMYK for exporting to a surface
capable of outputting CMYK (PDF).

> It can then try to extract the
> additive contribution of this spot color and figure out how to print the
> given sRGB using as much of the spot color as possible.

I'm completely lost on this one, how??

> I guess the input would be all sRGB. But for integer output the colour space
> should be selectable. ... Instead the user should
> be able to decide which colour space s/he wants to render to. This could be
> ECI-RGBv2, ProPhoto-RGB ...

Why do you want another color spaces if (unclamped) sRGB can capture
ale of the colors as well? Perhaps you are talking about unclamped
sRGB?

> Further I wold like to add two possibilities for colour managed input other
> than with static sRGB primaries:
> a) switch cairos input colour space on request,
> allowing to render in that colour space. Backends should support output to a
> additional colour space (PNG, image and PDF surfaces). The display surfaces
> need additional code to convert to the destination device on the fly. But
> that later to monitor conversion can be almost automatic. Colour conversions
> would be kept out of cairos core as blending is done in one colour space
> from one homogenous source colour space.
> Applications would need extra code to convert to the decided colour space.
> Cairo needs some means to fail in case the contexts input colour space is
> switched during drawing, e.g. return an error while setting the input colour
> space after the first drawing operation.

What is " one homogenous source colour space"? Again, who will do the
conversion - the app or Cairo? Could rewrite my CMYK example above so
I can better understand what you meant?

> b) cairo allows for tagging individual graphic elements with ICC profiles
> This includes cairos responsibility to convert them to a blending space for
> a flat representation like monitor or PNG. The advantage would be that for
> PDF the graphic elements can be placed with the same numbers, just get
> tagged with the individual ICC profile.

Are you saying, that Cairo should understand ICC profiles, tag all the
surfaces and do all the conversion on its own?

> DeviceN could be supported in cairo by converting that DeviceN input for
> backends, which are not capable of blending more than 3 colour channels.
> This would fit to model b). Or applications could use DeviceN only with
> certain backends by allowing them to query the backends capabilities: model
> a). The need to communicate with backends directly for switching code during
> drawing will weaken cairos one input multiple output feature.

Model "a" is no color management in Cairo, and "b" is color management
in Cairo? So if I have CMYK image I cannot display it on screen? I
have to first convert it to screen's space? So if I have gray scale
image, the application needs to convert it to some RGB for screen, and
for printing application has to convert it to CMYK, right? But that
means that I have to Cairo paths, that I cannot use "one drawing API
==> multiple outputs", as you said bellow. How would that fit the new
meta sureface, i.e. re-draw the same sequence of operators on
different surfaces?

> However I feel this problem can be safely ignored, in particular because
> partially transparent compositing of the negative values do not produce
> useful results anyway (fixing this would require linear math for the
> compositing, which is unacceptable as it will change the appearance of
> normal overlays such as partial transparency and defeat the useful gamma
> artifacts of sRGB that make negatives look correct to human vision).

So no unclamped RGB after all?

> I do not think there is going to be any interest in anything other than two
> outputs from any Cairo device:

If we are talking about *additive* color spaces, then ok but this
thread is mainly about "subtractive" ones.

> 1. Produce the sRGB result as accurately as possible on the output device
> using whatever information is available about it such as color profiles.

Is this color managed Cairo? Tag surfaces with ICC and let Cairo do the work?

> 2. "raw", use the sRGB results to directly drive 3 color primaries that the
> device can do, such that clamped numbers cover the gamut of the device.

Is this no-color managed Cairo? Just supply 3 numbers and hope you
know what you are doing?

> For an awful lot of Cairo back ends these two modes are identical.

Currently, I fail to see how those two model are ever even remotely
identical but hopefully that will clear up when you reply...

> When they
> are not identical, the second version is needed so that output can be
> matched with other software. I am not sure which mode should be the default,
> it may vary depending on the device.

Are you proposing two different behaviors for Cairo? If you want, you
could used color manager Cairo and tag the surfaces, if you want you
could supply straight values?

> Any other mode would involve simulating one device on another and I do not
> think should be Cairo's responsibility. The application can choose the
> correct sRGB values to match the other device and use the first mode, or it
> can learn the necessary information about both devices and use the second
> mode.

Ok, I think I understood this. But how do you supply images in CMYK?
Because, to me, it seems that either you have to supply two image
surfaces (CMYK and RGB fallback) or you need color managed Cairo so it
understands tagger surfaces. (Btw, if you already have color managed
Cairo, why do you insist on using sRGB? Then, it does matter what
space you are using, just supply one more profile.)

Phew....