Fmriprep preproc bold images have different dimensions between subjects

Hello - We are preprocessing a bunch of images from the UKBioBank dataset through fmriprep. I have a subset of subjects processed through 20.2.0 and 21.0.2 - my issue below is applicable to both versions.

In looking at the space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz images, there are different dimensions between subjects. However, within subject but between version the dimensions are the same. For example:

sub-01 old: (82, 97, 79, 490)
sub-01 new: (82, 97, 79, 490)
sub-02 old: (82, 97, 81, 490)
sub-02 new: (82, 97, 81, 490)
sub-03 old: (82, 97, 83, 490)
sub-03 new: (82, 97, 83, 490)
sub-04 old: (81, 97, 82, 490)
sub-04 new: (81, 97, 82, 490)

Where “old” and “new” just refer to the different fmriprep versions. However, when I look at task-rest_space-MNI152NLin6Asym_desc-smoothAROMAnonaggr_bold.nii.gz they are all the same dimensions (91, 101, 91, 490).

The raw images are all the same dimensions (88, 88, 64, 490).

I have some subjects from the ABIDE dataset also processed with both fmriprep versions and this discrepancy is not there, even though all subjects were processed using the same fmriprep command:

singularity run --cleanenv                                                      \
	-B ${TEMPLATEFLOW_HOST_HOME}:${SINGULARITYENV_TEMPLATEFLOW_HOME}            \
	-B ${TMPDIR}/in:/in                                                         \
	-B ${TMPDIR}/out:/out                                                       \
	-B ${TMPDIR}/wrk:/wrk                                                       \
	${container} /in /out/${s} participant                                      \
	--participant_label ${s}                                                    \
	-w /wrk/${s}                                                                \
	--nthreads 10                                                               \
	--mem_mb 48000                                                              \
	--fs-license-file ${license}                                                \
	--output-spaces fsaverage6 fsLR MNI152NLin2009cAsym                         \
	--cifti-output                                                              \
	--skip-bids-validation                                                      \
	--notrack                                                                   \
	--use-aroma                                                                 \
	--error-on-aroma-warnings

What would cause this dimension discrepancy?
Thanks in advance.

Hi Dustin,

Form what I recall, space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz are in native resolution, unless otherwise specified. My assumption would be that the AROMA outputs are in 2x2x2, since that’s the template they need to be normalized to for AROMA. While the input files have the same dimensionality, is there any chance they have different resolutions? That might explain the shape differences.

Hi Taylor,

To see the dimensions I was just using .shape on the image loaded using nilearn.image.load_img.
When I look at the input data in this way, they all have the same dimensions (88, 88, 64, 490).

However, I just looked at a couple of the input images using 3dinfo and it appears that they are in different orientations. For example:

Data Axes Tilt:  Oblique (39.609 deg. from plumb)
Data Axes Approximate Orientation:
  first  (x) = Right-to-Left
  second (y) = Inferior-to-Superior
  third  (z) = Anterior-to-Posterior   [-orient RIA]
R-to-L extent:  -111.669 [R] -to-    95.945 [L] -step-     2.386 mm [ 88 voxels]
A-to-P extent:    47.245 [P] -to-   198.445 [P] -step-     2.400 mm [ 64 voxels]
I-to-S extent:  -102.441 [I] -to-   105.172 [S] -step-     2.386 mm [ 88 voxels]
Number of time steps = 490  Time step = 0.73500s  Origin = 0.00000s

and

Data Axes Tilt:  Oblique (8.596 deg. from plumb)
Data Axes Approximate Orientation:
  first  (x) = Anterior-to-Posterior
  second (y) = Inferior-to-Superior
  third  (z) = Right-to-Left   [-orient AIR]
R-to-L extent:   -69.389 [R] -to-    81.811 [L] -step-     2.400 mm [ 64 voxels]
A-to-P extent:  -107.481 [A] -to-   100.132 [P] -step-     2.386 mm [ 88 voxels]
I-to-S extent:  -148.101 [I] -to-    59.513 [S] -step-     2.386 mm [ 88 voxels]
Number of time steps = 490  Time step = 0.73500s  Origin = 0.00000s

Would this explain the difference? The fmriprep outputs are all in the same orientation. I guess I naively assumed that fmriprep would take input orientation into account and make sure the data were transformed in a uniform way before processing.

I hadn’t even considered orientation! :thinking: I think that could explain the differences though… If the voxel sizes and fields of view are the same, but the orientations are different, then when the orientation is standardized by fMRIPrep, there could be small differences in the resulting matrices, right? I don’t think there’s a way to standardize different orientations in a uniform way, unless you completely remove any voxels on the edge of the matrix. I could be misunderstanding the process though.

TBH, I was definitely hoping it would just be voxel size differences driving things- I haven’t dealt with orientation differences much.

1 Like

Thanks for your help!

Now I’m more concerned with orientation heterogeneity in UKBB than the differences in fmriprep outputs…

Just to update this thread because my original question has not been answered yet:

Why might my space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz images be different dimensions when the input images are the same dimension? And, why are the output dimensions different from the raw image?

Yes, some of the images are different orientations. But when only looking at subjects with the same orientation I’m seeing difference output dimensions.

For example:
Raw image dimensions: (88, 88, 64, 490)
Raw image orientation: (‘L’, ‘A’, ‘S’)

sub-01_task-rest_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz dimensions:
(82, 97, 81, 490)

sub-02_task-rest_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz dimensions:
(82, 97, 74, 490)

A majority of the subjects have (82, 97, 81, 490), but (82, 97, 74, 490) is not the only variant. Again, this behavior is occurring with both fmriprep 20.2.0 and 21.0.2

I also noticed this in my own fmriprep’d dataset a couple of days ago when I was about to do a 2nd level analysis using nilearn and I got an error message saying that they weren’t all the same FOV; some of my data had slight affine/shape differences - in my case I had a few subjects who had slight affine difference and ±1 shape differences in the first and third dimension.

I was also using MNI152NLin2009cAsym and fmriprep 20.2.7; voxel sizes were all the same between them.

In the end I iterated through all my 1st level images and used nilearn.image.resample_to_img to resample to the dimension and orientation of my first image…

1 Like