After excruciating seven years in the making, GIMP 3.0 is finally here. Let’s focus on just the major changes and then have a grown-up conversation about project’s future plans, funding, and the name change.
Disclaimer: I was a team member until late 2022.
What’s new in GIMP 3.0
Here are some of the release highlights:
- Layer filters
- Multiple layers selection
- Layer locks
- CMYK exporting / late binding
- Color management updates
- Text outlines
- Better file formats support
- New logo
Layer filters
Most filters available in the program are now non-destructive. Add some text, apply a text style to it, saturate it, then apply the drop shadow effect — all in a single layer.
Then, click “fx” in the Layers panel, toggle the visibility of a filter you applied, change the order of filters by moving them up and down, or double-click to open filter’s settings. Edit the text if you like—and filters will redraw themselves.
Do you want to apply a filter to a layer group the same way? Sure, no problem.
Non-destructive editing is only available for GEGL-based filters, which means most filters available out of the box. There’s also no limitation for higher bit depths. If you want an arbitrary GEGL-based layer filter in the 32-bit per channel image mode, you can have it.
I probably need to spell it out, but this is not all that non-destructive editing is supposed to be in GIMP. Think non-destructive cropping (partially done) or rotation or perspective transformation. This will eventually land to GIMP.
Now, here is a good question: is it slow? Yes. It takes GIMP a noticeable time to replay all the changes when you open an XCF file with layer filters. Here is a very much watching-the-paint-dry kind of demo:
Since OpenCL is still kinda problematic to use, there are several possible strategies for further improvement here.
- You can start saving buffer caches directly to XCF, but that will blow up the size of XCF files.
- You can optimize GEGL filters to use advanced processor instructions (something that should be done anyway), but these days you have to optimize for x86_64 as much as for ARM.
Overall, layer filters are a very welcome and long overdue feature that will make workflows vastly more efficient, especially once filters are fast.
Multiple layers selection
You can now select multiple layers or paths and drag them around:
(Artwork by Fredrik Persson)
Sounds simple enough? It probably does. But Jehan probably still has nightmares about refactoring GIMP’s code to allow for that.
See, GIMP was designed with the idea that only one item can be selected at a time. It was such a deeply rooted concept that it took him three attempts to get it right. This patch touched a lot of GIMP’s code: dozen of files all over the place. And the outcome isn’t something magical: it’s just a program functioning as expected.
Layer locks
The various locks for layers have moved from the toolbar above the layers tree view to the layer rows. Click where a lock icon is supposed to be visible in the Lock column and select the options you need.
CMYK exporting
While you cannot create CMYK images from scratch and do editing in CMYK mode yet, late binding is now available. This means you create an RGB image and then convert to CMYK TIFF, JPEG, JPEG-XL, or PSD.
(Here and once more below, randomly picked artwork by Oleksandra Havrylina)
This topic came up in a GIMP 3.0 conversation on Reddit a few days ago, so let’s reiterate.
There is a lot more to CMYK than being able to export a CMYK TIFF. It’s not just a CMYK mode either. It’s a ton of things.
Some of them, like total ink coverage readout, are fairly easy to implement when you know what you are doing, with GPL code if not to reuse, then definitely to learn from.
Others require some very specific expertise, one that the team members likely don’t have today. Because of that, if would be beneficial for the project to partner with an expert in the community.
Color management updates
GIMP used to be an sRGB-only for a very long time, treating all RGB data as sRGB. Then it became color-aware and started converting AdobeRGB and friends to sRGB. Now it doesn’t even need to do that, you can just open an image in a wide-gamut color space and work in it natively.
And when you start working with that image, your color pickers all show what space they are in:
Additionally, it’s easier to do soft-proofing now: right-click a widget in the lower right corner to open settings, set the profile, then toggle soft-proofing either in the dialog or by left-clicking on the widget in the status bar.
Text outline
The Text tool got two new styles: Outlined and Outlined and filled. It does what it says on the tin. However, the rendering quality is not amazing, and the UI is kinda clunky.
Better file formats support
The team has improved the compatibility with Photoshop, not just the PSD files, but also things that Photoshop embeds into JPEG and TIFF files, including clipping paths and guides.
For game developers, the DDS plugin now supports BC7 compression.
Additionally, GIMP now reads Adobe Color Book (ACB), Adobe Swatch Exchange (ASE), and the open-source Swatchbooker palette file format. To achieve that, the team implemented CIE LAB support in palette code. The native file format, .gpl, hasn’t changed though. It’s still 8-bit per channel untagged RGB data.
New logo/icon
The new logo is a step in the opposite direction of what many users have been requesting. It has become even more cartoonish than before.
There have been numerous proposals in the issue tracker (see these two threads, for example), but Areyom ended up making the one you are likely looking at.
Overall, I find this conversation a little funny. I’ve seen people who claim to be marketing experts bashing the project over the previous logo. Meanwhile making a “serious” logo is simply not how branding works.
Branding is supposed to represent core values of people who represent the brand. If you have developers who are a bit artsy, friendly, and a little dorky, Wilber is what you get.
If you want anything else, then let’s be honest: you just want GIMP developers to be somebody they are not or the project to be developed by entirely different human beings. Tough luck, my friends, tough luck.
On a related matter, the splash screen artwork was done by Fredrik Persson, the guy who casually makes 100+ layers and multi-gigabyte large projects in GIMP.
Caveats
There’s much to discuss here, but I’ll stick with three topics I feel strongly about.
Window layout
The default window layout is virtually the same as 20+ years ago:
The team had numerous conversations about that in the past. It always boiled down to “We can’t change what we have because people use GIMP differently, and we would be forcing a layout on them. We should have job-oriented named workspaces in the first place”. Which is a great idea but probably not at the expense of shipping same ol’ same ol’ for years.
Several years ago, I sourced screenshots of customized layouts from GIMP users to get a better idea what people are used to for different scenarios like painting, photography, etc. The entire screenshot dump and preliminary analysis are still available.
I didn’t go further with this because noone was volunteering to write the code. Plus, the relevant issue in the tracker is now in the Future milestone which basically means “probably never, unless someone volunteers”.
HiDPI issues
The previous version of the toolkit that GIMP used, GTK2, was notoriously bad on HiDPI displays. Even though the team performed some impressive magic to make things work better, users with 4K displays would still regularly complain about the toolbox being too small.
You’d think that the GTK3 port would provide a great out-of-the-box experience. It doesn’t. In fact, it broke probably as many things as it fixed. Here are two major issues I have to deal with on a 14" display at 2560x1440px.
-
Image view scaling is broken. At 100% zoom level, everything is double the size. I filed the bug report four years ago, got “not a regression” in response. The issue has since been moved to the UX project for discussion.
-
The screenshot plugin is broken. When you choose to capture one window, it will capture it at half the actual size (1280x720px). And when you capture the entire screen, this is what you get instead:
I filed a bug report two years ago, but this is just one of thousands bug reports, there have been no takers so far.
Options, options, options
Do you dislike the on-canvas text editor? Then open the text editor window. It will not hide the on-canvas toolbar, but you will be writing in a separate dialog.
Do you dislike the on-canvas text editor, but you also kinda hate the text editor window? Sure, here’s another option to hide the on-canvas toolbar.
If you look at Artbox, a soft fork by one of the new contributors, it has even more UI options of that kind. One of the options deals with the overkill in the tool settings UI, you know, where you now get these rows with four buttons:
So the overall trajectory here seems to be adding options rather than streamlining the default experience.
Back when I worked with the Ondsel team, one thing we did on a regular basis is ditch all personal customizations, download the latest weekly build, and go over defaults to see what we could improve to make the initial user experience better.
Our decisions were highly opinionated. Some decisions resulted in code and new options in upstream, but the code changes always came with customizations to improve the UX. And guess what—users loved the result.
What’s next
There are some very good and sorely missing features in progress:
- CMYK as an image mode, and possibly LAB coming next.
- Layer filters enhancements: editing masks for filters, stacking filters right in the layers dock, etc. (UX proposal)
- Vector layers from an old Google Summer of Code project.
So, I’m not worried whether the team has users’ best interests at heart—they absolutely have. What I’m somewhat concerned about is how the project plans its work.
If you didn’t know, this famous clip from Malcolm in the Middle illustrates the last 20+ years of GIMP development with astonishing and painful accuracy:
(A terrible lot of ADHD people will relate to that.)
Can the team switch to shorter release cycles with more focused work? I think so. Will they do it? We’ll just have to wait and see.
Another thing worth pointing out here is that the team seems to be building a UX taskforce (again). It’s unclear how they operate apart from having an issue tracker of their own, but the fact that they started doing this again speaks volumes.
Project funding
The v3.0 release would be a perfect time to revamp the organization and make the development sustainable by hiring team members. Alas, the disappointing non-news is that the project continues to be very non-transparent about what it’s trying to change. So far, there have been only some hints about upcoming changes.
A year or two ago, the team made a fiscal deal with the GNOME Foundation related to handling donations. The nature of the deal was never announced by GIMP, but if you look at the GNOME Foundation’s “2024-2025 budget and economic review”, you will see this:
…we have been workng with the GIMP on financial and legal arrangements to receive approx $1M of historical Bitcoin donations. (And sell them immediately – holding Bitcoin assets creates a regulatory/reporting problem for US nonprofits and our accountants have advised us against it.)
The team moved “about half the coins” (approx. $1,1mln) to GNOME Foundation in January this year, but they still have 9.8333247 BTC which at the moment translates to over $840K USD. That brings the crypto-originated part of the stash closer to $2mln, minus GNOME’s fee as a fiscal agent.
For fiat money, I don’t feel comfortable disclosing the balance from 2021—the last one I have the knowledge of. But to give you idea, the 2022-2023 report by GNOME suggests almost $180K of income and $36K expenses in those two years.
Liberapay brings another approx. EUR400 every week at the moment (that’s not an entirely correct way to phrase it because of how the platform operates, but it is what it is). The Liberapay funds are split two ways, between Jehan Pagès and Øyvind Kolås (Pat David is only formally part of the team at Liberapay).
Patreon currently brings $1,200 to ZeMarmot (part of the proceedings is supposed to fund GIMP development by Jehan Pagès), and approx $1,300 goes to Øyvind Kolås.
All in all, the team is sitting on over $2mln. And even though a huge part of the money was not easily accessible until recently, the rest was perfectly usable for doing paid work. Before you ask: yes, throughout the history of the project, there were contributors interested in doing paid development for the project. That never materialized.
Having said all that, I can’t stress enough that the real conversation here is not about the money. It’s whether GIMP will start planning their work and hiring developers or giving grants. It seems obvious that the team won’t go public at the very least until it’s done moving BTC to GNOME for selling. Again, we’ll just have to wait and see.
The name change
Of course there’s the topic of the name change. The more polarized the world becomes, the angrier people get on both sides of the argument.
The overall sentiment in the team changed over the years from “Hell, no” to “Not particularly objecting, but not wanting to do the work either” to, now, “We’ll keep discussing this”:
We don’t today have consensus in the team to make that change, so posting as GIMP_Official, I can’t say what will happen yet, but we’ve agreed last year to discuss it further.
(Source)
Once again, this is not where pushing the team on the matter will result in swift (or otherwise) action.
Rebranding is not easy. It takes a huge amount of effort. It’s annoying. It makes you frustrated and tired. It hurts people who already rely on the brand name one way or another. It makes tutorials not googlable for all new users. And the list goes on.
If and when the name change happens, it will probably be the single most important change for the project since the full GEGL integration. It won’t get you better UX/UI, it won’t get you any new features, it won’t change anything except one thing: make the use and discussion of GIMP somewhat less problematic.
This is a companion discussion topic for the original entry at https://librearts.org/2025/03/gimp-3-0-released/
