[cairo] Subtractive API, part 0

[ecir hana]

On Sat, Jan 30, 2010 at 9:07 PM, Chris Murphy <lists at colorremedies.com> wrote:
>
> You want Cairo to simply understand four channel color spaces? That's it? They're entirely
> arbitrary four channels, and there is no need for Cairo to pass on any additional information
> so that four channel color can be displayed (RGB) or printed (mixed RGB and CMYK)? So
> Cairo manipulates this four color space somehow and then returns the result back to the
> application, which is then responsible for a CMYK->RGB conversion prior to submitting the
> result to the window server for display?

"You want Cairo to simply understand [multiple] channels, explicitly
named, color space?" ...

Hmm... You know what, this is just spot on. Yes.

I actually start to see no other way around it. Before you kill me,
let's enumerate what other possibilities there are. You could tag
spaces, you could define LAB colors or spectral frequencies, ... All
this means, that Cairo has to have the conversions on its own, i.e.
there has to be some CMS. This is essentially saying, that you are
allowed to mix surfaces with different ICCs. And I'm afraid this is
not going to happen (note this is a trick - to prove me wrong you or
someone has to implemented it). Obviously this is up to Cairo
developers to decide, I just got the impression that a cross-platform
CMS is not the most easy thing to get done and that Cairo has probably
better issues to solve than CMS. I also think it is unrealistic to
expect Cairo to bundle with some version of some CMS and maintain it
in separate repository for its own use. You, and many others here, are
right about many aspects but all of you need CMS embedded into Cairo
to make your arguments work.

That means, you would need to disallow to mix surfaces with different
ICCs or spaces. Everything would be just a simple untagged RGB, as it
is now. In case of CMYK and DeviceN this means that there always will
be fallbacks in plain RGB (contrary to CMYK I said before - just to
make things even simpler). You could tag a space with a profile but it
wont have any effect on screen or on blending - it would become just a
metadata, as you said bellow, just a notice to the printer what your
output intentions are or to spaces conversion. Everything else is up
to the user of Cairo. Use TinyCMS or nothing at all. Think of it as
you are thinking about Cairo and Pango. So in my opinion, the task is
to come up with an API which facilitates the naming of multiple
colorants and attaching metadata eventually useful for CMS later.

> You might be able to get away with merely passing on ICC profiles as metadata, without
> requiring any capability of color space conversions. It's undesirable to normalize anyway,
> prior to understanding the actual destination color space. So I wouldn't recommend that an
> application be required to normalize to displayRGB, it would be better for the application to
> tag its data with some source space (whatever it is) and have the window server capable of
> normalizing to displayRGB. And then the printing system can normalize to printRGB
> (whatever that is). Otherwise you end up with applications that have no means of inheriting
> even basic color consistency, it would have to be implemented in each application
> independently. I think that's a waste of developer resources.

I'm not sure I understood. Are you saying that all the color
conversion should be left to the OS? This would be great! If it
worked. But as this is something completely off my knowledge, does
anyone know, if this could work? Even on mobile phones? What about
CMYK a spots? Are you saying, that I could write "Ultramarine" with
CMYK(1, 2, 3, 4) fallback and SWOP profile, and let the OS do all the
work? I'm asking because I never saw how to pass ICC profile to a
window after asking for drawing context.

> Absolutely, all the time. Movie posters will be printed on dozens of printers, perhaps in
> multiple geographic locations.

Great example, thanks.

> It's kindof a ridiculous example because I can point to another process magenta and it will
> be a completely different color than the one you found. Magenta is not a color. It's a range
> of colors. It's a vague term.

That's because you don't use magenta but you mix two colors together:
magenta and the color for paper. The point I was making was that if
you apply thick enough layer or use similar paper we would get similar
color if the only thing we knew to buy was "magenta". But you are
right, I lied a bit, I specifically talked about printing press inks.

> Maybe, maybe not. It depends.
>
> 1. Do we have the same output device with the same output behavior (not guaranteed)?
> 2. Do we have the exact same spot color colorant (this is already a given)?
> 3. Are we using the same media?
> 4. Are we using the same driver/RIP software and versions?

If not, what is the better alternatives? I could ask the same
questions for whatever answer you would come up and I think spots
would be better choice. Really, could you give a counter example? Were
you thinking something like tagged CMYK? If spots don't use the same
media and tagged CMYK doesn't use the same media - first, what kind of
comparison is this, and second, with spots there could go less things
wrong as they are more simple (I assume we are not talking about 7
overlaying Pantones vs CMYK).

Besides, media type, which contributes most to the final result, could
be encoded in the name of spot color.

> Why should an application have to do this? It could tag the color with a CIE value and then
> downstream it's approximated as close as possible if the original colorant isn't available.
> Why ask every application to reinvent the wheel?

See above. Also I don't think it reinventing the wheel here, as you
could use CMS library, too.

> It's a continuum. It's not fair to say no one gets it right. I don't now perfection is an
> attainable goal anyway so I'm casting it right out from the get go. But given what I say in
> the paragraph above, there is a product that gets it very close to correct, and that's
> Serendipity Blackmagic. It does take opacity, dot gain, and print sequence into account
> for soft proofing and hard proofing.

Yes, but do you think it should be part of Cairo? Why should Cairo
care about dot gain? Doesn't it make more sense to do all this color
thing outside of Cairo?