Closed KernelPryanic closed 11 months ago
@KernelPryanic thanks for reporting this issue. Would it be possible for you to provide an anonymized copy of the DICOM file(s) needed to reproduce this problem?
@jbocce, I have also encountered this issue using public data. Similar to @KernelPryanic, it triggers when trying to load the segmentation. I also see the same error: TypeError: Z.toFixed is not a function
in reference to SliceThickness in OHIFCornerstoneSEGViewport.tsx. I hope this helps. Let me know if you need any more information.
Thank you @mccle. That is great information. I tried a few of the patient ids from that public data, however I did not see the problem. Could you please point to a specific study/patient id of that data that demonstrates the problem? Thanks so much.
Thank you for responding so quickly, @jbocce. The cases I had checked had StudyInstanceUIDs of 1.3.6.1.4.1.14519.5.2.1.3671.4754.117496148504386222592571043379, 1.3.6.1.4.1.14519.5.2.1.3671.4754.131608903441424620949571415524, and 1.3.6.1.4.1.14519.5.2.1.3671.4754.121472087445374646718121301133. I encountered the error with all three when trying to view the segmentations.
@mccle, for whatever reason, I have not been able to reproduce the problem with any of those studies listed. Furthermore, I also arbitrarily checked a few the series for the SliceThickness
and SpacingBetweenSlices
and found them to have a valid numeric value for which toFixed
would be safely called. That said, I suppose we could add further checks of SliceThickness.toFixed
and SpacingBetweenSlices.toFixed
for further safety. Thoughts?
@jbocce, it looks like the error was the result of my SliceThickness
being defined as "3"
and being unable to call toFixed
. I added parseFloat
to a couple of lines in extensions/cornerstone-dicom-seg/src/viewports/OHIFCornerstoneSEGViewport.tsx
and it seems to have fixed the problem I was having before and renders segmentations. These are my changes (starting at line 346):
...
thickness: SliceThickness ? `${parseFloat(SliceThickness).toFixed(2)}mm` : '',
spacing:
SpacingBetweenSlices !== undefined
? `${parseFloat(SpacingBetweenSlices).toFixed(2)}mm`
: '',
...
Do you think it would be worthwhile to add these checks? Also, do you have any insight as to why my SliceThickness
was a string? I'd be curious to find out if the problem would be better addressed elsewhere.
Thanks @mccle. I think what you have makes sense. Supplying anonymized DICOM files demonstrating the problem would also be appreciated if possible.
@jbocce, would the data from The Cancer Imaging Archive still work? I do not seem to be able to upload the DICOMs directly, but this is where I obtained them and they only worked for me after my alteration.
For full reproducibility, I should mention the following:
/usr/share/nginx/html/app-config.js
, /etc/nginx/nginx.conf
, and /etc/nginx/conf.d/default.conf
within the resulting container.If there is anything else you think may be relevant, please let me know.
Thanks again @mccle. I tried those same studies with a local DCM4CHEE and was NOT able to reproduce the problem.
Hmm, that is a rather old commit. Consider updating and using the master branch as that is now the most recent v3 code.
In any case, do you mind starting a PR with the changes you suggested? It would be greatly appreciated and help the OHIF community out a lot!
Let me know.
Describe the Bug
When we're trying to open the segmentation view on the DICOM object we're getting the following error in the console:
Adding extensions explicitly in the
app-config.js
didn't help. But they should be enabled by default as I understood.Steps to Reproduce
The current behavior
Showing "Something went wrong" message and throws
SliceThickness.toFixed is not a function
exception.The expected behavior
Showing segmentation as in this demo: https://v3-demo.ohif.org/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.256467663913010332776401703474716742458
OHIF version
v3-stable Commit: 869b8ced0581904ebac1867ca302635a93129f02
OS
macOS 13.4
Node version
16.15.0
Browser
Firefox (113.0.2)