Using samj’s portable at the moment Do have a question, though. I know that G’MIC can handle higher bit depth, but, does G’MIC translate the result to 8 bits or does it recognized the bit precision and passes the higher bit depth level result to GIMP accordingly? Just curious.
This is a tricky question. The assumed range of G’MIC is 0-255 but in CLI it is still a float value. When I prepare a TIF for GIMP, I have to remember to reduce the range to 0-1 or round to the nearest integer (and make the TIF ushort).
The thing about GIMP 2.10.x (and 2.9.x) is that you could change the precision on the fly. There is no way for the plugin to detect which precision it is, and many filters are hard-coded to receive and produce 8-bit channels.
In some of my filters, I included very crude code to detect the range but I have not updated any of them since I have yet to sign on to GitHub — one of these days…
Good question indeed.
Since GIMP 2.9, we have made some coding in the plug-in (with the help of Mitch/GIMP) to manage GEGL buffers, so yes, the plug-in handles high-bit depth images, both for input and output.
But of course, this is true if the plug-in has been compiled with the 2.9 or 2.10 API, not with 2.8.
A way to check that is to apply a gaussian blur (from G’MIC filters) on a 16 or 32 bits image, and look at its histogram them. If the histogram is smooth, then it’s OK. If it’s quantized (contains holes between contiguous values), then the plug-in works in 8bits.
1 Like
Good way to check; just did this and it appears to fix the histogram after I converted an 8-bit image to 16 bit and run anisotrophic smoothing on the image (via G’MIC of course). Glad to know that these operations are passing on the higher bit depth to the result for GIMP. Thanks for the insight, David. I’ll pass this thread elsewhere to share the info. 