[cairo] Subtractive API, part 0

[ecir hana]

On Sat, Jan 30, 2010 at 10:30 AM, Andrea Canciani <ranma42 at gmail.com> wrote:

> Would it be incorrect to separate the interpolation/composting
> problem and the colorspace handling?
> I.e. as long as I want to ADD, OVER etc two images (both expressed in
> the same colorspace as the operation I want to do) doesn't it make
> sense to just operate on each component without caring what color this
> corresponds to?
> I know that this would produce different results depending on the
> colorspace of the images, but isn't this what I'm really interested to
> do?

For example, are you asking whether if you have to layers in cmyk and
you want to multiply them is it ok to just take pixel A and pixel B
and the resulting pixel would be A * B? In my opinion, absolutely! For
the reasons Chris Murphy named, like the unknown ink opacity, it is
impossible to come up with more accurate way of saying half magenta,
than cmyk(0, 0.5, 0, 0). Also note, that sometimes there is no visible
difference between 90% printed color and solid one. I think that a too
smart way of handling this would cause more problems than it would
solve. And finally, say you have a one layer as cmyk(1, 0, 0, 0) and
another cmyk(0, 1, 0, 0) and you multiply them over. What would happen
if you did the composing in another space? No one knows. But if you
would use cmyk, the result would be cmyk(1, 1, 0, 0). I guess, what I
try to say is the "principle of least surprise"...

> Wouldn't just use colorspaces "for everything" solve this problem?
> This would mean to always have to specify colors with n component
> values and the colorspace where they should be interpreted.

What do you mean by color space? Because when I say
cairo_set_source_cmyk(cr, c, m, y, k) I talk about CMYK, of course.
Did you meant ICC? At any rate, as it seems, color spaces per se are
not the problem - the trouble is the conversion between them.

> But it would it be correct to work (or even just convert an image that
> was in RGB, grayscale CIE, whatever) in a CMYK space, as long as it's
> calibrated for your specific device, right?

I'm not sure I followed this one.

I think I would try "to work" on an image in its own color space as
long as possible and to convert it to cmyk only afterward, for the
final export.

Or, other way I understood it:

I meant that it is possible to type in CMYK values which, when
printed, would look like the color I wanted. I.e. without ICC. Because
those CMYK values could come already calibrated, so I guess my answer
is "yes".

> Why? Having the ICC profile the image is supposed to be in would solve
> this problem, right?

Because it is useful to communicate that you want your poster to be
printed on coated paper. I cannot understand why someone would print a
poster on coated paper and then re-print it on uncoated one. But yes,
it might happen and it is good to explicitly state your intend.

> I don't see some of the problems that seems so hard to overcome as
> colorspaces seem to solve most of them (no true magenta? right. just
> 100% of the 2nd primary. it will be correct iff used on a device whose
> 2nd primary is the same as in the colorspace I defined)
> Would you please be able to explain what would go wrong abstracting
> what colorspace we're using (except, of course when doing colorspace
> conversions)?

This is similar as above, I'm not sure I followed. What do you mean by
"abstracting what colorspace we're using"? Could you gave an example?

> PS: uh! what are good references about color management? Currently I'm
> reading some of the ICC specification (plus a few other "standards",
> mainly related to YCrCb spaces).

I'm definitely not a good person to ask this, maybe others will tell
you more. All I can say is how I understand CMS, corrections are very
welcomed:

CMS is basically two things, one simple and one really difficult.
There actually is one and only, true color space - LAB. When you also
define the white balance what you get is 4-dimensional space and if
you pick a point there everyone in the whole world would precisely
understand what color you are talking about. That's the easy one. The
problem is that for purely technological reasons there is no device
which can show LAB. All monitors, printers, papers, scanners, cameras,
... are different. So what you do is you come up with a mapping which
says this color on this device should be that color in LAB. This
mapping is called ICC. You go from your monitor to LAB and from LAB to
your printer (i.e. two ICCs). And you know what? In one instance it in
fact works - if you are able to control all the devices in your
workflow. Say you are a huge magazine publisher. You know what
monitors you use, what lamps there shine and what cameras you take
picture with, you print all the time on the same paper with the same
printer with the same dyes. You print a few test sheets, you measure
the output and tweak a bit some of your profiles until it looks right.
And then you don't touch it! The problem is, that you and I are not
huge publishers. You come to some random printing house which gave you
the best price, you demand some random paper which they never heard of
and then you glue a protective foil over the final prints. Obviously,
there is most certainly no right ICC because the numbers of possible
ICCs grows exponentially so no one cares. So what you do then is you
make an assumption here, a generalization there. By the time your
prints get out, the colors are so far from your original intend, that
the portion which CMS contributes to the correctness of result is
smaller that say, if you relayed on dot gain compensation or
experience, for example. Not to mention that some printers simply
refuse to take tagged sources, probably as they had bad experience
with it.