Slashdot Mirror
Interview with Gimp Maintainer
palpatine writes "Linux.com has an interview with Manish Singh (yosh), the chief maintainer of the Gimp project. "
Yosh mentions that they are in a feature freeze now
(and here is the list of frozen features) for Gimp v1.2. Tons of cool stuff to lust after.
I've been using the GIMP since about 0.54 and I couldn't live without it. I scan a lot of images for a family history project, and I take lots of photos with my digital camera. I use the GIMP for all sorts of color adjustment, cropping, touch-up, and special effects in my photos, as well as creating the graphics for my web site.
Although I'm not a professional photographer or the like, I still want to organize and manage my images in a professional manner. In my job as a programmer, I use RCS and directory hierarchies to organize and care for my code -- why shouldn't I treat my images with as much care?
I have needs that GIMP doesn't meet by itself. For example, I want to organize my images. Not just into folders, but according to varying criteria, such as date taken, subject, exhibit (whether an image has been used in a web site or document), etc.
Also, I want to track different versions of my images. I typically keep several versions: the raw scan, the first touch-up (after scratch removal, color correction, and other tweaks), a cropped version (because I might crop differently for different uses), and several scalings: the full original, a 640x480 web-site size, and a thumbnail. I want a tool that helps me manage all these versions, track where they've been used, and jump among them (or call them up in GIMP).
Organizing images is an area that's coming along nicely, with the development of gPhoto and Photodex, but these tools only address that one area of concern. And to be truly useful, they need to be well-integrated with the GIMP, so that one can edit an image with a double-click.
I have heard that Photodex will eventually have integration with the GIMP, but that appears to be some way away. Photodex also has the problem that it isn't open source, and probably won't ever be.
GPhoto shows great promise, but it appears to have some overlaps with the GIMP. For example, it has its own color correction dialog. I'd prefer to see gPhoto integrated with the GIMP for image editing, rather than trying to provide its own. GPhoto has great digital camera support so far, its greatest strength. Good digicam management is another need for a complete image management tool suite.
What about version control? No one out there seems to be thinking at all about this. Maybe because it's a wacko idea -- but I for one would find it useful.
Version control of images needn't be difficult. Of course, you couldn't do it the same way RCS does it, with content diffs. Storage requirements would get way out of hand; just saving the individual versions would require less.
A better idea, one that could be accomplished with the help of the GIMP, would be to record all the mousing, keystrokes, and dialog interaction that goes into the editing of an image; these are the "diffs". This data could be stored far more compactly than storing all the image versions. You could play back the edits on the original raw scan to produce any intermediate or final version. If it takes too long to play back from the original, you could store full binary versions of significant intermediate versions.
None of this is intended to slam the GIMP, Photodex or gPhoto. Just some ramblings on where I'd like to see image management go in the open-source world.
--JT
I've seen various people say things about the Gimp's interface, like: "I don't like it", or "I'm used to Photoshop, so learning a new interface is a pain". Anyway, this idea bubbled up in my brain as I was walking home yesterday:
One of the projects in the Gnome Software Map is libglade, a library which allows an app to load a user interface definition from Glade (the GTK user interface designer) at runtime, thus enabling user interfaces to be changed and used without a recompile.
My idea was, if the Gimp's interface was designed in Glade, and loaded via libglade, surely it would be possible for people to customise it to their heart's content, and enterprising souls could design and release custom interfaces, eg Photoshop clones, for those who need a tool that "just works" and don't have time to fiddle.
(when I was coding on the Amiga, I originally used an editor called CygnusEd. Then I replace it with one called GoldEd, which had an extremely customisable interface, so I could make all the menus, hotkeys, etc. the same as CygnusEd. This was fantastic, but obviously a lot of work for the programmer - surely something like libglade could allow our major applications such flexibility without demanding too much effort from the developers at all?)
What does anyone think?
This is just one of the many ways the open source world manifests its delightful anarchy. If there's only one guy working on Win32 GIMP, it's because only one guy feels like working on Win32 GIMP. If you want more people to work on it, do it yourself, or convince somebody to work on it for you.
People don't write code because The Masses(tm) need it. People write code because whatever program they (or their friends) need doesn't exist, or because the project cool and an interesting challenge, or because someone is paying them to write code, or because they are showing off, or just because they can.
It's all wonderfully banal, and it works fine.
-Mars
There are basically two types of color matching that are relevant. The first is Pantone spot colors, and the second is ICC. The latter is generally what you'd use when preparing photos and related images for CMYK offset printing. ICC is gaining ground, and is used as the color matching standard in such emerging technologies as SVG.
Pantone is basically a named collection of colors. The cool thing about Pantone is that you can communicate Pantone colors to professional printers, and they know how to match it. Let's say for example that you're doing a business card, and you want your logo to be in black and a nice deep blue. By specifying Pantone 280, you can be assured that the printers will produce the same nice deep blue that you intended. Incidentally, it's not hard to find a Pantone palette for Gimp if you're skilled at Web searching.
Pantone colors are far less useful when dealing with natural images. The Pantone palette is only a few thousand colors, while the standard for scanned images is sixteen million. These are all the colors between "nice deep blue" and "slightly deeper blue than that". That's where ICC comes in.
ICC basically specifies a transformation from a source color space (say, a calibrated RGB such as sRGB) to a destination color space (say, CMYK values for your particular printing press). In theory, this allows exact color matches between scanned, displayed, and printed images, but in practice things are a lot more complicated because (a) people don't perceive color the same way from an emissive display such as a CRT and reflected color from paper, and (b) not all devices can reproduce the same range of colors. Category (b) is especially tricky because the only way to ensure an exact color match is to use a lowest-common-denominator set of colors. As you can imagine, that's not a good idea. It doesn't look very good. In any case, ICC goes at least partway to solving these things.
Now we get to the patent problem. It appears that Electronics for Imaging has some patents that cover the generic idea of colorimetric matching between scan, display, and print. These patents have recently been upheld in court, so they'd appear to be pretty strong. I don't see a way around them.
As far as I know, these patents only apply in the United States. There is some very interesting development of color management code going on outside the US. Perhaps in 2003, when the most important of the EFI patents expires, this means that color management will be free for all to use.
Hope this clears things up.
LILO boot: linux init=/usr/bin/emacs
For those who haven't checked out 1.1.x Gimp, you really should It's a horse of a different bitmap. There's so much that's new. The Gimp/Perl plugins (my favorite, as a few are mine) have really come of age. The user-interface is still a little quirky, but gods is it nicer than 1.0.
;-)
The fast unsharp mask is amazing. Try sucking in a photo of some forest scene or people. Use Image -> Equalize and then use Filters -> Enhance -> Unsharp Mask. You will see detail you couldn't see when you were taking the picture!
1.2 is going to really rock. Suck it out of CVS if you want to see the latest, and/or work on the code. There's a great CVS tutorial for accessing the Gimp here:
CVS Tutorial.
Also you can find Gimp News here.
Also, as a shameless plug, you could find out how to write plugins in Perl from my recent Perl Journal article. You can find out more about the Perl Journal at http://www.itknowledge.com/tpj/ It's kind of a funny article, since in it I plug my company, and I no longer work there