[pieper]

DCMTKFileReader::GetSpacing swaps Pixel Spacing into the index order it returns, then overwrites that with the unswapped values when it cannot find all three. Series lacking Spacing Between Slices (0018,0088) read with in-plane axes transposed.

Measured behavior

Single-frame CT, Rows 4, Columns 8, PixelSpacing 1\3, so the correct ITK spacing is [3, 1, …]. Read through 3D Slicer 5.12.4, which exposes both back ends:

ImageIO	without (0018,0088)	with (0018,0088)
DCMTKImageIO	[1, 3, 2] — swapped	[3, 1, 2]
GDCMImageIO	[3, 1, 2]	[3, 1, 2]

DCMTKImageIO::ReadImageInformation does not check the EXIT_FAILURE that GetSpacing returns on that path. Square pixels hide the effect, which is why it has gone unnoticed.

Why the swap is correct

DICOM PS3.3 Section 10.7.1.3:

The first Value is the row spacing in mm, that is the spacing between the centers of adjacent rows, or vertical spacing. The second Value is the column spacing in mm, that is the spacing between the centers of adjacent columns, or horizontal spacing.

Other implementations agree, several of them with a comment saying so:

implementation	code
dicom3tools	libsrc/src/dctool/pixposn.cc — "PixelSpacing Row/Col is space BETWEEN rows/cols respectively - hence row pixels of size PixelSpacingRow along ImageOrientationPatientCol"
PixelMed	com/pixelmed/geometry/GeometryOfSlice.java — row*columnArray[i]*voxelSpacing[0]/*between rows*/ + column*rowArray[i]*voxelSpacing[1]/*between cols*/
GDCM	gdcmImageHelper.cxx — sp.push_back(at.GetValue(1)); sp.push_back(at.GetValue(0));, and std::swap(sp[0], sp[1]) on the general path
DCMTK	dcmimgle/libsrc/diimage.cc — PixelHeight from value 1, PixelWidth from value 2
highdicom	src/highdicom/spatial.py — spacing_between_rows / spacing_between_columns, each paired with the matching index direction
nibabel	nicom/dicomwrappers.py — np.fliplr(iop) with voxel_sizes = (ps[0], ps[1], zs)
dcmqi	libsrc/Itk2DicomConverter.cpp — writes spacing[1] \ spacing[0] from an ITK image

The two comments describing (0028,0030) as "physical X,Y spacing" are corrected in the same commit; they state the value order the opposite way round and are what the removed assignments were consistent with.

Test

itkDCMTKImageIOGTest.cxx adds a GoogleTest driver to this module. DCMTKImageIO.InPlaneSpacingOrderWithoutSpacingBetweenSlices writes a single-frame CT with PixelSpacing 1\3 and no (0018,0088), reads it back, and checks the spacing is [3, 1]. It writes its own input with DCMTK, already in TEST_DEPENDS, so no new ExternalData is needed.

Not built locally. ITKIODCMTK is EXCLUDE_FROM_DEFAULT and configure-ci does not set Module_ITKIODCMTK, so the Pixi jobs appear not to build this module — a reviewer with the module enabled would be confirming something CI does not. The behavior in the table above was measured against a built ITK, and the fix itself is a deletion of three assignments.

AI assistance

• Tool: Claude Code (claude-opus-5)
• Role: root-cause analysis and drafting
• Contribution: isolated the fall-through in GetSpacing by differential testing of the two ImageIO back ends with and without (0018,0088), then surveyed how other DICOM implementations order the attribute
• Reviewed before committing; test compilation not verified locally

Related: pydicom/pydicom#2416 — the same confusion in an example, found in the same survey.