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…”:
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.
@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 ?
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.
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.
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.
