Segmentation Storage: 1.2.840.10008.5.1.4.1.1.66.4

Hi there,

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:

image

What do I need to be able to load DICOM/SEG instances (singlebit) ?

Thanks much

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.

Ah, we did mention the Reporting extension:

The following software was tested:

  • 3D Slicer ( Reporting extension, starting from Nov 22, 2015 nightly build version)

Reporting was superseded by QuantitativeReporting, in an attempt to reduce confusion (but in this case achieving the opposite result!).

@fedorov, is there anything that we could do to avoid the crash and report a more informative message ?

In that particular case, would it change anything to go in Edit -> Settings -> DICOM and set the DICOM Reader Approach to DCMTK ?

In the order of my preference:

  1. I think the best would be to support reading of DICOM Segmentation in ITK :wink:

  2. 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.

  3. 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.

This looked like the best option to me.

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.

image

image

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?

@pieper @jcfr @lassoan can each of you please voice your opinion?

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.

1 Like

Pending responses from @jcfr and @lassoan, the PR for the simple fix has been submitted: https://github.com/Slicer/Slicer/pull/1088

I agree that the extension could be bundled with Slicer by default (similarly to how it is done for MultiVolumeExplorer).

1 Like

FYI

Related issue:

and PR:

@lassoan it sounds like we are all in agreement, and also this issue of having to install the extension very often brings confusion to the users.

Should I try to make a PR with this change? I have not touched Slicer in quite a while, so hopefully I can pull it off …

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.

@issakomi at least based on this current thread, the original issue reported by the user is quoted below: