Hi, I‘m facing another problem when I perform these operations. After export labelmap, the labelmap I got is missing some information. this picture is before export
this one is after export
could u tell me why? Thanks a lot.
It looks like that the RT structure set is invalid (multiple contours are specified for the same slice). What software did you use to create this? Can you send a download link to the anonymized data set so that we can have a look?
Thank you, you are right, a slice does have multiple contours. I have found a python package called “dcmrtstruct2nii”, it can convert DICOM-RTSTRUCT format to Nifti format.
What software created this contour?
dcmrtstruct2nii uses an incorrect algorithm for contour conversion, based on a misinterpretation of the DICOM standard. If the software that created the RT structure set similarly misinterpreted the DICOM standard then the result may be good (the two errors cancel out each other). However, in general, you should not use neither the software that created these invalid contour, nor dcmstruct2nii.
1 Like
sorry, I don’t know what software created this contour. After I converted rtstru with dcmrtstruct2nii and opened it with ITK-SNAP software, it seemed to be correct. As shown in this picture
. Is it the case you mention? (the two errors cancel out each other) .
Another strange thing happened, some rtstruct can use 3d slicer to export to labelmap without holes, but its image dimension become smaller. As show in the picture
It’s original size should be 512512227
These questions really bother me. Hope can get your help. thanks!
We enabled this feature (automatic cropping of the voxel array to minimize file size) by default in earlier Slicer versions. However, this caused complications when people wanted to press these images in software that ignored physical space information. So, we changed the behavior and in current Slicer Stable Release and Slicer Preview Release we don’t crop the exported labelmaps to the minimum necessary size by default anymore.
Where did you get the data sets from? I would contact them and tell them to either fix their data sets or offer them in other formats.
I use Slicer 4.11.20210226 and Slicer 4.13.0-2021-09-07 versions, they both automatically crop the labelmap without holes to minimize the file size.
The data came from a hospital. The doctor said they used commercial software, but I had no way to get these commercial software. Can I use the data transferred from dcmrtstruct2nii? Will using them cause any other problems?
These Slicer versions use the segmentation geometry as output, which is determined from the first selected master volume. If you want to use a specific volume’s geometry in the segmentation then you can choose that volume as reference volume.
Let us know if you get to know what software they are using exactly and how. Maybe they do some conversion or anonymization step that messes up the original data or the segmentation tool is not used properly or not DICOM compliant.
Interesting. IMHO, ROI for something concave that looks like e.g. tooth with two roots will have several slices with one contour, several with two. Do you think it is invalid? BTW, there is new type CLOSEDPLANAR_XOR, it works only with multiple contours of one ROI per slice, per definition. Or do you mean “duplicated contours are specified for the same slice”, i have seen such data sets, it were bad, of course.
What the O.P. is seeing looks like a display bug. I have seen similar.
You are correct, it’s totally fine to have multiple closed contours on a single slice. Or even not on a slice. And thank you for the reference about CLOSEDPLANAR_XOR, this is new to me. 3D Slicer (plastimatch) uses XOR rather than keyholing for export, but with the CLOSED_PLANAR. I wonder which systems would recognize and use CLOSEDPLANAR_XOR.
1 Like
I meant that overlapping planar contours are invalid - or at least they were, until CLOSEDPLANAR_XOR has been introduced. I have never seen CLOSEDPLANAR_XOR before and I would be really sad if vendors chose to put another twist on an already horrible segmentation representation instead of adopting DICOM Segmentation Object.
The correction proposal that introduced CLOSEDPLANAR_XOR - submitted by Varian and BrainLab engineers - indicates that the goal is to manage the misuse of the DICOM standard by “current implementation base of RT Structure Set” (it is unclear what software they refer to), by making it easier for treatment planning systems to reject XOR-style overlapping contours:
For safety reasons, it should be possible to express this different technique, while assuring that systems that do not support this can still operate safely and not consume contours using this different technique.
Probably we’ll need to wait for several more years to see if treatment planning system developers will start generating or accepting CLOSEDPLANAR_XOR themselves or they go and adopt second-generation DICOM RT objects (2G RT) instead. 2G RT promotes using common DICOM segmentation representations for “conceptual volume” definition in contrast to just locking into RT structure sets:
(source)
Thank you all, I will try to discuss with the hospital to see what’s going on.
Probably Varian may use CLOSEDPLANAR_XOR in a near future or uses already (Varian and BrainLab submitted the correction proposal). It looks like a kind of legalization of the technique they used already, e.g. screenshot with Varian’s ROI (CLOSED_PLANAR), blue (“Bones”)
I have created test data set, seems that SlicerRT has no problem with the new contour type, at least at a first look.
3 Likes
Thanks! The result looks good.
1 Like
The link to the test dataset illustrated doesn’t seem to work - can you repost the test data or link to a persistent location for it please?
XOR test data set
Thanks.
This reminds me that I need to add CP 2037 CLOSEDPLANAR_XOR Contour Geometric Type to dicom3tools dciodvfy.
1 Like