> i'd like to pose a question to the community in an
> effort to understand the current thinking regarding
> acceptable levels of motion in epi data what to do
> about it (i.e. guidelines/methods for deciding which,
> if any, scans to omit from analysis; including motion
> parameters as regressors of no interest, etc).  of
> course, looking at one's data is the best tool for
> assessing motion and its effects on any given dataset.
>  that said, i'd like feedback on more objective
> methods, and welcome any thoughts anyone cares to
> offer on the topic. i'll start with a few questions:
>
> 1) some suggest that intrascan movement is
> particularly difficult for most registration
> algorithms to handle, and that estimating
> translational motion from one scan to the next is an
> appropriate method for quantifying intrascan movement.
>  someone suggested that any scan for which translation
> exceeds 20% of voxel size should be removed from
> analysis.  i'm not sure where that number came from,
> but does this sound like a reasonable method of
> objective evaluation?

This is a model order selection issue, and will depend on the type of movement
involved.  Rotations may be more serious than translations, as these interact
more with the image distortions and other artifacts.  Also, any through-plane
translations could be more detremental than translations within plane.

>
> 2) are there any similar thoughts on what would be
> considered unacceptable levels of rotation, in terms
> of degrees?  is there a similar calculation to that
> described above in #1 to quantifying it?

It's hard to say.  If your scans are artifact free (and the brain is not
slopping about in the skull), then any amount of rotation or translation
would be acceptable.  I prefer to turn these questions around, and ask how
valid the data are with respect to the model that will be applied to them.

>
> 3) how should task-correlated motion be dealt with?
> is some degree of correlation to be expected, given
> that in most paradigms, subjects are required to make
> some kind of overt response?

Task related motion should be dealt with in pretty much the same way as any
other confounding effect in the statistical model.  If you don't model the
confound, then you accept that the significant differences you see could be
explained by the confound.  If you do model the confound, then you risk any
real effects being explained away by the confound.

>
> 4) what are peoples thoughts on including motion
> parameters as regressors of no interest?  i know that
> some include motion parameters as regressors of no
> interest for each subject as a matter of course, while
> others include them only for subjects who have
> particularly problematic motion, or where it seems to
> improve statistical results.  would those of you who
> do so be willing to post a brief message about the
> pros and cons of your method of choice?

Estimated movement parameters can be included as confounds within the model.
It is a sad fact of life that if the task (after convolving with the HRF) and
movement are correlated, then there is no way (within the current framework)
to clearly seperate artifact from activation.

Another effect is that is there is very little motion, then much of the
variance in the estemated movement may be due to activations.  By including
estimated motion parameters within the model, you may find that most of the
real activations can be explained by the estimated motion.  You could try
http://www.fil.ion.ucl.ac.uk/spm/ext/#INRIAlign for getting around this
problem.

The ideal attempt at a solution would be to fit a Bayesian generative model
that includes subject movement, fMRI artifacts, and the model of activation
within the same framework.  This may become part of some later SPM release,
but some other package will probably get there first (it is not an especially
glamorous area of research).

>
> 4a) what are your thoughts about using just some, but
> not all motion parameters as regressors of interest?
> i.e. should it be all or none? can one include just
> translation, or just rotation?  or include just one
> axis if is it looks problematic?

This is likely to depend on your data.

>
> hopefully i'm not alone in pondering these issues and
> your answers will be useful to others as well.  thanks
> in advance for any feedback you can offer.

Many of us will ponder them, but have not come up with any really good
solutions that work for all cases.  This is why I've kept my answers
deliberately vague.

Best regards,
-John