Closed lassoan closed 5 years ago
Also, we should think about adding diffusion support. Either here or to use dcm2niix instead of DWIConvert in SlicerDMRI.
There are heuristics in DICOMDiffusionVolumePlugin to guess if a series is a DWI or not, but I believe dcm2niix would be able to give a much better estimate of what kind of acquisition it is.
@ljod can you also comment on this? Perhaps we could make SlicerDMRI depend on SlicerDcm2nii the way it does on UKF currently. We could either use dcm2niix instead of dwiconvert here or we could leave in support for both (not sure if there are any odd corner cases that would require letting the user choose, but if so we could offer dwi convert with lower confidence).
Thanks Andras and Steve! We have a substitute module instead of DWIConvert, which is in this extension and hopefully people are using it. Yes it would be great if the dcm2nii plug-in also worked for diffusion.
Also regarding corner cases. In our testing of a large number of PACS datasets from the last ten years or so, DWIConvert converts a higher percentage than dcm2nii. But many of these are silent failures that don't convert properly. So I would trust the results from dcm2nii much more.
So I would trust the results from dcm2nii much more.
Agreed! But should we leave in an option to use DWIConvert (or maybe we should deprecate it and remove it from Slicer5)
I think for now we need to leave in the option as users transition to the new loading method. I agree with deprecation and removal in Slicer 5.
Confidence of dcm2niix plugin is set to 0.45 (or 0.3, if there are warnings), which means that still the usual scalar volume plugin will be used to load the volume by default. However, when loading fails, the user can enable advanced option and choose the loadable generated by dcm2niix.
Also enabled OpenJPEG and JPEG-LS for building dcm2niix to enable loading of compressed images.
Example: loadables for a valid volume
Example: loadables for an invalid volume (I've deleted a few slices)