I’m using FSL feat to analyze my fmriprep output; however, I wanted to clarify which functional output file is appropriate. In fmriprep I specified --use-aroma, so in addition to the preproc_bold.nii.gz file I have a smoothAROMAnonaggr_bold.nii.gz file
I understand that the smoothAROMAnonaggr_bold.nii.gz file has undergone spatial smoothing, and I am under the impression that it’s also non-aggressively denoised. This leads me to believe that this is the file I should use in analyses, but I’ve noticed that the preproc_bold.nii.gz file is generated after. Am I correct in assuming then that the smoothAROMAnonaggr_bold.nii.gz is proper file to use (in addition to regressing out confounds from confounds_regressors.tsv)?
@dlevitas Yes, that’s correct. The timestamps are artifacts of the scheduling algorithm, and not an indicator of one being “more processed” than the other. They are in fact separately resampled, so the last common links in their provenance are the original volumes (possibly slice-timing corrected) and any common transforms calculated (HMC, SDC, registration, normalization).
That said, all of the regressors in confounds_regressors.tsv (with the exception of the AROMA mixing vectors) are calculated on the unsmoothed, non-denoised data, and should be used with caution on the AROMA-denoised series.
@effigies Just to clarify on the breadth of your “Yes that’s correct”.
I know that fmriprep used to also produce the aggressively denoised image as an output but doesn’t do so anymore. Would the recommendation be to use the smoothAROMAnonaggr_bold.nii.gz. image and include motion, fd, and global signal variables and/or the AROMA mixing vectors as first-level covariates in CONN, for not so arbitrary example, or to use the preproc_bold.nii.gz?
I know that fmriprep used to also produce the aggressively denoised image as an output but doesn’t do so anymore.
I do not believe we did. Perhaps @jdkent can confirm?
Would the recommendation be to use the smoothAROMAnonaggr_bold.nii.gz . image and include motion, fd, and global signal variables and/or the AROMA mixing vectors as first-level covariates in CONN, for not so arbitrary example, or to use the preproc_bold.nii.gz ?
I believe AROMA advocates would say that AROMA should capture motion-related components, and so motion and FD would be at best redundant and at worst reintroduce motion-correlated noise. If you wish to do GSR, then that should be calculated post-denoising, I would think. There’s an open issue to recalculate some of the regressors post-AROMA. I would be very hesitant to use most of the regressors calculated on the raw BOLD data when analyzing the the AROMA-denoised data.
In any event, the AROMA regressors are only to be used if you want to do aggressive denoising on the desc-preproc_bold.nii.gz files. I do not think there is any good way to use them with the denoised data. (I may be misinterpreting part of your question, but just in case I’m not I want to make that clear.)
To all of this I add the caveat: I am not a specialist in rest fMRI or functional connectivity, and don’t know what is currently considered the best practice. And I have no experience with CONN, so cannot make a recommendation there. I invite further comment from others. @mmennes will probably be the best authority on AROMA.
I have a quick follow up question regarding this part:
all of the regressors in confounds_regressors.tsv (with the exception of the AROMA mixing vectors) are calculated on the unsmoothed, non-denoised data, and should be used with caution on the AROMA-denoised series
When creating a design matrix for analysis on the smoothAROMAnonaggr_bold.nii.gz data, would the only nuisance regressors worth incorporating be the aroma_motion_# columns then? From what I’ve been hearing, it seems that the the other confounds generated in the .tsv file (CSF, WM, FD, t_comp_cor, a_comp_cor, etc.) will likely reintroduce noise.
No, if you’re using smoothAROMAnonaggr_bold, then the AROMA-identified motion regressors have already been removed. Those regressors are there to allow you to do the aggressive denoising on the regular desc-preproc_bold series, if you prefer. (Chronologically, it’s actually the case that smoothAROMAnonaggr was added because it’s a moderate pain to do non-aggressive denoising after the fact, so we just take the outputs that AROMA gives us and pass them forward.)