What’s new in GIMP 2.7.0 development release

This kind of version usually gives a good idea of what’s going to be in the new stable version. This time there also is a helpful report by Simon Budig from the annual meeting of the team at Libre Graphics Meeting in early May 2009 :)

OK, version 2.7.0 is out now, and the agenda is:

• Final transition to project files paradigm
• Further transition to GEGL
• Text tool working on canvas
• Tagging of brushes, gradients and patterns
• Brush dynamics enhanced
• View and editing of metadata
• Various user interface changes
• Anything stuck?
• Google Summer of Code 2009
• How GEGL is doing
• What’s next?

I’m leaving a number of changes out of scope of this review: you can see the full list of changes in the announcement, and there will be a full review of stable v2.8 anyway. So let’s focus on things that are most important.

Final transition to project files paradigm

This quite serious change is affecting every single GIMP user except probably those who will try using the new version, be freakened out and refuse to use GIMP ever again.

When you try to save a multilayered image to a JPEG, PNG or any other target file using the current stable version of GIMP, you will be warned that some of the data (layers separation, editable text layers, masks) will be lost. And if you close this file right after that, the data will indeed be gone for good.

What you will see in the new unstable version is that every opened file except XCF is considered imported to a newly created project, and thus saving will be possible only to a project XCF file, thus always preserving layers with blending modes and masks. In cases you just want to edit a single PNG or TIFF file there are two new menu items at your service:

1. Export… (Ctrl+Shift+E) — the usual Save As dialog where you can save your project to a target file. You will need to provide filename and extension. By default PNG is suggested.
2. Overwrite — overwrites the file that was first imported to the project with currently vsible data.
3. Export to (Ctrl+E) — reexports to a previously exported newly created image (not imported from existing file).

So what it boils down to is that if you usually open something like IMG_0001.JPG, edit it and save back to this file, you only need to setup a hotkey for overwriting, teach yourself to use it instead of Ctrl+S and not use adult language in presence of kids when you press Ctrl+W only to find out that GIMP wants you to save changes to the project file you never intended to create in the first place :)

The corresponding spec considers long-term plans to make file format specific saving options a much less pain to suffer from. Work on this has already started and is reported by developers to be ca. 80% done.

This change really might look counterproductive and will surely cause ten extra pages of hatred driven comments at Slashdot. I didn’t really agree with this concept myself the very first minutes after reading the proposal. However after thinking more about this I figured out I was out of fingers to count all the cases when I didn’t save an XCF and then spent minutes to hours recreating complex multilayered compositions (like photos of fireworks) with masks. From memory, months after. So force-saving to XCF definitely has its advances. Besides for simpler workflows you already have free/libre tools like Fotoxx and mtPaint.

In other words we are seing the dawn of days when you have all chances in the world to hear something like “Why would you want using GIMP? You don’t really drive Ferrari to the next greengrocery, do you? Use a simpler app, dude”. The recent attempt to remove GIMP from Ubuntu CDs for being too complex only proves that.

Further transition to GEGL

Just in case you missed the previous report from the “GIMP-3” reality show, let me tell you that the work on porting GIMP to GEGL has already started. And if you are new to the show, GEGL is the next GIMP’s engine designed to make GIMP 101% ready for pro users.

So far GIMP can optionally use GEGL for color tools (with currently useless 32 floating point bit per channel precision) and has a testing interactive tool to apply arbitrary GEGL operations to selections or layers. The latter has even formed a c2g operation fanclub of people who love making b/w film looking images from color photos.

So the new version has another switch, this time in View menu, that enables projection rendering using GEGL. In GIMP a projection is a flattened representation of all visible layers with masks. Which means that GIMP already does graphs compositing for layers and floating selections (you can use File > Debug > Show Image Graph command to visuzlize that). Also, with GEGL based projection enabled blending modes like hue, saturation and value are calculated using CIE LCh color space (which is basically Lab* in polar coordinates).

The list of changes required to make the switch to GEGL complete looks more or less like this:

• make babl and GEGL color management aware;
• make GIMP use GEGL’s data types;
• port more GIMP plug-ins to GEGL operations and implement support for legacy plug-ins;
• make rendering magnitudes faster (I’ll get back to this soonish).

Text tool working on canvas

Hallelujah! No, I’m serious. This awful and unusable text input dialog has finally died. You can still call it (without a pentagram, which is insecure really), in case you just can’t live without it. But why would you want doing that, when you can type in text, select it, cut and paste it right on canvas? Complex text formatting would be even better, and it will come eventually. Patience is a virtue.

GIMP uses pangocairo for all that jazz, so you shouldn’t be having serious issues with complex indic or arabic scripts. And additionally you can now switch between all hinting modes availables in FreeType (which sits behind text rendering in GIMP).

Let’s thank Daniel Eddeland for accomplishing this project during Google Summer of Code 2008 and Mitch Natterer for cleaning up, improving and merging this code to the main codebase.

Tagging of assets

This project was done by Aurimas Ju?ka also during Google Summer of Code 2008. Aurimas worked a lot with Peter Sikking — GIMP’s usability architect. As a result the function works reliably and easy:

1. Select an asset of interest (a brush, a gradient or a pattern).
2. Below the assets list type in name of a tag or multiple tags (using commas), and press Enter.
3. As you type in, GIMP will suggest similar previously used tags.
4. As you work further on a project, you can type in name of a tag above the list of assets (completion variants will be suggested as well) and GIMP will filter assets matching your query for you.

Currently you cannot assign tags to multiple assets. This is GIMP’s limitation which will eventually be fixed. Even so tagging makes management of large assets collections finally possible.

Brush dynamics enhanced

For years evolvement of brush based tools in GIMP was all but active. Thanks to a new team member, Alexia Death, GIMP finally has a user interface and underlying functionality to map various input device events to brush settings. For example you can map speed of drawing a stroke to opacity and color. Version 2.6 featured beginnings of this functionality. The new version enhances them massively:

Also, brush rotation slider was added, so now you can rotate a brush to 180° clockwise or counter-clockwise. Naturally, what you would expect here to be done is reading of stylus rotation event and mapping it to this setting. I’m curious myself if we will see this in 2.8.

Viewing and editing metadata

If you deal with digital photography and, especially, work with serious magazines, you do need being able to specify IPTC or XMP metadata in the images you send for publishing. GIMP never had such a functionality and one had to use external tools to change metadata.

Work on internal viewing and editing of metadata was started by Raphael Quinet long time ago. Unfortunately he couldn’t finish it, but what was done has served as a starting point to Roman Joost who is better known for his excellent work on GIMP’s official user manual.

Right now you can only view Exif and XMP metadata, but not edit it. The short-term goal is to enable defining Dublin Core metadata, saving to XMP file and probably cleaning up the dialog itself.

The task doesn’t seem to be difficult at first sight, but Roman has very little experience of C and Gtk+ programming. The original code was already turned off before in version 2.4, so I do hope that he can accomplish this project.

Various user interface changes

There is a number of UI improvements, some of them quite long anticipated. I’ll list few here.

My personal favourite among them is simple calculation in entry widgets. For example, while scaling you can now input ‘3472px + 213px’ and get 3685px:

Or you can do something like ‘570pt / 2cm’: you can actually mix various units. The calculation table lives in Edit > Units, so you can add your own units.

The next visible change that will take some getting used to is reordered list of layer modes. The modes are regrouped to represent the way they visaully affect an image. The groups are now:

• Normal, Dissolve
• Lighten only, Dodge, Screen, Addition
• Darken only, Multiply, Burn
• Overlay, Soft light, Hard light
• Difference, Subtract, Grain extract, Grain merge, Divide
• Hue, Saturation, Value, Color

Took me about two or three weeks to not try looking for a particular mode where it’s not anymore, but the final layout makes a lot more sense in the end. Thank you, Martin :)

Another change seems to address a particular feature request. At least I heard this complaint from one user: earlier, if you created a selection and switched to some otehr tool, you couldn’t see information about selection’s position and size. Now the Pointer dialog has this information:

Anything stuck?

It’s quite typical for any kind of software project to have some code that isn’t ready to be exposed to users, for one reason or another. In this case we have:

• Vector layers. Most work on integration of this GSoC'06 project was done by Mitch Natterer earlier this year. The rest of it is actual user interface and undo/redo support. Back in June Pete Sikking, the GIMP’s usability architect did a three days long with four students groups and suggested working out UI for vector layers. Peter has already blogged on the results. So first there will be a spec, and then it will be implementation time. From what you can see it’s possible that another missing feature, sane drawing of geometric shapes, could be implemented as part of this project.
• Python scripting improvements. This GSoC'08 project is quite important, because it makes Python scripts as full-featured as any plug-in written in either C, C++ or ?# . For instance, preview areas can be created. If you want to know, when this project will be merged, ask the student’s mentor or the student himself :)

Google Summer of Code 2009

This year GIMP as a mentoring organisation has six projects. Two of them are directly GIMP related:

1. Zhenfeng Zhao continues work on brush dynamics started by Alexia in 2.6 and under her guidance. One of the goals of the project is to implement UI for editing response curves for various input device (like a Wacom stylus) events. The student works closely with both mentor and Peter Sikking who is refining the functional specification instantly.
2. Yi Ding works on the existing foreground selection tool. During last several year all major companies and software projects have done some work in this area (even Microsoft). GIMP was among the first to do it, but lost the pace, while the underlying technology called SIOX wasn’t fully implemented, and the tool itself wasn’t quite speedy. So the student is adding a refining brush that will make selection of complex objects like hair or clouds much easier. Or, rather, make it possible :) She is mentored by Gerald Friedland who is inventor of SIOX.

GEGL has four projects and two of them address a long-standing issue with lack of high quality resampling when scaling or transforming images:

1. Adam Turcotte is busy porting Nohalo Level 1 and Snohalo Level 1 samplers from VIPS to GEGL and implementing new Nohalo and Snohalo Level 2 and 3 samplers, each of them to be automatically chosen according to a user-defined quality value. Sample images are uploaded here.
2. Eric Daoust is implementing better and faster downsamplers and resamplers.
3. Henrik Akesson, who made a pretty good impression of himself before GSoC, is doing a study of GEGL’s perfomance flaws. Results of his automatic testing suite will be uploaded later. What’s interesting is that he is mentored by lead VIPS developer John Cupitt.
4. Jerson Michael Perpetua is working on implementation of GPU-based buffers and operations in GEGL. Unfortunately this student went off radar about two weeks ago, having had left only some code he committed around midterm evaluation time. (20090818 — the student is back and rocking again)

The whole GPU thing needs some extra explanation. For some reason a lot of people think that use of GPU alone automatically boosts perfomance, and this statement has a lot of clauses. Modern GPUs, while doing calculations much faster, do not pass processed data back fast enough to make a big difference. And if there is a lot of data to process, you might even lose in speed of processing. Basically they are technically limited by design, and effective use of GPUs will be possible when they have a much fast bus and become multicore. If you don’t believe me, would you rather believe Adobe employees? :)

GEGL developers, however, would prefer going further than low-level GPU based processing or multithreading and rather work on high-level parallelization, when tasks can be distributed across CPU cores, GPUs and hosts in a network.

We are probably close to a point where GIMP + GEGL vs. Photoshop + PixelBender sounds like a fair competition.

Last thing that has to be mentioned here is that today is beginning of the last GSOC’s phase when students stop committing code.

How GEGL is doing

Much better than three years ago, but not good enough to recommend it to anyone as a drop-in replacement for existing graphics libraries. While having a superior design, it is still too slow for production.

Even so a number of projects using GEGL is growing. The first one, if you recall, was gnome-scan. All other tools are more or less photography workflow tools.

The second GEGL based project is a slowly evolving Lightroom-style tool called Niepce Digital. Unfortunately Hubert is torn between his projects — Abiword and gphoto — and recently he started a new project called Gnote which is Tomboy, a notes taker, rewritten in C++.

The third project is another Raw workflow application. Johannes Hanika chose a somewhat predictable name for it: Darktable. Judging by changes in SVN the project is quite active, version 0.2 was recently released and already there’s a bunch of changes done after that. Right now Darktable relies on LibRaw and ImageMagick, and use of GEGL is optional. But thanks to GSoC students this can change soon. The app has plug-in architecture (almost) from ground up, so one could extend its functionality by, let me put it this way, adding hands (hello Shiva, the swiss army god) and not trepanating the skull.

Finally, the long-term plan for F-Spot is to also use GEGL. C# bindings were written by Ruben Vermeersh over a year ago, but they are still not really used by the application, even though Ruben is doing a GSoC project this year to bring basic Raw functionality to F-Spot.

What’s Next, or The Future is (B)right

GIMP developers are famous for having grown to dislike making forecasts and setting roadmaps. One could only try to do it instead of them and be blamed then. Which people actually do. I can hear them saying things like “Native Lab* is going to be in the stable version, I do know that” or “Hey, but I’ve heard that GIMP has a full implementation of CMYK after all!”.

Ah, CMYK :) During LGM'09 Peter Sikking presented two usability projects, one of them being a concept of support for CMYK as a subset of plate colors. You probably read the epic thread in developers mailing list, eh?

To cut the long story short, the plan is to implement a kind of mastering mode where the original image will be preserved in its color space (RGB) and the whole work will be done on projection, for which various tools will be available, from selection tools and filters like unsharp mask to special tools like trapping. That is, there will be no SCHMUCK image mode, but the target image can consist of arbitrary channels. And if you open (err, import :)) a CMYK TIFF or PSD file, GIMP will transparently go to the mastering mode. It’s not quite clear which version of GIMP will feature this, but that definitely won’t be in 2.8.

The second project presented by Peter is the further work on user interface. That’s exactly one of the main things that make people go blue in the face while telling everyone around how bad GIMP is. It looks like transition to tabs based UI will be done while working on 2.10. And indeed this is quite a while to wait for, unless some ubercool hacker joins the team to work on the new UI.

Same is about proposed merge of transformation tools (scaling, shearing etc.) into one. Initially (before 2.6 was released) it was planned for 2.8. The work on specification seems to be mostly complete, but right now the project is considered low priority for 2.8.

So, will there be any surprises in 2.8? Probably not. However, there are features work on which was started in one way or another, but then postponed till 2.10.

One of them is an existing patch that adds opening, editing with color tools and saving a PNG file in 16/32 floating point bits per channel mode. This decision was taken, because PNG is just not enough, and because high bit depth should be available for all filters, not just for color tools.

In fact, some filters are kind of ready for that. I’m specifically talking about Liquid Rescale (or, rather, liblqr) which can work in 64bpc mode and a number of color spaces including L*a*b*. But if you had that patch applied, you’d be back to the times of Photoshop 5 and 6 which converted images to 8pbc and back to be able to use “legacy” filters. And what’s the point? Now, the sooner file loaders and savers are ported to GEGL, the closer full GEGL integration to GIMP is, if you catch my drift.

Another feature that is partly implemented is long anticipated grouping of layers. It’s not quite clear right now if it will make it to 2.8 or not, but foundation seems to be in place. In fact, it was removed from UI right before releasing 2.7.0 because not everything was working.

So, I’m telling you all of the above not-to-be-done-right-now things for just one solid reason. There is a shamingly popular notion that GIMP developers are idiots who have no idea what real users need and want and who don’t care about that. And to make this crystal clear let me sum up main directions of actual development:

• addressing long-standing functionality issues (samplers, SIOX, metadata);
• work on speeding up the new engine and its integration into GIMP (Henrick’s GSoC project, GEGL based color tools in 2.6, GEGL based projection in 2.7-2.8);
• work on foundation for the bright GPU-based future (Jerson’s GSoC project);
• cleaning up the usability mess (changes in 2.6 and 2.7.0, Peter’s work on UI specs);
• making GIMP better suited for digital artists (Alexia’s work in 2.6 and 2.7.?, Zhenfeng’s GSoC project).

And let me remind you that these days they are just a handful of developers, not a huge team like Mozilla, while the project is at the same level of complexity and code base size.

So they do no epic advances and slowly, but surely are moving in the right direction, which is most commendable, in my opinion. You wouldn’t want them go down to a niche already full with Photofiltre, Paint.Net and the like, would you?

As for the date of 2.8 release, it isn’t really set in stone, but according to what some developers say, end of 2009 looks quite realistic. If you took as a starting point notes that Simon Budig did during developers BOF at Libre Graphics Meeting earlier this year, you would see that of all the tasks marked as obligatory for 2.8 are done. Only merging two this year’s GSoC projects, extended brush dynamics and SIOX improvement, is left. Export/Saving spec’s implementation that is marked as optional can be considered as obligatory now, since it’s already ca. 80% ready, as Martin Nordholts says, and he is the guy who works on that.

And the very last thing. The previous stable version, 2.6, while not having a lot more features than 2.4, had pretty benevolent feedback. I’d even say, unexpectedly benevolent. Which leads me to conclusion that despite of years of slow evolution GIMP is still in demand by users.