fmriprep: Failed resampling of BOLD into MNI space - starting with v20.1.1

We are getting poor MNI normalizations (see images below) using fMRIPrep versions 20.1.1 and 20.2.0 LTS. We had good normalizations with version 20.0.6. I have not tested any other versions.

What version of fMRIPrep are you using?

versions 20.2.0 LTS and 20.1.1

Top image is example of expected normalization in SPM12, middle image is the normalization obtained using fMRIPrep v20.1.1 (similar issues with v20.2.0), bottom image is normalization obtained using fMRIPrep v20.0.6 (no issues).

UCLA_good UCLA_bad UCLA_good_using_20 0 6

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

Singularity

What is the exact command-line you used?

singularity run --cleanenv ${FMRIPREP}/fmriprep-20.1.1.simg \
	${basefolder}/${projectname}/ ${basefolder}/${projectname}/derivatives \
	--fs-license-file $HOME/freesurfer6.txt \
	-w ${basefolder}/work \
	--nthreads 2 \
	participant \
	--participant-label ${subjid} 

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

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

In the last run (using v20,2,0) I used prior Freesurfer and work output files, but in past runs, I cleared both the Freesurfer derivatives and work directories before running.

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.

fmriprep.o1057033.txt

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 49 (30 by maintainers)

Commits related to this issue

Most upvoted comments

Hi, we processed a few commonly used datasets, and after we saw the warning for version 20.2.0, I went back to check how many subjects were affected. So, I am posting the information below as it might be useful for others. All the information is for resting state fMRI only.

	affected  / number of subjects on dataset
ukb      38703    / 38703
pnc        0      / 1394
hcp       951     / 1080
cobre     177     / 177
fbirn II   5      / 5

For the datasets that were affected, these are some statistics for their severity.

UKBIOBANK:

 Mean: 0.00518193539885735
 STD: 0.0016678250764811612
 Min: 4.714077218269039e-05
 Max: 0.0899535575234005

HCP

 Mean: 1.6014423472312408e-07
 STD: 1.2199390972215357e-07
 Min: 0.0
 Max: 8.087149296898133e-07

Cobre

 Mean: 0.3328491497572712
 STD: 0.09601558139962757
 Min: 0.09060217156461481
 Max: 0.5646974185071048

fbirn II

 Mean: 0.15869213891835365
 STD: 0.14207928970998107
 Min: 0.0020258594995189623
 Max: 0.3462542458014055

I hope it helps!

Generally, reusing within the same minor version should be okay

@effigies I don’t have an affected file with a severity of 0.0, sorry if what I posted was unclear! I was trying to check for any way my dataset might have been affected despite not seeing any of the artifacts above.

And @CFGEIER --I changed the last 4 lines of the script to the below, which will print severity for each file and should work with earlier than 3.8 python, and saved it as saved_testing_script.py, then ran it using the loop below (hacky but it was the fastest way for me).

if __name__ == "__main__":
    for fname in sys.argv[1:]:
        affected, severity = test(nb.load(fname))
        print(f"{fname} has severity ({severity})")
        if affected:
            print(f"{fname} is affected ({severity})")

Loop:

for sub in `cat $subjectlist`
do
  scans=`find sub-${sub}/ses-01/func/ -iname "sub-${sub}_*_bold.nii.gz"`
  echo $scans
  python saved_testing_script.py $scans
done

Here’s a simple script to test:

#!/usr/bin/env python
import sys
import numpy as np
import nibabel as nb


def test(img):
    zooms = np.array([img.header.get_zooms()[:3]])
    A = img.affine[:3, :3]
    
    cosines = A / zooms
    diff = A - cosines * zooms.T

    return not np.allclose(diff, 0), np.max(np.abs(diff))


if __name__ == "__main__":
    for fname in sys.argv[1:]:
        affected, severity = test(nb.load(fname))
        if affected:
            print(f"{fname} is affected ({severity=})")

Anything below 1e-7 seems safe. Up to 1e-2 seems likely to be fine, but I’d check. Above that, I would not be surprised to see visible artifacts, but again would check.

You should be able to reuse working directories within a minor release series.

In principle it should be safe to reuse the working directory because the nipype graph has changed.

On Fri, Aug 20, 2021, 17:17 Dorota Jarecka @.***> wrote:

I have multiple images from abide studies that seems to be affected. I understand that I should use 20.2.3 and rerun my analysis, but it’s not clear to me if I can use anything from the previous work directory (run with fmriprep20.2.1)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/nipreps/fmriprep/issues/2307#issuecomment-902767845, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAESDRRNWFMDJKWYFQBMMI3T5ZWY5ANCNFSM4SVHCHNA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

Correct, that should be fine. Though I’d be interested in a file that showed both affected and a severity of 0. Could you share the first kilobyte of such a file?

Are you simply after a file with severity of 0.0, in which case I have examples of that from publicly accessible data? Or have misunderstood?

Correct, that should be fine. Though I’d be interested in a file that showed both affected and a severity of 0. Could you share the first kilobyte of such a file?