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.
Do you know that telling people to use QT_GRAPHICSSYSTEM=native has worse performance than raster (default) right?
Is that really the only way to achieve this?
Can you provide numbers on “worse” or describe it?
There were a few posts in 2009 that had numbers, but since raster was better it became the default over the previous native.
Understanding why it’s fast is quite easy, you look at why there is Wayland and pretty much the same applies, X11 does lots of round trips with the app when doing native, while on raster it works like wayland where you just send the whole surface rendered and avoid talking too much with X.
You can still find on google posts like “How to drastically improve your KDE speed by using raster”.
So while you get 30bit you loose the speed, best would be for raster to do it right.
Some feedback from a 30-bit setup. I see indeed some slower effects in plasma. But on my desktop system it can be neglected. Working and video speed are sufficient.
Maybe for gamers more would not hurt. But I am not a gamer, so cant speak for this demanding user group.
Given that 30-bit requires a generally well performing graphics card, I guess that a native versus raster plasma desktop is a much smaller issue for most 30-bit demanding users.
What is worse is that native isn’t supported with Qt5, so some work will need to be done to make raster work in with 30bit depth. Though I wonder if we can’t just tell X11 that the output is 24bit.
This looks like a good topic for the Plumbers conference. Are you planning to come?
Dont know which session it could fit. For a full length the toppic is too small.
Pingback: Links 23/5/2014: Linux 3.15 RC6, KDE Previews | Techrights
Compiz/Emerald has merged the proposed workaround in master:
http://cgit.compiz.org/fusion/decorators/emerald/commit/?id=3bf1edb8b9a3efe8accfab3c5810647d84af9ef3
Here is the fix for the raster graphicssystem, at least it works on my system: https://codereview.qt-project.org/#change,86193
Great. Do you have a link to the plain patch? Thanks
Hi
I would like to thank the author for the article. The text is a good summary of the spread but marginalized subject which has been appearing since 2009 (2007).
Because of problems occurring in 30 bit color configuration, it would be nice to work out x server configuration per user account.
It would be very useful to have a separate account for graphic work, and another one for ordinary uses.
Has anybody got experience in this matter?
Thanks
Anybody could test darktable? (It can open also tiff files, not only RAW.) I have asked on its mailing list, but nobody has confirmed it yet.
darktable-1.2.3 can read jpeg, png and tiff images. But no ICC profiles where detected by darktable in opposite to Krita, ShowFoto of DigiKam or Gimp. Eog and Gwenview can read ICC profiles at least from jpeg and png files. All tested on a 30-bit display with a patched libgtk-2.
Thanks for testing. The missing support of embedded ICC profiles for non-RAW images has already been reported to dt bugs.
Coincidently, the bug was fixed few hours ago:
http://darktable.org/redmine/issues/10040
Instead of installing -dev version from git, it should be enough to activate “input color profile” module (right pane, in the bottom) and set it manually — just for the test purposes.