The last days I played with lcms‘ unbound mode. In unbound mode the CMM can convert colours with negative numbers. That allows to use for instance the LMS colour space, a very basic colour space to the human visual system. As well unbound RGB, linear gamma with sRGB primaries, circulated long time as the new one covers all colour space, a kind of replacement of ICC or WCS style colour management. There are some reservations about that statement, as linear RGB is most often understood as “no additional info needed”, which is not easy to build a flexible CMS upon. During the last days I hacked lcms to write the mpet tag in its device link profiles in order to work inside the Oyranos CMS. The multi processing elements tag type (mpet) contains the internal state of lcms’ transform as a rendering pipeline. This pipeline is able to do unbound colour transforms, if no table based elements are included. The tested device link contained single gamma values and matrixes in its D2B0 mpet tag. The Oyranos image-display application renderd my LMS test pictures correctly, in opposite to the 16-bit integer version. However the speed was decreased by a factor of ~3 with lcms compared to the usual integer math transforms. The most time consuming part might be the pow() call in the equation. It is possible that GPU conversions are much faster, only I am not aware of a implementation of mpet transforms on the GPU.
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
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 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.
In presentations I like to use colourful graphics. Some of those graphics are generated automatically by the Cairo based oyranos-profile-graph 2D grapher tool. In git that tool obtained a option to show black body spectra based on kelvin. The spectra are scaled for better illustration.
Some other work in Oyranos went on with the device mapping to JSON serialisation, as is useful to store device configurations using the Oyranos API. Through JSON files it is possible to support new device classes without to worry about creating a native Oyranos device module. The basic idea is to let users bring in a OpenICC device description and a weighting description. Oyranos is then able to find matches inside its DB and weight the resulting properties according to the provided weighting file. The example code is inside oyranos-test-device and needs still some polishing to become a stable tool. For instance more integration with the frontends and UI parts is needed, to make sure everything gives a nice user experience. Raw images can now be rendered better in image_display and do not show the artefacts from table based conversion of linear camera space to gamma encoded monitor spaces.
During spring 2013 I decided to abstain from public activities and paused coding completely. After some months I was mentally able to enjoy work on self contained stuff. That was first without any community involvement. Months later I contacted some people to explain that situation and want to thank here all those friendly souls who directly encouraged me. After what happened in the last years, I learned, that it can be pretty healthy to not to stay in public light and become involved in highly controversial discussions. Especially the later can become easily burning. As a result of that personal lesson, I skipped 2013 LGM and other meetings and outside activities. Now after around 9 months I feel really better and hope to become slowly more involved. Still I am learning how to keep others opinions at arms length. And that lesson appears key for me to stay welcoming and focused. Well, time will show how well .
Oyranos supports Elektra-0.8.4 in git as a result of friendly behind the scene discussions later in 2013. A new image filter, called “scale“, is currently used inside the image-display example viewer. It does so far no interpolation, but it might become useful for other applications as well, in order to select only a subset of unaltered image pixels. ICC named colour list reading was added. More changes happened around documentation, building external modules and use of threading inside the image-display application.
After Richards recent patch about adding a colour management system to wayland, I was interested to build a Oyranos CMS connection module for wayland. The patch is in a initial stage, but might get to a similar level like what is already in CompICC and KWin colour servers.
First I substituted all openSUSE-12.3 distro packages with the adequate packages from tobijk and obtained a version 1.0.6 . Keeping the distro Mesa package resulted in a missed EGL Wayland extension and some crashes. On the Wayland website are some instructions on how to setup the environment. Especially the XDG_RUNTIME_DIR variable needs attention. I skipped the part of adding a special weston-lauch group and run the application simply by root. However the a symbol in cairo was missed “cairo_egl_device_create”. After cloning and building pixman and cairo following the Wayland instructions everything went fine. Here a simple ~/.config/weston.ini file to start with:
Weston launches on my system into a multi monitor setup with nouveau. There is still heave tearing, while moving the terminal. After Strg+Alt+Entf (Ctrl+Alt+Del) weston quits.
Firefox detects since version 17.0 the Linux system profile, which is a great improvement for the operating system. While colour conversions on all platforms still default to on for ICC tagged content, they can be enabled for all other colours. Untagged colours will then default to sRGB instead of omitting monitor compensation for them. To do so go to the famous about:config URL and change gfx.color_management.mode from “2″ to “1″. Then use the installed CMS, e.g. on KDE KolorManager, to set a system monitor profile, and it will be detected after restarting Firefox.
For Android there is no CMS available. That means the ICC monitor profile must be set manually or sRGB will be assumed instead. The settings name in about:config is gfx.color_management.display_profile. Enter into this string the file name with full path, if you are on Android. That procedure is somewhat inconvenient compared to desktops. However the OpenICC group has published some specifications for implementation. This might be even possible for students inside the rewarding Google Summer of Code 2013 program.
For comparison, the Chrome web browser does support colour management on some desktop versions but unfortunately not on Android.
The below false colour test image should look correctly with ICC profile enabled browsers. Look at the colour gradients and then at the colour names and compare.
One year ago I wrote about the Lenovo Thinkpad Tablet based on Tegra II. After 12 months + the device is now pretty doomed. Not only mechanical switches stop working, the power supply gave up around the same time. Looks like Lenovo sells cheap and crappy hardware for business prices. For a ThinkPad labeled device that is far behind any expectations. But the whole concept behind Lenovos business tablets is flawed.
The manufacturer delivered since quite some time no security updates. The device boots only OS kernels digitally signed by Lenovo. So business administrators can not fix anything on their own as is otherwise usual for Android. That lockout makes just junk in a business environment. Further the company decided to build upon a Windows only chipst for the ThinkPad 2 Tablet, without any plans for migration of investments in Android. The minimum would have been a dual boot machine for those, who prefer to continue with, what they have build already. This is a business reset decision inside Lenovo. One simple measure would be to make the kernel signature public available to allow for security and OS updates on the device on a professional base. An other important step is to open up the currently Windows only ThinkPad 2 tablet for Android.
Once a year all or most of the applications around graphics from the free software world come together and work on new ideas and features for there software. The event where they come together is called LibreGraphicsMeeting. Oyranos participated always the last years in that meeting and got a lot of feedback and ideas from it. This year the LibreGraphicsMeeting will take place in Madrid/Spain and there is still time to submit interesting presentations around free software and graphics. As always the LibreGraphicsMeeting tries to collect some money for travel costs of the participating developers.
But there is more, last year we tried to get Gustav Gonzalez to the LGM and it didnt happen. This year Sirko started an campaign very early, as Gustav needs an visa for Spain he has to show flight tickets and accomodation for get it until 15th of February. Now we have nearly the sum for the flights, we looked for flights and we only need arround 200$ for them and another 150$ for accomodation. In case you dont know who Gustav Gonzalez is….
He is the main developer of Tupi, an cool QT 2D animation tool. Which makes it very easy to draw animations. Tupi is an fork of KToon where nobody works on anymore But what he has achieved since he forked it, is amazing. Meeting other developer from graphic applications would surly good for him and bring him new ideas for Tupi. SO it would be definitly a benefit to send him to LGM.
Around a dozen people met inside the Red Hat offices in Brno last weekend. The attendees came from various distributions and projects to discuss and work on color management for Linux. Most people arrived at Thursday and we started immediately to brain storm ideas and share information.
I was quite shocked as I heard Dantii could not join us. Fortunately the last messages about him sound very encouraging. It is great that our community could in different ways help him and his family.
Printing people discussed the PDF/X OutputIntent. The concept was developed to overcome the current short commings in the cupsICCprofile, which is primarily a vendor solution for CUPS print servers and the colord user session hook inside CUPS server. The implementation of the concept was done inside libCmpx, which is basically a wrapper around Ghostscript, which does the majority of the work, and a interface to Oyranos. From the other side John Layt looked into that work and Krita new print colour management tab to understand the implications for the KDE/Qt print dialog. He discussed lively with Till Kamppeter, Richard Hughes, Chris Murphy and me on how to get forward with that. Richard wrote a proof of concept for on screen print simulation in GTK. Chris talked a lot about osX printing and did some testing there. His experience on other platforms than Linux helped us a lot to figure out, which path we want to go and way the make sense. I searched for some PDF’s showing the features we need. They can now be found on ColourWiki. Jaroslav Reznik printed them and Till tested them. Michael Vrhel from the Ghostscript project fixed already after the event all of the bugs, which Till worked on in Brno. We had the idea, that some PDF printers might be able to do the right thing with the OutputIntent themselves. While discussing on how to know about that capability, Till and Richard had a nice idea how to reduce code duplication inside the current set of Linux CUPS filters. In parts the Color Management Hackfest crossed over into a Printing Summit.
Jan Grulich started coding on KolorManager. He implemented a widget to show a 2D graph of a ICC profile inside the information tab. Sirko Kemter was not very happy about the colours inside the graph. So I adjusted them, but after the hackfest.
While working on that, Jan profiled his monitor using Dantii’s colord-kde. Yes, Lukáš Tinkl fixed it, so it can now create ICC profiles. We needed to hand massage the profile to get it into Taxi DB, and then thought, it would be good to download the fresh profile later through Oyranos. That worked fine on the command line. But inside KolorManager a selection that a profile is available for download from Taxi DB would be more appealing. Jan wanted to look into that, and I worked later on a API and code snippet for Oyranos.
By the way, the above screen shot is done using the new colour correction feature for KDE-4.10. You might see the strong colour cast in it. Dan Vrátil worked on undoing that cast inside KSnapshot using the actual monitor profile. The initial coding was fast. But he likes to get that working for multiple outputs too.
Casian Andrei, who did the KWin Color Correction project during this years GSoC, wrote some documentation about that newly added feature. While writing that and clarifying some points, we discussed the opt-out inside KWin and found that it is not yet present. Sig. But Casian had played with the idea already and said that per region opt-out would be trivial inside KWin and started to write on that feature during Sunday. In case that works out, it would be trivial to opt out inside existing applications. But we found as well, that for a perfect results only a blending in the correct colour space is needed during compositing. That can be implemented inside toolkits, which is not trivial, and can then be used together with the per window opt-out. That buys us some valuable time for the toolkits to become ready for full colour management support. Whether the same per region approach is easy enough to implement in Wayland needs to be seen.
Now back to profile distribution. Oyranos obtained a new backup tool for Taxi DB. And we counted already over 200 different ICC profiles in the online data base. Sirko Kemter and Daniel Jahre grabbed the taxi sources, installed MongoDB and worked on mostly basic stuff to add later more features. The online front end to the DB can be used on every platform for download and upload. Daniel and Sirko discussed how to temporarily store a ICC profile from the ColorHug LiveCD. We found that the data base can be used for very different things, e.g. distribution of spectral data sets for camera sensors.
Pippin worked since some time on improving the display of gradients on 8-bit driven monitors. He came up with a dithering approach and tested that using the Taxi DB profiles for the analysis of his implementation. That helped him to make the algorithm more robust even with strongly distorted monitor gamma curves. There is quite some interest inside the graphics designers community for his work to solve banding problems. We talked a bit about gegl and I found babl especially interesting. The small library does, what I call pixel layout conversions. Those are in part colour space conversions and encoding conversions. For better separating encoding, 8-bit versus 16-bit etc., from colour spaces, e.g. linear gamma + Rec709 primaries versus sRGB etc., we need better ICC profile analysis. Especially gamma analysis can be improved inside rendering pipelines. Beside discussing hardware stuff, spectral imaging, video processing and so on, he gave a small and very helpful introduction into colour theory, which was a eye opener for many of the colour management newcomers and thus very welcome.
We had a interesting discussion about financial implications of colour measurement hardware. My impression is the high costs and thus reduced availability for good colour measurement gear nags on the success and acceptance of ICC colour management in consumer and professional markets.
During the hackfest it was really a pleasure to have so many experts in the field in one room and work together in a highly productive atmosphere. Some of them I met the first time. So let me thank our sponsors Google, Red Hat and KDE for their generous support of the hackfest idea.
We all worked quite a lot and found such a event should not stay single. So we agreed already to arrange a one day track and one following day at LGM in Madrid / Spain 2013 under the OpenICC umbrella. I hope we will see then even more projects coming.
Yesterday we heard about the arrest of one of our attendees during his journey to the Linux Color Management Hackfest. We where astonished to hear that the Argentinian police issued a international arrest warrant. As Germany is bound by international agreements to follow that, Dantii was arrested in Munich, where he where on transit. In the process of the german justice act his case will be decided. German courts have a notoriously high workload. So it can easily happen that his case might be handled within the next 6 months, which is quite long. The only chance he has is to obtain documents, which can exonerate his person in this case. Therefor his wife tries to come to Munich and bring the needed documents to Germany. Please consider helping Dantii.