I am browsing through the paper: DICOM for quantitative imaging biomarker development: a standards based approach to sharing clinical data and structured PET/CT analysis results in head and neck cancer research (@fedorov and al.) and near the end I could find the following section:
Each of these platforms was capable of successfully importing the SEG objects and displaying the encoded segments. An example of the rendering of the segmentations in 3D Slicer is shown in Fig. 8.
After downloading one participant from the TCIA reference, and trying to load the Segmentation Storage instance in 3D Slicer all I could trigger is the following error message:
What do I need to be able to load DICOM/SEG instances (singlebit) ?
Mathieu, you need to install QuantitativeReporting extension from Slicer ExtensionManager first. This issue comes up again and again. I did not realize in the PeerJ paper we do not mention the extension. I will add a note to the paper to clarify this. Please let me know if you have troubles loading the data after you install the extension.
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.
