I was asking myself the same question and then stumbled onto the post below From April 2019. It seems that we will have to use fMRIPrep and tedana separately as they are no longer working to integrate them together.
“The choice to not incorporate tedana denoising into fMRIPrep was a conscious one. Given that fMRIPrep is geared towards robustness – and our lingering concerns as to whether tedana denoising was (yet) able to produce robust results – we decided not to include it for now.”
Thanks for this. It does appear that putting tenana into the current workflow of fMRIPrep has been put on the back burner.
I’m still a bit confused about what fMRIPrep is actually currently doing with ME data:
the --t2s-coreg option says that if this option is not enabled, ‘standard EPI-T1 coregistration in performed using the middle echo.’ There was a post back in Aug. 2018 where @emdupre says that " --t2s-coreg would not combine the multiple echos. It’s another way to coregister the functional and anatomical data by first generating a T2* map and then coregistering the anatomical to that single image rather than to each of the echos separately."
There are posts in 2019 that talk about removing this option all together based on issues raised about this option, so I’m hesitant to use it.
So, if we don’t use this option, (2) the boiler plate says it “optimally combines” the ME data, and gives a reference to the Posse 1999 paper. Is this what fMRIPrep is doing with the ME data? What is outlined by Posse et al.?
Yes, I’d recommend against using --t2s-coreg at this time.
Optimal combination averages the data across echoes, with each voxel’s average weighted based on that voxel’s T2* value. The idea is to essentially predict what the data would be if you acquired each voxel its specific best echo time. In the tedana documentation, we have a walkthrough of optimal combination with figures that might be helpful.
It seems that these paths have changed with new versions of fmriprep (I’m using 20.1.1) - could you point me toward where I can find the second transform in the fmriprep workdir?
I know I am a little late to the party, but I have also wanted to combine tedana’s ME-ICA with fmriprep. I have a fix that has been working well for me.
I had to make the following changes to fmriprep:
Fmriprep container was build utilizing singularity’s --sandbox flag (1). This allows us to make edits to include tedana in the pipeline.
Edited the multi_echo interface to allow for tedana to be used instead of t2smap (2)
Removed skullstripping second pass step done before tedana (3)(a) (3)(b) since this was causing too much brain to be masked out. Created a custom_utils.py interface to replace skullstripping for this one step.
(2)edited file at fmriprep_ICA/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/interfaces/multiecho.py to change ‘_cmd’ from ‘t2smap’ to ‘tedana’ and edit outputs in def _list_outputs(self)
(3)(a)To correct for this issue, we needed to find a way to remove the skullstrip_second_pass for only this one section. We want to interfere with the code as little as possible. I achieved this by creating a custom workflow in fmriprep_ICA/usr/local/miniconda/lib/python3.7/site-packages/fmriprep/workflows/bold/custom_utils.py` script can be found in attachments as ‘custom_utils.py’
(3)(b) After creating the custom_utils.py it had to be added into the main bold workflow fmriprep/workflows/bold/base.py at line 414
These changes have already been made in a version of fmriprep that I forked. They can be found here:
If you are interested in trying out, feel free to contact me!
I’m helping out a collegue with multi-echo data and wanted to ask how does your workflow differ from running standard fmriprep (21.0.2) with the -me-output flag, getting native space single echo files and running tedana on those files?
We made these changes to the script before the --multi-echo flag was available. We are continuing to use it because it builds tedana directly into fmriprep. It’s very helpful to have everything in one singularity container and we can also utilize fmripreps qc outputs.
The improvement in dropout is quite significant using me-ica as opposed to the standard T2star method.
Thanks so much for sharing details about this workaroud for integrating tedana into fmriprep! As I am about to analyze some ME-BOLD data, I was wondering if this is still the most up to date approach you would recommend (as you said, having the fmriprep QC is very valuable, so I’m leaning against separating the timeseries to different echoes and running tedana externally).