Poor func/anatomical registration with fmriprep (21.0.2) on multi-echo data set

[zachladwig]

Hi!

I am sometimes getting bad func/anatomical registration which results in low snr on parts of the brain where I wouldn’t expect to get low snr (like the lateral occipital lobe).

Here is the fMRIprep command I used.

singularity run --cleanenv -B /projects/:/projects/\
    -B ${WORK_DIR}:/quest_scratch \
    /projects/singularity_images/fmriprep-21.0.2.simg \
    ${BIDS_DIR} \
    ${BIDS_DIR}/${DERIVS_DIR} \
    participant --participant-label ${subject} \
    -w /quest_scratch --omp-nthreads 8 --nthreads 16 \
    --fs-license-file /projects/singularity_images/freesurfer_license.txt \
    --fs-subjects-dir ${BIDS_DIR}/${DERIVS_DIR}/sourcedata/freesurfer \
    --output-spaces MNI152NLin6Asym:res-2 \
    --ignore slicetiming --fd-spike-threshold 0.2 --me-output-echos --resource-monitor

And here is an example where you can see the mismatch in the back of the brain, especially on the right hemisphere. The third image shows the boldref image on top of the T1 and the pial surface outline. no signal to be found.

Any idea why this is happening and how I can improve it?

[effigies]

The gray/white contrast in your BOLD is extremely low, so boundary-based registration has little to work with. If you can find some other way to register it and update the header, you can use --bold2t1w-init header --force-no-bbr to tell fMRIPrep not to attempt any registration.

[zachladwig]

thank you @effigies

I do have single band reference files for each echo which all seem to have at least decent gray/white contrast (much better than what is shown in the registration screen shot i included in the last post).

Does fmriprep use them? From the documentation it looks like it should but then I saw some posts that sbrefs aren’t used for multiecho data?

[effigies]

I believe so but can’t check right now. Multi echo has definitely changed since 21.0. Can you try with 23.1?

[zachladwig]

Hi @effigies

I tried it with 23.0.2 on a subset of sessions since we had that on our system already.

Registration looked a little better, but the contrast between gray/white matter in boldref images doesn’t look any better. What do you think?

How is it making these boldref images? The contrast is definitely much better in all the single band references I am passing in (at each echo)

[zachladwig]

Here is an example of the SBref (echo 3) versus the boldref image for the same run

[zachladwig]

Hi @effigies,

Just checking. Is your recommendation to register it elsewhere and then do fmriprep with --bold2t1w-init header --force-no-bbr?

[effigies]

Thanks for your patience. Yes, I think that is probably best. I looked at the code again, and we are using the sbrefs for the initial bold reference, which is used for head motion correction, but not for the final, which is used for coregistration. This needs fixing in an updated 23.2 series. That is unlikely to happen this month.

[jsein]

Interesting! On top of that, SBref images used as reference for HMC tend to bias the HMC parameters with the standard cost function used by mcflirt:

[mcflirt related behavour] FMRIPREP: Strange motion estimations in confounds_timeseries.tsv (lots of zeros)

Hi, thank you for the fantastic work with FMRIPREP. I just noticed something wrong in the output of FMRIPREP for a subject in a particular study: the motion parameters estimated by mcflirt are very strange, with a lot of zeros. Here is the content of the .par file calculated by FMRIPREP v 20.2.1, launched through a singularity image on a cluster. 0 -0 0 0 0 0 0 -0 0 0 0 0.00447239 0 -0 0 0 0 0 0 -0 0 0 0 0.0191925 0 -0 0 0 0 0.0628555 0 -0 0 0 0 0.01720…

[effigies]

Wow, either I missed this or forgot about it. Have you found any issues in using mutualinfo for BOLD runs without sbrefs?

It does seem that we should probably prefer just to motion correct to the first volume and register the first volume to the reference, regardless of whether we use mcflirt or 3dvolreg.

[jsein]

More details on this topic here:

[mcflirt related behaviour] Wrong motion parameters estimates in confounds_timeseries.tsv (lot of zeros!)

Discussion with FSL developpers here:
https://www.jiscmail.ac.uk/cgi-bin/wa-jisc.exe?A2=ind2101&L=FSL&D=0&X=5CD9DAA0225F506E17&Y=julien.sein%40univ-amu.fr&P=190219

Discussion on the HCPPipelines list here:

issue with mcflirt using SBref as reference when subject doesn't move

[jsein]

@effigies

It does seem that we should probably prefer just to motion correct to the first volume and register the first volume to the reference, regardless of whether we use mcflirt or 3dvolreg.

I agree, register to the first volume or to the average of the first 10 volumes as it is done I believe in the HCPPipelines.

[jsein]

@effigies

Have you found any issues in using mutualinfo for BOLD runs without sbrefs?

I don’t remember if there was any issue to use mutualinfo with mcflirt without SBref as a target for HMC. I will check back.

[zachladwig]

@effigies

ked at the code again, and we are using the sbrefs for the initial bold reference, which is used for head motion correction, but not for the final, which is used for coregistration. This needs fixing in an updated 23.2 series. That is unlikely to happen this month.

Hi @effigies thank you for this reply. If it is not using the sbref for registration, what is it using? The median volume?

[effigies]

We motion-correct and take the mean volume, then apply some bias-field correction.