Follow-up to #6468 (now closed): the GDCMSeriesFileNames migration onto gdcm::IPPSorter landed (50dfb136658, 7cb3bbec23d), but @dzenanz's specific request from that discussion is not yet fully satisfied and deserves its own tracking issue.
Gantry-tilt CTs should continue to be supported. I encountered this with pediatric patients - technicians were trying hard to avoid the eyes while scanning.
Current state on main
gdcm::IPPSorter treats gantry tilt as an error, so with the default m_FailOnAmbiguousOrdering = true (itkGDCMSeriesFileNames.h:258) a gantry-tilt series now throws instead of ordering. Gantry-tilt CT is only handled by setting FailOnAmbiguousOrdering to false, which routes to the ported SerieHelper fallback — and the code comment for that path (itkGDCMSeriesFileNames.cxx:234) calls it "an untrustworthy, non-standard hack whose output should not be trusted."
So the acquisition @dzenanz named — real, clinically-motivated pediatric head CT — is supported only via an opt-in path the code itself disavows, and not at all by default.
The ask
Decide and implement first-class gantry-tilt handling for GDCMSeriesFileNames. Options to weigh:
- Detect gantry tilt explicitly (non-orthogonal slice-normal vs. orientation) and order it correctly via IPP-projected-on-normal, without routing through the disavowed legacy fallback — i.e. make the tilt case trustworthy rather than merely tolerated.
- Keep the strict default but promote gantry tilt out of the "ambiguous → throw" bucket into a supported, documented, correctly-sorted case.
- Confirm whether
IPPSorter's own SetComputeZSpacing / tilt handling can be leaned on before falling back to ported logic.
Whatever the choice, the acceptance test is a gantry-tilt CT series that sorts correctly under the default settings, with a regression test fixture.
Related
Follow-up to #6468 (now closed): the
GDCMSeriesFileNamesmigration ontogdcm::IPPSorterlanded (50dfb136658,7cb3bbec23d), but @dzenanz's specific request from that discussion is not yet fully satisfied and deserves its own tracking issue.Current state on
maingdcm::IPPSortertreats gantry tilt as an error, so with the defaultm_FailOnAmbiguousOrdering = true(itkGDCMSeriesFileNames.h:258) a gantry-tilt series now throws instead of ordering. Gantry-tilt CT is only handled by settingFailOnAmbiguousOrderingto false, which routes to the ported SerieHelper fallback — and the code comment for that path (itkGDCMSeriesFileNames.cxx:234) calls it "an untrustworthy, non-standard hack whose output should not be trusted."So the acquisition @dzenanz named — real, clinically-motivated pediatric head CT — is supported only via an opt-in path the code itself disavows, and not at all by default.
The ask
Decide and implement first-class gantry-tilt handling for
GDCMSeriesFileNames. Options to weigh:IPPSorter's ownSetComputeZSpacing/ tilt handling can be leaned on before falling back to ported logic.Whatever the choice, the acceptance test is a gantry-tilt CT series that sorts correctly under the default settings, with a regression test fixture.
Related