I have a serious problem while loading rtstructs. They are displayed correctly while loading as planar contours. So far so good:
But when I want to use the binary labelmap they are completely destroyed.
The segmentation has already defined a Master volume:
I don’t know what I am doing wrong here! I just couldn’t use the RTstructs. Help!!
Maybe there is something wrong with the master volume. Try to seg labelmap geometry using an “Annotation ROI” as explained here. If you still have issues the best would be if you could share the RTSTRUCT so that we can investigate.
How do I share the files with you?
Upload to dropbox/onedrive/google drive and post the link.
Here are the files, let me know if you can get them
https://1drv.ms/f/s!AkKpgfpFgNdvk3bkDvNqyB7ofguq
One folder is the CT, and the other are the RTSTRUCT
I loaded it to the latest version, and although it looks like the closed surface is alright, the triangulation is actually faulty:
Moreover it seems like a systematic issue, as if the contours are not saved the way we have seen from the planning systems we encountered (which is most of them, as SlicerRT is used since 2012 and this is the first time I’m seeing something like this - similarly to the fact that each structure is in its own structure set object, which is also unusual).
The contours themselves seem to be alright to me, see
Maybe it’s as easy as an inverse direction of defining the contours as usual. Maybe @Sunderlandkyl can take a look into it (once he’s back from vacation).
@Alex_Vergara would be interesting if using plastimatch convert to discretize those contours has the same problem. Can you try that?
I’ve checked the data set and the problem is that each contour is listed 5 times (see [3006,0050] ContourData fields in the metadata browser). Although each duplicate contour refers to a different image series (via ContourImageSequence), I’m not sure if it is valid to dump all these duplicate contours in one sequence, as there is no way a third-party software could know how it is supposed to interpret these duplicate contours.
Maybe @Sunderlandkyl can implement a workaround in Slicer that will deal with this very unusual and potentially invalid data representation. In the meantime, you might check with your software provider if they have a new version of their software where this issue is fixed; or maybe you can make some configuration or workflow changes that would prevent exporting of the same contour several times within the same ContourSequence.
@lassoan @cpinter
The software provider is Dosisoft, the planning system that exported the RTStructs is planetDose. This is a standard exportation of an already defined segmentation used for dosimetry. The repetitions is because we require one segmentation per time point (5). So you can just take the first one on each structure which is the most relevant. I don’t know a simple workaround to handle this case. But anyways, Slicer shall be able to detect the repeated structures and ask to import them all or just one, in each RTSTRUCT file. In any case, I will ask Dosisoft if there is a way to export only one segment per structure.
As you can see there is no output even when plastimatch says it is OK
E15AVG:RTStruct_20181114151700455_Liveralltimes alex$ plastimatch convert --input RS.1er_Tx.1.3.6.1.4.1.33868.20181114151634.7910670.dcm --output-img RS.1er_Tx.nrrd --output-type float
Found RTSTUCT, UID=1.3.6.1.4.1.33868.20181114151700.69827
Found DCM_ReferencedFrameOfReferenceSequence!
Found DCM_RTReferencedStudySequence!
Trying to load rt structure set.
Adding structure (3), Liver - R
Structure 3 has color 0\205\209
PIH is:
Origin = -137.1192 -71.1401 -35.0000
Size = 512 512 30
Spacing = 0.3733 0.3733 5.0000
Direction = 1.0000 0.0000 0.0000 0.0000 1.0000 0.0000 0.0000 0.0000 1.0000
Rt_study_warp: Convert ss_img to cxt.
Rt_study_warp: Apply dicom_dir.
Rt_study_warp: Set geometry from PIH.
Rt_study_warp: Set rasterization geometry.
rast_dim = 512 512 30
rast_offset = -137.119 -71.1401 -35
rast_spacing = 0.373258 0.373258 5
Rt_study_warp: warp and save ss.
Warp_and_save_ss: save_ss_img
Finished!
E15AVG:RTStruct_20181114151700455_Liveralltimes alex$ ls
RS.1er_Tx.1.3.6.1.4.1.33868.20181114151634.7910670.dcm
RS.1er_Tx.1.3.6.1.4.1.33868.20181114151634.7910670.dcm.ig.img.hdr
I’m not sure if it is valid to dump all these duplicate contours in one sequence
Valid, but semantically unclear. Separate ROI for each timepoint would be a better choice.
So you can just take the first one on each structure which is the most relevant.
Unfortunately it’s not that simple. At a given Z coordinate, you may have a single contour, or multiple contours. If it is a single contour, how does one know it belongs to the first, or the second, or the nth version of the structure? If the Referenced SOP Instance UID were used correctly, one could potentially analyze the referenced images and figure this out. But the in the RTSTRUCT you have shared, the multiple contours at a given Z coordinate reference the same CT slice.
plastimatch convert --input RS.1er_Tx.1.3.6.1.4.1.33868.20181114151634.7910670.dcm --output-img RS.1er_Tx.nrrd --output-type float
Plastimatch will interpret this as the union of all contours by default. If that is acceptable, I suggest the below syntax.
plastimatch convert --input rtstruct-file.dcm --referenced-ct DICOM/ --output-prefix structures
That worked, well sort off! It created a labelmap:
Edit: Deleting the previous segmentation and creating a new empty one solved the problem!
That plastimatch line is indeed the solution, would be nice to have it in Slicer by default!
This is the solution
I agree, I checked the DICOM standard and it is not explicitly forbidden to insert redundant/contradicting contours. Nevertheless, I’m quite sure that this dumping of contours from various sequences into a single structure can only be interpreted by dosisoft’s own software. There is no way other software could know that if the contour refers to different images then they should be interpreted as separate contours.
In case of this specific data set, all the repeated contours are exactly the same, so by Plastimatch computing of the union it produces correct results. But of course this will break as soon as the contours are not the same in all repetitions.
To not pollute our DICOM importers with various vendor-specific workarounds, we usually address this kind of DICOM content issues by adding new rules to Slicer’s DICOM patcher module. So, if dosisoft is not willing to change their ways then we can add a new DICOM patcher rule (split segments if an RTSTRUCT produced by dosisoft refer multiple image series in the same structure).
@Alex_Vergara Please report this issue to dosisoft. They are probably aware that they have cut some corners but they should also know that it is hurting their users.
Hello, I have the same issue with my data. Is it possible to make a video and share it? I really couldn’t solve the problem. I have the complete RTstruct data (with several annotations for Lung, Heart, etc.). I can visualize it in the DICOM database of the slicer, but that’s all. I cannot open it and use it for segmentation. Any idea? or Recommendation?
Thanks in Advance!
Is your structure set generated by dosisoft software?
Hi Lassoan, Thanks for the quick reply. It says that " Electa`s XiO® proton therapy treatment". The software is XiO when we check RTSTRUCT data via MatLab. I can visualize the RTSTRUCT file via MITK software, but not the 3D slicer.
Best,
Can you upload an anonymized data set somewhere and post the link here?
