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.

OpenICC Program FOSDEM 4 + 5 February 2012 in Brussels, Belgium

OpenICC uses 2012 a DevRoom at FOSDEM on Sunday together with Xorg people. The goal is to provide a meeting space for colour management topics.

The program is online on the OpenICC wiki. The talks will present and discuss colour management in Compositors, OpenICC, Scribus, Taxi DB, Oyranos and SVG2.

Oyranos Colour Management LiveCD III

The third version of the Oyranos Colour Management LiveCD is based on openSUSE-12.1 and will run on x86_64 compatible PC´s. I placed the ISO image yesterday after some preparations on the better accessible SourceForge site for download. The CD project starts into a instantly colour managed desktop, which is unique under Linux.

The ICC desktop colour correction is done by the CompICC colour server. The LiveCD contains the usual mixture of colour managed graphics applications. Among them is the colour management system Oyranos, the KDE Color Management panel, a profiler based on Argyll CMS and many colour management aware applications for drawing, colour analysis and desktop publishing. Due to package size changes not even all programs from the last release are covered. I am very sorry for that. Nevertheless I decided to include Firefox, as a very wide spread every days application. After fixing a bug in Firefox, the web browser is usable under CompICC and has generally improved regarding colour management. But still it has many colour management related issues.

The desktop widget contains some test images to help you verifying, your desktop is setup correctly and works inside all colour managed applications. Covered are some JPEG, PNG, TIFF and SVG images with wide gamut and swapped channel test profiles. You will surely spot problems, as not everything in Linux desktops is really polished regarding colour management. But these test data can help you in getting a sense of, what can be relied on and what not. You can easily include other applications into your test by installing from openSUSE. And please help the projects and report bugs to the according project bug trackers. This will show interest in the issues seen with colour management and helps developers spot current weaknesses, which are otherwise overseen.

The CD uses the stable version of the Compiz compositing window manager, which is the only one being able to run under KDE. While the Oyranos CMS is packaged in openSUSE, a full screen desktop colour correction is currently not possible with KDE´s KWin or any window manager other than Compiz with the CompICC plugin. One difference to the previous LiveCD is a better useable nouveau driver, which since greatly improved and can now launch into Compiz with GPU acceleration.

OpenICC @ FOSDEM 4 + 5 February 2012 in Brussels, Belgium

OpenICC can next year use a DevRoom at FOSDEM on Sunday together with Xorg people. The goal is to provide a meeting space for colour management topics.

Call for Talks:

So far we have one glue talk between Xorg and OpenICC, Scribus and PDF colour management, Taxi DB, OpenICC work and one about Oyranos CMS. We would be glad to see some more talks proposed related to colour management. If you think you could contribute a talk about your favorite project and user topic or get a interesting discussion rolling, then please get in contact with me.

Submission deadline is new year. We will middle January confirm accepted talks.

While OpenICC is usually much biased towards ICC ;-) , we feel obliged by the first part of our title and like to get in contact with people using other colour management standards as well and discuss all the overlapping topics. That could be movie or photography. Let´s make it happen. FOSDEM is told to be a good place for that.

Colour Management in openSUSE-12.1

The Oyranos Colour Management System will be in the upcoming openSUSE-12.1 release. With the new library users can configure their ICC profiles and settings in one central place. It brings as well a set of command line tools like oyranos-policy for handling policy configuration files and oyranos-profiles for installation of ICC profiles. KDE users can install the KolorManager package. This Oyranos front end adds a system settings control panel for individual settings adaption. But most systems will run fine with Oyranos defaults.

KolorManager is a front end to Oyranos´ settings and device configuration. It can be found in KDE´s system settings panel.

The first tab in the Settings frame contains the policies. Different settings can be grouped into a policy for easier switching workflow configurations. By selecting a policy the Default Profiles and the Behaviour tabs are updated accordingly. If you prefer a very simple workflow with all images converted to sRGB by default, then the Office policy might be right for you. Other users should select one of the quality preserving policies or the inbuilt defaults.

The Devices frame contains all detected colour devices. The currently correctly working device class is monitor. For these devices the setup of the _ICC_PROFILE in Xorg works. Applications can use this information to actively colour correct from their blending or editing colour space to the actual monitor colour space. Be prepared, that at the moment some applications might not use the system profile from Xorg. In some cases that can be changed in the colour management preferences of affected applications.

Below is a list of colour management packages in openSUSE and what they are for.

  • Oyranos – the Colour Management System library and tools
  • KolorManager – front end to Oyranos
  • ICC Examin – for looking at the content of ICC profiles and their 3D gamut
  • libXcm – parse monitor information and handle X colour management protocols
  • xcm – command line tools for libXcm
  • qcmsevents – libXcm based system applet observes X colour management events
  • icc-profile-openicc and icc-profile-basiccolor-printing2009 – high quality ICC profiles
  • oyranos-monitor – monitor command line tool
  • oyranos-monitor-nvidia – fetches monitor information from nvidia proprietary driver
  • lcms2 – high quality ICC Colour Matching Module (CMM) and command line tools
  • Xcalib – command line to upload linear curves from ICC profiles into graphics cards

More packages like ArgyllCMS, it´s front end dispcalGUI, SampleICC and CompICC can be installed from opensuse buildservice.

Colour Correction Concepts for Monitors

Colour management for the desktop is a long standing issue not only for Linux. The following text will concentrate on colour correction of monitors. This means the experience, when you switch your computer or handheld on and look on the screen.

Why colour correct the desktop?
People tend to compensate for quite a lot of different types of monitors. They are most often able to adapt to one full screen and see colours as they are intended to look like. That’s fine as long as they are concentrated on the visual event on that one display. But in this article we want to discuss how to compensate the monitor colours to our human visual needs in environments with various displays side by side, as is the typical situation for more and more people today. They take pictures with mobile phones or other digital cameras and look at them on laptops, tablets, picture frames, TV sets and printouts often side by side. Or we look at them over the internet and want to share the same visual impression with other people. Many people with uncorrected systems see quite a difference between various colour devices and try to figure out how to conveniently synchronise them. Colour management should help accomplish that task.

What is used today on Linux for colour improvements?
Different display devices feature different colour gamuts and colour appearance. We are especially sensible to the gray balance. This is a important property for our visual experience. Gray balance is since long time maintained by placing three linear correction curves into the graphics card. They are known as VCGT tag. Properly done, this helps in maintaining a equally stepped gradient from black to white with neutral shades in between. This calibration technic is fast and deployed since a long time by tools like xcalib. Calibration means in ICC terms, to setup a device driver in order to deliver a good and stable colour response. Strictly it is not part of the ICC specification. But for practical reasons it is usually embedded in ICC profiles. This basic calibration with linear curves is still in use on Windows, osX and X11 systems.

Acer Extensa 5630EZ laptop monitor

Different primary colours become more and more an issue through evolving LCD display technology. The above and below CIE shoe diagrams show quite different gamuts between the three primary colours red, green and blue of a typical laptop above and a wide gamut monitor below.

HP LP2481zx wide gamut monitor

It is generally desirable to use a screen, which is able to show deeply saturated colours. But uncorrected images show much shifted colour primaries to better cover human visible colours. Compared to traditional monitor primaries green typical becomes more cyan and red is moved toward the purple line. Of course the same RGB number triple looks quite different on booth devices. A calibration technic like VCGT linear per channel curves can not correct in any way for these saturation and hue shifts. Colours look strange not only on side by side comparisons of such devices. We need a colorimetric description of the monitor to properly colour correct the given device response.

Historically we have seen three approaches to cover the colour correction of the full screen.

  • X11 systems are colour management wise much like Windows. They predate ICC colour management and therefore have no historical APIs to enforce throughout colour correction. Maintainance of gray balance through VCGT is possible. The X11 XCMS extension was to our knowledge never in real use. Never APIs can bring a requirement for colour management. Few do today. Differences between corrected and non corrected content on one screen can be very irritating.
  • A very rigorous answer to the situation of missed colour management APIs is a fixed colour correction in hardware. But this can limit the capabilities of monitors to sRGB and thus the experience of wide gamut monitor technology not available. On the other side it provides a way to synchronise tightly controlled display devices.
  • On osX the whole rendering pipe line is colour managed. Each colour must have a colour space assigned to or it is not accepted by the systems graphic APIs. As a result all content from applications is converted on the fly by Apples ColorSync to the according monitor and looks correct. ColorSync takes over the work to bring colours from a source colour space like LStar-RGB to a native destination colour space like from a monitor. This helps programmers to concentrate on their actual task, which is most often not colour management related at all.

What is done so far to get the colour correction ball rolling?
In 2008 we started a project for OpenICC to do colour correction on the GPU on top of X11. The project allows to colour correct all non colour characterised desktop areas. Non colour characterised means by definition all window regions, except actively marked regions for opt out of system colour management. If no colour managed application is running, this means a full screen colour correction. These non colour characterised regions or areas are handled similar to other non colour characterised content. Such colours are considered to be in sRGB In the printing world for instance. sRGB is the internets default colour space. This approach is a combination of the above outlined ones and an answer to the historical X11 specifics. The advantage is, that legacy APIs and applications can benefit from a colour corrected desktop, while updated applications will be able to opt-out of colour correction. Thus a situation like on osX, with all content clearly characterised, can be reached gradually. During the project was a protocol designed for server client communication. The belonging spec is the X Color Management spec and is maintained by me over OpenICC. The spec was previously called net-color spec, but was renamed due to name space conflicts. For a smooth transition of legacy applications, the implementation of the spec in libXcm contains the xcm tool. This tool allows to set colour regions manually as a workaround. LibXcm covers just the communication protocol for applications and toolkits to talk to a colour server. The colour server, for instance CompICC, is responsible for doing the colour correction on GPU. If you want to add a colour server to your favorite compositing window manager or have questions around the spec, get in contact with me.

Can the X Color Management spec do compositing?
During a discussion on a Qt email list came out the question about compositing and colour correction. Most obviously the spec misses a freely selectable compositing colour space to do full blown up compositing. this would mean blurry region borders and other technics where transparency is involved. That is simply out of scope for the X Color Management spec. It is logical in the responsibility of the compositor to decide about the compositing colour space. Compositing window managers on Linux use today just the plain monitor colour space for their compositing. That is not perfect but seems to be good enough for simple transparency effects.  One correct way would be to meld the compositing of the window manager into the compositing of the client, which is in many cases the toolkit. But that is a bold adventure.taking the freedom of toolkits away and making traditionally modular stuff very monolithic. A architectural more sensible approach would be to use an intermediate blending space on top of the X Color Management spec. Thus the blending space is correctly selectable and modularity, interoperability and so on is much better. The toolkit can then rely on the compositing window manager to do all complicated transforms with the provided window and do colour correction as a final step. That would then essentially become a per window colour correction. From a today’s point of view the intermediate per window blending space needs a lot to do inside toolkits. It might take years to get there as toolkits just started about first steps. So the per region colour corrected desktop is still a valuable concept for today’s needs.

What is needed in the future?
Future developments have to take into account that the X11 architecture might change and other approaches become possible. The design of new architectures should cover colour management right from the beginning. With Wayland on the horizon and OpenGL-ES this is technically not a problem and would solve legacy issues like we see today in X11, on Windows and all major mobile platforms.

X Color Management 0.3 DRAFT1

The net-color spec from the libXcm repository is renamed. During a great conversation with Martin Gräßlin from KWin at oSC rwx³ he pointed out, that the _NET_ prefix is reserved inside the Xorg atom name space. So I decided to rename all atoms in the applications known to me, which use the net-color spec. The renaming went on fast and all apps work again as expected in git.

The new spec is called X Color Management. It contains the color regions in Xorg description and the used device profile for Linux desktop colour servers.
Affected are libXcm, Xcm, Oyranos, CompICC and CinePaint.

Oyranos Colour Management LiveCD II

After new second try, the driver license problem appears somewhat more relaxed. One important component needs good OpenGL support for plug and play full desktop colour correction. First choice for the OpenGL API on Nvidia and Ati hardware are the proprietary drivers from these manufacturers. For a LiveCD this did not work out due to legal reasons. The new CD can offer some basic OpenGL support to run Compiz and GPU accelerated colour conversions. The more and improving open source Nouveau driver comes to the rescue. Together with the experimental Mesa DRI it provides shader support. Some aspects work even better than the proprietary drivers, like backlight, obtaining monitor infos in a standard way through XRandR and automatic driver selection by Xorg. If you want to run on a daily base consider the Nvidia driver, as that provides power saving. It’s simply cooler.

There are some more changes like placing Krita on the CD. Krita is colour management wise a very interesting project. It supports floating point HDR images, comes with two own colour transformation modules in OpenGTL. The other new application is RawStudio. It implements the DCP spec of Adobe for DNG colour profiles. Both add to a very interesting colour software suite.

To read more about the LiveCD, please look at the old blog entry.

Oyranos Colour Management LiveCD

On OpenICC’s download area (edited on 16. February) on SourceForge is now a CD Live media available for 64-bit computers. It contains many colour management tools as available from openSUSE’s Build Service.
* littleCMS – widely used colour converter
* ArgyllCMS -1.3.0, dispcalGUI – cross platform colour management
* Oyranos – colour management system
* Compiz ICC colour server – or short CompIcc
* kolor manager – in KDE’s system settings panel
* ICC Examin – profile viewer
* Xcm/QCmsEvents – Xorg colour management event observer
* CinePaint – with net-color and other patches
* Scribus 1.3.8 – Layoutprogramm
* Cmyktool, Photoprint – imaging software
* SampleICC, IccXML – ICC sample implementation
* Nouveau/radeonhd + Mesa 3D drivers (edited 16. February)
… and more.

The CD should start on not too old nvidia graphics card hardware. Other systems are currently not support due to the requirement of a stable OpenGL driver with GPU Shader support for Compiz and CompIcc.

Once the live media runs, the desktop should appear colour managed. The trayicon, with the little horse shoe in it, should be coloured to show the colour server is correcting the the desktop. CompIcc is colour managing each monitor separately and acts on hotplug appropriately. Currently is no monitor ICC profile pre installed on the CD. So it must be generated on the fly. The colorimetry data comes from the monitor itself and contains the colour primaries, a white point and a single gamma value. This is enough to let strange primaries appear more natural, or detect a wide gamut monitor and compensate for its possibly very strong saturation.

kolor-manager device profile selection

To change the monitor profile one can use kolor-manager from KDE’s systemsettings panel. It contains as well policies and default profile selection. These settings are stored in a per user database. To see that CompIcc is working one might select the CIE*XYZ profile, with its headroom and gamma of 1.0 the monitor appearance should change dramatically. But thats only visible when the “Show only device related ICC profiles” box is deactivated.

On the desktop are three example images just for having some wide gamut media available. The two tiff files are raw camera developed images with a custom ICC profile assigned. The restaurant JPEG is in AdobeRGB as typical for some cameras. All are tagged with the respective profiles and can be loaded into the installed image tools. PhotoPrint is a very sensible application and Scribus of course. To show the whole image gamut on a wide gamut monitor only CinePaint can communicate with CompIcc to get a own hole in the screen to colour correct to the native screen colours. All other applications see sRGB as monitor colour space. Thats visible by again assigning a CIE*XYZ while CinePaint has opened a image. It will not be affected as it does not check monitor profile switching.

The advantages of complete desktop colour correct are:
* wallpapers and movies look like indented
* shopping via internet is more reliable colour wise
* content on different brand of monitor look more uniform
* wide gamut displays become useable
* non colour managed applications fall back reasonable to sRGB

Hope you can start the media. For ATI cards one further version is planed and maybe for other cards, like intel graphics, a separate version can follow.