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:
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
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:
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.