Segmentation Storage: 1.2.840.10008.


(Mathieu Malaterre) #1

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:


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

Thanks much

(Andrey Fedorov) #2

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.

(Andrey Fedorov) #3

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!).

(Jean Christophe Fillion Robin) #4

@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 ?

(Andrey Fedorov) #5

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.

(Andras Lasso) #6

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

(Steve Pieper) #7

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.

(Mathieu Malaterre) #8

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 !

(Mathieu Malaterre) #9

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

(Andrey Fedorov) #10

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.

(Steve Pieper) #11

This looked like the best option to me.

(Andrey Fedorov) #12

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?

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

(Steve Pieper) #13

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.

(Andrey Fedorov) #14

Pending responses from @jcfr and @lassoan, the PR for the simple fix has been submitted:

(Andras Lasso) #15

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