aous72
commented
3 months ago Hi Mike,
Thank you for putting this in.
I agree this can be a good idea.
Please note that I think the coding efficiency (or reduction is file size) will not be huge -- we can only know when we test it.
Kind regards, Aous.
My understanding is that the internal memory structures in OpenJPH use 32-bit values to store image samples and wavelet coefficients. Depending on various factors (color transform, number of decomposition levels, etc), I think the existing 32-bit memory structures may have enough precision to support up to 27 bit or 28 bit input imagery.
Using HTJ2K compression with both 16-bit float and 32-bit float is of interest in movie production applications. 16-bit float input imagery works great with the existing OpenJPH 32-bit memory structures.
16bit float values are often stored in OpenEXR files during movie production and visual effects work. There is some interest in moving to even higher fidelity workflows using 32bit float values in OpenEXR files.
32bit float values are also commonly stored in 32-bit float TIF files, which are widely supported by many movie production tools and also photography tools, like Adobe PhotoShop and others.
32bit float values are also used for scientific applications, which often use other file formats like FITS or HDF5.
I understand that moving to 64-bit internal memory structures to support 32-bit imagery would double the memory usage, perhaps this could be enabled only when necessary to continue using 32-bit structures and their smaller memory footprint.
The recent and related issue #150 will also help with handling floating point imagery and is especially important when using lossless compression with floating point imagery.