Two months after releasing GIMP 3.0, we are delighted to announce the second micro-release, GIMP 3.0.4.
This addresses bugs and also incorporates some of the fabulous and helpful feedback we have received.
Micro releases like 3.0.4 are focused on fixing bugs and regressions,
so there are no major new features to announce (though we continue to work on those! Just on separate feature branches for GIMP 3.2).
However, we want to tell you about some major fixes that may have impacted your workflow.
There was a bug with pasting selections from GIMP into other programs, where the pasted section was padded to the
original image size. This is now fixed thanks to work from Anders Jonsson, Aruius, and Alx Sa. If you
notice any regressions or other issues after this fix, please let us know!
There were several types of crash reported to us, related to changing or turning off the main monitor. Jacob Boerema and
Jehan worked together to diagnose this issue and make several necessary fixes. However, if you continue to have problems
related to this, let us know so we can continue to work on it.
Idriss Fekir and Liam Quin, our resident font experts, have been busy making improvements to our text systems.
In addition to general bug fixes with text layers, they’ve also greatly improved font loading speed on start-up.
If you have a large number of fonts on your computer, GIMP should start much faster now!
Non-destructive filters received a number of bugfixes and improvements as well. The name of the filter is once again displayed
in the undo history when added to an image. In addition, individual filter edits are now tracked in the undo history, thanks to
work by Jehan and Alx Sa. We also resolved a few crashes, and we fixed some visual glitches when rotating layers with
active non-destructive filters.
A few other small fixes of note:
New contributor Gabriele Barbero fixed a bug where the Help button on the About Dialog didn’t load the help page correctly.
New contributor Integral fixed a bug on KDE Wayland where the default Wayland icon was shown instead of our Wilber icon.
The ZDI-CAN-26752 bug for .ICO imports is now fixed.
Screenshot of GIMP splash screen with correct Wilber icon on KDE Wayland, by Integral - GIMP 3.0.4
Akkana Peck noticed that the Window Hint option in Preferences no longer allowed floating windows to stay in front
of the main image window in multi-window mode. She found and implemented a fix using the updated GTK3API.
Screenshot of Preferences Dialog with ‘Hint for docks and toolbox’ option highlighted - GIMP 3.0.4
The space bar once again respects the action setting in Canvas Interactions. This means instead of always panning, you
can set it to switch to the Move Tool instead - or even set it to do nothing at all!
The Difference Cloud filter once again has a GUI to let you adjust its settings. This actually fixes a regression from
the port to GEGL in GIMP 2.8, so it’s a long-standing update!
Difference Cloud filter GUI - GIMP 3.0.4
A few other small fixes of note:
The Plug-in Browser should now show all plug-ins again.
New contributor Aruius resolved a bug where the Sample Points display didn’t update when the image’s precision changed.
The Screenshot plug-in once again uses radio buttons rather than a drop-down menu for its options, reducing the number of
clicks needed to change settings.
Rupert Weber fixed a bug on Linux where BMP format warnings didn’t display in some cases.
Since this is a “bugfix” release, we didn’t want to make too many disruptive UI changes. However, Reju has identified
and designed a few smaller updates to help make GIMP’s UI more consistent.
The MyPaint Brush tools options UI has been redesigned to match the layout of other painting tools.
The generic “Force” slider does not impact the Pencil Tool. This option is now hidden in that tool’s options rather than
just marked inactive, to be less confusing.
The Device Status dock has been updated to show more clearly which input device is in use, and is closer to the GIMP 2.10 version.
The Path tool now automatically closes the path when you click on the starting point in Design mode, rather than requiring
you to hold down the Ctrl first. This makes the Path tool more consistent with similar tools in GIMP, as well as
in other software. If you need to move the starting point, you can deselect the current end point by holding Shift
when you click on it, and then select the starting point to move it.
Jacob Boerema reviewed our brush size code, and found that different parts of GIMP set different limits for the maximum brush size.
He defined a single maximum value and set it to be used throughout GIMP, to ensure there are no surprises when resizing your brush!
A few other small fixes of note:
On Windows, floating docks in Multi-Window Mode now also have their titlebars match the theme dark mode setting.
You can now press Enter to connect the start and end points in Scissor Select. Pressing Enter
a second time will create a selection as normal.
We received reports that GCC 15 could not build GIMP by default, due to some older areas of our codebase using
now reserved keywords for variable names. Nils Philippsen located the problem areas and updated the relevant code
to match current standards.
On macOS, we now have a developer version of the .DMG as first mentioned in the
3.0.2 news post.
This means that creating plug-ins for macOS will be much easier and faster than before.
Thanks again to Lukas Oberhuber, Peter Kaczorowski, Dominik Reichardt, and other contributors
for their hard work!
Our resident packaging and build expert Bruno Lopes has been busy with more improvements to our processes.
A few of these updates are listed below:
The AppImage no longer contains Debug Symbols for dependencies (with the exception of babl and GEGL).
This should significantly cut down on the file size, going back to the small size it had in RC3.
Instead, if you need to debug the AppImage, follow our
new debugging instructions.
To guarantee the best stability for future GIMP installations on Microsoft Windows, the
installer’s Customize mode is now restricted to “clean” installations (a.k.a. when
you first install GIMP). That’s because we need to adjust or even remove features from
the .exe installer when they get too hard to maintain or become potentially broken (e.g.
our custom file associations page was removed starting with GIMP 2.10.12 installer).
In the Customize mode case, it was suppose to let you choose what GIMP components should
installed, but unfortunately, it was not working like that at all.
Back then, to allow the Customize mode between GIMP installations (e.g. when
reinstalling, updating), our Windows developers needed to 1) hardcode the components
files almost twice and 2) code our own utility to do recursive uninstall of some complex
components. All of that extra work to barely emulate how it (automatically) works on NSIS
and WIX installers. Because of this, that feature became unmaintained without us noticing
for many years and was silently breaking some GIMP installations. That said, you will still
be able to use that feature with the command line - but keep in mind it is not properly working.
To be clear: that feature works perfectly on clean installs and, from 3.0.4 onward, also if the
installer detects a broken install (e.g. when you installed GIMP in a external SSD but
lost it). We call this much requested feature: Repair mode.
Also in the Customize mode, in addition to letting you choose what language packs are
present, you can now also choose to install plug-in development files which work with
our new plug-in tutorials.
As a bonus, even if you select literally all components available in the Customize mode,
GIMP 3 is still more than 300MB smaller than GIMP 2.10 😉, that’s it.
GEGL version 0.4.62 brings several bug fixes to prevent crashes, courtesy of Øyvind Kolås. UI ranges were added by
Budhil Nigam to some operations, which means our Fractal Trace filter now has more sensible number ranges on the slider.
babl version 0.1.114 contains some fixes from Øyvind to ensure TRCs are stored
correctly from color profiles.
Internally, Bruno Lopes converted many scripts in both projects to use Python, making them easier to build on other platforms.
15 translations were updated: British English, Bulgarian, Catalan,
Chinese (China), Danish, French, Georgian, German, Norwegian Nynorsk,
Persian, Portuguese, Slovenian, Swedish, Turkish, Ukrainian.
32 people contributed changes or fixes to GIMP 3.0.4 codebase (order
is determined by number of commits; some people are in several groups):
14 developers to core code: Alx Sa, Jehan, Bruno Lopes, Idriss Fekir,
Jacob Boerema, Gabriele Barbero, Akkana Peck, Integral, Lukas
Oberhuber, Nils Philippsen, aruius, Lloyd Konneker, mkmo, Øyvind Kolås.
9 developers to plug-ins or modules: Alx Sa, Bruno Lopes, Jehan, Jacob
Boerema, Anders Jonsson, Nils Philippsen, Rupert, Sabri Ünal, Lloyd Konneker.
16 translators: Emin Tufan Çetin, Kolbjørn Stuestøl, Alexander Shopov,
Anders Jonsson, Luming Zh, Martin, Yuri Chornoivan, Alan Mortensen,
Andi Chandler, Dirk Stöcker, Ekaterine Papava, André Dazereix, Danial
Behzadi, Hugo Carvalho, Jordi Mas i Hernandez, Philipp Kiemle.
2 theme designers: Alx Sa, Bruno Lopes.
7 build, packaging or CI contributors: Bruno Lopes, Jehan, Idriss
Fekir, Integral, Lukas Oberhuber, lloyd konneker, Ondřej Míchal.
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
GEGL 0.4.62 is made of 22 commits by 7 contributors: Øyvind Kolås,
Bruno Lopes, Davide Ferracin, Jehan, Liam Quin, Muhammet Kara, budhil.
babl 0.1.114 is made of 24 commits by 5 contributors: Øyvind Kolås,
Bruno Lopes, John Paul Adrian Glaubitz, lillolollo, sewn.
ctx had 88 commits since 3.0.2 release by 1
contributor: Øyvind Kolås.
gimp-data had 8 commits by 3 contributors: Bruno Lopes, Jehan, Lukas Oberhuber.
The gimp-test-images (unit testing repository) repository had 1
commit by 1 contributor: Jacob Boerema.
The gimp-macos-build (macOS packaging scripts) release had 4
commits by 1 contributor: Lukas Oberhuber.
The flatpak release had 15 commits by 3 contributors: Bruno Lopes,
Ondřej Míchal, Jehan.
Our main website (what you are reading right now) had 44 commits by 4
contributors: Jehan, Alx Sa, Wiliam Souza, Bruno Lopes.
Our developer website had 63 commits by
5 contributors: Bruno Lopes, Jehan, Chas Belov, Lukas Oberhuber, Denis Rangelov.
Our 3.0 documentation had 75 commits by 13
contributors: Andre Klapper, Alevtina Karashokova, Jacob Boerema, Alan
Mortensen, Alx Sa, Kolbjørn Stuestøl, Alexandre Franke, Chas Belov,
Jordi Mas i Hernandez, Peter Mráz, ShellWen Chen, Takayuki KUSANO,
Yuri Chornoivan.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
Reju, an active contributor to the UX design repository, has been recently granted “reporter” status.
We appreciate their hard work developing designs and discussing UX improvements with developers and the community!
We are once again participating in the Google Summer of Code internship program. We have three great project proposals
from our summer students:
Ondřej Míchal is working on a redesign of our developer reference system in GIMP. They already have some early work
done on a GEGL Filter Browser, which will be very helpful for
plug-in creators looking to use the new Filter API.
Gabriele Barbero will be developing further improvements to the text tool, building on past work by former GSoC students
and current contributor Idriss Fekir.
Shivam Shekhar Soy will be working on our online extensions repository.
This is another step on our roadmap to allow you to easily download and install new extensions to GIMP, replacing the beloved
GIMP Plug-in Registry.
Mirrors are important as they help the project by sharing the load for dozens of thousands of daily downloads.
Moreover by having mirrors spread across the globe, we ensure that everyone can have fast download access to GIMP.
Since GIMP 3.0.0 release, we focused on bug fixing. As could be expected
after a 7-year development marathon, various issues have slipped through
our testing and we had to deal with these. Though perfection doesn’t
exist and we’ll continue to work on bug fixes, we believe we are in a
saner state now, and therefore we are now
going to enter a “Merge Window” period where we will allow new features
and breaking changes in the code again. In other words, we are starting
to move onto active GIMP 3.2 preparation! 😱
We won’t spoil 🤫 too much our feature list, also because it is possible
that some of the features we are planning don’t make it (though
development has already started in feature branches). But we can already
tell you that we feel that GIMP 3.2 will be pretty awesome too, despite
being much smaller than GIMP 3.0 was!
To be continued…
Don’t forget you can donate and personally fund GIMP developers, as a way to
give back and accelerate the development of GIMP. Community commitment helps the project to grow stronger!
Edit: this news was obviously a fun 🐠 April fool! 🐟
Nevertheless some people may have noted that the merge request for this
image format is real. While supporting all kind of outdated and
not-too-frequent file formats is certainly not our top priority,
supporting as many image formats, past and present, is within our goals.
Everyone who has old image archives they want to still be able to load
would understand how important this is.
Not only this, our half-joke was a good reminder that our project is
fully community-led, which means features happen because contributors
want to work on them.
GIMP 3.0 was a big release, and we’ve gotten a lot of feedback from users since then. While Jehan is busy with
bug fixes, code review, and administrative work, he’s asked me to take over certain duties to ease the burden
on him.
Therefore, I am proud to announce a new priority for GIMP 3.2: File Format support!
It’s true that GIMP already supports a wide range of images such as the very useful Esm Software PIX format. However, there are so many more types of images in the
world that I believe GIMP should support. Supporting all image formats - no matter how supposedly “obscure” - is crucial to maintaining access to our shared digital culture.
The first format in this new campaign is Jeff’s Image Format!
Example JIF image from Jeff’s website, converted with GIMP - authorship and copyright unsure
Jeff’s Image Format is a variation of the GIF standard, created in the late 1990s. It was intended to get
around potential legal issues with the patented LZW compression used in GIFs, by using a LZ77-derived compression instead.
The format is otherwise nearly identical to GIF (save for the JIFF99a magic number), making it an easy target
for import support in GIMP. Furthermore, it helps you to be right no matter how you pronounce GIF!
While you’ll have to wait until GIMP 3.2 to experience importing JIF images, you can check out the merge request
for Jeff’s Image Format support in GIMP to tide
yourself over until that glorious day! If you have any sample images you’d like to contribute, please share
on the issue tracker.
I am so proud to lead this new initiative for GIMP, and I believe it will take us (and open source image
editing in general) in an exciting new direction. I look forward to this journey with you all!
(At least until Jehan gets back and sees that I’ve posted this)
Example Animated JIF image from Jeff’s website, converted with GIMP - authorship and copyright unsure
As we noted in the
3.0 release notes, we are
returning to our pre-2.10 development process of only adding new features on minor releases. This allows
us to respond more quickly to problems and bugs found by users.
Furthermore it’s a good opportunity to show off our streamlined release procedure, allowing us to make
much faster releases in the v3 series than we used to be able to do with GIMP 2.10.
The initial release of GIMP 3.0 was great, and we deeply appreciate all the positive comments as well as
the constructive feedback from new and existing users! You helped us uncover a number of bugs and regressions,
and GIMP 3.0.2 provides fixes for several of them.
Here is a summary of the fixes:
macOS and flatpak users reported a crash when selecting a brush with the view set to Icon Grid. This was
tricky to solve as it did not crash on every OS, but Jehan and Øyvind Kolås worked together to implement a fix.
Some packaging changes resulted in a few missed features, such as Python plug-ins and the auto-update check
not running on Windows and some display filters and color selectors not appearing on macOS.
Bruno Lopes and Lukas Oberhuber diagnosed and fixed these in revisions to 3.0, and these updates are
included in the 3.0.2 release.
Different system themes had styles which our Default theme did not override, causing some UI glitches or
odd coloring. Denis Rangelov worked to develop CSS rules to prevent these problems regardless of what
system you’re on. Lukas Oberhuber fixed some additional macOS-specific issues with flyout menus on
tool groups.
A patch to improve tablet support has been temporarily reverted. While it fixed an issue with detecting
the eraser tip of some stylus, it seemed to cause a different issue with pressure sensivity on other tablets.
We will review this patch and update it in a future release to fix the eraser bug without causing the other
side effects.
Additional fixes were implemented throughout GIMP by Jehan, Jacob Boerema, Alx Sa,
Idriss Fekir, Wyatt Radkiewicz, and Anders Jonsson.
We are continuing to review reports of bugs, UI glitches, and regressions, and are working on solutions for
those. However, we believe GIMP 3.0.2 fixes some immediate problems for users, and we hope it makes using
GIMP 3.0 a little smoother. Please continue to report any issues or feature request you have to our
issue tracker so we’re aware of them!
Lukas Oberhuber, Peter Kaczorowski, Dominik Reichardt, and others have been hard at work creating
a new plug-in development package for macOS.
Traditionally it has been difficult to develop GIMP plug-ins on macOS, so this is a great
improvement! We’ll be updating our developer website soon with more
information. For now, you can read the discussion on the
tracking issue.
Bruno Lopes has implemented more improvements to our Windows installer. It now sets up a Restore Point
for system-wide installs. Also, if you uninstall GIMP via the installer, it will now prompt about removing
your configurations. This allows you to make a truly clean uninstall and reinstall of GIMP if you installed as a normal user
(not as an admin).
GEGL received a small bugfix update as well. 0.4.58 includes a fix for Dither being applied to negative pixel
coordinates, as well as additional translation updates.
10 translations were updated: Bulgarian, Chinese (China), Dutch,
Georgian, Icelandic, Slovenian, Spanish, Swedish, Turkish, Ukrainian.
20 people contributed changes or fixes to GIMP 3.0.2 codebase (order
is determined by number of commits; some people are in several groups):
7 developers to core code: Alx Sa, Jehan, Anders Jonsson, Denis
Rangelov, Idriss Fekir, Jacob Boerema, Øyvind Kolås.
6 developers to plug-ins or modules: Alx Sa, Jacob Boerema, Jehan,
Jethro Beekman, Lukas Oberhuber, Wyatt Radkiewicz.
10 translators: Luming Zh, Martin, Rodrigo Lledó, Yuri Chornoivan,
Alexander Shopov, Anders Jonsson, Ekaterine Papava, Muhammet Kara,
Nathan Follens, Sveinn í Felli.
1 Theme designer: Alx Sa.
1 Icon designer: Denis Rangelov.
3 build, packaging or CI contributors: Bruno, Lukas Oberhuber, Jehan.
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
GEGL 0.4.58 is made of 6 commits by 2 contributors: Øyvind Kolås,
Kolbjørn Stuestøl.
ctx had 2 commits since 3.0.0 release by 1
contributor: Øyvind Kolås.
gimp-data had 2 commits by 2 contributors: Denis Rangelov, Jehan.
The gimp-macos-build (macOS packaging scripts) release had 13
commits by 2 contributors: Lukas Oberhuber, Bruno Lopes.
The flatpak release had 2 commits by 1 contributor: Bruno Lopes.
Our main website (what you are reading right now) had 50 commits by 5
contributors: Jehan, Bruno Lopes, Alx Sa, Michael Schumacher, lillolollo.
Our developer website had 18 commits by
3 contributors: Bruno Lopes, Jehan, Lukas Oberhuber.
Our 3.0 documentation had 22
commits by 8 contributors: Alan Mortensen, Andre Klapper, Jacob
Boerema, Jordi Mas, Nathan Follens, Marco Ciampa, Tim Sabsch, Xavier Brochard.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
Since the 3.0 news post, two new mirrors have been contributed by Shrirang Kahale:
Delhi, India
Mumbai, India
Mirrors are important as they help the project by sharing the load for dozens of thousands of daily downloads. Moreover by having mirrors spread across the globe, we ensure that everyone can have fast download access to GIMP.
Our immediate focus is fixing initial bug reports from users for GIMP 3.0. However, we are also starting to
work on new features for the next minor release, GIMP 3.2. We look forward to talking more about that soon,
but for now, you can check the roadmap to see where we’re headed!
Don’t forget you can donate and personally fund GIMP developers, as a way to
give back and accelerate the development of GIMP. Community commitment helps the project to grow stronger!
At long last, the first release of GIMP 3.0 is here! This is the end result of
seven years of hard work by volunteer developers, designers, artists, and community members (for reference, GIMP 2.10 was first published in 2018
and the initial development version of GIMP 3.0 was released in 2020). With GIMP 3.0 you can do more than ever before, more easily, more quickly!
GIMP 3.0 splash screen, by Sevenix (CC by-sa 4.0)
While we can’t cover every single change in GIMP from 2.10, we want to highlight some of the biggest ones as you start exploring this new release.
Need to tweak a filter you applied hours ago?
New in GIMP 3.0 is non-destructive editing for
most commonly-used filters. See the changes in
real time with on-canvas preview.
Exchange files with more applications, including
BC7DDS files as well as better PSD export and
many new formats.
Don’t know how big to make your drawing?
Simply set your paint tool to expand layers automatically as needed.
Making pro-quality text got easier, too. Style your text,
apply outlines, shadows, bevels, and more, and you can
still edit your text, change font and size,
and even tweak the style settings.
Organizing your layers has become much easier with the ability to
select multiple items at once, move them or transform them all together!
Color Management was again improved, as our long-term project to make
GIMP an advanced image editor for all usages.
Updated graphical toolkit (GTK3) for modern desktop usage.
We’ve prepared release notes to go over all the changes, improvements, new features, and more. And if you’d like even more details, you can peruse the NEWS.pre-3.0 changelog for all 2.99 and 3.0 RC releases.
But to see it for yourself, you can get GIMP 3.0 directly from our Downloads page and try it out!
We also advise all packagers to use the latest GTK version: GTK 3.24.49.
It contains bug fixes for major issues (ranging from crashes to input
devices’ grab issues, UI glitches with interfaces in RTL
languages, and more…).
Don’t forget you can donate and personally fund GIMP developers, as a way to
give back and accelerate the development of GIMP. Community commitment helps the project to grow stronger!
We’re excited to share the third release candidate of GIMP 3.0 for what (we hope) is the final round of community testing before the stable version! This release follows the recent GIMP 3 and Beyond talk by Jehan at FOSDEM 2025.
While resolving the last few major bugs for 3.0, we’ve made some changes that we feel need more community review. While trying out this release candidate, please keep an eye out for the following:
Just in time for GIMP 3.0, a new version of GTK3 has been released!
Among other changes, GTK 3.24.48 includes fixes for several bugs
affecting GIMP with patches initially contributed by Jehan, such as
a crash in Wayland when dragging layers and text glitches in certain
widgets with Right-To-Left languages.
We want to thank Carlos Garnacho and Matthias Clasen for their
help on these respective patches.
GTK 3.24.48 also adds support to the version 2 of xdg_foreign for
Wayland (v1 stays supported as fallback). Specifically the absence of
this support was causing GIMP to freeze with certain actions on
KDE/Wayland, which is now fixed.
As a consequence of these issues — some of them really making GIMP
unstable on Wayland — we recommend packagers to update to the latest
version of GTK3 when packaging our RC3.
However, please let us know if you notice any regressions or other issues as a result of the new GTK3 version.
With non-destructive editing in GIMP, users can now stack multiple filters on top of each other. These filters usually work in high bit-depth format so image information is not lost. However, each filter’s output was converted to and from the original image’s bit-depth when stacked – so if the image was only 8-bit, a great deal of information was lost in these constant conversions. Jehan fixed this problem by only converting to the image’s format when the filter is meant to be merged in, rather than in non-destructive stacks. Since this is a big change in how filters work, we want to have more users test this change for any possible regressions.
When changes are made to an image (such as painting), the image projection needs to be “flushed” to display new changes to the screen. Some aspects of this process were not “thread-safe”, which means that when your computer used multiple threads to speed up the work, they might conflict with each other and cause a crash. This was observed in our auto-expanding layer feature. Jehan fixed the function to be entirely thread-safe. However, changes to multi-threading can leave some well-hidden bugs, so more community testing would be helpful.
The GIMP Procedural DataBase browser shows plug-in and script developers all the functions they can access. Until now, it also showed “private” functions that are only used internally. Jehan added a flag to hide these functions. We initially cast too wide of a net and hid some important public functions. While we fixed these instances, we’d like more review from the community to make sure we didn’t miss any mislabeled public functions.
While we are still in major feature-freeze until the stable release of GIMP 3.0, some small and self-contained enhancements have been made to plug-ins.
The new (gimp-drawable-merge-filter)PDB call allows Script-fu writers to use labels to specify filter properties.
This will give Script-fu users the same flexibility with calling and updating filters that C and Python plug-in developers
have in the GIMP 3.0 API. As an example, here is a call to the Emboss filter:
In Script-Fu, all the functions generated from plug-ins’ PDB procedure
must now be called with a brand new named-argument syntax, inspired by
the Racket Scheme variant.
For instance, say your plug-in wants to call the Foggify plug-in, instead of calling:
Much more self-documented calls, especially as some plug-ins have a
lot of arguments (so we could end up having functions with a dozen of
integers or floats and that was very confusing).
The order of arguments doesn’t matter anymore.
You can ignore arguments when you call them with default values.
It allows to improve plug-in procedures in the future by adding new
arguments without breaking existing scripts.
This last point in particular is important, and orders of arguments did
not matter anymore when calling PDB procedures from the C API, as well
as all introspected bindings. Script-Fu was the only remaining interface
we had which still cared about argument orders and numbers. This is not
true anymore and is therefore a huge step towards a much more robust API
for GIMP 3!
In addition to bug fixes such as saving CMYK merged images properly, Jacob Boerema has added support for loading 16-bits-per-channel LAB PSDs. He also updated the PSD export dialog to use GIMP’s built-in metadata export features.
Much-requested support for loading DDS images with BC7 support has been implemented by CMYK Student. Jacob Boerema
worked to fix compatibility with DDS files exported from older versions of GIMP.
After nine months of incubation (the number is a mere coincidence 🙂), we present
a “new” distribution format for Linux users: .AppImage. Initially we used it as
an internal format for testing, as
already covered in previous posts.
Bruno Lopes‘ efforts have allowed us to improve the build process. We now feel
confident with the generated AppImage and so we aim to make it official.
As an official upstream package, no fancy third party plug-ins or other arbitrary binaries
that are not GIMP dependencies are added to “bloat” it. It is what some people call
“vanilla” GIMP, a clean but complete GIMP for production (aka for general use).
Like any packaging format, it has its own characteristics and limitations. In the
case of GIMP’s AppImage, included tools such as gimp-console* and gimp-debug-tool*
require prior extraction of the .AppImage file with --appimage-extract command.
Also, partly due to AppImage’s design, commands that points to $PWD will not work.
These two are the only known feature limitations so far. So, if you find any others
or even bugs, please report them on our tracker.
It is now easier to load images from Google Drive and other remote or cloud platforms without having to manually select a
file format to try opening it with.
Our build process now generates additional icons with the -rtl extension, which are automatically used with Right-to-Left languages. An example of this is the left and right arrow icons; they now face the correct direction in both language types.
Plug-in developers no longer have to make custom file chooser buttons - GimpProcedureDialog now automatically creates them when a File type parameter is used. You can also specify whether the button is for opening or saving files and folders.
Rupert Weber continued his effects in cleaning up our BMP plug-in. Additionally, he has in-progress work to add support
for importing color profiles in BMPs, which will hopefully be ready in a future release.
CMYK Student updated the ICNS plug-in with new support for ic05 icon types and ARGB icon formats. They also fixed a bug when loading older ICNS formats with no transparency mask. Lukas Oberhuber assisted with diagnosing and resolving
a known bug in the ICNS format that caused our macOS icon
to show garbled pixels at small sizes.
The GEGL 0.4.54 release also contains some new enhancements and bugfixes. Thomas Manni updated the Noise Spread filter to
prevent bugs when applied to empty layer groups. Jonny Robbie added new option and paper types to the Negative Darkroom filter,
and optimized some floating point operations in GEGL as a whole.
33 people contributed changes or fixes to GIMP 3.0.0 RC3 codebase (order
is determined by number of commits; some people are in several groups):
13 developers to core code: Jehan, Alx Sa, Jacob Boerema, lloyd
konneker, Anders Jonsson, Thomas Manni, Bruno, Daniele Forsi, Lloyd
Konneker, Lukas Oberhuber, Rupert, cheesequake, Øyvind Kolås.
10 developers to plug-ins or modules: Alx Sa, Jacob Boerema, Jehan,
Rupert, lloyd konneker, Anders Jonsson, Bruno, Daniel Novomeský,
Daniele Forsi, lillolollo.
19 translators: Alan Mortensen, Alexander Shopov, Nathan Follens,
Kolbjørn Stuestøl, Hugo Carvalho, Asier Sarasua Garmendia, Ngọc Quân
Trần, Jordi Mas, Marco Ciampa, Sabri Ünal, Anders Jonsson, Danial
Behzadi, Ekaterine Papava, Jiri Grönroos, Jose Riha, Luming Zh,
Martin, Rodrigo Lledó, Yuri Chornoivan.
1 Theme designer: Alx Sa.
6 build, packaging or CI contributors: Bruno, Jehan, lloyd konneker,
Alx Sa, Rupert, Jacob Boerema.
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
GEGL 0.4.54 is made of 11 commits by 16 contributors: Øyvind Kolås,
Alexander Shopov, Hugo Carvalho, JonnyRobbie, Alan Mortensen, Anders
Jonsson, Asier Sarasua Garmendia, Bartłomiej Piotrowski, Jehan,
Martin, Nathan Follens, Nils Philippsen, Rodrigo Lledó, Sam L, Thomas
Manni, Yuri Chornoivan.
ctx had 233 commits since RC2 release by 1
contributor: Øyvind Kolås.
gimp-data had 6 commits by 4 contributors: Bruno, Jehan, Alx Sa,
Andre Klapper.
gimp-test-images (new repository for image support testing) had 5
commits by 2 contributors: Jacob Boerema, Alx Sa.
The gimp-macos-build (macOS packaging scripts) release had 6
commits by 2 contributors: Lukas Oberhuber, Bruno.
The flatpak release had 12 commits by 3 contributors after RC2
release: Bruno Lopes, Jehan, Hubert Figuière.
Our main website (what you are reading right now) had 42 commits by 6
contributors: Jehan, Alx Sa, Bruno, Jacob Boerema, Andre Klapper, Petr Vorel.
Our developer website had 18 commits by
5 contributors: Jehan, Bruno, Lukas Oberhuber, Alx Sa, Anders Jonsson.
Our 3.0 documentation had 373
commits by 13 contributors: Andre Klapper, Kolbjørn Stuestøl, Nathan
Follens, Jacob Boerema, Alan Mortensen, Yuri Chornoivan, Dick
Groskamp, Jordi Mas, Alevtina Karashokova, Alx Sa, Anders Jonsson,
Daniele Forsi, Hugo Carvalho.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
Since the 3.0RC2 news post, two new mirrors have been contributed:
Saswata Sarkar, Gurugram, India
Hoobly Classifieds, USA
Mirrors are important as they help the project by sharing the load for dozens of thousands of daily downloads. Moreover by having mirrors spread across the globe, we ensure that everyone can have fast download access to GIMP.
GIMP is often used in research, and therefore it is cited in various
science publications. A researcher using GIMP for astronomical image
processing approached
us to know how to
cite GIMP properly, even more as they say it is used to perform an
important step in their algorithm.
Since it seems like an interesting question, we updated our “Citing
GIMP and Linking to Us” page with a new “Citing GIMP in
research”
subsection containing the conclusion of this discussion.
In particular, a BibTex entry, for researchers using LaTeX to manage
their bibliography, is available on this link to simplify your work. For
instance, say you use this RC3 for your research, you may cite GIMP with
this entry:
@software{GIMP,
author = {{The GIMP Development Team}},
title = {GNU Image Manipulation Program (GIMP), Version 3.0.0-RC3. Community, Free Software (license GPLv3)},
year = {2025},
url = {https://gimp.org/},
note = {Version 3.0.0-RC3, Free Software}}
Thank you to Cameron Leahy for this piece of BibTex code!
We really appreciate all the community testing and feedback we’ve received during the last two release candidates!
This will hopefully be the final release candidate before the stable 3.0 version. Our focus now is to finish
resolving the few remaining bugs in our 3.0 milestone list,
while keeping an eye out for any new reports resulting from the changes in RC3.
Don’t forget you can donate and personally fund GIMP developers, as a way to
give back and accelerate the development of GIMP. Community commitment helps the project to grow stronger!
Several members of the GIMP team will be present next weekend
(1st and 2nd of February 2025) at
FOSDEM, a conference in Brussels,
Belgium. This event describes itself this way:
FOSDEM is a free event for software developers to meet, share ideas
and collaborate. Every year, thousands of developers of free and open
source software from all over the world gather at the event in
Brussels. You don’t need to register. Just turn up and join in!
Needless to say, with over 8000 people expected, it is one of the
biggest event in the Free Software ecosystem.
On Sunday morning, from 10 to 11:50 AM, we have 2 talks lined up,
in the main track and biggest room (Janson
in building J, with over 1400 people of capacity!), and one of these
talks is in fact a keynote:
“GIMP 3 and beyond” Date/Time: Sunday, February 2, from 10 to 10:50 AM Main track talk Speakers: Jehan (maintainer) and other GIMP team members Room: Janson, building J Streaming: live.fosdem.org/watch/janson
The keynote in particular will be a work-in-progress screening of
ZeMarmot short animation film, which is worked on by 2 major contributors of GIMP
(Jehan, maintainer, and Aryeom, designer for GIMP, and film director of
ZeMarmot) within the non-profit production
LILA which produces Libre Art movies.
Not only this, you may notice the presence of musicians, since the music
will be played live by 3 musicians from the AMMD
non-profit, producing Libre Art music, concerts and recording. The film
is a short (about 10 minutes), then it will be followed by a talk
presenting our work.
As for the GIMP talk, we will showcase the soon-to-be-released GIMP 3!
In the end of both talks, you will be able to ask questions.
After the first round of community feedback, we’re happy to share the second release candidate for GIMP 3.0!
People gave us really helpful feedback from the first release candidate and we were able to fix a lot of bugs.
It is our little under-the-tree 🎄 present for you all!
New release candidate splash screen, by Sevenix (CC by-sa 4.0) - GIMP 3.0 RC2
There have been a number of fixes since RC1. We want to highlight the most impactful
bugs so that users are aware and can provide additional testing. For details on other
bug fixes, please check our
NEWS
page in GitLab.
During community testing, we discovered that user’s 2.10 settings were not being migrated to
GIMP 3.0 due to some incorrect assumptions in the import code. Since most of the developers
have been using GIMP 3.0 exclusively for some time, we did not notice this issue. The bug
should now be fixed, so we ask for bug reports if any 2.10 preferences are not being imported
correctly in RC2. Note that if you already used 3.0 RC1, you’ll need to delete those configurations
first, as otherwise RC2 won’t try to import the 2.10 preferences (make sure you back up your settings
of course!)
In the 2.99 development releases, the Windows versions automatically launched a console display
in addition to GIMP itself. This is very useful for Windows developers to see debug messages, but
the console was not intended to be shown during stable releases. Since we changed our build process
to use Meson instead of Autotools, we learned we needed to make additional changes to stop the
console from being displayed. This should be fixed now thanks to Jehan - if you still see the
console on Windows, please file a new bug report!
There has been a long-standing issue where some macOS users only saw “missing Unicode” symbols instead
of menu text in GIMP (both in 2.10 and in 3.0). This was due to a bug in Pango,
the library we use for text layouts. This was fixed with the recent Pango 1.55.0 release, so we encourage
all third-party macOS packagers to update to this version as they build GIMP for distribution.
If you had this issue of broken fonts on macOS (left), it is now fixed (right) - screenshots by reporters - GIMP 3.0.0 RC2
After the 3.0 RC1 release, we received reports from some users that they still could not import and export
images between GIMP and darktable. We worked with the darktable developers to iron out the remaining bugs,
so integration between darktable 5.0.0 and GIMP 3.0 RC2 should be working
for everyone now. However, please file a new bug report if you continue to have trouble connecting the two!
Many of the older API wrappers for GEGL operations were removed in RC1. While this reduced technical debt,
it also caused issues for many third-party plug-in and script developers who wanted to port their plug-ins
to 3.0. While our initial plan was to implement the new public filter API after the 3.0 release, the feedback
from the community convinced us to add it in for 3.0 RC2.
Applying filters through libgimp 3.0.0 API (Script-fu et al.) - GIMP 3.0.0 RC2
Jehan‘s work allows developers to apply filter effects either immediately or as a non-destructive effect.
You can see examples of how to do this in C, Python, and Script-Fu in the
merge request, or by looking up gimp-drawable-filter
in the Procedure Browser inside GIMP. We’ve also begun using the filter
API in our Python scripts to automatically create blurred background
effects
for the Windows installer, and with this same API in C, Alx Sa added support
for importing
Photoshop’s legacy Color Overlay layer
style.
We ask for feedback and bug reports from plug-in and script authors who utilize the new filter API in their work! We have
more updates planned for it in GIMP 3.0 as well.
Discussions between color science experts Elle Stone and Øyvind Kolås revealed another area that needed
improvement as part of our Color Space Invasion project. Specifically, images with color profiles that have non-perceptual
TRCs might not be rendered correctly when set to certain layer modes.
Øyvind has implemented a correction for this problem by adding proper
perceptual space as default to specific layer modes. While we believe
this enhancement should not impact older XCF files, we of course want to
hear from you if there are any backwards compatibility issues with 3.0
RC2!
Thanks to the continued efforts of Bruno Lopes and with assistance from Samueru and the AppImage community, our experimental
AppImage now works on most Linux distros. We want to encourage more testing of it, in hopes that we can offer it as
another Linux release in addition to our Flatpak. You can see instructions to install experimental AppImage packages from our
development download page.
Our nightly flatpak has now a dedicated App-IDorg.gimp.GIMP.Nightly.
This mostly means that it can be installed side by side with the stable
flatpak while both are visible in your menus (no need to select which
version is to be shown with flatpak make-current anymore).
Yet it also means that anyone who had the nightly flatpak until now
won’t see any update coming anytime soon. In order to continue using the
nightly flatpak, uninstall the existing one and install the new one with
these commands:
⚠️ Reminder: the nightly flatpak is current development code as it
happens in source repository. At times, it may even be very broken or
render your project files invalid. We do not recommend it for
production! Use this version to help us debugging by reporting issues or
if you really like risks to test latest features.
Jehan made some quality of life improvements to the Python console. You can now use
Ctrl+R and Ctrl+S shortcuts to search through your
command history, and Page Up and Page Down now let
you scroll history in addition to the Up and Down arrow keys.
History search in Python Console with Ctrl-R - GIMP 3.0 RC2
Alx Sa implemented loading CMYKPAM files in the PNM plug-in.
On Windows, we’ve also added the ability to open images through
Windows Shortcuts (.lnk files) directly from the file chooser dialog.
This is also work by Alx Sa.
More tweaks and improvements have been made to the theme. In particular, the slider styling has
been substantially improved after feedback and work from Denis Rangelov. Denis also made new
icons for the Navigation Dockable Dialogue, replacing duplicates with distinct symbols.
Anders Jonsson has also been reviewing the theme and removing some workarounds which were required
in GIMP 2.10, but no longer needed with our new 3.0 themes.
Idriss Fekir has made improvements to our XCF font loading code, to improve compatibility
when importing older XCF files.
For those who haven’t followed GIMP’s development as closely, these news posts only cover
incremental changes since the last release. They do not list every change or improvements
made for GIMP 3.0 - that would be a very long article indeed!
While we’ll have full release notes for the final 3.0, we thought it’d be helpful
to summarize a few of the major changes made during the 2.99 development process:
The initial work to port GIMP to GTK3 occurred in 2.99.2.
This release also introduced multi-layer selections, along with initial API changes and
color space management improvements.
More API updates were made in 2.99.4, including the ability to auto-generate plug-in UIs
based on user input. Various usability improvements were also made, along with the introduction of the experimental Paint Select tool.
2.99.6 brought more API updates and internal work.
More user-facing features included the ability to place guides outside the canvas, better touchpad support, and more support for
different PNG color metadata.
The development pipeline was improved significantly in 2.99.8,
allowing for faster build times and automation. Support for new file formats like PSB and JPEGXL were added in this release,
along with Windows Ink tablet support.
2.99.10 introduced “layer sets”, replacing the older concept
of linked layers. Painting dynamics were streamlined in this release, along with the first version of the Welcome dialog.
Early-binding CMYK support was implemented in 2.99.12.
The CSSGUI themes also received a major overhaul in this release, along with more file format supports and major
improvements to Script-Fu.
2.99.14 saw the introduction of non-destructive outlines
for the text tool. The alignment tool was also revised, theme and icon scaling were improved, and floating selections were
largely replaced in the workflow.
The GTK3 port was finally completed in 2.99.16. The / search
pop-up was updated to show the menu path for all entries, as well as making individual filters searchable.
Non-destructive filters were first introduced in 2.99.18.
Major color management improvements were also made, and new auto-expanding layer boundary and snapping options were also implemented.
Similar to GIMP, there’s a number of bugfixes for the GEGL 0.4.52 release. Øyvind Kolås has fixed some generic “Aux input”
labels to be more meaningful - this will be visible in GIMP’s filters as well. He also improved the accuracy of some filter’s
color processing. Longtime contributor Thomas Manni also fixed crashes when some filters were run on very small layers.
18 translations were updated: Bulgarian, Catalan, Chinese (China),
Chinese (Taiwan), Danish, Finnish, Georgian, Icelandic, Italian,
Latvian, Lithuanian, Norwegian Nynorsk, Persian, Portuguese, Russian,
Slovenian, Swedish, Ukrainian.
35 people contributed changes or fixes to GIMP 3.0.0 RC2 codebase (order
is determined by number of commits; some people are in several groups):
12 developers to core code: Jehan, Alx Sa, Michael Schumacher, Anders
Jonsson, Lloyd Konneker, Øyvind Kolås, Idriss Fekir, Andre Klapper,
Jacob Boerema, Michael Natterer, Rupert Weber, Thomas Manni.
11 developers to plug-ins or modules: Jehan, Lloyd Konneker, Alx Sa,
Rupert Weber, Daniel Novomeský, Jacob Boerema, Aki, Bruno, Ryan Sims,
Simon Munton.
19 translators: Alan Mortensen, Cheng-Chia Tseng, Kolbjørn Stuestøl,
Rūdolfs Mazurs, Jiri Grönroos, Sveinn í Felli, Alexander Shopov,
Aurimas Černius, Marco Ciampa, Danial Behzadi, Hugo Carvalho, Jordi
Mas, Anders Jonsson, Ekaterine Papava, Julia Dronova, Luming Zh,
Martin, Michael Schumacher, Yuri Chornoivan.
2 Theme designers: Alx Sa, Anders Jonnson.
2 documentation contributors: Jehan, Bruno.
5 build, packaging or CI contributors: Bruno, Jehan, lloyd konneker,
Alx Sa, Jacob Boerema, Rupert Weber.
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
GEGL 0.4.52 is made of 31 commits by 16 contributors: Øyvind Kolås,
Sam L, Thomas Manni, lillolollo, Alan Mortensen, Anders Jonsson,
Ekaterine Papava, Hugo Carvalho, Jordi Mas, Juliano de Souza Camargo,
Kolbjørn Stuestøl, Lukas Oberhuber, Luming Zh, Marco Ciampa, Martin,
Yuri Chornoivan.
ctx had 48 commits since RC1 release by 1
contributor: Øyvind Kolås.
gimp-data had 6 commits by 5 contributors: Anders Jonsson, Jehan,
Sevenix, Alx Sa and Denis Rangelov.
gimp-test-images (new repository for image support testing) had 2
commits by 1 contributor: Rupert.
The gimp-macos-build (macOS packaging scripts) release had 5
commits by 1 contributor: Lukas Oberhuber.
The flatpak release had 4 commits by 2 contributors: Bruno Lopes, Jehan.
Our main website (what you are reading right now) had 29 commits by 3
contributors: Jehan, Alx Sa, Andrea Veri.
Our developer website had 16 commits by
2 contributors: Jehan, Bruno Lopes.
Our 3.0 documentation had 157
commits by 10 contributors: Andre Klapper, Kolbjørn Stuestøl, Jacob
Boerema, Alan Mortensen, Anders Jonsson, Marco Ciampa, Jordi Mas, Yuri
Chornoivan, Alx Sa, Jiri Grönroos.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
GNOME has moved away from using mirrors
during their latest infrastructure update. As our download mirrors are hosted by them, we were asked if
we wanted to move as well. As a community project, we value everyone who contributes a mirror to make GIMP
more accessible in their area. Therefore, we have decided to stay with using mirrors to distribute GIMP.
If you are interested in contributing a mirror for your region, here is the new procedure:
Tell us about why you want to mirror GIMP, which other Free Software
you already mirror, what is your setup, the server’s location…
Tell us about you: are you an organization or an individual? Give us
the specific name and URL to be shown in the mirror sponsor
list.
Once we are done verifying your organization, rsync credentials will
be exchanged securely, allowing you to sync your mirror with the
source server
There is nothing to do in particular to appear on the
Sponsors page which will be updated regularly through scripts. Yet it
may take a few days or even weeks at times. So don’t worry if your
organization name does not appear immediately!
🛈 We programmatically check at random intervals that mirrors are updated
quickly enough and that the data match for obvious security reasons.
Also, since the 3.0RC1 news post,
a new mirror has been contributed:
Sahil Dhiman, Mumbai, India
Mirrors are important as they help the project by sharing the load for dozens of thousands of daily downloads.
Moreover by having mirrors spread across the globe, we ensure that everyone can have fast download access to GIMP.
GIMP’s code repository is also hosted on GNOME’s GitLab platform.
Andrea Veri asked if we would be able to sponsor a runner on the platform, which allows any project
on the platform to test building their software before, during, and after code changes are made.
After a vote by GIMP’s committee, we
agreed and are now the sponsors of an x86 CI/CD runner!
Universal Windows installer for x86 (32 and 64-bit) and for ARM (64-bit)
MSIX package (GIMP Preview) for x86 and ARM (64-bit)
macOS DMG packages for Intel hardware
macOS DMG packages for Apple Silicon hardware
Other packages made by third-parties are obviously expected to follow (Linux or *BSD distributions’ packages, etc).
🛈 Notes:
The 2 macOS DMG packages will likely be late as we are waiting for
Apple update’s validation by the GNOME Foundation before being able to
sign our packages.
The MSIX package takes usually a few business days of validation by
Microsoft.
Thanks to the huge amount of reports we got for our first release
candidate, we are able to present you this second version which is all
the more robust. As you saw, a few additional surprises 🎁 came together
with bugfixes, in particular the new filter API, which triggered support
of PSD legacy Color Overlay import, improved blend modes and compositing,
and more. We thought that it was worth breaking the feature freeze for
these changes and that this will make all the difference!
With this second release candidate, we are closer than ever to actual
GIMP 3.0.0. As usual, we are looking forward to any new community issue
reports allowing us to
finalize the 3.0.0 release! 🤗
Don’t forget you can donate and personally fund GIMP
developers, as a way to give back and
accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
🎅🎄🎉 Oh and of course, the whole team wishes you all a happy holiday season! 🥳🥂🎆
We are very excited to share the first release candidate for the long-awaited GIMP 3.0! We’ve been hard at work since our last development update to get this ready, and we’re looking forward to everyone finally being able to see the results.
New release candidate splash screen, by Sevenix (CC by-sa 4.0) - GIMP 3.0 RC1
So, what exactly is a “release candidate” (RC)? A release candidate is something that might be ready to be GIMP 3.0, but we want the larger community to test it first and report any problems they find. If user feedback reveals only small and easy to fix bugs, we will solve those problems and issue the result as GIMP 3.0. However, we hope and expect a much larger audience to try out 3.0 RC1 - including many people who have only been using 2.10 up until now. If larger bugs and regressions are uncovered that require more substantial code changes, we may need to publish a second release candidate for further testing.
The current Wilber logo was created by Jakub Steiner for GIMP 2.6 in 2008! While it is still a fantastic logo, design trends have changed a bit in the last sixteen years and Wilber’s more detailed appearance sticks out on modern desktops.
If you’re interested in learning more about the design choices, usage, and design variants, please check out our logo guide. We also documented the history of the Wilber logo.
Our wonderful new splash screen (shown at the top of this news post) was created by longtime contributor and artist Sevenix! You can see more of their work on their personal art page.
Going forward, we plan to change splash screens much more frequently to show off all the many kinds of art made with GIMP (photography, illustration, design…).
Related to this, we have created an updated splash screen archive to highlight the work of current and previous splash screen artists.
One of the major improvements from the GTK3 port is that the vector UI icons now scale more cleanly based on your preference settings. Our Legacy icon theme was mainly raster PNGs however, so it could not take advantage of the GTK3 scaling system. Contributor Denis Rangelov took on the extensive challenge of recreating the Legacy tool icons as SVGs. Now both of GIMP’s icon themes look great on HiDPI screens!
The work is not finished, as many icons are still non-scalable and some icons are still missing. Denis has expressed interest in continuing to improve the Legacy icon theme, so we hope to rename it as Classic when this project is achieved, to show it is now well-maintained.
One of the key changes in 2.99.18 was massive improvements to color management in GIMP. As this work was not fully finished in 2.99.18, it was a major blocker of the 3.0 RC1 release.
Since that release, we have found and fixed a number of bugs and missed areas that needed to be color space aware. We have also reviewed reports by color expert Elle Stone to make sure that the color values shown by GIMP are as accurate as possible. At the same time, it’s very important to ensure that XCF project files created in GIMP 2.10 and before will render the same when opened in 3.0. For instance, one of the first Google logos was created in GIMP - and if you open the original XCF project file in GIMP 3.0 RC1, it still appears the same as it did when it was created in 1998!
Therefore, we have thoroughly reviewed the various layer modes to ensure that commitment to compatibility is retained for this release.
Color space invasion is a long-running project, which will continue after GIMP 3.0 is released.
Another task that had to be finished before the 3.0 release was finalizing the public API. Since our last news post, we finished the remaining major changes - replacing all instances of our custom GimpRGB color structures with the better color-managed GeglColor, and improving our array format so the number of elements does not have to be specified separately. This work was a long process by Jehan and Lloyd Konneker, with a great deal of bugtesting and feedback from Anders Jonsson.
In addition, a number of functions have been added, renamed, or removed from the public API compared to 2.10. For instance, an older patch by Massimo Valentini adds gimp-context-get-emulate-brush-dynamics and gimp-context-set-emulate-brush-dynamics, which allows script and plug-in developers to use the Emulate Paint Brush Dynamics setting when painting. On the other hand, the various gauss functions were all consolidated into a single function, plug-in-gauss. While this change will require some updates in existing scripts, developers now have more direct control over the Gaussian Blur effect rather than relying on hidden preset values.
Since the API is now stable, plug-in and script developers can begin porting their 2.10 scripts based on this release. You can find initial API documentation on our developer site. We intend to add more tutorials and porting guides here during the release candidate phase. We also encourage you to check out the Script-fu and Python plug-ins in our repository to see working examples of the new API.
Since our last update, we have continued to make improvements and bug fixes to our non-destructive filter code. Many of these issues were reported by Sam Lester during the developing and testing of his third-party GEGL filters.
While non-destructive filters have been a very popular addition to GIMP 3.0, some early adopters have requested that we provide a way to return to the original destructive workflow. Therefore, we have added an optional “Merge Filters” checkbox at the bottom of NDE filters. If enabled, the filter will be immediately merged down after it is committed. Note that filters can not be applied destructively on layer groups – in those cases, the option to merge filters is not available.
Example of Filter with “Merge Filter” checkbox - GIMP 3.0 RC1
On a related note, Jehan also implemented storing version of filters in GIMP’s XCF project files. This will allow us to update filters in the future without impacting how older project files look when they’re opened. Additional work will be needed in GEGL to fully implement this feature, but that can be done after 3.0 without impacting existing project files.
GIMP 3.0 RC1 contains several updates to the user interface. For example, more aspects of the GUI are now able to take advantage of the multi-select features implemented by Jehan in earlier versions of 2.99.
We also restored the ability to use the mouse scrollwheel to flip through the different dockable dialogue tabs. This feature was built into GTK2 but removed in GTK3. Per user request, we reimplemented this feature in GIMP itself based on a similar implementation in geany.
During development, we received a report that the scrolling credits in our About Dialog could cause discomfort due to its motion. As a result we’ve added code to check your operating system’s “Reduced Animation” setting and turn off those animations in GIMP per your preference settings.
As we have been in a feature freeze since the last release of 2.99, most of the changes to plug-ins have been API updates and bug fixes (some of them for issues that were quite old). However, a few smaller enhancements have been implemented.
The BMP format now supports 64 bits per pixel images. New contributor Rupert Weber assisted us with adding support for importing this BMP format correctly. They have also submitted patches with more fixes to our BMP plug-in and testing pipeline.
Since GIMP 2.99.16, we’ve been able to import TIFFs with Photoshop format layers. However, the Alias/Autodesk Sketchbook program created their own standard to save layers which was not compatible. Since this was marked as a bug in our issue tracker, we added support for loading layers from TIFFs saved in Sketchbook format as well.
Both GEGL and babl have seen a number of updates since their last releases in February.
GEGL 0.4.50 introduces a number of new filters created by Sam Lester.
Inner Glow
Bevel
GEGL Styles
*GEGL Styles* effect - GIMP 3.0 RC1
These can all be accessed via the GEGL Operations tool, or by searching for them with the / search action shortcut.
Øyvind Kolås made a number of bug fixes and improvements to the stability of GEGL. Several changes were also made related to the color space invasion in GIMP, such as adding convenience methods for getting and setting GeglColors in HSV(A) and HSL(A) color models, implemented by Alx Sa. Jacob Boerema and his GSoC student Varun Samaga B L merged a number of improvements to the OpenCL version of filters. While GIMP still does not enable OpenCL by default, their work brings us much closer to being able to so. We will discuss these improvements in a future news post.
babl 0.1.110 also received some contributions during this cycle. Jehan implemented new conversion processes between RGB and HSL color models, which improves the performance of a number of filters compared to GIMP 2.99.18. He also fixed certain parts of the code that behaved differently depending on whether your processor supported SSE2. Øyvind Kolås improved the accuracy of several sections of code when converting from floating point to integer values. Additionally, Lukas Oberhuber found and fixed a memory leak and Jacob Boerema fixed an issue where images with NaN could cause a crash.
31 translations were updated: Basque, Belarusian, Brazilian
Portuguese, British English, Bulgarian, Catalan, Chinese (China),
Chinese (Taiwan), Danish, Dutch, Galician, Georgian, German, Greek,
Hungarian, Icelandic, Italian, Korean, Latvian, Norwegian Nynorsk,
Polish, Portuguese, Russian, Serbian, Serbian (Latin), Slovenian,
Spanish, Swedish, Turkish, Ukrainian, Vietnamese.
72 people contributed changes or fixes to GIMP 3.0.0 RC1 codebase (order
is determined by number of commits; some people are in several groups):
27 developers to core code: Jehan, Alx Sa, Jacob Boerema, bootchk,
Anders Jonsson, Øyvind Kolås, Cheesequake, cheesequake, Niels De
Graef, Idriss Fekir, Simon Budig, lillolollo, lloyd konneker, Andre
Klapper, Andrzej Hunt, Bruno, Joachim Priesner, Nils Philippsen,
Alfred Wingate, Bruno Lopes, Elle Stone, Kamil Burda, Luca Bacci, Mark
Sweeney, Massimo Valentini, Oleg Kapitonov, Stanislav Grinkov, megakite.
15 developers to plug-ins or modules: Alx Sa, Jehan, lloyd konneker,
bootchk, Jacob Boerema, Anders Jonsson, Nils Philippsen, Andrzej Hunt,
Andre Klapper, Rupert, Bruno Lopes, Daniel Novomeský, Mark Sweeney,
Stanislav Grinkov, lillolollo.
42 translators: Martin, Yuri Chornoivan, Luming Zh, Rodrigo Lledó,
Kolbjørn Stuestøl, Ekaterine Papava, Cheng-Chia Tseng, Sabri Ünal,
Marco Ciampa, Tim Sabsch, Jordi Mas, Alexander Shopov, Anders Jonsson,
Alan Mortensen, Asier Sarasua Garmendia, Sveinn í Felli, Andi
Chandler, Balázs Úr, dimspingos, Juliano de Souza Camargo, Ngọc Quân
Trần, Vasil Pupkin, Alexandre Prokoudine, Bruce Cowan, Jürgen
Benvenuti, Nathan Follens, Милош Поповић, Balázs Meskó, Christian
Kirbach, Daniel, Emin Tufan Çetin, Fran Dieguez, Guntupalli Karunakar,
Hugo Carvalho, Jehan, Philipp Kiemle, Piotr Drąg, Robin Mehdee,
Rūdolfs Mazurs, Seong-ho Cho, Víttor Paulo Vieira da Costa, ayesha akhtar.
7 resource creators (icons, themes, cursors, splash screen,
metadata… though a good part of there were moved to gimp-data
repository): Alx Sa, Jehan, Bruno Lopes, Anders Jonsson, Jacob
Boerema, bootchk, nb1.
10 documentation contributors: Jehan, Bruno, Lloyd Konneker, Alx Sa,
Bruno Lopes, Anders Jonsson, bootchk, Lukas Oberhuber, Andre Klapper,
Jacob Boerema.
11 build, packaging or CI contributors: Bruno Lopes, Jehan, bootchk,
Alx Sa, lloyd konneker, Jacob Boerema, Niels De Graef, Alfred Wingate,
Lukas Oberhuber, Michael Schumacher, Anders Jonsson.
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
babl 0.1.110 is made of 22 commits by 7 contributors: Øyvind Kolås,
Jehan, Bruno Lopes, Anders Jonsson, Biswapriyo Nath, Jacob Boerema,
Lukas Oberhuber.
GEGL 0.4.50 is made of 204 commits by 33 contributors: Øyvind Kolås,
Sam Lester, Martin, Varun Samaga B L, Yuri Chornoivan, Luming Zh,
Rodrigo Lledó, Jehan, Jordi Mas, Anders Jonsson, Kolbjørn Stuestøl,
Marco Ciampa, Sabri Ünal, Bruno Lopes, Alan Mortensen, Asier Sarasua
Garmendia, Ekaterine Papava, Bruce Cowan, Lukas Oberhuber, Tim Sabsch,
psykose, Alexandre Prokoudine, Alx Sa, Andi Chandler, Andre Klapper,
ArtSin, Daniel Șerbănescu, Jacob Boerema, Joe Locash, Morgane Glidic,
Niels De Graef, dimspingos, lillolollo.
ctx had 616 commits since 2.99.18 release by 2
contributor: Øyvind Kolås, Ian Geiser.
gimp-data (new repository holding images, splashes, icons and other
binary data for the software) had 76 commits by 7 contributors: Jehan,
Aryeom, Bruno, Alx Sa, Denis Rangelov, Anders Jonsson, Bruno Lopes.
The gimp-macos-build (macOS packaging scripts) release had 41
commits by 3 contributors: Lukas Oberhuber, Bruno Lopes, Jehan.
The flatpak release had 38 commits by 4 contributors: Bruno Lopes,
Jehan, Hubert Figuière, Will Thompson.
Our main website (what you are reading right now) had 60 commits since
2.10.38 release by 5 contributors: Jehan, Alx Sa, Andre Klapper,
Bruno Lopes and Denis Rangelov.
Our developer website had 33 commits
since 2.10.38 release by 5 contributors: Bruno Lopes, Jehan, Lloyd
Konneker, Alx Sa, Lukas Oberhuber.
Our 3.0 documentation had 928
commits since 2.99.18 release by 14 contributors: Andre Klapper,
Kolbjørn Stuestøl, Jacob Boerema, Alan Mortensen, Yuri Chornoivan,
Jordi Mas, Marco Ciampa, Anders Jonsson, Sabri Ünal, dimspingos, Alx
Sa, Andi Chandler, Daniel, Nathan Follens.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
We are well aware that the path to GIMP 3.0 has been a long one, and GIMP 2.10 users have not had access to all of the great new features we’ve been working on over the years. Going forward, we are restructuring our development process to decrease time between releases. As briefly mentioned in our post 3.0 roadmap, we want to focus on smaller, feature-focused releases. This means that we are aiming for GIMP 3.2 to come out within a year after the final release of 3.0, rather than in 2050 as is often joked! Micro releases with bug fixes may happen in-between.
Smaller releases with few “big” features will also allow us to more thoroughly test each change, further improving the stability of each release. During the 3.0 development process, developers like Jacob Boerema, Lloyd Konneker, Bruno Lopes, and Jehan have been creating and improving our automated testing processes to further catch and identify bugs early. We will talk more about these improvements in future news posts.
FCIX, in the Dominican Republic, Australia and 2 in the USA.
Taiwan Digital Streaming Co., Taiwan
OSSPlanet, Taiwan
Shrirang Kahale, India
This brings us to a total of 56 mirrors from all over the world!
Map of GIMP Mirrors worldwide, generated from MirrorBits
Mirrors are important as they help the project by sharing the load for dozens of thousands of daily downloads. Moreover by having mirrors spread across the globe, we ensure that everyone can have fast download access to GIMP.
Bruno Lopes has truly taken the lead to improve our build and packaging process on multiple platforms.
Over the summer, he created an experimental AppImage build (as detailed in a prior news post). If you are interested in improving it further and hopefully making it available as a standard download, please get in touch! Bruno has also created flatpak build scripts to make the process of creating your own GIMP flatpak much easier.
A lot of work was done to improve our presence on the Microsoft Store for 3.0. Our GIMP 2.10 app was not fully integrated into the store platform due to certain limitations - it is really just a wrapper for our existing GIMP installer. Therefore it did not automatically update for users and it was not possible to automate installations with tools like Microsoft Intune. Thanks to a lot of effort on Bruno’s part, we will have a new GIMP app in the Microsoft Store which resolves these issues (and many others) for the final GIMP 3.0 release. From now, we also have a separate GIMP (Preview) which allows you to install development versions in a similar manner to the Beta flatpak on Linux. You can try it out at this Microsoft Store link.
(For technical and maintenance reasons described here, 32-bit binaries will not be available in the new MSIX packages of GIMP, which unfortunately removes support for the legacy TWAIN plug-in in x64 and arm64 packages used for quick scanning. If you depend on these, the .exe installer still supports 32-bit processors. However, the support for this architecture is planned to be dropped in the future)
Additionally, the standard Windows installer has been updated to a more modern design. It also lets you install individual language packages and lets you start up GIMP immediately after the installer is finished. For the more technically inclined, the Windows build scripts have also been ported to use PowerShell, and the cross build scripts can now run locally.
Due to changes and updates in our software building infrastructure, we’ve had to raise the minimum OS requirement for MacOS to Big Sur (MacOS 11).
Earlier this year, the GNOME Foundation announced a fiscal sponsorship agreement with GIMP. This is all thanks to a lot of hard work by Jehan over many, many months. Our goals with this agreement are to support stable funding for developers interested in working on GIMP for a longer term through grants, and to provide easier ways for people to contribute to GIMP’s development. This is still a work-in-progress, so we will make a more detailed announcement once everything has stabilized.
Thanks to volunteer translators, we now have a Bengali language translation of GIMP! If you are interested in translating GIMP into your own language or assisting with an existing translation, you can find out how here.
We are now entering the last stage of this major release: candidates for
the final version! Though one can always hope to get a RC right the first time, experience
tells us that this RC1 — which is the result of more than 6 years of
work — will likely have problems, bugs, probably nasty crashes. This is
where we need you all! We rely on everyone to find and
report issues so that
the actual 3.0.0 release can really be considered stable. 🤗
Some small bugs may be considered secondary (though we still welcome
reports for all bugs, even smaller ones!), because perfection barely
exists in software. There are other things in particular we really want
to catch, such as:
any inconsistency or problem in the API (it will stay stable for the
whole v3 series, so if there are problems to find, it’s now; we want a
robust plug-in framework);
bugs when reading or rendering existing XCF made by former stable
versions of GIMP;
crashes;
regressions;
proper migration of configuration from previous versions.
We are not giving out a date estimate for the actual 3.0.0 release,
firstly because we can’t know for sure, secondly because each time we
do, news outlets seem to just skim every warning out of our text and
transform our words into unbreakable promises. Just know that we also
want it to happen as soon as possible, i.e. when we can consider our
software to feel stable enough.
Don’t forget you can donate and personally fund GIMP
developers, as a way to give back and
accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
This is a short development update on our progress towards the first release candidate for GIMP 3.0.
We recently reached the string freeze milestone. What this means is that there will be no more changes in user-facing text (like GUI labels and messages) so that translators can work on the final translations for the 3.0 release.
Progress on completing the blocking issues for 3.0 slowed over the summer due to the maintainer and some of the main developers falling ill after the Libre Graphics Meeting conference. This is why we are “late” compared to our original estimated timelines. Thankfully everyone’s feeling much better now, and work has resumed in earnest! As of this writing, we’re currently at 96% completion for the 3.0 RC1 milestone, with 11 issues remaining.
We’ll have a lot more to share in the news post for GIMP 3.0 RC1. However, here are a few highlights to show what we’ve been working on the last few months:
Finalizing the API is a crucial task for GIMP 3.0. As we’ve added new features and improved existing ones during development, we’ve needed to make “breaking” changes to the public API. This means that if a third-party developer ported their 2.10 plug-in or script to use GIMP 2.99.16’s API, it might not work with the 2.99.18 API due to further changes. Once 3.0 is released however, any function that’s in the public API must continue to work for all future releases of GIMP 3. So we have to get it right before the first 3.0 release!
Most of the API changes are invisible to non-developers, so we won’t detail all of them here. However, we’d like to share a few to illustrate the on-going work:
Over several past releases, our internal plug-ins have been ported to the new GimpProcedure and GimpProcedureDialogAPI. This update automatically saves the last settings used, letting users reset to it or to the “factory default” values whenever they like. The GimpProcedureDialogAPI also allows developers to automatically create a GUI based on the settings they defined.
Until recently though, this GUI creation feature was only fully available to C plug-ins – other plug-in languages like Python couldn’t generate certain widgets such as dropdown boxes and radio buttons. Since the 2.99.18 release however, we’ve been able to make the full API available to all supported plug-in languages. Python plug-in developers can see more examples of how to use this new API in the Python plug-in section of our repository. Once the API is fully stabilized, we’ll update our developer website with more tutorials on how to use this and other APIs in your plug-ins.
Example of generated dialog (Palette Sort Python plug-in)
Lloyd Konneker has been organizing and implementing many improvements to our Script-fu code library. For script developers, script-fu-register has been deprecated and replaced with two new functions: script-fu-register-procedure for general scripts and script-fu-register-filter for image-processing scripts. These two new script functions also use the GimpProcedureDialogAPI, so script developers will have access to the same automated GUI creation mentioned in the last section. You can look at our in-progress guide to see how you can use these new features when porting your 2.10 plug-in scripts.
A long standing feature request has been exporting images with different settings, while leaving the original image unchanged. For instance, letting users export an image in several different sizes.
The new GimpExportOptions class sets the groundwork for us to implement this in future 3.x releases. We’ve simplified how images are exported using the plug-in API, and moved much of the export settings code to the GimpExportOptions parameter. This change will allow us to add new types of export settings and features after 3.0 without plug-in developers having to make changes to their own code. As a nice side-effect, this work also fixed some existing inconsistencies between exporting an image from GIMP’s GUI and exporting from a script.
The second remaining area of work for 3.0 is finishing the color space invasion project. Our goal is for the color space and color profile information to be associated with the pixels in all aspects of GIMP, from the canvas to the GUI and everywhere in-between. This is important for artists to keep colors consistent on all devices and monitors they use. The first half of this work was completed by Jehanin the 2.99.18 release. Since then we have been fixing the inevitable bugs from such a large change while making the rest of GIMP color-space aware. This work overlaps with the API changes, as several of our code functions still assumed the colors were in the sRGB color space.
In addition, we’ve been reviewing the existing color algorithm to make sure they are correct and performing efficiently. Øyvind Kolås and Elle Stone have provided great insight and assistance with this process. We want to ensure that your GIMP 2.10 XCF project files look the same when opened in GIMP 3.0, but we also want to set up infrastructure to improve the accuracy of layer modes and other aspects of GIMP going forward.
Since introducing non-destructive filters in GIMP 2.99.18, we’ve received a lot of great feedback and bug reports from early adopters. Based on these reports we’ve fixed many bugs related to copying, pasting, and updating filters, along with improving the general stability of the effects code. The temporary filter icon has also been replaced by a more intuitive design from new contributor Denis Rangelov (created with the vector art program Inkscape, another FLOSS project that we highly recommend).
In addition to on-going bug fixes, we’ve also implemented non-destructive filters on layer groups. Now you can add an adjustment filter like Brightness-Contrast (or any other layer effect) to a group and have it change the display of each layer inside it.
Example of Color Temperature non-destructive editing filter being applied to a layer group. Photos by Andrea Luck, Attribution (CCBY 2.0)
Øyvind has also worked hard on ctx these last few months, including improving portability for various platforms (on all types of architectures, libc and OSes), improving performance and massively profiling and fuzz-testing the project. For reminder, ctx is one of the latest ambitious project in the GIMP family, for 2D vector rendering and serialization. Though it is not necessarily used a lot in GIMP itself yet, it may pave the way for future work on more vector abilities in our software.
Of course, all this happens while still maintaining babl and GEGL, our color conversion engine and graph-based pixel processing framework.
These 2 libraries do not receive significant changes lately, despite all the work done with the Color Space Invasion and the non-destructive editing projects, which is quite a good sign of a stable software in good shape!
Bruno Lopes has been working hard to improve our build processes on all platforms. His on-going work has helped reduce redundancies and inefficiencies in our development pipeline, Windows installers, and Flakpak distributions. He is also preparing a new version of our Microsoft Store installer that will be better integrated into the platform, and as noted in a prior news post, he’s experimenting with an AppImage version of GIMP. You can also thank Bruno for his work in updating the build documentation on our developer website.
While GIMP does not natively process RAW images, we have plug-ins that allow sending and retrieving images with great FLOSS raw photo processing software like darktable and RawTherapee. Earlier this year, darktable updated their public API which GIMP uses to set up this connection - causing the plug-in to stop working. Fortunately Hanno Schwalm and other darktable developers worked with us to create a GIMP-specific API that should be more stable going forward. We really appreciate collaborating with darktable developers to restore this connection!
(Note that this updated API is not yet available in GIMP 2.10.38 or GIMP 2.99.18. For now, you can use darktable 4.6 and below with GIMP as a workaround)
With all the new changes and improvements in GIMP 3.0, the help manual needs a lot of updates from 2.10. Jacob Boerema has taken
the lead on this project to update screenshots and text as well as adding new sections. This is an area where anyone can help
without needing to write a line of code! You can review the upcoming documentation on our help manual test site. If you notice something’s missing or outdated, you can post about it on our issue tracker. If you want to help further, you can also fix the problem yourself and submit a merge request.
Preview of GIMP 3.0 Help Manual; illustration by Aryeom (CC by-sa 4.0)
Since the feature freeze milestone, we’ve been focused on fixing as many bugs as we can before the first release. These include everything from older bugs that existed in GIMP 2.10, to recent ones created as we implemented all the new features for GIMP 3.0. Special thanks to Anders Jonsson, Andre Klapper, Lloyd Konneker, and Sam Lester for their extensive work finding and fixing these bugs! Early adopters and testers have also provided valuable bug reports, so if you’ve come across a bug in the development releases, please report them on our issue tracker.
We once again participated in GSoC this summer. We were fortunate to work with three student contributors this time around. Due to the circumstances mentioned above, their projects were scaled back a bit compared to our initial plans. Still, all three students did great work!
Idriss Fekir continued his work on improving the text tool from GSoC 2023. His work also overlapped with the color space improvements, such as fixing issues with text color as we made it color-space aware.
Cheesequake did initial research and design for eventually porting our GtkTreeViewGUI to GTK4. He also assisted with many bug fixes for our non-destructive editing code.
Varun Samaga B L worked on improving OpenCL code in GEGL. OpenCL speeds up the performance of filters and other aspects of GIMP by taking better advantage of your graphics card’s multi-processing capabilities. You can see a more detailed write-up from Varun on his GSoC report.
We really appreciate all the hard work from our GSoC students!
One area we want to focus on after 3.0 is improving our UI/UX design process. We have set up a separate UX repository to report and discuss issues related to design. We are looking to build a team of designers to discuss and create design improvements to GIMP that also respect existing user’s workflows. Denis Rangelov has taken a strong interest in this area and has already done great work in identifying, categorizing, and moving design issues from the code repository to the dedicated design section. Some design improvements have already been implemented for 3.0, and we look forward to working with community designers to give people a better experience!
There’s a lot more work going on behind the scenes, and we look forward to sharing it with you soon in the 3.0 RC1 release news post! If you haven’t already, you can test out the 2.99.18 release from the development downloads page. It does not include any of the improvements we’ve made since its release, but it still gives a good preview of
what 3.0 will look like.
Don’t forget you can donate and personally fund GIMP developers, as a way to give back and accelerate the development of GIMP. Community commitment helps the project to grow stronger!
Earlier in April and May, we were working behind the scenes on improving our
CI and build-related code. In this
context, one thing that came up was: how easy it is to test a merge request on
Linux? For example, on Windows, we have .zip files for each commit; on macOS,
we have .app (inside .dmg). For Linux… well we had none (we have weekly
flatpak builds but they are time consuming for testing purposes). So, after a
brief consideration we decided to go with AppImages.
AppImage is a application package format, basically a bundle, that’s great for
the development and testing workflow described above. To be clear,
⚠️ we’re not distributing AppImage as official packages yet ⚠️
(more about this later in this post). About the experiments…
AppImage doesn’t have a mandatory SDK. The creation process can be done using freely available tools,
such as linuxdeployqt, appimage-builder and AppImageKit. But we decided to
go with go-appimage, which is multi purpose and ours is to do a quick test build.
In our case, the tool is responsible for bundling almost every dependency and
for squashing everything with proper ELF data to be executable in one click. But the tool, naturally,
can’t guess the particularities of the different software (e.g. use of script
interpreters), so we need to copy and set some things
manually.
By the way, we opened issues in the go-appimage repo in the hope of improving
some things, one little example of FOSS collaboration.
Of course, we didn’t start from scratch! We learned from other unofficial GIMP
AppImage builds (a list of which can be found here).
Maybe there are others, but we could only find these four.
We also contacted the developers of these unofficial builds for testing and
feedback about a potential official appimage. Huge thanks to them! Also, other
people contributed too (this info can be found in the merge request).
Thanks to all people involved! 😄
We couldn’t simply take these unofficial appimages code and put it in our repo
because this isn’t how software works. Our code, even the packaging code,
preexists the new packaging (in this case, bundling) so the former needs to be
considered in order to the proper adaptations be made into the later.
Considering our past packaging code and experiences, we defined some principles
to be checked before approving a new package format. In short, the format needs to:
Have its scripts inside GIMP repo and using GIMP/GNOME runners for better transparency
(macOS is the exception right now for historical reasons, which should ideally be fixed in the future);
Have its scripts building/packaging over official GIMP git source/binaries for better security;
Have its scripts simplified and human-readable as much as possible for better maintenance.
The last point assumes that some person is maintaining the package, and this is
the main reason our appimage (bundle) is not ready for distribution yet. No person
volunteered to tackle this responsibility by following these principles. So, the
best that we could do, staying compliant with the principles, was a testing bundle.
Our appimage can be used, and it’s indeed being used right now
to triage issues and test merge requests on the Debian version supported
by the respective branch (on master branch it is Debian 12 currently), and that
has been very handy. Let us explain:
Suppose that you don’t have a very powerful machine, which is very common.
Normally, you will only build GIMP natively and contribute to this specific
platform, since building inside a VM is quite clumbersome. But thanks to our
testing AppImage:
a Windows user can just log into the VM, download the Debian artifact from
the MR and test it. We have contributors that use Windows VM (and they can
download the cross .zip artifact), now the inverse is possible;
And this is useful for issues too: triaging them recommends the latest master
so constant local rebuilding. Fortunately, this isn’t needed since our CI auto
generates an .appimage for every new commit.
Of course, this is a limited use case and makes our appimage unsuitable even
for being linked in the dev version download page. Not every contributor uses
Debian (12) nor does every Windows or Mac contributor have a Debian (12) VM.
To be fair, if the appimage displays problems that we can’t fix, it can even
be dropped at any time.
So, we welcome contributions to improve compatibility with other distros
(at least the oldest supported Ubuntu and newest Fedora) in order to raise it to a
package level. If you are interested, talk to us.
The Libre Graphics Meeting (LGM) is the biggest international
gathering of Free Software for graphics creation. Born in
2006 as an evolution of our
GIMPCon, the event went on
every year since then, thanks to the support of various major projects,
such as Blender, Inkscape,
Scribus… until 2019, because of a pandemic
which everybody knows about!
After 2 years where the event went online, then 2 years without LGM at
all, it is finally back, this time in France, Rennes, from Thursday, May
9 (French holiday) to Saturday, May 11, 2024!
Logo of Libre Graphics Meeting 2024
As every year, the GIMP team will be present. Three talks are presented
by members of the team, one of them being prolonged through a
standards-making workshop:
Friday, May 10 at 2:30PM: OpenType and the
desktop
by Liam Quin, one of our long term contributors:
Proposing a cross-desktop font service (DBUS-based?) to support user
interfaces for people to instantiate variable fonts, to edit colour
font palettes, choose alternate glyphs, install/uninstall fonts, and
that can return paths, or glyph lists, or font names, or rendered
text, to any application.
Friday, May 10 from 4PM: workshop part of OpenType and the
desktop
talk by Liam Quin: hoping that the presentation will move on to a
discussion so that Free Software projects can work together to propose
a standard for font listing, selection, usage and more.
GIMP team will present the long-awaited new major version, GIMP
3.
On the menu : non-destructive editing, multi-layer selection,
color management improvements, brand new plug-in API, port to GTK3
(HiPPI, Wayland support, CSS themes, better tablet support, etc.)
and more.
We will also expose our plans for the future.
Jehan (GIMP maintainer) and Aryeom (artist in residence,
illustrator, designer…) will present their short animation film,
ZeMarmot, produced by the
non-profit film production LILA (Libre comme l’Art / Free as
Art).
The movie in its current state (color and background unfinished)
will be screened with live music by 3 musicians (ORL, Pelin, Adrien)
from our friend music collective, AMMD, which
work with us on this movie and only produces Libre Music.
The showing will take about 10 minutes, followed by a talk and
questions with Aryeom (film director), ORL (film score composer, and
musician) and Jehan (technical, development, organization, backend…).
Libre Graphics Meeting: from May 9 to 11, 2024, doors opening at 9AM, then all day long!
Main GIMP talk: Saturday, May 11, 2024 from 2PM to 3PM (by the GIMP team)
OpenType talk: Friday, May 10, 2024 from 2:30PM to 3:30PM (by Liam Quin)
OpenType workshop: Friday, May 10, 2024 from 4PM to 6PM (by Liam Quin)
ZeMarmot musical showing and talk: Saturday, May 11, 2024 from 3PM to 4PM (by Aryeom, film director, ORL, composer, Jehan, developer, and Pelin and Adrien, musicians)
Don’t forget you can donate and personally fund GIMP
developers, as a way to give back and
accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
This (possibly last) GIMP 2 stable release brings much-requested backports
from GTK3, including improved support for tablets on Windows. A number of
bug fixes and minor improvements are also included in this release.
This news lists the most notable and visible changes. In particular, we
do not list every single bug fix or smaller improvement.
To get a more complete list of changes, you should refer to the
NEWS
file or look at the commit
history.
Before this release, GIMP only supported connecting tablets on Windows through WinTab drivers
rather than the newer Windows Ink drivers. Because of this, we received a number of reports
about tablets having issues with unresponsive buttons, incorrect pressure sensitivity,
lagging brush movement, and mid-stroke position changes.
These problems were due to a limitation of GTK2, as
support for Windows Ink
was implemented in GTK3 by long-time contributor Luca Bacci. For this release, Luca was
gracious enough to backport this support to GTK2. You can now switch between WinTab and
Windows Ink drivers (if supported by your computer) in the Preferences dialog under the
Input Device settings.
Windows Pointer Input API can now be changed - GIMP 2.10.38
Luca also contributed a number of other features
from GTK3 to GTK2. Some of the backported improvements include updating the size of the Print Dialog so buttons
are not cut off, fixing issues with pop-up dialogs appearing behind the previous ones, and several fixes to
keyboard input.
These improvements are primarily for Windows and are already included in the 2.99 development release.
However, we are very happy that these quality of life improvements are now available in this stable release
of GIMP 2.10!
Two commonly reported crashes have now been corrected.
A change in GLib 2.80 exposed a bug in our closing process and caused a
crash on exit. Luca Bacci once again devised a fix for both 2.10.38 and
the upcoming 3.0 release candidate. Another crash that some users
encountered when making very small selections was also fixed.
25 people contributed changes or fixes to GIMP 2.10.36 codebase (order is
determined by number of commits):
7 developers: Alx Sa, Jehan, Luca Bacci, Jacob Boerema, Lukas Oberhuber,
lillolollo, Øyvind Kolås
19 translators: Kolbjørn Stuestøl, Sabri Ünal, Bruce Cowan, Yuri Chornoivan,
Vasil Pupkin, Anders Jonsson, Rodrigo Lledó, Jürgen Benvenuti, Sveinn í Felli,
Andi Chandler, Juliano de Souza Camargo, Ekaterine Papava, Balázs Úr, Martin,
Philipp Kiemle, Alan Mortensen, Dimitris Spingos, Marco Ciampa, Yacine Bouklif
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
The gimp-2-10 branch of gimp-macos-build (macOS build scripts) had 30
commits since the 2.10.36 release by 2 contributors: Lukas Oberhuber, Bruno Lopes.
The flatpak release is made of 11 commits by 3 contributors: Jehan,
Hubert Figuière and Bruno Lopes.
Our main website (what you are reading right now) had 42 commits since
2.99.18 release by 4 contributors: Jehan, Alx Sa, Andre Klapper and
Lukas Oberhuber.
Our developer website had 34 commits since
2.99.18 release by 6 contributors: Bruno Lopes, Jehan, Alx Sa,
bootchk, Alpesh Jamgade and Robin Swift.
Our 2.10 documentation had 35 commits since
2.10.36 release by 8 contributors: Alan Mortensen, Anders Jonsson,
Rodrigo Lledó, Jacob Boerema, Kolbjørn Stuestøl, Marco Ciampa, Andi
Chandler and Víttor Paulo Vieira da Costa.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
Idriss, 2023 GSoC contributor, has been recently granted “developer” access on
the main source repository, for the awesome continued job since then.
Ville Pätsi, very long term contributor (more than 20 years!), on various
topics (design, theming and more) got the “reporter” access to Gitlab to help
with triaging and organizing directly in the tracker.
Since our last
news, 3 new
mirrors have been
contributed to GIMP by:
Clarkson Open Source Institute, USA
FCIX, Switzerland
Tomás Leite de Castro, Portugal
This brings us to a total of 49 mirrors all over the world.
Mirrors are important as they help the project by sharing the load for dozens of
thousands of daily downloads. Moreover by having mirrors spread across the
globe, we ensure that everyone can have fast download access to GIMP.
CircleCI and MacStadium make our macOS continuous integration platform possible.
Arm Ltd. sponsors and administers several Aarch64 runners on
Windows for our ARM 64-bit build for Windows; and Microsoft had
given away the one-time fee for their Microsoft Store.
“Hardware Sponsors”
lists sponsors which donated some hardware to contributors to help
with development:
Arm Ltd. recently donated a Windows Dev Kit 2023 to support our
recent Aarch64/Windows support.
Clearly one of the smallest releases ever in the 2.10 series, and it might be our
last. We’ll see, though we also know some people get stuck longer than others on
older series (especially when using LTS
distributions of Free Software operating systems), so we might do (if we feel
like it’s needed) a 2.10.40 release with bug fixes only just before or just after
GIMP 3.0.0 release, as a wrap up.
In any case, we are now stopping backporting features in the 2.10 series. These
graphics tablet support improvements for Windows are huge enough that they had
to get in; yet from now on, we want to focus solely on releasing GIMP 3.0.0.
Now you might wonder when that is? Very soon! We are on the last sprint towards
the release candidate. This includes a lot of bug fixes, but also still some API
changes going on. We will keep you updated!
Don’t forget you can donate and personally fund GIMP
developers, as a way to give back and
accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
At long last, we bring you the final development version before GIMP 3! While the release of 2.99.18 is a bit behind our intended schedule, there are a number of new features and improvements that we’re very excited to share with you.
⚠️ ☢️
We remind that a development version means that this is a release to show
work-in-progress but also give an opportunity to the community to detect issues
early and report issues. In other word, this is an unstable version and we
do not recommend to use it in production. Use it because you want to help GIMP
improve by reporting bugs.
This version 2.99.18 in particular might be one of the most unstable releases in
the 2.99 series because of the space invasion. It is expected and normal.
⚠️ ☢️
This news post lists the most notable and visible changes. We do not list minor bug fixes or smaller improvements here. To get a more complete list of changes, you should refer to the NEWS file or look at the commit history.
We have been working very hard on the Space Invasion project, which is — as you might
recall —
our codename for the project of making GIMP more correct regarding colors.
Lately we have been porting older internal color structures (GimpRGB,
GimpCMYK, GimpHSV…) which we used to carry color information to
GeglColor. This
generic object can contain any color data regardless of color model, precision
or space supported by babl, our pixel encoding engine.
What it means for color correctness in particular is that we will now do color
conversion only when needed (last-second conversion) and therefore won’t lose
information when it could have been avoided. For instance, say you color-pick
color from an image: if we were to convert to an intermediate format, before
using it on a second image (which may or may not be in another color format),
we’d do 2 conversions. Which means more possibility of precision loss. The issue
is even more flagrant if the input and output formats are the same (i.e. no
conversion should happen at all). And this will be even more a problem when we
will have core CMYK backend (we really want to avoid doing a round-trip to an
intermediate format with CMYK, which doesn’t have bijective conversion with most
other color models, even when working unbounded and ignoring precision issues).
We are also slowly moving stored data to this generic color object. In
particular it means that color palettes will be able to contain CMYK colors,
CIELAB colors or in any other supported model (and not only these colors after a
conversion to unbounded sRGB).
A consequence for code maintainance is that it makes it a lot easier to handle
color conversions within our codebase, now that the structure embeds both the
data and its “meaning”. It makes color handling a lot less bug-prone compared to
when we had to keep track of both information as separate data.
Lastly we are working toward showing color space information in various parts of
the interface, when relevant, such as when displaying or choosing RGB, CMYK, HSL
or HSV data.
Values in these color models without the associated color space are
near-meaningless. Interface displaying values in RGB without further
information are a remnant of the past when it mostly meant sRGB. This is
clearly not true anymore in modern graphic work and the interface should make
this clear.
The below video shows some of this interface work where RGB, HSV or CMYK models
for instance are always displaying the color space the values are in (which very
often means the name of the ICC profile). This is being done in the color picker
tool, color samples, FG/BG Color dockable, “Change Foreground/Background Color”
dialog and in more places.
Not only this, but when people select a soft-proofing profile and activate
soft-proofing (e.g. through the nice new simulation toggle which was added in GIMP
2.99.12),
we will also show out-of-gamut area not only within the image’s color space, but
also the soft-proof space.
(Color) Space Invasion in the interface - GIMP 2.99.18
Very important warning: this is once again a huge port in our codebase,
which impacted litterally thousands of lines of code. This work is unfinished
though it will have to be finished before the first release candidate. Therefore
unstabilities or bugs are to be expected in this update so if you encounter any
issue, we recommend to report
them.
Achromatic pixels in the Hue-Saturation tool are now special-cased so that
grayscale pixels (saturation of 0) are only changed by the master adjustment,
not by the red adjustment.
Grayscale gradients are now kept achromatic even with “Dithering” checked in
the Gradient tool.
As the space invasion project goes on, getting things
consistent is getting easier in various color-related algorithms, hence enabling
us to discover issues quickly and fix them.
One area we’re “ahead of schedule” on are the much-requested non-destructive
layer effects! The foundation for these features has been laid by many
developers over many years, since the introduction of GEGL into GIMP. Originally
planned for the 3.2 roadmap, an initial implementation was made as a
continuation of a Google Summer of Code project.
If you are not familiar with the term, “non-destructive editing” implies the
ability of changing the output pixels while keeping the source pixels intact.
For filter effects, such as Blur, it means that layer effects are kept separate
from the layer’s pixels. This means that if later on you want to change a
setting, rearrange, or even remove the filter, you can easily do so without
affecting the rest of the image. Until now, GIMP has followed a destructive
editing workflow where effects were immediately merged down onto the layer, so
this is a major change!
Any GEGL operation that has a GUI is now applied to layers non-destructively (Non-destructive effects for layer masks and channels are planned for future updates.). This includes third-party GEGL plug-ins and custom operations created with our GEGL Graph tool. These effects can be saved and loaded in .xcf project files, although not all GEGL properties are supported in the current build.
Once a filter has been applied, you can interact with it further by clicking the filter icon in the layers dockable. This will open a pop-up that shows all filters currently applied to the layer. From here, you can toggle the filter’s visibility, edit the filter settings, re-order the filters, and delete individual effects. You can also merge down all filters to recreate a destructive workflow.
Non-destructive layer effects - GIMP 2.99.18
Note that this is only an early implementation, and much work remains to be done for a full-featured version of non-destructive editing. We will continue to refine the existing features for the 3.0 release based on user testing and feedback, and extend them further afterwards.
The interface itself is not how we envision this feature ideally and a first
specification draft was layed out
for a much more integrated workflow.
The below screenshot is a mockup from this first specification which would show
layer effects within the main layer list, sharing the same “eye” and “lock”
buttons, but also with their own easily editable mask:
Specification mockup image: vision of layer effects directly in the layer list with their own mask
Nevertheless creating this new interface will be its own challenge so we decided
to delay it to after GIMP 3 release and to propose this early implementation at first.
Idriss Fekir, another GSoC 2023 student, has been working with long-time developer Liam Quinn to improve how GIMP handles fonts. A lot of this work was internal to improve GIMP’s ability to handle future font and text updates. Some of the more visible changes include:
GIMP no longer relies on font names being unique to distinguish between them. This means it won’t append “#1”, “#2” and so on but instead keep the original names in the font selection list. Despite the apparent name clash, both identically named font will now work properly.
GIMP can now load fonts using custom styles (bypassing Pango which is unable
to load them).
We can now load more types of fonts than before. In cases where we don’t support a font yet (or the font is non-existent), we can better detect this and fall back to a default font. This also improves support when loading an .xcf file created on another computer to different fonts available.
On Windows, we force the Pango backend to always use anti-aliasing. This improves the readability of menu text on that operating system, especially with a dark theme.
The XCF-saving code now stores font information much more accurately which
helps to avoid loading the wrong font when reopening some XCF.
Alignment of text in text layers for RTL languages is now more consistent with
how it works in other software (such as LibreOffice or Scribus).
These changes are a lot less flashy relatively to some of the other features and
therefore may feel less important, yet they are actually the foundation work on
making text handling a lot more reliable in GIMP. We are envisionning a future
where text editing will be simpler while much more powerful and featureful (in
particular OpenType features are some of the big improvements we hope to get eventually).
The third GSoC project last summer by student Shubham Daule brought a long requested feature – auto-expanding layers! Brush tools now have an additional “Expand Layers” option. When checked, painting past the layer boundaries will cause them to automatically expand so you don’t have to manage the layer size yourself. If you want to expand the layer beyond the current size of the canvas, you’ll need to also check the “Show All” option in the View menu.
Auto-expanding layers - GIMP 2.99.18
The Expand Layers option also has additional settings when selected. You can decide how much you want the layer boundaries to expand by whenever the brush reaches them. There are also options to specify how the new areas of the layer and layer mask should be filled in when expanded.
New contributor mr. fantastic developed two new options for aligning layers on the canvas. With “Snap to Bounding Boxes” enabled, dynamic guides will now show when the layer you are moving is aligned with the center or sides of others. The active layer will also snap to those boundaries to assist you with arranging them properly. The second option, “Snap to Equidistance”, allows you to snap between three layers that are equidistant from each other.
We continued to improve the user interface and style for this release. One of the biggest improvements was dealing with “system theme leaks”. There are styles that were not specifically defined in our themes, thus allowing different systems to supply their own (often conflicting) styles. With the help and feedback of several contributors and users, we’ve made a lot of progress in defining those styles so that everyone has a consistent experience!
Recently Jehan worked on re-organizing and simplifying our theme system. In past development versions we had five different themes: Default, Gray, System, Darker, and Compact (Each with light and dark options). These have been simplified into the System theme and a single Default theme with three possible states – light, dark, and gray. Similarly, our four separate icon themes were condensed into the Legacy set and a Default with Color and Symbolic options. We think these changes will reduce user confusion and make it easier for them to find their preferred interface appearance.
In addition, on Windows the main titlebar (and most dialog title bars) now adjust to light or dark mode depending on the selected theme.
The Welcome Dialog has been expanded to provide quick access to a number of useful features and options. There are now four new sections:
Personalize: There are several customization options that require you to dig through the Preference Dialog to change. Now from this page you can easily change the color and icon themes, the user interface language and font size, and OS-specific settings.
Create: This page shows your eight most recently opened images and allows you to quickly reopen them. There are also buttons to create a new image or load an existing one. As with other programs, you can set this screen to automatically appear when GIMP starts for immediate access to these features.
Contribute: We consolidated some of the many ways you can be involved in GIMP’s development on this page. There are direct links to report bugs, write code, assist with translation or donate financially.
Release Notes: Originally these were shown on the lower half of the Welcome page. Now we have a full tab dedicated to them for easier reading.
A new contributor Stayd has been working with developer Jacob Boerema to make many improvements to the DDS plug-in. As a start, the import functions have been written to be simpler and easier to extend in the future. Some of the other additional updates include:
Loading 16 and 32 bits per channel RGBADDS images is now possible.
The Catmull-Rom cubic filter has been added for mipmap generation, and all mipmap generation calculations are performed at 32-bit precision.
DDS images in the R8G8, R16, and R16G16 formats can now be loaded as well.
An option to flip DDS images vertical on import was added to mirror the existing export option, as some game images store their data this way.
In the past, overwriting a GIF rather than exporting would always convert it into a single frame image. Now we check to see if the GIF is an animation on load, so it will stay that way when overwritten.
Both plug-ins now use their respective libraries (libheif and libjxl) to load metadata. As a result, we have removed our custom code to interpret the image orientation and rely on the information supplied from the library instead.
OpenEXR allows for channels to have custom names besides the color type. In these cases we now treat any single channel image with an unconventional name as grayscale. On import, we also display a notification so that users are aware of the conversion.
The “Layers as Pages” export option now works even if there is only a single layer group. Previously this option was not available, as the plug-in only checked if there was more than one “layer” without considering if it was a layer group with multiple sub-layers.
Safe-to-copy PNG chunks are now preserved on import and included in the exported image. Additionally, an often-reported issue with exporting transparent indexed PNGs has been fixed. Now the exported indexed colors should be displayed correctly.
Jacob Boerema continued his work to improve the PSD plug-in. In addition to bug fixes such as correcting the layer order on import, he also clarified the export warning on layer mode compatibility between GIMP and Photoshop.
The Paintshop Pro plug-in now supports importing more features from the project file, such as the ICC color profile, guides, grids, and the active selection from when the file was saved. The ZDI-CAN-22096 and ZDI-CAN-22097 security vulnerabilities were also patched in this release.
New image format supports: Farbfeld, Esm Software PIX, HEJ2¶
We recently added import and export support for Farbfeld, an sRGB image format intended to be easy to parse, pipe, and compress externally.
We also added import only support for the following new file formats:
Esm Software PIX: A modified JPEG format used exclusively by the Esm Software company to store their customized images. This was implemented in response to a bug report that confused this format with our existing Alias PIX image support.
HEJ2: An addition to our existing HEIF plug-in by contributor Daniel Novomeský which allows importing JPEG 2000 compressed images.
Swatchbooker is a free/libre open source software that creates and converts color palettes in a variety of formats. While the software itself has not been updated in many years, its custom palette format .sbz is the most comprehensive of all the ones we currently support. Among its many features are allowing multiple color model definitions per palette entry, localizable names and descriptions, and support for per-entry ICC color profiles.
While working on our import support, we were able to contribute information that led to a bug fix in Krita’s support for Swatchbooker. It’s always great when projects can work together and help each other!
Long-time GNOME contributor Carlos Garnacho added support for interacting with GIMP via tablet pads. When a tablet is plugged in, you can now assign different actions to the tablet controls via the “Input Device” dialog under the Edit menu. In particular you don’t have to map keyboard shortcuts to the tablet’s buttons, system-side, then map the same shortcut to actions, GIMP-side. You can directly map the tablet’s buttons to actions without the intermediary of keyboard shortcuts.
Assigning actions to tablet pad buttons - GIMP 2.99.18
This work also involved porting features to GTK 3, the GUI framework that GIMP is built on. Note that this feature is currently only supported on Wayland.
The Application Programming Interface, for plug-in makers, is steadily being
reworked as part of the GIMP 3 overhaul. Part of it is that when colors are
involved, we are moving the API to use GeglColor as part of the more general
Space Invasion project. Yet it’s only a small part of
the whole API improvements.
We are also moving towards more classes to represent the various resources
managed by GIMP (brushes, fonts, patterns, etc.) instead of only representing
these by names (which was a historical limitation whereas it is absolutely
possible for 2 resource makers to choose the same name and the fact is that we
see such cases in the wild — for instance 2 fonts independently created may have
the same name).
Another big move is replacing the GimpValueArray representing the ordered
arguments of a plug-in procedure by a GimpProcedureConfig which contains
arguments by name instead of by order. This allows much more semantic usage of
plug-in procedures (especially when they have long list of arguments) but also
will make it easier to enhance plug-ins in the future, with new or reordered
arguments without creating new procedures because the order and number arguments
matter a lot less. It means that adding new arguments in the future won’t break
existing scripts depending on past versions of these plug-ins anymore (plug-in
writers will still have to choose appropriate defaults for the new arguments in
order for this to be true, of course).
In parallel, we continue to improve the ability of automatic GUI creation given
to plug-ins, making creating dialogs more easy than ever. This includes (among
many other enhancements) a new type of procedure argument named GimpChoice
which is a string list of choices which can be displayed to creators as
drop-down list widgets in your plug-in dialog.
We are planning to write and release tutorial for plug-in writers in the
Resource Development section of our
developer website in the same time as GIMP 3
release, or not long after.
This release of GIMP is accompanied by new releases of GEGL and babl, both of which assist with the color space invasion project.
babl 0.1.108 brings a new babl_space_is_rgb function to help us directly confirm a color space is RGB (rather than doing multiple tests to see if it’s not CMYK or grayscale). There were also several improvements to the build process and to the babl command-line interface tool.
GEGL 0.4.48 provides several updates to the GeglColor object which now supports much of GIMP’s color operation. Specific improvements include being able to directly get and set CMYK color values, as well as assigning the color space when setting RGB(A) colors.
A crash in the existing gegl:voroni filter was fixed, and a long-standing bug with the gegl:dropshadow filter which prevented the effect from shrinking was corrected too.
Last but not least, a new gegl:shuffle-search filter was added to the workshop. It shuffles neighboring pixels to create a more optimized dithering effect.
60 people contributed changes or fixes to GIMP 2.99.18 codebase (order is
determined by number of commits; some people are in several groups):
23 developers to core code: Jehan, Alx Sa, Shubham, Jacob Boerema, Idriss
Fekir, bootchk, Anders Jonsson, Carlos Garnacho, mr.fantastic, Stanislav
Grinkov, lillolollo, Øyvind Kolås, Sabri Ünal, programmer_ceds, Lukas
Oberhuber, programmer-ceds, James Golden, Luca Bacci, Massimo Valentini, Niels
De Graef, Zander Brown, psykose, sonia.
17 developers to plug-ins or modules: Jehan, Alx Sa, Jacob Boerema, bootchk,
Anders Jonsson, Stayd, Zander Brown, Bruno Lopes, Daniel Novomeský, Sabri
Ünal, programmer_ceds, Kamil Burda, Mark, Michael Schumacher, Stanislav
Grinkov, programmer-ceds, sonia.
31 translators: Yuri Chornoivan, Martin, Ekaterine Papava, Luming Zh, Sabri
Ünal, Anders Jonsson, Rodrigo Lledó, Jordi Mas, Alan Mortensen, Vasil Pupkin,
Asier Sarasua Garmendia, Kolbjørn Stuestøl, Boyuan Yang, Víttor Paulo Vieira
da Costa, dimspingos, Alexander Shopov, Alexandre Prokoudine, Aurimas Černius,
Balázs Úr, Marco Ciampa, Sveinn í Felli, Danial Behzadi, Ngọc Quân Trần,
Jürgen Benvenuti, Piotr Drąg, Timo Jyrinki, Andre Klapper, Kristjan SCHMIDT,
MohammadSaleh Kamyab, Rafael Fontenelle, Tim Sabsch.
9 resource creators (icons, themes, cursors, splash screen, metadata…): Alx
Sa, Jehan, Ferry Jérémie, Stanislav Grinkov, Anders Jonsson, Bruno Lopes,
Jacob Boerema, Sabri Ünal, mr.fantastic.
5 documentation contributors: Jehan, Bruno Lopes, Jacob Boerema, Alx Sa,
Anders Jonsson.
14 build, packaging or CI contributors: Jehan, Bruno Lopes, bootchk, Alx Sa,
Zander Brown, Jacob Boerema, Jacob Boerema, Stayd, Carlos Garnacho, Heiko
Becker, mr.fantastic, Daniel Novomeský, U-YGGDRASIL\ender, lillolollo.
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
babl 0.1.108 is made of 17 commits by 6 contributors: Jehan, Øyvind Kolås,
John Marshall, Andre Klapper, John, sid.
GEGL 0.4.48 is made of 77 commits by 20 contributors: Øyvind Kolås, Jehan,
Anders Jonsson, Jacob Boerema, Yuri Chornoivan, Alan Mortensen, Sabri Ünal,
Andre Klapper, Ekaterine Papava, Jan Tojnar, Jordi Mas, Luming Zh, Martin,
Piotr Drąg, Víttor Paulo Vieira da Costa, Asier Sarasua Garmendia, Marco
Ciampa, Rodrigo Lledó, dimspingos, woob.
ctx had 308 commits since 2.99.14 release by 1
contributor: Øyvind Kolås.
The gimp-macos-build (macOS packaging scripts) release is made of 32 commits
by 1 contributor: Lukas Oberhuber.
The flatpak release is made of 15 commits by 3 contributors: Jehan, Daniel
Novomeský and Hubert Figuière.
Our main website (what you are reading right now) had 31 commits since
2.10.36 release by 6 contributors: Jehan, Alx Sa, Sabri Ünal, Anders Jonsson,
Bruno Lopes, Jonathan Demeyer.
Our developer website had 30 commits since
2.10.36 release by 5 contributors: Bruno Lopes, Jehan, Alx Sa, bootchk, Robin Swift.
Our 3.0 documentation had 247 commits since
2.99.16 release by 17 contributors: Andre Klapper, Jacob Boerema, Yuri
Chornoivan, Alx Sa, Jordi Mas, Alan Mortensen, dimspingos, Anders Jonsson,
Boyuan Yang, Sabri Ünal, Víttor Paulo Vieira da Costa, Juliano de Souza
Camargo, Rodrigo Lledó, Kolbjørn Stuestøl, Marco Ciampa, Danial Behzadi, Emin
Tufan Çetin.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
Access rights to the git repository were recently given to Bruno Lopes (who has been very active improving our build process and Windows packaging).
Several long term or recent developers or packagers who started to contribute to
the new developer website were also given access to the associated git
repository.
More contributors are now actively participating to testing releases and
packaging, and this is the first news for years which Jehan has not written
nearly entirely! Thanks a lot to Alx Sa (a.k.a. Nikc or CmykStudent) for taking
up on collaborative news writing!
Clearly we are consolidating day after day a solid core team of contributors and
this shows in our release process having more and more feedback at each release.
We are also particularly happy and proud that the 4 GSoC projects we had, since
we started again subscribing to this mentoring program, were all successful and
ended up being merged to the main code branch within half a year at most after
the internship end.
Since our last
news, a new
mirror has been
contributed to GIMP by:
Sahil Dhiman, in Nürnberg, Germany, as a personal project.
This brings us to a total of 46 mirrors all over the world.
Mirrors are important as they help the project by sharing the load for dozens of
thousands of daily downloads. Moreover by having mirrors spread across the
globe, we ensure that everyone can have fast download access to GIMP.
Since our news for an experimental build on Windows for ARM 64-bit
architecture,
we received help from Hernan Martinez, well known contributor in the MSYS2
project, who hosted our first ever CI runner for Windows on Aarch64
architecture. Though this was only a temporary setup (literally a build machine
in someone’s living room) until we get a more stable situation, we are extremely
thankful to Hernan who helped us make our second step on this platform (the
first step was done by Jernej, who made our first experimental installer), make
sure our automatic build process worked there and more.
Since then, we got the stabler situation: Arm Ltd. themselves stepped up and
contributed officially 3 runners for our Continuous Integration process in
Gitlab! Arm Ltd. also sponsored a Windows devkit to one of our developers.
While we still do consider this build experimental, because of lack of testing
and because only 2 contributors have a machine able to run it right now, the
biggest blocker got removed and we are happy to announce that our universal
Windows installer for GIMP 2.99.18 contains GIMP for all 3 platforms (x86 32 and
64-bit, and now ARM 64-bit)!
As we have now entered a feature freeze, our focus has shifted to bug-fixing, clean-up, and preparing for the first 3.0 release candidate.
We indeed think that this should be the last development release since no new
feature will be introduced from now on, at least GUI features (the API is still
evolving until the first release candidate). So what you see now is basically
what you should get in GIMP 3.0.0, feature-wise.
This is why we released this version even though we know it is quite unstable.
Now is the time for last minute comments! Also it’s the moment to report and fix
bugs like there is no tomorrow. We hope to be able to deliver a RC1 soon and it should be as bugless as possible.
Our current expectation is to be able to release GIMP for the upcoming Libre
Graphics Meeting in May 9-12. To be
fair, this is not an easy goal and therefore we are not sure if we can make it.
What is sure is that even if we did not manage this on time, it should not
happen too long after.
In particular we won’t release just because we set a deadline. We want to
provide the best experience, which means that if we discover last minute blocker
bugs, we will delay the release until they are fixed.
Don’t forget you can donate and personally fund GIMP
developers, as a way to give back and
accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
This stable release of GIMP comes with a few security fixes, so we advise you to
update even if you feel like your current version works fine for you. Apart from
the many bug fixes and security updates, it also provides new support for
palette formats and a new generated gradient.
This news lists the most notable and visible changes. In particular, we
do not list here bug fixes or smaller improvements.
To get a more complete list of changes, you should refer to the
NEWS
file or look at the commit
history.
Everywhere a gradient option is available, the gradient list will now feature
the additional “FG to Transparent (Hardedge)” option. It generates a gradient
from the foreground color to transparency, with hard-edge transitions between
the 2 colors.
In the Gradient Tool in particular, you can generate patterns very quickly with
the “Repeat” option, alternating repetitive colored shapes with full transparency
over a given background.
New FG to Transparent (Hardedge) gradient - GIMP 2.10.36
GIMP now loads GIF images containing the PixelAspectRatio header metadata by
setting different resolutions per dimension, hence rendering the image correctly
(instead of looking squashed on the screen).
Of course the option “Dot for Dot” in the View menu must be unchecked to see
the image at its expected ratio.
Four vulnerabilities were reported by the Zero Day Initiative in code for the
following formats and fixed immediately:
DDS: ZDI-CAN-22093
PSD: ZDI-CAN-22094
PSP: ZDI-CAN-22096 and ZDI-CAN-22097
Additionally dependencies have been updated in our binary packages, and with
them, some vulnerabilities recently reported in these libraries were fixed.
In any case, we recommend to update GIMP with the latest packages.
Broken Graphics Tablets with recent linuxwacom driver¶
We don’t usually mention bug fixes prominently but an ugly one happened
recently after a change in the xf86-input-wacom (linuxwacom) driver, which
provoked crashes of GIMP when using a graphic tablet on Linux.
Various distributions already downgraded the driver, or backported the fix,
since a patch to the driver has been quickly pushed as well. Nevertheless if you
are in the unlucky situation of using the non-patched driver, this version of
GIMP also contains a workaround to the bug.
29 people contributed changes or fixes to GIMP 2.10.36 codebase (order is
determined by number of commits):
7 developers: Alx Sa, Jehan, Stanislav Grinkov, Jacob Boerema, Daniel
Novomeský, Andras Timar and Gabriel Scherer.
22 translators: Marco Ciampa, Sabri Ünal, Luming Zh, Anders Jonsson, Yuri
Chornoivan, Martin, Rodrigo Lledó, Balázs Úr, Hugo Carvalho, Jürgen Benvenuti,
Nathan Follens, Piotr Drąg, Alan Mortensen, Cristian Secară, Ekaterine Papava,
Jordi Mas, Vasil Pupkin, Aurimas Černius, Danial Behzadi, Petr Kovář, Sveinn í
Felli and dimspingos.
3 resource creators (icons, themes, cursors, splash screen, metadata…):
Stanislav Grinkov, Jehan, Daniel Novomeský.
One documentation contributor: Jehan.
3 build or CI contributors: Jernej Simončič, Jehan and Stanislav Grinkov.
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
babl, GEGL and ctx are actively developed, but no releases have accompanied
this version of GIMP for once. So we will provide relevant statistics at next release.
The gimp-2-10 branch of gimp-macos-build (macOS build scripts) had 45
commits since 2.10.34 release by 1 contributor: Lukas Oberhuber.
The stable flatpak branch had 28 commits since 2.10.34, by 3 contributors (and
a bot): Jehan, Daniel Novomeský and Hubert Figuière.
Our main website (what you are reading right now) had 165 commits since
2.99.16 release by 6 contributors: Sabri Ünal, Jehan, Bruno Lopes, lillolollo,
Alx Sa and Robin Swift.
Our developer website had 17 commits since
2.99.16 release by 5 contributors: Jehan, Bruno Lopes, Aryeom, Jacob Boerema
and Robin Swift.
Our 2.10 documentation had 138 commits since 2.10.34
release by 16 contributors: Andre Klapper, Jacob Boerema, Marco Ciampa, Anders
Jonsson, Boyuan Yang, dimspingos, Yuri Chornoivan, Jordi Mas, Rodrigo Lledó,
Martin, Alexander Shopov, Alx Sa, Balázs Úr, Piotr Drąg, Sabri Ünal and Tim Sabsch.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
Access rights to the git repository were recently given to Lukas Oberhuber
(our maintainer for the macOS packages).
During the duration of
GSoC, “reporter”
rights on our Gitlab project were given to Idriss and Shubham, 2 of the GSoC
contributors (the third one already had git access).
Robin Swift, who already helped with GIMP’s developer
website
has started working on a port of the main website (which you are reading right
now) from Pelican to Hugo, a project which was long planned yet had stalled so far.
Finally we remind that we are actively looking for people helping us
test
packages before releases (especially for GIMP 3.0 and forward). This will help
make GIMP releases much more robust. Since the last release, Anders Jonsson and
Mark Sweeney were added as Flatpak testers. We also have several testers of the
Windows packages, yet we still have no testers for macOS.
Whatever your OS and the architecture you test on, we welcome your feedback to
detect issues early! Together, the community is stronger! 💪
Since our latest news, 4 new
mirrors were
contributed to GIMP by:
Silicon Hill, student club of the Czech Technical University in Prague,
Czech Republic;
Lancaster-Lebanon IU13, an organization comprised of more than 20 public
school districts and several non-public, parochial, and charter schools in
Lancaster, Pennsylvania, USA;
the Moroccan Academic and Research Wide Area Network (MARWAN) in Rabat, Morocco;
Jing Luo, in Tokyo, Japan.
This brings us to a total of 45 mirrors so far, from all over the world.
Mirrors are important as they help the project by sharing the load for dozens of
thousands of daily downloads. Moreover by having mirrors spread across the
globe, we ensure that everyone can have fast download access to GIMP.
Sabri Ünal continued their 📚 bibliographic research, adding so many published
books that we decided to completely reorganize the books as a structured file
database, allowing us to easily process the information or change the page
styling separately from the data.
This also triggered us to split the books page into 2:
As book descriptions don’t always clearly state the version of GIMP they pertain
to, we used the release date of GIMP 2.10.0 (April 27, 2018) as the split date.
Last but not least, this new structure allows us to easily generate statistics,
which we now show at the bottom of the books pages. At least 44 books were
published after GIMP 2.10.0 release, and 305 were published before it.
Therefore we are currently listing a grand total of 349 books about GIMP in 17 languages!
I believe it might be the next to last release in the 2.10 branch, though of
course, this is still to be confirmed. What may happen in real life does not
always align with plans.
In the meantime, we are working harder than ever to release GIMP 3.0. You will
hear shortly about this in our next development release.
Don’t forget you can donate and personally fund GIMP
developers, as a way to give back and
accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
As architecture platform usage widens, Windows on ARM (64-bit) is now a thing.
So we decided to support experimentally GIMP for Windows on ARM!
With the newly published revision 2, our universal installer of GIMP 2.10.34 for
Windows (as found on our downloads page)
will auto-detect the running platform and install the ARM build when relevant.
Thanks in particular to our Windows packager, Jernej Simončič, for his
continuous work!
The “experimental” qualificative for this new support is for the following reasons:
It is not as widely tested. We are aware of some issues already and hope that
releasing this experimental build will help us get more feedback.
Only Jernej has a machine with Windows on ARM so far. In particular none of
the developers have such hardware, as far as we know. So we don’t expect to
be able to fix issues for Windows/ARM as fast as for other supported platforms.
Last, but not least, this additional build is not set up yet in our
continuous integration platform, which means we cannot discover appearing
issues as thoroughly and quickly as for other architectures, nor can we
automatize builds as transparently as we wish.
Aside from reports and
patches, we really need
to set up a Windows/ARM machine in our continuous integration platform.
Indeed this is considered a blocker and may be cause for abandoning the
experimentation when we release GIMP 3 since we don’t want to backtrack and get
back to manual builds done by a single contributor on their personal machine for
the 3.0 series.
This means that we are looking for anyone willing to help us set up a machine
with Windows on ARM and configure it as a runner on our Gitlab
project.
Because of obvious security requirements, such a volunteer would need to have
sysadmin experience, willing to commit themselves in the long run (let’s not
leave a Windows machine with holes on the internet) and have had some experience
in FLOSS contributions.
It might also be interesting to coordinate with other cross-platform Free
Software projects to share the administration burden of a CI runner which we can
use together to build for Windows/ARM.
If you are interested, please get in touch on
IRC or in the dedicated
report.
Closer than ever to a release candidate for GIMP 3.0, we introduce the latest
development version: GIMP 2.99.16!
This news covers some of the more noteworthy or interesting parts of this update
and we are very happy to be able to showcase these.
New development splash screen, by Aryeom - GIMP 2.99.16
Note: the fun story behind this splash screen is
Aryeom molding a pizza dough
Wilber on the first evening
at Wilber Week. The oven-cooked dough stayed with
us during the whole stay. This
release was dubbed the “Wilber Week 2023 edition” as a homage to our very
successful contributor
meetup.
This news lists the most notable and visible changes. In particular, we
do not list here bug fixes or smaller improvements.
To get a more complete list of changes, you should refer to the
NEWS
file or look at the commit
history.
GIMP 3.0 has been known as the GTK+3 port version, so you will be happy to read
that this port is finally over. To be fair, we still have a few minor
deprecation warnings here and there, but nothing like the hundreds we used to have.
Our last big work was to port how “actions” are handled, which in GTK vocabulary
means shortcuts, their mechanism, but also how menus are handled and how generic
widgets can be quickly assigned shared action code. Starting from GTK+3, actions
moved to GLib (GtkAction became GAction) while losing a lot of features
(everything user-facing basically, i.e. labels, descriptions, icons, and so on)
or broken apart (the concept of shortcut itself stayed in GTK).
Therefore we had to reimplement the whole thing as a wrapper around GAction,
called obviously GimpAction, because for us, these user-facing features are
major parts of what makes an action (especially as we do a lot of GUI and code generation so things like
labels or icons are not to be associated to a widget — be it a button, a menu
item or anything else — but to the action assigned to this widget, for easy
and generic reuse).
We also had to wrap a bunch of other widgets, such as our own menus (mostly
because menus generated from menu models don’t have tooltips anymore in GTK+3,
yet we make extensive use of tooltips) and menu models (GimpMenu and
GimpMenuModel), our own toolbar and menu bar (GimpToolbar and GimpMenuBar)
and more.
It took me about 2 months to finish while also having to take care of other
code, maintenance and usual bug fixes. Boring and exhausting, but this is now
done! 😅
It also gives us a whole new world of possibilities as we added new concepts
which we wanted for a long time, such as the ability to associate a short and
long label to an action (e.g. when it’s used in a contextual interface such as a
menu vs. when it’s used without context, such as the action search). It is also
the path for planned future improvements (e.g. for a future customizable
toolbar).
We still have a bit more work to do to get our new menu and action code exactly
how we want it, but we are in a good enough state to showcase it. It won’t feel
very different to most of you (and you may also find issues), but not feeling
too different was the point too.
Now there are much more immediate improvements which are worth noting.
The new Glib/GTK+3 actions make it possible to assign several shortcuts for a
single action. For the time being, the shortcut dialog doesn’t allow you to do so,
yet we already use this ability internally for default shortcuts. For instance
number keypad keys are not the same as the ones from the number key row so we
used to create a duplicate action doing the same thing to support both (because
for most people Ctrl-1 should work the same whether from keypad or top row).
Now we can just assign both variants to a same action.
As another example, it is now possible to support the special semantic media key
(such as media key Copy, Cut and Paste which can be found on some keyboards).
An updated shortcut dialog allowing you to set your own multiple shortcuts might
not come for GIMP 3.0, though hopefully not too long after.
Now that we have our own action wrapper, we made so that it also tracks its own
menu position, so that we can show this menu path in the action search dialog.
This will help people who prefer menus to better find their ways.
Action search dialog now showing menu paths - GIMP 2.99.16
You may also notice a small “Manual” 📓 icon in this screenshot. Clicking it will
open the manual page for a given action (if no help section exists for this
specific action yet, you will be redirected to the action search help page).
Alternatively, hitting the F1 key will open the help page of the selected action.
GEGL is our image processing engine. Filters are
implemented as separate modules, which we call “operations”. While it is
released with a long list of default operations, third-party developers can
implement their own filters, hence benefitting from automatic dialog generation,
on-canvas live preview, curtain preview, preset saving, previous use settings
history and more.
GEGL has been a major component since GIMP 2.10, yet we still needed specific
code to place GEGL operations in menus.
As for third-party filters developers, they had to either implement a bogus
plug-in to wrap their GEGL operation, or settle for being only visible in the
long list of filters shown inside the GEGL operation tool.
Well this has changed as GEGL filters now have easy access to menus in their own
right, just like plug-ins do.
From now on, GIMP reads the GEGL key "gimp:menu-path" to add an operation in
menus. For instance, say that I wrote an artistic filter to stylize an image and
I want it to be under the submenu Filters > Artistic. So my operation code
could contain the following code:
gegl_operation_class_set_keys(operation_class,"name","Jehan:my-style","title",_("My Super Cool Style"),"description",_("Stylize an image the way I like it"),"gimp:menu-path","<Image>/Filters/Artistic",NULL);
And here it is:
Easily adding a third-party filter to menus - GIMP 2.99.16
GIMP will generate automatically the GUI according to the properties declared in
your operation.
Of course, you can also create your own menu folders. Say I create a bunch of
filters which we use specifically for our movie
project, I could create a submenu
"<Image>/Filters/ZeMarmot" (or even a top-level menu. You’ll notice the
“Girin” menu in my screenshot which is where we install our custom plug-ins already).
We will use this to simplify core GIMP code as well, even though for now, only
two new GEGL filters use this feature.
ℹ️ About GEGL operation namespaces: you may notice that I prefixed my
hypothetical filter name with “Jehan:”. This is a way to “namespace” your
filters with a unique name and avoid clashes if someone were to implement a
filter with the same name. Choose this namespace wisely, and in particular do
not use “gegl:” or “svg:” namespaces which are reserved for GEGL core operations
(and might even be forbidden some day to third-party operations).
The second big improvement is that your custom filters will now appear in the
action search (/ key by default), whether or not you added them to a menu. It
allows searching and running them very easily!
Third party filters are now searchable - GIMP 2.99.16
While the on-canvas editor of the text tool is very practical, it was sometimes
a bother as it is in your way. There are cases when you’d like to be able to see
the bare canvas while editing text.
It is now possible thanks to the new option “Show on-canvas editor” to toggle
its visibility.
In this version, we modified the option “Use extents of layer contents” so that
it applies to the alignment reference as well (not only the target objects).
A patch was submitted to make the Transform Matrix selectable in the tool’s
on-canvas dialog. This makes it easier to reuse the matrix in other software
(while first testing in GIMP for immediate preview of the transformation, then
copying and pasting the matrix).
Space Invasion is our project to ensure color correctness everywhere we show
or use colors, choose proper color defaults, propose relevant color options…
In this version, some work was done in internal code which was still assuming
sRGB input or output and was used in a few situations. It is now possible to
choose more easily out-of-sRGB foreground and background colors, and the Color
Picker tool shows color values from the proper image space.
Still in the Color Picker tool (and the Sample Points dockable), a new
“Grayscale (%)” display mode was added, which shows the pixel’s Grayscale
value if the picked image were converted to Grayscale mode.
There is still much more work-in-progress regarding these interfaces, such as
ensuring the colors are correctly displayed in the various color boxes (not only
on canvas), that we get reasonable behavior on shared color widgets when
switching from an image’s color space to another, and so on.
Also we plan to become more explicit on the color space currently in use on all
these shared interfaces where you can choose or show colors (Colors dockable,
Foreground/Background colors, Color Picker tool, Sample Points dockable…). This
is going to be one of the biggest parts of the next development release.
In the Preferences dialog, Image Windows settings, you will find a new
checkbox titled “Merge menu and title bar“. This is basically an option to
switch to Client Side Decoration for the image windows, which mostly means
that the menu will be merged inside the title bar, hence saving vertical space.
Preferences settings “Merge menu and title bar” - GIMP 2.99.16
Note: this option doesn’t work for macOS which always has its own
platform-specific menu style.
Since the header bar is set to be hidden when maximizing, if you checked “Show
menubar” for the “Default Appearance in Fullscreen Mode” in Preferences > Image
Windows > Appearance, the menu will be temporarily moved out of the title bar.
This makes the menu visible (if relevant option is checked, which is the
default) even in fullscreen mode.
Now we know that client-side decoration is quite a controversial feature. You
find people who love this with all their might as much as the opposite (in
particular because you lose window styling consistency since decorations are not
handled by the window manager anymore). Moreover we are being told that in some
specific cases, the system refuses to drop its own window decoration and you may
end up with 2 title bars (one drawn by the system and one by GIMP).
For these reasons, this option is disabled by default.
The dark variant of the Default theme has been reworked because it was a bit
too dark. The older version has been moved temporarily as a new theme titled
Darker, though we aren’t sure if we will keep it.
During our last in-person developer
meeting, where this
work happened, the concept of a “High Contrast” theme was also evoked.
At some point, we even discussed the possibility to implement settings for
color customization of the theme.
Now we are not sure which will happen for GIMP 3.0. It will really depend on
whether we get more theme contributions by the time we release.
The “Stroke/Fill Selection Outline” or “Stroke/Fill Path” dialogs used to
propose to stroke (respectively fill) either with a “Solid color” (in fact the
foreground color) or with a “Pattern“. We split the “Solid Color” into
“Foreground color” and “Background color“, so that you don’t have to
constantly switch their positions.
Furthermore the “Stroke Selection” and “Stroke Path” dialogs in particular
have been reorganized in a stack switcher making the 2 options “Line” and
“Paint tool” easier to use.
As a result of saving dialog space, we don’t hide anymore the “Line Style”
settings under an expander, in order to show more prominently the line rendering options.
When creating a new image or a new layer, there is this “Fill with” field
where you can choose the created layer color among the FG/BG colors, white,
black, transparency or a pattern. We added “Middle Gray (CIELAB)” which
corresponds to 50% of perceptual lightness (the L* of CIELAB or CIELCh),
or again 18.42% luminance.
Though the concept of “Middle Gray” may have different values depending on the
chosen definition, this is one of the most common, considered as perceptually
halfway between darkness and light to the average human observer’s eye.
A major chunk of the work on file formats is from Alx Sa (known as Nikc in
previous news), who has a knack for adding support for various formats and
improving the existing ones. And that’s awesome work so bravo Alx! 👍
FITS is an image format most commonly used in astronomy.
While we used to embed our own code for FITS support, we now ported it to
cfitsio, a library
maintained by the NASA.
This allows us to import compressed FITS files (GZIP, HCOMP, PLIO, RICE) in
8/16/32-bit and float/double precision. As a general rule, it will greatly
improve our support level for this format.
Since we now use an external library, FITS support becomes optional (especially
relevant to Linux distribution packages; on our own packages, it is always present).
Additionally we would like to thank Siril (the
astronomical image processing tool) whose developers exchanged with us to
improve the support in GIMP.
Clipping paths can now be imported from and exported to PSD files!
If your image has any path, a PSD export dialog will propose you to “Assign a
Clipping Path“, and a combo menu will allow you to select the path to use.
Exporting a clipping path - GIMP 2.99.16
This clipping path can be used in programs which support clipping paths,
e.g.
Scribus (desktop publishing)
already lists all the paths as usable as clipping path
yet will highlight in green the selected clipping path hence allowing to better
tag the path you want to use for this purpose.
Using a clipping path in Scribus (note in particular the path highlighted in green) - GIMP 2.99.16
Similarly, on import, any clipping path information stored in the PSD will be
reused as default for export.
Another interesting change is that on import, if some PSD features are not
supported, a compatibility warning dialog will be displayed, listing all the
missing features:
Compatibility warnings when importing a PSD - GIMP 2.99.16
This way, you can make an informed decision when working with exchanged PSD files.
Note that the export dialog also has a new “Compatibility Notice” regarding
legacy layer modes, as some people have noted that they have better
compatibility when exporting PSDs and reopening them in Photoshop.
Last but not least, a new PDB procedure "file-psd-load-metadata" was created to allow other plug-ins to
delegate PSD metadata loading to the PSD plug-in. Indeed a common usage in
various file formats is to self-extend by storing custom metadata in Photoshop
proprietary metadata format. We already implemented 2 such usages:
TIFF images can contain image-level proprietary resources in the
TIFFTAG_PHOTOSHOP metadata, as well as layer-level resources (e.g. PSD
layers instead of TIFF pages) in the TIFFTAG_IMAGESOURCEDATA metadata. GIMP
now supports both of these and will load what it supports.
JPEG images can contain PSD metadata on image-level only, such as paths. These
will now be loaded as well.
Same as in the PSD plug-in itself, if some of these metadata are unsupported, a
compatibility dialog will be raised.
These will enable a whole new world of support for JPEG and TIFF (relative to
the specific proprietary PSD resources) as they will sync to the support level
of the PSD plug-in instead of duplicating code.
Additionally to the various metadata-related improvements, the option
“4:2:2 horizontal (chroma halved)” got renamed to “4:2:2 (chroma halved
horizontally)” and the option “4:2:2 vertical (chroma halved)” to “4:4:0
(chroma halved vertically)“.
Research indicates these to be the most usual notations for these options these days.
We added initial support for CMYK(A) export: Key and Alpha data is saved in
extra channels and the simulation profile is saved as well.
Per the specification developers, the format does not support ‘naive’ CMYK
conversion, so a profile is required for export. The option “Export as CMYK”
will be disabled if no CMYK simulation profile is set.
We enabled OpenMP support when available
on the build machine. This means in particular that parallel processing is
enabled, which should improve processing speed in some cases.
New image format supports: PAM, QOI, Amiga IFF/ILBM, DCX¶
We recently added both import and export support for the following formats:
PAM (grayscale and RGB,
with or without alpha): essentially PPM files with a different header format
and alpha/16 bit support.
QOI: the funnily named
“Quite OK Image” format for lossless image compression of color raster images
(8-bit per channel), with or without an alpha channel.
We added import-only support for the following formats:
Amiga IFF/ILBM: initial support for
importing indexed ILBM, Amiga PBM, and ACBM images.
Now it may seem useless to support weird, old if not sometimes forgotten formats
but this is actually important (at least the import ability). This can be useful
for archiving, being able to display old images one may have created years ago,
reusing and work on existing data.
Ultimately GIMP aims at being able to load any format which has existed under
the sun!
Note: some of these new supports might not be yet in our official packages
(e.g. Amiga IFF/ILBM), though should be soon.
The development interface for plug-ins continues to evolve towards its
final state, though it is still one of the last big worksites now that
the GTK+3 port is over.
GIMP plug-ins used to refer to various resources (brushes, fonts, gradients,
palettes, patterns, etc.) by name. We moved into creating specific classes (GimpBrush, GimpFont, GimpGradient, GimpPalette and GimpPattern
respectively) in libgimp for these data, under a common parent class
GimpResource. This moves this part of the API to an object-oriented interface
(same as other existing types for images, layers…) which will be a lot nicer for bindings.
Moreover we move to unique IDs for each resource, which is not name-based. While
this part is still mostly libgimp-side, we plan on making names less of an
identifier in core code as well. This indeed creates name clashes much too
easily, especially if you exchange data with other people (it is very easy to
find custom brushes or fonts made by different people and using the same name).
We are working on making GIMP much more robust to these kind of real-life name clashes.
Some work was done on reviewing our plug-in localization rules. While we used to
have the menu strings localized by the core application itself, the rest was
localized by the plug-in process. This has always been confusing to third-party
developers (“Should I use _() or N_() to translate strings?“). Now it’s
very simple: the plug-ins takes care entirely of their own localization, hence
always send already translated strings to the core process. It also means that
changing GIMP’s language settings triggers a reload of all plug-in registrations
(to update strings).
Apart from simplifying the rule, it also prevents a possible clash for the
gettext catalog names (in case 2 plug-ins were to use the same catalog name,
it doesn’t matter anymore as each process handles their own).
And finally, even though we still recommend gettext (we also provide
infrastructure functions for plug-ins to easily set up plug-in localization with
gettext), it make third-party plug-in developers freer to choose their own
localization infrastructure if they prefer something else.
All these changes are also part of a longer term work to move plug-ins to
self-contained extensions
which will be easily sharable and installable.
While GStrv was added in GIMP
2.99.10,
it was not serialized into config files (our infrastructure to store plug-in
settings across runs), until this version.
A very cool first usage of this ability is for the Script-fu console which now
remembers the history of run commands.
Moreover plug-ins now have access to GBytes arguments for all the cases where
we were misusing arrays of unsigned integers on 8-bit instead, in order to
represent binary data (or more generally custom data, which can be anything,
from text to binary). The GimpUint8Array type has been removed as a possible
plug-in argument type and all its uses replaced.
More functions were added, for instance to enhance the capabilities of the GUI
generation for plug-ins. Some encoding issues were handled and various
functions’ annotations and usage have been clarified.
For a more exhaustive list of functions added, removed or changed, we advise to
look at the
NEWS file.
As usual, this version of GIMP is accompanied by new versions of
babl and GEGL:
babl 0.1.104 and 0.1.106 improved the LUT code and provide faster startup by
caching balanced RGB to XYZ matrices.
GEGL 0.4.44 and 0.4.46, in addition to the usual bug fixes, started to add the
"gimp:menu-path" key to some operations, improved gegl:ff-load,
gegl:ff-save to make them build with FFmpeg 6.0 (though gegl:ff-save still
doesn’t work properly with this version of FFmpeg), and added 2 new operations:
gegl:chamfer
New operation in workshop that use gegl:distance-transform and
gegl:emboss, based on LinuxBeaver’s research into modeling different bevels
with combinations of blurs.
Applying “gegl:chamfer” to text for a bevel effect - GIMP 2.99.16
gegl:local-threshold
Neighborhood aware and optionally antialiased thresholding of an image. The
operation is equivalent to doing an unsharp mask with a large radius, followed
by scaling the image up applying threshold and scaling down by the inverse of
the scale up factor.
If you have a photo and you want to make a decent highlights vs shadows
threshold it gives a lot better results than the built-in threshold. It finds
per-pixel adapted threshold levels for a gaussian average from the
neighborhood radius. In addition it permits creating anti-aliased threshold
masks (if the radius is set to 0, the behavior is similar to the built-in
threshold op).
From a UX point of view, the only thing missing for this new filter taking
over the current threshold filter is specifying the rgb⇒gray conversion,
then the additional parts of the UI would be options for threshold.
Beware though that antialiasing is achieved by scaling the input up and down -
so high settings make it churn with relatively little quality gain.
Left: original; top-right: result with current Threshold filter; bottom-right: result with new Local Threshold - GIMP 2.99.16
67 people contributed changes or fixes to GIMP 2.99.16 codebase (order is
determined by number of commits):
34 developers: Jehan, Alx Sa, Michael Natterer, Jacob Boerema, Simon Budig,
Luca Bacci, Niels De Graef, Daniel Novomeský, Lloyd Konneker, Øyvind Kolås,
Lukas Oberhuber, Ian Martins, programmer-ceds, Andras Timar, Andre Klapper,
Carlos Garnacho, Idriss Fekir, Jordi Mallach, Sabri Ünal, Shubham, Stanislav
Grinkov, Stephan Lenor, Venkatesh, kotvkvante, lapaz, lillolollo,
programmer_ceds, valadaptive, 依云, Anders Jonsson, Jordi Mas, Richard
Szibele, Tomasz Golinski and Florian Weimer.
31 translators: Martin, Yuri Chornoivan, Ekaterine Papava, Alexander Shopov,
Hugo Carvalho, Jordi Mas, Sabri Ünal, Rodrigo Lledó, Asier Sarasua Garmendia,
Anders Jonsson, Alan Mortensen, Cristian Secară, Sveinn í Felli, dimspingos,
Alexandre Prokoudine, Balázs Úr, Chao-Hsiung Liao, Piotr Drąg, Tim Sabsch,
Kristjan SCHMIDT, Luming Zh, Marco Ciampa, Alexandre Franke, Aurimas Černius,
Balázs Meskó, Christian Kirbach, Danial Behzadi, Emin Tufan Çetin,
MohammadSaleh Kamyab, Zurab Kargareteli and حجتاله مداحی.
10 resource creators (icons, themes, cursors, splash screen, metadata…):
Jehan, Michael Natterer, Alx Sa, Stanislav Grinkov, Lloyd Konneker, Ville
Pätsi, Aryeom Han, Daniel Novomeský, Anders Jonsson and Mark.
5 documentation contributors: Jehan, Lloyd Konneker, Anders Jonsson, Corey
Berla and Michael Natterer.
15 build or CI contributors: Jehan, Alx Sa, Jacob Boerema, Michael Natterer,
Daniel Novomeský, Lloyd Konneker, Michael Schumacher, Stanislav Grinkov, Niels
De Graef, Simon Budig, Lukas Oberhuber, Florian Weimer, Luca Bacci, lillolollo
and Jordi Mallach.
Contributions on other repositories in the GIMPverse (order is determined by
number of commits):
1 contributor to babl 0.1.104 and 0.1.106: Øyvind Kolås.
13 contributors to GEGL 0.4.44 and 0.4.46: Øyvind Kolås, Marco Ciampa, Martin,
Asier Sarasua Garmendia, Ekaterine Papava, Piotr Drąg, Yuri Chornoivan,
Alexandre Prokoudine, Jan Tojnar, Rodrigo Lledó, Sabri Ünal, Tim Sabsch and dimspingos.
2 contributors to ctx since 2.99.14 release:
Øyvind Kolås and Carlos Eduardo.
3 contributors to gimp-macos-build (macOS build scripts) since 2.99.14
release: Lukas Oberhuber, Kyungjoon Lee and Mingye Wang.
2 contributors (and a bot) to the beta flatpak: Jehan, Daniel Novomeský and flathubbot.
7 contributors to our main website (what you are reading right now) since
2.99.14 release: Jehan, Sabri Ünal, Jacob Boerema, Aryeom Han, Michael
Schumacher, lillolollo and Tim Spriggs.
9 contributors to our developer website since
2.99.14 release: Jehan, Bruno Lopes, Jacob Boerema, Krek Krek, Mark, Alx Sa,
GoldenWon, Michael Schumacher and kotvkvante.
16 contributors to our 3.0 documentation
since 2.99.14 release: Andre Klapper, Jacob Boerema, Anders Jonsson,
dimspingos, Yuri Chornoivan, Jordi Mas, Nathan Follens, Tim Sabsch,
حجتاله مداحی, Alexander Shopov, Balázs Úr, Danial Behzadi, Hugo
Carvalho, Martin, Piotr Drąg and Rodrigo Lledó.
Let’s not forget to thank all the people who help us triaging in Gitlab, report
bugs and discuss possible improvements with us.
Our community is deeply thankful as well to the internet warriors who manage our
various discussion channels or social
network accounts such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
Our release procedure is getting much better at each new version. I would like
to thank our testers who did an awesome job raising the few release-blockers we
had for GIMP 2.99.16, as well as the people who followed up on these issues,
handled technical responses, created or updated packages, and more.
In particular, a huge thank you to (by alphabetical order) Alx Sa, Anders Jonsson,
Daniel Novomeský, Hubert Figuière, Jacob Boerema, Liam Quin, lillolollo, Luca
Bacci, Lukas Oberhuber, Mark Sweeney, Sevenix, ShiroYuki_Mot and Uzugijin!
As a reminder, if anyone is willing to help us improve GIMP by participating to
release testing, please open a report on the developer website
tracker
with the following information:
The Operating Systems (Linux, Windows, macOS, *BSD…) you will be testing on,
with details if possible (which Linux distribution and version? Which version
of Windows or macOS?…).
The architectures you will be testing on (x86, ARM… 32 or 64-bit).
If you will test our pre-built packages or from source (custom builds).
Then we will notify you in the next release testing phase (stable and
development releases).
Our expectations from testers:
Make sure you receive Gitlab notifications when your nickname is cited (we
advise to set your Global notification
level to “Participate” or
“On mention”).
Follow the release report to know what’s happening and when you are needed.
Release reports are not a place where we teach people how to use basic
functions of a computer. Testers don’t have to be developers, but they have to
be able to follow basic technical guidelines, give feedback more useful than
“it doesn’t work” and be able globally to interact with developers.
Be nice and welcoming: everyone here is a volunteer, testers as much as
developers. This is Community, Free Software, not a soulless job. 🤗
The Fremont Cabal Internet Exchange contributed a new download
mirrors to
distribute GIMP, based in Sheffield, South Yorkshire (United Kingdom).
With 11 mirrors out of 41 in total, they are clearly our biggest mirror sponsor!
Thanks FCIX!
Mirrors are important as they help the project by sharing the load for dozens of
thousands of daily downloads. Moreover by having mirrors spread across the
globe, we ensure that everyone can have fast download access to GIMP.
Sabri Ünal did an awesome bibliographic research, added 39 books and updated
even more in our “Books About GIMP” page. We
won’t list all the changes as there are just too many, though you can read the
detailed merge request descriptions
(!93 and
!98).
We are starting to get a more up-to-date books
page with recent publications. Nice! 📚🤓
GIMP 2.99.16 is only available for Linux and Windows for now. Our macOS
packaging is currently blocked by our inability to notarize the packages until
the GNOME Foundation fixes their Apple account. We will keep you updated.
Update from July 11: GIMP 2.99.16 is now avalaible on Linux, Windows and macOS!
Though the
roadmap
shows a few more unfinished items, the 2 biggest workfields to come for the next
release are the API redesign — which is well on its way but is important enough
that we’ll need to really look into details —, and the Space Invasion project
(making sure every existing color-related feature is reliable).
As we are really reaching the “stabilization” stage in our development, while
our requirement rule was based on “Debian testing” (whichever it was), we
recently froze our dependency bumps on the just released Debian 12 (bookworm).
It means that we won’t bump any minimum requirement over what is in Debian 12
(except for optional dependencies, and even only so as exceptional cases and
with very good reasons). This is because we plan to release soon enough that we
need to make sure GIMP can be packaged on all reasonably recent
distributions.
Of course, for our own packages (Windows, macOS and Flatpak), we will always
use the latest dependency versions anyway.
Don’t forget you can donate and personally fund GIMP
developers, as a way to give back and
accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
With the unfortunate health situation of past years, GIMP team had not been
able to meet since 2019. This affected the software evolution (commit numbers
have been divided by about half!) because for many of us, GIMP is more than a
software: it’s people, it’s a community. So motivation shrank by lack of social encounter.
Therefore we are glad to announce the return of Wilber Week: our week-long
meeting of GIMP contributors (started back in
2017 as a
companion to the Libre Graphics Meeting).
A month ago, we had our second Wilber Week in Amsterdam!
Wilber Week 2023: GIMP/Inkscape contributors (from left to right: Niels, Mitch, Simon, Liam, Ville, Aryeom, Jehan, Øyvind, Chris and Schumaml) — photo by Niels, CC by-sa
Carlos Garnacho: long-time contributor and
advisor for anything input device, GTK or GNOME related, contributor and
maintainer for various important bricks in GNOME.
Niels de
Graef:
4+-years contributor, big contributor as well in GNOME, GTK and more…
Øyvind Kolås (pippin): 20+-year contributor, GEGL
maintainer, digital media toolsmith…
Simon Budig (nomis):
25+-year contributor, cares about keeping GIMP a nice community forever…
Ville Pätsi (drc): 22+-year contributor, photographer,
graphics contributor…
Additionally we invited 2 Inkscape contributors. What started as a simple
toot on Mastodon
transformed into a private discussion with Martin Owens from Inkscape who was
hoping to discuss color management with us. So we invited them to enjoy our
hacking retreat and discuss further!
In the end, Marc Jeanmougin, Inkscape
developer, and Chris Rogers, graphics
contributor, spent the week with us!
We were all lodged in a fricking century-old sailing boat. No joke! That was an
insanely cool place where we could start hacking from day one!
Wilber Week 2023: hacking in a sailing boat (from left to right:
Schumaml, Mitch, Jehan, Carlos, Marc) — photo by Niels, CC by-sa
About the city itself, let me state for the record that, as a vegan and
pro-soft transportation, Amsterdam seems like a very nice place to live in!
The Blender Foundation gracefully lent workshop and meeting rooms to our team.
Wilber Week 2023: GIMP contributors entering Blender headquarters — photo by Schumaml, CC by-sa
Of course, having “desks” was not our real reason to choose this office. It was
very cool to meet Blender teams. We were also able to have various interesting
discussions. Quite notably, Nathan
Vegdahl from Blender was extremely
welcoming and showed us a lot of very cool stuff!
As was expected, we discussed about color management, in particular in Wayland
as Sebastian Wick, major contributor for color management in Wayland was pulled
in a few times (thanks to Niels!) through remote video calls. This was very constructive!
Wilber Week 2023: meeting with GIMP, Inkscape and Wayland contributors in
Blender headquarters (left to right: Liam, Øyvind, Nathan, Marc, Jehan, Mitch,
Simon, Niels; and Sebastian on screen) — photo by Aryeom, CC by-sa
Bottom line: the interactions with Blender folks made the trip quite worthwhile!
In the same time, there were more things I was hoping to discuss, such as better
file exchange and interactions between our programs (think Libre Graphics
Suite, a major gripe we have at ZeMarmot project as we work with all these
software and it’s not always easy!).
There was already so much going on that this didn’t happen. Hopefully the
opportunity will come again!
This was a very packed week for hacking on GIMP, fixing bugs, improving long
overdue code and so on.
A huge part of this was thanks to the fact that we got our co-maintainer back,
Michael Natterer, a.k.a.
mitch!
We missed him dearly and it’s so good to have him looking over our code once
more, as well as hacking frenziedly until late at night, like the old times!
Wilber Week 2023: where has been mitch for 2 years? Turns out he was just sleeping… — photo by Jehan, CC by-sa
Of course, a lot of other old-timers came back to code for the occasion, so
let’s not forget them all!
Among the many things which happened during this very eventful week (or as
direct consequences), let’s mention:
Simon Budig should be commended for fixing warnings, cleaning code and
updating code away from deprecated API!
Niels de Graef and Carlos Garnacho helped with various GTK- and
Wayland-related fixes. This also resulted in patches in GTK or other
dependencies, not only in GIMP.
The plug-in API got seriously worked on, adding support of GBytes as plug-in
arguments, improving the new GimpResource class and subclasses allowing
plug-ins to easily manipulate various data (brushes, dynamics, patterns…) and more.
Autotools is finally gone from our main repository! (though it is still
present in the stable branch)
Our Continuous Integration now shows JUnit reports from meson unit tests.
Ville is getting used to improving our themes: he did the 2.10 ones, now again
he helped on the Default 3.0 theme, improving work started by other contributors.
As a direct result of Wilber Week, Carlos implemented, soon after, pad
customization ability to GIMP (with a very nice write-up on this
work).
As review will take some time, it won’t be in 2.99.16 though will definitely
end up in GIMP 3.0!
Aryeom worked on an updated logo, with the help of various GIMP contributors
(in particular Ville, Øyvind and Simon) as well as Chris from Inkscape. This
is still work-in-progress.
Some improved GEGL integration discussion and work happened during the week,
then continued after, allowing to easily add third-party GEGL operations in
GIMP’s menu and search for
them in the action search
(note: implementation changed since these toots; not all operations end up in
menus now, only when a specific metadata is present in the operation).
Aryeom updated the splash screen for the next development version (to be continued…).
While they couldn’t be present unfortunately, we shouldn’t forget Jacob
Boerema, Alx Sa and others who continued to improve GIMP remotely in the same time!
Since we had 3 projects selected in GSoC
2023 with Liam and
myself as mentors, we had GSoC meetings as remote calls with the students.
We have had a bitcoin address on the website. Some people have asked for more
crypto-currency options. With a rise in scams, high energy use and differing
national tax implications, we have decided — after discussion and a vote during
Wilber Week — to no longer feature a bitcoin donation link.
The donations in bitcoin have been received, some of them used, but we are still
working on how to properly channel these funds towards our expenses.
It turns out that we have been interviewed by Pablo Vazquez while in Blender’s,
so the cat is out of the bag in a quite public way now: we have been trying to
set up our own entity. But first, since I teased you, here was the interview:
Wilber Week 2023: GIMP’s Wilber Week 2023 at Blender HQ, by Pablo Vazquez (featuring Simon, Jehan and Mitch)
In case you wonder, the slides can be found
here, they were taken from
a end-of-event presentation I gave to Blender folks.
Wilber Week 2023: the EOF talk —
photo by Aryeom, CC by-sa
Making a proper entity for GIMP is something which has been on my mind for many
years and which I started to discuss with others of the team, and with friends
from other non-profits to help me find the best way, since 2019! After some
hiatus on this project, I revived my work on it late 2022, and we are actually
quite advanced, though I will refrain on giving too much details now in order
not to jinx it.
Let’s see how it pans out!
Now something to be clear about: GIMP has always been a bit of a messy and
friendly community project. And that’s part of what I like about it: this bit of
anarchy. Whatever we build to support the project, I will always fight for this
spirit to live on. This was in fact one of the difficult part of setting up an
organization and why it took so long: doing so without the organization taking
over the project, but instead as a support to the community.
Clearly this Wilber Week made me trust that my initial plan (outlined in the
2022 report
as hoping to have GIMP 3.0 release candidates this year) should be possible. If
we can keep the community as lively, there is high chance to see this happen.
We are clearly sailing in exciting times, right now, toward a very cool future! 😄
For anyone interested, the meeting page on the developer
website
gives a bit more details on what happened, what was actually discussed, meeting
notes, etc.
Right now, we are deep into preparing the release of the next development
version of GIMP (GIMP 2.99.16). And while it’s not even out, we are already
quite excited about the next one (which might even be a release candidate in the
best case!).
In the meantime, do not forget you can donate and personally fund GIMP
developers, as a way to
give back and accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
On our new developer website, we listed a few
ideas which might be
suitable for a GSoC. These range from core color science projects to UX
improvements, build system updates or even making a website for our future
extension platform.
Obviously this list of ideas is far from exhaustive and we definitely welcome
your propositions. Even better, if you have great ideas of your own, it may
play in your favor, as long as they are realistic projects which can be finished
within GSoC timeframe, or at least broken down in usable parts.
As already explained last year, and again in our internship
page, if you want to participate,
some of the most important requirements are:
Get familiarized with our code by fixing a few patches beforehand. You
don’t have to work on extra-complicated bugs or features at first (reports
labelled
“Newcomers”
are probably good first-patch targets), nor does it absolutely need to be
related to the topic of your planned project. We mostly need to interact with
you on a technical topic as a first approach.
Communicate! Don’t just drop your project out of the blue on the GSoC
interface (several people did this last year). Come and discuss your project
ideas with us on IRC. You may
also open a report on our issue
tracker detailing your proposition.
This news lists the most notable and visible changes. In particular, we
do not list here the bug fixes.
To get a more complete list of changes, you should refer to the
NEWS
file or look at the commit
history.
The release of a GIMP Help manual has been long overdue. We published a 2.10.0
test release, but that was never meant to be an official release.
Due to the lack of volunteers and the amount of documentation needing updates,
this test release eventually became the de facto first 2.10 release, although
it was outdated in a lot of places and missing documentation for newer features.
There still is more work to be done, but after a long period of hard work, the
manual is finally in a state where we can present you a new official release.
Not that we want to discourage you from using this release version of the
manual, but the online manual is being updated daily. It should generally be
your first choice, unless you have limited internet bandwidth or other reasons
to prefer the offline version.
We modernized our website to be more in line with the main GIMP website and
improved the information about our manuals. New automated builds are published
to our website once a day. Even better, our website now shows the completion
status for each language.
A lot of languages still need considerable work. If you would like to help
improve that, please visit
https://docs.gimp.org/help.html
for more information.
Several new translations are being worked on: Czech (restored), Hungarian,
Portuguese, Ukrainian. In addition to these, installers are now also
available for Slovenian and Swedish, which were missing from the 2.10.0 test
release.
Persian was added too, but since no actual translations for the 2.10.34 manual
were made yet, we do not supply an installer for that.
Almost all other languages were updated to some degree.
A large part of the manual has seen updates. In some cases only small updates,
but many pages have seen considerable changes.
Some highlights are:
All GEGL filters, some of which were not documented at all, are now covered.
The new layer modes introduced in GIMP 2.10.0 are finally documented,
including examples of each mode.
The getting stuck section was updated and extended to cover more problematic situations.
Missing preferences were added, others that are no longer there were removed.
The Script-Fu tutorial got revised.
Context sensitive help ids in GIMP were synchronized with the manual. This
means that it is now a lot less likely you will encounter a missing help page.
Most parts of GIMP’s interface should now be documented. If you see anything
that is still missing or that could be improved, don’t hesitate to
open a documentation issue.
Since GIMP is getting closer to a 3.0 release, we need to update our
documentation to add all changes that have been made compared to GIMP 2.10,
and of course we will also keep updating the 2.10 manual.
To make this effort more manageable, we would really welcome more helping hands.
This news lists the most notable and visible changes. In particular, we
do not list here the bug fixes.
To get a more complete list of changes, you should refer to the
NEWS
file or look at the commit
history.
Apart from various bug fixes, the TIFF import dialog now gets a new option
labelled “Show reduced images“, which is backported from the development
release GIMP
2.99.14.
Here is what we said about this option when initially announced:
The TIFF format has a concept of “reduced page”. Until now, we were assuming
pages tagged as “reduced” to be thumbnails. Yet this is not always the case. For
instance we had feedback from makers of medical devices which were using
“reduced pages” as sub-sampled images generated by said devices. They needed
GIMP to be able to load all the pages as layers (the main images and the
sub-sampled ones).
Importing reduced pages of TIFF files - GIMP 2.10.34
This is why we added a new option called “Show reduced images” which lets you
decide whether you want to load these or not. The option will be checked by
default through a small heuristic: if there is only 1 reduced page and it’s in
the second position, then it’s probably a thumbnail (as per common usage across
software); in which case we disable the checkbox by default. Still in the end,
the choice is yours!
While JPEGXL import has been possible in the stable branch since GIMP
2.10.32,
export support has now been backported too in this version, though it is limited
to 8-bit lossless.
Additionally, metadata support on import (only) has been backported, making this
version of GIMP much more useful for anyone working with this format.
Note for packagers: metadata support in JPEGXL requires libjxl 0.7.0 or over.
Our code for PDF import and export was pretty oblivious of the ability to have
transparency in PDF. This is now changing.
From GIMP 2.10.34 and onwards, the PDF import dialog will propose an option
labelled “Fill transparent areas with white“. It will be checked by default
(thus providing the old behavior) because most office software seem to create
PDF files assuming reader software will fill the background with white.
Unchecking the box would not render the expected result.
This is likely why our code was historically doing the same as other reader
software.
Nevertheless for the cases where you were actually intending transparent
background upon loading, it will now be possible.
PDF import in GIMP 2.10.34: new “Fill transparent areas with background color” option
Symmetrically when exporting a PDF, we now propose an option labelled “Fill
transparent areas with background color“, letting you decide whether or not you
want to add an opaque background, hence getting rid of transparency, or leaving
your image with transparency, exactly as you see it in GIMP canvas.
PDF export in GIMP 2.10.34: new “Fill transparent areas with white” option
Of course note that, as said above, not all PDF readers handle transparency.
Very often, many readers (including web browsers’ readers) will fill the
background with white.
Yet if you have a more compliant PDF reader or editor, this new usage can be of interest.
🛈 We are talking here of “raw data” where you export your pixels as
contiguous or planar data directly, without following a specific file
format, and not RAW file formats as are usually called formats used by
digital cameras (for these, we still prefer to pass through good raw
developer software, such as darktable or RawTherapee).
Note though that improvements to this plug-in in the development version were
not fully backported. In particular, you may not be able to load back the high
bit depth images that you exported. The reason is that the changes required for
this would modify considerably the PDB
procedure tied to this plug-in, which would break third-party scripts relying on
this procedure to load raw data as images.
Template selector in Canvas Size dialog - GIMP 2.10.34
Item dockables with “Visibility” and “Link” headers¶
As a very partial backport of the many usability
changes
which happened in the development version 2.99.10, the Layers, Channels and
Paths dockables now feature a small header above the items list, containing the
“eye” and “chain” icon, hence making the columns more discoverable.
“visibility” and “link” icon header
Note: the outline effect when hovering the visibility and link columns was
already backported in GIMP
2.10.32.
GIMP has 2 color-picking features: the Color Picker tool which works only within
the opened images yet with greater color management and the color picker button
in the Colors dockable, which can color pick anywhere in the display and
relies on the infrastructure allowed by the OS or desktop you are currently
running on.
On Windows, the color-picking feature has been entirely rewritten with
OS-dedicated code which works much better with multiple monitors, even when
using different PPI scales, for instance
when mixing high and low pixel density displays (this fixes some coordinates
mistracking bug our previous implementation had).
On Linux/X11, we are backtracking to fix a regression in desktop
color-picking. We used to follow recommendations for the new Wayland path, which
is to favor color-picking “portals” when available. Unfortunately most (if not
all?) these portals still don’t give any color-management information about the
returned color. As graphics work requires accurate color management, we decided
to get back using full old-style X11 code.
Note that since the stable branch of GIMP is still using GTK+2, even if you run
on Wayland, GIMP itself would use XWayland. In other words, GIMP 2.10.34 now
runs the X11 code path whatever windowing system is in use.
In “Change Foreground|Background Color” dialogs or in the Colors dockable,
you have the option to view your colors in a 0..100 or 0..255 scales. You
can also see your color in alternative LCh or HSV color models.
These 2 settings are now stored and remembered across sessions so that you don’t
have click them again each time for your usual and preferred workflow.
This version comes with a few bug fixes dedicated to the macOS builds. The most
noteworthy one is that we implemented HTTPS support (since our I/O backend library, GIO, is lacking proper macOS
support for this protocol) for 2 features in particular:
Check for updates: unless you disable the option in “Preferences”, you should
now be notified of new versions of GIMP.
Help system: it is now possible to read the remote documentation from within
the Help Browser in GIMP.
As usual, this version of GIMP is accompanied by new versions of
babl and GEGL:
babl 0.1.100 comes with bug fixes in the recently added LUT creation and
usage
code. It also better supports non-ASCII characters in file paths on Windows.
babl 0.1.102 disabled the LUT usage by default depending on the environment variable BABL_LUT, leaving us some time to iron out a few more issues we
discovered at the last minute.
GEGL 0.4.42 adds conditional support for libraw 0.21.0, while also improving
the following operations: rgb-clip, perlin, mosaic, c2g, long-shadow
and gif-load.
Various build improvements also happened in both babl and GEGL.
35 people contributed changes or fixes to GIMP 2.10.34 codebase:
13 developers: Jehan, Jacob Boerema, Alx Sa, Daniel Novomeský, Lukas
Oberhuber, Luca Bacci, Ian Martins, Nyári-Kovács, Dávid Tamás, Simon Budig,
Stanislav Grinkov, valadaptive and Øyvind Kolås.
22 translators: Sabri Ünal, Anders Jonsson, Martin, Yuri Chornoivan, Marco
Ciampa, Cristian Secară, Rodrigo Lledó, Tim Sabsch, Alan Mortensen,
Chao-Hsiung Liao, Ekaterine Papava, Milo Ivir, Piotr Drąg, Zurab Kargareteli,
Jordi Mas, Luming Zh, Luna Jernberg, Balázs Úr, Hugo Carvalho, Jürgen
Benvenuti, Kristjan SCHMIDT and Sveinn í Felli.
19 translations were updated: Catalan, Chinese (China), Chinese (Taiwan),
Croatian, Danish, Esperanto, Georgian, German, Hungarian, Icelandic, Italian,
Polish, Portuguese, Romanian, Slovenian, Spanish, Swedish, Turkish and Ukrainian.
Contributions on other repositories in the GIMPverse:
4 contributors to babl 0.1.100 and 0.1.102: Luca Bacci, Jehan, Øyvind Kolås
and Ulf Prill.
7 contributors to GEGL 0.4.42: Øyvind Kolås, Alan Mortensen, Jehan, Michael
Drake, Sabri Ünal, Chris Mayo and Jordi Mas.
2 contributors to ctx since 2.99.14 release:
Øyvind Kolås and Carlos Eduardo.
3 contributors to gimp-macos-build (macOS build scripts) since 2.99.14
release: Lukas Oberhuber, Kyungjoon Lee and Mingye Wang.
4 contributors to our main website (what you are reading right now) since
2.99.14 release: Jehan, Aryeom Han, Michael Schumacher and Tim Spriggs.
3 contributors to our developer website since
2.99.14 release: Jehan, Krek Krek and kotvkvante.
9 contributors to our documentation since
2.99.14 release: Jacob Boerema, Anders Jonsson, Jordi Mas, Yuri Chornoivan,
Andre Klapper, Danial Behzadi, Hugo Carvalho, Martin and Nathan Follens.
Then let’s not forget to thank all the people who help us triaging in
Gitlab, report bugs and discuss possible improvements with us.
And of course, our community is deeply thankful to the internet warriors
who manage our various discussion
channels or social network accounts
such as Ville Pätsi, Liam Quin, Michael Schumacher and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
As far as I remember, GIMP has had a very accurate release procedure, with
step-by-step TODO items listed in a long file.
Lately I have been working on improving it further, making a public
report, actually checkable
bucket list items… and in particular, I would like the source and binaries to be
thoroughly tested by as many people as possible. 👩🔬🧪👨🔬
This version is the first time we try this new release procedure (the procedure
worked fine: the release was delayed by us finding some last-minute issues which
is actually a good thing!).
We already have a few people testing GIMP on Windows, though the more the
better.
On the other hand, we have nearly nobody testing the macOS builds or the
flatpak (apart from developers and packagers of course). 😢
Note that we don’t have our own packages for every OS out there, but we
definitely welcome people willing to test GIMP on *BSD, Haiku or whatnot, as
long as you can build GIMP on your own on your system of choice.
For these reasons, if anyone is willing to help us improve GIMP by participating
to release testing, please open a report on the developer website
tracker
with the following information:
The Operating Systems (Linux, Windows, macOS, *BSD…) you will be testing on,
with details if possible (which Linux distribution and version? Which version
of Windows or macOS?…).
The architectures you will be testing on (x86, ARM… 32 or 64-bit).
If you will test our pre-built packages or from source (custom builds).
Then we will include you in the next release testing (stable and development releases).
Our expectations from testers:
Make sure you receive Gitlab notifications when your nickname is cited (we
advise to set your Global notification
level to “Participate” or
“On mention”).
Follow the release report to know what’s happening and when you are needed.
Release reports are not a place where we teach people how to use basic
functions of a computer. Testers don’t have to be developers, but they have to
be able to follow basic technical guidelines, give feedback more useful than
“it doesn’t work” and be able globally to interact with developers.
Be nice and welcoming: everyone here is a volunteer, testers as much as
developers. This is Community, Free Software, not a soulless job. 🤗
2 organizations contributed more download
mirrors to
distribute GIMP.
Thanks to Artfiles New Media GmbH (Hamburg, Germany), which has actually been
a long-term mirror sponsor and recently came back by updating their settings to
our new mirror system; and the Fremont Cabal Internet Exchange which added 2
more mirrors in the United States and one in Bogotà, Colombia (our second mirror
in South America).
Mirrors are important as they help the project by sharing the load for dozens of
thousands of daily downloads. Moreover by having mirrors spread across the
globe, we ensure that everyone can have fast download access to GIMP.
A new “Czech” section was added to our books
page, with 4 books which got reported to us.
These books are a bit old and all seem to be targetting GIMP 2.8. So let’s hope
for a lot of GIMP 2.10 (and soon 3.0) coverage in Czech in the future!
We remind everyone that we welcome book additions, especially newer books for
latest versions of GIMP (which would be most useful to everyone). Whether you
wrote it or just read it, if you know of a book about GIMP, just report the
same information as other books in the
list. Thanks!
These days, we are mostly focusing on the development version, especially since
we have big plans for 2023, as was outlined in our 2023 plans (2022 annual
report).
For anyone interested in the future of GIMP, I highly recommend reading this report.
Nevertheless bug fixes in particular, and maintenance in general, still need to
get out for the stable branch. We will likely release at least one, possibly
more, stable versions before GIMP 3.0 release.
Don’t forget you can donate and personally fund GIMP
developers, as a way to
give back and accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
1461 commits on the unstable development branch (2.99.x, future
3.0) and 276 commits on the stable development branch (2.10.x) of
the main repository.
87 contributors on the main repository, including (some people belong
to several categories):
35 developers
47 translators
26 contributors to resources (icons, themes, in-code documentation) or
build improvements
7 core developers contributed 10 or more commits in GIMP’s main
repository:
Jehan: 649 commits
Jacob Boerema: 64 commits
Nikc: 50 commits
Daniel Novomeský: 25 commits
lloyd konneker: 25 commits
Lukas Oberhuber: 18 commits
Niels De Graef: 15 commits
115 commits to babl by 10 contributors, with 3
developers contributing 10 or more commits:
Øyvind Kolås: 86 commits
Axel Viala: 10 commits
Jehan: 10 commits
138 commits to GEGL by 32 contributors, with 5
developers contributing 5 or more commits:
Øyvind Kolås: 47 commits
Behnam Momeni: 9 commits
Michael Drake: 7 commits
Thomas Manni: 7 commits
Jehan: 5 commits
1042 commits to ctx by 2 contributors (mostly
Øyvind Kolås).
492 commits in gimp-help (our manual) by 29 contributors, with 11
people contributing 10 or more commits (this list mixes documenters, build
maintenance and translators):
Jacob Boerema: 229 commits
Anders Jonsson: 47 commits
Rodrigo Lledó: 38 commits
Jehan: 28 commits
Jordi Mas: 25 commits
Tim Sabsch: 19 commits
Nathan Follens: 17 commits
Marco Ciampa: 16 commits
Yuri Chornoivan: 15 commits
Andre Klapper: 13 commits
Hugo Carvalho: 11 commits
178 commits in gimp-macos-build (our macOS build) by 3 contributors
(mostly Lukas Oberhuber).
33 commits in the stable branch of our Flathub/Flatpak package and 23
commits on the beta branch by 6 contributors, including 4 core contributors:
Jehan, Ondřej Míchal, Hubert Figuière and Daniel Novomeský.
227 commits to GIMP’s website (gimp.org, i.e. right here) by 10
contributors (mostly Jehan).
178 reports fixed and 206 merge requests integrated in our 2022
releases. Hundreds more reports handled, triaged, answered to, worked on…
Many patches contributed by GIMP contributors in various other projects we use
(at least GLib, GTK, Cairo, meson, Mirrorbits…) and an uncountable number of
issues reported by our contributors to other projects.
And more!
Compared to last year:
The total amount of work is quite similar, and while that tendency had already
started a year ago, the work has clearly been shifting even more towards the
development branch (future 3.0), which nows accounts for 84% of commits
(against 74% last year), while the stable branch is really getting into
maintenance-only mode.
Less work on GEGL happened but more work on babl. The recent work on automatic
LUT creation and SIMD optimizations explains it.
ctx stays heavily developed.
While Øyvind and myself still remain the 2 heavy-lifters, we get more people
around clearly pulling their weight. It is exciting to see more contributors stay.
Jacob is working more on the documentation which is really increasing in quality.
On the side of our graphics engine, the automatic LUT
creation
for color conversion in babl is clearly a big step forward, introduced in GIMP
2.99.10 (then in the stable version 2.10.32).
At the same time, all babl, GEGL and ctx got nice SIMD
optimization
which allowed nice performance boosts.
Øyvind Kolås is really doing an amazing job, as usual.
It is also interesting to note how the concept of “GEGL plug-ins” took off in 2022.
It in fact just refers to third-party GEGL operations which you simply install
in a folder and GIMP will see them at next restart, including all the fancy UI,
such as on-canvas preview with split view (and when we’ll have non-destructive
layer effects, these operations will also be usable!).
Among people spearheading such community development, we should cite
LinuxBeaver and Liam
Quin.
For anyone interested, I suggest to read the 3-part
tutorial written by Liam (“Using GEGL
Plug-Ins”,
“GEGL
Graph”
and “Writing C
Plug-Ins”).
✔ ported away from intltool to gettext only (technical debt cleanup);
✔ finished the meson build: the autotools build still exists but is now
considered secondary;
✔ finished the last pieces for multi-layer selection (a move started early
2020).
including rewriting completely the interaction in the formerly terrible align
and distribute tool.
These are 3 huge pieces in our roadmap which we happily marked as completed
(apart from probable bugs).
On the getting closer side:
We nearly finished the “Less floating selection” move (some use cases remain,
which we need to think about more).
The Wayland support is still kinda wonky at times (even disregarding all the
issues we cannot do anything about — such as color management not implemented
yet in Wayland —, we have weird windowing issues), but it improved in 2022.
The API work is really moving forward; Lloyd Konneker helped a lot on this.
The GTK+3 port is nearly finished, as we are handling these days the last
annoying warnings (though it’s more a January 2023 thing!).
Space invasion: good parts of it were done since the CMYK push made us look at
specific pieces of code more in details. Though a lot still needs to be done
and color science is at times a very head-scratching part of the work.
Now anyone following our development news knows
that a lot more happened.
This report is not going to repeat what we already wrote about in various news items.
One particular contributor to encourage this year is Nikc who came to us with a
few patches at first then proposed a Google Summer of Code
project, and decided
to stay around. Thanks to them, a lot happened for CMYK support in GIMP and our
“Space Invasion” project also moved forward further.
They are now a very prolific core contributor. This can only mean good stuff for
the future!
Clearly our macOS support has never been better: good continuous
integration, automatic DMG package creation, and now we even got an Apple
Silicon package!
The quality of maintenance and updates for this package is outstanding.
Lukas Oberhuber is the one to thank for this. Yet the bus factor for our macOS
package remains extremely low so we always welcome more contributors.
On Windows side, GIMP is now officially distributed on the Windows
Store,
after getting contacted by a developer relations team at Microsoft. This is
great as too many non-trusted packages used to be distributed there and now they
seem to have mostly disappeared with the official one eclipsing them with its very
good rating.
On Flathub (GNU/Linux), the burden is getting lightened as we now got
automation in dependency version check, thanks to Ondřej Míchal. The flatpak
package team is also getting bigger, with 4 recurring contributors.
We also got some infrastructure changes, such as our mirroring system, now based
on Mirrorbits. This is something I am planning to talk again about soon, so I
won’t go into details.
On community side, our mailing lists have been discontinued, together with all
of GNOME mailing
lists
whose infrastructure we are on. We now
recommend 2 forums for the community:
Our documentation
website
is getting a lot of love, thanks to Jacob Boerema, with automatic updates,
statistics showing… and of course, the contents is getting serious scrutiny to
improve documentation quality. Compared to 2021, there has been nearly double
the number of commits in 2022, which is revealing of the big step up.
Meanwhile we revived the developers
website
which was in a dire state for over 10 years.
We still have a pending project to port the main website to the Hugo framework
as well. Unfortunately this could not happen in 2022.
I should not give dates, so don’t take it as a promise. Maybe it’s just a
foolish dream by a foolish man:
I am currently planning GIMP 3.0.0 release in 2023, or at least our first
release candidates.
Here. I said it. If it doesn’t happen, remember that it was not a promise. 😜
There is still a lot to be done, so I hope I’m not making a fool of myself. But
at some point, not being able to release just gets frustrating. Of course, we
are still within acceptable development durations (GIMP 2.8 to 2.10 took 6
years; we are still in the 5th year since 2.10) but I really want to get it over with.
Now to get this deadline to work, I have decided to delay some elements out of
our 3.0 roadmap. In particular:
Extensions management: project dear to me as I started it and developed what
is already implemented, yet to get a safe online infrastructure to handle
extension search and download, we will need time.
Paint Select tool: very awesome tool, but its contributor, Thomas Manni, is
not happy with the performance (it requires instant canvas feedback to be
usable) and is currently investigating alternative algorithms.
In the same time, I have been pushing aside some nice new code contributed to us
when I realize reviewing it and making back and forth corrections will take us
weeks. For instance, some of you may have seen the nice “vector
layers” demo by Nikc (based on
work by Hendrik Boom and Jacob Boerema) on social networks. This won’t make it
to GIMP 3.0.
This is a rule which I apply to my own code. Some people might indeed remember
my own link layer experiments for
instance, which I stopped working on 2 years ago, already for the same reason.
These will still happen, I’m only moving these targets away into further
releases, which I’m explaining in the next section.
This leads me to an organizational work I’ve been doing lately on our roadmaps
and on planification of releases. Up to this day, you must have read a lot about
our bi-version planification: GIMP 3.0 for GTK+3 port then 3.2 for
advanced non-destructive editing.
While this second target is still definitely a big plan in our roadmap, I don’t
think that making it again a huge development cycle with dozens of features and
taking several years is the wisest thing. This old development model made sense
back in the day, but less nowadays in my opinion.
My goal for GIMP is to release more often, with faster development cycles, maybe
less features at once, yet nice features at each release. This is something I
had been pushing for, ever since 2014, when I was still a newcomer (I first
evoked that we should be able to publish new features even in micro versions in
a meeting during LGM
2014).
This ultimately led to our release policy
change,
starting from GIMP 2.10.0. And this is what I want to continue pushing further.
So my point is that targetting for a “GIMP 3.2” somewhere in the distant future
doesn’t make sense anymore. The non-destructive editing features, such as
non-destructive layer effects, will happen, but will it be GIMP 3.2.0? Or some
3.0.x version instead? We’ll see. It’s all just numbers anyway. We may likely
break this down in smaller releases in the end.
With this in mind, I reviewed our after-3.0 roadmaps into smaller pieces,
per logical categories of projects we want and which will definitely happen.
Link and vector layers are now into a new “non-destructive layer
types”
category. The code is so well advanced that it would be a waste and while
these won’t make it to GIMP 3.0.0, it will definitely become one of the prime
targets immediately after release. Maybe in GIMP 3.0.2?
By the way, this also opens the door to the long-awaited shape features:
with vector layers, we could have non-destructive shape drawing.
I mean, on-canvas shapes should be a vector features to make it right!
Non-destructive layer
effects
(formerly the main target for 3.2) is obviously a project on its own.
Macro
support is also something we’ve wanted for a long time and with GIMP 3.0, we
have started to lay the foundations for this feature. This should hopefully
soon become a reality.
Animation
support,
which as most of you know is something I’ve worked on for years, will have to
be in GIMP someday. So it’s also its own category. It will also bring
multi-page support (not just layers as pages).
The Space Invasion
project will continue: for 3.0, we focus on correctness of color models we
already support; after 3.0, we might look into going further with new color
models backends, such as core CMYK or L*a*b* support, but also spot color
channels and whatnot…
We have now a bunch of unfinished tools
in our playground area and it would be good if we took the time to finish
them. Of course, we also have ideas for nice new tools. And finally there are
tools which we really want to improve, such as our Text tool which deserves
more love.
Finally we have started to enhance the concept of
“canvas“, with the “Show
all” feature since GIMP
2.10.14.
We always wanted to go further, and also to rework the concept of layer
dimension (e.g. with auto-growing layers, or even infinite layer abilities).
…
And this is how I completely rewrote our roadmap page. Hopefully some people
will enjoy reading the new page and will find it exciting. Note that contents
didn’t change that much, except that it has been reorganized to put more
emphasis on the bigger strokes for GIMP evolution after GIMP 3.0 release, making
it more obvious (hopefully) which direction current contributors are pushing
GIMP to go.
This is where we are at. I’m expecting 2023 to be an eventful year. 2022 has
been quite awesome too, but also tiring to the point that there were weeks when
I couldn’t work on anything, especially soon after coding bursts for releases. I
also focused a bit more on getting healthier work habits, such as working with a
height-adjustable desk (for sitting and standing work sessions) and doing
regular walks.
This is also why I work on procedures to get faster releases, better
infrastructure and better documentation for onboarding new contributors. I am
aiming for a more organized path while keeping the slightly 🌪️ chaotic ❤️🔥 core
which really makes working in our team so enjoyable. ☺️
As I was saying in last year’s report, GIMP is not only a Free Software, it
is also a Community Software: random human beings doing something nice
together and sharing it with everyone. Why? Because we can, because we want. And
that’s why I love our small community, with just the right amount of chaos and
insanity, sparkled with just the right amount of organization!
Finally don’t forget you can 💌 donate to the project and personally fund several
GIMP developers, as a way to give back
and accelerate the development of GIMP. As you know, myself as
maintainer of GIMP (through “ZeMarmot” project) and Øyvind as maintainer of GEGL
are crowdfunding the work this report is about.
Any support is appreciated to help us succeed in such endeavour.
I wish you all a happy, funny 🥳 and healthy year 2023 and/or year of the rabbit 🐇!
It is a bit of an early Chistmas 🎅 for people using Apple Silicon machines
(Apple M1, M2…) as we release for the first time ever a stable version of GIMP
for this architecture!
It is a revision package for GIMP 2.10.32, already released a few months
ago, re-built with
our new MacPorts-based
infrastructure
on both x86_64 (“macOS on Intel” architecture) and AArch64 (“macOS on Apple Silicon”).
Note that we provide 2 DMG packages now, one for each architecture, not a single
universal package. The website will try and detect which architecture you are
on, but if it fails to detect properly (detection is not as easy on some
browsers), be careful to choose the version for the correct hardware (“for
Intel” or “for Apple Silicon“).
Additionally in this revised package, dependencies have been updated, in
particular babl and GEGL. It means that even for macOS on Intel, you will get
the recent
fix
to the race condition bug which was sometimes causing crashes of GIMP (somehow
we mostly saw it happen on macOS).
This is why we recommend every person on macOS (whichever your hardware) to
update GIMP with this revision 1 of GIMP 2.10.32.
To celebrate, Aryeom (ZeMarmot‘s director) drew
this nice birthday illustration (fully drawn within GIMP, and under Creative
Commons by-sa 4.0 license, of course!):
“Happy 27th birthday!” by Aryeom
(also a Wilber-less version as
temporary gimp.org header), Creative Commons by-sa 4.0
For both Aryeom and I (Jehan), this is our tenth year of continued contribution,
since a first commit in September 2012 (basic icon-changing patch in the
animation playback plug-in, soon followed by more… many more patches…). Back
then, never would we have imagined sticking for so long around this nice core
community (regarding this point, we thank the other contributors for their
welcomeness, and in particular the wonderful
mitch)
and contributing litterally thousands of patches in GIMP! So it’s also a pretty
big personal milestone.
It is also my second year maintaining GIMP. And to be fair, Aryeom has a huge
role in my maintenance with constant reviewing, testing my code (and other
contributor’s code), following up with feedback, specifying behaviors (while
always caring about others’ usage! One of her main rule when she helps designing
changes is researching and wondering what worflows others have). So much is
being done in the shadow to keep it all together.
But GIMP is not only us. What would we do without Øyvind Kolås in particular?
Nowadays he is carrying most of our core flow-based graphics engine maintenance,
GEGL, and its sister projects (babl
and ctx).
Of course, I can’t forget all other awesome contributors: developers, packagers,
community support, translators (GIMP is more than 90% translated in 27
languages among 84 languages we currently
support!), documenters, website contributors, tutorial writers… We should also
thank the GNOME Infrastructure team for being so helpful of course. And many
many more! What would GIMP be without all of you? 💌
I will likely do a more detailed report later (like I did last
year) to sum up 2022
events, so I’ll stay short in this news. For once!
All in all, we wish to remind that GIMP is Community, Free Software. It
is what we make of it together. We welcome
contributors very warmly 🤗!
Finally if you can’t contribute your time, in these year-end times of giving, don’t forget
that you may support financially GIMP developers.
GIMP project actively supports its contributors willing to make a living with
their Free Software contribution. Right now it means 3 people: Aryeom and myself
(through ZeMarmot project) as GIMP maintainers
and Øyvind as GEGL maintainer. If you
appreciate what we do and wish to give back, funding us is an excellent way.
It is part of what makes GIMP development sustainable.
And for everyone who is really eager to see GIMP 3.0 out, it should go
without saying that funding developers is what accelerates the development of
GIMP.
🎁 So GIMP, and
Wilber, we wish you a very happy 27! 🎂
And to every member of the community: thank you all for sticking with this
project for all or part of these 27 years!GIMP would not be where it is today
without all of you! 💌
The GIMP team is happy to release GIMP 2.99.14 with a lot of nice milestones on
the route to GIMP 3.0.
We are getting into deep changes, so we hope you will all test thoroughly and
we remind you that it is an unstable version meant for testing and reporting issues.
Align and Distribute tool: fully reworked interaction¶
The Alignment tool was very hard to use, with complicated on-canvas interaction
to select the target items (and never being too sure if we selected right!).
Thanks to the core multiple layer
selection
which GIMP is now capable of, we greatly simplified the tool:
Target items to align or distribute are now the selected layers and/or paths
in their respective dockable, as set in the “Targets” section in tool options.
Targets in alignment tool options - GIMP 2.99.14
For layers in particular, a new option “Use extents of layer contents” allow
to align or distribute target layers based on their pixel contents, not the
layer bounds (which typically might be bigger than the pixel data). This is
similar to running “Crop to Content” before aligning, except that we don’t
actually crop.
Guides still need to be selected on-canvas if you want to align or distribute
them. The tool options hints at the modifiers: Alt or Shift-Alt. Moreover
the selected guide color will change, giving a visual feedback of selected guides.
Aligning and distributing guides - GIMP 2.99.14
Simple clicks (no modifiers) in the canvas is now only used to pick the
reference object for alignment, if “Picked reference object” is set in the
“Relative to” dropdown menu. In such case, you can pick as reference any
layer, path or guide. The 2 other dropdown choices are “Image” and
“Selection” in order respectively to use the current image or selection as
alignment reference.
Your reference object shows on-canvas handles as visual feedback.
In the “Targets” section of the tool options, you can also choose your item
anchor points: left, right, top, bottom and center. Therefore if you align
2-dimension targets and reference, you may align e.g. the left side of targets
to the left, middle or right side of your reference. Any combination is possible.
The distribute actions do not use the reference object anymore. Instead they
use the leftest/rightest or top/bottom object as reference (i.e. that the 2
extreme position targets don’t move). This is consistent with how other
software, e.g. Inkscape, handle distribution.
2 types of distribution actions are proposed:
Distribute anchor points evenly in the horizontal/vertical: the distance
between the anchor point of each target stays the same, e.g. the distance
between the left side of each object.
Distribute horizontally/vertically with even horizontal/vertical gaps:
the distance between the right side of one object and the left side of the
next (in horizontal distribution) statys the same.
Align Wilber
and ZeMarmot relatively to Wilber’s
center point, then objects tops under Wilber, before distributing them - GIMP
2.99.14
All transform tools (Unified Transform, Rotate, Scale…) needed an explicit click
on canvas before their handle showed up on the canvas when activated with the
tool box or shortcut, which was not consistent with their activation through the
Tools menu, and with how some other tools worked.
As this change was requested, we decided to experiment with directly activating
the handles as soon as the tool is selected.
The “Floating selection” concept has been a huge topic across the years,
especially because it was quite unexpected by many people.
After discussing the matters, we came to the conclusion that we should
experiment limiting its usage.
Nevertheless we are also deeply aware that this feature can be a huge time saver
and a much better interface for some types of interaction. In particular, the
quick on-canvas copy|cut-paste with the Alt modifier (Ctrl-Alt to cut-paste or Shift-Alt to copy-paste) heavily relies on the floating selection to
extremely quickly move bits of a layer.
Obviously the explicit “Float” action (equivalent to a cut-paste) is in a
similar situation.
For pasting inside a layer mask, it is even mandatory because it allows to edit
the pasted data — e.g. positioning appropriately, transforming it… — before
actually merging into the mask which may already contain mask data. Note that if
some day, layers were allowed to contain several masks, this would not be
necessary anymore.
For this reason, the 3 cases where we still have floating items are:
when pasting into a layer mask;
when doing quick copy|cut-paste on canvas with the Alt modifiers;
when floating layers explicitly with the “Float” action.
There is still a case which we need to discuss as it also creates floating
selections: transform tools when there is a selection.
For other common types of data pasting, they will now create new layers directly.
As a side change, when the “floating selection” happens on a layer mask, we now
call it “floating mask” and shows it above the mask in the Layers dockable (it
used to be above the layer at all times). This should make this specific case
less confusing.
In the light of multi-layer selection, we have been wondering how the various
types copy-paste cases should work. In particular when copying several layers,
should you paste several layers or a merged copy? And when copying pieces
(through a selection) of several layers?
This is still a
work-in-progress
but we are trying to properly specify consistent and reasonable behavior for the
many sub-cases. In particular now, we always paste as many layers as was copied,
even when we copied from a selection (in which case, the new layers will be the
size of the selection bounding box).
For the merging case, we add 2 new actions called “Paste as Single Layer” and
“Paste as Single Layer in Place” in the Edit > Paste as submenu. As the
names imply, they paste the merged down version of your copied contents. It’s a
bit similar to “Copy Visible”, except that it only applies to the selected
layers and can be chosen at paste time.
GIMP now comes with a “Gray” theme based on a 18.42% luminance middle-gray
background, which should be a good neutral environment for professionnal color work.
Focusing on your artwork color with a middle-gray 18.42% luminance theme - GIMP 2.99.14
We now provide a theme-override icon size selection in Preferences > Themes
with conceptual sizes: small, medium, large and huge. The following widgets are
so far modified: toolbox icons, fg/bg editor in toolbox, foreground/background
editor in Colors dockable, dockables tab icons, bottom buttons (in the button
box) of dockables, header eye and lock icons above item trees, and eye and lock
icon switches in item tree cells.
Overriding theme-set icon sizes - GIMP 2.99.14
You may recall that we have a similar setting in GIMP 2.10 stable branch, which
was initially removed for GIMP 3.0, because our updated toolkit has high-density
display awareness and will already resize all the interface following your
“scale factor” settings (as set in your system).
Nevertheless we realized it was not enough. First of all, because this single
settings cannot take all special cases into consideration and some people still
wanted even bigger icons because they were watching their display from far away,
or simply prefered small icons, or any other reason.
This is the rationale for adding this override of icon size, thus bypassing the
system settings. As a nice aside, it will work with any theme. So you don’t have
to discard a theme you appreciate just because the chosen icons are not the size
you want.
Saving with RLE (default) and zlib (the “better but slower compression”
checkbox in the Save dialog) is now multi-threaded (following the settings in
Preferences), which makes it a lot faster.
In the best case scenario, we saw up to 70% save time (e.g. a 276-layer, 115MiB,
was reliably saved in about 50 seconds before, and 15 seconds after the change,
on the same test machine), though other tests would be around 1/3 save time
(another 180MiB XCF was saving in 1m30s before and 1min after the change on a
same machine). On any case, it’s a great news for people working on big images,
who hopefully won’t have to wait so long. Or even small images anyway!
This work was initially contributed by suzu_11 and further improved upon.
A further change in the XCF format, which warranted bumping the format version,
was that paths now have a proper structure in the XCF specification instead of
just being “properties” on images.
What it means especially is that the XCF format will now store locks and color
tags on paths, but also the path selection (whether several paths were selected
in their dockable). It will also make path items easier to evolve in the future
as we add new features, instead of being stuck on some old, outdated and
non-evolvable format.
As an aside, the XCF format specification had been stored inside the source
repository ever since 1997 (2006 in its detailed version). We moved the file to
the new developer website:
Documentation of the XCF file format .
It should make it easier to read, with markdown formatting and generated table
of contents.
This is a technical information which possibly only developers would understand:
the main process is now run as a GimpApp which is a new class derived from
GtkApplication. The main process of gimp-console on the other hand is a
GimpConsoleApp which is derived from GApplication. Both new classes share a same GimpCoreApp interface.
This is a main step for the GTK+3 port as it should allow us to work with
GMenu next.
Among other improvements, the PDF export now provides an option “Root layers
only” available when “Layers as pages” is checked.
Root layers only option in PDF export - GIMP 2.99.14
This option considers root layers only as PDF pages, and not their children,
which means you can more cleanly organize your PDF pages into layer groups.
We improved AVIF compatibility with Safari on iOS 16.0. Some AVIF images are
indeed rendered differently in Apple’s implementation compared to implementations
of Google and Mozilla (See upstream report).
This changes requires libheif 1.10.0 though the plug-in can still build with
older libheif.
export of CMYK(A) files added, with 8 or 16-bit precision per channel, using a
CMYK soft-proof profile for conversion.
Paths are now exported with PSD files.
Exporting PSD images as CMYK using the soft-proof profile - GIMP 2.99.14
As a reminder, proper CMYKPSD
import
was improved in GIMP 2.99.12, storing the CMYK profile from the PSD as
soft-proof profile, making round-trips easier (passing through a RGB conversion
in GIMP).
The TIFF format has a concept of “reduced page”. Until now, we were assuming
pages tagged as “reduced” to be thumbnails. Yet this is not always the case. For
instance we had feedbacks from makers of medical devices which were using
“reduced pages” as sub-sampled images generated by said devices. They needed
GIMP to be able to load all the pages as layers (the main images and the
sub-sampled ones).
Importing reduced pages of TIFF files - GIMP 2.99.14
This is why we added a new option called “Show reduced images” which lets you
decide whether you want to load these or not. The option will be checked by
default through a small heuristic: if there is only 1 reduced page and it’s in
the second position, then it’s probably a thumbnail (as per common usage across
software); in which case we disable the checkbox by default. Still in the end,
the choice is yours!
Several API improvements are present in this release:
We have a better GimpPickButton implementation for Windows, which should
work better than the existing implementation, thanks to Luca Bacci.
Text layers now have a dedicated class GimpTextLayer.
Various functions were added to get lists of selected items (as per 2.99
ability to select multiple items).
gimp_vectors_stroke_translate() now uses double offsets (instead of integer).
There is a new function gimp_text_layer_set_markup(), contributed by Ian
Munsie, which allows to set Pango
markup directly in text layers.
It is a powerful function because it allows to render texts even with features
not supported in the text tool GUI.
For instance, this is a text layer with a double underline and an overline
on “Hello“, “under” in subscript, and “2” in superscript all of which
are supported features in Pango, but not in our text tool GUI, as set
through the Python binding of our API:
As a note of interest, any styling unsupported by the GUI will be discarded
if you edit the text layer through the GUI.
Text layer styled with gimp_text_layer_set_markup() - GIMP 2.99.14
Though this release is not the most packed with API changes, a lot of background
work is in-progress and in particular Lloyd Konneker is very actively
participating to the work. We should hopefully see the result in the next
development release.
Let’s start with the one bad news (before going to the good ones): there seems
to be a major hover and click bug in GTK on macOS Ventura, the last version of
macOS released a few weeks ago. It basically makes all GTK+3 application
unusable, including GIMP. Every new release of this operating system seems to
bring its load of (bad) surprises! 😓
As of now, no solutions exist yet as GTK developers are still looking for the
cause. In any case, you may want to hold onto updating your OS if some GTK+3
applications (e.g. GIMP, Inkscape, Siril…) are a major part of your workflow.
The biggest news is that we now have a DMG package for Apple Silicon machines
(M1, M2…)! 🥳
Be careful, you should take this as an experimental 🥼 package of an
experimental 🧪 GIMP version. So issues are expected. As usual, we welcome
any issue
report you would get with GIMP
(on macOS or any other platform by the way).
The second big change on macOS land, less visible yet quite major as an
infrastructure change: Lukas ported the build to MacPorts away from the historical JHBuild scripts.
The main reason was that we could take advantage of the bigger “port”
maintaining community for our dependencies, instead of building everything
ourselves. This can be compared to using MSYS2 on Windows or the runtime
system of flatpak. This improves the build time, but also the maintenance load
as Lukas is still alone to maintain all this.
The drawbacks are that it makes it a bit harder to tweak dependencies when
needed (as usual when you rely on an upstream), but also that the DMG packages
are now bigger in file size. This is unfortunate, but considering that the
alternative might be to wear our macOS maintainer out and have no package at
all, we consider it to be worth it.
The “update check” — i.e. the ability to verify if new versions of GIMP were
released, i.e. that you are running outdated GIMP — was never working on macOS
because of the lack of HTTPS support for macOS in GIO, our backend library to
handle all input/output transparently.
Lukas Oberhuber implemented a work-around for this, based on a macOS system API
(no additional dependency), which we may backport later to GIO. Maybe macOS
will eventually have the ability to open HTTPS remote images at some point!
As told when releasing GIMP
2.99.12,
we entered an intensive testing phase for our meson build. We received useful
reports and feedbacks, which allowed us to get the meson build even closer to finalization.
This release might be the last one when we will provide both an autotools and
meson tarball for packagers. If all goes well, we may decide to phase out our
autotools build after GIMP 2.99.14, and only provide a meson tarball.
So if any packager finds any issue, please, now is the time to tell us about it!
This is the experimental version of what should become the libgimp 3.0 API. Of
course, it’s still a moving target, so you should not expect it to be stable
yet, up until we officially release GIMP 3.0. Still, plug-in developers are
welcome to experiment already in order to prepare their plug-in for the new
major version (several well known plug-ins already do have versions usable with
our 2.99 experimental API).
An API reference tarball is generated as part of the continuous integration
process and we now distribute them on our download
server for anyone who
prefers to read the documentation offline.
4 organizations contributed download
mirrors to
distribute GIMP.
Thanks to metanet.ch (Zürich, Switzerland), the Fremont Cabal Internet
Exchange (7 mirrors across the United States and Canada!), the LIP6,
Sorbonne université (Paris, France) and EdgeUno (Bogotá, Colombia; our
first mirror in South America, at least since the renewed mirror procedure!).
We remind that mirrors are important as they help the project by sharing the
load for dozens of thousands of daily downloads. Moreover by having mirrors
spread across the globe, we ensure that everyone can have fast download access
to GIMP.
31 people contributed to the main
repository for GIMP 2.99.14:
16 developers contributed to GIMP code base for this micro version:
1 developer with more than 100 commits: Jehan.
3 developers with 10 to 20 commits: Jacob Boerema, Nikc and Daniel Novomeský.
12 developers with less than 10 commits: Lukas Oberhuber, Hanabishi, Luca
Bacci, Øyvind Kolås, Gotam Gorabh, Ian Munsie, Michael Schumacher, Niels
De Graef, suzu_11, Hanabishi, Niels De Graef and lloyd konneker.
15 translations were updated: Basque, Catalan, Chinese (China), Galician,
Georgian, German, Hungarian, Icelandic, Polish, Portuguese, Russian,
Slovenian, Spanish, Swedish, Ukrainian.
17 translators contributed: Hugo Carvalho, Yuri Chornoivan, Martin, Zurab
Kargareteli, Sveinn í Felli, Alexandre Prokoudine, Anders Jonsson, Balázs Úr,
Jordi Mas, Boyuan Yang, Luming Zh, Rodrigo Lledó, Asier Sarasua Garmendia,
Fran Dieguez, Piotr Drąg, Balázs Meskó, Tim Sabsch.
1 person contributed to icons and themes: Jehan.
10 people contributed build-related updates: Jehan, Alx Sa, Hanabishi, Øyvind
Kolås, Daniel Novomeský, Ian Munsie, Luca Bacci, Lukas Oberhuber, Niels De
Graef, Thomas Klausner.
These are the stats on babl,
GEGL and
ctx repositories:
1 contributors to babl 0.1.98 with 5 commits: Øyvind Kolås
12 contributors to GEGL 0.4.40:
4 code contributors: Øyvind Kolås, Jehan, Sam James, nikita.
8 translators: Marco Ciampa, Asier Sarasua Garmendia, Enrico Nicoletto,
Fran Dieguez, Jordi Mas, Luming Zh, Matheus Barbosa, Sabri Ünal.
ctx doesn’t have releases per-se as it is project-embedded code.
In the time frame between GIMP 2.99.12 and 2.99.14, there were 247 commits by
1 contributor: Øyvind Kolås.
On the documentation
repository, in the GIMP 2.99.12 to
2.99.14 timeframe, 5 people contributed:
Main contributor on documentation and script with 57 commits: Jacob Boerema.
1 additional contributor on documentation: Tim Sabsch.
4 translators: Tim Sabsch, Andre Klapper, Hugo Carvalho, Rodrigo Lledó.
On the main website
repository, in the GIMP
2.99.12 to 2.99.14 timeframe, 1 contributor contributed 89 commits: Jehan.
On the macOS build
repository, in the
GIMP 2.99.12 to 2.99.14 timeframe, 1 contributor contributed 43 commits: Lukas Oberhuber.
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting and manual tweaking, errors may
slip inside these stats. Feel free to tell us if we missed or
mis-categorized some contributors or contributions because we try to
acknowledge every contributor for being a part of GIMP!
With this release, we are really approaching GIMP 3.0 release, as can be seen
from the roadmap of 3.0
where most items are “nearly done” or “done”. We are clearly reaching this part
of development when we start targetting specific pain points, which means a lot.
Nice milestones in this release:
we now have all themes we absolutely needed (neutral dark, light and
middle-gray themes);
macOS builds are getting on-par with other builds;
usability is being finalized, after the multi-item selection really changed
the whole paradigm of how GIMP interacts with layers changed;
the space invasion project is currently running strong. Even though this
release doesn’t show as much consequences of it yet as we hoped, the next
release should;
developer documentation, for onboarding of new contributors, is finally
getting somewhere.
Don’t forget you can donate and personally fund GIMP
developers, as a way to
give back and accelerate the development of GIMP.
Community commitment helps the project to grow stronger! 💪🥳
Next Friday, the 4th of November 2022, from 6PM to 8PMCET, Aryeom (with her
hats of film director of “ZeMarmot” and GIMP
contributor) and myself (Jehan, with my hats of main developer/maintainer of
GIMP and technical operations in “ZeMarmot”), will host a conference at the
Jules Verne library in Vandœuvre-lès-Nancy (France).
Poster for the talk “GIMP and ZeMarmot” of 4 November 2022 in Vandœuvre-lès-Nancy
Location
Médiathèque Jules Verne
2 rue de Malines
54500 Vandoeuvre-lès-Nancy
France
+33 (0)3 83 54 85 53
Time
Friday, November 4, 2022 - from 6PM to 8PM (CET, French time)
The event is organized by a public body whose name could be translated as
something like “the Collective Factory of the Libre
Culture” (FCCL), which is a cool name, right? It’s rare enough
to have public institutions funded by a city (in this case: Vandœuvre-lès-Nancy)
encouraging Free Software usage, and this is why we accepted their invitation.
As far as we know, ever since the global health crisis, it will be the first
physical conference with contributors of GIMP.
Quite strange to prepare talks again after 3 years! 🥲
We will obviously talk about GIMP and how it is developed as a community,
since the concept of “Community, Free Software” is dear to me. We will also talk
about “ZeMarmot“, the Free/Libre Animation Film
produced by the non-profit LILA which
crowd-funds our work (for the movie and GIMP
development). So it will be the opportunity to discuss about various interesting
topics, based on our concrete experience of running FLOSS and Libre Art projects.
So if you are in France around Vandœuvre-lès-Nancy on November 4, we hope we’ll
see you there. 🤗 Otherwise, I am told that the talk will be streamed
live 🖥️ (in French of course).
As the name indicates, it is targetted at developers, both core contributors
(people making GIMP itself) and third-party developers (people
making plug-ins and publishing them on the side). This is why the website
has 2 main sections:
Core: for core developers, with roadmaps,
information on how to build GIMP, coding style guidelines…
Resources: for third-party developers,
with links to the public libgimpAPI, tutorials to make plug-ins…
We call this section “Resources” as in the future, it may also contain info
on how to make brushes or other data for GIMP.
GIMP has had a developer website for at least 2
decades (the Internet Archive traces back an early page in 2001), yet mostly
unmaintained ever since 2009, which is a shame.
Since then, documentation for developers was scattered on the general
website, the source repository itself and 2 wikis
(developer and GUI wiki). As you may know, the developer wiki encountered
problems
recently. As for the GUI wiki, it is still there, though we plan to merge both
wikis into our new developer website.
Rather than having duplicate documents all over the place, we want to
consolidate developer documentation into a single point of entry.
This new website is still a work-in-progress. Contents is still incomplete and
often outdated. We decided to publish it in its current state and update it as
we go, rather than wait forever.
As usual, we stick to only serving static pages, no server-side scripting. It’s
simpler and safer as we don’t want to spend our time administering a webpage (we
develop GIMP, not webpages).
What has been done so far:
We ported the website from DockBook to Hugo, especially
thanks to Robin Swift, with help from Pat David. It has a few advantages:
The markdown syntax is less powerful yet so far sufficient and simpler
that DockBook XML. It should facilitate
contributions.
Hugo websites are easier to build and test, with nice immediate feedback
loop when using the hugo webserver during development.
Hugo has a nice organization where file structure also decides of the
website structure.
Contents was reorganized, reviewed, partially rewritten or merged. Some
outdated documents were kept for historical interest, yet may not be as
relevant for modern GIMP usage.
We identified 2 main sections — as explained above: Core and Resources —
with an additional Conferences section where we mostly keep track of
historical meetings where developers made some decisions on the future of
GIMP. We try to organize documents in these sections and subsections when relevant.
We progressively improve automatization of the website publishing, for
instance automatic grab of the newest libgimp library documentation, and
early error detection.
We created a testing website to validate changes before publishing to the main
website (similar as what we do for gimp.org). Both websites will be
automatically published daily from their own branch and can be triggered
manually through Continuous Integration jobs on Gitlab.
All documents from the old developer website were salvaged, ported to
markdown, reorganized or discarded after examination.
Several development-related documents from the main gimp.org website were
moved to developer.gimp.org or merged into others. For instance, we had
redundant pages about contributing code for GIMP. There is now (unless we
missed some) only a single tutorial:
Submit your first patch.
Dozens of the old wiki documents were ported to markdown and moved or
discarded after examination. In particular, some of the most requested pages
have a home again:
Some documents from the main source repository of GIMP were moved. An
important document is the GIMP Coding Style
guide.
Redirections were created, because “Cool URIs don’t
change” and links to moved pages can
be found in many third-party websites. For instance old links on the roadmap
(which used to be at
wiki.gimp.org/wiki/Roadmap) now
redirect to the new roadmap.
More documents need to move, be rewritten or fixed. This is only a start.
Also the website style is currently pretty simple and bare. On one hand, maybe
it’s not too bad for a development website. On the other hand, discussions have
happened proposing to make the website look a little more lively and less
austere 🧐. We’ll see!
We strive for a lively third-party plug-in ecosystem. For this to happen, we
want to help third-party developers. There are a lot of documentation and
tutorials about plug-in developement, but they are spread across the web, many
links are dead, a good part of the documents are unmaintained and therefore
partly outdated.
This new website doesn’t bring much yet on this side, though by making
plug-in development one of the 2 main sections, we clearly intend to change this
fact for the upcoming GIMP 3.0. You should not expect new tutorials for GIMP
2.10 plug-in development, but this is definitely where you should keep an eye on
if you are interested by plug-in creation for GIMP 3.0: Resources section of
GIMP’s developer website
As usual, we remind that GIMP is Community, Free and Libre Software. It is what
we all make of it, together. This is a main reason of such a developer website.
Hopefully you will find it useful. If not, don’t remember that the website
itself is community-made. So feel free to propose developer tutorials and fixes
or updates to existing ones.
Last but not least, if GIMP is useful to you and you wish to fund
development, you are very welcome to donate to the project and fund core
GIMP developers, as a way to give back
and accelerate the development of GIMP.
GIMP 2.99.12 is a huge milestone towards GIMP 3.0. Many of the missing
pieces are getting together, even though it is still a work in progress.
As usual, issues are expected and in particular in this release which
got important updates in major areas, such as canvas interaction
code, scripts, but also theming…
“CMYK space invasion”, by Jehan (based on GPLv3 code screencast), Creative Commons by-sa 4.0 - GIMP 2.99.12
There were requests for quickly changing tool settings, such as brush
size or tool opacity, without having to go to the “Tool Options” dockable
A quickly appearing on-canvas GUI was considered (similar to other
software), though we realized that many people who want this prefer a
non workflow-disruptive interaction.
This is why we went for a simpler and direct design. For instance, now
Alt + right click will trigger a brush resize action on canvas.
Changing brush size with Alt + right click - GIMP 2.99.12
Note that this code area still is a work-in-progress. There are more
interactions still worked on, such as opacity update and customizability
(see next section).
Many features are available on-canvas, some of them less known than
others, for panning, zooming, rotating the canvas (since GIMP
2.10.0)
or even selecting layers through canvas (since GIMP
2.10.10).
Note: on macOS, Cmd is used in place of Ctrl. This is usually
implied when Ctrl only is mentioned.
These are based on the following logic:
The main button is reserved for tools. Even though some of them
share similar logic (e.g. all the selection tools share modifiers to
add, subtract or intersect selections), some tools will have specific
use cases.
The secondary button is used for “navigation”, in particular canvas
navigation, but even on some kind of z axis with layer navigation
(recent Layer picking ability since GIMP 2.10.10).
The third button was always reserved for contextual menu only. The new
brush resizing ability breaks this tradition.
As we added new features, it became obvious that we were eventually
going to lack modifiers for other useful actions. Also everyone is
unique and has their own preferred workflow, so some people would
definitely wish to have slightly different action behavior.
As an example, even the just implemented brush
sizing already comes in 2 variants (resize
from center or sides).
Not to mention we had feedbacks of people disliking unexpected canvas
changes, for instance because they hit Shift too early and a canvas
rotation happens (admittedly not everyone cares about having canvas
rotation in their workflow).
Moreover some legacy actions, such as the contextual menu, can be
questionable nowadays (especially as it is the same menu available
at the top of the window).
This is why the canvas interaction code got factorized to use
customizable modifiers rather than hard-coded. The table above is still
the default, but now you may customize it: add more actions and
modifiers, remove some or change them all. The settings are in
Preferences > Canvas Interaction > Modifiers, then click on the button
labelled “Click here to set a button’s modifiers” with any mouse or
stylus button to start customize its modifiers.
You can even add “custom actions“, i.e. anything to which you could
assign a shortcut. Want to swap the foreground/background color on
right click? Now you can. Want to activate the Unified Transform tool with Shift-middle click and remove canvas rotation? You can too.
Remapping Shift+middle click to select the Unified Transform tool
and removing Shift-Ctrl + middle click mapping - GIMP 2.99.12
Not only this, but it should work with any button (not only the second
and third). So if you have a mouse with 20 buttons, you could map every
one of them to an action (as well as any combination with modifiers).
Furthermore it will recognize different input devices, so that you can
map different actions to the same button of several plugged mice or
styli (note that it doesn’t recognize yet different device of the exact
same model, but eventually it probably will).
⚠️ If you experience bugs in any canvas interaction, this is a good time
to report them because a lot of code updates happened to make the code
more generic so early-tester bugs are expected.
A new settings is available in Preferences > Canvas Interaction to
customize the zoom behavior, when zooming with Ctrl + middle click or
Ctrl-Space.
The legacy algorithm would zoom, in or out, continuously as long as there is
movement. It doesn’t depend on the movement span, which is why we called
it the “By duration” drag-to-zoom behavior.
The new behavior is the “By distance” drag-to-zoom as it will zoom more
if you do large moves, or in a more fine-grained way with very short
moves. We left both behaviors available as a settings because after user
testing, we decided that some people may prefer the old behavior, though
the newly proposed one also made sense.
Finally the “Drag-to-zoom speed” allows you to set the speed rate at
which the zoom will happen, in percentage of the default (i.e. that 100
is the default speed; you can raise or lower it).
In Preferences > Input Devices, you will first discover that some
settings have been moved around. In particular, pointer-related settings
have been moved from “Image Windows” to “Input Devices” tab and reorganized.
The second improvement is that the settings behavior have been rethought:
Now when “Show brush outline” is checked and “Show pointer for
paint tools” is unchecked, if the brush outline cannot be drawn (for
instance because you use a dynamics changing the size with pressure),
GIMP will display a fallback 4-arcs generic outline showing the set
size (it used to show a crosshair which made no sense, as “Show
pointer” was explicitly unchecked).
When both “Show brush outline” and “Show pointer for paint tools”
are unchecked, we show a minimal visual feedback of a few pixels only,
as inconspicuous as possible, instead of a crosshair. Once again,
people are explicitly asking for nothing, so showing a crosshair felt
counter-productive. Yet actually showing nothing at all would be
confusing too. Even with tablet displays, the parallax issue is
unfortunately very real. This is why we opted for an extremely small
point-like cursor. It still shows your exact position with few disturbance.
The point-like cursor was originally contributed by L Amander, then
modified by Aryeom who made it visible on both dark and light
background, and the new pointer was adapted into existing settings
instead of creating a dedicated setting.
⚠️ This point-like cursor feature is really adapted for tablet displays
and may seem very hard to use and frustrating for any other usage
(nearly invisible pointer).
Drawing with point-like cursor: 🔎 can you see the pointer? 🔬 - GIMP 2.99.12
Improving again the “Fill by line art detection” of Bucket Fill tool¶
The “Fill by line art detection” mode of the Bucket Fill tool is a big
question for us as we are regularly tweaking the
options
to improve usability.
The idea is how to make the settings easier to understand while not
losing the very advanced capacity of the tool.
Therefore we tried something new, reorganizing the options in 3
categories which correspond to the 3 main steps of the line art algorithm:
Line Art Detection: the settings which configure how the line art
is detected: which source is being used? Using opacity or grayscale?
Which threshold?
Line Art Closure: the settings for the closure algorithm of
opened line art areas.
Fill Borders: the settings for borders of the fill: how much
should we grow under the detected line art? How to get nicer borders?
3 steps in the line art algorighm: (1) line detection, (2) line closure, (3) border style - GIMP 2.99.12
Also we add an “Automatic closure” checkbox which is equivalent to
setting the “Maximum gap length” to zero, and simply means we don’t
want any smart closure by an algorithm. It is more understandable this
way while making easier to switch between smart and no closure.
As a parallel, the option “Allow closing lines in selected layer” was
renamed “Manual closure in fill layer“.
Finally we added a “Stroke borders” which works similarly as the
“Stroke Path” or “Stroke Selection” features and which can be
useful, in particular for visible borders of unclosed areas.
More iterations may happen to improve usability of this very nice tool
as we progress towards GIMP 3.0.
In GIMP, we represent transparency in an image through the very common
“checkerboard” pattern. In order to handle various use cases, we were
proposing a series of colors, from light to dark grays, and even
proposing white, gray or black only backgrounds. Though all these had
the shared characteristics of being shades of gray.
Preferences > Display > Transparency > Check style has now a new
option “Custom checks” allowing to select any RGB colors for the 2
colors representing “transparency”. If you wish to show transparency
with rainbow 🌈 colors, this is up to you!
The new function gimp_checks_get_colors() has been added to the
interface for plug-ins, replacing gimp_checks_get_shades(). This would
allow any plug-in needing to render transparency checkerboard according
to user choice.
This was originally contributed by Ben Rogalski, then improved, in
particular for proper API and plug-in support.
Remember the “Welcome
dialog”
which you get after an update (you probably got one in GIMP 2.99.12)? We
worked a bit on the “Release Note” tab to allow for “demo” items. I.e. now
some items (spotted with a different bullet point) will play a short
scenario showing what a new feature refer to.
This is still a work-in-progress which doesn’t work for all types of
features, and the styling for demo “playback” can definitely be
improved. This is what it looks like right now:
Double-clicking demo items in release notes of Welcome dialog - GIMP 2.99.12
It was already possible to zoom the canvas with pinch
gesture
since GIMP 2.99.6.
It is now also possible to rotate the canvas with a pinch gesture. Note
that we made the choice to make zoom and rotation through pinch
exclusive, i.e. that the first detected movement will lock on the
gesture to either zoom or rotation, not both at the same time. It seemed
to us that people might find it annoying to rotate when you just want to
zoom (or the other way around).
Furthermore you can now zoom the preview images in item dockables
(Layers, Channels, Paths) with pinching or mouse wheel.
Finally you can zoom in the Gradients dockable by pinch gesture too.
All of these were contributed by Povilas Kanapickas, who had already
implemented zoom through pinch gesture on canvas.
This one deserved a section on its own in this news report because
thanks to our new GSoC
student,
things moved quite fast here, not only for CMYK, but for the color space
invasion project as a whole. We
had to re-think a lot of the color conversions and display in various
parts of the program.
The main usage of “simulation” is soft-proofing, a very common use case
being printing. E.g. you could work in a RGB space, but know the final
format (e.g. through a profile given to you by a printshop, often a CMYK
profile) and want to see how your image would render, in particular
regarding gamut loss.
It was already possible to set a “Soft proof profile“, as well as a
rendering intent, and whether you wanted black point compensation or
not. Yet this info was lost at each session restart.
These data will now be stored within the XCF file itself. So you won’t
need to re-set them each time. Indeed if you work on a print job, the
final target can be considered part of your workflow for this specific
print job, hence part of the image.
As a consequence, these 3 information (soft proof profile, soft proof
rendering intent and soft proof black point compensation) moved from the
View > Color Management menu to the Image > Color Management menu (though View > Color management still contains some settings, such as
whether to enable color management and whether or not to soft-proof;
these are not image data but specific to a view: a same image can be
simultaneously displayed in several views, one proofed and the other
not, for instance).
To make simulation a first-class citizen in your workflow, we wanted a
way to make it obvious when you are viewing a proofed image or not.
This is done through a new icon at the right of the status bar. This
icon has 3 purposes:
It visually shows whether we are in simulation (a.k.a. soft-proofing)
mode or not.
It allows to switch from simulation to non-simulated modes by clicking
on it.
It allows to customize simulation settings (simulation profile,
simulation rendering intent, black point compensation…) with a pop-up
dialog by right-clicking.
Quickly enabling soft-proofing, clicking a toggle on status bar; or changing soft-proofing settings, right-clicking the same toggle (here showing a CC by-sa character design on canvas, by Aryeom) - GIMP 2.99.12
Most GUIs which were displaying CMYK data were displaying “naive CMYK”
colors. It is some generic algorithm not taking into account a specific
CMYK color space.
Now if you set a simulation profile, and if this profile is a CMYK one,
then these interface will display CMYK colors for this space, assuming
that this is what you are interested in.
This includes interfaces such as the Color Picker tool, Sample Points,
and the CMYK color selector.
Similarly, several supported image formats have now new or improved CMYK
support. We are not talking about having core CMYK support as backend
encoding; GIMP is still only working in either *RGB, grayscale or
indexed. Yet, you can now better import or export CMYK images in several
formats, with much more suitable conversion done. In particular, it
means that:
The CMYK profile of imported CMYK images will be stored as a
simulation profile. I.e. that the image will now be RGB, yet the CMYK
profile will be kept for simulation.
RGB images can be exported as CMYK, using the simulation profile (if a
CMYK one) for conversion, then stored in the resulting CMYK file.
The assumption is always that the simulation profile is your target
color space.
The updated formats so far are:
JPEG:
CMYK export now possible using the image Soft-proofing profile.
CMYK import ported to GEGL/babl conversion. The CMYK profile in
the JPEG image will be stored as soft-proof profile on the image.
TIFF:
8 and 16-bit CMYK(A) export now possible, using the image
Soft-proofing profile.
CMYK import now possible. The CMYK profile in the TIFF image will
be stored as Soft-proofing profile on the image.
PSD:
CMYK import ported to GEGL/babl conversion. The CMYK profile in
the PSD image will be stored as soft-proof profile on the image.
Plug-ins can now request or set the soft-proofing profile of an image
with new functions, such as gimp_image_get_simulation_profile() or
gimp_image_set_simulation_profile() respectively. This is really a new
image data which can and should be used by plug-ins when they want to
display or process CMYK colors in the context of the active image.
Similarly several libgimpwidgets widgets (GimpColorNotebook,
GimpColorSelection and GimpColorSelector) became simulation-aware
with new dedicated functions to set the simulation space of interest.
GTK got a new CSS-like theming system in GTK+ 3, which means our 2.10
themes were not reusable and which is why we called for theme designers
many times because a graphics application should really have a good set
of neutral gray themes for an interface with the less color pollution
possible, as it can affect your color perception.
It is only a month ago that we got a first proposal for a mid-gray
neutral theme, though this one is still a work-in-progress. On the other
hand, it triggered our long-term contributor, Akkana
Peck, to propose a Light theme. With quick
back-and-forth exchanges, this one was rapidly completed and merged into
the source tree. Nikc helped also a lot by finding solutions to annoying
bugs where we were stuck.
In the end, we made the theme more generic, making colors into variables
with semantic names, and reused the same style code yet different colors
to make a dark theme.
Instead of having 2 themes, we merged these into a “Default” theme with
both a light and dark variants which will be switched depending on the
“Use dark theme variant if available” checkbox.
For this to work, we also made a new process for theme makers, based on
generic GTK process, which is that your theme can contain a
gimp-dark.css file (additional to the main gimp.css). This secondary
file will be used instead of the first when the “Use dark theme variant
if available” option is checked in Preferences.
New Default theme in light and dark variants - GIMP 2.99.12
Additionally to the new CMYK support on import, our PSD support got the
following improvements:
Improved error logging during load.
Added support for extra layer mask: according to the specifications
the extra mask is used “when both a user mask and a vector mask are
present“.
We haven’t seen an example that has the extra mask, so not sure
which of the masks would appear first.
For now assuming that the extra mask will be first. The advantage
of adding this here now, is that we won’t try to add a mask
channel as a normal channel.
Minimal support of duotone data: on import, a duotone image will
be imported as grayscale image with an alert and the color
information will be stored in a parasite; on export, a dialog will
propose you to re-include the duotone data if the image is still
grayscale. This allows for a roundtrip in GIMP without losing the
duotone information.
New dialogs when importing (left) then re-exporting (right) a PSD duotone image - GIMP 2.99.12
Some valid SVG can fail to import when they contain some huge data (of
various types). This is not a limitation of the parser but a security
limitations, because malicious SVG files can be created on purpose to
consume too much memory.
Nevetheless this can still happen on valid and non-malicious files, as
some users encounter issues with SVG files exported by Sweet Home 3D (a
nice Free Software for drawing interior design plans). Hence when
failure to load a SVG occurs, GIMP will propose to try again with the
security limitation removed.
Dialog to disable safety limit on failed SVG import - GIMP 2.99.12
🛈 Note that GIMP doesn’t have the information whether the load failure
happened because of this specific issue or not, so if the reason was
other, even retrying without security limitation may still fail.
⚠️ Also very IMPORTANT: as explained, this was a safety measure, which
implies that disabling it has security implications. You should only
accept disabling it to load SVG files from trusted sources, as the
pop-up also reminds. ☢️
A new option appeared in the GIF export dialog: “Number of repeats“.
It specifies a specific number of repeat for loop animation. Previously
you only had the choice of single run animation versus infinite loop.
GIF export dialog with new option “Number of repeats” - GIMP 2.99.12
The following changes happened in our PNG support:
The format does not have any flag for linear RGB, but it can simply
include a linear profile (or a 1.0 gAMA chunk). Therefore since we
always attach the profile when importing (or transforming the gAMA
chunk into a profile), we now always load PNG images as non-linear backend.
When exporting indexed images, a new checkbox “Optimize for smallest
possible palette size“, if enabled, will export a PNG file with
lowest bit-depth palette possible (less than an 8-bit palette with 256
entries, if possible).
🛈 We are talking here of “raw data” where you export your pixels as
contiguous or planar data directly, without following a specific file
format, and not RAW file formats as are usually called formats used by
digital cameras (for these, we still prefer to pass through good raw
developer software, such as darktable or RawTherapee).
A big rewriting of the Raw Data dialog (and API) organization happened.
First, it is now possible to export any bit depth as raw data (despite
the higher bit depth support, exporting 16 or 32-bit images used to
still export them 8-bit raw data). This part will also be available in
future stable version GIMP 2.10.34.
And especially all exportable formats can be loaded back, and more. As
it made for a huge list, the way the import dialog used to list formats,
we split settings. Data type (unsigned or signed integer, floating
point), endianness or planar configuration (contiguous or planar) are
now their own settings and code has been generalized to support each and
every combination. The “Pixel format” list is now only about the
layout for various components.
Raw data import dialog with more settings and much more support formats - GIMP 2.99.12
As a consequence GIMP now supports a lot more raw data formats, while
keeping a usable dialog, without showing a never-ending list of formats.
The PDBAPI for this plug-in has also been improved to follow the same
scheme of separate arguments.
As a last change, the HGT format (supported since the stable version GIMP
2.10.0)
is sharing the same codebase so we used to pop the raw data dialog up.
Nevertheless we have all the relevant information for a properly formed
HGT file, so we now load these directly without dialog (unless we fail
to detect the proper sample spacing).
GIMP now has import and export support for the ANI animated mouse
cursor format.
The export dialog allows you to set hot-spot coordinates for each image
in the animation.
Hot-spot coordinates from imported ANI files are stored as parasite in
the XCF to be reused as a default when re-exporting.
Export dialog of ANI format with cursor name, author, animation delay and hot-spot settings (CC by-sa illustration, shown in-dialog, by Aryeom) - GIMP 2.99.12
Lloyd Konneker, our new Script-fu maintainer, really did take his new
responsibility to heart as Script-fu code has not seen such activity for
years now.
A lot of bugs were fixed, more documentation for Script-fu developers
was written, but also huge changes happened.
Script-fu used to be a very monolithic extension plug-in (i.e. a plug-in
running permanently in background), with all its features in one binary,
which had several drawbacks. One of them is that the Script-fu server (script-fu-server), which allows to communicate with GIMP remotely,
would also be running in the same process.
It can be considered a security hazard, which is why it was made its own
plug-in, which can be run independently, on request only.
GIMP now installs a gimp-script-fu-interpreter-3.0 binary which will
run the Script-fu scripts. It has huge advantages:
Script-fu scripts are finally proper plug-ins. They are installed
within the plug-ins/ folder (not in scripts/ anymore), and work
the same way as other bindings.
Note that Script-fu is not a GObject-Introspected binding, unlike
other bindings, and it has its own way to wrap the PDB protocol or
libgimp* libraries, but other than this, it became now much closer conceptually.
It makes the Script-fu infrastructure much more robust as a single
crashing script will not crash the whole Script-fu altogether. Every
Script-fu plug-in now runs in its own dedicated and independant process.
Since a lot happened on the main libgimp*API, Script-fu specific API
had not been able to follow up. We are now trying to fill that gap and
to get Script-fu much closer to the main interface.
Among these changes, the new function script-fu-register-filter is
used to declare PDB procedure of the C class GimpImageProcedure. It
will also allow to much more easily use the procedural dialog generation
through the GimpProcedureDialog class.
A lot of discussions also happened on the topic of argument handling for
various types. This is still a work-in-progress as we are trying to
improve some use cases, for instance handling of plug-in’s specific
lists of options.
The Application Programming Interface for plug-in developer received
various improvements and changes within this iteration.
Of course, we have many new functions corresponding to new features in
GIMP, such as for the simulation color management, customizable
checkerboard colors and more. See the
list.
A new gimp_image_metadata_save_filter() also appears, as an
alternative to gimp_image_metadata_save_finish() when you want to save
metadata yourself and you need only filtering processing.
It returns filtered metadata allowing the caller to save the finalized
metadata via other means (via native format’s library for example). This
API can be used to support metadata saving of image formats not directly
supported by gexiv2/exiv2. We already use it for the HEIF/AVIF plug-in.
We also finally got rid of various functions assuming that an image only
had a single active layer or channel. We know this is not true anymore
in GIMP 3.0, with multi-item
selection.
Among the many other changes, one of the most important changes in this
updated API is how we handle plug-in localization. While the translation
of most strings were left to the plug-in’s discretion, the strings at
register time (plug-in title, documentation…) were translated by the
core, e.g. when used in menus or in the PDB browser, using gettext
catalog given at registration time. This raised various issues, such as
what happens if several plug-ins were to register a catalog with the
same name (which could have been fixed, with even more complicated
internal logic)? Or what happens if a plug-in doesn’t register a
localization catalog, but the default catalog contains (wrong)
translations for submitted strings? Moreover it ended up to be quite
confusing as many plug-in developers were wondering what is translated
where, i.e. if a string should be surrounded by _() (common gettext
macro) or N_() (noop gettext macro).
So the new logic is much simpler: translation is now left entirely at
the plug-in discretion, i.e. all strings received by the core are
assumed to be in the correct target language. The core doesn’t try to
translate anything coming from plug-ins anymore.
Now to help a bit with localization, our infrastructure proposes a
standard file organization, with all gettext catalogs under the
locale/ folder of the plug-in directory, and named the same way as the
plug-in itself. If the catalog is absent, our system outputs a message on stderr to inform of this standard procedure. A plug-in following
this procedure won’t have anything else to do than place the compiled
gettext catalogs (*.mo files) with the right domain name in the right folder.
A GimpPlugIn can supplant this behavior at any time by overriding the
set_i18n() method, to either disable localization altogether, pointing
to a different catalog path and name or even use another system than gettext.
The only remnant of the old logic, which we need to think about and
improve, is the localization of menu paths, as we still want
core-localization of some base menu paths. E.g. the root menus (“Edit”,
“Image”, “Colors”, “Filters”…) but also some submenus (“Blur”,
“Enhance”, “Distorts”…) should still be localized by the core while
plug-ins will need to handle new parts in the menu path. This is the
only exception to the new “no core translation” logic for plug-in.
A new libgimp class GimpBatchProcedure was added, facilitating the
creation of batch interpreter plug-ins, i.e. plug-ins meant to be run
from command line to process a series of procedure calls. Currently 2
such interpreters exist in GIMP: the Script-fu (plug-in-script-fu-eval) and the Python (python-fu-eval) interpreters.
Running code this way is done with the --batchCLI option. Historically Script-fu was used as
default, but this is not the case anymore. Now you must explicitly
specify an interpreter with --batch-interpreter.
Moreover a new option --quit was created and this is what you must use
if you wish to exit GIMP immediately after the scripts are run. Do not call "(gimp-quit 1)" anymore. A nice improvement is that GIMP will now
exit immediately after a batch failure (i.e. if you had a series of
--batch calls, it will stop at the first failure) and will propagate
the failure into the process exit code.
Exit codes are inspired from command Linux error codes: 0 for success,
69 for service unavailable (e.g. setting a non-existing interpreter
name), 64 for usage (e.g. not specifying any interpreter or calling
errors), 70 for execution errors (bugs in the interpreter plug-in) and
130 for canceling the call. Therefore you will now know when your
scripts fail.
As an example of batch processing, here is how you could load a PNG
image, then export it back as JPEG:
GIMP build system traditionally uses GNU autotools. An initial, yet
incomplete, port to the newer meson system was contributed in 2017 by
Félix Piédallu.
It took a few years to complete the last customizations, tweaking meson
scripts to be able to handle all the special cases we had in GIMP code.
As we approached completion in this development cycle, we started to
officially recommend meson for Windows, then macOS, and finally, early
August, we decided to recommend meson for all platforms.
This is still an evaluation phase for this build system, though now we
are moving forward into intensive testing. If you are a packager,
please try to now use our meson build and report any issue to us.
Exceptionally for this version, we released 2 tarballs on our download
server:
gimp-2.99.12.tar.xz and gimp-2.99.12-autotools.tar.bz2. As you can
guess, the former is the meson-generated tarball, yet we left an
autotools-generated tarball as fallback if the meson tarball end up
having major issues.
The
INSTALL
file was rewritten as well with meson instructions.
Of course, all our own packages (flatpak for Linux, installer for
Windows and DMG for macOS) are now built with meson.
As many other projects, GIMP was using the intltool project to extract
localizable strings and translate various files with gettext, not only code.
Since about 2016, upstream gettext gained the ability to extract
strings for more types of files and formats, projects were encouraged
to move on and the intltool project was progressively abandoned. But GIMP was still
using it for various types of files (XML, desktop files, Inno Setup
translation files and more…) so the workfield was not small.
Well no more as Niels De Graef finally took care of this port and got
rid of this technical debt! 🥳
Of course, it triggered various problems, even to release day as we
realized when testing installers that some buttons were broken (which is
one of the few reasons why this news is out days after the actual source
release) and we had to fix the strings. Hopefully this was the last
related issue!
Wayland issues are slowly yet surely being getting rid of. Some of the
issues we had just disappeared with more recent versions of some Wayland
compositors. We do hope more bugs in upstream compositors will be fixed
eventually because some serious issues are still puzzling us (such as
crashes of some GTK applications, GIMP included, on the Sway Wayland compositor).
Some other issues have been handled in our code.
One of them is that early testers may have noticed a very annoying popup
telling you that “gimp-2.99 wants to inhibit shortcuts” (at least on
Mutter, the Wayland compositor of GNOME) in former 2.99 versions.
This got fixed by removing various keyboard grabbing code which was not
necessary anymore with GTK+3.0.
Some issues still remain, based on the early state of Wayland in
general, in particular because it doesn’t have color management. We were
often advised to use the “portals” for various features, such as color
picking, which unfortunately do not return us color-managed colors (as a
side issue, some desktop — such as Cinnamon and Mate — simply are
missing implementation for the color picking portal even though the
portal exists, which confuses GIMP). This is a regression problem
because we were getting wrong colors (slightly wrong, or even very wrong
if you use a wide gamut display) even when one were still running on
X11. Therefore now we will favour the X11 implementation for color
picking when you are running on X11 and will use the portals only
on Wayland. We may go back to portals for everyone on Linux when they
return managed colors.
Meanwhile, we are in discussions with Freedesktop portal developers to
get a new color-picking portal API, which will eventually have to be
implemented for the various desktops. Let’s hope it happens sooner
rather than later! 😅
As usual, a lot of maintenance work was done by Lukas
Oberhuber.
Packaging work is not as visible, hence is quite often thankless, which
should be fixed: thanks Lukas as well as every other packager!
Apart from this, you may remember the slowness issues happening on newer
macOS versions (ever since Big Sur). We had some custom patches already
for GTK and some dirty trick in GIMP code itself since GIMP
2.99.10.
It all led to various improvements in GTK code which took over the
previous patches. It took months of testing, several code proposals
in several directions (at least 3 different merge requests, possibly
more code was discarded) and it got to a very satisfying result as Lukas
confirmed it is much faster now and GIMP is totally usable. Our in-GIMP
dirty tricks could also be removed.
For all these improvements, we want to thank in particular John Ralls
who provided the final fixes and Christian Hergert for his constant
inputs. Of course, we should not forget the numerous other contributors
who stopped by to help and give useful inputs. Hopefully GTK on macOS
will continue to improve even more!
In any case, this is great news for all other multi-platform GTK
software, though no GTK+3 release contains these fixes yet. It will be
available in GTK+ 3.24.35.
We include a patch on Cairo (again by John Ralls) as well for improved
performance on macOS, though the gained performance was not as obvious
as the GTK fix.
Also additionally to the development releases, we now provide nightly
builds for macOS. Check the section “Automatic development builds” of
the Development download page
for a procedure.
⚠️ As usual, we remind that nightly builds means that it’s even more
experimental than development builds: these packages happen at random
point in the development process and the builds are not even
human-tested. ☢
In any case, a lot has happened since the days, not so long ago, when we
were despairing at the sad state of GIMP on
macOS,
with slowness (to the point of being unusable) and interface issues. Now
we are finally getting to a point where we can hope GIMP 3.0 will be
great on macOS, though we are still very short on contributors for this
OS. We welcome any developer wanting to join us!
Last point for people waiting for M1 builds: some work has been done in
this direction, but we are mostly blocked by CI hardware limitations.
We’ll keep you updated on improvements for this topic obviously.
For people who have a M1 Mac and are willing to build locally, there are
build scripts,
in the gimp-macos-build repository
though starting from the README
might be ideal.
Note that Lukas is already doing all his work on M1 machines now, so
we are just waiting for CI support to provide proper packages.
babl 0.1.94 fixes a crash on non-aligned data for SIMD and improve vala
compatibility of introspection information.
It also brings a new command line utility for converting unique colors
from one format and/or space to another. This is very useful to us for
testing our color conversions and verifying that GIMP code does the
right conversions too, which is why we wrote this tool in the context of
the color invasion project.
For instance, to convert some color from sRGB to the CIELAB color space:
Note that babl 0.1.96 is functionally the same as babl 0.1.94, except
for a fix in the build system, which was preventing to build babl from a
tarball. Packagers in particular should therefore use the latest version.
A new denoising operation called “Denoise DCT” ("denoise-dct") was
introduced by Thomas Manni. It decomposes the input buffer to sliding
overlapping patches, calculates the DCT denoising in each patch, and
then aggregates the denoised patches to the output buffer averaging the
overlapped pixels.
As for existing operations, the following were improved:
ff-load and ff-save: big API cleanup, now ffmpeg-5.0 compatible.
gif-load: updated to latest upstream libnsgif version.
slic: progress reporting and improved parameter handling.
vector-fill: updated to latest upstream ctx version.
oilify: clamp inputs to avoid nan in output.
gegl:load: fix possible double free.
rgbe-write: plug leaks in error paths.
Apart from bug fixes, other interesting points are that the build
simplified using GEGL as a subproject and the continuous integration has
been rewritten to be more reliable.
Aryeom got reporter access to gimp
and gimp-web to help with various design-related issues.
Daniel Novomeský, maintainer of our JPEG-XL and HEIF/AVIF plug-ins, has
been given access right to our flathub repository (for our stable and
development flatpak) to help with maintenance.
We’d like to thank a category of contributors who are historically not
much in the light: release testers. Recently in particular, as we are
enhancing our continuous integration and release
process,
we also try to improve manual verifications before release. Users are
very welcome to discuss with us and hang out on our discussion channels
during release frenzy to test the final builds.
For our Windows installer, additionally to packagers (Jernej Simončič)
and developers (Jacob Boerema), we want to thank
Sevenix for having always been
on-call, testing our installers for a few releases now. Sevenix also
helps us to moderate our recent Discord discussion
channel.
This is true for the Linux flatpak and the macOS DMG as well, as in
these case, only their packagers (respectively Jehan and Lukas
Oberhuber) have been testing them before release these days. So whatever
is your platform of choice, please join us!
It’s a good reminder that you don’t need to be a developer to contribute
back. There are tasks for designers, packagers, testers, translators,
documenters and more! 🤗
We regularly write about this here: the new
maintainer
of the gimp-help repository (our documentation), Jacob
Boerema, has been improving it for over
a year now, doing much needed maintenance, removing technical debt, and
improving what existed. But you could not see much of it… until today!
Indeed he very recently updated the online documentation
website. As you can see, from the landing page
already, we finally see all languages, and each of them show their
translation ratio now. We do hope it will trigger more people to help
and contribute to translation! 😸
A daily-update process has also been set up, so that we won’t ever get
back in this bad situation of outdated online documentation for years
(even though some contents were already fixed in-repository).
The Quick Reference PDF is now also available in every supported
language (once again with translation completion percentage showing up).
Of course, a lot of original contents still deserve more love, either
outdated, or information about new features may be missing. There is
just so much that a man alone can do. Yet now the infrastructure is
there to welcome a much faster update and feedback process, so if anyone
wants to contribute to the documentation, you should look at the
repository and
propose merge requests. The contribution format is DocBook.
For translation contributions, you should get in touch with GNOME
translation teams as they have their own platform. More information is
available here.
A dedicated news with more details might soon be published, possibly if
we decide to make a new tagged release of the manual, which will mean
new installers for Windows, and tarballs for other platforms and for
packagers, containing up-to-date contents for offline usage.
Meanwhile our developer website was in an
even more dire situation as it had not been updated for over 10 years!
This is about to change as one of our goals for GIMP 3.0 is to improve
the plug-in ecosystem, not only with an upcoming extension
platform,
but also with better and more up-to-date documentation.
The work on the new developer website is finally starting, thanks to the
impulsion by Robin Swift, a new contributor, and help from Pat David
(who is the long-time contributor who already helped by revamping our
website
and created the PIXLS.US community for FLOSS
photography tool).
We already ported the website contents, away from DocBook, to the
Hugo platform. This should simplify contributions.
We also cleaned most of the outdated contents and started to port some
contents which were stored in the source repository itself and from the wiki.
Ah, the wiki! Some people might have noticed that it is gone now. We
used to have the roadmap, build instructions for newcomers and more
technical or historical stuff over there. Let’s say that unfortunate
events occurred and we lost it. 😱
Fortunately all the contents could be salvaged, and we plan to port the
valuable parts into the upcoming developer website, nicely
organized.
After all, both the wiki and the developer website were filling a
similar purpose (with the exception that one was mostly abandoned). So
in the end, it’s a good thing, organization wise, right? 😅).
It’s still very early in the migration process, so we will keep you
up-to-date with more exciting news soon.
61 people contributed to the main
repository for GIMP 2.99.12:
23 developers contributed to GIMP code base for this micro version:
1 developer with more than 300 commits: Jehan.
4 developers with 10 to 50 commits: Jacob Boerema, Nikc, Loyd
Konneker, Niels De Graef.
18 developers with less than 10 commits: Povilas Kanapickas, Kevin
Cozens, Lukas Oberhuber, woob, Simon Budig, Anders Jonsson, Axel
Viala, Ben Rogalski, Claude Paroz, Daniel Novomeský, GokhanKabar,
Jan Tojnar, L amander, azetoy, houda, Øyvind Kolås, ktoyle and
Sonia Habtiche.
35 translators contributed: Yuri Chornoivan, Hugo Carvalho, Martin,
Rodrigo Lledó, Zurab Kargareteli, Luming Zh, Anders Jonsson, Fran
Dieguez, Sveinn í Felli, Nathan Follens, Asier Sarasua Garmendia,
Balázs Úr, Matej Urbančič, Alan Mortensen, Aleksandr Melman, Alexandre
Prokoudine, Claude Paroz, Jordi Mas, Sabri Ünal, Balázs Meskó,
MohammadSaleh Kamyab, Alexander Shopov, Jiri Grönroos, Piotr Drąg,
dimspingos, Charles Monzat, Hannie Dumoleyn, Jürgen Benvenuti, Tim
Sabsch, Alexandre Franke, Aryeom, Boyuan Yang, Danial Behzadi, Maíra
Canal and Rafael Fontenelle.
4 people helped with in-code documentation: Jehan, Lloyd Konneker,
Niels De Graef and Akkana Peck.
1 person contributed to icons: Stanislav Grinkov.
3 people contributed to cursors: Aryeom, Jehan and L amander.
3 people contributed to themes: Jehan, Akkana Peck and Nikc.
12 people contributed build-related updates: Jehan, Lloyd Konneker,
Akkana Peck, Anders Jonsson, Jan Tojnar, ktoyle, Øyvind Kolås, Lukas
Oberhuber, Bartłomiej Piotrowski, Ondřej Míchal, Daniel Novomeský and
Jacob Boerema.
These are the stats on babl,
GEGL and
ctx repositories:
7 contributors to babl 0.1.94 and 0.1.96:
3 contributors with multiple commits: Axel Viala, Øyvind Kolås and Jehan.
4 contributors with single commits: Eli Schwartz, Lukas Oberhuber,
Sergey Torokhov and Xavier Claessens.
24 contributors to GEGL 0.4.38:
7 contributors with multiple commits: Øyvind Kolås, Behnam
Momeni, Thomas Manni, Michael Drake, Xavier Claessens, Axel Viala
and Anders Jonsson,
3 contributors with single commit: Felix Schwarz, Jehan and darnuria.
15 translators: Hugo Carvalho, Piotr Drąg, Rodrigo Lledó, Yuri
Chornoivan, Anders Jonsson, Luming Zh, Martin, Zurab Kargareteli,
dimspingos, Alan Mortensen, Jordi Mas, Marcia van den Hout, Marco
Ciampa, Sabri Ünal and Tim Sabsch.
ctx doesn’t have releases per-se as it is project-embedded code. So
let’s count commits in the time frame between GIMP 2.99.10 and 2.99.12:
1 contributor with more than a hundred commits on documentation and
scripts: Jacob Boerema.
7 contributors on the documentation itself or scripts, with less than
30 commits: Jehan, Anders Jonsson, Andre Klapper, Balázs Úr, Daniele
Forsi, Jernej Simončič and Marco Ciampa.
21 translators: Rodrigo Lledó, Jordi Mas, Nathan Follens, Yuri
Chornoivan, Marco Ciampa, Anders Jonsson, Tim Sabsch, Hugo Carvalho,
Balázs Úr, dimspingos, Alan Mortensen, Aleksandr Melman, Charles
Monzat, Claude Paroz, Danial Behzadi, Kjartan Maraas, Luming Zh,
Martin, Matheus Barbosa, Milo Ivir and Ulf-D. Ehlert.
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting and manual tweaking, errors may
slip inside these stats. Feel free to tell us if we missed or
mis-categorized some contributors or contributions because we try to
acknowledge every contributor for being a part of GIMP!
Other packages made by third-party are obviously expected to follow
(Linux, *BSD distributions’ packages, etc.). The MSYS2 project is also
apparently planning to package the development version soon too.
This release is once again a major milestone towards GIMP 3.0. All 2.99
development versions were big milestones, but we are really feeling we
are getting close to release candidates now, with some great improvements
happening in much needed places:
we are finally getting proper neutral-gray themes;
our Wayland build is finally getting a bit stabler (even though issues remain);
our macOS build is really on the usable side now;
our last remaining GTK port issues are slowly, but very surely,
getting taken care care of;
the space invasion project is showing leaps thanks to the CMYK project
(which forces us to review color space issues as a whole);
Script-fu and the API in general are getting much love;
several of our long-worked improvement projects are getting to an end;
and more as so many things are on the work!
We still can’t give you any date for GIMP 3.0, but we are getting there! 🤩
While others distributing GIMP is not necessary a problem (we even have
a page explaining why selling GIMP is not illegal),
we have no way to know what is actually in a third-party package, hence
we cannot vouch for them.
Problems could be malware 😱 participating in botnets, hack your files or
other computers or perhaps just steal CPU resources. Some are charging
for their packages while using deceptive wording — seeming to be the
official GIMP team — and at the same time introducing subtle bugs or
significant problems like uploading opened images behind the users back.
The official GIMP packages do not contain malware nor do they upload
your files. We have a strict Privacy
Policy.
Our packages are also free of charge.
These are not all cases, and other third-party packagers may be doing a
great job adding value (user support, additional documentation, more
filters…) so you are welcome to continue using these as long as you are
aware they are not related to us.
Anyway we saw enough problematic cases that we are happy to announce
GIMP being now officially distributed on the Microsoft Store so that
everyone can get GIMP from its source.
We worked closely with a developer relations team at Microsoft for this
new distribution channel. GIMP is proposed as what they call a
traditional desktop
app
which basically means that even if you install GIMP from the store, it
actually uses the exact same installer (as found on our download
page then run by the store in silent mode).
The good side is that it’s easier for us to maintain and user experience
is exactly the same. The bad side is that it doesn’t get additional
niceties made available by centralized repositories, such as
auto-update. You will still have to update yourself, the old way.
This is why working on a MSIX or UWP package remains a possibility if
anyone wants to continue the work started.
Contributors welcome! 🤗
This news lists the most notable and visible changes. In particular, we
do not list here the bug fixes.
To get a more complete list of changes, you should refer to the
NEWS
file or look at the commit
history.
GIMP now supports 8 and 16-bit CMYK(A) TIFF files on import. This is
one of the first consequences (already!) of the GSoC
project
by NikcDC under mentorship of Jehan.
Moreover the BigTIFF format is now supported, both for import and
export. BigTIFF is an evolution of the original TIFF format allowing
files bigger than 4GiB by using 64-bit internal offsets.
The TIFF export dialog exposes a checkbox to enable this format variant.
BigTIFF export in GIMP 2.10.32: new option in the TIFF export dialog
Moreover, if you try to export as a TIFF file and if it fails because of
the maximum file size being exceeded, it will propose you to retry
either as BigTIFF or with another compression algorithm.
Finally additional special cases in TIFF format are now taken into
account, making loading TIFF files more robust.
JPEGXL file format has been supported in development code ever since
GIMP
2.99.8.
Daniel Novomeský backported the import code to the stable branch.
We remind that a third-party
plug-in
already exists, by developers of the libjxl library. It is a different
codebase and should still work with GIMP 2.10.32. The main advantage of
the third-party plug-in is that it has also export capabilities (which
our stable plug-in doesn’t have yet), though with some unsolved issues
causing some images to fail to load or export correctly.
You are welcome to continue using the third-party plug-in if you prefer.
For instance the MSYS2 project now has it built-in within the libjxl
package. If you install it, it will take precedence over our new core plug-in.
Some game engines require DDS images to be flipped vertically. Until
now, asset creators had to flip the image in GIMP, export, then undo,
which was not a very practical workflow.
This is why NikcDC added a new “Flip the image vertically on export”
option allowing you to flip your image at export time.
Similarly, there is now a “Visible layers” option (additionally to
“Selected layer“, “As cube map“…) allowing you to export the whole
image render, not a single layer. So depending on your work usage, you
won’t have to flatten your image (to later undo this action) anymore
before export.
DDS export in GIMP 2.10.32: new “flip” and “All visible layers” options
Several metadata handling improvements were made. One of the most
important changes is that GIMP will start dropping
Xmp.photoshop.DocumentAncestors tags if more than a thousand of them
are found.
This case is very likely due to a bug in some versions of Photoshop or
other software creating PSD files as we encountered over 100,000 such
tags in some files (it probably makes no sense that a document could
have that many ancestor documents), which was seriously slowing down
GIMP to the point it looked frozen.
XCF import code also received various improvements, making the software
more robust to invalid files. In some cases, it allows to salvage more
data from corrupted XCF files, hence protecting your work.
The Text tool now supports localized glyphs (locl) depending on the
value of the “Language” tool option.
It is useful if you write in languages with regional variant forms (e.g.
Serbian or Ukrainian use the same Cyrillic alphabet yet with 5 letters
having regional variants).
If your chosen font supports several variants, you can now
tell the internal formatting system through the “Language” settings
which one needs to be used.
‘locl’ support in GIMP 2.10.32: same characters in (left) Serbian (right) Ukrainian (top) upright (bottom) italic
All official themes now have on-hover indicator around the eye 👁️ and
link 🔗 toggles in Layer/Channel/Path Dialog tree-views.
On-hover effect on eye and link toggles in GIMP 2.10.32
In the Dark theme, a new on-hover effect on radio menu items was added
to improve readability.
On-hover effect on radio menu items in GIMP 2.10.32
In the Color icon theme, thin contrast borders were added to the
‘close’ and ‘detach’ icons to improve their readability against dark
backgrounds on mouse-hover.
More readable icons in GIMP 2.10.32
In the Color icon theme, horizontal and vertical chain ⛓️ icons are
more distinguishable between their broken and not-broken variants.
GIMP 2.10.32 is the first stable release with the nice optimizations
brought since babl 0.1.90 and GEGL
0.4.36,
now that they have been battle-tested and debugged within the
development release GIMP 2.99.10.
As a consequence, babl 0.1.92 has been released, fixing in particular
SIMD discovery ability, which was misbehaving on Windows.
These improvements are important enough that we felt their 2.99.10
description deserved to be copied on the stable news to make clear this
applies to GIMP 2.10.32 now.
babl works as a universal pixel encoding translator by having - a not
necessarily fast reference conversion able to deal with everything - and
a collection of conversions that can be chained together into what babl
calls fishes. The fishes are raced against each other to find the best
conversion babl is able to create.
In some situations, a LUT (Look-Up
Table)
will perform better, we now know what the performance will be of using a
LUT for various combinations of input and output bits per pixel; and
mark fishes that are better as LUTs on creation time. If such a fish is
used more than a minimum, LUT population is triggered.
Right now one drawback is that it might actually slow down slightly the
first conversion happening in a given input > output conversion couple.
The solution which might come later would be to create the LUTs in the
background in a thread and continue doing non-LUT conversions until it
is ready.
Note that the created LUTs are also garbage-collected after a few
minutes of non-usage, to avoid filling memory with single use LUTs.
SIMD builds for x86_64 and ARM neon (ctx, babl and GEGL)¶
All of babl, GEGL and ctx have gotten similar SIMD build and dispatch changes applied.
Image processing code written to be portable and performant caters well to the
auto-vectorization support for SIMD in modern compilers. The way it is done is
mostly by changes to the build system. For now the code remains the same for
all targets but the approach can be extended with conditional intrinsics.
To see the impact this can have, here is a test of filling a circle with ctx
and its different pixel encoding targets, on a Raspberry Pi with default
compiler flags (without neon support). Note that the cairo reference
comparison is the BGRA8 format (the only other format proposed by Cairo is A8):
Filling a 256px radius circle in a 512x512 buffer a number of times without Neon (smaller is better)
And the same test, with the compiler allowed to use Neon instructions:
Filling a 256px radius circle in a 512x512 buffer a number of times without Neon (smaller is better)
Note well that both the optimized and non-optimized cases are built-in,
and availability of relevant instructions determined by runtime tests.
This makes these optimizations very portable, despite being based on
recent architecture instructions.
ℹ️ Note that these changes (both the automatic LUT generation and the SIMD
dispatch) will apply to GIMP 2.10 versions later. For now they are
available in 2.99 as a form of beta test. We welcome feedbacks if you
encounter any misbehavior.
lukaso was already considered co-maintainer of the macOS build
repository of GIMP (gimp-macos-build) since they have done most heavy
lifting on GIMP for macOS for many months. This has been made official
by changing their account to maintainer on this build repository.
Lloyd Konneker has been given developer git access to the main GIMP
repository, in particular for their nice work so far on script-fu (which
was in a state where dropping script-fu for GIMP 3.0 would have been
considered otherwise).
Kevin Cozens, a long term GIMP contributor and script-fu maintainer got
back recently and was given git access again to the repository. He will
help co-maintain script-fu with Lloyd.
Ondřej Míchal has been given “Reporter” rights on the main GIMP
repository (allowing to triage reports: labelling, closing,
reopening, and moving reports…).
After being given “Reporter” rights initially, NikcDC has eventually
been given developer git access in order to facilitate the work on
feature branches for their GSoC
project.
10 people contributed changes or fixes to GIMP 2.10.32 codebase:
3 people contributed several code changes or fixes: Jacob Boerema,
Jehan and Nikc.
1 person contributed several theme and icon improvements: Stanislav Grinkov.
6 people contributed single commits: Sabri Ünal, Daniel Novomeský,
Lukas Oberhuber, Rafał Mikrut, smlu and Øyvind Kolås.
About translations of GIMP itself:
24 translators contributed: Anders Jonsson, Sveinn í Felli, Alan
Mortensen, Aleksandr Melman, Yuri Chornoivan, Hugo Carvalho, Luming
Zh, Rodrigo Lledó, Jordi Mas, Martin, Piotr Drąg, Balázs Úr, Jiri
Grönroos, Zurab Kargareteli, Boyuan Yang, Marco Ciampa, Matej
Urbančič, Milo Ivir, Sabri Ünal, Tim Sabsch , Balázs Meskó, Charles
Monzat, Fran Dieguez, Hannie Dumoleyn.
GIMP 2.10.32 includes a new Georgian translation, incrementing the
number of available languages for the stable version to 83.
GIMP was already localized in Galician, but not the Windows
installer… until this version!
Contributions on other repositories in the GIMPverse:
1 contributor to babl 0.1.92: Øyvind Kolås.
5 contributors to babl 0.1.90: Øyvind Kolås, Mingye Wang, Jehan,
Tomasz Golinski and Andrzej Hunt.
6 contributors to GEGL 0.4.36: Øyvind Kolås, Anders Jonsson, Jehan,
Alan Mortensen, Caleb Xu and zamfofex.
ctx contributors in the same timeframe: Øyvind Kolås, and Jehan.
2 contributors to gimp-macos-build (macOS build scripts): Lukas
Oberhuber and Jehan.
4 contributors to org.gimp.GIMP (stable flatpak): Hubert Figuière,
Ondřej Míchal, Jehan and Rebecca Wallander.
1 Windows packager: Jernej Simončič.
Contributors to gimp-help (GIMP manual) since last
stats:
2 technical contributors (build scripts, continuous
integrations…): Jacob Boerema and Jehan.
5 documenters (original English text): Jacob Boerema, Anders
Jonsson, Andre Klapper, Jehan and Marco Ciampa.
20 translators: Rodrigo Lledó, Jordi Mas, Nathan Follens, Yuri
Chornoivan, Anders Jonsson, Hugo Carvalho, Marco Ciampa, Tim
Sabsch, Balázs Úr, dimspingos, Alan Mortensen, Aleksandr Melman,
Charles Monzat, Claude Paroz, Kjartan Maraas, Luming Zh, Martin,
Matheus Barbosa, Milo Ivir, Ulf-D. Ehlert.
6 contributors to gimp-web (website) since last stats: Jehan,
Alexandre Prokoudine, Anders Jonsson, Tom Gooding, Alberto Garcia
Briz, Babs Keeley.
Then let’s not forget to thank all the people who help us triaging in
Gitlab, report bugs and discuss evolutions with us.
And of course, our community is deeply thankful to the internet warriors
who manage our various discussion
channels or social network accounts
such as Ville Pätsi, Alexandre Prokoudine, Liam Quin, Michael Schumacher
and Sevenix!
Note: considering the number of parts in GIMP and around, and how we
get statistics through git scripting, errors may slip inside these
stats. Feel free to tell us if we missed or mis-categorized some
contributors or contributions.
Ever since our new official mirror
procedure,
the following mirrors have been added to our rotation scripts:
Get Hosted Online (Rothwell, United Kingdom)
Aceldama Systems (Montreal, Canada)
Open Computing Facility (Berkeley, CA, United States)
Freedif (Singapore)
One mirror from the previous list had to be removed because of
performance issues, and a mirror acceptance is still on-hold because of
the conflict and unstability in East Europe.
As a fun note, GIMP is now back to Berkeley through the Open Computing
Facility (student organization for all University of California,
Berkeley students, faculty, and staff). For anyone wondering why it’s
fun, you may read with interest the birth
story of the GNU
Image Manipulation Program.
TLDR; GIMP was originally
born in the University of California. I guess it’s good to be home, right?
We took the opportunity to restructure the page with per-language section.
This is also a good time to remind that it is up to everyone to help us
keep this page updated. We know many more books have been published
about GIMP across the years so the list is very incomplete. Therefore if
you wrote or know of a book absent from the page, please feel free to
report the same information as other books on the
page so
that we can add them. Thanks!
You may notice that stable releases are slowing down (GIMP
2.10.30
happened 6 months ago) as we are reaching a good stability overall on
this branch, despite being held back by our very old toolkit.
Nowadays most of our focus is on the development branch. Yet we will
continue to provide updates and bug fixes to the 2.10 branch until GIMP
3.0 is out.
The cat is out of the bag: Nikc, a Google Summer of Code student, is working
this year on getting CMYK features into
GIMP.
Let’s talk about this in a little more detail.
For the record, we only requested this unique project slot to Google.
Nikc discussed beforehand with us to understand the needs, the project
current state as well as the wanted direction. They also contributed
patches before GSoC selection so we knew how they interact during code
review. If anyone is interested in GSoC in future years, please consider
communicating with us like this, not just dropping a proposal without
contacting us on our mailing
lists or
IRC. 😉
Historically, it was complicated to implement CMYK support in GIMP as
the program used to be hardwired to use sRGB color space for pretty much
everything. Supporting any RGB color space has been work in progress for
many years and it got much better already in the 2.10 stable series.
On the other hand, print was not facilitated as a main workflow provided
by our project for decades.
Since late 2000s, we’ve been considering a late binding workflow for CMYK,
i.e. where you work in RGB, softproof in CMYK and then export to CMYK. Peter
Sikking, a UX architect we worked with, came up with a
plan for that, but the
image processing engine was missing the required changes, and someone would
have to work on exposing everything in GUI.
We ultimately lacked contributors interested into prioritizing that, and
one patch we got
from a contributor some years ago couldn’t be merged for architectural
reasons, it had to be redone completely to play well with the rest of
GIMP’s code.
A few years back, Øyvind Kolås finally added the missing
bits to GEGL, our image
processing engine, that made it possible to do things like blending a CMYK
image with an RGBA image and writing the result as a TIFFCMYK file.
This paved the way to this particular GSoC project.
First and foremost, we are not yet talking about a CMYK image mode, akin to
‘RGB’, ‘Greyscale’, and ‘Indexed’ like what you have today. Here is what it
will focus on instead.
Importing and exporting images in a CMYK color space. GIMP will open
images in a CMYK color space and convert them to RGB(A) for viewing and
editing. You will also be able to export images to CMYK. We are currently
targeting TIFF, PSD, PDF, EPS, AI, and PDF file formats.
While you won’t be able to edit CMYK images in a non-native color space
yet, being able to both open (if only to view) and export CMYK data is
clearly a step forward. Moreover while working with a CMYK backend is
useful for some use cases (controlling your black colors or other
accurate color mix as per printer instructions, ink coverage, trapping,
overprinting and whatnot), working with *RGB images, then moving
to CMYK in the end, is still a recommended workflow for many types of
works. For instance, graphics professionals in the GIMP team and around
worked with a lot of success with a mix of GIMP and
Scribus, which is a software we warmly recommend.
Example of printing with FLOSS: the “Libre Calendar 2015” was a collaborative project by LILA, with several artists (illustrators, photographers and 3D), processed with GIMP, Inkscape and Scribus, Creative Commons by 2.0
Here is the current progress regarding CMYK support in file formats:
JPEG:
CMYKJPEG loading has been supported in GIMP for many years.
CMYKJPEG loading has been recently ported to using babl for
conversion by Jehan Pagès.
CMYKJPEG exporting has been implemented as well by Jehan Pagès.
These improvements will be available in upcoming GIMP 2.99.12 and
were implemented as a demonstration sample for Nikc since
Jehan is the project mentor.
PSD:
CMYKPSD 8-bpc CMYK loading
has already been available since GIMP 2.10.18 thanks to Massimo Valentini.
The code has been updated by Jacob Boerema
to load 16-bpc CMYKPSD files
in GIMP 2.99.10.
Work is in progress by Nikc to port CMYKPSD load code to use the
babl library for conversion (should be available for 2.99.12,
provided it passes review).
Exporting CMYK files in the PSD format could also be within the
scope of this GSoC project.
CMYKTIFF loading and exporting is a work in progress by Nikc and
might be available in GIMP 2.99.12 if it passes review on time.
Other formats with CMYK support will be considered.
A new dockable dialog for color management. To aid the late binding
workflow, we need to be able to easily switch soft-proofing (simulating
the CMYK result). Right now switching it ON/OFF and choosing profiles is
done through menus which is cumbersome.
Nikc will develop a new dockable dialog to convert between color
spaces via ICC profiles, control soft-proofing, etc. This is the next step
after CMYK support in various file formats. We’ll feel comfortable talking
about this more once it’s being actively worked on.
Soft-proof profile(s) as first-class citizen: currently the
soft-proof profile is attached to the view, which means it disappears
and needs to be set up again in-between sessions. Also the selected
profile is not available to plug-ins which makes our CMYK export
capabilities much less interesting until it gets implemented. This is
why we want to move the soft-proof profile to become an image data
instead, which will be stored in the XCF file. Nikc announced to have
already started to work on this.
Discussions are ongoing to make this change generic to allow storing
even several simulation profiles in the long run. This will make sense
in particular when GIMP will support the concept of multiple export
targets, as was theorized in an early blog
post.
Indeed a single image can be targetted differently for low-quality web
previewing, for high-quality digital viewing, for printing… And it can
even have different print targets. This is not in the scope of this GSoC
project but are things we need to take into account early on when
modifying the core code.
Identifying and fixing issues with color management. There are still all
sorts of bugs and imperfections in GIMP’s color management implementation. We
already know about some of them and we have no doubt that others will manifest
themselves as the work on this GSoC project continues. Among the obvious
areas to look on in details are: color picking and sample
points,
color
selection,
soft-proofing, various types of previews, maybe improved ways to work on
specific color channels…
So fixing or improving those is definitely part of the project. As you
can see from the links above, work has already been started on some of
these areas, and porting more code to using
babl for streamlined conversion is a big part
of the project.
Note that all improvements are not necessarily about CMYK-only in the
end, since we have been working to make our color code more generic,
which means that some changes may need to happen on a lower level, hence
enhancing the workflow, efficiency and accuracy with any color model.
When are we shipping the results of the GSoC project?¶
Currently, we expect to make all new features and improvements developed by Nikc
this spring/summer to be part of GIMP 3.0.
Previously, we talked about anyRGB approach to editing that was within the
scope of the Space Invasion initiative (end-to-end ICC profile attribution for
an image while passing it through various operations in the node composition).
Essentially, you should be able to open an image in e.g. AdobeRGB color space
and never convert it to e.g. sRGB unless a particular GEGL operation requires that.
We revised the anyRGB plan to extend it to anyModel (RGB, CMYK, LAB
etc.). This is going to be a major undertaking, we do not expect to ship
this in GIMP 3.0 and we’d rather not give any estimations at this time.
Even staying within the scope of the printing world, hardcoding the
specific CMYK model, rather than having generic core, would make no
sense. What if you could also add spot color channels to your image for
instance? This anyModel core is the direction we are heading for and
the result of the groundwork which has been slowly built up by several
contributors for many years now.
Up till 2013, GIMP was a regular at the Summer of Code. Ever since then
we haven’t applied.
Nine years have passed, so we decided to give it a new try and 2 days
ago, we received an email:
GNU Image Manipulation program is officially a Google Summer
of Code 2022 mentor
organization!
If anyone is interested, it could be a good opportunity to jump into the
development of a huge desktop program used by millions of people. Here
are some ideas of what you could possibly work on: wiki with list of
possible project
ideas.
On our side, we are interested in realistic projects which can really be
finished or at least broken down in usable parts. Our list of ideas is
mostly informative and we very much welcome people coming with their own
ideas. If you want to participate, come discuss with us on
IRC.
GIMP is a huge codebase with high quality level requirements before
acceptance of any code. It will require any participant to be thorough,
listen well to our reviews and have some perseverance.
To increase acceptance chances, you could pick some bugs to fix or some
easy features to implement (look in our newcomers
list
or simply in the full
list of reports; possibly
if you encounter an issue yourself, you could just come and fix that!),
make a merge request with us and see how it goes. This would be the best
kind of first contact before submitting your application.
Last but not least: we welcome contributors from all walks of life,
regardless of origin, skin color, gender etc. All we ask is that you remain
courteous and respectful to your fellow developers while working with us,
and we will of course return the courtesy. If you’re looking for a
welcoming environment, our project may be the perfect fit for you! 🤗
GIMP 2.99.10 is once again a pretty massive step in our development
plans toward GIMP 3.0. We redesigned some core concepts of GIMP (“linked
layers”, item locks’ GUI, dynamics switch), substantially improve the
new API further into releasable state, babl and GEGL gets crazy
optimizations going on, macOS and Wayland get more love, all the while
improving file formats… And more!
The below report will go through the most interesting changes.
“Experiments” by Aryeom, Creative Commons by-sa 4.0 - GIMP 2.99.10
Our stable series (2.10) still uses a concept of “linked layers”, which
is mostly for transforming layers together. For instance, say you want
to translate, rotate or shear several layers the exact same way. You
would link them with the “chain” 🔗 icon next to each layer in the
Layers dockable.
In GIMP 3.0, as we have multi-selection of layers and all the transform
tools were already made to work on multiple layers at once, this concept
was redundant and confusing. Nevertheless there was still one added
value: as a way to mark and store a relation between layers.
This is why we remove the link feature and added instead a “layer set”
feature. A “layer set” is a selection of layers stored with a name.
Layer set popover at bottom of Layers dockable
For instance, you could select a few layers together and store this
selection as a layer set. Anytime in the future, you can select the same
layers again in one click, without going through the slow process of
clicking them one by one. In the below example, I am storing a semantic
name for several layers featuring sleeping marmots:
Left: select some layers and write a set name - Right: the set can now be selected again anytime
There is more! The same dialog allows you to search through layers by
names. Say I want to select all layers containing “marmot” or “flower”,
I could just search said keyword.
Searching layers with “flower” in the name - 3 were found in this huge layer list
For the geekiest of us: by default, this uses simple text search, but in
Preferences, tab “Interface”, you can also set the search entry
to use the Glob or Regular Expression syntaxes!
Settings for search syntax: text search, glob pattern or regular expression
The locks (position, contents and alpha) used to be at the top of the
Layers or Channels dockables. It meant that to know whether a specific
layer was locked, you had to select it. Worse, when selecting several
layers, the buttons could end up in an inconsistent state (if some
layers are locked while others not).
So we moved the locks to the space left vacant by the now-defunct “link”
🔗 icon, next to each item. Clicking it will open a small popover dialog
where you can select the lock type.
Selecting a single lock will show it next to the visibility (eye 👁️)
icon, selecting 2 locks or more will show a generic multi-locks icon.
Each of the new icons, specific or generic, were designed by Aryeom.
Now you know in a single glimpse to the layers list which ones are
locked or not.
Left: popover on “lock” area click -
Middle: lock position (specific icon shown) -
Right: lock contents (2 locks in use: multi-locks icon shown)
Among other advantages, the lock icons now allow the Shift-click
interaction, same as the visibility icon, so that one can switch many
items’ locks at once. We also created a new Alt-click interaction to
switch locks within all selected layers. So we now have:
Simple click on a lock or visibility icon: the clicked item’s
visibility or lock state is switched.
Shift-click: the clicked item stays visible/locked while the
visibility or lock state of all other items on the same level in
the layer tree is switched ON or OFF.
Alt-click: the clicked item stays visible/locked while the
visibility or lock state of all other selected items is switched
ON or OFF.
You will notice that we also added a new lock, the “Visibility Lock”. As
the name implies, it prevents the visibility status to be modified. This
is especially interesting together with features allowing to change
multiple items at once, like the Shift-click or Alt-Click actions
explained above. You could for instance have a background image locked
to be always visible, then you could switch other foreground layers’
visibility while always keeping the background visible. Oppositely you
could prevent your initial croquis for instance from being shown by mistake.
Locking visibility of background layers to always visible and
croquis layer to never visible.
Among other changes in this area, the alpha and position locks can now
be set on Layer groups:
Alpha lock on groups mostly works like contents lock on groups (except
that it’s for the alpha channel only), i.e. that it forbids to change
the alpha channel from any child layer.
Position lock work both ways by forbidding moving child layers but
also parent layers.
It is now possible to enable and disable dynamics in a single checkbox,
instead of tediously having to select the “Dynamics Off” neutral
dynamics. Obviously this neutral dynamics has been removed from the list
of installed data.
It allows to switch dynamics painting in a single click, and without
having to remember which dynamics you were using when switching back.
Enabling and disabling dynamics in one click
For advanced user, we also set up the new action
“context-dynamics-toggle”. Thus you can create a shortcut (Edit >
Keyboard Shortcuts menu) to switch the dynamics painting for even
faster work.
Setting a shortcut to enable or disable dynamics in the Keyboard
Shortcuts dialog
New option in “Line Art” mode of bucket fill tool¶
We added a new option “Allow closing lines in selected layer” in the
“Fill by line art detection” mode of the bucket fill tool. The name is
not necessarily final as naming this was hard.
Anyway here is what it does: when you choose the “Layer above|below the
selected one” source, the selected layer is not used as line art source
(as the title says). Yet with this option, you add the ability to paint
with your fill color directly in the selected layer and union this data
as closure data.
Once again, it is not a source for line art detection, which means
it doesn’t trigger any recomputing. It is additional data for manual
line closure only after line art and closure computation.
One of the main usage could be to set the “Maximum gap length” to 0,
which totally disables line art closure computation, hence having much
less computing (i.e. faster on big line art images). Then you’d rely
solely on manually closed line arts. Unfortunately sometimes you don’t
want to close a line art with your line color/brush/style, you want
to close it with your fill color/brush/style. This is when this
option comes into play.
For instance, here is how you could fill the line art with the smart
closing which could oversegment if you don’t tweak properly the
“Maximum gap length“. Additionally the closure (here at the leg
bottoms of the character) would likely not be the expected style:
Now let’s disable the smart closing algorithm and use the new option
instead. We will simply paint with our expected fill color and style to
close the line art and it will be considered as “line” without
recomputation. This way, the fill is instant and the closure style is
exactly the one you expect:
This new option is originally based on an advanced digital painter tip
of Aryeom on how to colorize efficiently a croquis (she was using this
long before the “fill by line art detection” feature in GIMP, using
Fuzzy Select in sample merged mode). Closing line arts with fill style
is one of the many techniques she teaches to digital painting students at
university. So we thought integrating this into our line art fill tool
would be a definite gain as Aryeom was disappointed by the absence of
style and control with the smart closing algorithm.
Note: we are aware the settings in this tool are a bit complicated to
apprehend. We will hopefully do a pass of redesigning soon.
GIMP now gets a Welcome Dialog which will show up only once after a
new installation or an update. It will display the splash image, some
short text and links to documentations and alike.
It also has a “Release Notes” tab containing the Release Notes of the
new version so that anyone can peek at a listing of novelties.
Welcome Dialog at first launch after installation or update
Note: the currently proposed Windows installer misses the release note.
We will fix this shortly.
The website’s (the one you are reading on gimp.org) news will still
provide nicer longer texts with explicative screenshots. But at least,
the Welcome Dialog will be here for people not reading the website.
An advantage of the Welcome Dialog’s release notes though is that it can
be fully localized by our translators (unlike the website in its
current version). For instance, here are the release notes showing on a
Portuguese-localized GIMP:
Welcome Dialog’s release notes are localized; e.g. here in Portuguese
Some more work might happen on this Welcome Dialog. For instance,
a “Customization” tab for some of the more controversial settings (such
as themes and icons) will likely be added.
There is also the question about adding more “everyday use” features,
such as a list of the last opened images, or a “New Image” option,
avoiding going in menus (or using shortcuts).
Of course it means giving the ability to open the dialog at every start
as an option (unlike now where it will only open once after a new update).
Our compact slider was only available to core
code
until recently. It means that all plug-ins in particular could not use
of this slider.
So the widget has now been moved to the libgimpui library, making it
usable by any plug-in which wants a nice looking and efficent slider
with slow relative moves, fast drag moves and direct keyboard edits (see
some of the usability work in an older
news),
all the while maximizing the space.
A few of our official plug-ins already make use of it now.
The PNG export dialog with compact slider
Additionally our default System theme made it even more compact,
because there were some complaints that this said compact slider was
not compact enough!
As often lately, our PSD plug-in got some love to widen our support abilities:
new support for loading 16-bit per channel CMYK images.
new support for files in LAB colorspace.
new support for loading 32-bit per channel images (some code
existed yet may have never really worked).
Add extra layer groups when loading PSD images with clipping
layers: Photoshop handles clipping layers in a different way than
GIMP. The only way to have it look the same is by adding extra
layer groups. PSD layers that have clipping set, combined with the
first non clipping layer below it are grouped together in a new
layer group. Doing this results in the same image as the PSD
merged image unless there are other PSD elements in play that we
don’t handle yet.
PSD layers with clipping set need clip to backdrop as composite
mode: certain PSD layers have a flag called clipping set to 1. We
were not handling this flag and had some reports about colors
bleeding where there were not supposed to. We are going to set
GIMP’s layer composite mode to “Clip to Backdrop” which is the closest
we can get to Photoshop’s clipping. With this, the colors won’t bleed anymore.
GIMP is now able to load and export Microsoft Windows Cursors, including
the ability to read at import, pass on and edit at export the hot spot
location for each cursor in the file.
We definitely removed support for the KDE and GNOME portals for
screenshots. On recent versions of these portals, new security
restrictions were making them unusable for GIMP which didn’t have the permissions.
We now use only the Freedesktop portal on Linux (unless the direct X11
codepath is available, i.e. on Wayland) which is the new recommended
logic by both the GNOME and KDE teams.
On Windows, the Screenshot plug-in finally gets an “Include mouse
pointer” option.
The HEIF plug-in used to have some heuristic for the choice of the
bit-depth defaults when exporting, depending on the image’s encoding
settings. This heuristic didn’t agree with everyone’s logic.
Also it was going against the settings storage which are now a basic
feature of most plug-ins.
So we decided to just drop this heuristic and leave the user completely
responsible for chosing the bit-depth they wish.
We have 2 plug-ins depending on the WebkitGTK library:
help-browser: for displaying the html docs. Nowadays every desktop
machine has a browser, so it feels redundant. Its main advantage
though was its very nice “topic tree”, which is basically a side menu
to navigate the documentation quite efficiently.
web-page: a webpage screenshot plug-in allowing to shot the whole
page, not just what is visible. This is a very neat feature, yet it
also appeared on most web browsers by default these days. For
instance on Mozilla Firefox, you can right-click then select “Take
Screenshot” in the contextual menu of a page.
On the other hand:
WebkitGTK is very hard and long to build. More than once we
encountered issues and are dreading them. Actually our macOS package
don’t build it right now because of such difficulties.
From what we gather, recent versions are officially unsupported on
Windows right now and we don’t know when or if it will change soon.
So we have 2 of our main platforms not using it, it makes a lot of
packaging problems, all this for features which are a bit redundant with
browser nowadays anyway. This is why we decided to drop the ball, at
least for now, by deprecating these 2 plug-ins. Unless situation changes
in any positive way, we are not recommending packagers to build these anymore.
Our icon theme handling code was a bit of a mess because of too many
build cases, so we refactored it:
We now use the exact same list for the Color and Symbolic icon themes,
both in their SVG and PNG variants.
The PNG variants for both themes are now fully generated from the SVG
files instead of duplicating everything and risking strange bugs with
specific build combinations.
Our Continuous Integration now has a new weekly job to verify that the
meson and autotools build rules are perfectly synced regarding icons.
We started to group icons in semantic lists when possible to help with
deciding the right sizes to generate in the PNG case.
By the way, why we keep the PNG variant option needs to be explained. We
were originally planning to drop it, but it turns out that the librsvg
dependency used as GdkPixbuf loader, ported to Rust in its later
versions, doesn’t build on all platforms and architectures (as Rust is
not fully portable yet).
It means that some platforms may need to either use very old versions of
librsvg or may even prefer to use PNG-only icons. This is why we keep
the PNG variant for now. It is suboptimal and on platforms where
librsvg is not a problem, we definitely advise to use SVG icons. But
at least the option exists.
Note though that there is another case where we depend on librsvg: the
SVG import plug-in and this one had been made a mandatory one. We are
not changing this because as graphics professionals, we consider that
even in a raster program, you need to be able to import SVG nowadays.
This format is simply a professional standards now and not supporting it
seems absurd.
Yet we understand if it is a problem on some platforms so, packagers,
feel free to comment out the SVG plug-in if really this is a problem to
you, as we have been told. It should be quite easy to achieve.
A new .clang-format file was added to our repository and now every
merge request will trigger a CI job to verify coding-style of your change.
Now to be perfectly fair, we are not completely happy with the check
results, which is why the job failures are not fatale, mostly
informational. Let’s say this is a first step, hoping this coding style
check will get better.
Tool to bisect-test with older versions of flatpak¶
Note: this is developer fanciness and may not be of high interest to others.
Flatpak has limitations but also quite some interesting features. One of
them is the ability to install older versions of the package easily. It
can be a pretty neat developer tool when we want to test something on an
older version of GIMP, a kind of git bisect but with flatpak packages.
Nevertheless listing the old versions, uninstalling your current
version, installing the relevant older version, and remembering the
command lines for all this (since we don’t do this daily either) was
making it hardly usable in real life.
Say I want to know all the beta release still stored on Flathub:
$tools/flatpak-releases--beta
0:Workingaroundweirdinstallpathofappstreamfile.(be96fed3)[2022-02-2400:37:25+0000]1:Updatedependencies(127a0fa7)[2022-01-1316:59:43+0000]2:Issue#106: File->Create->From Screenshot not working. (9c831b14) [2021-12-14 21:46:52 +0000]3:ReleaseGIMP2.99.8.(908bf5b0)[2021-10-2020:29:00+0000]4:ReleaseGIMP2.99.6.(e04355dd)[2021-04-2614:08:32+0000]5:Makesurethedefaultpathforplug-insandscriptspointtotheextensionpoint(8b02ea26)[2021-03-3116:12:06+0000]6:BuildLittle-CMS2.12ourselves.(ae60863e)[2021-03-2916:03:51+0000]7:AddextensionpointforGimp3(34b2f8c0)[2021-03-2712:40:57+0000]8:ReleaseGIMP2.99.4.(20a0a962)[2020-12-2223:45:19+0000]9:UpdatetoGNOMEPlatform3.38.(a84da0fa)[2020-11-1423:08:38+0000]10:Useorg.gnome.Platform//3.36beta.(12017e04)[2020-11-0622:59:59+0000]11:ReleaseGIMP2.99.2!(58fef365)[2020-10-2522:20:18+0000]12:Addsharedmoduleforintltool.(a1d2b211)[2020-06-0118:34:15+0000]
The number 0 is the GIMP 2.99.10 release (the package stored the last
commit message, which might not be as relevant as we’d want).
Now say I want to install the GIMP 2.99.6 release for a test:
Our developer document was a bit sparse and not too maintained these
days, so a new version is starting to get written. It’s still widely
incomplete and some part are based on older docs which might be
outdated, or at least would deserve a review. In any case, work is in progress.
The work on the API is still going full on. Here are the most noteworthy
changes which happened during GIMP 2.99.10 time frame.
Changes in libgimp:
GimpStringArray type was removed in favor of GStrv. Various
libgimp API were updated to use GStrv, and relevant plug-in procedures with
GStrv arguments or return values were updated as well.
New functions:
gimp_context_are_dynamics_enabled()
gimp_context_enable_dynamics()
gimp_item_get_lock_visibility()
gimp_item_set_lock_visibility()
gimp_pdb_run_procedure_config()
Removed functions:
gimp_item_get_linked()
gimp_item_set_linked()
Changes in libgimpui:
New widgets:
GimpLabelColor (now used by default for GimpRGB properties in `GimpProcedureDialog)
GimpLabelEntry (now used by default for string properties in `GimpProcedureDialog)
gimp_event_triggers_context_menu(): alternative to
gdk_event_triggers_context_menu() with the additional ability of
using button release events as contextual menu triggering
(instead of press events), which might be prefered in some
cases. Other than this, it uses exactly the same conditions as
its GDK counterpart.
gimp_procedure_dialog_get_spin_scale()
gimp_prop_label_color_new()
gimp_prop_label_entry_new()
gimp_prop_spin_scale_new()
gimp_prop_widget_set_factor()
Improved functions:
gimp_procedure_dialog_get_widget() can now generate widgets of type GimpSpinScale (for int/double properties) and GimpLabelColor or GimpColorButton (for GimpRGB properties).
gimp_procedure_dialog_get_color_widget() now only return
GimpLabelColor widgets (editable or not).
Also the Vala bindings gimp-3.vapi and gimp-ui-3.vapi were renamed to gimp-3.0.vapi and gimp-ui-3.0.vapi respectively in the autotools
build (now consistent with meson).
By the way, it seems we have issues with the Vala and Lua plug-ins on
Windows in the installer we are providing. We don’t know why yet and
still need to investigate.
Various bugs and improvements have been made specifically to Wayland and
macOS support. These often go together as we notice that many of the
issues which appear on one of these also appear on the other.
On macOS in particular though, there were massive slowness issues of the
2.99 development series, so much that at some point, our packager feared
that GIMP 3.0 on macOS would never be usable.
Well we are proud to announce this was premature despair as we finally
found some solutions for some things, workarounds for others, sometimes
not too pretty yet enough for GIMP to be finally usable and even faster
than the 2.10 series in our various tests! Our only uncertainty is that
the code was mostly tested on macOS Monterey. We don’t know the
situation on Big Sur where the problems initially started.
Several parts of the solutions lead us to GTK patches. Not everything is
upstream yet, but we already use our current satisfying patch set in our
own DMG package. This will help other projects using GTK3 and
experiencing similar issues.
babl works as a universal pixel encoding translator by having - a not
necessarily fast reference conversion able to deal with everything - and
a collection of conversions that can be chained together into what babl
calls fishes. The fishes are raced against each other to find the best
conversion babl is able to create.
In some situations, a LUT (Look-Up
Table)
will perform better, we now know what the performance will be of using a
LUT for various combinations of input and output bits per pixel; and
mark fishes that are better as LUTs on creation time. If such a fish is
used more than a minimum, LUT population is triggered.
Right now one drawback is that it might actually slow down slightly the
first conversion happening in a given input > output conversion couple.
The solution which might come later would be to create the LUTs in the
background in a thread and continue doing non-LUT conversions until it
is ready.
Note that the created LUTs are also garbage-collected after a few
minutes of non-usage, to avoid filling memory with single use LUTs.
SIMD builds for x86_64 and ARM neon (ctx, babl and GEGL)¶
All of babl, GEGL and ctx have gotten similar SIMD build and dispatch changes applied.
Image processing code written to be portable and performant caters well to the
auto-vectorization support for SIMD in modern compilers. The way it is done is
mostly by changes to the build system. For now the code remains the same for
all targets but the approach can be extended with conditional intrinsics.
To see the impact this can have, here is a test of filling a circle with ctx
and its different pixel encoding targets, on a Raspberry Pi with default
compiler flags (without neon support). Note that the cairo reference
comparison is the BGRA8 format (the only other format proposed by Cairo is A8):
Filling a 256px radius circle in a 512x512 buffer a number of times without Neon (smaller is better)
And the same test, with the compiler allowed to use Neon instructions:
Filling a 256px radius circle in a 512x512 buffer a number of times without Neon (smaller is better)
Note well that both the optimized and non-optimized cases are built-in,
and availability of relevant instructions determined by runtime tests.
This makes these optimizations very portable, despite being based on
recent architecture instructions.
ℹ️ Note that these changes (both the automatic LUT generation and the SIMD
dispatch) will apply to GIMP 2.10 versions later. For now they are
available in 2.99 as a form of beta test. We welcome feedbacks if you
encounter any misbehavior.
On our main source repository, “reporter” access (allowing to triage
reports: labelling, closing, reopening, and moving reports…) have been
given to nmat and Liam Quin.
Ondřej Míchal has now been given write access to the package repository
for our stable and beta flatpak on Flathub, thus joining Hubert Figuière
and Jehan for maintenance, after their various improvements to our
flatpak packages, including some very nice work for automatic detection
of outdated dependencies, thanks to the flatpak-external-data-checker
tool.
17 developers contributed to GIMP code base for this micro version:
1 developer with more than 300 commits (Jehan)
4 developers with 10 to 30 commits (Jacob Boerema, Niels De Graef,
Lukas Oberhuber and Daniel Novomeský)
12 developers with 1 to 4 commits: Øyvind Kolås, Anders Jonsson,
Asalle, Emily Gonyer, Luca Bacci, Markus Volk, Ondřej Míchal,
Stanislav Grinkov, Yoshinori Yamakawa, bartoszek, Nikc and Tomasz Goliński.
20 translations were updated: Basque, British English, Catalan,
Chinese (China), Danish, German, Greek, Hungarian, Italian, Kabyle,
Latvian, Lithuanian, Polish, Portuguese, Russian, Slovenian, Spanish,
Swedish, Ukrainian, Vietnamese.
24 translators contributed: Yuri Chornoivan, Hugo Carvalho, Anders
Jonsson Matej Urbančič Rodrigo Lledó, Rūdolfs Mazurs, Asier Sarasua
Garmendia, Luming Zh, Bruce Cowan, Jordi Mas, Piotr Drąg, Ask Hjorth
Larsen, Boyuan Yang, Marco Ciampa, Alan Mortensen, Daniel Mustieles,
Yacine Bouklif, Alexandre Prokoudine, Aurimas Černius, Balázs Meskó,
Luna Jernberg, Ngọc Quân Trần, Tim Sabsch and dimspingos.
4 people helped with in-code documentation: Jehan, Niels De Graef,
Alexandre Prokoudine and Daniel Novomeský.
2 people contributed to icons: Aryeom and Jehan.
9 people contributed to build-related updates: Jehan, Lukas Oberhuber,
Øyvind Kolås, Asalle, Daniel Novomeský, Yoshinori Yamakawa, Aryeom
Han, Markus Volk and bartoszek.
One new splash screen by Aryeom Han.
These are the stats on babl, GEGL and ctx side:
4 contributors to babl 0.1.90:
1 contributor with more than 70 commits (Øyvind Kolås).
4 contributors with 1 to 4 commits: Mingye Wang, Jehan, Tomasz
Golinski and Andrzej Hunt.
6 contributors to GEGL 0.4.36:
1 contributor with more than 20 commits (Øyvind Kolås).
5 contributors with 1 to 2 commits: Anders Jonsson, Jehan, Alan
Mortensen, Caleb Xu and zamfofex.
ctx doesn’t have releases per-se as it is project-embedded code. So
let’s count commits in the time frame between GIMP 2.99.8 and 2.99.10:
1 contributor with more than 600 commits (Øyvind Kolås)
1 contributor with 1 commit (Jehan)
We should also not forget the documentation repository which gets more
activity these days, thanks to the new maintainership by Jacob. In the
same time frame as GIMP 2.99.10, it got 5 contributors:
2 contributors on the documentation itself: Jacob Boerema and Anders Jonsson.
4 contributors worked on translations: Rodrigo Lledó, Anders Jonsson,
Jordi Mas and Piotr Drąg.
Finally the work on the macOS repository should not be forgotten, thanks
to our new packager, Lukas:
1 contributor with more than 60 commits (Lukas Oberhuber).
2 contributors with 1 to 2 commits: Jehan and Andreas Scherer.
Other packages made by third-party are obviously expected to follow
(Linux or *BSD distributions’ packages, etc.).
ℹ️ Fun fact: we learned that GIMP was successfully built on Haiku
OS (yet
another operating system, not a mainstream one) and is now provided
through their packaging system. Even though we know it well, it always
amazes us how cross-platform GIMP is as it can be found on nearly every
operating system (yes GIMP is on GNU/Hurd too from what we are told!)
and micro-architecture there is. 😊
This release is quite heavy on API-side updates, which is one of the big
blocker for GIMP 3.0 release (still some work-in-progress on this side).
The “link” concept was also an old concept which needed to disappear for
GIMP 3.0, so this is one less blocker as this change is now completely finished.
The GTK port is another big blocker; important work in this direction
has been started by some contributors regarding a move to the
GApplication and GtkApplication frameworks and the GAction port.
These patches are still heavily under work and need review thus it has
not been merged in any form in GIMP 2.99.10. We will most likely have
the opportunity to talk more about it on the next release.
Meanwhile work related to Wayland and macOS support are still taking
quite a bit of developer time as you can see.
While we are ending 2021, let’s sum up the year. For my first year as
co-maintainer, I thought it would be a good idea to write this report in
my name so that I can give personal impressions of how it is to work on
GIMP and what it means to me.
4 stable releases (GIMP 2.10.24, 2.10.26, 2.10.28 and 2.10.30)
2 development releases (GIMP 2.99.6 and 2.99.8).
1179 commits on the unstable development branch (2.99.x, future
3.0) and 407 commits on the stable development branch (2.10.x) of
the main repository.
91 contributors on the main repository, including (some people belong
to several categories):
41 developers
42 translators
24 contributors to resources (icons, themes, in-code
documentation) or build improvements.
22 people contributed more than 10 commits in the main repository,
among which 2 contributors did more than 100 commits (Jacob Boerema
and myself), among which only one (myself) did more than 500.
247 commits to GIMP’s website (gimp.org, i.e. right here) by 14 contributors.
1179 commits to ctx by 3 contributors
(mostly Øyvind Kolås).
255 commits in gimp-help (our manual), whose main contributor is
Jacob Boerema who is doing an awesome work reviving it.
53 commits in gimp-macos-build (our repository for the macOS build)
by 4 contributors (mostly by Lukas Oberhuber who took over
maintainance of the macOS package).
185 reports fixed in our 2021 releases and hundreds more
handled, triaged, answered to, worked on…
Many patches contributed by GIMP contributors in various other
projects we use (GLib, GTK, Cairo, GExiv2 and others… We don’t keep
track) and an uncountable number of issues reported by our
contributors to other projects.
Helping (or getting helped by) other Free Software when we
can, e.g. the very nice Siril project for
astronomical image processing and other software, because unlike what
some think, we are not in a market or a competition! We all work
together to make a better graphics work environment.
And more!
In the end, that’s quite a lot of work proudly brought to you by GIMP.
As you may notice, we have quite some contributions, yet the core work
is still actually done by a handful of people as most contributions
are one-off (out of the 91 contributors, 69 contributed less than 10
commits, and among these 51 contributed a single commit).
I want to commend Jacob Boerema in
particular who is the biggest contributor this year on the stable
branch, while I must admit I mostly focus on the development branch and
sometimes tend to neglect a bit the stable branch 😒! Thanks Jacob! 🤗
And we should never forget babl, GEGL and the new project ctx by
Øyvind Kolås as these constitute the core of GIMP imaging engine and are
considered as much a part of GIMP project as the interface itself.
You might have noticed a regular section for the last few news titled
“Team news” where we list changes in the team, in particular new
contributors who are given more access to the tracker or the source
repository. I have been trying to be more and more proactive into
integrating people into the core team.
Indeed as you saw in the statistics, Jacob Boerema is the only other
contributor who did more than 100 commits in 2021, while I did a bit
over 500. So I want to improve this ratio and increase the bus factor.
GIMP team has always been very welcoming, at least ever since I started
contributing, back in 2012 and this is even why I stayed back then. I
want to perpetuate this tradition. My goal is to identify faster the
people to give more responsibility to (note that technical skills are
important but social skills — in other words being a good person and
nice to others — is my priority checkbox). Well it’s definitely an evil
trick 🦹 to lessen my own burden, but I also expect this to make it way
more fun 🎡 contributing to the project (based on personal experience)!
Therefore let me give special props to Jacob Boerema for his tireless
work on file format support and more, Niels de Graef for his invaluable
help and good expertise with GTK, Luca Bacci for his very nice work on
input device support, helping on Windows and his GTK expertise, Daniel
Novomesky for making HEIF/AVIF and JPEG-XL first-class formats…
Let’s not forget recurring contributors such as Massimo Valentini, Lloyd
Konneker… (what would we do without these people never giving up on GIMP,
years after years?!) and promising newcomers like Stanislav Grinkov.
Now let’s applaud our packagers: Jernej Simončič has been around in GIMP
for as long as I could remember, flawlessly making Windows installers
like a solid rock to rely on; macOS history is bumpier yet Lukas
Oberhuber has been doing an outstanding work lately so I sure hope he’ll
stay around; on Flatpak side, Hubert Figuière helps quite a lot too (and
I secretly 🤫 hope he will end up taking over me maintaining our
stable, beta and nightly flatpak-s!).
At the end of the day, GIMP is much bigger than just developers, it’s a
community. What would we do without people helping for the website, bug
triaging, infrastructure and more? And let’s not forget the translators,
so many of them! I just love all of you! Sorry that I cannot just name
everyone (in case I forgot you, don’t take it the wrong way, there are
just so many awesome people around!).
What I like to tell everyone is that GIMP is both a community software
and Free Software, or simply a Community, Free Software. This double
concept is extremely important to me and this is why I love GIMP and why
both Aryeom and I (from ZeMarmot projet,
from which our heavy-lifting contributions really started) stuck with
it. This is about humans meeting each others and trying to do something
nice together (even though each’s personal end goal might be different).
Everything works wonderfully as long as we remember to be good to each
other. 🤗
Therefore to all contributors (of any specialties) who helped GIMP so
far, I want to say a huge thank you! GIMP is what it is thanks to you! 🙏
With 4 development versions released already, you know that we are
working very hard on the future: GIMP 3.0.
Some features took a lot of time, mostly when we changed core logics. I
am thinking in particular about the code for multi-selection of layers.
It’s not that selecting multiple items in a list is hard to implement,
it’s that any feature in the whole application has been forever
expecting just one layer or one channel selected. So what happens when
there are 2, 3 or any number of items selected? Every feature, every
tool, every plug-in and filter has to be rethought for this new use
case. This is a huge work and it has been 2 years I have been on and off
on this one in between porting or developing other code and reviewing
contributors’ code. Fortunately this change is nearing the end lately
(not completely finished though).
So that’s a great progress.
By the way, a part of this work has been to get rid of the “link” (chain
⛓ icon in the Layers dockable) concept in favor of multi-selection
(and layer search and storage as a replacement concept for the ability
to save layer links). This part is also done now. I’ll talk more about
this in the GIMP 2.99.10 release news.
Link concept replaced by multi-layer search, lock icons moved - GIMP dev branch
Among other blockers which I listed a year
ago, we are
steadily progressing on our GTK3 port and Wayland support as well as
stabilizing the plug-in API. I do hope these will be considered in a
good enough state soon enough so that we can consider having a release candidate.
On the other hand, the space
invasion
has been a bit on the slow pace in 2021 so this is definitely one topic
we need to get back full-on very soon. Same for the extension
platform.
The core 🫀⚙️ of modern GIMP is GEGL, a library project
nearly as old as GIMP itself, by the same core of people, even though
the first tentative integrations only happened in GIMP
2.6, and since
then slowly making its way to be the main engine behind most pixel
manipulation in the software.
GEGL development has been slowing down a bit since 2019, but mostly
because it is becoming stabler by the day, which is really when things
are getting good, solid and interesting.
Now it would still be unfair to forget talking about the recent support
of the CMYK color model in GEGL, which means we are a step closer to
get some support in GIMP itself.
Another exciting thing is the new project Øyvind Kolås has been working
on these days: ctx, a vector graphics library.
Now I know it may not sound as useful when you develop a raster graphics
application, but there are still a lot of intersecting topics. One of
these topics is the graphics interface itself which is usually rendered
out of vector primitives. In GTK case, the rendering is going through
Cairo. Øyvind has been working a lot to both render nicer and
faster than
Cairo, or similarly, on many cases. ctx also has color-management
thought into the framework from the ground up as a first-class citizen.
Of course ctx is still heavily under work as can be seen by the
intense commit rate so we’ll have to see where it goes, but this is for
sure exciting since Øyvind is a well-proven excellent R&D developer.
There are other areas where ctx is useful, such as the few GEGL
operations with vector components which have already been ported to this
new library (e.g. gegl:fill-path) and text itself is usually rendered
through vector shapes (so who knows what might happen when we improve
text support?). GIMP is not going to refocus on vector graphics anytime
soon, but we may definitely get more vector-related features as we go
(anyone who follow a bit ZeMarmot‘s work knows that we are really
looking into improved ways for SVG integration for instance, such
as in my early, not merged yet, link layer
experiment).
When we do more vector work, ctx will definitely be a top contender.
I can already hear Øyvind telling me that ctx is actually much more
than these few areas I summed up here. So let me be sorry in advance,
Øyvind! This is why this report is in my name, taking into account my
own limitations in understanding your bigger plans, and looking forward
to be pleasantly surprised and amazed in the future! 🤯
In all software projects, there is a constant which is mostly invisible,
yet extremely important: infrastructure.
You might have noticed we did speak a bit more than usual about this in
2021 because it has really been something which used to bother me in my
early years contributing to GIMP. I always thought we needed more
robust, automated and transparent builds (which is getting there for
Windows,
macOS
and Linux with Flatpak), better download mirrors
handling,
better continuous
integration
in general, better end-user documentation (Jacob is on it! And we have
plans to get a more automated release and online testing policy of GIMP
manual, which should happen in 2022)…
We also had some work done in 2021 around developer documentation:
Akkana Peck (well known for having written
books on GIMP) and Lloyd Konneker helped set up some initial
documentation to port plug-ins and script from 2.10 to 3.0. Akkana also
jump-started generating API references for the Python and Javascript
bindings (with g-ir-doc-tool). Then very recently Niels De Graef
migrated our generic API documentation generation from gtk-doc to
gi-docgen, producing much more modern web documentation for plug-in
developers. None of these are online yet, only built within the source
repository for the time being. Getting an online update procedure for
these is also on the TODO list.
New API documentation for plug-in developers - GIMP dev branch
All these topics take a lot of time and are also necessary to get a much
nicer experience using GIMP. So I am already quite proud of what
we did in 2021 and really excited about our 2022 plans.
You might wonder now: when will GIMP 3.0 be released?
Nope sorry, as always, we don’t answer such question. 😛
What we can say is that we are hard at work for this to happen and for
sure I’d like it to be earlier rather than later.
As said above, apart from the code itself, I also want us to get our
new online manual infrastructure improved before the release, but also
our extension framework ready as well as a brand new developer website
with documentation and more.
So the plans are actually quite extensive and it’s not only within GIMP
code itself (though code definitely needs more work too).
We’ll see how things go from here!
Several file format supports were updated with fixes or improvements:
AVIF, HEIF, PSD, DDS, RGBE and PBM.
Let’s highlight in particular:
PSD support received various types of improvements allowing it
to load more sub-cases of PSD: layer masks tagged with invalid
dimensions, CMYK without alpha, CMYK without layers, merged image of a
16 bit per channel RGBA which had opaque alpha channel etc. In case
of CMYKPSD files, for now, GIMP will convert to sRGB to allow to view
the contents of a file rather than display a message that the file
is not supported.
Some backends got reworked to follow OS evolutions:
Backport of selection outline drawing reimplementation from GIMP
2.99.8 for macOS Big Sur and over (already discussed
patch,
itself exceptionnaly backported to the 2.10.28 DMG package so that
macOS users enjoyed visible selections earlier).
On Windows, we moved from GetICMProfile() to the
WcsGetDefaultColorProfile()API because the former is broken in
Windows 11. Thus we were failing to get monitor profiles.
On Linux and other OSes which might use Freedesktop portals, we
implemented color picking on display (Colors dockable) with the
Freedesktop API when available, keeping old implementations as
fallbacks.
Screenshot plug-in now also uses in priority the Freedesktop API
rather than specific KDE or GNOMEAPI (which are getting restricted
for security reasons since KDE Plasma 5.20 and GNOME Shell
41).
Various improvements were made on metadata support, be it on core code
as well as in the metadata plug-ins (viewer and editor).
A noteworthy fix is that the text tool won’t follow anymore the subpixel
font rendering choice from system settings. Subpixel rendering is for
GUI on a screen of a specific type and pixel order and is not suitable
for image contents which can be zoomed in or out, showed on various
screens or even printed. This change also depends on a patch we
contributed to Cairo which will be available in their next release (we
include the patched version in our flatpak).
Luca Bacci is now a core developer with git access, acknowledging his
very nice contributions so far.
Lukas Oberhuber, our new macOS packager, was given “reporter” access
on the main source repository which allows him to help triaging on the
bugtracker: labelling, closing, reopening, and moving reports…
Among the 82 languages for which GIMP is available, 14 translations were
updated: Brazilian Portuguese, British English, Catalan, Croatian,
Finnish, Italian, Latvian, Lithuanian, Polish, Portuguese, Slovenian,
Spanish, Swedish and Ukrainian.
The Windows installer now contains Portuguese localization (from
Portugal, it already had Brazilian Portuguese), making it available in
35 languages.
Also some previously announced translations were missing in the
installer. These should be fixed now.
Translators on GIMP 2.10.30:
Anders Jonsson, Aurimas Černius, Bruce Cowan, Bruno Lopes da Silva,
Daniel Mustieles, Hugo Carvalho, Jiri Grönroos, Jordi Mas, Marco Ciampa,
Matej Urbančič, Milo Ivir, Piotr Drąg, Rodrigo Lledó, Rūdolfs Mazurs and
Yuri Chornoivan.
As usual, this release is supplemented with the release of
GEGL 0.4.34 the same day as GIMP 2.10.30.
There have been some build related improvements, such as moving the
implementation of ctx from the main GEGL
library to one of the runtime loadable operation bundles. In operations
the robustness of gegl:ripple and the gegl:magick-load powered
fallback have been improved.
Contributors to the GEGL release:
Anders Jonsson, Asier Sarasua Garmendia, Boyuan Yang, dimspingos,
Gavin Cui, Hugo Carvalho, Jehan, Jordi Mas, krzygorz, Lukas Oberhuber,
Marco Ciampa, Matej Urbančič, Øyvind Kolås, Rodrigo Lledó, Rūdolfs
Mazurs and Simon McVittie.
The Linux flatpak, Windows installer and macOS DMG package are already
available and nearly all mirrors fully synced up, in less than a day
from source release to binary release. This may be our new record of a
perfectly timed release!
While the development branch is getting most activity, we don’t forget
the stable branch. This release contains several fixes which we really
wanted to get out there, so we recommend everyone to update.
We are not sure we will be able to do a development release before the
end of the year, so we wish you already a wonderful holiday season! 🎄🎉
Everyone is asking us if GIMP is vulnerable to the recent log4jvulnerabilities
(also dubbed “log4shell” in the media, in particular regarding to the
CVE-2021-44228
zero-day vulnerability).
As an official statement: no, GIMP is not vulnerable to log4shell!
We do not use log4j and there is not even any Java code in GIMP. So
enjoy GIMP and feel safe while creating more wonderful artworks 🖼!
Fixed regressions in recent macOS versions (selection outlines and slowness)¶
Ever since the Big Sur release a year ago, macOS users have been
experiencing regressions such
as invisible selection outlines (a.k.a. “marching ants” 🐜) and general lack
of responsiveness. These would happen for everyone using GIMP on macOS Big Sur
or newer, whatever GIMP version (some people reported these issues even for old
GIMP 2.8 packages). This was caused by changes in the operating system itself.
The slowness issue had been mostly worked around by Des McGuinness, our
previously very active macOS package maintainer, though GIMP’s responsiveness
may still not be on par with other platforms.
We recently fixed the selection outline visibility issue
as well and then backported the fix to GIMP 2.10.28 DMG package! Therefore
we encourage everyone still having this issue to use the latest package, either stable 2.10.28 or the unstable 2.99.8.
Our new macOS package contributor, Lukas Oberhuber, has been working
very hard to improve the packaging scripts, clarifying the process by
merging two repositories in one, getting rid of various useless files and
build rules and directly using modules of the upstream gtk-osx project
(when possible) rather than duplicating rules.
He simplified our gimp-macos-build
repository a lot, which should hopefully lower the entry barrier.
Finally, he fixed several bugs and environment code directly in the GIMP
codebase to bring our development code up-to-date with macOS support.
As a consequence, Lukas is now officially a new co-maintainer of the
macOS package. Welcome and congratulations, Lukas! 🥂
There are still serious macOS-specific bugs in both the stable and the
development series. They are being worked on by Lukas who is supported by the
core team, yet there are limits to what a single person is able to achieve.
For at least the past 10 years, GIMP has not been able to have two active
macOS developers at once. In fact, this is the second time this year that we
publish a macOS-only
news post, which is not a good sign at all. It means being able to release
improvements for this operating system is exceptional enough that we feel like
we should inform people.
So we re-iterate our call for contributors. Do you like GIMP? Do you use
macOS and have technical knowledge and skills for packaging and/or
development? Then please consider joining us!
We’ve detailed the building process in the README.md file of the
gimp-macos-build repository. This is the first thing potential contributors ask us about.
Once you make sense of our build scripts and are able to compile your
own local copy of GIMP, please talk to Jehan or lukaso on IRC (#gimp
channel on GIMPnet - irc.gimp.org),
though others may be able to help too of course. If you already have specific
solutions to existing problems, we can push your patch to a branch and generate
a new DMG build for testing.
As usual, we hope that macOS support will improve and that we won’t feel
the need to make dedicated news again. In the end, it depends on macOS
users, since GIMP is a full community Free Software. It is what we all
make of it, together. The community has many Linux and Windows
developers. We also get regular *BSD and even Hurd patches (seriously).
How come we barely get any macOS developers?
Having M1 support is also a topic we have been discussing obviously. It
will likely require more stable contributions for this to happen. So come in
and contribute, everyone, it might be cold ❄ outside, but it’s warm 🔥
in here.
The Clone, Heal and Perspective Clone tools now work when multiple
layers are selected. There are 2 new modes in particular:
When sourcing from multiple selected drawables then cloning into a
single drawable, the pixel source is the composited render of source
layers. This is similar to “Sample Merged”, except that it is limited
to a list of drawables and you don’t have to hide the layers that you
don’t want to source from.
When cloning while multiple drawables are selected, each
drawable clones from itself to itself, i.e. every drawable is both its
source and target (the layers selected when sourcing do not matter
in this case). This can be very useful in particular when you need to
heal several layers exactly the same way, for instance when working on
textures and various texture mappings.
Development of this feature was proposed and financially supported by
Creative Shrimp: Gleb Alexandrov and
Aidy Burrows, well-known Blender educators. Here’s an excerpt from a new
course where multi-layer cloning is already used:
Extract of a video course by Creative Shrimp (Gleb Alexandrov and Aidy Burrows)
Windows drawing logics evolved in recent compositing window managers. In
particular, the drawing of image selection (marching ants 🐜
representing your selection boundary) broke on Wayland, as well as on
macOS since Big Sur release. The selection tools were still perfectly
working but the outlines were simply not visible on the canvas anymore.
We fixed this by reimplementing part of how selections were being drawn
over the image. We aimed to only fix this for Wayland, but our recent
macOS contributor (see below in macOS package section) confirmed
it also fixes the issue for Big Sur. Now the next step is to backport
this fix to the stable branch (only for the sake of macOS, since the
stable GTK2 version uses XWayland and thus doesn’t exhibit the bug).
There have been two more Wayland-specific changes. For our Flatpak builds,
we will now use the new fallback-x11 permission instead of x11
to prevent unnecessary X11 access while in Wayland, hence improving
security step by step.
Finally, some people reported huge memory leaks under Wayland only (it
was fine on X11). We didn’t do much so we can’t take any credit for
this, but this seems to have been fixed, probably in a dependency with
Wayland-specific code.
Wider coverage of input devices thanks to Windows Ink support¶
Windows Pointer Input Stack (Windows Ink) support was recently added
to GTK3 by Luca Bacci, who also made it available in GIMP and added a
new option in the Preferences dialog to switch between Wintab (older
API) and Windows Ink. You can find this option on the Input Devices page.
Pointer input API selection — GIMP 2.99.8
This is a huge milestone for artists using Windows since more graphics
tablets or touch devices come with Ink support as a default whereas the
legacy Wintab interface requires specific drivers.
This is even more the case with Windows 8 and newer, for which most
tablets should work out-of-the-box with Windows Ink.
Clicking anywhere on the toolbox or on Wilber’s drop area now returns
the focus to the canvas (similarly to the Esc shortcut). This allows
you to work on canvas with shortcuts more efficiently.
For instance, you could pan directly with the Space bar without having
to click on canvas (hence activating a tool) when your keyboard focus was
previously on some text input widget, by clicking anywhere on toolbox
(buttons and dead area alike) first.
After years of discussions and bug reports, we dropped the thumbnail icon
feature. Previously, when images were opened, the application icon in
the taskbar would combine a preview of the active image and the actual
application icon (Wilber). The icon would then change whenever the
active image changed. For many people, this complicated locating GIMP’s
window among windows of other running applications.
Moreover, due to recent changes in desktop environments’ behavior, this
feature was actually working on less and less platforms. So depending
on your OS and desktop environment, it either didn’t work at all or
actively worked against you. This is why we decided to do away with it.
Improved file formats support: JPEG-XL, PSD/PSB, and more¶
JPEG-XL is now optionally supported thanks to Daniel Novomeský
who also previously contributed to HEIC/AVIF support.
GIMP can load and export JPEG-XL files (.jxl) in grayscale and
RGB, with color profiles support. Our exporting code also provides
a “lossless” option and several “Effort/Speed” encoding values.
JPEG-XL exporting options — GIMP 2.99.8
This plug-in is different from the third-party plug-in that is part of the libjxl library
that we use too. It supports GIMP 3 plugin API, reads grayscale images
as grayscale, is written in C rather than C++, and exposes several presets
for speed/quality tradeoff. We also do not yet expose features that could be
considered experimental. If you are interested in JPEG-XL support
for GIMP 2.10.x, please use the plug-in from libjxl.
We also improved support for Adobe Photoshop project files. GIMP now
supports larger-than-4GiB PSD files and loading up to 99
channels (specs say that 56 is the max but some sample PSD files have
more channels).
Additionally, now you can also load PSB files which are essentially
PSD files with support for width and height of up to 300,000 pixels.
There have been even more changes to file formats support and plug-ins:
16-bit SGI images are now supported (until now, they were loaded as 8-bit).
The WebP plug-in was ported to the GimpSaveProcedureDialogAPI.
Script-Fu now handles GFile and GimpObjectArray types.
Our API for
plug-in developers got the following improvements:
New gimp_display_present() function to present a specific display at
the top of the image display stack.
New gimp_export_thumbnail() function to query the user settings
(added in “Image Import & Export” page of Preferences in this
version) on whether or not a file plug-in should export the image thumbnail.
New gimp_procedure_dialog_fill_expander() function to create a
GtkExpander in procedure dialogs.
All widgets within a same container in a GimpProcedureDialog are added
to their own GtkSizeGroup for better aligned generated dialog, yet
only within their own level of widgets.
Several contributors including Andrzej Hunt and Massimo Valentini started
chasing small memory leaks with code analyzers, which is a very nice way
to spend your downtime. We recommend! 👍
We wrote rules for the continuous integration platform to create installers.
This is very useful for users who want to test new unreleased features
and bug fixes. Installers are being created once a week because the full process takes ca. 2 hours and we didn’t want to trigger it too often.
If you want to test the latest installer for Windows, here is how you
can do it:
Go to GIMP’s scheduled pipelines
listing
and click the “Last Pipeline” ID listed next to the Windows
installer item.
Select the job named “win-installer-nightly”
Click the “Browse” button
Navigate to the build/windows/installer/_Output/ directory
Finally click the gimp-2.99.*-setup.exe file to download and install it.
This procedure or any updated version of it is available in the
“Automatic development builds” section of the download
page.
⚠️ Be warned that a weekly installer is a purely automated build,
there is no human verification. It is happening at a semi-random time
during the development process, you may end up with very broken software
at times, even though we try to never leave the repository in a dire
state. It is even less safe than development releases. We are grateful
for feedback and bug reports. Just please don’t expect these builds
to be rock-solid or even usable. ☢️
Additionally to the weekly installers, our continuous integration
platform will now also generate the installer when a new release is
tagged. This should allow for much faster installer releases, within
hours instead of days in the former fully manual process.
The only part of the installer creation process that is not automated
is applying the digital signature. Digital signing will be done manually
by our long-time Windows installer maintainer, Jernej Simončič. He will
download and verify thoroughly the installer before signing it. So you
are getting the best of both worlds: automation builds and human-verified software.
Note: this semi-automated release process is only for our development
branch; it will be used in the stable branch when we will release GIMP 3.0.
We also added some additional tests for verifying installer script consistency. In particular, translations are handled by the
GNOME translator teams, and we
sometimes get translations into a new language that is not yet properly
listed by the installer. A few times in the past, we did announce a new
installer language which users could not find in the actual released
installer! 😅
Our continuous integration platform will now warn us when such a case
happens again, so that noone’s work would be wasted and all new
translations would be properly used by the installer.
Similarly to the Windows installer nightlies, GIMP now gets a weekly
flatpak, i.e. a flatpak built out of development code, entirely
automated, a work initiated by Ondřej Míchal.
Install the “nightly” repository to get our weekly updates with this command:
If you installed both the stable, beta (development releases) and
master (weeklies) repositories, your desktop will only see one of them
at any given time. You can select exactly which version it sees and start
with the following command (e.g. selecting stable as default):
flatpak make-current —user org.gimp.GIMP stable
Then if stable was made to be your default flavor of GIMP, you can run
the other versions with the following command (e.g. the weeklies):
flatpak run org.gimp.GIMP//master
This information is also available on the downloads page.
⚠️ Please keep in mind that a weekly build is purely automated, there is
no human verification, it happens at semi-random time during the
development process. Hence you may end up with very broken software
at times even though we try to never leave the repository in a dire state.
It is even less safe than development releases. People are welcome to
test our weekly builds to help us with feedback and bug reports, but you
should not expect these builds to be any close to stable software or even
usable. ☢️
Finally, there’s some exciting news for macOS users: we were recently
joined by a new contributor, Lukas Oberhuber, who started working on the
development package. Lukas already has a working local build, he is
currently tweaking the remote automated build. So we might finally have
our first macOS development release (hopefully for GIMP 2.99.8) soon.
Lukas also contributed fixes to GIMP source code to better support macOS.
While this is excellent news, it does not invalidate the call for more
macOS contributors we have made many times before. A single contributor
(furthermore for both packaging and development!) is a very low bus
factor. The more
contributors, the better, so if you want to help to ensure
sustainability of macOS packaging, you are still very much welcome to join!
To facilitate in-review code testing, we now provide automatic builds
for merge requests. If you are planning to contribute a patch using
this Gitlab feature, please add the 5. Windows Installer and/or
5. Flatpak package label to a newly created merge request. This will
trigger building a Windows installer and/or a standalone flatpak.
We expect this to be helpful for testing new features and bug fixes.
GIMP source repository now provides a very nice first draft of Coding
style guide
written by Stanislav Grinkov. The new guide combines guidelines
formerly available in the HACKING file and information passed down
through discussion channels like IRC, patch reviews etc.
We expect this draft to receive further improvements as we do love
very neat and organized code. In any case, this is a great start!
The Linux development flatpak has already been published so that
anyone who installed it previously should have an update proposed by
their software manager (or from terminal: flatpak update
org.gimp.GIMP//beta).
Daniel Novomeský is now a core developer with git access, for their
continuous contributions to the HEIF/HEIC/AVIF plug-in as well
as the brand new JPEGXL plug-in.
Code contributors on GIMP 2.99.8: Andrzej Hunt, Daniel Novomeský, Des
McGuinness, Ian Martins, Jacob Boerema, Jehan, Jordi Mas, lloyd
konneker, Luca Bacci, Lukas Oberhuber, Marc Espie, Marie-P, Massimo
Valentini, Mayank Suman, Michael Bazzinotti, Michael McLaughlin, Michael
Schumacher, Niels De Graef, Øyvind Kolås, Pavel Artsishevsky,
programmer-ceds and Stanislav Grinkov.
Build contributors on GIMP 2.99.8: Andre Klapper, Christopher Davis,
Daniel Novomeský, Jehan, Jernej Simončič, lloyd konneker, Luca Bacci,
Marco Spiess, Niels De Graef, Ondřej Míchal, Øyvind Kolås, Stanislav
Grinkov and Trần Ngọc Quân.
Among the 84 languages for which GIMP 2.99.8 is available, 20
translations were updated: Basque, Brazilian Portuguese, Catalan,
Chinese (China), Finnish, German, Greek, Hungarian, Icelandic,
Indonesian, Italian, Lithuanian, Polish, Portuguese, Russian, Slovenian,
Spanish, Swedish, Ukrainian and Vietnamese.
The development Windows installer now contains Portuguese and Lithuanian
translations, making it available in 38 languages.
Translators on GIMP 2.99.8: Alexandre Prokoudine, Anders Jonsson,
Asier Sarasua Garmendia, Aurimas Černius, Balázs Úr, Boyuan Yang, Bruno
Lopes da Silva, dimspingos, Enrico Nicoletto, Hugo Carvalho, Jiri
Grönroos, Jordi Mas, Luna Jernberg, Marco Ciampa, Matej Urbančič, Ngọc
Quân Trần, Philipp Kiemle, Piotr Drąg, Rodrigo Lledó, rofiquzzaki,
Sveinn í Felli and Yuri Chornoivan.
You might have noticed that a lot of effort has been done to improve the
infrastructure these last few months (whether for continuous
integration, testing, automating releases,
mirrors…)
and more has to be done as this was highly needed for the long run. As a
consequence of these infrastructure improvements, this release news was
published a single-day after actual source release, which is a new
record for us (it usually takes days to generate the Windows installer
then to have all mirrors synced)!
Apart from infrastructure, this version is nonetheless a big one with
more than 50 reports closed, 25 merge requests accepted and over 500
commits since 2.99.6.
We are still working hard to finalize the GTK3 port as well as the new
plug-in API. Taking care of technology changes (Wayland on Linux and
macOS in particular) these days is also taking quite a toll in our
development efficiency as we spend a lot of time fixing things which
just get broken because the underlining systems change. Nevertheless we
are quite happy of how things evolve as future GIMP 3 is looking more
and more awesome every day, right? 🤗
As far as we could remember, organizations from all over the world have
supported the GNU Image Manipulation Program by mirroring 🪞 our file
downloads. This is important as we may have to sustain dozens of
thousands downloads a day.
“Mirrored Wilber” by Aryeom, Creative Commons by-sa 4.0
Interdisciplinary Centre for Mathematical and Computational Modelling UW, University of Warsaw
IP-Connect LLC
Korea FreeBSD Users Group
Jaleco
Kumi Systems
Lysator ACS
nbshare.io
Studenten Net Twente (SNT), the University of Twente
UKFast
University of Crete
University of Kent UK Mirror Service
University of Maryland, College Park
XMission
One more mirror request is being processed at the moment.
The always-updated list is on a dedicated sponsor
page. The image above poetically
representating the mirrors, by Aryeom of ZeMarmot
project, will also illustrate this sponsor page.
We recently cleaned out our mirror list per these rules:
We now list exactly the mirrors verified by the infrastructure team,
no more no less. Being verified gives you rsync credentials allowing
faster and safer updates.
See below if you want in.
Mirrors are not listed anymore in the Downloads page
since there is an automatic mirror rotation operating when clicking
the download buttons. Instead we have the dedicated
Sponsors page, which means better
visibility to sponsoring mirrors, all the while simplifying the
download page which used to be over-crowded with information.
We display names of mirroring organization, for instance “University
of XYZ” with a link to the organization website, rather than just URLs.
Note: we had more mirrors either listed on our former download page or
who made reports of interest to be official mirrors across the
years (back then our workflow was much fuzzier). We sent messages to
all of them but are not sure it reached the people in charge. If you
wish to be part of the official list, help shoulder the download burden
and be featured on our sponsors page, please read the procedure below.
Write in title and introduction that you want to be a mirror for GIMP
in particular
Add /cc @Jehan in the request description or in a comment
Fill the relevant fields from the new-mirror template
If you want a specific name and URL to be shown in the mirror sponsor
list, please write it explicitly in the
report (otherwise we will choose whatever organization name and URL
seems the most relevant from what you wrote down)
Once we are done verifying your organization, rsync credentials will
be exchanged securely, allowing you to sync your mirror with the
source server
There is nothing to do in particular to appear on the
Sponsors page which will be updated
regularly through scripts. Yet it may take a few days or even weeks at
times. So don’t worry if your organization name does not appear immediately!
🛈 We programmatically check at random intervals that mirrors are updated
quickly enough and that the data match for obvious security reasons.
We used to list mirrors on
gimp.org/downloads/ on a declarative
basis. People wishing to download were encouraged to pick a mirror
rather than the main download server.
Years ago, we moved to an automatic mirror rotation through web
redirections. In other words, any URL to download.gimp.org/mirror/
automatically redirects to any of the configured mirrors (our own
download server included), hence lowering the burden on all servers
without having people to manually pick a mirror in a boring list.
Yet followup checks were not thorough enough, there were no clear
procedure to give mirror administrators and there were discrepancies
between mirrors listed on the website and the ones actually taking part
in download rotation. These are the changing points.
Listing only verified mirrors has the following advantages:
The infrastructure team makes the background check to verify an
organization is trustworthy.
Mirrors get rsync credentials, enabling faster updates (instead of
through third-parties which may themselves sync from other third
parties, hence avoiding several-day delays).
Our team has an accurate list of mirrors for systematic security
checks of file presence and authenticity. We will react quickly in
case of problem.
Only verified mirrors are added in the download rotation settings,
thus contributing with the bigger chunk of downloads. It is only
normal for them to be featured prominently.
More discussions are going on to improve the procedure and mirror
technology even further by using the Mirrorbits software. More on this
later (and after more extensive testing).
Additionally to mirrors, we would like to 🙏 thank the GNOME
infrastructure team for their invaluable help!
The work on mirrors was a long run background job which was improved by
various people, notably Michael
Schumacher
and Pat David.
These recent improvements to the mirror procedure, making it faster and
safer for people downloading GIMP and easier for contributors as well as
for mirror administrators, were done by GIMP co-maintainer, Jehan of
ZeMarmot project (Liberapay and
Patreon fundings). The goal is to
simplify and automatize as much as possible the process to make our list
of mirrors always up-to-date, more reliable downloads, but also to
verify the mirrors are safe by running automated data integrity
verification scripts.
GIMP 2.10.28 is now released. This is a bugfix release, because we are
giving most of our time and efforts to the development version (2.99.x).
Note: you may have noticed we skipped GIMP 2.10.26. A build bug has
been discovered just after tagging the release. GIMP 2.10.28 is the same
without the bug. We recommend against building and using GIMP 2.10.26.
The Dashboard dockable now has memory support in OpenBSD.
Performance improvements for GIMP on macOS Big Sur were applied in our
macOS packages since GIMP 2.10.22 as experiments. We felt confident
enough to move the code to our main codebase.
The following plug-ins received fixes: C-source, DICOM, GIF, PS,
Sunras, BMP, DDS, PSD, TIFF, Gimpressionist, metadata viewer and
several script-fu scripts as well as the script-fu interpreter itself.
Some accessibility issues in themes were fixed, such as mouse-hover
feedback or problematic colors.
A new Script-Fu function (dir-make) enables to create directories
from scripts.
To get a more complete list of changes, you should refer to the
NEWS
file or look at the commit
history.
Code contributors: bootchk, Des McGuinness, Ian Martins, Jacob Boerema,
Jehan, Lloyd Konneker, Luca Bacci, Marc Espie, Massimo Valentini,
Michael Bazzinotti, Michael McLaughlin, Øyvind Kolås, saul, Simon
McVittie and Stanislav Grinkov.
Theme contributors: Kevin Payne and Stanislav Grinkov.
Build contributors: Marco Spiess and Mario Daniel Ruiz Saavedra.
Jacob Boerema got appointed a new co-maintainer of the manual
repository (gimp-help) after porting its scripts to Python 3 and
improving them.
Stanislav Grinkov is now a new core developer.
Des McGuinness and Lloyd Konneker were given “reporter” access which
allows them to help triaging on the bugtracker: labelling, closing,
reopening, and moving reports…
nmat was given “reporter” access on the website project (gimp-web),
for his tremendous help with website maintenance.
Among the 82 languages for which GIMP is available, 14 translations were
updated: Catalan, Chinese (China), Croatian, Dutch, German, Italian,
Lithuanian, Polish, Russian, Slovenian, Spanish, Swedish, Ukrainian, and Vietnamese.
The Windows installer now contains Vietnamese and Lithuanian
translations, making it available in 34 languages.
Translators on GIMP 2.10.26/28: Alexandre Prokoudine, Anders Jonsson,
Aurimas Černius, Boyuan Yang, Daniel Mustieles, Hannie Dumoleyn, Jordi
Mas, Luna Jernberg, Marco Ciampa, Milo Ivir, Ngọc Quân Trần, Matej
Urbančič, Philipp Kiemle, Piotr Drąg, Rodrigo Lledó, Tim Sabsch and Yuri Chornoivan.
More work than ever is happening around Windows lately, both within GIMP
and the libraries it depends on. Which is how several long-standing issues
with GIMP on Windows finally got fixed:
Very slow file dialogs: it used to happen when network devices were
slow or unavailable, or pluggable devices disconnected, or even
because of fake floppy drives configured in the BIOS. GLib was using
an inappropriate Windows API to get some information about drives.
This has been fixed!
(#913,
glib!2020)
Opening files in specific third-party software was crashing GIMP:
apparently, these applications were editing the file-handling registry
field while GLib had a buggy watcher on the registry.
(#6780,
glib!2205,
glib!2210)
GTK was outputting the wrong character on some keyboard input using
Input Engines (e.g. alphanumeric characters were interpreted as
half-width katakana when using the Japanese IME).
(#1603,
gtk!3741)
TIFF exporting used to lock the TIFF files because of a bug in the
Windows thumbnailer (Explorer.exe would acquire a lock on the file
and never release it). Since Microsoft doesn’t seem to want to fix this
long-standing bug, we decided to switch to another way of creating
thumbnails by adding a “reduced-resolution image” as the second page
of the TIFF, as proposed in the TIFF specification, instead of adding a
subifd thumbnail. This takes care of the lock issue in a nice way,
bypassing Explorer‘s bug. Of course, it means that programs that can’t
reads tags properly might try opening thumbnails as additional pages,
even though it is explicitly annotated as “reduced-resolution image“.
If you ever run into this very issue, please report it to developers
of such programs. What they need to check is the SubFile type of the pages
their software opens (as per TIFF
specification).
(#3740)
GIMP used to prevent some applications to open, when these programs needed
to watch some specific directory, because GLib was reading directory
with inappropriate access rights. Actually, this fix has been available
since GIMP 2.10.24.
(#4594,
glib!1976)
Windows software with invisible windows (e.g. gesture shortcuts,
screen capture and the like) used to interfere with GTK software and
break some mouse interactions. We have had a patch for this, by Ell,
since 2017, which we used for all GIMP 2.10.x
releases. Unfortunately, with GTK2 maintenance stopped, our patch
was only available in the bugtracker and in our binaries, while it was
beneficial to other GTK software, even in GTK3 or newer. It has only
recently been reworked and improved by Luca Bacci so that this problem
is now officially fixed in GTK3 too!
(#1082,
gtk!2767)
In particular, we would like to thank Luca Bacci, Jacob Boerema, LRN, Ell,
and all the contributors who stayed on top of Windows issues for this
progress to happen, sometimes taking years of patience.
On macOS side, the activity is still slow, if not non-existent.
We remind that GIMP is made by you. Yes, you 👆 reading this right now.
Windows developers used to be very few too. As you can see, this is
clearly changing. Therefore, if anyone cares about GIMP for macOS, please
step forward.
You may have noticed that GIMP 2.10.24’s macOS DMG was released months
late. Even this only happened because Jehan spent days to fix the
build on the remote build server, bit by bit, without any local access
to a macOS machine, nor any ways to run and test himself. If the
packagers are still unavailable, we may try to do the same for this
release, though we can’t set a deadline.
It is obviously not a sustainable release model. It is even worse for
the development versions: we haven’t had a single build for GIMP 2.99.x
on macOS yet.
As usual, this release is supplemented with the releases of
babl 0.1.88, early July, and
GEGL 0.4.32 the same day as GIMP 2.10.26.
In GEGL in particular, the following operations were improved:
distance-transform: new edge_handling parameter allows users to
choose whether areas outside the input are to be treated as above
threshold or below threshold (i.e. infinitely white or black
respectively) for calculating distance. (by woob)
negative-darkroom: contrast boost and illuminant adjustment
parameter, reworked emulsion dye model, UI improvements, more
black-and-white paper presets and some operation speed-up.
(by JonnyRobbie for features and Richard Kreckel for speed-up)
fill-path: 32-bit float RGB and CMYK color processing, using ctx as
renderer. (by Øyvind Kolås)
The test system got also some nice improvements by John Marshall.
The Linux flatpak has already been published so that anyone who
installed it previously should have an update proposed by their
software manager (or from terminal: flatpak update org.gimp.GIMP//stable).
The Windows installer is already available. Most mirrors have picked
it up, but some still haven’t. So if the download fails, just try to
click the Download button again.
The macOS DMG package will hopefully be published soonish.
Though we may likely get again exciting new features in further 2.10.x
versions, nowadays most feature development happen in the development
version for future GIMP 3. You may have seen some of it, if you follow
our work on social networks, or if you test nightlies of GIMP.
Otherwise, you will have more surprises when we will release GIMP 2.99.8
development version!
GIMP has been developed as a community effort since very early on, after
its original authors left the project.
This begs the question of sustainability when contributors wish to stay
longer while not being able to afford being penniless volunteers forever.
We have seen skilled developers come and go for years, the latter
becoming a growing concern. Contributing takes a crazy amount of time
and people have family, work and other responsibilities to take care of.
Thus when core team contributors are willing to be paid for making Free
Software, we have decided that GIMP as a project should encourage such
endeavours by putting more emphasis on their funding.
There are currently 2 such crowdfunding projects. You can consider
these crowdfundings as “official” as can be and completely endorsed by
the GIMP project:
Øyvind has been contributing to GIMP since 2004. He soon became
GEGL maintainer, for what was meant to become one
day GIMP’s image engine. GEGL and babl (its companion pixel format
encoding library) already support color management, higher bit depths
and CMYK; some of the non-destructive capabilities are already exposed
as part of GIMP’s on-canvas preview of image filters.
The integration of GEGL started in GIMP
2.8 with a wider
port towards color management happening in
2.10. It is still a
work in progress, with plans for deeper integration of existing and
future capabilities of GEGL in future versions of GIMP as they continue
to get refined and tested.
Øyvind is known not only for his work on GEGL itself, but also for his
various experiments around images and colors. One of his visual
experiments with color grids on grayscale
images
even got viral back in 2019 and spread all over the web on too many news
outlets to name them all.
Color assimilation grid illusion, by Øyvind Kolås
One of his later endeavours is ctx, a vector
graphics stack, which is probably hard to describe as some parts of this
project are a bit mind blowing, so let’s give you the official description:
ctx is a media-rich terminal and a vector graphics stack, built around
a textual serialization protocol. The textual serialization has a
corresponding binary representation that is used by the core
rasterizer as well as sharing data among threads. The ctx protocol is
available as an extension to ANSI escape sequences in the ctx terminal
- the terminal launched when running the ctx binary with no arguments.
This extension allows scripts in any language to output vector
graphics in addition to or instead of monospace text in each
tab/window, and also provides network transparent rendering.
All of this development background is most likely why Øyvind describes
himself as:
I am a digital media toolsmith, creating tools and infrastructure to
aid creation of my own and others artistic and visual digital media experiments.
ZeMarmot is a Libre Art project born as
an idea in 2014, launched in 2015 with production starting in 2016. In
particular, it is an Open Animation short film (Creative Commons
BY-SA license
promoting sharing and reuse) led by the film director, Aryeom, and GIMP
co-maintainer, Jehan.
ZeMarmot project logo
Now you might wonder why an animation film would help GIMP, yet this is
the whole reason why Jehan has been heavily developing the software, to
the point that he became the biggest contributor since 2020 and is now
co-maintainer. Working on other fun projects with Aryeom is even the
whole reason why Jehan started contributing to GIMP at all, ever since 2012.
ZeMarmot is a traditional (yet digital) 2D animation film, meaning a
lot of illustration work (each frame hand-drawn), hence requiring heavy
usage of brush tools, selections, filters, transformation tools,
scripting for automatization and all sort of raster edit needs.
This is why the ensuing development is not only about illustration and
animation, as some might believe. They are not aiming at changing the
scope of the software. GIMP is a generic graphics manipulation tool and
what we have realized over the years is that most features are so
cross-disciplined that it makes total sense to have a generic tool.
Moreover Aryeom and Jehan also work from time to time on printing jobs,
logos, photos, pin buttons, board games… they do all kinds of things
with GIMP!
A lot of care is taken to fix bugs, improve stability, efficiency,
packaging and add generic tools and features useful to photographers,
designers, illustrators, scientists, animators…
Trying to list all the improvements brought by their work would be a
challenge because there are too many.
Nowadays, ZeMarmot is as much an artisanal animation film project
(Aryeom single-handedly working on nearly every production role) as it
is a software development project (both with Jehan on development
and Aryeom on testing and designing features). Aryeom and Jehan believe
that taking ownership of your working tool matters and this why their
collaboration works so well, by bringing together artist and developer.
The nice final touch is that their big dream is to be able one day to
hire more Free Software developers and artists. This project is under
LILA‘s (Libre comme L’Art — Free as
Art in French) umbrella, a France-registered non-profit dedicated to
Libre Art and creative media Free Software.
Imagine in a not-so distant future if we had a non-profit studio
producing artworks in Libre Art licenses, for everyone to view, share
and even modify (source files are provided, e.g. the
ones for this video
they made for Framasoft about
Peertube)
with many artists (hence producing films at much better pace than they
are able right now) and developers fixing production issues.
We can truly consider LILA as GIMP’s sister non-profit Open Animation
studio! And yes, an Open Animation studio producing Libre Art will help
get better tools for photography editing or design as well.
For years, we have received donations
through the umbrella of the GNOME Foundation. It is still possible to do
so of course. Yet these donations are so far only usable for community
needs. In particular, it helps us when we need hardware (not so often),
and to gather contributors for
conferences
(regularly we also help funding the conferences itself, because we
believe that a sane free software graphics ecosystem should not be only
about GIMP so we love to support other graphics software too) and
contributor
meetings.
Note that it is also possible to fund several contributors through GIMP
Liberapay account as an interesting alternative.
What these donations through GNOME still cannot do is funding paid
development, so if that’s what you want, please fund the developers
directly as explained above.GIMP project obviously welcomes the 2
types of donation, for community needs through GNOME and for paid
development through the 2 crowdfundings listed.
Thanks to everyone for supporting GIMP in whatever way suits you best! 🤗
☣️ GIMP 2.99 releases are development snapshots. There are known bugs,
sometimes crashes and definitely unfinished features; that’s why it’s
not yet a final release. Use at your own risk! ☣️
GIMP 2.99.6 contains quite a few visible and interesting improvements,
yet the biggest changes are hidden from the public eye into the quite
steadily evolving API (Application Programming Interface for plug-in developers).
⚠️ Many of the third-party plug-ins already ported for GIMP 2.99.2 or
2.99.4 will end up broken, and there is a high chance they will break
again in further development releases until we stabilize the API. We
apologize for this, though this is the price of making plug-ins for a
program in-development. We figured it’s better to do this now rather
than ending up stuck with a bad interface for the years to come (as
stability will be ensured once GIMP 3 will be out).
Release highlights:
Off-canvas guides
Template selector in Canvas Size dialog
Pinch gesture on canvas for zooming
Improved Paint Select (experimental) tool
Better handling of gAMA and/or cHRM chunks of PNG
API evolution
“Work in Progress (Feel free to grab a tool and help)” by Aryeom, Creative Commons by-sa 4.0 - GIMP 2.99.6
In the continuation of out-of-canvas area
visibility,
guides can now be placed outside the canvas. This was deemed useful for
various use cases when you want to work on bigger areas than your canvas.
For people worried of graphical interaction with guides, the workflow to
delete them (dropping the guides off-canvas) just changed to be about
dropping the guides off-viewport, which turns out to not be so different
after experimenting with this change in production for a few months.
It is common usage to resize your canvas to a standard format, for
instance paper formats. For this reason, our recent and quite prolific
contributor Stanislav Grinkov implemented a template selector
in the Canvas Size dialog.
Template selector in Canvas Size dialog - GIMP 2.99.6
In order to handle the cases when you choose a template with expected
pixel density differing from the image’s, you may be queried to decide
whether you want to set your image to the template’s density or scale
the template’s dimensions to match the image’s density.
This is very fresh news as we merged this code (by Povilas Kanapickas,
brand new contributor!) only a few days ago: GIMP now has pinch gesture
support for touchpads, some tablets or touch screens (it might not work
with all tablets and touch screens). In other words, if you have a
device with touch support, you can zoom in and out through pinching
movements with your fingers.
This is known to work on Linux/Wayland (tested successfully on a laptop
touchpad and a Wacom Intuos Pro) and it might work in a few months in
X11 (after this
patch
gets merged). Someone reported the feature working on Windows 10 too
with one’s touchpad and integrated laptop’s touch display.
We have not found anyone yet to test the feature on macOS (it relies on
generic GTK code, but the exact support depends on specific per-platform
implementation and on the touch device firmware and/or driver
implementation). I guess this will be the surprise for this release. We
welcome any feedback in the associated
report.
As a note of interest, we used to say that gesture
support
was not our biggest priority, hence might not make it to GIMP 3. Yet
here it is! Another great example that GIMP is made by anyone. All it
takes for your dream features to happen is someone willing to contribute
code! It might be you! 🙂
The tool is still listed as experimental as it is not yet deemed
finished by its contributor, Thomas Manni. Nevertheless it has already
improved quite a bit and starts getting really interesting.
Several bugs were fixed and selection is now viewport-based which allows
it to be much faster already depending on the zoom. Yet this is not even
the expected optimization which is planned to make the tool work really
fast. Expect more to come!
This work has been happening both on GIMP code base and on our graphics
engine library’s code base, GEGL.
Copy-pasting Wilber in a few seconds with the Paint Select tool (realtime GIF, faster as zoomed-in) - GIMP 2.99.6
As a side note, the Paint Select tool now has its own icons, original
design by Yash Arya, with collaborative work and design finalisation by Aryeom.
New Paint Select tool icon by Yash Arya and Aryeom - GIMP 2.99.6
PNG: color profile generated from imported gAMA and cHRM chunks¶
The PNG format has several ways to manage colors, one of them is through
color profiles, which is also the logics in GIMP as in any modern
graphics editor. In the PNG specification, the presence of a color
profile is considered priority and overrides any of the other color
management methods.
The other ways were through the gAMA, cHRM and sRGB chunks (a
“chunk” is basically a PNG metadata), where instead of giving a full
profile, a PNG could store its gamma correction as a single value (hence
exact sRGB gamma curve cannot be stored this way, but an approximation
of it can) in gAMA while the primary chromaticities can be stored in the cHRM chunk.
GIMP’s core logics never supported (and still won’t because it is an old
deprecated method which should not be implemented to new code) only
using such a single gamma value. Yet we wanted to be able to read and
display such images correctly.
Our historical workaround was to store the gAMA and cHRM values in a
parasite on the XCF file, and just put it back when exporting to PNG
again which means that the image was wrongly displayed in GIMP itself
but fine after export.
Now GIMP will propose creating an actual ICC profile from the gAMA and
cHRM chunks, thus the image will be properly displayed. Since we don’t
store anymore the PNG chunks, the “Save gamma” export option has been
removed from PNG export dialog. Only proper profile is supported now
(i.e. an old-style PNG image which goes through a roundtrip
import-export in GIMP will come in with gAMA/cHRM chunk and out with an
equivalent ICC profile). Note that it is also recommended by the PNG
spec to export with ICC profiles when a encoder software supports
it.
Generating a color profile from PNG gAMA and cHRM chunks - GIMP 2.99.6
Note: a crash cause has been discovered in babl when opening indexed
images with embedded color profiles. Since we are now creating color
profiles when a PNG had these chunks, this change can provoke this
crash.
Fortunately a patch has already been
written, and
we expect it to be present in the next version of babl.
Our screenshot plug-in has several implementations and used to always
display a dialog. Nowadays with portals on Linux (especially for
Wayland and sandbox-style packaging), more of the logics is moved
toward the portal itself. This is the case in particular for the
Freedesktop portal which asks what and how to shoot your screen
contents. Therefore when GIMP uses the Freedesktop portal, it won’t
show anymore our now-redundant dialog.
Color profile and comment are now saved on each layer of an exported
TIFF file to prevent any ambiguity for other programs (since every
layer can have its own profile and comment in the TIFF format). As
usual, while GIMP tries to be lenient on errors in files it imports
(allowing to salvage even broken files), it should be strict on its
own exported files.
Other plug-ins got some minor improvements, such as progression
feedback during PDF export, multi-layer selection support in PSD,
Qbist ported to the new API…
Work continued on GUI generation for plug-ins, allowing to generate a
GTK dialog in just a few lines of code (options being introspected
from the plug-in procedure’s arguments).
Plug-in procedure’s default argument used to give a single image and
drawable. It was changed to give an image and an array of drawables,
since now GIMP has multi-layer selection ability. This is the main
reason why most plug-ins out there which used to work on earlier
2.99.x versions will break. Sorry about this, it’s for the greater
good and goes with the new abilities of GIMP for better handling of
complex images!
Some more work is also ingoing on the concept of a plug-in procedure’s
“sensitivity”, i.e.: when is the plug-in usable? Up until GIMP 2.10.x
series (and even in the first development releases 2.99.2 and 2.99.4),
plug-ins were sensitive when an image is opened with a single drawable
selected. Now with the new multi-selection abilities, it became clear
that maybe you want a plug-in which works also on several layers at
once, or even only when several layers are selected! And what if
you wanted a plug-in which doesn’t care if an image was opened at all?
We therefore added a new function to set the sensitivity cases for a
plug-in, though we are already thinking on improving this even further
(which is why we are not going to name the function here and we don’t
advise to use it yet if you find it).
Moreover many functions have been renamed for consistency, and also
sometimes avoiding some name clashes on language binding generation,
such as gimp_parasite_name() becoming gimp_parasite_get_name().
Here is the list of updated function
names in
GIMP 2.99.6.
“Parasites” (which is the technical name for random data attached to
an image, a layer, or to GIMP itself) are now usable as plug-in
procedure arguments. While this seems like a weird change, it is
useful when you want to store random data (even binary data) between
several GIMP runs. We already use this trick in the QBist plug-in from
default plug-ins.
Many more changes happened on the API, you may have a better overview by
checking the
NEWS file,
though even this file might not be exhaustive (in case we forgot to note
some changes!).
Since we released a stable version not long ago, GIMP 2.99.6 relies on
the same versions of babl 0.1.86 and
GEGL 0.4.30, which is getting stabler as time goes.
The Linux flatpak has been published so that anyone who installed it
previously should have an update proposed by their software manager
(or from terminal: flatpak update org.gimp.GIMP).
The Windows installer is available on the download page.
Note: we realized a few changes listed in this news post were not
integrated in the last 2.99.6 installer (like the Hebrew translation
of the installer and the Paint Select tool). Expect us to add these in
a further installer!
We are not sure yet when we will be able to publish macOS DMG packages
for development versions. It depends on contributor time and
willingness. We also remind that our team is fully made of volunteers
so if you wish to help on macOS side (or anything else), we will
welcome you with opened arms! 🤗
Let’s also take the opportunity to thank all past and current packagers.
Without them, GIMP would be a lot less easy to install, right? They are
also doing a core contribution to the community!
Lately, a lot of the focus has been on the application interface (libgimp), which we are still tweaking in order to provide the best
plug-in interface possible, based on 25
years of shared
community experience. Even though this part is not very visible, it is
important because we ensure major API version stability, i.e. that any
API change after GIMP 3.0 release can only be incremental, cruft over
more cruft. This is our one chance to do things better (as well as we
can, errors will be made of course, but let’s keep these limited).
Even for non-developers, a good API will mean that you will be able to
install many useful plug-ins in the future.
On GTK3 side itself, the port of GtkAction is still the main big
remaining area. Some serious Wayland issues remain to be investigated,
the space invasion is ongoing, and so on.
Even though some progression has happened on most topics, the development
report we
shared a few months ago is still quite accurate.
As usual, we won’t give any type of deadline or release date for GIMP
3.0. We don’t know ourselves, and because it depends on volunteer time,
we can’t know.
We are very happy to have seen some new talented contributors these last
few months (hopefully they will stay with us for a long time). We would
enjoy getting more so if anyone wants to help, you are more than welcome
to join the fun! So please “grab a tool!” as Wilber proposes you to do
in the above comics strip! 👷
Finally, please don’t forget you can donate to the project and personally
fund several GIMP developers, as a way to
give back and accelerate the development of GIMP.
As a community project, GIMP is indeed able to continue only thanks to
contributors giving their time.
This is why we have recently updated the donation page to put an
emphasis on the importance of funding the developers in order to
ensure the project sustainability.
Though there are various fixes in core code, this change is probably the
most worth mentionning. Ever since GIMP 2.10.14, we are now able to see
the out-of-canvas
area.
Consequently, many features can now work outside the canvas, yet not all
features yet. This change is the continuation of this work, allowing you
to snap various tools to guides, grids or vectors, even outside the canvas.
Snapping to guide/grid/vectors off-canvas made possible - GIMP 2.10.24
A lot of work has been going on in the metadata area, mostly
consolidating our support and fixing many issues.
The metadata viewer and editor also received a lot of love, making them
more robust to various edge cases, such as duplicate tags, but also
mapping equivalency between similar IPTC and XMP tags, better encoding
handling, and so on.
The GPS data is also handled a bit better with more precision, tooltips
and better formatting.
There are still a lot of improvements to be made in the metadata area
though we are probably on the right path. This part of the development
is not as visible as other, yet this is very time-consuming and
thankless groundwork while being useful to anyone who needs good
metadata support so we’d like to thank Jacob
Boerema who has worked tirelessly on
this for months.
A fun story which started with a conference by Adam Cox of Louisiana
State University about
using GIMP for enhancing historic maps, with the issue that GeoTIFF
metadata tags were lost and made the workflow a bit more cumbersome.
It prompted a bug report then later a patch by the passing contributor
Ruthra Kumar and a review by the core team. All this within 2 months.
And now GIMP is able to import and export back the GeoTIFF tags. Note
that no semantic logics is implemented, i.e. that GIMP can only export
what it imported (the checkbox will only be sensitive on export if there
was GeoTIFF metadata on import). It will not tweak the metadata contents
for you. In particular since it contains georeferencing data, some type
of image transform could make the data meaningless. This is up to you to
know what the data references and how to keep its meaning.
Save GeoTIFF metadata as imported - GIMP 2.10.24
This nice little story shows once again a power of Free Software, which
is before all a software made by yourself. Anyone who contributes is
part of the GIMP team! 🤗
Note: the sharpest mind may have realized the feature was available in
the development release 2.99.4. Yet we add the description for 2.10.24
because this is the first stable release featuring GeoTIFF support.
TIFF got various improvements when handling multi-page files, but also
many edge cases, such as 2 or 4-bit TIFF images, opening some types of
non-conformant TIFF files and so on.
HEIF got some visually lossless export support when libheif 1.10 or
later is used. We also detect separately HEIC and AVIF support at
runtime, allowing to build the plug-in with only support of one encoding.
PNG now ignores useless layer offset of 0, a metadata which some
third-party software are always storing, hence getting rid of
unecessary dialog prompts.
JPEG will better warn the user when some metadata saving failed.
BMP in more bit depth can now be loaded, in particular 24bpp BMP
images; moreover GIMP is now able to rescue some non-conformant BMP
with wrong compression noted in header.
PDF import now proposes an option to reverse order of layers (same as
we already had on export) and now support fractional DPI import.
DDS in BC5 format benefited from some fixes. Moreover as we are
able to detect some images with errors previously created by GIMP, the
software will also automatically fix these errors upon loading them.
Raw image formats are still forwarded through featureful raw
developers
such as darktable or
RawTherapee. The former is undergoing
some API changes, and while darktable 3.6 is not even out yet, GIMP
already has support for this upcoming version. Therefore GIMP 2.10.24
will work with future darktable.
GIMP is now available in one more language: Kabyle. This is still an
early translation as only 18% of the stable branch is
translated so far
(and 32% of the development branch!) yet we can already thank these new
translators to bring GIMP to even more people.
This makes GIMP available to 82 languages other than default English!
Translators are also contributors doing an incredible work, even though
their work doesn’t always get the visibility and acknowledgement they
deserve. Thanks to all of them!
Our pixel encoding and color space conversion engine, babl 0.1.86, now
supports creating babl space from input-class ICC profiles and improves
thread safety.
On its side, GEGL 0.4.30 made improvements to its test suite and to
the following operations: jpg-load, png-load, tiff-load,
rgbe-load, color-reduction, fattal02 and paint-select. This
later operation in particular was introduced for the new Paint Select
tool
so we will have the opportunity to talk about the improvements on the
next development release news.
Additionally to the other improvements, a new very interesting operation
appears in GEGL, contributed by Jonny Robbie: negative-darkroom.
This operation is for artists who use hybrid workflow technique of
analog photography. After scanning a developed negative, this operation
is used to invert the scan to create a positive image by simulating the
light behaviour of darkroom enlarger and common photographic papers.
Negative Darkroom operation in GEGL 0.4.30 / GIMP 2.10.24
As all GEGL operations are automatically detected and made available by
GIMP, this new operation can be used in GIMP 2.10.24 through the generic
GEGL tool (menu Tools > GEGL Operation… then select “Negative
Darkroom (negative-darkroom)” in the dropdown list).
Creating a custom dedicated dialog for this operation has been raised
and may happen in an further version of GIMP to even more improve the
usage and experience.
Meanwhile babl minimum requirement in GEGL has been downgraded to 0.1.78
(same as in GIMP) because newer versions require too recent meson
build tool, which is unfortunately still not available on some
distributions. In order not to prevent people from benefiting from a
newer version of GEGL and GIMP, we refrain on purpose to bump the
minimum requirement for a bit even though we highly encourage every
packager to use the last version of babl when possible. Many fixes and
improvements were also made available in recent versions.
The Linux flatpak has already been published so that anyone who
installed it previously should have an update proposed by their
software manager (or from terminal: flatpak update org.gimp.GIMP).
Note: our flatpak now supports only x86-64 and AArch64 (i.e. the
64-bit variants of the x86 and ARM architectures). In particular i386
(32-bit x86) had been dropped quite some time ago by the Freedesktop
runtime we depend on. This is now the ARM (32-bit) support which has
been dropped (even though 32-bit hardware is still being released or
often 64-bit board computers are sold with a 32-bit OS). We tried to
hold back a bit, for more than 6 months even, but now that the older
runtime we used is unsupported, updating is the only sane choice.
For the record, our i386 flatpak is therefore stuck at GIMP 2.10.14
and our ARM flatpak is stuck at GIMP 2.10.22 with a few thousands
downloads for this last version of GIMP i386 and a bit more than 400
for the last version of GIMPARM.
The Windows installer is already available. Most mirrors have picked
it up, but some still haven’t. So if the download fails, just try to
click the Download button again.
The macOS DMG package will be published in the next few days once our
packager can make the time.
The development continues very strong on the development branch and we
can clearly see the shift towards more work on GIMP 3 as 2.10.x release
become more about robustness and less about new features (though we
still continue to backport features when it can be done without too much
additional work).
We will give more details on this side of development when we will
release the upcoming 2.99.6 development version.
We fixed several discoverability issues in the new (more compact) slider
widget. This was mostly the result of usability tests by Aryeom after
extensive use in production.
Before, if you tried to edit the scale value numerically (i.e. by inputting numbers on keyboard), you’d also trigger a value change by using the main
mouse button click. You could avoid that by using the middle mouse button
click, but is was hardly discoverable.
So now you can pinpoint-click the displayed numbers. This action will only focus the text input (by default entirely selecting the existing value as
is common when focusing text entries). You can still click-edit the value
from everywhere in the widget, except exactly on the numbers.
The second issue was related to changing the cursor depending on the context:
The top-arrow cursor came from a time where this widget had 2 areas, a
top and bottom. It didn’t really mean anything anymore with the
new interaction. We replaced it by a common “grab” cursor as
defined in the CSS specification. This becomes a “grabbing” cursor
when a click’n’drag is in progress.
When the pointer is hovering the text area, it becomes a “text”
cursor instead, hence advertizing the fact that a click here would
start editing the number.
Finally, when holding the Shift modifier key, the cursor will become
a horizontal resize cursor (“col-resize” in the CSS specification),
hence advertizing the ability for smaller relative resizing (an action
also available with the third button, usually right-click).
GIMP 2.99.4: from left to right, new cursors on the slider to grab, when grabbing, do small updates or text-edit
Multi-item selection in the Layers dockable comes with common key
interactions for multiple selection such as: Shift-click for range
selection or Ctrl-click for selection modification. These interactions clashed with some features we had on layer and mask thumbnails.
For instance one could end up changing the selected layers while in the
same time create or remove layer masks by mistake.
Since the multiple layers feature is just too important and these
generic interactions are so well established across software (hence their
removal or replacement not even being a question), we made the following
design choices:
No special click features in the Layers dockable should be based
only on Shift, Ctrl or Shift-Ctrl modifiers, but it could
include these if any additional modifier (e.g. Alt) comes to play.
We moved all existing features that didn’t follow such rule to the
Alt+ combination.
For cases where all modifier combinations were taken, we removed
click features based mostly on seniority (e.g. Alpha to Selection
has been around pretty much since inception of GIMP while mask creation
utilities were only added a few years ago).
Actions are now based on exact modifier combinations to avoid feature
clashes (e.g. Ctrl-click should not trigger both the Ctrl-click
and simple click actions).
Actions done when clicking a thumbnail with modifiers do not change
the selection and will now operate on the clicked layer or mask, not
on selected layers/masks. This makes these actions more useful as they
are not redundant anymore.
The concrete consequential changes are as follows:
Ctrl-click on a mask thumbnail to enable/disable the layer mask has
been changed to Alt-Ctrl-click. The other mask action, Alt-click
for showing the mask, stays the same.
Shift-click and Ctrl-click actions on a layer thumbnail to
respectively add (with last used values) or remove a layer mask have
been removed. Indeed all Alt+ combinations are already taken on
layer thumbnails (for “Alpha to Selection“, “Add Alpha to
Selection“, “Subtract Alpha from Selection” and “Intersect Alpha
with Selection“, respectively on Alt-click, Alt-Shift-click,
Alt-Ctrl-click and Alt-Shift-Ctrl-click; we also took the
opportunity to improve the Undo labels for these actions, improving
discoverability on random clicks) and these “Add/Remove mask”
actions were much newer (2.10.0) anyway.
Thumbnail popups on long click do not happen anymore when any modifier
is being held, hence removing a distraction when this was obviously
not what the click was for.
The infamous “Input Devices” dialog has always felt packed with arcane
features and devices. With GIMP 3, many features will be working
out-of-the-box and it felt like the right time to clean this dialog a bit.
We now only show entries for actual physical devices attached to your
computer. So no more “virtual devices”. Similarly we now hide the XTEST device which some kind of a test device generated by the X11
server (Linux).
We used to show all possible axes for all devices, including some axes
like “Rotation” or “Slider” which are present very rarely (only on
specific drawing styluses in the market, even uncommon among
professionals). The dialog will now only list the axes returned by the
backend (note that even this list may still show more than what a
specific device really has because drivers are sometimes over-listing,
yet it is still much closer to reality).
When a device is connected, the names of the axes will also be the
ones as listed by the backend, which will get us closer-to-reality
names. Typically the X axis for a graphics tablet will be Abs. X
because these devices are usually meant for absolute pointer
positioning whereas it will be Rel. X on mice.
Curve editing for the tablet pressure response was one of the most
interesting configuration option in this dialog, even more now that we
don’t need to enable or disable specific devices. This is why when a
device has a “Pressure” axis, it will be selected by default, hence
allowing you to directly work on the curve, without unnecessary clicks.
Call for user input:
There are a few puzzling settings in this dialog and we would welcome
input from anyone who had an actual need for them. How were you using any
of these features? Which OS? What was the goal?
There used to be a “Keys” list for every device in the dialog. We
actually removed this list back in 2.99.2. Based on tests, code
research, and discussion with Carlos Garnacho, our local GTK and input
device expert, we came to the conclusion that the “Keys” concept was
tied to “keyboard” devices (a type of devices not shown in this
dialog) and it was meaningless on “pointer” devices (mice, touchpads,
graphics tablets…). Yet here was the option! Maybe it actually had a
hidden usage to someone, someday? If this is your case, please explain
us so that we can think of a way to restore the feature with an
understandable interface.
The “Axes” list has the ability to set the “axis use” for a given
axis (the little numbers next to each axis). Yet we never managed to
do anything with it. This looks mostly either broken or meaningless.
Has anyone a use for this axis settings?
Each device has 3 “modes”: Disabled, Screen, and Window. “Disabled”
simply means that the device will share the main virtual device
pointer while “Screen” will make it look independent. The “Window”
mode, on the other hand, is a concept only meaningful for “floating”
devices (a concept maybe not even valid on all platforms) and even
then it looks broken, as far as our tests went. Is there anyone in the
world who actually uses the “Window” mode and sees a difference with
“Screen” in recent GIMP versions?
If anyone has the use for these features, we would definitely welcome
feedback because we are as puzzled as many others whether users actually
rely on these things. On one hand, we are tempted to remove these settings, because it doesn’t make sense to show a non-working configuration. On the
other hand, we don’t want to remove actual features if someone somewhere
has a use for them. So if you are one of those people, please contact us.
E.g. open a report
to tell us more.
Maybe there are other ways to improve this dialog for more people? Tell us
what you expect from it!
As explained in the 2.99.2
release notes,
GIMP 3 will be coming with a much better input device detection as well
as hotplug detection. So we decided to provide reasonable defaults for when
a new device is detected. This would help people see if it works correctly.
In particular for graphics tablets, people expect pressure to work from scratch.
For these reasons, here are the tools enabled by default the first time
you plug a device:
Pen devices (tablet styluses’ main input): Paintbrush tool;
Eraser devices (tablet styluses’ back input): Eraser tool;
Touch screens (finger): Smudge tool;
All other devices: Paintbrush tool.
Moreover, the default dynamics when a new device is plugged is now
“Pressure Size“, i.e. the brush size will increase when you press harder.
This should make the first-time experience with GIMP much more enjoyable
for people using graphics tablets, as they can directly start to paint
on the canvas without having first to understand all the inner settings
of GIMP’s painting system (based on the combination of brush and dynamics).
Our font list will now display fonts targeted at Korean and Japanese
writing systems with “한” and “あ” respectively. This will allow to more
quickly detect fonts useful for your language of choice in a long list.
Thumbnails in GIMP 2.99.4 of fonts targeting various writing systems
For Korean “한” (han) was chosen (apart from being the first syllable in
“Hangeul”, the name of the Korean writing system) firstly because it is a
syllable with two consonants, which gives good indications on stylistic
choices, and secondly because the circle shape in ‘ㅎ’ (hieut) but also
its small hat have many stylistic variants and are therefore also
quite good hints of stylistic choices made by a font designer.
As for “あ”, it is the first kana in the hiragana syllabary, which is
one of the main components of the Japanese writing system.
The code logics is based on approximation of probable target language
depending on supported characters found in the fonts. It may not always
show the ideal sample characters, especially for fonts that try to
support many different scripts, but it remains very useful overall.
This is based on existing code, which already had detection for other
writing systems, yet not for Korean and Japanese until now.
Our long-term contributor Thomas Manni is working on a new paint-based
selection tool. It will offer a new way to progressively make a
selection by roughly painting with a brush over the region of interest.
This new tool is based on a targeted segmentation algorithm (graphcut):
its goal is to quickly isolate a specific region in the image. The tool
provides a binary result (fully selected for the area of interest, fully
non-selected for all other pixels).
It’s at a very early stage of development, so if you test it right now,
you will probably be disappointed by its lack of precision and poor
performance. Fear not, there’s just way more work to be done, you’ll
like it once it’s complete.
Canvas interaction of the new Paint Select tool: quick selection of Wilber in one stroke
But what about the Foreground Select tool?
Some people might be wondering about the existing Foreground Select tool
which might look very similar to the new experimental Paint Select tool.
This quote from Thomas might explain the difference:
Foreground Select uses a matting algorithm: its goal is to provide an
alpha (grey) value for all “unknown” pixels. Generally it should be
used only on regions where pixels’ colors are a mix of foreground and
background colors (like strands of hair or fur).
Moreover, it is true that part of this new development comes from
recognition of some limitations of the current Foreground Select tool
which unfortunately does not work so well for actually segmenting global
shapes, often takes a lot of time on big images, and has memory and
stability issues.
We are not aiming to replace the Foreground Select tool though. The idea
is to offer a new way to do selections. We might be able to improve the
Foreground Select tool to work better in more situations. Discussions
have also been happening on reworking the interaction interface as a better
way to retarget the tool’s usage.
More experiments are still in progress or planned by Thomas, in particular,
to give new ways to refine edges of existing selection (since the
Paint Select tool creates binary selections which are less appropriate
for edge selection).
This is all to be considered as open development and experiments in free
software. We shall see how things evolve!
We have been working on dialog generation for plug-ins. A plug-in
historically comes with a “procedure” (which can be called from the core
but also from other plug-ins through the PDB protocol), with
parameters and 3 run methods: interactively, non-interactively and with
last values. The non-interactive and with last values run methods
imply known parameters (given by the caller or previous calls), but an
“interactive” run implies to ask for these parameters in a GUI, usually
with added logics.
Until now, this always needed specific GUI code. We now added new
functions for easy dialog generation from the procedure parameters. In
simplest case, you could therefore generate a full blown plug-in dialog
in less than 5 lines.
Several checks were added, such as mnemonic verification, ensuring that
every displayed property in a plug-in dialog has a unique mnemonic. This
is a very useful feature for usability and accessibility, for people who
mostly use keyboard navigation.
Similar ability used to be available on some specific bindings (Python
and Scheme) up to the GIMP 2.10 series. Unlike this past ability, the
new functions will be available for all plug-ins (i.e. C/C++ plug-ins,
but also for GObject-Introspected bindings, for instance in Python 3,
JavaScript, Vala, or Lua). Moreover, the customizability is much more
powerful and will provide much better dialogs and advanced logics.
With the plug-in dialog generation, we also special-cased some features
for export plug-ins. In particular, we tried to rework some of the
metadata logics and analyzed common points across various file formats.
This goes together with a more thorough work currently done by Jacob
Boerema on metadata handling. Some of this work will end up in the GIMP
2.10.x series, but the fundamental part might only be available in GIMP 3.
Only 4 plug-ins so far have benefited from the new generic dialog
generation API: the PNG, JPEG, TIFF, and FLI plug-ins. In the most
extreme case, we shaved 600 lines of code off the JPEG plug-in code!
Note: we just discovered (after release) crashes on these 4 plug-ins
😱, which escaped us because they only happen on Windows! Pretty bad,
but then it’s the joy of running unstable versions. We will fix these
as soon as possible.
PNG export dialog fully generated in a few lines of code: you don’t see much difference? That’s the point!
Multi-threading preferences now available from plug-ins¶
The Preferences dialog proposes a “Number of threads to use” setting,
allowing people to customize the thread usage (defaulting to system
threads detection). This was only used by core processing until now. We
now make this setting available to plug-ins too through the
gimp_get_num_processors()API function, hence allowing plug-ins to
follow user preferences.
The HEIF/AVIF plug-in now uses this function (it was already
multi-threaded, yet was using system threads discovery with no way to
override the settings until now). The JPEG2000 loading code, which was
single-threaded until now, has been ported to use this new function,
hence decoding images much faster.
Lloyd Konneker refactored and improved the infrastructure to help
debugging plug-ins. It is now capable of telling the difference between
WARNING from CRITICAL bugs for better targeted debugging.
We started documentation on porting plug-ins to 3.0
a month ago. We welcome anyone who follows the API changes to look
at already ported official plug-ins in our source repository and help
with the documentation side too. This is still moving API, yet most
of the core logics will stay the same, so the groundwork can be started already!
Øyvind Kolås released babl 0.1.84 and GEGL 0.4.28 in time for GIMP 2.99.4.
Both releases mostly contain small fixes.
Apart from that, GEGL got two new operations:
“gegl:paint-select” is the backbone of the new Paint Select tool
by Thomas Manni
“gegl:icc-load” treats .icc files as images, permitting loading
a space into the graph from a file.
Øyvind Kolås spent lately much time on polishing his
ctx project (a new 2D vector graphics
platform/protocol/library/terminal we talked
about
a year ago.
We need to remind that this is a development version and therefore bugs and even crashes are bound to happen. We do not advise using it in production.
Nevertheless we are encouraging early tests and welcome reports as well
as patches on issues. We fixed 21 reported issues (and many more
unreported ones) since GIMP 2.99.2
release and
we expect many are still unfixed. We probably even created some new ones as
the work on upcoming v3.0 continues!
Between the GIMP 2.99.2 and 2.99.4, 283 changes were committed to this
particular development branch of GIMP in a bit less than 2 months. This
was quite a busy end of the year!
A Windows installer and a Flatpak build are already available:
Note: we still haven’t got a build for GIMP 2.99.4 for macOS, yet you may
have noticed our other news from the very same day about finally
releasing GIMP 2.10.22 for
macOS
(double Christmas 🎁!). So there’s a progress, and an unstable macOS package might happen soon too!
A lot more work is still in-progress, so as always, we welcome any
contributions to code, bug
investigation, themes, icons, documentation, translation, website, builds…
GIMP is a community-developed software. You could think of everyone who contributed to this release as of friendly elves from all over the world
who helped making this holiday present happen.
Oh, and one last thing. We are well aware that GTK 4.0 is out now,
we have no plans switching over to it before GIMP 3.0 is released.
As usual, you can donate to the project
and personally fund several GIMP developers who make this all possible
at all. This is also a way to give back and accelerate the development
of GIMP if you appreciate the project.
Have a very nice holiday season 🥳🎄 and the end of 2020, everyone!
This year was a complete mess for most people out there. But we do
sincerely hope that at least some things were good for you, and maybe
(just maybe) GIMP was one of those things. We sure wish 2021 to go easy
on everyone!
GIMP 2.10.22 is now available as a DMG file from our downloads page.
Many thanks to Des McGuinness, who updated the build enviroment created by
Alex Samorukov and succeeded in getting the current stable code built and notarized!
This brings all the changes and fixes since GIMP 2.10.14 to macOS users, who
had been limited to this increasingly outdated version for far too long. Several
of the changes are quite visible and noticable to users, so it is a good idea
to check the release notes for GIMP2.10.18,
2.10.20 and
2.10.22 to get up
to date with the current versions.
It is not all well on the platform yet, though - with users upgrading to the latest macOS release, Big Sur, we started getting reports about performance and user interface issues.
GIMP being very slow and invisible selection outlines are reported most frequently. It is likely both are symptoms of the same underlying technical issue, that being the image window content being updated completely and far too frequently than necessary.
It feels really good to have active contributors to the macOS platform again, this gives us confidence that the issues can be investigated properly and, hopefully, mitigated or completely solved.
If you encounter any issue in addition to the two linked above, please let us know; the bugs page explains how to do this. If you are unsure whether a bug is already known, you can search for them there, or have a look at all the issues reported for the macOS platform.
When in doubt, report it anyway, we will figure out duplicates and mark them accordingly.
Exactly 25 years ago, Peter Mattis wrote a message to several newsgroups announcing a new image editor called GIMP.
“Happy 25th birthday GIMP!” by Aryeom, Creative Commons by-sa 4.0
We’ve been really busy ever since!
Had to come up with GTK, a user interface toolkit of our own. Did not expect whole desktop environments, like GNOME and Xfce, to become the result of that. GTK is now a self-contained project used by thousands of developers.
Surprisingly, got a few developers from Hollywood to write the beginnings of what became a new image processing engine called GEGL, now used by a few more software projects too. We still have barely scratched the surface of what’s possible with GEGL.
Introduced Wilber, a little cute mascot who traveled the world and, admittedly, did some kinky things. They grow up so fast! (Check out the splash screen archive)
Helped kickstart Libre Graphics Meeting as an extended version of our annual meetup in 2006. Made a lot of new friends every year since then.
Did our best to provide a sensible workflow to users by using common user interface patterns. That gave us a few questionable monikers like ‘Photoshop for Linux’, ‘free Photoshop’, and ‘that ugly piece of software’. We still can wholeheartedly agree with the latter one only!
Tried to do too many things at once with too few active developers to realistically get things done in a sensible timeframe. Made a lot of people think the project died while we were slaving away really. So we introduced some planning. It’s been paying off so far.
Made more people angry with software’s quirks than we’d like to. Got help on that from more passionate contributors than we expected to. We can certainly use more help still.
Got ourselves an animation project called ZeMarmot to make a positive feedback loop involving artists and developers. Continue using our chat for conversation with artists, some of which put GIMP through a lot. That really helps.
Every day, we are one step closer to completing the boring yet extremely important work on refactoring GIMP to make way for great new things. Things that we’ve been meaning to do for a long time. Things that users have been expecting for an even longer time.
The world is definitely a different place 25 years later. Louder, noisier, more demanding. Definitely less safe. But also full with warmth and humanity. We’ve seen waves of that washing up and down the rocky shores of GIMP.
We don’t really have any kind of big news for you to commemorate the anniversary. Sorry about that. We keep slaving away — in a more intelligent way these days, hopefully. But there might be cake.
The first difference will be visual as you will notice that GIMP got a
bit more of a modern look and it can also use some new widgets (instead
of redeveloping them on GTK2) as well as client-side window decorations
on various dialogs. But the aesthetic differences are far from being the
main appeal of GTK3.
One of the main issues of GTK2 was the absent support for high pixel
density displays (e.g. small screens with high resolution or big screens
with extremely high resolution) which has become more widespread,
especially among graphics professionals. GIMP 2.10 came with partial
workaround which was acceptable only in some limited cases but was not
really appropriate for intense use of the software.
GTK3 brings proper support to GIMP so it will follow your system-set scale settings.
Status: done, some custom widgets might still need an update.
By “input device”, we are mostly talking about drawing tablets or
pen displays. In GIMP 2, their support had many shortcomings: you had to
plug the tablet before starting GIMP, enable each new device explicitly
in the settings and, worse, unplugging the tablet could lead to
instability of the software (though this issue got mostly worked around
on GTK2 by GIMP developers in the v2.8 release series).
GIMP 3 (hence this first development release) is bringing hotplug support,
which means: start GIMP, plug your tablet, done. You are ready to draw,
with pressure, tilt, and everything.
We are also trying to improve general support by making the advanced
configuration of input devices easier to set.
A while ago, we also experimented with support for touch gestures like
zooming, panning, rotating etc. We did not finish this work because we
realized this was not a priority compared to some other features.
Touch gestures are very nice and awesome but also sometimes become a burden.
Actually, many professional artists even disable touch sensitivity to
prevent unwanted input while working with a stylus (high-end tablets often
come with a physical switch for this nowadays, and this can also be disabled
in tablet settings). With this in mind, we have decided to not make it
a priority compared to some other work-in-progress. So we are not sure
whether specific gesture support will make it to GIMP v3.0. We do
welcome patches from anyone willing to make it one’s priority though.
Status: some work needs to be done to simplify configuration dialog as
the support for legacy features is either not needed anymore or can be
done better. We might also want to add support for Wayland-specific
features related to input devices.
With GTK3, we also inherit its CSS-based theme format. Unfortunately
this means that all custom-made themes from past versions will be
incompatible with GIMP 3.0 and future releases. On the bright side,
this new theme format uses a very well known theming standard. This
should make it much easier to tweak GIMP’s interface to your needs and preferences.
Moreover, the symbolic icon themes are much better supported. They will
follow the theme-set foreground and background colors. If you ever had to
switch from a dark theme to a light one in GIMP 2.10, you probably
remember you also had to switch the symbolic icon themes manually. This
won’t be necessary anymore as symbolic icons will be recolored according
to your theme.
Finally, the “dark theme” is a core concept of GTK3, which means,
for instance, that even window decorations get recolored as you can
see in the screenshot above.
Also, a same theme could propose both a dark and a light variant, so the
Theme preferences page shows a “Use dark theme variant if available”
checkbox. Similarly, icon themes may propose both symbolic and color
icons. Which is why the “Icon Theme” preferences page has a “Use
symbolic icons if available” switch so that you could choose your
preferred style.
Switching to Dark or light themes with a single checkbox with icons recoloring to theme colors
Status: waiting for theme contributors.
Code-side, changes related to theming are basically done. Now we need a
new default theme.
For now, GIMP 2.99.2 only lists the “System” theme, which lets GIMP
follow your system-wide GTK theme. This is a regression from 2.10 that
we intend to fix in time for GIMP 3.0 by reintroducing a default theme
with a neutral dark/light variant as well as a neutral middle-gray
custom theme.
The main issue with system themes is that they cover very basic desktop
use cases. Meanwhile, advanced graphics work requires a neutral gray theme
to avoid polluting your color perception. This is the main reason why
GIMP needs to default to a neutral color theme with symbolic icons.
Colored themes and icons are still an option, and, in fact, we are
pretty sure that the community will soon come up with good-looking
custom themes. This is a great way to contribute to GIMP as a non-developer!
The port to GTK3 should normally give us Wayland support on Linux for free.
And it mostly does. Unfortunately, a few bugs have already been reported
for GIMP running on Wayland. Some of them are clearly blockers for releasing
GIMP 3 (such as various weird GUI bugs or huge memory leaks). Others are less serious
but still are a bit embarrassing, like the one where the splash screen is
broken on HiDPI displays because Wayland doesn’t report scaling properly.
Until these issues are fixed, we don’t think we can safely claim that we
provide appropriate Wayland support. We will be grateful for all patches to
address that, whether they arrive to GIMP, GTK, or another relevant part
of the technology stack. If you are interesting in helping out, here is the
list of Wayland-related bugs.
Appropriate Wayland support also means we need to reimplement a few
features through so called portals. We have already done this for the
screenshot plug-in (using Freedesktop, GNOME, and KDE portals), and there
is some ongoing work to fix on-display color picking (already works in KDE,
doesn’t yet work with GNOME and Freedesktop portals).
As for the file portal, this is probably something that won’t happen
for GIMP 3.0, because we still require some features of the GTK file
dialog, but it might happen later with a planned redesign for improved
export process.
Status: a few blocking bugs in particular require attention. We
welcome contributions.
Managing a complex project with tens and hundreds of layers is now much
easier thanks to newly added multi-layer selection. Aryeom, the animation film director
working with the core team, has been asking for this since 2015, so
the ZeMarmot project finally made this happen. This is another
example of a successful close artist-developer collaboration: every feature
was carefully designed following discussions and was tested in production.
Selecting 4 layers to organize them or transform them at once
The Layers dockable is now fully multi-selection aware, using the usual
interaction for multi-items selection (Shift+click for selecting a
range of layers and Ctrl+click for selecting or deselecting
non-contiguous layers). Organizational operations now work on all
selected layers, i.e. that you can move, reorder, delete, duplicate,
merge (and more…) all selected layers at once.
Several tools now also work on multiple selected layers. For instance
all transform tools (move, rotation, scale, perspective, unified
transform…) will transform all selected layers (in addition to the existing
layer links with the “chain” icon). You can also crop several layers at
once or copy-paste merged layers’ projection. Even the Color Picker tool
can now pick merged color from several layers (some kind of partial
“Sample merged” without having to hide unwanted layers).
These are just a few examples because this change affects a large part
of the code base: the concept of an active layer is prominent in every
action. You can read more about this in a detailed development
report.
Status: this is a work in the progress.
Some features in GIMP still expect a single layer and need to be fixed
before the final release. It’s possible that we will inadvertently break
something while working on that, which is why it’s important that we do
more development releases. Moreover, we might extend the multi-item
selection to paths and channels soon.
Finally, painting and GEGL operations (filters) are still limited to
single layers. Adding ability to paint or run pixel operations on
several layers at once will probably require some additional interface
specification and designing to prevent undesired consequences like
extremely slow operation or the ability to cancel a long-running process.
We had to break the plug-in APi to introduce many improvements, although we
took a special care not to break things where it wasn’t necessary to do so.
Porting a single-file plug-in from GIMP 2.10 to GIMP 3 usually takes between
5 and 30 minutes. We are working on a porting documentation to be released
along with GIMP 3.
If you are a plug-in developer, one of the first steps you can take is
making sure you don’t use any deprecated functions. We compiled a list of functions removed and their
replacement. You can already do this part of the port while still targeting GIMP 2.10.x versions.
Among the noteworthy changes, we moved away from object IDs to real
objects. In particular in GIMP 3, GimpImage, GimpItem,
GimpDrawable, GimpLayer, GimpVectors, GimpChannel and GimpPDB
are objects (other classes of objects already exist or may be added later).
It brings safer programming by having typed objects whose class can be
easily verified, hence better error messaging (with IDs, which are
basically integers, having weird bugs because of improper IDs was not
uncommon and it was not always easy to track the bug).
Also object-programming implies class inheritance. Typically a
GimpLayer is also a GimpDrawable, itself a GimpItem. This means
you can use any methods from parent classes and easily test for class ownership.
A non-C consequence is that it enables bindings to adapt the API to
their own object model. Hence duplicating a GimpImage named for instance img in Python 3 can be done with the quite pythonic APIimg2
= img.duplicate().
Status: object port is basically done. We also want to use object
signalling, which is a work-in-progress and should eventually allow to
connect signal handlers directly on objects, in order to manage events
from the core application (something impossible in GIMP 2, except by
regular polling).
Another change in our API is that paths are now handled as GFile,
which implies using the GLib/GIOAPI.
While it may seem a bit cumbersome (as it adds the additional step of
creating and managing a GFile), this allows much more robust file
handling. In particular, you won’t have to take care about path
character encoding (a real issue when developers just assume everyone
uses the same encoding as themselves) hence broken paths and
non-portable code. Also we don’t have to deal with difference of
operating systems regarding folder separation or file system notations.
Working with a GFile makes internal representation transparent and
file handling robust.
The second big advantage is that it means all such API gains any ability
of installed GIO modules, in particular loading or saving from/to remote
locations (even possibly through secure channels like HTTPS).
This opens a wide range of possibilities.
GIO port of file handling had been done in the core code of GIMP, back
for GIMP 2.10 initial release. We are now bringing the advantages to
plug-in developers as well in GIMP 3.0.
Status: done, except with legacy bindings.
Language bindings through GObject Introspection also have full access to
GLib/GIOAPI so they are already able to create GFile from paths or URI
without any problem.
Yet legacy manual bindings, such as script-fu (Scheme), don’t have
GFile access. We are working on it (a patch even already exists, but
needs to be reviewed).
Some major changes have been done in the API to declare your plug-in.
This is now done by subclassing the GimpPlugIn class and overriding
some methods to list and document the created plug-in procedures. We
made a much cleaner and explicit API than the previous one which should
help plug-in developers.
The way your plug-in procedure’s arguments are now handled has also been
standardized, in particular using config GObject properties. This is
easier to deal with as a generic logics. Especially the same config
object allows us to generate many features. For instance, it will help
generate dialogs on demand for plug-ins who do not want to tinker with
GTK or other toolkit themselves. It also simplify and standardize
argument saving for subsequent calls or a same procedure.
Eventually this is also part of the base work for a future
recording/macro feature (very unlikely to be in GIMP 3.0, but this is
part of the ground work towards such feature) since we will be able to
reliably save the arguments used when running plug-ins.
Status: though the main part of this API is done, more needs to happen
before the release, and in particular we are still tinkering with the
argument representation.
We have introspected the full API through GObject
Introspection. It means that GIMPAPI should be fully usable in a wide range of language bindings. We have
only tested a few so far, so we can confirm that GIMP can now be
scripted (additionally to C and C++ of course) with:
Python 3
JavaScript
Lua
Vala
One of the main differences with how GIMP used to be scriptable, with
Python 2 notably, is that a custom layer API is not needed anymore.
Also GIMP 2 bindings used to be made around the PDB protocol which is
only a subset of the full C libgimpAPI. The new bindings are built around libgimp itself. Therefore plug-ins in Python 3, Javascript, Lua
or Vala (or any future introspected binding) will have the same
possibilities as C plug-ins. This is a bright new world for GIMP plug-in developers!
Another consequence is that the API is basically the same for all these
languages, apart for language idiosyncrasies.
For instance if finding an intersection of a drawable with a selection
in C is:
Another nice example is how C-type arrays, with an additional length
arguments are handled. As expected, the length argument does not exist
in a binding if the target language has an appropriate structure.
For instance, while you can copy from multiple drawables from a script with:
/* Where @drawables is a C array of drawables, and @num_drawables * indicates the size of this array. */gimp_edit_copy(num_drawables,drawables);
This can be done in Python 3 as (with num_drawables removed and C array
replaced by a Python list):
Gimp.edit_copy([drawable1,drawable2,drawable3])
Not only do these binding now have access to the full GIMPAPI, but they
also have access to many more introspected APIs used as dependencies to
GIMP. For instance a plug-in can have access to the full GLib/GIO, GTK,
Pango, Cairo APIs as well as the babl and GEGLAPI (for easier pixel
manipulation and access to a massive range of existing operations). This
was one of the main limitation of the former Python 2 binding, which
could not manipulate pixels with GEGL.
Status: some people are regretting the facilities provided by the
former Python 2 binding, such as automatic dialog creation. This
is worked on right now (some embryo of dialog generation has even
already landed in the development branch after 2.99.2 release) hence
should be available for the next development release. The best part is
that such API will be done on the main API, thus available to all
bindings, not just Python or Scheme.
This is one of the biggest advantages of introspected API compared to
manually maintained bindings: rather than reimplementing nice features
in every available binding, we will provide them in the main API so that
every developer can enjoy them, whatever your preferred language.
Finally Script-fu is not one of the introspected bindings (though there
is supposedly GObject Introspecting scheme bindings, but we haven’t
tested any yet) and still mostly works as its own extension. Yet issues
regarding some of the API changes have been raised (for instance the
inability to create GFile as discussed earlier) and will have to be
fixed before finale stable release.
For each of the tested binding languages, we created a plug-in called
“Goat exercise”, which is a demo for creating plug-ins. You can call it
a “GIMP Hello World!“.
Each Goat Exercise does exactly the same thing in its own language: it
creates a dialog with a label, buttons and a text view (GTK+ and
GLib/GIO demo); one of the buttons triggers a filter modifying the
active layer (GEGL demo and GIMPAPI demo); all this while showing its
own source code inside the text view (making it easy to inspect the code
from within GIMP) and with a button sending you to the repository file
(if you prefer to check out the last version, comfortably in your code editor).
The 5 versions of the Goat Exercise plug-in in Python 3, Javascript, Lua, C and Vala
These plug-ins are quite important as we are planning to improve the
plug-in ecosystem with GIMP 3. They are the first step of
“self-documenting demo plug-ins” (while doing something a bit more
exciting that a bare “Hello World”).
Status: current code of the Goat Exercise is not always up-to-date
with the most recent API yet as it is a moving target. These will be
updated before release.
We have started to write down some documentation regarding plug-in
development in GIMP 3, and will progressively start to publish some
tutorials. Hopefully we will even be able to relaunch our developer
website that has been slowly decaying for too many years. We hope that
GIMP 3 will revitalize the GIMP plug-in ecosystem!
Status: still at an early stage, we welcome more contributors to make
it possible.
Extensions are a new file format that is simply a wrapper of data
(brushes, splash screens, patterns, dynamics…) or plug-ins, associated
with metadata (name, description, screenshots, version, requirements…).
The goal will be to allow plug-in developers to publish their work on
repositories for anyone to search third-party plug-ins,
install/uninstall, enable/disable and update them, all within GIMP.
The menu Edit > Manage Extensions shows the base dialog. In the
“System Extensions” tab in particular, you will notice an “Official Demo
Plug-ins” which is our first extension. It in fact bundles all the Goat
Exercises plug-ins we talked about earlier. If you switch if off, you
will notice after a restart (right now you have to restart GIMP to see
the effect) that the menu category Filters > Development > Goat
Exercises disappeared.
The Goat Exercises are themselves a system extension.
We’ll get back to talking about this feature after we’ve done more work
on it. In particular, we will provide documentation on how to create
extensions. It is definitely something plug-in and resource creators
should look forward to, as it will help share their creations with others.
Status: still more work to do on the GIMP side, especially for
communicating with repositories, and much more work to be done for the
official repository and the website for extensions.
“Space invasion” is the internal code name for the work originally
started in 2018
whose goal was proper support of color space during core pixel
processing. In the GIMP 2.10 series, despite core color management
support, the profiles were sometimes lost during an operation processing
and only reintroduced on finale results, which may result in wrong
values in some cases.
Anyone interested to understand further the problematics can read
Øyvind Kolås’s post and in
particular the detailed associated release notes for GEGL
0.4.6 where he
explains this really well.
Some of the improvements of this work have already been progressively
backported to various GIMP 2.10.x releases, but GIMP 3.0 should be the
culminating release where we hope to get this 100% right.
Status: the development branch is much more advanced on this topic
than the 2.10 series, but some more work needs to be done. Various
aspects of GIMP still mostly expect or display sRGB-only values.
GIMP 3 now has a render cache that keeps the result of scaling, color
management, display filters and shell mask (for tools like Fuzzy Select).
This results in much snappier user experience in comparison to the GTK2
version of GIMP.
There is now also a Zoom Quality setting in Preferences -> Display.
When set to Fast, GIMP will do a nearest neighbor interpolation from
the next bigger mipmap level instead of linear or box filtering. This
gives a slight and permanent boost to painting and all updates. We have
a few ideas to improve this further like reblitting in high quality
after a timeout.
Color Profile Policy now exposes a new choice “Convert to Preferred
Profile” and the import dialog default “Convert” action will convert
the image to the preferred profile (if any was set, otherwise it falls
back to the built-in profile). Converting to the built-in profile will
still be available as a secondary action. If you want to always work with
a given profile, you can set up your preferred workflow as soon as importing
is done.
Moreover, a new Metadata Rotation Policy is exposed in the Preferences
dialog, next to the Color Profile Policy (in page Preferences >
Image Import & Export) with 3 options: “Ask what to do”, “Discard metadata
without rotating”, and “Rotate the image then discard metadata”.
Updated Color Profile policy and new Metadata rotation policy
The metadata rotation policy used to be handled on the API side, with
a dialog generated by libgimpui and saved in a global parasite.
The whole logics and GUI has been moved as core logics, similar to the
“Color Profile Policy”. This implies that plug-ins don’t even need to
handle this as it will happen as specified by the user automatically
on every new import.
The compact spin scale was introduced in GIMP
2.10.18. In the 2.10 series, it was left as an optional feature which could
be deactivated in the Preferences dialog. In GIMP 3, this is now the
only possible behavior, with no options.
New compact slider is now default and only option
Please note that the bright blue color on the screenshot is not our
preference, it’s what the system theme dictates. This widget actually uses GtkProgressBar colors by default. Therefore this can be adjusted
in a custom theme by changing GtkProgressBar colors or only the colors
in this specific widget (again, we welcome theme contributors!).
While porting old features and implementing new ones, a lot of side work
has been done on the code structure. Many parts of the code base got
refactored for better maintenance.
Even when some port is not done yet, ground work may have been prepared,
such as the GimpAction interface to add a layer of abstraction to
GtkAction (preparing us to actually move away from it at a later
point which is one of the main remaining big ports for the move to GTK3).
Many other parts are constantly remodeled and improved as part of
a never-ending background work.
Status: refactoring is always work in the progress, always was, always
will be. It never really stops.
This release is available in the “beta” branch of our official Flathub
package, which is a
hidden release branch (you won’t find this information on the public
web page). This command will allow you to install GIMP 2.99.2:
From now on, you will be able to update to new development builds as
soon as they are available through this channel (if your desktop has
Flatpak integration, it might even check and propose you the updates automatically).
Note that Flatpak only allows one visible branch of a same application
at once. So if you installed both the stable and development releases
with Flatpak, your desktop in particular will only show either one or
the other. To switch the visible branch, run the relevant command among
the 2 proposed below:
Some people also created shortcuts running the explicit command flatpak
run org.gimp.GIMP//beta (respectively stable) as workaround to get
icons for both versions.
Some features may be missing. In particular, you won’t find the
JavaScript binding on the Windows build because of the complexity of
some dependencies. We will fix this in future releases leading up
to GIMP 3.
Our macOS packager has still not fully returned, so unfortunately there
is no official macOS package. As always, we remind that GIMP is free/libre
software developed by community. Any of you can become an official package maintainer (and having several contributors would keep everyone safe).
If you are interested, we suggest to get in touch with us on our
IRC channel for developers, #gimp.
As you can see, a lot has been done (the NEWS
file will also give a bit more details). The vast majority of the work
has already been done. What remains now is the final stroll. This is
however not such an idle walk in the park, as the final decisions and
attention to details is always the most difficult part. We want to
release a rock-solid GIMP v3 and need to pay a lot of attention to
details. This is where we are now and why we are releasing this first
development version.
This development report lists pretty accurately all the remaining steps, and you’ll notice how it
actually follows quite well the changes in GIMP 2.99.2. The API part,
though going unnoticed to many users, is probably the major part which
we must absolutely get right before the release since our API is meant
to stay stable withing the 3.x series. Once we have it done, we will want
to keep existing interfaces of libgimp 3.0.0 functions unchanged unless absolutely necessary (i.e. unless we discover bugs that made a function
useless). This is likely to take a lot of our time.
There are definitely other parts where help will be crucial, whether it’s
plug-ins, core code, user interface, or application interface. So we do
need more eyes on this to resolve as many little issues as we can.
GIMP 2.10.22 is a bug fix release, which for once contains mostly
maintenance changes in core code.
Release highlights:
Improved HEIC and newly added AVIF support
Numerous improvements in the PSP file format support
Improved multi-layer TIFF exporting
Better handling of the Exif “Orientation” metadata
New “Sample merged” option in the GEGL operation tool
On official plug-in side though, there are quite a few improvements, in
particular, better support of image formats, as well as support for one
new format, AVIF.
“Wilber Learning never Stops!” by Aryeom, Creative Commons by-sa 4.0
AVIF is the HEIF variant using AV1 compression (instead of HEVC in the
same HEIF container format, which is the default and also called HEIC).
This format was highly awaited as being an open, royalty-free, video
coding format developed by the
Alliance for Open Media.
AVIF is already supported on the web in Firefox (experimentally, you
must enable image.avif.enabled in about:config), Chrome and Opera,
which makes it a serious contender as a web image format.
It is now supported by GIMP, both for import and export.
Not only this, but HEIF files (both AVIF and HEIC) can now be imported
and exported in high bit depth (10- and 12-bit per channel).
GIMP 2.10.20 brings AVIF support, as well high-bit depth support.
It will also import NCLX profiles and metadata.
And finally, NCLX color profiles and metadata will now be properly imported.
These changes all happened thanks to the awesome contributions of Daniel Novomesky.
The plug-in for reading PSP (Paint Shop Pro) files has received numerous
bug fixes and improvements. Raster layers from PSP images over
version 6 are now supported, as well as 16-bit integer, grayscale, and
indexed images.
Furthermore, PSP blend modes are now better converted to GIMP layer
modes for correct rendering.
The importer is also much more robust and is even able to fix errors of
some files which may have been wrongly exported by third party software.
It also handles some edge cases like zero-length layer names better.
All these improvements were made by Jacob Boerema, one of GIMP newest core contributors.
Multi-layer TIFF export got improved by allowing to crop layers to image
bounds in the exported image. Indeed, TIFF has no concept of global image
bounds, only layer bounds. Hence cropping the layers is the only way to
enforce the image bounds.
Obviously, this cropping may or may not be what you wanted and perhaps
you were expecting layers of various sizes. This is why the feature is
available as a new optional Crop layers to image bounds checkbox in
the export dialog.
There have been other bug fixes and improvements in the TIFF plug-in
as well.
Other file format supports were improved. In particular:
BMP always include color masks when exporting BMP with color space
info, as mandated by BITMAPV5HEADER specification.
DDS import is now a bit more permissive, allowing to load some files
with invalid header flags regarding compression, while we are able to
know the right compression from other flags. This allows to recover
invalid DDS files exported by other software.
JPEG and WebP detection improved.
XPM does not export a “None” (transparent) color when unused.
Exporting an unused color was not a bug per-se but was not very well
handled by some third party software.
In previous release, when an image with an “Orientation” tag was imported,
GIMP would propose to rotate the image or leave it as-is. If you denied
rotation, the image would keep the tag and retain it upon exporting.
So when you opened the edited image in other software, you’d get the
rotation you didn’t ask for.
The new policy is to remove the “Orientation” tag whether or not you
accept the rotation. Hence what you see in GIMP is what you will see
anywhere else after exporting.
When some filters have a color property, their dialog usually exposes a
button allowing to pick a color directly on the canvas. Until now, it could
only pick from the active layer (the one you were editing).
All filters implemented as GEGL operations now show a Sample merged
checkbox in the Tool Options dockable (just below the Sample average
option). This allows color picking visible colors when necessary.
The new “Sample merged” options will allow to pick visible colors when relevant, for instance here with the “Colorize” operation.
Spyrogimp, the official plug-in to draw spyrograph patterns, now works
on grayscale images too and won’t clutter the undo history as much as it
used to.
This is actually a feature that arrived in GIMP 2.10.20, but we forgot
to mention it in the previous release notes. So let’s describe the changes here.
The conversion to an indexed image uses a median-cut algorithm to derive
a suitable palette for the image. Such algorithm computes each index to be
used as the average of colors in a 3D box in a color space, making the
result value drift away from the extremes.
This makes it nigh impossible to achieve pure white or black, even when
the original image contained these colors, like in scans of printed
documents or technical drawings.
We now counteract the drift by snapping the whitest color to white and
the blackest color to black if the resulting colors of median-cut are
sufficiently close to white or black and if the original image already
had some pure white or black.
Left is an original image in RGB, converted to a 6-palette indexed image in GIMP 2.10.18 (center) and 2.10.20 or later (right).
Note that the 2-color optimum palette case is special-cased not to use
this modified algorithm as we already provide a dedicated “black and
white (1-bit) palette” option which would do the same thing.
After a small poll (which got 174 answers) on multiple social media
platforms, Sample merged option is now enabled by default in the
Color Picker tool. The idea is that it should now be less confusing to
beginners because they will be able to pick what they see rather than the
color in the active layer.
Of course for advanced users, it doesn’t change a thing as they
perfectly know how to toggle this option, both use cases being
useful at different times. This change does not affect anything other
than the defaults and does not modify how the feature works.
The dashboard dockable now has a new option to record progressive
performance logs that contain complete information after each recorded
sample. This allows recording complete logs even in cases where they
can’t be properly terminated, such as when GIMP crashes or freezes
in the middle of the log.
Progressive logs are disabled by default, since they potentially
increase the sampling cost. They can be enabled through a toggle in the
log file dialog, or through $GIMP_PERFORMANCE_LOG_PROGRESSIVE
environment variable.
Moreover, verbose debug information (gimp-2.10 -v on command line,
or debug output) now displays Flatpak related information when it’s
relevant: the exact Flatpak build hash, the runtime version, the
installed Flatpak extensions, permissions, etc. This helps debugging
Flatpak builds.
Since GIMP 2.10.0, several GEGL operations have OpenCL code paths,
hopefully allowing faster processing. Unfortunately OpenCL situation is
not so idyllic because of the lack of contributions to improve our code
as well as faulty drivers.
In various cases, enabling OpenCL in GIMP could lead to instability. We
decided it was not acceptable anymore and moved the feature into the
Playground tab of the Preferences dialog. Technically it means that
the feature is hidden unless you run GIMP with --show-playground
command line option, so that anyone enabling this is really aware of the
instability of the feature. Hopefully we will be able at some point to
move this back into mainline Preferences.
The Playground page in the Preferences is not visible anymore, unless
you run a development version of GIMP, or if you start a stable version
with the --show-playground command line option.
Nevertheless if you activated any of the unstable features from
Playground, then the page will always be shown (making it easy to find
the settings again if you need to disable it).
Our official Flatpak now has an extension point for plug-ins. This means
that anyone can now package third-party plug-ins as “Flatpak extensions”
and contribute them to the Flathub repository. Thanks to the contributor
Hubert Figuière, 7 very popular GIMP plug-ins are already available to
Flatpak users: BIMP, FocusBlur, Fourier, G’MIC, GimpLensfun,
LiquidRescale, and Resynthesizer.
The one-liner CLI call to install them all at once is (if GIMP is
already installed as Flatpak, and the Flathub repository is configured):
Note: Flathub does not yet provide a way to discover software
extensions directly on its web catalog. The following CLI call can be
used to search for GIMP plug-ins: flatpak search org.gimp.GIMP.Plugin
Moreover, the GIMP manual will now be installed by default when
installing our Flatpak, but not in all languages. To install the manuals
in all available languages, run:
Flathub statistics indicate that there are nearly 230K users of our
Flatpak package (with about 100K users updating GIMP within the first 2
weeks after a build update), which is pretty decent for a single package
format on GNU/Linux.
As usual, GIMP release is accompanied by babl
(0.1.78, 0.1.80 and 0.1.82) and GEGL (0.4.24 and 0.4.26)
releases, with various bug fixes.
It is to be noted that, even though GIMPminimum requirement is babl
0.1.78, we advise to build against the latest version if possible, i.e.
babl 0.1.82. This last version handles more complex parametric TRCs for
ICCv4, which means that without these changes, your color profile
conversion may be wrong in case you use a profile with these parameters.
GIMPCI process now runs a distcheck step, hence producing a fully
unit-tested source tarball without human interaction.
Continuous builds of the development version (future GIMP 3) for Windows
were already provided since GIMP
2.10.18
but the downloadable archive was huge, containing many temporary files
from the build process and a wrapper to necessarily run at first launch.
We now implemented a new CI job with a slimmed-down and hopefully usable
build (if not please report, or better: send us patches!) and already
fully set up with no first launch process.
The idea came from the Siril project
(astronomical image processing free software) after we helped them set
up a cross-compilation CI, similar to ours, using
crossroad. A pretty good example
of exchange between free software where some code goes from one project
to another where it is improved, then back to the original one. 🥳
This will be very useful when asking people to test the development
version as a lot of bugs are fixed on it (often just because the GTK2
toolkit is simply not maintained anymore whereas the development version
using GTK3 fixes the problem by itself). The following dynamic links
will always return you the last successful development builds:
NOTE 1: test builds are for testing purpose only (as the name tells!).
They have not been human-tested, it relies on regularly modified
development code, and our automatic build process is still a bit young,
which means there may even be bugs specific to the build. So please do
not use it for production!
NOTE 2: there are still a few known issues such as missing GObject
Introspection, i.e. that the Python 3/Javascript/Lua/Vala plug-ins won’t
work with this build (yet).
NOTE 3: these builds are not provided with a fancy installer nor any
desktop integration (i.e. no shortcuts in menus, etc.). Just unzip the
archive, and double-click gimp.cmd or gimp-2.99.exe files.
These changes are all part of a more global work in progress to improve
development code testing as well as eventually automatize the release
procedure to be faster, easier, and more trustworthy.
Unfortunately, we don’t have good news for macOS users at this time.
The contributor who set up CI builds for making macOS releases and worked
on macOS-specific bugs in GTK is still unavailable. So far, no other
contributors stepped up to fill in. If you are interested to help out,
please contact us on the IRC channel
for developers, #gimp, or the gimp-developer@
mailing list.
Contributors to this release are: Daniel Novomesky, David Russo,
Elad Shahar, Ell, Jacob Boerema, Jehan, Liam Quin, Michael Natterer,
Peter Oliver, luz.paz, sabri ünal, Sebastian Rasmussen, Simon McVittie,
space pudim, Øyvind Kolås.
Translators: Alan Mortensen, Alexandre Prokoudine, Anders Jonsson,
Andika Triwidada, Asier Sarasua Garmendia, Baurzhan Muftakhidinov,
Boyuan Yang, Christian Kirbach, Daniel Mustieles, Jordi Mas,
Julien Hardelin, Marco Ciampa, Milo Ivir, Piotr Drąg, Rodrigo Lledó,
Sabri Ünal, sicklylife, Stephan Woidowski, Tim Sabsch, Yuri Chornoivan.
We also thank lillolollo, nmat, and Michael Schumacher for triaging bug
reports, and Julien Hardelin for updating the user manual.
During the same time span, specific work on the development version
(future GIMP 3.0) continued, including:
Multi-layer selection support added in the Layers dockable and taken
into account by many tools and features.
Several API improvements:
PDB functions can be called more easily from one plug-in to
another in language bindings;
image rotation is now handled by core GIMP when importing new
images (similarly to how color profile importing happens) and
a new “Rotation policy” setting is made available in Preferences;
GObject Introspection for GimpUI now discards the gimp_ui prefix
when relevant (i.e. gimp_ui_init() will be GimpUi.init() rather than GimpUi.ui_init());
Vala GObject Introspection binding improved;
New concept of “argument sync” to GimpProcedure so that procedure
arguments can be synced with an image parasite of the same name.
Finally, some bug fixing on Windows, e.g. fixing CSS theme loading.
Twain plug-in for Windows ported to v3 API. It was the last C plug-in
which was still totally unported, which means all official plug-ins
are now at least ported at a usable state (if not necessarily to the
latest API as it is still a moving target).
A few improvements to handle smaller screen (which ironically became
even more of a problem with HiDPI scaling being enabled on middle-end
display resolutions).
Former Python 2 specific API (pygimp) has now been fully removed and
all former Python plug-ins have been ported to Python 3 and new GIMP 3
API (this work started over a year ago and is now finished, with a lot
of help from Elad Shahar). The new way to make Python plug-ins is
streamlined, following the same logics as for other supported
languages (C/C++, Python 3, Lua, Vala and Javascript so far).
Some Wayland bug hunting done (still more to go).
GimpSpinScale styling improved and the new style is now unique (old
non-compact style is not available anymore, unlike in GIMP 2.10.x).
Usability of the Input Devices editor has been improved.
The user interface is now available in two more languages in the development
branch (first new languages since Marathi support was added back in GIMP
2.10.6):
Kabyle and Central Kurdish. Please note though that these two additional
translations are not yet present in the GIMP 2.10 series. With these,
GIMP will be available in 83 languages. It is a very good opportunity
to remind that translators are doing a tremendous job.
Also with new file format support (AVIF), various major file format
improvements, new programming languages for plug-ins, our little
Wilber is really getting very studious lately, learning many new things!
We listened to users’ feedback on introducing tool groups in the toolbox in the previous release. A lot of people told us they appreciated the change in general but were quite averse to having to click to open the list of tools in a group. The new release adds the option to show the tool-group menu as soon as the mouse hovers over the toolbox button, without having to click it. This option is enabled by default when the toolbox is arranged in a single column, but it can be enabled for arbitrary toolbox layouts, or disabled entirely, through the Toolbox page of the Preferences dialog.
Additionally, when not using the new behavior, toolbox tooltips now list all the tools in a group, to improve their discoverability.
GIMP now provides a kind of a non-destructive cropping behavior by default. Instead of deleting pixels that you cropped out and thus changing both the layer and the canvas, it will simply resize the canvas. If you export such an image, the resulted file will only have what you see within canvas boundaries.
The benefit of that is (at least) threefold:
You can revert to the original uncropped version by going to Image -> Fit Canvas to Layers. None of your edits between cropping and uncropping will disappear.
If you save your project as an XCF file, you can close the file and even quit GIMP and still be able to remove cropping and then crop differently at any time later.
When you are on the fence about your cropping decision, you can view pixels that you cropped out by going to View -> Show All.
If you want the old “destructive” behavior back, simply tick the ‘Delete cropped pixels’ checkbox in Crop tool’s settings.
The Vignette filter now has on-canvas controls to visually manipulate the geometry of the vignette rather than enter numeric values in a dialog.
Whichever vignette shape you pick, you will always have control for the inner area that stays unchanged, the border of the vignette where pixels stop changing, and the medium point between the two. Dragging the mouse pointer anywhere outside of the outer control will result in rotating the vignette shape.
In addition, there are two new shapes, ‘Horizontal’ and ‘Vertical’.
There are three new filters all related to imitating out-of-focus blur.
Variable Blur takes a layer or channel as an input mask to decide which pixels should be blurred (at what percentage of user-defined maximum blur intensity) and what pixels should stay unchanged, and then blurs pixels with Gaussian Blur.
Lens Blur does the same but provides a far more realistic imitation of the out-of-focus blur, including the partial occlusion of sharp foreground objects by highlights blurred in the background. You also have control of how much highlights are affected.
Focus Blur provides a simple user interface to out-of-focus blurring using the same on-canvas controls that the updated Vignette filter has. You can choose between Gaussian Blur and Lens Blur as blurring methods. One of the uses for the filter is creating miniature fakes out of regular photos — the effect originally achieved by using a tilt-shift lens that changes the plane of focus.
Featured image by Matt McNulty.
New Bloom filter applies an effect that looks a lot like what you can get with the Soft Glow filter but, unlike, Soft Glow, it doesn’t decrease saturation. Technically, Bloom isolates the highlights region, feathers it, and then recombines it with the original image.
The options dialog of GEGL filters now provides a new Blending Options section, which allows controlling the blending-mode and opacity with which the filter is applied.
This replaces the Fade functionality, which was removed in version 2.10.10.
Filter previews now remain cached even when toggled off, allowing for quickly switching between the original and filtered views.
Painting tools can now save and load opacity and blending mode to/from presets.
Canon CR3 files are now properly recognized by GIMP and sent to your raw developer software of choice.
The TWAIN plug-in used for acquiring images via scanners has been slightly refactored and now supports 16-bit RGB/grayscale images.
PNG and TIFF plug-ins now default to not saving color values when alpha channel is present and 0 itself. This is to address security concerns about using simple cutting to remove sensitive information.
The PDF plug-in now imports multi-page documents in bottom-first order, similar to animated formats, and also similar to defaults for PDF exporting. This brings consistency but breaks existing behavior in 3rd party scripts.
As usual, new GIMP release is accompanied by new releases of babl and GEGL libraries.
The new version of babl comes mostly with bug fixes and performance improvements like the use of AVX2 instructions to convert gamma u8 data to linear float (making those conversions between 1.25x and 2.2x faster). It also features VAPI file generation for Vala integration as the unstable branch of GIMP now supports creating new plug-ins with Vala.
The most important changes in GEGL are:
New meta-data API that permits handling non-Exif metadata in different file loaders
and savers in a generic manner
Faster and softer cubic interpolation.
GEGL now gracefully fails when running out of swap space.
The hue-chroma operation has been fixed to avoid modifying hue/chroma of neutrals
The dropshadow operation now has an option to grow the shadow. This means, with zero shift and larger shadow, you can stroke a text or a bitmap layer.
On top of that, GEGL got several new operations, some of which we already described above. Others are:
border-align: places a buffer within the borders of another one.
pack: joins two buffers into one, with optional gap.
piecewise-blend: uses a grayscale map as index into array of buffers used as LUT (required by new blur filters)
reset-origin: moves upper left of extent to 0,0
band-tune: parametric band equalizer for tuning frequency bands of image.
Contributors to this release are: Ell, Jehan, Jernej Simončič, lillolollo, luz.paz, Marco Ciampa, Michael Natterer, Michael Schumacher, Nikc, Øyvind Kolås, pesder, Sabri Ünal, Salamandar, Sergio Jiménez Herena, Simon Budig, T Collins, woob.
Translators: Alexandre Prokoudine, Anders Jonsson, Bruce Cowan, Cristian Secară, Daniel Korostil, Daniel Șerbănescu, Dimitris Spingos, Jiri Grönroos, Jordi Mas, Nathan Follens, Piotr Drąg, Rodrigo Lledó Milanca, Sabri Ünal, Seong-ho Cho, Tim Sabsch, Yuri Chornoivan, Georgy Timofeevsky.
We also thank lillolollo, nmat, and Michael Schumacher for triaging bug reports, and Julien Hardelin for updating the user manual.
We are wrapping up the development in the master branch for v2.99.2, the first unstable release in the 2.99 series leading up to v3.0 some time in the future.
We know that this release is anticipated by various demographics of our users, from people doing digital painting (you can hotplug a graphic tablet now) to photographers using a 4K display (the icon size is right for them now) to people generally wishing to drop GTK2 and Python 2 from their operating systems.
Having said that, there is a warning to make as well.
While we are looking forward to feedback and bug reports, we do not recommend upcoming v2.99.2 for use in production. There are both improvements and regressions from the 2.10.x series. Full details will be published when the release is out (soon).
We skipped announcing 2.10.16 due to a critical bug. Together, the two updates deliver several major usability improvements, a new tool for transformations in 3D space, new release checker, and the usual amount of bug fixes.
Here are release highlights:
Tools are now grouped in the toolbox by default
Sliders now use a compact style with improved user interaction
Vastly improved user experience for the transformation preview
Dockable areas now highlighted when a dockable dialog is being dragged
New 3D Transform tool to rotate and pan items
Much smoother brush outline preview motion on the canvas
Symmetry painting enhancements
Faster loading of ABR brushes
PSD support improvements
Consolidated user interface for merging down and anchoring layers
Update check to notify users of new releases available
Tools can now be grouped in the toolbox, and this option is enabled
by default.
You can customize groups by creating new ones and dragging tools between
them. The changes will take effect immediately. Or you can disable
the grouping entirely. You’ll find configuration options on the
Interface/Toolbox page of the Preferences dialog.
Please note that the default order of tools in the toolbox is now different.
You can customize it as well.
Sliders typically used in GEGL-based filters and tools’ options now have
a compact style by default: they take a lot less space vertically and have
a vastly improved interaction model.
You can use multiple modifiers with either left-click or mouse wheel scrolling:
Left-click + drag changes a value with a default increment
Shift + left-click + drag (or right-click + drag) changes a value
with a smaller step
Ctrl + left-click + drag change a value with a larger step
The ‘You can drop dockable dialogs here’ message is now gone from the
toolbox, and other empty dockable areas. This used to annoy quite a few users
who used a single/double-column layout for the left panel.
But since we still need to hint where you can dock dialogs, whenever you drag
a dialog, all dockable areas will be highlighted.
Since releasing 2.10 in 2018, we received a lot of feedback that the symbolic
icon theme used by default doesn’t have enough contrast. We recently did
a quick poll on Twitter showing people a variation of the theme with more
foreground/background color contrast, and that certainly clicked with users.
Some of the feedback suggested, however, that a part of the demographic likes
the current contrast. So instead of pushing changes for everyone, we
introduced a new high-contrast symbolic theme. You can choose it in the
Preferences dialog, just like any other icon theme.
The contrast is a compile-time variable that you can change prior to building
GIMP from source code. We see this as more of a dirty temporary solution.
With GTK3, it’s going to be a lot easier to make things configurable. In
particular, upcoming Inkscape 1.0 is featuring a new icon theme called
‘multicolor’ that makes a great use of CSS in GTK3 and, while staying symbolic,
uses some color where it matters. We will be definitely looking closer at that approach.
To complement the new high-contrast variation of the symbolic theme, GIMP now
also draws a double black/white border around FG/BG indicator in the toolbox
to make that border more legible, especially in dark themes.
A new option called Composited Preview is now available for most
transformation tools. It enables the rendering of the transform preview
with the right position of the modified layer in the layers stack, as well
as with the correct blending mode.
It comes with two sub-options.
Preview linked items enables previewing changes to all linked items
like layers rather than just the currently selected item.
Synchronous preview render the preview as you move the mouse/stylus
pointer to change the transform instead of waiting for the movement to stop.
This provides instant feedback when GIMP can update the display fast enough,
which is usually not the case with large layers.
GIMP now also automatically previews the clipping of transformed layers.
This allows reducing the amount of trial and error when e.g. rotating.
A new transform tool helps changing the perspective of a layer or panning
it in 3D space. You can set a vanishing point, then rotate the layer
in X, Y, and Z axes.
Multiple modifiers are available to constrain rotation and panning to just one
axis. The Unified interaction checkbox allows shifting the vanishing, as well
as panning and rotating without switching between tabs on the on-canvas
settings dialog. Finally, the Local frame option allows controlling the
transformation in the layer’s local frame of reference, instead of the global one.
The brush outline motion now feels smoother thanks to raising the refresh
rate from 20 FPS to a maximum of 120 FPS, as well as disabling the snapping to
dabs (new option, off by default). The former became a sensible idea thanks
to painting parallelization introduced by Ell several releases ago.
The snapping to brush dabs can be re-enabled on the Image Windows page
of the Preferences dialog.
Additionally, the paint rate of the Airbrush tool was increased from 15 to a
maximum of 60 stamps per second, making paint buildup smoother. Note that, as a
result, the relation between the tool’s Rate parameter and the actual paint
buildup rate is now different, which may affect existing tool presets.
It’s also worth mentioning that the Warp Transform tool now respects
mouse pointer settings defined on the Image Windows page of the
Preferences dialog.
Furthermore, in order to improve the quality of downscaled brushes, paint tools
now use mipmaps for downscaling bitmap brushes. Instead of resampling
downscaled brushes directly from their original size, GIMP now creates a
box-filtered mipmap hierarchy for the original brush on demand, and uses the
closest mipmap level as the resampling source for downscaled brushes. This
significantly reduces aliasing in downscaled brushes, producing smoother results.
GIMP now spends a lot less time loading Photoshop’s brushes (ABR).
So if you use a lot of those, the startup time will become pleasantly
smaller, by order of a magnitude.
The technical explanation is that GIMP used to read the stream of ABR
data byte by byte, and now it uses scanline reading instead.
PSD files now load faster mostly by eliminating excessive copies between
the original file and the project representation inside GIMP. For large
PSD files, the loading is now ~1.5 to ~2 times faster.
Moreover, GIMP is now capable of loading CMYK(A) PSD files (only 8-bit per
channel for now). It does so by converting pixels to RGB(A) float using
sRGB as the profile which, we know, is not good enough for serious work.
However, the plug-in is already using babl formats to specify and communicate
CMYK pixel format encodings with GIMP. This is a good first step towards better
CMYK support. It can be improved both on its own as well as integrate with
the ongoing work enabling general color-space support for babl formats in the
development branch.
The Layers dialog finally consolidates the UI for merging layers and
attaching floating selections.
The bottom toolbar will now display a button for anchoring a floating
selection only when there is one. Otherwise, it will display a button
for merging layers.
You can also use several modifiers:
Shift will merge a layer group
Ctrl will merge all visible layers
Ctrl + Shift will merge all visible layers with last used values
Update check to notify users of new releases available¶
GIMP will now check every time on the start up if the version of GIMP
you have is the latest one available. It will do so by pinging
GIMP’s server for the version of the latest release, then comparing it
to the one installed on your computer.
GIMP will also compare revisions of the installers so that users would
be aware of updated installers available. This is typically useful when
we update installers to provide fixes in 3rd party components that we use.
Finally, this feature is used when constructing a crash report. If you
experience a crash while using an outdated version of the program, GIMP
will now tell you so.
You can disable this feature on the System Resources page of the
Preferences dialog, and manually use the Check for updates button in the
About dialog.
It is also possible to build GIMP without this feature by passing the
--disable-check-update argument to the configure script.
Work on our continuous integration goes forward. We now implemented
automatic compilation of the main development branch both with the legacy autotools build system and the new meson one. We also produce
an alternative build with the Clang compiler (additionally to the GNU compiler gcc).
Moreover, for cross-platform development, we now produce Windows builds,
both for 32-bit and 64-bit, cross-compiled with the
crossroad/Mingw-w64 tools.
All these automatic builds allow us to catch early on specific bugs
which may affect only certain configurations or platforms.
We hope it could also attract new developers wishing to dabble in
contributing. Looking at compilation warnings and trying to fix them may
be a very good first step into GIMP code. It would be much less
overwhelming than actually trying to dive into our huge code from scratch.
If you are interested, look into our CI
pipelines and look at
the last ones (preferably the master branch), then into one of the
various compilation jobs. We will be waiting for your
patches!
There have been several improvements in GEGL since the release
that accompanied GIMP 2.10.14:
Fixed potential data-corruption/crash in the tile-swap back-end on Windows
(the fix has already been made available in an updated installer for 2.10.14),
and improved tile-queuing speed.
The GEGL core now avoids running more thread jobs than there are
pixels to process.
The teardown of buffer caches is now faster when bounding box shrinks.
In-place processing now only happens if region of interest fits in
input abyss.
Edge handling was improved for gegl:distance-transform operation
The babl library got build fixes, improved host CPU detection,
macOS-specific fixes, and Clang warning squelches.
Code contributors to this release are: Alex Samorukov, Anders Jonsson,
band-a-prend, Cyril Richard, Elad Shahar, Ell, Elle Stone, Félix Piédallu, Jehan
Pagès, Jernej Simončič, lillolollo, Massimo Valentini, Michael Natterer, Nikc,
Øyvind Kolås, Pascal Terjan, woob.
Translators: Alan Mortensen, Alexandre Prokoudine, Anders Jonsson, Asier Sarasua
Garmendia, Balázs Meskó, Balázs Úr, Bruce Cowan, Daniel Korostil, Jordi Mas,
Julien Hardelin, Marco Ciampa, Piotr Drąg, Rodrigo Lledó Milanca, Ryuta Fujii,
Sabri Ünal, sicklylife, Sveinn í Felli, Tim Sabsch, Zander Brown.
As usual, we thank lillolollo, nmat, and Michael Schumacher for triaging
bug reports, and Julien Hardelin for keeping the user manual up to date.
Our main objective is still completing the GTK3 port and releasing GIMP 3.0.
This will take a while.
One of the ideas we are also exploring is improving the default
single-window layout and introducing named workspaces streamlined
for common use cases such as general editing, web design, digital
photography, painting etc.
If you customized your default GIMP layout, we encourage you to post
a screenshot and tell us about your use cases for GIMP that affected this
customization. You can do that either
on Twitter or in the mailing list
for users.
Once we have a representative amount of samples for each common use case,
we will analyze the data and see if we can create default workspaces that
you can further tweak to your liking.
2019 was the second year in a row where we shipped updates with new features in the stable branch. Our assumption was that this could change the public’s perception of the ongoing development efforts and shift the balance towards having more contributors. Here is why.
Between 2012 and 2018 (v2.8 and v2.10 releases respectively), we worked hard and added a ton of improvements and new features, we demoed them on social networks, mentioned them in annual reports etc., and yet we kept hearing how GIMP was dead because those changes were not in any stable releases. The same thing was happening before in the four years between v2.6 and v2.8.
Moreover, this was preventing people from contributing as they would have to wait a long time to see their contribution actually used. That wasn’t sparking an interest really.
Hence, after the v2.10 release, we kept adding new features at the same pace and started producing regular updates with those features, and all of a sudden we started hearing how we “picked up the pace”!
So this could be a lesson for other projects: arguing against the irrational is futile. Just don’t keep people waiting. If you did something good, share it!
Either way, there have been three updates in 2019. In terms of focus, here is what we targeted. The list below is far from being complete, these are just the most obvious changes.
GIMP is finally able to optionally display and edit pixels outside the canvas boundaries.
There’s a new preference to allow the editing of hidden layers.
On-canvas handles of transformation tools can now be readjusted after zooming in or out.
The Free Select tool now creates a preliminary selection so that you could both copy and paste the selection and tweak positions of nodes when you do a polygonal selection.
You can now switch to a particular layer by pointing at its pixels and pressing Alt + middle click.
The Curves tool/filter now allows for more predictable editing and comes with two types of nodes instead of one to make more useful, more sophisticated curves.
Due to popular demand, we merged the existing DDS plug-in originally developed by Shawn Kirst. But as none of us is a game developer, we appreciate further contributions from the community.
Layers are now optionally preserved when exporting to TIFF, and if you load a TIFF file with an unspecified channel, GIMP will now ask you how to handle it.
GIMP now supports ICC profiles in HEIF images at both loading and exporting time when built with libheif v1.4.0 and newer.
A major addition here is the Normal Map filter that generates normal maps commonly used in production of 3G graphics and games. It’s already usable for some workflows, and there’s a plan for further improvements.
We also provided direct access to more filters, developed in GEGL a couple of years ago:
Bayer Matrix (for ordered dithering) and Linear Sinusoid (useful for halftoning)
Newsprint, a GEGL version of the old GIMP filter for halftoning, plus quite a few extras
Mean Curvature Blur for edge-preserving blurring
A few more filters, namely Neon, Stretch Contrast, and Oilify are finally on par with the original implementations and thus replaced them.
During 2019, we ported babl, GEGL, and the master branch of GIMP to the Meson build system. While it’s of little relevance to end-users who rely on ready-to-use builds of GIMP, to developers it means much faster compilation time.
We also set up Gitlab-based continuous integration (CI) for all three projects, which gives us a few bonuses over the previously used Jenkins-based solution. One of them is that Windows builds are now available for every successful commit to GIMP’s master branch.
Over the year, Alex Samorukov contributed a bunch of improvements to the macOS version, including support for Catalina.
As you probably already know from the previous report, we manage to backport most of the new features form the unstable branch to the stable one. However, some changes are the result of refactoring and some changes rely on the tech not available in the GTK2 stack.
One of the latter things is the entirely new object-based plug-ins API, with an extra bonus of preserving plugins’ settings across sessions. We expect more to happen there. This part of the work was done mostly by Michael Natterer and Jehan Pages.
The use of GObject introspection has more implications: we switched to Python 3 and made it possible to write new plug-ins in Lua and JavaScript.
Most recently, Jehan started working on a new feature that checks for availability of a newer version of the program and suggests downloading an update. It also integrates into the bug reporting dialog to tell the user if the version currently in use is out of date and the update may not have that bug anymore.
There have been numerous changes in both GEGL and babl:
further work on space invasion to streamline the handling of color spaces, in collaboration with Elle Stone and others;
a ton of changes in the standalone GEGL tool, making it suitable for node-based compositing and video playback;
far more sophisticated CMYK support, up to blending CMYK and RGB pixel data, reading and writing CMYKTIFF and JPEG files;
a better use of available CPU cores on more operations thanks to newly added dynamic computation of per-operation thread cost;
better memory management: when you close large images in GIMP, it will now free used memory a lot faster.
sharper output when downscaling images with the cubic sampler.
Øyvind Kolås also started ctx, a new vector rasterizer project with API inspired by Cairo and HTML5 canvas’ 2D rendering context, and sufficiently small resource footprint to provide modern vector graphics on many microcontrollers.
The ctx library already has support for floating point pixel formats, and that support is geared to end up generic for gray, RGB, CMYK and other multi-component formats. Lack of support for color spaces and pixel encodings beyond 8-bit sRGB in cairo has been a gap for GEGL/GIMP that ctx can end up filling.
Most of the source code changes in all three projects are still coming from the usual suspects: Michael Natterer, Jehan Pages, Ell, Øyvind Kolås, and Thomas Manni. Nevertheless, there have been a few new contributors who seem interested in sticking around.
A significant part of the contributions towards the new build system and CI support came from Félix Piédallu and Salamandar.
We now also have a small dedicated team of people, frogonia and nmat, who triage bug reports on a regular basis and do user support on the IRC channel. Liam Quin who has been team member for a long time, now does the vast majority of user support on Facebook.
We are still lucky to have Julien Hardelin as the author of the user manual.
And, of course, we keep getting no small amount of translation updates from new and seasoned translators. In fact, since the v2.10.14 release, we now mention non-code contributors to the project in release notes.
As usual, we appreciate both coding and non-coding contributions to GIMP, GEGL, and babl.
There are many things we want to improve and even redo completely. And while we do say that certain changes are targeted for v3.2 and beyond, anything goes really, especially with the master branch.
UI/UX redesign? Shapes drawing? Clips for layers? Better text tool? Layer filters? Vector layers? You name it. Talk to us, if you want to work on any of that.
And if you don’t do programming, there’s plenty of work to do all around: updating and translating the user manual, writing new tutorials, updating incomplete translations, even making great art with GIMP and telling people about it.
Connexion
design from new contributor Denis Rangelov (created with the vector art program 
