Image Editing with 30-bit Monitors

Payable hardware for professionals is capable of 30-bit throughput since quite some years. And costs continue to go down. This means even budget setups are possible with this kind of gear. So lets follow the question why, who and how monitors capable of displaying 30-bit alias 10-bit per red, green and blue channel can be used. This blog article will first touch some basics, followed by technical aspects below.

Why is it useful to display graphics on a 30-bit monitor setup?
It is essential for graphical editing, to see what effect a editing step has. It is pretty common that low resolution monitors impose a barrier to reliably predict the intended output. This is true for geometrical resolution like for colour resolution and for gamut. The rule of thumb is, the graphics editor needs the most information available to do here/his job and spot artefacts and issues early in the process. This principle is deployed for print, web, film and video editing to reduce costs. You know, redoing something costs time and is part of the jobs calculation. More image information means as well more certainty to reach a graphical result. The typical artefact caused by low colour resolution is reduced tonal range. Colour conversions can reduce the tonal range further. So a sRGB image will look different on a 8-bit per channel monitor with a native gamma close to 2.2 compared to a pipeline with 10-bit per channel. The 8-bit output imposes a bottleneck resulting in loosing some tonal steps known as banding, which must not necessarily be present in the observed sRGB image. One very often read argument against higher bit depth is, that editing hardware shall be as close as possible to customers ones. But that is a illusion. The wide diversity of media and devices makes this nearly impossible. But simulation of end customer hardware is of course an issue and many graphics software has implemented simulation capabilities to address that concern.

Who is most interested in 30-bit colour editing on Linux?
Graphics professional and ambitious users closely observe Linux since many years and deploy it. Many block busters are produced and rendered on Linux machines. Web graphics is well supported since years and camera raw programs implemented a impressive level of features in the last years. So Linux is a potential content creation platform beside content consumption. The typical work flow for content creating people is to generate and edit their art work in high geometrical and colour resolution and down convert to lower resolutions as fits for the job, be that web, print, catalog previews and more flexible high quality delivery depending on actual contract. For instance many photographers archive their shootings in the cameras native format to preserve all available information for later editing or improved rendering. This is a important investment in the future for non short lived work, where old files can shine in new light. Motion picture productions are often rendered and color graded in floating point space by using the OpenEXR intermediate file format and output to 12 bits per component for playback in a cinema. Video production uses in parts raw workflows for advertisements. Medical-, scientific- and archival imaging are potentially interested too and require in parts 30-bit setups like in the DICOM standard. The benefit of 10-bit per channel versus 8-bit does not matter to everyone. Most consumers will not spot any difference while watching web video. But in more demanding areas it is a small but helpful improvement.

How to deploy 30-bit displays on Linux?
That feature was implemented by several companies starting on low level software components like X11, Cairo and pixman. However desktops where pretty slow to adapt software to the new needs and fix bugs. That was in part of the initially higher costs for the hardware. Only few developers in the open source community had early access to suitable gear. I do not write here about suitable graphic cards and monitor combinations. You should consult the web for this. Search for 30-bit monitor. Many early adopters observed psychedelic colours, not working graphics areas and more. Here the state on the well known KDE X11 desktop in release 4.11 on a openSUSE-13.1 . The login screen colours are broken. The splash screen after login looks correct and after some period the desktop becomes visible with again broken colours. To manually fix most of that, one have to tell that Qt shall use native colours. Create following text into a file called ~/.kde4/env/ .

$ kwrite ~/.kde4/env/


With the above variable the desktop should look reasonably in KWin, which is really great. Automating that in Qt would be appreciated.

However 30-bit monitors typical aim at high quality setups. Beside colour resolution they often enough offer a wider gamut than usual monitors. This results in partially heavily saturated colours, which burns in sensible eyes. Those people who do colour grading or photo editing are mostly affected, otherwise they can not easily play this work. So desktop colour correction is an other important feature to enable here. KWin supports ICC based colour correction through KolorManager, which would be useful for the colour saturation. But KWin disables all effects for 30-bit OpenGL visuals. The alternative Compiz-0.8 series has the CompIcc colour server plug-in, which provides the same ICC colour correction feature. To make use of it, one needs to install following packages: compizconfig-settings-manager, CompIcc-0.8.9. Unfortunedly the KDE decorator is no longer available. So use the Emerald decorator from X11:Compiz with the 30-bit-shadow.patch in order to avoid artefacts in the shadow code. Compiz can be used as a default window manager application. Use the system settings to switch to Compiz. Use ccsm to switch on Color Management if not done automatically. And voila the 30-bit desktop should be ready to explore.

What works and what not?
The Plasma desktop is fine including all menus. Dolphin, KWrite, and other applications work. Thunderbird shows some artefacts due to not properly supporting the R10G10B10A2 pixel format. The same is true for Firefox, which lets in parts shine through content behind the Firefox window. Gwenview and ShowFoto work fine within their 8-bit drawing. Only the preview is broken in ShowFoto. Krita supports with the OpenGL backend even native 10-bit per colour component. Menus in Sketch are black. Krita shows minimal artefacts through twice colour converting from image to sRGB by Krita and from sRGB to the monitor colour space by CompIcc. But this effect is much lesser visible than the improvements through its 30-bit support. Applications which try to code 24-bit colour themselves are broken like Konqueror. Gtk and hence Gnome applications with graphical areas do not work. They show black areas. VLC works fine. So daily work should be fine in with 30-bit in the KDE application family depending what you do, with some minor glitches. Valuable Gtk applications as is like Inkscape and most Gtk applications are unusable in a 30-bit setup, with Gimps drawing area being a exception. Thunderbird/Firefox are guessedly affected by the same Gtk bug for which a patch was created some time ago. A patched libgtk-2 is available for testing on openSUSE, which appears to have fixed the problem almost for me.

Beside the need to exchange a windowmanager, to patch a few components and do some manual settings, Linux appears almost there in support of 30-bit setups. Polishing of that feature needs testing of patches and finally acceptance for distribution. Your feedback about bugs, tests and patches can make a difference to developers.

Magic Lantern @ LGM in Leipzig

… on Wednesday April 2nd. Their talk will begin 18:30 o’clock local time in the New Paulinum of the University of Leipzig.

Magic Lantern was started in 2009 by Trammel Hudson to bring professional video recording and advanced photographic features to Canon EOS DSLR cameras.

The project expanded and its feature set. Custom video overlays, raw video recording, time lapsed video, manual audio control and more belong to it. With these tools Magic Lantern greatly improved useability in many areas upon bare Canon firmware and is now daily used by many professional photographers, journalists and movie makers.

Movie LUT’s inside ICC Profiles

Krita, a painting application with high dynamic range (HDR) support, is in the planning phase for the next release cycle. One hot topic is currently the discussion about what can be done to make movie makers even more happy. A good candidate is the marriage of film industry colour management with Krita’s inbuilt ICC style colour management. But Krita maintainer Boudewijn Rempt expressed surprise about movie style colour management in other apps.

This post tries to compare how both colour management worlds work and how they can better fit for the advantage of each other.

The ICC format standard is for its most popular flavors designed as a characterisation of one colour space conversion in reference to the standard observer colour space or in ICC terms the PCS. That allows a very flexible combining of ICC profiles from many different devices into colour transformations and is one of the basic principles of the ICC standard. The advantage of using existing ICC workflows is, that tools for on the fly monitor colour correction are almost all ICC based and well understood.

So, how does the movie industry currently define colour spaces in their workflows?

In short, film colour spaces are characterised by standards and not by ICC profiles. On a technically level the involved file formats use pretty much the same basics. That is, curves and 3D tables, which are available inside the ICC foraremat as well.

However colour tables of movie makers, called LUT’s, are very closely related to the intended usage during film production. These LUT’s can combine a colour space conversion from a source colour space: typically a linear gamma floating point encoding toward a final display.

A simple colour conversion with just two ICC profiles would not adequately represent how a good movie picture should look like. So adding of scaling curves is needed, to obtain a tonal representation of  brighter than white parts of a scene. That part can include logarithmic scaling or other methods. An S shaped gamma is sometimes used to get a closer to film look of the footage output and possibly more tricks are used to create a pleasing colour output. And last but not least, the simulation of the intended output device, as in a typical cinema, is most often baked into film production LUT’s.

So a LUT contains the original source colour space and many additional ingredients. Movie makers have searched for ways to use their LUTs inside traditional ICC colour managed software: in one approach, they simply placed the LUT inside a ICC profile and could use the LUT’s in more software, typical as a proofing profile. A proofing profile is a normal ICC output profile describing the colour behaviour of a single devices. For film makers that is pretty much the way they use LUT’s anyway: as colour conversions in their workflows.

The approach of LUT baking into ICC output profiles is semantically not a good fit. However, there exist two other not so well known ICC format flavors, which could be far better deployed in order to support film LUT’s style colour conversions.

The one which comes technically closest to a film LUT is the “device link profile class”. A device link profile represents a combination of a complete colour transformation over a arbitrary number of colour spaces and manipulations into one final colour profile. As input and output colour spaces are included, a device link profile is pretty much a fixed thing like a LUT. But that means, it completely misses the flexibility of normal ICC profiles: that is the ability to get combined with different devices in an almost automatic fashion, with little user interaction if at all.

Another ICC profile type candidate is the abstract or effect style” ICC profile. These profiles can be used to simulate a device, do a colour manipulation or a combination of different conversions. The big advantage of the “abstract or effect profile” class is the very common PCS reference for the input and output side. So these profiles can easily be chained between a input colour space and a monitor device profile.

Baking movie LUT’s inside abstract profiles instead of device profiles would work more nicely inside ICC style workflows. Then, applications which support effect profiles can simply select the right effect LUT without touching a source colour space or even the monitor profiles, which would, among most people familiar with ICC style colour management, be considered a hack, and with reason.

The idea of using abstract profiles inside a painting application is not new. It was demonstrated around 2004 inside the CinePaint open source application. The abstract profiles were, for convenience, called “look profiles” inside the UI. CinePaint allowed users to chain “look profiles” and comfortably enable and disable them in order to see their effect.

The “look profiles” where used on the fly, without touching the image colour space. It was also possible to apply “look profiles” irreversibly and persistently to a image. The decision for CinePaint’s “look profile” workflow was directly inspired by movie studio needs.

At the time the underlying lcms library supported only 8 and 16-bit per channel. With the upcoming half floating point support in lcms, the “look profile” workflow starts soon to make sense as well for OpenEXR images. Lcms implemented further support of floating point elements inside ICC profiles to meet higher precision needs of the film industry. It will be interesting to see how this can be utilised.

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.

OCIO 1.0.1 released

Jeremy Selan released a new version of the open source color management library OpenColorIO.


  • simplification of ocio2icc / ociobakelut
  • bug fixes

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.


Google Summer of Code Mentors Summit 2011

Last week end from 21th to 23th October mentors meet in San Francisco / US to share our experiences in organising and mentoring students during Google Summer of Code 2011, talk about open source projects and of course get in contact with other teams and meet in person. The Mentors Summit was well organised and it was fun to be there. It was my first time in the south of North America. So chances where good to meet new people.

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.MountainView Google Summer of Code Mentors Summit 2011

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