[cairo] Subtractive API, part 0

[Andrea Canciani]

On Sat, Jan 30, 2010 at 12:32 AM, ecir hana <ecir.hana at gmail.com> wrote:
> (Look, at least on my part, this discussion is rather interesting so
> thanks for your patience.)
This discussion is very interesting for me, too. I've just started
reading about colorspaces and CMS, so I'm not the best one to
contribute yet, but since I'm going to do a thesis on extending pixman
(and probably cairo) with colorspace support (and a few other things),
your knowledge and expanations seem quite valuable.
>
> I repeatedly said this proposal is not about displaying colors and yet
> you always talk about color management. The proposal does not care
> whether cmyk(0, 1, 2, 3) is rgb(4, 5, 6) or rgb(7, 8, 9). It is about
> saying "cmyk", about the ability to define any cmyk(w, x, y, z) in
> Cairo.
Would it be incorrect to separate the interpolation/compositing
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?
>
> Apparently, you have two problems with the above: how do you display
> untagged cmyk and how do you print untagged cmyk. As I said, those are
> questions not central to my proposal but I will address them anyway,
> for the sake of discussion. For display, use that simple formula I
> wrote above. Is it perfect? Hardly and I never claimed that. For my
> needs, it is sufficient as I understand that what's on the screen is
> wrong anyway. If you need more precise way of converting to RGB you
> are very welcomed to come up with a more suitable fallback. Again, I
> don't care whether you use ICC or CIE LAB or sRGB - my question is,
> certainly there is some kind of fallback which would make you happy,
> but how to tell Cairo about it? If you were in need of defining cmyk
> in Cairo how would you write it down? Would "set-cmyk-for-this-icc" do
> it? What about:
>
> void cairo_set_source_cmyk_icc(cairo_t *cr, double cyan, double
> magenta, double yellow, double black, cairo_icc_t *profile);
>
> Or perhaps, even if IMHO it's of no use, you could define rgb
> f_allback for a cmyk color, how about that? You could supply any
> values you want, like:
>
> void cairo_set_source_cmyk_rgb(cairo_t *cr, cyan, magenta, yellow,
> black, f_red, green, f_blue);
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.
>
> For printing, even with untagged cmyk, nothing stops the application
> or CMS to supply correct cmyk values to Cairo. Those values would get
> baked-in into the pdf, making them possibly unusable on another device
> - so what? Do you print a poster on two different printers? The point
> is, currently you could not even export cmyk. If there was the ability
> to define cmyk, you could enter any values, be it from CMS or
> experience. If you still insist that the PDF must have embedded ICC,
> is it really such a problem to provide it as an additional argument of
> the function from the very above? Btw, decoupling CMS from Cairo has
> several advantages.
>
> Then there is my favorite topic, spot colors. Saying there is no
> magenta is just utterly wrong. You can buy magenta here:
> http://www.printinginksupplies.com/NOVASET-PROCESS-MAGENTA_p_76.html
>
> I claim that if you need to print a certain color the best possible
> way is to use a spot color. I hope we agree that if the color is
> present on the output device, there is no problem whatsoever and we
> both get the same result if we use the same spot color, right? Now,
> what happens if the device does not support the spot? Again, I don't
> really care. There is no substitute for metallic color or matte
> varnish, anyway. Take gold, for example. To supply some random yellow
> in CMYK for the fallback is perfectly ok, because metallic colors look
> differently at different view angles. You certainly don't need CIE to
> get higher precision because it is totally wrong anyway. But if you
> insist, your application could ask you what kind of paper, printer,
> ... you use and supply these CMYK fallback values to Cairo. I'm
> interested in how the API function should be written, what kind of
> data structures are there needed and what does it mean for the current
> Cairo surfaces.
>
> In other words, say you want to print "ultramarine" color. How do you
> tell Cairo? How do you supply its tints values?
>
> On Fri, Jan 29, 2010 at 6:42 PM, Chris Murphy <lists at colorremedies.com> wrote:
>>
>> CMYK is completely useless on everything except for the CMYK output device those
>> values were intended for.
>
> Right. This is all I was talking about.
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?
>
>> And worse, you will be creating files that contain undefined CMYK values.
>> ...
>> They do not actually communicate a repurposeable intent.
>
> Good point. I agree.
Why? Having the ICC profile the image is supposed to be in would solve
this problem, right?
> ...
I think I read all of the mail (recently) posted on this subject, but
I might have missed some.
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)?
Thank you for your time (and for running this discussion).
Andrea Canciani

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). Thanks again