Proposals:Writing DICOM from non-DICOM

From KitwarePublic
Jump to navigationJump to search

The Problem

How to take a 3D image (not from DICOM) and write it as a series of DICOM files.

The current options

Multi-Frame DICOM

If the image is passed to an ImageFileWriter and a GDCMImageIO is connected to it, then the image will be writen as a single DICOM file with a multi-frame content.

ImageSeriesWriter

If we take a 3D image in ITK and pass it to the ImageSeriesWriter and set the ImageIO to be the GDCMImageIO class, then the series will be written but they will all have the same DICOM header, and the third component of the origin and spacing will not be correct.

The way it should behave

With the ImageSeriesWriter

The expected behavior with the ImageSeriesWriter would be to have each one of the files in the series use a corrected header such that:

  • The origin of each one of the 2D images is computed in order to correspond to their location in space in the 3D image.
  • The pixel spacing of the images should match the two first spacings in the input 3D image
  • The inter-slice spacing is equal to the third dimension pixel spacing of the input image.
  • The direction cosines of the DICOM slices should match the orientation of the original 3D image.


The final test of the correctness in the series writing process would be to take a 3D image (not-from-DICOM), save it as a DICOM series and then read it back in order to recover an identical copy of the original image.

Proposed solution

With the ImageSeriesWriter

We propose to modify internally the ImageSeriesWriter in order to create a cannonical DICOM header and for each slice update its information about:

  • 3D position
  • Inter-Slice spacing
  • Orientation (direction cosines)

This could be done in an "else" option to the case when the user provide a MetaDataDictionaryArray to the ImageSeriesWriter.

Retrieved from "https://public.kitware.com/Wiki/index.php?title=Proposals:Writing_DICOM_from_non-DICOM&oldid=5666"