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.
I see from https://github.com/dtschump/gmic-community/blob/master/include/david_tschumperle.gmic#L44 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
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.
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!