On the road to 2.8

I’ve started working on the next G’MIC version 2.8.0.
Here is the current state of the changes done so far, compared to latest stable 2.7.5:

New features:

  • In a math expression, it is now possible to transfer the content of a vector A to a G’MIC 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 even possible to specify image dimensions when storing the vector values, with store(A,'var',w,h,d,s).


  • In math parser, function ext() has been renamed as call().
  • Command restore is deprecated and has been removed. Use input $varname instead.
1 Like

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

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:

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

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

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 :

:arrow_right: https://gmic.eu/files/prerelease/

Any feedback appreciated!

1 Like

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?


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.

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.

1 Like

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

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

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

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.

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


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)

In the docs, references issues.

Character error

Copy-paste error

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