Get RICA to work with tedana_reclassify
handwerkerd opened this issue · comments
Summary
When Decision Tree Modularization is merged, the interface with RICA will break. The current function RICA uses to manually change classifications will be removed and these changes will happen through a new workflow tedana_reclassify It would be good to make sure RICA works with both version before that major change is merged
Additional Detail
RICA should be able to interface with tedana through tedana.workflows.tedana_reclassify.post_tedana. In the new version, instead of inputting multiple filenames, it takes a filename registry called desc-tedana_registry.json or registry.json RICA should be able to use the same system where users select a directory to use, but, if the registry exists, use the registry to identify file names and the run post_tedana otherwise just run the current I/O code which should keep for older versions of tedana.
With the newer version, the component table will keep existing classification_tags for each component and also add a manual reclassify tag. Additionally the component_status_table will add columns for each component showing how components where changed with reclassification so that provenance of manually will be fully documented.
Additionally, the file registry should work with relative paths so it would be possible to have RICA output a new denoised dataset to a new output directory and the new registry in that output directory will be able to reference back to the original files that weren't changed and didn't need to be copied.
Next Steps
- Everything in the modularization PR should be rest to work wtih RICA.
- From our last dev call, it sounded like @eurunuela wanted to try to find time to work on this.
- @jbteves and @handwerkerd can definitely help if there's any confusion or if issues arise.
- Ideally get this done soonish (January), so, if we need to change anything in tedana to make this work, we can make sure it's fixed before merging that PR.
I've had a look at tedana_reclassify.
It looks like passing the manacc and manrej arguments as a list of integers is necessary, right? If that is the case, I believe the easiest workaround to make it compatible with Rica would be to accept .csv files too. This way, I could generate two .csv files with Rica: one for accepted components, and one for rejected components.
What do you think @handwerkerd @jbteves?
Eneko, I implemented a solution for you and then totally forgot to tell you, sorry. There are a few ways to supply the components now:
- supply it as a comma-delimited string on the command line
- Supply it as a .csv file, with either no column headers or at least one column with a "Components" header.
- Supply it as a text file, with each component number delimited by space, tab, newline, or commas.
This is great. Thank you Josh! I will try to develop the new downloading function in Rica sometime this week.