How to export TotalSegmentator results as DICOM SEG?

I would like to export results of TotalSegmentator into DICOM Segmentation format. I am using latest Slicer stable 5.2.1 on Mac.

I loaded input CT series from DICOM Browser. I have QuantitativeReporting extension installed. However, segmentation results are not automatically placed properly in the patient hierarchy on segmentation completion, see below:

I then manually drop segmentation under the patient node, but I am still getting the same error when I select the segmentation node and try to “Export to DICOM…”:

2023-01-13_09-54-22

If I click “OK” in the shown popup, a dummy patient item is created in the hierarchy, which is definitely not what I want to do.

cc: @Justin_Kirby

@lassoan have you ever tried this? The terminology should be good so maybe it’s just a matter of setting up the subject hierarchy to connect the segmentation results to the study. Maybe you have suggestions @cpinter ?

Yes, it all works!

Probably the reference volume was not set in the segmentation. I’ve tried to explain this in the message in the DICOM export dialog (see red text):

The solution is to specify segmentation geometry using the DICOM image as source:

I’ve now updated TotalSegmentator to do this step automatically.

DICOM export takes 40 seconds and loading takes 50 seconds. This is tolerable but for comparison, when we save/load as nrrd then both take about 1 second.

2 Likes

2 posts were split to a new topic: Improve TotalSegmentator pre-segmentation speed

Andras, before the fix, it was not possible to get to that export dialog unless a dummy patient was created. The initial popup I showed in the initial message had only the option to cancel, or to create a dummy patient.

Thank you, it is working now!

I am working on one improvement to dcmqi that I know will help reduce this time. For the record, there was not even an attempt to optimize DICOM SEG import/export, since for smaller number of segments this is not a practical issue. I don’t know how much I can improve this, but I will look into it.

2 Likes

Reading/writing hundreds of files have significant overhead, so probably dcmqi should have support for storing multiple segments in one 3D volume, and allow multiple 3D volumes for storing overlapping segments (so the segmentation file is 3D if all segments are non-overlapping; 4D if there are overlaps). We have implemented functions in Slicer for splitting/merging overlapping/non-overlapping segments that you might find useful for this.

We have found that even with using a single 3D file for storing all the segments, splitting them to separate volumes and process one by one is much slower. For example, when in Slicer we stored each segment as a separate volume, it took about 30 seconds to load the Brain Atlas. When we switched to storing all segments in the usual single 3D shared labelmap representation then loading time went down to a fraction of a second. I know that supporting this would require improving the DICOM standard, but I think it would worth it, not only because of the speed improvement but also because of simplicity and reduced memory need.

1 Like

@lassoan can you help with pointers to those relevant functions in Slicer?

I started working on adding that functionality in Add support for saving segments in a single file by fedorov · Pull Request #464 · QIICR/dcmqi · GitHub

1 Like

This file is a good starting point: Slicer/vtkSegmentationModifier.cxx at main · Slicer/Slicer · GitHub