DICOM segmentation storage


I am investigating possibility and of saving segmentations in correct format. So far I have encountered 3 options:

I dont have experience with them in ITK. I would like to know which is the correct way to implement this and whether the itk implementation is available and stable.

For good DICOM compliance, you might want to look at dcmqi. Better DICOM write support is one of the currently needed features in ITK.

1 Like

To complete @dzenanz, you can have a look at this example, ResampleDICOM, to have and idea of the current DICOM manipulation in ITK.
Also, ITK relies on third party libraries (GDCM by default, or DCMTK) to manipulate DICOM so you can check their documentation.


The itkimage2segimage command line executable from dcmqi offers a quick way to get started.

CC: @jcfr


Both DICOM Segmentation IOD and Surface Segmentation IOD are valid options. As most segmentations are created from images, Segmentation IOD is often the preferred choice and probably more commonly used.

RT structure set is a really old format with several fundamental issues. If you don’t need compatibility with legacy systems then it is better to avoid it.

1 Like

@Hrabalski I don’t think there is a general answer to the question what object type to choose. It depends on what kind of segmentations you are working with, what is important for your use case, why you started to think about DICOM for storing segmentations in the first place. If you give a bit more context, it might be easier to help you.

Support in tools might be another factor to consider, but, again, I don’t know how important this is for you.

DICOM Segmentation image object is supported by several tools (both commercial and open source), you can see a summary here: https://qiicr.gitbooks.io/dicom4qi/, and you can use dcmqi for conversion.

DICOM RT Structure set is widely supported in the radiotherapy workstations, and there open source tools for conversion - Plastimatch http://plastimatch.org/ and SlicerRT (you have to google the link, since as a new user I can only insert two links in a post…).

I am not aware of tools supporting DICOM Surface object.

1 Like

Thank you for all the answers.

I am pushed to use DCMTK library by now, but in case there was any high level solution implemented in ITK, I would prefer using it.

The idea for the moment is to store segmentations from multiple stages of treatment. Prefered way to store them is single DICOM image.

So far I am using CT image SOP class with secondary image tag, but this doesnt seem to be the best way.

DICOM Segmentation object is represented by a family of classes in DCMTK that you can use to implement your own conversion in the DCMTK dcmseg library.

dcmqi is a separate library that builds on top of dcmseg to implement a higher level solution.

If your multiple stages of treatment are spread over time, you cannot put all of them into a single DICOM Segmentation object. In DICOM, you will have segmentation(s) stored in a series that can belong to a single DICOM study. You can store multiple segmentation labels, which can overlap, within a single DICOM segmentation object. You cannot store segmentation labels that correspond to different imaging studies in a single object.

Yes, this is a commonly used practical approach, and will maximize the chances of your series being rendered by the PACS viewers and off the shelf components. However, it provides no place to encode the semantics of the object, and it has multiple other limitations

  • you will have one file per slice instead of one file for the whole object
  • you don’t have a place to encode the source series instances
  • you cannot specify any metadata about your segmentation approach
  • you cannot specify anatomic location or semantics of the segmented region

So, again, you have to decide what is important in your situation.