[ITK-users] Minimal example for writing Dicom sets an incorrect spacing between slices

[Bill Lorensen]

Here is an old message that describes the issue with Spacing:

Written by David Clunie, September 2005

Hi Andrew, Mathieu, Stephen, et al

Image Position (Patient) (0020,0032) is the only attribute
that can be relied on to determine the "reconstruction interval"
or "space between the center of slices".

If the distance between Image Position (Patient) (0020,0032)
of two parallel slices along the normal to Image Orientation
(Patient) (0020,0037) is not the same as whatever happens to
be in the DICOM Spacing Between Slices (0018,0088) attribute,
then (0018,0088) is incorrect, without question

As Mathieu notes, this is a known bug in some scanners.

When Slice Thickness (0018,0050) + Spacing Between Slices
(0018,0088) equals the computed reconstruction interval,
then chances are the modality implementor has made the
obvious mistake of misinterpreting the definition of
(0018,0088) to mean the distance between edges (gap)
rather than the distance between centers.

Conversely, I have never encountered an error like this in
Image Position (Patient) (0020,0032).

Further, one should never use Slice Location (0020,1041)
either, an optional and purely annotative attribute, though
chances are that the distance between the Slice Location
(0020,1041) values of two slices will match the distance
along the normal to the orientation derived from the
position.

David

On Wed, Mar 26, 2014 at 10:57 AM, Joël Schaerer <joel.schaerer at gmail.com> wrote:
> Hi all,
>
> I think I may have found a problem in the Dicom writing example
> ImageReadDicomSeriesWrite.cxx included with the sources (version 4.3.1). The
> spacing between slices in the output dicom files is systematically set to 1,
> no matter the spacing of the input image.
>
> Here is a sample image:
>
> http://sd-33294.dedibox.fr/~joel/input.mha
>
> This is the output from gdcminfo on one of the output files:
>
> MediaStorage is 1.2.840.10008.5.1.4.1.1.4 [MR Image Storage]
> TransferSyntax is 1.2.840.10008.1.2 [Implicit VR Little Endian: Default
> Transfer Syntax for DICOM]
> NumberOfDimensions: 2
> Dimensions: (256,256,1)
> SamplesPerPixel    :1
> BitsAllocated      :16
> BitsStored         :16
> HighBit            :15
> PixelRepresentation:1
> ScalarType found   :INT16
> PhotometricInterpretation: MONOCHROME2
> PlanarConfiguration: 0
> TransferSyntax: 1.2.840.10008.1.2
> Origin: (0,0,0)
> Spacing: (0.9375,0.9375,1)
> DirectionCosines: (1,0,0,0,1,0)
> Rescale Intercept/Slope: (0,1)
> Orientation Label: AXIAL
>
> Here is the relevant gdcmdump output:
>
> (0018,0088) ?? (DS) [1 ]                                          # 2,1
> Spacing Between Slices
>
> I've tried forcing a number of dicom tags in the GDCMImageIO metadata dict,
> with no success.
>
> Is there a workaround around this? Is it a bug in ITK?
>
> Thanks for your help!
>
> joel
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users



-- 
Unpaid intern in BillsBasement at noware dot com