Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature
A first look at GIMP 2.4
Share
Print
CommentsIf you'd like to get a look at the new features before the release, you can download the development version, and be sure to read the release notes for 2.3 for new features and known issues.
New tools
The first thing most users will notice about 2.4 is the addition of three new tools to the palette: the Align tool, the Foreground Extraction tool, and a new "Simple" Rectangle Selector. The Align tool lets you vertically and horizontally align image layers -- a task you had to perform manually before. You can align an image to any edge or the center, specify an offset in any direction, and adjust vertical and horizontal alignment separately.
| |
| GIMP toolboxes compared; version 2.2 left, version 2.4 right - click to enlarge |
The "Simple" Rectangle Selector marks a rectangular portion of the image, after which the boundaries of that rectangle can be moved and resized by hand without affecting the underlying image. It is a bit like having a "live mask," letting you work on portions of the image separately without re-selecting. Unlike the basic selection tools, selecting a portion of the image with this tool and adjusting that selection are difficult to mess up. I know it doesn't sound like a big deal, but for tasks like previewing and tweaking a crop this is a very nice enhancement.
The Foreground Extractor is quite a little marvel. With it you can pull any object out of a picture, regardless of the surroundings. It uses the Simple Interactive Object Extraction (SIOX) algorithm, originally developed for use in the E-Chalk distance-learning tool. First, you simply draw a loose outline around the object you wish to extract. Then, you scribble over "representative" portions of the foreground object and voilà -- the algorithm magically finds the edges of your object.
You can read more about this feature (including a nice tutorial) at SIOX.org. Creating tabloid-worthy phony images just got a whole lot easier.
|
| |
| The Simple Rectangle Selector masking off part of an image - click to enlarge |
In addition to these new tools, several existing tools are significantly enhanced. The airbrush tool now responds to pressure (on a pressure-sensitive tablet) like a real airbrush. The clone tool can rubber-stamp from all visible layers instead of just the active layer. And you can now load and use native Photoshop brushes with the paint tools.
|
| |
| Extraction action with the SIOX foreground extractor tool - click to enlarge |
GIMP 2.4 has new actions in the menus as well. "Snap to Canvas Edge" and "Snap to Active Path" are now options under View. "Remove Alpha Channel" is new under the Transparency menu, and a "Recompose" option has been added to the Mode menu. "Desaturate" can now use any of three different methods to remove color.
Under the hood, a new interpolation method called Lanczos has been added for all scaling operations. It outperforms the old champ, cubic interpolation. Scalable Vector Graphics (SVG) cut-and-paste now works between GIMP and other applications. The GIMP 2.4 also has full drag-and-drop capability for image data, layers, and channels. For example, if you want to make a new image out of the blue channel only, just drag it from the Channels list to the toolbox.
Reorganization
Its developers made other changes for 2.4 to meet GNOME Human Interface Guidelines (HIG) and Freedesktop.org standards, and in response to user requests.
In the first category are the usual gang of capitalization, internationalization, and user interface (UI) element fixes. The Delete key now deletes/erases the current selection -- a feature prevented by a GTK bug in the past. Button order for dialog windows and pop-ups is now read from the user's system preferences, adhering to either the GNOME or KDE standard, depending on which environment is running. And the default measurement units are now determined by the user's locale setting, which should postpone the metric/imperial armageddon for at least a few tense months.
A lot of work has gone into cleaning up the menu structure in 2.4. Color operations -- previously relegated to a sub-menu under Layer -- have been granted a top-level menu of their own. This is a long overdue change, since these are among the most-accessed features of the application.
Plugins and filters have undergone a polish as well. All plugins and filters now support a live "preview" box. Several have been renamed for clarity's sake. The menus for plugins and filters have been cleaned up as well. While 2.2 had separate top-level menus for the Scheme scripting engine Script-Fu, the Python scripting engine Python-Fu, and an assortment of video-related filters and actions titled Video, 2.4 places both scripting plugins under the extensions menu Xtns, and merges the video effects in with the other filters.
Color management
2.4 is the first GIMP release to support color management, a feature dearly missed by photographers and designers up until now. In the preferences dialog you will find a new Color Management control panel where you can set rendering intent and specify your working colorspace and device profiles.
|
| |
| The new color management control panel - click to enlarge |
GIMP is also one of the first applications to support the new ICC Profiles in X specification, which associates ICC color profiles with X displays at the X server (rather than the application) level, although for the time being it doesn't offer any advantage over picking your display profile manually.
Color management at this time is still a work-in-progress. For example, you cannot transform an image from one colorspace to another within the program. But it is great to see color management finally make an appearance in the GIMP. For more information about color management and its usefulness, read this introductory article I wrote in March.
Room for improvement
As always in software, there are areas for improvement. The most fundamental shortcoming of the GIMP, according to graphics professionals, remains its limitation to grayscale and RGB image modes; press-ready images need CMYK and many designers make heavy use of Lab color and duotone (tinted) modes. Second is its limitation to 8-bit color -- as high-end scanner and digital camera prices drop, more and more people need to work with 16-bit-per-channel data. Fixing either these issues will require rewriting a significant portion of the program's core.
The GIMP developers know this, and the long-promised port of GIMP internals to the new Generic Graphical Library (GEGL) is their solution, but it has been pushed back to a future release. As GEGL was first proposed five years ago, some -- understandably -- wonder whether it will ever see the light of day.
Apart from massively reworking the core, however, there are a few bits and pieces to which I would like to see improvement in the short term. Better support for image metadata and additional digital camera RAW filetypes would help professional users, for instance. And many Photoshop users want to see additional tools like a "history" brush or a polygon tool. The addition of surface textures and "natural media" effects, while not critical, would certainly be fun to see.
On the whole, the GIMP 2.4 release is a much bigger step up from 2.2 than 2.2 was from 2.0. The GIMP is still missing a few features, but the list of things you can't do with the GIMP keeps getting smaller with each release.
Comments
on A first look at GIMP 2.4Note: Comments are owned by the poster. We are not responsible for their content.
<a href="http://gimpfoo.de/2005/10/06/an-early-glance-at-gimp-on-os-x/" title="gimpfoo.de">http://gimpfoo.de/2005/10/06/an-early-glance-at-g<nobr>i<wbr></nobr> mp-on-os-x/</a gimpfoo.de>
Another option is
GTK+-Cocoa, but this will probably require some development work to port.
Russ %-)
Yea, who needs Photoshop? The Gimp is just as good. Woops, I mean the Gimp is even better than Photoshop! Good grief...
The only thing I really hate about GIMP is having a billion windows cluttering up my taskbar. I can't simply minimize the whole app in one click-- so irritating.
That depends on your window manager settings. I almost never minimize windows, but I do have a keyboard shortcut that iconifies or de-iconifies all gimp windows at once. So far I used it maybe twice.
The only thing I really hate about GIMP is having a billion windows cluttering up my taskbar.
That's the purpose of workspaces. On GNOME, I just use Ctrl+Alt+RIGHT and LEFT to navigate between workspaces. I heard that even Window$ Vista is going to include such a feature. (or maybe I'm mixing up my stories.)
Maybe it's just old habbit, but I want my programs to use a single window (not taking more then one place in the taskbar, per instance) and I don't want programs in a group on my taskbar, if I can avoid it.
I like the GIMP, really I do, I'd love it if they just made it into a single window.
Its a neat, albeit cumbersome and slow, tool suitable for graphic artists and amateur photographers who are willing to take the time to learn it and live with its many shortcomings. But its a poor substitute for Photoshop and its evolved at a snails pace. It's also poorly designed(not that Photoshop is great btw) and they have turned a deaf ear towards end users who rightly or wrongly "want their free photoshop".
I for one do NOT envy trying to copy photoshop, that's got to be hard as heck. But that's what Gimp devs decided to do so they can't complain when users try and it out and then complain about it's shortcomings compared to Photoshop.
The bottom line is Gimp simply isn't where it should be by now. If we are very luckly in 5 years it will be equal to Photoshop 5.0, but don't hold your breath. Among OSS tools as they compare to their commercial couterparts GIMP comes up lame(to use a bad pun). Compare Firefox, OO.org, Thunderbird, Evolution, Gaim, etc. Look at how fast they evolved into useable drop-in replacements in the 3 to 5 years. Now look at Gimp. See something wrong here? Talk about stuffing new features into product without fixing what's wrong.
Gimps need either A) a corporation to adopt and fund it or B) rethink what it wants to be.
I'd love to see an offshoot of the project into a modern version of Photoshop Deluxe/Picasa. Make a nice image management module and make a dozen simply adjustments instead of 4,000 different looking tools which all look and act differently.
Barring that, clean house and start over. The path Gimp is on isn't leading anywhere good.
Gimp is not slow, especially compared with PS.
Gimp interface is not cumbersome. PS interface is particularly cumbersome. Since they do not change it with time, it is getting very bad. Gimp interface is adjusted, so it is much better.
Gimp has lots of features that PS does not have (the opposite is true too of course).
I love Free Software, and help when I can,
but this project needs a rm -fr and redo from start.
A lot of the problems of GIMP are there since a long time, and are the clear result of initial bad design.
This is one of the cases where an alternative, redundant project would be _good_.
Actually, you can with Gimp 2.4 (well 2.3.x). Got to Preferences->Window Management. You can choose there to have all docks "transient" to the image window. Thus, when you minimise the image window, all windows will minimise with it. It works.
It works with a decent window manager (Metacity, probably KWin). For Gimp 2.2, you can also achieve that with some decent Window Managers too (the good old E16 comes to my mind, but probably fluxbox also can do this)
Re: You can minimise in one click in Gimp 2.4!
Posted by: Anonymous [ip: 80.176.132.122] on August 25, 2007 01:01 PM'I can't simply minimize the whole app in one click-- so irritating.
I can, it's disabled by default for compatibility reasons, set the right window hints in the preferences.
BTW, may I ask why you are doing this comparison to Photoshop? I haven't seen anyone claiming here that GIMP would be better. If you are happy with PS, just keep using it (and paying for it).
Are you kidding??? The article itself does not make any claims against Photoshop but, the Open Source community has always thrown out the Gimp as being "just as good" or even better than the Gold Standard of image editing applications, Photoshop.
Photoshop comparisons are standard from Gimp proponents so it is a completely fair comparison.
ICC is the International Color Consortium (www.color.org). ICC color profile support is about display management, and ICC profiles are used by all color managed systems.
Pantone is unrelated. The Pantone colors are a commercial set of spot colors, which allow you to reference a spot color by pantone number; they exist outside of "CMYK" or other color models.
Free software apps that support spot color (say, Scribus or Inkscape) can in fact use Pantone colors; you just have to tell the printer the swatch you want yourself or search for a Pantone-clone color tile set.
These apps can't distribute Pantone clones for legal reasons, but professional designers know you always have to talk to your printer about spot colors, and you always have to see real proofs before you go to press. If you only have free software, you can still do that, and the real skill that separates good designers from bad is the ability to choose correctly.
The only real issue with Gimp in this regard is spot color handling, which again we will see with GEGL at some point.
pnmtotiffcmyk - convert a portable anymap into a CMYK encoded TIFF file
You could probably even write a script-fu to do it.<nobr> <wbr></nobr>.. am I missing something?
btw, maybe it would be a good idea to do a fork of the gimp into an application directed mainly at screen design work (as it currently is, actually) and one directed at press-ready touch-up and editing (which is covered *at most* marginally in the current incarnation). remember basic *nix philosophy: do one thing well. and be able to combine dedicated tools into larger, complex workflows. there is no reason why this should not be possible within a GUI.
Read at:
<a href="http://www.behrmann.name/index.php?option=com_weblinks&task=view&catid=67&id=56&Itemid=85" title="behrmann.name">ICC Cmyk introduction</a behrmann.name>
Features include:
- native Cmyk editing (paint, curves, levels<nobr> <wbr></nobr>...)
- softproofing (Cmyk -> monitor Rgb)
- hardproofing (ink-jet -> offset match)
- 16-bit cmyk printing through the very good Gutenprint printer drivers
If you can't/won't and Gimp doesn't do it for you, walk to your local software store and get what you need.
Actually Adobe doing the same on their suite - windows are now detachable now and can be spread over the course - where you want them. So concept is very good one - just people aren't use to it.
It figures. I finally gave up on using stone tools (i.e. GIMP) last week and bought Photoshop. Maxxed out my plasticards, but at least I finally have a REAL image editor.
And now, the morning after I install PS on my newly-aquired used Mac, I find that the GIMP is FINALLY going to support color management! (well, sort of).It's Murphy's Law all over again. Oh well, GIMP still doesn't do 16 bit per channel color, so it's still unusable for pros (or anyone doing any kind of serious photography).
(the only place I personally find an 8-bit channel a noticable limitation is grayscale ("black and white") images).
The problem is that real world images do not fit into this 8-bits-per-channel total nicely or evenly. For one thing, you can distinguish a lot more gradation in the green channel than the blue. For another, any particular image may need to show more detail in certain parts of the spectrum. That's possible because non-eye sensors like CCD's, photosensitive chemicals (ie, "film") and so on can distinguish more than 16.7 million colors, or whatever the local total for the color in question is. When you look at a nice photo of a bunch of red chameleons blending into red rocks in National Geographic, it's been tweaked and shifted to bring out all that nuance -- more nuance than the unaided eye can see.
Which introduces the next problem, shifting or expanding the range of the entire image. It's not just for false color Mars photography; scanners and digital images almost always need adjustment. Whenever you try to stretch the dynamic range of an image you must interpolate the values in between the original pixels. Having only eight bits per channel gives you very little wiggle room before you start to see artifacts.
Furthermore, apart from such direct color-manipulation, more bits per pixel minimizes roundoff for other operations (like blending) that happen in color land.
So in short, 8 bits would be fine if you didn't have to manipulate the image.
And no, Photoshop has not always been 16 bit either. It started slowly and every new release added more things that worked in 16 bit and left fewer that didn't, until they were all gone. But they are several releases ahead in that regard.
So, you may ask, why weren't people upset about Photoshop's 16-bit shortcomings? They were! They really were! But it was years ago, and then like now the pros cared about it and the non-pros shrugged it off as an imaginary distinction of no practical value. But you've got to remember, five years ago 35mm-sized digital SLRs basically did not exist. And only pros could afford to get film drum-scanned. Most high-end photography resorted to Photoshop only when neccessary, or used expensive third-party plugins to work around the shortcomings. This field has moved remarkably fast in the past few years.
The problem is that 8 bits postprocessing is less accurate.
For example, if one of your photos is partly underexposed then you probably want to raise the luminosity in the shadows.
If your image is 8 bits (256 levels), the shadows will provide, let's say, 10 levels of 'gray' to play with. This is not a lot and the result is likely to be crap (and noisy).
Now, if your digital camera provides 16bit per channel then the same shadows will provide 2500 levels to plays with. That's a hell of a difference.
Most digital cameras only provide 12bits but 4bit more bits means 16 times more levels to play with.
Anyways, the situation in The Gimp is not so bad for digital camera owners.
The UFRAW plugin can load almost any RAW image files.
Also, UFRAW allows you to adjust your image (levels, WB,<nobr> <wbr></nobr>...) using all available bits.
Once loaded, The Gimp has to work in 8bits but that is less of a problem.
what is difficult about 16 bits per channel?
Posted by: Anonymous Coward on October 06, 2005 03:22 AMRe:what is difficult about 16 bits per channel?
Posted by: Nathan Willis on October 06, 2005 03:53 AMAt least that's my off-the-cuff guess at it.
I used to do a lot of graphics programming for fun, and those sorts of problems show up when you don't plan ahead.
When Gimp was first developed, I really doubt they ever considered it would be needed, and by the time they realized people wanted it... Yeah.
Re:what is difficult about 16 bits per channel?
Posted by: Anonymous Coward on October 06, 2005 04:15 AMmemcpy(dst, src, 4 * pixelsInThisRow);
And those will break. All of them. And there are far more insidious problems, too, this is the simple example.
ImageMagick solved this by making 8 or 16 bits a compiletime option; this means that almost all installations of imagemagick work with 16 bit/channel internally.
Originally, this was the plan for Krita, too. However, this is not flexible, and there are image formats that want 32 bits per channel.
Krita now (yes, right now, klik development snapshot at <a href="http://www.xs4all.nl/~bsarempt/krita.cmg" title="xs4all.nl">http://www.xs4all.nl/~bsarempt/krita.cmg</a xs4all.nl> -- bugs guaranteed, grayscale is currently broken, Casper is working on it) supports fully color managed 8 and 16 bit channel grayscale, rgb, xyz and cmyk image formats, and also half and 32-bit float rgb (openEXR).
But we were fortunate in having had an architecture that was designed for this kind of flexibility bequeathed us by my predecessor, Patrick Julien, and in that we didn't have a gazillion of filters to port.
On the other hand, we don't have a gazillion of filters yet<nobr> <wbr></nobr>:-).
Boudewijn Rempt -- Krita maintainer
Re:what is difficult about 16 bits per channel?
Posted by: Anonymous Coward on October 06, 2005 11:55 PMI think most of the user interface 'issues' have more to do with it being different than anything else. I've never been able to get used to non-Gimp programs.
Following in that thought, I'm really glad that they don't use MDI. That's one thing is that if they switched to MDI, I'd probably just not upgrade. Gimp is just plain not-MDI. That's it's thing. If I wanted MDI, I'd use another program.
Gimp is Gimp. I use it because it's like Gimp, not because it's like Photoshop. Christ...
Too many windows?
Who cares, it's Linux! As far as I know, every desktop Linux has comes with 'tabbed browsing' and has since Eisenhower was president.
It's a pretty basic feature. Tabs on the desktop, (i.e. 'multiple workspaces'), tabs on the browser, tabs on the CLI, tabs on the terminal emulator, the text editor, etc.
Personally I use a workspace for every program... That is actually my #1 favorite Linux\Unix feature, oddly enough.
I'm sure Windows will have it by 2013. (And claim they invented it.)
What I miss in the GIMP is an option to change the interface to a MDI variant.
Not so long ago, I heard about a thing called GIMPshop, it's basically GIMP but with an interface that more resembles Photoshop.
<a href="http://plasticbugs.com/?page_id=294" title="plasticbugs.com">http://plasticbugs.com/?page_id=294</a plasticbugs.com>
I ended up writing my own little IPTC app in perl/Tk, but it'd be nice to have it in The GIMP, which I've used exclusively for over 3 years.
There are a few command line tools; for me the big missing link is IPTC support in the alleged "image management" apps -- imgSeek has always been the only one that took IPTC support seriously, but I've not been able to get it working on Ubuntu, to which I'm a recent convert. The other "image manager" wannabes are woefully lacking; barely glorified thumbnail browsers the lot of them.
However, since you brought it up -- where is your IPTC app? Have we seen it? I hope you're not going to tease the world with its existence and then never show it the light of day. Maybe someone can work it into a Gimp plugin, to say the least.
I do not think that it has a bad meaning. That seems to be a technical term used to refer to all information attached to the image without being part of the image itself (Those informations are atttached to the image like a parasite is attached to a body).
Also, the Gimp developpers appear to be working on a new property editor that support XMP (IPTC is part of XMP?). Within the Gimp 2.3.4, load an image and select File > Properties.
Most of the tabs are not functionnal. The last one 'Advanced' provides an editable list of XMP tags.
I could not figure out how to add a new field but I was able to import tags from an XMP file and then edit them by double clicking.
The gimp was also capable of saving and reloading a JPG with those tags.
That property editor is still very crude but things are obviously progressing.
This is obviously very experimental.
Otherwise in windows there is jead
<a href="http://www.sentex.net/~mwandel/jhead/usage.html" title="sentex.net">http://www.sentex.net/~mwandel/jhead/usage.html</a sentex.net>
not again MDI !
MDI is UGLY. (and a technical pain in a GTK/X11 world and a really complicate feature for so many users you cannot imagine )
Macintosh photoshop NEVER DID USE MDI windows
(why ? because the DOCK and whole mac interface nullify the need of "mdi" )
mdi is not a part of GNOME user interface. Gnome Panels and gnome window management is improving to improve gimp uses.
gimp 2.3 is improving how dialog boxes are attached to their picture windows and how the "gimp panel tool" is managed.
I understand in windows , gimp is an "alien". yes, in windows, gimp should create a "mdi window" as _windows_ photoshop. the standard windows taskbar is not enough.
but PLEASE : understand in the GNOME world and Macintosh world : MDI IS A NO NEED.
and I love my gimp with its removable panels.
here we see GNOME Gimp. its MAIN target (yeah I know it's hurt somes, but windows is not the main target of gimp developpers)
anyway, gimp is before all a Gnome applications (use of gtk, optional use of gnome-vfs, Gnome human interface guidelines respect now and so on).
and I try to not confuse every people with speak of too much technical details and choices.
You may think this is an unimportant detail, but consider that the user has to save files hunderds of times and navigating through the file hierarchy each time is a slooowww operation.
Thanks.
Adobe have clearly put a lot of thought into the workflow and keying assignments; The Gimp developers clearly haven't!
I read this article eagerly waiting to hear about the usability improvements, and right at the bottom we hear some stuff about the HIG -- but no real mention of a usability drive. Usability is finally becoming a palatteble word in many parts of the FOSS community; I look forward to the day when it becomes _cool_ amongst Gimp developers too.
I look forward to the day when commenters start to actually do some research before making their statements.
Currently GIMP does open the save file chooser dialog with the directory opened where you last opened or saved this particular file you are saving. This seems like a very good choice to me. Why should it be changed?
Because it's totally brain dead. If you think about it it assumes that all you files are stored in one single directory, the home directory, which is clearly wrong.
Of course this means changing the directory each and every time I save a file. The bookmark feature comes in handy, but this could be improved.
Another good reason is of you are working with pictures from a CD. Try saving them in the same folder where you opened them !
Usability is extremely important to the pro user, the user must be able to decide where to save and do it quick !!
The possibility to dock a directory list to the left side of the gimp save dialog is certainly useful, but a quick browse function or the possibility to set up a particular folder as default is certainly missing in The Gimp and in Linux.
When I was on Windows a few years ago there was this app "desktop folders" where you could set up any folder as the default and dock it to the open/save dialog.
That's one of the few things I still miss today on Linux
Why , oh why, don't you contribute a line drawing tool if you think it's a useful addition? That should be one of the simplest tools one could possibly write.
It could be, and this is just a wild guess, that you can draw a straight line, using either the pencil or paintbrush tool, but clicking somewhere, pressing and holding shift down, and clicking where you want it to end.
Voilà, a line!
not quite done yet
Posted by: Anonymous Coward on October 05, 2005 07:30 PM#