# Loading DICOM segmentation

**URL:** https://discourse.slicer.org/t/loading-dicom-segmentation/14139
**Category:** Support
**Created:** [October 19, 2020, 3:06pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139 "2020-10-19T15:06:54Z")
**Posts on this page:** 13
**Page:** 1

<div class="post-metadata">

### Author: ![yoomi](https://avatars.discourse-cdn.com/v4/letter/y/a6a055/32.png) [@yoomi](https://discourse.slicer.org/u/yoomi)
#### Post date: [October 19, 2020, 3:06pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/1 "2020-10-19T15:06:54Z")

</div>

Hi, I’m having some trouble loading certain DICOM segmentation’s into the Slicer scene. Importing the file is no problem (imported using DICOM database), but the error log says “could not load: [filename] as a DICOMSegmentation”. Does anyone know why this might be? Thanks

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [October 19, 2020, 3:17pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/2 "2020-10-19T15:17:20Z")

</div>

If you only have this problem with certain segmentation files then we need one of those files so that we can investigate. You can upload the files anywhere and post the link here (make sure no patient health information is in the files).

---

<div class="post-metadata">

### Author: ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [October 20, 2020, 2:03am UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/3 "2020-10-20T02:03:28Z")

</div>

If you cannot share the files, it may also be helpful to share the full error log (Help \> Report a bug).

Are you able to load some DICOM segmentations, but not others, or you cannot load any?

---

<div class="post-metadata">

### Author: ![yoomi](https://avatars.discourse-cdn.com/v4/letter/y/a6a055/32.png) [@yoomi](https://discourse.slicer.org/u/yoomi)
#### Post date: [October 23, 2020, 2:09pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/4 "2020-10-23T14:09:04Z")

</div>

Hello, here is an example of a segmentation file that I am unable to upload. The full error message is just “could not load as a DICOMSegmentation”. Thanks everyone for your help.

> **[segmentation.dcm](https://drive.google.com/file/d/1XfVcJ3DVLo6areLoOWZ72b3e-QPpZ-79/view?usp=sharing)**
>
> Google Drive file.

---

<div class="post-metadata">

### Author: ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [October 23, 2020, 2:32pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/5 "2020-10-23T14:32:43Z")

</div>

Thank you, I can reproduce the problem.

I believe the segmentation series here is the one with SeriesDescription “VOI PE Segmentation thresh=70” from this study available on IDC: [https://viewer.imaging.datacommons.cancer.gov/viewer/1.3.6.1.4.1.14519.5.2.1.7695.1700.186130315530827043916665138479](https://viewer.imaging.datacommons.cancer.gov/viewer/1.3.6.1.4.1.14519.5.2.1.7695.1700.186130315530827043916665138479).

There are several issues:

- the MR series corresponding to this segmentation is a 4D series
- the segmentation is encoded as FRACTIONAL

It looks like this combination is not handled well at the moment by either Slicer or IDC/OHIF Viewer.

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [October 23, 2020, 4:45pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/6 "2020-10-23T16:45:16Z")

</div>

Loading 4D MRI series should work well in Slicer already. Slicer can also represent FRACTIONAL segmentations, although right now fractional segmentations are still just loaded as binary. So, all segmentations should be possible to load.

The problem with this file is that it contains an empty segmentation. It has a single slice, with all zero values. Probably it is just a placeholder.

While checking this, I’ve found a bug in the segmentation importer for loading single-frame segmentations, and I’ve submitted a [fix](https://github.com/QIICR/dcmqi/pull/407).

---

<div class="post-metadata">

### Author: ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [October 23, 2020, 5:27pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/7 "2020-10-23T17:27:44Z")

</div>

Andras, thank you for the fix. I merged it. I don’t think it will solve the underlying issue for the user though. We need to add a check to the SEG DICOM plugin to account for the situation when the segment is empty. I admit I didn’t even think of a possibility of someone saving a segment that is blank. Thank you for investigating this so quickly!

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [October 23, 2020, 5:34pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/8 "2020-10-23T17:34:54Z")

</div>

In this case, there was nothing in the segmentation, so the user got all that was available (nothing).

But yes, the importer has to be prepared for blank segments. For example, if a segmentation has blank and non-blank segments, probably import stops due to the failed import of the first blank segment and the rest of the segments are not imported. At least we should file submit a bug report to QuantitativeReporting to remember to fix this at some point.

---

<div class="post-metadata">

### Author: ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [October 23, 2020, 5:40pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/9 "2020-10-23T17:40:52Z")

</div>

I’ve just added a quick fix here: [BUG: add a check for the number of segments · QIICR/QuantitativeReporting@1ca31ce · GitHub](https://github.com/QIICR/QuantitativeReporting/commit/1ca31ce1681f9e04dc3129fdca42abe815c31e06)

I confirmed with this fix there is no error, segmentation node is created, but has no segments, and there is a warning in the error log. I think now the behavior of the application makes sense.

![image](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/1/4/1401434b527cc23b5f72eafb307983a64095c31b.png)

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [October 23, 2020, 5:52pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/10 "2020-10-23T17:52:20Z")

</div>

It could be nice to create the segment anyway and set its name, color, terminology, etc. instead of skipping it completely (if it is easy to implement).

---

<div class="post-metadata">

### Author: ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [October 23, 2020, 5:57pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/11 "2020-10-23T17:57:39Z")

</div>

Yes, I agree it would be nice, and it’s an interesting “hack” to work around the lack of an equivalent of a “pick list” in DICOM SEG/SR.

I believe at the moment the behavior of empty segment import is such that no empty segment is created. The corresponding line is highlighted below. I think this would need to be implemented in the segmentations logic. I do not know how difficult it would be to implement.

> <https://github.com/QIICR/QuantitativeReporting/blob/1ca31ce1681f9e04dc3129fdca42abe815c31e06/DICOMPlugins/DICOMSegmentationPlugin.py#L225>

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [October 23, 2020, 6:46pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/12 "2020-10-23T18:46:29Z")

</div>

It would be hard to tell what and how many empty segments `segmentationsLogic.ImportLabelmapToSegmentationNode` should create. We could add an option that would create an empty segment for each entry defined in the color node associated with the input labelmap. But this would be quite a special case, so I’m not sure if it would worth the time to implement.

Instead DICOMSegmentationPlugin could be updated so that if `_importSegmentAndRemoveLabel` returns an empty segmentation then it adds a new segment (using [`segmentationNode.GetSegmentation().AddSegment(...)`](http://apidocs.slicer.org/master/classvtkSegmentation.html#aabe215076719c40187dc6d3902afbc9c)).

---

<div class="post-metadata">

### Author: ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)
#### Post date: [October 23, 2020, 7:25pm UTC](https://discourse.slicer.org/t/loading-dicom-segmentation/14139/13 "2020-10-23T19:25:43Z")

</div>

> [@lassoan](#):
>
> It would be hard to tell what and how many empty segments `segmentationsLogic.ImportLabelmapToSegmentationNode` should create.

This actually would be very easy, since when dcmqi converts DICOM SEG, each segment is saved into a separate file. So when that import function is called on a label map, the label map has one and only segment.

In any case, I created a ticket to keep track of this idea, if/when we get to it: [Create empty Slicer segmentation segments when empty segments are imported from DICOM SEG · Issue #253 · QIICR/QuantitativeReporting · GitHub](https://github.com/QIICR/QuantitativeReporting/issues/253).
