A preview of GIMP 2.8
The venerable GIMP image editor is nearing its next release, version 2.8, but as a decidedly "release-when-ready" project, there is no pre-determined drop date to circle on one's calendar. Judging by builds from the unstable 2.7 branch, however, the next release will have goodies to share with several different types of GIMP user: photo editors, web designers, high-end, and casual.
At the moment, the newest code is version 2.7.3, although the project's Git changelog suggests that there will be at least one more release (2.7.4) between now and a stable 2.8.0. Official development releases are made as source tarballs only, but Linux binaries are available through various third-party sites, such as GraphicAll.org or Matt Walker's personal package archive (PPA). The 2.7-series does introduce some API changes, so exercise caution when testing it out. It will "migrate" settings from ~/.gimp-2.6/ to ~/.gimp-2.7/, but third-party plug-ins in particular are not likely to work without modification. If in doubt, make backups.
Headline features
Each new release of a GUI application is expected to include at least a few immediately-usable improvements, either in the form of UI changes, or new tools and functionality. GIMP 2.8 introduces four new "big toys" in this category.
![[Cage tool]](https://static.lwn.net/images/2011/gimp-cage-sm.png)
The first is the Cage tool, an entirely new image transformation tool that originated in a Google Summer of Code (GSoC) 2010 project. The cage tool allows you to draw arbitrary polyhedral outlines around part of an image, then twist and distort the image within by manipulating the corners of the outline. The effect is something like making a marionette move — with the major difference being that you can stretch and distort the marionette in addition to twisting and turning it. Drawing the right cage is critical to being able to manipulate the image the way you want; fortunately you can adjust the cage on-canvas even after you start distorting it. The tool is also a bit like the "Liquify" effect in Photoshop, in the sense that it allows smooth, "hands-on" manipulation of the image, in a manner that is far more interactive (and thus more intuitive) than traditional distort and transform tools.
The second feature is support for layer groups. As the name suggests, layer grouping allows you to nest image layers into sets, which you can then make adjustments to collectively. Although you cannot paint simultaneously into multiple layers in a layer group, you can move, transform, and hide groups, as well as change their opacity, blending mode, and other settings. GIMP 2.8 also introduces the ability to lock the pixels and alpha channels of individual layers (with "Lock" toggles on the layer dialog box) to prevent accidental changes; this feature can also be used to lock the contents of entire layer groups.
![[Text editing]](https://static.lwn.net/images/2011/gimp-text-sm.png)
On-canvas text editing is the third new feature, and it is one that has been in development since GSoC 2008. The new text editor pops up a miniature editing toolbar that hovers on the canvas over the cursor. From there, you can change font, text size, text color, and text decorations at will, just as you would in any text editor. This editing toolbar allows you to select any text in the layer and change it, so you can incorporate multiple colors and font settings in a single text layer — something that required multiple text layers (and fine layer-alignment skills to boot) in previous releases.
The final new "bullet point" feature is an optional single window editing mode, which you can toggle in and out of from the "Windows" menu. In single window mode, the tool palette and dialog dock (which usually holds the layers dialog) snap onto the sides of the image window. When you open multiple images at once, they are placed into tabs across the top of the window, with a thumbnail for each image.
![[Single window]](https://static.lwn.net/images/2011/gimp-single-window-sm.png)
For a long time there has been a highly-vocal subset of people who swore that GIMP was downright unusable without a single window mode. I have difficulty processing this criticism, because I have never seen anyone articulate something that works better (or is easier to do) in single window mode, or more difficult to do in floating-palette mode. It strikes me as an essentially personal preference; nevertheless, now that single window mode is available, I suppose it will make quite a few people happy. But it remains an option only; for those who find the floating palettes easier to use, the new mode will have no effect.
The fun stuff you might overlook
A second group of new features consists of those changes that either introduce new functionality or provide better usability, but are not big enough to make most lists of "flashy new improvements."
For example, there are several small UI changes that provide incremental
improvements. One is an on-canvas progress meter (using a circular,
stopwatch-like animation), which replaces the flat, bar-shaped progress
meter at the bottom edge of the image window. It appears closer to the
mouse cursor, so it is a better visual cue that GIMP is working on
completing a task. There are also composition guides (such as
rule-of-thirds grid lines) overlaid when you use a transformation tool;
this simply helps you eyeball the transformations that you want to make.
But the most interesting is a new widget for setting tool options. It
combines a "spinbox," a text label, and a slider into a single unit
(several examples are shown at left). You can adjust its value with finesse using the spinbox +/- buttons, edit it precisely with the keyboard, or drag and slide it with the cursor (which is intended to be a particular boon for tablet users). There does not appear to be a name for the new widget (I am secretly hoping for "splader"), but in the code it is implemented as a GimpSpinScale.
Working with brush dynamics (the manner in which brush tools respond to pressure-sensitive tablet usage) is also improved in the unstable GIMP builds. The GUI has been completely redesigned (a GSoC 2009 project), you can edit custom response curves for each metric, and you can change the rotation and aspect ratio of any brush. There is still not quite as much control over brush behaviors in GIMP as there is in a painting-centric application like Krita or MyPaint, but this set of changes offers a noticeable improvement of benefit to tablet users.
Two other changes are also reminiscent of the direction taken in recent Krita builds. First, you can save (and name) your customized brush dynamics presets, and switch between them quickly in the tool palette. There is a more general tool preset system as well, which allows you to save the current settings of any tool (including the foreground and background color selections) to a dock-able "Tool Presets" dialog, and access it in the future with one click. That aids in reproducing tricky settings, particularly where destructive editing is concerned and extended trial-and-error would consume too much time.
Second, a close cousin to the tool preset and brush dynamic preset functionality is the ability to assign keyword tags to resources, and to filter through them by tag. "Resources" in this sense refers to image editing components like colors, gradients, textures, or brushes. GIMP can share resources with a large number of applications (both free and proprietary), and among designers collecting them is a hobby. It is all too easy to amass a large, unwieldy collection if you work with GIMP all the time, so tagging allows you to whittle down the excess. Finally, you can export color palettes used in GIMP into a variety of forms suitable for consumption in other applications — notably CSS stylesheets, PHP or Python dictionaries, and Java color maps.
The truly under-the-hood work
A final category of improvements includes those non-interactive features and utilities that benefit you even if you do not notice them during the typical editing session.
This includes support for new file formats — GIMP 2.8 can now import and export to the OpenRaster interchange format, can import JPEG2000 files, and can export images directly to PDF. It also includes cleanup work like adding new texture brushes and clearing out old and accidentally-duplicated brushes, adding IPv6 support (which GIMP and its plug-ins use to retrieve objects from the web), and adding support for right-to-left languages in the interface. The project has also moved to GPLv3+ and LGPLv3+ (the latter for the library components of the code, naturally), a decision that may not immediately affect users, but is noteworthy for developers.
I also appreciate a few of the minor enhancements simply because they are useful to me personally. For example, GIMP can now print crop marks automatically when printing an image — the checkbox is found in the "Image Settings" tab of the Print dialog. I can see a number of projects where that will prove valuable. Another example is the ability to assign custom function mappings to arbitrary buttons on your input devices. GIMP has allowed this for graphics tablets before, but in 2.8 you can do the same thing for the spare buttons on your mouse, trackball, or jog/shuttle controller. I have been experimenting with mapping Undo and Redo to the extra buttons on my trackball; I am not yet sure if they are here to stay, or if horizontal scrolling would be more useful.
Several of the new features mentioned above are only possible because of the ongoing work to port GIMP internals to new toolkits. For example, the Cage tool is implemented entirely in GEGL operations (the next-generation image processing core being incrementally merged into the application), and the GIMP team has dictated that all new tools be written for GEGL from the ground up, a decision that will affect some work in the next development cycle. But the Cage tool also makes use of GIMP's port to Cairo as the rendering engine, replacing older GDK bits. As a result, the on-canvas controls are smoother-looking and just-translucent enough to let you see some of the pixels underneath them.
The GEGL and Cairo porting work continues, and will not end with the release of 2.8. This release adds layer scaling, layer modes, floating selections, and projection (which is GIMP terminology for compositing layers onto the canvas view) to the list of subsystems ported to GEGL. There is also new selection code, new save/export code, and new APIs for plug-in writers. Documentation (particularly for the plug-in authors) is still forthcoming, although there is activity in the Git repository.
The GIMPs of the future
Speaking of ongoing work, the last major update to the stable GIMP was 2.6.0, back in 2008. The project has made it clear in recent months that it wants to shift to a faster update cycle, and to develop new features on feature-branches to be merged back in once complete — changes which are no simple task given the size of the code base and the small development team. The project's pace has always been a popular target for detractors, but it seems to have staked out a definitive roadmap that covers the completion of long-standing major tasks (such as rewriting the internals to use GEGL) and ongoing feature development.
According to Alexandre Prokoudine at Libre Graphics World, the plan is still to release 2.8 by the end of 2011, a decision that forced the team to delay one or two key features that had previously been slated for the 2.8 release. The next major milestone is now expected to be 2.10, which will integrate the last of the still-unadopted GSoC work: a Warp tool, Seamless Clone tool, a new widget for changing image and layer sizes, functional masks for layer groups, and the porting of all image filters to GEGL. It is not clear whether or not that milestone also includes GSoC work to add a GPU back-end to GEGL via the OpenCL framework or not.
The plan then calls for version 3.0, which will be a "port" of 2.10's functionality to GTK+ 3, and will finalize the transition of internal functions to GEGL buffers. That release will mark the debut of the most-requested feature in recent years, support for editing images in 16-bit-per-channel — and higher — bit depths. The roadmap does extend beyond 3.0, and includes other major enhancements like non-destructive editing, which was previewed as far back as Libre Graphics Meeting 2010, and marks the start of a new development direction — requiring new interface conventions and file formats at the very least.
There are no dates associated with any of the future milestones, but in practice they would not be too useful more than one release cycle out anyway. GIMP is developed without financial underwriting from a major distribution or other open source software company; a fact that its critics tend to overlook when lamenting floating tool palettes or other pain points. Nevertheless, it advances year after year, and the 2.8 release cycle holds a great deal of new functionality for end users. Hopefully it will not be another three years before 2.10; accelerating the development cycle would probably help draw in new users, plug-in writers, and perhaps even core developers. In the meantime, however, there is enough new in the next stable release to keep most people busy for a while.
Index entries for this article | |
---|---|
GuestArticles | Willis, Nathan |
Posted Nov 10, 2011 3:55 UTC (Thu)
by tshow (subscriber, #6411)
[Link] (5 responses)
1) I occasionally have to use gimp on OSX, which has an absolutely broken focus model. Click-to-focus means that if you want to (for instance) select the crop tool and then use it, you have to click on the tool palette to give it focus, then click on the crop tool, then click on the image to give it focus, then click on it again to start cropping. If you forget the second click on the tool palette you appear to have done something but you keep whatever tool was last selected. It's survivable, obviously, but it's like trying to do surgery with mittens on and a little yappy dog in the room.
2) I also occasionally have to use gimp with a very large number of images, and managing all those individual windows can get troublesome. I once (on a windows machine, admittedly) accidentally hit "enter" in explorer with in excess of 3000 images selected. It took nearly an hour to get back enough control to reboot the machine cleanly. Linux doesn't fare anywhere near that badly, but it can still stumble with large numbers of files.
Multiwindow gimp mostly works great when you have sloppy floating focus and a robust window manager. Unfortunately, on some OSs I'm forced to use from time to time, those aren't a given.
Posted Nov 10, 2011 16:31 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
That's not true of all click-to-focus arrangements. In most window managers I've used, there is a configuration setting which controls whether the initial click to focus the window is also passed on to the application, in which case you don't need to select the tool palette and image window separately, just click on the tool and then perform the crop. Normally this is enabled by default.
Posted Nov 14, 2011 17:55 UTC (Mon)
by rmano (guest, #49886)
[Link] (1 responses)
Posted Nov 21, 2011 22:57 UTC (Mon)
by JanC_ (guest, #34940)
[Link]
Posted Nov 15, 2011 3:06 UTC (Tue)
by foom (subscriber, #14868)
[Link]
Of course that isn't an actual feature/brokenness of MacOS. Ever since near the very beginning, there's been a concept of a "tool palette" which floats on top of other windows, doesn't accept focus, and accepts clicks even when not focused. Photoshop's tool palette certainly used to work like that many many years ago. (I haven't used it in a decade or so; not sure how it works now). For a built-in example in OSX, look at the standard font window.
Maybe *GIMP* on OSX is broken in this way (don't know; don't use it either), but you can't really blame OSX's focus model for GIMP being a terrible port.
Posted May 7, 2012 16:11 UTC (Mon)
by dlazaro (subscriber, #38702)
[Link]
That is current as of OS X Lion. If I remember correctly, previous versions had a defaults preference activated through the command line that was described in the Xquartz(1) man page.
Posted May 7, 2012 14:52 UTC (Mon)
by mikemol (guest, #83507)
[Link] (1 responses)
I really don't get why applications such as Gimp or VS2010 can't manage tear-away toolbars and documents, and allow those torn-away to be fully managed by the system window manager. (Heck, even VS2010 fails on this front, which becomes critically clear when you try doing anything fancy in multimon setups)
Posted May 7, 2012 15:17 UTC (Mon)
by rwst (guest, #84121)
[Link]
There is something to it when people say linuxers don't care about the UI. Of course, a generalization, as e.g. inkscape has tearable bars. But when we tried to redesign the whole UI, the sheer size of the code base didn't allow for big refactoring. OTOH, branching the code base by a single coder would have created a multi-year endeavour---just for the UI?
So, it's the casualty of doing coding in Linux, the missing time for big things, and the lack of professional (= paid) leadership, all a bit.
Single Window Mode
Single Window Mode
Single Window Mode
Single Window Mode
Single Window Mode
Single Window Mode
Single-window mode
Single-window mode