Hi,
The registration works as follows:
1) Volume N+1 is registered to volume N (the reference volume specified by
-refvol or the default of half-way through the time-series). The starting
estimate for this transformation is the identity, and the resulting
transformation
is stored as, say, T(N+1).
2) Volume N+2 is registered to volume N (*not* N+1) with T(N+1) as
the starting estimate for the transformation. The resulting transformation
is saved as T(N+2).
3) Volume N+3 is registered to volume N with T(N+2) as the starting
estimate ...
etc, until the end of the time series is reached in this direction, then ...
1a) Volume N-1 is registered to volume N using the identity as the starting
estimate. The resulting transformation is stored as, say, T(N-1).
2a) Volume N-2 is registered to volume N using R(N-1) as the starting
estimate. The resulting transformation is stored as T(N-2).
3a) Volume N-3 is registered to volume N using T(N-2) as the starting
estimate ....
So T(x) gives the transformation of volume x to volume N.
This process is repeated at finer resolutions, but then all starting
estimates
are taken from the results found in the previous scale.
What I mean in the above by "starting estimate" is simply the transformation
where the local optimisation begins. For example, if it is a translation of
4mm then it will start looking for translations around 4mm first,
progressing
to ones further away if the images require it. The starting estimates are
important for avoid local minima - with closer starting estimates being
more robust.
So there is no problem with slow motions or any accrual problems (as
we don't need to multiply lots of matrices together - all transformations
relate a volume to the unique reference volume).
To look at limitations of motion it is best to examine the plots generated
by FEAT which give both relative motion (one time-point to the next)
as well as absolute motion with respect to the reference. The latter
is just given by the transformations found above, while the former is
just calculated as: inv(T(x+1)) * T(x)
Hope this answers your questions.
All the best,
Mark
Appu Mohanty wrote:
>MCFLIRT question: Granted that we use the -refvol default of the middle
>volume as the reference, and call that volume N. The MCFLIRT web page
>explains how volume N+1 is registered to N via a search for the best
>fit. We're not able to determine something about how N+2 (or any N+x) is
>registered.
>
>A simple alternative is that the search for each of the N=? volumes is
>relative to N. Downsides of that are that (1) it won't handle a gradual
>motion that may be small from volume to volume but accrues too large
>more distant in time from N and (2) that accrual problem will be worse
>for longer recording sessions.
>
>The MCFLIRT web page says that the N+1 adjustment is used as an estimate
>for adjusting N+2. Our question is: what is meant by "estimate"? Read
>literally, the web page could be understood to mean that the N+1
>adjustment is applied to N+2 (i.e., no further search or optimization is
>done for N+2). That would mean that the only motion that can be
>corrected is that which occurs from N to N+1 or from N to N-1 (surely
>not the case). Or, "search" could mean "starting point" for an
>optimization for N+2.
>
>A second alternative is that each N+x+1 volume is registered by
>comparison to the N+x volume, with the final registration applied to
>N+x+1 being the cumulative or net registration of all volumes N+1 to
>N+x.
>
>A concrete implication of this choice is: if one sets a 2 mm criterion
>for maximum allowed motion, in the first alternative that 2 mm is the
>difference allowed between the N+x volume and the N (middle) volume,
>whereas in the second alternative the 2 mm is the difference allowed
>between adjacent volumes (thus, the change from N to N+x could be almost
>as large as 2*x mm).
>
>Thanks in advance.
>
>
|