Filters in functional preprocessing should be orthogonal

[miykael]

The Linquist paper about "Modular preprocessing pipelines can reintroduce artifacts into fMRI data" shows that subsequent filters in fMRI analysis should be orthogonal.

The problem is, that preprocessing steps performed at a later stage of the pipeline can potentially reintroduce artifacts that had previously been removed from the data in an earlier step.

We note that the issues discussed in this paper can be circumvented in two ways. The first approach would be to abandon the modular approach to preprocessing the data, and instead use a joint approach that simultaneously performs the different preprocessing steps within an omnibus framework. For example, it would be relatively straightforward to formulate a single linear model that simultaneously performs motion regression, nuisance regression, and temporal filtering. [...]
The second approach is to formulate the design matrices used in each preprocessing step in such a manner that when applied sequentially they are constrained to project onto orthogonal subspaces. For example, if motion correction is performed after temporal filtering, the columns of the design matrix used in the motion regression should also be temporally filtered in a similar manner to ensure the data is projected onto an orthogonal subspace. The general rule-of-thumb is that one must orthogonalize both the data, and all subsequent projections to maintain data orthogonality with the current projection.

The current version of fmriflows doesn't orthogonalize filters:

• Motion correction is followed by temporal filtering (without filtering motion regressors before they are applied)
• Also, CompCor components, FD, DVARS, and Friston24 components are estimated without considering temporal filters or each other as well.

This is problematic, but Linquist also mentions that the second approach often is already implemented in task fMRI studies, as their GLM include motion regressors and high-pass filters. But fmriflows wants also to give the option of low-pass filtering, which would need to be considered in the later GLM.

I'm not sure yet how to best tackle this issue, but it's clear that it needs to be addressed. The smoothest approach would be to put everything into a GLM, but this would imply to not perform motion correction. It would require that users understand this issue and setup the GLM correctly.

[miykael]

Additionally, I'm not sure how to do low-pass filters in a GLM. I think high-pass can be achieved with cosine filters (DCT), but I don't know how to specify the cosine filters for low-pass.

[miykael]

I think I'm getting there... So, CompCor, FD and DVARS are just estimations, while motion correction and temporal filters actually change the data.

Orthogonality between motion correction and temporal filters

Therefore, the motion parameters used for motion correction should first be temporally filtered. That should take care of their orthogonality. This is especially important in the context of high temporal resolution fMRI, (see Scheel et al., (2014)).
Also, if users don't want to apply a high-pass filter on their data, but only specify it in the GLM, then the motion correction will be as usual.

Open Questions

1. What's the correct order concerning the Friston24 components? First, compute Friston components, then apply temporal filters or reversed?
2. Should FD be computed on temporally filtered motion parameters or not?
3. CompCor, DVARS and the extraction of average signal (GM, WM, CSF) is computed on realigned files, should I remove motion artifacts afterward?

[miykael]

PR #20 takes care of many questions in this section. At the current standpoint, I believe that fmriflows implements the ideal combination of filtering and motion correction.