[pymvpa] Preprocessing in FSL, question on specifics

Yaroslav Halchenko debian at onerussian.com
Wed Jul 13 03:17:17 UTC 2011

hm, I don't think they would add such additional regularization since then
someone would need to choose the optimal/sensible hyperparameter to balance
between "goodness of fit" and "how far has it moved"... and I do not see any
such regularization term exposed by mcflirt... moreover it would be somewhat
defeating the purpose -- detecting actual motion in addition to slow

ok, since nothing left (besides understanding quite a bit of mcflirt C++ code),
reverting to the documentation of mcflirt:


       MCFLIRT loads the time-series in its entirity and will default to the
    middle volume as an initial template image. A coarse 8mm search for the motion
    parameters is then carried out using the cost function specified followed by
    two subsequent searches at 4mm using increasingly tighter tolerances. All
    optimizations use trilinear interpolation.

       As part of the initial 8mm search, an identity transformation is
    assumed between the middle volume and the adjacent volume. The transformation
    found in this first search is then used as the estimate for the transformation
    between the middle volume and the volume beyond the adjacent one. This scheme
    should lead to much faster optimization and greater accuracy for the majority
    of studies where subject motion is minimal. In the pathalogical cases, this
    scheme does not penalise the quality of the final correction.

so, it is indeed sequential with starting point for optimization for the next
volume using transformation from the previous one (quite logical) but no other
additional constraints are mentioned.  Trusting the above documentation, I am
taking it further into the wilder claim: if their optimization is not prone to
fall into local minimas, quality of mcflirt should remain nearly the same
regardless of the order of volumes (sure thing it would take longer though).
So, it is only for someone to try to prove it empirically (with mcflirt, not
SPM -- we know those results already ;-) )

On Tue, 12 Jul 2011, Michael Hanke wrote:

> On Tue, Jul 12, 2011 at 04:50:04PM -0500, J.A. Etzel wrote:
> > Volume order within a session definitely matters: I had a dataset in
> > which the volumes were entered in the wrong order (due to a
> > numerical vs. alphabetical file naming mixup) and the motion
> > correction was extremely abnormal and poor. Once the file naming was
> > fixed the motion correction looked fine.

> According to my experience, most software uses some sort of running
> guess on the transformation matrix with heavy constraints on the
> translation/rotation magnitude between volume (for speed reasons).
> Reverse order of volumes shouldn't have much of an effect, but random
> order would. For heavy between session motion (maybe people got out of
> the scanner) it might be better to compute a cross-session alignment and
> combine that with within session motion correction. But again, that is
> nothing MVPA specific.

> Michael
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

More information about the Pkg-ExpPsy-PyMVPA mailing list