MRtrix3 provides a set of tools to perform various advanced diffusion MRI analyses, including constrained spherical deconvolution (CSD), probabilistic tractography, track-density imaging, and apparent fibre density
Erroneous sign flip appears to trace all the way back to 909ccab81b659cfb42eac08e1bf1cd814836f98c 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 from dcm2niix and the orientations indicated in the SeriesDescriptions.
In terms of consequences:
Anything that involves detection of the slice encoding axis (ie. sign of the direction is ignored) should not be affected; eg. mrdegibbs.
For 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, but eddy does not take such into consideration.
Other pipelines may need to be checked.
@dchristiaens: I recommend checking the dHCP pipeline regarding whether slice encoding information was extracted using mrconvert or dcm2niix. 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.
Erroneous sign flip appears to trace all the way back to 909ccab81b659cfb42eac08e1bf1cd814836f98c 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
mrconvertfrom an input DICOM series commensurate with both the outputs fromdcm2niixand the orientations indicated in theSeriesDescriptions.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 theslspecfile gets reversed. To my knowledge,eddymodels 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, buteddydoes not take such into consideration.mrconvertordcm2niix. 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.