Z spacing in Image Series Reader

How is Z spacing determined from a DICOM series, when using SimpleITK’s ImageSeriesReader? It looks like X and Y spacing is taken from Pixel Spacing (0028|0030) field, but I have not been able to find the code for Z spacing. Is it inherited from GDCM, or does ITK have its own algorithm to calculate it?

Hello @alkamid

The Z spacing is determined by GDCM. This is done by reading the series and looking at the Image Position Patient tag (0020|0032) per image and then calculating the z spacing.

2 Likes

Thank you @zivy for the explanation. Do you happen to know where in GDCM’s source is this calculated? The simplest method I can think of would be taking the mean of Z differences between all sorted slices — is this what’s happening? Given that this is ITK forum, treat it as a bonus question! (:

Hello @alkamid,

Possibly here, but as you noted this isn’t the GDCM forum, so you should probably ask there to get the authoritative answer.

Z spacing is calculated in ImageSeriesReader. Take a look at this commit which updated that calculation for ITK 5.0.

2 Likes

Thanks a lot @dzenanz, this is exactly what I was looking for!

1 Like

@dzenanz, do I read the code correctly, and there is a default value of Z spacing = 1 if it’s not specified in DICOM metadata? Why is this the case?

    if ( Math::AlmostEquals(dirNnorm, 0.0) )
      {
      spacing[this->m_NumberOfDimensionsInImage] = 1.0;
      }

If just one image is read, having its thickness be 0.0 is more wrong than having it be 1.0. A choice which was probably made long ago, and now that is backwards compatible behavior.

Is this fallback only activated when one image is read? Could we have a series with wrong Z spacing which would result in a 3D volume with 1.0 spacing?

That will be zero only if the last slice has the same position as the first slice:


Which means there is just one slice, or the positions (image position patient tag) are junk.

1 Like