Possible bug in Half.shortBitsToFloat about twelvemonkeys

[Daniel-Alievsky]

I've found an example here and added it to my example set:
https://github.com/scichains/scichains-maps/tree/main/build/java/resources/demo/images/tiff/rare_precisions
But I'm planning to move my TIFF support to another GitHub project soon, so the previous link will become invalid.

[haraldk]

I didn't write this specific code. Please see this StackOverflow answer, where the author explicitly addresses the lines you mention.

So, yes, your code is correct. The other version will just make gradients look smoother. 😀

[haraldk]

Giving it some more thought... Maybe we should just change it to the more standard version, to be less confusing in edge cases like this?

16 bit floats are quite exotic and not very useful in my mind, anyway...

[Daniel-Alievsky]

Thank you for the fix!
Really, it is an exotic case, as well as 24-bit float. But it seems these bit depths could be useful if we need to store large image (100000x100000 ?) containing some result of image processing, such as gradients or Sobel filter. Such operations are usually work much better when they are performed with floating-point values. At the same time, the results are usually close to 0.0, and we do need good precision for values near 0.0, but not for large values like 100-200 (when the source image is represented by bytes 0..255). 16-bit float is an ideal choice for this situation.

[haraldk]

Btw.. Do you happen to have any sample TIFF files with 24 bit floats?

Maybe I need a ThreeQuarter type... 😛