Interview: Ã˜yvind KolÃ¥s

Ã˜yvind KolÃ¥s is a Norwegian developer and the main author of the GEGL image processing library of which he recently published the the first tarball. His talk will present the core aspects of GEGL, a graph based image processing and compositing framework. GEGL promises to bring non-destructive editing, high dynamic range, large images and other features to the next generation of the GIMP.

In earlier talks mr. KolÃ¥s focused on the past and the future. This time around it's time to talk about the current state of GEGL. GEGLs capabilities are currently gaining strength and the public API is reaching stability.

The presentation will show how to embed GEGL in an application or script to do image processing tasks, and will explain GEGLs inner workings and plug-in system.

Have you already visited FOSDEM in the past? Did you enjoy those previous editions?

I've attended FOSDEM twice before. Ever since the first time I attended I've regretted not going the times I've missed it. I've enjoyed the people, the talks, and the beer of Belgium; friends back home have enjoyed the Belgian chocolate.

What do you hope to accomplish by giving this talk?

I hope that the talk will expose GEGL to a wider audience and work as a catalyst to inspire others to build projects on top of, further develop, and extend GEGL. I expect myself to have improved the documentation and further stabilized the system as I gear up to do the presentation.

Can you sketch GEGL's history for us?

GEGL was conceived as a replacement for the original image compositing core of GIMP in 2000 by the people responsible for the Hollywood branch of GIMP (which was the basis for the Cinepaint fork of GIMP). The project went dormant after the spark of the initial development subsided. In 2003, Daniel S. Rogers made an effort to fill in the blank pieces but momentum was lost, leaving the codebase with yet another component not fully integrated with the rest of the architecture. In the summer of 2005, in preparation for a merge with another project, three hackers re-indented, reverse engineered and restructured the code base.

What was merged in was the remains of a simpler graph based image processing system called gggl which fueled an "in-house" video editing and compositing system used for creating music videos. A new tile architecture was developed for inclusion as well, this was prototyped in a hyper-sketch application for Nokia's 770 internet tablet (ed's note: see Horizon). GEGL woke up and started processing images in the summer of 2006 and has been improving at a steady pace and now more people are able to understand the system as well as enhance it.

Could you elaborate a bit on the reasons why the project remained dormant for such a long period?

GEGL went dormant before it could either read or write images. Understanding what something is meant to do when there are pieces missing is harder than figuring out what an at least minimally functional system does, and then improve it. In addition to understanding, or guessing, what GEGL was meant to do, restarting development also required an understanding of how to do object oriented programming using C. The combination of these factors turned the projects mailing list into a low traffic echo room.

Now, GEGL can process images. GIMP is going to use it and hopefully other projects will start using it. I've spent a lot of resources on pushing GEGL this far and I hope the project will soon acquire enough momentum to move forward even if I have to reduce my involvement.

So it's not only the GIMP that will be using GEGL?

GEGL is designed to be an independent image processing and compositing framework. The design sets out to mitigate some of the shortcoming of the current design while being usable in other applications and libraries as well. Language bindings for ruby, lua, python, php and others will probably show up soon.

Will you include some Gimp specifics in your talk, or keep it more general then?

I am going to talk about GEGL. The consequences GEGL is able to have on GIMP might be left as an exercise for the audience. Showing prototypes and experimental GUIs built on top of GEGL will hopefully fuel peoples imagination

Speaking of that, your Horizon project shows quite an interesting interface. Where did you get your inspiration? Did you look at some acedemic 'zooming UI' (ZUI) research?

The user interface evolved as a combination of my itch to have a zoomable unbounded digital sketchpad and GEGLs (then future) need for a sparse, tiled, pyramidal buffer architecture. I don't consider horizon to be a real ZUI, I do have plans to try resurrecting a more interesting version of horizon built on top of GEGL, but I doubt that even this version could be called a proper ZUI.

Is GEGL a full-time occupation of you, or does it come close?

The last year I've spent close to a full time position on GEGL in addition to doing the work that pays my bills. Next year my plan is to start a PhD and that might make it impossible to put the same amount of time and energy into it and supporting the technologies that I've been developing in the last three years.
If an institution would offer me a PhD position in a good research environment where my work would be able to directly benefit GEGL I would consider it very carefully.

What's the status of OpenRaster [image file format] currently?

OpenRaster is IMHO something that can develop into a nice baseline standard for storing, and exchanging layered raster images. It builds upon ideas that have been circulating in GIMP development circles since at least 2001. And received further interest and importance with recent momentum of new free software graphics applications like krita, inkscape and scribus. The core of the specification is currently not good enough in my opinion, further research is needed into how layer/filter masks will be represented. The challenge is to create a format usable for simple interchange that also can serve as a foundation for advanced custom native formats.

A last, special question: What's the origin of your nickname "pippin"?

I first read the work of J.R.R. Tolkien when I was 12 years old and enjoyed it a lot. When I gave myself a nick I wanted to pick one that I could somehow identify with. Pippin is the hobbit that is a bit too inquisitive for his own good. He applies his curiosity to his surroundings, and at times, setting larger forces in motion than he can control.