I have encountered distortion correction issues, most recently with fmriprep 23.1.4. Does anyone have any ideas? So far no one has responded on Neurostars
See pdf in dropbox: https://www.dropbox.com/scl/fi/wwfhij7xtxqd8s58i3tvo/fmriprepSDC.pdf?rlkey=gn4caapucwq8f6uhkatott3rm&dl=0
fmriprepSDC.pdf

Shared with Dropbox

Dropbox
@JosetAEtzel or @effigies , do either of you have any insights into this terrible fmriprep distortion correction issue? Some labs are encountering this and others are not. It is really worrying. Is it related to the FOV not quite getting the whole brain? That is my only theory at the moment. ; (

@dpat @effigies I'm traveling so just looking on the phone, and can't cross-check our #fMRIPrep versions yet. But a few thoughts anyway:
- are these CMRR multiband sequences? If so, have you checked the SBRef images as well as the fmaps?
- We're collecting an #fMRI dataset with 3mm iso voxels, CMRR MB4, and haven't had trouble
- are all the person's runs in a session distorted, or just some? If some, compare the fmaps, etc between good and bad runs.

Good luck!

@JosetAEtzel @effigies

Thanks so much to both of you for your feedback.

**All affected or only some?**
Jo, I'm inquiring with the relevant labs whether it is all subjects or only some that are affected. Anecdotally, my conversations indicate that at the very least some participants are affected more than others.

As for multiple runs in one session: yes, in the example I have with 4 runs, all are affected.

@JosetAEtzel @effigies

**MB acceleration**
It looks to me like the run from the good lab had multiband acceleration while neither of the labs that had problems were using multiband. I've attached their protocols

Pest protocol (bad example):
https://www.dropbox.com/scl/fi/adohy8oiqcrv7fkgheg8d/pest.pdf?rlkey=b35u17bvtbk3q1p8fmjt5b0eg&dl=0
See See page 28-29 FMR Accel mode none

CAM protocol (good example): https://www.dropbox.com/scl/fi/1dez31jvztq1hgvs6tty9/cam.pdf?rlkey=ou5oihy9lnb3skln8sjzu7df8&dl=0
See pages 10-11 RS-FMRI-MB-high_resolution Accel factor 3.

pest.pdf

Shared with Dropbox

Dropbox
@dpat @JosetAEtzel I I think there are two issues right now. One related to masks when estimating/applying fieldmaps, and the other related to not applying a Jacobian modulation (down-weighting false signal pile-up). I think these can interact, so I'm trying to resolve Jacobians first.
@effigies
Thank you so much for taking this on. I am inquiring about sharing the bad dataset with you, if that would be useful.
@dpat Took about 2 months longer than I hoped, but we've got a release for you to test: https://mas.to/@effigies/111449183587172464
Chris Markiewicz (@[email protected])

I've just released fMRIPrep 23.2.0a1 for testing. This a pre-release of a major update that we've been referring to as fMRIPrep-next. Release notes here: https://github.com/nipreps/fmriprep/releases/tag/23.2.0a1 Please test it out, and report back any failures (or successes). Aiming for a full release in a few weeks.

mas.to
@effigies I tried this out and the native space boldref images look so much better! However, the standard space image is still a bit weird. This is with fieldmap-based correction. I've linked to before and after pictures: https://www.dropbox.com/scl/fi/os8z5em74604n2l11u1kp/fmriprep_sdc-Before-and-After-boldref-images.pdf?rlkey=pan7n1l4y0ir0pmkbke0pbm8i&dl=0
fmriprep_sdc Before and After boldref images.pdf

Shared with Dropbox

Dropbox
@dpat Not sure they attached here. Would you care to open an issue?
@dpat Oh, I see. That is a much bigger effect than I expected. Is there any chance of getting ahold of your data?
@effigies absolutely. See dropbox: The data is deidentified. https://www.dropbox.com/scl/fi/9saxth9tk3hgu9u6kd2ho/bids_pest107.zip?rlkey=fhzgtvrf7y2cewv4u2w279p99&dl=0
This is the raw bids, not the derivatives. Let me know if you want the latter.
bids_pest107.zip

Shared with Dropbox

Dropbox
@dpat Nope, raw is great. Running now. Thanks!
@dpat I'm realizing in the images you sent, you used the HMC boldref. That's not distortion corrected at all. Have a look at the desc-coreg_boldref.nii.gz. Or the "Susceptibility distortion correction" reportlet compares them:
@dpat The distortion correction seems not ideal, but in line with the fieldmap provided. The main weirdness IMO is that there is significant signal pileup in the inferior frontal lobe, which will be an effect of Jacobian modulation. I'm a bit conflicted here, as that typically produces cleaner results.
@effigies Well, the results are certainly much improved. Do you have any suggestions going forward?
@dpat Not at present. I'm going to look into whether we should make Jacobian modulation optional, or contingent on the fieldmap type.
@effigies I'm wondering if the defacing is causing problems for the distortion correction? I know there are a variety of problems emerging for handling defaced data well.
@dpat Are you defacing BOLD data or fieldmaps? If so, that's possible. It would be interesting to retry on undefaced data and see what the effect is.
@effigies No we are not defacing anything but the T1w image.
@effigies I tried running your new alpha version of fmriprep on non-defaced data, but the results look the same *there is still a bright rhinoceros horn on the normalized image. I guess I'm glad that, as you suggested, defacing does NOT appear to
cause the problem.
@dpat Have you tried this dataset with 20.2.7 (LTS)? I just tested another dataset with direct fieldmaps (processed very similarly) and it's somewhat cleaner than the alpha.
@effigies Do you really mean 20.2.7 or is there a new 23.2.x?
@effigies According to my notes, I did try 20.2.7 lts and was not impressed.
@dpat Good to know. I've been told that this dataset I'm looking at is kind of weird. Old scanner software, tricky subjects. Trying 20.2.7 was an attempt to determine if the fieldmap was just garbage, but it worked well back then.
@effigies Our scanner software desperately needs to be updated...I hadn't thought about it possibly contributing to problems. However, some labs don't have any problem. I believe they are orienting their slices differently as there is less evidence of stretchy eyeballs in their raw scans.
@effigies I did not even realize what the hmc images were! Thank you! I have uploaded the coreg_boldref instead (same link: https://www.dropbox.com/scl/fi/os8z5em74604n2l11u1kp/fmriprep_sdc-Before-and-After-boldref-images.pdf?rlkey=pan7n1l4y0ir0pmkbke0pbm8i&dl=0)
fmriprep_sdc Before and After boldref images.pdf

Shared with Dropbox

Dropbox
@dpat Yes, this is what I'm seeing. The coreg reference shows the same effects as the coreg reference resampled to MNI. So it's not an effect of the MNI resampling being bad, but a limit of the fieldmap. If you're able to apply your fieldmaps with more standard PRELUDE and FUGUE and get a better result, we could try to see where we're doing something different.
@effigies Are the magnitude and phasediff field maps we are collecting suboptimal? Is the slice angle for the fmri data a problem (I notice quite a bit of distortion in these fmri images from the start). Not all researchers are seeing this problem…I really appreciate your willingness to examine the problem.
@dpat I'm not prepared to say that the fieldmap is suboptimal, but the result looks suboptimal and our code seems to be doing what it's supposed to. It could be that there are better ways for us to handle this fieldmap/BOLD, but I would need to see it done better by another tool to understand where we're falling short.