[Insight-users] Dicom and Image Spacing

[Rômulo Pinho]

Hello, Alex
It is indeed a change in GDCM 2.x. You can read about it at

http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=Using_GDCM_API#Automatic_ordering_of_slices_for_vtkGDCMImageReader.SetFileNames

http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=Imager_Pixel_Spacing#Spacing_along_Z_.28third_dimension.29

http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=Using_GDCM_API#Where_is_the_value_of_gdcm.Image.Spacing_coming_from_.3F 


Kind regards,
Rômulo


On 12/06/2012 10:16 AM, Alexander Schmidt-Richberg wrote:
> Hi,
>
> sorry if this has been discussed before. I'm sure I'm not the first to
> realize, but I couldn't find anything in the mailing lists.
>
> I have a problem with reading/writing volume images as Dicom files with
> ITKv4, presumably due to the change from GDCM 1.x to 2.x.
>
> In ITK 3, the image spacing was stored in the tags
> "SpacingBetweenSlices" and "ImagerPixelSpacing". In v4,
> "NominalScannedPixelSpacing" is used for the in-plane spacing, however,
> the z-spacing is not stored at all (if I'm right). That means, all of
> the "old" images I'm reading with ITK4 have a uniform spacing of 1,
> since the old tags are not interpreted. Moreover, programs like MeVisLab
> ignore the new tag.
>
> Has this behavior been discussed? Is it working as intended and is there
> any workaround?
>
> Best regards Alex
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20121206/b6b248d9/attachment.htm>