Specific segments in a segmentation node, according to numeric order (e.g., #17), consistently fail to be written to a DICOM RT file, regardless of what image volume is used or how the segments are created.
Operating system: Windows 10 Enterprise
Slicer version: 5.0.3 or 4.11.20200930
Expected behavior: During DICOM export, all segments from a segmentation node are expected to export to the selected DICOM-RT file.
Actual behavior: Most segments export, but the 17th segment in the segmentation node consistently fails to export to the DICOM-RT file. I’ve confirmed this via many attempts, exporting either manually or via the Python interpreter, employing three different MR volumes (including the sample Slicer MR Head volume). I’ve also tested multiple DICOM readers (including re-importing it back into Slicer). This behavior occurs, regardless of how the segments are created – segments can be either drawn or converted from labelmaps – and I have confirmed this on two versions of Slicer (v. 5.0.3 and 4.11). Also, from one attempt with a larger number of segments, it appears that segments #33, and #38 also fail to export (I would surmise that is likely consistent as well). I’ve confirmed that the information regarding the missing structure(s) is not present in the DICOM-RT file’s header. Any ideas for a work-around?
I’ve confirmed the same bug on a different computer, now, as well. It can be verified easily on any dataset, e.g., by loading the sample MR-Head data, creating a new segmentation, adding >17 segments, drawing/painting within them, placing the volume and segmentation nodes within a new subject and new study, and exporting to DICOM. The 17th segment is never written to the DICOMRT structure file, as confirmed by reimporting the study, or viewing the DICOM metadata. Screen captures attached…
Regrettably, I have yet to get a reply from anyone on the SlicerRT team, or anyone affiliated with Slicer at all, other than your reply above. This radio silence is discouraging, as the bug appears simple to duplicate (and therefore presumably debug), and more importantly, we are about to begin a clinical trial in early October on a software we’ve developed that currently has dependencies on 3D Slicer and its SlicerRT extension. If we can’t rely on Slicer to actually consistently write each and every created segment to DICOM-RT files, this is a huge problem on our end, as it would potentially corrupt our trial results. Thus, if no workaround is found in the next several weeks, I’m afraid we’ll need to re-design our own software to exclude Slicer – perhaps instead employing the recently-released open-source SlicerRT alternative, DicomRTTool instead (?) (as described in the recently published paper in Practical Radiation Oncology: Simple Python Module for Conversions Between DICOM Images and Radiation Therapy Structures, Masks, and Prediction Arrays - ScienceDirect). I’ll be returning to the issue in late September, when I need to decide upon a path forward and will hopefully have time to code a workaround if none is found by then. Thanks for your previous reply, though. I’m holding out some hope that someone on the Slicer team may attempt to at least dig a little bit into the issue by then. I suspect it ought to be an easy fix, once its root is discovered.
Thanks for the extra context. As far as I know right now there’s no dedicated funding supporting SlicerRT work but maybe someone in the community can find the time. I agree that on the surface it appears to be a highly localized issue that is hopefully easy to fix. Perhaps someone who wants to learn Slicer programming can take on this issue for practice. Thanks for pointing out DicomRTTool which looks useful in its own right.
Thanks for the quick reply, Steve. The info you’ve provided regarding the current lack of funding for additional SlicerRT work is very helpful to know / be made aware of – any lack of response certainly makes much more sense given that. With that in mind, once I have a bit of time again in a few weeks, I’ll probably take a brief stab at looking for the root of the issue, myself, as well, and will report back if I discover anything. If nothing jumps out quickly, though, I’ll probably need to move ahead with migrating our software to an alternative solution, unfortunately. Either way, I appreciate your having taken the time to comment on this!
Great, thank you Kyle! Apologies for my previous impatience – I’m about to take a few weeks off, myself : ). If I can be of any assistance as you investigate, please feel free to let me know. The link to SlicerRT’s GitHub page is also very helpful!
Apologies for the delay. Just wanted to report that upon initial testing of the new preview release (build 5.1.0-2022-09-16), the problem I reported above does indeed appear to be fixed. Thanks a ton, Kyle, for your efforts to quickly resolve the issue!
Let’s see if anyone from the SlicerRT team can offer suggestions.