[Bug] Volume rendering broken if using DICOM JSON data source

[jodogne]

Describe the Bug

Dear all,

I write this issue on behalf of the Orthanc community. We are currently trying to upgrade the OHIF plugin for Orthanc from release 3.7.0 to 3.8.0.

Unfortunately, the volume rendering of OHIF 3.8.0 is currently broken if using the DICOM JSON data source and we are unable to identify the reason why. The same DICOM JSON data source is working fine with OHIF 3.7.0. Note that contrarily to the DICOM JSON data source, the DICOMweb data source is working with OHIF 3.8.0.

We would need the help from OHIF developers to identify why the DICOM JSON data source is invalid for OHIF 3.8.0. Thanks in advance for your help!

Regards, Sébastien-

Steps to Reproduce

1. Start Orthanc with the OHIF plugin enabled using the default configuration (which is equivalent to setting the option DataSource in section OHIF to the value dicom-json).
2. Upload the ASSURANCETOURIX DICOM sample from OsiriX to Orthanc. This is a PET/CT study.
3. Locate the ASSURANCETOURIX study in Orthanc Explorer, click on the Open OHIF viewer yellow button, and select Volume rendering.

The current behavior

OHIF 3.8.0 only displays one slice of the volume.

Errors are also displayed in the console: Uncaught DOMException: Failed to execute 'postMessage' on 'Worker': ArrayBuffer at index 0 is already detached.

The expected behavior

The volume should be rendered in its entirety.

Please find attached the DICOM JSON created by Orthanc. It might be ill-formed wrt. the expectations of OHIF 3.8.0, or it might miss some DICOM tag.

dicom.json

OS

Ubuntu 22.04

Node version

21.2

Browser

Chromium 124.0 (same issue with Firefox 125.0.2)

[sedghi]

I know what is going on. Will fix it in 3.8.1

[sedghi]

@jodogneIs there a chance the data is loaded, and the issue lies solely with the window level? That seems to be the case in our test DICOM JSON.

Can you try to window level and see if it is empty or just black

https://viewer-dev.ohif.org/viewer/dicomjson?url=https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json&hangingprotocolid=main3D

[amazy]

Hi @sedghi

I have tried with the 3.9.0-beta-15 which, I assume, includes this fix. I do not see any progress.

I think the problem comes actually earlier, I see a lot of "undefined" errors in the logs and they come from here: which then leads to "undefined" because the error does not have a status in the default error handler

Callstack view if it helps:

Note: you can download the test data from here:

FYI, I also tried to open your test data with the OHIF from the Orthanc plugin (http://localhost:8043/ohif/viewer?hangingprotocolId=mprAnd3DVolumeViewport&url=https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json) and it works

Hope this helps,

Alain.

[amazy]

I gave3.9.0-beta.16 a try. It's working fine now! Thanks

However, in my test setup, I had a special configuration that made it fail again. If you set "HttpThreadsCount": 4, in the orthanc.json, you'll get 3 frames missing in the OHIF display.

Note that I first changed the default http error handler in our custom app-config.js to improve the error display (might be good to push it into the OHIF repo to avoid the 'undefined' warning messages in the console :

  httpErrorHandler: error => {
    // This is 429 when rejected from the public idc sandbox too often.
    if (error.status) {
      console.warn(error.status);
    } else {
      console.warn(error);
    }
  },

It seems that, on my system, OHIF is launching 7 workers to download frames and since Orthanc (in this configuration) is able to handle only 4 concurrent HTTP requests, 3 frames take a very long time to load (4s instead of 8ms) but, they get a normal response after this delay.

Note that I tried this config with the prior OHIF version and, indeed, we see 3 frames missing during the loading of the images but, they do appear at the end when OHIF receives the answer from Orthanc.

[jodogne]

Hello,

I can confirm that this issue is fixed in OHIF 3.9.0-beta16:

The issue was probably linked to the fact that the test image ASSURANCETOURIX from OsiriX is encoded using the 1.2.840.10008.1.2.4.91 transfer syntax. There seems to have been a regression between OHIF 3.7.0 and OHIF 3.8.0 regarding the support of compressed transfer syntaxes.

As soon as a new official release is available for OHIF, we'll package it.

Kind Regards, Sébastien-

[tonitomystery]

What happens to me is that if I have another browser tab active at the time the 3D protocol is being loaded, it loads completely, however if it loads and I remain in the viewer tab, it does not load completely, only a strip. In addition, it only happens with compressed images. In my case, the transfer syntax is 1.2.840.10008.1.2.4.80.