Hi Danny,
In principle there is no risk in transforming continuous data,
provided that isotrak and hpifit information are correct.
However, if the distance between the true and target
head positions is over 2-3 cm, the result may become less
optimal when combining interference suppression and
data transformation.
In addition, if you notice afterwards that hpifit result was
bad and needs to be redone or want a different reference
head position for a set of files, you need to rerun all
raw data files.
Thus, the matter of raw data processing / transformation is
mainly to avoid time-consuming re-processing of raw data files.
Best regards, Jukka
Danny Mitchell wrote:
> Dear Jukka,
>
> Thank you for those clarifications.
>
> I'm curious about your comment :
>
> Option 'trans' is primarily meant for evoked data, i.e. I recommend to
> process raw data without 'trans', do averaging, and only thereafter
> transfer to a different head position.
>
>
> I would prefer to transform the continuous data (and have been doing
> so), for example for analysis of induced effects.
> What are the risks associated with transforming continuous data?
>
> Many thanks,
> Danny
>
> On Dec 12, 2007 9:38 AM, Jukka Nenonen <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> Dear Daniel,
>
> Thank you for the questions.
>
> Daniel Wakeman wrote:
> > Hello,
> >
> > I have several questions about the appropriate usage of maxfilter. I
> > may have mis-understood some of the calculations maxfilter is
> > performing, so please correct me, where I'm wrong.
> >
> > Several people at the CBU have been told that when they run into
> the error:
> >
> > ERROR: sphere fitted to isotrak extends outside of the sensors!
> (r0 = (12
> > 12 45) mm, rad = 10 cm)
> > Opened FIFF file lista4first_raw.fif (1350 data buffers).
> > Output file lista4first_sss_raw.fif was not written (exit value = 3)!
>
> This error message can have two causes:
> a) The coordinate transformation in the FIFF-file is wrong, usually
> due to problems in the initial head position fitting (hpifit). You
> can try
> to judge it by show_fiff:
> ...
> 222 = transform device -> head
> 0.991323 0.122468 0.047753
> -0.117611 0.988611 -0.093888
> -0.058708 0.087457 0.994436
> -3.402352 -11.903301 51.529018 (inv. 5.585114 6.803262
> -52.141802)
> ...
> The result (in an adult head) typically has a rotation (first three
> lines above) close
> to a unity matrix, and translations (fourth line) reasonably close to
> the 'xfit default'
> 0,0,40 (in the above example, rather 0,0,50).
> Large deviations in rotation or translation may cause the head to 'pop
> up' through
> the sensor array.
>
> As default, MaxFilter tries to fit a sphere to isotrak points, and then
> translates the
> origin to the device coordinate frame. If the coordinate
> transformation has
> problems, the fitted origin may show up too close to the nearest
> sensor and
> the program judges that the head would pierce through the sensor array,
> therefore
> the error message, despite the fitted origin in HEAD coordinates is
> apparently OK.
>
> Please note that maxfilter cannot correct the incorrect transormation.
> Even if you
> try to give option '-frame head -origin 0 0 50', the program may find
> the origin
> transformed to device frame too close to the sensors are report an
> error.
> You can still process the data by selecting '-frame device'.
>
> b) A set isotrak points may have been digitized outside of the head,
> thus the fitted sphere becomes distorted and does not represent the head
> geometry.
> In this case the situation is usually corrected by giving the origin
> manually.
>
> > They should use -origin 0 0 45 -frame head. However, this
> instruction
> > seems very dangerous without at least some preliminary tests e.g. How
> > much are we changing the position of the sphere from what was
> calculated
> > with the Digitized points? Given the radius of the sphere being
> > calculated, will this position change include all of the head? Why
> > can't we specify both the origin and the radius? We should be
> able to
> > visualize these spheres using ce_dekra.pngmri_lab (or some other program
> ideally one
> > in which we can visualize the device, the mri, and the spheres).
> We can
> > certainly currently visualize created spheres in mri_lab.
>
> MaxFilter (and SSS) interference suppression is very robust in respect
> to the
> origin location (as long as it does not become too close to the nearest
> sensor).
> If you want to do data transformations (maxmove), I advise to follow
> the
> steps of the source modelling, e.g. define the origin in meg-mri
> integration
> program and using that origin (with '-frame head'). if the isotrak
> data and
> hpifit were fine, the maxfilter sphere fit usually becomes fairly
> close to
> the origin defined from mri data.
>
> BTW, the radius of the sphere is completely irrelevant in SSS. The
> program
> reports it in the above error, but uses it only to check if it becomes
> larger than the distance from the origin to the nearest magnetometer.
>
> > Is there any limit to the number of times we can run maxfilter on a
> > dataset e.g. (can we run it once with -autobad, another time with
> > -movecomp, another time with -trans) If so how do we apply -nosss e.g
> > -autobad with -nosss, -movecomp without -nosss, and -trans
> without -nosss.
>
> SSS is an idempotent operation (as long as the origin and orders remains
> fixed),
> but numerous repeating may have some numerical effects. Option
> '-nosss' is
> generally meant only for maintenance purposes (especially with active
> compensation) and should not be used in regular data processing.
> Thus, the above combinations of 'nosss' are paradoxal because
> 'autobad',
> 'movecomp' and 'trans' do need SSS...
>
> Thus, you can redo SSS operations on a file which already was processed
> but need the option 'force' (see MaxFilter User's Guide page 19).
>
> > Also:
> >
> > Can we -trans evoked data sets (Has this been thoroughly tested and
> > confirmed to work: if so how)?
> >
> > Can you do SSS without -trans and then -trans the SSS data set?
>
> Option 'trans' is primarily meant for evoked data, i.e. I recommend to
> process raw data without 'trans', do averaging, and only thereafter
> transfer to a different head position.
>
> > It seems like maxfilter is actually utilizing several different
> > functions/programs, it would be very beneficial if each
> function/program
> > was a seperate /neuro/bin/util/, so we could avoid all of these
> > interaction issues. Towards that end can you give us a comprehensive
> > list of the options, which correspond to different tools?
>
> Unfortunately, all functions are packed within a single program,
> maxfilter.
> The User's Guide describes all available options, see Appendix E.
>
> > I would also like to get some critical log information when running
> > maxfilter e.g. what spheres were used their radii and origins; when
> > maxfilter has interpolated a channel I would like a measure of how
> > faithfully the channel has been represented (e.g. deviation from what
> > would have happened if there was channel data? Different
> collections of
> > channels marked bad in different locations will give different
> quality
> > representation of the channel. e.g. in a worst case scenario three
> > complete (x gradiometer, y gradiometer, and magnetometer) chips
> next to
> > one another would be marked bad). I may be misunderstanding the way
> > this works, but the representation should not be as faithful.
>
> SSS parameters are stored in a history block in the result file, and
> you
> can always view them afterwards (see MaxFilter User's Guide page 19).
> We are relying on the studies carried out in the desing and testing
> phases
> of maxfilter which try to 'measure' that maxfilter is not distorting
> any
> brain signals.
>
> However, it is not easy to define a measure of channel representation
> because usually we don't have a suitable reference. The recorded raw
> data contains interferences and channel imperfections which maxfilter
> tries to correct. Other methods, such as SSP, are also cleaning them
> but do not provide comparable signals.
>
> In fact, a MNE reconstruction step is needed brefore data with SSP can
> be compare to data after SSS. Therefore, you need to
> - Load evoked file with SSP in source modelling (xfit)
> - apply MNE reconstruction (default setting)
> open the full view dialog, and save the data in a new FIFF-file (see
> Source Modelling Software User's Guide Section 6.2.5 Save responses...)
> - Overlay the saved file with the maxfilter result.
>
> >
> > Thank You,
> > Dan
>
> With best regards, Jukka
>
> ================================
> 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] <mailto:[log in to unmask]>
> http://www.neuromag.com
>
>
--
================================
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
|
