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.
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.
Thanks a lot @dzenanz, this is exactly what I was looking for!
@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.