fMRIPrep - significant increase of file size after "bold_std_trans_wf"

valwmr · February 4, 2022, 2:28pm

Hi everyone,

First of all, I am pretty new to analysis with fMRIPrep and hope that someone might be able to help me. I’m currently running fMRIPrep (20.2.6) on some resting- and task-state data from stroke patients, and I think the results generally look fine (no errors were reported). The problem is that the output XXXX_task-rest_space-MNI152NLin2009cAsym_res-1_desc-preproc_bold.nii.gz and also preproc task nifti files seem to have huge file size (>5 GB) after preprocessing. For example, the original resting file is about 400 MB and contains 450 volumes. After applying the transforms (see command.txt below) the single volume niftis increase from ~900 KB (subfolder “bold_split”) to ~25 MB (subfolder “bold_to_std_transform”). I have added two Nifti header examples for these changes (see below).
Afterwards, the merged bold file (“vol0000_xform-00000_merged.nii.gz”) in the subfolder “merge” has this huge size.
I know that the finished preprocessed files increase in size, but that much surprises me. With this size no further processing is possible for us. Can someone help here and say if it is because of our fMRIPrep arguments or possibly something else?

Thank you all!

fMRIPrep command: /usr/local/miniconda/bin/fmriprep /data /out participant --participant-label 9633 --skip-bids-validation --ignore slicetiming --md-only-boilerplate --fs-no-reconall --nthreads 6 --stop-on-first-crash --mem_mb 23000 -w /scratch --output-spaces MNI152NLin2009cAsym:res-1

example command.txt in wf sufolder:
antsApplyTransforms --default-value 0 --float 1 --input /scratch/fmriprep_wf/single_subject_9633_wf/func_preproc_ses_1_task_rest_wf/bold_split/vol0001.nii.gz --interpolation LanczosWindowedSinc --output /scratch/fmriprep_wf/single_subject_9633_wf/func_preproc_ses_1_task_rest_wf/bold_std_trans_wf/_std_target_MNI152NLin2009cAsym.res1/bold_to_std_transform/vol0001_xform-00001.nii.gz --reference-image /home/fmriprep/.cache/templateflow/tpl-MNI152NLin2009cAsym/tpl-MNI152NLin2009cAsym_res-01_T1w.nii.gz --transform /scratch/fmriprep_wf/single_subject_9633_wf/anat_preproc_wf/anat_norm_wf/_template_MNI152NLin2009cAsym/registration/ants_t1_to_mniComposite.h5 --transform /scratch/fmriprep_wf/single_subject_9633_wf/func_preproc_ses_1_task_rest_wf/bold_reg_wf/fsl_bbr_wf/fsl2itk_fwd/affine.txt --transform identity --transform /scratch/fmriprep_wf/single_subject_9633_wf/func_preproc_ses_1_task_rest_wf/bold_std_trans_wf/_std_target_MNI152NLin2009cAsym.res1/bold_to_std_transform/tmp-r8dtosrj/mat2itk_pos-003_xfm-00001.txt

input antsApplyTransforms:
fslhd vol0001.nii.gz

sizeof_hdr 348
data_type INT16
dim0 3
dim1 106
dim2 106
dim3 72
dim4 1
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 4
nbyper 2
bitpix 16
pixdim0 1.000000
pixdim1 2.000000
pixdim2 2.000000
pixdim3 2.000000
pixdim4 0.810000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.000000
cal_min 0.000000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
toffset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -2.000000 -0.000000 0.000000 106.000000
qto_xyz:2 0.000000 -1.951069 -0.439692 128.700974
qto_xyz:3 0.000000 -0.439692 1.951069 -27.194122
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Inferior-to-Superior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -2.000000 0.000000 0.000000 106.000000
sto_xyz:2 0.000000 -1.951069 -0.439692 128.700974
sto_xyz:3 0.000000 -0.439692 1.951069 -27.194122
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Anterior-to-Posterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip FSL5.0
aux_file

output antsApplyTransforms:
fslhd vol0001_xform-00001.nii.gz

sizeof_hdr 348
data_type FLOAT32
dim0 3
dim1 193
dim2 229
dim3 193
dim4 1
dim5 1
dim6 1
dim7 1
vox_units mm
time_units Unknown
datatype 16
nbyper 4
bitpix 32
pixdim0 1.000000
pixdim1 1.000000
pixdim2 1.000000
pixdim3 1.000000
pixdim4 0.000000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.000000
cal_min 0.000000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
toffset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name MNI_152
qform_code 4
qto_xyz:1 1.000000 0.000000 0.000000 -96.000000
qto_xyz:2 0.000000 1.000000 0.000000 -132.000000
qto_xyz:3 0.000000 0.000000 1.000000 -78.000000
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Left-to-Right
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
sform_name MNI_152
sform_code 4
sto_xyz:1 1.000000 0.000000 0.000000 -96.000000
sto_xyz:2 0.000000 1.000000 0.000000 -132.000000
sto_xyz:3 0.000000 0.000000 1.000000 -78.000000
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Left-to-Right
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip xform matrices modified by FixHeaderApplyTransforms (niworkflows v1.3.5).
aux_file

Steven · February 4, 2022, 2:42pm

This is expected. Remember that the an image you are seeing is really just a 4-dimensional matrix. When you get it off the scanner (i.e., your raw, before fmriprep, image) all of the values might be integers, which do not take up that much memory. After fmriprep does its resampling and spatial normalization (which involves things like interpolation) now you have floats with several decimal places that begin to take up more memory. When you compound the float vs integer memory increase across all voxels and time points, it is not unreasonable to see that much of an increase, especially for a long acquisition (like yours, at 450 volumes), and high-res voxels (looks to be 1mm isotropic for you).

In short, don’t worry!

valwmr · February 4, 2022, 3:33pm

Thank you for your quick reply!
Unfortunately, we can’t continue with these file sizes because we don’t have a cluster available at the moment.
If by chance you can think of a useful solution to reduce the number of decimal places of the float or another way to normalize via fMRIPrep, feel free to let me know.

I really didn’t expect such a large increase in size.

Steven · February 4, 2022, 4:20pm

You can try analyzing your data on brainlife.io . It is a free cloud-based neuroanalytical platform. You can store, preprocess, and postprocess, data on there.

effigies · February 4, 2022, 8:22pm

You can also use --output-spaces MNI152NLin2009cAsym:res-2 to get 2mm isotropic voxels, which should result in file sizes ~1/8 of what you’re seeing.