[cairo] Adding a color management interface to GTK
ku.b at gmx.de
Thu Jan 21 10:47:24 PST 2010
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
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
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
> 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
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.
developing for colour management
www.behrmann.name + www.oyranos.org
More information about the cairo