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.

Linux Color Management Hackfest 2012

The hackfest in Brno is approaching fast. I wrote earlier this year about the idea. It will happen from 9th until 12th November 2012 inside the Red Hat Czech office. Talks with our local organiser and various sponsors went good so far. People will code in Brno on various topics around color management in Linux.

The main focus looks like to be at applications, desktop and library integration. For the printing system and Taxi DB was good interest too. As the event is organised as a framework for attendees, each one will decide, what is best to do. After a morning meeting, where we can coordinate, we will likely split in smaller groups according to a choosen topic or move around as needed. We hope that works for all attendees. There are specialists present for many Linux color topics for discussion and of course color management newbies can ask them to effectively improve their project.

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.

LibreGraphicsMeeting Videos

In begin of May there was the 7th LibreGraphicsMeeting in Vienna and Oyranos participated also this year in this meeting of nearly all free/open source graphic software. Oyranos had two talks there and I already blogged the impressions. Now the most of the videos from the talks are online.

The playlist with all talks which was recorded can be found here.

ICC profile graphs

During the recent days I improved the file dialog preview of ICC Examin. As a result I created a new Oyranos tool called oyranos-profile-graph, which can be found in git. It provides a simple icon and can potentially be used in tools like Synnefo or KolorManager‘s info tab.

There exist some graphing tools like ppmcie to generate a nice triangle inside a CIE*xy horse shoe.

CIE*xy graph from ppmcie

But as ICC Examin sticks on CIE*Lab, I think it is more appropriate to use the CIE*a*b projection instead. Both are available by oyranos-profile-graph. The graphical output of the tool is really simple, beside using Cairo for antialiased curves. Below are the 2D graphs for sRGB.icc LStar-RGB.icc ProPhoto-RGB.icc ISOcoated_v2_bas.ICC ISOuncoatedyellowish_bas.ICC profiles. The first graph is CIE*ab and the second shows the same saturation lines in CIE*xy.

 

Linux Color Management Hackfest idea

Sirko brought up the idea to organise a hackfest together with developers of applications for Linux desktops and experts interested in colour management. The idea behind that event was to bring interested developers together, support them in implementing color management in their software and move forward that topic across desktops and distributions.

During the recent LGM we found a chance to involve Richard Hughes and planed together about what we like to do during the hackfest. We spotted three main areas of interest: desktop applications including window managers, web browsers and printing. These topics are already worked on, but in a scattered way.

As example, Gwenview is a really great application for managing pictures. But it has no color management implemented yet. Color management in KWin is worked on during the GSoC this year, but in the opposite color management in the compositing manager mutter on the GNOME side is far away as can be read here. Not many web browsers support color management and if they who do, it is often incomplete. The SVG v2 standard will for example introduce additional color management features compared to SVG v1. So it is now the right time to get these implemented in order to be well prepared. For the KDE printing stack there is also a GSoC project this year, but also the Linux Foundation has a working group for this topic.

So, by meeting in person in one place, we want to get something done and build a good understanding of the role of each participating group for a working end to end colour management.

The hackfest will very likely happen in Brno in the Czech Republic at the Red Hat offices. A good time appears later this year 16th till 19th November. Now we like to collect more ideas, speak to people and sort financial issues.

LGM 2012 Impressions

The Technikum Wien provided a nice place and great support for the LibreGraphicsMeeting. Many thanks to them. LGM happened together with the Linuxwochen Wien and developers and users could talk about graphics and arts themes. Additionally to the one presentation track over all days, we had BoF’s and workshops. Some of us took the chance to present to a non LGM audience and meet people there too.

The LGM talks covered lots of OpenCL projects. That means modern GPU computing power is available to open source graphics components in a much broader way. As the use of OpenCL is supported by the Mesa software implementation, there is some kind of guarantee, that OpenCL programs will run on elder hardware. That means OpenCL can be used without the need for developers to provide a fallback mechanism, which simplifies adoption.

The colour management talks provided lively discussions around many topics like printing, displaying and open hardware. We discussed as well the impact of introducing colour management in frameworks like GEGL. As mizmo showed interest, I explained the most basic terms of ICC rendering intents in a small BoF using ICC Examin. Animtim compiled and installed Oyranos from sources and wrote already a small tutorial on how to build Oyranos on kubuntu-12.04.

Markus Raab with Elektra on LGM 2012 Vienna

Markus Raab presenting Elektra on LGM 2012 Vienna

The presentation of Markus Raab about the Elektra configuration gave to me some impressive insights into the concepts and flexibility of that small framework. The really cool thing about this library is it can abstract a lot of details and provide additional features, which can be added on run time like DBus support. He announced a new release of Elektra as version 0.8.0 during the event.

The metalab was for most people from countries without a similar open hardware/open source collaboration zone a impressive visit. We all enjoyed to could stay there for some hours and felt, this place is much in the spirit of most LGM contributors.

Nathan Willis @ LGM 2012 Vienna

During Nathan Willis workshop about the Create wiki, we discussed to start a email list for create users. That list is supposed to provide help and talk about experiences with graphics applications and help from users for users.

Sirko (alias gnokii) and Tobias (alias houz) played diplomat and managed to channel information in a way that Richard Hughes and I could finally meet in a productive atmosphere and continued talking about technical issues. At the end we found a mod to work again together on standards inside the OpenICC collaboration project. I am pretty happy with that change. So, thanks to all parties who helped with that.

Café Hawelka Vienna

Tatica, Pete, Sirko and I walked around on the last day in Vienna and relaxed in the café above.

LGM 2012 talks

As mentioned in a post before, the Libre Graphics Meeting will be held in Vienna from 2th until 5th of May this 2012. I have now submitted my talks and will hopefully know in some days if they are accepted.

OyranosColour Management a la Greek: will give a overview about some technical concepts for platform independent color management systems.
Evolving Concepts for Colour Management: will summarise the ongoing ideas and discussions on the freedesktop working group OpenICC.

Like in the years before, there is a chance to meet with students of the upcoming Google Summer of Code projects.

Sirko submitted Taxi DB – Call A Cab To Bring The Colors: which describes the idea behind the ICC profile database and hopefully we getting some feedback and ideas, on how to make sure, that the quality of the profiles will be high.

Markus Raab has submitted a talk about Elektra, which is used as DB API by Oyranos. I hope that will show new lively developments in Elektra ;-)

I am sure the self-styled competitor will also be around and give an talk about his view on color management.

If we can get to useful work on specs on a OpenICC round table for the sake of cross desktop compatibility, then even better.

Gustav likes to attend the Libre Graphics Meeting, but he needs some support to get there. We should help him, so that he can meet Boudewijn Rempt and some others from Krita, who can help him to find his way to the KDE community. But he needs some money for travelling. And there are still some other requests for generosity I mentioned before.

Tupi Libre Graphics Meeting Tatica
Click here to lend your support to: Libre Graphics Meeting Presentation and make a donation at www.pledgie.com ! Click here to lend your support to: Libre Graphics Meeting 2012 Vienna and make a donation at www.pledgie.com ! Click here to lend your support to: Tatica travels to LGM and make a donation at www.pledgie.com !

Libre Graphics Meeting (LGM) is coming along nicely and will surely become again a cool event for the FLOSS community. LGM is this year co-located with the Linuxwochen Vienna and their Call for Papers is still open until 1st of April.

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.

An other Open Source Colorimeter

Richard Hughes, the author of colord, developed in the recent months new hardware for measuring monitor colours. The ColorHug called device shall come at a relatively low price. It shall be useable for LCD/LED monitors providing input to calibration and profiling software. The most wide spread open source colour management system, which can create ICC profiles from colour measurements, is Argyll.

ColorHugThe author Richard Hughes states on his blog entry: “Existing hardware is proprietary and 100% closed, and my hardware has a GPL bootloader, GPL firmware image and GPL hardware schematics and PCBs”. The “100%” is a wrong marketing claim as Richard Hughes should know as Argyll user. However the new device fits nicely into a row with prior open source art in colorimeter hardware like the HCFR. The HCFR is supported in Argyll since some years now. To make the new ColorHug device functional, it would be great, if the hardware author could deliver a module instantly useable in Argyll.

What would now be interesting is to know, how the new device will compare with pre existing ones, being them proprietary or open source licensed hardware. The author gave a hint about speed. But speed is only one property useable to reduce noise in dark readings. Much more interesting is colour accuracy.

What is colour accuracy and why is it so important for a colorimeter like the HCFR or the new ColorHug? Colorimeter devices suffer almost all from a difference to the ideal colour reception of human eye, especially the cheaper ones. Only spectrometers can compensate better for that effect of non perfect filters in front of the actual light sensors, but expose other disadvantages. Colorimeter devices, which perform close to human sensibility, are usual expensive. Some are even more expensive than colour spectrometers. Colorimeter manufacturers use a common trick and put a correction matrix inside the device, which shall compensate for the difference between the sensitivity of human eyes and the colorimeter. But many users complained not to be able to get good results despite. This is easily understandable, as monitors emit light with very different spectral characteristics, which do not match the used filter in the colorimeter and its matrix. One approach to get better results is to use a per monitor model compensation matrix. Fortunately Argyll has implemented compensation matrices in one of its recent releases. The requirement for this approach to work is, that the data base needs input data from users.