[Bug] Issue with Loading Compressed DX Images

[emelalkim]

Dear Team,
We have encountered a critical issue related to loading compressed DX images using cornerstone. Upon investigation, we have observed the following error messages and behavior:

1. Data Specifications:

• Compressed DX images

2. Error Messages:

   • Failed to decode tile error message

3. Related Posts/Issues:
   We have come across a similar problem in a forum post with no apparent solution.
   Also, there is this open issue but it doesn't mention DX or compressed images

4. Specific Behavior:

• Behavior in ePAD using cornerstone and DICOM P10 from local file system:
  Specific images seem to trigger this behavior. If we attempt to load the problematic DX image first (sample data), any subsequent DX image loaded ends up displaying all black. Opening a DX image that loads properly first, and then opening the problematic DX image seems to resolve the issue temporarily. Both series and all images of the series are displayed.
• Behavior in OHIF
  We were also able to partly reproduce the problem in OHIF local version. The sample data can load only one of the images. The other two throws "Failed to decode tile" error message

6. Sample Data:
   3 Compressed DX images

We're actively investigating. Any insights and pointers are appreciated.

Steps to Reproduce

1. Scenario One: Not opening
   a. Open DICOM P10 From local file system live-example.
   b. Drag drop one of the images with no _1003good.dcm at the end.
   c. It should throw failure to decode error
   d. Drag drop EE0E3825_1003good.dcm (without refreshing the page)
   e. It should throw failure to decode error again
2. Scenario Two: Opening
   a. Open DICOM P10 From local file system live-example (or refresh the page).
   b. Drag drop the image named EE0E3825_1003good.dcm
   c. It should display fine.
   d. Drag drop one of the images with no _1003good.dcm at the end (without refreshing the page)
   e. It should display fine.

The current behavior

When we try to load the jp2 DICOM file without opening another DICOM that opens fine first, it throws
[ERROR] opj_decompress: failed to decode tile!
task decodeTask failed - Aborted(). Build with -sASSERTIONS for more info. RuntimeError: Aborted(). Build with -sASSERTIONS for more info.
at z (openjpegwasm_decode.js:9:7718)
at i (openjpegwasm_decode.js:9:52570)
at 65916ef3def695744bda.wasm:0xb9c
at 65916ef3def695744bda.wasm:0xf654
at 65916ef3def695744bda.wasm:0x1a728
at 65916ef3def695744bda.wasm:0x1ab63
at J2KDecoder.J2KDecoder$decode [as decode] (eval at (openjpegwasm_decode.js:9:35236), :8:1)
at l (decodeJPEG2000.ts:73:11)
at async H (decodeImageFrame.ts:164:25)
at async Object.handler (decodeTask.ts:51:9)

The expected behavior

There are 2 issues that need to be fixed

1. It should be able to display the jp2 DICOM images without issues
2. If it cannot open a DICOM file it shouldn't be affecting/leaking to other DICOM openings

OS

macOS 14.1.1

Node version

20.9.0

Browser

Edge 119.0.2151.72, Chrome 119.0.6045.199

[webkriativa-gabriel]

Here's another example of a file that induces this behavior:
https://drive.google.com/file/d/19dZl32rLbi_pWFRvH6sSQCkG6jLsyGj0/view

[emelalkim]

Hi @sedghi,

• I did a diff check for the src files as you suggested. Only 2 files have changes and I'm pretty sure the issue is in the J2Decoder. Here are the links to the diff J2KDecoder diff, CMakeLists diff.
  I tried to understand what could cause the issue in these changes. I think it is either the disabling of strict mode (Chris's code disables strict mode) or the additional things done by cornerstone's version (Create a JavaScript-friendly result from the memory view and color_sycc_to_rgb).
  What do you think? Would you be able to compile the library with disabling the strict mode so that we can try?

• Additionaly,

1. I tried copying the js and wasm files to the nodemodules but it fails with Failed to execute 'postMessage' on 'DedicatedWorkerGlobalScope': ArrayBuffer is not detachable and could not be cloned which makes sense as the builds are actually quite different
2. Adding try catch didn't work, although I catch and set the codec to null or used another variable it somehow leaks and I get done() invoked with non-Error: Aborted(). Build with -sASSERTIONS for more info on the second, non-problematic DX
3. I compared Chris' sample code and the way decode is done in cornerstone. Cornerstone uses decoder.decode(); instead of decoder.decodeSubResolution(decodeLevel, decodeLayer) and cornerstone's getPixelData creates Int8Array and Uint8Array instead of just returning the decodedBuffer. I don't think these can cause anything

[emelalkim]

Hi @sedghi, any opinion or update about this?

[emelalkim]

Hi @sedghi,
I tried building codecs myself. I disabled strict mode, but it didn't resolve the issue.
I can reproduce the issue now in codecs project's tests. If I use openjpegjs_decode.js (in test/index.js), it doesn't fail/it can decode successfully. However, if I use openjpegjs.js itself, it throws "failed to decode tile" error message.
I added lots of logs and tracked it down to this line in the openjpeg code. It cannot allocate the memory.
This happens with both strict mode disabled and the original code. I don't understand why it is working in the openjpegjs_decode version and failing in the openjpegjs one. As far as I see, the only difference is the addition of the encoder. It seems like it is messing up something with the memory allocation.
Any ideas on what can cause this or who to ask for help?

[daker]

@emelalkim is this fixed ? if yes then close the issue