RTSTRUCT segmentation discrepancy

Operating system: Windows 7
Slicer version:4.11.0-2020-02-19
Expected behavior:
Actual behavior:

After exporting a segmentation to an RTStruct I noticed that there are discrepancies with respect to the original segmentation in many slices of the volume. See for example the differences of 1 slice in the following screenshots.

The image used is the head CT from Slicer’s sample data.
Is this a normal behaviour?

Thank you

MIght be a keyholizing issue. Is the screenshot from 3D Slicer? Can you clarify what workflow steps you used?

RTSTRUCT is saved in form of closed contours on each axial slice. If you have such a fragmented segmentation, you will probably encounter similar issues. I suggest cleaning your segmentation before saving to structure set.

A lot of the issues I’m referring to are related to polydata visualization. So it is possible that the underlying data itself is perfectly fine. Go to the Segmentations module, and in the advanced display section switch 2D visualization to binary labelmap. You will probably see healthier slice intersections.

I would recommend to stay away from RT structure sets. This format was developed more than 20 years ago, specifically for radiation therapy. It is not suitable as a general-purpose segmentation storage format. The main issue is that in RT structure sets, segmentation is stored as a set of parallel planar contours, and so complex geometries (such as the one you show in your screenshots) practically cannot be represented without risk of data loss or corruption.

If you must use RT structure set (e.g., you export data to be imported by a TPS) then keep in mind these limitations. For all other purposes, follow what modern medical imaging software do: store segmentation in DICOM segmentation object. Slicer can read/write these DICOM files if you install QuantitativeReporting extension.

When I toggle in Segmentations>Display>Advanced>Representation in 2D views from binary label map to closed surface the segmentation in some slices becomes better (even though not exactly the same as the original segmentation), while in some others kind of worse.

That explains why I see these differences. I will use the DICOM segmentation IOD from now on.

I have some trouble though exporting to the Segmentation IOD using Slicer, since I get some errors .After installing the QuantitativeReporting ,the current version of Slicer I am using complains that the DCMQI is not compatible and the QuantitativeReporting might not work properly. When tried to export the segmentation as seen in the following screenshot I got the following errors:


I also tried to export the study as a DICOM segmentation object using an older Slicer version (4.11.0-2019-04-06)where the DCMQI was compatible but I got another error there during the export.

I will try to use the binary dcmqi and see if the export will be succesful.

Thanks again to all of you for your assistance and valuable suggestions

Please also try the latest Slicer Preview Release and let us know if you experience any issues. Thank you!

I have used the latest preview release (4.11.0-2020-03-10 r28818) but I still get the same error as above.

@fedorov are you aware of this issue?

1 Like

I will investigate later today, thank you for mentioning.

1 Like

@athanell how did you load the image you are segmenting?

It looks like it was not loaded from DICOM. If that is the case, with the current capabilities, it is not possible to export DICOM segmentation. The plugin should not crash, but other than the crash, it expects the reference image has the accompanying DICOM series.

If your input images are not DICOM: You can load the images from non-DICOM format into Slicer and export to DICOM format. You can then import/load them to Slicer, specify segmentation, and export the segmentation to DICOM.

@fedorov Probably we should simplify this process (we can export the referenced volume to DICOM, too, and generate all the necessary UIDs).

I created an issue here https://github.com/QIICR/QuantitativeReporting/issues/247.

Does it make sense to automatically export the referenced volume? I think that process should be interactive. Maybe it is better to give error to the user and ask to export the referenced volume as DICOM first?

It would be nice to offer exporting the referenced volume, so that users can just click OK (export with volume) or Cancel (abort exporting so that the user can export the volume manually).

I apologize for the very late response Andrey. You are correct I didn’t load the volume in a DICOM format. After converting the volume to a DICOM I could export the segmentation correctly.
Thank you for your assistance.

1 Like

I apologize for the very late response Andras. Indeed as you mentioned after converting the volume to a DICOM I could export the segmentation correctly.
Thank you again for your assistance.

1 Like