[Dear NEUROMEG list readers: Below is a correspondence I started earlier, and the reply by Dr. Nenonen from Neuromag. Had some troubles with my JISCmail account...]
Thank you for your swift reply. Here are some follow-ups:
Q1) We see a clear difference between the QUAT channels written by -headpos and the CHPI channels written by -movecomp (screenshot attached). In a file acquired while I gently nodded the phantom continuously, the y- and ax-parameters behave as one would expect. When looking at the estimated head positions (in Maxfilter GUI), the _quat.fif file shows smooth motion parameters, whereas _tsss_mc.fif shows the rougher 10-second-step behaviour. I of course believe you (!!) when you say that the actual head position is indeed estimated at the same rate in both analyses, but the information we can read out of the files seems to be distinct, and I'd like to understand it a bit better.
In case the attachment doesn't make it through, here is a public link to the file:
I get that -movecomp actually "moves the head" (hence the name... ;), so it may make perfect sense that the CHPI channels reflect this. However, given that I've asked maxfilter to use the initial head position, shouldn't the CHPI then logically just be FLAT, fixed to the initial position...? This would not be very exciting data, but I really don't understand what the 10-sec-step data actually represents...
Q4 & Q5) OK, I see I've confused the head vs. device coordinate systems, the -origin is of course in the head frame by default. What I'm getting at is the use of -trans default when doing multi-subject analysis in sensor-space. That option seems to be a good way of normalizing some of the inter-subject variability in head placement in the helmet, and thus get a less blurred representation of the average responses (e.g. power) in sensor-space. What I'm concerned about is that there can be quite a bit of difference in (typically) the z-coordinate, depending on head shape and body (neck) form. So some subjects are further away from the "default" origin than others, and thus the head position normalization might induce extra noise (esp. in vertex sensors) in those subjects that were furthest from "default". Having now (properly) read through the manual, this is exactly what you refer to in 6.2.3.
Q6) What is the "default" position, when using "-trans default"? Is it (0,0,0)_device, or (0, 13, -6)_device, or something else? I'm sorry if this is stated somewhere, but I couldn't find it...
Christopher Bailey, MSc
MEG Engineer, MINDLab Core Experimental Facility
Center of Functionally Integrative Neuroscience (CFIN)
Aarhus University, Denmark
tel. cell: +45-2674-9927
tel. office: +45-7846-9944
On Mar 7, 2012, at 12:47 PM, Jukka Nenonen wrote:
> Dear Chris,
> Here are my brief answers, please don't hesitate to ask if you need more
> Best regards, Jukka
>> -----Original Message-----
>> From: Viirola, Juha
>> Sent: 06 March 2012 19:34
>> To: Nenonen, Jukka; Taulu, Samu
>> Cc: Meg Support; [log in to unmask]
>> Subject: FW: MaxFilter (2.2.10) questions
>> Hi Jukka and Samu, did you get this? Can you have a look. Best Juha
>> -----Original Message-----
>> From: Christopher Bailey [mailto:[log in to unmask]]
>> Sent: 06 March 2012 18:18
>> To: [log in to unmask]
>> Cc: Meg Support
>> Subject: MaxFilter (2.2.10) questions
>> Dear Jukka, Samu and others,
>> The following questions relate to our recent experiences using MaxFilter 2.2.10. We routinely use cHPI on all measurements. (On some datasets we have left a 20-30 sec period in the beginning of each session free of the cHPI signals.) From previous correspondence with you and others, we are convinced that using temporal-SSS is generally called for when doing motion compensation. We therefore locally recommend the following sequence (with careful inspection of the filtered vs. raw data)
>> step A) maxfilter -f basename_raw.fif -o basename_tsss_mc.fif -st -movecomp -hp headpos.log -v
>> OPTIONAL step B) maxfilter -f basename_tsss_mc.fif -o basename_tsss_mc_transDefault.fif -trans default -force
>> Q1) In the manual it is stated that the head position is estimated every 10 to 1000 ms (depending on need to update). However, when using movement compensation with tSSS, we only get one position estimate per correlation window (we use the default 10 second setting). This does make sense in the light of the fact that SSS subspaces are estimated once per window for the temporal extension, but perhaps there should be explicit mention of this in the manual? Also, will this approach not mean that rapid head movements will remain undetected?
> Head positions are always estimated in the same way whether tSSS with
> long buffers are used or not. Rapid head movements are thus always
> spotted: HPI coil movement by 3 mm (half of the diameter) or more cause
> distinct changes in the cHPI signals and the program re-evaluates then
> the SSS bases for a new head position (MaxFilter User Guide Appendix
> D.1). Therefore, only one head position for 10-second interval means
> that there was no movement.
>> Q2) Depending on the answers above, would it make sense to first simply estimate (-headpos) the head position quaternions, and thereafter apply -st and -movecomp to the resultant output (instead of starting from the raw file)? Would this not give us the possibility to at least check for within-window movement? I realise we still would need to drop the temporal extension to be able to compensate, but it would give us the option of rejecting trials on the basis of movement. Please advise.
> As stated above, there is no difference in cHPI amplitude and head
> position estimation whichever options are selected (headpos, movecomp,
> st, etc).
> Thus, it should not matter (apart for minor numerical rounding effects)
> running "maxfilter ... -movecomp -st", "maxfilter -headpos -st ->
> maxfilter ... -movecomp ", or "maxfilter -headpos -> maxfilter ... -st
> -movecomp". The QUAT channels in the result FIFF file after 'headpos'
> could be used to reject epochs with movement, but our DANA software does
> currently not support suchrejection.
>> Q3) What exactly happens in the optional step B (applied for sensor-space analysis)? We have noted that the only way to execute step B is by issuing the -force flag. Our take on it is that you have a check in place that by default prevents running maxfilter on a file which has already been processed with (t)SSS. The way we choose to understand this step is that when maxfilter detects that the processing history contains an SSS block, it reads the already estimated (in the tsss_mc-step A) subspace-definitions from the header, and uses those when recalculating to the "default" position. Can you confirm this?
> Yes, this is correct, the program sets the head position and expansions
> according to the processing history.
>> Q4) As indicated above, we do not specify the -origin parameter (this is more due to our ignorance than to active choice...). How does the actual origin of the head (in the device coordinate system) interact with the choice of this parameter? In other words, would it be correct to assume that the choice of the -origin parameter will affect the tSSS results depending on where the head origin was actually placed relative to the sensors?
> Generally, if you have anatomical information (MRI), you should set the
> sphere origin as in xfit (e.g. fit in mrilab). Usually, the origin does
> not matter much for tSSS, except when the head is clearly in an
> 'abnormal' position, too low or too front. The default origin is 0,0,40
> mm in the head frame, but some users seem to prefer 0,0,50 mm instead.
> You can also fit the origin to isotrak points, but the result depends on
> how the digitizations were done. All points are included, and especially
> points on the face and below the ears may push the fitted origin too low.
>> Q5) As a corollary to Q4, when using "-trans default", do you think it might make sense to use e.g. the average head position (after motion compensation to initial head position in each file) as the -origin, in order to minimize the amount by which each subject on average is "moved around"? Or perhaps I've misunderstood the meaning of the origin-parameter altogether...?
> If there is not much movement, the 'default' origin should be fine.
> However, if there are large and frequent movements, an average head
> position could be better choice.
> Please see MaxFilter User Guide section 4.5.2 for the details.
>> I hope you can find the time to answer these questions.
>> Best regards,
>> Christopher Bailey, MSc
>> MEG Engineer, MINDLab Core Experimental Facility
>> Center of Functionally Integrative Neuroscience (CFIN)
>> Aarhus University, Denmark
>> tel. cell: +45-2674-9927
>> tel. office: +45-7846-9944
>> Please consider the environment before printing this e-mail.
>> The contents of this e-mail message (including any attachments) are confidential to and are intended to be conveyed for the use of the recipient to whom it is addressed only. If you receive this transmission in error, please notify the sender of this immediately and delete the message from your system. Any distribution, reproduction or use of this message by someone other than recipient is not authorized and may be unlawful.
> 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]