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

[Kai-Uwe Behrmann]

CCing to OpenICC as this thread is shurely of high interesst there too. 
I apologise for the inconvenience caused by this cross post.

Am 21.01.10, 10:13 -0000 schrieb Richard Hughes:
> In https://bugzilla.gnome.org/show_bug.cgi?id=606885#c20 I've proposed
> a new set of GtkColor api calls that allows us to color manage
> GdkPixbufs and cairo surfaces. The modules have deliberately been kept
> small and simple at this stage, as we can easily add properties and
> methods at a later time.
>
> The reason I'm hoping to add API to GTK is so that most applications
> can actually use it to do 90% of what they need. It's not designed for

That approach is about explicite colour management. As such its covered by 
lcms and others well enough.
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.

GtkColorTransform is already hard stuff for most users. They want some 
fuzzy CM but have so many other things to do. CM implies pitfalls many 
will not see instantly. E.g. double colour transforms, wrong rendering 
intents, missed extensibility later and so on.

Compared to that, implicite CM could be very straight forward.
Few questions if at all and it just works. Thats lovely.

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.

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.

A implicite CM style is of course more work at the start than a 
resampling of a few lcms APIs. But implicity CM is much easier maintained 
and extented in the future. Programmers will use CM more probably as 
its much less work for them then to opt out of CM. With fewer APIs users 
can make fewer mistakes and Gtk maintainers have the chance to fix bugs 
easier.

As Gtk uses Cairo internally, my guess is that any work on making Cairo 
ICC CM aware would be of great benefit for Gtk too.  That way Gtk's CM 
could be designed much more clearer and modular right from the beginning.
I do not know if thats an option to continue this way. At 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.

> something like GIMP that needs to deal with full CMYK spaces and spot
> colors (although there's nothing stopping us adding this kind of
> support in the future) but it is designed to get 90% of applications
> color managed. By making GtkImage optionally color managed you've
> fixed 90% of all the applications (photo viewers, pdf readers etc) and
> a lot of the end-user "my photo looks too bluish" type problems melt
> away.

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. 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.

> Of course, I'm no expert in cairo, so the cairo surface API is
> probably horribly inefficient (given we currently have to
> pre-unmultiply and re-premultiply in C) but probably sufficient for
> most of the end-user cases out there.
>
> When designing the API, I was very keen to not to try to support
> everything, as this way nothing would ever be done. Color management
> is such a large area, with multiple orthogonal concepts, that it's
> usually very hard to agree on anything, much less shared API we can
> use. 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.

> care. Making color management 'just work' is the biggest hurdle for a
> color managed desktop.

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

In the long run a compositing window manager might be best to colour 
convert the whole desktop in hardware on the fly including animations ...
Marking all pre colour managed areas properly in Gtk so that they are not 
colour converted twice and telling the window manager about ICC profile 
and options for each area would be enough for that. This would fit very 
closely to what my feeling is how implicite CM could be done in Gtk.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org