Color Management in KDE
jlayt at kde.org
Mon Jan 21 21:22:42 GMT 2013
A couple of months ago I attended the Linux Color Management Hackfest mainly
to find out how to color manage printing, but also to get a wider overview,
and to figure out the colord versus Oyranos situation. I've been sitting on
this email for a bit as it's probably going to be controversial and step on a
few toes of people who've put a lot of hard work into CM, for which I
apologise. My big concern is that KDE is sleep-walking into a hodge-podge
solution with little co-ordination on implementations and dependencies, and
little knowledge of the implications of the decisions being made. I've tried
to come up with a logical pragmatic solution within the usual KDE standards
and architecture, but I am not a CM expert so if you feel that I've got
anything wrong or misunderstood the situation please don't hesitate to call me
In my opinion:
* colord is clearly the preferred option for querying the CM config at a
system or user level
* However until colord and Oyranos share a common config we will still need to
support querying Oyranos
* This is best done through a new shared library with backend plugins, rather
than each app coding support for themselves
* The user can still choose between using colord or Oyranos to set up their
* In KDE4 app devs can still choose to use the Oyranos abstraction api if they
* Eventually Qt5 will gain full native support and we won't have to worry
Why do I say colord is the preferred option?
* Can be a runtime dependency via Dbus, not compile time like Oyranos
* Is hard dependency for Gtk/Gnome3, it seems highly unlikely they will
* Is integrated into CUPS only due to Red Hat pressure, it seems highly
unlikely Apple will add Oyranos support
* Plans already underway for a shared config, so seems pointless to duplicate
the DBus service as well
* Seems unlikely Qt5 will choose to support both, colord seems more likely
* Keeps our dependencies clean and simple, as well as our code
So what does that mean for Oyranos?
* Already planned to share a common config, we will still support Oyranos
* Saves Oyranos having to build and support own DBus service and keep in sync
with colord's service
* Makes no difference to those who prefer to use Oyranos config tools or CMM
I'd like to hear from people who've already implemented colord or Oyranos
support in their apps to see if they would be interested in working together
on a shared library, possibly based on the Calliga/Krita api.
Here's a rather more detailed reasoning for those who want to know more.
So what is color management? Here's my simple and probably wrong
Hardware is variable and you cannot guarantee that a given RGB value will look
the same on any two screens or printers. A Color Management System (CMS) will
adjust the RGB values used on different devices to ensure that the colors
displayed are consistent with the original intent. A CMS needs to know the
Color Profile of the source Colors and the Color Profile of the destination
device, and then Transform the source colors into the required destination
colors. The destination profile can either be a generic default for a given
device, or a specific calibrated profile provided by a user.
There are two main parts to a CMS:
* CMF - Color Management Framework - manages Devices and Color Profiles. This
has two parts, one setting up the config by creating profiles and assigning
them to devices, the other telling apps and services what profiles to use for
* CMM - Color Management Module - does the actual Color Transforms from one
space or profile to another.
There is some debate on how separate or integrated these two parts need to be,
on Windows and OSX they are integrated, but on Linux they are completely
The implementations we need to know about are:
* The OS X CMS is called ColorSync which is built-in to all OS X graphics
systems and turned on by default.
* The Windows CMS is called WCS and has been available since Vista but is off
by default (XP has something called ICS which I'm told doesn't really count).
* LCMS/LCMS2 and ArgyllCMS are the most commonly used FOSS CMM's.
* Oyranos and colord are the two CMF implementations on Linux.
* Linux only, CMF only
* Not a CMM, leaves that to toolkit, app or window manager
* libcolord gobject C library, LGPL 2.1
* Config stored in DConf
* DBus service & api for all options
* Command line tool for all options
* Intergrated into GTK, CUPS, SANE, etc.
* Is a hard dependency for GTK, CUPS and Gnome 3, so will almost always be
installed on a system
* Not fully stable api yet
* Can be optional runtime dependency via DBus
* CMF and CMM abstraction API
* Linux and BSD support using own CMF implementation
* OS X native ColorSync CMF support
* Plans for Windows CMF support
* CMM api only supports lcms/lcms2, plans to re-write to support more CMM's
* C library, BSD license
* No DBus service
* Command line tools for certain options
* No integration into CUPS, GTK, SANE, etc.
* Not fully stable api yet
* Must be hard build time dependency
In some ways Oyranos could be seen as an alternative to Qt in providing a
common abstraction api across the major platforms, except it is in C, not yet
on Windows, and requires explicit CMM code rather than having it implicit in
the Qt graphics classes.
Both Oyranos and colord implement both parts of the CMF, allowing users to
configure their devices, and allowing the apps to query the system config to
use instead of implementing their own config management. colord has the
advantage of being integrated in a number of core systems like CUPS where
Oyranos is not.
The main problem right now is that the colord and Oyranos configs are not
synchronised. If a distro uses colord as their default CMF, and a user
installs an app that uses Oyranos for its CMF, then they will need to know to
configure Oyranos as well as colord, and vice versa. As CUPS only uses colord
then any distro defaulting to Oyranos will require the user to also configure
colord if they want printing to work properly. This is poor usability, and
makes it very hard for an app to know which is the correct config to use. It
is planned to store a shared config in DConf, but this depends on Elektra
obtaining a DConf backend, and a timeframe for this is not clear.
I did suggest that Oyranos implement a DBus service with the same API as
colord so apps only need to code for one runtime api, but I now don't think
this is a good idea. It would not be a full solution as CUPS and GTK use
libcolord not DBus to obtain the config. It would also require the two DBus
implementations to be kept in sync which seems wasteful once the config is
Until the config is shared an interim solution might be for KolorManager, the
Oyranos config tool, to write the config to colord as well?
CUPS supports printer color management via libcolord. It asks colord for the
Profile to use for a Printer and Print Job. This works fine for local
printers, but fails for remote print servers. The correct solution is to
embed the Print Intent in the Print File itself, and I'm working on this for
both KDE4 and Qt5. For KDE4 this would require printing to PDF, then using
GhostScript to embed the intent, and then printing the PDF via lpr like Okular
does. This could prove very slow.
Qt does not support Color Management, but there seems to be work in progress
for Qt 5.1 or 5.2. I assume Qt will wrap the host color managment systems
(ColorSync, WCS) using platform plugins and provide a common api. On Linux
(and perhaps Windows XP), Qt will have to either write their own CMM (faster
but a lot more work) or use LCMS2 (MIT license, probably slower but less code
to implement), and for the CMF will probably use libcolord once the config is
For KDE4 and probably early KF5 we have to look at other options.
KDE4 CMM Options
Neither colord or Oyranos is a CMM, but Oyranos has an abstraction api that
simplifies writing transform code. This is an option, but it only supports
LCMS and LCMS2, not OSX ColorSync or Windows WCS. Kai-Uwe has suggested he
needs re-write it and change the API to support other CMM's, so I see little
use for it for now unless an app finds it easier and less code. I'd suggest
just directly using LCMS2 as standard until Qt gives us implicit support in
the graphics classes, but this is entirely at the apps discretion.
KDE4 CMF Options
Eventually Qt5 will give us a cross-platform CMF abstaction layer, but in the
interim there are four options:
1) Apps use only colord via dbus as a runtime dependency, but this won't work
on OS X or Windows and initially won't read the Oyranos config.
2) Apps use only Oyranos as a build dependency, but this won't work on
Windows, and initially won't read the colord config or integrate with CUPS or
SANE or GTK.
3) Apps use both colord and Oyranos depending on what is installed, but this
carries a large maintenance burden and complicates dependencies unnecessarily.
4) We implement a small KDE library to wrap plugins for colord and Oyranos and
optionally Windows and OS X, so apps are independent of whichever is available
and protected from API instability. A default sRGB plugin could be used when
neither are installed. This would make the eventual Qt5 migration easier, and
maybe influence the Qt5 api.
Obviously my recommendation is for option 4 to be implemented for KDE 4.11.
This could be based on the existing Calligra API. I'm not sure how much time
I'll have to work on this myself, but it seems to me less work for apps to
work on this together instead of each one re-implementing the same code.
Let me be clear though, if an app wishes to use Oyranos directly as a hard
requirement because of some better functionality or less code then they are
free to do so, but it does come at a cost that they need to be aware of, a
cost which I don't think belongs in kdelibs or Workspace.
More information about the kde-core-devel