Proposals:Writing DICOM from non-DICOM: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
Line 13: Line 13:
== ImageSeriesWriter ==
== 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.
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. Also the Direction cosines will completely be discarded.


= The way it should behave =
= The way it should behave =

Revision as of 16:32, 21 March 2006

The Problem

How to take a ND image (possibly not a DICOM image file) and write it as a series of (N-1)D DICOM image 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. Also the Direction cosines will completely be discarded.

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.

Lorensen Comments

I would rather not add DICOM specific code to ImageSeriesWriter. Some sort of a helper class could be created that would populate the MetaDataDictionary for each slice. Helper classes would permit us to produce a variety of DICOM headers if need be. Many of the commercial Radiology workstations such as GE's Advantage Windows require tags that vary depending upon the vendor.

However, there is a know problem in image series writer. It invokes a 2D reader for each image. It passes down a 2D position and 2D orientation. DICOM, even though it is a 2D format, has a 3D position. This needs to be resolved for GDCMImageIO to generate proper image position patient.

Appendix

Use cases of the ImageSeriesWriter

  • The Writer does not use the MetaDataDictionary of the input image, instead it takes the MetaDataDictionary from the ImageIO.
  • The user can specify an array of MetaDataDictionaries. This was added a while ago in order to be able to read a DICOM series and write it as another DICOM series while still preserving the headers.