I think the best would be to support reading of DICOM Segmentation in ITK
Another alternative, which we discussed in the past, is to add dcmqi to be a dependency in Slicer core application (it is rather light, since it will reuse ITK and DCMTK from Slicer), and support Segmentation objects without having to install any extensions.
If we have no resources for 1, and cannot reach consensus for 2, I would update ScalarVolume plugin to not pass Segmentation down the pipeline to ITK readers. This will resolve the crash, but will not help with easily loading the data.
I don’t know how it will behave, but it won’t load the dataset properly, I am pretty sure. Interpretation of DICOM Seg requires extra steps that are outside DCMTK/ITK readers, and is implemented in dcmqi.
I think it’s good that most DICOM importers are in extensions, but the current mechanism of detecting and offering relevant DICOM import extensions should be improved. Slicer should offer to install potentially useful extensions by a single click (instead of telling the user what to do, have a yes/no button and if user clicks yes then install the extensions).
Agreed. Previously the extension manager logic didn’t expose this functionality, but maybe it does now that the auto-update of extensions was added. If not we would need to go back and add some methods to allow the dicom module to install extensions automatically.
Thank you @fedorov ! This works now. It is odd I could not find any reference to this issue doing a search on ‘segmentation storage’. Anyway problem solved, onto next one !
Not sure who is the target of the smiley, so I’ll ask. Does ITK now support bit (0/1) image ? It would seems to be a rather simple fix in itk::GDCMImageIO (unless I am missing the whole point).
Yes, this would be great. Right now it is not “instead of have a yes/no button”. There is not such functionality as far as I know - the only chance user has to learn about the extensions is in a popup notification at the time of import. Is someone planning to work on that feature? If not, or until then, should we add a check for Segmentation image IOD and exit the plugin with warning instead of generating that message in the initial post?
I should be more careful with my smileys next time! I don’t know the answer to your question, but that would not be the critical part. I don’t think it is critical to have output as a bit image. Is more than just supporting bit images, since those segmentations are multiframes, and there will need to be code to sort and paste them into multiple volumes (since segments can overlap), and propagate the metadata, and support a lot more for writing.
I experience again and again that Slicer users cannot figure out that they need to install the QuantitativeReporting extension in order to be able to load DICOM SEG objects. The “hints” mechanism we currently have that suggests installing extensions on data import are far from perfect, and I am afraid most users ignore them. The error message lacks any useful information in the user-facing message, and the console error is equally useless.
In the past we discussed adding dcmqi as a core component (see above), but I am not sure we reached consensus from all participants.
As a less intrusive fix, maybe we could add a specific check in the Scalar volume DICOM plugin to inform the user about the need to install QuantitativeReporting at the time DICOM SEG is attempted to be loaded. Does anyone have concerns about this?
I vote that dcmqi and Quantitative Reporting be integrated into the core. The whole concept of prompting people to install extensions doesn’t seem to work well (it’s hard to make a clear, concise message in a dialog and then people forget it when the dialog goes away). And we really should be encouraging people to use SEG and SR by supporting them natively.
I guess the only downside of integrating it into the core is that we lose the ability to add fixes/enhancements after a stable version is released, but since the extension is relatively mature, it should be OK.
There also a few dependencies to take care of:
SlicerDevelopmentToolbox: It is a collection of useful code snippets, but would need to be cleaned up before it could get part of Slicer core. It would be better to remove this dependency by moving all necessary parts into QuantitativeReporting.
DCMQI: this is a quite nice and stable library, so it should be no problem adding it as a dependency to Slicer core
PETDICOMExtension: this seems to be a quite specialized tool, so it would be probably better not to bundle it with Slicer core
@jcfr can comment on when this should happen, as he is currently reworking the Slicer build system for VTK9.
Don’t want to step in into discussion about extension (IMHO, i believe that best extensions were better to be a part of Slicer, not sure), but the issue was related to MONAI project, they have to use pydicom to read single-bit images, AFAIK.
Indeed, this makes things more complex. I did not appreciate those issues. Potentially, we could separate dcmqi and DICOM plugin for Segmentations from QuantitativeReporting, but that would also not be very straightforward…