1 JANUARY 1997
Spencer Kimball & Peter Mattis

by Zachary Beane

Spencer Kimball and Peter Mattis are undergraduate students at the University of California at Berkeley. They're responsible for creating the GIMP. Version 0.54 is out right now; version 0.60 is in the works.

They agreed to answer a collection of questions for an interview via email. Peter did most of the writing.

Your home page says that you created GIMP to address the lack of free or inexpensive Unix graphics tools. How did you guys actually get together to tackle this? Was it like in Blues Brothers? Were you on a mission from God?

Spencer was my brother's roommate for four years. (He's been my roommate for the past six months). So I knew who he was when we decided to take the compilers course here together. Big mistake. During one of the impossibly boring assignments we decided we wanted to do something which wouldn't suck. The idea of doing the GIMP actually fell out fairly naturally.


We wanted to
do something
which wouldn't
suck.

It took us a little while to come up with the name. We knew we wanted an image manipulation program like Photoshop, but the name IMP sounded wrong. We also tossed around XIMP (X Image Manipulation Program) following the rule of when in doubt prefix an X for X11 based programs. At the time, Pulp Fiction was the hot movie and a single word popped into my mind while we were tossing out name ideas. It only took a few more minutes to determine what the 'G' stood for.

And to make the matter clear, the GIMP originally stood for General Image Manipulation Program, but has since been dubbed GNU software by Richard Stallman (with our agreement). Spencer and I decided that GNU Image Manipulation Program is a better usage of the 'G'.

How have people reacted to GIMP? What's been the biggest surprise or the most unexpected result of creating and releasing GIMP?

The reaction has been very positive and much larger than either of us expected, given that it still isn't finished. The biggest surprise is probably the level of fanaticism. Both of us are firmly aware that the GIMP is not yet up to Photoshop's level, yet many people have written stating that it is "kicks Photoshop's butt". That surprised us. We're also surprised and amazed at the quality of images that can be produced with the GIMP. Neither of us are artists. The GIMP homepage suffers from this fact when viewed in comparison to some of the other GIMP web sites.

Is GIMP a side project or the main event for you? How much time does it take away from your "real life"?

I would say that GIMP is a side project and that school is the main event. When not busy with school work we both spend much of our time programming. Of course, every now and then a distraction occurs and school work has this annoying habit of consuming my time near the end of the semester.

GIMP has a definite Photoshop feel to it. What programs did you use for inspiration? What were the features you had to have in GIMP that weren't available anywhere for Unix?

We've used Photoshop as the basis for functionality the GIMP needs. I used Photoshop quite a bit on the Macintosh which is the reason we knew it was such a cool program. Everytime we complete a feature we look to Photoshop for the next item to add. This will eventually stop as we're quickly running out of features to add.

The main feature that the GIMP had to have that wasn't available elsewhere in free software for Unix was plug-ins. Other than that, we also decided that undo was very important. Unlimited undo has made Spencer's life tough at times and in the past he cursed it regularly, but it has made the GIMP a much more usable program.

What are some of the features that you have planned (or implemented) for a future release? You mentioned that it's not up to Photoshop's level, but what features (for you) would put it in the general vicinity?

In previous version images used a linear memory scheme where pixels were laid out consecutively in memory. While simple, that scheme has definite problems with large images. The latest development versions of the GIMP have switched to a tile based memory management system. It's now possible to work images that are larger than physical memory fairly efficiently. In fact, the biggest limitation on image size now is probably disk space.

The plug-in API has also been expanded and generalized. This was necessary in part due to the need for the plug-ins to be able to deal with the tile based images, but it also means a lot more. The main GIMP application maintains a database of procedures. These procedure allow plug-ins to access much of the GIMP's internals. Additionally, plug-ins actually install themselves in the procedural database which will allow plug-ins to be able to call each other. The mechanism is sufficiently general to allow a scripting language to eventually be added as a plug-in.

Spencer has recently added many of the color correction dialogs found in Photoshop, such as Hue-Saturation, Color Balance, Brightness/Contrast, Threshold and Posterize. These have been needed for a long time.

Do you see any technical limitation to Linux/Unix/X that may give you problems taking it to that level?

SysV shared memory has always been a sore spot. The main problem is that there are limitations on the size of a shared memory segment and on the number of shared memory segments the entire operating system can support. However, this problem has been greatly reduced with the tiled images as only a handful of small shared memory segments are needed at the moment and the plan is to allow for operation when shared memory is completely unavailable.

Plug-ins were another troublesome area. Dynamically loading code seems like the best option but it's difficult to do in a portable manner. If we were starting off writing the GIMP today we probably would have used the ELF dlopen family of functions and tried to adapt it for different systems. But at the time we started a.out Linux systems were still the majority as ELF was only starting to emerge. It turns out that making plug-ins entirely separate processes was a good idea. A bug in a plug-in will not cause the GIMP to crash. (Make that, a bug in a plug-in shouldn't cause the GIMP to crash). And by being separate processes it paves the way for having plug-ins run on separate server machines or in a distributed environment.

Are you going to implement any drawing primitives at all, like lines and circles and things like that? Why/why not?

We probably won't implement them for version 1.0. We're a little resistant because our original design specified the GIMP as an image manipulation program and not a painting program. However, they would be fairly easy and it's likely they'll be added sometime simply because we get so much demand for them.