From wibral at MPIH-FRANKFURT.MPG.DE Mon Aug 1 11:45:11 2005 From: wibral at MPIH-FRANKFURT.MPG.DE (Michael Wibral) Date: Mon, 1 Aug 2005 11:45:11 +0200 Subject: Matlab 7 crashes with Fieldtrip graphics In-Reply-To: Message-ID: Hi, I had a similar problem with graphs of the same type (also not from within Fieldtrip) and it helped to change the OpenGL preferences of Matlab 7 by issuing the command: opengl('software') either on the command line before you run anything else or somewhere in your script before you actually do graphics. Matlab seems to have (a lot) of incomaptibilty problems with hardware implementations of Open GL. I hope that solves your problem, Michael Litvak Vladimir schrieb: > Dear Fieldtrip developers, > > I started using Matlab 7 and it crashes when using topoplotTFR almost > every time (especially if it was already running for a while prior to > that). I know it's not your bug but have you encountered this (on Win > XP)? This really gets on my nerves. If anyone else has this problem > maybe it's a good idea to ask Mathworks about it. > > Thanks, > > Vladimir > > . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maris at NICI.RU.NL Fri Aug 5 14:33:52 2005 From: maris at NICI.RU.NL (Eric Maris) Date: Fri, 5 Aug 2005 14:33:52 +0200 Subject: nonparametric statistics Message-ID: Dear all, Several people have asked me for a reference paper explaining the theory behing the nonparametric statistical tests that are performed in several Fieldtrip functions. Recently, together with Robert Oostenveld, I have submitted such a paper. You can find this paper in the Publications folder on the Fieldtrip website. greetings, dr. Eric Maris NICI/Biological Psychology and F.C. Donders Center for Cognitive NeuroImaging University of Nijmegen P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 (NICI) T:+31 24 3610754 (FCDC) F:+31 24 3616066 (NICI) E: maris at nici.ru.nl The University of Nijmegen will be named Radboud University Nijmegen as of September 1st, 2004 From h.f.kwok at BHAM.AC.UK Tue Aug 9 15:05:08 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 15:05:08 +0200 Subject: problems using fieldtrip Message-ID: This is the first time that I am using FieldTrip. Just like to ask what other software are needed besides MATLAB in order to run the tutorials. I have tried to run the tutorials after downloading and unzipping the Subject01.zip but I ran into problems. Firstly, in the Event Related Averaging tutorial, the EventRelatedAveraging.m was mentioned but I could not find the file. Secondly, after I created a cfg structure with 'Subject01.ds' as the dataset and all the other field properties as instructed in the tutorial, I got the following error message when using the preprocessing.m: CTF_READ_RES4 [v 1.12] ??? Error using ==> read_fcdc_header could not read CTF res4 header file Error in ==> preprocessing at 219 hdr = read_fcdc_header(cfg.headerfile); Can anyone help please? Regards, Hoi Fei From r.oostenveld at FCDONDERS.RU.NL Tue Aug 9 15:38:55 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 9 Aug 2005 15:38:55 +0200 Subject: problems using fieldtrip In-Reply-To: Message-ID: Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 15:48:44 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 14:48:44 +0100 Subject: problems using fieldtrip In-Reply-To: <78FC6891-F9A5-443C-8EC6-DA4AE1194C32@fcdonders.ru.nl> Message-ID: Thanks, Robert, The 'Subject01.ds' was in the search path. The error occurred whether I was in the same directory as the 'Subject01.ds' or not. When I typed the command while in the same directory as the 'Subject01.ds', I got this: CTF_READ_RES4 [v 1.12] ...done ( 0.79 sec) ??? Error using ==> read_fcdc_header could not read CTF res4 header file Error in ==> preprocessing at 219 hdr = read_fcdc_header(cfg.headerfile); Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 16:14:22 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 15:14:22 +0100 Subject: problems using fieldtrip In-Reply-To: <78FC6891-F9A5-443C-8EC6-DA4AE1194C32@fcdonders.ru.nl> Message-ID: Dear Robert, I have just tried to put breakpoints in some of the m-files to see what the problems are. I have found some potential causes of the problem. Starting from line 133 of the 'read_fcdc_header.m': if ctferror && haseegsf % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From Jan.Schoffelen at FCDONDERS.RU.NL Tue Aug 9 17:14:32 2005 From: Jan.Schoffelen at FCDONDERS.RU.NL (J.M. Schoffelen) Date: Tue, 9 Aug 2005 17:14:32 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59cec$a3af3270$e516bc93@universi8ef8be> Message-ID: Dear Hoi Fei, I think I have a clue of what is going on: if ctferror && haseegsf This is the thing that should not occur, so for some reason or another both haseegsf and ctferror are true: This means that somewhere in your path you have the files ctf_read_meg4, and ctf_read_res4, which usually is no problem, but in this case is half of your problem, because it makes the if-statement already half true. Next to this ctferror apparently is true, which should not be the case. It goes wrong in line 130, where ctferror is put to one after the catch, so the try did not work out too well. I would say that this could be caused by the fact that you lack the function read_ctf_res4 altogether, which should be located in the private-subdirectory of fieldtrip. This does not seem too likely to me, so I would guess that somehow the headerfile in line 126 is incorrecly formatted. To get an idea if this is the case, try to put a breakpoint in line 127 or so. Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? This might also be the problem. Hope this helps a bit, Yours, Jan-Mathijs % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 17:25:48 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 16:25:48 +0100 Subject: problems using fieldtrip In-Reply-To: <0IKY00HZWNO8K0@mailserver.uci.kun.nl> Message-ID: Hi, Jan-Mathijs, I have checked and the ctf_read_res4 file is in the private subdirectory and I was at the same folder as the Subject01.ds. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of J.M. Schoffelen Sent: 09 August 2005 16:15 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei, I think I have a clue of what is going on: if ctferror && haseegsf This is the thing that should not occur, so for some reason or another both haseegsf and ctferror are true: This means that somewhere in your path you have the files ctf_read_meg4, and ctf_read_res4, which usually is no problem, but in this case is half of your problem, because it makes the if-statement already half true. Next to this ctferror apparently is true, which should not be the case. It goes wrong in line 130, where ctferror is put to one after the catch, so the try did not work out too well. I would say that this could be caused by the fact that you lack the function read_ctf_res4 altogether, which should be located in the private-subdirectory of fieldtrip. This does not seem too likely to me, so I would guess that somehow the headerfile in line 126 is incorrecly formatted. To get an idea if this is the case, try to put a breakpoint in line 127 or so. Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? This might also be the problem. Hope this helps a bit, Yours, Jan-Mathijs % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From r.oostenveld at FCDONDERS.RU.NL Tue Aug 9 20:57:05 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 9 Aug 2005 20:57:05 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59cf6$9e7d0b10$e516bc93@universi8ef8be> Message-ID: Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From h.f.kwok at BHAM.AC.UK Wed Aug 10 09:55:35 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 08:55:35 +0100 Subject: problems using fieldtrip In-Reply-To: Message-ID: Hi, When I typed "which ctf_read_res4" in Matlab, it returned: C:\Program Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01\ctf_read_res4.m Is it because of the EEGLab plugins that I installed previously then? Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 19:57 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From h.f.kwok at BHAM.AC.UK Wed Aug 10 09:57:45 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 08:57:45 +0100 Subject: problems using fieldtrip In-Reply-To: Message-ID: Hi, I've removed the EEGlab from the path and now the FieldTrip is working all right. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 19:57 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Wed Aug 10 09:58:27 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Wed, 10 Aug 2005 09:58:27 +0200 Subject: problems using fieldtrip In-Reply-To: <000401c59d80$e43ec1e0$e516bc93@universi8ef8be> Message-ID: Hi Hoi Fei On 10-aug-2005, at 9:55, Hoi Fei Kwok wrote: > When I typed "which ctf_read_res4" in Matlab, it returned: > C:\Program > Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01 > \ctf_read_res4.m > > Is it because of the EEGLab plugins that I installed previously then? > Yes, that might well be the problem. Please remove the EEGLAB directory from your matlab search path and try the tutorial again. Robert From h.f.kwok at BHAM.AC.UK Wed Aug 10 10:37:51 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 09:37:51 +0100 Subject: problems using fieldtrip In-Reply-To: <596064D3-DD4C-4F24-A018-C7F65FC3B67D@fcdonders.ru.nl> Message-ID: Hi, On one hand, removing the EEGLAB solved the problem. On the other hand, the FieldTrip website mentioned about integrating the FieldTrip with the EEGLAB. So how should one go about that? Maybe the problem I encountered indicates that one should avoid certain EEGLAB plugins if one wants to use both the EEGLAB and FieldTrip. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 10 August 2005 08:58 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei On 10-aug-2005, at 9:55, Hoi Fei Kwok wrote: > When I typed "which ctf_read_res4" in Matlab, it returned: > C:\Program > Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01 > \ctf_read_res4.m > > Is it because of the EEGLab plugins that I installed previously then? > Yes, that might well be the problem. Please remove the EEGLAB directory from your matlab search path and try the tutorial again. Robert From r.oostenveld at FCDONDERS.RU.NL Wed Aug 10 12:03:50 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Wed, 10 Aug 2005 12:03:50 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59d86$cb7702c0$e516bc93@universi8ef8be> Message-ID: Hi, EEGLAB is (or will be in the near future) using the source localization features of Fieldtrip, i.e. it is one-way traffic. I expect that the reading of the data and processing of the data up to the point of the scalp maps will be done completely in EEGLAB, hence the problem that you now encountered (i.e. conflicting low-level data importers) will not pose an immediate problem for people who use it as intended. However, I also hope that once the integration gets into shape that also more low-level code will be shared between the two and then we might run into these problems more often. So it is good for us to hear about issues like these. Robert On 10-aug-2005, at 10:37, Hoi Fei Kwok wrote: > Hi, > > On one hand, removing the EEGLAB solved the problem. On the other > hand, the > FieldTrip website mentioned about integrating the FieldTrip with > the EEGLAB. > So how should one go about that? Maybe the problem I encountered > indicates > that one should avoid certain EEGLAB plugins if one wants to use > both the > EEGLAB and FieldTrip. > > Regards, > Hoi Fei > From sanja at UNM.EDU Thu Aug 11 22:52:12 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Thu, 11 Aug 2005 22:52:12 +0200 Subject: combineplanar Message-ID: Hello, I am trying to use meginterpolate/freqanalysis/combineplanar to get the tfr data in the planar gradiometer system, instead of the original 275 ch axial. However, combineplanar needs planarchannelset, but this function is not included in the 20050811 distribution. Could you include this function in the next distribution? I have a set of questions related to meginterpolate: Can CTF274.lay be used for ploting the planar data? Should I use a default single sphere model for each subject or a single sphere model particular for a subject for realignment? Should "nominal" sensor locations be used as a template for each subject, or do you recommend taking an average across subjects for the template? I appreciate your help, Sanja Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From holroydt at MAIL.NIH.GOV Thu Aug 11 23:26:41 2005 From: holroydt at MAIL.NIH.GOV (Tom Holroyd) Date: Thu, 11 Aug 2005 17:26:41 -0400 Subject: combineplanar In-Reply-To: Message-ID: Sanja Kovacevic wrote: > I have a set of questions related to meginterpolate: Can CTF274.lay be used > for ploting the planar data? I don't know the answer to your question, but I would like to note that CTF274.lay is based on the NIMH system which has one dead SQUID, namely MRF43. You might want to generate a CTF275.lay with that channel replaced. The meginterpolate code can actually "fix" dead channels anyway... > Should I use a default single sphere model for > each subject or a single sphere model particular for a subject for > realignment? Should "nominal" sensor locations be used as a template for > each subject, or do you recommend taking an average across subjects for the > template? Oh, as long as I'm here: Personally I wouldn't bother averaging across subjects, because even "aligned", averaging subjects together in sensor space is nearly meaningless. (Though an interesting project, by analogy to Talairach or MNI space, is to "warp" the sensor space data into a common space, based on "anatomical" landmarks such as the peaks of the AEF and/or SEF. I still wouldn't do that, though.) -- Dr. Tom Holroyd "A man of genius makes no mistakes. His errors are volitional and are the portals of discovery." -- James Joyce From ole.jensen at FCDONDERS.RU.NL Fri Aug 12 12:13:44 2005 From: ole.jensen at FCDONDERS.RU.NL (Ole Jensen) Date: Fri, 12 Aug 2005 12:13:44 +0200 Subject: averaging in sensor space In-Reply-To: <42FBC291.2070105@mail.nih.gov> Message-ID: Regarding the discussion on planar gradients and averaging over subjects: As Tom suggests it is always best to average over subjects in source space. However, sometimes we do not have high enough signal-to-noise in order to reliably identify the sources while we still observe consistent effects at the sensor level. I think it is an important discussion since it pertains to how we approach MEG data in general. Therefore I would like to provide an argument for why I believe it is sensible to average over subjects in sensor space: Say that a dataset has been analyzed in the frequency domain and we have representations of power for each sensor. I find it convenient to apply the combined planar gradient for power representations since this will tend to give the strongest power in sensors above the source. An axial gradient representation will result in two regions of strong power at each side of the source (i.e. where the fields exit and enter). We have had quite good luck averaging combined planar gradient power representations over subjects at the sensors level both with and without realignment. The FieldTrip has statistical methods implemented for dealing with the multiple comparison problem (multiple sensors). Also, for instance the group in Tuebingen has several publications were power (albeit using axial gradients) where they average over subjects at the sensor level. The approach is quite similar to that applied by the ERD/ERS community on EEG data. Note that differences in head size, position etc might diminish a given effect - however, I do not believe that averaging over subjects in sensor space will result in false positives. With respect to event related fields one should be very careful averaging the axial gradient over subjects at the sensor level. The orientation of sources from subject to subject might be different thus partially canceling a given effect. One solution is to calculate the RMS of the two orientations of the planar gradient and then average over subjects. This has for instance been done convincingly by the BRU/LTL Helsinki group in N400m studies. We have also good experiences with that approach at the Donders. The main disadvantage of averaging combined planar gradients of ERFs is that we loose information about source orientation. I would advice against doing source modeling on MEG data which has been averaged over subjects (this is often done for EEG data). Here it is appropriate to average either a current estimate of "beamformed" power estimate in source space after realigning the source representations to a standard brain. We are often using the following approach 1) Calculate time-frequency representations (TFRs) of power for planar gradients 2) Combined the planar gradient for each orientation 3) Average over subjects in sensors space 4) Use randomization statistics to identify clusters of difference 5) Use the beamformer to estimate power in source space for time and freq tiles identified in 4) in individual subjects 6) Morph the results of beamformed power to a standard brain 7) Average morphed power representations in source space Bests, Ole > Oh, as long as I'm here: > > Personally I wouldn't bother averaging across subjects, because even > "aligned", averaging subjects together in sensor space is nearly > meaningless. (Though an interesting project, by analogy to Talairach > or MNI space, is to "warp" the sensor space data into a common space, > based on "anatomical" landmarks such as the peaks of the AEF and/or > SEF. I still wouldn't do that, though.) > -- Ole Jensen Principal Investigator F.C. Donders Centre for Cognitive Neuroimaging P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Office : +31 24 36 10884 MEG lab : +31 24 36 10988 Fax : +31 24 36 10989 e-mail : ole.jensen at fcdonders.ru.nl URL : http://oase.uci.ru.nl/~olejen From r.oostenveld at FCDONDERS.RU.NL Fri Aug 12 14:02:20 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 12 Aug 2005 14:02:20 +0200 Subject: combineplanar In-Reply-To: Message-ID: Hi Sanja, On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: > I am trying to use meginterpolate/freqanalysis/combineplanar to get > the tfr > data in the planar gradiometer system, instead of the original 275 > ch axial. > However, combineplanar needs planarchannelset, but this function is > not > included in the 20050811 distribution. Could you include this > function in > the next distribution? Please find the function attached to this mail. I will add it to the next daily releases, sorry that it was missing. The attached version however does not include the 275ch CTF system yet, but it is easy to add. You basically only have to make a table with the planar channel labels that should be combined, and the name of the combined channel (i.e. the original name). I would appreciate it if you would send me the table information for the CTF 275 system, I will then update the release version as well. > I have a set of questions related to meginterpolate: Can CTF274.lay > be used > for ploting the planar data? Should I use a default single sphere > model for > each subject or a single sphere model particular for a subject for > realignment? Should "nominal" sensor locations be used as a > template for > each subject, or do you recommend taking an average across subjects > for the > template? Yes, but only for combineplanar'ed data in combination with topoplotTFR. It is conceptually not possible to make a topography of the "raw" planar data itself, but you can do a multiplotER and multiplotTFR of the planar data. However, that would require another lay file. The NM122all.lay file is one for the Neuromag system that plots the 122 planar channels at 66 locations, with horizontal and vertical channel next to each other. If you do not specify a layout in the cfg of multiplotTFR, the private subfunction createlayout will construct a layout on the fly based on the gradiometer positions. Usually the plotting is more controlled with a manually eddited layout file, but the automatic one can serve as starting point. Looking into the code, I now realise that there still are some loose ends. The megplanar function does not return the planar gadiometer definition. Please have a look at the private functions axial2planar and createlayout, and use them together to construct a planar layout file. best regards, Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: planarchannelset.m Type: application/octet-stream Size: 16045 bytes Desc: not available URL: From r.oostenveld at FCDONDERS.RU.NL Fri Aug 12 14:10:14 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 12 Aug 2005 14:10:14 +0200 Subject: averaging in sensor space In-Reply-To: <42FC7658.7060606@fcdonders.ru.nl> Message-ID: Hi guys, Just some additions to Ole's nice arguments... On 12-aug-2005, at 12:13, Ole Jensen wrote: > We are often using the following approach > 1) Calculate time-frequency representations (TFRs) of power for > planar gradients > 2) Combined the planar gradient for each orientation > 3) Average over subjects in sensors space > 4) Use randomization statistics to identify clusters of difference Prior to step 1, we would MEGREALIGN the raw data as obtained from preprocessing to a template helmet location (typically the average over all subjects in the study). That realigmnent reduces some variance in the averaging in step 3. After determining the time-frequency tile of interest (step 4), we go back to the original data as obtained from PREPROCESSING (i.e. prior to MEGREALIGN) and repeat FERQANALYSIS with settings (timewindow +frequency+multitapers) that are tuned to optimize the frequency estimate in that TF tile. And then we continue with > 5) Use the beamformer to estimate power in source space for time > and freq tiles identified in 4) in individual subjects > 6) Morph the results of beamformed power to a standard brain > 7) Average morphed power representations in source space best, Robert From sanja at UNM.EDU Fri Aug 12 17:01:09 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 12 Aug 2005 09:01:09 -0600 Subject: averaging in sensor space In-Reply-To: <42FC7658.7060606@fcdonders.ru.nl> Message-ID: On Fri, 12 Aug 2005 12:13:44 +0200 Ole Jensen wrote: > Regarding the discussion on planar gradients and >averaging over subjects: > > As Tom suggests it is always best to average over >subjects in source space. However, sometimes we do not >have high enough signal-to-noise in order to reliably >identify the sources while we still observe consistent >effects at the sensor level. I think it is an important >discussion since it pertains to how we approach MEG data >in general. Therefore I would like to provide an argument >for why I believe it is sensible to average over subjects >in sensor space: > > Say that a dataset has been analyzed in the frequency >domain and we have representations of power for each >sensor. I find it convenient to apply the combined planar >gradient for power representations since this will tend >to give the strongest power in sensors above the source. >An axial gradient representation will result in two >regions of strong power at each side of the source (i.e. >where the fields exit and enter). We have had quite good >luck averaging combined planar gradient power >representations over subjects at the sensors level both >with and without realignment. The FieldTrip has >statistical methods implemented for dealing with the >multiple comparison problem (multiple sensors). Also, for >instance the group in Tuebingen has several publications >were power (albeit using axial gradients) where they >average over subjects at the sensor level. The approach >is quite similar to that applied by the ERD/ERS community >on EEG data. Note that differences in head size, position >etc might diminish a given effect - however, I do not >believe that averaging over subjects in sensor space will >result in false positives. > > With respect to event related fields one should be very >careful averaging the axial gradient over subjects at the >sensor level. The orientation of sources from subject to >subject might be different thus partially canceling a >given effect. One solution is to calculate the RMS of the >two orientations of the planar gradient and then average >over subjects. This has for instance been done >convincingly by the BRU/LTL Helsinki group in N400m >studies. We have also good experiences with that approach >at the Donders. The main disadvantage of averaging >combined planar gradients of ERFs is that we loose >information about source orientation. > > I would advice against doing source modeling on MEG data >which has been averaged over subjects (this is often done >for EEG data). Here it is appropriate to average either a >current estimate of "beamformed" power estimate in source >space after realigning the source representations to a >standard brain. > > We are often using the following approach > > 1) Calculate time-frequency representations (TFRs) of >power for planar gradients > 2) Combined the planar gradient for each orientation > 3) Average over subjects in sensors space > 4) Use randomization statistics to identify clusters of >difference > 5) Use the beamformer to estimate power in source space >for time and freq tiles identified in 4) in individual >subjects > 6) Morph the results of beamformed power to a standard >brain > 7) Average morphed power representations in source space > > > Bests, > > Ole > > > > > > >> Oh, as long as I'm here: >> >> Personally I wouldn't bother averaging across subjects, >>because even >> "aligned", averaging subjects together in sensor space >>is nearly >> meaningless. (Though an interesting project, by analogy >>to Talairach >> or MNI space, is to "warp" the sensor space data into a >>common space, >> based on "anatomical" landmarks such as the peaks of the >>AEF and/or >> SEF. I still wouldn't do that, though.) >> > > > -- > Ole Jensen > Principal Investigator >F.C. Donders Centre for Cognitive Neuroimaging > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Office : +31 24 36 10884 > MEG lab : +31 24 36 10988 > >Fax : +31 24 36 10989 > > e-mail : ole.jensen at fcdonders.ru.nl > URL : http://oase.uci.ru.nl/~olejen Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From scrofa at GMAIL.COM Sun Aug 14 14:25:22 2005 From: scrofa at GMAIL.COM (Daniel Kislyuk) Date: Sun, 14 Aug 2005 15:25:22 +0300 Subject: importing 306-Vectorview dataset Message-ID: Hello! I'm trying to import neuromag data (with EEG) to fieldtrip using read_fcdc_header and read_fcdc_data routines, but i keep getting these error message: ---------------------------------------------------------------------------------- ??? Attempt to execute SCRIPT megmodel as a function. Error in ==> d:\danielk\fieldtrip\private\fif2grad.m On line 19 ==> megmodel('head',[0 0 0],filename); Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m On line 245 ==> hdr.grad = fif2grad(headerfile); ----------------------------------------------------------------------------------- Could you, please, help me? Thanks, Daniel From tnt at PHYSIOL.OX.AC.UK Sun Aug 14 16:53:26 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Sun, 14 Aug 2005 16:53:26 +0200 Subject: calculating frequency interaction Message-ID: Hi, I have a conceptual question which I'd like to post to the list. It has been the practice in multisensory research to define the integration of two inputs from different sensory modalities (e.g. auditory (A) and visual (V)) by calculating the interaction [AV - (A+V)], where AV is the simultaneous presentation of both unisensory stimuli. There, it is assumed that any non-linear summation denotes the interaction of the two sensory streams, and hence, is a measure of multisensory integration. For example, assume the following response profile A = 2 units V = 3 units AV = 6 units then the bimodal presentation AV cannot be predicted by the summation of the unimodal inputs alone, hence the difference is thought to be related to multisensory integration. This has been applied to both fMRI and ERP data (from MEG & EEG). (There are, of course, some confounds associated with this method, such as attention, etc, but that's a different matter.) I am interested in how this interaction effect can be calculated with frequency data. Frequency power estimates are done by squaring the amplitude of the bandpassed response, so there is already a "non-linear" step involved in the process. Calculating the interaction as above could then result in erroneous estimates of the integration effect: A = 4 units V = 9 units AV = 36 units From tnt at PHYSIOL.OX.AC.UK Sun Aug 14 17:05:18 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Sun, 14 Aug 2005 17:05:18 +0200 Subject: calculating frequency interaction (now with the complete message) Message-ID: SORRY, I send the last message too early by mistake. Please find the whole text below T. == Hi, I have a conceptual question which I'd like to post to the list. It has been the practice in multisensory research to define the integration of two inputs from different sensory modalities (e.g. auditory (A) and visual (V)) by calculating the interaction [AV - (A+V)], where AV is the simultaneous presentation of both unisensory stimuli. There, it is assumed that any non-linear summation denotes the interaction of the two sensory streams, and hence, is a measure of multisensory integration. For example, assume the following response profile A = 2 units V = 3 units AV = 6 units integration effect = 6-(2+3)= 1 Here, the response to the bimodal presentation AV cannot be predicted by the summation of the unimodal inputs alone, hence the difference is thought to be related to multisensory integration. This has been applied to both fMRI and ERP data (from MEG & EEG). (There are, of course, some confounds associated with this method, such as attention, etc, but that's a different matter.) I am interested in how this interaction effect can be calculated with frequency data. Frequency power estimates are done by squaring the amplitude of the bandpassed response, so there is already a "non-linear" step involved in the process. Calculating the interaction as above could then result in erroneous estimates of the integration effect: A = 3 units; squared = 9 V = 3 units; squared = 9 AV = 6 units; squared = 36 integration effect = 6^2-(3^2+3^2) = 18 even though it is quite evident that the neuronal response to AV is a direct summation of A and V. Any suggestions on how to solve this problem would be greatly appreciated. Thomas From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 09:33:48 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 09:33:48 +0200 Subject: importing 306-Vectorview dataset In-Reply-To: <489aa9f90508140525ff5f78c@mail.gmail.com> Message-ID: Hi Daniel, Did you download and install the MEG-PD toolbox (see http:// www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an extra shared library that is missing in the meg-pd tgz file, see http://oase.uci.kun.nl/~roberto/index.php/neuromag/. Fieldtrip does not support the Neuromag *.fif file format natively, since it is a closed file format. However, Fieldtrip can use the MEG- PD toolbox. What is does is to call the appropriate functions from the MEG-PD toolbox, and to reformat their output into a format that all Fieldtrip functions can handle. The "megmodel" function is a function from the MEG-PD toolbox. This MEG-PD toolbox contains mex files, and they are only provided for linux and HPUX. That means that you cannot read Neuromag data in Matlab under Windows. Besides the mex files (i.e. a file named megmodel.mexglx), there are documentation files (i.e. megmodel.m). These documentation files contain only help and cannot be executed. I suspect that the mex file is missing in your installation. Please type "which megmodel" and check whether it is the mexglx or the m file. best regards Robert On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > Hello! > > I'm trying to import neuromag data (with EEG) to fieldtrip using > read_fcdc_header and read_fcdc_data routines, but i keep getting these > error message: > > ---------------------------------------------------------------------- > ------------ > ??? Attempt to execute SCRIPT megmodel as a function. > > Error in ==> d:\danielk\fieldtrip\private\fif2grad.m > On line 19 ==> megmodel('head',[0 0 0],filename); > > Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m > On line 245 ==> hdr.grad = fif2grad(headerfile); > ---------------------------------------------------------------------- > ------------- > > Could you, please, help me? > > Thanks, > Daniel > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 09:55:20 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 09:55:20 +0200 Subject: calculating frequency interaction (now with the complete message) In-Reply-To: Message-ID: Hi Thomas, On 14-aug-2005, at 17:05, Thomas Thesen wrote: > Calculating the interaction as above could then result in erroneous > estimates of the integration effect: > > A = 3 units; squared = 9 > V = 3 units; squared = 9 > AV = 6 units; squared = 36 > > integration effect = 6^2-(3^2+3^2) = 18 > > even though it is quite evident that the neuronal response to AV is > a direct > summation of A and V. > The effect of summation of the two signals on the estimated power (or amplitude) of their sum depends on the phase relation between the two signals. 1) If the two signals are in perfect phase alignment in each trial (i.e. zero deg phase difference), they will add up as you described. 2) If they are in perfect antiphase (180 deg), they will cancel out. 3) If they have a random phase with respect to each other, i.e. the phase difference is different in each trial, they will add up "a little". In case 1, the amplitude (i.e. sqrt of the power) depends linearly on the amplitude of the two signals. In case 3, the power depends linearly on the power of the two signals. Please try playing with the following lines of code real_pow1 = 3; real_pow2 = 3; t = linspace(0, 2*pi, 1000); for trl=1:100 s1(trl,:) = sqrt(real_pow1)*sqrt(2)*sin(t); phasediff = 2*pi*rand(size(t)); % CHANGE THIS TO SEE THE EFFECT s2(trl,:) = sqrt(real_pow2)*sqrt(2)*sin(t + phasediff); end % add the two signals for each trial s3 = s1+s2; % estimate the single trial power pow_s1 = sum(s1.^2,2)/length(t); pow_s2 = sum(s2.^2,2)/length(t); pow_s3 = sum(s3.^2,2)/length(t); % estimate the power and amplitude pow1 = sum(pow_s1)./100 pow2 = sum(pow_s2)./100 pow3 = sum(pow_s3)./100 ampl1 = sqrt(pow1) ampl2 = sqrt(pow2) ampl3 = sqrt(pow3) I hope that this clarifies it. Of course, it does not yet help you deciding how to test for the interaction, since the additive effect (which you expect under the null hypothesis) can be either on amplitude or on power. To choose the right test, you will have to consider the sources of the two signals that are being mixed on the channel level, i.e. are they coming from one source, or from two sources, and in the latter case, are the two sources strongly coherent or not? best regards, Robert ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From D.Talsma at PSY.VU.NL Mon Aug 15 13:34:04 2005 From: D.Talsma at PSY.VU.NL (Talsma D) Date: Mon, 15 Aug 2005 13:34:04 +0200 Subject: Differences in channel numbers and MEG Interpolate Message-ID: Hi Fieldtrippers, I have the following question regarding meginterpolate: Is it possible to use MEG interpolate to add a channel to the dataset that was never recorded in the first place? I have data from a limited number of subjects that is recorded with one channel (MLO21) less (149 channels) than the data from the other subjects (150 MEG channels). From what I can tell, this is not a channel that is just marked as 'Bad', but one that was never recorded in the first place. I tried interpolating this channel using meginterpolate, but after this procedure, I still have a dataset with 149 channels. Below are the settings I used. Needless to say, I tried various variations, but none appeared to work. For now, I'm going to try and remove the offending channel from the remaining subjects that were recorded with 150 channels. Thanks in advance, Durk templatefile = { 'pp01/corr-resp.ds', 'pp01/incor-resp.ds', 'pp02/corr-resp.ds', 'pp02/incor-resp.ds', 'pp03/corr-resp.ds', 'pp03/incor-resp.ds', 'pp04/corr-resp.ds', 'pp04/incor-resp.ds', 'pp06/corr-resp.ds', 'pp06/incor-resp.ds', 'pp09/corr-resp.ds', 'pp09/incor-resp.ds', 'pp10/corr-resp.ds', 'pp10/incor-resp.ds', 'pp11/corr-resp.ds', 'pp11/incor-resp.ds', 'pp12/corr-resp.ds', 'pp12/incor-resp.ds', 'pp13/corr-resp.ds', 'pp13/incor-resp.ds', 'pp14/corr-resp.ds', 'pp14/incor-resp.ds', 'pp15/corr-resp.ds', 'pp15/incor-resp.ds' }; cfgrepair = []; cfgrepair.repair = 'yes'; cfgrepair.realign = 'no'; cfgrepair.planar = 'no'; cfgrepair.template =templatefile; cfgrepair.hdmfile ='standard.hdm'; cfgrepair.badchannel = {'MLO21'}; dataCor_corrected = meginterpolate(cfgrepair, dataCor); dataInc_corrected = meginterpolate(cfgrepair, dataInc); From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 13:55:44 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 13:55:44 +0200 Subject: Differences in channel numbers and MEG Interpolate In-Reply-To: Message-ID: Hi Durk, No, that is not possible. Megrepair will only interpolate an existing channel (using nearest neighbours). What you can do is to manually add the channel to your preprocessed dataset. E.g. cfg = ... raw = preprocessing(cfg); raw.label{end+1} = 'MLO21'; for i=1:length(data.trial) data.trial{i}(end+1,:) = 0; end Btw. I suggest to call MERREPAIR, MEGREALIGN and MEGPLANAR seperately and not use the MEGINTERPOLATE (in the old days, there was this one function, but that was split up into its logical components). best, Robert On 15-aug-2005, at 13:34, Talsma D wrote: > Hi Fieldtrippers, > > I have the following question regarding meginterpolate: Is it possible > to use MEG interpolate to add a channel to the dataset that was never > recorded in the first place? I have data from a limited number of > subjects that is recorded with one channel (MLO21) less (149 channels) > than the data from the other subjects (150 MEG channels). From what I > can tell, this is not a channel that is just marked as 'Bad', but one > that was never recorded in the first place. I tried interpolating this > channel using meginterpolate, but after this procedure, I still have a > dataset with 149 channels. Below are the settings I used. Needless to > say, I tried various variations, but none appeared to work. > > For now, I'm going to try and remove the offending channel from the > remaining subjects that were recorded with 150 channels. > > Thanks in advance, > Durk > > > templatefile = { 'pp01/corr-resp.ds', > 'pp01/incor-resp.ds', > 'pp02/corr-resp.ds', > 'pp02/incor-resp.ds', > 'pp03/corr-resp.ds', > 'pp03/incor-resp.ds', > 'pp04/corr-resp.ds', > 'pp04/incor-resp.ds', > 'pp06/corr-resp.ds', > 'pp06/incor-resp.ds', > 'pp09/corr-resp.ds', > 'pp09/incor-resp.ds', > 'pp10/corr-resp.ds', > 'pp10/incor-resp.ds', > 'pp11/corr-resp.ds', > 'pp11/incor-resp.ds', > 'pp12/corr-resp.ds', > 'pp12/incor-resp.ds', > 'pp13/corr-resp.ds', > 'pp13/incor-resp.ds', > 'pp14/corr-resp.ds', > 'pp14/incor-resp.ds', > 'pp15/corr-resp.ds', > 'pp15/incor-resp.ds' > }; > > cfgrepair = []; > cfgrepair.repair = 'yes'; > cfgrepair.realign = 'no'; > cfgrepair.planar = 'no'; > cfgrepair.template =templatefile; > cfgrepair.hdmfile ='standard.hdm'; > cfgrepair.badchannel = {'MLO21'}; > > dataCor_corrected = meginterpolate(cfgrepair, dataCor); > dataInc_corrected = meginterpolate(cfgrepair, dataInc); > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From jhouck at UNM.EDU Mon Aug 15 19:17:33 2005 From: jhouck at UNM.EDU (Jon Houck) Date: Mon, 15 Aug 2005 11:17:33 -0600 Subject: importing 306-Vectorview dataset Message-ID: Hello, Kimmo has a partial Windows version of the MEG-PD toolbox posted on his site now. I've used it successfully with 306-channel data in the old 4D Toolbox, but haven't tested it with Fieldtrip yet. It may be of some use here. Regards, Jon Houck ----- Original Message ----- From: "Robert Oostenveld" To: Sent: Monday, August 15, 2005 1:33 AM Subject: Re: [FIELDTRIP] importing 306-Vectorview dataset > Hi Daniel, > > Did you download and install the MEG-PD toolbox (see http:// > www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an > extra shared library that is missing in the meg-pd tgz file, see > http://oase.uci.kun.nl/~roberto/index.php/neuromag/. > > Fieldtrip does not support the Neuromag *.fif file format natively, > since it is a closed file format. However, Fieldtrip can use the MEG- > PD toolbox. What is does is to call the appropriate functions from > the MEG-PD toolbox, and to reformat their output into a format that > all Fieldtrip functions can handle. The "megmodel" function is a > function from the MEG-PD toolbox. This MEG-PD toolbox contains mex > files, and they are only provided for linux and HPUX. That means that > you cannot read Neuromag data in Matlab under Windows. Besides the > mex files (i.e. a file named megmodel.mexglx), there are > documentation files (i.e. megmodel.m). These documentation files > contain only help and cannot be executed. I suspect that the mex file > is missing in your installation. Please type "which megmodel" and > check whether it is the mexglx or the m file. > > best regards > Robert > > > > > On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > > > Hello! > > > > I'm trying to import neuromag data (with EEG) to fieldtrip using > > read_fcdc_header and read_fcdc_data routines, but i keep getting these > > error message: > > > > ---------------------------------------------------------------------- > > ------------ > > ??? Attempt to execute SCRIPT megmodel as a function. > > > > Error in ==> d:\danielk\fieldtrip\private\fif2grad.m > > On line 19 ==> megmodel('head',[0 0 0],filename); > > > > Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m > > On line 245 ==> hdr.grad = fif2grad(headerfile); > > ---------------------------------------------------------------------- > > ------------- > > > > Could you, please, help me? > > > > Thanks, > > Daniel > > > > > > ======================================================= > Robert Oostenveld, PhD > F.C. Donders Centre for Cognitive Neuroimaging > Radboud University Nijmegen > phone: +31-24-3619695 > http://www.ru.nl/fcdonders/ > From lauri at NEURO.HUT.FI Mon Aug 15 21:43:58 2005 From: lauri at NEURO.HUT.FI (Lauri Parkkonen) Date: Mon, 15 Aug 2005 22:43:58 +0300 Subject: importing 306-Vectorview dataset In-Reply-To: <5757A7A1-9C27-4487-8906-6FD1603C53C4@fcdonders.ru.nl> Message-ID: Hi Daniel and other Fieldtrippers, To read the Neuromag files into Fieldtrip/Matlab you need Kimmo Uutela's FiffAccess (aka meg-pd) package, available for Linux, HPUX and Windows as Robert and Jon pointed out. The packages do contain the required shared library, however, you need to tell the Linux dynamic linker where to find this library before starting Matlab (see the FiffAccess manual/Installation instructions). This step is often forgotten so I wrote here some instructions (assuming you're running Linux). You have two options to tell the system where to look for the new library: 1) User-specific configuration: Set the environment variable LD_LIBRARY_PATH to point to the library directory before starting Matlab: - sh/bash users export LD_LIBRARY_PATH /opt/neuromag/lib/i586-pc-linux-gnu - tcsh/csh users setenv LD_LIBRARY_PATH /opt/neuromag/lib/i586-pc-linux-gnu (there are some inconsistencies whether the architecture is i586-... or i686-...; please check in which one you actually find the library file after installing the FiffAccess package and substitute accordingly) 2) System-wide configuration: As the root user, add the line /opt/neuromag/lib/i586-pc-linux-gnu to /etc/ld.so.conf (or - in some Linux distros - make a file containing that line and put the file under /etc/ld.so.conf.d) and run /sbin/ldconfig. With both options, you can check if the shared lib is found correctly by saying ldd /opt/neuromag/meg_pd_1.2/megmodel.mexglx which should print out something like: linux-gate.so.1 => (0x00d02000) libmagnet_pdg_1.2.so => /opt/neuromag/lib/i586-pc-linux-gnu/libmagnet_pdg_1.2.so (0x00beb000) libmx.so => not found libmex.so => not found libmat.so => not found libm.so.6 => /lib/libm.so.6 (0x0051e000) libc.so.6 => /lib/libc.so.6 (0x003ba000) /lib/ld-linux.so.2 (0x0027b000) Don't worry about libmx, libmex and libmat not being found; they'll be linked correctly by Matlab. Hope this helps you to get the Neuromag file import working. Best regards, Lauri Robert Oostenveld wrote: > Hi Daniel, > > Did you download and install the MEG-PD toolbox (see http:// > www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an > extra shared library that is missing in the meg-pd tgz file, see > http://oase.uci.kun.nl/~roberto/index.php/neuromag/. > > Fieldtrip does not support the Neuromag *.fif file format natively, > since it is a closed file format. However, Fieldtrip can use the MEG- > PD toolbox. What is does is to call the appropriate functions from > the MEG-PD toolbox, and to reformat their output into a format that > all Fieldtrip functions can handle. The "megmodel" function is a > function from the MEG-PD toolbox. This MEG-PD toolbox contains mex > files, and they are only provided for linux and HPUX. That means that > you cannot read Neuromag data in Matlab under Windows. Besides the > mex files (i.e. a file named megmodel.mexglx), there are > documentation files (i.e. megmodel.m). These documentation files > contain only help and cannot be executed. I suspect that the mex file > is missing in your installation. Please type "which megmodel" and > check whether it is the mexglx or the m file. > > best regards > Robert > > > > > On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > >> Hello! >> >> I'm trying to import neuromag data (with EEG) to fieldtrip using >> read_fcdc_header and read_fcdc_data routines, but i keep getting these >> error message: >> >> ---------------------------------------------------------------------- >> ------------ >> ??? Attempt to execute SCRIPT megmodel as a function. >> >> Error in ==> d:\danielk\fieldtrip\private\fif2grad.m >> On line 19 ==> megmodel('head',[0 0 0],filename); >> >> Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m >> On line 245 ==> hdr.grad = fif2grad(headerfile); >> ---------------------------------------------------------------------- >> ------------- >> >> Could you, please, help me? >> >> Thanks, >> Daniel >> >> > > ======================================================= > Robert Oostenveld, PhD > F.C. Donders Centre for Cognitive Neuroimaging > Radboud University Nijmegen > phone: +31-24-3619695 > http://www.ru.nl/fcdonders/ -- ----------------------------------------------- Lauri Parkkonen Brain Research Unit, Low Temperature Laboratory Helsinki University of Technology Otakaari 3 A, 02150 ESPOO, FINLAND tel: +358-9-4512965 fax: +358-9-4512969 mailto:lauri at neuro.hut.fi http://boojum.hut.fi From tnt at PHYSIOL.OX.AC.UK Mon Aug 15 23:41:55 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Mon, 15 Aug 2005 23:41:55 +0200 Subject: calculating frequency interaction (now with the complete message) Message-ID: Hi Rob, Thanks for the simulation. That really helped to make the issue clear! If others are interested to see how the phase relationship between two signals relates to the linearity or non-linearity of the summed power or amplitudes can have a look at these figures that were derived from Robs code below: http://www.physiol.ox.ac.uk/~tnt/fieldtrip/ FT_phase1.jpg FT_phase2.jpg One example shows perfect phase and one anti-phase. The bottom graph shows the phase relationship of the signals for condition A and V, and their sum A+V. In the code that's s1 to s3. The top graphs show the values for amplitude (ampl1 to ampl3) and power (pow1 to pow3). Diff is the subtraction of pow3-pow2-pow1 (or the same foe amp). If diff is zero the summation is linear. Rob, your comments regarding the appropriate approach for testing the interaction are very insightful. Thank you. Considering that MEG/EEG data contain a lot from both of these options it seems unwise to do this type of testing. One couldn't tell wether a different phase relationship or a true effect might be responsible for non-linear summation. Or am I wrong there? I just saw at a conference a poster where they tried the same thing using bootstrapping. The web link above contains a copy of that poster "Senkowski...jpg". What do you think about this approach? Could that be done using FieldTrip? Thanks a lot, Thomas On Mon, 15 Aug 2005 09:55:20 +0200, Robert Oostenveld wrote: >Hi Thomas, > >On 14-aug-2005, at 17:05, Thomas Thesen wrote: > > >> Calculating the interaction as above could then result in erroneous >> estimates of the integration effect: >> >> A = 3 units; squared = 9 >> V = 3 units; squared = 9 >> AV = 6 units; squared = 36 >> >> integration effect = 6^2-(3^2+3^2) = 18 >> >> even though it is quite evident that the neuronal response to AV is >> a direct >> summation of A and V. >> > >The effect of summation of the two signals on the estimated power (or >amplitude) of their sum depends on the phase relation between the two >signals. >1) If the two signals are in perfect phase alignment in each trial >(i.e. zero deg phase difference), they will add up as you described. >2) If they are in perfect antiphase (180 deg), they will cancel out. >3) If they have a random phase with respect to each other, i.e. the >phase difference is different in each trial, they will add up "a >little". >In case 1, the amplitude (i.e. sqrt of the power) depends linearly on >the amplitude of the two signals. In case 3, the power depends >linearly on the power of the two signals. > >Please try playing with the following lines of code > >real_pow1 = 3; >real_pow2 = 3; >t = linspace(0, 2*pi, 1000); > >for trl=1:100 > s1(trl,:) = sqrt(real_pow1)*sqrt(2)*sin(t); > phasediff = 2*pi*rand(size(t)); % CHANGE THIS TO SEE THE EFFECT > s2(trl,:) = sqrt(real_pow2)*sqrt(2)*sin(t + phasediff); >end > >% add the two signals for each trial >s3 = s1+s2; > >% estimate the single trial power >pow_s1 = sum(s1.^2,2)/length(t); >pow_s2 = sum(s2.^2,2)/length(t); >pow_s3 = sum(s3.^2,2)/length(t); > >% estimate the power and amplitude >pow1 = sum(pow_s1)./100 >pow2 = sum(pow_s2)./100 >pow3 = sum(pow_s3)./100 > >ampl1 = sqrt(pow1) >ampl2 = sqrt(pow2) >ampl3 = sqrt(pow3) > >I hope that this clarifies it. Of course, it does not yet help you >deciding how to test for the interaction, since the additive effect >(which you expect under the null hypothesis) can be either on >amplitude or on power. To choose the right test, you will have to >consider the sources of the two signals that are being mixed on the >channel level, i.e. are they coming from one source, or from two >sources, and in the latter case, are the two sources strongly >coherent or not? > >best regards, >Robert > > >======================================================= >Robert Oostenveld, PhD >F.C. Donders Centre for Cognitive Neuroimaging >Radboud University Nijmegen >phone: +31-24-3619695 >http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Tue Aug 16 09:29:07 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 16 Aug 2005 09:29:07 +0200 Subject: calculating frequency interaction (now with the complete message) In-Reply-To: Message-ID: Hi Thomas, On 15-aug-2005, at 23:41, Thomas Thesen wrote: > Rob, your comments regarding the appropriate approach for testing the > interaction are very insightful. Thank you. Considering that MEG/ > EEG data > contain a lot from both of these options it seems unwise to do this > type of > testing. One couldn't tell wether a different phase relationship or > a true > effect might be responsible for non-linear summation. Or am I wrong > there? You always assume the null-hypothesis to be true, which means no effects and no coherences. Then you test the probability of observing your data under this hypothesis. If that is unlikely, you conclude that the null-hypothesis does not apply. Therefore, knowing that there are all sorts of complex dynamics in the brain does not harm the correctness of your inference based on the statistical test, since the test is based on the absence of the effect. Of course you should be carefull and explicit in phrasing your null-hypothesis, my phrasing here is too vague to operationalize it. > I just saw at a conference a poster where they tried the same thing > using > bootstrapping. The web link above contains a copy of that poster > "Senkowski...jpg". What do you think about this approach? Could > that be done > using FieldTrip? The approach could in theory be done in Fieldtrip without too much additional programming effort. It slightly resembles the statistical test based on randomization theory that is implemented in clusterrandanalysis (also see http://www2.ru.nl/fcdonders/fieldtrip/ uploads/media/RandBioTheory.pdf). However, the test suggested by Senkowski on the poster that you sent is not very clear in the hypothesis that is being tested. They focus on the sensitivity of the test, but not on the validity of rejecting the null hypothesis. I would rephrase their approach: they assume that the AV trials originate from the same (unknown) distribution as the manually crafted A+V trials. They have created NA times NV of these N+V trials (i.e. each possible combination) and randomly draw subsets from this A +V distribution with the same number of trials as they have in their AV average. The error that they make is that they do not consider the noise that is present in the measurement. In the absence of any signal of interest in the EEG, you still would have (electrode) noise. That noise is present in the AV condition, in the A condition and in the V condition. If you add an A trial with a V trial, the noise will add. Since noise here is assumed to be uncorrelated over trials, the noise in A+V will be sqrt(2) times the noise in either A or V allone. But the noise in AV is similar as that in either A or V (since they are all raw trials from the recorded data), hence the noise in their A+V trial is sqrt(2) times the noise in the AV trial. Therefore I conclude that there is a trivial difference between the data, irrespective of the true underlying difference, which results in a systematic overestimation of the A+V power with respect to the AV power. In their case, the more noise their signals contain, the more likely it is that they will reject the hypothesis that the A+V and the AV trials originate from the same distribution. Their incorrect alternative hypothesis is subadditivity, i.e. the AV condition has less power than the A+V condition. best regards, Robert From morier8 at ETU.UNIGE.CH Wed Aug 17 12:43:14 2005 From: morier8 at ETU.UNIGE.CH (patrice) Date: Wed, 17 Aug 2005 12:43:14 +0200 Subject: immediate 3D plot Message-ID: Hi all, I would like to make a graphical plot of my data with fieldtrip. No frequency analysis, no averaging, no filtering or whatever, only a simple plot to display the active regions in the brain. My data (EEG) are stored in a 2D matrix (voxels x time-points). My voxels are distributed in the whole brain (not only on the scalp). Furthermore, I have a file that contains the 3D coordinates of my voxels (X,Y and Z) and an header file associated to the used model. Is it feasible with fieldtrip? If yes, do you have any idea to achieve this? Any suggestion would be helpful. Regards, patrice From r.oostenveld at FCDONDERS.RU.NL Fri Aug 19 15:41:38 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 19 Aug 2005 15:41:38 +0200 Subject: immediate 3D plot In-Reply-To: Message-ID: Hi Patrice On 17-aug-2005, at 12:43, patrice wrote: > I would like to make a graphical plot of my data with fieldtrip. No > frequency analysis, no averaging, no filtering or whatever, only a > simple > plot to display the active regions in the brain. I guess that means that you want to plot the potential that you have recorded at each electrode site? > My data (EEG) are stored in a 2D matrix (voxels x time-points). My > voxels > are distributed in the whole brain (not only on the scalp). Does that mean that you have depth electrodes? Or did you do a source reconstrucion of your EEG in some external software? > Furthermore, I have a file that contains the 3D coordinates of my > voxels (X,Y and Z) > and an header file associated to the used model. Is it feasible > with fieldtrip? If > yes, do you have any idea to achieve this? Is it a regular arrangement, i.e. do the voxels form a box-like volume? If so, then you can "massage" the data into fieldtrip as a sourcereconstruction and use the sourceinterpolate function. However, since you have recorded it at many samples (timepoints), that means that a graphical representation of that data would consist of a 3D volume with an additional time dimension, i.e. the data is 4D. Hence, it would be a movie in which you can show a single cross- section (slice) through the brain at a time. Such a movie can be made in Matlab, but fieldtrip would not be of many use for you. Robert From sanja at UNM.EDU Fri Aug 19 19:42:21 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 19 Aug 2005 11:42:21 -0600 Subject: source projection In-Reply-To: <8182F211-66DD-4AFC-8E9D-472F041233EF@fcdonders.ru.nl> Message-ID: Hi Robert, I've tried using megrealign and megplanar with the CTF 275 ch data, however I run into problems with source projection. First, for megrealign there was a warning about the higher order synthetic gradiometer configuration. Nevertheless, megrealign ran, but after freqanalysis the resulting tfr values for several channels were much higher (3 orders of magnitude) than for the rest of the channels (which was not the case for the original not realigned data). Second, megplanar stopped running with "the forward model does not look like EEG, nor like MEG" error. I've saved the CTF data with the 3rd order noise cancellation on (via newDs -filter) and then read these noise canceled data into fieldtrip. However, I've only read in MEG and STIM channels, I haven't read in the reference channels. Do you have any thoughts on what might be going on? I appreciate your help, Sanja On Fri, 12 Aug 2005 14:02:20 +0200 Robert Oostenveld wrote: > Hi Sanja, > > On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: >> I am trying to use >>meginterpolate/freqanalysis/combineplanar to get >> the tfr >> data in the planar gradiometer system, instead of the >>original 275 >> ch axial. >> However, combineplanar needs planarchannelset, but this >>function is >> not >> included in the 20050811 distribution. Could you include >>this >> function in >> the next distribution? > > Please find the function attached to this mail. I will >add it to the next daily releases, sorry that it was >missing. > > The attached version however does not include the 275ch >CTF system yet, but it is easy to add. You basically >only have to make a table with the planar channel labels >that should be combined, and the name of the combined >channel (i.e. the original name). I would appreciate it >if you would send me the table information for the CTF >275 system, I will then update the release version as >well. > >> I have a set of questions related to meginterpolate: Can >>CTF274.lay >> be used >> for ploting the planar data? Should I use a default >>single sphere >> model for >> each subject or a single sphere model particular for a >>subject for >> realignment? Should "nominal" sensor locations be used >>as a >> template for >> each subject, or do you recommend taking an average >>across subjects >> for the >> template? > > Yes, but only for combineplanar'ed data in combination >with topoplotTFR. It is conceptually not possible to >make a topography of the "raw" planar data itself, but >you can do a multiplotER and multiplotTFR of the planar >data. However, that would require another lay file. The >NM122all.lay file is one for the Neuromag system that > plots the 122 planar channels at 66 locations, with >horizontal and vertical channel next to each other. > > If you do not specify a layout in the cfg of >multiplotTFR, the private subfunction createlayout will >construct a layout on the fly based on the gradiometer >positions. Usually the plotting is more controlled with >a manually eddited layout file, but the automatic one > can serve as starting point. Looking into the code, I >now realise that there still are some loose ends. The >megplanar function does not return the planar gadiometer >definition. Please have a look at the private functions >axial2planar and createlayout, and use them together to >construct a planar layout file. > > best regards, > Robert From sanja at UNM.EDU Fri Aug 19 23:43:42 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 19 Aug 2005 15:43:42 -0600 Subject: source projection In-Reply-To: Message-ID: Oh, I forgot to mention that I used meplanar with the source projection option. I tracked the problem down to axial2planar (line 309 of megplanar: planar.grad = axial2planar([], axial.grad)). Axial2planar does not return the field "type" in planar.grad, and therefore compute_leadfield could not recognize the sensor type and gives "the forward model does not look like EEG, nor like MEG" error. -Sanja On Fri, 19 Aug 2005 11:42:21 -0600 Sanja Kovacevic wrote: > Hi Robert, > > I've tried using megrealign and megplanar with the CTF >275 ch data, however I run into problems with source >projection. First, for megrealign there was a warning >about the higher order synthetic gradiometer >configuration. Nevertheless, megrealign ran, but after >freqanalysis the resulting tfr values for several >channels were much higher (3 orders of magnitude) than >for the rest of the channels (which was not the case for >the original not realigned data). Second, megplanar >stopped running with "the forward model does not look >like EEG, nor like MEG" error. I've saved the CTF data >with the 3rd order noise cancellation on (via newDs >-filter) and then read these noise canceled data into >fieldtrip. However, I've only read in MEG and STIM >channels, I haven't read in the reference channels. Do >you have any thoughts on what might be going on? > > I appreciate your help, > > Sanja > > > On Fri, 12 Aug 2005 14:02:20 +0200 > Robert Oostenveld wrote: >> Hi Sanja, >> >> On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: >>> I am trying to use >>>meginterpolate/freqanalysis/combineplanar to get >>> the tfr >>> data in the planar gradiometer system, instead of the >>>original 275 >>> ch axial. >>> However, combineplanar needs planarchannelset, but this >>>function is >>> not >>> included in the 20050811 distribution. Could you include >>>this >>> function in >>> the next distribution? >> >> Please find the function attached to this mail. I will >>add it to the next daily releases, sorry that it was >>missing. >> >> The attached version however does not include the 275ch >>CTF system yet, but it is easy to add. You basically >>only have to make a table with the planar channel labels >>that should be combined, and the name of the combined >>channel (i.e. the original name). I would appreciate it >>if you would send me the table information for the CTF >>275 system, I will then update the release version as >>well. >> >>> I have a set of questions related to meginterpolate: Can >>>CTF274.lay >>> be used >>> for ploting the planar data? Should I use a default >>>single sphere >>> model for >>> each subject or a single sphere model particular for a >>>subject for >>> realignment? Should "nominal" sensor locations be used >>>as a >>> template for >>> each subject, or do you recommend taking an average >>>across subjects >>> for the >>> template? >> >> Yes, but only for combineplanar'ed data in combination >>with topoplotTFR. It is conceptually not possible to >>make a topography of the "raw" planar data itself, but >>you can do a multiplotER and multiplotTFR of the planar >>data. However, that would require another lay file. The >>NM122all.lay file is one for the Neuromag system that >>plots the 122 planar channels at 66 locations, with >>horizontal and vertical channel next to each other. >> >> If you do not specify a layout in the cfg of >>multiplotTFR, the private subfunction createlayout will >>construct a layout on the fly based on the gradiometer >>positions. Usually the plotting is more controlled with >>a manually eddited layout file, but the automatic one can >>serve as starting point. Looking into the code, I >>now realise that there still are some loose ends. The >>megplanar function does not return the planar gadiometer >>definition. Please have a look at the private functions >>axial2planar and createlayout, and use them together to >>construct a planar layout file. >> >> best regards, >> Robert Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From r.oostenveld at FCDONDERS.RU.NL Sat Aug 20 10:08:19 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Sat, 20 Aug 2005 10:08:19 +0200 Subject: source projection In-Reply-To: Message-ID: Hi Sanja, First some general comments. In my experience megrealign works more accurate with the sincos option (i.e. nearest neighbour interpolation) than with the sourceproject option. I have validated this function using simulated data, in which I computed the field of a dipole on axial gradiometers, and the field of the same data on (true) planar gradiometers. Then I converted the axial to the planar data with megplanar and the different options there and compared the two. I repeated this with different noise levels and the sincos was consistenly more acurate than the others. However (relevant for other people as well) the 'orig' method is still the default. That was implemented initially by Ole Jensen, the other ones were implemented by me. The low-level forward computation of the fields in Fieldtrip cannot make use of the synthetic higfher order gradients. In theory that could be supported, but the weights of the reference sensors are not read in from teh res4 file. That means, whenever you do a computation that involves a forward computed field (sourceanalysis, dipolefitting, megrealign and megplanar+sourceproject), the forward field is a plain 1st order MEG gradient. If your CTFdata is 3rd order, and you have saved it with newDs, there will be a slight discrepancy between the measured data and the forward model, even if your measured data contains a single perfect dipole. The field of the sources in the brain will also be slightly supporessed, which is not represented in the forward model. However, the advantage of the 3rd order gradient is that also environmental noise is suppressed. So there is a trade off, if you have a lot of noise, it is better to use the 3rd order gradient, if you have very clean data, it is better not to use it. I would like to implement the 3rd order gradients, and have most code for it in place, but there are some details that need to be sorted out. If you are going to use it and think that you can contribute, I would appreciate your help on that. Now onto your question: On 19-aug-2005, at 23:43, Sanja Kovacevic wrote: > Oh, I forgot to mention that I used meplanar with the source > projection option. I tracked the problem down to axial2planar (line > 309 of megplanar: planar.grad = axial2planar([], axial.grad)). > Axial2planar does not return the field "type" in planar.grad, and > therefore compute_leadfield could not recognize the sensor type and > gives "the forward model does not look like EEG, nor like MEG" error. > > One potential problem here might be that axial2planar is also trying to compute the planar representation of the reference sensors. I don't think that that applies in your case, but it should not do that. So that is something to check. The latest version of compute_leadfield (revision 1.7) should also detect the correct type in the absence of the "type" field. It has the following added with repect to the older versions elseif isfield(sens, 'pnt') & isfield(sens, 'ori') iseeg = 0; ismeg = 1; If yours does not contain that, please upgrade your fieldtrip version. best regards, Robert From sanja at UNM.EDU Wed Aug 24 00:50:18 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Tue, 23 Aug 2005 16:50:18 -0600 Subject: source projection In-Reply-To: <9F60D4E0-E095-4BF8-B3AB-91241311EB95@fcdonders.ru.nl> Message-ID: Hi Robert, Have you also tried different neighbor distances when you tested megplanar? I believe that for the 151 channel system, the default 4 cm distance would lead to a smaller average number of neighbors than for the 275 channel system. For 275 channel data, using 3 cm neighbor distance I've got 5.5 neighbors on average, while using 4 cm neighbor distance, I've got 9.1 neighbors on average. I noticed that when I used 4 cm neighbor distance, changes in power were more spread out. Do you have any suggestions on how many neighbors would be optimal? Thank you, Sanja From r.oostenveld at FCDONDERS.RU.NL Thu Aug 25 09:00:55 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Thu, 25 Aug 2005 09:00:55 +0200 Subject: source projection In-Reply-To: Message-ID: Hi Sanja, That is something that I never considered, actually. In our 151 channel case, we have with the default 4 cm about one circle of sensors around the sensor of interest. In your 275 channel case that is of course more. Intuitively, I would say that you want to have a smallest circle of sensors that is possible, to accieve the highest spatial resolution. Increasing the spatial resolution is, besides making the spatial topography more easy to understand, a main goal of planar gradients. But constructing the synthetic planar gradients using the nearest neighbour approach also makes the signals more noise, since, at the sensor of interest, you are mixing in the (independent) noise of the neighbouring sensors. In our 151ch case, that is something that we just have to accept, but in your 275ch case, you can trade in some of the spatial resolution (lower, if more channels as neighbours) against the noise (beter, by averaging the noise over them). best regards, Robert On 24-aug-2005, at 0:50, Sanja Kovacevic wrote: > Hi Robert, > > Have you also tried different neighbor distances when you tested > megplanar? I believe that for the 151 channel system, the default 4 > cm distance would lead to a smaller average number of neighbors > than for the 275 channel system. For 275 channel data, using 3 cm > neighbor distance I've got 5.5 neighbors on average, while using 4 > cm neighbor distance, I've got 9.1 neighbors on average. I noticed > that when I used 4 cm neighbor distance, changes in power were more > spread out. Do you have any suggestions on how many neighbors would > be optimal? > > > Thank you, > Sanja > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From Jan.Schoffelen at FCDONDERS.RU.NL Tue Aug 30 13:18:14 2005 From: Jan.Schoffelen at FCDONDERS.RU.NL (J.M. Schoffelen) Date: Tue, 30 Aug 2005 13:18:14 +0200 Subject: bug-report topoplotER Message-ID: Dear all, I would like to point you to the fact that there is a "bug" in one of fieldtrip's plotting functions: topoplotER.m You can specify for the data to be plotted, the time-interval, or the frequency-interval you would like to have displayed. The function is capable of plotting just one time-bin, or frequency-bin, if you specify cfg.xlim = [x x], x being the latency or frequency you're interested in. HOWEVER, so far this only worked correctly if the wished for latency/frequency was exactly present in the data. The function gives you a completely wrong output, if that is not the case (the same thing goes if your latency-window or frequency-window is in between consecutive data-points in your data). In future releases of this function, an explicit error will be given, instead of silent and misleading nonsense. Sorry for the potential inconvenience, Jan-M -------------- next part -------------- An HTML attachment was scrubbed... URL: From wibral at MPIH-FRANKFURT.MPG.DE Mon Aug 1 11:45:11 2005 From: wibral at MPIH-FRANKFURT.MPG.DE (Michael Wibral) Date: Mon, 1 Aug 2005 11:45:11 +0200 Subject: Matlab 7 crashes with Fieldtrip graphics In-Reply-To: Message-ID: Hi, I had a similar problem with graphs of the same type (also not from within Fieldtrip) and it helped to change the OpenGL preferences of Matlab 7 by issuing the command: opengl('software') either on the command line before you run anything else or somewhere in your script before you actually do graphics. Matlab seems to have (a lot) of incomaptibilty problems with hardware implementations of Open GL. I hope that solves your problem, Michael Litvak Vladimir schrieb: > Dear Fieldtrip developers, > > I started using Matlab 7 and it crashes when using topoplotTFR almost > every time (especially if it was already running for a while prior to > that). I know it's not your bug but have you encountered this (on Win > XP)? This really gets on my nerves. If anyone else has this problem > maybe it's a good idea to ask Mathworks about it. > > Thanks, > > Vladimir > > . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maris at NICI.RU.NL Fri Aug 5 14:33:52 2005 From: maris at NICI.RU.NL (Eric Maris) Date: Fri, 5 Aug 2005 14:33:52 +0200 Subject: nonparametric statistics Message-ID: Dear all, Several people have asked me for a reference paper explaining the theory behing the nonparametric statistical tests that are performed in several Fieldtrip functions. Recently, together with Robert Oostenveld, I have submitted such a paper. You can find this paper in the Publications folder on the Fieldtrip website. greetings, dr. Eric Maris NICI/Biological Psychology and F.C. Donders Center for Cognitive NeuroImaging University of Nijmegen P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 (NICI) T:+31 24 3610754 (FCDC) F:+31 24 3616066 (NICI) E: maris at nici.ru.nl The University of Nijmegen will be named Radboud University Nijmegen as of September 1st, 2004 From h.f.kwok at BHAM.AC.UK Tue Aug 9 15:05:08 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 15:05:08 +0200 Subject: problems using fieldtrip Message-ID: This is the first time that I am using FieldTrip. Just like to ask what other software are needed besides MATLAB in order to run the tutorials. I have tried to run the tutorials after downloading and unzipping the Subject01.zip but I ran into problems. Firstly, in the Event Related Averaging tutorial, the EventRelatedAveraging.m was mentioned but I could not find the file. Secondly, after I created a cfg structure with 'Subject01.ds' as the dataset and all the other field properties as instructed in the tutorial, I got the following error message when using the preprocessing.m: CTF_READ_RES4 [v 1.12] ??? Error using ==> read_fcdc_header could not read CTF res4 header file Error in ==> preprocessing at 219 hdr = read_fcdc_header(cfg.headerfile); Can anyone help please? Regards, Hoi Fei From r.oostenveld at FCDONDERS.RU.NL Tue Aug 9 15:38:55 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 9 Aug 2005 15:38:55 +0200 Subject: problems using fieldtrip In-Reply-To: Message-ID: Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 15:48:44 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 14:48:44 +0100 Subject: problems using fieldtrip In-Reply-To: <78FC6891-F9A5-443C-8EC6-DA4AE1194C32@fcdonders.ru.nl> Message-ID: Thanks, Robert, The 'Subject01.ds' was in the search path. The error occurred whether I was in the same directory as the 'Subject01.ds' or not. When I typed the command while in the same directory as the 'Subject01.ds', I got this: CTF_READ_RES4 [v 1.12] ...done ( 0.79 sec) ??? Error using ==> read_fcdc_header could not read CTF res4 header file Error in ==> preprocessing at 219 hdr = read_fcdc_header(cfg.headerfile); Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 16:14:22 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 15:14:22 +0100 Subject: problems using fieldtrip In-Reply-To: <78FC6891-F9A5-443C-8EC6-DA4AE1194C32@fcdonders.ru.nl> Message-ID: Dear Robert, I have just tried to put breakpoints in some of the m-files to see what the problems are. I have found some potential causes of the problem. Starting from line 133 of the 'read_fcdc_header.m': if ctferror && haseegsf % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From Jan.Schoffelen at FCDONDERS.RU.NL Tue Aug 9 17:14:32 2005 From: Jan.Schoffelen at FCDONDERS.RU.NL (J.M. Schoffelen) Date: Tue, 9 Aug 2005 17:14:32 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59cec$a3af3270$e516bc93@universi8ef8be> Message-ID: Dear Hoi Fei, I think I have a clue of what is going on: if ctferror && haseegsf This is the thing that should not occur, so for some reason or another both haseegsf and ctferror are true: This means that somewhere in your path you have the files ctf_read_meg4, and ctf_read_res4, which usually is no problem, but in this case is half of your problem, because it makes the if-statement already half true. Next to this ctferror apparently is true, which should not be the case. It goes wrong in line 130, where ctferror is put to one after the catch, so the try did not work out too well. I would say that this could be caused by the fact that you lack the function read_ctf_res4 altogether, which should be located in the private-subdirectory of fieldtrip. This does not seem too likely to me, so I would guess that somehow the headerfile in line 126 is incorrecly formatted. To get an idea if this is the case, try to put a breakpoint in line 127 or so. Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? This might also be the problem. Hope this helps a bit, Yours, Jan-Mathijs % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 17:25:48 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 16:25:48 +0100 Subject: problems using fieldtrip In-Reply-To: <0IKY00HZWNO8K0@mailserver.uci.kun.nl> Message-ID: Hi, Jan-Mathijs, I have checked and the ctf_read_res4 file is in the private subdirectory and I was at the same folder as the Subject01.ds. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of J.M. Schoffelen Sent: 09 August 2005 16:15 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei, I think I have a clue of what is going on: if ctferror && haseegsf This is the thing that should not occur, so for some reason or another both haseegsf and ctferror are true: This means that somewhere in your path you have the files ctf_read_meg4, and ctf_read_res4, which usually is no problem, but in this case is half of your problem, because it makes the if-statement already half true. Next to this ctferror apparently is true, which should not be the case. It goes wrong in line 130, where ctferror is put to one after the catch, so the try did not work out too well. I would say that this could be caused by the fact that you lack the function read_ctf_res4 altogether, which should be located in the private-subdirectory of fieldtrip. This does not seem too likely to me, so I would guess that somehow the headerfile in line 126 is incorrecly formatted. To get an idea if this is the case, try to put a breakpoint in line 127 or so. Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? This might also be the problem. Hope this helps a bit, Yours, Jan-Mathijs % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From r.oostenveld at FCDONDERS.RU.NL Tue Aug 9 20:57:05 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 9 Aug 2005 20:57:05 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59cf6$9e7d0b10$e516bc93@universi8ef8be> Message-ID: Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From h.f.kwok at BHAM.AC.UK Wed Aug 10 09:55:35 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 08:55:35 +0100 Subject: problems using fieldtrip In-Reply-To: Message-ID: Hi, When I typed "which ctf_read_res4" in Matlab, it returned: C:\Program Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01\ctf_read_res4.m Is it because of the EEGLab plugins that I installed previously then? Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 19:57 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From h.f.kwok at BHAM.AC.UK Wed Aug 10 09:57:45 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 08:57:45 +0100 Subject: problems using fieldtrip In-Reply-To: Message-ID: Hi, I've removed the EEGlab from the path and now the FieldTrip is working all right. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 19:57 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Wed Aug 10 09:58:27 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Wed, 10 Aug 2005 09:58:27 +0200 Subject: problems using fieldtrip In-Reply-To: <000401c59d80$e43ec1e0$e516bc93@universi8ef8be> Message-ID: Hi Hoi Fei On 10-aug-2005, at 9:55, Hoi Fei Kwok wrote: > When I typed "which ctf_read_res4" in Matlab, it returned: > C:\Program > Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01 > \ctf_read_res4.m > > Is it because of the EEGLab plugins that I installed previously then? > Yes, that might well be the problem. Please remove the EEGLAB directory from your matlab search path and try the tutorial again. Robert From h.f.kwok at BHAM.AC.UK Wed Aug 10 10:37:51 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 09:37:51 +0100 Subject: problems using fieldtrip In-Reply-To: <596064D3-DD4C-4F24-A018-C7F65FC3B67D@fcdonders.ru.nl> Message-ID: Hi, On one hand, removing the EEGLAB solved the problem. On the other hand, the FieldTrip website mentioned about integrating the FieldTrip with the EEGLAB. So how should one go about that? Maybe the problem I encountered indicates that one should avoid certain EEGLAB plugins if one wants to use both the EEGLAB and FieldTrip. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 10 August 2005 08:58 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei On 10-aug-2005, at 9:55, Hoi Fei Kwok wrote: > When I typed "which ctf_read_res4" in Matlab, it returned: > C:\Program > Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01 > \ctf_read_res4.m > > Is it because of the EEGLab plugins that I installed previously then? > Yes, that might well be the problem. Please remove the EEGLAB directory from your matlab search path and try the tutorial again. Robert From r.oostenveld at FCDONDERS.RU.NL Wed Aug 10 12:03:50 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Wed, 10 Aug 2005 12:03:50 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59d86$cb7702c0$e516bc93@universi8ef8be> Message-ID: Hi, EEGLAB is (or will be in the near future) using the source localization features of Fieldtrip, i.e. it is one-way traffic. I expect that the reading of the data and processing of the data up to the point of the scalp maps will be done completely in EEGLAB, hence the problem that you now encountered (i.e. conflicting low-level data importers) will not pose an immediate problem for people who use it as intended. However, I also hope that once the integration gets into shape that also more low-level code will be shared between the two and then we might run into these problems more often. So it is good for us to hear about issues like these. Robert On 10-aug-2005, at 10:37, Hoi Fei Kwok wrote: > Hi, > > On one hand, removing the EEGLAB solved the problem. On the other > hand, the > FieldTrip website mentioned about integrating the FieldTrip with > the EEGLAB. > So how should one go about that? Maybe the problem I encountered > indicates > that one should avoid certain EEGLAB plugins if one wants to use > both the > EEGLAB and FieldTrip. > > Regards, > Hoi Fei > From sanja at UNM.EDU Thu Aug 11 22:52:12 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Thu, 11 Aug 2005 22:52:12 +0200 Subject: combineplanar Message-ID: Hello, I am trying to use meginterpolate/freqanalysis/combineplanar to get the tfr data in the planar gradiometer system, instead of the original 275 ch axial. However, combineplanar needs planarchannelset, but this function is not included in the 20050811 distribution. Could you include this function in the next distribution? I have a set of questions related to meginterpolate: Can CTF274.lay be used for ploting the planar data? Should I use a default single sphere model for each subject or a single sphere model particular for a subject for realignment? Should "nominal" sensor locations be used as a template for each subject, or do you recommend taking an average across subjects for the template? I appreciate your help, Sanja Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From holroydt at MAIL.NIH.GOV Thu Aug 11 23:26:41 2005 From: holroydt at MAIL.NIH.GOV (Tom Holroyd) Date: Thu, 11 Aug 2005 17:26:41 -0400 Subject: combineplanar In-Reply-To: Message-ID: Sanja Kovacevic wrote: > I have a set of questions related to meginterpolate: Can CTF274.lay be used > for ploting the planar data? I don't know the answer to your question, but I would like to note that CTF274.lay is based on the NIMH system which has one dead SQUID, namely MRF43. You might want to generate a CTF275.lay with that channel replaced. The meginterpolate code can actually "fix" dead channels anyway... > Should I use a default single sphere model for > each subject or a single sphere model particular for a subject for > realignment? Should "nominal" sensor locations be used as a template for > each subject, or do you recommend taking an average across subjects for the > template? Oh, as long as I'm here: Personally I wouldn't bother averaging across subjects, because even "aligned", averaging subjects together in sensor space is nearly meaningless. (Though an interesting project, by analogy to Talairach or MNI space, is to "warp" the sensor space data into a common space, based on "anatomical" landmarks such as the peaks of the AEF and/or SEF. I still wouldn't do that, though.) -- Dr. Tom Holroyd "A man of genius makes no mistakes. His errors are volitional and are the portals of discovery." -- James Joyce From ole.jensen at FCDONDERS.RU.NL Fri Aug 12 12:13:44 2005 From: ole.jensen at FCDONDERS.RU.NL (Ole Jensen) Date: Fri, 12 Aug 2005 12:13:44 +0200 Subject: averaging in sensor space In-Reply-To: <42FBC291.2070105@mail.nih.gov> Message-ID: Regarding the discussion on planar gradients and averaging over subjects: As Tom suggests it is always best to average over subjects in source space. However, sometimes we do not have high enough signal-to-noise in order to reliably identify the sources while we still observe consistent effects at the sensor level. I think it is an important discussion since it pertains to how we approach MEG data in general. Therefore I would like to provide an argument for why I believe it is sensible to average over subjects in sensor space: Say that a dataset has been analyzed in the frequency domain and we have representations of power for each sensor. I find it convenient to apply the combined planar gradient for power representations since this will tend to give the strongest power in sensors above the source. An axial gradient representation will result in two regions of strong power at each side of the source (i.e. where the fields exit and enter). We have had quite good luck averaging combined planar gradient power representations over subjects at the sensors level both with and without realignment. The FieldTrip has statistical methods implemented for dealing with the multiple comparison problem (multiple sensors). Also, for instance the group in Tuebingen has several publications were power (albeit using axial gradients) where they average over subjects at the sensor level. The approach is quite similar to that applied by the ERD/ERS community on EEG data. Note that differences in head size, position etc might diminish a given effect - however, I do not believe that averaging over subjects in sensor space will result in false positives. With respect to event related fields one should be very careful averaging the axial gradient over subjects at the sensor level. The orientation of sources from subject to subject might be different thus partially canceling a given effect. One solution is to calculate the RMS of the two orientations of the planar gradient and then average over subjects. This has for instance been done convincingly by the BRU/LTL Helsinki group in N400m studies. We have also good experiences with that approach at the Donders. The main disadvantage of averaging combined planar gradients of ERFs is that we loose information about source orientation. I would advice against doing source modeling on MEG data which has been averaged over subjects (this is often done for EEG data). Here it is appropriate to average either a current estimate of "beamformed" power estimate in source space after realigning the source representations to a standard brain. We are often using the following approach 1) Calculate time-frequency representations (TFRs) of power for planar gradients 2) Combined the planar gradient for each orientation 3) Average over subjects in sensors space 4) Use randomization statistics to identify clusters of difference 5) Use the beamformer to estimate power in source space for time and freq tiles identified in 4) in individual subjects 6) Morph the results of beamformed power to a standard brain 7) Average morphed power representations in source space Bests, Ole > Oh, as long as I'm here: > > Personally I wouldn't bother averaging across subjects, because even > "aligned", averaging subjects together in sensor space is nearly > meaningless. (Though an interesting project, by analogy to Talairach > or MNI space, is to "warp" the sensor space data into a common space, > based on "anatomical" landmarks such as the peaks of the AEF and/or > SEF. I still wouldn't do that, though.) > -- Ole Jensen Principal Investigator F.C. Donders Centre for Cognitive Neuroimaging P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Office : +31 24 36 10884 MEG lab : +31 24 36 10988 Fax : +31 24 36 10989 e-mail : ole.jensen at fcdonders.ru.nl URL : http://oase.uci.ru.nl/~olejen From r.oostenveld at FCDONDERS.RU.NL Fri Aug 12 14:02:20 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 12 Aug 2005 14:02:20 +0200 Subject: combineplanar In-Reply-To: Message-ID: Hi Sanja, On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: > I am trying to use meginterpolate/freqanalysis/combineplanar to get > the tfr > data in the planar gradiometer system, instead of the original 275 > ch axial. > However, combineplanar needs planarchannelset, but this function is > not > included in the 20050811 distribution. Could you include this > function in > the next distribution? Please find the function attached to this mail. I will add it to the next daily releases, sorry that it was missing. The attached version however does not include the 275ch CTF system yet, but it is easy to add. You basically only have to make a table with the planar channel labels that should be combined, and the name of the combined channel (i.e. the original name). I would appreciate it if you would send me the table information for the CTF 275 system, I will then update the release version as well. > I have a set of questions related to meginterpolate: Can CTF274.lay > be used > for ploting the planar data? Should I use a default single sphere > model for > each subject or a single sphere model particular for a subject for > realignment? Should "nominal" sensor locations be used as a > template for > each subject, or do you recommend taking an average across subjects > for the > template? Yes, but only for combineplanar'ed data in combination with topoplotTFR. It is conceptually not possible to make a topography of the "raw" planar data itself, but you can do a multiplotER and multiplotTFR of the planar data. However, that would require another lay file. The NM122all.lay file is one for the Neuromag system that plots the 122 planar channels at 66 locations, with horizontal and vertical channel next to each other. If you do not specify a layout in the cfg of multiplotTFR, the private subfunction createlayout will construct a layout on the fly based on the gradiometer positions. Usually the plotting is more controlled with a manually eddited layout file, but the automatic one can serve as starting point. Looking into the code, I now realise that there still are some loose ends. The megplanar function does not return the planar gadiometer definition. Please have a look at the private functions axial2planar and createlayout, and use them together to construct a planar layout file. best regards, Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: planarchannelset.m Type: application/octet-stream Size: 16045 bytes Desc: not available URL: From r.oostenveld at FCDONDERS.RU.NL Fri Aug 12 14:10:14 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 12 Aug 2005 14:10:14 +0200 Subject: averaging in sensor space In-Reply-To: <42FC7658.7060606@fcdonders.ru.nl> Message-ID: Hi guys, Just some additions to Ole's nice arguments... On 12-aug-2005, at 12:13, Ole Jensen wrote: > We are often using the following approach > 1) Calculate time-frequency representations (TFRs) of power for > planar gradients > 2) Combined the planar gradient for each orientation > 3) Average over subjects in sensors space > 4) Use randomization statistics to identify clusters of difference Prior to step 1, we would MEGREALIGN the raw data as obtained from preprocessing to a template helmet location (typically the average over all subjects in the study). That realigmnent reduces some variance in the averaging in step 3. After determining the time-frequency tile of interest (step 4), we go back to the original data as obtained from PREPROCESSING (i.e. prior to MEGREALIGN) and repeat FERQANALYSIS with settings (timewindow +frequency+multitapers) that are tuned to optimize the frequency estimate in that TF tile. And then we continue with > 5) Use the beamformer to estimate power in source space for time > and freq tiles identified in 4) in individual subjects > 6) Morph the results of beamformed power to a standard brain > 7) Average morphed power representations in source space best, Robert From sanja at UNM.EDU Fri Aug 12 17:01:09 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 12 Aug 2005 09:01:09 -0600 Subject: averaging in sensor space In-Reply-To: <42FC7658.7060606@fcdonders.ru.nl> Message-ID: On Fri, 12 Aug 2005 12:13:44 +0200 Ole Jensen wrote: > Regarding the discussion on planar gradients and >averaging over subjects: > > As Tom suggests it is always best to average over >subjects in source space. However, sometimes we do not >have high enough signal-to-noise in order to reliably >identify the sources while we still observe consistent >effects at the sensor level. I think it is an important >discussion since it pertains to how we approach MEG data >in general. Therefore I would like to provide an argument >for why I believe it is sensible to average over subjects >in sensor space: > > Say that a dataset has been analyzed in the frequency >domain and we have representations of power for each >sensor. I find it convenient to apply the combined planar >gradient for power representations since this will tend >to give the strongest power in sensors above the source. >An axial gradient representation will result in two >regions of strong power at each side of the source (i.e. >where the fields exit and enter). We have had quite good >luck averaging combined planar gradient power >representations over subjects at the sensors level both >with and without realignment. The FieldTrip has >statistical methods implemented for dealing with the >multiple comparison problem (multiple sensors). Also, for >instance the group in Tuebingen has several publications >were power (albeit using axial gradients) where they >average over subjects at the sensor level. The approach >is quite similar to that applied by the ERD/ERS community >on EEG data. Note that differences in head size, position >etc might diminish a given effect - however, I do not >believe that averaging over subjects in sensor space will >result in false positives. > > With respect to event related fields one should be very >careful averaging the axial gradient over subjects at the >sensor level. The orientation of sources from subject to >subject might be different thus partially canceling a >given effect. One solution is to calculate the RMS of the >two orientations of the planar gradient and then average >over subjects. This has for instance been done >convincingly by the BRU/LTL Helsinki group in N400m >studies. We have also good experiences with that approach >at the Donders. The main disadvantage of averaging >combined planar gradients of ERFs is that we loose >information about source orientation. > > I would advice against doing source modeling on MEG data >which has been averaged over subjects (this is often done >for EEG data). Here it is appropriate to average either a >current estimate of "beamformed" power estimate in source >space after realigning the source representations to a >standard brain. > > We are often using the following approach > > 1) Calculate time-frequency representations (TFRs) of >power for planar gradients > 2) Combined the planar gradient for each orientation > 3) Average over subjects in sensors space > 4) Use randomization statistics to identify clusters of >difference > 5) Use the beamformer to estimate power in source space >for time and freq tiles identified in 4) in individual >subjects > 6) Morph the results of beamformed power to a standard >brain > 7) Average morphed power representations in source space > > > Bests, > > Ole > > > > > > >> Oh, as long as I'm here: >> >> Personally I wouldn't bother averaging across subjects, >>because even >> "aligned", averaging subjects together in sensor space >>is nearly >> meaningless. (Though an interesting project, by analogy >>to Talairach >> or MNI space, is to "warp" the sensor space data into a >>common space, >> based on "anatomical" landmarks such as the peaks of the >>AEF and/or >> SEF. I still wouldn't do that, though.) >> > > > -- > Ole Jensen > Principal Investigator >F.C. Donders Centre for Cognitive Neuroimaging > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Office : +31 24 36 10884 > MEG lab : +31 24 36 10988 > >Fax : +31 24 36 10989 > > e-mail : ole.jensen at fcdonders.ru.nl > URL : http://oase.uci.ru.nl/~olejen Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From scrofa at GMAIL.COM Sun Aug 14 14:25:22 2005 From: scrofa at GMAIL.COM (Daniel Kislyuk) Date: Sun, 14 Aug 2005 15:25:22 +0300 Subject: importing 306-Vectorview dataset Message-ID: Hello! I'm trying to import neuromag data (with EEG) to fieldtrip using read_fcdc_header and read_fcdc_data routines, but i keep getting these error message: ---------------------------------------------------------------------------------- ??? Attempt to execute SCRIPT megmodel as a function. Error in ==> d:\danielk\fieldtrip\private\fif2grad.m On line 19 ==> megmodel('head',[0 0 0],filename); Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m On line 245 ==> hdr.grad = fif2grad(headerfile); ----------------------------------------------------------------------------------- Could you, please, help me? Thanks, Daniel From tnt at PHYSIOL.OX.AC.UK Sun Aug 14 16:53:26 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Sun, 14 Aug 2005 16:53:26 +0200 Subject: calculating frequency interaction Message-ID: Hi, I have a conceptual question which I'd like to post to the list. It has been the practice in multisensory research to define the integration of two inputs from different sensory modalities (e.g. auditory (A) and visual (V)) by calculating the interaction [AV - (A+V)], where AV is the simultaneous presentation of both unisensory stimuli. There, it is assumed that any non-linear summation denotes the interaction of the two sensory streams, and hence, is a measure of multisensory integration. For example, assume the following response profile A = 2 units V = 3 units AV = 6 units then the bimodal presentation AV cannot be predicted by the summation of the unimodal inputs alone, hence the difference is thought to be related to multisensory integration. This has been applied to both fMRI and ERP data (from MEG & EEG). (There are, of course, some confounds associated with this method, such as attention, etc, but that's a different matter.) I am interested in how this interaction effect can be calculated with frequency data. Frequency power estimates are done by squaring the amplitude of the bandpassed response, so there is already a "non-linear" step involved in the process. Calculating the interaction as above could then result in erroneous estimates of the integration effect: A = 4 units V = 9 units AV = 36 units From tnt at PHYSIOL.OX.AC.UK Sun Aug 14 17:05:18 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Sun, 14 Aug 2005 17:05:18 +0200 Subject: calculating frequency interaction (now with the complete message) Message-ID: SORRY, I send the last message too early by mistake. Please find the whole text below T. == Hi, I have a conceptual question which I'd like to post to the list. It has been the practice in multisensory research to define the integration of two inputs from different sensory modalities (e.g. auditory (A) and visual (V)) by calculating the interaction [AV - (A+V)], where AV is the simultaneous presentation of both unisensory stimuli. There, it is assumed that any non-linear summation denotes the interaction of the two sensory streams, and hence, is a measure of multisensory integration. For example, assume the following response profile A = 2 units V = 3 units AV = 6 units integration effect = 6-(2+3)= 1 Here, the response to the bimodal presentation AV cannot be predicted by the summation of the unimodal inputs alone, hence the difference is thought to be related to multisensory integration. This has been applied to both fMRI and ERP data (from MEG & EEG). (There are, of course, some confounds associated with this method, such as attention, etc, but that's a different matter.) I am interested in how this interaction effect can be calculated with frequency data. Frequency power estimates are done by squaring the amplitude of the bandpassed response, so there is already a "non-linear" step involved in the process. Calculating the interaction as above could then result in erroneous estimates of the integration effect: A = 3 units; squared = 9 V = 3 units; squared = 9 AV = 6 units; squared = 36 integration effect = 6^2-(3^2+3^2) = 18 even though it is quite evident that the neuronal response to AV is a direct summation of A and V. Any suggestions on how to solve this problem would be greatly appreciated. Thomas From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 09:33:48 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 09:33:48 +0200 Subject: importing 306-Vectorview dataset In-Reply-To: <489aa9f90508140525ff5f78c@mail.gmail.com> Message-ID: Hi Daniel, Did you download and install the MEG-PD toolbox (see http:// www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an extra shared library that is missing in the meg-pd tgz file, see http://oase.uci.kun.nl/~roberto/index.php/neuromag/. Fieldtrip does not support the Neuromag *.fif file format natively, since it is a closed file format. However, Fieldtrip can use the MEG- PD toolbox. What is does is to call the appropriate functions from the MEG-PD toolbox, and to reformat their output into a format that all Fieldtrip functions can handle. The "megmodel" function is a function from the MEG-PD toolbox. This MEG-PD toolbox contains mex files, and they are only provided for linux and HPUX. That means that you cannot read Neuromag data in Matlab under Windows. Besides the mex files (i.e. a file named megmodel.mexglx), there are documentation files (i.e. megmodel.m). These documentation files contain only help and cannot be executed. I suspect that the mex file is missing in your installation. Please type "which megmodel" and check whether it is the mexglx or the m file. best regards Robert On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > Hello! > > I'm trying to import neuromag data (with EEG) to fieldtrip using > read_fcdc_header and read_fcdc_data routines, but i keep getting these > error message: > > ---------------------------------------------------------------------- > ------------ > ??? Attempt to execute SCRIPT megmodel as a function. > > Error in ==> d:\danielk\fieldtrip\private\fif2grad.m > On line 19 ==> megmodel('head',[0 0 0],filename); > > Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m > On line 245 ==> hdr.grad = fif2grad(headerfile); > ---------------------------------------------------------------------- > ------------- > > Could you, please, help me? > > Thanks, > Daniel > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 09:55:20 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 09:55:20 +0200 Subject: calculating frequency interaction (now with the complete message) In-Reply-To: Message-ID: Hi Thomas, On 14-aug-2005, at 17:05, Thomas Thesen wrote: > Calculating the interaction as above could then result in erroneous > estimates of the integration effect: > > A = 3 units; squared = 9 > V = 3 units; squared = 9 > AV = 6 units; squared = 36 > > integration effect = 6^2-(3^2+3^2) = 18 > > even though it is quite evident that the neuronal response to AV is > a direct > summation of A and V. > The effect of summation of the two signals on the estimated power (or amplitude) of their sum depends on the phase relation between the two signals. 1) If the two signals are in perfect phase alignment in each trial (i.e. zero deg phase difference), they will add up as you described. 2) If they are in perfect antiphase (180 deg), they will cancel out. 3) If they have a random phase with respect to each other, i.e. the phase difference is different in each trial, they will add up "a little". In case 1, the amplitude (i.e. sqrt of the power) depends linearly on the amplitude of the two signals. In case 3, the power depends linearly on the power of the two signals. Please try playing with the following lines of code real_pow1 = 3; real_pow2 = 3; t = linspace(0, 2*pi, 1000); for trl=1:100 s1(trl,:) = sqrt(real_pow1)*sqrt(2)*sin(t); phasediff = 2*pi*rand(size(t)); % CHANGE THIS TO SEE THE EFFECT s2(trl,:) = sqrt(real_pow2)*sqrt(2)*sin(t + phasediff); end % add the two signals for each trial s3 = s1+s2; % estimate the single trial power pow_s1 = sum(s1.^2,2)/length(t); pow_s2 = sum(s2.^2,2)/length(t); pow_s3 = sum(s3.^2,2)/length(t); % estimate the power and amplitude pow1 = sum(pow_s1)./100 pow2 = sum(pow_s2)./100 pow3 = sum(pow_s3)./100 ampl1 = sqrt(pow1) ampl2 = sqrt(pow2) ampl3 = sqrt(pow3) I hope that this clarifies it. Of course, it does not yet help you deciding how to test for the interaction, since the additive effect (which you expect under the null hypothesis) can be either on amplitude or on power. To choose the right test, you will have to consider the sources of the two signals that are being mixed on the channel level, i.e. are they coming from one source, or from two sources, and in the latter case, are the two sources strongly coherent or not? best regards, Robert ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From D.Talsma at PSY.VU.NL Mon Aug 15 13:34:04 2005 From: D.Talsma at PSY.VU.NL (Talsma D) Date: Mon, 15 Aug 2005 13:34:04 +0200 Subject: Differences in channel numbers and MEG Interpolate Message-ID: Hi Fieldtrippers, I have the following question regarding meginterpolate: Is it possible to use MEG interpolate to add a channel to the dataset that was never recorded in the first place? I have data from a limited number of subjects that is recorded with one channel (MLO21) less (149 channels) than the data from the other subjects (150 MEG channels). From what I can tell, this is not a channel that is just marked as 'Bad', but one that was never recorded in the first place. I tried interpolating this channel using meginterpolate, but after this procedure, I still have a dataset with 149 channels. Below are the settings I used. Needless to say, I tried various variations, but none appeared to work. For now, I'm going to try and remove the offending channel from the remaining subjects that were recorded with 150 channels. Thanks in advance, Durk templatefile = { 'pp01/corr-resp.ds', 'pp01/incor-resp.ds', 'pp02/corr-resp.ds', 'pp02/incor-resp.ds', 'pp03/corr-resp.ds', 'pp03/incor-resp.ds', 'pp04/corr-resp.ds', 'pp04/incor-resp.ds', 'pp06/corr-resp.ds', 'pp06/incor-resp.ds', 'pp09/corr-resp.ds', 'pp09/incor-resp.ds', 'pp10/corr-resp.ds', 'pp10/incor-resp.ds', 'pp11/corr-resp.ds', 'pp11/incor-resp.ds', 'pp12/corr-resp.ds', 'pp12/incor-resp.ds', 'pp13/corr-resp.ds', 'pp13/incor-resp.ds', 'pp14/corr-resp.ds', 'pp14/incor-resp.ds', 'pp15/corr-resp.ds', 'pp15/incor-resp.ds' }; cfgrepair = []; cfgrepair.repair = 'yes'; cfgrepair.realign = 'no'; cfgrepair.planar = 'no'; cfgrepair.template =templatefile; cfgrepair.hdmfile ='standard.hdm'; cfgrepair.badchannel = {'MLO21'}; dataCor_corrected = meginterpolate(cfgrepair, dataCor); dataInc_corrected = meginterpolate(cfgrepair, dataInc); From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 13:55:44 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 13:55:44 +0200 Subject: Differences in channel numbers and MEG Interpolate In-Reply-To: Message-ID: Hi Durk, No, that is not possible. Megrepair will only interpolate an existing channel (using nearest neighbours). What you can do is to manually add the channel to your preprocessed dataset. E.g. cfg = ... raw = preprocessing(cfg); raw.label{end+1} = 'MLO21'; for i=1:length(data.trial) data.trial{i}(end+1,:) = 0; end Btw. I suggest to call MERREPAIR, MEGREALIGN and MEGPLANAR seperately and not use the MEGINTERPOLATE (in the old days, there was this one function, but that was split up into its logical components). best, Robert On 15-aug-2005, at 13:34, Talsma D wrote: > Hi Fieldtrippers, > > I have the following question regarding meginterpolate: Is it possible > to use MEG interpolate to add a channel to the dataset that was never > recorded in the first place? I have data from a limited number of > subjects that is recorded with one channel (MLO21) less (149 channels) > than the data from the other subjects (150 MEG channels). From what I > can tell, this is not a channel that is just marked as 'Bad', but one > that was never recorded in the first place. I tried interpolating this > channel using meginterpolate, but after this procedure, I still have a > dataset with 149 channels. Below are the settings I used. Needless to > say, I tried various variations, but none appeared to work. > > For now, I'm going to try and remove the offending channel from the > remaining subjects that were recorded with 150 channels. > > Thanks in advance, > Durk > > > templatefile = { 'pp01/corr-resp.ds', > 'pp01/incor-resp.ds', > 'pp02/corr-resp.ds', > 'pp02/incor-resp.ds', > 'pp03/corr-resp.ds', > 'pp03/incor-resp.ds', > 'pp04/corr-resp.ds', > 'pp04/incor-resp.ds', > 'pp06/corr-resp.ds', > 'pp06/incor-resp.ds', > 'pp09/corr-resp.ds', > 'pp09/incor-resp.ds', > 'pp10/corr-resp.ds', > 'pp10/incor-resp.ds', > 'pp11/corr-resp.ds', > 'pp11/incor-resp.ds', > 'pp12/corr-resp.ds', > 'pp12/incor-resp.ds', > 'pp13/corr-resp.ds', > 'pp13/incor-resp.ds', > 'pp14/corr-resp.ds', > 'pp14/incor-resp.ds', > 'pp15/corr-resp.ds', > 'pp15/incor-resp.ds' > }; > > cfgrepair = []; > cfgrepair.repair = 'yes'; > cfgrepair.realign = 'no'; > cfgrepair.planar = 'no'; > cfgrepair.template =templatefile; > cfgrepair.hdmfile ='standard.hdm'; > cfgrepair.badchannel = {'MLO21'}; > > dataCor_corrected = meginterpolate(cfgrepair, dataCor); > dataInc_corrected = meginterpolate(cfgrepair, dataInc); > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From jhouck at UNM.EDU Mon Aug 15 19:17:33 2005 From: jhouck at UNM.EDU (Jon Houck) Date: Mon, 15 Aug 2005 11:17:33 -0600 Subject: importing 306-Vectorview dataset Message-ID: Hello, Kimmo has a partial Windows version of the MEG-PD toolbox posted on his site now. I've used it successfully with 306-channel data in the old 4D Toolbox, but haven't tested it with Fieldtrip yet. It may be of some use here. Regards, Jon Houck ----- Original Message ----- From: "Robert Oostenveld" To: Sent: Monday, August 15, 2005 1:33 AM Subject: Re: [FIELDTRIP] importing 306-Vectorview dataset > Hi Daniel, > > Did you download and install the MEG-PD toolbox (see http:// > www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an > extra shared library that is missing in the meg-pd tgz file, see > http://oase.uci.kun.nl/~roberto/index.php/neuromag/. > > Fieldtrip does not support the Neuromag *.fif file format natively, > since it is a closed file format. However, Fieldtrip can use the MEG- > PD toolbox. What is does is to call the appropriate functions from > the MEG-PD toolbox, and to reformat their output into a format that > all Fieldtrip functions can handle. The "megmodel" function is a > function from the MEG-PD toolbox. This MEG-PD toolbox contains mex > files, and they are only provided for linux and HPUX. That means that > you cannot read Neuromag data in Matlab under Windows. Besides the > mex files (i.e. a file named megmodel.mexglx), there are > documentation files (i.e. megmodel.m). These documentation files > contain only help and cannot be executed. I suspect that the mex file > is missing in your installation. Please type "which megmodel" and > check whether it is the mexglx or the m file. > > best regards > Robert > > > > > On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > > > Hello! > > > > I'm trying to import neuromag data (with EEG) to fieldtrip using > > read_fcdc_header and read_fcdc_data routines, but i keep getting these > > error message: > > > > ---------------------------------------------------------------------- > > ------------ > > ??? Attempt to execute SCRIPT megmodel as a function. > > > > Error in ==> d:\danielk\fieldtrip\private\fif2grad.m > > On line 19 ==> megmodel('head',[0 0 0],filename); > > > > Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m > > On line 245 ==> hdr.grad = fif2grad(headerfile); > > ---------------------------------------------------------------------- > > ------------- > > > > Could you, please, help me? > > > > Thanks, > > Daniel > > > > > > ======================================================= > Robert Oostenveld, PhD > F.C. Donders Centre for Cognitive Neuroimaging > Radboud University Nijmegen > phone: +31-24-3619695 > http://www.ru.nl/fcdonders/ > From lauri at NEURO.HUT.FI Mon Aug 15 21:43:58 2005 From: lauri at NEURO.HUT.FI (Lauri Parkkonen) Date: Mon, 15 Aug 2005 22:43:58 +0300 Subject: importing 306-Vectorview dataset In-Reply-To: <5757A7A1-9C27-4487-8906-6FD1603C53C4@fcdonders.ru.nl> Message-ID: Hi Daniel and other Fieldtrippers, To read the Neuromag files into Fieldtrip/Matlab you need Kimmo Uutela's FiffAccess (aka meg-pd) package, available for Linux, HPUX and Windows as Robert and Jon pointed out. The packages do contain the required shared library, however, you need to tell the Linux dynamic linker where to find this library before starting Matlab (see the FiffAccess manual/Installation instructions). This step is often forgotten so I wrote here some instructions (assuming you're running Linux). You have two options to tell the system where to look for the new library: 1) User-specific configuration: Set the environment variable LD_LIBRARY_PATH to point to the library directory before starting Matlab: - sh/bash users export LD_LIBRARY_PATH /opt/neuromag/lib/i586-pc-linux-gnu - tcsh/csh users setenv LD_LIBRARY_PATH /opt/neuromag/lib/i586-pc-linux-gnu (there are some inconsistencies whether the architecture is i586-... or i686-...; please check in which one you actually find the library file after installing the FiffAccess package and substitute accordingly) 2) System-wide configuration: As the root user, add the line /opt/neuromag/lib/i586-pc-linux-gnu to /etc/ld.so.conf (or - in some Linux distros - make a file containing that line and put the file under /etc/ld.so.conf.d) and run /sbin/ldconfig. With both options, you can check if the shared lib is found correctly by saying ldd /opt/neuromag/meg_pd_1.2/megmodel.mexglx which should print out something like: linux-gate.so.1 => (0x00d02000) libmagnet_pdg_1.2.so => /opt/neuromag/lib/i586-pc-linux-gnu/libmagnet_pdg_1.2.so (0x00beb000) libmx.so => not found libmex.so => not found libmat.so => not found libm.so.6 => /lib/libm.so.6 (0x0051e000) libc.so.6 => /lib/libc.so.6 (0x003ba000) /lib/ld-linux.so.2 (0x0027b000) Don't worry about libmx, libmex and libmat not being found; they'll be linked correctly by Matlab. Hope this helps you to get the Neuromag file import working. Best regards, Lauri Robert Oostenveld wrote: > Hi Daniel, > > Did you download and install the MEG-PD toolbox (see http:// > www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an > extra shared library that is missing in the meg-pd tgz file, see > http://oase.uci.kun.nl/~roberto/index.php/neuromag/. > > Fieldtrip does not support the Neuromag *.fif file format natively, > since it is a closed file format. However, Fieldtrip can use the MEG- > PD toolbox. What is does is to call the appropriate functions from > the MEG-PD toolbox, and to reformat their output into a format that > all Fieldtrip functions can handle. The "megmodel" function is a > function from the MEG-PD toolbox. This MEG-PD toolbox contains mex > files, and they are only provided for linux and HPUX. That means that > you cannot read Neuromag data in Matlab under Windows. Besides the > mex files (i.e. a file named megmodel.mexglx), there are > documentation files (i.e. megmodel.m). These documentation files > contain only help and cannot be executed. I suspect that the mex file > is missing in your installation. Please type "which megmodel" and > check whether it is the mexglx or the m file. > > best regards > Robert > > > > > On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > >> Hello! >> >> I'm trying to import neuromag data (with EEG) to fieldtrip using >> read_fcdc_header and read_fcdc_data routines, but i keep getting these >> error message: >> >> ---------------------------------------------------------------------- >> ------------ >> ??? Attempt to execute SCRIPT megmodel as a function. >> >> Error in ==> d:\danielk\fieldtrip\private\fif2grad.m >> On line 19 ==> megmodel('head',[0 0 0],filename); >> >> Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m >> On line 245 ==> hdr.grad = fif2grad(headerfile); >> ---------------------------------------------------------------------- >> ------------- >> >> Could you, please, help me? >> >> Thanks, >> Daniel >> >> > > ======================================================= > Robert Oostenveld, PhD > F.C. Donders Centre for Cognitive Neuroimaging > Radboud University Nijmegen > phone: +31-24-3619695 > http://www.ru.nl/fcdonders/ -- ----------------------------------------------- Lauri Parkkonen Brain Research Unit, Low Temperature Laboratory Helsinki University of Technology Otakaari 3 A, 02150 ESPOO, FINLAND tel: +358-9-4512965 fax: +358-9-4512969 mailto:lauri at neuro.hut.fi http://boojum.hut.fi From tnt at PHYSIOL.OX.AC.UK Mon Aug 15 23:41:55 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Mon, 15 Aug 2005 23:41:55 +0200 Subject: calculating frequency interaction (now with the complete message) Message-ID: Hi Rob, Thanks for the simulation. That really helped to make the issue clear! If others are interested to see how the phase relationship between two signals relates to the linearity or non-linearity of the summed power or amplitudes can have a look at these figures that were derived from Robs code below: http://www.physiol.ox.ac.uk/~tnt/fieldtrip/ FT_phase1.jpg FT_phase2.jpg One example shows perfect phase and one anti-phase. The bottom graph shows the phase relationship of the signals for condition A and V, and their sum A+V. In the code that's s1 to s3. The top graphs show the values for amplitude (ampl1 to ampl3) and power (pow1 to pow3). Diff is the subtraction of pow3-pow2-pow1 (or the same foe amp). If diff is zero the summation is linear. Rob, your comments regarding the appropriate approach for testing the interaction are very insightful. Thank you. Considering that MEG/EEG data contain a lot from both of these options it seems unwise to do this type of testing. One couldn't tell wether a different phase relationship or a true effect might be responsible for non-linear summation. Or am I wrong there? I just saw at a conference a poster where they tried the same thing using bootstrapping. The web link above contains a copy of that poster "Senkowski...jpg". What do you think about this approach? Could that be done using FieldTrip? Thanks a lot, Thomas On Mon, 15 Aug 2005 09:55:20 +0200, Robert Oostenveld wrote: >Hi Thomas, > >On 14-aug-2005, at 17:05, Thomas Thesen wrote: > > >> Calculating the interaction as above could then result in erroneous >> estimates of the integration effect: >> >> A = 3 units; squared = 9 >> V = 3 units; squared = 9 >> AV = 6 units; squared = 36 >> >> integration effect = 6^2-(3^2+3^2) = 18 >> >> even though it is quite evident that the neuronal response to AV is >> a direct >> summation of A and V. >> > >The effect of summation of the two signals on the estimated power (or >amplitude) of their sum depends on the phase relation between the two >signals. >1) If the two signals are in perfect phase alignment in each trial >(i.e. zero deg phase difference), they will add up as you described. >2) If they are in perfect antiphase (180 deg), they will cancel out. >3) If they have a random phase with respect to each other, i.e. the >phase difference is different in each trial, they will add up "a >little". >In case 1, the amplitude (i.e. sqrt of the power) depends linearly on >the amplitude of the two signals. In case 3, the power depends >linearly on the power of the two signals. > >Please try playing with the following lines of code > >real_pow1 = 3; >real_pow2 = 3; >t = linspace(0, 2*pi, 1000); > >for trl=1:100 > s1(trl,:) = sqrt(real_pow1)*sqrt(2)*sin(t); > phasediff = 2*pi*rand(size(t)); % CHANGE THIS TO SEE THE EFFECT > s2(trl,:) = sqrt(real_pow2)*sqrt(2)*sin(t + phasediff); >end > >% add the two signals for each trial >s3 = s1+s2; > >% estimate the single trial power >pow_s1 = sum(s1.^2,2)/length(t); >pow_s2 = sum(s2.^2,2)/length(t); >pow_s3 = sum(s3.^2,2)/length(t); > >% estimate the power and amplitude >pow1 = sum(pow_s1)./100 >pow2 = sum(pow_s2)./100 >pow3 = sum(pow_s3)./100 > >ampl1 = sqrt(pow1) >ampl2 = sqrt(pow2) >ampl3 = sqrt(pow3) > >I hope that this clarifies it. Of course, it does not yet help you >deciding how to test for the interaction, since the additive effect >(which you expect under the null hypothesis) can be either on >amplitude or on power. To choose the right test, you will have to >consider the sources of the two signals that are being mixed on the >channel level, i.e. are they coming from one source, or from two >sources, and in the latter case, are the two sources strongly >coherent or not? > >best regards, >Robert > > >======================================================= >Robert Oostenveld, PhD >F.C. Donders Centre for Cognitive Neuroimaging >Radboud University Nijmegen >phone: +31-24-3619695 >http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Tue Aug 16 09:29:07 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 16 Aug 2005 09:29:07 +0200 Subject: calculating frequency interaction (now with the complete message) In-Reply-To: Message-ID: Hi Thomas, On 15-aug-2005, at 23:41, Thomas Thesen wrote: > Rob, your comments regarding the appropriate approach for testing the > interaction are very insightful. Thank you. Considering that MEG/ > EEG data > contain a lot from both of these options it seems unwise to do this > type of > testing. One couldn't tell wether a different phase relationship or > a true > effect might be responsible for non-linear summation. Or am I wrong > there? You always assume the null-hypothesis to be true, which means no effects and no coherences. Then you test the probability of observing your data under this hypothesis. If that is unlikely, you conclude that the null-hypothesis does not apply. Therefore, knowing that there are all sorts of complex dynamics in the brain does not harm the correctness of your inference based on the statistical test, since the test is based on the absence of the effect. Of course you should be carefull and explicit in phrasing your null-hypothesis, my phrasing here is too vague to operationalize it. > I just saw at a conference a poster where they tried the same thing > using > bootstrapping. The web link above contains a copy of that poster > "Senkowski...jpg". What do you think about this approach? Could > that be done > using FieldTrip? The approach could in theory be done in Fieldtrip without too much additional programming effort. It slightly resembles the statistical test based on randomization theory that is implemented in clusterrandanalysis (also see http://www2.ru.nl/fcdonders/fieldtrip/ uploads/media/RandBioTheory.pdf). However, the test suggested by Senkowski on the poster that you sent is not very clear in the hypothesis that is being tested. They focus on the sensitivity of the test, but not on the validity of rejecting the null hypothesis. I would rephrase their approach: they assume that the AV trials originate from the same (unknown) distribution as the manually crafted A+V trials. They have created NA times NV of these N+V trials (i.e. each possible combination) and randomly draw subsets from this A +V distribution with the same number of trials as they have in their AV average. The error that they make is that they do not consider the noise that is present in the measurement. In the absence of any signal of interest in the EEG, you still would have (electrode) noise. That noise is present in the AV condition, in the A condition and in the V condition. If you add an A trial with a V trial, the noise will add. Since noise here is assumed to be uncorrelated over trials, the noise in A+V will be sqrt(2) times the noise in either A or V allone. But the noise in AV is similar as that in either A or V (since they are all raw trials from the recorded data), hence the noise in their A+V trial is sqrt(2) times the noise in the AV trial. Therefore I conclude that there is a trivial difference between the data, irrespective of the true underlying difference, which results in a systematic overestimation of the A+V power with respect to the AV power. In their case, the more noise their signals contain, the more likely it is that they will reject the hypothesis that the A+V and the AV trials originate from the same distribution. Their incorrect alternative hypothesis is subadditivity, i.e. the AV condition has less power than the A+V condition. best regards, Robert From morier8 at ETU.UNIGE.CH Wed Aug 17 12:43:14 2005 From: morier8 at ETU.UNIGE.CH (patrice) Date: Wed, 17 Aug 2005 12:43:14 +0200 Subject: immediate 3D plot Message-ID: Hi all, I would like to make a graphical plot of my data with fieldtrip. No frequency analysis, no averaging, no filtering or whatever, only a simple plot to display the active regions in the brain. My data (EEG) are stored in a 2D matrix (voxels x time-points). My voxels are distributed in the whole brain (not only on the scalp). Furthermore, I have a file that contains the 3D coordinates of my voxels (X,Y and Z) and an header file associated to the used model. Is it feasible with fieldtrip? If yes, do you have any idea to achieve this? Any suggestion would be helpful. Regards, patrice From r.oostenveld at FCDONDERS.RU.NL Fri Aug 19 15:41:38 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 19 Aug 2005 15:41:38 +0200 Subject: immediate 3D plot In-Reply-To: Message-ID: Hi Patrice On 17-aug-2005, at 12:43, patrice wrote: > I would like to make a graphical plot of my data with fieldtrip. No > frequency analysis, no averaging, no filtering or whatever, only a > simple > plot to display the active regions in the brain. I guess that means that you want to plot the potential that you have recorded at each electrode site? > My data (EEG) are stored in a 2D matrix (voxels x time-points). My > voxels > are distributed in the whole brain (not only on the scalp). Does that mean that you have depth electrodes? Or did you do a source reconstrucion of your EEG in some external software? > Furthermore, I have a file that contains the 3D coordinates of my > voxels (X,Y and Z) > and an header file associated to the used model. Is it feasible > with fieldtrip? If > yes, do you have any idea to achieve this? Is it a regular arrangement, i.e. do the voxels form a box-like volume? If so, then you can "massage" the data into fieldtrip as a sourcereconstruction and use the sourceinterpolate function. However, since you have recorded it at many samples (timepoints), that means that a graphical representation of that data would consist of a 3D volume with an additional time dimension, i.e. the data is 4D. Hence, it would be a movie in which you can show a single cross- section (slice) through the brain at a time. Such a movie can be made in Matlab, but fieldtrip would not be of many use for you. Robert From sanja at UNM.EDU Fri Aug 19 19:42:21 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 19 Aug 2005 11:42:21 -0600 Subject: source projection In-Reply-To: <8182F211-66DD-4AFC-8E9D-472F041233EF@fcdonders.ru.nl> Message-ID: Hi Robert, I've tried using megrealign and megplanar with the CTF 275 ch data, however I run into problems with source projection. First, for megrealign there was a warning about the higher order synthetic gradiometer configuration. Nevertheless, megrealign ran, but after freqanalysis the resulting tfr values for several channels were much higher (3 orders of magnitude) than for the rest of the channels (which was not the case for the original not realigned data). Second, megplanar stopped running with "the forward model does not look like EEG, nor like MEG" error. I've saved the CTF data with the 3rd order noise cancellation on (via newDs -filter) and then read these noise canceled data into fieldtrip. However, I've only read in MEG and STIM channels, I haven't read in the reference channels. Do you have any thoughts on what might be going on? I appreciate your help, Sanja On Fri, 12 Aug 2005 14:02:20 +0200 Robert Oostenveld wrote: > Hi Sanja, > > On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: >> I am trying to use >>meginterpolate/freqanalysis/combineplanar to get >> the tfr >> data in the planar gradiometer system, instead of the >>original 275 >> ch axial. >> However, combineplanar needs planarchannelset, but this >>function is >> not >> included in the 20050811 distribution. Could you include >>this >> function in >> the next distribution? > > Please find the function attached to this mail. I will >add it to the next daily releases, sorry that it was >missing. > > The attached version however does not include the 275ch >CTF system yet, but it is easy to add. You basically >only have to make a table with the planar channel labels >that should be combined, and the name of the combined >channel (i.e. the original name). I would appreciate it >if you would send me the table information for the CTF >275 system, I will then update the release version as >well. > >> I have a set of questions related to meginterpolate: Can >>CTF274.lay >> be used >> for ploting the planar data? Should I use a default >>single sphere >> model for >> each subject or a single sphere model particular for a >>subject for >> realignment? Should "nominal" sensor locations be used >>as a >> template for >> each subject, or do you recommend taking an average >>across subjects >> for the >> template? > > Yes, but only for combineplanar'ed data in combination >with topoplotTFR. It is conceptually not possible to >make a topography of the "raw" planar data itself, but >you can do a multiplotER and multiplotTFR of the planar >data. However, that would require another lay file. The >NM122all.lay file is one for the Neuromag system that > plots the 122 planar channels at 66 locations, with >horizontal and vertical channel next to each other. > > If you do not specify a layout in the cfg of >multiplotTFR, the private subfunction createlayout will >construct a layout on the fly based on the gradiometer >positions. Usually the plotting is more controlled with >a manually eddited layout file, but the automatic one > can serve as starting point. Looking into the code, I >now realise that there still are some loose ends. The >megplanar function does not return the planar gadiometer >definition. Please have a look at the private functions >axial2planar and createlayout, and use them together to >construct a planar layout file. > > best regards, > Robert From sanja at UNM.EDU Fri Aug 19 23:43:42 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 19 Aug 2005 15:43:42 -0600 Subject: source projection In-Reply-To: Message-ID: Oh, I forgot to mention that I used meplanar with the source projection option. I tracked the problem down to axial2planar (line 309 of megplanar: planar.grad = axial2planar([], axial.grad)). Axial2planar does not return the field "type" in planar.grad, and therefore compute_leadfield could not recognize the sensor type and gives "the forward model does not look like EEG, nor like MEG" error. -Sanja On Fri, 19 Aug 2005 11:42:21 -0600 Sanja Kovacevic wrote: > Hi Robert, > > I've tried using megrealign and megplanar with the CTF >275 ch data, however I run into problems with source >projection. First, for megrealign there was a warning >about the higher order synthetic gradiometer >configuration. Nevertheless, megrealign ran, but after >freqanalysis the resulting tfr values for several >channels were much higher (3 orders of magnitude) than >for the rest of the channels (which was not the case for >the original not realigned data). Second, megplanar >stopped running with "the forward model does not look >like EEG, nor like MEG" error. I've saved the CTF data >with the 3rd order noise cancellation on (via newDs >-filter) and then read these noise canceled data into >fieldtrip. However, I've only read in MEG and STIM >channels, I haven't read in the reference channels. Do >you have any thoughts on what might be going on? > > I appreciate your help, > > Sanja > > > On Fri, 12 Aug 2005 14:02:20 +0200 > Robert Oostenveld wrote: >> Hi Sanja, >> >> On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: >>> I am trying to use >>>meginterpolate/freqanalysis/combineplanar to get >>> the tfr >>> data in the planar gradiometer system, instead of the >>>original 275 >>> ch axial. >>> However, combineplanar needs planarchannelset, but this >>>function is >>> not >>> included in the 20050811 distribution. Could you include >>>this >>> function in >>> the next distribution? >> >> Please find the function attached to this mail. I will >>add it to the next daily releases, sorry that it was >>missing. >> >> The attached version however does not include the 275ch >>CTF system yet, but it is easy to add. You basically >>only have to make a table with the planar channel labels >>that should be combined, and the name of the combined >>channel (i.e. the original name). I would appreciate it >>if you would send me the table information for the CTF >>275 system, I will then update the release version as >>well. >> >>> I have a set of questions related to meginterpolate: Can >>>CTF274.lay >>> be used >>> for ploting the planar data? Should I use a default >>>single sphere >>> model for >>> each subject or a single sphere model particular for a >>>subject for >>> realignment? Should "nominal" sensor locations be used >>>as a >>> template for >>> each subject, or do you recommend taking an average >>>across subjects >>> for the >>> template? >> >> Yes, but only for combineplanar'ed data in combination >>with topoplotTFR. It is conceptually not possible to >>make a topography of the "raw" planar data itself, but >>you can do a multiplotER and multiplotTFR of the planar >>data. However, that would require another lay file. The >>NM122all.lay file is one for the Neuromag system that >>plots the 122 planar channels at 66 locations, with >>horizontal and vertical channel next to each other. >> >> If you do not specify a layout in the cfg of >>multiplotTFR, the private subfunction createlayout will >>construct a layout on the fly based on the gradiometer >>positions. Usually the plotting is more controlled with >>a manually eddited layout file, but the automatic one can >>serve as starting point. Looking into the code, I >>now realise that there still are some loose ends. The >>megplanar function does not return the planar gadiometer >>definition. Please have a look at the private functions >>axial2planar and createlayout, and use them together to >>construct a planar layout file. >> >> best regards, >> Robert Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From r.oostenveld at FCDONDERS.RU.NL Sat Aug 20 10:08:19 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Sat, 20 Aug 2005 10:08:19 +0200 Subject: source projection In-Reply-To: Message-ID: Hi Sanja, First some general comments. In my experience megrealign works more accurate with the sincos option (i.e. nearest neighbour interpolation) than with the sourceproject option. I have validated this function using simulated data, in which I computed the field of a dipole on axial gradiometers, and the field of the same data on (true) planar gradiometers. Then I converted the axial to the planar data with megplanar and the different options there and compared the two. I repeated this with different noise levels and the sincos was consistenly more acurate than the others. However (relevant for other people as well) the 'orig' method is still the default. That was implemented initially by Ole Jensen, the other ones were implemented by me. The low-level forward computation of the fields in Fieldtrip cannot make use of the synthetic higfher order gradients. In theory that could be supported, but the weights of the reference sensors are not read in from teh res4 file. That means, whenever you do a computation that involves a forward computed field (sourceanalysis, dipolefitting, megrealign and megplanar+sourceproject), the forward field is a plain 1st order MEG gradient. If your CTFdata is 3rd order, and you have saved it with newDs, there will be a slight discrepancy between the measured data and the forward model, even if your measured data contains a single perfect dipole. The field of the sources in the brain will also be slightly supporessed, which is not represented in the forward model. However, the advantage of the 3rd order gradient is that also environmental noise is suppressed. So there is a trade off, if you have a lot of noise, it is better to use the 3rd order gradient, if you have very clean data, it is better not to use it. I would like to implement the 3rd order gradients, and have most code for it in place, but there are some details that need to be sorted out. If you are going to use it and think that you can contribute, I would appreciate your help on that. Now onto your question: On 19-aug-2005, at 23:43, Sanja Kovacevic wrote: > Oh, I forgot to mention that I used meplanar with the source > projection option. I tracked the problem down to axial2planar (line > 309 of megplanar: planar.grad = axial2planar([], axial.grad)). > Axial2planar does not return the field "type" in planar.grad, and > therefore compute_leadfield could not recognize the sensor type and > gives "the forward model does not look like EEG, nor like MEG" error. > > One potential problem here might be that axial2planar is also trying to compute the planar representation of the reference sensors. I don't think that that applies in your case, but it should not do that. So that is something to check. The latest version of compute_leadfield (revision 1.7) should also detect the correct type in the absence of the "type" field. It has the following added with repect to the older versions elseif isfield(sens, 'pnt') & isfield(sens, 'ori') iseeg = 0; ismeg = 1; If yours does not contain that, please upgrade your fieldtrip version. best regards, Robert From sanja at UNM.EDU Wed Aug 24 00:50:18 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Tue, 23 Aug 2005 16:50:18 -0600 Subject: source projection In-Reply-To: <9F60D4E0-E095-4BF8-B3AB-91241311EB95@fcdonders.ru.nl> Message-ID: Hi Robert, Have you also tried different neighbor distances when you tested megplanar? I believe that for the 151 channel system, the default 4 cm distance would lead to a smaller average number of neighbors than for the 275 channel system. For 275 channel data, using 3 cm neighbor distance I've got 5.5 neighbors on average, while using 4 cm neighbor distance, I've got 9.1 neighbors on average. I noticed that when I used 4 cm neighbor distance, changes in power were more spread out. Do you have any suggestions on how many neighbors would be optimal? Thank you, Sanja From r.oostenveld at FCDONDERS.RU.NL Thu Aug 25 09:00:55 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Thu, 25 Aug 2005 09:00:55 +0200 Subject: source projection In-Reply-To: Message-ID: Hi Sanja, That is something that I never considered, actually. In our 151 channel case, we have with the default 4 cm about one circle of sensors around the sensor of interest. In your 275 channel case that is of course more. Intuitively, I would say that you want to have a smallest circle of sensors that is possible, to accieve the highest spatial resolution. Increasing the spatial resolution is, besides making the spatial topography more easy to understand, a main goal of planar gradients. But constructing the synthetic planar gradients using the nearest neighbour approach also makes the signals more noise, since, at the sensor of interest, you are mixing in the (independent) noise of the neighbouring sensors. In our 151ch case, that is something that we just have to accept, but in your 275ch case, you can trade in some of the spatial resolution (lower, if more channels as neighbours) against the noise (beter, by averaging the noise over them). best regards, Robert On 24-aug-2005, at 0:50, Sanja Kovacevic wrote: > Hi Robert, > > Have you also tried different neighbor distances when you tested > megplanar? I believe that for the 151 channel system, the default 4 > cm distance would lead to a smaller average number of neighbors > than for the 275 channel system. For 275 channel data, using 3 cm > neighbor distance I've got 5.5 neighbors on average, while using 4 > cm neighbor distance, I've got 9.1 neighbors on average. I noticed > that when I used 4 cm neighbor distance, changes in power were more > spread out. Do you have any suggestions on how many neighbors would > be optimal? > > > Thank you, > Sanja > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From Jan.Schoffelen at FCDONDERS.RU.NL Tue Aug 30 13:18:14 2005 From: Jan.Schoffelen at FCDONDERS.RU.NL (J.M. Schoffelen) Date: Tue, 30 Aug 2005 13:18:14 +0200 Subject: bug-report topoplotER Message-ID: Dear all, I would like to point you to the fact that there is a "bug" in one of fieldtrip's plotting functions: topoplotER.m You can specify for the data to be plotted, the time-interval, or the frequency-interval you would like to have displayed. The function is capable of plotting just one time-bin, or frequency-bin, if you specify cfg.xlim = [x x], x being the latency or frequency you're interested in. HOWEVER, so far this only worked correctly if the wished for latency/frequency was exactly present in the data. The function gives you a completely wrong output, if that is not the case (the same thing goes if your latency-window or frequency-window is in between consecutive data-points in your data). In future releases of this function, an explicit error will be given, instead of silent and misleading nonsense. Sorry for the potential inconvenience, Jan-M -------------- next part -------------- An HTML attachment was scrubbed... URL: From wibral at MPIH-FRANKFURT.MPG.DE Mon Aug 1 11:45:11 2005 From: wibral at MPIH-FRANKFURT.MPG.DE (Michael Wibral) Date: Mon, 1 Aug 2005 11:45:11 +0200 Subject: Matlab 7 crashes with Fieldtrip graphics In-Reply-To: Message-ID: Hi, I had a similar problem with graphs of the same type (also not from within Fieldtrip) and it helped to change the OpenGL preferences of Matlab 7 by issuing the command: opengl('software') either on the command line before you run anything else or somewhere in your script before you actually do graphics. Matlab seems to have (a lot) of incomaptibilty problems with hardware implementations of Open GL. I hope that solves your problem, Michael Litvak Vladimir schrieb: > Dear Fieldtrip developers, > > I started using Matlab 7 and it crashes when using topoplotTFR almost > every time (especially if it was already running for a while prior to > that). I know it's not your bug but have you encountered this (on Win > XP)? This really gets on my nerves. If anyone else has this problem > maybe it's a good idea to ask Mathworks about it. > > Thanks, > > Vladimir > > . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maris at NICI.RU.NL Fri Aug 5 14:33:52 2005 From: maris at NICI.RU.NL (Eric Maris) Date: Fri, 5 Aug 2005 14:33:52 +0200 Subject: nonparametric statistics Message-ID: Dear all, Several people have asked me for a reference paper explaining the theory behing the nonparametric statistical tests that are performed in several Fieldtrip functions. Recently, together with Robert Oostenveld, I have submitted such a paper. You can find this paper in the Publications folder on the Fieldtrip website. greetings, dr. Eric Maris NICI/Biological Psychology and F.C. Donders Center for Cognitive NeuroImaging University of Nijmegen P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 (NICI) T:+31 24 3610754 (FCDC) F:+31 24 3616066 (NICI) E: maris at nici.ru.nl The University of Nijmegen will be named Radboud University Nijmegen as of September 1st, 2004 From h.f.kwok at BHAM.AC.UK Tue Aug 9 15:05:08 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 15:05:08 +0200 Subject: problems using fieldtrip Message-ID: This is the first time that I am using FieldTrip. Just like to ask what other software are needed besides MATLAB in order to run the tutorials. I have tried to run the tutorials after downloading and unzipping the Subject01.zip but I ran into problems. Firstly, in the Event Related Averaging tutorial, the EventRelatedAveraging.m was mentioned but I could not find the file. Secondly, after I created a cfg structure with 'Subject01.ds' as the dataset and all the other field properties as instructed in the tutorial, I got the following error message when using the preprocessing.m: CTF_READ_RES4 [v 1.12] ??? Error using ==> read_fcdc_header could not read CTF res4 header file Error in ==> preprocessing at 219 hdr = read_fcdc_header(cfg.headerfile); Can anyone help please? Regards, Hoi Fei From r.oostenveld at FCDONDERS.RU.NL Tue Aug 9 15:38:55 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 9 Aug 2005 15:38:55 +0200 Subject: problems using fieldtrip In-Reply-To: Message-ID: Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 15:48:44 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 14:48:44 +0100 Subject: problems using fieldtrip In-Reply-To: <78FC6891-F9A5-443C-8EC6-DA4AE1194C32@fcdonders.ru.nl> Message-ID: Thanks, Robert, The 'Subject01.ds' was in the search path. The error occurred whether I was in the same directory as the 'Subject01.ds' or not. When I typed the command while in the same directory as the 'Subject01.ds', I got this: CTF_READ_RES4 [v 1.12] ...done ( 0.79 sec) ??? Error using ==> read_fcdc_header could not read CTF res4 header file Error in ==> preprocessing at 219 hdr = read_fcdc_header(cfg.headerfile); Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 16:14:22 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 15:14:22 +0100 Subject: problems using fieldtrip In-Reply-To: <78FC6891-F9A5-443C-8EC6-DA4AE1194C32@fcdonders.ru.nl> Message-ID: Dear Robert, I have just tried to put breakpoints in some of the m-files to see what the problems are. I have found some potential causes of the problem. Starting from line 133 of the 'read_fcdc_header.m': if ctferror && haseegsf % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From Jan.Schoffelen at FCDONDERS.RU.NL Tue Aug 9 17:14:32 2005 From: Jan.Schoffelen at FCDONDERS.RU.NL (J.M. Schoffelen) Date: Tue, 9 Aug 2005 17:14:32 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59cec$a3af3270$e516bc93@universi8ef8be> Message-ID: Dear Hoi Fei, I think I have a clue of what is going on: if ctferror && haseegsf This is the thing that should not occur, so for some reason or another both haseegsf and ctferror are true: This means that somewhere in your path you have the files ctf_read_meg4, and ctf_read_res4, which usually is no problem, but in this case is half of your problem, because it makes the if-statement already half true. Next to this ctferror apparently is true, which should not be the case. It goes wrong in line 130, where ctferror is put to one after the catch, so the try did not work out too well. I would say that this could be caused by the fact that you lack the function read_ctf_res4 altogether, which should be located in the private-subdirectory of fieldtrip. This does not seem too likely to me, so I would guess that somehow the headerfile in line 126 is incorrecly formatted. To get an idea if this is the case, try to put a breakpoint in line 127 or so. Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? This might also be the problem. Hope this helps a bit, Yours, Jan-Mathijs % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From h.f.kwok at BHAM.AC.UK Tue Aug 9 17:25:48 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Tue, 9 Aug 2005 16:25:48 +0100 Subject: problems using fieldtrip In-Reply-To: <0IKY00HZWNO8K0@mailserver.uci.kun.nl> Message-ID: Hi, Jan-Mathijs, I have checked and the ctf_read_res4 file is in the private subdirectory and I was at the same folder as the Subject01.ds. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of J.M. Schoffelen Sent: 09 August 2005 16:15 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei, I think I have a clue of what is going on: if ctferror && haseegsf This is the thing that should not occur, so for some reason or another both haseegsf and ctferror are true: This means that somewhere in your path you have the files ctf_read_meg4, and ctf_read_res4, which usually is no problem, but in this case is half of your problem, because it makes the if-statement already half true. Next to this ctferror apparently is true, which should not be the case. It goes wrong in line 130, where ctferror is put to one after the catch, so the try did not work out too well. I would say that this could be caused by the fact that you lack the function read_ctf_res4 altogether, which should be located in the private-subdirectory of fieldtrip. This does not seem too likely to me, so I would guess that somehow the headerfile in line 126 is incorrecly formatted. To get an idea if this is the case, try to put a breakpoint in line 127 or so. Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? This might also be the problem. Hope this helps a bit, Yours, Jan-Mathijs % try to read it using the CTF importer from the NIH and Daren Weber try tmp = ctf_read_res4(fileparts(headerfile), 0); ctferror = 0; % convert the header into a structure that FieldTrip understands hdr = []; hdr.Fs = tmp.setup.sample_rate; hdr.nChans = length(tmp.sensor.info); hdr.nSamples = tmp.setup.number_samples; hdr.nSamplesPre = tmp.setup.pretrigger_samples; hdr.nTrials = tmp.setup.number_trials; for i=1:length(tmp.sensor.info) hdr.label{i} = tmp.sensor.info(i).label; end hdr.label = hdr.label(:); % add a gradiometer structure for forward and inverse modelling hdr.grad = nimh2grad(tmp); % also store the original header, so that it can be reused by read_fcdc_data hdr.orig = tmp; catch ctferror = 1; end end if ctferror error('could not read CTF res4 header file'); end In the above section of codes, the hdr is redefined and then on line 151, the variable tmp is passed as an input argument for 'nimh2grad'. On line 22 of nimh2grad: sel = hdr.sensor.index.meg; now hdr is tmp (as tmp is the input argument). However, when I examined tmp after coming out of the function, I found that there isn't a field tmp.sensor.index.meg. Instead, I found things like the meg_left_central, meg_left_frontal, etc but just not 'meg'. Therefore, I think sel was assigned as an empty matrix and that implies length(sel)=0 and so the for loop starting from line 30 of 'nimh2grad.m' was not executed. I am not sure if you agree with my conclusion and if anything can be done about it. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 14:39 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Dear Hoi Fei On 9-aug-2005, at 15:05, Hoi Fei Kwok wrote: > This is the first time that I am using FieldTrip. Just like to ask > what > other software are needed besides MATLAB in order to run the > tutorials. I Some parts of the tutorials use CTF specific applications. That is commercial software only available to CTF MEG users. However, you can skip those parts of the tutorial. Furthermore, I think that there is a tutorial that refers to MRIcro, you can get that here: http:// www.psychology.nottingham.ac.uk/staff/cr1/mricro.html > have tried to run the tutorials after downloading and unzipping the > Subject01.zip but I ran into problems. > Firstly, in the Event Related Averaging tutorial, the > EventRelatedAveraging.m was mentioned but I could not find the file. you can copy and paste all matlab instructions from the pdf into the matlab command line window. I will also make the demo scripts available for download on the website, but I won't be able to do that immediately. > Secondly, after I created a cfg structure with 'Subject01.ds' as the > dataset and all the other field properties as instructed in the > tutorial, I > got the following error message when using the preprocessing.m: > > CTF_READ_RES4 [v 1.12] > ??? Error using ==> read_fcdc_header > could not read CTF res4 header file > > Error in ==> preprocessing at 219 > hdr = read_fcdc_header(cfg.headerfile); Are you at the right location with Matlab? I.e., if you type "pwd", does that correspond with the directory where Subject01.ds is located? best regards, Robert From r.oostenveld at FCDONDERS.RU.NL Tue Aug 9 20:57:05 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 9 Aug 2005 20:57:05 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59cf6$9e7d0b10$e516bc93@universi8ef8be> Message-ID: Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From h.f.kwok at BHAM.AC.UK Wed Aug 10 09:55:35 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 08:55:35 +0100 Subject: problems using fieldtrip In-Reply-To: Message-ID: Hi, When I typed "which ctf_read_res4" in Matlab, it returned: C:\Program Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01\ctf_read_res4.m Is it because of the EEGLab plugins that I installed previously then? Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 19:57 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From h.f.kwok at BHAM.AC.UK Wed Aug 10 09:57:45 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 08:57:45 +0100 Subject: problems using fieldtrip In-Reply-To: Message-ID: Hi, I've removed the EEGlab from the path and now the FieldTrip is working all right. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 09 August 2005 19:57 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei, On 9-aug-2005, at 17:25, Hoi Fei Kwok wrote: > I have checked and the ctf_read_res4 file is in the private > subdirectory and > I was at the same folder as the Subject01.ds. > > Are you sure that you have ctf_read_res4 in fieldtrip/private? It should not be there. The function "cft_read_res4" and "read_ctf_res4" are two different functions. The first one was written by Tom Holroyd and Darren Weber and is downloadable from eeg.sf.net (SourceForge), the second one originates from CTF and is included in Fieldtrip. CTF is not completely clear about the subformats of their res4 file type, and there seem to be some CTF datasets which can be read with one version of the routine and some datasets that can be read with the other. Therefore both functions are supported: if you have the function "ctf_read_res4" on your path, then that one will be used, otherwise the default "read_ctf_res4"" function that is supplied together with Fieldtrip will be used. Please type "which ctf_read_res4" in Matlab, it should return "not found" (also the other one should not be found, but that is because it is a private function). Fieldtrip will work on the demo data without the code from eeg.sf.net. best regards, Robert PS if it still does not work: change directory to "fieldtrip-xxx/ private" and from there try "hdr = read_ctf_res4(filename)" on the matlab command line, where filename contains the full path and filename of the res4 file (i.e. not the dataset directory, but really the complete path to the file itself. See also http://www2.ru.nl/ fcdonders/fieldtrip/1168.html for some related information on private functions. ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Wed Aug 10 09:58:27 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Wed, 10 Aug 2005 09:58:27 +0200 Subject: problems using fieldtrip In-Reply-To: <000401c59d80$e43ec1e0$e516bc93@universi8ef8be> Message-ID: Hi Hoi Fei On 10-aug-2005, at 9:55, Hoi Fei Kwok wrote: > When I typed "which ctf_read_res4" in Matlab, it returned: > C:\Program > Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01 > \ctf_read_res4.m > > Is it because of the EEGLab plugins that I installed previously then? > Yes, that might well be the problem. Please remove the EEGLAB directory from your matlab search path and try the tutorial again. Robert From h.f.kwok at BHAM.AC.UK Wed Aug 10 10:37:51 2005 From: h.f.kwok at BHAM.AC.UK (Hoi Fei Kwok) Date: Wed, 10 Aug 2005 09:37:51 +0100 Subject: problems using fieldtrip In-Reply-To: <596064D3-DD4C-4F24-A018-C7F65FC3B67D@fcdonders.ru.nl> Message-ID: Hi, On one hand, removing the EEGLAB solved the problem. On the other hand, the FieldTrip website mentioned about integrating the FieldTrip with the EEGLAB. So how should one go about that? Maybe the problem I encountered indicates that one should avoid certain EEGLAB plugins if one wants to use both the EEGLAB and FieldTrip. Regards, Hoi Fei -----Original Message----- From: FieldTrip discussion list [mailto:FIELDTRIP at NIC.SURFNET.NL] On Behalf Of Robert Oostenveld Sent: 10 August 2005 08:58 To: FIELDTRIP at NIC.SURFNET.NL Subject: Re: [FIELDTRIP] problems using fieldtrip Hi Hoi Fei On 10-aug-2005, at 9:55, Hoi Fei Kwok wrote: > When I typed "which ctf_read_res4" in Matlab, it returned: > C:\Program > Files\MATLAB704\eeglab\eeglab4.512\plugins\ctfimport1.01 > \ctf_read_res4.m > > Is it because of the EEGLab plugins that I installed previously then? > Yes, that might well be the problem. Please remove the EEGLAB directory from your matlab search path and try the tutorial again. Robert From r.oostenveld at FCDONDERS.RU.NL Wed Aug 10 12:03:50 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Wed, 10 Aug 2005 12:03:50 +0200 Subject: problems using fieldtrip In-Reply-To: <000001c59d86$cb7702c0$e516bc93@universi8ef8be> Message-ID: Hi, EEGLAB is (or will be in the near future) using the source localization features of Fieldtrip, i.e. it is one-way traffic. I expect that the reading of the data and processing of the data up to the point of the scalp maps will be done completely in EEGLAB, hence the problem that you now encountered (i.e. conflicting low-level data importers) will not pose an immediate problem for people who use it as intended. However, I also hope that once the integration gets into shape that also more low-level code will be shared between the two and then we might run into these problems more often. So it is good for us to hear about issues like these. Robert On 10-aug-2005, at 10:37, Hoi Fei Kwok wrote: > Hi, > > On one hand, removing the EEGLAB solved the problem. On the other > hand, the > FieldTrip website mentioned about integrating the FieldTrip with > the EEGLAB. > So how should one go about that? Maybe the problem I encountered > indicates > that one should avoid certain EEGLAB plugins if one wants to use > both the > EEGLAB and FieldTrip. > > Regards, > Hoi Fei > From sanja at UNM.EDU Thu Aug 11 22:52:12 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Thu, 11 Aug 2005 22:52:12 +0200 Subject: combineplanar Message-ID: Hello, I am trying to use meginterpolate/freqanalysis/combineplanar to get the tfr data in the planar gradiometer system, instead of the original 275 ch axial. However, combineplanar needs planarchannelset, but this function is not included in the 20050811 distribution. Could you include this function in the next distribution? I have a set of questions related to meginterpolate: Can CTF274.lay be used for ploting the planar data? Should I use a default single sphere model for each subject or a single sphere model particular for a subject for realignment? Should "nominal" sensor locations be used as a template for each subject, or do you recommend taking an average across subjects for the template? I appreciate your help, Sanja Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From holroydt at MAIL.NIH.GOV Thu Aug 11 23:26:41 2005 From: holroydt at MAIL.NIH.GOV (Tom Holroyd) Date: Thu, 11 Aug 2005 17:26:41 -0400 Subject: combineplanar In-Reply-To: Message-ID: Sanja Kovacevic wrote: > I have a set of questions related to meginterpolate: Can CTF274.lay be used > for ploting the planar data? I don't know the answer to your question, but I would like to note that CTF274.lay is based on the NIMH system which has one dead SQUID, namely MRF43. You might want to generate a CTF275.lay with that channel replaced. The meginterpolate code can actually "fix" dead channels anyway... > Should I use a default single sphere model for > each subject or a single sphere model particular for a subject for > realignment? Should "nominal" sensor locations be used as a template for > each subject, or do you recommend taking an average across subjects for the > template? Oh, as long as I'm here: Personally I wouldn't bother averaging across subjects, because even "aligned", averaging subjects together in sensor space is nearly meaningless. (Though an interesting project, by analogy to Talairach or MNI space, is to "warp" the sensor space data into a common space, based on "anatomical" landmarks such as the peaks of the AEF and/or SEF. I still wouldn't do that, though.) -- Dr. Tom Holroyd "A man of genius makes no mistakes. His errors are volitional and are the portals of discovery." -- James Joyce From ole.jensen at FCDONDERS.RU.NL Fri Aug 12 12:13:44 2005 From: ole.jensen at FCDONDERS.RU.NL (Ole Jensen) Date: Fri, 12 Aug 2005 12:13:44 +0200 Subject: averaging in sensor space In-Reply-To: <42FBC291.2070105@mail.nih.gov> Message-ID: Regarding the discussion on planar gradients and averaging over subjects: As Tom suggests it is always best to average over subjects in source space. However, sometimes we do not have high enough signal-to-noise in order to reliably identify the sources while we still observe consistent effects at the sensor level. I think it is an important discussion since it pertains to how we approach MEG data in general. Therefore I would like to provide an argument for why I believe it is sensible to average over subjects in sensor space: Say that a dataset has been analyzed in the frequency domain and we have representations of power for each sensor. I find it convenient to apply the combined planar gradient for power representations since this will tend to give the strongest power in sensors above the source. An axial gradient representation will result in two regions of strong power at each side of the source (i.e. where the fields exit and enter). We have had quite good luck averaging combined planar gradient power representations over subjects at the sensors level both with and without realignment. The FieldTrip has statistical methods implemented for dealing with the multiple comparison problem (multiple sensors). Also, for instance the group in Tuebingen has several publications were power (albeit using axial gradients) where they average over subjects at the sensor level. The approach is quite similar to that applied by the ERD/ERS community on EEG data. Note that differences in head size, position etc might diminish a given effect - however, I do not believe that averaging over subjects in sensor space will result in false positives. With respect to event related fields one should be very careful averaging the axial gradient over subjects at the sensor level. The orientation of sources from subject to subject might be different thus partially canceling a given effect. One solution is to calculate the RMS of the two orientations of the planar gradient and then average over subjects. This has for instance been done convincingly by the BRU/LTL Helsinki group in N400m studies. We have also good experiences with that approach at the Donders. The main disadvantage of averaging combined planar gradients of ERFs is that we loose information about source orientation. I would advice against doing source modeling on MEG data which has been averaged over subjects (this is often done for EEG data). Here it is appropriate to average either a current estimate of "beamformed" power estimate in source space after realigning the source representations to a standard brain. We are often using the following approach 1) Calculate time-frequency representations (TFRs) of power for planar gradients 2) Combined the planar gradient for each orientation 3) Average over subjects in sensors space 4) Use randomization statistics to identify clusters of difference 5) Use the beamformer to estimate power in source space for time and freq tiles identified in 4) in individual subjects 6) Morph the results of beamformed power to a standard brain 7) Average morphed power representations in source space Bests, Ole > Oh, as long as I'm here: > > Personally I wouldn't bother averaging across subjects, because even > "aligned", averaging subjects together in sensor space is nearly > meaningless. (Though an interesting project, by analogy to Talairach > or MNI space, is to "warp" the sensor space data into a common space, > based on "anatomical" landmarks such as the peaks of the AEF and/or > SEF. I still wouldn't do that, though.) > -- Ole Jensen Principal Investigator F.C. Donders Centre for Cognitive Neuroimaging P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Office : +31 24 36 10884 MEG lab : +31 24 36 10988 Fax : +31 24 36 10989 e-mail : ole.jensen at fcdonders.ru.nl URL : http://oase.uci.ru.nl/~olejen From r.oostenveld at FCDONDERS.RU.NL Fri Aug 12 14:02:20 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 12 Aug 2005 14:02:20 +0200 Subject: combineplanar In-Reply-To: Message-ID: Hi Sanja, On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: > I am trying to use meginterpolate/freqanalysis/combineplanar to get > the tfr > data in the planar gradiometer system, instead of the original 275 > ch axial. > However, combineplanar needs planarchannelset, but this function is > not > included in the 20050811 distribution. Could you include this > function in > the next distribution? Please find the function attached to this mail. I will add it to the next daily releases, sorry that it was missing. The attached version however does not include the 275ch CTF system yet, but it is easy to add. You basically only have to make a table with the planar channel labels that should be combined, and the name of the combined channel (i.e. the original name). I would appreciate it if you would send me the table information for the CTF 275 system, I will then update the release version as well. > I have a set of questions related to meginterpolate: Can CTF274.lay > be used > for ploting the planar data? Should I use a default single sphere > model for > each subject or a single sphere model particular for a subject for > realignment? Should "nominal" sensor locations be used as a > template for > each subject, or do you recommend taking an average across subjects > for the > template? Yes, but only for combineplanar'ed data in combination with topoplotTFR. It is conceptually not possible to make a topography of the "raw" planar data itself, but you can do a multiplotER and multiplotTFR of the planar data. However, that would require another lay file. The NM122all.lay file is one for the Neuromag system that plots the 122 planar channels at 66 locations, with horizontal and vertical channel next to each other. If you do not specify a layout in the cfg of multiplotTFR, the private subfunction createlayout will construct a layout on the fly based on the gradiometer positions. Usually the plotting is more controlled with a manually eddited layout file, but the automatic one can serve as starting point. Looking into the code, I now realise that there still are some loose ends. The megplanar function does not return the planar gadiometer definition. Please have a look at the private functions axial2planar and createlayout, and use them together to construct a planar layout file. best regards, Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: planarchannelset.m Type: application/octet-stream Size: 16045 bytes Desc: not available URL: From r.oostenveld at FCDONDERS.RU.NL Fri Aug 12 14:10:14 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 12 Aug 2005 14:10:14 +0200 Subject: averaging in sensor space In-Reply-To: <42FC7658.7060606@fcdonders.ru.nl> Message-ID: Hi guys, Just some additions to Ole's nice arguments... On 12-aug-2005, at 12:13, Ole Jensen wrote: > We are often using the following approach > 1) Calculate time-frequency representations (TFRs) of power for > planar gradients > 2) Combined the planar gradient for each orientation > 3) Average over subjects in sensors space > 4) Use randomization statistics to identify clusters of difference Prior to step 1, we would MEGREALIGN the raw data as obtained from preprocessing to a template helmet location (typically the average over all subjects in the study). That realigmnent reduces some variance in the averaging in step 3. After determining the time-frequency tile of interest (step 4), we go back to the original data as obtained from PREPROCESSING (i.e. prior to MEGREALIGN) and repeat FERQANALYSIS with settings (timewindow +frequency+multitapers) that are tuned to optimize the frequency estimate in that TF tile. And then we continue with > 5) Use the beamformer to estimate power in source space for time > and freq tiles identified in 4) in individual subjects > 6) Morph the results of beamformed power to a standard brain > 7) Average morphed power representations in source space best, Robert From sanja at UNM.EDU Fri Aug 12 17:01:09 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 12 Aug 2005 09:01:09 -0600 Subject: averaging in sensor space In-Reply-To: <42FC7658.7060606@fcdonders.ru.nl> Message-ID: On Fri, 12 Aug 2005 12:13:44 +0200 Ole Jensen wrote: > Regarding the discussion on planar gradients and >averaging over subjects: > > As Tom suggests it is always best to average over >subjects in source space. However, sometimes we do not >have high enough signal-to-noise in order to reliably >identify the sources while we still observe consistent >effects at the sensor level. I think it is an important >discussion since it pertains to how we approach MEG data >in general. Therefore I would like to provide an argument >for why I believe it is sensible to average over subjects >in sensor space: > > Say that a dataset has been analyzed in the frequency >domain and we have representations of power for each >sensor. I find it convenient to apply the combined planar >gradient for power representations since this will tend >to give the strongest power in sensors above the source. >An axial gradient representation will result in two >regions of strong power at each side of the source (i.e. >where the fields exit and enter). We have had quite good >luck averaging combined planar gradient power >representations over subjects at the sensors level both >with and without realignment. The FieldTrip has >statistical methods implemented for dealing with the >multiple comparison problem (multiple sensors). Also, for >instance the group in Tuebingen has several publications >were power (albeit using axial gradients) where they >average over subjects at the sensor level. The approach >is quite similar to that applied by the ERD/ERS community >on EEG data. Note that differences in head size, position >etc might diminish a given effect - however, I do not >believe that averaging over subjects in sensor space will >result in false positives. > > With respect to event related fields one should be very >careful averaging the axial gradient over subjects at the >sensor level. The orientation of sources from subject to >subject might be different thus partially canceling a >given effect. One solution is to calculate the RMS of the >two orientations of the planar gradient and then average >over subjects. This has for instance been done >convincingly by the BRU/LTL Helsinki group in N400m >studies. We have also good experiences with that approach >at the Donders. The main disadvantage of averaging >combined planar gradients of ERFs is that we loose >information about source orientation. > > I would advice against doing source modeling on MEG data >which has been averaged over subjects (this is often done >for EEG data). Here it is appropriate to average either a >current estimate of "beamformed" power estimate in source >space after realigning the source representations to a >standard brain. > > We are often using the following approach > > 1) Calculate time-frequency representations (TFRs) of >power for planar gradients > 2) Combined the planar gradient for each orientation > 3) Average over subjects in sensors space > 4) Use randomization statistics to identify clusters of >difference > 5) Use the beamformer to estimate power in source space >for time and freq tiles identified in 4) in individual >subjects > 6) Morph the results of beamformed power to a standard >brain > 7) Average morphed power representations in source space > > > Bests, > > Ole > > > > > > >> Oh, as long as I'm here: >> >> Personally I wouldn't bother averaging across subjects, >>because even >> "aligned", averaging subjects together in sensor space >>is nearly >> meaningless. (Though an interesting project, by analogy >>to Talairach >> or MNI space, is to "warp" the sensor space data into a >>common space, >> based on "anatomical" landmarks such as the peaks of the >>AEF and/or >> SEF. I still wouldn't do that, though.) >> > > > -- > Ole Jensen > Principal Investigator >F.C. Donders Centre for Cognitive Neuroimaging > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Office : +31 24 36 10884 > MEG lab : +31 24 36 10988 > >Fax : +31 24 36 10989 > > e-mail : ole.jensen at fcdonders.ru.nl > URL : http://oase.uci.ru.nl/~olejen Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From scrofa at GMAIL.COM Sun Aug 14 14:25:22 2005 From: scrofa at GMAIL.COM (Daniel Kislyuk) Date: Sun, 14 Aug 2005 15:25:22 +0300 Subject: importing 306-Vectorview dataset Message-ID: Hello! I'm trying to import neuromag data (with EEG) to fieldtrip using read_fcdc_header and read_fcdc_data routines, but i keep getting these error message: ---------------------------------------------------------------------------------- ??? Attempt to execute SCRIPT megmodel as a function. Error in ==> d:\danielk\fieldtrip\private\fif2grad.m On line 19 ==> megmodel('head',[0 0 0],filename); Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m On line 245 ==> hdr.grad = fif2grad(headerfile); ----------------------------------------------------------------------------------- Could you, please, help me? Thanks, Daniel From tnt at PHYSIOL.OX.AC.UK Sun Aug 14 16:53:26 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Sun, 14 Aug 2005 16:53:26 +0200 Subject: calculating frequency interaction Message-ID: Hi, I have a conceptual question which I'd like to post to the list. It has been the practice in multisensory research to define the integration of two inputs from different sensory modalities (e.g. auditory (A) and visual (V)) by calculating the interaction [AV - (A+V)], where AV is the simultaneous presentation of both unisensory stimuli. There, it is assumed that any non-linear summation denotes the interaction of the two sensory streams, and hence, is a measure of multisensory integration. For example, assume the following response profile A = 2 units V = 3 units AV = 6 units then the bimodal presentation AV cannot be predicted by the summation of the unimodal inputs alone, hence the difference is thought to be related to multisensory integration. This has been applied to both fMRI and ERP data (from MEG & EEG). (There are, of course, some confounds associated with this method, such as attention, etc, but that's a different matter.) I am interested in how this interaction effect can be calculated with frequency data. Frequency power estimates are done by squaring the amplitude of the bandpassed response, so there is already a "non-linear" step involved in the process. Calculating the interaction as above could then result in erroneous estimates of the integration effect: A = 4 units V = 9 units AV = 36 units From tnt at PHYSIOL.OX.AC.UK Sun Aug 14 17:05:18 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Sun, 14 Aug 2005 17:05:18 +0200 Subject: calculating frequency interaction (now with the complete message) Message-ID: SORRY, I send the last message too early by mistake. Please find the whole text below T. == Hi, I have a conceptual question which I'd like to post to the list. It has been the practice in multisensory research to define the integration of two inputs from different sensory modalities (e.g. auditory (A) and visual (V)) by calculating the interaction [AV - (A+V)], where AV is the simultaneous presentation of both unisensory stimuli. There, it is assumed that any non-linear summation denotes the interaction of the two sensory streams, and hence, is a measure of multisensory integration. For example, assume the following response profile A = 2 units V = 3 units AV = 6 units integration effect = 6-(2+3)= 1 Here, the response to the bimodal presentation AV cannot be predicted by the summation of the unimodal inputs alone, hence the difference is thought to be related to multisensory integration. This has been applied to both fMRI and ERP data (from MEG & EEG). (There are, of course, some confounds associated with this method, such as attention, etc, but that's a different matter.) I am interested in how this interaction effect can be calculated with frequency data. Frequency power estimates are done by squaring the amplitude of the bandpassed response, so there is already a "non-linear" step involved in the process. Calculating the interaction as above could then result in erroneous estimates of the integration effect: A = 3 units; squared = 9 V = 3 units; squared = 9 AV = 6 units; squared = 36 integration effect = 6^2-(3^2+3^2) = 18 even though it is quite evident that the neuronal response to AV is a direct summation of A and V. Any suggestions on how to solve this problem would be greatly appreciated. Thomas From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 09:33:48 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 09:33:48 +0200 Subject: importing 306-Vectorview dataset In-Reply-To: <489aa9f90508140525ff5f78c@mail.gmail.com> Message-ID: Hi Daniel, Did you download and install the MEG-PD toolbox (see http:// www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an extra shared library that is missing in the meg-pd tgz file, see http://oase.uci.kun.nl/~roberto/index.php/neuromag/. Fieldtrip does not support the Neuromag *.fif file format natively, since it is a closed file format. However, Fieldtrip can use the MEG- PD toolbox. What is does is to call the appropriate functions from the MEG-PD toolbox, and to reformat their output into a format that all Fieldtrip functions can handle. The "megmodel" function is a function from the MEG-PD toolbox. This MEG-PD toolbox contains mex files, and they are only provided for linux and HPUX. That means that you cannot read Neuromag data in Matlab under Windows. Besides the mex files (i.e. a file named megmodel.mexglx), there are documentation files (i.e. megmodel.m). These documentation files contain only help and cannot be executed. I suspect that the mex file is missing in your installation. Please type "which megmodel" and check whether it is the mexglx or the m file. best regards Robert On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > Hello! > > I'm trying to import neuromag data (with EEG) to fieldtrip using > read_fcdc_header and read_fcdc_data routines, but i keep getting these > error message: > > ---------------------------------------------------------------------- > ------------ > ??? Attempt to execute SCRIPT megmodel as a function. > > Error in ==> d:\danielk\fieldtrip\private\fif2grad.m > On line 19 ==> megmodel('head',[0 0 0],filename); > > Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m > On line 245 ==> hdr.grad = fif2grad(headerfile); > ---------------------------------------------------------------------- > ------------- > > Could you, please, help me? > > Thanks, > Daniel > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 09:55:20 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 09:55:20 +0200 Subject: calculating frequency interaction (now with the complete message) In-Reply-To: Message-ID: Hi Thomas, On 14-aug-2005, at 17:05, Thomas Thesen wrote: > Calculating the interaction as above could then result in erroneous > estimates of the integration effect: > > A = 3 units; squared = 9 > V = 3 units; squared = 9 > AV = 6 units; squared = 36 > > integration effect = 6^2-(3^2+3^2) = 18 > > even though it is quite evident that the neuronal response to AV is > a direct > summation of A and V. > The effect of summation of the two signals on the estimated power (or amplitude) of their sum depends on the phase relation between the two signals. 1) If the two signals are in perfect phase alignment in each trial (i.e. zero deg phase difference), they will add up as you described. 2) If they are in perfect antiphase (180 deg), they will cancel out. 3) If they have a random phase with respect to each other, i.e. the phase difference is different in each trial, they will add up "a little". In case 1, the amplitude (i.e. sqrt of the power) depends linearly on the amplitude of the two signals. In case 3, the power depends linearly on the power of the two signals. Please try playing with the following lines of code real_pow1 = 3; real_pow2 = 3; t = linspace(0, 2*pi, 1000); for trl=1:100 s1(trl,:) = sqrt(real_pow1)*sqrt(2)*sin(t); phasediff = 2*pi*rand(size(t)); % CHANGE THIS TO SEE THE EFFECT s2(trl,:) = sqrt(real_pow2)*sqrt(2)*sin(t + phasediff); end % add the two signals for each trial s3 = s1+s2; % estimate the single trial power pow_s1 = sum(s1.^2,2)/length(t); pow_s2 = sum(s2.^2,2)/length(t); pow_s3 = sum(s3.^2,2)/length(t); % estimate the power and amplitude pow1 = sum(pow_s1)./100 pow2 = sum(pow_s2)./100 pow3 = sum(pow_s3)./100 ampl1 = sqrt(pow1) ampl2 = sqrt(pow2) ampl3 = sqrt(pow3) I hope that this clarifies it. Of course, it does not yet help you deciding how to test for the interaction, since the additive effect (which you expect under the null hypothesis) can be either on amplitude or on power. To choose the right test, you will have to consider the sources of the two signals that are being mixed on the channel level, i.e. are they coming from one source, or from two sources, and in the latter case, are the two sources strongly coherent or not? best regards, Robert ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From D.Talsma at PSY.VU.NL Mon Aug 15 13:34:04 2005 From: D.Talsma at PSY.VU.NL (Talsma D) Date: Mon, 15 Aug 2005 13:34:04 +0200 Subject: Differences in channel numbers and MEG Interpolate Message-ID: Hi Fieldtrippers, I have the following question regarding meginterpolate: Is it possible to use MEG interpolate to add a channel to the dataset that was never recorded in the first place? I have data from a limited number of subjects that is recorded with one channel (MLO21) less (149 channels) than the data from the other subjects (150 MEG channels). From what I can tell, this is not a channel that is just marked as 'Bad', but one that was never recorded in the first place. I tried interpolating this channel using meginterpolate, but after this procedure, I still have a dataset with 149 channels. Below are the settings I used. Needless to say, I tried various variations, but none appeared to work. For now, I'm going to try and remove the offending channel from the remaining subjects that were recorded with 150 channels. Thanks in advance, Durk templatefile = { 'pp01/corr-resp.ds', 'pp01/incor-resp.ds', 'pp02/corr-resp.ds', 'pp02/incor-resp.ds', 'pp03/corr-resp.ds', 'pp03/incor-resp.ds', 'pp04/corr-resp.ds', 'pp04/incor-resp.ds', 'pp06/corr-resp.ds', 'pp06/incor-resp.ds', 'pp09/corr-resp.ds', 'pp09/incor-resp.ds', 'pp10/corr-resp.ds', 'pp10/incor-resp.ds', 'pp11/corr-resp.ds', 'pp11/incor-resp.ds', 'pp12/corr-resp.ds', 'pp12/incor-resp.ds', 'pp13/corr-resp.ds', 'pp13/incor-resp.ds', 'pp14/corr-resp.ds', 'pp14/incor-resp.ds', 'pp15/corr-resp.ds', 'pp15/incor-resp.ds' }; cfgrepair = []; cfgrepair.repair = 'yes'; cfgrepair.realign = 'no'; cfgrepair.planar = 'no'; cfgrepair.template =templatefile; cfgrepair.hdmfile ='standard.hdm'; cfgrepair.badchannel = {'MLO21'}; dataCor_corrected = meginterpolate(cfgrepair, dataCor); dataInc_corrected = meginterpolate(cfgrepair, dataInc); From r.oostenveld at FCDONDERS.RU.NL Mon Aug 15 13:55:44 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Mon, 15 Aug 2005 13:55:44 +0200 Subject: Differences in channel numbers and MEG Interpolate In-Reply-To: Message-ID: Hi Durk, No, that is not possible. Megrepair will only interpolate an existing channel (using nearest neighbours). What you can do is to manually add the channel to your preprocessed dataset. E.g. cfg = ... raw = preprocessing(cfg); raw.label{end+1} = 'MLO21'; for i=1:length(data.trial) data.trial{i}(end+1,:) = 0; end Btw. I suggest to call MERREPAIR, MEGREALIGN and MEGPLANAR seperately and not use the MEGINTERPOLATE (in the old days, there was this one function, but that was split up into its logical components). best, Robert On 15-aug-2005, at 13:34, Talsma D wrote: > Hi Fieldtrippers, > > I have the following question regarding meginterpolate: Is it possible > to use MEG interpolate to add a channel to the dataset that was never > recorded in the first place? I have data from a limited number of > subjects that is recorded with one channel (MLO21) less (149 channels) > than the data from the other subjects (150 MEG channels). From what I > can tell, this is not a channel that is just marked as 'Bad', but one > that was never recorded in the first place. I tried interpolating this > channel using meginterpolate, but after this procedure, I still have a > dataset with 149 channels. Below are the settings I used. Needless to > say, I tried various variations, but none appeared to work. > > For now, I'm going to try and remove the offending channel from the > remaining subjects that were recorded with 150 channels. > > Thanks in advance, > Durk > > > templatefile = { 'pp01/corr-resp.ds', > 'pp01/incor-resp.ds', > 'pp02/corr-resp.ds', > 'pp02/incor-resp.ds', > 'pp03/corr-resp.ds', > 'pp03/incor-resp.ds', > 'pp04/corr-resp.ds', > 'pp04/incor-resp.ds', > 'pp06/corr-resp.ds', > 'pp06/incor-resp.ds', > 'pp09/corr-resp.ds', > 'pp09/incor-resp.ds', > 'pp10/corr-resp.ds', > 'pp10/incor-resp.ds', > 'pp11/corr-resp.ds', > 'pp11/incor-resp.ds', > 'pp12/corr-resp.ds', > 'pp12/incor-resp.ds', > 'pp13/corr-resp.ds', > 'pp13/incor-resp.ds', > 'pp14/corr-resp.ds', > 'pp14/incor-resp.ds', > 'pp15/corr-resp.ds', > 'pp15/incor-resp.ds' > }; > > cfgrepair = []; > cfgrepair.repair = 'yes'; > cfgrepair.realign = 'no'; > cfgrepair.planar = 'no'; > cfgrepair.template =templatefile; > cfgrepair.hdmfile ='standard.hdm'; > cfgrepair.badchannel = {'MLO21'}; > > dataCor_corrected = meginterpolate(cfgrepair, dataCor); > dataInc_corrected = meginterpolate(cfgrepair, dataInc); > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From jhouck at UNM.EDU Mon Aug 15 19:17:33 2005 From: jhouck at UNM.EDU (Jon Houck) Date: Mon, 15 Aug 2005 11:17:33 -0600 Subject: importing 306-Vectorview dataset Message-ID: Hello, Kimmo has a partial Windows version of the MEG-PD toolbox posted on his site now. I've used it successfully with 306-channel data in the old 4D Toolbox, but haven't tested it with Fieldtrip yet. It may be of some use here. Regards, Jon Houck ----- Original Message ----- From: "Robert Oostenveld" To: Sent: Monday, August 15, 2005 1:33 AM Subject: Re: [FIELDTRIP] importing 306-Vectorview dataset > Hi Daniel, > > Did you download and install the MEG-PD toolbox (see http:// > www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an > extra shared library that is missing in the meg-pd tgz file, see > http://oase.uci.kun.nl/~roberto/index.php/neuromag/. > > Fieldtrip does not support the Neuromag *.fif file format natively, > since it is a closed file format. However, Fieldtrip can use the MEG- > PD toolbox. What is does is to call the appropriate functions from > the MEG-PD toolbox, and to reformat their output into a format that > all Fieldtrip functions can handle. The "megmodel" function is a > function from the MEG-PD toolbox. This MEG-PD toolbox contains mex > files, and they are only provided for linux and HPUX. That means that > you cannot read Neuromag data in Matlab under Windows. Besides the > mex files (i.e. a file named megmodel.mexglx), there are > documentation files (i.e. megmodel.m). These documentation files > contain only help and cannot be executed. I suspect that the mex file > is missing in your installation. Please type "which megmodel" and > check whether it is the mexglx or the m file. > > best regards > Robert > > > > > On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > > > Hello! > > > > I'm trying to import neuromag data (with EEG) to fieldtrip using > > read_fcdc_header and read_fcdc_data routines, but i keep getting these > > error message: > > > > ---------------------------------------------------------------------- > > ------------ > > ??? Attempt to execute SCRIPT megmodel as a function. > > > > Error in ==> d:\danielk\fieldtrip\private\fif2grad.m > > On line 19 ==> megmodel('head',[0 0 0],filename); > > > > Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m > > On line 245 ==> hdr.grad = fif2grad(headerfile); > > ---------------------------------------------------------------------- > > ------------- > > > > Could you, please, help me? > > > > Thanks, > > Daniel > > > > > > ======================================================= > Robert Oostenveld, PhD > F.C. Donders Centre for Cognitive Neuroimaging > Radboud University Nijmegen > phone: +31-24-3619695 > http://www.ru.nl/fcdonders/ > From lauri at NEURO.HUT.FI Mon Aug 15 21:43:58 2005 From: lauri at NEURO.HUT.FI (Lauri Parkkonen) Date: Mon, 15 Aug 2005 22:43:58 +0300 Subject: importing 306-Vectorview dataset In-Reply-To: <5757A7A1-9C27-4487-8906-6FD1603C53C4@fcdonders.ru.nl> Message-ID: Hi Daniel and other Fieldtrippers, To read the Neuromag files into Fieldtrip/Matlab you need Kimmo Uutela's FiffAccess (aka meg-pd) package, available for Linux, HPUX and Windows as Robert and Jon pointed out. The packages do contain the required shared library, however, you need to tell the Linux dynamic linker where to find this library before starting Matlab (see the FiffAccess manual/Installation instructions). This step is often forgotten so I wrote here some instructions (assuming you're running Linux). You have two options to tell the system where to look for the new library: 1) User-specific configuration: Set the environment variable LD_LIBRARY_PATH to point to the library directory before starting Matlab: - sh/bash users export LD_LIBRARY_PATH /opt/neuromag/lib/i586-pc-linux-gnu - tcsh/csh users setenv LD_LIBRARY_PATH /opt/neuromag/lib/i586-pc-linux-gnu (there are some inconsistencies whether the architecture is i586-... or i686-...; please check in which one you actually find the library file after installing the FiffAccess package and substitute accordingly) 2) System-wide configuration: As the root user, add the line /opt/neuromag/lib/i586-pc-linux-gnu to /etc/ld.so.conf (or - in some Linux distros - make a file containing that line and put the file under /etc/ld.so.conf.d) and run /sbin/ldconfig. With both options, you can check if the shared lib is found correctly by saying ldd /opt/neuromag/meg_pd_1.2/megmodel.mexglx which should print out something like: linux-gate.so.1 => (0x00d02000) libmagnet_pdg_1.2.so => /opt/neuromag/lib/i586-pc-linux-gnu/libmagnet_pdg_1.2.so (0x00beb000) libmx.so => not found libmex.so => not found libmat.so => not found libm.so.6 => /lib/libm.so.6 (0x0051e000) libc.so.6 => /lib/libc.so.6 (0x003ba000) /lib/ld-linux.so.2 (0x0027b000) Don't worry about libmx, libmex and libmat not being found; they'll be linked correctly by Matlab. Hope this helps you to get the Neuromag file import working. Best regards, Lauri Robert Oostenveld wrote: > Hi Daniel, > > Did you download and install the MEG-PD toolbox (see http:// > www.kolumbus.fi/kuutela/programs/meg-pd/)? You might also need an > extra shared library that is missing in the meg-pd tgz file, see > http://oase.uci.kun.nl/~roberto/index.php/neuromag/. > > Fieldtrip does not support the Neuromag *.fif file format natively, > since it is a closed file format. However, Fieldtrip can use the MEG- > PD toolbox. What is does is to call the appropriate functions from > the MEG-PD toolbox, and to reformat their output into a format that > all Fieldtrip functions can handle. The "megmodel" function is a > function from the MEG-PD toolbox. This MEG-PD toolbox contains mex > files, and they are only provided for linux and HPUX. That means that > you cannot read Neuromag data in Matlab under Windows. Besides the > mex files (i.e. a file named megmodel.mexglx), there are > documentation files (i.e. megmodel.m). These documentation files > contain only help and cannot be executed. I suspect that the mex file > is missing in your installation. Please type "which megmodel" and > check whether it is the mexglx or the m file. > > best regards > Robert > > > > > On 14-aug-2005, at 14:25, Daniel Kislyuk wrote: > >> Hello! >> >> I'm trying to import neuromag data (with EEG) to fieldtrip using >> read_fcdc_header and read_fcdc_data routines, but i keep getting these >> error message: >> >> ---------------------------------------------------------------------- >> ------------ >> ??? Attempt to execute SCRIPT megmodel as a function. >> >> Error in ==> d:\danielk\fieldtrip\private\fif2grad.m >> On line 19 ==> megmodel('head',[0 0 0],filename); >> >> Error in ==> d:\danielk\fieldtrip\read_fcdc_header.m >> On line 245 ==> hdr.grad = fif2grad(headerfile); >> ---------------------------------------------------------------------- >> ------------- >> >> Could you, please, help me? >> >> Thanks, >> Daniel >> >> > > ======================================================= > Robert Oostenveld, PhD > F.C. Donders Centre for Cognitive Neuroimaging > Radboud University Nijmegen > phone: +31-24-3619695 > http://www.ru.nl/fcdonders/ -- ----------------------------------------------- Lauri Parkkonen Brain Research Unit, Low Temperature Laboratory Helsinki University of Technology Otakaari 3 A, 02150 ESPOO, FINLAND tel: +358-9-4512965 fax: +358-9-4512969 mailto:lauri at neuro.hut.fi http://boojum.hut.fi From tnt at PHYSIOL.OX.AC.UK Mon Aug 15 23:41:55 2005 From: tnt at PHYSIOL.OX.AC.UK (Thomas Thesen) Date: Mon, 15 Aug 2005 23:41:55 +0200 Subject: calculating frequency interaction (now with the complete message) Message-ID: Hi Rob, Thanks for the simulation. That really helped to make the issue clear! If others are interested to see how the phase relationship between two signals relates to the linearity or non-linearity of the summed power or amplitudes can have a look at these figures that were derived from Robs code below: http://www.physiol.ox.ac.uk/~tnt/fieldtrip/ FT_phase1.jpg FT_phase2.jpg One example shows perfect phase and one anti-phase. The bottom graph shows the phase relationship of the signals for condition A and V, and their sum A+V. In the code that's s1 to s3. The top graphs show the values for amplitude (ampl1 to ampl3) and power (pow1 to pow3). Diff is the subtraction of pow3-pow2-pow1 (or the same foe amp). If diff is zero the summation is linear. Rob, your comments regarding the appropriate approach for testing the interaction are very insightful. Thank you. Considering that MEG/EEG data contain a lot from both of these options it seems unwise to do this type of testing. One couldn't tell wether a different phase relationship or a true effect might be responsible for non-linear summation. Or am I wrong there? I just saw at a conference a poster where they tried the same thing using bootstrapping. The web link above contains a copy of that poster "Senkowski...jpg". What do you think about this approach? Could that be done using FieldTrip? Thanks a lot, Thomas On Mon, 15 Aug 2005 09:55:20 +0200, Robert Oostenveld wrote: >Hi Thomas, > >On 14-aug-2005, at 17:05, Thomas Thesen wrote: > > >> Calculating the interaction as above could then result in erroneous >> estimates of the integration effect: >> >> A = 3 units; squared = 9 >> V = 3 units; squared = 9 >> AV = 6 units; squared = 36 >> >> integration effect = 6^2-(3^2+3^2) = 18 >> >> even though it is quite evident that the neuronal response to AV is >> a direct >> summation of A and V. >> > >The effect of summation of the two signals on the estimated power (or >amplitude) of their sum depends on the phase relation between the two >signals. >1) If the two signals are in perfect phase alignment in each trial >(i.e. zero deg phase difference), they will add up as you described. >2) If they are in perfect antiphase (180 deg), they will cancel out. >3) If they have a random phase with respect to each other, i.e. the >phase difference is different in each trial, they will add up "a >little". >In case 1, the amplitude (i.e. sqrt of the power) depends linearly on >the amplitude of the two signals. In case 3, the power depends >linearly on the power of the two signals. > >Please try playing with the following lines of code > >real_pow1 = 3; >real_pow2 = 3; >t = linspace(0, 2*pi, 1000); > >for trl=1:100 > s1(trl,:) = sqrt(real_pow1)*sqrt(2)*sin(t); > phasediff = 2*pi*rand(size(t)); % CHANGE THIS TO SEE THE EFFECT > s2(trl,:) = sqrt(real_pow2)*sqrt(2)*sin(t + phasediff); >end > >% add the two signals for each trial >s3 = s1+s2; > >% estimate the single trial power >pow_s1 = sum(s1.^2,2)/length(t); >pow_s2 = sum(s2.^2,2)/length(t); >pow_s3 = sum(s3.^2,2)/length(t); > >% estimate the power and amplitude >pow1 = sum(pow_s1)./100 >pow2 = sum(pow_s2)./100 >pow3 = sum(pow_s3)./100 > >ampl1 = sqrt(pow1) >ampl2 = sqrt(pow2) >ampl3 = sqrt(pow3) > >I hope that this clarifies it. Of course, it does not yet help you >deciding how to test for the interaction, since the additive effect >(which you expect under the null hypothesis) can be either on >amplitude or on power. To choose the right test, you will have to >consider the sources of the two signals that are being mixed on the >channel level, i.e. are they coming from one source, or from two >sources, and in the latter case, are the two sources strongly >coherent or not? > >best regards, >Robert > > >======================================================= >Robert Oostenveld, PhD >F.C. Donders Centre for Cognitive Neuroimaging >Radboud University Nijmegen >phone: +31-24-3619695 >http://www.ru.nl/fcdonders/ From r.oostenveld at FCDONDERS.RU.NL Tue Aug 16 09:29:07 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Tue, 16 Aug 2005 09:29:07 +0200 Subject: calculating frequency interaction (now with the complete message) In-Reply-To: Message-ID: Hi Thomas, On 15-aug-2005, at 23:41, Thomas Thesen wrote: > Rob, your comments regarding the appropriate approach for testing the > interaction are very insightful. Thank you. Considering that MEG/ > EEG data > contain a lot from both of these options it seems unwise to do this > type of > testing. One couldn't tell wether a different phase relationship or > a true > effect might be responsible for non-linear summation. Or am I wrong > there? You always assume the null-hypothesis to be true, which means no effects and no coherences. Then you test the probability of observing your data under this hypothesis. If that is unlikely, you conclude that the null-hypothesis does not apply. Therefore, knowing that there are all sorts of complex dynamics in the brain does not harm the correctness of your inference based on the statistical test, since the test is based on the absence of the effect. Of course you should be carefull and explicit in phrasing your null-hypothesis, my phrasing here is too vague to operationalize it. > I just saw at a conference a poster where they tried the same thing > using > bootstrapping. The web link above contains a copy of that poster > "Senkowski...jpg". What do you think about this approach? Could > that be done > using FieldTrip? The approach could in theory be done in Fieldtrip without too much additional programming effort. It slightly resembles the statistical test based on randomization theory that is implemented in clusterrandanalysis (also see http://www2.ru.nl/fcdonders/fieldtrip/ uploads/media/RandBioTheory.pdf). However, the test suggested by Senkowski on the poster that you sent is not very clear in the hypothesis that is being tested. They focus on the sensitivity of the test, but not on the validity of rejecting the null hypothesis. I would rephrase their approach: they assume that the AV trials originate from the same (unknown) distribution as the manually crafted A+V trials. They have created NA times NV of these N+V trials (i.e. each possible combination) and randomly draw subsets from this A +V distribution with the same number of trials as they have in their AV average. The error that they make is that they do not consider the noise that is present in the measurement. In the absence of any signal of interest in the EEG, you still would have (electrode) noise. That noise is present in the AV condition, in the A condition and in the V condition. If you add an A trial with a V trial, the noise will add. Since noise here is assumed to be uncorrelated over trials, the noise in A+V will be sqrt(2) times the noise in either A or V allone. But the noise in AV is similar as that in either A or V (since they are all raw trials from the recorded data), hence the noise in their A+V trial is sqrt(2) times the noise in the AV trial. Therefore I conclude that there is a trivial difference between the data, irrespective of the true underlying difference, which results in a systematic overestimation of the A+V power with respect to the AV power. In their case, the more noise their signals contain, the more likely it is that they will reject the hypothesis that the A+V and the AV trials originate from the same distribution. Their incorrect alternative hypothesis is subadditivity, i.e. the AV condition has less power than the A+V condition. best regards, Robert From morier8 at ETU.UNIGE.CH Wed Aug 17 12:43:14 2005 From: morier8 at ETU.UNIGE.CH (patrice) Date: Wed, 17 Aug 2005 12:43:14 +0200 Subject: immediate 3D plot Message-ID: Hi all, I would like to make a graphical plot of my data with fieldtrip. No frequency analysis, no averaging, no filtering or whatever, only a simple plot to display the active regions in the brain. My data (EEG) are stored in a 2D matrix (voxels x time-points). My voxels are distributed in the whole brain (not only on the scalp). Furthermore, I have a file that contains the 3D coordinates of my voxels (X,Y and Z) and an header file associated to the used model. Is it feasible with fieldtrip? If yes, do you have any idea to achieve this? Any suggestion would be helpful. Regards, patrice From r.oostenveld at FCDONDERS.RU.NL Fri Aug 19 15:41:38 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Fri, 19 Aug 2005 15:41:38 +0200 Subject: immediate 3D plot In-Reply-To: Message-ID: Hi Patrice On 17-aug-2005, at 12:43, patrice wrote: > I would like to make a graphical plot of my data with fieldtrip. No > frequency analysis, no averaging, no filtering or whatever, only a > simple > plot to display the active regions in the brain. I guess that means that you want to plot the potential that you have recorded at each electrode site? > My data (EEG) are stored in a 2D matrix (voxels x time-points). My > voxels > are distributed in the whole brain (not only on the scalp). Does that mean that you have depth electrodes? Or did you do a source reconstrucion of your EEG in some external software? > Furthermore, I have a file that contains the 3D coordinates of my > voxels (X,Y and Z) > and an header file associated to the used model. Is it feasible > with fieldtrip? If > yes, do you have any idea to achieve this? Is it a regular arrangement, i.e. do the voxels form a box-like volume? If so, then you can "massage" the data into fieldtrip as a sourcereconstruction and use the sourceinterpolate function. However, since you have recorded it at many samples (timepoints), that means that a graphical representation of that data would consist of a 3D volume with an additional time dimension, i.e. the data is 4D. Hence, it would be a movie in which you can show a single cross- section (slice) through the brain at a time. Such a movie can be made in Matlab, but fieldtrip would not be of many use for you. Robert From sanja at UNM.EDU Fri Aug 19 19:42:21 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 19 Aug 2005 11:42:21 -0600 Subject: source projection In-Reply-To: <8182F211-66DD-4AFC-8E9D-472F041233EF@fcdonders.ru.nl> Message-ID: Hi Robert, I've tried using megrealign and megplanar with the CTF 275 ch data, however I run into problems with source projection. First, for megrealign there was a warning about the higher order synthetic gradiometer configuration. Nevertheless, megrealign ran, but after freqanalysis the resulting tfr values for several channels were much higher (3 orders of magnitude) than for the rest of the channels (which was not the case for the original not realigned data). Second, megplanar stopped running with "the forward model does not look like EEG, nor like MEG" error. I've saved the CTF data with the 3rd order noise cancellation on (via newDs -filter) and then read these noise canceled data into fieldtrip. However, I've only read in MEG and STIM channels, I haven't read in the reference channels. Do you have any thoughts on what might be going on? I appreciate your help, Sanja On Fri, 12 Aug 2005 14:02:20 +0200 Robert Oostenveld wrote: > Hi Sanja, > > On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: >> I am trying to use >>meginterpolate/freqanalysis/combineplanar to get >> the tfr >> data in the planar gradiometer system, instead of the >>original 275 >> ch axial. >> However, combineplanar needs planarchannelset, but this >>function is >> not >> included in the 20050811 distribution. Could you include >>this >> function in >> the next distribution? > > Please find the function attached to this mail. I will >add it to the next daily releases, sorry that it was >missing. > > The attached version however does not include the 275ch >CTF system yet, but it is easy to add. You basically >only have to make a table with the planar channel labels >that should be combined, and the name of the combined >channel (i.e. the original name). I would appreciate it >if you would send me the table information for the CTF >275 system, I will then update the release version as >well. > >> I have a set of questions related to meginterpolate: Can >>CTF274.lay >> be used >> for ploting the planar data? Should I use a default >>single sphere >> model for >> each subject or a single sphere model particular for a >>subject for >> realignment? Should "nominal" sensor locations be used >>as a >> template for >> each subject, or do you recommend taking an average >>across subjects >> for the >> template? > > Yes, but only for combineplanar'ed data in combination >with topoplotTFR. It is conceptually not possible to >make a topography of the "raw" planar data itself, but >you can do a multiplotER and multiplotTFR of the planar >data. However, that would require another lay file. The >NM122all.lay file is one for the Neuromag system that > plots the 122 planar channels at 66 locations, with >horizontal and vertical channel next to each other. > > If you do not specify a layout in the cfg of >multiplotTFR, the private subfunction createlayout will >construct a layout on the fly based on the gradiometer >positions. Usually the plotting is more controlled with >a manually eddited layout file, but the automatic one > can serve as starting point. Looking into the code, I >now realise that there still are some loose ends. The >megplanar function does not return the planar gadiometer >definition. Please have a look at the private functions >axial2planar and createlayout, and use them together to >construct a planar layout file. > > best regards, > Robert From sanja at UNM.EDU Fri Aug 19 23:43:42 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Fri, 19 Aug 2005 15:43:42 -0600 Subject: source projection In-Reply-To: Message-ID: Oh, I forgot to mention that I used meplanar with the source projection option. I tracked the problem down to axial2planar (line 309 of megplanar: planar.grad = axial2planar([], axial.grad)). Axial2planar does not return the field "type" in planar.grad, and therefore compute_leadfield could not recognize the sensor type and gives "the forward model does not look like EEG, nor like MEG" error. -Sanja On Fri, 19 Aug 2005 11:42:21 -0600 Sanja Kovacevic wrote: > Hi Robert, > > I've tried using megrealign and megplanar with the CTF >275 ch data, however I run into problems with source >projection. First, for megrealign there was a warning >about the higher order synthetic gradiometer >configuration. Nevertheless, megrealign ran, but after >freqanalysis the resulting tfr values for several >channels were much higher (3 orders of magnitude) than >for the rest of the channels (which was not the case for >the original not realigned data). Second, megplanar >stopped running with "the forward model does not look >like EEG, nor like MEG" error. I've saved the CTF data >with the 3rd order noise cancellation on (via newDs >-filter) and then read these noise canceled data into >fieldtrip. However, I've only read in MEG and STIM >channels, I haven't read in the reference channels. Do >you have any thoughts on what might be going on? > > I appreciate your help, > > Sanja > > > On Fri, 12 Aug 2005 14:02:20 +0200 > Robert Oostenveld wrote: >> Hi Sanja, >> >> On 11-aug-2005, at 22:52, Sanja Kovacevic wrote: >>> I am trying to use >>>meginterpolate/freqanalysis/combineplanar to get >>> the tfr >>> data in the planar gradiometer system, instead of the >>>original 275 >>> ch axial. >>> However, combineplanar needs planarchannelset, but this >>>function is >>> not >>> included in the 20050811 distribution. Could you include >>>this >>> function in >>> the next distribution? >> >> Please find the function attached to this mail. I will >>add it to the next daily releases, sorry that it was >>missing. >> >> The attached version however does not include the 275ch >>CTF system yet, but it is easy to add. You basically >>only have to make a table with the planar channel labels >>that should be combined, and the name of the combined >>channel (i.e. the original name). I would appreciate it >>if you would send me the table information for the CTF >>275 system, I will then update the release version as >>well. >> >>> I have a set of questions related to meginterpolate: Can >>>CTF274.lay >>> be used >>> for ploting the planar data? Should I use a default >>>single sphere >>> model for >>> each subject or a single sphere model particular for a >>>subject for >>> realignment? Should "nominal" sensor locations be used >>>as a >>> template for >>> each subject, or do you recommend taking an average >>>across subjects >>> for the >>> template? >> >> Yes, but only for combineplanar'ed data in combination >>with topoplotTFR. It is conceptually not possible to >>make a topography of the "raw" planar data itself, but >>you can do a multiplotER and multiplotTFR of the planar >>data. However, that would require another lay file. The >>NM122all.lay file is one for the Neuromag system that >>plots the 122 planar channels at 66 locations, with >>horizontal and vertical channel next to each other. >> >> If you do not specify a layout in the cfg of >>multiplotTFR, the private subfunction createlayout will >>construct a layout on the fly based on the gradiometer >>positions. Usually the plotting is more controlled with >>a manually eddited layout file, but the automatic one can >>serve as starting point. Looking into the code, I >>now realise that there still are some loose ends. The >>megplanar function does not return the planar gadiometer >>definition. Please have a look at the private functions >>axial2planar and createlayout, and use them together to >>construct a planar layout file. >> >> best regards, >> Robert Sanja Kovacevic Research Assistant MIND Imaging Center Albuquerque, New Mexico, USA Phone: +1 (505) 272 3327 Fax: +1 (505) 272 4056 From r.oostenveld at FCDONDERS.RU.NL Sat Aug 20 10:08:19 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Sat, 20 Aug 2005 10:08:19 +0200 Subject: source projection In-Reply-To: Message-ID: Hi Sanja, First some general comments. In my experience megrealign works more accurate with the sincos option (i.e. nearest neighbour interpolation) than with the sourceproject option. I have validated this function using simulated data, in which I computed the field of a dipole on axial gradiometers, and the field of the same data on (true) planar gradiometers. Then I converted the axial to the planar data with megplanar and the different options there and compared the two. I repeated this with different noise levels and the sincos was consistenly more acurate than the others. However (relevant for other people as well) the 'orig' method is still the default. That was implemented initially by Ole Jensen, the other ones were implemented by me. The low-level forward computation of the fields in Fieldtrip cannot make use of the synthetic higfher order gradients. In theory that could be supported, but the weights of the reference sensors are not read in from teh res4 file. That means, whenever you do a computation that involves a forward computed field (sourceanalysis, dipolefitting, megrealign and megplanar+sourceproject), the forward field is a plain 1st order MEG gradient. If your CTFdata is 3rd order, and you have saved it with newDs, there will be a slight discrepancy between the measured data and the forward model, even if your measured data contains a single perfect dipole. The field of the sources in the brain will also be slightly supporessed, which is not represented in the forward model. However, the advantage of the 3rd order gradient is that also environmental noise is suppressed. So there is a trade off, if you have a lot of noise, it is better to use the 3rd order gradient, if you have very clean data, it is better not to use it. I would like to implement the 3rd order gradients, and have most code for it in place, but there are some details that need to be sorted out. If you are going to use it and think that you can contribute, I would appreciate your help on that. Now onto your question: On 19-aug-2005, at 23:43, Sanja Kovacevic wrote: > Oh, I forgot to mention that I used meplanar with the source > projection option. I tracked the problem down to axial2planar (line > 309 of megplanar: planar.grad = axial2planar([], axial.grad)). > Axial2planar does not return the field "type" in planar.grad, and > therefore compute_leadfield could not recognize the sensor type and > gives "the forward model does not look like EEG, nor like MEG" error. > > One potential problem here might be that axial2planar is also trying to compute the planar representation of the reference sensors. I don't think that that applies in your case, but it should not do that. So that is something to check. The latest version of compute_leadfield (revision 1.7) should also detect the correct type in the absence of the "type" field. It has the following added with repect to the older versions elseif isfield(sens, 'pnt') & isfield(sens, 'ori') iseeg = 0; ismeg = 1; If yours does not contain that, please upgrade your fieldtrip version. best regards, Robert From sanja at UNM.EDU Wed Aug 24 00:50:18 2005 From: sanja at UNM.EDU (Sanja Kovacevic) Date: Tue, 23 Aug 2005 16:50:18 -0600 Subject: source projection In-Reply-To: <9F60D4E0-E095-4BF8-B3AB-91241311EB95@fcdonders.ru.nl> Message-ID: Hi Robert, Have you also tried different neighbor distances when you tested megplanar? I believe that for the 151 channel system, the default 4 cm distance would lead to a smaller average number of neighbors than for the 275 channel system. For 275 channel data, using 3 cm neighbor distance I've got 5.5 neighbors on average, while using 4 cm neighbor distance, I've got 9.1 neighbors on average. I noticed that when I used 4 cm neighbor distance, changes in power were more spread out. Do you have any suggestions on how many neighbors would be optimal? Thank you, Sanja From r.oostenveld at FCDONDERS.RU.NL Thu Aug 25 09:00:55 2005 From: r.oostenveld at FCDONDERS.RU.NL (Robert Oostenveld) Date: Thu, 25 Aug 2005 09:00:55 +0200 Subject: source projection In-Reply-To: Message-ID: Hi Sanja, That is something that I never considered, actually. In our 151 channel case, we have with the default 4 cm about one circle of sensors around the sensor of interest. In your 275 channel case that is of course more. Intuitively, I would say that you want to have a smallest circle of sensors that is possible, to accieve the highest spatial resolution. Increasing the spatial resolution is, besides making the spatial topography more easy to understand, a main goal of planar gradients. But constructing the synthetic planar gradients using the nearest neighbour approach also makes the signals more noise, since, at the sensor of interest, you are mixing in the (independent) noise of the neighbouring sensors. In our 151ch case, that is something that we just have to accept, but in your 275ch case, you can trade in some of the spatial resolution (lower, if more channels as neighbours) against the noise (beter, by averaging the noise over them). best regards, Robert On 24-aug-2005, at 0:50, Sanja Kovacevic wrote: > Hi Robert, > > Have you also tried different neighbor distances when you tested > megplanar? I believe that for the 151 channel system, the default 4 > cm distance would lead to a smaller average number of neighbors > than for the 275 channel system. For 275 channel data, using 3 cm > neighbor distance I've got 5.5 neighbors on average, while using 4 > cm neighbor distance, I've got 9.1 neighbors on average. I noticed > that when I used 4 cm neighbor distance, changes in power were more > spread out. Do you have any suggestions on how many neighbors would > be optimal? > > > Thank you, > Sanja > > ======================================================= Robert Oostenveld, PhD F.C. Donders Centre for Cognitive Neuroimaging Radboud University Nijmegen phone: +31-24-3619695 http://www.ru.nl/fcdonders/ From Jan.Schoffelen at FCDONDERS.RU.NL Tue Aug 30 13:18:14 2005 From: Jan.Schoffelen at FCDONDERS.RU.NL (J.M. Schoffelen) Date: Tue, 30 Aug 2005 13:18:14 +0200 Subject: bug-report topoplotER Message-ID: Dear all, I would like to point you to the fact that there is a "bug" in one of fieldtrip's plotting functions: topoplotER.m You can specify for the data to be plotted, the time-interval, or the frequency-interval you would like to have displayed. The function is capable of plotting just one time-bin, or frequency-bin, if you specify cfg.xlim = [x x], x being the latency or frequency you're interested in. HOWEVER, so far this only worked correctly if the wished for latency/frequency was exactly present in the data. The function gives you a completely wrong output, if that is not the case (the same thing goes if your latency-window or frequency-window is in between consecutive data-points in your data). In future releases of this function, an explicit error will be given, instead of silent and misleading nonsense. Sorry for the potential inconvenience, Jan-M -------------- next part -------------- An HTML attachment was scrubbed... URL: