The weekend on Chemnitzer Linux Tage happened in a very nice atmosphere at the TU campus.
The Oyranos booth had this year lots of place to show ideas on the hot topics like desktop and print colour management. Unfortunately my long planed co exhibitor could not make it to Chemnitz to show openSUSE-medical. We planed to display medical images on a properly setup 30-bit system as is required by the DICOM specification. Sirko Kemter designed one artistic 2 meter banner and helped with the basic design of the other posters, which we used for the new space. The Oyranos posters included some schematic graphics and the usual “Why do we need colour management” style explanations. For the later one I sketched a comparison of three non colour managed monitors showing the same fashion person. The SVG graphics from the open clip art library was colour converted to three real world monitor profiles. It resembles a typical shop over web situation, where colour counts for selection of the right looking goods.
Several visitors allowed me to start the actual SuseStudio created Oyranos LiveCD on their laptops with different success. We used the exhibited measurement devices and a camera target to create custom ICC profiles for use in digikam, Scribus, Inkscape and friends. The LiveCD is still based on openSUSE-11.3 and worked in many but not all cases. I found it impressive how good looked the featured KDE desktop, when the CompICC plug-in launched immediately. Working OpenGL, which is needed for the desktop colour server shader, was still not always available.
The newest openSUSE-11.4 version was demonstrated on the neighboring openSUSE booth. openSUSE-11.4 was released only some days ago. The OBS color_management repository was updated with the help of Stanislav Brabec just some days before to have nearly all packages build for 11.4. Thus Oyranos workes flawless on 11.4 too.
All in all a great weekend with lots of good talks and meeting of old and new friends.
After new second try, the driver license problem appears somewhat more relaxed. One important component needs good OpenGL support for plug and play full desktop colour correction. First choice for the OpenGL API on Nvidia and Ati hardware are the proprietary drivers from these manufacturers. For a LiveCD this did not work out due to legal reasons. The new CD can offer some basic OpenGL support to run Compiz and GPU accelerated colour conversions. The more and improving open source Nouveau driver comes to the rescue. Together with the experimental Mesa DRI it provides shader support. Some aspects work even better than the proprietary drivers, like backlight, obtaining monitor infos in a standard way through XRandR and automatic driver selection by Xorg. If you want to run on a daily base consider the Nvidia driver, as that provides power saving. It’s simply cooler.
There are some more changes like placing Krita on the CD. Krita is colour management wise a very interesting project. It supports floating point HDR images, comes with two own colour transformation modules in OpenGTL. The other new application is RawStudio. It implements the DCP spec of Adobe for DNG colour profiles. Both add to a very interesting colour software suite.
To read more about the LiveCD, please look at the old blog entry.
On OpenICC’s download area (edited on 16. February) on SourceForge is now a CD Live media available for 64-bit computers. It contains many colour management tools as available from openSUSE’s Build Service.
* littleCMS – widely used colour converter
* ArgyllCMS -1.3.0, dispcalGUI – cross platform colour management
* Oyranos – colour management system
* Compiz ICC colour server – or short CompIcc
* kolor manager – in KDE’s system settings panel
* ICC Examin – profile viewer
* Xcm/QCmsEvents – Xorg colour management event observer
* CinePaint – with net-color and other patches
* Scribus 1.3.8 – Layoutprogramm
* Cmyktool, Photoprint – imaging software
* SampleICC, IccXML – ICC sample implementation
* Nouveau/radeonhd + Mesa 3D drivers (edited 16. February)
… and more.
The CD should start on not too old nvidia graphics card hardware. Other systems are currently not support due to the requirement of a stable OpenGL driver with GPU Shader support for Compiz and CompIcc.
Once the live media runs, the desktop should appear colour managed. The trayicon, with the little horse shoe in it, should be coloured to show the colour server is correcting the the desktop. CompIcc is colour managing each monitor separately and acts on hotplug appropriately. Currently is no monitor ICC profile pre installed on the CD. So it must be generated on the fly. The colorimetry data comes from the monitor itself and contains the colour primaries, a white point and a single gamma value. This is enough to let strange primaries appear more natural, or detect a wide gamut monitor and compensate for its possibly very strong saturation.
|kolor-manager device profile selection
To change the monitor profile one can use kolor-manager from KDE’s systemsettings panel. It contains as well policies and default profile selection. These settings are stored in a per user database. To see that CompIcc is working one might select the CIE*XYZ profile, with its headroom and gamma of 1.0 the monitor appearance should change dramatically. But thats only visible when the “Show only device related ICC profiles” box is deactivated.
On the desktop are three example images just for having some wide gamut media available. The two tiff files are raw camera developed images with a custom ICC profile assigned. The restaurant JPEG is in AdobeRGB as typical for some cameras. All are tagged with the respective profiles and can be loaded into the installed image tools. PhotoPrint is a very sensible application and Scribus of course. To show the whole image gamut on a wide gamut monitor only CinePaint can communicate with CompIcc to get a own hole in the screen to colour correct to the native screen colours. All other applications see sRGB as monitor colour space. Thats visible by again assigning a CIE*XYZ while CinePaint has opened a image. It will not be affected as it does not check monitor profile switching.
The advantages of complete desktop colour correct are:
* wallpapers and movies look like indented
* shopping via internet is more reliable colour wise
* content on different brand of monitor look more uniform
* wide gamut displays become useable
* non colour managed applications fall back reasonable to sRGB
Hope you can start the media. For ATI cards one further version is planed and maybe for other cards, like intel graphics, a separate version can follow.
As powerful as the net-color spec for CompIcc and Oyranos are, they are currently slow. It takes Compiz around 11 seconds to show a usable desktop. For a colour geek like me no problem. Especially with a wide gamut display the startup delay is less of a pain then over saturated colours. The weak points I could figure out is that Compiz sends several _NET_DESKTOP_GEOMETRY events. I tried to blacklist some events and fiddle with _NET_DESKTOP_GEOMETRY, but that gave errors in other places. After using the nvidia-settings panel the new monitors where not initialised by the CompIcc plugin. So I decided to speed up the remainder. That is Oyranos and some stuff inside the plugin itself.
First with many profiles installed Oyranos spends more time on greping through them to find implicit matches. The search for implicit matches occurs after the explicit search. So assigning a ICC profile to a monitor device would already help.
One of my monitors uses a lcms generated on the fly profile. That is much slower than the implicit search. So I decided to cache the on the fly profile. Its now in ~/.local/share/color/icc/devices/Monitor. Thats especially nice as it has a beautiful name on disk. Manufacturer-Model-Serial_edid.icc . The _edid sequence says, it is automatic generated. To look up the newly created profile, it has the meta tag with the EDID infos embedded. For the next start its a implicit profile and thats faster.
The next bottleneck is colour conversion. CompIcc uses a texture lookup with 64 cubic grid points. These are 262144 pixel or 1.5MB in memory per monitor. Of course the 64 grid could be reduced, but at the expense of precision. Thats not so nice on the desktop. As the transformation happens at start time 3 times per monitor, it appears as a good idea to cache this expensive texture. Its written to a Oyranos pixel array and cached with a Oyranos in memory hash table. The lookup is several times faster than the computation in lcms.
Well these two changes made CompIcc start now in five seconds or maybe four. Without my many profiles, startup in git takes around three seconds.
Further a on disk cache could help eliminate the texture computation. That would be around one second for my two monitors. The implicit search could be reduced by caching a list on disk for previously parsed ICC profiles. But that is always fragile without a proper md5 hash. And I am not sure if reading and hashing is actual the most expensive part during the implicit search. But after all a abstracted on disk cache would be great in Oyranos. Lets see when I come around that.
CompIcc sees sRGB as its document colour space. Obviously setting sRGB as monitors device colour space would result in no colour conversion for untagged content. Conversion from one ICC profile to the same ICC profile does not alter the colour numbers nor their interpretation.
Currently untagged content is the majority of graphics on the Linux desktop, at least from the perspective of a colour server. The sRGB == sRGB solution is a real hack to skip colour corrections. This hack is too easily in conflict with the desktop colour space. And the right way is still to tag window regions as already prematched. The later method is a clear path to omit any colour correction in the context of a colour server. After fiddling around in CompIcc to support setting sRGB as a monitor colour space I gave up on that idea. It is simply too fragile and difficult to implement.
The newly released CompIcc with its monitor hotplug support appears much more stable without the sRGB hack.
It is pretty normal that graphics applications use GPU power for their image processing needs. The graphics cards where primarily designed to better support that kind of processing and offload computational power requirements from the main processor the CPU.
GPU computing came not over night. It was first introduced for boosting 2D applications. Simple desktop operations like moving a regions like a window or scaling and help in fast video decoding where first targets. Somewhat later came support for 3D operations. The later is now widely used through OpenGL APIs. The capabilities of the graphic cards increased and OpenGL was extended to support specialised programming on the GPU. The fragment and vertex shaders appeared. Programming of them is in a assembler language. So do not expect much convenience reading, while looking at the assembler code. However, for hard coded graphic operations it plays quite nicely. Compiz, for instance, uses this language for its desktop effects. Long times the assembler code was only available through the proprietary OpenGL drivers from ATI, Nvidia or Intel. Now the open source drivers begin to mature in supporting GPU programming. So it is possible to run Compiz with newer versions of the Nouveau or Radeon drivers. These two types of shaders, vertex and fragment, where joined and later a more convenient expression form for shaders was specified through GLSL. GLSL is OpenGL Shader Language. Newer OpenGL API’s support programming of them in a more straight forward manner. GLSL is officially part of OpenGL since version 2.0.
The C-like GLSL language is much more pleasing at least to most developers eyes. So it is possible to use this language by non specialised programmers to do fast computing on the GPU. If you understand and can write C, imagine you create a graphics filter of your own and process your graphics data through OpenGL directly on the GPU. Its fast and slick and you do not have to wait for a programming hero to convert your favorite algorithm for the GPU to run reasonably fast. But its works only on GPU’s. So either there is a software fallback in case your driver does not support GLSL or you are limited to a subset of hardware and drivers. Thats not so good for sharing and wide spreading your nice ideas.
The Kronos Group, which is the formal body behind OpenGL, specified the new OpenCL standard to improve portability and allow for much more flexible programming. OpenCL has, like GLSL, a C-alike syntax. It is a subset of C with some extensions. OpenCL is now adopted by osX SL and available as vendor driver from Nvidia. If you read adopted by Apple’s osX, you guess right, it is as well available for phones and tablet computers. The AMD Stream SDK contains a OpenCL implementation for CPUs. OpenCL makes the GPU now scriptable with a easy fallback to CPU. Of course thats all very young and up to date exist no open source implementation.
Some readers might wonder, why ICC Examin has not yet a new osX package. There are several issues with FLTK. The most annoying is FLTK has no real colour management policy. But stop. Which cross platform toolkit has? Right – none. Qt has non, Gtk – don’t know? The situation dates from times where RGB was just native display values. But that is changing completely. osX has with SL colour server functionality on top of Quartz integrated. On Linux early prototypes date back to 2008 and start to be integrated as CompIcc project.
Application developers be warned. FLTK and Qt defaults to “Generic RGB” on osX SL. This means no sRGB primaries, alias a different Gamut, and a Gamma of 1.8.
Do not assume sRGB on all platforms. And worse, a application can not assume anything about the colour space of the toolkit. Trolltech and FLTK, and Gnomes Gtk too, can change the underlaying colour space at good will. So colour managed applications using these cross platform toolkits are merciless exposed to this situation.
The name for the X colour management library is found. In short libXcm. Now what? Use it with the compiz plugin to colour correct the complete desktop. The plugin runs on the GPU and is thus pretty fast. It support multiple monitors. Of course a running compiz installation is required to use the plugin.
You need to install some colour management packages. I have created them for Fedora12 and 13 and for openSUSE-11.2.
If you have openSUSE-11.2 or Fedora-12/13 installed, then you can add my OBS repository
For openSUSE-11.2 do a:
sudo zypper ar http://download.opensuse.org/repositories/home:/bekun/openSUSE_11.2/home:bekun.repo
now you can import packages from bekun. The following will install the compiz plug in.
sudo zypper install oyranos-xorg-compiz oyranos-monitor oyranos-monitor-nvidia
Afterward you need to activate the colour_desktop plugin in CCSM
Please note I tested the compiz plugin only in a nvidia environment.
To check if the plugin really works you might install the qcmsevents systray programm:
sudo zypper install oyranos-xorg-qcmsevents
It should appear as a coloured systray icon. It can as well show you a window with more verbose messages. When you switch a ICC profile the selected monitor should typical change its appearance. From the command line you can use oyranos-monitor to play with ICC profiles. For that you might want to have some profiles installed. Oyranos comes with a collection of ICC profiles. Simply install the following package.
sudo zypper install oyranos
Now you can set a aggressive profile to show the effect:
CIE*XYZ would normally not be used for devices. The following command will unset the profile again
Now setup newly and a fallback profile should be generated:
The initial behaviour is to parse the available EDID tag and create an ICC profile from that.
Thats a rough guess but often enough a great improvement to sync e.g. a laptop with a wide gamut monitor. Do not forget to synchronise colour temperature and brightness. To obtain more precise results you need a colorimeter or spectrophotometer and software like ArgyllCMS or a GUI for ArgyllCMS.
How about selecting device profiles by a nice GUI. For KDE4 exists kolor-manager. The repository contains packages for openSUSE-11.2.
sudo zypper install kolor-manager icc_examin
After installation you can call systemsettings and select the kolor-manager panel.
In the Devices tab you can select your monitor and associate a profile to it. Selecting no profile should switch to the EDID automatic generated one.
Speed should be no problem on reasonable new hardware. Compiz itself has already some demand for resources. The colour_desktop plugin adds to that but relatively few. If you watch full screen video it can be up to 15%. With usual internet browsing or text writing it should be very few. I have the plugin running on a laptop and there is not much noticeable battery power reduction.
The OpenICC team proudly received two project assignments inside Googles Summer of Code program for 2008. Many thanks to all students who showed their interest for our projects.
The KDE Control Panel for Color Management project of Joseph Simon III will be mentored by Jon Anthony Cruz. Joseph is us already know for his excellent work last year on LProf. Jon mentors the first year for OpenICC and has long year experience with Inkscape and various other projects.
Color Management near X is the theme of Tomas Carnecky. He has good experiences with streamed content, OpenGL and X. He will be mentored by me, Kai-Uwe Behrmann. Tomas will attend the LGM 2008 meeting in Wroclaw in a few days and present and discuss his proposal in more detail.