Release of G'MIC 2.3.0

This is the changelog for the release of the 2.3.0 version of the G’MIC software.
It lists all new features and changes done since the latest minor version 2.2.0.

What is G’MIC?

G’MIC (GREYC’s Magic for Image Computing) is a full-featured open-source framework for image processing. It provides several different user interfaces to convert/manipulate/filter/visualize generic image datasets, ranging from 1d scalar signals to 3d+t sequences of multi-spectral volumetric images, thus including 2d color images.

Enjoy !

What’s new in version 2.3.0?

New features:

  • [stdlib-2.2.1] New command apply_tiles (shortcut at) to apply a G’MIC command on blocs composing an image, to make the processing local for each image bloc.

  • [gmic-qt-2.2.1] New filter Details / Local processing allows to apply color normalization or equalization on local neighborhoods.

  • [gmic-qt-2.2.1] Added entry About / Privacy notice which details how automatic filter update works, and what kind of information can be collected from such an update (hint: very few actually :slight_smile: ).

  • [stdlib-2.2.1] New command spt estimate “acceptable” solutions to the Travelling Salesman problem. It is able to order a set of N-dimensional points to create a shortest path.


  • [stdlib-2.2.2] New command linethick draws thick lines in images.

  • [core-2.2.2] New functions polygon() and ellipse() in math expression evaluator allows a mathematical expression to draw a line, a polygon, an ellipse or a circle in an image.

  • [stdlib-2.2.4] New command quantize_area quantize selected images such that each flat region has an area greater or equal to specified min area.

  • [stdlib-2.2.4] New command bump2normal converts a bump map to a normal map.

  • [gmic_qt-2.2.4] New filter ‘Light & Shadows / Illuminate 2d shape’ automatically adds light shading to a 2d drawing over a transparent background to give him a 3d look.


  • [git-2.2.1] Tags describing new versions now will look like v.2.2.1 instead of v.221 (see request).

  • [build-2.2.2] Updated version of a cmake configuration file CMakeLists.txt has been added. Thanks Sander! (see request).

  • [core-2.2.2] Command exec now accepts an additional is_verbose parameter (defaulted to 0) which tells if the invoked command is authorized to output things in stdout/stderr or not.

  • [core-2.2.2] Nan numbers are now detected correctly when -ffast-math optimization is enabled, which allows to compiler G’MIC with all possible optimizations enabled (limited to -O3 before).

  • [core-2.2.2] Improved interactive display used by commands display, crop and select.

  • [web-2.2.2] New gallery page, to get an idea of G’MIC features, with image samples.

  • [core-2.2.3] Saving volumetric images as .yuv file now save all image slices as different frames.

  • [web-2.3.3] Updated web pages and build scripts to create G’MIC plug-in binaries compatible with the latest stable GIMP release (2.10).

  • [stdlib-2.2.3] Use of https connexions for getting filter updates.

  • [web-2.3.3] The G’MIC website now uses https connexions by default.

  • [gmic-qt-2.2.3] Filter Sketch has been recoded from scratch and is now faster. It has been moved to folder Artistic/ also.

  • [gmic-qt-2.2.3] Various improvements and bug fixes in the G’MIC-Qt interface:

    • Key ‘/’ now used as a shortcut to activate the filter search widget (same as CTRL+F).
    • Fixed crash when searching for a filter while a fave was selected.
    • Make Output messages option global, and put it in the Settings dialog.
    • Fix behavior of the reset parameters button for Fave filters.
  • [cli-2.2.3] Command demo has been recoded from scratch and propose a cleaner interface:

  • [gmic-qt-2.2.4] Add support for Qt.5.11.

  • [gmic-qt-2.2.4] Improved error management in the plug-in.

  • [gmic-qt-2.2.4] Improve filters Layers / Blend [standard] by adding a Custom formula blending mode which allows the user to define its own blending mode with a custom expression.

  • [core-2.2.4] Command noise has a different behavior in Salt&Pepper mode: when done on a constant image (with value V), the resulting noisy image has values that can be in set {V-1,V,V+1}.

  • [core-2.2.4] Git repository of the G’MIC core sources have been moved to Framagit. Gihub repositories are still there, automatically mirrored from the ones on Framagit.

  • [gmic-qt-2.3.0] Improvements of the Fourier Transform filter: better support of high-bit depth images, less image data needed and option to choose the magnitude/phase storage type.

Bug fixes:

  • [all-2.2.1] Fixed various typos in source files (see request).
  • [core-2.2.1] Fixed possible issues when loading malformed .bmp file.
  • [core-2.2.1] Fixed buffer overflow in command hessian when called with argument xy.
  • [core-2.2.2] Fixed command guided when radius=regularization=1.
  • [gmic-qt-2.2.2] Better management of layer groups in plug-in for GIMP.

And as always, a lot of small bug fixes! :wink:

1 Like

New features? Tell us more.

No new features planed right now, but when some will be there, I’ll tell you :slight_smile:

– two negates should probably cancel each other out.
– should probably be opacity aware and have an option to negate that or not.

At least, I find it useful that way and made it so in my user.gmic.

They do, if you specify a max value as an argument : $ gmic sp lena +negate 255 negate. 255.

A generic command cannot be sure an input image has an opacity. A 4-channels image may be representing RGBA data, but also anything else (e.g. CMYK). The user has to know what is the semantic of the data he manipulates. If you know your input image is RGB or RGBA, then :
$ gmic image_rgb_or_rgba.png apply_channels negate,rgb will do negate only the three first channels, leaving the fourth one unchanged.

1 Like

Thanks for the info. On the first point, I thought there was a way. Maybe change base_value to max_value. On the second point, I thought about that too. I had to ask because some filters do split_opacity and therefore make the assumption that the input may be RGBA. I guess it depends.

Right, most of the commands doing things specifically for color images (sepia, map_clut…) assumes that input is in sRGB (except commands like cmyk2rgb of course!). For the other more generic commands (basically all purely arithmetic operators), there are no assumption on the input data.
negate clearly belongs to this latter category.

Good to know. I tested negate a bit more using

gmic sp tiger + 10 +negate 255 p. negate. 255 p. -   # 1
gmic sp tiger - 10 +negate 255 p. negate. 255 p. -   # 2
gmic sp tiger * 10 +negate 255 p. negate. 255 p. -   # 3
gmic sp tiger / 10 +negate 255 p. negate. 255 p. -   # 4
gmic sp tiger - {im} +negate 255 p. negate. 255 p. - # 5

#4’s negates didn’t cancel out. negate doesn’t appear to handle decimals well; in particular, when we are dealing with images in the 0-1 range.
#5 shows that g'mic uses signed zeros.

That is just due to rounding errors when dealing with float-valued data. Nothing to worry with, and nothing that can be considered as anomalous.

  • #4 indeed returns a difference image that has a range of 10e-6.
  • Signed zeros is indeed defined in the IEEE floating point norm.

One last question about negate. What should base_value actually be: max signal (1, 255, 65535, etc.) or max value (iM)? I am guessing that it is the former. Sorry this has become a Q&A lol.

Base value is whatever you want or need it to be - it’s best if you think if it as simply a math operation (rather than a way of producing photo negatives). If your input is 0-255 then mostly you would use 255. It entirely depends on the reason for use; G’MIC core commands usually make no assumptions about your input.

1 Like

My issue with the color selector at the moment is that it seem 8-bit, and I’m not aware that it can select LAB value on the image or high depth images. Is that going to be solved?

The color selector is provided by the graphical toolkit (either GTK or Qt, depending on which version of the plug-in you are using). Unless they decide to upgrade it to be able to support 16bits color selection, it won’t be fixed in G’MIC.

So that means no LAB, CMYK, or high depth selection any time soon. Oh well.

  • 2018/03/12 : Release of version 2.2.1.

Thanks for apply_blocs. This is really what I wanted when I asked about CLAHE, the ability to manipulate things in a regional manner. Just a suggestion: in English “bloc” is a word that refers to politics; e.g., Bloc Québécois. Maybe “blocks”, “tiles”, “regions” or even “local” could replace “bloc”.

OK, renamed it to apply_tiles (shortcut at), should be working with the next filter update.

  • 2018/04/11 : Release of G’MIC 2.2.2.

Not a big deal: when I was examining the filters in stdlib, e.g., remove_hotpixels, I discovered that there were 18 instances of -+ commands. With the new syntax the - is no longer necessary, right?

Right, fixed :stuck_out_tongue: