Consistent Behaviour across the fx_... Commands?

Software G'MIC
1

Hi, I’m helping a Gimp user move to using gmic(1) more from the shell so they can batch process, etc., but I’m finding the fx… commands don’t have a consistent interface which makes them awkward to switch between.

As an example, they might run a few 16-bit PNGs through a script which does

gmic \
    verbose - \
    "$@" \
    / 257 \
    fx_pencil_portraitbw 30,120,1,0.5,144,79,21,0,50,50 \
    '*' 257 \
    outputw

This works fine with outputw overwriting the original input files, as desired. I suggested the fx… line could be changed to whatever GUI filter they’d been experimenting with in Gimp. This doesn’t always work, e.g. fx_illustration_look 100,0,0,0,0…

I see from gmic-community/david_tschumperle.gmic at master · dtschump/gmic-community · GitHub that it removes the original layer and creates a new merged layer holding the result. This causes outputw to write to the file name([unnamed]),mode(normal),opacity(100). file(1) here doesn’t identify it, but I correctly guessed it was gmic’s native format and, by renaming it to not contain parenthesis, can display it with gmic and see the expected result.

Is this a fault or is each fx… allowed to have whatever interface is thought useful? Is there anything which would let me provide something like the invocation above where the fx… is readily switchable?

The fx… don’t seem to be documented so I assume the source of each needs reading to work out how to wrap it to overwrite the original file? Is it at least true that they all expect values in the range [0, 255]?

(Originally, I didn’t have the div and mul by 257 because fx_pencil_portraitbw happily took a [0, 65535] RGBA image and produced [0, 255] so it didn’t seem necessary. But only the RGB was altered and the unchanged A caused outputw to write a 16-bit PNG with black RGB. :slight_smile:

Lastly, the input PNGs here are either 8-bit or 16-bit and the latter need the scaling down to [0, 255]. Is there a variable or similar which lets the script know if it was 16-bit so it can conditionally scale?

Thanks for G’MIC. It’s replaced ImageMagick, which I never liked, for my command-line use and may topple netpbm, which I do like, in time!

Cheers, Ralph.

2

Fx commands are essentially commands used by the gui filter. You should look for the cli command version of the fx/gui ones during the meantime.

3

The fx commands have huge variation (number of input/output layers, expected number of channels, value range…) so that’s not possible to easily cover all cases.

What I would suggest is create a user gmic file (.gmic on linux or user.gmic on windows I think) with your own “wrapper” command, so you can do some more complex handling. Either that or supply a command file with gmic m myfile.gmic ...

That way you could store the original name in a variable (savename={n}) and allow an input range to be specified.

4

There is also something else you can do, to ensure the input filename is conserved:

gmic input.png nm={n} fx_filter params nm \$nm ow