Highpass filter in fmriprep

Does fmriprep highpass filter the data at any point during the preprocessing? This is my fmriprep call:

fmriprep-docker /home/user/BIDS/data /home/user/BIDS/derivatives participant --participant-label sub-001 --fs-license-file /home/user/freesurfer.txt --ignore slicetiming --use-aroma

The outputs are not highpass filtered. The CompCor decompositions are performed on a highpass filtered version of the data, so CompCor components should only be used in addition to the cosine regressors.

See https://fmriprep.readthedocs.io/en/latest/outputs.html#confound-regressors-description, subheading " CompCor confounds".

1 Like

Thanks @effigies. I intend to bandpass filter the *_desc-preproc_bold.nii.gz data, so that file should not be highpass filtered right?
By the way, why is highpass filtering employed before running CompCor?

It is not filtered. If you’re asking about the consequences of double-filtering, they’re probably not severe, as long as your second pass-band lies within the first and the overall properties of the two filters are similar, but I agree that it’s better not to.

1 Like

@effigies, can I follow up on this thread because I’m still confused if I should do high-pass filtering or not?

I would like to include the CompCor regressors for denoising and I’m aware I should also include cosine regressors. My question is, is adding the CompCor and cosine regressors from fmriprep equivalent to denoising using my own CompCor regressors (calculated using nonfiltered data) and high-pass filtering in the same GLM (for example with 3dTproject)?

No. If you don’t high-pass filter before calculating CompCor, your components will be different because they will not be forced to be orthogonal to the low frequency drift components.

If you choose the number of components by variance explained, then it’s possible that you’ll end up at a conceptually comparable result, but they would not be equivalent.

This isn’t to say that calculating CompCor without high-pass filtering is incorrect; there’s no ground truth here.

Thanks @effigies. Then let’s say I use fmriprep’s CompCor regressors as well as cosine regressors in denoising. Will linear drift and other low-frequency noise be removed from the output of my denoising by adding the cosine regressors? Or will I need to perform high-pass filtering in addition if I would like to remove those low-frequencies?

Yes. Inclusion of the cosine filters in the denoising is a high-pass filter.

1 Like

hi @effigies. a related question to this thread.
I want to include CompCor in my models but am using SPM which already includes cosines as a part of the model by default. I can see 2 reasonable options of how to do that:

  1. Take the fmriprep cosine and ask SPM not to perform HPF
  2. Match the SPM harmonics to those used by fmriprep (or make sure they have a lower cutoff frequency).
    For both solutions it will be helpful to know what frequency is used by fmriprep.

We use a 128s cutoff. I think this is (or was) the SPM default at one point, so it probably makes very little difference (cosines are pretty well defined). If you have non-steady-state volumes, you’ll need to account for that. Using the fMRIPrep regressors includes this already.

What if I do not calculate CompCor or do not use compcor regressors, can I still use cosine regressors for high-pass filtering during denoising, or is one always dependent on the other?

If you don’t use CompCor, then you have no obligation to use that particular high-pass filter, but you may.

Thanks @effigies. One related question, I noticed that running cosine_drift function outside fmriprep will create more regressors than those included in the confounds file generated by fmriprep.
How does fmriprep come up with the final number of cosine_XX regressors that are included in the tsv confounds file?

We use a 128s high-pass cutoff. This along with the TR and number of volumes (excluding dummy scans) will determine the number of regressors.

But what is the formula? How is this calculated, let’s say with a TR of 2, 450 volumes and 128s high-pass cuttoff?

The implementation is here:

thanks @effigies. However, this function returns a 450x450 array whereas the fmriprep confounds tsv file only contains a few cosine_XX columns. My question is rather how does fmriprep decide how many columns to extract from that 450x450 array.

This function should not return a 450x450 array. What’s your TR?

@effigies my TR is 2, number of volumes is 450. I just copy-pasted the function into python and ran _cosine_drift(2,range(450)). The output is a numpy array with size 450x450.

In [1]: import numpy as np

In [2]: from nipype.algorithms.confounds import _cosine_drift

In [3]: period_cut = 128

In [4]: frametimes = np.arange(450) * 2.0

In [5]: cdrift = _cosine_drift(period_cut, frametimes)

In [6]: cdrift.shape
Out[6]: (450, 14)
1 Like