[pymvpa] Preprocessing in FSL, question on specifics

Yaroslav Halchenko debian at onerussian.com
Tue Jul 12 21:02:22 UTC 2011


On Tue, 12 Jul 2011, Mike E. Klein wrote:
>    before being run a second time on the concatenated file. While there is
>    very little head motion within each session, there looks to be
>    considerably more between sessions, which probably comes as no
>    surprise. A test of running motion correction a single time (after
>    concatenation) looks like it does not perform very well: there is still
>    a large amount of motion visible to the naked eye.

ha -- that is interesting to me:  afaik (correct me if I am wrong) motion
correction is just a re-alignment/slicing to a reference 3D volume extracted
(or computed, e.g.  mean of representative volumes), i.e. no temporal
order between volumes should matter...  and now you are getting worse results
if you concatenate them all into a single 4D series (which is what I usually
do, to eliminate double-smoothing/error others pointed out) :

1 reference volume is "bad" (FSL's mcflirt takes the middle volume as the
  reference by default iirc) -- is there lots of motion found from the
  volumes around it?

2 there could be some global factors (non-homogeneous intensity drifts)
  across the runs so that default "normcorr" cost function cannot
  account for them, thus providing bad motion correction.

3 or may be, if you are judging from "motion parameters" plots -- just a
  matter of different scales and having 1 reference volume vs many.

BTW have you ever looked at ARTs:
http://nipy.sourceforge.net/nipype/interfaces/generated/nipype.algorithms.rapidart.html
which could help you to estimate if there are problematic volumes due to
motion (1) or some global (2) intensity jumps which could not be attributed
to the experimental design.

>    As an aside, if I plan to discard some specific volumes, I also would
>    value any input as to whether it makes more sense to delete them from
>    the 4D time series (using fslsplit and fslmerge), or to leave them in
>    and give them their own label ("discard") in the attributes.txt file.

imho the later (mark as "discard") would be the easiest and space saving
solution ;)  
-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic



More information about the Pkg-ExpPsy-PyMVPA mailing list