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:

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.

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.

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.

IccXML provides a library and tools to convert between ICC profiles and XML in both directions.

SampleICC release obtained up to the actual revision 1.6.6 various bug fixes, build system improvements and the new iccGetBPCInfo tool.

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.

Changes:

• Updated to ICC spec 4.3
• Added compatibilty with Argyll’s CGATS parser

As I wrote in my recent post, Firefox has many colour management bugs and one is of special concern toward the Oyranos Colour Management LiveCD III. This bug is now reported upstream and I proposed a patch to fix. It is double color correction with X Color Management, which is in close relation to Hal V. Engels report about Firefox color management does not honor _ICC_PROFILE X11 atoms. It affects all X11 builds and inhibits automatic selection of the system ICC monitor profile. A properly detected system monitor profile in Firefox will show default sRGB colours as well as images with ICC profiles much more in line with other colour managed applications. Getting this bug fixed is a major improvement for presenting colours on the web for Linux.

But why is this bug of so strong concern especially for the Oyranos LiveCD? The CompICC desktop colour server, which is part of the CD, uses sRGB as the assumed document colour space of all non colour managed content on screen. It needs to fool all non X Color Management spec aware applications to think the monitor is exactly in sRGB as long as they do not register with the colour server. In the sense of the X Color Management spec only that content, which is registered through specific per window colour regions is honoured to be colour managed and can use the monitors device ICC profile. This way applications like Inkscape, Krita or eog stay upward compatible and continue to work. However Firefox is not able to fetch the sRGB profile due to the above mentioned bug and falls back to a otherwise clever ICC from EDID generated profile. But Firefox colour corrects under Xorg to the from EDID profile and after that already done compensation assumes CompICC the Firefox window to be in sRGB and colour corrects to the actual setup monitor profile, which might be a from EDID generated profile as well, which leads to double colour correction. The fix of this bug lets Firefox detect the correct system profile. Double colour correction can happen as well if the monitor profile is explicitly set in the client application. So use always the system profile. Setting the system profile is really the job of a CMS like Oyranos.

As I read the code, Firefox honors embedded ICC profiles in JPEGs and PNGs. Great. These bitmaps works even in bitmaps inside SVGs, which is wonderful.

In recent changes Firefox can even handle v4 ICC profiles. These profiles are created by newer ICC profilers and became in recent years pretty widespread. But v4 profiles are not supported by default in Firefox. You need to enable them manually in Firefox´ configuration tab.

The situation for pure vectors graphics in Firefox is not in the same level as with bitmaps. The HTML/CSS color_profile element is completely ignored.

Conclusion, Firefox has after the proposed patch the ability to show with its internal colour management comparable colours of bitmaps like most other colour managed applications.

How to deploy the ICC capabilities of Firefox beyond the WWW´s sRGB as a web artist? You can place JPEG and PNG bitmap images with embedded ICC profiles inside web pages. An other way is to place such images inside SVG. While the freely available SVG editor Inkscape will not show a colour corrected preview of these images, it will not touch the JPEG and PNG images, so Firefox can render them correctly by the SVG standard.

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.

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.

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

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.

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.

For KDE exists the KolorManager systemsettings panel for configuring a ICC profile per monitor device. It´s Oyranos CMS cares as well about setup of standard Xorg _ICC_PROFILE(_xxx) root window atoms and video card graphics table (VCGT). The later is a one dimensional per channel colour correction feature. So expect no magic all included solution by this means.

The heart of today most wide spread colour management systems is the ICC file specification. And to get ICC style Colour Management working inside KDE, the framework has to handle several needs.

One is to provide a overall desktop colour correction, which applies to the whole monitor screen area. A Desktop Colour Server will improve the overall Desktop usability and appearance in heterogeneous  environments like Linux. Obviously colour measurement devices and early colour correcting applications need native access to the monitor colour space. The currently only full featured and backward compatible implementation of that scheme for Linux is the CompICC plugin to Compiz. The CompICC colour server assumes sRGB for all input. Output target is the actual monitor profile set e.g. by KolorManager. More details can be read in a older blog post. Given that colour servers are still pretty rare, only osX and CompICC provide that, it might not be a good goal for the foreseeable future to let all applications rely solely on that feature for their colour corrections. But it has the potential to the most slick and flexible desktop colour experience.

On the Input side ICC profiles and according Exif meta data need to be detected from the input streams and get appropriately assigned as ICC meta data to graphics objects. That can be application specific but is a very common task, which will be better implemented on the toolkit or framework level. The display component should then make use of this ICC meta data and do on the fly colour correction. As well file output needs support of embedding the ICC profile data back into the data stream.

Alongside the ICC data handling come options and preference management, which is covered by the KolorManager GUI to the Oyranos API.

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.

Changes:

• simplification of ocio2icc / ociobakelut
• bug fixes

About:
Based on development started in 2003, OCIO enables color transforms and image display to be handled in a consistent manner across multiple graphics applications. Unlike other color management solutions, OCIO is geared towards motion-picture post production, with an emphasis on visual effects and animation color pipelines.

Download:
Github

The VLC and FFMPEG people where interested in colour management. I tried to give them some idea, what colour managed applications need to know about media streams. It seems, that awareness rises about colour management in the open source video community, which is wonderful.

Two members of the Scribus team where present, Peter Linell and Malex. We could discuss quite some topics around distributions. It was great to meet them both.

The Open Source in Visual Effects was missed be me due to a swapping of rooms. Luckily Peter knew the OpenColorIO author and we could get in contact in a small four people meeting. We discussed Linux colour management, distribution and the relation of movie picture to ICC style colour management. Jeremy Selan pointed out the very difference of HDR scene referred imagery compared to the style of HDR which is typical in ICC workflows. I could convince Jeremy to look at the ICC floating point extension and it’s two open source implementations. He was interested and might work on implementing that in OCIO too. If that happens, it would be a great step toward joining movie with still graphics workflows. In the past the issues around round tripping and HDR handling had lead to the decision of movie studios to develop own colour management systems. OCIO supports already the export of colour correction tables to ICC profiles for use in photo and paint applications, which traditionally feature ICC workflows. Once the input side through ICC profiles is implemented in OCIO the same library could be used as a CMM inside ICC and movie workflows.

Thanks to Google and its OPSO team for sponsoring and organising a great event.

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.