-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to denoise data using existing component table #334
Comments
My intuition is that you would want it to be a post-tedana operation since I would assume you at least want the PCA denoising and optimal combination before you run AROMA. That could be wrong, though, since I don't work with other ICA routines. |
I imagine a post-tedana workflow where you provide it with the table and tedana output directory, and it creates a new output directory, applying the new classifications, regenerating the denoised data, noise component timeseries for inspection, etc. |
I like the idea of incorporating it into tedana in that it'd be great to be able to just update the classification table instead of providing a list to Not a strong preference, since there are other ways we could update |
More #407 than #344. #407 should make it possible to denoise data the exact same way as the original denoising using the existing workflow. In its current form, even with a mixing matrix and component table provided, T2* estimation and optimal combination will still be performed from scratch. Both are deterministic, so in practice this isn't a problem, but still... |
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: ! |
I think this should have been closed by #508 🤦♂ |
Summary
We currently support manual identification of accepted components (and could easily extend to rejected components) using comma-separated lists of components. However, additional decision trees (e.g., AROMA) could easily operate by overwriting the original component table with updated classifications. We should be able to simply run tedana with a component table (which may have updated classifications) without a separate list of classifications.
Additional Detail
This will impact our internal logic regarding component tables, the mixing matrix, and
manacc
(and possibly a futuremanrej
). It could also be a separate post-tedana
workflow, if needed.Next Steps
The text was updated successfully, but these errors were encountered: