Optionally supplement component selection with AROMA

[tsalo]

Summary

In their 2017 paper, Dipasquale et al. compared AROMA run on optimally combined data to ME-ICA. While they ultimately determined that ME-ICA was the best choice, given that it did a better job than AROMA at reducing functional connectivity-motion associations. However, AROMA did quite well overall and definitely improved TSNR far more than ME-ICA.

Additional Detail

AROMA is implemented in pure Python and only uses four metrics for component classification, so it should be fairly straightforward to incorporate into tedana. One benefit to incorporating AROMA into tedana instead of allowing users to simply run it separately (e.g., at part of fMRIPrep) is that we can perform a single ICA decomposition and classify components according to both sets of criteria at once, rather than running an ICA for tedana and then another one for AROMA. A drawback would be that we will need more inputs in order to support AROMA, including motion parameters and transforms to standard space. Luckily, I think that these inputs are things we probably also want for comprehensive reports, so we may want to support them as options anyway.

Next Steps

1. Determine how best to abstract AROMA methods away from FSL. This could involve contributing to AROMA directly or incorporating its code in tedana (AROMA has an Apache license).
   • We need to compute metrics and call the component selection without calling MELODIC, without using FSL's directory structure/filenaming conventions, and without writing out files, if possible (e.g., by returning DataFrames instead of writing out text files).
2. Add --tedica argument to the tedana workflow. We already plan to ultimately support both v2.5 and v3.2 of Kundu's component selection approach, so this will need to be added at some point anyway.
   • The options could be kundu2 (default) and kundu2+aroma. Or something.
3. Add options for motion parameters and transforms.
   • We at least want motion parameters to improve our visual reports. Transforms will be a bit more problematic, although we could probably use tissue probability maps or masks instead.
4. Add function in selection for running AROMA on our ICA results and outputting a DataFrame that we can merge with the tedana one we build already.
5. Validate approach.

[handwerkerd]

FWIW, this is one example where TSNR can be a problematic metric. The method that removes the most variance will almost always have a lower TSNR. TSNR can be a valuable measure for comparision acquisitions, but can be problematic when comparing preprocessing steps that are designed to remove variance. Figuring out if the "correct" variance was kept/removed is harder & the focus of a lot of the other measures in that paper.

More generally, I agree that AROMA and tedana can be complimentary approaches and it should be possible to use them together on the same set of ICA components.

[tsalo]

@handwerkerd I didn't realize that. I guess that the benefits of including AROMA aren't as clearcut as I thought, but, as you said, we should definitely support it as an option.

The AROMA code isn't really set up to be used by other tools, but we can either work off a fork or discuss refactoring the package somewhat with the project maintainer.

In any case, even though AROMA is designed to operate in standard space, I think we can do it in native space as well. AROMA uses three standard space masks, and I think we can replicate each of them in native space from the EPI data. Here are the three masks:

• mask_out.nii.gz: A mask of voxels outside the brain.
• mask_edge.nii.gz: Mask of the edge of the brain. Created by eroding the MNI 2mm brain mask with a 10mm box kernel and subtracting the eroded mask from the full mask.
  • We can use compute_epi_mask or make_adaptive_mask for both this and the non-brain mask.
• mask_csf.nii.gz: Mask of CSF, created by thresholding a CSF segmentation prior at 95%.
  • The T2* map provides good tissue separation, with CSF having higher T2* values than GM or WM. We could maybe apply a threshold to the brain-masked T2* map to get something like a CSF mask. What do you think of this approach?

[tsalo]

Actually, I think there's another problem. AROMA runs MELODIC with mixture model-based inference, and I don't think we can easily replicate that in Python.

UPDATE: I'm not sure if the resulting thresholded/statistical maps would be similar, but one thing I'm proposing in #223 is proper (hopefully) calculation of Z-statistics from component parameter weight maps.

[emdupre]

I wonder if rather than running AROMA directly we could just incorporate their selection criteria. There's a very long conversation to be had there about selection criteria in general, but AROMA is sort of a unique constraint in that we would need access to the motion parameters.

In terms of running OC + AROMA, that should be already accessible to folks in fMRIPrep. So I don't want to replicate that -- I'd just like to know if their selection criteria will help ours. Directly comparing the ICA implementations is tricky, and I agree with @handwerkerd here that this is part of a bigger discussion on the right dimensionality reduction technique. Maybe we should open a thread on that directly ?

[tsalo]

We can definitely incorporate versions of the features using the information available (plus motion parameters), but with the caveats I mentioned above. Namely, MELODIC has mixture model-based inference that I don't know if I can replicate in Python and native-space masks derived from our adaptive mask will be pretty different from the standard-space masks used in the package.

While I don't love the idea of expanding the inputs for tedana, we're already considering allowing motion parameters (and segmentation masks) for the reports. If we do decide to allow those additional files for report generation, we can also use them for other things (like this) as well. Although.... we could always incorporate the frequency and CSF spatial features, but not the motion parameter feature. I could add those in fairly easily, I think, although we'll have to think about the best way to incorporate code from AROMA directly into tedana. Would citing the AROMA paper with duecredit and in the docstrings be enough?

If the only way of doing both AROMA and MEICA is by doing them on separate decompositions, then I think that AROMA is outside of tedana's scope and I totally agree that we should just leave it to fMRIPrep to do it.

[jbteves]

@tsalo do you think we should close this issue as being outside of our scope?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to tedana:tada: !