Expose the slice step that affine_of_package already computes (#177) - #180
Merged
Merged
Conversation
…si-nmr#177 affine_of_package builds the centre-to-centre slice step, uses it as the third column of the affine, and discards it. A consumer that needs the number -- a NIfTI writer's third zoom, a DICOM SpacingBetweenSlices -- had to re-derive it, and the two obvious parameter sources are both wrong for a large share of real data. Over the 1599 reconstructions of our corpus that have geometry, VisuCoreSlicePacksSliceDist falling back to VisuCoreFrameThickness disagrees with the affine for 197 and resolution[2] for 82. Both fail structurally, not marginally. VisuCoreFrameThickness is the slab thickness of a 3-D acquisition, so T1_FLASH_3D_iso reports 12.0 mm where the plane step is 0.125 mm. resolution[2] is 0.0 where the third dimension is not spatial (13 parametric maps here) and a cross-package diagonal where the reconstruction holds several packages -- 20*sqrt(2) between two perpendicular packages whose spacings are 2.0 mm (61 here). slice_distance is the length of the affine's slice column, per package, so it inherits the affine's handling of all three cases without special-casing any of them: finite and positive for every one of those 1599, and unavailable for the 27 with no geometry -- the same availability as affine_of_package itself. Spacing is not thickness. They differ for a gapped acquisition, and VisuCoreFrameThickness remains the source for the thickness; a consumer writing BIDS needs both, separately. SlicePackageSplitter, which had the same norm inline, now asks for it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NuK1cZi8U54WXAdXMmGpzy
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.
Fixes #177.
affine_of_packagebuilds the centre-to-centre slice step, uses it as the third column of the affine, and discards it. This exposes it:Shape and availability are as the issue proposed: one value per package, because packages can be spaced differently (spec 7.10), and available exactly where
affine_of_packageis — note that isaffine_of_package, notaffine, so a parametric map whose third axis is a frame group still reports its spacing.SlicePackageSplitter._split_VisuCoreSlicePacksSliceDisthad the same norm inline; it now asks for it.Measured on our corpus
1631 vendor
2dseqreconstructions (PV 5.1, 6.0, 6.0.1, 7.0.0, 360.3.4–360.3.7), againstnp.linalg.norm(affine_of_package(i)[:3, 2]):VisuCoreSlicePacksSliceDist, falling back toVisuCoreFrameThicknessresolution[2]slice_distanceitself is finite and positive for all 1599, and unavailable for the 27 that carry noVisuCorePosition/VisuCoreOrientation. 0 bad values.Both alternatives fail structurally rather than marginally:
Of the 82
resolution[2]disagreements, 13 are the0.0parametric-map case and 61 are the cross-package diagonal.Notes for review
COMPUTED_REPORT_PROPERTIES.affineis inbruker reportoutput and this arguably belongs there too, but that changes the report schema and all four property references, so I left it as an API-only addition for you to decide on. Happy to add it.test/synthetic.py), covering the gapped stack, the 3-D slab, the per-package list, the parametric map, and the no-geometry failure.test_affine_agrees_with_the_paravision_nifti_sformfailures are the same ones master has.🤖 Generated with Claude Code
https://claude.ai/code/session_01NuK1cZi8U54WXAdXMmGpzy