Problems with fieldmap-based susceptibility distortion correction in combination with a high-resolution partial volume

1

I am hoping that one of the fmriprep experts in this forum can help us with problems we encountered using fieldmap-based distortion correction in combination with a high-resolution partial volume dataset. Is there anyone out there, who successfully did this and if yes tell us how? Any help is greatly appreciated and please let me know if you need more info in addition to what I have given below)!

We are collecting functional data at high (1.5 mm isotropic) resolution within a partial volume (28 slices) on a Siemens MAGNETOM Prisma Fit at 3 Tesla with TR = 2.45. We are acquiring several BOLD runs (single echo), T1, a full-FOV EPI image, and fieldmaps (phasediff and magnitude).

So far we have been running fmriprep fairly successfully using the default setup with two exceptions: (1) WITHOUT using fiedmap-based distortion correction (SDC) and (2) using --bold2t1w-init header, using this call:

docker run -ti --rm -v “/mnt/g/SPM_data/445/bids/:/data:ro” -v “/mnt/g/SPM_data/445/bids/derivatives/fmriprep:/out” -v “/mnt/g/tmp/:/work” -v “/mnt/c/Allgpsy/hruge/Freesurfer:/fslic:ro” -v “/mnt/g/SPM_data/445/:/plugin:ro” nipreps/fmriprep:22.0.1 /data /out participant --participant-label 22443 -w /work --fs-license-file /fslic/license.txt --output-spaces anat MNI152NLin2009cAsym fsnative fsaverage --use-plugin /plugin/plugin_mem.yml --stop-on-first-crash --ignore fieldmaps sbref --bold2t1w-init header

Note that we also tell fmriprep to ignore the sbref image (i.e., the full FOV images. Otherwise, fmriprep performance deteriorates considerably)

However, we were NOT successful in integrating the fieldmap-based SDC (i.e. by telling fmriprep to not ignore the fieldmaps). Btw., we also unsuccessfully tried the fieldmap-less SDC option and also we ran into the comparable problems using different versions of fmriprep (anything between 20.x and 22.0.2) and with and without freesurfer reconall.

The problem is NOT that fmriprep exits with an error message, but the results are not satisfying on several levels:

  1. The segmentation of the functional images (summarized in the *desc-rois_bold.svg figures) seems strange (not always but most of the time). See below for examples.
  2. The SDC correction itself seems too extreme (summarized in the *desc-sdc_bold.svg Figures) compared to what I have seen using full FOV data.
  3. Coregistration is off (as summarized in the *desc-bbregister_bold.svg Figures).

I have copied the *.svg files for two exemplary functional runs of one subject WITH and WITHOUT SDC here:

WITHOUT SDC:

  • Functional segmentation shown in *desc-rois_bold.svg is maybe not perfect but still OK I would think.
  • Coregistration check shown in * desc-bbregister_bold.svg also rather OK I would think
    WITH SDC:
  • Functional segmentation shown in *desc-rois_bold.svg totally off especially in run 3
  • Coregistration check shown in *desc-bbregister_bold.svg not OK – look at the z=22 section)
  • The SDC correction shown in *desc-sdc_bold.svg seem strange (too much?)
2

Thank you for this thorough report.

My 2 cents:

Maybe using the option --force-no-bbr could give you different (hopefully better) results when bold-2-T1w registration fails?
Do you you have a full-FOV BOLD image that you could use as an intermediate target for registration? IT is a strategy commonly used for full FOV acquisitions but I am not sure how to use it within FMRIPREP.

3

Thanks a lot for your reply.

Point 1: Unfortunately, using --force-no-bbr makes things worse! I have copied the results here (in subfolder with_SDC_nobbr):

Note that --force-no-bbr also worsens the good results we obtained without fieldmap-based SDC.

Point 2: Yes, we have full-FOV images, but that also doesn’t improve things (if I do not deactivate by --ignore sbref).

Note that in dcm2bids json file, I specified the full-FOV like this, but I wasn’t sure about customLabels and sidecarChanges (but generally when trying out many different versions my general impression was that the full-FOV didn’t really help):

 {
     "dataType": "func",
     "modalityLabel": "bold",
     "customLabels": "task-2LRN_run-01",
     "criteria": {
        "SeriesNumber": 7
     },
     "sidecarChanges": {
        "TaskName": "2LRN"
     }
  },  
 {
     "dataType": "func",
     "modalityLabel": "sbref",
     "customLabels": "task-2LRN_run-01",
     "criteria": {
        "SeriesNumber": 9
     },
     "sidecarChanges": {
        "TaskName": "2LRN"
     }
  },
4

I am surprised by this choice.

Usually sbref images refer to the image generated from multiband sequences which has better contrast than the bold series acquired at steady-state.

I think this sbref is used (when --ignore sbref is not passed as an argument) as a target for the bold realignment AND used also for the bold-to-T1 registration.

I am not sure how mcflirt, the realignment function used internally by FMRIPREP would deal with a sbref image with different FOV that the BOLD images themselves. This may explain why the removal of --ignore sbrefgives you wrong results.

The same thing may happen also with you fieldmap, there could an issue of misregistration between your magnitude image which I guess is full FOV and your partial volume bold image.

We did run an fMRI project with partial FOV at our center and fmriprep worked fine on our data:
Here are a several differences we had which could explain the difference of behavior of fmriprep:

  • The FOV was bigger: 30 slices of 2mm and 2mm isotropic resolution
  • the fieldmap was done by acquiring 2 SE-EPI images with reversed phase encoding directions and similar distorsions settings as the func image (same resolution, total readout time and echo spacing).