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 complete list of changes, you should refer to the
NEWS file or look at the commit history.

GTK+3 port officially done

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.

GimpAction infrastructure

Our last big work was to port how “actions” are handled, which in GTK vocabulary means shortcuts and their mechanism, but also how menus are handled and how generic widgets can be quickly assigned shared action codes. 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 two 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 add new concepts which we have 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 that are worth noting.

Multiple shortcuts per action

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, the 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 the keypad or top row). Now we can just assign both variants to the 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.

Action Search improvements

Now that we have our own action wrapper, we made it 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 find their ways better.



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.

Improved GEGL operations GUI integration

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 filter 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:



And here it is:


Easily adding a third-party filter to menus - GIMP 2.99.16


GIMP will automatically generate 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 that 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 someday 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



Tools

Text tool

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.



Hiding the on-canvas text editor - GIMP 2.99.16



Align and Distribute too

The tool had been fully reworked in GIMP 2.99.14.

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).

Unified Transform tool

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 an immediate preview of the transformation, then copying and pasting the matrix).

Space Invasion

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 was 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), so 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.

Graphical User Interface

New option “Merge menu and title bar”

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 the 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.

Themes¶
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 of implementing settings for color customization of the theme.

Now we are not sure what will happen for GIMP 3.0. It will really depend on whether we get more theme contributions by the time we release.

Fill and Stroke selection/path improvements

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 two options “Line” and “Paint tool” easier to use.

As a result of saving dialog space, we don’t hide the “Line Style” settings under an expander anymore in order to show more prominently the line rendering options.



Reorganized Stroke dialogs - GIMP 2.99.16


“Middle Gray (CIELAB)” layer fill option

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.

File Formats

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.

FITS

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 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.

PSD (and a bit of TIFF and JPEG)

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 that 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 tag better 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's proprietary metadata format. We have already implemented two 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.

JPEG

In 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.

JPEG-XL

We added initial support for CMYK(A) export: Key and Alpha data is saved in extra channels, and the simulation profile is also saved.

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.

DDS

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.
  
• DCX: containers that store up to 1023 PCX files.

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, and reusing and working 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 they should be soon.

Plug-in API

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.

Resources data get their own class

GIMP plug-ins are 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 this kind of real-life name clash.

Plug-in localization improved

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 [i]_() or N_() to translate strings?[/i]“). Now it’s
very simple: the plug-ins take care entirely of their own localization, hence always sending 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 its 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 makes 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.

More specialized plug-in argument types

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.

And more…

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.

GEGL, babl
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 provided 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 two new operations:

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.
 


 gegl:chamfer
 
 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 a 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 of 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 from 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