Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-json_export: Fix slice encoding direction sign #2900

Closed
wants to merge 1 commit into from

Conversation

Lestropie
Copy link
Member

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 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.

@Lestropie Lestropie self-assigned this May 13, 2024
@Lestropie Lestropie requested a review from a team May 13, 2024 00:32
@Lestropie Lestropie added this to the 3.0.5 updates milestone Sep 16, 2024
@Lestropie
Copy link
Member Author

Superseded by #3011.

@Lestropie Lestropie closed this Sep 20, 2024
@Lestropie Lestropie deleted the slice_encoding_sign_fix branch September 20, 2024 23:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

1 participant