Hi Jason,
Thank you for the questions. In principle, it should be OK to use all
three options:
1) maxfilter -f <raw.fif> -o <tsss.fif> [-st] -trans default -frame head
-origin x y z
2) maxfilter -f <raw.fif> -o <tsss.fif> [-st] -trans default -frame head
-origin x y-13 z+6
3) maxfilter -f <raw.fif> -o <tsss.fif> [-st] -trans <target.fif>
In 2), the operation pushes the 'anatomical' sphere origin x,y,z to the
point 0,13,-6 mm in device frame.
Effectively, the distance from the cortex to sensors may become slightly
larger than in 1).
Just note the general limitations noted in the User's Guide (version 2.2):
If you run (t)SSS first for the origin x,y,z, and transform the result
using a different origin, page 22 warns that
"Forcing MaxFilter reprocessing may distort the result if different
expansion origin or order settings are used".
Page 62 warns: "Transforming the position more than 25 mm shows
increased noise on some MEG channels."
Best regards, Jukka
On 05/17/2012 07:36 PM, Jason Taylor wrote:
> Dear Jukka et al.,
>
> Following up on Danny's and Rik's recent questions...
>
> From previous exchanges on this list (about MF 2.0, but I'd now like
> to know about MF 2.2), my understanding is that if one takes a file
> that has *already been (t)SSS-ed* and applies "-trans default -frame
> head -origin x' y' z' ", then the 'origin' argument now defines the
> coordinate in head space that one desires to be virtually relocated to
> the device origin (as you described in response to Danny: "Option
> trans default composes another virtual SSS base where the origin
> coincides with the point (0,0,0) in device frame.
> SSS multipole amplitudes obtained from the original expansion for
> (x,y,z) are then employed to compute the result data from the virtual
> SSS base").
>
> So, if one wants a subject's head to be virtually transformed such
> that the head-space origin is moved to *0,13,-6 in device space*, is
> it safe to do as follows?:
>
> (1) Perform (t)SSS in 'native' head position ([x y z]=origin of head
> sphere fit offline):
> maxfilter -f <raw.fif> -o <tsss.fif> -frame head -origin x y z ...
>
>
> (2) Move (t)SSS-ed file to 'optimal' device origin:
>
> maxfilter -f <tsss.fif> -o <trans_tsss.fif> -trans default -frame head
> -origin x y-13 z+6 ...
>
>
>
> Alternatively, could one modify Danny's scheme of computing a 'target'
> file for -trans like so?:
>
>
> (0) Create target file (for positioning only -- ignore SSS output!):
> maxfilter -f <raw.fif> -o <target.fif> -trans default -frame head
> -origin x y-13 z+6
>
>
> (1) Perform (t)SSS in 'native' head position:
> maxfilter -f <raw.fif> -o <tsss.fif> -frame head -origin x y z
>
>
> (2) Move (t)SSS-ed file to 'optimal' device origin:
>
> maxfilter -f <tsss.fif> -o <trans_tsss.fif> -trans <target.fif>
>
>
>
> Failing any of these, I suppose we could abandon the 'optimal' device
> origin and simply use (0,0,0 [device]). However, it's surely
> advantageous to have the head-sphere origin coregistered with
> sensor-sphere origin (provided, as you warn, the translation is less
> than 25-30 mm).
>
>
> Thanks in advance for your help!
>
>
> Best,
>
> - Jason.
>
>
>
>
> ------------------------------------------------------------------------
> *From:* Announcement for the Neuro MEG list [[log in to unmask]]
> on behalf of Jukka Nenonen [[log in to unmask]]
> *Sent:* 16 May 2012 10:58
> *To:* [log in to unmask]
> *Subject:* Re: trans default and SSS expansion origin
>
> Hi Danny,
>
> Please find below our answers to your questions.
>
> Best regards from Jukka Nenonen, Samu Taulu and Juha Simola
>
>
>
> Danny Mitchell wrote:
>> Hi,
>>
>> I have a few questions regarding the "-trans default" option of
>> maxfilter, and where the head and SSS expansion origin should be
>> placed relative to the device origin.
>>
>> 1) According to the maxfilter manual, "the optimal device origin is
>> at 0,13,-6mm." Why is this the optimal origin? Is it because it minimises
>> the volume between the inner and outer spheres?
>
> It is optimal in the case there is no head inside the dewar, the
> result is simple the origin of a sphere fitted to all MEG sensor
> locations.
>
>>
>> 2) With -transdefault, the origin is set to 0,0,0 in the device
>> coordinate frame. Why is this different from the above coordinates? Is
>> it also optimal in another sense?
>
> Point 0,0,0 in device frame is the center of symmetry of the posterior
> parts of the helmet, and it generally coincides reasonably well
> to an origin fitted to subject's anataomy, e.g using MRI data.
>
>>
>> 3) Am I correct that when using -trans default (in Maxfilter 2.0)
>> "-frame head -origin x y z" defines both the SSS expansion origin
>> AND the target device origin in head coordinates. Therefore the SSS
>> expansion origin always ends up at the device origin, and the head
>> centre gets translated away from this, so that the SSS expansion
>> origin is no longer at the centre of the head, nor at the "optimal"
>> position?
>
> No, the SSS origin remains at the given point (x,y,z) in the head
> frame. Option trans default composes another virtual SSS base where
> the origin
> coincides with the point (0,0,0) in device frame. SSS multipole
> amplitudes obtained from the original expansion for (x,y,z) are then
> employed
> to compute the result data from the virtual SSS base.
>
> Note the limitation (see MaxFilter-2.2 User's Guide section 6.2.3):
> Transforming the head position more than 25 mm shows increased
> noise on some MEG channels.
>
>
>>
>> 4) So...is it sensible to use the following 2-step procedure to align
>> the head origin AND the SSS expansion sphere to (0, 13, -6):
>> (a) maxfilter ... -f <infile> -o <tempfile> -transdefault -frame head
>> -origin x y-13 z+6
>> (b) maxfilter ... -f <infile> -o <outfile> -trans<tempfile> -frame
>> head -origin x y z
>> (where x,y,z are the coordinates of the centre of the best sphere fit
>> to the head points.)
>
> Basically it is OK, but I would prefer to use an origin which has the
> best fir to subject's anatomy (i.e. x,y,z instead of x,y-13,z+6).
>
>>
>> 5) If so, does this apply to both Maxfilter 2.0 and Maxfilter 2.2?
>
> In both versions, trans default sets the virtual SSS basis origin to
> coincide with (0,0,0;device).
>
> Differences between 2.0 and 2.2:
>
> 2.0: The default origin is always obtained by fitting a sphere to
> isotrak (or sensors if there is no device->head transformation).
> 2.2: The default origin is at (0,0,40) (or 0,0,0 if there is no
> transformation).
>
> 2.0: trans default bug: you should always provide also -frame and
> -origin with 'trans default'.
> 2.2: the bug was fixed; trans default used (0,0,40;head) if frame and
> origin are not given by the user.
>
>>
>> 6) I'm also wondering whether poor choice of the expansion sphere
>> origin can lead to truncation or distortion of high spatial frequency
>> components of the signal? From my reading of Samu Taulu's thesis,
>> when D is the distance from a source to a sensor, the measurable
>> signal contains spatial frequencies up to ~1/(2D); and with the
>> default inner expansion order of Lin=8, the highest spatial
>> frequencies described are 9/(2ðR), where R is the distance of the
>> sensor to the SSS expansion origin; so all spatial frequency
>> information will be captured as long as D/R > ð/9. Have I understood
>> that correctly? If the SSS origin is set to the centre of an average
>> head, this seems generally satisfied when these are at 0,13,-6,
>> slightly less so when they are are at 0,0,0, and often not true for
>> as much as 25% of the scalp if -trans is not used at all.
>
> To give a comprehensive treatment of the "truncation distortion"
> related to the SSS-method is not straightforward (see below).
>
>
> The situation is much more clear when treated case by case. The
> possible distortion, due to truncation, in case of any dipole and any
> choice of origin can be studied using Xfit-program. There one can
> create a simulated "evoked response" data corresponding to a current
> dipole in any location (in spherical model). The distortion of these
> data and the resulting localization error can then be examined by
> processing this simulated "evoked response" with MaxFilter (SSS) using
> inner expansions of different lengths (/l/_in = 8,9,10, say), and
> different origins, and comparing the data. Some distortion naturally
> shows up, but the distortion must be compared to a realistic noise
> level in real signals.
>
>
> Some conceptual things:
>
> Assume we have a source at a distance D from the (curved, roughly
> spherical) surface containing the sensors.
>
> On this surface the wavelength spectrum of the magnetic field arising
> from this source is naturally independent of the choice of SSS-origin
> and thus independent of R. The discussion in Samu Taulu's thesis (and
> the criterion D/R>p/9 derived from this discussion) refers to the
> standard condition where the SSS-origin is placed near the center of
> the helmet (or the center of the subject's head), and where the
> distance from origin to all sensors is roughly R.
>
>
> The standard usage of SSS is to keep the origin close to the center of
> the source volume. Moving the SSS-origin further from the central
> location has several consequences. The most prominent one is that
> moving the origin toward the sensor surface reduces R (which is the
> distance from the origin to the sensor that is /nearest /to the
> origin) and thus reduces the size of the "inner sphere". This leads to
> (partial) rejection of field from currents which may be inside of the
> brain but outside of this sphere.
>
>
> As to possible SSS-related truncation distortion the consequences of
> off-center origin are much less important. If, for example, we place
> the origin on the top of the primary current dipole, then R=D and the
> criterion given in Samu's thesis is definitely not met. But in this
> case, when an expansion of given length (/l/_in ) is used, we get an
> /improved/ representation of short wavelenth magnetic field
> components, at least for the near by sensors, as compared to using the
> standard origin close to center.
>
>
> To put it short. If the origin of the SSS model is approximately in
> the central location of the source volume, typically based on HPI
> information, significant truncation effects should not arise with the
> default order values. The resulting SSS-decomposed data can be used to
> virtually transform the signals to correspond to some other head
> position. If an off-center origin is tried the situation is rather
> complex and we recommend "experimental" testing of the possible
> consequences by using Xfit as described above.
>
>>
>> Any comments/corrections/clarifications would be much appreciated.
>> Many thanks,
>> Danny
>
>
> --
>
> ================================
> Dr. Jukka Nenonen
> Manager, Method development
> Elekta Oy
> Street address: Siltasaarenkatu 18-20A, Helsinki, Finland
> Mailing address: P.O. Box 34, FIN-00531 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.elekta.com/healthcare_international_elekta_neuromag.php
>
>
>
>
--
================================
Dr. Jukka Nenonen
Manager, Method development
Elekta Oy
Street address: Siltasaarenkatu 18-20A, Helsinki, Finland
Mailing address: P.O. Box 34, FIN-00531 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.elekta.com/healthcare_international_elekta_neuromag.php
