Output Space with Different Dimension Sizes

Summary of what happened:

I hope you’re doing well! We’re wrapping up our MRI preprocessing for a study I’m helping on and we just noticed something off about certain output spaces. It appears weirdly our subjects output into MNI152NLin6Asym space have two different sizes they could be output into, either (61, 73, 61) or (52, 64, 54), which doesn’t seem to play well with some of our analysis scripts. The other output spaces we’re having fMRIPrep output into are MNIPediatricAsym which appears to consistently output into this shape (99, 117, 95) for all subjects. Is it normal for the output space to come in two differently shaped dimensions?

Command used (and if a helper script was used, a link to the helper script or the command generated):

pre-bsub call

#!/bin/sh


# ----------- System Environment Variables-------------- #

# Grab passed in subject
export SUBJECT=$1

# Define storage allocations areas of interest
export STORAGE_ALLOCATION=/storage1/fs1/perlmansusan/Active/
export BIDS_DIR=${STORAGE_ALLOCATION}moochie/analysis/CARE/ME_MRI_data/
export SCRATCH_DIR=${STORAGE_ALLOCATION}moochie/analysis/CARE/ME_scratch/
export OUTPUT_DIR=${STORAGE_ALLOCATION}moochie/analysis/CARE/MRI_data/derivatives/fmriprep/
export LICENSE_DIR=${STORAGE_ALLOCATION}moochie/github/LCBDtools/scripts/MRI/fmriprep/

export LSF_DOCKER_VOLUMES="/storage1/fs1/perlmansusan/Active:/storage1/fs1/perlmansusan/Active /scratch1/fs1/perlmansusan:/scratch1/fs1/perlmansusan ${BIDS_DIR}:/input ${OUTPUT_DIR}:/output ${LICENSE_DIR}:/freesurfer /home/$USER:/home/$USER"

# Alter the fMRIprep entry point to be /bin/bash so it cooperated with bsub and fMRIprep
# is not automatically called upon entering the docker image without options.
export LSF_DOCKER_ENTRYPOINT=/bin/bash

# Potentially unimportant variable, used to make sure the environmental variables 
# in the current shell transfer to the docker image being loaded but does not appear
# to work.
export LSF_DOCKER_PRESERVE_ENVIRONMENT=true

# -------------- fMRIPrep Environmental Variables -------- #
# This section is used to set the fMRIprep environmental variables based off 
# nipreps/fmriprep:23.0.2. Normally this wouldn't be necessary when running 
# fmriprep on docker but due to RIS's environment all environmental variables
# are wiped when we load the docker image. This is all based off of fMRIprep's
# Dockerfile where they set ENV variables.
#
# NOTE: If fMRIprep stops working when updating to a new version, it could be
# due to one of these environmental variables changing or a new variable being added.
# Consider looking at the newer fMRIprep Dockerfile and comparing the ENV variables 
# set to environmental variables listed below.

export FREESURFER_HOME="/opt/freesurfer/bin/"
export PATH="$FREESURFER_HOME:$PATH"

export MAMBA_ROOT_PREFIX="/opt/conda"

export PATH="/opt/conda/envs/fmriprep/bin:$PATH" 
export UV_USE_IO_URING=0

export DEBIAN_FRONTEND="noninteractive" 
export LANG="en_US.UTF-8" 
export LC_ALL="en_US.UTF-8"

export OS="Linux" 
export FS_OVERRIDE=0 
export FIX_VERTEX_AREA="" 
export FSF_OUTPUT_FORMAT="nii.gz" 
export FREESURFER_HOME="/opt/freesurfer"

export SUBJECTS_DIR="$FREESURFER_HOME/subjects" 
export FUNCTIONALS_DIR="$FREESURFER_HOME/sessions" 
export MNI_DIR="$FREESURFER_HOME/mni" 
export LOCAL_DIR="$FREESURFER_HOME/local" 
export MINC_BIN_DIR="$FREESURFER_HOME/mni/bin" 
export MINC_LIB_DIR="$FREESURFER_HOME/mni/lib" 
export MNI_DATAPATH="$FREESURFER_HOME/mni/data"

export PERL5LIB="$MINC_LIB_DIR/perl5/5.8.5" 
export MNI_PERL5LIB="$MINC_LIB_DIR/perl5/5.8.5" 
export PATH="$FREESURFER_HOME/bin:$FREESURFER_HOME/tktools:$MINC_BIN_DIR:$PATH"

export PATH="/opt/afni-latest:$PATH"
export AFNI_IMSAVE_WARNINGS="NO" 
export AFNI_PLUGINPATH="/opt/afni-latest"

export MAMBA_ROOT_PREFIX="/opt/conda"

export PATH="/opt/conda/envs/fmriprep/bin:$PATH" 
export CPATH="/opt/conda/envs/fmriprep/include:$CPATH" 
export LD_LIBRARY_PATH="/opt/conda/envs/fmriprep/lib:$LD_LIBRARY_PATH"

export MKL_NUM_THREADS=1
export OMP_NUM_THREADS=1

export LANG="C.UTF-8" 
export LC_ALL="C.UTF-8" 
export PYTHONNOUSERSITE=1 
export FSLDIR="/opt/conda/envs/fmriprep" 
export FSLOUTPUTTYPE="NIFTI_GZ" 
export FSLMULTIFILEQUIT="TRUE" 
export FSLLOCKDIR=""
export FSLMACHINELIST=""
export FSLREMOTECALL=""
export FSLGECUDAQ="cuda.q"

export IS_DOCKER_8395080871=1

export PATH="/opt/workbench/bin_linux64:$PATH"
export LD_LIBRARY_PATH="/opt/workbench/lib_linux64:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH"

export PATH="/usr/bin/c3d_affine_tool:$PATH"

export HOME="/scratch1/fs1/perlmansusan"

# -------- Call to bsub to run the bsub file ------------ #

bsub -J $SUBJECT-fmriprep-traditional -oo logs/fmriprep/$SUBJECT-fmriprep-traditional.log -g /$USER/preprocessing < fmriprep_bsub_traditional.sh

bsub file

#!/bin/sh 
#BSUB -G compute-perlmansusan
#BSUB -q general
#BSUB -m general
#BSUB -a 'docker(nipreps/fmriprep:latest)'
#BSUB -n 16
#BSUB -R 'rusage[mem=26GB] select[mem>25000 && tmp>250]'

cd /tmp/$JOBID.tmpdir

mkdir /tmp/$JOBID.tmpdir/scratch
mkdir /tmp/$JOBID.tmpdir/output

/opt/conda/envs/fmriprep/bin/fmriprep /input /tmp/$JOBID.tmpdir/output participant --participant-label sub-$SUBJECT -w /tmp/$JOBID.tmpdir/scratch --fs-license-file /freesurfer/license.txt --output-spaces MNI152NLin6Asym MNI152NLin2009cAsym MNIPediatricAsym:cohort-2:res-2 --n_cpus 16 --mem 24 --low-mem --skip-bids-validation

cp -r /tmp/$JOBID.tmpdir/output/. /output/

for file in `find /output/ -name *$SUBJECT*.gz` ; do
    gzip -d $file
done

Version:

Environment (Docker, Singularity / Apptainer, custom installation):

Run on docker through LSF_Spectrum bsub

Relevant log outputs (up to 20 lines):

No error’s reported in relavent logs

Screenshots / relevant information:


Hi @DennyS,

Do the input images that result in different output resolutions have different dimensions? What if you specify a res-X modifier?

Best,
Steven

Hey Steven, thanks for your help! Interestingly between the subjects with different shaped output spaces their raw unprocessed bold files both have the same dimension shapes of (68, 68, 40). Also the MNIPediatricAsym outputs, that all are consistent shape, have the res-2 cohort-2 flag, sorry forgot to mention

We’re also outputting in MNI152NLin2009cAsym space and it looks like they also are outputting in different shapes, either (65, 77, 65) or (53, 65, 56), not sure if that helps or not

What if you specify a res flag for those other MNI spaces? Would that work for your analyses?

I can definitely try it out and let you know what happens! I would just adjust the --output-spaces tag to this right?

--output-spaces MNI152NLin6Asym:res-2

Yah that should work, as long as that is the resolution modifier you want.

Hey Steven, looks like the job just finished up and it appears this resolves the issue! The new output is consistently (97, 115, 97). Bit of an odd issue to be honest because I could have sworn we actually tried to run it with the res-2 tag for MNI152NLin2009cAsym/MNI152NLin6Asym on an older version of fMRIprep but it would throw an error. Out of curiosity why would fMRIPrep opt to use two different resolutions for a dataset that’s all collected on the same scanner and setup?

Also is it possible to change the resolution for the images we’ve already produced without rerunning fMRIPrep? We’ve got ~200 subjects with up to 3 sessions each that would be a bit of a pain to rerun, especially since we’re coming up on a renewal for the study. Sadly we did not keep the work folder since we’re already hovering at 30 TB of derivatives for this one study without them :sweat_smile:

Hi @DennyS,

Happy it worked!

fMRIPrep tries to preserve native spacing if a res-x modifier is not used. Perhaps their are subtle differences in the field of view between the different images? I am not sure I can give you a definitive answer without having the data in front of me.

It is possible to just regrid the images to the MNI res-X template image after the fact, but ideally it would happen in the scope of fmriprep since all of the interpolation and regridding happens in a single-shot which reduces interpolation. Perhaps by playing around with the --level and --derivatives arguments you can reuse some of your preexisting data and eliminate some redundancies and processing needs. I am not very familiar with their usage though.

Best,
Steven