Fmriprep: Remove ICA-AROMA dependency

[rciric]

Implementing ICA-AROMA completely in nipype would permit removal of this dependency.

Since MELODIC has already been extricated from the ICA-AROMA workflow, this would entail the following steps:
(1) Compute the features used in classification:
-fractional overlap of the component with spatial masks (CSF compartment and edge of brain)
-high-frequency content of each component signal
-maximum correlation with realignment parameter time series and their first derivatives
(2) Perform the classification. A component is classified as noise if any of the following is true:

• It has a CSF fraction score > 0.1
• It has a high-frequency content score > 0.35
• A linear discriminant analysis of the edge fraction and maximum RP correlation scores returns a positive value. The halfspace/separating hyperplane is defined by the normal vector

{
    'intercept': -19.9751070082159,
    'maximum_RP_correlation': 9.95127547670627,
    'edge_fraction': 24.8333160239175
}

(3) Denoise the data. The original implementation uses fsl_regfilt to enable either aggressive or nonaggressive denoising. For fmriprep, this step might not be necessary since the denoising can be delegated to postprocessing.

There is notably a major refactor of ICA-AROMA that has been awaiting review and merge for a considerable length of time; it might be worthwhile to consider referencing this refactor where possible if we reimplement ICA-AROMA.

In another project, we removed the dependency by rewriting ICA-AROMA (unfortunately in bash+R, so not usable here). I'm including a link to the implementation as an additional reference with the caveat that it might not exactly implement ICA-AROMA functionality.

[oesteban]

Another reason is packaging (or lack thereof) - see Chris' offer on maartenmennes/ICA-AROMA#38

[oesteban]

And another one #1833.

[oesteban]

@jdkent, do you have the bandwidth and appetite to take on this one?

[jdkent]

I'm going to sfn this upcoming week, but after that I can take this on. (specifically, I may play around with this a little, but do not expect any significant progress until after the 24th)

[jdkent]

First question, should I do the implementation here in fmriprep, niworkflows, or nipype?

[oesteban]

That's a great question. Let's allow SfN's time and after, see whether there's interest in having a centralized repository and perhaps its own package.

[rtrhd]

Dear All,

I was behind the refactoring mentioned earlier. The fork is still available - we are currently using it at CRIC Bristol. There are also some regression tests against the original. Please feel free to use any of it that is suitable or let me know if I can help in any way.

I ended up both rewriting the feature extraction and adding an internal implementation of the regfilt denoising as the memory demands of fsl regfilt were causing problems with large datasets.

Ron Hartley-Davies

[tsalo]

If possible, it would be really great if the new implementation of AROMA could be run on BEP012-compatible decompositions. That way, the MELODIC and AROMA steps could be separated and other component classification tools, like tedana, could be run in addition to AROMA on the _same_ ICA run.

[oesteban]

Hey @tsalo, you seem in a roll now with fMRIPrep. I think writing BEP012-compatible decompositions makes a lot of sense.

I'm right now updating how derivatives names are constructed (nipreps/niworkflows#507). Could to have a crack at updating the default_path_patterns? By doing so, there's a big opportunity to advance support for these derivatives in the next release of niworkflows

[tsalo]

@oesteban Happy to give it a try.

[tsalo]

I have one other request for the proposed new AROMA implementation. If the classification step could be adapted to work with metrics calculated in native structural space, then it would be easier to share the ICA with other classification tools like tedana. All of the relevant masks should be easy enough to calculate from the structural data (i.e., edge, brain, out-of-brain, and CSF masks), so the only problem would be adjusting the thresholds AFAIK.

[tsalo]

@jdkent For the new implementation, I would personally prefer to see a separate repository/package.

Is there a route forward on this that would involve creating a new repository (possibly with @rtrhd's changes) that could be released on PyPi? That way we could start working on some of the additional requested features (e.g., native space and BEP012-compatible inputs).