Fmriprep smoothing option

Hi all,

Is there a way to specify spatial smoothing for fmriprep? Or is it better to perform it on the *bold_space-MNI152NLin2009cAsym_preproc.nii.gz files afterwards?

Also, am I correct in thinking that slice timing correction is not performed? (it’s labelled as future on github) Is there a way to do this before using fmriprep?

Thanks.

1 Like

Not currently, but we could add this feature as an option. Depending on the analysis different types of smoothing are required.

This is how we intended things to work. You can also perform smoothing on first level contrast maps, jsut before runnign group level.

You are correct - we are working on it!

Therefore, what is the current best option to conduct slice timing correction together with fmriprep ?

The best option is to help us implement it :slight_smile: https://github.com/poldracklab/fmriprep/issues/27

Otherwise, I would perform the slice time correction before feeding the files to FMRIPREP.

That’s what I’ve been doing, slice time correct first using SPM12, then feed into fmriprep, then smoothing in SPM12.
Prelim results looks much more robust than the typical SPM preproc pipeline. Well worth the effort.
@ChrisGorgolewski Thank you for the software. Look forward to future updates!

1 Like

Slice timing correction has already been added according to https://github.com/poldracklab/fmriprep/pull/415 ?

Yes - it’s in current master. Will be part of the next release.

Thank you very much for really quick update. I’d like to decide which version to use, could you let me know the rough estimate when the next release will come?

Most likely this week.

Thank you very much! I’m looking forward to seeing the new release.

Just to make sure -
In the current version of fmriPrep is there any smoothing? or none at all?

Currently, there is no option to include spatial smoothing in fMRIPrep. And it does not seem the principles for that design decision have changed. As Chris mentioned above, we understand that step is very analysis oriented and as such it should be performed in the beginning of the analysis stage.

Just to be sure, slice-timing correction has been added since this thread was first opened.

4 Likes

I am slightly confused with this. If I choose ICA-AROMA, spatial smoothing using Susan filter is applied and final denoised data is smoothed and in MNI space (*space-MNI152NLin2009cAsym_desc-smoothAROMAnonaggr_bold.nii). Am I correct in understanding that this is the output I will take for further first level analyses? Unless *space-MNI152NLin2009cAsym_desc-preproc_bold.nii image is the denoised non-smoothed data which I can use for further analyses?

Correct

Well, that depends. If you use the variant-AROMAnonaggr version of the outputs, then you will not want to use the Aggressive AROMA regressors nor other motion regressors in your modeling. Otherwise, you risk re-introducing noise. As you mention, if you use variant-AROMAnonaggr then do not apply any additional spatial filtering (as SUSAN has been applied). No temporal filtering is performed on the variant-AROMAnonaggr outputs (therefore, you’ll need to insert that step in your analysis workflows).

If your modeling is designed to use such regressors, then you shouldn’t pick the variant-AROMAnonaggr outputs. Use the AROMA aggressive regressors, include a spatial smoothing step and similarly to the previous case, add temporal filtering.

A post was split to a new topic: fMRIPrep: nonsteady states added back into AROMA non-aggressively denoised outputs