Øyvind Kolås - interview
From LXF Wiki
GEGL gets an upgrade
One-time graphic student and demo artist, Øyvind Kolås is at the heart of delivering the grail of Gimp developers, the GEGL engine. We went to Montreal, where he was delivering an update at the Libre Graphics Meeting...
Øyvind Kolås, better known to Gimp developers and contributors by the nickname "pippin" seems well at ease. I have cornered him with a cup of coffee outside the main lecture area where the key parts of this year's Libre Graphics Meetings are taking place, and I want to ask him about GEGL, a subject he knows more about than anyone else in the world.
The original GEGL project was first started over seven years ago. The grand idea was to create a graphics processing engine that could be used by the Gimp to deliver on all those things that people often complain about speed, lack of colourspaces, restricted bitdepth support. But the original project faltered soon after inception, only being resurrected when Øyvind Kolås decided to look into it out of curiosity. Now GEGL is firmly on the road map for future versions. So how did he come to be responsible for it? Nick Veitch finds out.
Linux Format: How did you get involved with programming graphics tools?
Øyvind Kolås: I started programming graphic-related things when I was about 13 or 14. I have a dual background with experience in both visual arts and computing. After high school I was deciding what I'd do next. I chose to follow the visual arts and be a graphic designer. So I went to art school and studied in Spain. I applied to various institutions, and I almost got in but didn't. So then I fell back on my other hobby and studied multimedia and computers for a couple of years, and suddenly I was a lecturer!
I have been working on creative tools to create visual compositions. So I'm both a toolsmith and a user of the same tools. When I was starting out, I was into the Scandinavian demo scene. That was my entry point to start playing with graphics on computer.
LXF: Being able to combine both those hobbies must be really cool. Do you think that's something you would always have ended up doing, even if you had got into art college?
OK: I would have continued to use computers I was writing my own small tools even then.
LXF: So it was inevitable?
OK: I was always doing both things.
LXF: Moving forward to the present, you're the main programmer for GEGL, the processing engine that among other uses, will form the heart of future versions of The Gimp. So, how is GEGL going?
OK: The current state of it is that GEGL does exist now, and it does what it was designed to do. It doesn't do it in an optimised way yet, but it has a small public API that I'm quite confident will stay stable for a long time. It has reached the stage where language bindings for C#, Python and Ruby have been created, and it's possible to encourage people to start playing with it.
LXF: I haven't looked at the code for a month or so, can you give me a quick update on what's happening with the latest version?
OK: The latest version is the one that was released just before Fosdem. I had a code sprint in the months coming up to Fosdem, but I haven't had so much time to work on it since then. Development has been rather dormant. In the last month the entire GEGL codebase has been swapped out of my mind. I'm in the process of swapping it back in.
LXF: Do you find it that hard? Is GEGL hard to code?
OK: Some things in there are non-trivial. Right now there are just a lot of fun things that aren't hard to get done, but still just need to be done. Being able to reach the stage where I had a public API for Fosdem was comforting. Now I can go back and change the internals, make it faster and do some refactoring without changing the external API. All the scripts that people make will continue to work, but with later versions it will just continue to get faster.
LXF: That must be a better way of doing it, because you can see a constant, tangible difference.
OK: That's something I've copied from another project. It has been focusing on getting the API stable and being very conservative about what's added to it, but also adding instrumentation to the code to be able to track changes from revision to revision. I also have the ability within the GEGL code to graph the processes and see which are using up the most time whether that's the processing or the pixel conversion.
LXF: Although other people contribute to GEGL, you do pretty much all of it yourself don't you?
OK: Yes. I'm not the original author, but...
LXF: Do you feel like you're on your own?
OK: There have been people helping out. One of the things I've done is try to think strategically about what kinds of things I can do to make it possible for new people to get involved with the project. When I first started resurrecting GEGL almost two years ago, people would contact me and say "what can I do?" and I'd say "I don't know!" I took time to internalise the existing code base, getting to know how it works, and changing the things that they didn't or I didn't like.
Now that the public API is in place, that API is GEGL. It is possible to do a lot more experimental stuff are defined and they do work.
There's another part to getting people involved, and that's the plug-in part of things. That's the part of the API that isn't stable yet. The bit that's stable is how an application would create an image-processing pipeline and configure the parameters for each thing. But for creating new processing elements, there's no such guarantee for that. The reason is the internals need refactoring and restructuring, and there are some features I want to add that aren't in there yet. So if I encourage people to write plug-ins then I would need to fix that.
LXF: How high up your list of priorities is that?
OK: I'm not that far off.
LXF: But every time you put something in, isn't there a temptation to tweak and add more?
OK: There's a rather fixed set of things that aren't possible, but which should be possible. In the course of making those things possible it may be that the behaviour of every single plug-in might have to change. And since I know of some of the changes, I'm very reluctant to publish the API. They'll just become quickly deprecated.
LXF: We talked earlier on the subject of how much time you may be able to spend on GEGL in the future. Is it now considered to be in a fit enough state that someone else could take over if they needed to?
OK: Mmm... yes.
LXF: Would there be volunteers?
OK: I think there are sufficient people interested in it. The code is in such a good state now that it wouldn't take so much time for someone else to pick it up and get going. There is some documentation now, so it's possible at least for someone to do that.
LXF: Much easier than the job you had...
OK: I was very afraid of starting to hack on GEGL. The first time I checked it out of CVS, I looked at it and couldn't make any sense of it. I liked the idea of it. So I wrote my own small prototype image processing library, which was very similar to GEGL, and I also used this for a video editing project. In the process of resurrecting GEGL, it was really a merger of these two projects. The image processor I had already had plug-ins and was part of a full video editing application that could do compositing and special effects. I produced some music videos with a friend of mine using that software
LXF: Cool, were they any good?
OK: Well... one of them featured in some sort of independent video awards, and one of them has aired a couple of times on MTV. So, that was commercial video editing work. The experience from creating that library made it possible to go back to GEGL and think "right, now what is this piece of software supposed to do?" I realised that there were large chunks of the code that didn't have anything to do with other parts of the code. So there were like three or four implementations of the same thing and some of them didn't work and none of them hooked up to the central thing and things.
When we started cleaning up the code, it was the Gimp developers, Sven Neuman and Mitch Natterer who were cleaning it up and making sure it followed the Gimp guidelines. Meanwhile I was trying to shoehorn in these concepts I had in my prototype. That was the summer of 2005.
There was quite a bit happening there, and then it went quiet for a while. Then I created a library called Babl, that was just ripping out the image conversion framework in the prototype. I already had that code, but I separated it out into Babl and then reused that library for GEGL. With the coding I've been doing on GEGL in the last year I've been stealing a lot of my own code, integrating a lot of things I have been doing for the last five or six years into GEGL.
LXF: Is it going to be hard to give up GEGL, if you have to?
OK: Well I don't envision myself leaving that project. It's a fun toy. It's a personal itch of mine to have a library to play with image processing algorithms. I also want to migrate some other experiments to use GEGL at some point.
LXF: As an engine it has a lot of potential uses. Obviously the Gimp developers are interested in it because it will power future generations of that software. But other people should be interested will there be other applications using it?
OK: That's my hope. That's my reasoning behind the bindings I mentioned earlier and getting a stable API. It's about trying to encourage people to start using it and building a larger community around it. There are so many things we won't know until we have many people using it. But also it will be possible to have common plug-ins.
LXF: Even the access to the colourspaces will be useful for some simple applications. There really haven't been any other major projects looking at GEGL yet, have there?
OK: Well, the C# binding is being created by someone who has been involved in working on the F-spot project, and the original Python binding was created by someone who's been working on animation software. There are various things going on.
LXF: It would be surprising if there weren't lots of people interested. Leaving aside GEGL for a moment, are there any other projects you're interested in?
OK: I have quite a few other projects going on myself, and one of the things I'm particularly interested in is user interfaces and UI design. I take a rather experimental approach to user interfaces. At some point I might write something like Aperture or some other photo application. I have been experimenting with a lot of the techniques. I have some wild ideas at the moment, but I'm not sure if they'll work.
LXF: Do you ever feel there's a lot of pressure on you because Gimp is looking to GEGL as the engine for future versions?
OK: Well, it does give me some extra motivation. But it doesn't feel like that much pressure. GEGL is in such a state that once they [the Gimp developers] start using it and wondering why certain things are slow there are capable hackers there who can help out with GEGL.
LXF: I guess there'll be a lot of activity going on then that will be a really good test for how GEGL performs...
OK: When I was talking about things that have been done before, part of those changes are to do with performance and how the architecture will deal with performance demands. There are a couple of known things now, and it's like this is slow now, but when those changes are done...
But that's not a reason for not integrating it, because all those changes will be internal and not exposed through the public API.
LXF: When will we see the first GEGL enabled Gimp?
OK: When it's ready!
LXF: I had thought that it might be sometime this year, but now I'm not so sure...
OK: For optimising work, I have decided to stay on the GEGL side of the fence. For cognitive load, that is both for me and the core Gimp developers they know that someone is working on GEGL and it's working nicely and when the time comes to integrate there's a person who really knows how it works. Ideally we'd want it to happen faster, but it's hard to judge. LXF