[ITK] [ITK-users] Minimal example for writing Dicom sets an incorrect spacing between slices
Bill Lorensen
bill.lorensen at gmail.com
Wed Mar 26 14:41:09 EDT 2014
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
_____________________________________
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
More information about the Community
mailing list