You’d have to be crazy to rewrite GIMP in anything — Interview with Ell

There aren’t many things as empowering as seeing a seemingly random person starting to hack on a free software project with a huge codebase and quickly grow into a major contributor that suddenly everyone listens to. So I listened some more. This is an interview with Ell, one of the several core GIMP developers.

Before you dive in, I owe you a disclaimer that I’m a GIMP contributor. So you should always treat whatever I write about this project with no small measure of skepticism.

Oded Nuriel never really intended to become an almost anonymous GIMP contributor of whom, until fairly recently, we only knew the nickname (Ell), gender, and country of residence. It just happened. So this is your chance to get to know him a little more, too.

The screenshots are that of various features he added over the past 3+ years, from the first one to more recent ones.

Everyone starts somehow in a software project. What was your unscratchable itch that got you to begin writing code for GIMP?

My first contribution was the “Diagonal Neighbors” option of the Fuzzy Select tool (AKA the “magic wand”). As much as I’d like to say I needed it for creative reasons (that would make for a better story), I was trying to analyze images for a programming challenge. This involved selecting narrow curves, made up of pixels that are connected either orthogonally (left, right, up, and down) or diagonally. The Fuzzy Select tool could only select orthogonally-connected pixels at the time.

Not having any luck finding another program that could do that, it seemed like a good excuse to check out the GIMP codebase — I needed a break, and it’s always fun to look under the hood of the things we usually take for granted.

Fortunately, adding an option to select diagonally-connected pixels was the perfect task for getting my feet wet: simple, self-contained, and even marginally useful! I sent out a patch and didn’t expect for there to be much more to the story, but here I am.

Oh, so what’s your primary use for GIMP?

I’m a casual artist at best; I do use GIMP to edit images, of course, but my real canvas is the code. For me, GIMP is a creative outlet to try new stuff, learn new things, or just kill time coding something.

I think, a year or two after you joined, I started noticing that mitch [Michael Natterer, GIMP maintainer], who has been around for almost 20 years, started consulting with you on this or that. Meanwhile, I keep hearing how writing C is horrible and too low-level, how badly structured and documented GIMP’s source code is etc. And I’m personally guilty of referring to 1+ mln LOC of GIMP/GEGL code as a really high barrier for newcomers :) But you managed to fit right in. What’s up with that? Do you think C is a really a bad choice for a project like GIMP? Is the LOC count the death of GIMP?

You know, I don’t think I’ve ever heard anyone comment on the quality of the code. We bash it all the time among ourselves, but a lot of it is just banter. I’d actually love to hear that! When you first start publishing your code, your main concern is that someone will actually look at it and criticize it. You very quickly learn that you should be much more worried that no one would bother.

Anyway, I digress. I don’t think that the code is badly structured. Some parts of it are in worse shape than others (and few are downright ugly), but this is unavoidable in a codebase this large, written over a long period of time, by many different people. For the most part, though, I think the code is relatively well organized, straightforward, and easy to hack on. I’ve seen much worse!

C is a low-level language, but this is the level of control software like GIMP needs — image editing is a resource-intensive task. It does pose a higher barrier to participation than some higher-level languages would, but it’s hardly a controversial choice: it’s still a popular language that isn’t going away any time soon. It’s not necessarily my favorite language, but it’s a lingua-franca when working at this level.

The death of GIMP… I don’t think it’ll be the LOC alone — a large codebase is sustainable if you can process it in small chunks — but it does make GIMP more vulnerable to changing circumstances. GIMP will die when the effort required to maintain it stops being worth it. We’re already seeing the strain that the GTK3 transition is incurring, and it’s bound to repeat itself. One day, it’ll stop being worth it.

A while back, I heard you jokingly saying smth about rewriting GIMP in Rust in 2020. I did laugh it off first, and then I was, like, okay, but this is Ell. IS THERE MORE TO THIS?! :D But seriously, you already introduced teeny-tiny parts of C++ code to GIMP for async stuff like paint dabs. Do you think GIMP would benefit from an even bigger rewrite?

Oh, you better believe it! GIMP in Rust 2020 — it’s happening baby!

Seriously, though, you’d have to be crazy to rewrite GIMP in anything. The biggest advantage GIMP has is that it already exists. We already have a foundation to build on, so that we can focus on the more interesting, rewarding, and important things. This sometimes involves rewriting parts of the code (sometimes even in a different language!), but it’s usually a focused effort in service of a more tangible goal.

Moreover, GIMP is far from perfect, and everyone involved is very much aware of that. It has technical debt and false starts. There’s a lot to learn from GIMP about how to write an image editor — it has some very clever ideas that can easily go overlooked when only looking from the outside — but I don’t think it’s worth replicating one-for-one. If you’re going to make changes on such a large scale, you’re better off writing something new altogether.

One argument I sometimes hear from GIMP hat… oh well, GIMP critics, should I say?, is that the team has no clue about image formats, or color science, or image processing algorithms. We can argue all night long whether it’s true. But, in your experience, how much specific knowledge does one really need to know to start contributing to any image editor or writing a new one? How much do you personally learn as you go and what’s your process?

GIMP is a big program. Most of the “exciting” work — the one involving more specialized knowledge — happens “at the leaves”: at the periphery, rather than at the core. The bulk of the work focuses on the rest of the tree, on providing structure and connecting it all together. In other words, there is plenty you can do even without deep knowledge of image processing. Some knowledge of the basic concepts is necessary to make sense of the code, or to write your own, but none of it is too involved.

Personally, I try to find a balance between working on exciting things, and more mundane things (a necessary evil). I try looking for things I haven’t done before, so there’s a fair bit of learning along the way.

The process is not always the same: sometimes I take a stab at something without doing any research first, just to see what I can come up with, and only look at literature, or other software, once I’m more-or-less happy with what I have. Other times, it’s more about trying out something I read or saw somewhere.

From your standpoint, what does it really take to start hacking on GIMP? I know the team usually recommends taking a stab at low hanging fruits like bugs that are easy to fix or small features that are easy to add. What’s your recipe?

It’s not an easy question. I think a lot of people fail to realize that finding something that’s worth working on is part of the challenge. It’s pretty common for people who want to start contributing to ask us “what should I work on?”. Hell, if I had a good answer to give you off the top of my head — something interesting enough to be engaging, valuable enough to be rewarding, and self-contained enough that you could actually finish it — I’d be working on it myself!

I actually don’t think the bug tracker is a very good place to look for project ideas. There’s usually a reason why bugs remain open for as long as they do: they’re either not as simple as they look, or not very interesting (or both!). Bugs in particular, rather than features, are also a riskier investment, because they face a higher level of scrutiny (for better or worse): we want a fix to be right, which can require a certain level of familiarity with the code; new features, especially self-contained ones, get a more liberal treatment.

A self-contained feature that you have a personal interest in really does seem to be the way to go; it’s how I got started. Either way, be prepared to see the work through yourself. I hope this doesn’t come off as cynical — collaboration does happen, and we do love to help out (even if we don’t always have the time or energy) — but ultimately it’s up to you. Paradoxically, the more willing you are to do things on your own, the more likely will others be to want a piece of the action.

Another thing I’ve heard from GIMP critics is that the Dashboard dock is definitely useless for end-users and probably useless for developers. It might very well be the case that we didn’t explain this feature to users well enough (references to a similar feature in Photoshop clearly didn’t work). You’ve been working on it for almost 2 years now, adding small new features etc. What use cases have you developed for the Dashboard over time?

The Dashboard isn’t meant to be used by everyone, but it can be useful for technically-minded users from time to time, for the same reason your operating system — or even your browser — have a resource monitor. It’s not something you normally use, but occasionally this information can be useful. GIMP is a resource-intensive program, and it can quickly gobble up memory when working on big projects; being able to keep an eye on it can come in handy.

As for development, I can’t speak for everyone else, but I use it all the time. In fact, I keep a whole pane dedicated to the Dashboard always open. My initial use for the Dashboard was hunting down a memory leak, and it still gives me a way to see if anything unusual is going on under the hood, even when I’m not specifically looking for it.

Performance logs, which record an execution profile of the program, turned out even more useful. Pretty much every performance-related change I’m making these days is guided by performance logs — mostly ones I record myself, but we also get logs from users. There have been some important performance improvements as a result of users sending us performance logs, especially for environments we don’t normally use ourselves.

There is a strong argument from users that GIMP and GEGL do not make use of AVX/AVX2 at all (and babl only recently started doing some AVX), which badly affects processing speed. Given that, these days, you seem to be the performance guy in the team, what’s your perspective on that?

It’s true that there’s performance to be gained here, but only up to a point. The big-impact changes happen at a higher level: better algorithms, better design, better utilization of resources. Writing hand-crafted code paths that make use of extensions like AVX is specially worth it for code that runs very frequently, like certain babl conversions. It’s not the only example, of course, but don’t expect to see it happening all over the place — we have bigger fish to fry.

If there’s one form of acceleration that could really make a difference, and that we don’t properly utilize, it’s the GPU. GEGL does have OpenCL support, but it’s not in great shape, and it’s not pervasive enough.

Soon after you joined, you were working on some kickass region selection improvement code, then you lost all of that because you hadn’t pushed it to upstream Git, and your hard drive went kaput. Are you still living on the edge? :)

I’d love to tell you that I learned my lesson, and that I religiously make backups now, but… Hey, I did go full SSD since then, so there’s that! Of course, nowadays it’s the norm anyway, so I guess I’m back to square one.

I do plan to get back to the selection-tool improvements eventually, but since it’s something I’ve already done once (well, technically), it’s on the back burner.

You’ve tied quite a few loose ends in GIMP over the past three years. Some of that stuff has been on the blockers list for users for well over a decade. I’d like to think you are just warming up :) So what represents the ultimate challenge for you feature- or performance-wise?

Wow, I don’t think I have an “ultimate challenge” I can single out, just a bunch of bigger, more challenging tasks I’d like to work on, or see happen in general. Most of it is “the usual”: non-destructive editing, vector layers, etc. Some of it is a bit more specific: I have a long-standing plan for a new native file format that’s more suitable for big projects, enabling things like background- and auto-save, backups, and snapshots.

Performance-wise, better GPU utilization is definitely interesting. The more likely next big performance boost, though, is processing the image at a reduced level of detail when zoomed out, which has the potential to make a very big difference for large images.

On a more ambitious level, it’d be interesting to venture into new territory: more powerful vector tools, maybe even 3D and animation. The inroads machine-learning is making on image processing is also hard to ignore, and I’d like to get in on that. In the meantime, though, we have our work cut out for us.