[cairo] Subtractive API, part 0

[Chris Murphy]

On Feb 2, 2010, at 11:29 AM, ecir hana wrote:
> le
> 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?

Why should every application have to do such a fundamental task? This is currently how it works on OS X. It's more optional on Windows 7.


> 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.

This is entirely boolean logic, it's just a matter of flowcharting it, making decision of what portions are doable in a reasonable time frame, and making it feature set upgradeable without breakage from the get go. So yes it could be done, it's just a matter of where. A catch with open source is there are a bunch of parts and less centralized agreement on how to communicate color spaces between applications, services, window server and print pipeline.

> 
> 
>> 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.

There are at least two completely different magentas commonly used on printing presses in the U.S. One is rhodamine dominant and the other is rubine dominant. They're not at all the same, I would not consider them similar. Both are "magenta".

Epson has two different magentas in their currently shipping professional printers. They're not only different from each other, but they're different than press magenta.

Cyan is similarly vague. Even black is vague. There are greenish black, bluish black, many are reddish black or yellowish black. All are merely called black. All are different and it becomes DRAMATIC when you start talking about GCR, and trying to produce a neutral gray.

Color laser printers have completely different CMYK primaries than the aforementioned inkjet and printing presses. Not similar at all. Very different.


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