Hi Jason,
thanks for the questions. Now I am sitting in the new office and busily
debugging maxfilter 2.1.
Just a remainder to the readers to avoid extra confusion:
this reply concerns only the problem when using the option '-trans
default'.
Options '-trans default' and '-origin x y z -frame head' are mean to be
independent
of each other. Using them together just provides a workaround for a
'trans' bug
in maxfilter 2.0.
When composing the 'default' transformation between device frame and
reference
head frame, the program picks the translation part from the SSS sphere
origin.
Unfortunately, the program constructs this transformation before
fitting the sphere, and therefore the translation may become (0,0,0).
However,
if you set the origin manually, the translation part becomes OK.
I agree with your suggestion below: generally it is better to process
all (raw)
data first using the subject's own head position. If you wish to compare
multiple recordings, use the '-trans' option as a last step (typically
for evoked
format data files). In this way you can avoid extra work of re-processing
all raw data if the translation to the target head position is erroneous.
NOTE: maxfilter may report an error "Output file exists" if SSS was already
done. Then you need to set another output filename, or use option 'force'.
SSS is an idempotent operation, thus it can be repeated several times
without
affecting the result.
I also suggest to check the program output if you are using the default
settings, because fitting the sphere to isotrak depends on how the
digitizations are done. Sometimes the sphere fit fails and reports
errors like "sphere fitted to isotrak extends outside of the sensors" or
(a more obscure one) "Simplex: nr of eval exceeds maximum".
Also, you need to be suspicious if the program reports that the origin
becomes close to (0,0,0) in the head coordinate frame.
If you are still confused how to use '-trans default', I advice to
select one of
the measurements as a target head position (e.g. file <target_meas.fif>),
and use it instead of 'default', i.e. set '-trans <target_meas.fif>'.
Best regards, Jukka
Jason Taylor wrote:
> (Forgive me if you receive this twice -- I received an error the first
> time I sent it.)
>
> Hi Jukka and list recipients,
>
> Thanks again for further clarifying these MaxMove options (especially
> while you are packing up your office!). I'm still a little confused
> about the use of -frame, -origin, and -trans options in combination.
> Here is why:
>
> In the manual, -frame and -origin are described in terms of defining,
> for the purposes of SSS computation, the origin of the sphere containing
> the brain (s[in]). If these options are not specified, MaxFilter fits a
> sphere to the isotrak-digitised headshape. Jukka (and Erika and
> Burkhard) pointed out that the centre of this sphere is typically ~40mm
> higher than the 'head' coordinate origin (defined by the three cardinal
> ear-nose-ear points). So, my understanding is: If I specify [ -frame
> head -origin 0 0 40 ], the sphere s[in] used in SSS will be centred on
> that point defined in the 'head' coordinate system.
>
> Not in the manual, but in the chain of emails above, -frame and -origin
> are described in terms of the -trans default option, to designate a
> point in 'head' coordinates that should correspond with the 'device'
> origin when the head is virtually transformed to a target position and
> the 'head' and 'device' coordinate systems are aligned. So, my
> understanding is: If I specify [ -frame head -origin 0 0 40 -trans
> default ], the 'virtual sensors' in the output data are aligned to the
> head coordinate system as though that point (0,0,40) in the subject's
> head had been in the centre of the sensor sphere.
>
> These two issues -- defining the optimal s[in] sphere for SSS and
> setting origin for head/device coordinate alignment -- seem to be
> independent. Unless I'm mistaken, it is desirable to (1) compute and
> separate signals originating from s[out] and s[in] centred on the
> *actual* head position (using -frame head -origin X Y Z), then (2)
> transform the data as if the head were in the *same* position for the
> whole block (using -movecomp), then (2) optionally transform the data as
> if the head were in the *ideal* position for comparison across blocks or
> subjects or devices or whatever (using -trans default -frame head
> -origin X Y Z). Is this what maxfilter does if I specify all options [
> -frame head -origin X Y Z -trans default -movecomp ] at once?
>
> Also, what if the origin desired for transformation is different from
> the origin that best defines the s[in] sphere, as might be the case when
> comparing across subjects? Wouldn't it be necessary to do this in two
> steps?
>
> Cheers, and good weekends to all.
> - Jason.
>
>
>
>
> On 10/26/07, *Jukka Nenonen* <[log in to unmask] <mailto:[log in to unmask]>>
> wrote:
>
> Dear Rik,
>
> I am writing a quick reply in the middle of moving boxes, our
> computers will shut down soon and I cannot do more work with
> MaxFilter before Tuesday.
>
> First, in your commands below the option 'nosss' is obsolete. It is
> meant only for maintenance purposes and should not be used in
> any data analysis. It may even produce ssome unwanted effects, but here
> it is simple overrode by option 'trans' (which is in fact doing another
> SSS).
>
> Yoy can realign the blocks in one run, please try:
>
> /neuro/bin/util/maxfilter \
> -f ./raw_block1.fif \ -o ./raw_block1_sss.fif \
> -autobad off -movecomp -hp ./raw_block1_hpi.pos \
> -trans target.fif
>
> /neuro/bin/util/maxfilter \
> -f ./raw_block2.fif \ -o ./raw_block2_sss.fif \
> -autobad off -movecomp -hp ./raw_block2_hpi.pos \
> -trans target.fif
>
> Here target.fif is a measurement where the head should
> be in a 'good' position.
>
> If you wish to use 'trans default' instead, I recommend to
> find an optimal origin for each subject first, e.g. using the
> mri data, or fitting to isotrak. In my opinion, the best alignment
> is to have individual head sphere origins at the same point,
> and the coordinate exes directions aligned with the device
> coordinate axes. (Please let me know if you have better ideas!)
>
> If you don't have that information, default (0,0,40)
> may position a large head too low and a small head too
> high. In such cases using a file (target.fif) may be better
> for a group analysis.
>
> We haven't performed extensive analyses for transforming raw data
> into a common head position, so I recommend to run some pilot testing
> with maxmove for finding a good 'protocol' before carrying on extensive
> analyses over multiple recordings and subjects.
>
> With best regards, Jukka Nenonen
>
> Rik Henson wrote:
> > Jukka -
> >
> > Please forgive our slowness, but could you confirm that the following
> > two stages would achieve our desired goal of 1) compensating for
> > movement within each of two blocks, and then 2) transforming each
> block
> > to the same space:
> >
> > Step 1 (apply SSS and movement compensation):
> >
> > /neuro/bin/util/maxfilter \
> > -f ./raw_block1.fif \ -o ./raw_block1_sss.fif \
> > -ctc /neuro/databases/ctc/ct_sparse.fif \ -cal
> > /neuro/databases/sss/sss_cal.dat \
> > -autobad off \
> > -movecomp -hpistep 200 -hpisubt amp -hp ./raw_block1_hpi.pos
> >
> > /neuro/bin/util/maxfilter \
> > -f ./raw_block2.fif \ -o ./raw_block2_sss.fif \
> > -ctc /neuro/databases/ctc/ct_sparse.fif \ -cal
> > /neuro/databases/sss/sss_cal.dat \
> > -autobad off \
> > -movecomp -hpistep 200 -hpisubt amp -hp ./raw_block2_hpi.pos
> >
> >
> > Step 2 (realign two blocks):
> >
> > /neuro/bin/util/maxfilter \
> > -f ./raw_block1_sss.fif \ -o ./raw_block1_sss_trans.fif \
> > -nosss \
> > -autobad off \
> > -frame head -origin 0 0 40 -trans default
> >
> > /neuro/bin/util/maxfilter \
> > -f ./raw_block2_sss.fif \ -o ./raw_block2_sss_trans.fif \
> > -nosss \
> > -autobad off \
> > -frame head -origin 0 0 40 -trans default
> >
> > If these are not correct, please edit the above maxfilter
> commands to be
> > correct.
> >
> > If these are correct, can we finally confirm that if we plotted the
> > sensor locations in headspace for the two blocks, they would overlap
> > exactly? In other words, would two different initial head
> positions be
> > transformed such that their centres are now identical, and such
> that the
> > point [0 0 40] in that common headspace would correspond to [0 0
> 0] in
> > device space?
> >
> > Rik
> >
> > PS Would it also help generally to put "-frame head -origin 0 0
> 40" in
> > the first two maxfilter calls, ie during the SSS computation?
>
================================
Dr. Jukka Nenonen
Manager, Method development
Elekta Neuromag Oy
Street address: Siltasaarenkatu 18-20A, Helsinki, Finland
Mailing address: P.O. Box 68, FIN-00511 HELSINKI, Finland
Tel: +358 9 756 240 85 (office), +358 400 249 557 (mobile),
+358 9 756 240 11 (fax), +358 9 756 2400 (operator)
E-mail: [log in to unmask]
http://www.neuromag.com
|
