Recently we saw some lively discussions about support of Half within the Tiff image format on the OpenEXR mailing list. That made me aware of the according oyHALF code paths inside Oyranos. In order to test easily, Oyranos uses the KISS format PPM. That comes with a three ascii lines header and then the uncompressed pixel data. I wanted to create some RGB images containing 16-bit floating point half channels, but that PFMformat variant is not yet defined. So here comes a RFC.
A portable float map (PFM) starts with the first line identifier “Pf” or “PF” and contains 32-bit IEEE floating point data. The 16-bit IEEE/Nvidia/OpenEXR floating point data variant starts with a first line “Ph” or “PH” magic similar to PFM. “Ph” stands for grayscale with one sample. The “PH” identifier is used for RGB with three samples.
That’s it. Oyranos supports the format in git and maybe in the next 0.9.6 release.
The first beta of the object oriented C API came out end of last month. It brings a bunch of changes. First, all known Oyranos using projects are updated or have patches available. While the internal changes where heavy weight, most external users had few lines to change. The new APIs where possible through a Google Summer of Code project of Yiannis Belias in 2011. Nearly all C object types and basic functions are generated from django templates, which are interpreted and processed by the Grantlee engine and a customising plugin.
As we work on WM ICC colour management, we need more facilities to test workflows. In order to support that, the oyranos-icc tool was added and can generate 3D LUTs in various formats. Among them is hald and 3D texture. Te later format is used in CompICC and the new KolorServer of Casian Andrei. The 3D texture is stored as a PPM and can be loaded into the image_display example viewer and drives fast client side colour correction inside OpenGL. The same tool can be used to convert PPM and PNG files through ICC profiles including proofing and effect profiles, much like the C API allows.
The oyranos-profile-graph tool was already described in this blog. New is the generation of ICC profiles out of libRaw/dcraw camera matrices. That is a very nice fallback in case a camera RAW file has no custom profile available. This will not substitute DCP profiles, but is a step forward in integrating camera RAW workflows into ICC driven systems.
default ROMM RGB versus dcraw matrix derived colour space ICC profiles
There is already much written about Google Summer of Code. I just want to point you to a bunch of cool colour management (CM) project ideas.
OpenICC lists some ideas, which are interesting for cross desktop CM, especially for start in bringing CM to toolkits. Interested students are basically free to select one toolkit, which fits them most.
The CMM’s for Oyranos idea shall ease access to the upcoming spectral imaging capabilities inside the ICC architecture and to use smart CMM’s like ArgyllCMS was demoed doing stand alone and within ColorSync. Smart CMMs allow to optimise colour conversions for a images and devices, which will show up in more lively photographs.
The OpenGTL/OpenCL meta backend for the Oyranos CMM framework will enable us to write CMM’s, which run on the GPU instead of the CPU. That would potentially bring a big speed improvement for deploying applications through a simple CMS API.
One student proposed to work on characterisation based ICC colour correction inside KWin, which will fly over any of the old style per single channel gamma calibration. If you like to get ride of each monitor showing you a different saturated red, green or blue desktop background, then go ahead and propose a similar project for one of your favorite compositing window managers to the openSUSE or OpenICC orgs.
And of course there are printing related CM project ideas. One for CM printing with Krita and one project for general CM print queue setup in KolorManager.
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 Oyranosdownloadpages. 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.
A new version of the compiz plugin for ICC colour correction of monitors is released. This release is a feature release.
new support per region ICC profiles
new switch to X Color Management specification
require libXcm-0.5.0 and Oyranos-0.4.0
Changes from 0.8.4:
fix alpha blending
speed up load time (cache the transformed pixels in memory)
The project brings you instant desktop colour correction on GPU through the compiz window manager (0.7.x/0.8.x). It supports multi monitors and live connecting. The implicite colour conversion appears on the fly. To opt out of colour correction for specialised graphics applications the X Color Management spec 0.4 is supported. Devices can be configured through the Oyranos Colour Management System.
The third version of the Oyranos Colour Management LiveCD is based on openSUSE-12.1 and will run on x86_64 compatible PC´s. I placed the ISO image yesterday after some preparations on the better accessible SourceForge site for download. The CD project starts into a instantly colour managed desktop, which is unique under Linux.
The ICC desktop colour correction is done by the CompICC colour server. The LiveCD contains the usual mixture of colour managed graphics applications. Among them is the colour management system Oyranos, the KDE Color Management panel, a profiler based on Argyll CMS and many colour management aware applications for drawing, colour analysis and desktop publishing. Due to package size changes not even all programs from the last release are covered. I am very sorry for that. Nevertheless I decided to include Firefox, as a very wide spread every days application. After fixing a bug in Firefox, the web browser is usable under CompICC and has generally improved regarding colour management. But still it has many colour management related issues.
The desktop widget contains some test images to help you verifying, your desktop is setup correctly and works inside all colour managed applications. Covered are some JPEG, PNG, TIFF and SVG images with wide gamut and swapped channel test profiles. You will surely spot problems, as not everything in Linux desktops is really polished regarding colour management. But these test data can help you in getting a sense of, what can be relied on and what not. You can easily include other applications into your test by installing from openSUSE. And please help the projects and report bugs to the according project bug trackers. This will show interest in the issues seen with colour management and helps developers spot current weaknesses, which are otherwise overseen.
The CD uses the stable version of the Compiz compositing window manager, which is the only one being able to run under KDE. While the Oyranos CMS is packaged in openSUSE, a full screen desktop colour correction is currently not possible with KDE´s KWin or any window manager other than Compiz with the CompICC plugin. One difference to the previous LiveCD is a better useable nouveau driver, which since greatly improved and can now launch into Compiz with GPU acceleration.
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.
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.
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.
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.