Calculating framewise displacement


I’m processing resting-state scans and want to compare framewise displacements pre and post preprocessing as a proof-of-concept that my motion censoring worked. In AFNI, how do I calculate framewise displacement POST preprocessing - on my finalized nifti - without performing any analysis other than the calculation of fwd values from TR to TR in the scan?


Hi, Stephanie-

I’m having a little bit of difficulty picturing this post-processing…

To calculate FD, you would use values from 3dvolreg, which calculates alignment between each EPI volume and one chosen reference EPI (typically the MIN_OUTLIERS one). This is typically performed as an early step of preprocessing, so that much should be fine. Also, for some commentary on the FD quantity itself (and some of its perhaps non-ideal qualities), please see:,153571,153578#msg-153578,148852,148854#msg-148854

When it comes to running 3dvolreg on processed data, well, by definition the volumes should be registered as well as they can be according to 3dvolreg. So, wouldn’t the displacement values be pretty much zero? (Note that this doesn’t mean that all relative motion is gone-- it’s just gone as much as the solid body parameter estimation with the particular cost function could approximate.) Your EPIs will likely have been warped to standard space by that point-- that might result in some new alignment features, however they should still essentially have no differences via 3dvolreg because the same EPI->anat and anat → standard space transforms would have been applied to each of the already registered volumes.

Am I missing something about the post-processing aspect?



No, that’s exactly right - the post-processing fwd should indeed be close to 0. I want the numerical proof of this to, for example, make a pretty bar graph showing a pre-processing difference in fwd between groups and a post-processing lack of difference in fwd between groups. I’ve successfully calculated this in multiple other pipelines; however, I’m new to AFNI and can’t figure out how to calculate fwd post-processing in AFNI. (The command we used to calculate fwd earlier in our pipeline before preprocessing is an FSL command that isn’t working when I try to use it post-processing - AFNI’s 3dDeconvolve is the last step of our pipeline, and its output doesn’t play nicely with the FSL command and is giving me obviously wrong results).

I just want to calculate fwd on the output of 3dDeconvolve though, nothing else. I’m looking up 3dvolreg that you suggested - it looks like it performs other functions though? Sorry, again, I’m new to AFNI - how do I use 3dvolreg to just take an input file and then output fwd?


3dvolreg will give you the translation (in mm) + rotation (in deg) parameters registering to a particular volume.

An example of running 3dvolreg from the AFNI Bootcamp demo (from the command in AFNI_data6/FT_analysis/s05*) is approximately (using a tcsh syntax for defining a variable “$run”, which you certainly don’t need to use; note that the AFNI command is agnostic to shell, beyond syntax):

set run  = 1

3dvolreg                                               \
    -verbose                                           \
    -zpad 1                                            \
    -base REFERENCE_BASE_VOL                     \
    -1Dfile dfile.r$run.1D -prefix rm.epi.volreg.r$run \
    -cubic                                             \
    -1Dmatrix_save mat.r$run.vr.aff12.1D               \

… where you can specify which volume you want to be the base for registration by choosing an index [n], where n=0,1,…, N-1 for N total volumes. When running, actually we usually recommend specifying the “minimum outlier volume”-- in your case, you can probably just pick “0” for your requirements, since you want framewise displacement, anyways.

The above command produces a set of motion corrected volumes “rm.epi.volreg.r$run”, and a 6-column file “dfile.r$run.1D” of the 3 translations and rotations, as noted above. I think by framewise displacement, you want the derivative of these, then-- the difference of the total motion estimate should give the differential between volumes?
That can be calculated with -infile dfile.r${run}.1D -derivative -write fwd.r${run}.1D

so for i = 1,…, N-1, the [i]th value from the original matrix X = {X[i,j]} is X[i,j]-X[i-1,j].

Is that all you need for your calcs? If you wanted to sum across the absolute value of the 6 motion parameters per TR, then you could do this to dump the numbers to the screen or a text file:

3dTstat -abssum -prefix - fwd.r${run}.1D
3dTstat -abssum -prefix - fwd.r${run}.1D > fwd_abssum.1D

or, to save it in a variable

set mmm = ( `3dTstat -abssum -prefix - fwd.r${run}.1D` )

(please check the numbers that should actually be calculated…)


Thanks for the thorough information! I’ve used the 3dvolreg output and calculated framewise displacement from that (I realized that the roll/pitch/yaw measurements needed to first be converted from degrees to mm, and then the absolute value of the derivatives could be summed and then averaged across the run), so the how-to step is no longer an issue. However, I believe there’s still a problem -

As a sanity check, I calculated the fwd as above at several points in preprocessing (and compared the output to a different program’s calculation of fwd; they are similar). Before preprocessing, there’s roughly 0.1 mm of motion, as expected. Up until the very end of our preprocessing, there’s also the expected amount of motion (lower than the raw amount, but not as low as it should be once censoring and motion regression are performed).

The very last step of our pipeline uses 3dDeconvolve and 3dTproject to simultaneously regress out nuisance regressors (motion params and wm, csf, gs and their derivatives) and perform bandpass filtering and censor out any outlier time points. Calculating fwd after this one final step results in absurdly high, obviously incorrect fwd values (for example, 15 mm). I’ve used several programs to calculate fwd at this step and they all give similar, strangely high fwd output measures. Thinking it was something about the censoring, I ran an edited 3dDeconvolve/3dTproject that did both bandpass filtering and nuisance regression but not time point censoring, and I get incorrect values that are even higher (since outlier censoring wasn’t included).

So it seems that I’ve narrowed down that there’s something specific about this 3dDeconvolve/3dTproject step that’s messing with the 3dvolreg calculations. Why is this happening? Is there some other way I can obtain accurate fwd measurements after this final step? I’m expecting an fwd of around 0.009… (again, this is for a proof-of-concept that our efforts to scrub out motion were successful, and I’m expecting an extremely low value of fwd so that I can compare our pre- and post- preprocessing measures of fwd).

I’d appreciate any thoughts! Thanks so much!

Edit: Side note, the output of 3dDeconvolve I’ve been using as an input to 3dvolreg is the -errts output… now I’m wondering if this should actually be the -fitts output instead?? (I’m new to AFNI and figured it couldn’t hurt to double-check!) Tutorials I’ve found seem to indicate that in rsfMRI analyses with 3dDeconvolve, since you enter things you DON’T want (i.e. motion) into the model, the errts is the file you DO want to look at for the output. So now if ftts is the FITTED time series does this mean that all accurate motion-related estimates are therefore in the ftts output? As in, I want to use errts output in my analyses (i.e. seed-based analysis), but I want to be using the ftts output if all I want is an estimate of the fwd?