Andy's Brain Blog

A couple of videos have been posted about multiple regression in SPM, both at the first level and second level. Technically, almost all of the GLMs researchers usually set up use multiple linear regression, where a linear combination of weighted regressors is fit to the timecourse of each voxel. However, in SPM parlance, regressors are distinct from conditions: Conditions are typically convolved with some sort of basis function (usually a hemodynamic response function), whereas regressors are not convolved with anything. For example, someone may enter motion parameters as regressors, since they are not convolved with any hemodynamic shape, but still may account for some of the variance observed in the signal (and, we hope, the signal that is primarily due to motion). Another example would be entering in the timecourse extracted from an ROI to do a functional connectivity analysis, or inserting the interaction term from a PPI analysis as a regressor.

At the second level SPM also gives the option for doing multiple regression; but this is simply the entering of covariates which can be tested for correlations with the signal change in contrasts across subjects. In most cases, however, you can select any other design, and enter in covariates regardless of which design that you choose; which I believe to be the better option, since it is more flexible.

In any case, most of the rest of the details can be found in the following videos. Speak hands for me.

Back in the good old days, we would create our scripts ex nihilo; out of nothingness would we construct gigantic, Babel-esque scripts that nobody - to be honest, not even we - could understand. We would pore over FMRI textbooks and fumble around with commands and tools we thought were germane, only to have everything collapse all around us when it came time for execution. I remember with painful clarity the moment when I finally hit upon the idea of looping over subjects for each iteration of the script; I thought I was a creative genius.

Lawless, ruthless, and terrifying; those days were like the wild west. Nobody knew what the hell was going on; you might come across a block of analysis script posted by some group in Singapore, compare it to your own, and wonder how your two labs could ever come to the same conclusion about anything, given how radically different your scripts were. Your script would call for slice timing correction, followed by coregistration and normalization, while their script would call for a cup of chopped onions and a clove of chopped garlic. Then, slowly, you would realize that what you were looking at was a recipe for chicken cacciatore or something, and you would feel like an idiot. Overall, those days were not good.

Fortunately for us, these days we now have a script called uber_subject.py, which takes care of generating analysis scripts quickly and easily. AFNI script ex machina, as it were. If you have programs and binaries from the past couple of years or so (and there's no reason you shouldn't; if you haven't updated in a while, a quick '@update.afni.binaries -d', without the quotes, should do the trick), you will have uber_subject.py. If you type it from the command line - and your python libraries are current and functional (see here for a message board thread if you have trouble with this) - then a graphical user interface will pop up, prompting you to input parameters such as smoothing kernel size, number of regressors, relationship status, and so forth, until you have a completely idiosyncratic script to fit your needs. Overall it has worked very well for me so far, and word is that it will be integrated with an even higher level script called uber_script.py. I've had some issues getting it to work, so instead of trying to fix it, I have taken the path of least resistance and settled for uber_subject.py. You will be glad that you did as well.