You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! I'm posting this issue here instead of OHIF since the issue appears to be linked to CS3D.
When loading a dicom series using the dicomlocal data source in OHIF, the series will load fine, but several warning will get printed on the console.
Investigating a bit, the error is actually printed out by the httpErrorHandler defined on theappConfig.js file , (the handler expects an http Error, but that specific error is a string which contains Couldn't decode.).
Describe the Bug
Hi! I'm posting this issue here instead of OHIF since the issue appears to be linked to CS3D.
When loading a dicom series using the
dicomlocal
data source in OHIF, the series will load fine, but several warning will get printed on the console.Investigating a bit, the error is actually printed out by the
httpErrorHandler
defined on theappConfig.js
file , (the handler expects an http Error, but that specific error is a string which containsCouldn't decode
.).Looking at the stack trace, it points to and errorhandler in the
ProgressiveRetrieveImage
class. More specifically the loader seems to expect thatimageQualityStatus
to be defined on the image instance in order for the image loading to becomplete
.Looking into loaders, the
wadors
loaders will define this property, but not thewadouri
ones.Should the
imageQualityStatus
always be FULL_RESOLUTION when loading from waduri ?Steps to Reproduce
https://viewer.ohif.org/local
The current behavior
The expected behavior
It should not trigger any errors.
OS
Linux 6.12.10-arch1-1
Node version
20.18.0
Browser
Chrome 132
The text was updated successfully, but these errors were encountered: