3dDeconvolve not enough parameters error

Dear all,

I am running afni_proc.py on resting state data and in my regression model I’m specifying motion censoring (i.e “scrubbing” for enorm values exceeding 0.3 mm) and temporal filtering (0.01-0.1 Hz). Unfortunately 3dDeconvolve is failing to run for many of the subjects in my study. I’m aware that this is a consequence of censoring as it decreases the amount of data available to run the regression analysis. I looked at the data, and it seems subjects are failing even when 70% of the data survives (a total of 147 volumes for each subject). I am wondering if this is usual or if I’m doing something incorrect. Is there any other way to get around this? I understand 0.3 mm is actually not much of a stringent limit.

Regards,
George

Hi George,

I wouldn’t quite say this is a consequence of censoring,
as the principle culprit is likely band passing. What is
your TR? And how many time points are you staring with?

Well, since you say that subjects start failing at about
70%, I will guess that your TR is 2s, and you have on the
order of 160 time points.

Most people ignore the fact, but for a TR of 2s, the cost
of bandpassing is 60% of the degrees of freedom up front.
If censoring costs another 30% and motion, derivatives,
and polorts cost another 10% (~16 regressors), there goes
100% of the degrees of freedom. And it can get worse…

And to put it another way, if the typical subjects has
only 15% of the time points censored, then they will be
left with about 15% (24?) degrees of freedom for the
correlation analysis. That is not a lot.

For these reasons, I consider band passing the main
culprit.

  • rick

Thank you Rick.

I am starting out with 147 volumes and TR is 2s. The error message points out that there are 108 parameters to estimate.

What is a possible way around this? I know it’s not optimal, but it seems most studies censor before applying a regression model that includes both a temporal filter and nuisance variables. Would that make a difference?

An other possible option is to perform temporal filtering at the very end, after the data has been censored and regressed.
Just wondering if the order of the steps can make any differences.

Regards,
George

The “way around this” is not to bandpass. Or to gather significantly longer imaging runs.

Thank you.

I was additionally thinking of rather than actually deleting the volumes, I could put in a regressor file with a dummy variable (0 for volumes above threshold and 1 for those that are not) in the regression model. The volumes could be deleted then after temporal regression if needed.

I am wondering what do people think about this approach. Really appreciate the help.

The two methods are mathematically equivalent – eliminating the time point from the data and from the regression matrix, or adding a bunch of regressors that are all 0s except a single 1 at the to-be-censored time point. Only a tiny difference should result from trying one method or the other.

The brutal fact is that subjects who move too much produce data than cannot be safely analyzed.

Hi Rick,

Just to follow up on this, I’m noticing that when I run the afni_proc.py script I am getting the following warning:

“*+ WARNING: Input dataset is not 3D+time; assuming TR=1.0”

after 3dTstat is called. I am wondering if this has any influence on how the bandpass filtering later, as the TR is 2 seconds.

Thank you,
George

Hi George,

That warning comes up in a couple of places for good
reason, so I would have to see the actual command in
question to know whether this is appropriate.

Do you know where that message comes from? The
text output should be saved to a file, hopefully.

  • rick

Hi Rick,

These are the instances when the warning message is coming:

set minindex = 3dTstat -argmin -prefix - outcount_rall.1D\'
3dTstat -argmin -prefix - outcount_rall.1D’
++ 3dTstat: AFNI version=AFNI_17.2.02 (Jul 10 2017) [64-bit]
++ Authored by: KR Hammett & RW Cox
*+ WARNING: Input dataset is not 3D+time; assuming TR=1.0
set ovals = ( 1d_tool.py -set_run_lengths $tr_counts -index_to_run_tr $minindex )

3dmaskave: AFNI version=AFNI_17.2.02 (Jul 10 2017) [64-bit]
+++ 49188 voxels survive the mask
3dTstat -sos -prefix - gmean.errts.unit.1D’
++ 3dTstat: AFNI version=AFNI_17.2.02 (Jul 10 2017) [64-bit]
++ Authored by: KR Hammett & RW Cox
*+ WARNING: Input dataset is not 3D+time; assuming TR=1.0

1d_tool.py -infile X.nocensor.xmat.1D -show_indices_interest
3dTstat -sum -prefix sum_ideal.1D X.nocensor.xmat.1D[0…$]
++ 3dTstat: AFNI version=AFNI_17.2.02 (Jul 10 2017) [64-bit]
++ Authored by: KR Hammett & RW Cox
*+ WARNING: Input dataset is not 3D+time; assuming TR=1.0
++ Output dataset ./sum_ideal.1D
1dcat X.nocensor.xmat.1D[0…$]

My TR is 2s, I am starting with 147 volumes. The regressor file for bandpass filtering has 90 different regressors (90 regressors). In the log, it says it attempts to estimate in total 108 parameters.

So it does seem that the main issue is with bandpass filtering rather than motion for a lot of the subjects.

I did try to run the regression analysis without actually censoring volumes but I included a regression file with 1’s for volumes that stay and 0’s for ones that can be ignored. The analysis finishes, even for subjects where a lot of the volumes would have been deleted. Just wondering what do you think about this approach. The volumes can be deleted after the regression/band pass filtering step, and I believe regression with the censoring parameters would not smear motion artifacts through out the timecourse when bandpass filtering is performed.

Thanks a lot for your help on this.

Regards,
George

Hi George,

Those messages come from running 3dTstat on 1D files, and
those files do not have a TR attached (though that is their
temporal grid). So those warnings are expected and are OK.

The issue is a combination of band pass filtering and motion
censoring. To me it makes more sense to censor and not band
pass. Keeping the censored time points in for the band passing
and regression step should indeed smear the motion around in
time.

Actually, it is not clear what method you are suggesting,
whether censoring would be applied in the regression or not.
But the appropriate way to do this step is at once.

You could raise the motion threshold for censoring. But when
giving up 60% of the data to band passing (~90 regressors for
147 time points), the choices are limited.

  • rick

The issue is that the aim is to do seed-based analysis, and afaik bandpass filtering is a requirement. What I was suggesting is to include a regressor in the regression analysis for the volumes to be censored without actually removing the timepoints during regression. I do not know however if bandpass filtering in that case would still be valid.

Thank you for your help,
George

Not everyone band passes for a seed-based correlation analysis.
Any “requirement” is up to reviewers, and a description of the cost
in terms of DoF should be convincing. The issues you are running
into are not special, basically everyone should see them.

Of those that do band pass for this, it seems likely that the majority
do not censor (a bad idea), do band passing incorrectly (very
common), or try to cheat the system by faking data or something.

Some people are expanding the pass bands, e.g. keeping the
frequencies between 0.01 and 0.2, which basically doubles the
DoF one has to work with (over using 0.1).

Note that with shorter TRs, this problem actually gets worse.

  • rick