CLT 2012 Impressions

Chemnitzer Linux-Tage was this year again a great event. The mainly german speaking visitors enjoyed a well organised fair of mixed open source community and business booths, talks and workshops.

On the Oyranos project booth discussed old friends various colour management topics and concepts. We felt that colour management terms and concepts inside the open source community are behind the awareness of other comparable graphic techniques like for instance font rendering. The more I find it amazing, that there is a core of users, which try hard to understand ICC techniques.

One topic with neighboring openSUSE people was of course the strong rose awareness around colour management during the recent discussions on the KDE core-devel list. What I found encouraging is, many people inside the KDE community see it important to collaborate. And so I think we in the OpenICC community should accelerate on our formal recommendation efforts for sharing colour data and configurations. An other related point was made, that it would be not helpful to stall projects in a too long wait for constructive discussions to come to live. I tried this sometimes and see now that balance between discussion and start for actual work could be improved. Good to get so many feedback about OpenICC core stuff in great face to face discussions.

With openSUSE’es Tom I discussed his improvements on the new open build service (OBS) search page layout, which is a great ongoing work. But much to my surprise he could point me to a nice and long wanted OBS feature, which I now integrated into the Oyranos download pages. That is, OBS provides embeddable download instructions for each distribution package of a project. These easy instructions show end users, how to install the desired software including all dependencies from OBS. Thanks for this valuable hint, which makes our colour management packages in OBS much more accessible to our users.

Looking around I found the mageia distribution interesting and would find it great to see this distribution integrated into OBS once a successful version 2 comes out this spring. But of course there are other interesting distributions out there to integrate into OBS. One advantage of OBS for me as a maintainer is as well, that I can test my packages prior to release in one go.

On the FFmpeg booth we discussed the idea that 3D lookup textures are a very simple way of exchanging colour transforms. I will surely look deeper into this and want to find a useful format to exchange 3D shader data for OpenGL textures. In CompICC a 16-bit PPM image helped for debugging. Lets see if we can find a more common and useful format to reuse.

CompICC-0.8.5 released

A new version of the compiz plugin for ICC colour correction of monitors is released. This release is a feature release.

Changes Overview:

  • new support per region ICC profiles
  • new switch to X Color Management specification
  • require libXcm-0.5.0 and Oyranos-0.4.0

Changes from 0.8.4:

  • fix alpha blending
  • speed up load time (cache the transformed pixels in memory)

The project brings you instant desktop colour correction on GPU through the compiz window manager (0.7.x/0.8.x). It supports multi monitors and live connecting. The implicite colour conversion appears on the fly. To opt out of colour correction for specialised graphics applications the X Color Management spec 0.4 is supported. Devices can be configured through the Oyranos Colour Management System.


git git://
git sha1: c963bdbc7aa4bf9703f3c87f82734d1223ff7d63
size: 76548 Byte
sha1sum: 902f2ea6b9c0aabe91297f6b80dd1f5ef9f910d1 compicc-0.8.5.tar.bz2
md5sum: 41a1a08c82ee18025d535c3dbc86aaf8 compicc-0.8.5.tar.bz2
Linux RPM:

Oyranos-0.4.0 released

The new version of the colour management system Oyranos is released. Version 0.4.0 is a feature and bug fix release.

Changes Overview:

  • new list Taxi DB profiles for a local monitor
  • new download and install ICC profiles from Taxi DB
  • fix HDMI2 XRandR EDID
  • new widget classes to image_display for per window CM
  • new add oyranos-monitor-daemon script
  • switch to libXcm 0.5.0 for X Color Management support

Oyranos is a colour management system allowing to share various settings across applications and services. The provided interfaces are the C library, native graphical front ends and partitial access through command line tools. The library is licensed under newBSD.

Known Applications using Oyranos:
ICC Examin, the KDE Kolor Manager and Synnefo configuration dialogs, the CompIcc colour server and more.


Thanks to all contributors and bug reporters.

git git://
git sha1: 97e01081831eb129cdea67c2c2b1acf23478cf8a
package: 0.4/oyranos-0.4.0.tar.bz2
size: 1265839 Byte
sha1sum: 4841e1271a24071600494fc0c1281c65b007de76 oyranos-0.4.0.tar.bz2
md5sum: 4ec2c728c5ca7d450c47d95405de3ade oyranos-0.4.0.tar.bz2
Linux RPM:

libXcm-0.5.0 released

This is a major new release of libXcm, the X11 Color Management library. The name space of the core protocol changed with the new spec.

Changes Overview:

  • switch from net-color to X Color Management specification 0.4
  • support per region ICC profile
  • add API to parse capabilities from _ICC_COLOR_DESKTOP atom
  • use autotools
  • add XcmVersion.h file
  • build under osX and Win32 without X11 and Linux specific parts

The library communicates X colour regions between server and clients, which is described in the included X Color Management spec. EDID data can be fetched through i2c communication. EDID data can be parsed for identification and access to colorimetric
calibration data. libXcm helps in observing known X11 colour management events.

Known applications using libXcm:
The library is used by CompIcc a compiz plugin for full screen colour correction in hardware. libXcm allows the plugin to support multi monitor and multiple regions per window. The Oyranos Colour Management System uses the EDID parser. qcmsevents applet observes and displays colour management events in a nice GUI. Xcm contains three command line tools for EDID fetching, EDID parsing and event observing.


git git://
git sha1: 2e1562482e2d8549db6111d401d5be7b55c5680c
size: 284884 Byte
sha1sum: ab24831a96447cb5afd04330fbd739c9bba37ffb libXcm-0.5.0.tar.bz2
md5sum: f9f3f2449cb91fbc814876653b644e13 libXcm-0.5.0.tar.bz2
Linux RPM:

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.

LGM Vienna 2-5 May 2012

The Libre Graphics Meeting is the annual event for open source creative graphics software. It greatly helps in improving the open source software stack through lots of talks, discussions, round tables, work shops and wonderful face to face meetings. There is always a great mixture of developers, artists, writers, translaters and interested people present, who come together in a very friendly and inclusive atmosphere. We had in the past always a OpenICC round table, when I was at LGM, and discussed various topics and planed around colour management. That should happen this year again with many ideas coming up.

To get people from all over the world to Europe, we need your help:


Sirko has created another pledgie:

X Color Management 0.4 DRAFT1

Some days ago on FOSDEM I gave a presentation about Colour Management in Compositors. At that point is was not very clear how to introduce colour management especially into the upcoming Wayland display server core and thus make it wide spread. The answer from Wayland developers is the same as from Xorg ones. They want a small core and colour management does not fit inside this.

As a result of a discussion between several colour management interested people from wayland, toolkits and me on the wayland IRC channel, we found a smallest common denominator. That will be a per window colour correction mechanism. The advantage is, it will be very easy to implement inside compositors and they can even start today about ICC support. The biggest disadvantage for applications is, they need to colour correct the whole window. That is as well the reason, why I did not like the idea in the past. Anyway, hopefully toolkits will jump in at one point and make that easy. Meanwhile we need to focus on example code, which demonstrates how per window colour correction can work.

The spec can be found as usual in the libXcm git repository. The main new part is the _ICC_COLOR_OUTPUTS atom and XcolorOutput structure.

Linux Printing

Colour managed printing under Linux relies on several components to play nicely together. Linux has the great lcms Colour Management Module (CMM) to parse ICC profiles and apply colour transformations based on those. The standard print job PDF can have source ICC profiles attached. CUPS knows about per print queue server side configured output ICC profiles. If feet with the correct settings by the according colour managing print filters, Ghostscript does a great job with the provided information at producing colour corrected raster output using lcms. That output is further processed by the printer driver and spooled by CUPS to the physical device.

PDF contains most often colour values defined in DeviceRGB, which is a very short way to specify some colour. And you know programmers are lazy and simply use that. So Ghostscript does a trick to colour manage these documents nonetheless and assumes DeviceRGB to be meant as sRGB, which is in this situation kind of the best it can do.

But DeviceRGB being handled as sRGB blocks practically two important use cases.

  1. Advanced application might want to do colour management early inside the application.Think of proofing and other specialised tasks done by designers and PrePress studios.
  2. Profilers, the applications which create ICC in the first place need targets to be printed without any colour correction. This case is vital to being able to setup colour management at all for new devices, media and drivers by creating valid ICC profiles. It affects owners of colour measurement devices for printers and if they publish their ICC profiles most other users too.

Fortunately there is a way to specify a output device profile per job, which is the way CUPS is designed to be used from client side. Comparably a per session based user device profile introduces a high risk to interfere with standard profile selection mechanisms and concurrenting sessions and is pretty limited in scope. The PDF/X standard allows to embed a output profile inside the document. That way all colour management is completely defined inside the PDF per job and can bypass any unwanted server side magic. The mechanism is called OutputIntent. Applications and print dialogs can use the OutputIntent in order to reliably send device Rgb or Cmyk through a colour management wise non intercepted printing path.

However, manipulation of existing PDF files is not that easy. Thankfully Joseph Simon has put some work into a project called Color-Managed Printing eXtension or short libCmpx. The library handles the harder parts of embedding a ICC output profile into a PDF/X and assists with profile selection. His primary design goal for the libCmpx library is to help enabling colour management in print dialogs. The origin of the project lays in the XCPD Google Summer of Code 2011 project for the OpenICC group.

libCmpx PDF Linux ICC colour management for printing with CUPS

ICC wants streamlined workflows

The ICC meeting from 30th January to 1th February was again a great chance to meet with colour management people in person. The meeting was hosted in Munich at Adobe with a great view over the snowy city. I joined the sessions under the OpenICC umbrella to represent the open source community.

Of course many talks went over various specification topics and coordination with other standard bodies and groups of interest in colour exchange. But as ICC is evolving, there are new topics coming up as well.

Notably, ICC is slowly moving from a solely static colour content description of what colours are. There is great interest to cover as well the process of applying colour conversions. This covers necessarily definition of terms and workflows and gets to the questions of why, how and who handles colour. This will help users to do high level decisions as opposed to the current need to understand low level technical ICC terms and figuring out how that applies to actual used implementations.

I presented my work inside OpenICC to add monitor identification and calibration state information inside ICC profiles to streamline profile distribution and installation. The concept found support and the presentation about the meta tag keys came along nicely.

ICC members dive currently into spectral imaging, which is prototyped in SampleICC. I appreciate this direction, as it very likely simplifies the use of spectral readings for colour calculations in applications.

The only discussed hint to reduce the size of n-channel profiles, was work on how to put formulas inside the colour processing pipe. It would be great if that comes to a useful result. Formulas inside ICC profiles where first introduced during the v4 specification but only apply to single channels. For per channel operations are currently some few formulas supported. However the new approach allows to express with more elementary operations and allows free access to all channels.

Obviously many members have a strong background in printing, which is greatly reflected in the spec. But some companies have a strong relation to various imaging industries, like camera manufacturers, who as well create printing or displaying devices. There is potential, that ICC will support their interests, provided they actively contribute. For instance ICC profile embedding inside images is well covered inside the ICC spec. That was a good base for e.g. the W3C to introduce colour management for photography on the net. There is no equivalent to movie or video content. In parts embedding of ICC profiles there does not even exist.

Altogether, the ICC meeting was a great chance to coordinate and intensify the work of ICC and OpenICC.

Quality of Default ICC Profiles

On the internet are many places to download ICC profiles, which promise to implement standards. But how reliable are these profiles and why should users and distributors care about their quality?

Why quality counts? For many users is real value in reliable colour space definitions. Most professionals and advanced amateurs know that wrongly implemented colorimetry can cause them unwanted modifications and will sum up over repeated conversions and colour space assignments until the error has rendered the colour material useless. But profile conformance to the standard, which these profiles claim to represent, is not so obvious. A profile checker can only detect conformance to the ICC standard itself, which is about the file format, but not about the quality of the encoded data.

The preferred solution for professionals is to download ICC profiles only from trusted vendors. Unfortunately for the open source community, most ICC profiles for common standards are restrictively licensed and allow no modifications. However these licenses are a reaction to people, who want to push stuff at whim and fake profile names. After all spreading low quality fakes will mostly harm users. Such faked profile made it in many open source packages. It would help the open source community, if vendors license their ICC profiles for standard conditions after the new non restrictive ICC profile license. Then faking profiles, by the reasoning of providing them under a free license, would not be needed any more.

We have some free and accurate profiles available. Over the past years colour experts have created precise profiles with a free license. Among these profiles are implementations of sRGB, AdobeRGB spec and after a license switch for LStar-RGB and many standard printing conditions. These profiles are packaged in the icc-profiles-openicc data set.

How to check ICC profiles for standards?One indirect method is comparing reference ICC profiles with alternative ones. A visual comparison is possible on Linux with the free CinéPaint and the separate ICC Examin plugin in CIE*Lab space. The above video compares visually the ROMM ICC profile, which shares its colorimetry with ProPhoto RGB, with the Scarse ProPhoto.icm. The Scarse colour value interpretation shows quite some deviation from the Adobe version. To repeat the test: open a test image and assign the ISO 22028-2 ROMM RGB profile. Then open the ICC Examin colour viewer from CinéPaint´s main menu > Image > Watch Colours 3D … The plugin should launch and show you the colour space with the image colours represented as big dots. You can change the dot size in ICC Examin with the ‘+’ and ‘-’ keys. Then assign the Scarse Kodak ProPhoto RGB to the image from main menu > Image > Assign ICC Profile …  The colour dots change to the new interpretation by the lcms CMM after assigning. A unwanted deviation in the interpretation is marked by a line. That visual method of inspecting line vectors is much easier than comparing colour differences directly. Possible rendering intents for these kind of comparisons are relative colorimetric and absolute colorimetric, as these are well defined by the ICC spec. Disadvantages of the outlined method are the need of reference profiles in the first place and so far no numerical results.