DICOM images infinite loading

Support
1

DICOM images infinitely loading and not showing up in the viewer

We’ve faced with an issue on the OHIF v3 - it doesn’t show the images, loading them infinitely. On the v4 (4.12.51) it was working fine. All the requests seems to be with status 2XX. In the console I’m getting the following errors:

Uncaught TypeError: navigator.serviceWorker is undefined
    <anonymous> http://xxx.xxx.xxx.xxx:8080/init-service-worker.js:1
init-service-worker.js:1:1
    <anonymous> http://xxx.xxx.xxx.xxx:8080/init-service-worker.js:1

and

ReferenceError: SharedArrayBuffer is not definedindex.worker.ea71efba2ce63c499055.worker.js:1:143844

Behavior is the same in Firefox (113.0.2) and Google Chrome (114.0.5735.106).

Screenshot 2023-06-08 at 16.28.32
Screenshot 2023-06-08 at 16.28.323020×1524 385 KB

OHIF version: v3.6.0

What steps can we follow to reproduce the bug?

  1. Run the OHIF container
  2. Prepare the confing with DCM4CHEE data endpoint
  3. Put the config into the OHIF container
  4. Try to open the study
2

Hello @KernelPryanic and welcome to the OHIF community.

I followed the steps you reported to reproduce the problem, but I was not able to witness the problem you saw. I was able to view images with no trouble. I stand corrected. If instead of using http://localhost to access OHIF I use the ip address of the OHIF server (say http://xxx.xxx.xxx.xxx, then I do see the issue you are reporting. I suspect this is because OHIF uses SharedArrayBuffer which requires a secure context (localhost is considered a secure context). You can find more info about this at Secure contexts - Web security | MDN.

For the record, this is what I did. I ran the (latest, published) OHIF Docker container and used the local_dcm4chee.js config file that is shipped with OHIF as such…

docker run -d -p 3005:80/tcp -v C:\dev\Viewers\platform\app\public\config\local_dcm4chee.js:/usr/share/nginx/html/app-config.js --name ohif-viewer-container ohif/app:latest

One thing you may want to try is to deploy your OHIF temporarily to some place like https://www.netlify.com/ that offers free HTTPS. Be sure that whatever data source you point to has no sensitive data as the site would be live for the world to see. Alternatively, you could create your own docker image that supports HTTPS where you would provide your own certificates.

Hope this helps.

1 Like
3

Hello @jbocce, you’re right, I’ve tested the solution forwarding the SSH tunnel from the host local machine and accessing it via localhost:8080. Also later I’ve configured a reverse proxy with a self-signed certificate and it worked. Thank you!

1 Like
4

Glad that helped. JSYK, there is this PR in cornerstone3D that we started today that partially addresses the problem. OHIF will be able to view non-MPR/volume viewports without the error you reported over a non-secure context. However, a secure context will be required for MPR/volume views.

5

@KernelPryanic I was wondering if you could please outline (in detail) the steps you took to configure a reverse proxy with a self-signed certificate? I would greatly appreciate it and I am sure the OHIF community would also appreciate it and it would be beneficial to all. Detailed steps for both how to create the self signed certificate as well as for setting up the reverse proxy would be great. Thanks so much.

1 Like