gmic command line in windows 10 gives error and outputs blank image

OS: Windows 10
GMIC verison: gmic-2.9.2-cli-win64
Using powershell to run the commands

This is the command I use, for example. However, it is not only the glow filter that does this, but anything I try to use.

.\gmic.exe -input ‘D:\Pictures\Olympus\3-8-21\DSC00064.tif’ -glow 1% -output ‘D:\Pictures\Olympus\3-8-21\DSC00064-out.tif’

The output file is created, but the image is blank. It’s just a white image. The command line outputs the following.

    .\gmic.exe : [gmic]-0./ Start G'MIC interpreter.
    At line:1 char:1
    + D:\cli-utils\gmic\gmic.exe -input 'D:\Pictures\Olympus\3-8-21\DSC ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: ([gmic]-0./ Start G'MIC interpreter.:String) [], RemoteException
        + FullyQualifiedErrorId : NativeCommandError
     
    [gmic]-0./ Input all frames of TIFF file 'D:\Pictures\Olympus\3-8-21\DSC00064.tif' at position 0 (1 image 3286x2460x1x3).
    [gmic]-1./ Add soft glow on image [0], with amplitude 1%.
    [gmic]-1./ Output image [0] as tif file 'D:\Pictures\Olympus\3-8-21\DSC00064-out.tif', with pixel type 'auto', no compression and bigtiff support (1 
    image 3286x2460x1x3).
    [gmic]-1./ End G'MIC interpreter.

Anybody have an idea what could be the problem? Google turned up nil.

Try updating the gmic version. I’ll refer to @David_Tschumperle and @afre to see if they have anything about glow.

If your input is a 16-bit TIF, you will have to divide the image to get it into range.

gmic image.tif div 257 glow 1% mul 257 output image2.tif
2 Likes

A web search suggests that PS has a different way of handling stderr. See the [gmic] output? PS doesn’t like it but G’MIC should be running all right. Either ignore this notice or redirect the error output.

Yeah, I tried the most recent version after posting it, same result. It wasn’t limited to glow, that was just one example. Nevertheless, I think the below posts answer my question. Now, if only I could figure out how to get gmic to retain the embedded icc profile insead of stripping everything down to sRGB.

G’MIC is profile agnostic. It sees the inputted image as data only. Some but not all commands assume sRGB [0,255]. Others don’t care what the colour channels and their ranges actually are; they just do the same thing to all channels. It takes getting used to and is the reason that I got into G’MIC scripting. I had to read the code to see what the command was doing.

  • To me, there is no errors. The command succeeds flawlessly. But the output image is probably float-valued, meaning the output tif is also float-valued. But for some unknown reason, most of the image viewers don’t manage float-valued tif files.

Try re-opening your output file with G’MIC and see if your processed image displays correctly:

.\gmic.exe D:\Pictures\Olympus\3-8-21\DSC00064-out.tif

If you see something in the G’MIC viewer (not blank stuff), then clearly your another image viewer is faulty (and it could be nice to send a feature request to the developers, to ask supporting float-valued tif image files).
In that case, a workaround can be to force G’MIC outputs a 8bits or 16bits tiff file, with

-output ‘D:\Pictures\Olympus\3-8-21\DSC00064-out.tif',uchar

(for 8 bits), or :

-output ‘D:\Pictures\Olympus\3-8-21\DSC00064-out.tif',ushort

(for 16 bits).

Note that if your input .tif file is 16bits (i.e. ushort-valued), then it is probably a good idea to divide the values by 257 before applying any filter in G’MIC. Most G’MIC filters assumes the RGB range of pixels is in [0,255] (but not 8bits integers, just float-valued).
And the same, if you want to output a 16bits tiff files, just remultiply the values by 257 before saving:

.\gmic.exe -input ‘D:\Pictures\Olympus\3-8-21\DSC00064.tif’ -div 257 -glow 1% -mul 257 -cut 0,65535 -output ‘D:\Pictures\Olympus\3-8-21\DSC00064-out.tif’,ushort

Of course no need to do that for 8bits tiff input files.

The quotes around the file names look suspicious to me.
It looks like you are using single-quotes (’) instead of double-quotes (").

I am not sure about PowerShell, but generally the command shells on Windows expect paths to be double-quoted.
Using quotes around a file path is only required if the path contains spaces.

With certain functions (such as remove_hot_pixels or iain_fast_denoise to name two) the scaling of the pixel values you demonstrated doesn’t seem to stop the output from being completely blown out, unfortunately. Another post suggested it could be because my images are floating point tiffs, but they are 16-bit integer tiffs. So, not sure what the issue is, but at least some work right

One way to know what your range is and if it is off course is using the command print. Insert it anywhere in the chain of commands and you get the images’ stats.

The reason that your image is blown out is when you process or save it, and it isn’t in the expected range, it gets clipped. E.g., if you blend with an image that is in [-255,65535], all values above and below [0,255] will be white or black. Does that make sense? So, in G’MIC, you have to do a bit more thinking and doing than your average app. This is by design, however, and makes G’MIC suitable for broader applications.