Open jodogne opened 4 months ago
I know what is going on. Will fix it in 3.8.1
@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
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.
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.
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-
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
DataSource
in sectionOHIF
to the valuedicom-json
).ASSURANCETOURIX
DICOM sample from OsiriX to Orthanc. This is a PET/CT study.ASSURANCETOURIX
study in Orthanc Explorer, click on theOpen OHIF viewer
yellow button, and selectVolume 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)