fMRIPrep 25.1.0: possible to increase output bounding box?

edited 22 Sept to add requested details. I don’t see the smaller bounding box as a bug or error (I’m guessing it could be related to the changes in fieldmap processing between the fmriprep versions); this is more of a feature query.

Summary of what happened:

Is there an option for increasing the size of the bounding box used in the fMRIPrep 25.1.0 derivatives? Another way to describe this might be that I’d like to reduce the amount of clipping around the brain; I’m not sure how exactly to describe what I’m looking for, so there’s a picture below.

These are the derivatives _space-MNI152NLin2009cAsym_desc-brain_mask.nii.gz images for the same _bold run and participant, after preprocessing with fMRIPrep 20.2.7 (left) and 25.1.0 (right). The derivatives vary, of course, given all the updates between the fMRIPrep versions, but are looking pretty reasonable so far.

My question is about the change in output image size from 81 x 96 x 81 with 20.2.7 to 65 x 80 x 68 with 25.1.0: the surround is cropped out more in the new version. Is it possible to specify the old-style, less-aggressive cropping, or bounding box dimensions in general?

(The voxel size, template alignment, etc. are fine in the derivatives; the brain is included. But the area around the brain can be useful for evaluating multiband artifacts, etc., so I’d like to retain it as well.)

Thank you!

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

SUBID=SCW
LOGGINGTIMESTAMP() { date -Ins; }
CURRENTCPUUSE() { echo $[100-$(vmstat 1 2|tail -1|awk '{print $15}')]; }
FREESPACEINCURRENTDIR() { printf '%s\n' $(df -BG -P . | tail -1 | awk '{print $4}' | sed s'/G$//'); }
PRIMARY_WORKING_DIR="/scratch2/JoEtzel/test/"
pushd ${PRIMARY_WORKING_DIR}
mkdir -p ${PRIMARY_WORKING_DIR}${SUBID}/.license/freesurfer/
cp /scratch2/license.txt ${PRIMARY_WORKING_DIR}${SUBID}/.license/freesurfer/license.txt

singularity run --cleanenv -B \
${PRIMARY_WORKING_DIR}${SUBID}:/tmp \
/data/nil-bluearc/ccp-hcp/SingularityImages/fmriprep-25.1.0.simg \
--fs-license-file /tmp/.license/freesurfer/license.txt \
-w /tmp /tmp/BIDS /tmp/derivatives \
participant --participant_label ${SUBID} \
--output-spaces fsaverage5 MNI152NLin2009cAsym \
--n-cpus 16 \
--omp-nthreads 4 \
--mem-mb 64000 -v >> ${PRIMARY_WORKING_DIR}${SUBID}/${SUBID}_fmriprep_singularity_VOLSURF.txt 2>&1

Version:

20.2.7 and 25.1.0

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

Singularity.

Data formatted according to a validatable standard? Please provide the output of the validator:

You are using fMRIPrep-25.1.0, and a newer version of fMRIPrep is available: 25.1.4.
Please check out our documentation about how and when to upgrade:
https://fmriprep.readthedocs.io/en/latest/faq.html#upgrading
250915-17:00:23,744 cli INFO:
	 Telemetry system to collect crashes and errors is enabled - thanks for your feedback!. Use option ``--notrack`` to opt out.
250915-17:00:31,537 cli INFO:
	 Making sure the input data is BIDS compliant (warnings can be ignored in most cases).
bids-validator@1.14.10
e[32mThis dataset appears to be BIDS compatible.e[39m
        e[34me[4mSummary:e[24me[39m                e[34me[4mAvailable Tasks:e[24me[39m        e[34me[4mAvailable Modalities:e[39me[24m 
        26 Files, 1.52GB        StroopBas               MRI                   
        1 - Subject             StroopPro                                     
        1 - Session                                                           

Relevant log outputs (up to 20 lines):

PASTE LOG OUTPUT HERE

Screenshots / relevant information:


Hi Jo,

The bounding box isn’t directly configurable. I have vague memories (that I don’t have the time at the moment to substantiate by looking through the pull request history) that we reduced the bounding box a few years ago, probably in an effort to reduce the size of derivatives.

IIRC you get a different bounding box if you use an MNI152NLin2009cAsym:res-2 vs MNI152NLin2009cAsym:res-native (default).

You almost need a mini-language to let people do the final resampling how they want, which makes me feel like the final form of this will probably just be a little resampling tool that implements all the options someone could want.

1 Like

That’s what I suspected, thanks! (Asking this sort of question probably puts me in with the people who ask clerks if there’s “one in the back” after not seeing the size they want on the rack. :sweat_smile:)

This probably wouldn’t be addressed by the hypothetical tool, though: the brain is the resolution and shape I wanted, but some of the surrounding space is omitted; resampling won’t restore the data (artifacts/ghosts/etc.) in those lost voxels.

Looking at the pair of boldref images again, it looks like fMRIPrep 25.1.0 (right) trimmed the output box to more-or-less the first complete plane from the top (1,1 at right is 9,9 at left; 8 rows/columns omitted):

Sorry, I meant a tool that would reuse the transforms but go back to the source data to perform the resampling. There’s something of the sort here: GitHub - nipreps/resampler: Single-shot resampling utility for nipreps derivatives, but it’s free-as-in-puppy software.

1 Like