Color Management in KDE

[Kai-Uwe Behrmann]

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:
> Hi,
>
> 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.
>
> TLDR
> ----
>
> 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
> config
> * In KDE4 app devs can still choose to use the Oyranos abstraction api if they
> want
> * Eventually Qt5 will gain full native support and we won't have to worry
> anymore
>
> 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

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.

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

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.

> 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

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.

> * 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.
>
> Intro
> -----
>
> So what is color management?  Here's my simple and probably wrong
> understanding.
>
> 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.

For the difference of calibration versus characterisation:
http://www.argyllcms.com/doc/calvschar.html

A ICC profile contains primarily a characterisation.

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

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

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

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.

> * LCMS/LCMS2 and ArgyllCMS are the most commonly used FOSS CMM's.
> * Oyranos and colord are the two CMF implementations on Linux.

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

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

SANE-backends-1.0 (e.g. libsane.so) 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.

> * 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
>
> Oyranos
> -------
>
> * 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

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.

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

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 libcolord.so shows a hard dependency to 
liblcms2.so .

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?

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

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.

> 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

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.

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

> 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
> shared.
>
> Until the config is shared an interim solution might be for KolorManager, the
> Oyranos config tool, to write the config to colord as well?

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.

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

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.

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

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.

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

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

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

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.

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

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

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

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

> Thoughts?
>
> John.

kind regards
Kai-Uwe Behrmann
-- 
www.oyranos.org