Failed normalization of BOLD into MNI space

[ChristianNSchmitz]

Dear niprep-team,
we've stumbled accross poor MNI normalizations for our functional images (see images below) using fMRIPrep versions 20.1.1 on docker. This bug seems to be quite similar to #2307

You can find example images attached:

What version of fMRIPrep are you using?

Version 20.1.1

What kind of installation are you using? Containers (Singularity, Docker), or "bare-metal"?

Docker

What is the exact command-line you used?

fmriprep-docker  ${basefolder}/rawdata ${basefolder}/derivates/fmriprep-preprocessing/ --fs-license-file/home/.licenses/freesurfer/license.txt

Have you checked that your inputs are BIDS valid?

Yes, using bids-validator

Did fMRIPrep generate the visual report for this particular subject? If yes, could you share it?

Shared with nipreps@gmail.com on my Google Drive under 'fMRIPrep'

Can you find some traces of the error reported in the visual report (at the bottom) or in crashfiles?

fMRIPrep finished without any errors but produced a poor MNI normalization of functional images. However, structural images are normalized correctly.

Are you reusing previously computed results (e.g., FreeSurfer, Anatomical derivatives, work directory of previous run)?

No.

fMRIPrep log

If you have access to the output logged by fMRIPrep, please make sure to attach it as a text file to this issue.

fmriprepLog.txt

[julfou81]

Hi, I got similar issues for some subjects. Did you check how is the registration from the functional space to the T1w image? You can look at it from the temporary files generated by nipype or directly by asking fmriprep to get output in the T1w space in addition to the MNI space (--output-spaces T1w MNI152NLin2009cAsym).
If the normalization of the anatomical image is fine, most probably it is the registration from bold to T1w that performed poorly. You may try other options: either run without FreeSurfer (--fs-noreconall), which means that flirt will be used instead of bbregister for the bold-to-T1w registration. You can also play with --bold2t1w-init, --bold2t1w-dof , --force-bbr options to see if the registration improves. Also you may want to check which reference image is used for the bold space (do you have bref image in your dataset (produced from the multi band sequence)?

[ChristianNSchmitz]

Hey, thank you very much for the quick reply!
If I'm asking fmriprep to get output in the T1w space in addition to the MNI space (--output-spaces T1w MNI152NLin2009cAsym fmriprep crashes (you can see the log-file attached). Playing with --bold2t1w-init, --bold2t1w-dof , --force-bbr options didn't improve the normalization.
Running fmriprep with FreeSurfer (--fs-noreconall) improved the normalization slightly but was still far off.
We have no specified a boldref image in the dataset but fmriprep-derived boldref image was equally distorted compared to the bold-derivatives.
Do you have any other idea how to improve the normalization?
Thank you very much for your support!
Best, Christian

crash-20210411-151153-root-autorecon2_vol-67b85c1c-9a7f-47e6-a226-302b3b3a27d5.txt

[julfou81]

Hi,

your error log looks like a FreeSurfer error, which may or may not be related to your normalisation issue.
It is not normal that asking for T1w as an output space produces an error. What kind of distorsion correction is attempted on your data? Do you have a fieldmap or a pair of epi scans with opposite phase encoding directions in the map/ folder?

[ChristianNSchmitz]

Hey, we use a fieldmap in the map-directory.

[julfou81]

Maybe there is a problem in the T1w brain masking procedure. Did you see anything wrong with the brainmask of the T1w image?

[ChristianNSchmitz]

The brainmask of the T1w looks perfectly normal. The bainmask of the BOLD-image, however, is totally distorted.
What is more: the html-ouput shows anatomical and functional images that are not distorted and look perfectly fine.

[julfou81]

The thing with the brain mask is logic and reflects that the normalisation of the bold images failed along the way. It discards the fact that the bold-2-T1w registration may have failed due to a poor T1w brain masked image. You should look at the temporary files generated by fmriprep to see at which stage the normalization process went wrong.
You mean that the HTML report looks totally normal?
Also I see a warning in red on the bottom right of your FSLeyes screenshots, what does it says?

[ChristianNSchmitz]

My system has deleted the /tmp directory automatically, I will rerun the analysis and let you know.

"You mean that the HTML report looks totally normal?" Exactly!

The wanring in FSLeyes tells "Displaying images with different orientation/fields of view!"

[julfou81]

Don't forget the option:
"-w, --work-dir
path where intermediate results should be stored"

to be sure to save the intermediate results.

[ChristianNSchmitz]

Hey,
thanks a lot for your help!
The intermediate results of the anatomical preprocessing are looking fine. Both the output of the last notes of init_anat_preproc_wf() and of the ANTs implementation for brain extraction looks solid.

However, the distortion can be seen in the bold_std_trans_wf node. Both t1w_brain and final_boldref_wf look fine. bold reg_reg_wf doesn't store any *.nii file in the respective directory.
I traced the mistake according to this workflow:
https://fmriprep.org/en/latest/workflows-5.png

There is a second thing, that might be of interest: As our MPRAGE has a size of >256mm we have to reduce the size of the image in using fsl in bash:
fslroi sub-006_ses-01_run-01_T1w.nii.gz sub-006_ses-01_run-01_T1w_fsl-fovsplit.nii.gz -1 192 15 568 -1 512

[julfou81]

Hi,

Could you check bold_to_t1w_transform/bold_to_t1w_transform and the look of the bold volumes in there? These are bold volumes in the T1w space after linear registration.
Also why do you reduce the size of the image T1w? Is it something you have to do for fmriprep? I was not aware of that limit. This is indeed something that may somehow interact in the processing. What do you give to fmriprep? Do you rename sub-006_ses-01_run-01_T1w_fsl-fovsplit.nii.gzin sub-006_ses-01_run-01_T1w.nii.gz?

[ChristianNSchmitz]

Hey, thanks for all the help!
the bold volumes in bold_to_t1w_transform/bold_to_t1w_transform look slightly off (you can see the screenshot attached with the bold in red).

If the FOV of the image is >256mm on one axis, I get an error like this:
https://neurostars.org/t/fmriprep-1-5-5-fails-on-freesurfer-call-error-fov-282-000-256/5836
or that
https://github.com/nipreps/smriprep/issues/29
We have to reduce the size of the image, otherwise it gives us a freesurfer-error (you can see a crash-report attached)
[crash-20210506-152622-root-autorecon1-fe3e4166-9c3f-41c0-b1ff-018523b32a5a.txt]
. Yes, I do rename the file in sub-006_ses-01_run-01_T1w.nii.gz

(https://github.com/nipreps/fmriprep/files/6469608/crash-20210506-152622-root-autorecon1-fe3e4166-9c3f-41c0-b1ff-018523b32a5a.txt)

[ChristianNSchmitz]

Hey, we changed the FOV of the T1w-image and, thus, didn't have to crop the image. However, the normalization-results looked identical.

[christianparet]

Hi nipreps-team,

We observe failed normalization of BOLD images into MNI space, very similar to Christian who started this thread (actually, he pointed us to look after it, many thanks!). The fmriprep htmls look also good. Using an external viewer however, where we overlay the subject's structural in MNI space with the normalized BOLD image shows similar deviation as in Christian's images.

The problem appears with fMRIPrep 20.2.0, while normalization worked clearly better with version 20.0.6 (see image below).

The fmriprep.toml file and the html output is provided via my googledrive: https://drive.google.com/drive/folders/1SzL-8SKPj1NHv-JMJt5NzS7VtgWRa12Q?usp=sharing

Code to execute fmriprep:
sudo docker run --rm -it -e DOCKER_VERSION_8395080871=19.03.6 -v ${basefolder}/dataset:/data:ro -v ${basefolder}/derivatives:/out -v /home/christian.paret/freesurfer/license.txt:/opt/freesurfer/license.txt poldracklab/fmriprep:20.2.0 /data /out/fmriprep-20.2.0 participant

[oesteban]

Probably duplicate of #2307 and #2410

[oesteban]

@ChristianNSchmitz and @julfou81 please confirm this issue has been resolved in the latest two releases (20.1.4 and 20.2.2, depending on the series you are locked in) and reopen if necessary.

Further conversation can be centralized #2451 and #2452 if it is not to inform that this bug has not been resolved on your data.