Excessive size resulting from antsApplyTransforms using _xfm.h5 from fMRIprep output

[effigies]

@moreblue

• What caused this excessive size? Is there any solution to the problem (which may already be used by fMRIprep)?

Two things, most likely.

1. Voxel size and field-of-view. If you’re using your normalized T1w image as your reference, then your outputs are going to match your normalized T1w’s voxel sizes and field-of-view, which will be appropriate for structural data, but probably too high-density to be sensible for BOLD.
2. Possibly your on-disk data type is larger for your output files. You’d just have to look.

@moreblue

• Is there any method more efficient than the way I did to warp functional BOLD outputs on T1w space? Is it best to re-run the fMRIprep using default settings?

It would probably be easiest to rerun fMRIPrep. One thing that doing so buys you is that head-motion-correction, susceptibility-distortion-correction and normalization are applied in a single step, reducing resampling artifacts.

If you still have your working directory, it should not take very long to rerun.

@moreblue

• If I were to use the warped image with 3.13GB, would that image be qualitatively different from what may have resulted from fMRIprep using default settings? In other words, are there any additional post-correctional touches to normalized functional BOLD image on MNI in the process of the standard fMRIprep pipeline?

There shouldn’t be any corrections applied, but there may be differences in artifacts based on resampling twice, rather than once. The only other consideration is that, if your input data is stored on-disk as int16, fMRIPrep will save the results as int16 to avoid needlessly inflating precision, so that’s one place a (very small) additional rounding difference could be introduced.