-json_export: Fix slice encoding direction sign #2900
Closed
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.
Erroneous sign flip appears to trace all the way back to 909ccab here, which came in #1175, so it appears to have been there ever since capturing of slice encoding information was added.
I discovered this during a larger experiment verifying the handling of DWI metadata, which involves processing data from 24 DWI acquisitions, with every possible combination of slice orientation, slice order ("ascending" vs. "descending"), and phase encoding direction. This changes makes the output of
mrconvert
from an input DICOM series commensurate with both the outputs fromdcm2niix
and the orientations indicated in theSeriesDescription
s.In terms of consequences:
mrdegibbs
.dwifslpreproc
, I think the effect should be nil.The effect of the slice encoding direction (not axis) being negative is that the order of slices / slice groups within the
slspec
file gets reversed.To my knowledge,
eddy
models within-volume subject motion separately per volume. Therefore if the order of slices / slice groups within each volume is exactly reversed, the fit of the relevant basis functions within each group should be reversed in time. There may be greater discrepancies in the derivatives of those functions between volumes, buteddy
does not take such into consideration.@dchristiaens: I recommend checking the dHCP pipeline regarding whether slice encoding information was extracted using
mrconvert
ordcm2niix
. If the former, then the imposition of smoothness of motion parameters between slice groups across different volumes may result in this bug detrimentally affecting pre-processing.