On the road to 2.3.0


(David Tschumperlé) #1

This is the current changelog for the 2.2.X version of G’MIC, towards the next major version 2.3.0.
This list will be updated as new features or corrections are done on the source code.

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.



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

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.


New features? Tell us more.

(David Tschumperlé) #3

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.

(David Tschumperlé) #5

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.


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.

(David Tschumperlé) #7

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.

(David Tschumperlé) #9

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.


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?

(David Tschumperlé) #14

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.

(David Tschumperlé) #16
  • 2018/03/12 : Release of version 2.1.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”.

(David Tschumperlé) #18

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