Pixels added to image even without code in filter


I have created a Gmic filter with no code. Just the initial lines:
#@gimp LR_slider : lr_slider, lr_slider_preview(0)
#@gimp : something = int(210,150,240)
lr_slider :

I’m using it in Gimp on a 5x5 pixels image. The filter has a integer slider. If I run the filter with no code it creates a black bar with a width of the slider’s int value in the first row of the image and an extra image with just the black bar??
Can somebody tell me what I’m doing wrong?


You must use the slider value for something or gmic interprets it as a command to create an image.

if you add something like

-blur $1

then it should work as normal


Oh, this is so typical…
…while debugging other things I commented out the place where I used the slider value in order to pinpoint mistakes in other places and that’s what happened.
Thank you, @Iain !!

(David Tschumperlé) #4

Technically, a G’MIC command may have arguments or not, so when defining a custom command, what the G’MIC interpreter does first is to check if the command makes use of argument variables, as $1 and so on, to detect if the custom command requires arguments.
In your case, it didn’t, so it indeed interpret a call like -lr_slide 4 as -lr_slide -input 4, which explains the unexpected behavior.
To avoid this, you may want to start all your custom commands with something as -skip $*, to be sure G’MIC knows that your command will take arguments one day or another :slight_smile:


This used to catch me out so often!

I had trouble understanding how -skip could fix it too, until I realised $1, $* and so on are always substituted.

So -skip does nothing with the parameters, but they are still used in the command which avoids an unexpected image appearing. That’s how it works in my brain at least, whether it’s technically correct or not…

(David Tschumperlé) #6

Yes, and to be more precise : each time the G’MIC interpreter encounters a custom command call, it actually generates a ‘temporary’ version of the command source code, where all arguments $1,$2,... have been substituted by their current values. It ends up with a possibly long string without $1,$2,... anymore, then start to interpret it.
That is also why the arguments $1,... do not exactly behave like other variables $foo for instance, because the latter are substituted during the custom command evaluation, not during its instantiation.
This becomes a bit technical though, and I’m not sure this is of any interest for the casual reader :slight_smile: