Linux Color Management Hackfest Brno 2012 ended

Around a dozen people met inside the Red Hat offices in Brno last weekend. The attendees came from various distributions and projects to discuss and work on color management for Linux. Most people arrived at Thursday and we started immediately to brain storm ideas and share information.

I was quite shocked as I heard Dantii could not join us. Fortunately the last messages about him sound very encouraging. It is great that our community could in different ways help him and his family.

The basic concept we worked with during the hackfest, was the opt-out of colour management approach. That was visible in printing and in window manager colour management.

Printing people discussed the PDF/X OutputIntent. The concept was developed to overcome the current short commings in the cupsICCprofile, which is primarily a vendor solution for CUPS print servers and the colord user session hook inside CUPS server. The implementation of the concept was done inside libCmpx, which is basically a wrapper around Ghostscript, which does the majority of the work, and a interface to Oyranos. From the other side John Layt looked into that work and Krita new print colour management tab to understand the implications for the KDE/Qt print dialog. He discussed lively with Till Kamppeter, Richard Hughes, Chris Murphy and me on how to get forward with that. Richard wrote a proof of concept for on screen print simulation in GTK. Chris talked a lot about osX printing and did some testing there. His experience on other platforms than Linux helped us a lot to figure out, which path we want to go and way the make sense. I searched for some PDF’s showing the features we need. They can now be found on ColourWiki. Jaroslav Reznik printed them and Till tested them. Michael Vrhel from the Ghostscript project fixed already after the event all of the bugs, which Till worked on in Brno. We had the idea, that some PDF printers might be able to do the right thing with the OutputIntent themselves. While discussing on how to know about that capability, Till and Richard had a nice idea how to reduce code duplication inside the current set of Linux CUPS filters. In parts the Color Management Hackfest crossed over into a Printing Summit.

Jan Grulich started coding on KolorManager. He implemented a widget to show a 2D graph of a ICC profile inside the information tab. Sirko Kemter was not very happy about the colours inside the graph. So I adjusted them, but after the hackfest.

While working on that, Jan profiled his monitor using Dantii’s colord-kde. Yes, Lukáš Tinkl fixed it, so it can now create ICC profiles. We needed to hand massage the profile to get it into Taxi DB, and then thought, it would be good to download the fresh profile later through Oyranos. That worked fine on the command line. But inside KolorManager a selection that a profile is available for download from Taxi DB would be more appealing. Jan wanted to look into that, and I worked later on a API and code snippet for Oyranos.

By the way, the above screen shot is done using the new colour correction feature for KDE-4.10. You might see the strong colour cast in it. Dan Vrátil worked on undoing that cast inside KSnapshot using the actual monitor profile. The initial coding was fast. But he likes to get that working for multiple outputs too.

Casian Andrei, who did the KWin Color Correction project during this years GSoC, wrote some documentation about that newly added feature. While writing that and clarifying some points, we discussed the opt-out inside KWin and found that it is not yet present. Sig. But Casian had played with the idea already and said that per region opt-out would be trivial inside KWin and started to write on that feature during Sunday. In case that works out, it would be trivial to opt out inside existing applications. But we found as well, that for a perfect results only a blending in the correct colour space is needed during compositing. That can be implemented inside toolkits, which is not trivial, and can then be used together with the per window opt-out. That buys us some valuable time for the toolkits to become ready for full colour management support. Whether the same per region approach is easy enough to implement in Wayland needs to be seen.

Now back to profile distribution. Oyranos obtained a new backup tool for Taxi DB. And we counted already over 200 different ICC profiles in the online data base. Sirko Kemter and Daniel Jahre grabbed the taxi sources, installed MongoDB and worked on mostly basic stuff to add later more features. The online front end to the DB can be used on every platform for download and upload. Daniel and Sirko discussed how to temporarily store a ICC profile from the ColorHug LiveCD. We found that the data base can be used for very different things, e.g. distribution of spectral data sets for camera sensors.

Pippin worked since some time on improving the display of gradients on 8-bit driven monitors. He came up with a dithering approach and tested that using the Taxi DB profiles for the analysis of his implementation. That helped him to make the algorithm more robust even with strongly distorted monitor gamma curves. There is quite some interest inside the graphics designers community for his work to solve banding problems. We talked a bit about gegl and I found babl especially interesting. The small library does, what I call pixel layout conversions. Those are in part colour space conversions and encoding conversions. For better separating encoding, 8-bit versus 16-bit etc., from colour spaces, e.g. linear gamma + Rec709 primaries versus sRGB etc., we need better ICC profile analysis. Especially gamma analysis can be improved inside rendering pipelines. Beside discussing hardware stuff, spectral imaging, video processing and so on, he gave a small and very helpful introduction into colour theory, which was a eye opener for many of the colour management newcomers and thus very welcome.

We had a interesting discussion about financial implications of colour measurement hardware. My impression is the high costs and thus reduced availability for good colour measurement gear nags on the success and acceptance of ICC colour management in consumer and professional markets.

During the hackfest it was really a pleasure to have so many experts in the field in one room and work together in a highly productive atmosphere. Some of them I met the first time. So let me thank our sponsors Google, Red Hat and KDE for their generous support of the hackfest idea.

We all worked quite a lot and found such a event should not stay single. So we agreed already to arrange a one day track and one following day at LGM in Madrid / Spain 2013 under the OpenICC umbrella. I hope we will see then even more projects coming.

OpenICC Google Summer of Code 2012 results

Google Summer of Code

Participation of the OpenICC group in the Google Summer of Code 2012 program was this year a great success. All projects reached their respective goals. Here a small summary:

Colour Management for Krita Printing
Joseph Simon worked on adaption and integration of his last years implementation for colour managed printing into Krita/Linux. The workflow is based on ICC profile injection into PDF through the means of a OutputIntent.

KWin Colour Correction
Casian Andrei’s KWin changes for ICC style colour correction in the GPU are reviewed upstream and his new code to the KolorManager code base waits just for approval. The concept follows the X Color Management spec. In contrast to the elder CompICC implementation is the KWin result highly modular and thus very flexible.

Simple Toolkit Abstraction
Nitin Chadas SimpleUI project for rendering a subset of XForms was written from
ground up and provides now backends for FLTK, Gtk and Qt. It needs a bit
of polishing to become useable.

Thanks to Google for providing the colour management and graphics community again a great chance to code and learn the open source way.

OpenICC Google Summer of Code 2012 projects

OpenICC obtained three project slots for the Google Summer of Code 2012
stipends. That means three students can work again this year full time over
three summer months on colour management projects. Thanks to Google for
organising and sponsoring the program.

Here are in short the projects:

Joseph Simon will continue to work on PDF colour management for the
KDE/Linux printing stack. To have a real world project he choose to implement
Colour Management for Krita Printing.

Casian Andrej will work on ICC KWin colour correction using the X Color
Management spec. That way KWin gets a clear path toward consistent colour
output on the desktop.

Nitin Chada will work on different toolkit dependent renderers for a
XForms subset inside the Simple Toolkit Abstraction project. That standalone project shall enable modules to present
options inside dialogs or embedded in host applications.

Lets have a successful coding summer and deserve the trust Google putted in
the OpenICC organisation and with that in the participating students.

Colour Management GSoC projects

Google Summer of Code

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.

CLT 2012 Impressions

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 Oyranos download pages. 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.

CompICC-0.8.5 released

A new version of the compiz plugin for ICC colour correction of monitors is released. This release is a feature release.

Changes Overview:

  • 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)

About:
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.

ChangeLog:
http://compicc.git.sourceforge.net/git/gitweb.cgi?p=compicc/compicc;a=shortlog;h=refs/tags/0.8.5

git git://compicc.git.sourceforge.net/gitroot/compicc/compicc
git sha1: c963bdbc7aa4bf9703f3c87f82734d1223ff7d63
package: http://downloads.sourceforge.net/project/compicc/Compicc/compicc-0.8.5.tar.bz2
size: 76548 Byte
sha1sum: 902f2ea6b9c0aabe91297f6b80dd1f5ef9f910d1 compicc-0.8.5.tar.bz2
md5sum: 41a1a08c82ee18025d535c3dbc86aaf8 compicc-0.8.5.tar.bz2
Linux RPM: http://download.opensuse.org/repositories/multimedia:/color_management/

ICC Examin-0.51 released

ICC Examin Version 0.51 is a feature release. The package newly explores into window and OpenGL colour correction and contains bug fixes.

Changes overview:

  • new on the fly large gamut intermediate ICC profile
  • new let a colour server colour correct OpenGL
  • new Oyranos colour corrects report window on CPU
  • fix regression in file observation
  • require Oyranos 0.4.0

About:
ICC Examin is a small utility (unix name: iccexamin) for the purpose of watching the internals of ICC v2 and v4 profiles, measurement data (CGATS), colour samples (named colour profiles), gamut visualisations (vrml) and video card gamma tables (Xorg/XFree86/osX).

ChangeLog Version 0.51
http://www.oyranos.org/scm?p=icc_examin.git;a=shortlog;h=refs/tags/0.51

Thanks:
Thanks to all contributors and bug reporters.

git git://www.oyranos.org/git/icc_examin
git sha1: 90c55f1a141f17c9cdd1b1e9ae0723306351cc5e
package: http://downloads.sourceforge.net/project/oyranos/ICC Examin/ICC Examin 0.50/icc_examin-0.51.tar.bz2
size: 579532 Byte
sha1sum: 88b951879f304add2670630bd3d0632a0dd39ff7 icc_examin-0.51.tar.bz2
md5sum: e2db40c31596ba2d08cd2612de496289 icc_examin-0.51.tar.bz2
Linux RPM: http://download.opensuse.org/repositories/multimedia:/color_management/

KDE End to End Colour Management

The last blog posts about KDE and colour management might have been irritating about what actual happens on colour managed desktops. Here come some clarifications and thoughts from the Oyranos CMS maintainer. The project name starts with Oy (Oyranos like sky), hence my nick oy on IRC ;-)

Colour Management Systems (CMS) are a precondition to do colour correction of input and output devices. But this is not sufficient for having a colour corrected desktop. The claim was made, that Gnome is the first colour managed desktop on Linux. But Gnomes window manger mutter has no means to use ICC profiles. The same is true for all other window managers with an exception of old Compiz. A CMS selects only the needed ICC profile and does the configuration in that field. But the background, applications like the dock and most others are not colour corrected by standard ICC profiles mechanisms in Linux. The only thing users can do since many years on Linux is to do monitor calibration setup per single channel. This helps for better grayscale, but not for compensating of colour gamuts. Calibration is only a first step, but not sufficient for ICC colour correction. So Gnome users have today no colour corrected desktop like all other Linux users.

What is needed to get to a End to End colour corrected desktop in KDE? A more general Overview can be found here.

  1. KWin needs ICC support, in order to colour correct the KDE desktop in a reasonable time frame. That will help with the output side in a fast way by using the GPU during compositing while using few resources. If you feel it is time to do something, here is a  Google Summer of Code CM project idea for KWin. With my experience from the CompICC project, I would be glad to help any such project.
  2. An other project I would find really helpful is to provide colour correction to KDE’s primary image viewer gwenview. If people could help with a hackfest, that would be cool. We have such thing in mind and some ideas about, maybe you like to join us.
  3. Qt/KDE needs to explore how to do own fast colour correction of a complete window to be prepared for the future. Here are two project ideas.
  4. OpenICC did investigate to get print colour management right. There are currently two approaches who are promising. OpenICC has one project idea to introduce colour managed printing into Krita and one for user profile setup for colour managed print queues with KolorManager. These are two complementing, maintainable and robust paths for getting printing CM right.

Now some clarifications about Oyranos itself, as in the kde-planet where many wrong statements transported intermixed with half true claims.

  • Core is a toolkit independent library
  • KDE, Qt and FLTK front ends exist like KolorManager. Other native ones are possible.
  • The Elektra API and library is used for format independent configuration DB access.
  • Oyranos is planed to switch to a OpenICC JSON DB format to converge with ArgyllCMS and other interested CMS’es
  • Oyranos is a cross platform project
  • A DBus API would be welcome on top of the basic library but not in its core
  • Oyranos forces no one to use the CPU or prohibit to use the GPU :-D
  • The CMS provides means to do optional multi monitor colour correction and other conversions.
  • CompICC uses Oyranos and does colour correction on the GPU
  • Oyranos developers belief in collaboration :-)
  • Self containment in Oyranos results from adhering to and work on interoperable standards.
  • User configurations belong to users in Oyranos, so it needs no special root rights, which exposes security and privacy risks.
  • Oyranos provides optional policies for grouping single settings. That is a additional feature not a limitation.
  • Oyranos uses many advanced automatism’s to do it’s work successful
  • The CMS is designed to work with default settings.
  • Advanced manual configurations are supported and part of Oyranos’ user centrism.
  • Oyranos cares about quality and requires a careful selected and peer reviewed profile set that comes with no Fakes and no wrong colorimetry.
  • Licensing fits most open source and commercial projects with a newBSD style license.

Choice is a good thing for users. As a CMS author I have no problems, that an other CMS comes to KDE too on Linux. Many Linux CM standards I initiated or helped with allow for such interoperability, which is in the spirit of the ICC standard.

X Color Management 0.4 DRAFT1

Some days ago on FOSDEM I gave a presentation about Colour Management in Compositors. At that point is was not very clear how to introduce colour management especially into the upcoming Wayland display server core and thus make it wide spread. The answer from Wayland developers is the same as from Xorg ones. They want a small core and colour management does not fit inside this.

As a result of a discussion between several colour management interested people from wayland, toolkits and me on the wayland IRC channel, we found a smallest common denominator. That will be a per window colour correction mechanism. The advantage is, it will be very easy to implement inside compositors and they can even start today about ICC support. The biggest disadvantage for applications is, they need to colour correct the whole window. That is as well the reason, why I did not like the idea in the past. Anyway, hopefully toolkits will jump in at one point and make that easy. Meanwhile we need to focus on example code, which demonstrates how per window colour correction can work.

The spec can be found as usual in the libXcm git repository. The main new part is the _ICC_COLOR_OUTPUTS atom and XcolorOutput structure.

OpenICC Program FOSDEM 4 + 5 February 2012 in Brussels, Belgium

OpenICC uses 2012 a DevRoom at FOSDEM on Sunday together with Xorg people. The goal is to provide a meeting space for colour management topics.

The program is online on the OpenICC wiki. The talks will present and discuss colour management in Compositors, OpenICC, Scribus, Taxi DB, Oyranos and SVG2.