Revisit component sorting within metric calculation

[tsalo]

Summary

In order to support multiple component selection methods performed on a single decomposition (e.g., running tedana and AROMA on the same ICA results) within fMRIPrep, we should not change the mixing matrix at all by resorting or flipping components.

Next Steps

1. Remove sorting steps from metric calculation functions.
2. If any steps in the metric calculation functions require components sorted by kappa, perform the sorting within the step and update the unsorted component table.
3. Remove reindex argument from dependence_metrics().
4. Update figures and reports to maximize their utility without sorting the actual component order.

[tsalo]

The good news is that, with our new dynamic reports, the order of the components doesn't matter nearly as much! The Kappa rank plot is the only one that retains the same ordering we apply to the components themselves.

[tsalo]

Does anyone have a strong opinion one way or another on this?

Since we wouldn't change the mixing matrix at all, we would probably want to log whether the component time series was flipped in the component table. I don't foresee it being a major problem for denoising, since any denoising step should automatically flip the component's sign to best match the data, right?

[jbteves]

@tsalo I think if there were strong opinions they would have been voiced by now.

[tsalo]

@jbteves good point. I will move forward with this when I have the bandwidth (or if someone else wants to take it on that's great too). Considering the work a number of us put in at BrainHack Donostia on a pure Python version of AROMA, this is more relevant than ever.

[jbteves]

Hm, would it make sense to open a PR to your PR for #592 ?

[CesarCaballeroGaudes]

I would also like that the format and order of the ICs is compatible across both packages.

[tsalo]

I think it happens in metric calculation, right? So probably #591, unless you are still working on an object-oriented version that will go in its own PR.

[jbteves]

Whoops, yes, I meant #591.