Unexpected fmriprep upsampling using MNI152NLin2009cAsym

1

Hello,

I’m getting some unexpected behavior with the resolution of my processed data. Specifically, I’m expecting it to stay in native space, but it’s getting resampled to a 2mm resolution. I’m running fmriprep 20.0.7 through singularity.

I’m specifying output-spaces to be --output-spaces fsaverage:den-10k MNI152NLin2009cAsym MNI152NLin6Asym:res-2:

singularity run --cleanenv $SIMG \
        $project/data/ \
        $project/derived/ \
        participant \
        --nthreads 5 \
        --mem_mb 65536 \
        --fs-license-file $project/extra/license.txt \
        --fs-subjects-dir $project/derived/freesurfer \
        --participant-label $subject \
        -w $project/work \
        --skull-strip-fixed-seed \
        --bold2t1w-dof 9 \
        --dummy-scans 10 \
        --output-spaces fsaverage:den-10k MNI152NLin2009cAsym MNI152NLin6Asym:res-2 \
        --cifti-output

My understanding is that without any specifier, the MNI152NLin2009cAsym output should remain in the same resolution as the input data, based on the spaces documentation (https://fmriprep.readthedocs.io/en/latest/spaces.html). However, it’s getting upsampled from 2.4^3mm to 2^3mm data.

Original data:

> fslinfo sub-GLS003_ses-1_task-graphlearning_run-1_bold.nii.gz
data_type      INT16
dim1           90
dim2           90
dim3           60
dim4           736
datatype       4
pixdim1        2.400000
pixdim2        2.400000
pixdim3        2.400000
pixdim4        0.800000
cal_max        0.0000
cal_min        0.0000
file_type      NIFTI-1+

fmriprep output:

> fslinfo sub-GLS003_ses-1_task-graphlearning_run-1_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz
data_type      INT16
dim1           97
dim2           115
dim3           97
dim4           736
datatype       4
pixdim1        2.000000
pixdim2        2.000000
pixdim3        2.000000
pixdim4        0.800000
cal_max        1698.2057
cal_min        -102.4300
file_type      NIFTI-1+

Any clarification on why this is happening would be appreciated!

2

Hi @ariekahn,

You are correct - the 20.0.x series of fMRIPrep revised how spatial references were handled within the software, and changed the default behavior (originally brought to attention in https://github.com/poldracklab/fmriprep/issues/2060). You should still be able to generate output data in the native resolution of the BOLD data, but you’ll have to append the :res-native to the desired output space.

A new minor version will be released next week reverting the default behavior (no specifier defaulting to native BOLD resolution).

2 Likes