Release of G'MIC 2.8

David_Tschumperle · October 28, 2019, 9:59pm

This is the changelog for the release of the 2.8.x version of the G’MIC software.
It lists all new features and changes done since the latest version 2.7.5.

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.

G’MIC main project page : https://gmic.eu
G’MIC download : https://gmic.eu/download.shtml
G’MIC web service : https://gmicol.greyc.fr/
G’MIC language tutorial pages : https://gmic.eu/tutorial/basics.shtml
Support G’MIC development : G'MIC — Association LILA

What’s new in version 2.8?

New features:

[gmic-qt-284] New filter Silhouettes / Others / Dragon Curve draws the Dragon Curve on the images. New command shape_dragon has been also added for this purpose.

gmic_dragoncurve1509×833 161 KB
[gmic-qt-282] New filter Colors / Transfer Colors [PCA] linearly transfers colors from one image to another, by transferring mean and covariance matrix (associated command transfer_pca). It can be also used in our image stylization filter Artistic / Stylize. Thanks to @luluxXX for the great idea!

[gmic-qt-282] New filter Details / Sharpen [Multiscale] that uses a multiscale image decomposition approach to bring out the details in your image.

[stdlib-282] New command transfer_pca that transfer covariance matrix and average vector from one vector-valued image to another one.

[stdlib-282] New command palette proposes 34 pre-defined color palettes, with 256 entries each, that can be used for visualization purposes (borrowed from Beautiful colormaps for oceanography: cmocean — cmocean 0.02 documentation and Palette List).
[gmic-qt-282] New filter Rendering / Newton Fractal implements Newton Fractals, with a lot of different adjustable parameters.

[gmic-qt-282] New filter Repair / Unpurple removes purple fringing from photographs. This is a port of GitHub - mjambon/purple-fringe: Removal of purple fringing from digital photos by new G’MIC contributor, Stanislav Paskalev.

gmic_unpurple1770×906 704 KB
[core-281] Support for entry points in .gmic script files, to make them potentially executable (with Shebang). For instance, on Unix, you can make an executable .gmic script file, like this :

#!/usr/bin/gmic
# File 'test.gmic'
  echo[] "Hi my friends!"

[core-281] New command network allows to enable/disable ‘load-from-network’ mode. When disabled, G’MIC cannot access to any data on the network.
[stdlib-280] We have started implementing a neural-network based machine-learning library directly into G’MIC. This is still in alpha-stage. Fully-connected networks have been already implemented and can learn, in a G’MIC pipeline. See dedicated section for more info. This will be hopefully a basis for more complex NN in the future.
[stdlib-280] New command deltaE computes the pointwise perceptual color difference between two images, using either the metrics CIE_deltaE76 or CIE_deltaE2000.
[stdlib-280] New command extract extracts coordinates or values from an image where user-specified condition holds.
[stdlib-280] New command is_variable_name tells if specified argument can be used as a variable name.
[math-core-280] it is now possible to transfer the content of a vector A to a G’MIC image variable $var, with function store(A,'var'). The vector data can be retrieved afterwards in a G’MIC pipeline, as a new image, with input $var . This uses the exact same mechanism as the recently introduced store command. It is possible to specify image dimensions when storing the vector values, with store(A,'var',w,h,d,s).
[math-core-280] Function date() is now able to return milliseconds for the current time.
[math-core-280] New functions begin_t(), end_t() and merge() have been added to add more flexibility to manage multi-threaded computations.
[math-core-280] New functions f2ui() and ui2f() encode potentially large unsigned integers as float values (such numbers are used in G’MIC 3D objects storage for instance).
[cli-280] CLI tool gmic is now able to return an error code different from 0 or -1, by using command error errcode in the G’MIC pipeline.

Modifications / Improvements:

[core-284] Some input expressions have been extended to accept a multiplier argument, e.g expressions (1,2,3)x4, 0x2 and 10,10x3 are now valid, and insert the specified image multiple times on the image list.
[core-284] New pre-defined variable k introduced in math expression evaluator. k stands for the current index in the image list of the image being processed (k is an integer defined in [0,l-1]).
[core-283] Improve management of non-ascii characters and escape sequences in G’MIC scripts.
[build-283] Add -flto flag when compiling G’MIC, to enable ‘Link Time Optimizations’. This leads to smaller compiled binaries.
[core-283] Command output now allows to specify the pixel type as an option, when saving an ANALYZE7.5 file (extensions .hdr or .nii).
[gmic-qt-282] New syntax allowed in a .gmic file, to allow a filter defining its default layer input mode.
[core-282] Math evaluator gets new functions ccos() (complex cosine) , csin() (complex sine), ctan() (complex tangent), ccosh() (complex hyperbolic cosine), csinh() (complex hyperbolic sine) and ctanh() (complex hyperbolic tangent).
[core-282] Slightly optimized the script interpreter, removing extra string comparisons that were useless. This makes a noticeable difference on some filters (+10% gain).
[core-282] Commands map and index now have access to more pre-defined palettes (all those introduced in new command palette).
[core-282] Moved sources back from framagit to github. Framagit repository has been deleted (Framagit is going to shutdown sooner or later).
[core-281] Hide compilation warnings due to header files of OpenEXR.
[cli-281] Environment variable $GMIC_VERBOSITY can be set to the desired initial verbosity of the cli-tool (default value is 1).
[stdlib-281] Command transfer_histogram is based on an improved histogram matching algorithm, and better match the histogram between specified images.
[gmic-qt-280] Filter Frames / Droste now use interactive points that can be moved from the preview widget.
[gmic-qt-280] Filter Repair / Smooth [guided] now accepts an additional layer as a guide image.
[stdlib-280] CLUT compression algorithm is now able to work with different colorspaces and different color metrics. Default values make the compression algorithm try to reduce a perceptual color difference rather than the L2-sRGB metric used before.
[stdlib-280] Command colormap has a new option to sort colors according to their occurrences.
[core-280] Verbosity management has been completely recoded, to make the writing of custom G’MIC commands more simple. See this post for more details about the new rules.
[core-280] Command restore is deprecated and has been removed. Use simpler expression input $varname instead.
[core-280] Command pass now returns the list of selected parent indices in status. A new mode has been added to only return the parent indices, without importing selected images in current environment.
[math-core-280] In math parser, function ext() has been renamed as call().

Bug fixes:

[gmic-qt-283] Fix size of spinboxes used for float parameters, that were too small for some filters.
[stdlib-282] Fix command input_cube to be able to manage .cube files with out-of-gammut values.
[core-282] Fix undefined behavior of command store that was causing some filters not to work on the G’MIC-Qt plug-in for GIMP 2.8.
[cli-281] Fix initial call to cli_start (regression in 2.8.0).
[gmic-qt-280] Small images now displays upscaled in the preview widget before filter is applied.
[stdlib-280] Fix colorspace conversion lab2xyz and xyz2lab.
[stdlib-280] Fix autoset alpha mode for grayscale images in 2D image viewer.
[stdlib-280] Fix texturize3d with large 3D objects.
[core-280] Fix .bmp loader for 16bits-encoded images (RGB565).
[core-280] Fix scope name for commands used to load/save custom formats (e.g. .flo files).
[math-core-280] Fix return values in function critical().

Other informations:

The INS2I institute of the CNRS made it possible for us to hire J-D Schröder, an engineer to work 1 year full-time on the G’MIC project, at our lab (GREYC). This is super great news.
The goal is twofold:

Implement a clean Python binding for G’MIC (Work in Progress) : https://pypi.org/project/gmic/
Propose G’MIC-based nodes for Blender

We’ll share more news when new progress are done.

Enjoy this release!

Reptorian · October 28, 2019, 10:19pm

Is there a way to restore image from variable inside apply_parallel?

David_Tschumperle · October 29, 2019, 7:48am

To restore an image from anywhere, just use input $varname.
And if the ‘anywhere’ is not in the current command scope (like in an apply_parallel argument), the you have to use global variables instead:
Quoting the documentation:

    - A variable definition is always local to the current command except when it starts by the
        underscore character '_'. In that case, it becomes also accessible by any command invoked
        outside the current command scope (global variable).

     - If a variable name starts with two underscores '__', the global variable is also shared among
        different threads and can be read/set by commands running in parallel (see command 'parallel'
        for this purpose). Otherwise, it remains local to the thread that defined it.

afre · October 29, 2019, 7:55pm

I have yet to use parallel processing. In which cases is it particularly useful? (Similarly, I rarely use shared because it confuses me.)

Reptorian · October 29, 2019, 11:39pm

I used parallel processing in rep_tiled_form because it was the only way I can keep the filter at a reasonable speed for generic usage. In the case of shared, I use it if I only need to process channels without any other operation or use a channel as a mask. That reminds me, I need to fix some few things.

@David_Tschumperle Thanks, I fixed rep_form_pixel.

Ooh, I have one thing I would like to see in the next gmic 2.8. A command made to keep the original image size after a command has been ran, or in other way, it only applies the resizing after a command. All it would do is to resize the image back to it original size at nearest neighbor interpolation. It should fail to work when the command results in different number of images.

oisc "_command",_boundary_conditions, _ax, _ay, _az, _ac
oisc is eq. to original_image_size_command

David_Tschumperle · October 30, 2019, 3:38pm

I’ve built the binary packages for version 2.8.0_pre and uploaded to the G’MIC website, you can get it there, to continue getting filter updates :

Index of /files/prerelease

Any feedback appreciated!

afre · November 1, 2019, 1:20am

Updating and compatibility

update (Version 2.8.0 (pre-release #191030)) doesn’t give me the newly committed afre_orien. Are there still issues?

Also I am uncomfortable having the filters be only available for people who upgrade regularly. Not everyone will have the latest version or know how to upgrade. Is there a way to ensure backwards compatibility or at least define compatibility so that the update command may determine what to update for which version?

Licensing

update280.gmic is dual licensed but afre.gmic only uses CeCILL v2.0. Some filter writers may add additional clauses. I think it might be a good idea to delineate which filters have which licences to make it clearer. Right now update*.gmic is simply dual licensed as far as anyone who reads it is concerned.

David_Tschumperle · November 1, 2019, 9:06am

About afre_orien : I’ll check. Apparently, the command is indeed compiled in the update280.gmic file, but was not send to the server, which I don’t understand.

About Licensing:

Basically, the file update280.gmic is a concatenation of the stdlib file and the gmic-community files. Theoretically, I’m not allowed to generate update280.gmic if all licenses of the gmic-community files are not compatible together.

From what I understand, I think we can currently choose a copyleft license (with a contamination clause, like CeCILL v.2) for applying to the update280.gmic file, and it will be OK.

If a contributor’s file in gmic-community has a more permissive license (e.g. LGPL or CeCILL-C), then I’m still authorized to generate the update file, and license it with a less permissive license, and people interested by a filter code in those files can still get it with the more permissive license as well.

Anyway, in the future, we have to take care of the license compatibility when a new file is added to gmic-community.

About filter updates:

IMHO, there are no simple answers to this problem. We have two possible approaches:

Either we force ourselves to keep a strong backward compatibility of the G’MIC syntax and API when new versions are out, so at least, people of older versions can still update and use some of the new filters (those that do not require the use of new introduced features).
Or, we have some breakpoints sometimes, and freeze the filter updates for a set of older versions.

I am more in favour of the second solution. As the G’MIC-Qt plug-in knows its version number, it can still get the latest filter updates that have been done for this particular version.
So, users of older versions can still use some of the filters from gmic-community.

And, from a developer viewpoint, having all filters use a common syntax makes things really easier to maintain (actually, I would be already dead if I had to maintain the filter codes for each possible released G’MIC versions…).

Another point to consider : The GIMP team is working on a resource manager directly integrated into GIMP. This means that in the future, plug-ins would be updated automatically for the users (just as it does on Linux, if you install it via the packages).
This will solve the problem of the updates of the plug-in binary.

afre · November 5, 2019, 2:39am

There is a problem with move. Moving down works but moving up or moving in reverse isn’t behaving as expected. E.g.,

gmic sp tiger,flower,chick mv[1] 0 # flower,tiger,chick

gmic sp tiger,flower,chick mv[1] 2 # tiger,flower,chick

gmic sp tiger,flower,chick mv[1] -1 # tiger,flower,chick

David_Tschumperle · November 5, 2019, 7:08am

That’s expected.
move[img] pos actually inserts the image img between the positions pos and pos+1, and then every image that was before in position [pos...-1] is ‘shifted’ to the right.

For instance, if you have a list with 3 images, you want positions 2 and -1 to represent the same position, so mv[0] 2 and mv[0] -1 should be equivalent (and they are).

It is not really possible for move to act differently if you move an image forward or backward in the list. I mean, for a single image, it could be possible, but what about moving a selection of several images at a position that is located in the middle ? Headache guaranteed

If you want to move an image at the end of the list, then mv[img] $! is the solution.

afre · November 6, 2019, 5:42pm

Basically, it is unusable in this state. The window goes to the top left corner of the screen. The top bar is off-screen and I cannot interact with it. If I try to resize the window or forcibly move it using Windows shortcuts, it redraws itself to its default state. If I click on the main window after the array window shows up, not only do both windows redraw themselves, but the main window covers the array window, preventing me from querying the values.

afre · November 7, 2019, 6:44pm

I noticed two issues with the plugin. If there are solutions for both that I am unaware of, please let us know.

1 Notes cannot take parentheses. I tried escaping them.

2 In a filter where resizing and alignment is present, preview may be cropped and blending layers misaligned. This happens when accepting multiple input layers. The workaround is to reset zoom.

PS If the outcome is smaller than the largest input image, you get a misalignment (the blending is misaligned: see where grass touches the lip) and a crop in the preview. E.g.,

Correct alignment looks like this

David_Tschumperle · November 12, 2019, 10:10am

Just thought a bit about that later, and mv[img] 100% is also working (and is often more user-friendly on the command line, because ! is a reserved character, at least on bash)

afre · November 12, 2019, 6:33pm

In the docs, references issues.

Character error

Copy-paste error

Reptorian · November 13, 2019, 4:22pm

@David_Tschumperle I was updating to see if Fibonacci filter arrived to g’mic. It did not, so I’m guessing there is going to be a stable release of 2.8 soon.

David_Tschumperle · November 26, 2019, 1:20pm

There is one minor syntax change in the G’MIC language that probably makes future versions of the G’MIC stdlib not compatible with current version 2.8.0_pre, so I suggest you update your binaries for 2.8.0_pre as soon as possible.

Basically, the selection shortcuts ., .. and ... (resp. for [-1], [-2] and [-3]), will be accepted also between brackets []. That way, it’s now valid to write something as a[0,.] c (rather than a[0,-1] c).

KaRo · November 26, 2019, 1:49pm

… very good extension to write scripts!

afre · November 26, 2019, 7:10pm

If I am reading this correctly, I always run into this problem when I take in user input. I have to code around this in awkward ways, including changing the way the command behaves. One more request: would it be possible to have a way to convert dot shortcut strings to the long form? That would help make console output text clearer.

BTW,

is that an extra not?

David_Tschumperle · November 27, 2019, 12:19pm

It’s now valid, sorry.

David_Tschumperle · November 27, 2019, 12:20pm

Not sure I understand what you mean here. Details and examples?