[cairo] RFC the idea of n-plane color support

[Kai-Uwe Behrmann]

Hi,
my name is Kai-Uwe Behrmann. I am thinking about an possiblity to color
correct monitors under linux, handling the source images native color
space. So some questions arrises.

How passes an ICC profile through Cairo to an final PDF output or to glitz
for monitor correction? Physical devices are allways different.
As Microsoft plans to overcome GDI, they will go steps further to
support 8/16-bit (sRGB,scRGB,CMYK,n-color) colorspaces in WCS.


regards
Kai-Uwe Behrmann
                                + imaging development / panoramas
                                + color management
                                + email :ku.b at gmx.de



Am 29.10.04, 14:33 -0000 schrieb rwmcfa1 and UNEXPECTED_DATA_AFTER_ADDRESS:

> On Fri, 2004-10-29 at 17:08, Carl Worth wrote:
> > On Sun, 20 Jun 2004 20:51:16 -0400, Ross McFarland wrote:
> > > attached is a patch that changes the color path in cairo allowing
> > > arbitrary data to be passed through.
> >
> > Hi Ross,
> >
> > I'm sorry for the very late reply, but I'm trying to push through my
> > backlog. Hopefully I won't have to get so far behind in the future. And
> > I do want people to know that patches they have submitted have not been
> > forgotten.
> >
> > > my thoughts are that cairo doesn't know or care anything about color, it
> > > just passes it through, so why not have a generic path so that any type
> > > of color could be passed through. (leave it up to the app and the
> > > backend to determine how the data is interpreted.)
> >
> > In the recent teleconference we discussed the issue of color spaces. I
> > agree that we need a system by which any color can be expressed. Keith
> > recommends that the cairo RGB API be specified to be sRGB but that it
> > allows negative values. I'm assured that this approach will allow all
> > colors to be expressed. It also has the benefit of doing the right thing
> > when users na?vely pass in RGB values.
>
> sRGB with negative values and positive values above 255 would allow you
> to specific all possible colors. but still would not be sufficient for
> many situations, namely for multi-ink printers/presses. you could
> conceivably represent all of the possible colors they could print, but
> you wouldn't be able to preserve the usage of specific inks.
>
> the simplest case where this comes into play is with a CMYK device. if
> text is specified as 50% K. and this is translated into rgb as (128,
> 128, 128) which is fine and would still result in the same ideal color.
> but if you try to go back to cmyk (inks now) how would that come out?
> you need to keep things that were specified as pure C,M,Y,K (or even
> specific combinations of them) as requested or you end up with
> undesirable print. at first glance the solutions seem simple, but i
> assure you they aren't. (there is much ongoing research about how to do
> this in a full-proof way and no answers)
>
> > But I'm not interested in an API addition that provides backend-specific
> > colors to be passed in. One of the goals of cairo is to enable you to
> > switch backends and get matching results without changing the
> > application code. If I understood the intent of your patch, it would
> > violate that property.
>
> i don't have a good answer for that except to say that i wouldn't
> envision any app or 'normal' backend using the ability. i would see it
> being useful in special case applications (print pre-press) or device
> RIPs.
>
> > What do you think of this approach?
>
> basically if you don't support an arbitrary number of color planes cairo
> couldn't be used as a RIP engine for a printer or printing press. (and i
> would imagine there are other similar situations with which i am not
> familiar) i realize that's not exactly your goal and there aren't
> exactly a plethora of RIP's out there, but when it is pretty well suited
> for such purposes otherwise and i think it's a shame to rule it out
> completely.
>
> --
> -rm
> http://www.neces.com/
>