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

[Kai-Uwe Behrmann]

Am 01.11.04, 15:54 -0500 schrieb Carl Worth:

> On Sat, 30 Oct 2004 18:53:42 -0400, Ross McFarland wrote:
> > On Sat, 2004-10-30 at 17:54, Carl Worth wrote:
> > > On Sat, 30 Oct 2004 16:43:09 -0400, Ross McFarland wrote:
> > > > it doesn't need to understand the color, as it doesn't now.
> > >
> > > But it does now. The color values provided by the user are sRGB. That's
> >
> > cairo itself doesn't know anything about sRGB.
>
> If I were to take a cue from my 4-year-old at this point, I would just
> say, "It does too!", well prepared to continue the debate ad nauseam.
>
> Let me instead say that I think we are in violent agreement here. The
> "core" cairo code does pass color values from the user to the backend
> largely uninterpreted.

Fine, so it would be consequent to let them pass and dont stop them.
Breaking this breakes the freedom of the user, as she/he is forced to cut
everything down to 8-bit sRGB. And again the technical sRGB .

> > what i'm proposing would cause no visible changes to apps. and only
> > (possibly) slight changes to backends (array indexes rather than struct
> > members. changes it took me a couple of mins to make in my local copy of
> > the backends.)
>
> The amount of work needed in the internals is almost irrelevant. That
> kind of work is always a lot easier than getting the API right, (which
> is the part I really care about).

Different backends cause different behaviour. It is the chance of cairo to
integrate all these differences. Otherwise the effort for all applications
based on cairo, to search for individual workarrounds would will be immense.

> I know very little about color management, so I've been trusting the
> advice of those with more expertise than me. The advice I've received so
> far has convinced me that the right architecture will leave color
> management outside of cairo itself.

Yes, color handling is the target of very specialized libraries. Solving
this field is not done easily. Cairo is not the right place to implement
the ICC standard.
But it does not imply to reject arbitrary color data. Color management can
help You handling 8-32 bit per channel. Take an look at the lcms tutorial.
Programming with lcms is mostly fun for the people who have an knowledge
of the basics.
I simply remember the Xcms API it has the right place, only no one (me
included) understood it. Today people can help You understanding current
libraries. We have many people around the world programming it. There is
an active and potent community spread over some projects.

As far as I understand Ross, he askes simply to let additional
information/content pass through. The concept of attchments is a very
qualified one. Please correct me if I am wrong.

Even though I would suggest the strong way. Take the content and handle it
properly, or at least, as Ross suggests, let them pass. This will make
cairo an very easy to use and competent library. Ashuring colors find
theyre way, instead letting things become inconsistent like in the past.

> >              so that if special tied apps and backends (printer/press
> > RIP's) could be developed with cairo.
>
> If the application is going to be tied so tightly with one particular
> backend, then it sounds like this data channel should go from the
> application directly to the backend.

In case of profile attachement would it mean, I have to recreate the PDF
generation, only because there is no way to pass a simple ICC profile?
hmm..

> For example, we've already got that kind of communication between
> applications and glitz. And this is the kind of thing that led to the
> following diagram of the cairo architecture:
>
> 	http://freedesktop.org/~cworth/xdevconf/slide_05.png

Spreading the competence of color management over many places is only
the half of that concept. I mean here: one correction in an application
followed by one separate in the graphics hardware (video cards gamma
table) and an other in the pdf backend all independently initialised by
the application.
I am shure You will change Your mind if starting with color transformation
in hardware. So why not creating now the basis?

> As I said, I'm no expert here, so I'm prepared to be convinced to change
> the current approach to color in cairo. But I'm definitely uninterested
> in new top-level API that only works for some subset of the backends.

If You need code to convert arbitrary color data through an bunch of
profiles I can contribute. This can allways been used as fallback. So
the "backend cannot" argument can be eliminated.
I am just working on an new file reader for scribus. It will be able to
handle all sorts of pixel layouts and up to 16 channels, as is currently
possible with the littleCMS library. Other projects are interessted too.
So why not splitting something off for cairo.

Of course it adds an API, but will work for all backends.

I plan to set up an first configuration to let different applications
(scribus, cinepaint, graphicsmagic, inkscape ...) react in sync to user
settings. This will not be placed in cairo. But I would like to see cairo
using such an concept.
An color management system needs many places to work properly. But best is
to do the transformation only once, because it is in case of often done
quality degrading.

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