Hi there,
We’ve got two different datasets using the exact same scanner protocols, and for reasons out of our control have ended up using different pipelines to get the data into BIDS format ready for fMRIPrep (one uses dcm2bids (herein referred to as pipeline 1), and the other uses a custom function developed in-house, pipeline 2). We plan to eventually switch to dcm2bids for both so that everything is consistent, but I want to understand a discrepancy that is arising from using two different methods…
For background, the EPI data is collected using axial slices with anterior-posterior phase encoding, and we collect b0 phase difference field maps with right-left phase encoding.
The NIFTIs output by pipeline 2 are in LPS orientation, and by pipeline 1 are LAS (discrepancy queried and resolved here. Pipeline 1 creates json files with PhaseEncodingDirection: i for fmap and PhaseEncodingDirection: j- for func. To my understanding, these are correct if the image is LAS (LAS increases in left, anterior and superior directions, so R-L is i and A-P is j-. The json files from pipeline 2, which have NIFTIs in LPS orientation, have PhaseEncodingDirection: i- for fmap and PhaseEncodingDirection: j for func. I think this is incorrect for the field maps. So, my first question is: am I right in understanding that if the image is LPS and phase encoding direction is R>L, PhaseEncodingDirection: i is correct?
When I look at the distortion correction by fMRIPrep, they (unsurprisingly given the above info) go in opposite directions; pipeline 1 causes the signal to shift anteriorly in the front of the brain, suggesting it was compressed during acquisition, whereas pipeline 2 shifts the signal posteriorly, suggesting the signal was stretched during acquisition. So, my second question is: should signal be stretched or compressed using anterior-to-posterior phase encoding? I was under the impression that A-P phase encoding would stretch the signal at the front of the brain, suggesting pipeline 2 is correct (though parameters in pipeline 2’s json files seem to be incorrect).
In case it’s relevant, we use a tilted (30 degree) acquisition for the EPIs.
if the image is LPS and phase encoding direction is R>L, PhaseEncodingDirection: i is correct?
Yes.
should signal be stretched or compressed using anterior-to-posterior phase encoding
If your images are in LAS and you have PhaseEncodingDirection of j-, then that is encoded Anterior-to-Posterior and I would expect to see compression in the front of the brain and expansion in the rear. Correction will do the reverse, and contract the rear and expand the front.
When I look at the distortion correction by fMRIPrep, they (unsurprisingly given the above info) go in opposite directions;
This should not happen, as one is LPS/j and the other is LAS/j-, so both should be treated the same. What version of fMRIPrep are you using? This may be resolved by 23.0.2, released in the last week or so.
In case it’s relevant, we use a tilted (30 degree) acquisition for the EPIs.
It will be relevant to the particular distortions, but not enough to change the overall gist.
hi @effigies, thanks for your fast response.
If your images are in LAS and you have PhaseEncodingDirection of j- , then that is encoded Anterior-to-Posterior and I would expect to see compression in the front of the brain and expansion in the rear. Correction will do the reverse, and contract the rear and expand the front.
Great, thank you for clarifying. That is definitely the correction that looks better visually when I compare the two!
This should not happen, as one is LPS/j and the other is LAS/j- , so both should be treated the same. What version of fMRIPrep are you using? This may be resolved by 23.0.2, released in the last week or so.
The actual field maps in the html outputs look very similar but with opposite colour blobs (red vs blue), and the SDC GIFs have identical ‘before’ images but one expands in the front of the brain and the other compresses for the ‘after’. I had assumed they were reversed because the phase encoding direction given in the json file for the fmap is opposite (i.e. i vs i-), or perhaps because either the phase encoding direction is different relative to the orientation of the image (though I’m not sure that’s relevant here)?
We’re using fMRIPrep 20.2.7 as advised here after we were having issues with SDC in v22
I had assumed they were reversed because the phase encoding direction given in the json file for the fmap is opposite (i.e. i vs i-),
For phase-difference fieldmaps, that does seem likely to produce a sign-inverted estimate of the field, which would then lead to incorrectly expanding/contracting when applying correction.
We’re using fMRIPrep 20.2.7 as advised here after we were having issues with SDC in v22
If you wouldn’t mind trying out 23.0.2 for the fieldmaps that are working well, I would be very interested in seeing how much of the old behavior we’ve managed to recover.