Exporting Volume + Segmentation LabelMap as DICOM


I am trying to export a Scalar Volume, which combines the original CT and the binary Label-Maps of the segmentation, as DICOM. Below is a coronal section of the volume and three labels, one of which is a cranioplasty implant. The purpose is to share the volume using a viewer like OHIF and get feedback through annotations.

I created the volume using the Mask Volume seg. editor effect, which only allows me to assign a greyscale intensity value per mask. So;

  1. Is it possible to assign a color as in the Label-Map?

  2. Do DICOM volumes even support color? i.e. would I even be able to export as DICOM…

  3. Is there a more efficient approach at generating these Volumes with Label-Maps

OHIF can display DICOM segmentation object overlaid on the volume. To create a DICOM segmentation object, you can convert the labelmap to segmentation and follow these instructions. I’ve also created a detailed video tutorial that demonstrates a full segmentation object roundtrip between OHIF->Slicer->OHIF:

1 Like


When exporting the segmentation as DICOM, the DICOMSegmentation option does not appear as shown on the video. This is what shows for me.

See the instructions that I linked above, You need to install Quantitative Reporting extension to have Segmentation Object export.


This is working so far. One thing I noticed is that I had to use the DICOM Patcher for some of the original datasets. Otherwise, sending to the KHEOPS server kept throwing Error 409

1 Like


Following-up on this.
How to you export a modified base or reference volume?
I tend to clone and modify the cloned volume node to preserve the original. For instance, applying a filter and maybe even a transformation.
When I export to DICOM, the segmentation is the only node that actually gets exported.
If I use the scalar volume exporter, the process generates an additional study.

The behavior might have been different in earlier Slicer versions, but in the current version (recent Slicer Preview Releases) if you export an image by right-clicking on it in the Data module then:

  • if you leave StudyInstanceUID empty then it will be set based on where you have the image in the Subject Hierarchy tree (first tab in Data module)
  • if you set the StudyInstanceUID, FrameOfReferenceInstaceUID to match another study (and preferably copy all the other patient and study field values, too) and generate a new SeriesInstanceUID value then the image will appear under that other patient/study

If you use this via the GUI then the first option is definitely easier. If you process the images automatically then the second may be a bit simpler and more explicit. Although if you do batch processing then it may be simpler to use DICOM Patcher module, which does not disassemble the image and puts it back together, but just changes individual DICOM tags. You can even add custom rules by a couple of lines of Python script to address specific non-conformities that you encounter and not fixed by default.


I am running 4.13.0-2022-01-16, do I need to grab the latest latest?

This is what happens when I go through the GUI;

  • On my data module, I clone the volume and name it differently. Then I create a segmentation with a single segment (not shown)


  • Right-click and pull the “exporter”. I leave everything blank and export the volume using the scalar volume exporter.

  • A different study is generated after a successful export.


Thank you, you are right, I could reproduce the behavior. It seems that you need to set the 3 IDs manually for now. You can get the ID values by right-clicking on the original series in the DICOM database and choose “View DICOM metadata” and then “Copy metadata”. I’ll see if we can automate this process to make it easier to export data to the same study as the original.

I thought of looking into the volume attributes to confirm that these IDs had copied through, and they did…

Here are the IDs on the cloned volume,

>>> instUids = vol2.GetAttribute("DICOM.instanceUIDs").split()
>>> filename = slicer.dicomDatabase.fileForInstance(instUids[0])
>>> print(slicer.dicomDatabase.fileValue(filename, "0020,0052"))
>>> print(slicer.dicomDatabase.fileValue(filename, "0020,000d"))
>>> print(slicer.dicomDatabase.fileValue(filename, "0020,000e"))

Here are the IDs for the original volume;

>>> instUids = vol1.GetAttribute("DICOM.instanceUIDs").split()
>>> filename = slicer.dicomDatabase.fileForInstance(instUids[0])
>>> print(slicer.dicomDatabase.fileValue(filename, "0020,0052"))
>>> print(slicer.dicomDatabase.fileValue(filename, "0020,000d"))
>>> print(slicer.dicomDatabase.fileValue(filename, "0020,000e"))

Then I started copying them manually into the GUI and realized that the SeriesInstanceUID needs to be different in order for this to work!

In other words, I think copying the volume node does preserve the SeriesInstanceUID instead of changing it. Is there a way to programmatically change this DICOM attribute?

I’ve made the DICOM export more convenient. In Slicer Preview Release that you download tomorrow or later images that show up under the same study in the subject hierarchy tree will be exported by default into the same study (the study instance UID is now populated automatically).

You can copy the frame of reference UID from the original image to the modified image if you want fused image display in external software.

A DICOM series is not allowed to be changed, ever, without generating new Series instance UID. If a file must be corrected then you send a “delete” request to the PACS (this hides the old instance); then push a new version of the image (that references the old hidden version). The same UID keeps referring to the same content.

Therefore, since the same series instance UID cannot be reused in another image, I would recommend to leave the series instance UID empty, which will generate a new UID automatically.

I’ve added some more information to the DICOM export section in the documentation.

Again, this new behavior is implemented in the Slicer Preview Release that you download tomorrow or later.