Hi Jukka,

So glad to hear this wasn't trivial after all :)

I think I understand your point: the difference in -mc and -headpos output is a "feature", not a "bug". My take-home is that IF there is sudden movement, both will be equally good at detecting it. So we don't need to run headpos as a separate step to be able to reject individual trials on the basis of excessive motion, which is good.

I would certainly like to try out the utility script you mention for robust estimation of a suitable origin for the expansion. Please let me know how to get my hands on it :)

Thanks for your time,

Chris
--
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 20, 2012, at 10:00 AM, Jukka Nenonen wrote:

Hi Chris,

Congratulations for the tricky example :-) I didn't find actual bugs, but certainly some aspects can be improved in maxfilter.

Christopher Bailey wrote:

[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...]

Dear Jukka,

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.


Indeed, maxfilter updates the head position less frequently when tSSS is used. The cHPI signals are estimated in the same way in both cases, but the movement velocity is low enough
to judge that new head positions are needed less frequently than once per second. I will still use your data for more detailed debugging if this has effects on the output data.

In case the attachment doesn't make it through, here is a public link to the file:
http://dl.dropbox.com/u/14937634/motionpar-headpos-vs-movecomp_tSSS.pdf

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.


Yes, there may be big variations in the head size and how 'deep' the subject heads are. Therefore, you should try to match the SSS origin to each subject as well as possible,
using MRI (when available) or fit to isotrak. In the latter case, the outcome however depends on how the digitizations were performed. For example, large number of points
digitized on the face or below ears is likely to distort the sphere fit.

MaxFilter uses the same procedure than xfit and mrilab, namely all digitization points are inluded in the sphere fit. I have made a small utility program which omits points
on the face and below the ears, and hopefully provides an origin which matches bettwer with the curvature of temporal, paritetal and occipital areas.
Let me know if you are interested to try it.

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...


It is (0,0,0) in device frame; the program moves the selected SSS origin there.

Best,

Chris

Best regards, Jukka

--

================================
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]<mailto:[log in to unmask]>
http://www.elekta.com/healthcare_international_elekta_neuromag.php