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  October 2007

NEUROMEG October 2007

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Problem with MaxMove?

From:

Samu Taulu <[log in to unmask]>

Reply-To:

Samu Taulu <[log in to unmask]>

Date:

Wed, 24 Oct 2007 14:03:28 +0300

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (92 lines)

Hello,

I would like to comment Burkhard's message that discusses the noise 
properties of the transformation methods. A separate issue is the bug in 
the MaxFilter program that causes noise problems not related to the 
mathematical method itself. Jukka Nenonen will send information to this 
list on how to circumvent the bug before the fix will be released.

Burkhard makes a good point about the fact that any transformation 
method inherently increases noise when virtually moving the head 
position over long distances (in the range of several centimeters). This 
can be understood, for example, by considering the case where the head 
is in a very low position during the measurement and then virtually 
transformed to a clearly upper position. If we assume that the MEG 
sensors detect the same spatial features of the field from both 
positions, then the noise has to increase in the transformation because 
the actual measurement has a lower signal-to-noise ratio than the upper 
position (closer to the sensors) would produce. Otherwise, we would be 
able to artificially increase the SNR just by transforming the head 
position closer and closer to the sensors, which obviously cannot be the 
case. Recently we have developed a noise weighting solution to prevent 
noisy transformations, and we are currently testing the method.

Best regards,
Samu


Burkhard Maess wrote:
> Hallo,
>
> I have never used the -trans option so far. Until now, I have not seen 
> the noisy stuff in my current data.  But  it reminds me to something I 
> have seen with other software and another MEG device as well:
>
> It looks as if the distance between helmet and head is changed too 
> heavily during the transformation. Our own home-made software has 
> produced a similar output whenever the two head positions (before and 
> after transformation) were too distant to each other.
> We have used the home-made software to allow for averaging across 
> blocks measured from one subject in one or even several sessions. 
> There is no problem to be expected if the head position stays the same 
> within 1 to 2 centimeters. Nowadays, I use maxmove for the same 
> purpose as well.
>
> Computation of a grand average is an interesting step in MEG analysis. 
> If your are lucky you may already get a glimpse to your effects. 
> Although the neuromag manual recommends the use of MaxMove for much 
> crisper grandaverages, I think, this really overemphasizes the 
> importance of the field grand average to the MEG community. We have 
> the possibilities to do individual source localization. So our grand 
> average should be based on those localization results and not magnetic 
> field measurements. Therefore, I think, it is a waste of effort to 
> recompute a complete MEG experiment to a virtual position at which 
> none of the participants was placed during a recording. Sorry, if this 
> statement was too harsh, but I stick to the opinion that maxmove has 
> to fail if we try to recompute the field distribution for a very 
> distant head position (say, e.g. more than 2 centimeters distance 
> between measurement and transformed head position).
>
> I regularly use the option '-origin -2.4 1.9 50.4' in the command 
> line. I always used this option '-frame head', too. But, I have not 
> checked which position the output file stores.
>
> Finally, I would like to say, that Jukka Nenonen has recommended to 
> work with manual bad channel detection whenever you analyze data from 
> continuous HPI measurements (which I have done exclusively). Use 
> '-autobad off -bad 533 2222' when you like to declare MEG0533 and 
> MEG2222 bad.
> The manual bad channel detection results in a more stable behaviour 
> when estimating the current head position from the HPI coil signals. 
> With "autobad on" the head position had with some subjects/data sets a 
> bistable appearance. The head appeared as moving between two close 
> positions (approx. 2mm away from each other). Nothing serious all in 
> all, but different from real behaviour of the subject, I guess.
>
> Cheers,
> Burkhard
>
>
>


-- 
-----------------------------------------------------------
Samu Taulu
Elekta Neuromag Oy
Street address:  Elimäenkatu 22, Helsinki, Finland
Mailing address: P.O. Box 68, FIN-00511 HELSINKI, Finland
Tel: +358 9 756 240 83 (direct), +358 9 756 2400 (operator)
Fax: +358 9 756 240 11
E-mail: [log in to unmask]

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
May 2023
January 2023
March 2022
January 2022
December 2021
November 2021
May 2021
September 2020
August 2020
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