signed 16bit negative values mismatch in interoperablity test between openjph and kakadu

[michaeldsmith]

I've been testing interoperability between kakadu and openjph with lossless compression using signed 16bit data.

If I don't test interoperability between kakadu and openjph, then I get confirmed lossless behavior.

1. encode with kakadu decode with kakadu is lossless
2. encode with openjph decode with openjph is lossless

Everything works when the input values are 0 or positive, but I don't get interoperability for negative values.

3. encode with kakadu decode with openjph is not lossless
4. encode with openjph decode with kakadu is not lossless.

Here is md5sum result for the various files

It seems like kakadu and openjph have different ways of handling the negative values, but it is consistent and therefore invertible/lossless.

Encoding the same source file with kakadu and openjph and viewing the encoded files in kdushow shows a clear difference in how the data is represented in the j2c files

In the snip below, the source is on the left, and the mismatching decoded files are in the center and to the right. I used the Vooya raw viewer with format settings single-channel, 256x256 and signed 16bit to view the decoded raw images.

If I instead treat the input file as unsigned 16bit raw (Nsigned=no with kakadu and -signed false with openjph), there is no issue and I get interoperable lossless performance, and all the md5 hashes match.

The attached zip files contains the source RAW file (all_16bit_values.raw) that contains all 16bit values, and the test scripts as well as the j2c codestreams and the decoded files.

2023_03_29_kdu_vs_openjph_signed_16bit_mismatch.zip

[aous72]

This is an issue of how raw files are processed. We need to have an independent raw_in and raw_out classes.

[aous72]

Thank you Mike for putting this is; I hope this fixes the issue.