An exclusive interview with Kai-Uwe Behrmann

Hello Kai-Uwe

As one of the lead developers of Cinepaint and a very active contributor in Color Management (CM) on Linux, you are a key-person when it comes to using Linux for photography. Thank you very much for taking the time to share your thoughts with us and help us understand better what is going on in the Color Management field on Linux.

 

Can you describe which OSS projects are you involved in?

Currently I work mostly on Oyranos. Other projects are worked on only as needed for Oyranos. Oyranos is the abstraction of many low level details of an operating system Colour Management System (CMS).

Then there is ICC Examin. It can be considered as an advanced colour management application. ICC Examin allows for ICC profile and some system analysis and needs many kinds of colour conversions. It serves well as a test bed for Oyranos.

My idea to work on both is to move most colour management calls out of ICC Examin’s C++ to Oyranos. This will provide lots of stuff like ICC profile handling, (not really but kind of) object oriented C structs, a hopefully clear and extensible API to interface from nearly every language and more. At the moment I think about integrating a thread interface into Oyranos as it is a requirement for ICC Examin.

Another project is CinePaint, but I am not so active with it at the moment. Substituting CinePaint’s internal colour management against Oyranos’ CMM framework would cause me frequent updates, due to some newer Oyranos API’s being not stable. But that is something for later.

Then I have a small file previewer called Colori. It just renders thumbnails into a FLTK window. The good thing about it is that it can handle almost any variant from Bob Friesenhahn’s and my own Tiff image file collections. Thus this application serves me as a test bed for creating many colour spaces on the fly. The thumbnails are to be created and need a conversion to screen colours. Running over hundreds of different files and in many colour space variants the thumbnailer is as well my test case for profile load and colour transformation cache balance.

Last but not least, quite some time goes into the work on various proposals and recommendations.

 

Since Oyranos is your main project, can you describe a bit more what it is? What are your plans for it? How does it fit inside the big CM picture?

Oyranos aims to work as a coordinator. It does less of the harder pixel manipulations like Lcms and ArgyllCMS or even profiling in Argyll and LProf. Oyranos connects devices, user preferences, CMM’s (Colour Matching Modul’s) and so on to take over the load of many decisions. Basic Color Management preferences can be set by users in just one place – the control panel. A sample implementation of such a panel exists in Oyranos already.

Of course Oyranos has no GUI preference. Even though the sample implementations come all in FLTK. My FLTK choice came in preparation for the next generation of CinePaint codenamed Glasgow.

 

Colour Management is an area that has seen many recent developments in Linux. To be effective, it has to be part the operating and has a system-wide influence. Do you feel a wide community shaping up for CM in Linux or do you have to “fight” for other parts of Linux to take CM into account in their development?

In a period where many resources go into big desktop projects like KDE or Gnome, OSes and bigger applications, I am amazed to see so many people working on different ends on colour management. They share ideas and collaborate on projects or help in fixing bugs. That without any identity other than to work on open source software.

The biggest danger I see is a single desktop coming with its own “solution”. This would easily end in a CM disaster as a CMS needs collaboration among all parties. A KDE or Gnome only “solution” would drive away many potential users from such a system. We could call this a negative feature. Applications, which handle and display images, need to rely on the same standard. If a tutorial have to explain, why the Desktop A uses a green slider instead of the red choice like in the Desktop B for the same thing Linux has easily outruled itself as overcomplicated. A good CMS is in need to make the already complicated topic CM easier.

Not to forget applications like Mozilla, which fortunately is about to implement colour management, or Gimp running on many platforms, not just Linux. A one desktop only “solution” would be a burden to implement on Vista and Co.

Anyway to see the many communities taking CM seriously and assisting developing and integrating a low level solution with minimal dependencies, as Oyranos aims to provide, is great. We can see interest among distributors and some projects.

I also would like to take the chance to invite people to participate. CM would benefit from help with documentation, translations or polishing web sites (especially the one from Oyranos). Pick something to implement, integrate or port. The projects in question include LProf and Oyranos.

The amount of work can be minimalistic like working from time to time on a Wiki or fixing a bug, maybe a students half year or GSoC range project, and up to serious involvement of a person or even a company or organisation.

 

What do you consider the greatest achievements so far in the area of Color Management on Linux?

At the risk of being blamed for defending a big monopolist, I would mention the fact that Xrite has opened their hardware specifications. Graeme Gill and others build tools to allow device calibration to work under Linux. The use of actual colorimetric devices, like monitor colorimeters, were for a long time a no-go for everybody on Linux and BSD. The now available drivers let open source systems look much brighter for the many of users, which are not able to spend lots of money for a big color calibration system.

As well we see a wealth of graphics applications implementing colour management. I think supporting CM will become pretty standard in only a few years.

 

… and what are the missing pieces?

Being able to plug a colorimetric device and get it recognised by any application of choice would be great. The Sane developers suggested to make this work like a special scanner device. The infrastructure would be in place.

Unfortunately Graeme has licensed his colour management system ArgyllCMS (which includes most colour measurement device drivers) under GPL. This in fact doesn’t allow sharing code with libraries such as Sane.

A widely recognised standard for CM settings including paths and profiles is also much needed for applications.

Oyranos is working towards that goal. It uses Elektra to handle the settings – but we need a way to solve the Elektra dependency. The reason to use Elektra is to see notification, web interface and so on come for free at a later stage. As well I’d like to pack the settings into an object style form to allow easy adding features in the future. Afterwards the standard settings should be integrated into desktop configuration panels.

For the ICC profiles we need an agreement among distributors to accept and distribute a common profile set or find good alternatives for the standard ones, when license difficulties arise.

Some people want to use different Color Management Modules (the colour engine, which does the colour conversions). This should be supported. A CMM framework is needed, instead of most open source applications being forced to use the Lcms CMM backend API directly. For instance Adobe asked about a Linux CMM API. We should be able to give them an answer. The CMM API’s in Oyranos will provide the CMM framework and the frontend API will as well cover all the standard settings and profiles.

This would greatly simplify the implementation work in a final graphics application and a similar CM behaviour among all applications using the Oyranos API’s would become typical.

A user wants to load or create one profile per device and use it everywhere. Currently many ICC device profiles are created and used only in one application. Take PhotoPrint and CinePaint, for instance. Both can print pretty much the same way, but they can not exchange their ICC print profiles without a lot of user involvement.

An agreement on how to connect driver selection / device settings and ICC profile selection would help to overcome this situation. I have outlined some ideas on ColourWiki. For Xorg the profile side has already started to being worked on through Ross Burton‘s _ICC_PROFILE Xatoms proposal.

 

More and more OSS imaging software are CM aware. Is the Oyranos CM configuration framework being adopted by other programs?

Beside CinePaint’s configuration not yet. But I hope we will get there.

 

Speaking of CinePaint, when talking about OSS photography or image software, the name that springs to mind is Gimp. CinePaint is less known. Can you tell us a little bit about it?

Gimp is maintained with a focus on a good UI. It gained much acceptance among a lot of users.

While I tried to collaborate with the Gimp developers, it became clear at some point that CinePaint would be much better for my needs. I wanted to work on a high bit depth image editor. CinePaint, and its name ancestor filmGIMP, provided this right from the beginning. The old Gimp Hollywood branch implemented 16-bit per channel and HDR image editing capabilities into an old Gimp version. The Hollywood branch was officially phased out in favour of GEGL. Later Robin Rowe reactivated this code base as it was behind the scenes continually used in film studios. He found interested people to work on it as a new project: CinePaint.

 

You are the lead developer on the 0.20.x CinePaint series. What do you consider your greatest achievement with this software?

I am happy about a working CMS inside one application. Even if I did not code the first implementation, I carried on extending, modifying and fixing bugs to shape the colour management up to the current state. Unfortunately I had to spend quite some time to stabilise CinePaint or bring it to Gtk2.

Later I found that Scribus had started with CM earlier. But the interest to use an often as buggy experienced CM capable image editor where small. This was in a time where most people in Linux argued, “we need sRGB and that will be all for a good colour management”. Now this has completely changed. A differentiated CM is an accepted topic for open source applications. I hope CinePaint could contribute to this change of mind.

 

What features are you working on for the next release? What else would you like to see included in CinePaint?

I work more indirectly on CinePaint features. As I pointed out above, most work goes into Oyranos. Once Oyranos does completely substitute CinePaint’s internal colour management system, CinePaint will see many benefits coming from Oyranos. Currently CinePaint just shares standard CM behaviour with Oyranos, such as standard profile settings, and it let Oyranos lookup the display profile and profile paths.

With Oyranos used in CinePaint as conversion API we can expect pluggable Colour Management Moduls. At a later stage, we will see better monitor colour correction, hopefully HDR colour handling like conversions and tonemapping and better device profile support.

 

What do you consider the most promising graphic application for Linux?

We see many hopes going into the Krita drawing UI. Krita is a nice application and has a very nice developer community. Unfortunately I did not manage to build the whole block when I tried some time ago. This should have improved. I am not sure how big Krita would be on osX or Windows due to all the KOffice and KDE dependencies.

 

What is your opinion about GEGL?

Node editing seems to me a good concept in GEGL.

GEGL’s colour management would benefit from a more generic approach.

Unfortunately I am not convinced with the Glib requirement as it is based on macros. Macros are a parallel language to the programming language itself (in this case C). Macros advanced under Glib to become a core part of the library design. As the language D is evolving, Glib could find in D a much better suited language than macros, I guess.

But this is just my personal and highly hypothetical point of view. Otherwise I have already considered looking closer at GEGL and I would expect it to have a better chance for reaching general acceptance including in non Gnome communities.

 

Kai-Uwe, thank you very much for your time and giving us so much insight on these topics. We are living exciting times as photographers and as Linux enthusiasts.

Joel, many thanks for your interest.