Summary
itk::DCMTKSeriesFileNames orders slices only by InstanceNumber (0020,0013) using an unstable std::sort, whereas itk::GDCMSeriesFileNames orders geometrically by ImagePositionPatient projected on the slice normal. When InstanceNumber is absent or constant across a series, every sort key is equal and the resulting order is implementation-defined (seeded by directory-glob order), producing a scrambled volume with a meaningless, machine-dependent z-spacing.
Where
Modules/IO/DCMTK/src/itkDCMTKSeriesFileNames.cxx:146 — std::sort(allHeaders..., CompareDCMTKFileReaders)Modules/IO/DCMTK/src/itkDCMTKFileReader.cxx:1455-1458 — CompareDCMTKFileReaders returns a->GetFileNumber() < b->GetFileNumber(); GetFileNumber() is InstanceNumber (0020,0013), default 0.
Compare with itk::GDCMSeriesFileNames → gdcm::SerieHelper::OrderFileList() → ImagePositionPatientOrdering() (Modules/ThirdParty/GDCM/.../gdcmSerieHelper.cxx:308-438): slice normal = cross-product of the two ImageOrientationPatient (0020,0037) cosine vectors; sort by IPP (0020,0032) dotted with that normal; fall back to ImageNumber.
Impact
Any DICOM series whose InstanceNumber does not monotonically track geometric position (or is unset) is read in the wrong slice order by DCMTKSeriesFileNames. This surfaced in PR #6456 (itkDCMTKTransformIOResampleTest), whose synthetic fixtures all carry InstanceNumber 0: the same inputs produce a different z-spacing on every machine, so no committed baseline can stabilize the test.
DCMTK has no helper to delegate to
DCMTK ships no directory-scanning series sorter analogous to gdcm::SerieHelper::OrderFileList. FGPlanePosPatient (dcmfg) is an enhanced-multiframe accessor; ConcatenationLoader sorts by InConcatenationNumber; dcddirif/dcdicdir build DICOMDIRs. The geometric ordering must be implemented in ITK using the existing DCMTKFileReader accessors (GetDirCosArray, GetOrigin, GetFileNumber).
Fix
Order by IPP-projected-on-normal as the primary key, with InstanceNumber then file name as deterministic fallbacks, using a stable sort. PR forthcoming.
Summary
itk::DCMTKSeriesFileNamesorders slices only by InstanceNumber (0020,0013) using an unstablestd::sort, whereasitk::GDCMSeriesFileNamesorders geometrically by ImagePositionPatient projected on the slice normal. When InstanceNumber is absent or constant across a series, every sort key is equal and the resulting order is implementation-defined (seeded by directory-glob order), producing a scrambled volume with a meaningless, machine-dependent z-spacing.Where
Modules/IO/DCMTK/src/itkDCMTKSeriesFileNames.cxx:146—std::sort(allHeaders..., CompareDCMTKFileReaders)Modules/IO/DCMTK/src/itkDCMTKFileReader.cxx:1455-1458—CompareDCMTKFileReadersreturnsa->GetFileNumber() < b->GetFileNumber();GetFileNumber()is InstanceNumber (0020,0013), default 0.Compare with
itk::GDCMSeriesFileNames→gdcm::SerieHelper::OrderFileList()→ImagePositionPatientOrdering()(Modules/ThirdParty/GDCM/.../gdcmSerieHelper.cxx:308-438): slice normal = cross-product of the two ImageOrientationPatient (0020,0037) cosine vectors; sort by IPP (0020,0032) dotted with that normal; fall back to ImageNumber.Impact
Any DICOM series whose InstanceNumber does not monotonically track geometric position (or is unset) is read in the wrong slice order by
DCMTKSeriesFileNames. This surfaced in PR #6456 (itkDCMTKTransformIOResampleTest), whose synthetic fixtures all carry InstanceNumber 0: the same inputs produce a different z-spacing on every machine, so no committed baseline can stabilize the test.DCMTK has no helper to delegate to
DCMTK ships no directory-scanning series sorter analogous to
gdcm::SerieHelper::OrderFileList.FGPlanePosPatient(dcmfg) is an enhanced-multiframe accessor;ConcatenationLoadersorts by InConcatenationNumber;dcddirif/dcdicdirbuild DICOMDIRs. The geometric ordering must be implemented in ITK using the existingDCMTKFileReaderaccessors (GetDirCosArray,GetOrigin,GetFileNumber).Fix
Order by IPP-projected-on-normal as the primary key, with InstanceNumber then file name as deterministic fallbacks, using a stable sort. PR forthcoming.