Inconsistent output grid in fmriprep

1

Hello,

I have a dataset that has been preprocessed using fmriprep 1.5.1rc1 as recommended in this thread, however, I’m running into an issue where my preprocessed data seem to be on different grids. I have many subjects (20), sessions (151), tasks, and runs (226) and I cannot find a pattern as to which runs are on which grid size.

All the data were acquired on a 96 x 96 x 31 grid with a voxel size of 2.083 x 2.083 x 4.4mm.

It seems as though I have 2 possible output grids, and, while the dimensions are different, it seems like the voxel sizes were preserved in some way.

88 x 51 x 88 with a voxel size of 2.083 x 4.400 x 2.083 or
88 x 106 x 43 with a voxel size of 2.083 x 2.083 x 4.400.

I have not systematically analyzed all grids for all runs, but I’m working on that now. It does seem like the latter output size is more common than the former. Does anyone have ideas as to why these output grids are different, though? Shouldn’t all output grids be the same if the input grids are identical?

A couple other points:

  • All of the runs within a session seem to be on the same grid
  • However, sometimes not all sessions per subject are on the same grid
  • I’m using space-MNI152NLin6Asym_desc-preproc_bold.nii.gz files

Here is the fmriprep command I used:

export TMPDIR=/lscratch/$SLURM_JOB_ID &&

export SINGULARITY_BINDPATH=/gs3,/gs4,/gs5,/gs6,/gs7,/gs8,/gs9,/gs10,/gs11,/spin1,/scratch,/fdb,/data,/lscratch &&    
export SINGULARITYENV_TEMPLATEFLOW_HOME=/home/fmriprep/.cache/templateflow &&     
mkdir -p $TMPDIR/wrk/sub-P03 &&     

singularity run --cleanenv
-B /home/dmoracze/.cache:/home/fmriprep/.cache
/data/DSST/containers/fmriprep-1.5.0.simg /data/dmoracze/rawdata
/data/DSST/KRNS/bids/derivatives/fmriprep-1.5.0
participant --participant_label sub-P03
-w /lscratch/$SLURM_JOB_ID/wrk/sub-P03
--nthreads 12 --omp-nthreads 8 --mem_mb 30
--fs-license-file /home/dmoracze/license.txt
--output-spaces func fsaverage6 MNI152NLin6Asym 
--use-aroma --error-on-aroma-warnings
2

Does anyone have any ideas about this issue? Perhaps I should re-run fmriprep?

3

Hi @dmoracze,

I don’t have any strong thoughts here except trying to clear the working directory (and perhaps the freesurfer directory for this participant) and try again, and/or update your installation of fmriprep to 1.5.8 (the latest release) and try running fmriprep again. If that does not work, I’ll cc some other people that could have a better idea of what’s going on.

Best,
James

4

Yeah that makes sense to try, thanks!

5

I tried reprocessing my data using fmriprep 1.5.8 and I receive exactly the same output.

Does anyone know what could possible explain the fact that I’m getting different output dimensions for some different session when the input dimensions are all exactly the same?

Here is my 1.5.8 fmriprep command (very similar to above, I just added another output space:

export TMPDIR=/lscratch/$SLURM_JOB_ID &&

export SINGULARITY_BINDPATH=/gs3,/gs4,/gs5,/gs6,/gs7,/gs8,/gs9,/gs10,/gs11,/spin1,/scratch,/fdb,/data,/lscratch &&    
mkdir -p $TMPDIR/out &&     

singularity run --cleanenv
/data/DSST/containers/fmriprep-1.5.8.simg /data/dmoracze/rawdata
/data/DSST/KRNS/bids/derivatives/fmriprep-1.5.8
participant --participant_label sub-P03
-w /lscratch/$SLURM_JOB_ID/wrk
--nthreads 12 --omp-nthreads 8 --mem_mb 30
--fs-license-file /home/dmoracze/license.txt
--output-spaces func fsaverage6 MNI152NLin6Asym MNI152NLin2009cAsym 
--use-aroma --error-on-aroma-warnings
6

From what you report, my best guesss would be that some of your data appear to have been acquired coronally and some axially. fMRIPrep will output all data in RAS+ orientation, so if they started in LIA (as an example), then the 4mm dimension will be rolled to the second dimension.

You can check the orientation of your input images with fslhd, mri_info or similar.

1 Like
7

@effigies yeah, you’re right. I was just looking at the overall dimensions. The dimensions are the same but the orientations are different. Thanks for the help!

1 Like