Difference between fmriprep+ica aroma and me-ica for multi-echo resting-state data


I have some multi-echo (3 echo’s) resting-state data that I ran through a fmriprep+xcp-d pipeline using using the xcp-d’s “aroma gsr” confound model.

Can someone with a deeper understanding of ME-ICA tell me whether it a) significantly differs b) is superior to using ICA-AROMA as described above?

ps.: I know about tedana, but I want to gradually work my way up the ladder.

Conceptually AROMA and ME-ICA are similar in that they are transforming the data into ICA components and identifying components to remove. The big difference is that AROMA decides on which components to remove based on how much each component correlates to head motion parameters or had edge artifacts while ME-ICA decides on components to remove based on whether the echo time dependence across echoes is unlikely to be BOLD-weighted. tedana is a re-implementation of the ME-ICA method.

A key point is that these methods are not inherently exclusive. You can theoretically take the same ICA components, run them through AROMA and tedana and remove the components and are rejected by either method. I can point you towards some efforts in this area and talk more about my own experiences working on merged methods, but there’s no push-button code that does both yet.

Conceptually, multi-echo methods can be superior because they can do everything AROMA does and also use additional empirical information from comparing echoes to more quantitatively remove non-T2* noise.

I use AFNI & not fmriprep so I can’t give advise there. I’m generally against using GSR as a standard pre-processing step, but there are specific use-cases where it may be appropriate.

Hope this helps


Thank you! I would be interested in whether this is worth the effort in your experience.

I’m generally against using GSR as a standard pre-processing step, but there are specific use-cases where it may be appropriate.

Right, I will read some more papers on whether I should do it or not!

Here is the progress on the merged methods that I’m aware of:
We’re working on a major refactor of the tedana code (see https://github.com/ME-ICA/tedana/pull/756 ). For the current tedana, there is one “decision tree” that decides which components are accepted or rejected and the criteria mostly depend on the relationships between the echoes. In the new version, there will be a flexible format where anyone can define their own decision criteria. One reason we’re working on this is because it would then be possible to combine multi-echo based metrics used by tedana with the other metrics used by AROMA into a single pipeline.

As for GSR, there’s a lot written, but this is a good starting point that summarizes some of the preceding literature: https://www.liebertpub.com/doi/full/10.1089/brain.2012.0080