It’s taken a Herculean seven-year effort, but GIMP 3.0 has finally been released. There are so many new features, changes, and improvements in this release that it’s impossible to highlight all of them. First and foremost, GIMP 3.0 marks the shift to GTK3 – this may be surprising considering GTK4 has been out for a while, but major applications such as GIMP tend to stick to more tried and true toolkit versions. GTK4 also brings with it the prickly discussion concerning a possible adoption of libadwaita, the GNOME-specific augmentations on top of GTK4. The other major change is full support for Wayland, but users of the legacy X11 windowing system don’t have to worry just yet, since GIMP 3.0 supports that, too.
As far as actual features go, there’s a ton here. Non-destructive layer effects is one of the biggest improvements.
Another big change introduced in GIMP 3.0 is non-destructive (NDE) filters. In GIMP 2.10, filters were automatically merged onto the layer, which prevented you from making further edits without repeatedly undoing your changes. Now by default, filters stay active once committed. This means you can re-edit most GEGL filters in the
↫ GIMP 3.0 release notesmenu on the layer dockable without having to revert your work. You can also toggle them on or off, selectively delete them, or even merge them all down destructively. If you prefer the original GIMP 2.10 workflow, you can select the “Merge Filters” option when applying a filter instead.
There’s also much better color space management, better layer management and control, the user interface has been improved across the board, and support for a ton of file formats have been added, from macOS icons to Amiga ILBM/IFF formats, and much more. GIMP 3.0 also improves compatibility with Photoshop files, and it can import more palette formats, including proprietary ones like Adobe Color Book (ACB) and Adobe Swatch Exchange (ASE).
This is just a small selection, as GIMP 3.0 truly is a massive update. It’s available for Linux, Windows, and macOS, and if you wait for a few days it’ll probably show up in your distribution’s package repositories.
Amazing! Hopefully we will see bigger improvements more often now especially with colour spaces (eg. CMYK and CieLab) and non-destructive editing. Maybe even UX.
It is easy to be cynical about the pace of GIMP development and indeed it has been slow. However, I think a lot of the problem has simply been that the version that the rest of us were using was not the one that the devs were adding new things to. The big architectural changes meant that new features added years ago are only seeing the light of day now.
ReactOS has the same problem. The “stable” version is years out of date. Anybody close to the project has been using versions with far more functionality for a really long time but, unless you are downloading nightly dev versions, you would never know that progress is being made. As a result, progress is much slower than it should be and far fewer people are able to participate.
Now that 3.0 is out, I do hope that the apparent pace of GIMP evolution accelerates and we can all get more exited about where it is going next.
GIMP fell into a similar trap that Netscape in the 90s: rewrite too much at once. KDE learned that with KDE 4. For both it was a necessary step for future evolution though, so Kudos to GIMP devs for sticking to it.
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Serafean,
It’s not always the case though. Sometimes it really is better to tear down the house and build a better foundation than try and keep building on what you’ve got. Inadequate wiring, leaks, bad isolation, bad windows, mold, rotten boards, structural limitations, not up to code, etc. Same can apply to software – patching a code base with many problems could be the wrong choice. This isn’t to say everything should be rewritten, only that it depends and it should not be ruled out if the code base has a lot of problems. Believe it or not I’ve seen a lot of terrible code in corporate environments. Of course it can be hard for managers to justify rewrites when they have such short term incentives – apply some putty to cover up the mold and make it someone else’s problem (typically my problem when I end up working on it).
As a light user who finds the ui of most image editors equally obscure, I am curious as to what the photoshop crowd thinks of this new version.
I tried it super fast and for me it is as ugly as always
I used to use Photoshop, I’ve moved 100% to Gimp now for editing my scanned, traditionally-painted paintings. Some of the ways you do things are a bit different, but nothing important, you can learn that. The biggest problem really is performance. Gimp is slow. It’s not visible on small images, but on 600 DPI scanned TIFF images, doing some simple transformations, can take anywhere from 3 to 8 seconds, while on Photoshop are 1 second, or instantaneous.
Eugenia Loli,
I use gimp’s box transformations to correct distortions for documents I take pictures of. My god the performance leaves a lot to be desired. It should be real time. Obviously blender isn’t the right tool for the job, but it’s shaders are real time and it proves that the computer is not the limiting factor, far from it. Gimp’s code just lacks optimization. Also whatever algorithm gimp uses is not pixel perfect, which is very frustrating when you know exactly where a mark on paper needs to be mapped to.
I’m thankful to have gimp, but yea it could use a lot more optimization and acceleration.
Is there a list of what file formats are actually supported? I couldn’t find any at the site.
Are there any graphics file formats that GIMP does not support? I’ve thrown all kinds of weird and obscure file endings at it over the years, can’t recall it ever letting me down.
GTK? Motif or GTFO! =)))))
In a more serious note, I am happy this is out now and I am eager to try it. Years ago, I dumped all subscription software out of my life (I don’t mind perpetual licenses), but GIMP or even Luminar Neo choke with 4×5 and 8×10 300-800mp scans.
GIMP scrolls and redraws the screen very slowly, and previewing any levels adjustment is impossibly slow. Luminar Neo leaks memory like there’s no tomorrow, slowly going through all 64GB of RAM and more than 100GB of swap space.
I was just yesterday considering going back to Adobe, but will now give GIMP another shot.
Shiunbird,
I use gimp almost exclusively for raster graphics. It’s not critical for me because I don’t do much graphics editing, but I concur: the software is badly optimized and would benefit from a major overall. It takes a while for debian repos to push feature updates but I look forward to v3.
Unless I’m actually working with photos, I prefer vector graphic tools to generate graphics. I use inkscape there, but it needs some work too.
Incidentally I’ve been working on an inkscape fork that takes the inkscape scene and forwards it to a laser projecting daemon in real time. My wife wanted something to draw outlines for her projects. Using ILDA software is clunky and doesn’t work with normal vector formats. So I thought it would be really cool to project directly out of real vector graphics software. Inkscape was an obvious candidate. I wanted to implement it as a plugin for inkscape, but it quickly became apparent that inkscape’s built in facilities weren’t up to the task so I had to create a fork that allows objects to be extracted from the scene to send them to the projector..