After successfully running fmriprep and tedana, there is a denoised image that needs to be transformed from native to MNI and have distortion correction before statistical analysis in FEAT. I’d like these two steps to be as well matched to the fmriprep pipeline as possible.
Instead of the distortion correction and spatial normalization steps again, I’m hoping that I can just use the optimally combined data from fmriprep as the input and append the time-course of the rejected tedana components to my confounds file that I’m using in my statistical analyses (in FSL/FEAT). However, I’m not sure if this strategy is the recommended approach. Is there anything else to consider with how these components might interact with the multiple echos or subsequent denoising and analyses in FSL/FEAT? I would like to ensure that all of my denoising and analyses are done in one step so that I can avoid re-introducing noise (cf. Lindquist et al., 2020, HBM).
One question- What version of fMRIPrep did you use?
If you used v21.0.0 or v21.0.1, there might be a double-unwarping issue affecting the optimally combined data fMRIPrep generates, but not the individual, preprocessed echos. In that case you would probably want to combine the individual echos and then apply the transforms afterwards, rather than use the standard-space combined data that are available. You can look at https://github.com/nipreps/fmriprep/issues/2727 for more info.
This is totally valid. We (the tedana devs) are actually in the process of adding information about that kind of denoising into our documentation. If you want more info about our thoughts on it, you can take a look at https://github.com/ME-ICA/tedana/pull/823. The considerations for including tedana’s ICA components in your GLM are basically the same as if you used ICA-AROMA for denoising and wanted to regress out its noise components. I believe there are a few questions about ICA-AROMA on NeuroStars that would be relevant to you, such as ICA-AROMA and Head Motion Regression or Aggressive vs nonaggressive denoising.
Additionally, @handwerker might have some insight into how best to do this.
I don’t think there’s an issue with the nature of the ICA components (i.e., the fact that they’re classified based on TE [in]dependence).
I think your primary concern should be about confound regressor independence. If you’re going to include nuisance regressors like motion parameters in your GLM, then you might want to orthogonalized the ICA components w.r.t. the other nuisance regressors, or vice versa.
tedana also has an option (--tedort) to orthogonalize the rejected ICA components w.r.t. the accepted ICA components, resulting in what we’ve called “pure evil” components. It might be worth considering.
Hey Taylor,
First off, thanks for answering basically all of my TEDANA questions so far by the way.
I am using fmriprep version 21.0.1 for the initial preprocessing with the --me-output-echos flag. These echos were the input for my tedana workflow. It’s good to know there may be a " double-unwarping" in the optimally combined data so I should definitely take the extra step of unwarping and registering the data myself.
To do all of that, it seems like I could just use a similar command as shown in the this post linked in the fmriprep issue you linked. The only thing different is that instead of files looking like space-T1w_desc-preproc_bold.nii.gz mine would look like ‘space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz’. That would be lovely as it wouldn’t require any data from scratch and I could still use the same fmriprep container to apply the transform.
Great that was my basic intuition I just wasn’t sure if the de-noising used information from the individual echos other than Good point on orthogonalizing the components at very least with other confounds. I was thinking I would take an approach similar to what @dvsmith describes at the end of that aggressive vs. nonaggressive post with tedana noise components, anatomical CompCor (for spatially diffuse noise), cosines, and non steady states in my GLM. Though I understand I’ll be trading off temporal degrees of freedom.
That sounds good. I think you would just need to include the t1w-to-standard transform in the antsApplyTransform call, in addition to the scanner-to-t1w transform.