[Openicc] [cairo] Adding a color management interface to GTK

[Richard Hughes]

2010/1/21 Kai-Uwe Behrmann <ku.b at gmx.de>:
> You add just an other API. But where is the new quality, the simplicity?
> What are te advantages to virtually copy the lcms into Gtk? Please do not
> missunderstand me, that I would ask for more features. I ask if your current
> API is in parts already too much.

That's the point. I've abstracted the color management objects so that
we can implement with ColorSync on OSX (or using Adobe Color
Management Module if that's installed) and the native API's on
Windows. The whole point of having a gio-extension point is so that
applications just work with none, one or some installed CMMs. This
keeps the embedded users happy (as the fallback is either NOP or
memcpy) and the artists happy as it "looks the same as in photoshop".

> GtkColorTransform is already hard stuff for most users. They want some fuzzy
> CM but have so many other things to do.

This is why most users won't be touching GtkColorTransform. If it's
built directly into high level widgets like GtkImage then it becomes
easy for the programmer to "enable" color management. If you make
color management as hard as it is now, then most application authors
won't bother, as we see from the small number of applications using
things like lcms.

> Gtk knows when it displays on screen on which monitor or on which printer.
> That could be enough to not bother 80% of the CM wanting programmers about a
> GtkColorTransform.

Correct, but we have to export it in the API so applications that do
know what they are doing, can do things like softproofing, and can
optimize color correcting 1500 photos in a folder. You don't want to
be loading (and then tearing down) lcms, the profile and transform
every time you render an image.

> If you manage to pass all collected ICC profiles through the Gtk structures,
> add resonable options, e.g. rendering intent, black point compensation and
> so on, then Gtk could be able to display or print the whole window colour
> managed. That had the potential of easier CM.

Agreed, and this is what I've tried to do.

> t least there are already many thoughts gone into the question about how CM could be
> implemented in Cairo and how a API could look like. It would not be from
> scratch.

Cairo is a great product, but at the wrong level to deal with this
hi-level color management. To make this easy for end users, we need to
talk about display color management in terms of GdkScreens and
GtkWidgets.

> Huch that touches the 10% of colour users. For "photo viewers, pdf readers
> etc" the GtkColorTransform stuff can be relevant. But thats not 90% of the
> users or area on the desktop. Most space are buttons, spacers, window
> borders, backgrounds and so on.

We're already applying vcgt ramps to the output(s), which, agreed,
isn't color management, but is color correction. You don't want to
have the performance penalty of color managing every widget in every
application as this is simply a waste of resources. Performing color
management on a desktop (which has large, changing areas) is
considerably more expensive than performing it on a 300x300 widget
(which you know when has been changed).

> One of the difficult to solve problems
> colour managed applications are still faced with, is image content divergine
> from the surrounding desktop. So a CM GtkImage widget would add to that
> group just with fewer options. Of course more applications have then that
> missed desktop CM problem.

I'm not sure I understand your point.

>> I'm also keen on pushing it into GTK core library rather than
>> just requiring applications use something like lcms. They can, and do,
>> frequently get this wrong and the vast majority of authors just don't
>
> So true. Thats why they need some help.

No, software authors aren't stupid or misguided, they usually have
time pressures, or want to add the sexy new widget into their
application. All the time we're asking them to poke about with
notify::pixbuf and manually tracking pixbufs or surfaces we're not
making things easy enough.

> For that CM must be easy. Explicite CM in its current form is not easy.
> (That said the lcms API had already easened life considerable for many.)

Ohh, I disagree. If we can make any random program color managed by
using a API call like
gtk_widget_set_use_internal_color_profile(widget,TRUE) then making
your application "color aware" is trivial.

> In the long run a compositing window manager might be best to colour convert
> the whole desktop in hardware on the fly including animations ...

And the performance hit of that is, well, huge. There's a reason Apple
and Microsoft haven't put the CMM in the window manager. It's a cool
trick, but in my opinion, not a good idea.

Richard.