Most medical imaging software including opensource ones can not handle DICOM-RT. However, commercial available radiotherapy treatment planning systems only know contours in DICOM-RT format but not surface segmentation. Although contours is an old and poor way of representation of segmentation, it is the only common languange for data exchange in radiotherapy section. The authors implemented the most wanted DICOM-RT exporting function in ITK for radiation oncologists.

Besides rt_image (r/w in IDL), CERR (r/w in Matlab), and Osirix(in MacOS only), the authors' work is the first opensource implementation of DICOM-RT structure sets exporting in C++.

For DICOM-RT structure sets reader, vtkGDCMPolyDataReader class in GDCM v2.0.10 is a good implementation, too.

The authors implement writing of DICOM RTSTRUCT. Reading is not (yet) implemented.

Source code, examples, and data are provided with the paper.

Source code, examples, and data are provided to reproduce the work.

I downloaded, compiled, and ran the given code (revision 5) using ITK 3.10.0 on Windows XP SP2.

This contribution requires deep changes to ITK (changes to GDCM and IO factories), which I assume makes the publication different from a "normal" Insight Journal contribution (which is typically extracted, built, and tested automatically). As such the authors describe how to setup the contribution using a variety of easy to understand Readme.txt files. There are no automatically run tests.

Some improvements could be made to further improve the reproducibility:

1. Rather than embedding the CMakeLists.txt for Mask2Contour and Export2RTSTRUCT in the Readme.txt, they could be added to the directory with the name CMakeLists.txt.removeme (for example). In this regard the Insight Journal system will not detect them (and hence will not try to build), while making it easier for users to build on their own machines.

2. The command line to run the example export2RTSTRUCT is buried away in Data/Readme.txt. This is difficult to find. Perhaps it could also be included in Section 4 "Example" of the article pdf.

3. A note for other reviewers: I had to add absolute paths into the parameter_file.txt to get the example to work. I also changed the second text file name for the contour data from "bones5.txt" (which is not included in the contribution), to "contour2.txt" (which is included).

The authors extend ITK with a new IO Factory.

I was able to get the contribution compiled and working within 30 minutes.

The code conforms to the ITK coding standard. There are sufficient comments. Specifically the comments in the example (export2RTSTRUCT.cxx) clearly described how to use the contribution. There are still some "NOT YET IMPLEMENTED" sections (mainly related to reading RTSTRUCT tags).

There are many existing applications which write and read RTSTRUCT. As such this contribution is useful for supporting such systems. It would be nice to add support for reading RTSTRUCTs.

Unfortunately contours are a poor representation for segmentation -- they are based on the "old" way of viewing 3-D images as a set of 2-D slices. Recently, the Surface Segmentation Storage Module (Supplement 132), which allows the reading/writing of meshes, was approved for inclusion in the DICOM standard:

     ftp://medical.nema.org/medical/dicom/supps/sup132_lb.pdf

It would be nice to see this direction of work (i.e. the addition of DICOM segmentation support to ITK) continue with the addition of Supplement 132.