KDE End to End Colour Management

The last blog posts about KDE and colour management might have been irritating about what actual happens on colour managed desktops. Here come some clarifications and thoughts from the Oyranos CMS maintainer. The project name starts with Oy (Oyranos like sky), hence my nick oy on IRC ;-)

Colour Management Systems (CMS) are a precondition to do colour correction of input and output devices. But this is not sufficient for having a colour corrected desktop. The claim was made, that Gnome is the first colour managed desktop on Linux. But Gnomes window manger mutter has no means to use ICC profiles. The same is true for all other window managers with an exception of old Compiz. A CMS selects only the needed ICC profile and does the configuration in that field. But the background, applications like the dock and most others are not colour corrected by standard ICC profiles mechanisms in Linux. The only thing users can do since many years on Linux is to do monitor calibration setup per single channel. This helps for better grayscale, but not for compensating of colour gamuts. Calibration is only a first step, but not sufficient for ICC colour correction. So Gnome users have today no colour corrected desktop like all other Linux users.

What is needed to get to a End to End colour corrected desktop in KDE? A more general Overview can be found here.

  1. KWin needs ICC support, in order to colour correct the KDE desktop in a reasonable time frame. That will help with the output side in a fast way by using the GPU during compositing while using few resources. If you feel it is time to do something, here is a  Google Summer of Code CM project idea for KWin. With my experience from the CompICC project, I would be glad to help any such project.
  2. An other project I would find really helpful is to provide colour correction to KDE’s primary image viewer gwenview. If people could help with a hackfest, that would be cool. We have such thing in mind and some ideas about, maybe you like to join us.
  3. Qt/KDE needs to explore how to do own fast colour correction of a complete window to be prepared for the future. Here are two project ideas.
  4. OpenICC did investigate to get print colour management right. There are currently two approaches who are promising. OpenICC has one project idea to introduce colour managed printing into Krita and one for user profile setup for colour managed print queues with KolorManager. These are two complementing, maintainable and robust paths for getting printing CM right.

Now some clarifications about Oyranos itself, as in the kde-planet where many wrong statements transported intermixed with half true claims.

  • Core is a toolkit independent library
  • KDE, Qt and FLTK front ends exist like KolorManager. Other native ones are possible.
  • The Elektra API and library is used for format independent configuration DB access.
  • Oyranos is planed to switch to a OpenICC JSON DB format to converge with ArgyllCMS and other interested CMS’es
  • Oyranos is a cross platform project
  • A DBus API would be welcome on top of the basic library but not in its core
  • Oyranos forces no one to use the CPU or prohibit to use the GPU :-D
  • The CMS provides means to do optional multi monitor colour correction and other conversions.
  • CompICC uses Oyranos and does colour correction on the GPU
  • Oyranos developers belief in collaboration :-)
  • Self containment in Oyranos results from adhering to and work on interoperable standards.
  • User configurations belong to users in Oyranos, so it needs no special root rights, which exposes security and privacy risks.
  • Oyranos provides optional policies for grouping single settings. That is a additional feature not a limitation.
  • Oyranos uses many advanced automatism’s to do it’s work successful
  • The CMS is designed to work with default settings.
  • Advanced manual configurations are supported and part of Oyranos’ user centrism.
  • Oyranos cares about quality and requires a careful selected and peer reviewed profile set that comes with no Fakes and no wrong colorimetry.
  • Licensing fits most open source and commercial projects with a newBSD style license.

Choice is a good thing for users. As a CMS author I have no problems, that an other CMS comes to KDE too on Linux. Many Linux CM standards I initiated or helped with allow for such interoperability, which is in the spirit of the ICC standard.

An other Open Source Colorimeter

Richard Hughes, the author of colord, developed in the recent months new hardware for measuring monitor colours. The ColorHug called device shall come at a relatively low price. It shall be useable for LCD/LED monitors providing input to calibration and profiling software. The most wide spread open source colour management system, which can create ICC profiles from colour measurements, is Argyll.

ColorHugThe author Richard Hughes states on his blog entry: “Existing hardware is proprietary and 100% closed, and my hardware has a GPL bootloader, GPL firmware image and GPL hardware schematics and PCBs”. The “100%” is a wrong marketing claim as Richard Hughes should know as Argyll user. However the new device fits nicely into a row with prior open source art in colorimeter hardware like the HCFR. The HCFR is supported in Argyll since some years now. To make the new ColorHug device functional, it would be great, if the hardware author could deliver a module instantly useable in Argyll.

What would now be interesting is to know, how the new device will compare with pre existing ones, being them proprietary or open source licensed hardware. The author gave a hint about speed. But speed is only one property useable to reduce noise in dark readings. Much more interesting is colour accuracy.

What is colour accuracy and why is it so important for a colorimeter like the HCFR or the new ColorHug? Colorimeter devices suffer almost all from a difference to the ideal colour reception of human eye, especially the cheaper ones. Only spectrometers can compensate better for that effect of non perfect filters in front of the actual light sensors, but expose other disadvantages. Colorimeter devices, which perform close to human sensibility, are usual expensive. Some are even more expensive than colour spectrometers. Colorimeter manufacturers use a common trick and put a correction matrix inside the device, which shall compensate for the difference between the sensitivity of human eyes and the colorimeter. But many users complained not to be able to get good results despite. This is easily understandable, as monitors emit light with very different spectral characteristics, which do not match the used filter in the colorimeter and its matrix. One approach to get better results is to use a per monitor model compensation matrix. Fortunately Argyll has implemented compensation matrices in one of its recent releases. The requirement for this approach to work is, that the data base needs input data from users.

Scarse Profile Library Warning

Scarse is a project for profiling scanners under GPL based on Argyll code. It started in the old century and became pretty silent, with the last news dating from 2005. The project provides a nice collection of ICC profiles in the Scarse Profile Library, which is now used by some open source graphics packages. ICC profiles referring to standards are used to describe the exact colorimetry of a colour space. The ICC profiles are used to convert to and from other colour spaces in order to exchange with applications, services and customers. It is therefore crucial to meet these standards otherwise results will be incorrect right from the beginning and might render further colour work damaged.

Claudio Wilmanns revealed today a colorimetric imprecision inside the Scarse WideGamutRGB profile. Norman Koren hinted that the Scarse profiles do not pass a profile validation tool. OpenICC could never verify these profiles or how they where build and therefore did not cover any of them in its icc-profiles-openicc data set.

After these comments I like to warn of the usage and distribution of any of the Scarse Profiles for the sake of users trusting profiles of the affected packages in their workflows. We are looking for replacements for some of the most popular ones.

Affected Profiles are AdobeRGB, AppleRGB, WideGamutRGB, CIE-RGB, ECI-RGB, sRGB, KodakProPhotoRGB, ColorMatchRGB and more.

Affected Packages are libkdcraw. Some of the shared-color-profiles/Argyll ‘lcms’ generated profiles from the colord author use in parts the colorimetry of Scarse profiles. The later profiles are not included in the Argyll-1.1.0 source package. These profiles are at risk.

Disclaimer: the author, Kai-Uwe Behrmann, maintains the icc-profiles-openicc package containing ICC profiles describing colour standards.