Open sebastianguerra opened 1 month ago
Using git bisect
, i found that this bug was introduced on the commit d57e8bc1571c6da4effaa492ee2d162c552365a2
"feat(4D): Add 4D dynamic volume rendering and new pre-clinical 4d pt/ct mode (#3664)" version v3.8.0-beta.74
.
I hope this helps
I encountered the same problem
Version 3.9.0-beta.80
I encountered the same problem
Version 3.8.3
Describe the Bug
We found an error while trying to display some DICOM images after updating the viewer from version
3.8.0-beta.67
tov3.9.0-beta.63
I've found that this error only happens if the useSharedArrayBuffer value is 'FALSE', or if it's 'AUTO' and has a bad header configuration.
I was able to find these three examples where it happens
211db473-994bea37-834e2d61-b6fd36de-6d111f90.zip 0ebf9f99-a3d55b05-cac7cbc3-a779754a-379318f1.zip 15bd4b5a-2a7540dc-1c214b1b-7cc31b57-095869de.zip
Also, if it's worth something, these images had the bug before they were anonymized, but not after
865d6b92-c0f67ba2-08cd0b77-fef370d4-0f3b11be.zip f973f213-17ba5067-fa56e529-730bcda2-3a928041.zip
All the given images load and display correctly on OHIF
3.8.0-beta.67
, OHIF V2 and on OsirixFollowing the error trace on the OHIF debugger, i also found out that it is trying to load the image using 'cornerstoneStreamingDynamicImageVolumeLoader' instead of 'cornerstoneStreamingImageVolumeLoader'. Maybe that could be the problem? I see that after getting the imageId the loader doesn't check if useSharedArrayBuffer is enabled or not before calling
createFloat32SharedArray
Steps to Reproduce
The current behavior
Load with error and doesn't show the images
The expected behavior
The studies should load without any errors, and the images should be displayed correctly in the viewer
OS
macOS 14.2.1
Node version
18.16.1
Browser
Chrome Version 123.0.6312.124 (Official Build) (arm64)