Release of G'MIC 2.7.0

If you decide to translate your filters in several languages, then use #@gui_xx rather than #@gui to declare your filters, where xx is the 2-char string of the locale (e.g. fr or en).
It is then simple to link each of this filter with a different command, where you can set a $_locale variable that can be used in the main filter code afterwards.
Something like this:

#@gui_fr Mon filtre : fx_test_fr, fx_test_fr
#@gui_it Mon filtro : fx_test_it, fx_test_it
#@gui_en My filter : fx_test_en, fx_test_en
fx_test_fr : _locale=fr fx_test
fx_test_it : _locale=it fx_test
fx_test_en : _local=en fx_test

fx_test : 
  if '$_locale '=='it' error "Italian error"
  elif '$_locale'=='fr' error "French error"
  elif '$_locale'=='en' error "English error"

Another website quibble: link on the main page gives Firefox the chills.


Thanks, I’ll fix this. The CImg website does not accept https at the moment.

gmic pairs 1 tic with 1 toc.

gmic tic tic sp tiger toc sp tiger toc

Would it be simpler to allow multiple tocs per tic?

gmic tic sp tiger toc sp tiger toc

I am sure that there is a reason for why it is the way it is…

tic toc? Confuzzled

Imported commands from other *.gmic files don’t have their #@cli, #@gui, etc., tags acknowledged. Would be convenient if we could have all of the commands behave the same way regardless of their location.

I brought this up before regarding the GUI plugin not picking the commands on update. But the same is true for the CLI.

E.g., help info only comes from update*.gmic and user.gmic. In order for it to work, I would have to copy over my custom command to user.gmic. It is bothersome because I prefer certain commands to reside in other files.

Inpaint [Multi-Scale] doesn’t refresh the preview when I change a parameter. A workaround is to select another filter and then re-select it to commit changes.


Inpaint [Multi-Scale] using output mode new layer(s) creates an empty transparent layer.

This doesn’t do that for me.
I have tested with a RGB and RGBA image, and the new output layer just contains the result of the inpainting.

Strange. I am using GIMP 2.10.10 (from Partha) with G’MIC 2.7.3. I tried it numerous times and it turned out that way. Then tried Blur [Gaussian] on the original layer to see if the same was true for it: nope.

Other things to note is that my input float TIF has values less than 0 and greater than 1, and that I painted an area red and then selected father around it. Even without negative values I get this

The red rectangle is the new layer. If I turn off visibility for the bottom layer, I get all transparency.

Ah you are right, it does that when working on a selection.
Probably a bug in the plug-in code, I’ll report that to Sébastien.

Was my fault, it’s fixed now.

Concerning help in gmic cli:

I have a new command (pink_new) in my community file. gmic h pink_new don’t show the help text, still renaming pink_new to let’s say pinknew it prints the help text. Anything with underscore in comments?

gmic h pink_new

shows only
pink_new :

nothing more!

That is strange, it works for me:

:~/work/src/gmic-community/include$ gmic h pink_new

  gmic: GREYC's Magic for Image Computing. 
        Version 2.7.3 (pre-release #191001) 
        Copyright (c) 2008-2019, David Tschumperle / GREYC Lab / CNRS. 


      Pink wrapper name,p1,...,pn (requires the PINK library to be installed).
      prepares input, calls external "name input output" and reads output (/tmp)
      and replaces positional image parameters bei temp. files
      ATTENTION positional image parameter are never spitted and merged
      similar to input and output images
      pink_new prepares selected images and image parameter as pnk files in 'auto' mode and
      creates a command string.
      Files are written as pnk files to temporary space, outfile is
      pnk file name pointing to temporary space.
      "pink_name infile p1 ... (px)imagefile ... pn outfile"
      GMIC_PINK_NO_RM true: created files are not removed
      GMIC_PINK_VERBOSE true: created cmd string and pink messages are printed
      Example: [#1]  image.jpg +pink_new. asfr,5 \
                 pink_new.. asf,5
               [#2]  image.jpg +blur 2 pink_new maxima,4
               [#3]  sp ? to_gray ir. 0,50% +pink_new. distc,3 +negate.. +\
                 pink_new... dist,3 pink_new[1] bisector,[0] pink_new[3] bisector,[2] k[1,3] a c
               [#4]  sp 2 +pink_new. dilatballnum,5 +-
               [#5]  sp boats ir. 0,50% +pink_new. dilatballnum,10 +pink_new.\
                 . distgeo,.,4
               [#6]  sp barbara +pink_new. seuilauto,128,max,3

Hmm, very strange. I thought that it might correspond with @afre remarks. I am using either 2.7.2 or 2.7.3 from yesterday on Mac.

If I recompile my community file, it works too:

gmic m karst…gmic h pink_new

What can I try?

It seems to depend on the input of the update file! I f I change there the line
#@cli pink_new : to #@cli pinknew :
alone, help works, of course with gmic h pinknew!

I have now tried most of my community commands help.
I cannot understand why some don’t list the comments and others do, no recognizable rule for me.
All commands are printing help if I recompile my file with -command!

Doesn’t work for me:

Ah, that’s the www. prefix that is not recognized anymore by the site server. I’m not sure why they changed that (and if this is a permanent change), it’s a bit weird.
Anyway, I’ll remove it everywhere I used it before.

Yeah, it seems that I have been reporting URLs for a while around here. :man_shrugging::woman_shrugging: Guess they change just as people change. :smile: Please change the community links as well. Thanks!