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

[foldes.andrei]

Hello,

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.

[handwerkerd]

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

Dan

[foldes.andrei]

@handwerkerd

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.

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!

[handwerkerd]

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.

• I’ve worked on a method that combines tedana with motion and physiological noise regressors (though not the exact AROMA method). It can be run on tedana output, but could potentially be integrated into tedana once the above is added to the code. You can see the OHBM poster at ComplexMultiEcho1/Holness_OHBM2022.pdf at main · nimh-sfim/ComplexMultiEcho1 · GitHub and the code is in that repo. That attempt didn’t see a huge benefit of a combined method, but other metrics to combine may work better.
• I’m not directly involved with this & I don’t know the current status, but there’s an effort to clean up the AROMA code so that it can play well with tedana: GitHub - ME-ICA/aroma: ICA-AROMA, as a Python package. A work in progress.

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