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).
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.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 49 (30 by maintainers)
Commits related to this issue
- MAINT: Add DS030 dataset, with clipped (55 timepoints) BOLD data This dataset is added to set the ground for testing the new reference calculation workflow (#601). Additionally, I will upload deriva... — committed to nipreps/niworkflows by oesteban 3 years ago
- MAINT: Add DS030 dataset, with clipped (55 timepoints) BOLD data This dataset is added to set the ground for testing the new reference calculation workflow (#601). Additionally, I will upload deriva... — committed to nipreps/niworkflows by oesteban 3 years ago
- FIX: Feed *NiTransforms* with LTAs of type RAS2RAS As reported by @eburkevt back in October 18, 2020, resampled BOLD time-series in standard spaces do not look good anymore. This PR uses FreeSurfer t... — committed to nipreps/fmriprep by oesteban 3 years ago
- FIX: Misinterpretation of voxel ordering in LTAs The structarray was used directly and the extra axis actually changed the order of operations when the direction cosines were scaled by the voxel size... — committed to nipy/nitransforms by oesteban 3 years ago
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.
For the datasets that were affected, these are some statistics for their severity.
UKBIOBANK:
HCP
Cobre
fbirn II
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).Loop:
Here’s a simple script to test:
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:
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?