You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
encode with kakadu decode with kakadu is lossless
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.
encode with kakadu decode with openjph is not lossless
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.
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.
Everything works when the input values are 0 or positive, but I don't get interoperability for negative values.
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
The text was updated successfully, but these errors were encountered: