Bob and Gang had good replies. But to be sure, do you intend to get a single beta weight for each of the 700 stimulus images? And so each stimulus type would only have a single event across all runs, is that correct? I hope so, since the long subsequent thought process assumes it... :)


If that is true, then the betas should be unaffected whether the regression is done per run, per session, or across all sessions at once. That is because there should be no regressor that spans (is non-zero for) more than a single run, and scaling is done per run (in afni_proc.py). The difference would be in the t-stats, as mentioned by others, based on whether noise is pooled.

Assuming you do not care about per beta t-stats, then there is no reason to require a concatenated regression.

The one aspect that would vary across these methods is registration, and that would indeed lead to different results. Choices:
1. register each EPI volume to a single EPI base (probably bad)
2. register each EPI volume to a per-run base, and then align bases across runs/sessoins (probably still not good enough)
3. register each EPI volume to a per run base, and then either:
3a. align that base to the anatomy
or
3b. align that base to a session base, and then to the anatomy

Choices 1 and 2 are where (if done by afni_proc.py) the regression would be modeled on the concatenated data, which for registration purposes does not seem like a good idea in the first place.

Which is preferable between 3a and 3b is not clear. It depends on quality of the EPI images, but either method seems reasonable.
But getting back to afni_proc.py and registration, method 3a could be done by running afni_proc.py once per session. Method 3b could be done by running afni_proc.py across all sessions at once, leading to a concatenated regression model and RAM issues.

That means choice 3a (running afni_proc.py once per session) might be both reasonable and feasible.

Anyway, is this true, that you will only have one event per class?

- rick