I’m looking to preprocess my multiecho data for functional connectivity analyses. I’m wondering if anyone has any suggestions on whether to include both tedana’s denoising and 36P regression, or just one or the other? I have a high noise dataset, if that’s relevant.
If it makes sense to include both, would it make sense to run XCP-D using tedana’s mixing matrix as a custom confound (labelling signal components with signal__) while also using the -36P setting for nuisance regressors? If I’m being honest, I don’t really understand how the orthogonalization process works, and I wouldn’t want any noise associated with HMP but classified as signal by tedana to be included in my final outputs.
@dowdlelt and @handwerkerd might be the best folks to answer this, but my first thought is that there is probably a lot of redundant info between the two sets of regressors, and including both would probably be a bit of a hit to your degrees of freedom.
The orthogonalization step will orthogonalize all noise regressors w.r.t. the signal regressors, so you would end up with your 36P regressors being modified as well. If you think that the 36P regressors would include noise signals that also appear in the tedana signal regressors, then that would definitely be an issue. My understanding of the literature is that multi-echo denoising cannot identify BOLD-based noise (e.g., physiological noise), so if you expect the 36P regressors to include signals that reflect BOLD-based noise from non-neural physiological processes, then you should avoid orthogonalizing them w.r.t. the tedana signal regressors.
An alternative might be to orthogonalize the tedana noise regressors w.r.t. its signal regressors before feeding them into XCP-D.
I’m skeptical about 36P for resting state in general. If you’re doing resting state connectivity with a 0.1Hz low pass filter, that means a 10 minute resting state run drops down to effectively 60 degrees of freedom regardless of the TR. If you’re then both censoring and removing 36 nuisance regressors, what’s left? As such, adding those to tedana’s regressors is problematic. We’re currently working on something that can create a subset of external and multi-echo nuisance regressors within tedana which would be useful for your goals, but I can’t recommend waiting for us to finish that before running your analyses.
Not sure if I’m giving any definitive advice, but, if your dataset is high noise, it might be worth spending some time identifying the noise sources (and regressors) that can best be removed and not dealing with adding dozens of regressors that aren’t substantively altering the results.