encoding bug in OpenJPEG third party module

[zivy]

The version of OpenJPEG in ITK which is used for JPEG2000 compression (default codec when writing DICOM via GDCM) has a bug encoding int32, it silently fails writing (incorrect write). When attempting to read the result the reader will throw an exception reporting the issue (correct behavior). This appears to be resolved in newer versions of OpenJPEG, so likely updating the module to a newer version will resolve the issue.

Note that the bug was still in OpenJPEG circa 2020 (see this discussion).

Python code illustrating the issue:

import itk
import numpy as np
from imagecodecs import jpeg2k_encode, jpeg2k_decode

file_name = "slice.dcm"
arr = np.arange(100, dtype="int32").reshape(10,10)

image = itk.GetImageFromArray(arr)
itk.imwrite(image, file_name, compression=True)
itk.imread(file_name)

#encoding/decoding works with the openjpeg version used by the imagecodecs package which relies
#on version 2.5.0 of openjpeg
encoded_arr = jpeg2k_encode(arr)
decoded_arr = jpeg2k_decode(encoded_arr)

[issakomi]

The version of OpenJPEG in ITK which is used for JPEG2000 compression (default codec when writing DICOM via GDCM)

GDCM uses own OpenJPEG library (or "system" optionally), it is libitkgdcmopenjp2-5.4.a in ITK build. Yes, it is rather old, 2.3.0 (from 2019, AFAIK). CC @malaterre

...
[ 37%] Building C object Modules/ThirdParty/GDCM/src/gdcm/Utilities/gdcmopenjpeg/src/lib/openjp2/CMakeFiles/gdcmopenjp2.dir/j2k.c.o
[ 37%] Building C object Modules/ThirdParty/GDCM/src/gdcm/Utilities/gdcmopenjpeg/src/lib/openjp2/CMakeFiles/gdcmopenjp2.dir/jp2.c.o
[ 37%] Building C object Modules/ThirdParty/GDCM/src/gdcm/Utilities/gdcmopenjpeg/src/lib/openjp2/CMakeFiles/gdcmopenjp2.dir/mct.c.o
[ 37%] Building C object Modules/ThirdParty/GDCM/src/gdcm/Utilities/gdcmopenjpeg/src/lib/openjp2/CMakeFiles/gdcmopenjp2.dir/mqc.c.o
[ 37%] Building C object Modules/ThirdParty/GDCM/src/gdcm/Utilities/gdcmopenjpeg/src/lib/openjp2/CMakeFiles/gdcmopenjp2.dir/openjpeg.c.o
...

[blowekamp]

Is this an issue that need to be reported and addressed in the GDCM repo?

[issakomi]

Is this an issue that need to be reported and addressed in the GDCM repo?

GDCM uses own OpenJPEG library (or "system" optionally)

Yes, but also there may be other issues with BitsAllocated 32 sometimes and the line prec=%u (should be between 1 and 38 according to the JPEG2000 norm. OpenJpeg only supports up to 31) is still in OpenJpeg master, s. here and here. It is not simple, IMHO. Maybe build GDCM with system's OpenJpeg (on Linux it is easy and the version is 2.5.0+) and test, does it help or not.

Edit: also see this line in GDCM.

[zivy]

Just posted the issue on the GDCM bug-tracker (https://sourceforge.net/p/gdcm/bugs/559/).

@malaterre, really appreciate your help resolving this. We have some naive SimpleITK users who encountered the problem, using a system OpenJPEG is not an option for them - it is beyond what they can do. Thanks.

[malaterre]

Just posted the issue on the GDCM bug-tracker (https://sourceforge.net/p/gdcm/bugs/559/).

@malaterre, really appreciate your help resolving this. We have some naive SimpleITK users who encountered the problem, using a system OpenJPEG is not an option for them - it is beyond what they can do. Thanks.

@zivy I was not involved in the original Modules/ThirdParty/OpenJPEG, please update and you should be done. Last I checked this is the j2k module used by ITK/GDCM.

[zivy]

Hello @malaterre,

Sorry, but I'm a bit confused.

Per @issakomi's observation, the OpenJPEG library used by GDCM appears to be fromModules/ThirdParty/GDCM/src/gdcm/Utilities/gdcmopenjpeg which is separate from the Modules/ThirdParty/OpenJPEG (I originally thought that module was what needed to be upgraded). This is why I ended up posting the request for updating the library on the gdcm issue tracker. What am I missing here? Thanks for taking a look at this.