ICA on spatially or temporally concatenated multi-echo data

[tsalo]

Summary

In the past we supported running PCA+ICA on spatially concatenated multi-echo data. We ended up dropping the associated argument (--sourceTEs) because (1) it wouldn't work with MA-PCA and (2) we couldn't determine the theoretical basis for it.

Now that #1013 is close to being merged, I figured we could bring this back up.

1. Is there a reason to run ICA on spatially (z) concatenated data? What is the theoretical basis for it?
2. Can we try spatial concatenation with robustica?
3. Has anyone tried running the ICA on temporally concatenated data?
   • Does this make sense?

Additional Detail

This stems from #1023 (comment) and is related to #203 and #485.

[tsalo]

With temporally concatenated data, I expect that the components would vary temporally, but would be consistent spatially, across echoes. That sounds like a bad idea when we want components to be consistent temporally across echoes, but vary spatially.

[handwerkerd]

I think spatial concatenation before ICA only makes sense as part of a process to define alternate metrics to calculate T2* and S0 weighting. As mentioned in #1023 (comment) the original MEICA did this. Just to state the difference (as far as I understand it):

OG MEICA:

1. ICA is calculated on spatially concatenated echoes
2. The method assumed that, for each ICA component, the relative weight maps for each echo were nearly identical, but the weightings were different
3. kappa was larger if these weightings scaled linearly with echo time and rho was larger if the weightings were flat across echos

Publicly release MEICA & tedana:

1. ICA is calculated on the weighted combination of the echoes (optimal combination)
2. Each echo is then fit to each ICA component
3. kappa is larger if these fits scaled with echo time and rho is larger with they are flatter across echoes

I don't know exactly what Prantik made this change so early on, but I'm guessing there are a few factors. One is increasing the number of voxels in the ICA by >=3X which will make that step a lot more computationally intensive and slower, especially with RobustICA. I also suspect it led to more convergence issues. I also suspect the assumption that ICA makes nearly identical patterns across each echo with the original method was good, but far from perfect. When it failed, I could see it failing in problematic ways. Running ICA on the optimally combined data and then fitting likely reduced problematic failures.

This is a long way of saying, I think there are possibilities here, but it's more than just adding an option back in. I don't have the bandwidth to play around with this directly, but I'd advise anyone else who might be interested.

[handwerkerd]

Prantik also recommended temporal concatenation in his version of MEICA and I was always a bit more skeptical. The benefit is, if we assuming the properties of data are consistent across runs, then more time points results in better ICA and better results. My concerns were about how it handled baseline shifts, head motion, and other large distortions between runs. That is, if the interesting variation is swamped below these other factors, then the benefits might not appear in practice.

My concerns could be addressed if we integrate run-by-run detrending #1054 and possibly censoring #1053. I do think there's a lot of potential here & would very much support someone interested in work on detrending with the goal of adding in temporal concatenation next.

[tsalo]

I think I misunderstood your comment above. You mean temporally concatenating OC across runs, right? I originally thought you meant temporally concatenating across echoes, which is what I was originally proposing before I talked myself out of it.

Temporally concatenating OC data across runs sounds promising. Definitely happy to dig into dealing with detrending and censoring to make it more feasible.

EDIT: I just realized something that complicates concatenation across runs- we mostly run tedana on native-space data. At least with fMRIPrep, different runs won't be in the same "native"/"boldref" space. Not sure about afni_proc.py though. Is there an option to write out echoes to a bold reference space that's matched across runs?

[tsalo]

Possibly relevant analysis: https://github.com/TengfeiFeng/ME-fMRI_TensorICA

[handwerkerd]

If an analysis is being done in a template space, afni_proc aligns data to that space before running tedana. If the data are in native space, then all runs are aligned within native space before running tedana. I think this conforms to the recommendations in the docs: https://tedana.readthedocs.io/en/stable/multi-echo.html#processing-multi-echo-fmri

That repo looks like it's doing spatial concatenation where all echoes are separately inputted into the ICA (like in the original version of MEICA, but with a better tensor ICA approach). This has been a busy couple of weeks for me, but I (or someone else) might to reach out to the repo author to see if they want to be more connected to the tedana community.