Support for 16 bit gray images?

[FrancescAlted]

My understanding is that OpenHTJ2K supports mainly 32 bit sRGB images (4 bytes/pixel) as inputs. We would be interested in knowing if it could accept 16 bit gray images as well, or we need to 'massage' the data to convert it to sRGB first (if so, anybody knows a good tool for doing that?). Thanks in advance!

[FrancescAlted]

I did a small test with a 16-bit gray scale image, and it looks like OpenHTJ2K is limited to 12 bits per component:

$ identify MI04_020089.ppm
MI04_020089.ppm PPM 1008x1900 1008x1900+0+0 16-bit Grayscale sRGB 10.9589MiB 0.040u 0:00.019

$ open_htj2k_enc -i MI04_020089.ppm -o MI04_020089.j2k
elapsed time for reading inputs 15.108         [ms]
760.603654 [MB/s]
WARNING: Over 13 bpp precision will be down-shifted to 12 bpp.
WARNING: Over 13 bpp precision will be down-shifted to 12 bpp.
WARNING: Over 13 bpp precision will be down-shifted to 12 bpp.
Codestream bytes  = 1441685 = 6.022076 [bits/pixel]
elapsed time 73.215         [ms]

$ ll MI*
-rw-r--r--  1 faltet  staff   1.4M Oct 27 13:14 MI04_020089.j2k
-rw-r--r--  1 faltet  wheel    11M Oct 27 13:12 MI04_020089.ppm

$ open_htj2k_dec -i MI04_020089.j2k -o MI04_020089-recons.ppm
WARNING: sample precision over 13 bit/pixel is not supported.
WARNING: sample precision over 13 bit/pixel is not supported.
WARNING: sample precision over 13 bit/pixel is not supported.
elapsed time 59.992         [ms]
throughput 95.772770 [Msamples/s]
throughput 0.010441 [usec/sample]

This limitation is documented in the README indeed, but I am wondering if it could be a workaround for this (like passing 2 components of 8 bits coming from the low and high parts of the original 16 bit channel or something similar)? Thanks in advance!

[osamu620]

@FrancescAlted Due to the limitations of vectorized fixed-point DWT, currently, 16bit/pixel is not supported in OpenHTJ2K. The workaround you mentioned might increase codestream size because generally, the lower part (lower bits) of pixel values do not have a strong mutual spatial correlation. Moreover, encoding/decoding of two separated components is not efficient in terms of processing time.

Even so, you can still compress 16 bits/pixel images with the workaround, but, separating/concatenating of two components should be done outside of HTJ2K codec.

To support 16 bits or over 16 bits/pixel, floating DWT operating mode is required. Although I currently don't have enough time to implement this, I will add this floating mode in (hopefully) the near future.