[Bug] Image no longer viewable in OHIF 3.8/3.9

[pcsmits]

Describe the Bug

We occasionally get images that are viewable in our old OHIF viewer 3.6 but not our new viewer (tested on 3.8 and 3.9).

What we see

Sharing a link to google drive which contains screenshots of the issue and success on older viewer, the response data that we are receiving from dicom-web and an anonymized study. https://drive.google.com/drive/folders/16Q5j27OTZL5jewKCM7-ELIOJn0QHTuDn?usp=sharing

We have an old viewer and a newer viewer that we are slowly migrating to. The PACS server is also running a newer version (orthanc) but we validated the responses are identical except for what we will show below.

URLS tested
https://old_cluster.domain/dicom-web/studies/1.2.276.0.7230010.3.1.2.1717921080.1.1731343716.423526

https://old_cluster.domain/dicom-web/studies/1.2.276.0.7230010.3.1.2.1717921080.1.1731343716.423526/series/1.2.276.0.7230010.3.1.3.1717921080.1.1731425540.423628/instances/1.2.276.0.7230010.3.1.4.1717921080.1.1731425540.423629/frames/1

https://new_cluster.domain/dicom-web/studies/1.2.276.0.7230010.3.1.2.1717921080.1.1731343716.423526

https://new_cluster.domain/dicom-web/studies/1.2.276.0.7230010.3.1.2.1717921080.1.1731343716.423526/series/1.2.276.0.7230010.3.1.3.1717921080.1.1731425540.423628/instances/1.2.276.0.7230010.3.1.4.1717921080.1.1731425540.423629/frames/1

Results

First note: the output from the broken queries is in jp2k TransferSyntax (..90)

When comparing the binary contents of the ../frames/1 files, they are actually identical once you have removed the multipart separator. The Content-Type is also identical but the Transfer Syntax is LittleEndianExplicit (...1.2.1) and OHIF receives the frame in jp2K.

OHIF 3.8/3.9 executes this type of call to retrieve the frame: (specifically including jp2)
curl -H 'Accept: multipart/related; type="image/jp2; transfer-syntax=1.2.840.10008.1.2.1" 'http://.../frames/1'
Only on the one images that are breaking are request type jp2 (which doesn't happen on the old viewers for the same image)

while OHIF 3.6 executes this type of call to retrieve the frame:
curl -H 'Accept: multipart/related; type=application/octet-stream; transfer-syntax=1.2.840.10008.1.2.1' 'http://.../frames/1'

Summary

Reviewing the dicom-web response data:

• There is no change of behavior from dicom-web wrt to calls to /metadata and /frames that are the most relevant ones in OHIF.
• OHIF has changed its accept headers but is usually able to handle jp2k images correctly especially MONOCHROME image which is predominantly where we are seeing the errors
• The data is valid in the original file as we can view it in other viewers and older Ohif viewers.
• I believe the issue is wrong in the jp2k image decompression routines in OHIF. These routines were not used in OHIF 3.6 since the file was provided in LittleEndianExplicit TS.

Steps to Reproduce

With the link above download the anonymized dcm image (5mbs) and upload to OHIF 3.6 and OHIF 3.9

The current behavior

Getting errors in the UI for OHIF versions 3.7 and greater, all data is coming back from dicom-web is complete and without errors.

The expected behavior

The image should be viewable in the UI as it is viewable in older versions of OHIF as well as other viewers.

OS

Mac 15.0.1

Node version

node:18.16.1-slim

Browser

Chrome 130.0.6723.119