Oyranos CMS (moved see top post)

News is Moving House

2011-10-30T03:32:00.000+01:00

Our colour management news are moving to the main Oyranos site.

The news feed on oyranos-cms.blogspot.com moves right now to the Oyranos news feed. This change will bring a unified content handling for the project and the blog can be easier commented. Together with Gnokii we set up in the last days a WordPress installation on our server and will run most activities from there.

The news including the wind&oil and the oyranos-cms.blogspot.com blogs are merged into one feed and are properly tagged. They are now all available on www.oyranos.org and will be continued. The old wind&oil news is already offline. Other parts will follow like some project pages. They are better represented by the equivalent pages on the www.oyranos.org site.

We are sorry for the period of restructuring and hope you will enjoy the improved colour management news offer.

Colour Correction Concepts for Monitors

2011-09-28T07:59:00.001+02:00

Colour management for the desktop is a long standing issue not only for Linux. The following text will concentrate on colour correction of monitors. This means the experience, when you switch your computer or handheld on and look on the screen.

Why colour correct the desktop?
People tend to compensate for quite a lot of different types of monitors. They are most often able to adapt to one full screen and see colours as they are intended to look like. Thats fine as long as they are concentrated on the visual event on that one display. But in this article we want to discuss how to compensate the monitor colours to our human visual needs in environments with various displays side by side, as is the typical situation for more and more people today. They take pictures with mobile phones or other digital cameras and look at them on laptops, tablets, picture frames, TV sets and printouts often side by side. Or we look at them over the internet and want to share the same visual impression with other people. Many people with uncorrected systems see quite a difference between various colour devices and try to figure out how to conveniently synchronise them. Colour management should help accomplish that task.

What is used today on Linux for colour improvements?
Different display devices feature different colour gamuts and colour appearance. We are especially sensible to the gray balance. This is a important property for our visual experience. Gray balance is since long time maintained by placing three linear correction curves into the graphics card. They are known as VCGT tag. Properly done, this helps in maintaining a equally stepped gradient from black to white with neutral shades in between. This calibration technic is fast and deployed since a long time by tools like xcalib. Calibration means in ICC terms, to setup a device driver in order to deliver a good and stable colour response. Strictly it is not part of the ICC specification. But for practical reasons it is usually embedded in ICC profiles. This basic calibration with linear curves is still in use on Windows, osX and X11 systems.

Acer Extensa 5630EZ laptop monitor

Different primary colours become more and more an issue through evolving LCD display technology. The above and below CIE shoe diagrams show quite different gamuts between the three primary colours red, green and blue of a typical laptop above and a wide gamut monitor below.

HP LP2481zx wide gamut monitor

It is generally desirable to use a screen, which is able to show deeply saturated colours. But uncorrected images show much shifted colour primaries to better cover human visible colours. Compared to traditional monitor primaries green typical becomes more cyan and red is moved toward the purple line. Of course the same RGB number triple looks quite different on booth devices. A calibration technic like VCGT linear per channel curves can not correct in any way for these saturation and hue shifts. Colours look strange not only on side by side comparisons of such devices. We need a calorimetric description of the monitor to properly colour correct the given device response.

Historically we have seen three approaches to cover the colour correction of the full screen.

X11 systems are colour management wise much like Windows. They predate ICC colour management and therefore have no historical APIs to enforce throughout colour correction. Maintainance of gray balance through VCGT is possible. The X11 XCMS extension was to our knowledge never in real use. Never APIs can bring a requirement for colour management. Few do today. Differences between corrected and non corrected content on one screen can be very irritating.
A very rigorous answer to the situation of missed colour management APIs is a fixed colour correction in hardware. But this can limit the capabilities of monitors to sRGB and thus the experience of wide gamut monitor technology not available. On the other side it provides a way to synchronise tightly controlled display devices.
On osX the whole rendering pipe line is colour managed. Each colour must have a colour space assigned to or it is not accepted by the systems graphic APIs. As a result all content from applications is converted on the fly by Apples ColorSync to the according monitor and looks correct. ColorSync takes over the work to bring colours from a source colour space like LStar-RGB to a native destination colour space like from a monitor. This helps programmers to concentrate on their actual task, which is most often not colour management related at all.

What is done so far to get the colour correction ball rolling?
In 2008 we started a project for OpenICC to do colour correction on the GPU on top of X11. The project allows to colour correct all non colour characterised desktop areas. Non colour characterised means by definition all window regions, except actively marked regions for opt out of system colour management. If no colour managed application is running, this means a full screen colour correction. These non colour characterised regions or areas are handled similiar to other non colour characterised content. Such colours are considered to be in sRGB In the printing world for instance. sRGB is the internets default colour space. This approach is a combination of the above outlined ones and an answer to the historical X11 specifics. The advantage is, that legacy APIs and applications can benefit from a colour corrected desktop, while updated applications will be able to opt-out of colour correction. Thus a situation like on osX, with all content clearly characterised, can be reached gradually. During the project was a protocol designed for server client communication. The belonging spec is the X Color Managementspec and is maintained by me over OpenICC. The spec was previouslycalled net-color spec, but was renamed due to name space conflicts. For a smooth transition of legacy applications, the implementation of the spec in libXcm contains the xcm tool. This tool allows to set colour regions manually as a workaround. LibXcm covers just the communication protocol for applications and toolkits to talk to a colour server. The colour server, for instance CompICC, is responsible for doing the colour correction on GPU. If you want to add a colour server to your favorite compositing window manager or have questions around the spec, get in contact with me.

Can the X Color Management spec do compositing?
During a discussion on a Qt email list came out thequestion about compositing and colour correction. Most obviously the spec misses a freely selectable compositing colour space to do full blown up compositing. this would mean blurry region borders and other technics where transparency is involved. That is simply out of scope for the X Color Management spec. It is logical in the responsibility of the compositor to decide about the compositing colour space. Compositing window managers on Linux use today just the plain monitor colour space for their compositing. That is not perfect but seems to be good enough for simple transparency effects. One correct way would be to meld the compositing of the window manager into the compositing of the client, which is in many cases the toolkit. But that is a bold adventure.taking the freedom of toolkits away and making traditionally modular stuff very monolithic. A architectural more sensible approach would be to use an intermediate blending space on top of the X Color Management spec. Thus the blending space is correctly selectable and modularity, interoperability and so on is much better. The toolkit can then rely on the compositing window manager to do all complicated transforms with the provided window and do colour correction as a final step. That would then essentially become a per window colour correction. From a todays point of view the intermediate per window blending space needs a lot to do inside toolkits. It might take years to get there as toolkits just started about first steps. So the per region colour corrected desktop is still a valuable concept for todays needs.

What is needed in the future?
Future developments have to take into account that the X11 architecture might change and other approaches become possible. The design of new architectures should cover colour management right from the beginning. With Wayland on the horizon and OpenGL-ES this is technically not a problem and would solve legacy issues like we see today in X11, on Windows and all major mobile platforms.

Colour management results of Google Summer of Code 2011

2011-09-22T09:51:00.001+02:00

We are pleased to announce the final results of this years OpenICC participation in the Google Summer of Code program [1]. All students could reach successfully the project goals and obtained the second part of the Google stipends.

OpenICC mentored two students directly and one student through the collaboration with the openSUSE organisation. All three worked on colour management projects, which covered in parts new ground breaking technology and maintain existing one.

Yiannis Belias worked on the "API stabilization for Oyranos Colour Management System II" project [2]. The new classes, code generator improvements and tools will walk into the Oyranos master branch in the next months. This project helps in stablising the CMS core, which covers a great foundation of functionality. After the conversion, it will be much easier to provide stable and extensible APIs.

Joseph Simon realised the XCPD project. It's goal was to implement the idea of a robust, standards conform printing dialog, which is based on the Common Printing Dialog (CPD) projects code. The handled and manipulated PDF follows the PDF/X specification for embedding user side colour managed content and remote printer configuration [3] [4].

Sebastian Oliva implemented a ICC device profile data base, called taxi. It is intented to share vendor and user created ICC profiles across platforms in a automated fashion. The online data base is designed to cover meta data about the device driver calibration status alongside the characterisation information in the belonging ICC profiles. The DB is online [5] [6]. The project slot was provided by the openSUSE distribution project and mentored by a OpenICC member.

Google Summer of Code is a global program that offers student developers stipends to write code for various open source software projects.

Many thanks to all students for their great work, all people how helped in shaping the basic ideas and discussing the projects in detail and Google for providing the stipends and openSUSE for addtionally inviting their students to the europe openSUSE Conference.

[1] http://code.google.com/soc/
[2] https://github.com/yiannis/Oyranos
[3] https://www.gitorious.org/google-summer-of-code-2011/xcpd
[4] http://jsimon3.wordpress.com/2011/08/23/gsoc%E2%80%9911-update-%E2%80%93-final/
[5] http://icc.opensuse.org
[6] http://openicc.git.sourceforge.net/git/gitweb.cgi?p=openicc/taxi

dispcalGUI 0.7 @ rwx³

2011-09-15T08:08:00.001+02:00

My yesterday held workshop for calibrating and profiling monitors using dispcalGUI+ArgyllCMS in Nuremberg was a nice experience. Around ten people from the openSUSE Conference gathered, all being eager to do something for their health of colour vision. We wanted to create ICC device profiles and collect them for later publishing. Following is a small report and review from the workshop.

We had available a i1display, a DTP94 and a i1pro as measurement devices, which no of the attendees owned privately. Installation on openSUSE-11.4 went pretty smooth. ArgyllCMS is in the multimedia:photo repository and dispcalGUI is in multimedia:color_management. Both are easily searchable through the http://software.opensuse.org URL. One hacker had all packages installed in advance and could start instantly with the i1display. With the default settings in dispcalGUI appeared a small terminal and required to adjust native monitor settings or continue with calibration. We pressed number 7 and continued with the calibration part. This lasted relatively long. dispcalGUI and in the background ArgyllCMS took quite some work to iterate over the calibration for four times with lots of "regression getting worse" style messages. This indicated to us, that it reached an end for improvement or the application where not satisfied according to each persons like. The profiling and installation finished after quite some time and the new calibration and profile could be used in colour managed applications. In Gimp the monitor profile was not used by default. The Colour Management tab in Gimp's preferences needs to manually enable the system profile, which is a troublesome exercise to figure out. Instead colour managed applications should look first at the system profile. Overriding the system profile by default is dangerous for a good user experience.

The next people became ready and used the DTP94 in between. Unfortunately there where four people failing to use it. What looked like a defect DTP94 device cable of my best colorimeter, was observed by three users as continuous USB device ID switching. One could spot the reason to a conflicting UDEV rule of libmtp. I filled a bug report on SourceForge including the patch of that user. With that fix the DTP94 worked again. I am happy to can use the DTP94 in the future.

I figured out how we can speed up the calibration, by reducing the calibration quality, which was nice in such a big group. One attendee had a repeated black switching of his laptop monitor during the whole process in connection with the nv driver. That persisted even during the profiling stage, which makes no sense to me. I suggested him to install the nvidia proprietary driver especially for his installed Quadro card.

In several cases dispcalGUI crashed without providing further informations on the command line. We had then to repeat the process. Luckily a longer break allowed us to finalise most ICC profiles. I requested the monitors EDID data block from all people, to have the device information available alongside the profile. This can be done by installing the oyranos-monitor package, which brings relatively many dependencies, like a default profile set and several libraries and modules. oyranos-monitor -f edid -o monitor.edid could then be used to collect that data. Some installations did not work as expected and I have to look into the issue. The new profiles need now further preparation before they can be uploaded to icc.opensuse.org.

It was fun to see how most issues where resolved in the group, and that most people could get a device profile for their usage. Registration of a smaller number of people would be helpful to ensure no overload of capacities. Between, dispcalGUI has a homepage with further detailed informations.

Taxi @ rwx³

2011-09-13T18:44:00.000+02:00

Sebastian Oliva presented today at the openSUSE conference the results of his ICC Device Profile Repository project to his mentoring organisation as participant of the Google Summer of Code 2011 program. As profile creation is expensive to most users, he emphasised the importance to easily share ICC profiles among these users. During the summer project, which is called now taxi, he developed a generic API to store and obtain ICC profiles through JSON requests.

X Color Management 0.3 DRAFT1

2011-09-11T20:50:00.001+02:00

The net-color spec from the libXcm repository is renamed. During a great conversation with Martin Gräßlin from KWin at oSC rwx³ he pointed out, that the _NET_ prefix is reserved inside the Xorg atom name space. So I decided to rename all atoms in the applications known to me, which use the net-color spec. The renaming went on fast and all apps work again as expected in git.

The new spec is called X Color Management. It contains the color regions in Xorg description and the used device profile for Linux desktop colour servers.
Affected are libXcm, Xcm, Oyranos, CompICC and CinePaint.

CinePaint full screen

2011-09-08T07:54:00.000+02:00

On my git repository with CinePaint patches is the full screen mode changed. It uses the GTK funtionality. That mode is now window manager based and will not work with twm. The old code is still ifdefed for users who rely on that and compile it. Putting a full fledged solution like in gqview inside CinePaint would have been too much work.

New is as well resizing of frames in the flip book, to allow me to load a bunch of cameraRAW images and watch them much like in a slide show. Colour regions are updated for the colour server.

And last but not least a fix in now available, to let CinePaint run on non KWin and non Compiz window managers. I tested on twm.

The package is patched in OBS.

Oyranos @ rwx³

2011-09-06T10:12:00.000+02:00

rwx³ alias openSUSE Conference (oSC) will be from 11.09. - 14.09.2011 in Nuremberg / Germany. We will meet there and can discuss ICC colour management for the openSUSE distribution, KDE and Qt.

Sebastian Oliva will be there too. I hope we can hack together a Oyranos connection to his newly created ICC DB. The ICC DB project, done during GSoC 2011, shall be used to search for ICC profiles by terms of colour device configurations. This means a printer can obtain a fitting ICC profile for a special driver without the need to have all the canned profiles packaged. Independent vendors can easily upload their ICC data and get their optimised profile selected automatically - if all works. Sebastian and Joseph Simon have done fair bits to get there in a clean way, without hacking the whole system.

I will have colour measurement equipment with me and we can create new profiles for actual used gear, like laptop monitors. Of course these shall walk into the ICC DB.

It would be cool to meet with Compiz and KWin maintainers/packagers to get the GPU colour managed desktop project further. The net-color-spec appears pretty robust. But we need a critical mass to support the concept of colour correcting all windows on the desktop in compositing window managers.

Will be great to meet you all.

OpenICC and basICColor profile packages

2011-05-29T12:46:00.001+02:00

Originally I wanted to have most packages ready for Montreal. But it was good to not announce them. Now they are slowly rolling out.

Today came the basICColor_Offset_2009 package 1.1.1 shortly after OpenICC Data package 1.2.0. Both form now a fairly distributable and stable usable set of ICC profiles with completely free licenses.

ICC Examin had some issues in the CinePaint plugin. So I decided to first fix that and as well finish the started ICC v4 support in ICC Examin. Most of that should work already in git.

LGM Conference 2011 Montreal

2011-05-29T12:44:00.000+02:00

LGM was a quite useful chance to meet people. Jon Cruz from Inkscape I met the first time, which was a nice experience. His remarks on the Cairo API for ICC support at the end of the OpenICC round table where interesting and I hope we can continue with that hot toppic. As well I meet Richard Hughes the author of colord and GCM. We could settle on a specification for file based colour device configuration exchange of CMS/CMF's and discuss desktop colour servers, which was quite interesting. My talk was about "Connecting Device Calibration to ICC Profiles".

With many more people I could exchange ideas and make plans. Among them where Oliver Berten, the author of SwatchBooker, Peter Linell and Jean Ghali from Scribus and many more. To my surprise Boudewijn Rempt from Krita pointed out that OpenGTL's shiva can handle more than three colour channels. I would love to get support for that in Oyranos.

The whole atmosphere at LGM was great and Louis and the LGM organisation team did great in preparing culinary and cultural program highlights additional to a wonderful conference. As time for coding was somewhat short, some slight improvement could be coding & buffet. This would be a nice experience instead of the well known coding and pizza.

I found the town of Montreal to be a surprisingly friendly place. People from so many cultural background where smiling in the streets, of course always with a arm's length distance, which is quite unusual in Europe.

Google Summer of Code 2011 Students

2011-04-28T20:09:00.000+02:00

Several students proposed this year to specific colour management themes. Unfortunately not all could be accepted for the stipends, even though the quality of the proposals where generally high for the themes and response was very lifely. The mentors made their decision and picked the following three proposals and students.

Yiannis Belias will continue the last years project:
"API stabilization for Oyranos Colour Management System II" for OpenICC
We have seen good progress and quite usable code during the last year period. Still there is lots to do to integrate and finish the code transformation.

Joseph Simon will work on:
"Color Management for the Common Printing Dialog (CPD)" for OpenICC
This is a working title and might be changed based on input of the community. The idea covers a prototypical CM UI for print dialogs either using the CPD or perhaps something like the GTK print dialog. Perhaps the biggest challenge will be to figure out what should be in the printing CM UI. It would be great to see the OpenICC list to help work out the UI design.

Sebastian Oliva will work on:
"ICC Device Profile Repository" at the openSUSE organisation
A colour database to allow clients to request or submit colour profiles for colour managed devices. The idea was proposed at openSUSE as a collaboration project in their ongoing support of colour management. It will be mentored with the help from OpenICC people.

Congratulations for the acceptance of your proposals for the Google Summer of Code stipends this year. And thanks in advance for bringing your valuable time and energy into these projects to improve open source colour management.

Google Summer of Code 2011 Student Applications open

2011-03-29T12:01:00.000+02:00

This years Google Summer of Code program is open for student proposals. OpenICC in collaboration with openPrinting and openSUSE provide mentored projects around colour management. Own ideas from female and male students all around the world are welcome.

And still we provide guidance for all new or experienced people who like to help with and code for open source colour management projects, even without GSoC.

Libre Graphics Meeting 2011 Montreal

2011-03-29T07:26:00.000+02:00

LGM will this year happen in Canada. It is one of the great chances to meet so many of the graphics people out there from the major graphics projects. As more and more artists use libre graphics software the focus shifts from almost a mainly developer event in early years to a mix of artists, users, documentation writers, standardisation people and surely more roles. This gives a unique atmosphere to the event.

Typical the projects, which cover a wide range of graphics arts, will present their actual state and announce releases. There will be panels to envision the future of overall developments, to get in closer contact for collaboration projects and to propose or discuss new standards. There is always a reason for surprise.

With enough colour people meeting at LGM, there will be a OpenICC meeting to discuss topics around ICC style colour management in person. This is a good chance to get matters on the table and talk in person. Other colour discussions usually happen at various talks, workshops and so on. I will join this year again.

Dear reader, to make the event happen please consider funding travel and organisation. Many contributors from all over the world can not easily afford the costs for their hobby projects and must rely on your generous spent money to get there. A good chance is the pledgie champaign. The page covers as well links for sponsors:

Oyranos on CLT 2011

2011-03-23T20:32:00.000+01:00

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.

Synnefo Development Begins

2011-03-06T19:30:00.000+01:00

Joe Simon blogged under the same title about a new project, which will be derived from Kolor-Manager. Both GUI's will be front ends for Oyranos to set custom, manual preferences. The goal of the Oyranos project is to provide the same programming interfaces and user interfaces on all supported platforms and desktops.

Gutenprint talks to colour management systems

2011-03-05T07:49:00.001+01:00

The Gutenprint project is going to tag its colour related print options with the ColorKeyWords PPD entry. Thus Gutenprint follows a request to tag colour related options in native device API's. Marking colour related options as being colour related will help to automatically select ICC device profiles depending on the calibration state in the deriver. So in case Gutenprint is set to a increased brightness of 1.1 and the media size is A5, then the colour marked brightness setting will play a role in searching the correct ICC device profile. In contrary a non colour related paper size option will not influence the ICC profile search. This concept of marking driver options as being colour related works as well for SANE and Xorg. The colour related options can be serialised to a common file format, which still has to be defined. Then this calibration information can be embedded by profilers into ICC profiles. Such calibration data enriched ICC profiles can then even be used to setup the calibration state of a given device + driver combination and automatically ensure the correct usage, while minimising user errors. That approach is already deployed in Oyranos' Xorg module. For display profiles it is typical to embed the calibration data inside the ICC profiles for a long time. The embedded calibration data is used to setup the graphics card to work with the display. Gutenprint is the next candidate to get a similar calibration support inside ICC style colour management.

Oyranos Colour Management LiveCD II

2011-02-17T22:25:00.000+01:00

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.

Oyranos Colour Management LiveCD

2011-01-06T22:55:00.002+01:00

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.

Speeding up CompICC

2011-01-02T13:47:00.001+01:00

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.

Oyranos and the implicite profile selection

2010-11-30T16:05:00.001+01:00

With the ICC meta tag proposal, sent today to the OpenICC list, a new brick is set to make implicit colour management more solid for the Linux desktop. The monitor configuration is the most robust one so I decided to give this a fist draft. The tools are in git to enrich the ICC profiles with the belonging device informations. So this can pretty much run. I plan to provide some of my created ICC profiles as a downloadable device profile package. Once in the ICC profile is in the profile path, the device and installed profiles can be compared and a matching profile can be implicitly picked without further manual intervention. Overriding through a manual configuration in kolor-manager is always honored. The order of configuration is first look in the Oyranos DB for a explicit configured ICC profile, if no then scan the installed ICC profiles for one matching the to be setup device, if not generate on the fly from the monitors EDID data block, if not try from the Xorg log and as a last means take sRGB, if not fail miserably ;-)

What will follow, is the libRAW alias DCraw module. Yiannis started that in 2009 as oyRE. Thats the device detection code. It parses the libRAW options and EXIF informations contained in a cameraRAW file. We think of that file as a device. So its pretty unique in the Oyranos device configuration system. To build useful tool Yiannis created as well a small raw2tiff utility based on libRAW. That was so nice, I converted that into a Oyranos file load module called "lraw", with the usual four letter sign in Oyranos for a module. So the image_display tool can now load PPM,PFM, PNG and new by "lraw" various DCraw supported cameraRAW files. The next step for cameraRAW will be to rewrite raw2tiff with both "lraw" and "oyRE" inside and pick an other name. Similar to the oyranos-monitor tool that new tool will allow to embed colour related key/values inside the meta tag into a ICC profile. For that tool I plan to use the XFORMS CLI renderer and parser to handle to the module options. That will be a good case where ordinary options will mix with colour related ones. I think the options can be tagged for colour relevance like in SANE or CUPS modules. By this change Oyranos' device protocol needs an update. But before that I think a new release would be nice and push the new ICC meta tag implementation into place. The Oyranos LiveCD awaits than an update.

new iccprofile mime icon

2010-11-09T17:20:00.000+01:00

Nuno Pinheiro is a artist, working among other things on KDEs icon set. We discussed on the openSUSE conference 2010 about the missing ICC profile mime type icon, and he created a simple, and very well recognizable SVG icon. Personally I like it much.

Many readers might not know what this graphics actually means. This often horse shoe called shape is from a CIE*xy diagram and represents the range of human visible colours. The border represents the spectral colours, which are highest saturated to our seeing. One can find lots of scientific colour diagrams, based on the CIE*xy horse shoe. So it represents as well human vision and a scientific approach of colour reproduction and matching. Of course without Nuno's artistic interaction it would be half of the fun.

ICC meta tag in device profiles

2010-10-29T12:41:00.000+02:00

The meta tag is supported since quite some time in Oyranos. Now this functionality is integrated into kolor-manager, the Oyranos front end for KDE's systemsettings panel.

development version of kolor-manager with meta tag support

The meta tag allows to rank a given set of ICC profiles with a device. For that to work device characteristics and possibly driver informations need to be stored in the ICC profile. The meta tag accepts key value pairs. This is pretty much the way how many configuration systems are build.


ICC profile with meta tag shown in ICC Examin

Most keys originate from the monitors EDID block. The EDID block is a data sequence containing lots of useful informations. For colour management purpose are only a few bits relevant. Parsing and interpretation of the EDID informations does the libXcm to supply a common set of keys, which can be shared among different applications to easily understand each other. We store here the:

manufacturer - this might be as string available
mnft - contains a decoded 2 byte field
model - can be a string
serial - likewise
week and year - can be influential to production series
mnft_id and model_id - map to similar keys already present in other operating systems
colour_matrix_text_from_edid_redx_redy_greenx_greeny_bluex_bluey_whitex_whitey_gamma - is a very long key name and contains the comma separated colorimetry as found in the EDID block

One question might be why not store the EDID block itself inside the ICC profile. The tag for that is already defined. The EDID block is a static piece of information. The meta tag is much more elegant in that the values are human readable and single keys can be much more flexible compared to each other.

Additional driver informations are included as well like host, display_name and display_geometry in the above example. They are useful for the local Oyranos data base. For exchange with other computers these keys might be better stripped out.
How do these keys and values come inside the ICC profile? The development version of Oyranos in git has a simply API for adding a device object to a profile object. All text information is placed inside the meta tag. The oyranos-monitor tool accepts a EDID data block and a ICC profile and embeds the libXcm provided keys and values just without the driver information. So it is possible for a person who has profiled a device to ask Oyranos for the EDID of the local device by:
$ oyranos-monitor -f=edid -o=edid.bin
and then add the colour management information to the fresh ICC profile:
$ oyranos-monitor --add-edid=edid.bin --profile=MyNewProfile.icc

The MyNewProfile.icc profile can now be shared among other computers or users. It will magically appear in the fist line of the kolor-manager profile selector if the devices match otherwise not.

What next? It would be amazing if that ranking could be used to implicitly automatically select that ICC profile. Then installing a properly tagged ICC profile will automatically improve the unconfigured desktop, provided a system like Oyranos is used to understand the meaning. But thats not enough. Of course a vendor might decide to massage the key values inside the meta tag, in order to support a series of devices with the same ICC profile. For that Oyranos will have to learn understanding the complete syntax of the ICC meta tag specification, especially the value range feature.

I have focused on monitors, as this the most advanced supportable device class on Linux systems through the CompICC colour server and the various specifications for X colour management. Other device classes will surly profit from a similar approach. For that the keys and the meaning of the according values has still to be defined. The ICC meta tag adds a very useful tool for that to happen.

sRGB = monitor?

2010-10-11T14:52:00.000+02:00

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.

GPU Graphics Processing

2010-10-01T08:57:00.008+02:00

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.

ICC colour management in Xorg 2

2010-09-09T20:49:00.003+02:00

After some talk with Xorg developers, they argued that needing a second layer for the colour correction would cause trouble for the missing path of higher precision than 8bpc into Xorg. This seems at least not a problem for compiz. Using OpenGL the desktop is placed as textures into the graphics buffer and the colour correction can happen on the GPU, right before putting on cable.

The next argument against ICC in Xorg came with a additional read/modify/write cycle and its inherent power and time consumption.

Last but not least synchronisation is not easier with colour conversions running here and something drawing the pixels there.

So it seems most appropriate to keep colour management inside the compositing WM, improve the specs and put some more useful code snippets into libXcm.

(edited september 10, 2010 at 15:46)

Cross Platform Toolkits and CM

2010-09-02T09:43:00.000+02:00

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.

ICC colour management in Xorg

2010-08-24T18:46:00.000+02:00

The CompIcc plugin is already a great tool for mixed multi monitor setups. However compiz is in few distributions the default window manager. So it would make sense for the Linux desktop to implement the net-color spec inside Xorg.

Hey, hey, you might ask now, Why do I need this compositing toy called compiz now in Xorg and what brings me that ICC stuff? The answer is simple. Look at Apple computers. They show most likely the colours the designer has intended. And at least basic stuff works. You shurely want one a small gamut monitor to see the same skin tones like on a wide gamut monitor. After all its the photo or picture or drawing you are interested in. A grayish photo from a baby on a small laptop monitor or a grand daddy with highly orange saturated face on a wide gamut screen is surely not intuitive. Supposed your camera works good enough, and most digitals are really good, its possible to exchange the photos from the one monitor to an other monitor with different sized gamut. There shall be not that high difference as we see on todays Linux desktops.

Is'nt ICC colour management expensive? No, not necessarily. The very basic colorimetric information comes straight from the monitor. It is embedded in a small binary block known as EDID. A ICC profile can be generated on the fly from this data block. E.g. Oyranos supports that as a fall back. So, ICC colour management can be made instant and needs no extra purchase of expensive equipment to improve the colour rendering.

What is needed in Xorg to get ICC support in? A layer, which sees the window regions defined by the net-color spec and which can use hardware shaders. Then it needs to put the monitors each on a own texture, apply the window regions and let the shader run on the GPU. The net-colour spec has some more requirements. But these should be manageable.

Why in Xorg? Its a technical question. The main reason is that each compositing window manager needs to implement the net-color spec. That is lots of work and you know there are lots of window managers for Xorg. Beside that repeated work, not all window managers will naturally be prepared to work with GPU shaders. From a user point of view its desirable that capable hardware is deployed for colour correction without the need of configuration. So it makes sense to have the colour management implemetation in one place. Of course there needs to happen some discussion with the Xorg people about the concept and the details in advance.

Will higher bit depth and different channels, e.g. Cmyk, be supported? The net-color spec does not talk about that. It works with whatever pixel storage format is provided. E.g. In compiz it is 16-bit integers ARGB.

Will a true HDR format not be better and simpler to be implemented? Let me ask back how long shall we wait for that to happen?

What weaknesses are actual in the net-color spec? It can not define a custom colour transform per monitor. However by putting the colour management into the application it is still possible to gain more control over the colour rendering process. As well, defining a document colour space per region is not yet supported but easy to extent and I guess to implement. The classical use case for that would be a video stream with a attached ICC profile. Currently the content is assumed to be sRGB only or the application has to colour manage itself.

Oyranos LiveCD

2010-08-09T10:27:00.000+02:00

The releases of Oyranos as version 0.1.10 and ICC Examin in version 0.47 are not too far away. Now a CD image build on novell's susestudio combines that two with the compiz colour management plugin and the nvidia graphics card driver to a openSUSE-11.2 Linux OS. The LiveCD is tested in two systems with nvidia graphic cards. The ISO image can be burned on CD. It will just boot or can be installed on disk. Try the LiveCD out and let me know how it works for you. To download you have to login by your novell, google or whatever account is supported.

CSS3 and ICC colour profiles

2010-06-23T11:26:00.001+02:00

CSS3 drops color-profile property due to a lack of implementation and calls now for more implementations.

These are bad news, as it clearly reduces the scope of ICC profiles. In order to create content with certain colours a ICC profiles is the best way, as soon as the colours exceed the default sRGB colour space. Moreover HTML5 relies on CSS3 colour definitions.

SVG can be used in HTML5 not as syntax, but as embedded document. This means SVG color-profile is not available to all canvas elements. My guess is some web authors need to circumvent sRGB limitations by the means of embedding documents. Is this a continuation of the old flash with unspecified colour space? Clearly not at that level but in regards to colour it might be. We will see. What will be the blending colour space of native canvas elements with SVGs and PNG embeddings?

libXcm and full screen colour correction with a GPU

2010-06-17T15:04:00.002+02:00

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:
oyranos-monitor XYZ.icc
CIE*XYZ would normally not be used for devices. The following command will unset the profile again
oyranos-monitor -e
Now setup newly and a fallback profile should be generated:
oyranos-monitor
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.

Qt based X Colour Event observer

2010-06-14T20:00:00.001+02:00

Oyranos has a small application in its examples folder, which shows colour management related Xorg events in a window. The system tray icon shows the Oyranos logo. If its gray the desktop is not colour managed. With a colourful horse shoe it indicates a colour server is running on the desktop.

X11 color management library name

2010-06-04T13:19:00.001+02:00

Who does not know about the fun or trouble to get a name right?

Right now I am searching a name for a library. Tomas Carnecky started the xcolor library two years ago inside the OpenICC project. Now its time to get that code distributed as the compiz colour server will rely on it. At the same time we want people to write similar stuff for other compositing managers. libXcolor, working title, attaches colour regions to windows and associates ICC colour profiles with them. The fun is its pretty independent. Only libX11 is linked in and Xfixes should be recommended. Of course there is more needed than just telling about regions. But this little code allows us to communicate between applications and a colour server. So its the glue of information for flexibly colour correcting the desktop.

XCMS would be a good match. But that effort is almost historic and does not fit well to modern ICC style colour management. XColor is already in use by Xorg. AgryllCMS has a libxicc and I don't want to touch that either. libXcm seems free for X Color Management. Would be well on topic.

Btw. Pascal looked into building a Debian package. As part of that I exchanged the configuration and build system and now the whole project blow up in size. The package is much larger then the real code inside.

LGM 2010

2010-06-01T18:52:00.001+02:00

Libre Graphics Meeting in Brussels was a great event. The Oyranos project and a OpenICC meeting where a second time present. The last LGM for me was in Wroclaw two years ago, which was great as well.

This years organisation team managed the expectations very well. The location was really a place of inspiring creativity. The food where nice prepared north african dishes. I enjoyed the vegetarian mixture for these couple of days, as it tents to keep the head free and attention high.
The one track talks worked very well and we will enjoy the recordings of the whole track due to this session layout. The short presentations gave occasions for statements and many nice ideas. Surrounded by Birth of Feather (BoF) and workshops it was a nicely working mixture. And of course the discussions continue as well after LGM on public email lists and in private emails.

The colour management BoF took place on Friday. My notes for the OpenICC BoF session will go to the create and OpenICC email lists soon. We had a nice meeting around colour for the open source operating systems and desktops. Various projects where present like Scribus, Adobe, W3C, Ghostscript, Krita, GCM and Oyranos. The session served to inform and exchange with people around colour management concepts, directions and issues. Even if I had expected more projects to take part, I have seen great interest in colour around. Colour Management was considered as well in the OpenRaster BoF. There was a workshop around cameraRAW colour management and I learned in more detail how it works, which was very interesting.

The Blender project got really a financial impact and more projects target at gaining resources by turning their ideas into financial concepts. Thats a great sign, as it will allow to allocate more resources to the development of these open source projects. Blender had the great money collection to buy the code base for the project and release under a OSI license. Krita obtained much community sponsoring to pay now one developer for several months. Jon Philips talked about his commercial open source activities.
What I hope is that the mixture of various project concepts for the whole libre graphics development keeps open. Ending in a commercial mono culture just with open source strategies would not satisfy. What I really like in this community is the mixture of full time commitment and occasional contributions. There came many surprises to me by people, who seemingly have low commercial interests in their software, but seek ways to express their ideas and just want to evolve in this. I hope the mixture keeps alive as a base for a lively and creative spirit.

Many presentations where this year held by artists. That gave a very nice insight on how projects are driven by user demand. Just hire developers and let them implement, what users want, is a interesting concept. I am pretty sure this concept has limitations to complex software, but the directness of expression is amazing. It shows as well how users are actual enabled to implement their ideas by the means of existing technology. With future developments in web technology like HTML5, I expect to see more of that type of activities. A really great direction.

Wind&Oil shifted

2010-05-31T22:33:00.001+02:00

The blog just went in parts here from Wind&Oil.
Look at elder Oyranos related news as well there. And ...

Enjoy.