Using tedana in conjunction with rapidtide

[tsalo]

Summary

rapidtide estimates a regressor representing the global signal in the low-frequency oscillation (LFO) band, with each voxel having its own lag.

I was thinking that we could repurpose the current gsr code into a command-line interface that lets users denoise individual echoes with regressors derived from the optimally combined data.

1. Run t2smap to get the optimally combined data.
2. Run rapidtide on the optimally combined data to get out an unfitted, lagged regressor NIfTI file.
3. Run the new CLI on (1) the optimally combined data, (2) the lagged regressor file, and (3) the individual echo-wise files to get out echo-wise files with the lagged regressor removed.
   • We will need to extend the gsr function to support voxel-wise regressors to make this work.
4. Run tedana on the modified echo-wise files.
   • Probably want to feed in the T2 map from step 1 in case the changes to the echo-wise files also affects T2 estimation and optimal combination.

@dowdlelt I think you have experience using rapidtide and tedana together. WDYT?

Additional Detail

Related to #1022.

[tsalo]

I'm not actually sure if the GSR function does anything special that we would need to also do for external regressors.

[tsalo]

The GSR function includes Legendre polynomials, but I don't know if we would need that for "external" regressors. Other than that, it seems to just mean-center each echo's data, regress out the regressor, and then add the mean back into the data. If that really is how it works, then we should be able to apply the same approach to any external regressors we want, including rapidtide regressors and drifts (#1054). I'd love to compare this kind of approach against the one from #1009.

[dowdlelt]

I had thought about this a bit - I was thinking along the lines of seeing if each component would work better by determining time lags, but now that I think of it, that gets complicated very quickly. Rapidtide expects one signal to shift around, and I don't think there is any simple way of determining the time lags of many many regressors simultaneously (or if there would be any benefit!).

So, with that in mind, this idea seems more reasonable. I'm trying to think about ordering - would it be better to remove the time lagged signal from each echo and then do tedana as you suggest? Removing the global signal first might improve removing those components that look like BOLD, but aren't good signal...

Or should it be post tedana, to clean up residual global signals that weren't removed? After tedana, you have the benefit that large signals, or spikes in single slices, other non-generalizable signals have been removed, so maybe the time lagged signal would be an even better fit to the global problem. Of course, in the post tedana case, you could just use the denoisied timeseries as input into rapidtide, no new work needed.

[tsalo]

I was thinking along the lines of seeing if each component would work better by determining time lags, but now that I think of it, that gets complicated very quickly.

That sounds similar to what I was thinking about in #1022.

I'm trying to think about ordering - would it be better to remove the time lagged signal from each echo and then do tedana as you suggest? Removing the global signal first might improve removing those components that look like BOLD, but aren't good signal...

I agree that this is a hard problem. Based on Korponay et al. (preprint), though, it seems like some denoising methods might interfere with rapidtide. For example, in that preprint, they found that mean CSF or WM signals really just isolated the sLFO captured by rapidtide at a single delay, so if you run that kind of denoising beforehand I imagine it will prevent rapidtide from accurately estimating the sLFO signal. I worry that tedana might also identify components at specific delays in a similar way. Of course, that would only be a problem if tedana rejects those delay-specific components, which it probably shouldn't since they should be BOLD-based, but I still lean toward running rapidtide before tedana.

[tsalo]

If we were to run rapidtide, or any kind of external regressor-based denoising prior to the ICA step, I think we should calculate the full range of dependence metrics and report them in a file. For example, we would expect rapidtide's regressor to be strongly BOLD-based (high kappa, low rho) given the nature of the sLFO it's meant to isolate. On the other hand, if we tried regressing out motion parameters (which I'd really love to compare against the ICA-based approach in #1064), I'd hope to see high rho and low kappa.

[tsalo]

I tried creating a workflow to denoise the individual echoes with external regressors (and calculate dependence metrics for those regressors) in #1097, but ICA wouldn't converge on subsequent tedana runs, even when I used aggressive PCA.

Also, the motion regressors' kappa and rho values weren't what I was hoping for. Kappa values were in the 10 - 20 range and rho values were in the 10 - 14 range. Rho values were rarely higher than kappa values. Weird, right?

Perhaps a better alternative for combining rapidtide and tedana would be to do the following:

1. Run tedana.
2. Run rapidtide on the optimally combined (not denoised) tedana output.
3. Take the voxelwise rapidtide regressor and the tedana ICA components, and use both in a denoising GLM on the optimally combined data.
   • The thing I don't like about this is that there could be shared variance between the tedana ICA components and the rapidtide regressor. There's also no guarantee that the rapidtide regressor won't be split across multiple ICA components, so I think we'll end up losing degrees of freedom unnecessarily.