Unexplained flip of the PE direction under some unknown circumstances

[oesteban]

Using @mgxd's dataset in the debugging of the fMRIPrep + SDCFlows integration, we seem to have hit a difficult bug for which I haven't found the failure point (and hence the fix).

In order to permit progress on nipreps/fmriprep#2392, I'm separating this problem that seems to do with some idiosyncratic parameter (likely related to orientation headers) that makes the problem apparent.

[effigies]

I vaguely recall FSL making strong assumptions about an image being left or right handed in some context. Could be related?

[oesteban]

The flip is A/P so I'm afraid this is genuinely an SDCFlows problem. It also occurs that correction is correctly performed on the reference (i.e., a combination of EPI scans that were fed into topup) but then incorrectly applied on the target bold.

Registration of the bold target and the EPI reference seems okay (no gross error there), and I've checked the implementation a few times not.

[effigies]

Is it possible that we have, e.g., an LPS file that we're reorienting to RAS without flipping the PhaseEncodingDirection polarity?

[oesteban]

It is very possible, probably top 1 suspect. The alternative is also true: we have an LPS file and we are flipping two times.

[effigies]

Well, ds003130 has A/P and P/A bold series, sbrefs and EPI fieldmaps. Everything's in LAS. Should be a good test dataset.

[oesteban]

@mgxd - after processing your data with the new version, I found that the problem persists.

Then, I visually checked the distortion of the two EPI blips under fmap/ and the bold task under func/. Simple screening makes apparent that the distortion of the BOLD image is consistent with that of sub-voice969_ses-1-acq-func_dir-AP_run-02_epi.nii.gz, while metadata says otherwise:

(base) oesteban@myelin:/data/datasets/fmriprep-tests/mgxd/sub-voice969/ses-1$ grep PhaseEncodingDirection fmap/sub-voice969_ses-1_acq-func_dir-AP_run-02_epi.json 
    "InPlanePhaseEncodingDirectionDICOM": "COL",
    "PhaseEncodingDirection": "j-",
(base) oesteban@myelin:/data/datasets/fmriprep-tests/mgxd/sub-voice969/ses-1$ grep PhaseEncodingDirection func/sub-voice969_ses-1_task-emosent_run-01_bold.json 
   "InPlanePhaseEncodingDirectionDICOM": "COL", 
   "PhaseEncodingDirection": "j", 

In other words, either the functional or both fieldmaps have reversed PE settings - by the looks of the distortion I'd say the functional is wrong. Flipping the setting for the functional resolved the issue.

Affines don't show any axes flip or reordering that could affect the interpretation of the metadata by SDCFlows (although, the inconsistency above is independent of SDCFlows' interpretations):

In [3]: nb.load("func/sub-voice969_ses-1_task-emosent_run-01_bold.nii.gz").affine[:3, :3]
Out[3]: 
array([[-1.99918818e+00,  1.50208490e-03,  6.26566336e-02],
       [-2.04624012e-02,  1.84701359e+00, -8.43580365e-01],
       [ 5.31794392e-02,  7.67162681e-01,  2.03087330e+00]])

In [4]: nb.load("fmap/sub-voice969_ses-1_acq-func_dir-AP_run-02_epi.nii.gz").affine[:3, :3]
Out[4]: 
array([[-1.99963975, -0.02582768, -0.02781582],
       [-0.01320271,  1.84736598, -0.76620144],
       [-0.03558761,  0.76587981,  1.84720373]])

I think we can keep this closed - please let us know if you make in further investigation on this particular problem.

[oesteban]

I stand corrected - editing the metadata PhaseEncodingDirection did not work. Something deeper might be happening. Reopening and investigating tomorrow.

[mgxd]

@oesteban looking through fMRIPrep's 21.0.0 Dockerfile, I noticed we are not using topup from FSL6 - could that partially explain this?

[oesteban]

I doubt it because the field map looks okay. Also, I'm running locally with FSL 6, I believe.

[effigies]

Probably more an artifact of failing to account for rotation of splines