Hi, I’m using fmriprep to preprocess some resting state data on which I will ultimately perform a group ICA using the MIALAB’s GIFT toolbox. I’m wondering if anyone has an example of how they integrated the fmriprep outputs into a subsequent ICA (and/or any resting state analysis, just out of curiosity).
GIFT expects images to have undergone slice timing correction, motion correction, spatial normalization, and smoothing prior to implementing data reduction in GIFT (PCA --> group ICA --> back-reconstruction of individual subject spatial maps).
I’m unclear whether it’s better to use the smoothed, non-aggressively denoised images produced by fmriprep’s ICA-AROMA option…or whether that denoising step (and/or any other denoising methods using the confounds.tsv file, for ex. using the denoiser toolbox) would be more or less redundant with the subsequent data reduction steps in GIFT, and I should just smooth the images as an additional step post-fmriprep. I’m guessing the latter is the case, but wanted to check given that I’m new to this and haven’t found any examples yet.
We do not have any examples showing this, but I’m going to summon @rastko here. He might be a bit snowed under today, so until he can reply you might find his paper - https://www.nature.com/articles/s41596-018-0065-y very interesting.
Thanks @oesteban! I did run across his paper while I was trying to figure this out and thought it looked helpful. I’ll give it a read.
I’ve been playing around with a few subjects in GIFT and did notice there are a lot more noise components present in the data (eyes, motion, CSF) than I expected when using the non-aggressively denoised images (
sub-*_ses-*_task-rest_bold_space-MNI152NLin2009cAsym_variant-smoothAROMAnonaggr_preproc.nii.gz). (Guess that’s what makes it “non-aggressive”, I suppose - not going to remove everything). Based on this observation, it seems to me like it would probably make more sense just to perform denoising after the dimension reduction step (as described on slide 22 here) rather than doing it both before and after using different algorithms (ICA-AROMA vs. Noisecloud toolbox in GIFT). I was hoping there was a good way to integrate the aCompCor/tCompCor/other info in the confounds.tsv file from fmriprep into the subsequent analysis. I’ll ask on the GIFT listserv as well, though that one doesn’t seem as active.
Now that I’ve been working with my data/GIFT/fmriprep for a while, I realize I was wrong/confused about a lot of what I wrote above. In case someone is Googling and stumbles across this thread (as I often do), clearing up a few points:
For reference, I am using fmriprep outputs with the Group ICA of fMRI Toolbox (GIFT) toolbox (http://mialab.mrn.org/software/gift/index.html) to perform static and dynamic functional connectivity analyses.
Difference between aggressive vs. non-aggressive ICA-AROMA: see relevant section of my “getting started with fmriprep” guide.
ICA-AROMA is designed specifically to address motion-related artifacts, so of course it won’t do much for other types of artifacts, such as CSF and blood flow.
There is not a way or a need (that I can tell) to provide info from
confounds.tsv to GIFT in its data reduction steps.
However, what you could do with the info from fmriprep’s
confounds.tsv file is set up subject-level design matrices (or text files for batch entry) containing selected confounds, then use temporal sorting to display the components and see which might load onto the time course of the confounds. This would show which components were associated with a particular confound. (Otherwise, the design matrix is not used in GIFT during the analysis stage unless you’re doing semi-blind ICA).
The main difference that I’ve found between using the ICA-AROMA non-aggressively denoised vs. non-denoised preprocessed outputs (with post-fmriprep smoothing applied) is in how GIFT estimates the number of components for each subject/sessions:
For some reason, when I use the denoised data, I get a lot of overfitting, with most subjects having an estimated 100-150 components (rather than ~30-50 in the non-denoised data). GIFT allows you to specify the number of principal components you want GIFT to reduce each subject down to at each reduction step, so that is a way around getting back a hundred-plus splintered components. But I’m wondering why using the denoised data would cause overfitting?
My other outstanding question is whether it is a problem to perform multi-stage denoising – i.e., adding Step 1 below to a more usual procedure (Steps 2-3).
- For the initial data reduction step, use ICA-AROMA non-aggressively denoised outputs (instead of non-denoised preprocessed files) to address movement-related noise.
- After the first PCA/ICA in GIFT, identify and remove remaining obvious noise components using GIFT’s component removal utility, and rewrite the denoised data.
- Run PCA/ICA a second time on the now twice-denoised data.
(Timecourse detrending, despiking, and low-pass filtering are also part of the usual procedure in GIFT).
A follow-up to my follow-up above, for same reasons (so as not to confuse/misinform the hypothetical future person reading this):
Yes, it’s probably a bad idea to perform multi-stagedenoising. As documented in other places, sequential denoising runs the risk of reintroducing noise in standard fMRI analyses. Not sure if the same principle applies here since we aren’t using regressors, but from working with my data, it seems that it’s really not necessary to do a second denoising since GIFT’s ICA generally seems to do a good job of parsing signal/noise and it removed too much signal. ICs looked a lot more robust and stable when I just did the ICA-AROMA non-aggressive denoising prior to GIFT, without the second denoising step.
To get around the overfitting issue when using the fmriprep ICA-AROMA preprocessed outputs, I just specified the number of components requested in the data reduction steps instead of asking GIFT to estimate the number of components. Because the data have already had some variance removed by ICA-AROMA, I have been using a lower model order than in other papers. 30 (45 for the PCA step 1) seemed to work well for me but YMMV. You can try higher and lower numbers to see what gives the best balance between over-lumping and over-splitting.
Note also that if you’re using fALFF when identifying good/artifact components based on the Allen et al. 2011 paper (“A baseline for the multivariate comparison of resting-state networks”), their fALFF value below which components were classified as artifacts will probably be higher than when using ICA-AROMA denoised outputs, since we already removed a bunch of high-frequency noise (motion). So their fALFF = ~6 rule of thumb is not necessarily applicable.