After investigating colormap code some more, a curious thing is is_half. This command would only return true if images are in float16 mode. But, I cannot change image format in G’MIC, so it would always be float32. Why is it there to begin with?
Can input images be half?
There is a way to compile G’MIC so that images are stored as buffers of half (float-16) rather than float (float-32). In the provided makefile, see target half.
It uses these compilation flags
-D cimg_use_half -Dgmic_pixel_type=half
This is a highly experimental feature and you will probably encounter a lot of issues doing that. I must admit I haven’t tried for a while, and I wouldn’t be surprised if it doesn’t compile anymore (in that case, fixes are required).
2 Likes
I’ve worked on the sources these last days to try improving the support of float16 datatypes. Still not perfect (particularly when dealing with 3D meshes), but that’s really better now 
1 Like
Hmm, four questions:
- How do we tell what type is G’MIC images is using?
- Does all values inside math parser remains double?
- Doesn’t this mean that my i0<<24|i1 trick would not work in all cases? This works well for preserving values up to max representable double. Given i0,i1 are float32 numbers. So, this means I’d need new commands to address these.
- Are images strictly either float16,float32?
If so for 3, could we have some like casting tools within math parser then? Like, I want to convert double into vector of N size representing a double number and back again? Like the math parser knows what image type is, and use that to convert a double number to a vector of N size, and back again.
Is the need to work half data, or just export to it? I know OpenEXR uses it, don’t know of any others. And, I just don’t see the value in working an image in half when higher-precisions are available (and, default).
I’d be interested to hear from folk who have use cases for the former…
1 Like
Predefined variable _pixeltype contains the name of the pixel type, so gmic echo $_pixeltype will tell you this information.
Yes, variables and values inside the math parser are always stored in double precision.
It will work as long as you keep this value inside the math parser. But of course, if you plan to set it in an image pixel (in case half datatype is used), you’ll get into troubles.
The pixel type used for storing pixel values is an option that is decided during the compilation of the G’MIC interpreter. So, once it has been selected, all images have the same datatype.
By default, this datatype is set to float (aka float32), but it can be half or double (aka float64) as well.
But, for a standard use, float is clearly the best choice (see below).
The half datatype option is just a way to tell G’MIC how images values must be stored internally. This does not change the way image values are exported (e.g. TIFF images with half floating-point values will be still saved as float32 files, because I guess TIFF does not support storing image pixels in half).
This half datatype option has been introduced a few years ago, when I was collaborating with someone working in a startup, and dealing with very large images (very large at that time, like 40.000^2). Storting such images in half data rather than float32 saved 50% of the memory, which was better for his use case.
This being said, apart from this very ‘niche’ usage, I don’t see any interest in forcing G’MIC images to be stored as half rather than float.
The fact is : many filters and commands will stop working correctly because it’s very common to encounter precision problems with half : The maximum integer value that can be stored with full precision in a half (meaning with all correct digits) is 2048, which is clearly a quite low value that will very soon be reached (and exceeded) in many algorithms.
So, TBH, I’m trying to patch the code as much as I can to allow the use of half datatype when necessary, but this should not be an option to consider apart from very experimental tests.
2 Likes