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/qtnative.sh .

$ kwrite ~/.kde4/env/qtnative.sh

#!/bin/sh
export QT_GRAPHICSSYSTEM=native

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.

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.

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.

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