Apologize if this question is too simple but just wanted to make sure I wasn’t missing anything. I’m trying to create bandpass regressors for use in 3dDeconvolve, and would like to highpass filter at 0.01 Hz, would this be the correct way?

1dBport -nodata 525 0.8 -band 0 0.01 > bandpass_rall.1D

It appears correct based off the afni.proc.py forum:
“The first example provides basis functions to filter out all frequency
components from 0 to 0.25 Hz:
1dBport -nodata 100 1 -band 0 0.25 > highpass.1D”

Update, so I got some varying results from doing different things and just changing the 1dBport command, would anybody be able to help understand discrepancies? I feel like Examples 2,3, and 4 should be identical but they are not, and I’m not really understanding why. Thanks for your help!

Example 1
1dBport -nodata 525 0.8 -band 0.01 0.1 -invert -nozero > bandpass_rall.1D (original)
++ 3dDeconvolve extending num_stimts from 12 to 458 due to -ortvec
++ 3dDeconvolve: AFNI version=AFNI_17.1.10 (Jun 6 2017) [64-bit]

++ 525 retained time points MINUS 462 regressors ==> 63 D.O.F. left

Example 2
1dBport -nodata 525 0.8 -band 0.01 5100000 -invert -nozero > bandpass_rall.1D
3dDeconvolve extending num_stimts from 12 to 18 due to -ortvec

• – 22 other fixed ort regressors
++ 525 retained time points MINUS 23 regressors ==> 502 D.O.F. left

Example 3
1dBport -nodata 525 0.8 -band 0.01 5300000 -invert -nozero > bandpass_rall.1D (similarly for the 999… example you had given me and anything above this number)
++ 3dDeconvolve extending num_stimts from 12 to 534 due to -ortvec
++ 3dDeconvolve: AFNI version=AFNI_17.1.10 (Jun 6 2017) [64-bit]

++ 3dDeconvolve extending num_stimts from 12 to 534 due to -ortvec
++ 3dDeconvolve: AFNI version=AFNI_17.1.10 (Jun 6 2017) [64-bit]
++ Authored by: B. Douglas Ward, et al.
++ STAT automask has 542807 voxels (out of 542850 = 100.0%)
++ Skipping check for initial transients
++ Imaging duration=420.0 s; Automatic polort=3
++ Number of time points: 525 (no censoring)

• Number of parameters: 538 [538 baseline ; 0 signal]
** FATAL ERROR: 3dDeconvolve dies: Insufficient data (525) for estimating 538 parameters

Example 4
1dBport -nodata 525 0.8 -band 0 0.01 > bandpass_rall.1D
++ 525 retained time points MINUS 24 regressors ==> 501 D.O.F. left

Hi, sorry to bother all, but just wanted to see if anyone had feedback regarding this? Thanks.

Hi-

Sorry, things are slow around holiday time.

… and this is going to be a loooong message, because there are a lot of considerations here-- my apologies.

Before addressing the mechanics of bandpassing, I want to comment on some consequences of bandpassing, in terms of your GLM and allowed degrees of freedom. If you set up your problem to bandpass to keep only frequencies between 0-0.01 Hz, that will be quite problematic if you are including other things in the model, because you will run out of degrees of freedom (DFs).

If you have N time points in your time series, you start with N DFs. Every time point you censor, you lose 1 DF, and every regressor you put into your model, you lose 1 DF.

Bandpassing can be done by including frequencies in the regression model-- which you are doing. In a uniformly sample, finite time series (=FMRI data going into the model), there are frequencies ranging from 0 to the Nyquist frequency, where the Nyquist frequency f_N depends on your TR; essentially, f_N = 1/(2*TR). So, if your TR = 2 s, then f_N = 0.25 Hz. The frequencies are discrete, too. To censor a frequency in the GLM, you have 1 cos and 1 sin of that frequency. Going back to our counting of DFs, when you “bandpass” out a frequency in the GLM, you lose 2 DFs.

Now, to your case: you can approximate the number of DFs you lose with a bandpass in the following:

• Say you are keeping frequencies between fbot (bottom freq) and ftop (top freq), and these are in the range [0, f_N].
• Then, the fraction of DFs you keep is approx: (ftop - fbot)/f_N.
• And the fraction of DFs you lose is approx: 1 - [(ftop - fbot)/f_N].
• If ftop >> fbot, then you can approximate the loss as: 1 - ftop/f_N = 1 - (2 * ftop * TR).
• Note: from this last relation (though it is true in general, too), if you bandpass through a given range and decrease your TR, then you purge more DFs.

In standard RS-FMRI, people might have TR=2s, and bandpass to keep 0.01-0.1 Hz, then you are losing:
1 - (0.1 - 0.01)/0.25 ~ 1 - 0.1/0.25 = 1 - 0.4 = 0.6
… which means you are losing 60% of your DFs, just by bandpassing. (And you will almost certainly lose more with baseline regressors, motion regressors, and motion censoring.) That is a big loss.

Now, in your case, if you have TR = 2s. then bandpassing to keep freq between fbot=0 and ftop=0.01 Hz, leads to losing:
1 - (0.01 - 0)/0.25 = 1 - 0.01/0.25 = 1 - 0.04 = 0.96
… means you are losing 96% of your data (!!!). That is why you are getting the errors you are seeing in many cases: you are using up too many DFs in total. The modeling won’t let you set up a model that asks to over-use the available DFs (which is N, to start).

To do “high pass”, which means getting rid of low frequencies and keeping everything above a certain value, then you specify your “fbot”, and make your “ftop” the f_N or higher. For example, you could have your fbot = 0.01 and ftop = 999 (and the program should chop of ftop at the Nyquist frequency).

Note that often the reason for “high pass” filtering like this is to put a regressor in the model for low frequency, slow baseline drift. There are multiple ways to do this: I think SPM processing tends to use this “high pass filtering”, which is probably fine. In AFNI, we tend to use low order polynomials in the model. I don’t know that it makes that much difference, but there you have it.

It seems you are basically using 1dBPort to make the set of regressors to purge from your data.

Ex 1:

``````
1dBport -nodata 525 0.8 -band 0.01 0.1 -invert -nozero

``````

… You have 525 time points, TR = 0.8 s (so f_N = 0.625 Hz), and you are making regressors <0.1 Hz and >0.1 Hz to put in your model, for bandpassing. According to the above rule, I think you are removing:
~ 1 - 20.10.8 = 1 - 0.16 = 0.84
… so you are purging 84% of your DFs right off the bat. You see that in the message:

``````
++ 525 retained time points MINUS 462 regressors ==> 63 D.O.F. left

``````

… where you are actually losing 88% of your DFs in total, I assume because you have other regressors in your model, too.

Ex. 2:

``````
1dBport -nodata 525 0.8 -band 0.01 5100000 -invert -nozero > bandpass_rall.1D

``````

Here, you are making regressors of a different range, just <0.01 Hz, which are very few (though your ftop is reaalllly unnecessarily large; it just needs to be > f_N). Within the program, your fbot = 0.01 and ftop = f_N, so we can see the loss is:
1 - (f_N - 0.01)/f_N = 1 - 1 + (0.01 / 0.625) = 0.016,
—> so you are only purging about 1.6% of your data from bandpassing (= about 8 DFs), which is consistent with this message:

``````
++ 525 retained time points MINUS 23 regressors ==> 502 D.O.F. left

``````

Ex 3:

``````
1dBport -nodata 525 0.8 -band 0.01 5300000 -invert -nozero > bandpass_rall.1D

``````

… should, in theory, be the exact same as Ex 2, but the “ftop” number here is so big (5300000), that it appears to be breaking the input reading somehow-- it appears to be being treated as if ftop=fbot; that is, no regressors are made, just 1s. Why are you using such a large number? I don’t think you should be using that large-- ftop just needs to be bigger than f_N to have it be “maximal”.

Ex 4:

``````
1dBport -nodata 525 0.8 -band 0 0.01 > bandpass_rall.1D

``````

… which means make regressors just within fbot=0 and ftop=0.01, with no inversion. This should be approximately the same as Example 2, with the difference coming from the value of freq = 0.01 Hz being included in the “made” regressors here, but the value freq = 0.01 Hz not being included within Ex 2, the way the inversion is done, basically whether 0.01 is within the range of bandpassing (case in Ex 4) or whether it is not (case of inversion in Ex 2).

–pt

That overflow problem in the top frequency has been fixed, which should be reflected in the next build.

Thanks for pointing it out.

• rick

What about the overflow problem in me writing too-long-of-responses?

–pt

I wouldn’t know of such a problem, my ptaylor filter blocks most of your text… • r

It still amazes me that that was the first function that Bob put into the AFNI code over 25 years ago… He was so prescient.

–pt