JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for NEUROMEG Archives


NEUROMEG Archives

NEUROMEG Archives


NEUROMEG@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

NEUROMEG Home

NEUROMEG Home

NEUROMEG  March 2012

NEUROMEG March 2012

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: MaxFilter (2.2.10) questions

From:

Christopher Bailey <[log in to unmask]>

Reply-To:

Christopher Bailey <[log in to unmask]>

Date:

Thu, 8 Mar 2012 11:55:07 +0100

Content-Type:

multipart/mixed

Parts/Attachments:

Parts/Attachments

text/plain (22 lines) , motionpar-headpos-vs-movecomp_tSSS.pdf (22 lines) , ATT00001..txt (1 lines)

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

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.

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

Best,

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 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 > details. > > 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, >> >> 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 >> >> >> 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] > http://www.elekta.com/healthcare_international_elekta_neuromag.php > > > > >

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

July 2020
May 2020
April 2020
January 2020
December 2019
June 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
May 2018
April 2018
March 2018
February 2018
January 2018
November 2017
October 2017
September 2017
August 2017
March 2017
December 2016
September 2016
July 2016
April 2016
January 2016
August 2015
July 2015
June 2015
March 2015
December 2014
August 2014
May 2014
April 2014
January 2014
December 2013
November 2013
October 2013
September 2013
June 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
July 2012
May 2012
March 2012
February 2012
September 2011
July 2011
June 2011
May 2011
April 2011
March 2011
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
February 2010
January 2010
December 2009
November 2009
October 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
March 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager