[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Color Management in KDE
From:       John Layt <jlayt () kde ! org>
Date:       2013-01-21 21:22:42
Message-ID: 3997177.NTlG1H5UKE () ithaca
[Download RAW message or body]

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

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.

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.

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.

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

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

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

Thoughts?

John.

[prev in list] [next in list] [prev in thread] [next in thread]