Concerns regarding optimal sign determination for components

[tsalo]

Summary

To determine the appropriate signs for PCA/ICA components in the metric calculation step, we use the signs of the skew values for weights (per component) to flip components and weights so that component time series positively align with the data. However, I am not sure that this is the best way to do this.

Additional Detail

At times, I've noticed that a component with a linear trend can be rendered as going down, instead of up. As an example, take this high-variance component from the three-echo test dataset we use for CI (returned from a run using the Kundu TEDPCA decision tree):

[jbteves]

Would you mind posting a few more examples so that people can read them next to each other? Just like 2-3?

[emdupre]

Sorry for only being able to find a full presentation, but the first few slides here touch on the signing of ICA components (and why they can be arbitrarily flipped).

I think this was why the original code tried to align it with the data by arbitrary transforms, but I agree that's not going to recover the "true" solution all the time. I'm not sure there is a way to do that....

Could you point me to which metrics this useful for ?

[tsalo]

I don't believe that the signs are used for anything except visualization (with the time series and beta weights), but I think they should be (per #318). Unfortunately, we need to ensure that the signs are appropriately determined before we can use them.

Here's a list of metrics that would be affected if we used the signs for cluster extent thresholding and averaging:

• kappa and rho: Kappa and Rho are calculated as a weighted average across voxels of the R2/S0 model F-scores. The weights we use for the averaging are the squared Z-scores, which treats positive and negative weights as equivalent.
• countsigFR2: Number of significant voxels from cluster extent-thresholded R2 F-score map
• countsigFS0: Number of significant voxels from cluster extent-thresholded S0 F-score map
• dice_FR2: Dice similarity index between cluster extent-thresholded R2 beta and F-score maps
• dice_FS0: Dice similarity index between cluster extent-thresholded S0 beta and F-score maps
• countnoise: Number of significant non-cluster voxels from Z map
• signal-noise_t: T-statistic from t-test comparing distribution of R2 F-scores from "signal" voxels (clusters) to "noise" voxels (non-clusters)
• d_table_score: Incorporates a few of the above metrics

It's possible that using the skew value is the best available way to do it (the GIFT toolbox says it uses skew for signing components as well), but if so I'd like to have a record as to why this is the method we must use.

[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: !

[tsalo]

I don't know if this is worth continuing to pursue. Given how we treat component signs (#318), signing the components themselves doesn't currently matter. I'll just close this issue.