Repository navigation
BUG: Throw on repeated slice positions in DCMTKSeriesFileNames - #7064
Open
hjmjohnson wants to merge 2 commits into
Open
hjmjohnson wants to merge 2 commits into
hjmjohnson wants to merge 2 commits into
Conversation
hjmjohnson
marked this pull request as ready for review
November 1, 2026 13:26
Contributor
[Medium impact] The PR appears safe to merge; no actionable new issues remain.
|
hjmjohnson
force-pushed
the
bug-dcmtk-series-duplicate-position
branch
from
November 1, 2026 15:13
93c0472 to
4dac4a9
Compare
Member
Author
|
@greptileai review |
hjmjohnson
added a commit
to hjmjohnson/ITK
that referenced
this pull request
Nov 1, 2026
hjmjohnson
added a commit
to hjmjohnson/ITK
that referenced
this pull request
Nov 1, 2026
hjmjohnson
added a commit
to hjmjohnson/ITK
that referenced
this pull request
Nov 2, 2026
hjmjohnson
added a commit
to hjmjohnson/ITK
that referenced
this pull request
Nov 2, 2026
A series whose slice positions repeat (a multi-volume acquisition such as DWI) has no geometric order, so it cannot be one 3D volume. DCMTKSeriesFileNames sorted it by position anyway and silently returned a position-major interleave, unlike GDCMSeriesFileNames, which throws. Detect repeated positions along the slice normal and throw from GetFileNames() and GetInputFileNames() by default. Add FailOnAmbiguousOrdering and DidUseAmbiguousOrdering, matching GDCMSeriesFileNames. With the exception disabled, the series is returned in InstanceNumber order when the numbers are unique, else in file name order, which is the GDCM fallback and the DCMTK order before geometric sorting. GetSeriesUIDs() still enumerates without throwing. Assisted-by: Claude Code — surveyed dcm2niix, GDCM, and DICOM ordering; wrote the change and tests
OrderSeries() assigned the flag for each series it ordered, so ordering a later series with a valid geometry cleared the record of an earlier ambiguous one. Set it with OR and clear it only when the directory is parsed again. Assisted-by: Claude Code — found the reset while testing DCMTK parity; wrote the fix and test
hjmjohnson
force-pushed
the
bug-dcmtk-series-duplicate-position
branch
from
November 2, 2026 18:49
4dac4a9 to
b95470c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DCMTKSeriesFileNamesnow throws when slice positions repeat, matchingGDCMSeriesFileNames, and gainsFailOnAmbiguousOrderingandDidUseAmbiguousOrdering. GDCM'sDidUseAmbiguousOrderingno longer resets when a later series orders cleanly.A series with repeated positions (multi-volume DWI, for example) has no geometric order and is not one 3D volume. DCMTK sorted it by position anyway and silently returned a position-major interleave, which mis-paired gradients in BRAINSTools DWIConvert.
Related: #6463, #6464, #6466, #6468
Behavior
GetFileNames()andGetInputFileNames()throw for a series whose positions along the slice normal repeat (tolerance 1e-3 mm).GetSeriesUIDs()still enumerates without throwing.FailOnAmbiguousOrderingoff, the series comes back in InstanceNumber order when every slice has one and they are unique, else in file name order. This is the GDCM fallback, and also the DCMTK order in ITK 5.4.DidUseAmbiguousOrderingis true when any series returned since the last directory parse was ambiguous. GDCM assigned it per series, so ordering a later, well-ordered series cleared it; it is now OR-ed and cleared only on a new parse.Local testing
Linux, GCC 13.3, Release. A minimal build with
ITKIODCMTK,IOTransformDCMTK, andITKIOGDCM: all 36DCMTKSeriesFileNames*,GDCMSeriesFileNamesContract*, andGDCMSeriesDirection*GTests pass.New tests:
DCMTKSeriesFileNamesParity.RepeatedPositionsThrowByDefaultDCMTKSeriesFileNamesParity.RepeatedPositionsFallBackWhenAllowedDCMTKSeriesFileNamesParity.AmbiguityFlagIsStickyDCMTKSeriesFileNamesParity.MissingInstanceNumberFallsBackToFileNamesGDCMSeriesFileNamesContract.AmbiguityFlagIsSticky(fails on the unfixed GDCM code, passes with the fix)Downstream: BRAINSTools DWIConvert, built against this branch, passes all 52 of its tests (GE, Siemens, Philips, and Hitachi DWI series, several with repeated positions).
pre-commit run --all-filespasses.AI assistance
Claude Code researched how dcm2niix, dicm2nii, MRtrix3, and GDCM order DWI series, wrote the change and tests, and ran the builds above. I directed the design (throw by default, sticky flag) and reviewed the change.
🤖 Generated with Claude Code