Hi all,
I have some multiecho data I have preprocessed with fMRIPrep (with the --me-output-echos argument) and tedana (FAQ — tedana 23.0.1 documentation)
I am interested in some further cleaning with FSL Melodic/Fix.
I applied 3mm spatial smoothing to the optcomDenoised_bold image supplied by tedana, and then c called FSL Melodic with the terminal command;
melodic -i 3mm_smooth_optcomDenoised_bold --nobet --nomask --tr=0.91 --Oall --report -v --logpower
I want to hand train the FSL Fix classifier (I have already hand classified components for 20 subjects based on Melodic.ica output), but it is my understanding that melodic from the command line does not provide all of the files that FSL Fix usually expects.
Any guidance on how to structure my directory to apply Fix in this circumstance would be greatly appreciated.
Cheers,
T
Several of us have worked on similar ideas for combining the multi-echo/tedana approach with other metrics. For example see: GitHub - ME-ICA/aroma: ICA-AROMA, as a Python package. A work in progress. (non-functional work-in-progress) and https://github.com/nimh-sfim/ComplexMultiEcho1/blob/main/Visualizations/OHBM2022Poster/Holness_OHBM2022.pdf
This is a bit tricky because every component you remove is a lost degree of freedom and doing the methods serially means you’re more likely to remove the same information twice. This is solvable and the newest version of tedana is designed to make this more practical to do, but it’s not there yet (contributors welcome!)
For now, my suggestion is a bit hacky, but it should work. Run FSL Melodic/FIX on the optimally combined data. That will give you an ICA mixing matrix that you can then feed into tedana using the --mix option (you might need to play with file formatting). Tedana would then process the same ICA components. Remove the components that are rejected by FIX and/or tedana.
I suspect you’d have preferred an easier solution, but I hope this is still useful.
Best
Dan
1 Like
Thank you so much! I will give it a go.
Hello again!
I have been in talks with my team about the suggested approach.
If steps were to be done in a stepwise manner, e.g. tedana optcom and denoising then ICA Fix or ICA Aroma, rather than using --mix, how would ICA Fix or AROMA be removing the same info tedana has removed, given that at each step, new data would be in use (i.e. residual signal after each step)? Would FSL Fix reintroduce noise? How?
Hi there,
I would not run two different ICAs. As you say, new data would be in use when running the second ICA.
Probably the most correct way to do it would be to:
- Run ICA Fix or AROMA first as Dan suggested
- Give the mixing matrix to tedana
- Compare the two component classifications made by ICA Fix and tedana, and decide what components you want to accept and reject (ICA Fix > tedana or tedana > ICA Fix)
- Rerun tedana with the same mixing matrix plus giving the manually accepted and rejected components to perform the denoising. You want to ignore the denoising from the previous steps and use this one in your analysis.
Hope that’s clear.
If AROMA is important for your analysis (I think the manual classification of tedana components should pick up on the motion-related and CSF-related artifacts AROMA detects), I would highly encourage you to help us develop a tedana-friendly version of AROMA.
Eneko
Hi Eneko,
Thank you so much for your reply!
The proposed procedure does make sense to me - but I am still trying to understand exactly why running ICA serially is not advised. In my mind, if running tedana THEN AROMA or FIX, tedana would firstly optimally combine and remove some non-BOLD signal, and AROMA/FIX would then clear up any further noise leftover by tedana. This way, one is left with data minimally affected by noise. Are there any papers or forums you are aware of that gets in depth into this issue, for my own understanding?
Thanks again!
Toby
I think there is some concern there about the degrees of freedom for a start.
Additionally, If you run them in serial, you’ve effectively pulled out a bunch of components that could be id’d as noise, and then you put the data back together. Then you would be asking different software to re-seperate out everything. It is likely to work, in the “the software will produce things that look like components” but maybe not in a meaningful way. Its also a little bit strange, as tedana may remove certain components from some participants but others, so your training data would be somewhat non-homogenous, if that makes sense. If you train on non-tedana data then that is even more of a problem, because the tedana output is likely to have a vastly different noise structure.
Running one ICA step and allowing FIX/AROMA/tedana to all have a look at it an identify noise components gives each software a complete input, without subject-to-subject variance. This seems more straightforward - more so than providing FIX with strange training data.
1 Like
Thank you so much for your input, everyone.
Would it be possible, with some reformatting of the tsv file, to feed in the mixing matrix (“ICA mixing tsv”: desc-ICA_mixing.tsv), IC Map (““z-scored ICA components img”: desc-ICA_stat-z_components.nii.gz”), and the optcom non denoised image from Tedana into melodic using --mix and --ICs?
ie melodic -i desc-optcom_bold.nii.gz --ICs=desc-ICA_stat-z_components.nii.gz --mix=desc-ICA_mixing.tsv -o output --Oall --report -v
The reason I ask is that tedana was not working when I used the -mmix flag (using the mixing matrix from melodic) - but the above does seem to produce valid output.
Both Melodic and Tedana use FastICA - I am just wary of any issues with the ICA output being misinterpreted by Melodic when using ICA results from Tedana in this way.
Thanks again,
T
Hi all - sorry to be a bother ! Just wanted to check in here - any advice would be greatly appreciated.
Hi @cicadawing, apologies for the delayed response.
It’s strange that tedana didn’t work with the AROMA/FIX mixing matrix. What error did you encounter? I assume the issue might be related to the format of the AROMA/FIX matrix. Does the matrix include any headers? In tedana, the matrix should be of size n_timepoints x n_components without headers. Is your AROMA/FIX matrix structured in this way?
I still believe it’s important to run AROMA/FIX first, as it allows you to utilize tedana’s manual classification tools to enforce the classification of specific AROMA/FIX components that you don’t want tedana to modify.