An exclusive interview with Martin Nordholts

For a long time I wanted to do an interview with one of the GIMP developers. Then I came across Martin Nordholts (aka enselic) website and read the following description of his involvement with GIMP:

Here is my list of most critical features GIMP needs and which I intend to help bring into existance:

• High bit deepth editing through GEGL
• Non-destructive editing through GEGL
• A completely color managed workflow
• Native CMYK and spot color support

I decided he was the man and bugged him for an interview. So here is one of the core contributors to GIMP telling us about the current state of affairs, helping us to understand what is going on deep inside the GIMP (and GEGL) as well as lifting a corner of the veil about what is to come.

Martin, thanks a lot for taking the time for this interview. For a start, can you tell us a few words about yourself and your involvement in GIMP?

After my first GIMP contribution in October 2006 I gradually became more and more involved and now I am doing more or less daily contributions including fixing bugs, maintaining bug reports, reviewing and merging code and working on new features. I occasionally contribute to the GEGL framework too but GIMP gets most of my time. In my day job I work as a software developer for a well known mobile phone manufacturer.

Speaking from a photographer’s point of view, there is a long wait for features such as color management, higher bit depth editing or “effect layers” to be included in GIMP. Now that GEGL gets ready for “prime time”, how will its use in GIMP allow these features?

When GEGL is fully integrated, GIMP will offer high bit depth and non destructive editing including so called effect layers. Color management is a separate issue and a high quality color management work flow will require work both on the GEGL framework and the GIMP core.

With the 2.6 version of GIMP recently out, GEGL is used in GIMP for some operations. How much more work is there on GEGL to be ready to be used full swing in GIMP?

For GIMP 2.6 most color operations were ported to GEGL. For GIMP 2.8 we are as good as done porting the projection code to GEGL as well. The projection code is what combines the layers into a single composite i.e. image. With the image structure represented as a GEGL graph it is easy to insert non-destructive nodes and I know Øyvind has done some prototyping which as far as I understand was mostly painless.

One could say that GIMP has an isolated core capable of high bit-depth and non-destructive editing. What needs to be done is adapt code so that users can make full use of this currently isolated core. It is impossible and pointless to speculate about a specific date when this will be complete. We can only establish that work is being made and will eventually be finished.

How was the integration of GEGL in GIMP 2.6? Do you feel that the ground work done in the previous GIMP versions is bearing good fruits and the process was relatively simple or would you rather describe it as “painful”?

The work that has been done so far (including for 2.8) has been fairly straightforward. As often is the case it just takes some dedicated time for thinking and hacking.

Now the questions I have been dying to ask for so long (and I am probably not the only one…). How far are we from seeing the different features previously mentioned being included in GIMP? Maybe we can talk about color management first: it is there now in GIMP’s preference and in the image menu. I feel I have all I need for a color managed workflow, but do you plan on adding a few more “bells & whistle” (print proofing)? Does the current code need heavy refactoring to be GEGL compatible?

I am myself interested in improving the color management but I will not put any major effort into it before GEGL is almost completely integrated. Speculating in specific dates is again impossible and pointless. Some hacker might turn up and start working on this right away, or it might take several years before anyone find enough time and motivation to improve the situation.

The next question is about higher bit depth – a subject dear to a photographer’s heart. If a 8bits / channel is being assumed everywhere in the code, I can imagine that changing that assumption means refactoring everything. Is that correct? What are the main challenges to see a higher bit / channel version of GIMP?

Since GEGL is a new framework it really isn’t a matter of rewriting the 8 bpc legacy code, but rather replacing that code entirely. It will make sense to write wrappers for legacy components so that they can be used with the new framework as well, but that’s not really rewriting code. I don’t really see any major challenges regarding higher bit depth, code just needs to be written.

Long term plans does not work well in a project driven by volunteers, but there are some loose plans. If nothing goes wrong GIMP 2.8 will have the projection code ported to GEGL. When that is done the next natural step is starting to really use the new framework and its high bith-depth and non-destructivenss. Maybe GIMP 2.10 will make use of this somehow.

Now what about “effect layers” or even better: non destructive editing (a wicked cool feature, if you ask me)?

Non-destructiveness will be easier because legacy 8 bpc code paths can still be used to transfer data. Higher bit-depth will be harder due the need for new/more general code paths. Color management is the hardest part because it affects the entire image editing pipeline.

This also asks for a question about UI design – image editing is a complex task and a simple UI for a complex task is not easy?

The UI team (mostly Peter Sikking) is giving valuable input. I know there are plans for a user interface to non-destructive features but I don’t remember any details right now.

Are there some more features which you would like to mention?

There have been discussions about a single-window tabb-based interface that can probably interest a few people. Recent refactorings has also made progress towards better handling of the floating selection and support for layer groups which might even make it for GIMP 2.8. GIMP 2.8 will also feature three Google Summer of Code projects that are in progress of being merged, namely simple vector layer support, on-canvas text editing and tagging of GIMP resources.

Where are the areas where GIMP would benefit from help?

I don’t really believe in calling for help. If people are interested in helping they will help, otherwise they won’t. People in all areas are appreciated. Developers, bug report maintainers, website maintainers, documentation writers etc etc.

I know you may or may not be interested in photography 🙂 but what is your opinion on the status of open source software for photography in general?

I must admit I am not very much of a photographer. Photography interests me but I never have time to really do something serious. I am in other words not the right person to judge the quality of open source photography from a professional point of view. But we can all see that programs are constantly evolving and new ones are popping up so the situation is continuously improving.

Playing the devil’s advocate: with RAW developers becoming more and more powerful and able to treat different types of image files, is there still a place for a “good old editor” like GIMP?

What can I say, if some other image editor surpasses GIMP in terms of features then so be it. I suspect though that once we have finished the work we are doing currently doing, GIMP will be very attractive to the people currently turning to dedicated programs for high-bit depth RAW processing for example. I find competition (if one can use that term) nothing but interesting.

Martin thank you very much for your time.