[Bug] DicomJSONDatasource volume loading problem

[lambacini]

Describe the Bug

After CS3D Version update, volume loading with dicomjson datasource is broken.
There doesn't seem to be any problem when the viewport is stack, but there is a problem if we want to load it as a volume.

Steps to Reproduce

( no changes were made to the code base for testing. active master branch was used. )

Loading as Stack (Works Smoothly)
http://localhost:3000/viewer/dicomjson?url=https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json

Loading as Volume
http://localhost:3000/viewer/dicomjson?url=https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json&hangingprotocolid=mpr

The current behavior

.

The expected behavior

.

OS

Ubuntu 22.04

Node version

18.18.0

Browser

120.0.6099.71 (x64)

[lambacini]

Ohif 3.7 works fine. After updating cs3d ( ohif 3.8 & cs3d 1.41.0 ) it is not working correctly.
You can reproduce on the master branch.

[lambacini]

From what I can discern, the way the problem occurs ;
in the cornerstone3D library, BaseStreamingImageVolume.ts calls (via imageLoader) the wadouri.loadImage method, when imageRetrieveConfiguration is not set, options.loader is assigned "this" i.e. baseStreamingImageVolume.

in the wadouri.loadImage method, if options.loader is present, this loader is called , but the prefix is removed because it is invoked with the parsedImageId.url parameter (not xhrRequest). Consequently, the image loader cannot be located when the loadImageFromImageLoader method is called, as the prefixes are stripped.

It may not be the right solution, but it temporarily solved my problem (I needed an urgent solution :) )

I hope I have understood and explained it correctly.

@sedghi

[ahlaughland]

I have the same problem as I'm sure anyone who updates will too. It happens with the cornerstone dependency updates to streaming-image-volume-loader at commit 9d1884d

I rolled back to "@cornerstonejs/streaming-image-volume-loader": "^1.27.3", for now.

Hope this helps.

[jianyaoo]

When the 3d version was upgraded to 1.42.0, I encountered the same error problem when dicom loaded wadouri

[Ncp-Zg]

I had the same problem after the update.
Is there any change ?

[AmrGablla]

I have the same error when i use the cornerstone 3D 1.43.7 versions.

[sedghi]

Can you share reproducible steps?

[lambacini]

You can test the following links on current ohif master branch, no extra steps are needed.

Loading as Stack (this works)
http://localhost:3000/viewer/dicomjson?url=https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json

Loading as Volume
http://localhost:3000/viewer/dicomjson?url=https://ohif-dicom-json-example.s3.amazonaws.com/LIDC-IDRI-0001.json&hangingprotocolid=mpr

[sedghi]

I see and confirm, will look

[sedghi]

Just an update: this was added after HTJ2K additions to cs3d, still investigating

[wayfarer3130]

This is resolved using your solution in PR cornerstonejs/cornerstone3D#990

[sedghi]

You can update your cornerstone versions and it is fixed now, until I push a PR to fix upstream. Meanwhile change the loading strategy for MPR and this will fix your missing slices until we properly fix that in this issue #3890

[lambacini]

Thank you for your interest, i will test it and get back to you.

[sedghi]

We just release the OHIF 3.8, you can find more details here https://ohif.org/release-notes/3p8/
If you still encounter this issue in 3.8, please re-open this.