I am using 3dbandpass for resting state analysis and I realized that the output time series is zero in lots of places. can this behavior be avoided?
below is what is printed to screen
++ 3dBandpass: AFNI version=AFNI_16.1.06 (Apr 19 2016) [64-bit]
++ Authored by: RW Cox
++ Data length = 7680 FFT length = 7680
- bandpass: ntime=7680 nFFT=7680 dt=2.5 dFreq=5.20833e-05 Nyquist=0.2 passband indexes=192…1920
++ Loading input dataset time series
++ Number of voxels in automask = 31784
++ Checking dataset for initial transients [use ‘-notrans’ to skip this test]
- No widespread initial positive transient detected
++ 7680 dimensional data reduced to 3457 by:
4222 (bandpass), 0 (-ort), 0 (-dsort), 1 (detrend)
++ Bandpassing data time series
++ Creating output dataset in memory, then writing it
Rick can elucidate more on this point, but basically: if you want bandpassing in your resting state processing (i.e., frequency removal, leaving a certain band interval), then you should do so by regressing out the frequencies you don’t want during your main regression of nuisance terms (motion, slow trends, etc.). Mathematically, regression out of frequencies is equivalent to Fourier bandpassing-- in this case, the former is more useful for getting rid of the frequencies when you are also getting rid of other things (low freq polynomial trends, motion regressors, etc.). You can also manage the regression-based ‘bandpassing’ in a consistent manner in the presence of censored time points, which I think was at the heart of your question; it would not really be possible to do Fourier-based bandpassing processing when there are censored points present (and there are other mathematical problems with alternating nuisance regression and bandpassing separately).
In general, I would recommend setting up your desired processing with afni_proc.py anyways. You can check out Ex 9 of the afni_proc.py help for usage of bandpassing. Though, as a caveat, you should also read the afni_proc.py help for caveats about applying bandpassing with some other forms of motion regression/processing, such as RETROICOR.
Also note that it may not be imperative to bandpass your resting state data at all; several groups (e.g., Gohel & Biswal, 2015) have found useful signal (i.e., signals that show known functional networks) in frequencies that are typically above standard LFF maxima (i.e., >0.1 Hz). Bandpassing also has the negative of greatly reducing the degrees of freedom in your data, so it’s not a ‘cost free’ processing step (well, no processing step is cost free…).
Thanks Paul for the thorough explanation.
But what I wanted to know is that why 3dBandpass is setting some voxels to be zero at all times after filtering. I am using the errt time series which has fluctuation in all the voxels that are being zeroed in the output. I realize that if I don’t use -automask option this does not happen. could this be a bug in the code?
I’m going to guess that yes, automasking is masking out regions, perhaps those with very small initial values. If you run 3dAutomask on the data separately, are those same locations masked out?
Automasking is for trying to guess internally whether regions are inside/outside the brain, and so if initial values are small somewhere compared to others, those entire time series might get masked out.
I would probably recommend 3dAutomasking a different data set that doesn’t have fluctuations in values related to time series and then apply the mask when you are bandpassing. Otherwise, regions might get ‘masked out’ just because they have small initial values.
(This is speculation; if you want to upload a data set, then please do so and let me know, so I’ll look at it.)
Yes you are right. if I automask my errts time series I get zeros in the same regions. This time series is already masked coming out of 3dDeconvolve. So I didn’t need to mask it again but I thought it doesn’t hurt to redo automask, better safe than sorry right? not really… thanks for the insight
The automask operation looks for a contiguous blob
of high intensity voxels to call “brain”. In the errts
dataset, every voxel has a mean of zero, so automask
is not appropriate on a residual time series.
Thanks Rick, do you think this point is worth adding to the 3dAutomask and -automask option help in various functions?
Sure, at least for 3dAutomask. But the ‘and’
part is the key, and is messier, because the
automask functionality can be invoked from
Anyway, I will take a look.