Color Management in KDE


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

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
support Oyranos
* 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
until implemented
* 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
abstraction api

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
which device.
* 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.

System Config
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 5
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
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.




Re: Color Management in KDE

By Kai-Uwe Behrmann at 02/02/2013 - 08:38

Sorry for the delay in answere, but a infect took me quite some time.
More inline ...

Am 21.01.2013 22:22, schrieb John Layt:
Michael Sweet from CUPS said, he would not oppose linking to Oyranos,
but expects more code to make it reality. We from the Oyranos project
said, that a session daemon, like colord, inside CUPS server makes
technical, administrative and security wise not much sense.

You focus on DBus. Maybe a DBus API helps on one single platform. But it
is a IPC mechanism and no abstraction layer.

On the other side Qt would have to write, test and maintain many
platform code. The Qt project needs certainly a expert for that work.
ICC colour managemenet is a complex topic on the scale of i18n or
printing. Projects which successfully implemented ICC support engaged
with a specialist. Either the person involved in that work became a
specialist after lots of learning with the needed enthusiasm or the
project hired a colour scientist. In any way it took the projects many
years to figure concepts out including testing and fixing sometimes
essential bugs.

I am not so sure that will help. colord follows a minimalistic approach
as is typical to GNOME. At the moment Oyranos supports quite more features.

In regards to colord we gave up our requests to see certain features
added and maintained. We wanted some policies considerd for ICC shared
profiles, which is a essential part for Oyranos. But these whishes where
completely ignored. We try to work around things and hope to cooperate
better based on specs.

For the difference of calibration versus characterisation:
<a href="" title=""></a>

A ICC profile contains primarily a characterisation.

On Linux both aspects can be used integrated inside the ArgyllCMS tool
set or Oyranos API and tools.

Most ICC aware apps use the ICM part of WCS, because those APIs are ICC
based. The newer WCS parts are rarely considerd because, those drifted
away from the ICC spec and thus are less compatible with graphic
industry products.

ArgyllCMS contains a device configuration part for monitors dating back
before Oyranos and of course colord. It is known as ucmm.

[Btw. Argyll author Graeme Gill avoids the artificial blown up term CMF,
like all CMS authors I know of. There can be so many aspects of a CMS,
that it makes no practical sense to coin for each aspect a different term.]

SANE-backends-1.0 (e.g. has no dependency to DBus or colord.
Each colord client, which likes to support SANE has to implement that by
its own. colord has no device specific code inside. ldd shows that
easily on Linux.

Every CLI tool can be called at runtime especially easy on Posix
systems. That is not much different than DBus. So it would in theory be
possible to use Argyll/Oyranos or colord in exchange without hard
linking. I guess the amount of code might be similar like supporting all
those different DBus APIs + support code.

Let me add an advantage. Argyll and Oyranos have the needed device
dependent code already inside. No need to fiddle with EDID, X11, CUPS
and other API's.

The last half sentence makes no sense to me. First of all. lcms is the
most highly valued CMM on the planet right after the AdobeCMM. It's
portability is simply amazing.

CMM code is dlopen'd in Oyranos on demand. E.g. KolorManager will never
link against or call lcms.

On the opposite, a ldd to shows a hard dependency to .

Qt graphics classes are dependent to any CMM in what way? Are Qt apps
free to choose a CMM if Qt graphics classes have already choosen one?

A session daemon inside CUPS server is a burden to keep working properly.

We have developed and implemented a alternative concept. After some time
it became obvious, that Apple does in principle the same like in "our"
concept. The idea is to place the user selected output profile into the
print job itself, on Linux this is the PDF's OutputIntent like on OS X.
CUPS server has to detect that in both cases and then needs to shut up
and let pdftoraster do its job.

Agreed on the configuration side. In parts there are independent
standards, which allow apps to query ICC device configurations without
Argyll/Oyranos or colord involvement. That part is based in the ICC
Profile in X spec and the most widely used query mechanism on Linux.

I did not even hear about that service. Even though I am one of two
persons, who had worked on specs for a shared CMS DB on Linux. The other
person is Graeme Gill. His implementation is based on JSON files, which
I find sound.

That is an idea. Writing the needed keys for ArgyllCMS and those for
colord could potentially improve compatibility from the Oyranos side.
Everything else needs more discussion, perhaps on the next CM hackfest.

It has logical limitations even for all multi user systems. CUPS server
handles print jobs, while colord is session centric. Now mix print jobs
from elder sessions of other users with a actual session and the trouble
is instant.

Why do you expect slowlyness? Can you please share what you have so far?
I and I heard of others too would be really interessted in your findings
and the code modifications.

To be clear we talk here about backend APIs. That are the ones Oyranos
does currently not expose.

CUPS and SANE are non relevant, as those have to be adressed otherwise.
For GTK I am not sure either, as Gimp and Inkscape use the ICC Profile
in X spec, which is CMS independent.

Let me outline point 4) and what I expect that to become:
colord is mostly a small API for DB queries. The DB itself is otherwise
hidden. The outlined project will need many own code to implement the
basic device and driver configuration detection. Or it can choose to
ignore aspects leading to a poor implementation. As soon as one has
written all the needed code for KDE or Qt it needs to be continued for
each other supported platform. Thats the logic. In the end it means
parts of Oyranos or GCM get rewritten in a Qt specific style. All
remaining Linux DE's have to rewrite everything by themself too. The
actual Gnome CM (colord) way makes a massive repeat of code necessary.
IMO that is a waste of programmers energy. Because KDE/Qt will for sure
not provide a shared API suitable for any Gtk/EFL or other DE project
out there.

In my expectation the benefit for KDE will likely be relative small,
because it can not much cooperate with other projects this way.

Let me add:
5) KDE implements a own CMS based on available standards and specs. That
way it is completely independent, while remaining compatible with
existing CMS on many levels. It takes away ambiguity and a clean Qt
style is straight forward possible.

It takes many disadvantages from 4) but on the positives is a kind of
clean room implementation. Certainly it demands lots of work, but maybe
not much more or even less than 4).

Hmm, reads like a plan to abstract from the Oyranos abstraction API.
Maybe a graphics scheme could help in making that idea better

kind regards
Kai-Uwe Behrmann

Re: Color Management in KDE

By Daniel Nicoletti at 02/02/2013 - 16:33

2013/2/2 Kai-Uwe Behrmann <ku. ... at gmx dot de>:
There's no such thing as a colord daemon inside CUPS, there's only
a runtime dependency to get the printer profile and code inside CUPS
that applies that to the print job.

You have DBus on pretty much any *NIX plataform (tho some features aren't
available in all of them) and afaik there's some effort to bring it to Windows.
Having an abstraction layer is not the job of who provides the ICC <-> device
association, it would be the job of some Qt engineering wiling to provide a
QColorCorrection class to do the tranformation on some surface, at this point
it would need to know how to talk to OSX, Windows and Linux CMFs just to get
which profile to use.
So yes, we focus on DBus to make it easy for GTK and Qt applications to get
what does matter, and avoid linking with code that might crash apps, it does
make total sense...

Sure they need an specialist, after all they provide a commercial solution,
and abstracting is what Qt devs do better, look at the window system,
print system, compilers and lot more that they have to abstract...

IMO if you could turn your Oyranos libs into a simple library and make
it into kdelibs
which didn't had hard deps with Oyranos or colord (only linked abaings
Qt/KDE and
lcms2), would be what Krita & friends would need...


Re: Color Management in KDE

By Kai-Uwe Behrmann at 02/04/2013 - 02:32

Am 02.02.2013 22:33, schrieb Daniel Nicoletti:
Oyranos is based in many aspects on community driven spec from OpenICC.
I have the impression you did not read the OpenICC wiki pages, the specs
or email list. That's probably a problem for a person, who wants to
maintain a CM stack inside KDE. You completely depend on one API and the
word of one person without good own reasoning. That's all you offer KDE.

Coding device specifics in each client makes detection of driver
settings more error proune, as is it is a not simple and is a repeating
and to be continued task.

In KolorManager we do it *with* SIGNAL + SLOT for asynchronous tasks. No

The concept in colord is to use a device ID, which is a actificial name.
That one might have nothing to do with actual colour behaviour and thus
is eigther only particial useable for profile association or inflexible.
What appears small work to you results from the omitting of real world
use cases.

I did not write what you imply. Your blindly jump to hostile assumptions
about a project you appearently did not care to look much into.

The Oyranos CMM wrapper modules in question link against lcms, but the
modules themself are dlopend like any normal plugin system does.

The whole chain of drivers, their colour related options, the colour
device itself + involved media influence all the colour result. This
chain has to be reproduceible, otherwise reproduction of colour is not
managable. ICC profiles are merely a characterisation of a certain
colour reproduction state. A CMS typical tries to get all required
infomation to reproduce a colour behaviour and get most parameters to
reduce unwanted disturbance. That's the reason why driver settings must
be covered as well. In the case of X11 that might be switchable colour
primaries, which are detectable over the EDID data. For most other
device classes exist at least gamma and more driver parameters, which
need to be taken into account for profile selection.

There exist at least two open source implementations, which exactly do
this kind of abstraction. Applications use these and in parts own
abstraction layers.


Kai-Uwe Behrmann

Re: Color Management in KDE

By Cristian Tibirna at 01/22/2013 - 11:50

On Monday 21 January 2013 21:22:42 John Layt wrote:
Hello John

Thank you very much for a very clear exposition of the concepts and of the

A few questions, just to complete my understanding:
- is it possible that, from an integrated KDE p.o.v., having the support
provided in kwin and in the (to be fully revived) printing infrastructure,
would free apps from the need to directly address this issue?

I guess I understand that a very color-conscient application (like, say,
krita), will need to correctly support CM internally, particularly if the app
is used outside an integrated KDE session. But then, is there conflict when
both the application and the wm try to manage color?

- you mention a few hypothetical developments (especially in relation with
Qt5). Do you have direct information on the plans? Or, in other words, what is
the perceived probability that your future-projections could be defeated by
predictible developer-opinion/development-direction changes?

Thanks a lot.

Re: Color Management in KDE

By Kai-Uwe Behrmann at 01/23/2013 - 12:51

On 22.01.2013 17:50, Cristian Tibirna wrote:
A infection hit me. So, I am not able to check things and answer much
for some days.

kind regards

Re: Color Management in KDE

By Martin =?ISO-88... at 01/22/2013 - 01:43

On Monday 21 January 2013 21:22:42 John Layt wrote:
From what you describe the supposed plugin based approach looks sane to me.
Having a D-Bus interface and a runtime dependency is the better solution IMHO.
Although KWin has color correction in 4.10 I have never been able to even test
it due to the dependency chain and my distribution not providing Oyranos but
colord is already installed (note KWin has only a runtime dependency to a
module I'm unable to build). That's quite a pity and if such an abstraction
helps to get color correction to more users it's the way to go.