From werkle at mpib-berlin.mpg.de Mon Jan 2 12:41:56 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 11:41:56 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* From jan.schoffelen at donders.ru.nl Mon Jan 2 12:50:28 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Mon, 2 Jan 2017 11:50:28 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> Message-ID: Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From mehmetakifozcoban at gmail.com Mon Jan 2 13:05:52 2017 From: mehmetakifozcoban at gmail.com (=?UTF-8?B?TWVobWV0IEFraWYgw5Z6w6dvYmFu?=) Date: Mon, 2 Jan 2017 15:05:52 +0300 Subject: [FieldTrip] Whole band EEG Message-ID: ​Dear filedtripper and professors; How can İ intepret the phase scores in whole (full-0.5-50Hz) EEG band... Please can you help me with tutorial or paper about significant of whole EEG band​ -- Mehmet Akif ÖZÇOBAN Cd.PhD. Istanbul University -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 13:20:07 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 12:20:07 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de>, Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From michelic72 at gmail.com Mon Jan 2 13:43:57 2017 From: michelic72 at gmail.com (Cristiano Micheli) Date: Mon, 2 Jan 2017 13:43:57 +0100 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> Message-ID: Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: *Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)};* might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option *dbstop if error *(toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus wrote: > Dear Jan-Mathijs, > > thank you for you fast reply. But unfortunately, removing the fields does > not change the error message et all. > > Best, > Markus > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > > ________________________________________ > Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" > im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [ > jan.schoffelen at donders.ru.nl] > Gesendet: Montag, 2. Januar 2017 12:50 > An: FieldTrip discussion list > Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source > input data > > Markus, > > Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again > please? > Thanks, > BW, > JM > > > J.M.Schoffelen > Senior Researcher, VIDI-fellow > Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > > > > > > > > On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: > > > > > > Dear Fieldtrippers, > > > > > > happy new year to everyone here! > > > > This is the second attempt to get help on an issue with > ft_sourcestatistics. As I still can not figure out where the problem > resides, I give it a new try. > > > > My goal is to use a common DICS filter to reconstruct single-trial data > in three conditions. Afterwards, I want to run a test for a linear effect > across the conditions. I thought to follow closely the descriptions in > http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , > especially in the way I extract the single-trial data. However, when I run > ft_sourcestatistics, the single trial source data is not recognized as > source data ... > > > > Any ideas on what went wrong? > > > > Below is the code and error-messages: > > > > > > > > When I run the code below: > > > > %----------------------------------------------------------- > ----------------------------------------------- > > src_descrcfg = []; > > src_descrcfg.keeptrials = 'yes'; > > src00 = ft_sourcedescriptives(src_descrcfg,src00); > > src01 = ft_sourcedescriptives(src_descrcfg,src01); > > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > > > > src_statscfg = []; > > src_statscfg.parameter = 'trial.pow'; > > src_statscfg.method = 'analytic'; > > src_statscfg.statistic = 'indepsamplesregrT'; > > src_statscfg.alpha = 0.05; > > src_statscfg.correctm = 'no'; > > > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) > 3*ones(1,src11.df)]; > > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the > independent variable > > > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > > %----------------------------------------------------------- > ----------------------------------------------- > > > > I get the following output and error message: > > > > original data contained 201 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 48 MB > > original data contained 113 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 0 MB > > original data contained 46 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 0 MB > > Index exceeds matrix dimensions. > > > > Error in ft_datatype_source (line 187) > > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > > > Error in ft_checkdata (line 251) > > data = ft_datatype_source(data); > > > > Error in ft_sourcestatistics (line 100) > > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', > 'feedback', 'no'); > > > > > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with > the following content: > > > > > > src00 = > > > > freq: 9.7656 > > cumtapcnt: [201x1 double] > > dim: [27 36 30] > > inside: [29160x1 logical] > > pos: [29160x3 double] > > method: 'rawtrial' > > trial: [1x201 struct] > > df: 201 > > cfg: [1x1 struct] > > sampleinfo: [201x2 double] > > rating: [201x2 double] > > stim: {201x3 cell} > > > > > > The source-solutions were based on a common dics-filter after running > the following code: > > > > %----------------------------------------------------------- > ----------------------------------------------- > > % compute single trial spectra > > mtmfftcfg.keeptrials = 'yes'; > > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > > > % project all trials through common spatial filter % > > dics_alltrl_cfg = []; > > dics_alltrl_cfg = dics_commoncfg; > > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common > filter computed in the previous step! > > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial > through the filter. Only necessary if you are interested in reconstructing > single trial data > > > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % > contains the source estimates for all trials/both > > %----------------------------------------------------------- > ----------------------------------------------- > > > > > > Any ideas, why the data is not recognized as source-data when calling > ft_sourcestatistics (obviously it is recognized correctly with > ft_sourcedescriptives ...). > > > > > > Thank you very much for your help. > > > > Best regards, > > Markus > > > > > > > > ********************************************************************* > > Dr. Markus Werkle-Bergner, Dipl. Psych. > > Senior Research Scientist (W2) > > > > Jacobs Foundation Research Fellow 2017-2019 > > > > Max Planck Institute for Human Development > > Center for Lifespan Psychology > > > > Lentzeallee 94, 14195 Berlin > > > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > > Mail: werkle at mpib-berlin.mpg.de > > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > > ********************************************************************* > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 14:03:23 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 13:03:23 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de>, Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: >> src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] >> src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Mon Jan 2 14:17:35 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Mon, 2 Jan 2017 13:17:35 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> Message-ID: <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> Markus, Can you switch off the ‘keepfilter’ option before you do the ‘rawtrial’ business? The error context suggests that MATLAB tries to allocate data to a cell-array, which is probably the spatial filter (or possibly the label). Since this information is not needed for the statistical inference, you can discard it. Best, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 14:03, Werkle, Markus > wrote: Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 15:09:07 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 14:09:07 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de>, <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F631@MaxMail04.mpib-berlin.mpg.de> Dear Jan-Mathijs, yes, that did the trick! Setting cfg.dics.keepfilter = 'no' before passing the single trials through the common filter helped. Thank you and Cristiano for your quick and efficient support! Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 14:17 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you switch off the ‘keepfilter’ option before you do the ‘rawtrial’ business? The error context suggests that MATLAB tries to allocate data to a cell-array, which is probably the spatial filter (or possibly the label). Since this information is not needed for the statistical inference, you can discard it. Best, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 14:03, Werkle, Markus > wrote: Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From suhasg10495 at gmail.com Tue Jan 3 13:02:11 2017 From: suhasg10495 at gmail.com (Suhas G) Date: Tue, 3 Jan 2017 17:32:11 +0530 Subject: [FieldTrip] Request for help in debugging error in compilation of biosemi2ft.cc Message-ID: Hi, We are working on a BCI project, where we want to acquire data in real-time from Biosemi. We are using 128 channel Biosemi Active Two device. We are trying to incorporate fieldtrip real time buffer for our real time data acquisition. For the implementation we are following the steps provided on the fieldtrip website. We are getting certain errors during this implementation for which we request your guidance. Ubuntu: We are using Ubuntu 14.04 64 bit. The gcc compiler version used is 4.8.5. We are using Matlab 2015 1. The matlab outside part of buffer is compiled successfully using 'make' on command prompt in the directory src/buffer/src/. 2. The matlab inside part of buffer compilation, i.e creation of mex file was successful on matlab using 'compile' in src/buffer/matlab directory. These warning was displayed, but the mex completed successfully. *Warning: You are using gcc version '4.8.5-2ubuntu1~14.04.1)'. The version of gcc is not supported. Theversion currently supported with MEX is '4.7.x'. For a list of currently supported compilers see:http://www.mathworks.com/support/compilers/current_release . * 3. For compiling the biosemi2ft tool, this is the error which we get *eeg-egi at eeg-egi:~/Desktop/fieldtrip-20161228/realtime/src/acquisition/biosemi$ makeg++ -o ../../../../realtime/bin/glnxa64/biosemi2ft biosemi2ft.o BioSemiClient.o -L../../../../realtime/src/buffer/src -L../../../../realtime/src/buffer/src -lbuffer ../../../../realtime/src/buffer/cpp/SignalConfiguration.o ../../../../realtime/src/buffer/cpp/GdfWriter.o ../../../../realtime/src/buffer/cpp/FtConnection.o ../../../../realtime/src/buffer/cpp/StringServer.o -lbuffer -lpthread -ldl -lrtg++: error: ../../../../realtime/src/buffer/cpp/SignalConfiguration.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/GdfWriter.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/FtConnection.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/StringServer.o: No such file or directorymake: *** [../../../../realtime/bin/glnxa64/biosemi2ft] Error 1* The compilers which are installed are g++, g++-4.8, g++-4.8-multilib, g++-multilib, gcc, gcc-4.8, gcc-4.8-multilib, gcc-multilib, libllvm3.6:amd64 Please help us debug the same. Thank you. Suhas G -------------- next part -------------- An HTML attachment was scrubbed... URL: From suhasg10495 at gmail.com Tue Jan 3 13:02:13 2017 From: suhasg10495 at gmail.com (Suhas G) Date: Tue, 3 Jan 2017 17:32:13 +0530 Subject: [FieldTrip] Request for help in debugging real-time buffer compilation error Message-ID: Hi, We are using 128 channel Biosemi Active Two device. We are working on a BCI project, where we want to acquire data in real-time from Biosemi. We are trying to incorporate fieldtrip real time buffer for our real time data acquisition. For the implementation we are following the steps provided on the fieldtrip website. We are getting certain errors during this implementation for which we request your guidance. Windows: We are using Windows 7, 64 bit system. Installed Softwares: Microsoft Visual C++ 2005, 2008, 2010, 2012 and 2013 Microsoft Windows SDK 7.1 MinGW compiler and MSYS Cygwin 1. The matlab inside part of buffer compilation, i.e creation of mex file on matlab using 'compile' in src/buffer/matlab directory, gave the following error. We tried it using Visual Studio and minGW compilers. *>> mex -setup * *MEX configured to use 'Microsoft Windows SDK 7.1 (C)' for C language compilation.* *Warning: The MATLAB C and Fortran API has changed to support MATLAB* * variables with more than 2^32-1 elements. In the near future* * you will be required to update your code to utilize the* * new API. You can find more information about this at:* * http://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html .* *To choose a different language, select one from the following:* * mex -setup C++ * * mex -setup FORTRAN* *>> compile('vc')* *Compiling library functions in util.c ...* *Building with 'Microsoft Windows SDK 7.1 (C)'.* *Error using mex* *util.c* *C:\Program* *Files\MATLAB\R2016a\toolbox\fieldtrip-20170102\fieldtrip-20170102\realtime\src\buffer\src\util.c(13) : fatal* *error C1083: Cannot open include file: 'sys/time.h': No such file or directory* *Error in compile (line 156)* * eval(cmd);* *>> compile('mingw','C:/MinGW/lib')* *Compiling library functions in util.c ...* *Building with 'Microsoft Windows SDK 7.1 (C)'.* *Error using mex* *util.c* *C:\Program* *Files\MATLAB\R2016a\toolbox\fieldtrip-20170102\fieldtrip-20170102\realtime\src\buffer\src\util.c(13) : fatal* *error C1083: Cannot open include file: 'sys/time.h': No such file or directory* *Error in compile (line 156)* * eval(cmd);* 2. The matlab outside part compilation of buffer in src/buffer/src directory was attempted using make in cygwin terminal. We got the following error: EEG-EGI at EEG-EGI-PC /cygdrive/c/Program Files/MATLAB/R2016a/toolbox/fieldtrip-201 70102/fieldtrip-20170102/realtime/src/buffer/src $ make gcc -I. -Wunused -Wall -pedantic -O0 -fPIC -g -c -o tcpserver.o tcpserver.c tcpserver.c:1:0: warning: -fPIC ignored for target (all code is position indepen dent) /* ^ tcpserver.c: In function ‘cleanup_tcpserver’: tcpserver.c:31:5: warning: implicit declaration of function ‘closesocket’ [-Wimp licit-function-declaration] closesocket(threadlocal->fd); ^ tcpserver.c: In function ‘tcpserver’: tcpserver.c:51:22: error: storage size of ‘sa’ isn’t known struct sockaddr_in sa; ^ tcpserver.c:102:12: warning: implicit declaration of function ‘socket’ [-Wimplic it-function-declaration] if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:102:19: error: ‘PF_INET’ undeclared (first use in this function) if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:102:19: note: each undeclared identifier is reported only once for e ach function it appears in tcpserver.c:102:28: error: ‘SOCK_STREAM’ undeclared (first use in this function) if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:136:7: warning: implicit declaration of function ‘setsockopt’ [-Wimp licit-function-declaration] if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:136:21: error: ‘SOL_SOCKET’ undeclared (first use in this function) if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:136:33: error: ‘SO_REUSEADDR’ undeclared (first use in this function ) if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:142:19: error: ‘AF_INET’ undeclared (first use in this function) sa.sin_family = AF_INET; ^ tcpserver.c:143:19: warning: implicit declaration of function ‘htons’ [-Wimplici t-function-declaration] sa.sin_port = htons(host->port); ^ tcpserver.c:145:7: error: ‘INADDR_ANY’ undeclared (first use in this function) if (INADDR_ANY) ^ tcpserver.c:146:26: warning: implicit declaration of function ‘htonl’ [-Wimplici t-function-declaration] sa.sin_addr.s_addr = htonl(INADDR_ANY); ^ tcpserver.c:148:7: warning: implicit declaration of function ‘bind’ [-Wimplicit- function-declaration] if (bind(s, (struct sockaddr *)&sa, sizeof sa) < 0) { ^ tcpserver.c:153:7: warning: implicit declaration of function ‘listen’ [-Wimplici t-function-declaration] if (listen(s, BACKLOG)<0) { ^ tcpserver.c:168:9: warning: implicit declaration of function ‘accept’ [-Wimplici t-function-declaration] c = accept(s, (struct sockaddr *)&sa, &b); ^ tcpserver.c:186:9: warning: implicit declaration of function ‘usleep’ [-Wimplici t-function-declaration] usleep(ACCEPTSLEEP); ^ tcpserver.c:202:23: error: storage size of ‘lg’ isn’t known struct linger lg; ^ tcpserver.c:207:35: error: ‘SO_LINGER’ undeclared (first use in this function) setsockopt(s, SOL_SOCKET, SO_LINGER, (char *) &lg, sizeof(lg)); ^ tcpserver.c:202:23: warning: unused variable ‘lg’ [-Wunused-variable] struct linger lg; ^ tcpserver.c:213:37: error: ‘SO_RCVBUF’ undeclared (first use in this function) if (setsockopt(c, SOL_SOCKET, SO_RCVBUF, (const char*)&optval, sizeof(opt val)) < 0) { ^ tcpserver.c:220:37: error: ‘SO_SNDBUF’ undeclared (first use in this function) if (setsockopt(c, SOL_SOCKET, SO_SNDBUF, (const char*)&optval, sizeof(opt val)) < 0) { ^ tcpserver.c:249:50: warning: cast to pointer from integer of different size [-Wi nt-to-pointer-cast] rc = pthread_create(&tid, NULL, tcpsocket, (void *)c); ^ tcpserver.c:267:10: warning: zero-length gnu_printf format string [-Wformat-zero -length] printf(""); ^ tcpserver.c:267:10: warning: zero-length gnu_printf format string [-Wformat-zero -length] tcpserver.c:56:23: warning: unused variable ‘oldcanceltype’ [-Wunused-variable] int oldcancelstate, oldcanceltype; ^ tcpserver.c:56:7: warning: unused variable ‘oldcancelstate’ [-Wunused-variable] int oldcancelstate, oldcanceltype; ^ tcpserver.c:51:22: warning: unused variable ‘sa’ [-Wunused-variable] struct sockaddr_in sa; ^ make: *** [: tcpserver.o] Error 1 Please help us debug the same. Thank you. Suhas G -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Wed Jan 4 10:56:31 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Wed, 4 Jan 2017 10:56:31 +0100 Subject: [FieldTrip] Getting "nan" from ft_read_cifti Message-ID: <2B64515C-C06C-4BFB-B61F-4C981076523C@estudiant.upf.edu> Dear all, I am new to this subject, so I apologize if this is a very simple error. I have downloaded parcellated fMRI time series from HCP and when I apply the function: >> TC = ft_read_cifti('100206.dtseries.nii’); Then the TC.dtseries has 200 columns (parcels) and 96854 rows, which I understand they are the values for each timestep. The problem is that quite a lot of these rows are purely “NaN” values. Does anybody experienced the same problem? What I am missing? Thank you in advanced! Joan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.klinzing at uni-tuebingen.de Wed Jan 4 16:47:12 2017 From: jens.klinzing at uni-tuebingen.de (=?UTF-8?B?IkplbnMgS2xpbnppbmcsIFVuaXZlcnNpdMOkdCBUw7xiaW5nZW4i?=) Date: Wed, 04 Jan 2017 16:47:12 +0100 Subject: [FieldTrip] Keeptrials using "pcc" for source analysis In-Reply-To: References: Message-ID: <586D1900.3080804@uni-tuebingen.de> Hi Xie, are you sure your output does not contain trial data? If you look in source.avg.mom you should see a cell array containing for each inside source point another cell array with as many entries as there are trials (I know it is confusing because you expect .avg to contain averages, but it may not). The field .csd (cross-spectral density) should contain only one (complex-valued) entry per source point since it is averaged across trials (or calculated on the average over all trials, not sure right now). By the way: In case you get errors in downstream functions with your current output (e.g. when using ft_sourcegrandaverage) check the bugzilla on PCC output containing the spatial filter (e.g. http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2861 or 3184). If you don't really need the filter you can use cfg.keepfilter = 'no' on ft_sourceanalysis or remove the filter and filterdimord fields when calling functions that would otherwise fail. Best, Jens > Xie Wanze > Samstag, 31. Dezember 2016 15:09 > Dear Fieldtrip community, > I have a question about using the "keeptrials" option when do the > source analysis with the beamformer ('PCC') method. The issue I met > was that the cfg.keeptrials = 'yes' did not work, i.e., the > calculation was not done for all the trials but generated averaged > output. > Has anyone met this issue before? And does anyone know how to fix it? > It did not work for my data nor for the data I downloaded from the FT > database. I attached the codes that I copied from the FT website using > the FT's example data. > I would like to keep the trials information in the source analysis > because I plan to do the source space connectivity analysis later, > which needs the individual trials information. Or maybe the > "crsspctrm" matrix. > > Codes: > > cfg = []; > > cfg.frequency = freq.freq; > > cfg.method = 'pcc'; > > cfg.grid = lf; > > cfg.headmodel = hdm; > > cfg.keeptrials = 'yes'; > > cfg.pcc.lambda = '10%'; > > cfg.pcc.projectnoise = 'yes'; > > cfg.pcc.keepfilter = 'yes'; > > cfg.pcc.fixedori = 'yes'; > > source = ft_sourceanalysis(cfg, freq); > > > Output ("source"): > > freq: 10 > > cumtapcnt: [268x1 double] > > tri: [16000x3 double] > > inside: [8004x1 logical] > > pos: [8004x3 double] > > method: 'average' > > avg: [1x1 struct] > > cfg: [1x1 struct] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiew1202 at gmail.com Thu Jan 5 02:06:20 2017 From: xiew1202 at gmail.com (Xie Wanze) Date: Thu, 5 Jan 2017 09:06:20 +0800 Subject: [FieldTrip] Keeptrials using "pcc" for source analysis In-Reply-To: <586D1900.3080804@uni-tuebingen.de> References: <586D1900.3080804@uni-tuebingen.de> Message-ID: Hi Jens, Thank you for your response. I figured out where the problem resided. It seems to me that the 'PCC' temporarily does not work with the option "rawtrial = 'yes'". So, the output from using "keeptrials = 'yes'" does not contain the pow and mom information for individual trials. However, this information can be reconstructed for each trial using the ft_sourcedescriptive function with "keeptrials = 'yes' ". For source analysis of time series (e.g., lcmv and eloreta), individual trial information can be obtained by setting "keeptrials = 'yes' and rawtrial = 'yes' ". No need for the ft_sourcedescriptive function. I don't know if this was only my case or someone else also had come across the same situation. 2017-01-04 10:47 GMT-05:00 "Jens Klinzing, Universität Tübingen" < jens.klinzing at uni-tuebingen.de>: > Hi Xie, > are you sure your output does not contain trial data? > > If you look in source.avg.mom you should see a cell array containing for > each inside source point another cell array with as many entries as there > are trials (I know it is confusing because you expect .avg to contain > averages, but it may not). The field .csd (cross-spectral density) should > contain only one (complex-valued) entry per source point since it is > averaged across trials (or calculated on the average over all trials, not > sure right now). > > By the way: In case you get errors in downstream functions with your > current output (e.g. when using ft_sourcegrandaverage) check the bugzilla > on PCC output containing the spatial filter (e.g. http://bugzilla. > fieldtriptoolbox.org/show_bug.cgi?id=2861 or 3184). > If you don't really need the filter you can use cfg.keepfilter = 'no' on > ft_sourceanalysis or remove the filter and filterdimord fields when calling > functions that would otherwise fail. > > Best, > Jens > > Xie Wanze > Samstag, 31. Dezember 2016 15:09 > Dear Fieldtrip community, > I have a question about using the "keeptrials" option when do the source > analysis with the beamformer ('PCC') method. The issue I met was that the > cfg.keeptrials = 'yes' did not work, i.e., the calculation was not done for > all the trials but generated averaged output. > Has anyone met this issue before? And does anyone know how to fix it? > It did not work for my data nor for the data I downloaded from the FT > database. I attached the codes that I copied from the FT website using the > FT's example data. > I would like to keep the trials information in the source analysis > because I plan to do the source space connectivity analysis later, which > needs the individual trials information. Or maybe the "crsspctrm" matrix. > > Codes: > > cfg = []; > > cfg.frequency = freq.freq; > > cfg.method = 'pcc'; > > cfg.grid = lf; > > cfg.headmodel = hdm; > > cfg.keeptrials = 'yes'; > > cfg.pcc.lambda = '10%'; > > cfg.pcc.projectnoise = 'yes'; > > cfg.pcc.keepfilter = 'yes'; > > cfg.pcc.fixedori = 'yes'; > > source = ft_sourceanalysis(cfg, freq); > > > Output ("source"): > > freq: 10 > > cumtapcnt: [268x1 double] > > tri: [16000x3 double] > > inside: [8004x1 logical] > > pos: [8004x3 double] > > method: 'average' > > avg: [1x1 struct] > > cfg: [1x1 struct] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Jan 5 22:15:59 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 5 Jan 2017 21:15:59 +0000 Subject: [FieldTrip] Fwd: Time-frequency analysis: cfg.foi/T meaning References: Message-ID: <90BC228E-9B2F-4A4E-9F7B-3DAA3F93D120@donders.ru.nl> Begin forwarded message: From: Michał Komorowski > Subject: Time-frequency analysis: cfg.foi/T meaning Date: 5 January 2017 at 19:00:29 GMT+1 To: > Hello, http://www.fieldtriptoolbox.org/faq/why_does_my_output.freq_not_match_my_cfg.foi_when_using_mtmconvol_in_ft_freqanalyis I am trying to fit my time windows/simulated data frequencies in time-frequency analysis to make Fieldtrip not correcting my cfg.foi. In other words I want my output frequencies to be EXACTLY the same as cfg.foi. In the mentioned page a following criterion for time-frequency analysis was proposed: "Is the length of my data such, that the frequency resolution 1/T can capture all cfg.foi? This means, in other words, that cfg.foi/T should be integer numbers." I am not sure If the number cfg.foi/T makes sense, because the units of that ratio is [1/s*s = Hz*Hz]. Please correct me if I am wrong. I also tried many other ways of tweaking my parameters, but with no result. All in all, at that moment, from my perspective it looks like Fieldtrip will always correct my cfg.foi and I must not expect that my output frequencies will match with cfg.foi,. I am also almost equally sure that this is not true. I would be very happy if you can help me. Kind regards, Michał Komorowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From krugliakova.es at gmail.com Mon Jan 9 12:48:20 2017 From: krugliakova.es at gmail.com (Elena Krugliakova) Date: Mon, 9 Jan 2017 11:48:20 +0000 Subject: [FieldTrip] EEG source reconstruction using DICS method Message-ID: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> Dear Fieldtrip community, I have a question regarding source reconstruction using the 'dics' method applied to EEG data. I have two problems: first, even with 32GB of RAM it takes 9 hours to call one ft_sourceanalysis. Maybe, there is a way to optimise the procedure somehow? Second, at the end of analysis I obtain a very strange figure, on which I see activity localised outside the mri scan. Mistake on which step of analysis might cause this problem? As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer Please, find my script below. Thank you in advance! Kind Regards, Elena Script: % freqanalysis cfg = []; cfg.toilim = [-0.5 -0.1]; % prestimulus Pre = ft_redefinetrial(cfg, MyData); cfg = []; cfg.toilim = [0.9 1.3]; % poststimulus Post = ft_redefinetrial(cfg, MyData); cfg = []; dataAll = ft_appenddata([], Pre, Post); cfg = []; cfg.method = 'mtmfft'; cfg.output = 'powandcsd' cfg.keeptrials = 'no'; cfg.taper = 'dpss'; cfg.foi = 35; cfg.tapsmofrq = 4; freq_Pre = ft_freqanalysis(cfg, Pre); freq_Post = ft_freqanalysis(cfg, Post); freq_PrePost = ft_freqanalysis(cfg, dataAll); %% headmodel preparation --- with standard brain mri = ft_read_mri('Subject01.mri'); cfg = []; cfg.dim = mri.dim; mri = ft_volumereslice(cfg,mri); cfg = []; cfg.output = {'gray','white','csf','skull','scalp'} segmentedmri = ft_volumesegment(cfg, mri); cfg = []; cfg.shift = 0.3; cfg.method = 'hexahedral'; cfg.tissue = {'gray','white','csf','skull','scalp'} cfg.numvertices = [800, 800, 800, 400, 200]; cfg.unit = segmentedmri.unit bndFEM = ft_prepare_mesh(cfg,segmentedmri); cfg = []; cfg.method ='simbio'; cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); %% loading aligned electrodes load elec_aligned % 109 EEG electrodes %% leadfield preparation cfg = []; cfg.elec = elec_aligned; cfg.vol = vol_simbio_lowresol; cfg.channel = 'all'; cfg.reducerank = 3; % 3 for eeg cfg.grid.unit = 'mm'; cfg.grid.resolution = 10; leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); %% sourceanalysis cfg = []; cfg.frequency = 35; cfg.vol = vol_simbio_lowresol; cfg.grid = leadfield_FEM_lowresol cfg.projectnoise = 'yes'; cfg.method = 'dics'; cfg.dics.projectnoise = 'yes'; cfg.dics.lambda = '5%'; cfg.dics.keepfilter = 'yes'; cfg.dics.realfilter = 'yes'; sourceAll = ft_sourceanalysis(cfg, freq_PrePost); cfg.grid.filter = sourceAll.avg.filter; sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); sourcePost_con = ft_sourceanalysis(cfg, freq_Post); sourceDiff = sourcePost_con; sourceDiff.avg.pow = (sourcePost_con.avg.pow - sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; %% sourceplot cfg = []; cfg.downsample = 2; cfg.parameter = 'pow'; sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); cfg = []; sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); cfg = []; cfg.method = 'glassbrain'; cfg.funparameter = 'pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceDiffIntNorm); -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.chait at ucl.ac.uk Mon Jan 9 14:07:25 2017 From: m.chait at ucl.ac.uk (Chait, Maria) Date: Mon, 9 Jan 2017 13:07:25 +0000 Subject: [FieldTrip] Post-Doc position at UCL Ear Institute Message-ID: (please forward) A postdoctoral research associate position is available at the UCL Ear Institute's 'Auditory Cognitive Neuroscience Lab'. The project, titled "How the brain detects patterns in sound sequences", will be supervised by Dr Maria Chait and conducted in collaboration with Dr. Marcus Pearce (Queen Mary University, London) and colleagues at the UCL Wellcome Trust centre for neuroimaging. The post is funded for 34 months in the first instance and involves a combination of behavioural, computational, eye tracking, and functional brain imaging (EEG, MEG, fMRI) experiments in humans. For more information about the post please see the lab website: http://www.ucl.ac.uk/ear/research/chaitlab/vacancies The Ear Institute is a leading interdisciplinary centre for hearing research in Europe, situated within one of the strongest neuroscience communities in the world at University College London Key Requirements The successful applicant will have a PhD in neuroscience or a neuroscience-related discipline and proven ability to conduct high-quality original research and prepare results for publication. Essential skills include excellent time-management and organizational ability; proficiency in computer programming and good interpersonal, oral and written communication skills. Previous experience with functional brain imaging, neural data analysis, psychophysical assessment, and/or auditory science or acoustics would be desirable. Further Details You should apply for this post (Ref #: 1618836) through UCL's online recruitment website, www.ucl.ac.uk/hr/jobs, where you can download a job description and person specifications. Closing Date for applications is: 1 Feb 2017 For an informal discussion please contact Dr. Maria Chait (m.chait at ucl.ac.uk). Maria Chait PhD m.chait at ucl.ac.uk Reader in Auditory Cognitive Neuroscience Lab site: http://www.ucl.ac.uk/ear/research/chaitlab/ UCL Ear Institute 332 Gray's Inn Road London WC1X 8EE -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Mon Jan 9 22:44:18 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Mon, 9 Jan 2017 21:44:18 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Message-ID: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom -------------- next part -------------- An HTML attachment was scrubbed... URL: From son.ta.dinh at tum.de Tue Jan 10 08:20:58 2017 From: son.ta.dinh at tum.de (Ta Dinh, Son) Date: Tue, 10 Jan 2017 07:20:58 +0000 Subject: [FieldTrip] LCMV beamforming, source.avg.pow is not the power? Message-ID: Hi Fieldtrippers, I have been trying to do a source analysis on my (resting-state) data using LCMV beamforming and as part of a sanity check, I wanted to plot the alpha power. Using ft_sourceanalysis I get a source structure containing avg.pow and intuitively I expected this field to contain the averaged power of the time series. Therefore, I band-passed the data on the sensor level before doing the LCMV source reconstruction. Surprisingly however, when I used the resulting LCMV spatial filter to construct virtual channels and calculated the alpha power spectrum of the resulting time series using ft_freqanalysis, the average power between these 2 approaches differed by several orders of magnitude over many voxels. Did I make some conceptual misunderstanding? Are the 2 approaches I used not equivalent? Or does source.avg.pow not contain the average power at all? Any comments would be greatly appreciated! Best regards, Son Son Ta Dinh, M.Sc. PhD student in Human Pain Research Klinikum rechts der Isar Technische Universität München Munich, Germany Phone: +49 89 4140 7664 http://www.painlabmunich.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Tue Jan 10 11:01:28 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Tue, 10 Jan 2017 10:01:28 +0000 Subject: [FieldTrip] Post-Doc Position (2 years) at MPIB Berlin - Personalized Cognitive Neuroscience Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA65091@MaxMail04.mpib-berlin.mpg.de> Dear Colleagues, within the research area "Cognitive and Neural Dynamics of Memory Across the Lifespan", headed by Myriam Sander and myself, at the Max Planck Institute for Human Development, Berlin, we are looking for a post-doc to work in our group. Please check the attached advertisement for additional information. The successful candidate will work on a unique data set with intense micro-longitudinal within-person EEG measurements (up to 12 repeated sessions) conducted in the context of a working memory training study. The goal of the project is to develop novel analytical approaches to link cognitive and neural process models on the within-person level. Please spread the news! Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Ta Dinh, Son [son.ta.dinh at tum.de] Gesendet: Dienstag, 10. Januar 2017 08:20 An: fieldtrip at science.ru.nl Betreff: [FieldTrip] LCMV beamforming, source.avg.pow is not the power? Hi Fieldtrippers, I have been trying to do a source analysis on my (resting-state) data using LCMV beamforming and as part of a sanity check, I wanted to plot the alpha power. Using ft_sourceanalysis I get a source structure containing avg.pow and intuitively I expected this field to contain the averaged power of the time series. Therefore, I band-passed the data on the sensor level before doing the LCMV source reconstruction. Surprisingly however, when I used the resulting LCMV spatial filter to construct virtual channels and calculated the alpha power spectrum of the resulting time series using ft_freqanalysis, the average power between these 2 approaches differed by several orders of magnitude over many voxels. Did I make some conceptual misunderstanding? Are the 2 approaches I used not equivalent? Or does source.avg.pow not contain the average power at all? Any comments would be greatly appreciated! Best regards, Son Son Ta Dinh, M.Sc. PhD student in Human Pain Research Klinikum rechts der Isar Technische Universität München Munich, Germany Phone: +49 89 4140 7664 http://www.painlabmunich.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PostDoc_CONMEM_2017.pdf Type: application/pdf Size: 50077 bytes Desc: PostDoc_CONMEM_2017.pdf URL: From jan.schoffelen at donders.ru.nl Tue Jan 10 14:40:58 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Tue, 10 Jan 2017 13:40:58 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: Message-ID: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Tue Jan 10 15:36:48 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Tue, 10 Jan 2017 14:36:48 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> References: , <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Message-ID: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Jan 10 16:19:14 2017 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 10 Jan 2017 16:19:14 +0100 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) Message-ID: Dear all, Robert told me there is something implemented, yet undocumented, that would facilitate computing bipolar derivations when re-referencing EEG data. (I have many SEEG electrodes with multiple contact points and would like to have bipolar contacts for each electrode). I don't remember exactly what it was, though. Does anyone know what that would be/has used it before? (Possibly with ft_preprocessing, with a boolean in cfg.refchannel?) Thanks a lot, Vitória -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Jan 10 16:32:53 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Tue, 10 Jan 2017 15:32:53 +0000 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) In-Reply-To: References: Message-ID: <76DED69E-B3C3-4DD5-B6C6-2E803BBB99C3@donders.ru.nl> Hi Vitoria, ft_apply_montage is your friend. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 16:19, Vitoria Piai > wrote: Dear all, Robert told me there is something implemented, yet undocumented, that would facilitate computing bipolar derivations when re-referencing EEG data. (I have many SEEG electrodes with multiple contact points and would like to have bipolar contacts for each electrode). I don't remember exactly what it was, though. Does anyone know what that would be/has used it before? (Possibly with ft_preprocessing, with a boolean in cfg.refchannel?) Thanks a lot, Vitória _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Jan 10 16:37:47 2017 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 10 Jan 2017 16:37:47 +0100 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) Message-ID: Yep, that's him! Thanks! On 10 January 2017 at 16:32, Schoffelen, J.M. (Jan Mathijs) < jan.schoffelen at donders.ru.nl> wrote: > Hi Vitoria, > > ft_apply_montage is your friend. > > Best, > Jan-Mathijs > > > J.M.Schoffelen > Senior Researcher, VIDI-fellow > Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > > > > > On 10 Jan 2017, at 16:19, Vitoria Piai wrote: > > Dear all, > > Robert told me there is something implemented, yet undocumented, that > would facilitate computing bipolar derivations when re-referencing EEG > data. (I have many SEEG electrodes with multiple contact points and would > like to have bipolar contacts for each electrode). > > I don't remember exactly what it was, though. Does anyone know what that > would be/has used it before? (Possibly with ft_preprocessing, with a > boolean in cfg.refchannel?) > > Thanks a lot, Vitória > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmadsen at emory.edu Tue Jan 10 21:01:31 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Tue, 10 Jan 2017 15:01:31 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Thanks for the reference. In return, I also recommend reading Ciuparu and Mures an's recent rebuttal: European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, doi:10.1111/ejn.13179 TECHNICAL SPOTLIGHT Sources of bias in single-trial normalization procedures They demonstrate that the positive bias Grandchamp and Delorme warned about with single-trial baseline normalization was, in fact, due to the correlated numerators and denominators in each of the baseline normalization procedures they tested, which was, in turn, caused by the skewed distributions of baseline power values. They demonstrate that this bias is reduced by using a much longer baseline, ideally incorporated into the experimental design, but when that's not possible, stitching together the baselines of many trials. Neither article addresses my specific question of whether it would be even better to log-transform the raw power values before averaging, so I suppose I'll have to test it myself and write my own methods article! 🤓 I will go ahead and incorporate some of these alternative baseline normalization methods in my git fork of FieldTrip as I go along with my own analyses, so let me know if anyone else would find them useful, and I'll submit a pull request to contribute them to the master branch. Thanks for the fruitful discussion, all! ~Teresa On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: > Indeed, in a separate thread with Michael Cohen several months back he > suggested precisely that paper. > > On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" > wrote: > >> I think this paper is relevant to this discussion. >> >> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >> >> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >> >> >> >> On 19 December 2016 at 13:08, Teresa Madsen wrote: >> >>> I appreciate everyone's feedback, but I still wonder if something is >>> being missed. I understand that the non-normally distributed power values >>> may be less of an issue when performing non-parametric stats or even a >>> paired-samples t-test that looks at difference values which may be normal >>> even when the raw data isn't. However, my concern comes into play even >>> before these statistical comparisons are made, whenever any averaging is >>> done to freq-type data across times, frequencies, trials, electrodes, >>> subjects, etc. That means any time any of these configuration options are >>> used for any of these functions, and probably more: >>> >>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>> cfg.avgoverfreq = 'yes'; >>> ft_freqbaseline: cfg.baseline = anything but 'no' >>> >>> In each case, if raw power values are averaged, the result will be >>> positively skewed. Maybe it's not a huge problem if all of the data is >>> treated identically, but the specific case that triggered my concern was in >>> ft_freqbaseline, where the individual time-frequency bins are compared to >>> the mean over time for the baseline period. For example, when using >>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>> data does indeed have a more normal distribution over time, but the mean >>> over the baseline time period is performed *before* the log transform, when >>> the distribution is still highly skewed: >>> >>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>> size(data, 3)]); >>> data = 10*log10(data ./ meanVals); >>> >>> That's what I had originally done when analyzing data for my SfN poster, >>> when I realized the background noise that shouldn't have changed much from >>> baseline was mostly showing a decrease from baseline of about -3dB. >>> >>> Now, I've realized I'm seeing this as more of a problem than others >>> because of another tweak I made, which was to use a long, separate baseline >>> recording to normalize my trial data, rather than a short pre-trial period >>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>> for a baseline power estimate might be okay because overlapping time points >>> in the original data are used to calculate those power values anyway, >>> probably making them less skewed, but also (it seems to me) more arbitrary >>> and prone to error. I already offered my custom function BLnorm.m to one >>> person who was asking about this issue of normalizing to a separate >>> baseline recording, and I would be happy to contribute it to FieldTrip if >>> others would appreciate it. >>> >>> Since a few people suggested using the median, and it is also suggested >>> in Cohen's textbook >>> as >>> an alternative measure of the central tendency for skewed raw power values, >>> I wonder if the simplest fix might be to add an option to select mean or >>> median in each of the functions listed above. Another possibility would be >>> adding an option to transform the power values upon output from >>> ft_freqanalysis. >>> >>> Would anyone else find such changes useful? >>> >>> Thanks, >>> Teresa >>> >>> >>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>> J.Herring at donders.ru.nl> wrote: >>> >>>> In terms of statistics it is the distribution of values that you do the >>>> statistics on that matters. In case of a paired-samples t-test when >>>> comparing two conditions, it is the distribution of difference values that >>>> has to be normally distributed. The distribution of difference values is >>>> often normal given two similarly non-normal distributions, offering no >>>> complications for a regular parametric test. >>>> >>>> >>>> >>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>> normality, so you should have no problem there either. >>>> >>>> >>>> >>>> >>>> >>>> *From:* fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at scie >>>> nce.ru.nl] *On Behalf Of *Alik Widge >>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>> *To:* FieldTrip discussion list >>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>> data analysis >>>> >>>> >>>> >>>> In this, Teresa is right and we have observed this in our own EEG data >>>> -- depending on one's level of noise and number of trials/patients, the >>>> mean can be a very poor estimator of central tendency. My students are >>>> still arguing about what we really want to do with it, but at least one of >>>> them has shifted to using the median as a matter of course for baseline >>>> normalization. >>>> >>>> >>>> Alik Widge >>>> alik.widge at gmail.com >>>> (206) 866-5435 >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>> wrote: >>>> >>>> That may very well be true; to be honest, I haven't looked that deeply >>>> into the stats offerings yet. However, my plan is to express each >>>> electrode's experimental data in terms of change from their respective >>>> baseline recordings before attempting any group averaging or statistical >>>> testing, and this problem shows up first in the baseline correction step, >>>> where FieldTrip averages raw power over time. >>>> >>>> ~Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>> statistics implemented by fieldtrip, the data does not need to be normally >>>> distributed. >>>> >>>> >>>> >>>> On 12 December 2016 at 13:39, Teresa Madsen wrote: >>>> >>>> No, sorry, that's not what I meant, but thanks for giving me the >>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>> across frequencies, but the distribution across time (and according to the >>>> poster, also across space), also has an extremely skewed, negative >>>> exponential distribution. I probably confused everyone by trying to show >>>> too much data in my figure, but each color represents the distribution of >>>> power values for a single frequency over time, using a histogram and a line >>>> above with circles at the mean +/- one standard deviation. >>>> >>>> My main point was that the mean is not representative of the central >>>> tendency of such an asymmetrical distribution of power values over time. >>>> It's even more obvious which is more representative of their actual >>>> distributions when I plot e^mean(logpower) on the raw plot and >>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>> busy and confusing. >>>> >>>> I hope that helps, >>>> Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Hi Teresa, >>>> >>>> >>>> >>>> I think what you are discussing is the 1/f power scaling of the power >>>> spectrum. This is one of the reasons that comparisons are made within >>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>> as such the assumption is that within bands there should be a relative >>>> change against baseline and this is what the statistics are performed on. >>>> That is, baseline correction is assumed to be the mean for a specific >>>> frequency and not a mean across frequencies. >>>> >>>> >>>> >>>> And this leads to another point that when you are selecting a >>>> frequency range to do the non-parametric statistics on you should not do >>>> 1-64 Hz but break it up based on the bands. >>>> >>>> >>>> >>>> Hope my interpretation of your point is correct. I sent in >>>> individually, as I wanted to ensure I followed your point. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Nick >>>> >>>> >>>> >>>> >>>> >>>> On 12 December 2016 at 08:23, Teresa Madsen wrote: >>>> >>>> FieldTrippers, >>>> >>>> >>>> >>>> While analyzing my data for the annual Society for Neuroscience >>>> meeting, I developed a concern that was quickly validated by another poster >>>> (full abstract copied and linked below) focusing on the root of the >>>> problem: neural oscillatory power is not normally distributed across time, >>>> frequency, or space. The specific problem I had encountered was in >>>> baseline-correcting my experimental data, where, regardless of >>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>> However, I found that the distribution of raw power over time is so skewed >>>> that the mean was not a reasonable approximation of the central tendency of >>>> the baseline power, so it made most of my experimental data look like it >>>> had decreased power compared to baseline. The more I think about it, the >>>> more I realize that averaging is everywhere in the way we analyze neural >>>> oscillations (across time points, frequency bins, electrodes, trials, >>>> subjects, etc.), and many of the standard statistics people use also rely >>>> on assumptions of normality. >>>> >>>> >>>> >>>> The most obvious solution for me was to log transform the data first, >>>> as it appears to be fairly log normal, and I always use log-scale >>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>> that this would at least "restore (some) symmetry to the error >>>> distribution." I used a natural log transform, sort of arbitrarily to >>>> differentiate from the standard decibel transform included in FieldTrip as >>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>> across several frequency bands (using power values from a wavelet >>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>> cortex). The lines at the top represent the mean +/- one standard >>>> deviation for each frequency band, and you can see how those descriptive >>>> stats are much more representative of the actual distributions in the log >>>> scale. >>>> >>>> >>>> >>>> >>>> ​​ >>>> >>>> For my analysis, I also calculated a z-score on the log transformed >>>> power to assess how my experimental data compared to the variability of the >>>> noise in a long baseline recording from before conditioning, rather than a >>>> short pre-trial baseline period, since I find that more informative than >>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>> functions I wrote for this if people think it would be a useful addition to >>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>> poster, if anyone wants more detail - I just didn't want to make this email >>>> too big. >>>> >>>> >>>> >>>> Mostly, I'm just hoping to start some discussion here as to how to >>>> address this. I searched the wiki >>>> , listserv >>>> >>>> archives >>>> , >>>> and bugzilla >>>> for >>>> anything related and came up with a few topics surrounding normalization >>>> and baseline correction, but only skirting this issue. It seems important, >>>> so I want to find out whether others agree with my approach or already have >>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>> be changed or just documentation added, or what? >>>> >>>> >>>> >>>> Thanks for any insights, >>>> >>>> Teresa >>>> >>>> >>>> >>>> >>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>> across time >>>> >>>> >>>> *Authors* >>>> >>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>> Cognitive Sci., UCSD, San Diego, CA >>>> >>>> *Disclosures* >>>> >>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>> >>>> *Abstract* >>>> >>>> Neural oscillations are important in organizing activity across the >>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>> to numerous disease states. Oscillations are known to vary by frequency and >>>> amplitude across time and between different brain regions; however, this >>>> variability has never been well characterized. We examined human and animal >>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>> distribution of power and frequency across time, space and species. We >>>> report that between data types, subjects, frequencies, electrodes, and >>>> time, an inverse power law, or negative exponential distribution, is >>>> present in all recordings. This is contrary to, and not compatible with, >>>> the Gaussian noise assumption made in many digital signal processing >>>> techniques. The statistical assumptions underlying common algorithms for >>>> power spectral estimation, such as Welch's method, are being violated >>>> resulting in non-trivial misestimates of oscillatory power. Different >>>> statistical approaches are warranted. >>>> >>>> >>>> >>>> -- >>>> >>>> Teresa E. Madsen, PhD >>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>> analysis >>>> >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> >>>> Emory University >>>> >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> >>>> (770) 296-9119 >>>> >>>> braingirl at gmail.com >>>> >>>> https://www.linkedin.com/in/temadsen >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Teresa E. Madsen, PhD >>> Division of Behavioral Neuroscience and Psychiatric Disorders >>> Yerkes National Primate Research Center >>> Emory University >>> Rainnie Lab, NSB 5233 >>> 954 Gatewood Rd. NE >>> Atlanta, GA 30329 >>> (770) 296-9119 >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Nicholas Peatfield, PhD >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38279 bytes Desc: not available URL: From selene.petit at hotmail.fr Wed Jan 11 01:53:40 2017 From: selene.petit at hotmail.fr (=?iso-8859-1?Q?S=E9l=E8ne_Petit?=) Date: Wed, 11 Jan 2017 00:53:40 +0000 Subject: [FieldTrip] Help needed for an Emotiv layout Message-ID: Hi, I want to analyze some Emotiv EPOC+ data using cluster permutation. My problem is I don't know how to get a layout or a neighbour matrix for this system. Does someone have a .lay file and a neighbour file for Emotiv? Or should I create my own? I'm not sure how to do that, even after reading the documentation for ft_prepapre_layout. Thanks a lot in advance, Kindly, Selene Selene Petit PhD Candidate Department of Cognitive Science | Level 3, Australia Hearing Hub 16 University Avenue Macquarie University NSW 2109 Australia T: 0404602281 | ccd.edu.au | mq.edu.au -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Thu Jan 12 11:39:09 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Thu, 12 Jan 2017 10:39:09 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data Message-ID: Hello everyone! I am dealing with HPC timeseries from rfMRI (dtseries.nii) data and I it has a 200 dimensionality ("parcellated”). I want to know which area of the brain corresponds to each parcel but I could not manage to find it out. When I read the file with ft_read_cifti in Matlab, it returns me the following struct: struct with fields: dimord: 'pos_time' time: [1×200 double] hdr: [1×1 struct] unit: 'mm' brainstructure: [96854×1 double] brainstructurelabel: {1×21 cell} dim: [91 109 91] pos: [96854×3 double] transform: [4×4 double] dtseries: [96854×200 double] But any of those variables is linking the parcel with any brain area. Thank you all in advanced! Joan From jan.schoffelen at donders.ru.nl Thu Jan 12 12:19:58 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 12 Jan 2017 11:19:58 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Message-ID: <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Thu Jan 12 12:24:19 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Thu, 12 Jan 2017 11:24:19 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data References: Message-ID: <834270EE-34AE-4B5D-83B0-F5F27277A238@estudiant.upf.edu> Hello everyone! I am dealing with HPC timeseries from rfMRI (dtseries.nii) data and I it has a 200 dimensionality ("parcellated”). I want to know which area of the brain corresponds to each parcel but I could not manage to find it out. When I read the file with ft_read_cifti in Matlab, it returns me the following struct: struct with fields dimord: ‘pos_time' time: [1×200 double] hdr: [1×1 struct] unit: ‘mm' brainstructure: [96854×1 double] brainstructurelabel: {1×21 cell} dim: [91 109 91] pos: [96854×3 double] transform: [4×4 double] dtseries: [96854×200 double But any of those variables is linking the parcel with any brain area. Thank you all in advanced! Joan From mikexcohen at gmail.com Thu Jan 12 13:28:53 2017 From: mikexcohen at gmail.com (Mike X Cohen) Date: Thu, 12 Jan 2017 13:28:53 +0100 Subject: [FieldTrip] CONFERENCE: ICON2017, 5-8 AUGUST, AMSTERDAM Message-ID: [image: Inline image 1]  We are happy to send a reminder for the ICON XIII conference, which will take place on 5-8 August 2017 in Amsterdam (the Netherlands). Amsterdam is an easily-accessible and progressive city. The venue is the Beurs van Berlage, located in downtown Amsterdam and one of the most beautiful conference venues in Europe! Visit the website: http://www.icon2017.org NOTE THE DEADLINES!! 2 January : Registration opened 1 February : Symposia/ask-the-experts/hackathons submissions close! 31 March : Poster submissions close 1 May : Notification of submission acceptance 15 May : Early-bird discount registration ends PRE-CONFERENCE WORKSHOPS/SATELLITES We welcome pre-conference satellites, and will be happy to advertise them on the ICON website. Note that satellites are independent from ICON in terms of organization, registration, and costs. FOLLOW US ON TWITTER For up-to-date announcements before and during the ICON meeting, follow @icon2017 (see also "Media" tab on the website). QUESTIONS ABOUT THE MEETING OR SPONSORSHIP? email icon2017 at icon2017.org http://www.icon2017.org We look forward to seeing you in beautiful Amsterdam! Mike X Cohen and Birte Forstmann -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 105912 bytes Desc: not available URL: From mikexcohen at gmail.com Thu Jan 12 14:37:18 2017 From: mikexcohen at gmail.com (Mike X Cohen) Date: Thu, 12 Jan 2017 14:37:18 +0100 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Interesting discussion here. I think we should take a step back and distinguish between trivial and nontrivial causes and consequences for the skewed distribution. To some extent, the non-normal distribution is simply the result of defining power as a squared distance -- distances are always positive and squaring them means big values become really big. Consider the following: d = randn(10000,1); % random numbers subplot(311), hist(d,500); % their distribution subplot(312), hist(d.^2,500); % "power" distribution, also try a log-scaled y-axis subplot(313), hist(log(d.^2),500); % log-power distribution The fact that power values have a power-law-like distribution is therefore trivial. But this leads to two non-trivial questions: 1) Is this distribution meaningful for brain function (beyond simply the result of taking squared values)? People who study "the log-brain" and fractal-like (or scale-free) organization of brain function would argue that these distributions reveal meaningful insights into brain function, and therefore it is not really an artifact for analyses. In other words, large values are large for a reason; they might not be outliers that we should attempt to compress. 2) Does it matter for real data analysis? I think this is Teresa's initial concern. I'm inclined to think that it doesn't really matter, but that's just based on the idea (hope!) that if it did really matter and the way we do it is wrong, the field would have discovered this a long time ago. On the other hand, this wouldn't be the first time that people have gotten things wrong for decades. I think the best way to investigate #2 would be with simulated data, showing that a "true" effect is missed when not first computing log-power, presumably because the effect was overshadowed by large-amplitude "noise" (but somehow this would have to be physiological noise that wouldn't get rejected during data cleaning). In empirical data, all you'd be able to do is show a difference without knowing the right answer. btw, make sure to be careful with baselining log-power -- any divisions (e.g., dB or percent change) will be unstable/run off to infinity when baseline power is close to zero, i.e., raw power is close to 1. The sign might also get weird. Probably best to use a baseline subtraction. Mike --------------------------------------------><------------------------------------------------ Thanks for the reference. In return, I also recommend reading Ciuparu and Mures an's recent rebuttal: European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, doi:10.1111/ejn.13179 TECHNICAL SPOTLIGHT Sources of bias in single-trial normalization procedures They demonstrate that the positive bias Grandchamp and Delorme warned about with single-trial baseline normalization was, in fact, due to the correlated numerators and denominators in each of the baseline normalization procedures they tested, which was, in turn, caused by the skewed distributions of baseline power values. They demonstrate that this bias is reduced by using a much longer baseline, ideally incorporated into the experimental design, but when that's not possible, stitching together the baselines of many trials. Neither article addresses my specific question of whether it would be even better to log-transform the raw power values before averaging, so I suppose I'll have to test it myself and write my own methods article! 🤓 I will go ahead and incorporate some of these alternative baseline normalization methods in my git fork of FieldTrip as I go along with my own analyses, so let me know if anyone else would find them useful, and I'll submit a pull request to contribute them to the master branch. Thanks for the fruitful discussion, all! ~Teresa On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: > Indeed, in a separate thread with Michael Cohen several months back he > suggested precisely that paper. > > On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" > wrote: > >> I think this paper is relevant to this discussion. >> >> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >> >> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >> >> >> >> On 19 December 2016 at 13:08, Teresa Madsen wrote: >> >>> I appreciate everyone's feedback, but I still wonder if something is >>> being missed. I understand that the non-normally distributed power values >>> may be less of an issue when performing non-parametric stats or even a >>> paired-samples t-test that looks at difference values which may be normal >>> even when the raw data isn't. However, my concern comes into play even >>> before these statistical comparisons are made, whenever any averaging is >>> done to freq-type data across times, frequencies, trials, electrodes, >>> subjects, etc. That means any time any of these configuration options are >>> used for any of these functions, and probably more: >>> >>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>> cfg.avgoverfreq = 'yes'; >>> ft_freqbaseline: cfg.baseline = anything but 'no' >>> >>> In each case, if raw power values are averaged, the result will be >>> positively skewed. Maybe it's not a huge problem if all of the data is >>> treated identically, but the specific case that triggered my concern was in >>> ft_freqbaseline, where the individual time-frequency bins are compared to >>> the mean over time for the baseline period. For example, when using >>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>> data does indeed have a more normal distribution over time, but the mean >>> over the baseline time period is performed *before* the log transform, when >>> the distribution is still highly skewed: >>> >>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>> size(data, 3)]); >>> data = 10*log10(data ./ meanVals); >>> >>> That's what I had originally done when analyzing data for my SfN poster, >>> when I realized the background noise that shouldn't have changed much from >>> baseline was mostly showing a decrease from baseline of about -3dB. >>> >>> Now, I've realized I'm seeing this as more of a problem than others >>> because of another tweak I made, which was to use a long, separate baseline >>> recording to normalize my trial data, rather than a short pre-trial period >>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>> for a baseline power estimate might be okay because overlapping time points >>> in the original data are used to calculate those power values anyway, >>> probably making them less skewed, but also (it seems to me) more arbitrary >>> and prone to error. I already offered my custom function BLnorm.m to one >>> person who was asking about this issue of normalizing to a separate >>> baseline recording, and I would be happy to contribute it to FieldTrip if >>> others would appreciate it. >>> >>> Since a few people suggested using the median, and it is also suggested >>> in Cohen's textbook >>> as >>> an alternative measure of the central tendency for skewed raw power values, >>> I wonder if the simplest fix might be to add an option to select mean or >>> median in each of the functions listed above. Another possibility would be >>> adding an option to transform the power values upon output from >>> ft_freqanalysis. >>> >>> Would anyone else find such changes useful? >>> >>> Thanks, >>> Teresa >>> >>> >>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>> J.Herring at donders.ru.nl> wrote: >>> >>>> In terms of statistics it is the distribution of values that you do the >>>> statistics on that matters. In case of a paired-samples t-test when >>>> comparing two conditions, it is the distribution of difference values that >>>> has to be normally distributed. The distribution of difference values is >>>> often normal given two similarly non-normal distributions, offering no >>>> complications for a regular parametric test. >>>> >>>> >>>> >>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>> normality, so you should have no problem there either. >>>> >>>> >>>> >>>> >>>> >>>> *From:* fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at scie >>>> nce.ru.nl] *On Behalf Of *Alik Widge >>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>> *To:* FieldTrip discussion list >>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>> data analysis >>>> >>>> >>>> >>>> In this, Teresa is right and we have observed this in our own EEG data >>>> -- depending on one's level of noise and number of trials/patients, the >>>> mean can be a very poor estimator of central tendency. My students are >>>> still arguing about what we really want to do with it, but at least one of >>>> them has shifted to using the median as a matter of course for baseline >>>> normalization. >>>> >>>> >>>> Alik Widge >>>> alik.widge at gmail.com >>>> (206) 866-5435 >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>> wrote: >>>> >>>> That may very well be true; to be honest, I haven't looked that deeply >>>> into the stats offerings yet. However, my plan is to express each >>>> electrode's experimental data in terms of change from their respective >>>> baseline recordings before attempting any group averaging or statistical >>>> testing, and this problem shows up first in the baseline correction step, >>>> where FieldTrip averages raw power over time. >>>> >>>> ~Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>> statistics implemented by fieldtrip, the data does not need to be normally >>>> distributed. >>>> >>>> >>>> >>>> On 12 December 2016 at 13:39, Teresa Madsen wrote: >>>> >>>> No, sorry, that's not what I meant, but thanks for giving me the >>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>> across frequencies, but the distribution across time (and according to the >>>> poster, also across space), also has an extremely skewed, negative >>>> exponential distribution. I probably confused everyone by trying to show >>>> too much data in my figure, but each color represents the distribution of >>>> power values for a single frequency over time, using a histogram and a line >>>> above with circles at the mean +/- one standard deviation. >>>> >>>> My main point was that the mean is not representative of the central >>>> tendency of such an asymmetrical distribution of power values over time. >>>> It's even more obvious which is more representative of their actual >>>> distributions when I plot e^mean(logpower) on the raw plot and >>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>> busy and confusing. >>>> >>>> I hope that helps, >>>> Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Hi Teresa, >>>> >>>> >>>> >>>> I think what you are discussing is the 1/f power scaling of the power >>>> spectrum. This is one of the reasons that comparisons are made within >>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>> as such the assumption is that within bands there should be a relative >>>> change against baseline and this is what the statistics are performed on. >>>> That is, baseline correction is assumed to be the mean for a specific >>>> frequency and not a mean across frequencies. >>>> >>>> >>>> >>>> And this leads to another point that when you are selecting a >>>> frequency range to do the non-parametric statistics on you should not do >>>> 1-64 Hz but break it up based on the bands. >>>> >>>> >>>> >>>> Hope my interpretation of your point is correct. I sent in >>>> individually, as I wanted to ensure I followed your point. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Nick >>>> >>>> >>>> >>>> >>>> >>>> On 12 December 2016 at 08:23, Teresa Madsen wrote: >>>> >>>> FieldTrippers, >>>> >>>> >>>> >>>> While analyzing my data for the annual Society for Neuroscience >>>> meeting, I developed a concern that was quickly validated by another poster >>>> (full abstract copied and linked below) focusing on the root of the >>>> problem: neural oscillatory power is not normally distributed across time, >>>> frequency, or space. The specific problem I had encountered was in >>>> baseline-correcting my experimental data, where, regardless of >>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>> However, I found that the distribution of raw power over time is so skewed >>>> that the mean was not a reasonable approximation of the central tendency of >>>> the baseline power, so it made most of my experimental data look like it >>>> had decreased power compared to baseline. The more I think about it, the >>>> more I realize that averaging is everywhere in the way we analyze neural >>>> oscillations (across time points, frequency bins, electrodes, trials, >>>> subjects, etc.), and many of the standard statistics people use also rely >>>> on assumptions of normality. >>>> >>>> >>>> >>>> The most obvious solution for me was to log transform the data first, >>>> as it appears to be fairly log normal, and I always use log-scale >>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>> that this would at least "restore (some) symmetry to the error >>>> distribution." I used a natural log transform, sort of arbitrarily to >>>> differentiate from the standard decibel transform included in FieldTrip as >>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>> across several frequency bands (using power values from a wavelet >>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>> cortex). The lines at the top represent the mean +/- one standard >>>> deviation for each frequency band, and you can see how those descriptive >>>> stats are much more representative of the actual distributions in the log >>>> scale. >>>> >>>> >>>> >>>> >>>> ​​ >>>> >>>> For my analysis, I also calculated a z-score on the log transformed >>>> power to assess how my experimental data compared to the variability of the >>>> noise in a long baseline recording from before conditioning, rather than a >>>> short pre-trial baseline period, since I find that more informative than >>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>> functions I wrote for this if people think it would be a useful addition to >>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>> poster, if anyone wants more detail - I just didn't want to make this email >>>> too big. >>>> >>>> >>>> >>>> Mostly, I'm just hoping to start some discussion here as to how to >>>> address this. I searched the wiki >>>> , listserv >>>> < https://mailman.science.ru.nl/pipermail/fieldtrip/2006-December/000773.html> >>>> archives >>>> < https://mailman.science.ru.nl/pipermail/fieldtrip/2010-March/002718.html>, >>>> and bugzilla >>>> for >>>> anything related and came up with a few topics surrounding normalization >>>> and baseline correction, but only skirting this issue. It seems important, >>>> so I want to find out whether others agree with my approach or already have >>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>> be changed or just documentation added, or what? >>>> >>>> >>>> >>>> Thanks for any insights, >>>> >>>> Teresa >>>> >>>> >>>> >>>> >>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>> across time >>>> >>>> >>>> *Authors* >>>> >>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>> Cognitive Sci., UCSD, San Diego, CA >>>> >>>> *Disclosures* >>>> >>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>> >>>> *Abstract* >>>> >>>> Neural oscillations are important in organizing activity across the >>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>> to numerous disease states. Oscillations are known to vary by frequency and >>>> amplitude across time and between different brain regions; however, this >>>> variability has never been well characterized. We examined human and animal >>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>> distribution of power and frequency across time, space and species. We >>>> report that between data types, subjects, frequencies, electrodes, and >>>> time, an inverse power law, or negative exponential distribution, is >>>> present in all recordings. This is contrary to, and not compatible with, >>>> the Gaussian noise assumption made in many digital signal processing >>>> techniques. The statistical assumptions underlying common algorithms for >>>> power spectral estimation, such as Welch's method, are being violated >>>> resulting in non-trivial misestimates of oscillatory power. Different >>>> statistical approaches are warranted. >>>> >>>> >>>> >>>> -- >>>> >>>> Teresa E. Madsen, PhD >>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>> analysis >>>> >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> >>>> Emory University >>>> >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> >>>> (770) 296-9119 >>>> >>>> braingirl at gmail.com >>>> >>>> https://www.linkedin.com/in/temadsen >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Teresa E. Madsen, PhD >>> Division of Behavioral Neuroscience and Psychiatric Disorders >>> Yerkes National Primate Research Center >>> Emory University >>> Rainnie Lab, NSB 5233 >>> 954 Gatewood Rd. NE >>> Atlanta, GA 30329 >>> (770) 296-9119 >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Nicholas Peatfield, PhD >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -- Mike X Cohen, PhD mikexcohen.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From seymourr at aston.ac.uk Thu Jan 12 14:59:32 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Thu, 12 Jan 2017 13:59:32 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data Message-ID: Hi Joan, To me your dtseries.nii looks like it has been parcellated/segmented in time, not space, as the time field is a 1x200 array. You might also want to look at brain structurelabel field and how this relates to the brainstucture field. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Thu Jan 12 16:17:11 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Thu, 12 Jan 2017 15:17:11 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> , <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Message-ID: Thank you for your help Jan. Indeed, it was as simple as adding 'cfg.keeptrials = 'yes'' in my initial time-frequency analyses. Sorry to have encumbered you with what turned out to be a very trivial problem. Your help is much appreciated! K ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 12 January 2017 11:19 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Jan 12 17:06:05 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 12 Jan 2017 16:06:05 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Message-ID: <15BD5312-6EEB-453C-8D65-CB1C8D2176BF@donders.ru.nl> No worries, Kelly, but just to be sure: from your initial e-mail I got the impression that you wanted to do statistical inference across subjects, not across trials (within a signle subject). Specifying cfg.keeptrials before calling ft_freqanalysis should be done for the latter, not for the former type of statistical inference. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 12 Jan 2017, at 16:17, Murphy, Kelly (Research Student) > wrote: Thank you for your help Jan. Indeed, it was as simple as adding 'cfg.keeptrials = 'yes'' in my initial time-frequency analyses. Sorry to have encumbered you with what turned out to be a very trivial problem. Your help is much appreciated! K ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 12 January 2017 11:19 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From mona at sdsc.edu Fri Jan 13 01:04:02 2017 From: mona at sdsc.edu (Wong-Barnum, Mona) Date: Fri, 13 Jan 2017 00:04:02 +0000 Subject: [FieldTrip] NeuroMag 389 channel map Message-ID: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Hello fellow NeuroMag users: Does someone have a location map of the 389 channels on the head? I have been searching but haven’t found anything. These channels are labelled as MEG 0013, MEG 0012, …, MEG 2641, STI 001, STI 002, …, STI 016, EEG 001, EEG 002, …, EEG 060, EOG 061, EOG 062, ECG 063, EMG 064, EEG 065, EEG 066, …, EEG 074 Any help is appreciated. thanks, Mona ********************************************* Mona Wong Web & Mobile Application Developer San Diego Supercomputer Center Believing we are in control is an illusion that brings suffering. ********************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.hauswald at me.com Fri Jan 13 09:12:17 2017 From: anne.hauswald at me.com (anne Hauswald) Date: Fri, 13 Jan 2017 09:12:17 +0100 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Message-ID: Dear Mona, generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. For other purposes you might need the grad structure (data.grad) which is a result of ft_preprocessing and contains information like channel orientation, channel position, etc. for all 306 MEG channels. Hope this helps Best Anne > Am 13.01.2017 um 01:04 schrieb Wong-Barnum, Mona : > > > Hello fellow NeuroMag users: > > Does someone have a location map of the 389 channels on the head? I have been searching but haven’t found anything. These channels are labelled as MEG 0013, MEG 0012, …, MEG 2641, STI 001, STI 002, …, STI 016, EEG 001, EEG 002, …, EEG 060, EOG 061, EOG 062, ECG 063, EMG 064, EEG 065, EEG 066, …, EEG 074 > > Any help is appreciated. > > thanks, > Mona > > ********************************************* > Mona Wong > Web & Mobile Application Developer > San Diego Supercomputer Center > > Believing we are in control is an > illusion that brings suffering. > ********************************************* > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From m.p.craddock at leeds.ac.uk Fri Jan 13 15:51:32 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Fri, 13 Jan 2017 14:51:32 +0000 Subject: [FieldTrip] impact of skewed power distributions on data analysis In-Reply-To: References: Message-ID: Hi all, I'm fiddling around with simulations at the moment but not got a lot of free time, and every time I do fiddle with them the more complicated I seem to make them... correct me if i'm wrong, but there are a couple of different issues here. About the skewness of the distribution - you're not usually comparing two skewed distributions statistically (which even then would probably be ok if they're similary skewed), usually it's a bunch of means from those distributions, and the distribution of the means will often be normally distributed (as will their differences), and thus ok for parametric stats. So the main problem is really whether the mean is a good summary statistic for capturing differences between the underlying distributions or not (similar debates about reaction times) - it's certainly not robust to outliers. Median might be better in some ways, but it's a biased estimator of the population median and might have consequences on stat power - that's one for the simulations at some point. Taking the log first won't necessarily help. As the code Michael Cohen provides shows, taking the log can still result in skewed distributions - power is right-skewed but its log is left-skewed. Taking the square root would obviously be better in this case but that's because it just returns it to the original unsquared normal distribution - whether that's true of real data needs checking out. In addition if you take the log you're no longer testing the same thing when you compare the means - you're testing the geometric mean instead of the arithmetic mean. Differences in the arithmetic means across conditions will not necessarily translate into differences in the geometric means and vice versa. If you use a subtractive baseline, using the median or mean of power will only change what constant you subtract from the data. If you baseline correct using the average of all trials rather than condition specific baselines, it should make no difference to the stats if you use the mean or the median of baseline power (or indeed if you don't use baseline correction at all). If you test differences across electrodes as well as condition, and use electrode but not condition specific baselines - which seems reasonable, since you might expect bigger baseline differences across than within electrodes, it'll only change the main electrode effect, not the condition effect or the interaction between condition and electrode. If you use condition and electrode specific baselines, then it influences *everything*, and you also no longer know if the differences between conditions/electrodes are due to baseline or post-stimulus differences. Using the median over the mean will change the stats if you use divisive baselines, but whether that's a good or bad difference is another question for simulations. Cheers, Matt On 12/01/2017 13:37, Mike X Cohen wrote: > Interesting discussion here. I think we should take a step back and > distinguish between trivial and nontrivial causes and consequences for > the skewed distribution. To some extent, the non-normal distribution is > simply the result of defining power as a squared distance -- distances > are always positive and squaring them means big values become really > big. Consider the following: > > d = randn(10000,1); % random numbers > subplot(311), hist(d,500); % their distribution > subplot(312), hist(d.^2,500); % "power" distribution, also try a > log-scaled y-axis > subplot(313), hist(log(d.^2),500); % log-power distribution > > The fact that power values have a power-law-like distribution is > therefore trivial. > > But this leads to two non-trivial questions: > 1) Is this distribution meaningful for brain function (beyond simply the > result of taking squared values)? People who study "the log-brain" and > fractal-like (or scale-free) organization of brain function would argue > that these distributions reveal meaningful insights into brain function, > and therefore it is not really an artifact for analyses. In other words, > large values are large for a reason; they might not be outliers that we > should attempt to compress. > > 2) Does it matter for real data analysis? I think this is Teresa's > initial concern. I'm inclined to think that it doesn't really matter, > but that's just based on the idea (hope!) that if it did really matter > and the way we do it is wrong, the field would have discovered this a > long time ago. On the other hand, this wouldn't be the first time that > people have gotten things wrong for decades. > > I think the best way to investigate #2 would be with simulated data, > showing that a "true" effect is missed when not first computing > log-power, presumably because the effect was overshadowed by > large-amplitude "noise" (but somehow this would have to be physiological > noise that wouldn't get rejected during data cleaning). In empirical > data, all you'd be able to do is show a difference without knowing the > right answer. > > btw, make sure to be careful with baselining log-power -- any divisions > (e.g., dB or percent change) will be unstable/run off to infinity when > baseline power is close to zero, i.e., raw power is close to 1. The sign > might also get weird. Probably best to use a baseline subtraction. > > Mike > > > > > > --------------------------------------------><------------------------------------------------ > > Thanks for the reference. In return, I also recommend reading Ciuparu and > Mures an's recent rebuttal: > > European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, > doi:10.1111/ejn.13179 > TECHNICAL SPOTLIGHT > Sources of bias in single-trial normalization procedures > > They demonstrate that the positive bias Grandchamp and Delorme warned about > with single-trial baseline normalization was, in fact, due to the > correlated numerators and denominators in each of the baseline > normalization procedures they tested, which was, in turn, caused by the > skewed distributions of baseline power values. They demonstrate that this > bias is reduced by using a much longer baseline, ideally incorporated into > the experimental design, but when that's not possible, stitching together > the baselines of many trials. > > Neither article addresses my specific question of whether it would be even > better to log-transform the raw power values before averaging, so I suppose > I'll have to test it myself and write my own methods article! 🤓 > > I will go ahead and incorporate some of these alternative baseline > normalization methods in my git fork of FieldTrip as I go along with my own > analyses, so let me know if anyone else would find them useful, and I'll > submit a pull request to contribute them to the master branch. > > Thanks for the fruitful discussion, all! > ~Teresa > > > On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge > wrote: > >> Indeed, in a separate thread with Michael Cohen several months back he >> suggested precisely that paper. >> >> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" gmail.com > >> wrote: >> >>> I think this paper is relevant to this discussion. >>> >>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy > Trials. *Frontiers >>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>> >>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>> >>> >>> >>> On 19 December 2016 at 13:08, Teresa Madsen > wrote: >>> >>>> I appreciate everyone's feedback, but I still wonder if something is >>>> being missed. I understand that the non-normally distributed power > values >>>> may be less of an issue when performing non-parametric stats or even a >>>> paired-samples t-test that looks at difference values which may be > normal >>>> even when the raw data isn't. However, my concern comes into play even >>>> before these statistical comparisons are made, whenever any averaging is >>>> done to freq-type data across times, frequencies, trials, electrodes, >>>> subjects, etc. That means any time any of these configuration > options are >>>> used for any of these functions, and probably more: >>>> >>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>> cfg.avgoverfreq = 'yes'; >>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>> >>>> In each case, if raw power values are averaged, the result will be >>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>> treated identically, but the specific case that triggered my concern > was in >>>> ft_freqbaseline, where the individual time-frequency bins are > compared to >>>> the mean over time for the baseline period. For example, when using >>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output > freq >>>> data does indeed have a more normal distribution over time, but the mean >>>> over the baseline time period is performed *before* the log > transform, when >>>> the distribution is still highly skewed: >>>> >>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>> size(data, 3)]); >>>> data = 10*log10(data ./ meanVals); >>>> >>>> That's what I had originally done when analyzing data for my SfN poster, >>>> when I realized the background noise that shouldn't have changed > much from >>>> baseline was mostly showing a decrease from baseline of about -3dB. >>>> >>>> Now, I've realized I'm seeing this as more of a problem than others >>>> because of another tweak I made, which was to use a long, separate > baseline >>>> recording to normalize my trial data, rather than a short pre-trial > period >>>> as ft_freqbaseline is designed to do. Averaging a few hundred > milliseconds >>>> for a baseline power estimate might be okay because overlapping time > points >>>> in the original data are used to calculate those power values anyway, >>>> probably making them less skewed, but also (it seems to me) more > arbitrary >>>> and prone to error. I already offered my custom function BLnorm.m > to one >>>> person who was asking about this issue of normalizing to a separate >>>> baseline recording, and I would be happy to contribute it to > FieldTrip if >>>> others would appreciate it. >>>> >>>> Since a few people suggested using the median, and it is also suggested >>>> in Cohen's textbook >>>> as >>>> an alternative measure of the central tendency for skewed raw power > values, >>>> I wonder if the simplest fix might be to add an option to select mean or >>>> median in each of the functions listed above. Another possibility > would be >>>> adding an option to transform the power values upon output from >>>> ft_freqanalysis. >>>> >>>> Would anyone else find such changes useful? >>>> >>>> Thanks, >>>> Teresa >>>> >>>> >>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>> J.Herring at donders.ru.nl > wrote: >>>> >>>>> In terms of statistics it is the distribution of values that you do the >>>>> statistics on that matters. In case of a paired-samples t-test when >>>>> comparing two conditions, it is the distribution of difference > values that >>>>> has to be normally distributed. The distribution of difference > values is >>>>> often normal given two similarly non-normal distributions, offering no >>>>> complications for a regular parametric test. >>>>> >>>>> >>>>> >>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>> normality, so you should have no problem there either. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* fieldtrip-bounces at science.ru.nl > [mailto:fieldtrip-bounces at scie >>>>> nce.ru.nl ] *On Behalf Of *Alik Widge >>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>> *To:* FieldTrip discussion list > >>>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>> data analysis >>>>> >>>>> >>>>> >>>>> In this, Teresa is right and we have observed this in our own EEG data >>>>> -- depending on one's level of noise and number of trials/patients, the >>>>> mean can be a very poor estimator of central tendency. My students are >>>>> still arguing about what we really want to do with it, but at least > one of >>>>> them has shifted to using the median as a matter of course for baseline >>>>> normalization. >>>>> >>>>> >>>>> Alik Widge >>>>> alik.widge at gmail.com >>>>> (206) 866-5435 >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen emory.edu > >>>>> wrote: >>>>> >>>>> That may very well be true; to be honest, I haven't looked that deeply >>>>> into the stats offerings yet. However, my plan is to express each >>>>> electrode's experimental data in terms of change from their respective >>>>> baseline recordings before attempting any group averaging or > statistical >>>>> testing, and this problem shows up first in the baseline correction > step, >>>>> where FieldTrip averages raw power over time. >>>>> >>>>> ~Teresa >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>> nick.peatfield at gmail.com > wrote: >>>>> >>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>> statistics implemented by fieldtrip, the data does not need to be > normally >>>>> distributed. >>>>> >>>>> >>>>> >>>>> On 12 December 2016 at 13:39, Teresa Madsen > wrote: >>>>> >>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>> opportunity to clarify. Of course everyone is familiar with the 1/f > pattern >>>>> across frequencies, but the distribution across time (and according > to the >>>>> poster, also across space), also has an extremely skewed, negative >>>>> exponential distribution. I probably confused everyone by trying to > show >>>>> too much data in my figure, but each color represents the > distribution of >>>>> power values for a single frequency over time, using a histogram > and a line >>>>> above with circles at the mean +/- one standard deviation. >>>>> >>>>> My main point was that the mean is not representative of the central >>>>> tendency of such an asymmetrical distribution of power values over > time. >>>>> It's even more obvious which is more representative of their actual >>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>>> busy and confusing. >>>>> >>>>> I hope that helps, >>>>> Teresa >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>> nick.peatfield at gmail.com > wrote: >>>>> >>>>> Hi Teresa, >>>>> >>>>> >>>>> >>>>> I think what you are discussing is the 1/f power scaling of the power >>>>> spectrum. This is one of the reasons that comparisons are made within >>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to > gamma), >>>>> as such the assumption is that within bands there should be a relative >>>>> change against baseline and this is what the statistics are > performed on. >>>>> That is, baseline correction is assumed to be the mean for a specific >>>>> frequency and not a mean across frequencies. >>>>> >>>>> >>>>> >>>>> And this leads to another point that when you are selecting a >>>>> frequency range to do the non-parametric statistics on you should > not do >>>>> 1-64 Hz but break it up based on the bands. >>>>> >>>>> >>>>> >>>>> Hope my interpretation of your point is correct. I sent in >>>>> individually, as I wanted to ensure I followed your point. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> Nick >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12 December 2016 at 08:23, Teresa Madsen > wrote: >>>>> >>>>> FieldTrippers, >>>>> >>>>> >>>>> >>>>> While analyzing my data for the annual Society for Neuroscience >>>>> meeting, I developed a concern that was quickly validated by > another poster >>>>> (full abstract copied and linked below) focusing on the root of the >>>>> problem: neural oscillatory power is not normally distributed > across time, >>>>> frequency, or space. The specific problem I had encountered was in >>>>> baseline-correcting my experimental data, where, regardless of >>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>> However, I found that the distribution of raw power over time is so > skewed >>>>> that the mean was not a reasonable approximation of the central > tendency of >>>>> the baseline power, so it made most of my experimental data look > like it >>>>> had decreased power compared to baseline. The more I think about > it, the >>>>> more I realize that averaging is everywhere in the way we analyze > neural >>>>> oscillations (across time points, frequency bins, electrodes, trials, >>>>> subjects, etc.), and many of the standard statistics people use > also rely >>>>> on assumptions of normality. >>>>> >>>>> >>>>> >>>>> The most obvious solution for me was to log transform the data first, >>>>> as it appears to be fairly log normal, and I always use log-scale >>>>> visualizations anyway. Erik Peterson, middle author on the poster, > agreed >>>>> that this would at least "restore (some) symmetry to the error >>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>> differentiate from the standard decibel transform included in > FieldTrip as >>>>> cfg.baselinetype = 'db'. The following figures compare the 2 > distributions >>>>> across several frequency bands (using power values from a wavelet >>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>> cortex). The lines at the top represent the mean +/- one standard >>>>> deviation for each frequency band, and you can see how those > descriptive >>>>> stats are much more representative of the actual distributions in > the log >>>>> scale. >>>>> >>>>> >>>>> >>>>> >>>>> ​​ >>>>> >>>>> For my analysis, I also calculated a z-score on the log transformed >>>>> power to assess how my experimental data compared to the > variability of the >>>>> noise in a long baseline recording from before conditioning, rather > than a >>>>> short pre-trial baseline period, since I find that more informative > than >>>>> any of FieldTrip's built-in baseline types. I'm happy to share the > custom >>>>> functions I wrote for this if people think it would be a useful > addition to >>>>> FieldTrip. I can also share more about my analysis and/or a copy > of the >>>>> poster, if anyone wants more detail - I just didn't want to make > this email >>>>> too big. >>>>> >>>>> >>>>> >>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>> address this. I searched the wiki >>>>> , listserv >>>>> > >>>>> archives >>>>> > , >>>>> and bugzilla >>>>> for >>>>> anything related and came up with a few topics surrounding > normalization >>>>> and baseline correction, but only skirting this issue. It seems > important, >>>>> so I want to find out whether others agree with my approach or > already have >>>>> other ways of avoiding the problem, and whether FieldTrip's code > needs to >>>>> be changed or just documentation added, or what? >>>>> >>>>> >>>>> >>>>> Thanks for any insights, >>>>> >>>>> Teresa >>>>> >>>>> >>>>> >>>>> >>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>> across time >>>>> >>>>> >>>>> *Authors* >>>>> >>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>> Cognitive Sci., UCSD, San Diego, CA >>>>> >>>>> *Disclosures* >>>>> >>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>> >>>>> *Abstract* >>>>> >>>>> Neural oscillations are important in organizing activity across the >>>>> human brain in healthy cognition, while oscillatory disruptions are > linked >>>>> to numerous disease states. Oscillations are known to vary by > frequency and >>>>> amplitude across time and between different brain regions; however, > this >>>>> variability has never been well characterized. We examined human > and animal >>>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>> distribution of power and frequency across time, space and species. We >>>>> report that between data types, subjects, frequencies, electrodes, and >>>>> time, an inverse power law, or negative exponential distribution, is >>>>> present in all recordings. This is contrary to, and not compatible > with, >>>>> the Gaussian noise assumption made in many digital signal processing >>>>> techniques. The statistical assumptions underlying common > algorithms for >>>>> power spectral estimation, such as Welch's method, are being violated >>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>> statistical approaches are warranted. >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Teresa E. Madsen, PhD >>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>> analysis >>>>> >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> >>>>> Emory University >>>>> >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> >>>>> (770) 296-9119 >>>>> >>>>> braingirl at gmail.com >>>>> >>>>> https://www.linkedin.com/in/temadsen >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Nicholas Peatfield, PhD >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Nicholas Peatfield, PhD >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> >>>> >>>> -- >>>> Teresa E. Madsen, PhD >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> Emory University >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> (770) 296-9119 >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Nicholas Peatfield, PhD >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Teresa E. Madsen, PhD > Division of Behavioral Neuroscience and Psychiatric Disorders > Yerkes National Primate Research Center > Emory University > Rainnie Lab, NSB 5233 > 954 Gatewood Rd. NE > Atlanta, GA 30329 > (770) 296-9119 > > -- > Mike X Cohen, PhD > mikexcohen.com > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From mona at sdsc.edu Fri Jan 13 19:20:06 2017 From: mona at sdsc.edu (Wong-Barnum, Mona) Date: Fri, 13 Jan 2017 18:20:06 +0000 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Message-ID: <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> Hi Anne: Thank you so much for your reply. > generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. Is there an explanation of the 5 different neuromag layout files? I have the following: neuromag306all.lay neuromag306eeg1005_natmeg.lay neuromag306planar.lay neuromag306cmb.lay neuromag306mag.lay I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay files are for. I found http://www.fieldtriptoolbox.org/tutorial/layout page but if there is anything that’s useful, please point me to it. thanks, Mona ********************************************* Mona Wong Web & Mobile Application Developer San Diego Supercomputer Center "Believe you can and you are half way there." -- Theodore Roosevelt ********************************************* From acskwara at ucdavis.edu Sat Jan 14 02:14:20 2017 From: acskwara at ucdavis.edu (Alea Skwara) Date: Fri, 13 Jan 2017 17:14:20 -0800 Subject: [FieldTrip] Downloading sample data from the Fieldtrip ftp Message-ID: Hi All, I've been trying (unsuccessfully) to download some of the tutorial sample data from the fieldtrip ftp server. I tried several different ftp clients and was finally able to connect and view the files using Cyberduck, but when I actually attempt to download anything the connection fails. Has anyone had a similar problem and found a solution? Thank you, Alea -- Alea C. Skwara Graduate Student | Saron Lab http://mindbrain.ucdavis.edu/labs/Saron Center for Mind and Brain | University of California, Davis 267 Cousteau Place | Davis CA 95616 Cell: (828) 273-8595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From na.so.ir at gmail.com Sat Jan 14 15:12:49 2017 From: na.so.ir at gmail.com (Narjes Soltani) Date: Sat, 14 Jan 2017 17:42:49 +0330 Subject: [FieldTrip] error while removing ecg Message-ID: Dear all Hi, I am trying to remove ecg artifact from some neuromag MEG data using the “ ft_artifact_ecg” method, but unfortunately I encounter the following error: "Undefined function or variable "labelmlt"." When I traced the code, I found that the error is raised from “ft_channelselection” method. In this method, line 340, the value of variable "findmlt" is set to some index, in my code to 1, via the following code snippet: findmlt = find(strcmp(channel, 'MLT')); Then in line 428 of method “ft_channelselection”, the following line of code produces the above error: if findmlt, channel = [channel; labelmlt]; end I found that the only place in method “ft_channelselection” where variable “ labelmlt” is set is in line 249 which is not accessible in my code as it seems to only be accessible for the CTF file format. To solve the problem, I just copied lien 249 at the end of the switch case statements, i.e. after line 298 as follows: labelmlt = datachannel(strncmp('MLT', *datachannel*, length('MLT'))); and I replaced the bold “*datachannel*" variable with “channel” variable and this way the error was solved, but I am not really sure what I have done is correct or not. Would you please help me with this issue? I had the same problem with labelmrt and I solved it in the same way. Besides, I wonder if there is any better and more straightforward way to remove ECG artifact as even after solving the above errors, I have to manually answer to the following line at each run: current zvalue threshold = 3.000 keep the current value (y/n) ? Best, Narjes -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfibm at yahoo.com Mon Jan 16 09:08:02 2017 From: mfibm at yahoo.com (Mohamed Fawzy) Date: Mon, 16 Jan 2017 08:08:02 +0000 (UTC) Subject: [FieldTrip] i need help References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> Message-ID: <1609558455.3967220.1484554082497@mail.yahoo.com> hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing,Faculty of Computers and Informatics,Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14Mobile:00201220577416Tel:0020133188266    Fax:0020133188256E-mail: mohamed.issa at fci.bu.edu.eg ,  mfibm at yahoo.com,  -------------- next part -------------- An HTML attachment was scrubbed... URL: From stan.vanpelt at donders.ru.nl Mon Jan 16 09:27:55 2017 From: stan.vanpelt at donders.ru.nl (Pelt, S. van (Stan)) Date: Mon, 16 Jan 2017 08:27:55 +0000 Subject: [FieldTrip] i need help In-Reply-To: <1609558455.3967220.1484554082497@mail.yahoo.com> References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> <1609558455.3967220.1484554082497@mail.yahoo.com> Message-ID: <7CCA2706D7A4DA45931A892DF3C2894C521E1517@exprd03.hosting.ru.nl> Dear Mohamed, Fieldtrip is not stand-alone software, but a toolbox for Matlab. As such, it is platform-independent, but requires you to have a (Windows/Mac/Linux version of) Matlab installed on your computer. FieldTrip is freeware, but Matlab requires a license. Best, Stan -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour Radboud University Montessorilaan 3, B.01.34 6525 HR Nijmegen, the Netherlands tel: +31 24 3616288 From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Mohamed Fawzy Sent: maandag 16 januari 2017 9:08 To: fieldtrip at science.ru.nl Subject: [FieldTrip] i need help hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing, Faculty of Computers and Informatics, Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14 Mobile:00201220577416 Tel:0020133188266 Fax:0020133188256 E-mail: mohamed.issa at fci.bu.edu.eg , mfibm at yahoo.com, -------------- next part -------------- An HTML attachment was scrubbed... URL: From litvak.vladimir at gmail.com Mon Jan 16 11:36:11 2017 From: litvak.vladimir at gmail.com (Vladimir Litvak) Date: Mon, 16 Jan 2017 10:36:11 +0000 Subject: [FieldTrip] post-doc for cryogen-free MEG system Message-ID: ---------- Forwarded message ---------- From: Barnes, Gareth Date: Mon, Jan 16, 2017 at 9:22 AM Subject: [SPM] post-doc for cryogen-free MEG system To: SPM at jiscmail.ac.uk Dear All We’re looking for someone to join our team working on the development of a new cryogen-free MEG system (see below). Could you please pass this on to anyone who might be interested. Best Gareth UCL link: https://atsv7.wcn.co.uk/search_engine/jobs.cgi?SID= amNvZGU9MTYyMzE0MiZ2dF90ZW1wbGF0ZT05NjUmb3duZXI9NTA0MTE3OCZv d25lcnR5cGU9ZmFpciZicmFuZF9pZD0wJnZhY194dHJhNTA0MTE3OC41MF81 MDQxMTc4PTkyNzg2JnZhY3R5cGU9MTI3NiZwb3N0aW5nX2NvZGU9MjI0JnJl cXNpZz0xNDg0NTU3MjM5LWFlMGZlZDk2OTk2MDUyNjAwM2NiNTRlODM0MmEzMWE0YTA0NmY1ZDY= Research Associate , - Ref:1623142 *UCL Department / Division* UCL Institute of Neurology *Specific unit / Sub department* Wellcome Trust Centre for Neuroimaging *Grade* 7 *Hours* Full Time *Salary (inclusive of London allowance)* £34,056 - £36,923 per annum *Duties and Responsibilities* The Wellcome Trust Centre for Neuroimaging, UCL Institute of Neurology, is seeking to recruit a post-doctoral research fellow in the field of magnetoencephalography (MEG). This is part of a Wellcome-funded programme, in collaboration with the University of Nottingham, to develop a new generation of MEG system based on a optically pumped magnetometers (OPMs). Optically pumped magnetometers are ultra-sensitive magnetic field detectors which can operate at room temperature, and so can be brought closer to the head than the cryogenically-cooled field detectors that are currently used in MEG imaging. The aim is to build a multi-channel OPM MEG device which can be worn on the head allowing the subject to move freely in an open and natural environment. The prospect of an affordable and wearable system has a number of exciting applications including novel paediatric and clinical imaging systems. The post is available from 1st April 2017 and is funded by a grant from the Wellcome Trust for three years in the first instance. *Key Requirements* Applicants should have a PhD in Neuroscience or related area and strong proven expertise in physics / engineering or related discipline. Strong expertise in programming, ideally Matlab, is essential, as is an excellent academic record with evidence of independent, creative work, a strong mathematical background, expertise in modelling / simulation and experience in M/EEG. It would also be desirable to have experience with one or more M/EEG software packages and the use of different volume conductor models. *Further Details* A job description and person specification can be accessed at the bottom of this page. To apply for the vacancy please click on the ‘Apply Now’ button below. If you have any queries regarding the application process, please contact Samantha Robinson, HR Officer, UCL Institute of Neurology - *IoN.HRAdmin at ucl.ac.uk* For informal enquiries please contact Gareth Barnes (*g.barnes at ucl.ac.uk* ) *UCL Taking Action for Equality* *Closing Date* 12 Feb 2017 *Our department holds an Athena SWAN Silver award, in recognition of our commitment and success in addressing gender equality.* *This appointment is subject to UCL Terms and Conditions of Service for Research and Support Staff. Please use these links to find out more about the UCL Terms and Conditions related to this job, employee benefits that we offer and further information about UCL .* *JD and Person Specification* -------------- next part -------------- An HTML attachment was scrubbed... URL: From Darren.Price at mrc-cbu.cam.ac.uk Mon Jan 16 11:47:57 2017 From: Darren.Price at mrc-cbu.cam.ac.uk (Darren Price) Date: Mon, 16 Jan 2017 10:47:57 +0000 Subject: [FieldTrip] i need help In-Reply-To: <1609558455.3967220.1484554082497@mail.yahoo.com> References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> <1609558455.3967220.1484554082497@mail.yahoo.com> Message-ID: Hi You may need to recompile the mex files if you want to use more than 2GB of RAM. http://www.fieldtriptoolbox.org/faq/how_can_i_compile_the_mex_files_on_64_bit_windows You could also use something like VMware player to create a virtual operating system within windows. However, you would need a powerful computer with lots of spare RAM and CPUs cores for this option as it tends to be much slower. Another obvious solution is to dual boot your computer with Linux, but that’s not really what you’re asking is it? Is there a specific reason you would like to use Windows? Darren ------------------------------------------------------- Dr. Darren Price Investigator Scientist and Cam-CAN Data Manager MRC Cognition & Brain Sciences Unit 15 Chaucer Road Cambridge, CB2 7EF England EMAIL: darren.price at mrc-cbu.cam.ac.uk URL: http://www.mrc-cbu.cam.ac.uk/people/darren.price TEL +44 (0)1223 355 294 x202 FAX +44 (0)1223 359 062 MOB +44 (0)7717822431 ------------------------------------------------------- From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Mohamed Fawzy Sent: 16 January 2017 08:08 To: fieldtrip at science.ru.nl Subject: [FieldTrip] i need help hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing, Faculty of Computers and Informatics, Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14 Mobile:00201220577416 Tel:0020133188266 Fax:0020133188256 E-mail: mohamed.issa at fci.bu.edu.eg , mfibm at yahoo.com, -------------- next part -------------- An HTML attachment was scrubbed... URL: From giskeopheim at nru.dk Tue Jan 17 15:59:48 2017 From: giskeopheim at nru.dk (giskeopheim) Date: Tue, 17 Jan 2017 15:59:48 +0100 Subject: [FieldTrip] Fwd: Wavelet-transform based SAM beamforming In-Reply-To: <03f6d3b27e0a09a36897a8a82b7127b4@nru.dk> References: <03f6d3b27e0a09a36897a8a82b7127b4@nru.dk> Message-ID: Dear fieldtrip experts, I hope it is okay to ask a more general "pipeline" question, instead of one specifically related to some issue with code, since I do not know anyone who has experience with it. Is there currently any way to perform wavelet-based SAM beamforming with fieldtrip? I'm thinking something like 'cfg.wavelet' = 'yes' during preprocessing.., or, by all means, a way to convert output from transform functions to desired structs to use in both averaging and analysis functions? Transforming with ft_specest_wavelet to get the convolution in the time domain, gives a 'chan X freqoi X timeoi complex double', which of course is not the struct neccessary for performing the beamforming. Using the ft_freqanalysis with cfg.method = 'wavelet' does not give time domain output neccessary for SAM method, since it does a multiplication with the frequencies. I am working on a project where I want to build something crudely comparable to the algorithms used in the MEG Processor software up until its accumulated spectrograms (assuming you are familiar), but am facing the obvious problems mentioned above. I am of course open to the possibility of me misunderstanding of something essential, but I send this email in hope of getting some input even if that's the case.. Best regards, Giske (graduate student) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 11:57:11 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 11:57:11 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed Message-ID: Hi there, I was wondering if anyone could provide some advice on the specifics of calculating coherence on planar gradiometers (Elekta Neuromag system). In short I would like to calculate coherence between an average of several sensor based on the topography of the power (a seed virtual channel if you want), and all the MEG sensors. I would rather deal with combined gradiometers when in the spectral domain, given that those give me a clear and consistent topography within and between subjects. However, I can imagine combining gradiometers at different stages of the analysis: 1) Combine gradiometers on the timecourse data before spectral analysis. 2) Combine gradiometers after the spectral analysis, but before the coherence analysis. 3) Combine gradiometers after the coherence analysis. Option 2 has the advantage of staying in the same topographical representation in the spectral power estimates (to determine sensors) as well as in the coherence, making it easier to compare topographies of power and coherence. However, this does not allow me to use a 'pre-computed' average, i.e. virtual channel, of several *combined *gradiometers as the seed, since those are specified already in spectral estimate (ft_freqanalysis using fourier or fft). A solution for this might be to determine the seed based on combined gradiometers, then 'cut up' those channel labels into their original gradiometer labels, and use those(uncombined) gradiometers as the seeds in ft_freqanalysis. After the spectral analysis I can then first combine the gradiometers, then average the different seed channels, before and calculate the coherence with those as the seed. Does this sound valid to you people? I would like to check with you people if there are any concerns doing this. There might also be a simpler way doing it... As far as I am aware, there is no FieldTrip tutorial or FAQ where coherence analysis is applied to Neuromag data, so I hope this might also help other people. Regards, Stephen p.s. I am probably using the word 'seed' wrong here - feel free to update my nomenclature :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 12:43:44 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 12:43:44 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed In-Reply-To: References: Message-ID: Hi there, It seems I might be able to solve it using the fourier method in ft_freqanalysis, after which I can select and combine gradiometers and feed those into ft_connectivityanalysis. Thanks for your time, Stephen On 18 January 2017 at 11:57, Stephen Whitmarsh wrote: > Hi there, > > I was wondering if anyone could provide some advice on the specifics of > calculating coherence on planar gradiometers (Elekta Neuromag system). In > short I would like to calculate coherence between an average of several > sensor based on the topography of the power (a seed virtual channel if you > want), and all the MEG sensors. > > I would rather deal with combined gradiometers when in the spectral > domain, given that those give me a clear and consistent topography within > and between subjects. However, I can imagine combining gradiometers at > different stages of the analysis: > > 1) Combine gradiometers on the timecourse data before spectral analysis. > 2) Combine gradiometers after the spectral analysis, but before the > coherence analysis. > 3) Combine gradiometers after the coherence analysis. > > Option 2 has the advantage of staying in the same topographical > representation in the spectral power estimates (to determine sensors) as > well as in the coherence, making it easier to compare topographies of power > and coherence. However, this does not allow me to use a 'pre-computed' > average, i.e. virtual channel, of several *combined *gradiometers as the > seed, since those are specified already in spectral estimate > (ft_freqanalysis using fourier or fft). > > A solution for this might be to determine the seed based on combined > gradiometers, then 'cut up' those channel labels into their original > gradiometer labels, and use those(uncombined) gradiometers as the seeds in > ft_freqanalysis. After the spectral analysis I can then first combine the > gradiometers, then average the different seed channels, before and > calculate the coherence with those as the seed. > > Does this sound valid to you people? I would like to check with you people > if there are any concerns doing this. There might also be a simpler way > doing it... > > As far as I am aware, there is no FieldTrip tutorial or FAQ where > coherence analysis is applied to Neuromag data, so I hope this might also > help other people. > > Regards, > Stephen > > p.s. I am probably using the word 'seed' wrong here - feel free to update > my nomenclature :-) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 13:47:54 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 13:47:54 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed In-Reply-To: References: Message-ID: Hi there, Oops, no that does not fly either. Best, Stephen On 18 January 2017 at 12:43, Stephen Whitmarsh wrote: > Hi there, > > It seems I might be able to solve it using the fourier method in > ft_freqanalysis, after which I can select and combine gradiometers and feed > those into ft_connectivityanalysis. > > Thanks for your time, > Stephen > > On 18 January 2017 at 11:57, Stephen Whitmarsh < > stephen.whitmarsh at gmail.com> wrote: > >> Hi there, >> >> I was wondering if anyone could provide some advice on the specifics of >> calculating coherence on planar gradiometers (Elekta Neuromag system). In >> short I would like to calculate coherence between an average of several >> sensor based on the topography of the power (a seed virtual channel if you >> want), and all the MEG sensors. >> >> I would rather deal with combined gradiometers when in the spectral >> domain, given that those give me a clear and consistent topography within >> and between subjects. However, I can imagine combining gradiometers at >> different stages of the analysis: >> >> 1) Combine gradiometers on the timecourse data before spectral analysis. >> 2) Combine gradiometers after the spectral analysis, but before the >> coherence analysis. >> 3) Combine gradiometers after the coherence analysis. >> >> Option 2 has the advantage of staying in the same topographical >> representation in the spectral power estimates (to determine sensors) as >> well as in the coherence, making it easier to compare topographies of power >> and coherence. However, this does not allow me to use a 'pre-computed' >> average, i.e. virtual channel, of several *combined *gradiometers as the >> seed, since those are specified already in spectral estimate >> (ft_freqanalysis using fourier or fft). >> >> A solution for this might be to determine the seed based on combined >> gradiometers, then 'cut up' those channel labels into their original >> gradiometer labels, and use those(uncombined) gradiometers as the seeds in >> ft_freqanalysis. After the spectral analysis I can then first combine the >> gradiometers, then average the different seed channels, before and >> calculate the coherence with those as the seed. >> >> Does this sound valid to you people? I would like to check with you >> people if there are any concerns doing this. There might also be a simpler >> way doing it... >> >> As far as I am aware, there is no FieldTrip tutorial or FAQ where >> coherence analysis is applied to Neuromag data, so I hope this might also >> help other people. >> >> Regards, >> Stephen >> >> p.s. I am probably using the word 'seed' wrong here - feel free to update >> my nomenclature :-) >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.hauswald at me.com Wed Jan 18 13:57:03 2017 From: anne.hauswald at me.com (anne Hauswald) Date: Wed, 18 Jan 2017 13:57:03 +0100 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> Message-ID: <5B0FF59B-A01B-4559-A085-F5F2DDDF80D0@me.com> Hi Mona, as said, the layout files are mainly meant for 2-d plotting. Here http://www.fieldtriptoolbox.org/template/layout under „Neuromag array“ you find specifics for the different files. - neuromag306all.lay includes all 306 sensors - neuromag306mag.lay includes all 102 magnetometers - neuromag306cmb.lay includes 102 positions of 204 combined gradiometers (two at each position) - neuromag306planar.lay includes 204 positions of all planar gradiometers - neuromag306eeg1005_natmeg.lay includes 128 EEG positions Basically, with the Neuromag system you have 102 sensor elements with three sensors each (1 magnetometer and two orthogonal planar gradiometers). Hoper that helps Best Anne > > I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay > Am 13.01.2017 um 19:20 schrieb Wong-Barnum, Mona : > > > Hi Anne: > > Thank you so much for your reply. > >> generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. > > Is there an explanation of the 5 different neuromag layout files? I have the following: > > neuromag306all.lay neuromag306eeg1005_natmeg.lay neuromag306planar.lay > neuromag306cmb.lay neuromag306mag.lay > > I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay files are for. > > I found http://www.fieldtriptoolbox.org/tutorial/layout page but if there is anything that’s useful, please point me to it. > > thanks, > Mona > > ********************************************* > Mona Wong > Web & Mobile Application Developer > San Diego Supercomputer Center > > "Believe you can and you are half > way there." > -- Theodore Roosevelt > ********************************************* > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From tmadsen at emory.edu Wed Jan 18 16:41:58 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Wed, 18 Jan 2017 10:41:58 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Thanks for the additional feedback, Mike and Matt. I agree that the skewness of the power distribution is "trivial" in that it is skewed *by definition* as a squared value, but you're right that my concern is whether it has a nontrivial impact on the analysis of real data. I do intend to do further simulations to test this and various potential solutions, but I need to get another paper submitted first. I will report my findings back to this listserv when possible. Thanks again, Teresa On Fri, Jan 13, 2017 at 9:51 AM, Matt Craddock wrote: > Hi all, > > I'm fiddling around with simulations at the moment but not got a lot of > free time, and every time I do fiddle with them the more complicated I seem > to make them... > > correct me if i'm wrong, but there are a couple of different issues here. > > About the skewness of the distribution - you're not usually comparing two > skewed distributions statistically (which even then would probably be ok if > they're similary skewed), usually it's a bunch of means from those > distributions, and the distribution of the means will often be normally > distributed (as will their differences), and thus ok for parametric stats. > So the main problem is really whether the mean is a good summary statistic > for capturing differences between the underlying distributions or not > (similar debates about reaction times) - it's certainly not robust to > outliers. Median might be better in some ways, but it's a biased estimator > of the population median and might have consequences on stat power - that's > one for the simulations at some point. > > Taking the log first won't necessarily help. As the code Michael Cohen > provides shows, taking the log can still result in skewed distributions - > power is right-skewed but its log is left-skewed. Taking the square root > would obviously be better in this case but that's because it just returns > it to the original unsquared normal distribution - whether that's true of > real data needs checking out. In addition if you take the log you're no > longer testing the same thing when you compare the means - you're testing > the geometric mean instead of the arithmetic mean. Differences in the > arithmetic means across conditions will not necessarily translate into > differences in the geometric means and vice versa. > > If you use a subtractive baseline, using the median or mean of power will > only change what constant you subtract from the data. If you baseline > correct using the average of all trials rather than condition specific > baselines, it should make no difference to the stats if you use the mean or > the median of baseline power (or indeed if you don't use baseline > correction at all). If you test differences across electrodes as well as > condition, and use electrode but not condition specific baselines - which > seems reasonable, since you might expect bigger baseline differences across > than within electrodes, it'll only change the main electrode effect, not > the condition effect or the interaction between condition and electrode. If > you use condition and electrode specific baselines, then it influences > *everything*, and you also no longer know if the differences between > conditions/electrodes are due to baseline or post-stimulus differences. > > Using the median over the mean will change the stats if you use divisive > baselines, but whether that's a good or bad difference is another question > for simulations. > > Cheers, > Matt > > > On 12/01/2017 13:37, Mike X Cohen wrote: > >> Interesting discussion here. I think we should take a step back and >> distinguish between trivial and nontrivial causes and consequences for >> the skewed distribution. To some extent, the non-normal distribution is >> simply the result of defining power as a squared distance -- distances >> are always positive and squaring them means big values become really >> big. Consider the following: >> >> d = randn(10000,1); % random numbers >> subplot(311), hist(d,500); % their distribution >> subplot(312), hist(d.^2,500); % "power" distribution, also try a >> log-scaled y-axis >> subplot(313), hist(log(d.^2),500); % log-power distribution >> >> The fact that power values have a power-law-like distribution is >> therefore trivial. >> >> But this leads to two non-trivial questions: >> 1) Is this distribution meaningful for brain function (beyond simply the >> result of taking squared values)? People who study "the log-brain" and >> fractal-like (or scale-free) organization of brain function would argue >> that these distributions reveal meaningful insights into brain function, >> and therefore it is not really an artifact for analyses. In other words, >> large values are large for a reason; they might not be outliers that we >> should attempt to compress. >> >> 2) Does it matter for real data analysis? I think this is Teresa's >> initial concern. I'm inclined to think that it doesn't really matter, >> but that's just based on the idea (hope!) that if it did really matter >> and the way we do it is wrong, the field would have discovered this a >> long time ago. On the other hand, this wouldn't be the first time that >> people have gotten things wrong for decades. >> >> I think the best way to investigate #2 would be with simulated data, >> showing that a "true" effect is missed when not first computing >> log-power, presumably because the effect was overshadowed by >> large-amplitude "noise" (but somehow this would have to be physiological >> noise that wouldn't get rejected during data cleaning). In empirical >> data, all you'd be able to do is show a difference without knowing the >> right answer. >> >> btw, make sure to be careful with baselining log-power -- any divisions >> (e.g., dB or percent change) will be unstable/run off to infinity when >> baseline power is close to zero, i.e., raw power is close to 1. The sign >> might also get weird. Probably best to use a baseline subtraction. >> >> Mike >> >> >> >> >> >> --------------------------------------------><-------------- >> ---------------------------------- >> >> Thanks for the reference. In return, I also recommend reading Ciuparu and >> Mures an's recent rebuttal: >> >> European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, >> doi:10.1111/ejn.13179 >> TECHNICAL SPOTLIGHT >> Sources of bias in single-trial normalization procedures >> >> They demonstrate that the positive bias Grandchamp and Delorme warned >> about >> with single-trial baseline normalization was, in fact, due to the >> correlated numerators and denominators in each of the baseline >> normalization procedures they tested, which was, in turn, caused by the >> skewed distributions of baseline power values. They demonstrate that this >> bias is reduced by using a much longer baseline, ideally incorporated into >> the experimental design, but when that's not possible, stitching together >> the baselines of many trials. >> >> Neither article addresses my specific question of whether it would be even >> better to log-transform the raw power values before averaging, so I >> suppose >> I'll have to test it myself and write my own methods article! 🤓 >> >> I will go ahead and incorporate some of these alternative baseline >> normalization methods in my git fork of FieldTrip as I go along with my >> own >> analyses, so let me know if anyone else would find them useful, and I'll >> submit a pull request to contribute them to the master branch. >> >> Thanks for the fruitful discussion, all! >> ~Teresa >> >> >> On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge > > wrote: >> >> Indeed, in a separate thread with Michael Cohen several months back he >>> suggested precisely that paper. >>> >>> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" >> >> gmail.com > >> >>> wrote: >>> >>> I think this paper is relevant to this discussion. >>>> >>>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy >>>> >>> Trials. *Frontiers >> >>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>>> >>>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>>> >>>> >>>> >>>> On 19 December 2016 at 13:08, Teresa Madsen >>> >>> > wrote: >> >>> >>>> I appreciate everyone's feedback, but I still wonder if something is >>>>> being missed. I understand that the non-normally distributed power >>>>> >>>> values >> >>> may be less of an issue when performing non-parametric stats or even a >>>>> paired-samples t-test that looks at difference values which may be >>>>> >>>> normal >> >>> even when the raw data isn't. However, my concern comes into play even >>>>> before these statistical comparisons are made, whenever any averaging >>>>> is >>>>> done to freq-type data across times, frequencies, trials, electrodes, >>>>> subjects, etc. That means any time any of these configuration >>>>> >>>> options are >> >>> used for any of these functions, and probably more: >>>>> >>>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>>> cfg.avgoverfreq = 'yes'; >>>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>>> >>>>> In each case, if raw power values are averaged, the result will be >>>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>>> treated identically, but the specific case that triggered my concern >>>>> >>>> was in >> >>> ft_freqbaseline, where the individual time-frequency bins are >>>>> >>>> compared to >> >>> the mean over time for the baseline period. For example, when using >>>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output >>>>> >>>> freq >> >>> data does indeed have a more normal distribution over time, but the mean >>>>> over the baseline time period is performed *before* the log >>>>> >>>> transform, when >> >>> the distribution is still highly skewed: >>>>> >>>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>>> size(data, 3)]); >>>>> data = 10*log10(data ./ meanVals); >>>>> >>>>> That's what I had originally done when analyzing data for my SfN >>>>> poster, >>>>> when I realized the background noise that shouldn't have changed >>>>> >>>> much from >> >>> baseline was mostly showing a decrease from baseline of about -3dB. >>>>> >>>>> Now, I've realized I'm seeing this as more of a problem than others >>>>> because of another tweak I made, which was to use a long, separate >>>>> >>>> baseline >> >>> recording to normalize my trial data, rather than a short pre-trial >>>>> >>>> period >> >>> as ft_freqbaseline is designed to do. Averaging a few hundred >>>>> >>>> milliseconds >> >>> for a baseline power estimate might be okay because overlapping time >>>>> >>>> points >> >>> in the original data are used to calculate those power values anyway, >>>>> probably making them less skewed, but also (it seems to me) more >>>>> >>>> arbitrary >> >>> and prone to error. I already offered my custom function BLnorm.m >>>>> >>>> to one >> >>> person who was asking about this issue of normalizing to a separate >>>>> baseline recording, and I would be happy to contribute it to >>>>> >>>> FieldTrip if >> >>> others would appreciate it. >>>>> >>>>> Since a few people suggested using the median, and it is also suggested >>>>> in Cohen's textbook >>>>> as >>>>> an alternative measure of the central tendency for skewed raw power >>>>> >>>> values, >> >>> I wonder if the simplest fix might be to add an option to select mean or >>>>> median in each of the functions listed above. Another possibility >>>>> >>>> would be >> >>> adding an option to transform the power values upon output from >>>>> ft_freqanalysis. >>>>> >>>>> Would anyone else find such changes useful? >>>>> >>>>> Thanks, >>>>> Teresa >>>>> >>>>> >>>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>>> J.Herring at donders.ru.nl > wrote: >>>>> >>>>> In terms of statistics it is the distribution of values that you do the >>>>>> statistics on that matters. In case of a paired-samples t-test when >>>>>> comparing two conditions, it is the distribution of difference >>>>>> >>>>> values that >> >>> has to be normally distributed. The distribution of difference >>>>>> >>>>> values is >> >>> often normal given two similarly non-normal distributions, offering no >>>>>> complications for a regular parametric test. >>>>>> >>>>>> >>>>>> >>>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>>> normality, so you should have no problem there either. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* fieldtrip-bounces at science.ru.nl >>>>>> >>>>> [mailto:fieldtrip-bounces at scie >> >>> nce.ru.nl ] *On Behalf Of *Alik Widge >>>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>>> *To:* FieldTrip discussion list >>>>> >>>>> > >> >>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>>> data analysis >>>>>> >>>>>> >>>>>> >>>>>> In this, Teresa is right and we have observed this in our own EEG data >>>>>> -- depending on one's level of noise and number of trials/patients, >>>>>> the >>>>>> mean can be a very poor estimator of central tendency. My students are >>>>>> still arguing about what we really want to do with it, but at least >>>>>> >>>>> one of >> >>> them has shifted to using the median as a matter of course for baseline >>>>>> normalization. >>>>>> >>>>>> >>>>>> Alik Widge >>>>>> alik.widge at gmail.com >>>>>> (206) 866-5435 >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>>> >>>>> emory.edu > >> >>> wrote: >>>>>> >>>>>> That may very well be true; to be honest, I haven't looked that deeply >>>>>> into the stats offerings yet. However, my plan is to express each >>>>>> electrode's experimental data in terms of change from their respective >>>>>> baseline recordings before attempting any group averaging or >>>>>> >>>>> statistical >> >>> testing, and this problem shows up first in the baseline correction >>>>>> >>>>> step, >> >>> where FieldTrip averages raw power over time. >>>>>> >>>>>> ~Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com > wrote: >>>>>> >>>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>>> statistics implemented by fieldtrip, the data does not need to be >>>>>> >>>>> normally >> >>> distributed. >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 13:39, Teresa Madsen >>>>> >>>>> > wrote: >> >>> >>>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>>> opportunity to clarify. Of course everyone is familiar with the 1/f >>>>>> >>>>> pattern >> >>> across frequencies, but the distribution across time (and according >>>>>> >>>>> to the >> >>> poster, also across space), also has an extremely skewed, negative >>>>>> exponential distribution. I probably confused everyone by trying to >>>>>> >>>>> show >> >>> too much data in my figure, but each color represents the >>>>>> >>>>> distribution of >> >>> power values for a single frequency over time, using a histogram >>>>>> >>>>> and a line >> >>> above with circles at the mean +/- one standard deviation. >>>>>> >>>>>> My main point was that the mean is not representative of the central >>>>>> tendency of such an asymmetrical distribution of power values over >>>>>> >>>>> time. >> >>> It's even more obvious which is more representative of their actual >>>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>>> log(mean(rawpower)) on the log plot, but that made the figure even >>>>>> more >>>>>> busy and confusing. >>>>>> >>>>>> I hope that helps, >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com > wrote: >>>>>> >>>>>> Hi Teresa, >>>>>> >>>>>> >>>>>> >>>>>> I think what you are discussing is the 1/f power scaling of the power >>>>>> spectrum. This is one of the reasons that comparisons are made within >>>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to >>>>>> >>>>> gamma), >> >>> as such the assumption is that within bands there should be a relative >>>>>> change against baseline and this is what the statistics are >>>>>> >>>>> performed on. >> >>> That is, baseline correction is assumed to be the mean for a specific >>>>>> frequency and not a mean across frequencies. >>>>>> >>>>>> >>>>>> >>>>>> And this leads to another point that when you are selecting a >>>>>> frequency range to do the non-parametric statistics on you should >>>>>> >>>>> not do >> >>> 1-64 Hz but break it up based on the bands. >>>>>> >>>>>> >>>>>> >>>>>> Hope my interpretation of your point is correct. I sent in >>>>>> individually, as I wanted to ensure I followed your point. >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 08:23, Teresa Madsen >>>>> >>>>> > wrote: >> >>> >>>>>> FieldTrippers, >>>>>> >>>>>> >>>>>> >>>>>> While analyzing my data for the annual Society for Neuroscience >>>>>> meeting, I developed a concern that was quickly validated by >>>>>> >>>>> another poster >> >>> (full abstract copied and linked below) focusing on the root of the >>>>>> problem: neural oscillatory power is not normally distributed >>>>>> >>>>> across time, >> >>> frequency, or space. The specific problem I had encountered was in >>>>>> baseline-correcting my experimental data, where, regardless of >>>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>>> However, I found that the distribution of raw power over time is so >>>>>> >>>>> skewed >> >>> that the mean was not a reasonable approximation of the central >>>>>> >>>>> tendency of >> >>> the baseline power, so it made most of my experimental data look >>>>>> >>>>> like it >> >>> had decreased power compared to baseline. The more I think about >>>>>> >>>>> it, the >> >>> more I realize that averaging is everywhere in the way we analyze >>>>>> >>>>> neural >> >>> oscillations (across time points, frequency bins, electrodes, trials, >>>>>> subjects, etc.), and many of the standard statistics people use >>>>>> >>>>> also rely >> >>> on assumptions of normality. >>>>>> >>>>>> >>>>>> >>>>>> The most obvious solution for me was to log transform the data first, >>>>>> as it appears to be fairly log normal, and I always use log-scale >>>>>> visualizations anyway. Erik Peterson, middle author on the poster, >>>>>> >>>>> agreed >> >>> that this would at least "restore (some) symmetry to the error >>>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>>> differentiate from the standard decibel transform included in >>>>>> >>>>> FieldTrip as >> >>> cfg.baselinetype = 'db'. The following figures compare the 2 >>>>>> >>>>> distributions >> >>> across several frequency bands (using power values from a wavelet >>>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>>> cortex). The lines at the top represent the mean +/- one standard >>>>>> deviation for each frequency band, and you can see how those >>>>>> >>>>> descriptive >> >>> stats are much more representative of the actual distributions in >>>>>> >>>>> the log >> >>> scale. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ​​ >>>>>> >>>>>> For my analysis, I also calculated a z-score on the log transformed >>>>>> power to assess how my experimental data compared to the >>>>>> >>>>> variability of the >> >>> noise in a long baseline recording from before conditioning, rather >>>>>> >>>>> than a >> >>> short pre-trial baseline period, since I find that more informative >>>>>> >>>>> than >> >>> any of FieldTrip's built-in baseline types. I'm happy to share the >>>>>> >>>>> custom >> >>> functions I wrote for this if people think it would be a useful >>>>>> >>>>> addition to >> >>> FieldTrip. I can also share more about my analysis and/or a copy >>>>>> >>>>> of the >> >>> poster, if anyone wants more detail - I just didn't want to make >>>>>> >>>>> this email >> >>> too big. >>>>>> >>>>>> >>>>>> >>>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>>> address this. I searched the wiki >>>>>> , listserv >>>>>> >>>>>> > mber/000773.html> >> >>> archives >>>>>> >>>>>> > h/002718.html>, >> >>> and bugzilla >>>>>> for >>>>>> anything related and came up with a few topics surrounding >>>>>> >>>>> normalization >> >>> and baseline correction, but only skirting this issue. It seems >>>>>> >>>>> important, >> >>> so I want to find out whether others agree with my approach or >>>>>> >>>>> already have >> >>> other ways of avoiding the problem, and whether FieldTrip's code >>>>>> >>>>> needs to >> >>> be changed or just documentation added, or what? >>>>>> >>>>>> >>>>>> >>>>>> Thanks for any insights, >>>>>> >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>>> across time >>>>>> >>>>>> >>>>>> *Authors* >>>>>> >>>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>>> Cognitive Sci., UCSD, San Diego, CA >>>>>> >>>>>> *Disclosures* >>>>>> >>>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>>> >>>>>> *Abstract* >>>>>> >>>>>> Neural oscillations are important in organizing activity across the >>>>>> human brain in healthy cognition, while oscillatory disruptions are >>>>>> >>>>> linked >> >>> to numerous disease states. Oscillations are known to vary by >>>>>> >>>>> frequency and >> >>> amplitude across time and between different brain regions; however, >>>>>> >>>>> this >> >>> variability has never been well characterized. We examined human >>>>>> >>>>> and animal >> >>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>>> distribution of power and frequency across time, space and species. We >>>>>> report that between data types, subjects, frequencies, electrodes, and >>>>>> time, an inverse power law, or negative exponential distribution, is >>>>>> present in all recordings. This is contrary to, and not compatible >>>>>> >>>>> with, >> >>> the Gaussian noise assumption made in many digital signal processing >>>>>> techniques. The statistical assumptions underlying common >>>>>> >>>>> algorithms for >> >>> power spectral estimation, such as Welch's method, are being violated >>>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>>> statistical approaches are warranted. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Teresa E. Madsen, PhD >>>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>>> analysis >>>>>> >>>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>>> Yerkes National Primate Research Center >>>>>> >>>>>> Emory University >>>>>> >>>>>> Rainnie Lab, NSB 5233 >>>>>> 954 Gatewood Rd. NE >>>>>> Atlanta, GA 30329 >>>>>> >>>>>> (770) 296-9119 >>>>>> >>>>>> braingirl at gmail.com >>>>>> >>>>>> https://www.linkedin.com/in/temadsen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Teresa E. Madsen, PhD >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> Emory University >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> (770) 296-9119 >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >> >> >> -- >> Teresa E. Madsen, PhD >> Division of Behavioral Neuroscience and Psychiatric Disorders >> Yerkes National Primate Research Center >> Emory University >> Rainnie Lab, NSB 5233 >> 954 Gatewood Rd. NE >> Atlanta, GA 30329 >> (770) 296-9119 >> >> -- >> Mike X Cohen, PhD >> mikexcohen.com >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.klinzing at uni-tuebingen.de Thu Jan 19 10:09:15 2017 From: jens.klinzing at uni-tuebingen.de (=?ISO-8859-1?Q?=22Jens_Klinzing=2C_Uni_T=FCbingen=22?=) Date: Thu, 19 Jan 2017 10:09:15 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> Message-ID: <5880823B.2050806@uni-tuebingen.de> Dear Elena, Question 1: I assume the reason it takes so long is that you are using a FEM-based headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - sb_transfer) every time you do a source reconstruction. For more information see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 . You can circumvent the issue by computing the transfer matrix beforehand and changing the code in a way that it doesnt compute a new transfer matrix if you have already provided one. Alternatively you could use a BEM headmodel (dipoli if possible since bemcp seems to have issues http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2817). Question 2: Did you check your segmentation, the headmodel and the coregistration of electrodes/head every step of the way? If you fill all inside voxels with 1s and plot that, do you see an obvious shift/rotation of the "activity" in relation to the MRI? Best, Jens > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' > method applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to > call one ft_sourceanalysis. Maybe, there is a way to optimise the > procedure somehow? > > Second, at the end of analysis I obtain a very strange figure, on > which I see activity localised outside the mri scan. Mistake on which > step of analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - > sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjj11033 at kaist.ac.kr Thu Jan 19 11:26:52 2017 From: kjj11033 at kaist.ac.kr (=?UTF-8?B?6rmA7J6s7KSR?=) Date: Thu, 19 Jan 2017 19:26:52 +0900 (KST) Subject: [FieldTrip] =?utf-8?q?Questions_about_probability_variation_by_se?= =?utf-8?q?tting_different_tail_of_cluster_based_permutation_test?= Message-ID: <5880960c3fb3_@_imoxion.com> Dear group, Hi I'm Jaejoong of KAIST korea First of all, thanks for such a nice toolbox I have a question with tail of cluster based permutation test I compared difference between 2 conditions with test Weird thing is, when I run test with cfg.clustertail=0; negative cluster of probability 0.038 returned, which is not significant However, when I run test with clustertail=-1 and +1 both, negative cluster of probability of 0.021 returned, which is significant if I adjust with bonferroni correction for both positive one sied test and negative one sided test In my understanding, probability of negative cluster above should be same. So my question is 1) Why does probability of same negative cluster is varied by tail of permutation test? 2) Is it reasonable to run test with clustertail=+1/-1 and apply bonferroni correction for 2 tests? I would really appreciate your comments Sincerely Jaejoong -------------- next part -------------- An HTML attachment was scrubbed... URL: From krugliakova.es at gmail.com Thu Jan 19 13:55:49 2017 From: krugliakova.es at gmail.com (Elena Krugliakova) Date: Thu, 19 Jan 2017 13:55:49 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: <5880823B.2050806@uni-tuebingen.de> References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> <5880823B.2050806@uni-tuebingen.de> Message-ID: Dear Jens, Thank you for your answer! 1. Indeed, I found where ft_sourceanalysis starts to recompute transfer matrix and just loaded precomputed headmodel and sensors. Now everything is fine, and it takes several seconds to run ft_sourceanalysis. 2. About homogeneous "noise outside the mri scan". Noise appears after I calculate difference between two sources, following tutorial http://www.fieldtriptoolbox.org/tutorial/beamformer. However, sourceplot for not-contrasted conditions looks good. Maybe you could give me an advice, how to get rid of this background noise. Kind Regards, Elena With difference calculation: cfg = []; cfg.elec = elec; cfg.headmodel = vol; cfg.grid = leadfield; cfg.keepleadfield = 'yes' cfg.projectnoise = 'yes'; cfg.frequency = [10 15]; cfg.method = 'dics'; cfg.dics.projectnoise = 'yes'; cfg.dics.lambda = '5%'; cfg.dics.keepfilter = 'yes'; cfg.dics.realfilter = 'yes'; sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); cfg.grid.filter = sourcePNandBS.avg.filter; sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); sourceBS = ft_sourceanalysis(cfg, freq_BS_Post); *sourceDiff.avg.pow = (sourcePN.avg.pow - sourceBS.avg.pow) ./ sourceBS.avg.pow;* cfg = []; cfg.parameter = 'avg.pow'; sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); cfg = []; sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg, sourceDiffIntNorm); figure [image: Inline images 1] Without difference calculation: cfg = []; cfg.elec = elec; .......... sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); cfg.grid.filter = sourcePNandBS.avg.filter; sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); sourcePN.avg.pow = sourcePN.avg.pow ./ sourcePN.avg.noise; cfg = []; cfg.parameter = 'avg.pow'; sourcePN = ft_sourceinterpolate(cfg, sourcePN, mri); cfg = []; sourcePNIntNorm = ft_volumenormalise(cfg, sourcePNInt); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg, sourcePNIntNorm); figure [image: Inline images 2] On 19 January 2017 at 10:09, "Jens Klinzing, Uni Tübingen" < jens.klinzing at uni-tuebingen.de> wrote: > Dear Elena, > > Question 1: > I assume the reason it takes so long is that you are using a FEM-based > headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix > on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - > sb_transfer) every time you do a source reconstruction. For more > information see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 > . > > You can circumvent the issue by computing the transfer matrix beforehand > and changing the code in a way that it doesnt compute a new transfer matrix > if you have already provided one. > > Alternatively you could use a BEM headmodel (dipoli if possible since > bemcp seems to have issues http://bugzilla.fieldtriptoolbox.org/show_bug. > cgi?id=2817). > > Question 2: > Did you check your segmentation, the headmodel and the coregistration of > electrodes/head every step of the way? If you fill all inside voxels with > 1s and plot that, do you see an obvious shift/rotation of the "activity" in > relation to the MRI? > > Best, > Jens > > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' method > applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to call > one ft_sourceanalysis. Maybe, there is a way to optimise the procedure > somehow? > > Second, at the end of analysis I obtain a very strange figure, on which I > see activity localised outside the mri scan. Mistake on which step of > analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - sourcePre_con.avg.pow) > ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 144484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165407 bytes Desc: not available URL: From mehdy.dousty at gmail.com Fri Jan 20 01:05:06 2017 From: mehdy.dousty at gmail.com (mehdy dousty) Date: Fri, 20 Jan 2017 00:05:06 +0000 Subject: [FieldTrip] Extracting Default mode network from AAL Message-ID: Hello all, I am working on source localization based on the Inverse problem of MEG Human Connectome project. I used eLoreta to investigate the sources in the brain, and the results are projected to MNI 116, AAL116, I would like to know how I can identify the different networks such as DMN? Thanks Mehdy -------------- next part -------------- An HTML attachment was scrubbed... URL: From seymourr at aston.ac.uk Fri Jan 20 10:29:36 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Fri, 20 Jan 2017 09:29:36 +0000 Subject: [FieldTrip] [HCP-Users] Extracting Default mode network from AAL In-Reply-To: References: Message-ID: Hi Mehdy, I believe the AAL atlas came before the DMN and other large-scale brain networks were popular in neuroimaging, so there's no easy 1:1 mapping between them. Perhaps you could download the Yeo 7/17 network parcellations, overlay the AAL atlas points and see which ROIs overlap with the DMN? Otherwise you could repeat your analysis using a more up-to-date atlas such as the HCP MMP (https://balsa.wustl.edu/WN56)... Robert ________________________________ From: hcp-users-bounces at humanconnectome.org on behalf of mehdy dousty Sent: 20 January 2017 00:05:06 To: FieldTrip discussion list; hcp-users at humanconnectome.org Subject: [HCP-Users] Extracting Default mode network from AAL Hello all, I am working on source localization based on the Inverse problem of MEG Human Connectome project. I used eLoreta to investigate the sources in the brain, and the results are projected to MNI 116, AAL116, I would like to know how I can identify the different networks such as DMN? Thanks Mehdy _______________________________________________ HCP-Users mailing list HCP-Users at humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehdy.dousty at gmail.com Sun Jan 22 05:31:49 2017 From: mehdy.dousty at gmail.com (mehdy dousty) Date: Sun, 22 Jan 2017 04:31:49 +0000 Subject: [FieldTrip] HCP MEG SOURCE TO DMN Message-ID: Hi all, Firstly I give my special thanks to fieldtrip and human connectome project discussion list. Secondly, I have a question which needs the expert's attentions. I am using MEG resting state in HCP, and I would like to project the data to some atlases to extract DMN network. Since the AAL 116 does not give me the aforementioned network, and it is not clear from HCP instruction how to interpolate the computed grid points to other atlases, there is 1:1 interpolation between AAL and calculated source points, I am sending the email to help me through the issue. Thanks Mehdy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Horn at charite.de Sun Jan 22 14:50:43 2017 From: Andreas.Horn at charite.de (Horn, Andreas) Date: Sun, 22 Jan 2017 13:50:43 +0000 Subject: [FieldTrip] HCP MEG SOURCE TO DMN In-Reply-To: References: Message-ID: Hi Mehdy, There are two reference masks of the DMM being deployed within the GIFT ICA toolbox - they are potentially a bit old but should work for the purpose. Also, for a list of available whole-brain parcellation atlases (I.e. AAL alternatives, see http://www.lead-dbs.org/?page_id=1004). Best, Andy Am 21.01.2017 um 23:33 schrieb mehdy dousty >: Hi all, Firstly I give my special thanks to fieldtrip and human connectome project discussion list. Secondly, I have a question which needs the expert's attentions. I am using MEG resting state in HCP, and I would like to project the data to some atlases to extract DMN network. Since the AAL 116 does not give me the aforementioned network, and it is not clear from HCP instruction how to interpolate the computed grid points to other atlases, there is 1:1 interpolation between AAL and calculated source points, I am sending the email to help me through the issue. Thanks Mehdy _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.wilson at med.einstein.yu.edu Mon Jan 23 22:00:10 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Mon, 23 Jan 2017 21:00:10 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel Message-ID: Hi all, I'm working with EEG data and I'm trying to get some basic source fitting up and running. Unfortunately, I don't have individual subject MRIs, so I'm using the templates provided by fieldtrip. I've co-registered my 160 Biosemi electrodes to the standard_bem template (see attached picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid (picture attached, overlaid on standard_bem). I can prepare the leadfield from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. To test this configuration, I've selected a time window in my data and averaged across it (the covariance matrix was also calculated); the topography of this averaged data is attached. I then attempted a source fit with the LCMV beamformer: cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); After interpolating to the single_subj_T1.nii provided with ft_sourceinterpolate and plotting with ft_sourceplot, I am given a sourceplot that is highly focal in nature (see attached picture). I'd find it very surprising if this topography were generated primarily by a source that isn't even inside the brain (as the sourceplot indicates). So, I'm not sure exactly where/how I'm going wrong with this one, nor am I sure how to trouble shoot it. Any guidance you might provide would be greatly appreciated. Thanks so much, Tommy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Grid.PNG Type: image/png Size: 42603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Electrode localization.PNG Type: image/png Size: 94200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Source.PNG Type: image/png Size: 134694 bytes Desc: not available URL: From singht at musc.edu Tue Jan 24 02:43:10 2017 From: singht at musc.edu (Singh, Tarkeshwar) Date: Tue, 24 Jan 2017 01:43:10 +0000 Subject: [FieldTrip] FEM volume conduction model for stroke survivors Message-ID: <6B351597-5A9A-4027-8DA5-A7AD7D9E88D2@musc.edu> Dear Fieldtrip Community, Has anyone tried developing an FEM volume conduction model for stroke survivors (http://www.fieldtriptoolbox.org/tutorial/headmodel_eeg_fem). I was wondering, how have you modeled the lesioned volume? Have you modeled it as CSF, and if so, how did you do that? I used the code shown below and it appears to me that the lesions are not getting modeled as CSF; they appear to be modeled as scalp and skull. cfg = []; cfg.output = {'gray','white','csf','skull','scalp'}; segmentedmri = ft_volumesegment(cfg, mri); seg_i = ft_datatype_segmentation(segmentedmri,'segmentationstyle','indexed'); Any help would be sincerely appreciated. Regards, Tarkesh -- Tarkeshwar Singh Postdoctoral Scholar Department of Health Sciences and Research Medical University of South Carolina 77 President Street, Room C305 Charleston, SC 29425 singht at musc.edu ------------------------------------------------------------------------- This message was secured via TLS by MUSC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.keil at gmail.com Tue Jan 24 09:40:06 2017 From: julian.keil at gmail.com (Julian Keil) Date: Tue, 24 Jan 2017 09:40:06 +0100 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: Message-ID: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Hi Tommy, did you do some sort of contrast (e.g. with the noise estimate or a baseline) after your source analysis? Right now, it's not clear what you are looking at. Could you paste your code not only of the sourceanalysis, but the rest after which got you to the plot? It might also be the case that the automatic scaling in the source plot throws you off - maybe try setting it by hand. Good luck, Julian Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > Hi all, > > I'm working with EEG data and I'm trying to get some basic source fitting up and running. Unfortunately, I don't have individual subject MRIs, so I'm using the templates provided by fieldtrip. I've co-registered my 160 Biosemi electrodes to the standard_bem template (see attached picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid (picture attached, overlaid on standard_bem). I can prepare the leadfield from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. > > To test this configuration, I've selected a time window in my data and averaged across it (the covariance matrix was also calculated); the topography of this averaged data is attached. I then attempted a source fit with the LCMV beamformer: > > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > > After interpolating to the single_subj_T1.nii provided with ft_sourceinterpolate and plotting with ft_sourceplot, I am given a sourceplot that is highly focal in nature (see attached picture). > > I'd find it very surprising if this topography were generated primarily by a source that isn't even inside the brain (as the sourceplot indicates). So, I'm not sure exactly where/how I'm going wrong with this one, nor am I sure how to trouble shoot it. Any guidance you might provide would be greatly appreciated. > > Thanks so much, > > Tommy > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From michak at is.umk.pl Tue Jan 24 15:21:17 2017 From: michak at is.umk.pl (=?UTF-8?Q?Micha=C5=82_Komorowski?=) Date: Tue, 24 Jan 2017 15:21:17 +0100 Subject: [FieldTrip] Source statistic issue - between trials Message-ID: Dear community, Currently I am working on source analysis from EEG data. I have some trouble using ft_sourcestatistics do a between-trials analysis (single subject). I am trying to compare source from trials from task type A (ctrl) to with trials from task type B (task). Mainly I rely on http://www.fieldtriptoolbox.org/example/source_statistics . For almost week I am trying find a solution, inculding testing ft_sourcestatistics with different combinations of data: 1) source 1 : no ft_sourcedescriptives and no ft_sourceinterpolate used 2) source 2 : used ft_sourcedescriptives and no ft_sourceinterpolate used 3) source 3 : used ft_sourcedescriptives and used ft_sourceinterpolate For cases 1) and 2) I get very similar errors "Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering" (full error messages at the bottom). In case 3) I cannot run ft_statistics because there are no trials anymore. I have tried changing design matrix, search community messages for some advice and read related articles on fieldtriptoolbox site, but I have not find the answer. Any help would be appreciated. Michał Komorowski Statistics code: cfg = []; %cfg.dim = source.dim; % there is no such field in the data cfg.method = 'montecarlo'; cfg.statistic = 'ft_statfun_depsamplesT'; cfg.parameter = 'pow'; cfg.correctm = 'cluster'; cfg.numrandomization = 100; cfg.alpha = 0.05; cfg.correcttail = 'alpha'; % http://www.fieldtriptoolbox.org/faq/why_should_i_use_the_cfg.correcttail_option_when_using_statistics_montecarlo cfg.tail = 0; % two sided test cfg.design(1,:) = design; % condition code cfg.design(2,:) = [1:length(find(design==1)) 1:length(find(design==2))]; % trial indices cfg.uvar = 2; % unit of observation variable: trials cfg.ivar = 1; % independent variable: condition code % I think design matrix is ok according to: http://www.fieldtriptoolbox.org/walkthrough#paired_comparison) stat = ft_sourcestatistics(cfg, source); Data structures and error messages Case 1) no ft_sourcedescriptives and no ft_sourceinterpolate used source = freq: 10 cumtapcnt: [21x1 double] inside: [231420x1 logical] pos: [231420x3 double] method: 'rawtrial' trial: [1x21 struct] df: 21 cfg: [1x1 struct] the call to "ft_selectdata" took 1 seconds using "ft_statistics_montecarlo" for the statistical testing using connectivity of voxels in 3-D volume using "ft_statfun_depsamplesT" for the single-sample statistics constructing randomized design total number of measurements = 21 total number of variables = 2 number of independent variables = 1 number of unit variables = 1 number of within-cell variables = 0 number of control variables = 0 using a permutation resampling approach repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 computing a parametric threshold for clustering Error using ft_statfun_depsamplesT (line 84) Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering Error in ft_sourcestatistics (line 205) [stat, cfg] = statmethod(cfg, dat, design); >> cfg.design ans = 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 Case 2) used ft_sourcedescriptives and no ft_sourceinterpolate used source_app = freq: 10 cumtapcnt: [21x1 double] inside: [231420x1 logical] pos: [231420x3 double] method: 'rawtrial' trial: [1x21 struct] df: 21 cfg: [1x1 struct] the call to "ft_selectdata" took 0 seconds using "ft_statistics_montecarlo" for the statistical testing using connectivity of voxels in 3-D volume using "ft_statfun_depsamplesT" for the single-sample statistics constructing randomized design total number of measurements = 21 total number of variables = 2 number of independent variables = 1 number of unit variables = 1 number of within-cell variables = 0 number of control variables = 0 using a permutation resampling approach repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 computing a parametric threshold for clustering Error using ft_statfun_depsamplesT (line 84) Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering Error in ft_sourcestatistics (line 205) [stat, cfg] = statmethod(cfg, dat, design); Case 3) used ft_sourcedescriptives and used ft_sourceinterpolate source_mri_align_ctrl = freq: 10 anatomy: [128x128x128 double] coordsys: 'spm' dim: [128 128 128] pos: [2097152x3 double] transform: [4x4 double] unit: 'mm' inside: [128x128x128 logical] pow: [2097152x1 double] cfg: [1x1 struct] % there is no trials so one cannot conduct between-trials statistics ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.wilson at med.einstein.yu.edu Tue Jan 24 17:36:20 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Tue, 24 Jan 2017 16:36:20 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Julian, Thank you so much for your reply. I've pasted the commented code below (I apologize for the code dump). I've also attached an m-file to this email if you'd prefer to download it that way. If relevant, you can download the leadfield, headmodel and electrode locations here (that file also includes the raw data stored in variables A and U that I am attempting to source-fit). As per your questions: I do indeed have a contrast between attended (A) and unattended (U) conditions. I've written the code below to source-fit both conditions and create the contrast. However, despite that the raw topographies (see attached images) are different, the source-fits are the same (...?). As a consequence, the contrast has no non-zero values. If instead, I normalize to noise (i.e. generate the Neural Activity Index ) and look at a contrast there, we again see no non-zero values. Outside of the contrast, I've implemented your other suggestions. I've rescaled the original ft_sourceplot such that you can see the extent of it (see attached image). To my mind, it shouldn't look like this, but having never done this before, I'm not quite sure what to expect. I've also included an image of the ft_sourceplot for the Neural Activity Index of sourceA which also appears to me to be artefactual. More to the point, I'd expect that since the topographies for A and U are different, the NAIs should be different, which is not the case. I'm sort of at a loss about how to proceed here. So, thank you very much for taking the time to look into this. If I can supply anything else to help, please don't hesitate to let me know. Best, Tommy Wilson --- CODE --- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); On Tue, Jan 24, 2017 at 3:42 AM Julian Keil wrote: > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste your > code not only of the sourceanalysis, but the rest after which got you to > the plot? > It might also be the case that the automatic scaling in the source plot > throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual subject > MRIs, so I'm using the templates provided by fieldtrip. I've co-registered > my 160 Biosemi electrodes to the standard_bem template (see attached > picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid > (picture attached, overlaid on standard_bem). I can prepare the leadfield > from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the > LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data and > averaged across it (the covariance matrix was also calculated); the > topography of this averaged data is attached. I then attempted a source fit > with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated primarily > by a source that isn't even inside the brain (as the sourceplot indicates). > So, I'm not sure exactly where/how I'm going wrong with this one, nor am I > sure how to trouble shoot it. Any guidance you might provide would be > greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Attended.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Unattended.PNG Type: image/png Size: 91677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceA_sourceplot.PNG Type: image/png Size: 143463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceA_NAI_sourceplot.PNG Type: image/png Size: 147302 bytes Desc: not available URL: From tommy.wilson at med.einstein.yu.edu Tue Jan 24 17:55:56 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Tue, 24 Jan 2017 16:55:56 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi there, I apologize. I found a small bug in that script regarding the fieldtrip directory. The revised version is attached. Best, Tommy On Tue, Jan 24, 2017 at 11:36 AM Tommy Wilson < tommy.wilson at med.einstein.yu.edu> wrote: > Hi Julian, > > Thank you so much for your reply. > > I've pasted the commented code below (I apologize for the code dump). I've > also attached an m-file to this email if you'd prefer to download it that > way. If relevant, you can download the leadfield, headmodel and electrode > locations here > > (that file also includes the raw data stored in variables A and U that I am > attempting to source-fit). > > As per your questions: I do indeed have a contrast between attended (A) > and unattended (U) conditions. I've written the code below to source-fit > both conditions and create the contrast. However, despite that the raw > topographies (see attached images) are different, the source-fits are the > same (...?). As a consequence, the contrast has no non-zero values. If > instead, I normalize to noise (i.e. generate the Neural Activity Index > ) > and look at a contrast there, we again see no non-zero values. > > Outside of the contrast, I've implemented your other suggestions. I've > rescaled the original ft_sourceplot such that you can see the extent of it > (see attached image). To my mind, it shouldn't look like this, but having > never done this before, I'm not quite sure what to expect. I've also > included an image of the ft_sourceplot for the Neural Activity Index of > sourceA which also appears to me to be artefactual. More to the point, I'd > expect that since the topographies for A and U are different, the NAIs > should be different, which is not the case. > > I'm sort of at a loss about how to proceed here. So, thank you very much > for taking the time to look into this. If I can supply anything else to > help, please don't hesitate to let me know. > > Best, > > Tommy Wilson > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\'; > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrast > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > % Check to see if any non-zero values exist in the contrast > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > warning('No non-zero contast values exist. ft_sourceplot will give an > error. Do not plot.'); > end > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > % See: > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > sourceA_NAI = sourceA; > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > sourceU_NAI = sourceU; > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > warning('No non-zero contast values exist. ft_sourceplot will give an > error. Do not plot.') > end > > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [0 3e3]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_NAI_interp); > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil wrote: > > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste your > code not only of the sourceanalysis, but the rest after which got you to > the plot? > It might also be the case that the automatic scaling in the source plot > throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual subject > MRIs, so I'm using the templates provided by fieldtrip. I've co-registered > my 160 Biosemi electrodes to the standard_bem template (see attached > picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid > (picture attached, overlaid on standard_bem). I can prepare the leadfield > from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the > LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data and > averaged across it (the covariance matrix was also calculated); the > topography of this averaged data is attached. I then attempted a source fit > with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated primarily > by a source that isn't even inside the brain (as the sourceplot indicates). > So, I'm not sure exactly where/how I'm going wrong with this one, nor am I > sure how to trouble shoot it. Any guidance you might provide would be > greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); From m.p.craddock at leeds.ac.uk Tue Jan 24 22:07:05 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Tue, 24 Jan 2017 21:07:05 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Tommy, > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > This is the problem. ft_sourceanalysis is using the covariance matrix and leadfield to construct a spatial filter for each grid point; if the covariance matrices are equivalent, the source solutions will be too. What you need to do is something like run the source analysis on data averaged over both conditions first, then take the filter from the combined analysis and run source analysis on each condition seperately. so say sourceAll is the result of ft_sourceanalysis(cfg,bothConditions) You'd do cfg.grid.filter = sourceAll.avg.filter then ft_sourceanalysis(cfg,A) ft_sourceanalysis(cfg,U) As a quick and dirty version I just replaced the covariance matrix in A with the average of the two A.cov and U.cov, ran sourceanalysis on that, then put A.cov back to its original value and ran sourceanalysis on each condition seperately. Spoiler: the unattended condition has lower activity everywhere :) There's some weirdness around the boundaries of the headmodel, not sure what's causing that exactly. Maybe try using a different source grid instead of the standard one... Cheers, Matt On 24/01/2017 16:36, Tommy Wilson wrote: > Hi Julian, > > Thank you so much for your reply. > > I've pasted the commented code below (I apologize for the code dump). > I've also attached an m-file to this email if you'd prefer to download > it that way. If relevant, you can download the leadfield, headmodel and > electrode locations here > > (that file also includes the raw data stored in variables A and U that I > am attempting to source-fit). > > As per your questions: I do indeed have a contrast between attended (A) > and unattended (U) conditions. I've written the code below to source-fit > both conditions and create the contrast. However, despite that the raw > topographies (see attached images) are different, the source-fits are > the same (...?). As a consequence, the contrast has no non-zero values. > If instead, I normalize to noise (i.e. generate the Neural Activity > Index > ) > and look at a contrast there, we again see no non-zero values. > > Outside of the contrast, I've implemented your other suggestions. I've > rescaled the original ft_sourceplot such that you can see the extent of > it (see attached image). To my mind, it shouldn't look like this, but > having never done this before, I'm not quite sure what to expect. I've > also included an image of the ft_sourceplot for the Neural Activity > Index of sourceA which also appears to me to be artefactual. More to the > point, I'd expect that since the topographies for A and U are different, > the NAIs should be different, which is not the case. > > I'm sort of at a loss about how to proceed here. So, thank you very much > for taking the time to look into this. If I can supply anything else to > help, please don't hesitate to let me know. > > Best, > > Tommy Wilson > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\'; > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrast > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > % Check to see if any non-zero values exist in the contrast > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > warning('No non-zero contast values exist. ft_sourceplot will give > an error. Do not plot.'); > end > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > % See: > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > sourceA_NAI = sourceA; > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > sourceU_NAI = sourceU; > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > warning('No non-zero contast values exist. ft_sourceplot will give > an error. Do not plot.') > end > > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [0 3e3]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_NAI_interp); > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > wrote: > > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste > your code not only of the sourceanalysis, but the rest after which > got you to the plot? > It might also be the case that the automatic scaling in the source > plot throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual > subject MRIs, so I'm using the templates provided by fieldtrip. I've > co-registered my 160 Biosemi electrodes to the standard_bem template > (see attached picture). For the sourcemodel, I'm using the > standard_sourcemodel3d5mm grid (picture attached, overlaid on > standard_bem). I can prepare the leadfield from there with > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data > and averaged across it (the covariance matrix was also calculated); > the topography of this averaged data is attached. I then attempted a > source fit with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated > primarily by a source that isn't even inside the brain (as the > sourceplot indicates). So, I'm not sure exactly where/how I'm going > wrong with this one, nor am I sure how to trouble shoot it. Any > guidance you might provide would be greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From jens.klinzing at uni-tuebingen.de Wed Jan 25 10:29:29 2017 From: jens.klinzing at uni-tuebingen.de (=?UTF-8?B?IkplbnMgS2xpbnppbmcsIFVuaSBUw7xiaW5nZW4i?=) Date: Wed, 25 Jan 2017 10:29:29 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> <5880823B.2050806@uni-tuebingen.de> Message-ID: <58886FF9.3050904@uni-tuebingen.de> Dear Elena, I'm glad the first problem is solved. About the second one: Are you referring to the yellowish background outside of the brain? My first guess would be that this is a mere plotting issue. Can you check whether there actually are non-NAN or even non-zero values for grid points marked as 'outside' (before interpolation and before and after contrasting)? If not, you know it is a problem with the plotting. Best, Jens > Elena Krugliakova > Donnerstag, 19. Januar 2017 13:55 > Dear Jens, > > Thank you for your answer! > 1. Indeed, I found where ft_sourceanalysis starts to recompute > transfer matrix and just loaded precomputed headmodel and sensors. Now > everything is fine, and it takes several seconds to run ft_sourceanalysis. > 2. About homogeneous "noise outside the mri scan". > Noise appears after I calculate difference between two sources, > following tutorial > http://www.fieldtriptoolbox.org/tutorial/beamformer. However, > sourceplot for not-contrasted conditions looks good. Maybe you could > give me an advice, how to get rid of this background noise. > > Kind Regards, > Elena > > > > > With difference calculation: > > cfg = []; > cfg.elec = elec; > cfg.headmodel = vol; > cfg.grid = leadfield; > cfg.keepleadfield = 'yes' > cfg.projectnoise = 'yes'; > cfg.frequency = [10 15]; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); > cfg.grid.filter = sourcePNandBS.avg.filter; > sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); > sourceBS = ft_sourceanalysis(cfg, freq_BS_Post); > *sourceDiff.avg.pow = (sourcePN.avg.pow - sourceBS.avg.pow) ./ > sourceBS.avg.pow;* > > cfg = []; > cfg.parameter = 'avg.pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > cfg.opacitymap = 'rampup'; > ft_sourceplot(cfg, sourceDiffIntNorm); > > figure > Inline images 1 > > > > > Without difference calculation: > > cfg = []; > cfg.elec = elec; > .......... > sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); > > cfg.grid.filter = sourcePNandBS.avg.filter; > > sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); > sourcePN.avg.pow = sourcePN.avg.pow ./ sourcePN.avg.noise; > > cfg = []; > cfg.parameter = 'avg.pow'; > sourcePN = ft_sourceinterpolate(cfg, sourcePN, mri); > > cfg = []; > sourcePNIntNorm = ft_volumenormalise(cfg, sourcePNInt); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > cfg.opacitymap = 'rampup'; > ft_sourceplot(cfg, sourcePNIntNorm); > > figure > Inline images 2 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > Jens Klinzing, Uni Tübingen > Donnerstag, 19. Januar 2017 10:09 > Dear Elena, > > Question 1: > I assume the reason it takes so long is that you are using a FEM-based > headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix > on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - > sb_transfer) every time you do a source reconstruction. For more > information see > http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 . > > You can circumvent the issue by computing the transfer matrix > beforehand and changing the code in a way that it doesnt compute a new > transfer matrix if you have already provided one. > > Alternatively you could use a BEM headmodel (dipoli if possible since > bemcp seems to have issues > http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2817). > > Question 2: > Did you check your segmentation, the headmodel and the coregistration > of electrodes/head every step of the way? If you fill all inside > voxels with 1s and plot that, do you see an obvious shift/rotation of > the "activity" in relation to the MRI? > > Best, > Jens > > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' > method applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to > call one ft_sourceanalysis. Maybe, there is a way to optimise the > procedure somehow? > > Second, at the end of analysis I obtain a very strange figure, on > which I see activity localised outside the mri scan. Mistake on which > step of analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - > sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 154917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 181508 bytes Desc: not available URL: From tommy.wilson at med.einstein.yu.edu Wed Jan 25 17:13:23 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Wed, 25 Jan 2017 11:13:23 -0500 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Matt, Thanks so much for your reply here! I believe I've correctly implemented your comments: I computed a common filter by source analyzing the combined (read: averaged) data/covariance matrix. In a second step, I used this filter to source localize each condition separately. I subsequently contrasted the two conditions, but I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the voxels. I attached an image of the ft_sourceplot to this email. (I don't know why the NaNs aren't masking appropriately, but I can figure that out on my own time). I also attempted your quick and dirty solution to see if I could reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow > sourceA.avg.pow in 99% of voxels), which is exactly the opposite of what you said you came up with. (The ft_sourceplot for this scenario looks identical to the first, which is unsurprising--in both cases, we used the average covariance matrix to construct the filters, so they ought to be identical). I must be doing something wrong here, but alas, I can't seem to put the pieces together. Any help/guidance you could provide would be deeply appreciated. I've attached the updated script to this email (and printed it below for posterity), and as before, the data can be found here . Again, thank you for taking the time to respond. Best, Tommy --- CODE --- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Average both conditions to generate common filter M = ft_timelockgrandaverage(struct(),A,U); M.cov = mean(cat(3,A.cov,U.cov),3); % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances % A.cov = U.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common filter sourceM = ft_sourceanalysis(cfg,M); % Add the common filter to the cfg cfg.grid.filter = sourceM.avg.filter; % Source fit the originals sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Matt's quick and dirty version % Replace A's cov matrix with an average of A.cov and U.cov tmp = A.cov; A.cov = mean(cat(3,tmp,U.cov),3); cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common test filter sourceA_common_test = ft_sourceanalysis(cfg,A); % Add common filter to configuration cfg.grid.filter = sourceA_common_test.avg.filter; % Replace original covariance matrix A.cov = tmp; % Now fit both A and U with the common test filter sourceA_test = ft_sourceanalysis(cfg,A); sourceU_test = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrasts sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; sourceContrast_test = sourceA_test; sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; % Gauge what percent of the contrast is negative (i.e. sourceU power > % sourceA power) perc_neg = sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); perc_neg_test = sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); sourceContrast_test_interp = ft_sourceinterpolate(cfg, sourceContrast_test, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_test_interp); On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock wrote: > Hi Tommy, > > > % Equate covariance matrices for now to rule out any differences in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > This is the problem. ft_sourceanalysis is using the covariance matrix > and leadfield to construct a spatial filter for each grid point; if the > covariance matrices are equivalent, the source solutions will be too. > > What you need to do is something like run the source analysis on data > averaged over both conditions first, then take the filter from the > combined analysis and run source analysis on each condition seperately. > > so say sourceAll is the result of > ft_sourceanalysis(cfg,bothConditions) > > You'd do > > cfg.grid.filter = sourceAll.avg.filter > > then > > ft_sourceanalysis(cfg,A) > ft_sourceanalysis(cfg,U) > > As a quick and dirty version I just replaced the covariance matrix in A > with the average of the two A.cov and U.cov, ran sourceanalysis on that, > then put A.cov back to its original value and ran sourceanalysis on each > condition seperately. Spoiler: the unattended condition has lower > activity everywhere :) > > There's some weirdness around the boundaries of the headmodel, not sure > what's causing that exactly. Maybe try using a different source grid > instead of the standard one... > > Cheers, > Matt > > On 24/01/2017 16:36, Tommy Wilson wrote: > > Hi Julian, > > > > Thank you so much for your reply. > > > > I've pasted the commented code below (I apologize for the code dump). > > I've also attached an m-file to this email if you'd prefer to download > > it that way. If relevant, you can download the leadfield, headmodel and > > electrode locations here > > > > (that file also includes the raw data stored in variables A and U that I > > am attempting to source-fit). > > > > As per your questions: I do indeed have a contrast between attended (A) > > and unattended (U) conditions. I've written the code below to source-fit > > both conditions and create the contrast. However, despite that the raw > > topographies (see attached images) are different, the source-fits are > > the same (...?). As a consequence, the contrast has no non-zero values. > > If instead, I normalize to noise (i.e. generate the Neural Activity > > Index > > neural_activity_index>) > > and look at a contrast there, we again see no non-zero values. > > > > Outside of the contrast, I've implemented your other suggestions. I've > > rescaled the original ft_sourceplot such that you can see the extent of > > it (see attached image). To my mind, it shouldn't look like this, but > > having never done this before, I'm not quite sure what to expect. I've > > also included an image of the ft_sourceplot for the Neural Activity > > Index of sourceA which also appears to me to be artefactual. More to the > > point, I'd expect that since the topographies for A and U are different, > > the NAIs should be different, which is not the case. > > > > I'm sort of at a loss about how to proceed here. So, thank you very much > > for taking the time to look into this. If I can supply anything else to > > help, please don't hesitate to let me know. > > > > Best, > > > > Tommy Wilson > > > > --- CODE --- > > > > %% Source fitting protocol > > % Fieldtrip path (to find template MRI) > > ftdir = 'your\path\here\'; > > > > % Equate covariance matrices for now to rule out any differences in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > %%% Do the LCMV sourcefitting > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > sourceU = ft_sourceanalysis(cfg,U); > > > > > > %%% Attempt a contrast > > % Create the contrast > > sourceContrast = sourceA; > > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > > > % Check to see if any non-zero values exist in the contrast > > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.'); > > end > > > > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > > % See: > > http://www.fieldtriptoolbox.org/tutorial/beamformer# > neural_activity_index > > sourceA_NAI = sourceA; > > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > > sourceU_NAI = sourceU; > > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.') > > end > > > > > > %%% Visualize the output > > % Load template MRI > > mri = ft_read_mri([ftdir > > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > > > % Interpolate source onto MRI > > cfg = []; > > cfg.parameter = 'avg.pow'; > > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > > > % Visualize with ft_sourceplot > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.funcolorlim = [0 3e3]; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_interp); > > > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_NAI_interp); > > > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > > wrote: > > > > Hi Tommy, > > > > did you do some sort of contrast (e.g. with the noise estimate or a > > baseline) after your source analysis? > > Right now, it's not clear what you are looking at. Could you paste > > your code not only of the sourceanalysis, but the rest after which > > got you to the plot? > > It might also be the case that the automatic scaling in the source > > plot throws you off - maybe try setting it by hand. > > > > Good luck, > > > > Julian > > > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > > > Hi all, > > > > > > I'm working with EEG data and I'm trying to get some basic source > > fitting up and running. Unfortunately, I don't have individual > > subject MRIs, so I'm using the templates provided by fieldtrip. I've > > co-registered my 160 Biosemi electrodes to the standard_bem template > > (see attached picture). For the sourcemodel, I'm using the > > standard_sourcemodel3d5mm grid (picture attached, overlaid on > > standard_bem). I can prepare the leadfield from there with > > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV > tutorial. > > > > > > To test this configuration, I've selected a time window in my data > > and averaged across it (the covariance matrix was also calculated); > > the topography of this averaged data is attached. I then attempted a > > source fit with the LCMV beamformer: > > > > > > cfg = []; > > > cfg.method = 'lcmv'; > > > cfg.grid = leadfield; > > > cfg.vol = vol; > > > cfg.elec = elec; > > > cfg.lcmv.lambda = '15%'; > > > cfg.lcmv.keepfilter = 'yes'; > > > cfg.lcmv.fixedori = 'yes'; > > > cfg.lcmv.projectnoise = 'yes'; > > > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > > > After interpolating to the single_subj_T1.nii provided with > > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > > sourceplot that is highly focal in nature (see attached picture). > > > > > > I'd find it very surprising if this topography were generated > > primarily by a source that isn't even inside the brain (as the > > sourceplot indicates). So, I'm not sure exactly where/how I'm going > > wrong with this one, nor am I sure how to trouble shoot it. Any > > guidance you might provide would be greatly appreciated. > > > > > > Thanks so much, > > > > > > Tommy > > > > > > > localization.PNG>___________________ > ____________________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Average both conditions to generate common filter M = ft_timelockgrandaverage(struct(),A,U); M.cov = mean(cat(3,A.cov,U.cov),3); % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances % A.cov = U.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common filter sourceM = ft_sourceanalysis(cfg,M); % Add the common filter to the cfg cfg.grid.filter = sourceM.avg.filter; % Source fit the originals sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Matt's quick and dirty version % Replace A's cov matrix with an average of A.cov and U.cov tmp = A.cov; A.cov = mean(cat(3,tmp,U.cov),3); cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common test filter sourceA_common_test = ft_sourceanalysis(cfg,A); % Add common filter to configuration cfg.grid.filter = sourceA_common_test.avg.filter; % Replace original covariance matrix A.cov = tmp; % Now fit both A and U with the common test filter sourceA_test = ft_sourceanalysis(cfg,A); sourceU_test = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrasts sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; sourceContrast_test = sourceA_test; sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; % Gauge what percent of the contrast is negative (i.e. sourceU power > % sourceA power) perc_neg = sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); perc_neg_test = sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); sourceContrast_test_interp = ft_sourceinterpolate(cfg, sourceContrast_test, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_test_interp); -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceContrast_sourceplot.PNG Type: image/png Size: 128252 bytes Desc: not available URL: From m.p.craddock at leeds.ac.uk Wed Jan 25 18:11:41 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Wed, 25 Jan 2017 17:11:41 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> Sorry Tommy, I misread the sign of my results - they're the same as yours :) I get the NaNs plotting thing sometimes too, never totally sure why as it seems intermittent. Cheers, Matt On 25/01/2017 16:13, Tommy Wilson wrote: > Hi Matt, > > Thanks so much for your reply here! > > I believe I've correctly implemented your comments: I computed a common > filter by source analyzing the combined (read: averaged) data/covariance > matrix. In a second step, I used this filter to source localize each > condition separately. I subsequently contrasted the two conditions, but > I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the > voxels. I attached an image of the ft_sourceplot to this email. (I don't > know why the NaNs aren't masking appropriately, but I can figure that > out on my own time). > > I also attempted your quick and dirty solution to see if I could > reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow >> sourceA.avg.pow in 99% of voxels), which is exactly the opposite of > what you said you came up with. (The ft_sourceplot for this scenario > looks identical to the first, which is unsurprising--in both cases, we > used the average covariance matrix to construct the filters, so they > ought to be identical). I must be doing something wrong here, but alas, > I can't seem to put the pieces together. > > Any help/guidance you could provide would be deeply appreciated. I've > attached the updated script to this email (and printed it below for > posterity), and as before, the data can be found here > . > > Again, thank you for taking the time to respond. > > Best, > > Tommy > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\fieldtrip-20160309'; > > % Average both conditions to generate common filter > M = ft_timelockgrandaverage(struct(),A,U); > M.cov = mean(cat(3,A.cov,U.cov),3); > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > % A.cov = U.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > % Generate common filter > sourceM = ft_sourceanalysis(cfg,M); > > % Add the common filter to the cfg > cfg.grid.filter = sourceM.avg.filter; > > % Source fit the originals > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > %%% Matt's quick and dirty version > % Replace A's cov matrix with an average of A.cov and U.cov > tmp = A.cov; > A.cov = mean(cat(3,tmp,U.cov),3); > > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > % Generate common test filter > sourceA_common_test = ft_sourceanalysis(cfg,A); > > % Add common filter to configuration > cfg.grid.filter = sourceA_common_test.avg.filter; > > % Replace original covariance matrix > A.cov = tmp; > > % Now fit both A and U with the common test filter > sourceA_test = ft_sourceanalysis(cfg,A); > sourceU_test = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrasts > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > sourceContrast_test = sourceA_test; > sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; > > % Gauge what percent of the contrast is negative (i.e. sourceU power > > % sourceA power) > perc_neg = > sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); > perc_neg_test = > sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); > sourceContrast_test_interp = ft_sourceinterpolate(cfg, > sourceContrast_test, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [-100 5]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceContrast_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [-100 5]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceContrast_test_interp); > > On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock > wrote: > > Hi Tommy, > > > % Equate covariance matrices for now to rule out any differences > in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > This is the problem. ft_sourceanalysis is using the covariance matrix > and leadfield to construct a spatial filter for each grid point; if the > covariance matrices are equivalent, the source solutions will be too. > > What you need to do is something like run the source analysis on data > averaged over both conditions first, then take the filter from the > combined analysis and run source analysis on each condition seperately. > > so say sourceAll is the result of > ft_sourceanalysis(cfg,bothConditions) > > You'd do > > cfg.grid.filter = sourceAll.avg.filter > > then > > ft_sourceanalysis(cfg,A) > ft_sourceanalysis(cfg,U) > > As a quick and dirty version I just replaced the covariance matrix in A > with the average of the two A.cov and U.cov, ran sourceanalysis on that, > then put A.cov back to its original value and ran sourceanalysis on each > condition seperately. Spoiler: the unattended condition has lower > activity everywhere :) > > There's some weirdness around the boundaries of the headmodel, not sure > what's causing that exactly. Maybe try using a different source grid > instead of the standard one... > > Cheers, > Matt > > On 24/01/2017 16:36, Tommy Wilson wrote: > > Hi Julian, > > > > Thank you so much for your reply. > > > > I've pasted the commented code below (I apologize for the code dump). > > I've also attached an m-file to this email if you'd prefer to download > > it that way. If relevant, you can download the leadfield, > headmodel and > > electrode locations here > > > > > > (that file also includes the raw data stored in variables A and U > that I > > am attempting to source-fit). > > > > As per your questions: I do indeed have a contrast between > attended (A) > > and unattended (U) conditions. I've written the code below to > source-fit > > both conditions and create the contrast. However, despite that the raw > > topographies (see attached images) are different, the source-fits are > > the same (...?). As a consequence, the contrast has no non-zero > values. > > If instead, I normalize to noise (i.e. generate the Neural Activity > > Index > > > >) > > and look at a contrast there, we again see no non-zero values. > > > > Outside of the contrast, I've implemented your other suggestions. I've > > rescaled the original ft_sourceplot such that you can see the > extent of > > it (see attached image). To my mind, it shouldn't look like this, but > > having never done this before, I'm not quite sure what to expect. I've > > also included an image of the ft_sourceplot for the Neural Activity > > Index of sourceA which also appears to me to be artefactual. More > to the > > point, I'd expect that since the topographies for A and U are > different, > > the NAIs should be different, which is not the case. > > > > I'm sort of at a loss about how to proceed here. So, thank you > very much > > for taking the time to look into this. If I can supply anything > else to > > help, please don't hesitate to let me know. > > > > Best, > > > > Tommy Wilson > > > > --- CODE --- > > > > %% Source fitting protocol > > % Fieldtrip path (to find template MRI) > > ftdir = 'your\path\here\'; > > > > % Equate covariance matrices for now to rule out any differences > in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > %%% Do the LCMV sourcefitting > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > sourceU = ft_sourceanalysis(cfg,U); > > > > > > %%% Attempt a contrast > > % Create the contrast > > sourceContrast = sourceA; > > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > > > % Check to see if any non-zero values exist in the contrast > > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.'); > > end > > > > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > > % See: > > > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > > > sourceA_NAI = sourceA; > > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > > sourceU_NAI = sourceU; > > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.') > > end > > > > > > %%% Visualize the output > > % Load template MRI > > mri = ft_read_mri([ftdir > > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > > > % Interpolate source onto MRI > > cfg = []; > > cfg.parameter = 'avg.pow'; > > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > > > % Visualize with ft_sourceplot > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.funcolorlim = [0 3e3]; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_interp); > > > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_NAI_interp); > > > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > > >> wrote: > > > > Hi Tommy, > > > > did you do some sort of contrast (e.g. with the noise estimate > or a > > baseline) after your source analysis? > > Right now, it's not clear what you are looking at. Could you paste > > your code not only of the sourceanalysis, but the rest after which > > got you to the plot? > > It might also be the case that the automatic scaling in the source > > plot throws you off - maybe try setting it by hand. > > > > Good luck, > > > > Julian > > > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > > > Hi all, > > > > > > I'm working with EEG data and I'm trying to get some basic > source > > fitting up and running. Unfortunately, I don't have individual > > subject MRIs, so I'm using the templates provided by > fieldtrip. I've > > co-registered my 160 Biosemi electrodes to the standard_bem > template > > (see attached picture). For the sourcemodel, I'm using the > > standard_sourcemodel3d5mm grid (picture attached, overlaid on > > standard_bem). I can prepare the leadfield from there with > > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV > tutorial. > > > > > > To test this configuration, I've selected a time window in > my data > > and averaged across it (the covariance matrix was also > calculated); > > the topography of this averaged data is attached. I then > attempted a > > source fit with the LCMV beamformer: > > > > > > cfg = []; > > > cfg.method = 'lcmv'; > > > cfg.grid = leadfield; > > > cfg.vol = vol; > > > cfg.elec = elec; > > > cfg.lcmv.lambda = '15%'; > > > cfg.lcmv.keepfilter = 'yes'; > > > cfg.lcmv.fixedori = 'yes'; > > > cfg.lcmv.projectnoise = 'yes'; > > > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > > > After interpolating to the single_subj_T1.nii provided with > > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > > sourceplot that is highly focal in nature (see attached picture). > > > > > > I'd find it very surprising if this topography were generated > > primarily by a source that isn't even inside the brain (as the > > sourceplot indicates). So, I'm not sure exactly where/how I'm > going > > wrong with this one, nor am I sure how to trouble shoot it. Any > > guidance you might provide would be greatly appreciated. > > > > > > Thanks so much, > > > > > > Tommy > > > > > > > > localization.PNG>_______________________________________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From tommy.wilson at med.einstein.yu.edu Wed Jan 25 20:47:13 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Wed, 25 Jan 2017 14:47:13 -0500 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> Message-ID: Oh! Whew. Well, at least there's that. (It's the small things, you know?) But, doesn't that lead to another question? As you can see from the topographies attached, the Attended topography is much higher in amplitude than the unattended (they are on the same color scale). Perhaps this is a moment when my intuition doesn't matter, but wouldn't you expect that the source generating the Attended topography would have greater power than the Unattended source? Or is there something I don't understand here? Thanks again for taking the time to respond. I truly appreciate your help. Best, Tommy On Wed, Jan 25, 2017 at 12:11 PM, Matt Craddock wrote: > Sorry Tommy, I misread the sign of my results - they're the same as yours > :) I get the NaNs plotting thing sometimes too, never totally sure why as > it seems intermittent. > > Cheers, > Matt > > On 25/01/2017 16:13, Tommy Wilson wrote: > >> Hi Matt, >> >> Thanks so much for your reply here! >> >> I believe I've correctly implemented your comments: I computed a common >> filter by source analyzing the combined (read: averaged) data/covariance >> matrix. In a second step, I used this filter to source localize each >> condition separately. I subsequently contrasted the two conditions, but >> I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the >> voxels. I attached an image of the ft_sourceplot to this email. (I don't >> know why the NaNs aren't masking appropriately, but I can figure that >> out on my own time). >> >> I also attempted your quick and dirty solution to see if I could >> reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow >> >>> sourceA.avg.pow in 99% of voxels), which is exactly the opposite of >>> >> what you said you came up with. (The ft_sourceplot for this scenario >> looks identical to the first, which is unsurprising--in both cases, we >> used the average covariance matrix to construct the filters, so they >> ought to be identical). I must be doing something wrong here, but alas, >> I can't seem to put the pieces together. >> >> Any help/guidance you could provide would be deeply appreciated. I've >> attached the updated script to this email (and printed it below for >> posterity), and as before, the data can be found here >> . >> >> >> Again, thank you for taking the time to respond. >> >> Best, >> >> Tommy >> >> --- CODE --- >> >> %% Source fitting protocol >> % Fieldtrip path (to find template MRI) >> ftdir = 'your\path\here\fieldtrip-20160309'; >> >> % Average both conditions to generate common filter >> M = ft_timelockgrandaverage(struct(),A,U); >> M.cov = mean(cat(3,A.cov,U.cov),3); >> >> % Equate covariance matrices for now to rule out any differences in the >> % source fit due to differences in covariances >> % A.cov = U.cov; >> >> %%% Do the LCMV sourcefitting >> cfg = []; >> cfg.method = 'lcmv'; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.elec = elec; >> cfg.lcmv.lambda = '15%'; >> cfg.lcmv.keepfilter = 'yes'; >> cfg.lcmv.fixedori = 'yes'; >> cfg.lcmv.projectnoise = 'yes'; >> >> % Generate common filter >> sourceM = ft_sourceanalysis(cfg,M); >> >> % Add the common filter to the cfg >> cfg.grid.filter = sourceM.avg.filter; >> >> % Source fit the originals >> sourceA = ft_sourceanalysis(cfg,A); >> sourceU = ft_sourceanalysis(cfg,U); >> >> %%% Matt's quick and dirty version >> % Replace A's cov matrix with an average of A.cov and U.cov >> tmp = A.cov; >> A.cov = mean(cat(3,tmp,U.cov),3); >> >> cfg = []; >> cfg.method = 'lcmv'; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.elec = elec; >> cfg.lcmv.lambda = '15%'; >> cfg.lcmv.keepfilter = 'yes'; >> cfg.lcmv.fixedori = 'yes'; >> cfg.lcmv.projectnoise = 'yes'; >> >> % Generate common test filter >> sourceA_common_test = ft_sourceanalysis(cfg,A); >> >> % Add common filter to configuration >> cfg.grid.filter = sourceA_common_test.avg.filter; >> >> % Replace original covariance matrix >> A.cov = tmp; >> >> % Now fit both A and U with the common test filter >> sourceA_test = ft_sourceanalysis(cfg,A); >> sourceU_test = ft_sourceanalysis(cfg,U); >> >> >> %%% Attempt a contrast >> % Create the contrasts >> sourceContrast = sourceA; >> sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; >> sourceContrast_test = sourceA_test; >> sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; >> >> % Gauge what percent of the contrast is negative (i.e. sourceU power > >> % sourceA power) >> perc_neg = >> sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./num >> el(sourceContrast.avg.pow(sourceContrast.inside(:))); >> perc_neg_test = >> sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(: >> ))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); >> >> %%% Visualize the output >> % Load template MRI >> mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); >> >> % Interpolate source onto MRI >> cfg = []; >> cfg.parameter = 'avg.pow'; >> sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); >> sourceContrast_test_interp = ft_sourceinterpolate(cfg, >> sourceContrast_test, mri); >> >> % Visualize with ft_sourceplot >> cfg = []; >> cfg.method = 'ortho'; >> cfg.funparameter = 'avg.pow'; >> cfg.funcolorlim = [-100 5]; >> cfg.maskparameter = cfg.funparameter; >> ft_sourceplot(cfg, sourceContrast_interp); >> >> cfg = []; >> cfg.method = 'ortho'; >> cfg.funparameter = 'avg.pow'; >> cfg.funcolorlim = [-100 5]; >> cfg.maskparameter = cfg.funparameter; >> ft_sourceplot(cfg, sourceContrast_test_interp); >> >> On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock > > wrote: >> >> Hi Tommy, >> >> > % Equate covariance matrices for now to rule out any differences >> in the >> > % source fit due to differences in covariances >> > U.cov = A.cov; >> > >> >> This is the problem. ft_sourceanalysis is using the covariance matrix >> and leadfield to construct a spatial filter for each grid point; if >> the >> covariance matrices are equivalent, the source solutions will be too. >> >> What you need to do is something like run the source analysis on data >> averaged over both conditions first, then take the filter from the >> combined analysis and run source analysis on each condition >> seperately. >> >> so say sourceAll is the result of >> ft_sourceanalysis(cfg,bothConditions) >> >> You'd do >> >> cfg.grid.filter = sourceAll.avg.filter >> >> then >> >> ft_sourceanalysis(cfg,A) >> ft_sourceanalysis(cfg,U) >> >> As a quick and dirty version I just replaced the covariance matrix in >> A >> with the average of the two A.cov and U.cov, ran sourceanalysis on >> that, >> then put A.cov back to its original value and ran sourceanalysis on >> each >> condition seperately. Spoiler: the unattended condition has lower >> activity everywhere :) >> >> There's some weirdness around the boundaries of the headmodel, not >> sure >> what's causing that exactly. Maybe try using a different source grid >> instead of the standard one... >> >> Cheers, >> Matt >> >> On 24/01/2017 16:36, Tommy Wilson wrote: >> > Hi Julian, >> > >> > Thank you so much for your reply. >> > >> > I've pasted the commented code below (I apologize for the code >> dump). >> > I've also attached an m-file to this email if you'd prefer to >> download >> > it that way. If relevant, you can download the leadfield, >> headmodel and >> > electrode locations here >> > >> > dump.mat?dl=0 >> > dump.mat?dl=0>> >> > (that file also includes the raw data stored in variables A and U >> that I >> > am attempting to source-fit). >> > >> > As per your questions: I do indeed have a contrast between >> attended (A) >> > and unattended (U) conditions. I've written the code below to >> source-fit >> > both conditions and create the contrast. However, despite that the >> raw >> > topographies (see attached images) are different, the source-fits >> are >> > the same (...?). As a consequence, the contrast has no non-zero >> values. >> > If instead, I normalize to noise (i.e. generate the Neural Activity >> > Index >> > >> > activity_index >> > activity_index>>) >> > and look at a contrast there, we again see no non-zero values. >> > >> > Outside of the contrast, I've implemented your other suggestions. >> I've >> > rescaled the original ft_sourceplot such that you can see the >> extent of >> > it (see attached image). To my mind, it shouldn't look like this, >> but >> > having never done this before, I'm not quite sure what to expect. >> I've >> > also included an image of the ft_sourceplot for the Neural Activity >> > Index of sourceA which also appears to me to be artefactual. More >> to the >> > point, I'd expect that since the topographies for A and U are >> different, >> > the NAIs should be different, which is not the case. >> > >> > I'm sort of at a loss about how to proceed here. So, thank you >> very much >> > for taking the time to look into this. If I can supply anything >> else to >> > help, please don't hesitate to let me know. >> > >> > Best, >> > >> > Tommy Wilson >> > >> > --- CODE --- >> > >> > %% Source fitting protocol >> > % Fieldtrip path (to find template MRI) >> > ftdir = 'your\path\here\'; >> > >> > % Equate covariance matrices for now to rule out any differences >> in the >> > % source fit due to differences in covariances >> > U.cov = A.cov; >> > >> > %%% Do the LCMV sourcefitting >> > cfg = []; >> > cfg.method = 'lcmv'; >> > cfg.grid = leadfield; >> > cfg.vol = vol; >> > cfg.elec = elec; >> > cfg.lcmv.lambda = '15%'; >> > cfg.lcmv.keepfilter = 'yes'; >> > cfg.lcmv.fixedori = 'yes'; >> > cfg.lcmv.projectnoise = 'yes'; >> > >> > sourceA = ft_sourceanalysis(cfg,A); >> > sourceU = ft_sourceanalysis(cfg,U); >> > >> > >> > %%% Attempt a contrast >> > % Create the contrast >> > sourceContrast = sourceA; >> > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; >> > >> > % Check to see if any non-zero values exist in the contrast >> > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) >> > warning('No non-zero contast values exist. ft_sourceplot will >> give >> > an error. Do not plot.'); >> > end >> > >> > >> > %%% Instead of a contrast, look at the Neural Activity Index (NAI) >> > % See: >> > >> http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_ >> activity_index >> > activity_index> >> > sourceA_NAI = sourceA; >> > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; >> > sourceU_NAI = sourceU; >> > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; >> > >> > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - >> > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) >> > warning('No non-zero contast values exist. ft_sourceplot will >> give >> > an error. Do not plot.') >> > end >> > >> > >> > %%% Visualize the output >> > % Load template MRI >> > mri = ft_read_mri([ftdir >> > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); >> > >> > % Interpolate source onto MRI >> > cfg = []; >> > cfg.parameter = 'avg.pow'; >> > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); >> > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); >> > >> > % Visualize with ft_sourceplot >> > cfg = []; >> > cfg.method = 'ortho'; >> > cfg.funparameter = 'avg.pow'; >> > cfg.funcolorlim = [0 3e3]; >> > cfg.maskparameter = cfg.funparameter; >> > ft_sourceplot(cfg, sourceA_interp); >> > >> > cfg = []; >> > cfg.method = 'ortho'; >> > cfg.funparameter = 'avg.pow'; >> > cfg.maskparameter = cfg.funparameter; >> > ft_sourceplot(cfg, sourceA_NAI_interp); >> > >> > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > >> > >> >> wrote: >> > >> > Hi Tommy, >> > >> > did you do some sort of contrast (e.g. with the noise estimate >> or a >> > baseline) after your source analysis? >> > Right now, it's not clear what you are looking at. Could you >> paste >> > your code not only of the sourceanalysis, but the rest after >> which >> > got you to the plot? >> > It might also be the case that the automatic scaling in the >> source >> > plot throws you off - maybe try setting it by hand. >> > >> > Good luck, >> > >> > Julian >> > >> > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: >> > >> > > Hi all, >> > > >> > > I'm working with EEG data and I'm trying to get some basic >> source >> > fitting up and running. Unfortunately, I don't have individual >> > subject MRIs, so I'm using the templates provided by >> fieldtrip. I've >> > co-registered my 160 Biosemi electrodes to the standard_bem >> template >> > (see attached picture). For the sourcemodel, I'm using the >> > standard_sourcemodel3d5mm grid (picture attached, overlaid on >> > standard_bem). I can prepare the leadfield from there with >> > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV >> tutorial. >> > > >> > > To test this configuration, I've selected a time window in >> my data >> > and averaged across it (the covariance matrix was also >> calculated); >> > the topography of this averaged data is attached. I then >> attempted a >> > source fit with the LCMV beamformer: >> > > >> > > cfg = []; >> > > cfg.method = 'lcmv'; >> > > cfg.grid = leadfield; >> > > cfg.vol = vol; >> > > cfg.elec = elec; >> > > cfg.lcmv.lambda = '15%'; >> > > cfg.lcmv.keepfilter = 'yes'; >> > > cfg.lcmv.fixedori = 'yes'; >> > > cfg.lcmv.projectnoise = 'yes'; >> > > >> > > sourceA = ft_sourceanalysis(cfg,A); >> > > >> > > After interpolating to the single_subj_T1.nii provided with >> > ft_sourceinterpolate and plotting with ft_sourceplot, I am >> given a >> > sourceplot that is highly focal in nature (see attached >> picture). >> > > >> > > I'd find it very surprising if this topography were generated >> > primarily by a source that isn't even inside the brain (as the >> > sourceplot indicates). So, I'm not sure exactly where/how I'm >> going >> > wrong with this one, nor am I sure how to trouble shoot it. Any >> > guidance you might provide would be greatly appreciated. >> > > >> > > Thanks so much, >> > > >> > > Tommy >> > > >> > > > > >> localization.PNG>____________________ >> ___________________________ >> > > fieldtrip mailing list >> > > fieldtrip at donders.ru.nl >> > >> > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > >> > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Attended.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Unattended.PNG Type: image/png Size: 91677 bytes Desc: not available URL: From suzannevdveldt at gmail.com Wed Jan 25 22:55:44 2017 From: suzannevdveldt at gmail.com (Suzanne van der Veldt) Date: Wed, 25 Jan 2017 16:55:44 -0500 Subject: [FieldTrip] extracting spikes from new Message-ID: Hello all, Sorry to trouble you. I am excited to get starting with using FieldTrip for my data analysis, using in vivo ephys data recorded with plexon. I have my sorted spikes in .nex format. Unfortunately, field trip does not seem to be able to import my data. >> [rec1] = ft_read_spike('test', 'plexon_nex', '/Users/username/Documents/export’) Error using ft_read_spike (line 276) unsupported data format (unknown The .nex file is a regular file. I am running Matlab R2015b from Mac OSx Sierra 10.12.2. I hope someone might be able to give me a hint of what might be the problem. Kind regards, Suzanne van der Veldt PhD student McGill & Université de Bordeaux From tfkustermann at gmail.com Thu Jan 26 17:34:11 2017 From: tfkustermann at gmail.com (Thomas Kustermann) Date: Thu, 26 Jan 2017 17:34:11 +0100 Subject: [FieldTrip] Source statistic issue - between trials In-Reply-To: References: Message-ID: Hey Michał, I think your problem lies within the use of "ft_statfun_depsamplesT". FieldTrip then assumes that each trial index from condition one is paired with the same trial index from condition two which is why you get the output "repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 " In your case the design matrix should only include your first row and no uvar, statfun being ft_statfun_indepsamplesT. See: http://www.fieldtriptoolbox.org/tutorial/cluster_permutation _freq#permutation_test Cheers On Tue, Jan 24, 2017 at 3:21 PM, Michał Komorowski wrote: > Dear community, > > Currently I am working on source analysis from EEG data. I have some > trouble using ft_sourcestatistics do a between-trials analysis (single > subject). > I am trying to compare source from trials from task type A (ctrl) to with > trials from task type B (task). Mainly I rely on > http://www.fieldtriptoolbox.org/example/source_statistics . > > For almost week I am trying find a solution, inculding testing > ft_sourcestatistics with different combinations of data: > 1) source 1 : no ft_sourcedescriptives and no ft_sourceinterpolate used > 2) source 2 : used ft_sourcedescriptives and no ft_sourceinterpolate used > 3) source 3 : used ft_sourcedescriptives and used ft_sourceinterpolate > > For cases 1) and 2) I get very similar errors "Invalid specification of > the design array. Error using ft_statistics_montecarlo (line 242) could not > determine the parametric critical value for clustering" (full error > messages at the bottom). In case 3) I cannot run ft_statistics because > there are no trials anymore. > I have tried changing design matrix, search community messages for some > advice and read related articles on fieldtriptoolbox site, but I have not > find the answer. > > Any help would be appreciated. > > Michał Komorowski > > > Statistics code: > > cfg = []; > %cfg.dim = source.dim; % there is no such field in the data > cfg.method = 'montecarlo'; > cfg.statistic = 'ft_statfun_depsamplesT'; > cfg.parameter = 'pow'; > cfg.correctm = 'cluster'; > cfg.numrandomization = 100; > cfg.alpha = 0.05; > cfg.correcttail = 'alpha'; % http://www.fieldtriptoolbox.or > g/faq/why_should_i_use_the_cfg.correcttail_option_when_using > _statistics_montecarlo > cfg.tail = 0; % two sided test > cfg.design(1,:) = design; % condition code > cfg.design(2,:) = [1:length(find(design==1)) 1:length(find(design==2))]; % > trial indices > cfg.uvar = 2; % unit of observation variable: trials > cfg.ivar = 1; % independent variable: condition code > % I think design matrix is ok according to: http://www.fieldtriptoolbox.or > g/walkthrough#paired_comparison) > > stat = ft_sourcestatistics(cfg, source); > > > > > Data structures and error messages > > Case 1) no ft_sourcedescriptives and no ft_sourceinterpolate used > > source = > > freq: 10 > cumtapcnt: [21x1 double] > inside: [231420x1 logical] > pos: [231420x3 double] > method: 'rawtrial' > trial: [1x21 struct] > df: 21 > cfg: [1x1 struct] > > the call to "ft_selectdata" took 1 seconds > using "ft_statistics_montecarlo" for the statistical testing > using connectivity of voxels in 3-D volume > using "ft_statfun_depsamplesT" for the single-sample statistics > constructing randomized design > total number of measurements = 21 > total number of variables = 2 > number of independent variables = 1 > number of unit variables = 1 > number of within-cell variables = 0 > number of control variables = 0 > using a permutation resampling approach > repeated measurement in variable 2 over 11 levels > number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 > computing a parametric threshold for clustering > Error using ft_statfun_depsamplesT (line 84) > Invalid specification of the design array. > Error using ft_statistics_montecarlo (line 242) > could not determine the parametric critical value for clustering > > Error in ft_sourcestatistics (line 205) > [stat, cfg] = statmethod(cfg, dat, design); > > >> cfg.design > > ans = > > 1 1 1 1 1 1 1 1 1 1 1 2 > 2 2 2 2 2 2 2 2 2 > 1 2 3 4 5 6 7 8 9 10 11 1 > 2 3 4 5 6 7 8 9 10 > > > > Case 2) used ft_sourcedescriptives and no ft_sourceinterpolate used > > source_app = > > freq: 10 > cumtapcnt: [21x1 double] > inside: [231420x1 logical] > pos: [231420x3 double] > method: 'rawtrial' > trial: [1x21 struct] > df: 21 > cfg: [1x1 struct] > > the call to "ft_selectdata" took 0 seconds > using "ft_statistics_montecarlo" for the statistical testing > using connectivity of voxels in 3-D volume > using "ft_statfun_depsamplesT" for the single-sample statistics > constructing randomized design > total number of measurements = 21 > total number of variables = 2 > number of independent variables = 1 > number of unit variables = 1 > number of within-cell variables = 0 > number of control variables = 0 > using a permutation resampling approach > repeated measurement in variable 2 over 11 levels > number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 > computing a parametric threshold for clustering > Error using ft_statfun_depsamplesT (line 84) > Invalid specification of the design array. > Error using ft_statistics_montecarlo (line 242) > could not determine the parametric critical value for clustering > > Error in ft_sourcestatistics (line 205) > [stat, cfg] = statmethod(cfg, dat, design); > > > > Case 3) used ft_sourcedescriptives and used ft_sourceinterpolate > > source_mri_align_ctrl = > > freq: 10 > anatomy: [128x128x128 double] > coordsys: 'spm' > dim: [128 128 128] > pos: [2097152x3 double] > transform: [4x4 double] > unit: 'mm' > inside: [128x128x128 logical] > pow: [2097152x1 double] > cfg: [1x1 struct] > > % there is no trials so one cannot conduct between-trials statistics ... > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behzadiravani at gmail.com Thu Jan 26 17:36:28 2017 From: behzadiravani at gmail.com (Behzad Iravani) Date: Thu, 26 Jan 2017 17:36:28 +0100 Subject: [FieldTrip] Symmetric Source Reconstruction Message-ID: Dear FieldTrip experts , I'm interested to perform symmetric source reconstruction on time lock data. However I encountered an error. here is my code: cfg = []; cfg.grid.unit = 'mm'; cfg.grid.resolution = 5; cfg.grid.tight = 'yes'; cfg.inwardshift = -2; cfg.headmodel = vol; cfg.symmetric ='y'; % symmetric sources grid = ft_prepare_sourcemodel(cfg); % timelock data for two conditions load timelockA %co-variance computed load timelockB %co-variance computed load timeloackAB %co-variance computed load elecfile.mat % sensor positions load vol.mat % pre-compute head model cfg = []; cfg.method = 'lcmv'; cfg.grid = grid; cfg.headmodel = vol; cfg.elec = elecfile; cfg.keepfilter = 'yes'; source = ft_sourceanalysis(timeloackAB); % compute common filter cfg.keepfilter = 'no'; cfg.grid.filter =source.avg.filter sourceA = ft_sourceanalysis(timeloackA); % compute common filter sourceB = ft_sourceanalysis(timeloackA); % compute common filter % Contrast Condition A versus B cfg = []; cfg.parameter = 'pow'; cfg.operation = '(x1./x2-1)'; SourceC= ft_math(cfg,sourceA ,sourceB); load mri.mat % load anatomical image cfg = []; cfg.parameter = 'pow'; sourcePostInt = ft_sourceinterpolate(cfg, SourceC ,mri); here I get error in ft_warp_apply because the grid.pos is 6*n which it is supposed to be 3*n, since I chose the symmetric option it turned to 6*n. How can I solve this problem? Thanks in advance Best Behzad -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.chait at ucl.ac.uk Thu Jan 26 18:11:34 2017 From: m.chait at ucl.ac.uk (Chait, Maria) Date: Thu, 26 Jan 2017 17:11:34 +0000 Subject: [FieldTrip] (deadline approaching) Post-Doc position at UCL Ear Institute Message-ID: (please forward) A postdoctoral research associate position is available at the UCL Ear Institute's 'Auditory Cognitive Neuroscience Lab'. The project, titled "How the brain detects patterns in sound sequences", will be supervised by Dr Maria Chait and conducted in collaboration with Dr. Marcus Pearce (Queen Mary University, London) and colleagues at the UCL Wellcome Trust centre for neuroimaging. The post is funded for 34 months in the first instance and involves a combination of behavioural, computational, eye tracking, and functional brain imaging (EEG, MEG, fMRI) experiments in humans. For more information about the post please see the lab website: http://www.ucl.ac.uk/ear/research/chaitlab/vacancies The Ear Institute is a leading interdisciplinary centre for hearing research in Europe, situated within one of the strongest neuroscience communities in the world at University College London Key Requirements The successful applicant will have a PhD in neuroscience or a neuroscience-related discipline and proven ability to conduct high-quality original research and prepare results for publication. Essential skills include excellent time-management and organizational ability; proficiency in computer programming and good interpersonal, oral and written communication skills. Previous experience with functional brain imaging, neural data analysis, psychophysical assessment, and/or auditory science or acoustics would be desirable. Further Details You should apply for this post (Ref #: 1618836) through UCL's online recruitment website, www.ucl.ac.uk/hr/jobs, where you can download a job description and person specifications. Closing Date for applications is: 1 Feb 2017 For an informal discussion please contact Dr. Maria Chait (m.chait at ucl.ac.uk). Maria Chait PhD m.chait at ucl.ac.uk Reader in Auditory Cognitive Neuroscience Lab site: http://www.ucl.ac.uk/ear/research/chaitlab/ UCL Ear Institute 332 Gray's Inn Road London WC1X 8EE -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.oostenveld at donders.ru.nl Fri Jan 27 08:45:20 2017 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Fri, 27 Jan 2017 08:45:20 +0100 Subject: [FieldTrip] Week-long summer course on data analysis in MATLAB References: Message-ID: <9640D9F6-AABC-4214-AE79-DC23FA95757A@donders.ru.nl> Dear FieldTrip users My colleague Mike X Cohen will be teaching a week-long course coming summer in Nijmegen, Netherlands, called "Math and Matlab for Neuroscientists." It is designed for PhDs/postdocs. He taught this course last year and it was very successful. See attached for details and feel free to distribute this flyer as you see fit. best regards, Robert PS we will also be organizing the "Advanced MEG/EEG analysis toolkit course” (a.k.a. the FieldTrip course) in spring of this year. Once the date for that has been settled, it will be announced on this email list and details will be posted on http://www.fieldtriptoolbox.org/workshop -------------- next part -------------- A non-text attachment was scrubbed... Name: MathMatlab_Radboud2017.pdf Type: application/pdf Size: 1403012 bytes Desc: not available URL: -------------- next part -------------- From tmadsen at emory.edu Fri Jan 27 17:44:31 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Fri, 27 Jan 2017 11:44:31 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis In-Reply-To: References: Message-ID: Yes, thank you! That's exactly what I was thinking - I'll be glad to have your paper to cite in my methods section. ;-) I'm forwarding your email back to the listserv and other interested parties for reference. Thanks, Teresa On Thu, Jan 26, 2017 at 10:07 AM, berry van den berg wrote: > Hi Teresa, > > Maybe the following helps to gain a bit more insight. > > Thanks for the interesting discussion. We recently published an article > using what you describe: the log(power) and subsequently z-scoring across > trials on each time/ freq point. See http://rdcu.be/oOjc > > For the frequency analysis we were mostly interested in prestimulus > activity related to RTs and time-in-session which basically makes the use > of a prestimulus baseline correction invalid. Using the log transformed > power and z-scoring those gave pretty solid model fits. > > The data is not completely normal yet but pretty close (see plot below, > which comes from the prestimulus period [-700 to stim onset] in the alpha > [8 to 14Hz] range). For fitting a linear (or nonlinear) model, log > transforming the data was a necessary step. > > [image: Inline images 1] > > > > > > > > > On 10 January 2017 at 21:01, Teresa Madsen wrote: > >> Thanks for the reference. In return, I also recommend reading Ciuparu >> and Mures an's recent rebuttal: >> >> European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, >> doi:10.1111/ejn.13179 >> TECHNICAL SPOTLIGHT >> Sources of bias in single-trial normalization procedures >> >> They demonstrate that the positive bias Grandchamp and Delorme warned >> about with single-trial baseline normalization was, in fact, due to the >> correlated numerators and denominators in each of the baseline >> normalization procedures they tested, which was, in turn, caused by the >> skewed distributions of baseline power values. They demonstrate that this >> bias is reduced by using a much longer baseline, ideally incorporated into >> the experimental design, but when that's not possible, stitching together >> the baselines of many trials. >> >> Neither article addresses my specific question of whether it would be >> even better to log-transform the raw power values before averaging, so I >> suppose I'll have to test it myself and write my own methods article! 🤓 >> >> I will go ahead and incorporate some of these alternative baseline >> normalization methods in my git fork of FieldTrip as I go along with my own >> analyses, so let me know if anyone else would find them useful, and I'll >> submit a pull request to contribute them to the master branch. >> >> Thanks for the fruitful discussion, all! >> ~Teresa >> >> >> On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: >> >>> Indeed, in a separate thread with Michael Cohen several months back he >>> suggested precisely that paper. >>> >>> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" < >>> nick.peatfield at gmail.com> wrote: >>> >>>> I think this paper is relevant to this discussion. >>>> >>>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >>>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>>> >>>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>>> >>>> >>>> >>>> On 19 December 2016 at 13:08, Teresa Madsen wrote: >>>> >>>>> I appreciate everyone's feedback, but I still wonder if something is >>>>> being missed. I understand that the non-normally distributed power values >>>>> may be less of an issue when performing non-parametric stats or even a >>>>> paired-samples t-test that looks at difference values which may be normal >>>>> even when the raw data isn't. However, my concern comes into play even >>>>> before these statistical comparisons are made, whenever any averaging is >>>>> done to freq-type data across times, frequencies, trials, electrodes, >>>>> subjects, etc. That means any time any of these configuration options are >>>>> used for any of these functions, and probably more: >>>>> >>>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>>> cfg.avgoverfreq = 'yes'; >>>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>>> >>>>> In each case, if raw power values are averaged, the result will be >>>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>>> treated identically, but the specific case that triggered my concern was in >>>>> ft_freqbaseline, where the individual time-frequency bins are compared to >>>>> the mean over time for the baseline period. For example, when using >>>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>>>> data does indeed have a more normal distribution over time, but the mean >>>>> over the baseline time period is performed *before* the log transform, when >>>>> the distribution is still highly skewed: >>>>> >>>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>>> size(data, 3)]); >>>>> data = 10*log10(data ./ meanVals); >>>>> >>>>> That's what I had originally done when analyzing data for my SfN >>>>> poster, when I realized the background noise that shouldn't have changed >>>>> much from baseline was mostly showing a decrease from baseline of about >>>>> -3dB. >>>>> >>>>> Now, I've realized I'm seeing this as more of a problem than others >>>>> because of another tweak I made, which was to use a long, separate baseline >>>>> recording to normalize my trial data, rather than a short pre-trial period >>>>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>>>> for a baseline power estimate might be okay because overlapping time points >>>>> in the original data are used to calculate those power values anyway, >>>>> probably making them less skewed, but also (it seems to me) more arbitrary >>>>> and prone to error. I already offered my custom function BLnorm.m to one >>>>> person who was asking about this issue of normalizing to a separate >>>>> baseline recording, and I would be happy to contribute it to FieldTrip if >>>>> others would appreciate it. >>>>> >>>>> Since a few people suggested using the median, and it is also >>>>> suggested in Cohen's textbook >>>>> as >>>>> an alternative measure of the central tendency for skewed raw power values, >>>>> I wonder if the simplest fix might be to add an option to select mean or >>>>> median in each of the functions listed above. Another possibility would be >>>>> adding an option to transform the power values upon output from >>>>> ft_freqanalysis. >>>>> >>>>> Would anyone else find such changes useful? >>>>> >>>>> Thanks, >>>>> Teresa >>>>> >>>>> >>>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>>> J.Herring at donders.ru.nl> wrote: >>>>> >>>>>> In terms of statistics it is the distribution of values that you do >>>>>> the statistics on that matters. In case of a paired-samples t-test when >>>>>> comparing two conditions, it is the distribution of difference values that >>>>>> has to be normally distributed. The distribution of difference values is >>>>>> often normal given two similarly non-normal distributions, offering no >>>>>> complications for a regular parametric test. >>>>>> >>>>>> >>>>>> >>>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>>> normality, so you should have no problem there either. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* fieldtrip-bounces at science.ru.nl [mailto: >>>>>> fieldtrip-bounces at science.ru.nl] *On Behalf Of *Alik Widge >>>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>>> *To:* FieldTrip discussion list >>>>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>>> data analysis >>>>>> >>>>>> >>>>>> >>>>>> In this, Teresa is right and we have observed this in our own EEG >>>>>> data -- depending on one's level of noise and number of trials/patients, >>>>>> the mean can be a very poor estimator of central tendency. My students are >>>>>> still arguing about what we really want to do with it, but at least one of >>>>>> them has shifted to using the median as a matter of course for baseline >>>>>> normalization. >>>>>> >>>>>> >>>>>> Alik Widge >>>>>> alik.widge at gmail.com >>>>>> (206) 866-5435 >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> That may very well be true; to be honest, I haven't looked that >>>>>> deeply into the stats offerings yet. However, my plan is to express each >>>>>> electrode's experimental data in terms of change from their respective >>>>>> baseline recordings before attempting any group averaging or statistical >>>>>> testing, and this problem shows up first in the baseline correction step, >>>>>> where FieldTrip averages raw power over time. >>>>>> >>>>>> ~Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com> wrote: >>>>>> >>>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>>> statistics implemented by fieldtrip, the data does not need to be normally >>>>>> distributed. >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 13:39, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>>>> across frequencies, but the distribution across time (and according to the >>>>>> poster, also across space), also has an extremely skewed, negative >>>>>> exponential distribution. I probably confused everyone by trying to show >>>>>> too much data in my figure, but each color represents the distribution of >>>>>> power values for a single frequency over time, using a histogram and a line >>>>>> above with circles at the mean +/- one standard deviation. >>>>>> >>>>>> My main point was that the mean is not representative of the central >>>>>> tendency of such an asymmetrical distribution of power values over time. >>>>>> It's even more obvious which is more representative of their actual >>>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>>>> busy and confusing. >>>>>> >>>>>> I hope that helps, >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com> wrote: >>>>>> >>>>>> Hi Teresa, >>>>>> >>>>>> >>>>>> >>>>>> I think what you are discussing is the 1/f power scaling of the power >>>>>> spectrum. This is one of the reasons that comparisons are made within >>>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>>>> as such the assumption is that within bands there should be a relative >>>>>> change against baseline and this is what the statistics are performed on. >>>>>> That is, baseline correction is assumed to be the mean for a specific >>>>>> frequency and not a mean across frequencies. >>>>>> >>>>>> >>>>>> >>>>>> And this leads to another point that when you are selecting a >>>>>> frequency range to do the non-parametric statistics on you should not do >>>>>> 1-64 Hz but break it up based on the bands. >>>>>> >>>>>> >>>>>> >>>>>> Hope my interpretation of your point is correct. I sent in >>>>>> individually, as I wanted to ensure I followed your point. >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 08:23, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> FieldTrippers, >>>>>> >>>>>> >>>>>> >>>>>> While analyzing my data for the annual Society for Neuroscience >>>>>> meeting, I developed a concern that was quickly validated by another poster >>>>>> (full abstract copied and linked below) focusing on the root of the >>>>>> problem: neural oscillatory power is not normally distributed across time, >>>>>> frequency, or space. The specific problem I had encountered was in >>>>>> baseline-correcting my experimental data, where, regardless of >>>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>>> However, I found that the distribution of raw power over time is so skewed >>>>>> that the mean was not a reasonable approximation of the central tendency of >>>>>> the baseline power, so it made most of my experimental data look like it >>>>>> had decreased power compared to baseline. The more I think about it, the >>>>>> more I realize that averaging is everywhere in the way we analyze neural >>>>>> oscillations (across time points, frequency bins, electrodes, trials, >>>>>> subjects, etc.), and many of the standard statistics people use also rely >>>>>> on assumptions of normality. >>>>>> >>>>>> >>>>>> >>>>>> The most obvious solution for me was to log transform the data first, >>>>>> as it appears to be fairly log normal, and I always use log-scale >>>>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>>>> that this would at least "restore (some) symmetry to the error >>>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>>> differentiate from the standard decibel transform included in FieldTrip as >>>>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>>>> across several frequency bands (using power values from a wavelet >>>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>>> cortex). The lines at the top represent the mean +/- one standard >>>>>> deviation for each frequency band, and you can see how those descriptive >>>>>> stats are much more representative of the actual distributions in the log >>>>>> scale. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ​​ >>>>>> >>>>>> For my analysis, I also calculated a z-score on the log transformed >>>>>> power to assess how my experimental data compared to the variability of the >>>>>> noise in a long baseline recording from before conditioning, rather than a >>>>>> short pre-trial baseline period, since I find that more informative than >>>>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>>>> functions I wrote for this if people think it would be a useful addition to >>>>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>>>> poster, if anyone wants more detail - I just didn't want to make this email >>>>>> too big. >>>>>> >>>>>> >>>>>> >>>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>>> address this. I searched the wiki >>>>>> , listserv >>>>>> >>>>>> archives >>>>>> , >>>>>> and bugzilla >>>>>> for >>>>>> anything related and came up with a few topics surrounding normalization >>>>>> and baseline correction, but only skirting this issue. It seems important, >>>>>> so I want to find out whether others agree with my approach or already have >>>>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>>>> be changed or just documentation added, or what? >>>>>> >>>>>> >>>>>> >>>>>> Thanks for any insights, >>>>>> >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>>> across time >>>>>> >>>>>> >>>>>> *Authors* >>>>>> >>>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>>> Cognitive Sci., UCSD, San Diego, CA >>>>>> >>>>>> *Disclosures* >>>>>> >>>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>>> >>>>>> *Abstract* >>>>>> >>>>>> Neural oscillations are important in organizing activity across the >>>>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>>>> to numerous disease states. Oscillations are known to vary by frequency and >>>>>> amplitude across time and between different brain regions; however, this >>>>>> variability has never been well characterized. We examined human and animal >>>>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>>> distribution of power and frequency across time, space and species. We >>>>>> report that between data types, subjects, frequencies, electrodes, and >>>>>> time, an inverse power law, or negative exponential distribution, is >>>>>> present in all recordings. This is contrary to, and not compatible with, >>>>>> the Gaussian noise assumption made in many digital signal processing >>>>>> techniques. The statistical assumptions underlying common algorithms for >>>>>> power spectral estimation, such as Welch's method, are being violated >>>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>>> statistical approaches are warranted. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Teresa E. Madsen, PhD >>>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>>> analysis >>>>>> >>>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>>> Yerkes National Primate Research Center >>>>>> >>>>>> Emory University >>>>>> >>>>>> Rainnie Lab, NSB 5233 >>>>>> 954 Gatewood Rd. NE >>>>>> Atlanta, GA 30329 >>>>>> >>>>>> (770) 296-9119 >>>>>> >>>>>> braingirl at gmail.com >>>>>> >>>>>> https://www.linkedin.com/in/temadsen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Teresa E. Madsen, PhD >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> Emory University >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> (770) 296-9119 >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> >>>> >>>> -- >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Teresa E. Madsen, PhD >> Division of Behavioral Neuroscience and Psychiatric Disorders >> Yerkes National Primate Research Center >> Emory University >> Rainnie Lab, NSB 5233 >> 954 Gatewood Rd. NE >> Atlanta, GA 30329 >> (770) 296-9119 >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Berry van den Berg > email: berryv.dberg at gmail.com > website: berryvdberg.org > mobile: +31612585275 <+31%206%2012585275> > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 30063 bytes Desc: not available URL: From seymourr at aston.ac.uk Sun Jan 29 13:05:23 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Sun, 29 Jan 2017 12:05:23 +0000 Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing Message-ID: Dear FT Users, I am currently writing a function where ft_preprocessing is called iteratively; however computation is being slowed down by the display of text/output in the MATLAB command window (e.g. "the input is raw data with 1 channel and 62 trials"). Apart from hard-coding, I was wondering if there was an option to turn off logging in the FT code? Many thanks, Robert Seymour (PhD Student, Aston Brain Centre) -------------- next part -------------- An HTML attachment was scrubbed... URL: From leventmeister at gmail.com Sun Jan 29 18:25:34 2017 From: leventmeister at gmail.com (Levent Kandemir) Date: Sun, 29 Jan 2017 20:25:34 +0300 Subject: [FieldTrip] Fwd: Partial Source Model In-Reply-To: References: Message-ID: Hello, I calculate coherence from HCP data using http://www. fieldtriptoolbox.org/tutorial/beamformer but I get results as below; [image: Satır içi resim 1] What do you think the problem is? Thanks in advance, Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 133674 bytes Desc: not available URL: From ekenaykut at gmail.com Sun Jan 29 19:10:44 2017 From: ekenaykut at gmail.com (Aykut Eken) Date: Sun, 29 Jan 2017 21:10:44 +0300 Subject: [FieldTrip] Fwd: Partial Source Model In-Reply-To: References: Message-ID: <2AF1E465-2408-41E8-ADAF-05F74D997F1E@gmail.com> You can change the scale of color map or your data may be noisy. > On 29 Jan 2017, at 20:25, Levent Kandemir wrote: > > > Hello, > > I calculate coherence from HCP data using http://www.fieldtriptoolbox.org/tutorial/beamformer but I get results as below; > > > > What do you think the problem is? > > Thanks in advance, > Best regards, > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.urai at gmail.com Mon Jan 30 10:36:09 2017 From: anne.urai at gmail.com (Anne Urai) Date: Mon, 30 Jan 2017 10:36:09 +0100 Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing In-Reply-To: References: Message-ID: Hi Robert, many FieldTrip functions have the (sometimes undocumented) input option cfg.feedback. When set to 'none', output in the command line is suppressed. — Anne E. Urai, MSc PhD student | Institut für Neurophysiologie und Pathophysiologie Universitätsklinikum Hamburg-Eppendorf | Martinistrasse 52, 20246 | Hamburg, Germany www.anneurai.net / @AnneEUrai From: Seymour, Robert (Research Student) Reply: FieldTrip discussion list Date: 29 January 2017 at 13:05:23 To: fieldtrip at science.ru.nl Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing Dear FT Users, I am currently writing a function where ft_preprocessing is called iteratively; however computation is being slowed down by the display of text/output in the MATLAB command window (e.g. "the input is raw data with 1 channel and 62 trials"). Apart from hard-coding, I was wondering if there was an option to turn off logging in the FT code? Many thanks, Robert Seymour (PhD Student, Aston Brain Centre) _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.patai at ucl.ac.uk Mon Jan 30 14:27:22 2017 From: e.patai at ucl.ac.uk (Zita Eva Patai) Date: Mon, 30 Jan 2017 13:27:22 +0000 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data Message-ID: Dear FT-ers, I have an obvious question, but would still appreciate input from those more wise than myself: Can I put any sort of confound in to regress out of my data? For example things relating to -eye-movements (ICA done but I still have obvious condition differences) -experimentally uncontrolled stimulus changes -or any other environmental effects i'd like to control for Thank you zita -- Eva Zita Patai, DPhil Postdoctoral Researcher Institute of Behavioural Neuroscience UCL -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmadsen at emory.edu Mon Jan 30 17:30:30 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Mon, 30 Jan 2017 11:30:30 -0500 Subject: [FieldTrip] extracting spikes from new Message-ID: Suzanne, I think it may be a simple error in the way you formatted the inputs to that command. According to the help comments at the beginning of the function: % Use as % [spike] = ft_read_spike(filename, ...) % % Additional options should be specified in key-value pairs and can be % 'spikeformat' = string, described the fileformat (default is automatic) I don't see any other input arguments being used, so I'm assuming your 1st argument is the filename and guessing your 3rd argument is its location? If so, the correct format would be: >> [rec1] = ft_read_spike('/Users/username/Documents/export/test.nex'); Including the .nex extension in the filename will allow ft_filetype to automatically detect the format as 'plexon_nex', so you don't need to specify a spikeformat, but if that doesn't work for some reason, I believe the correct formatting (what is meant by key-value pairs) would be: >> [rec1] = ft_read_spike('test', 'spikeformat', 'plexon_nex’); If neither of those work, I'd be happy to help you troubleshoot this further, as I also use Plexon for data acquisition, have been working on improving FieldTrip's NEX handling, and will be moving into spike analysis soon. Let me know if that helps. ~Teresa On Wed, Jan 25, 2017 at 4:55 PM, Suzanne van der Veldt < suzannevdveldt at gmail.com> wrote: > Hello all, > > Sorry to trouble you. I am excited to get starting with using FieldTrip > for my data analysis, using in vivo ephys data recorded with plexon. I have > my sorted spikes in .nex format. Unfortunately, field trip does not seem to > be able to import my data. > > >> [rec1] = ft_read_spike('test', 'plexon_nex', '/Users/username/Documents/ > export’) > Error using ft_read_spike (line 276) > unsupported data format (unknown > > The .nex file is a regular file. I am running Matlab R2015b from Mac OSx > Sierra 10.12.2. > > I hope someone might be able to give me a hint of what might be the > problem. > > Kind regards, > Suzanne van der Veldt > > PhD student McGill & Université de Bordeaux > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.stolk8 at gmail.com Mon Jan 30 19:00:44 2017 From: a.stolk8 at gmail.com (Arjen Stolk) Date: Mon, 30 Jan 2017 10:00:44 -0800 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data In-Reply-To: References: Message-ID: Dear Zita, The short answer is yes, as you guessed already. Ideally, the confound is measured independently from the dependent measure, e.g. eye tracker activity to filter against eye movement related confounds in neural activity. But in the past we've also successfully regressed out eye movement related contributions as captured with EOG from frontal (source-reconstructed) neural activity, despite that both signals may have been partially correlated due to field spread. See 'General assessments of neurophysiologic data' & Fig S3 of this pdf: http://www.pnas.org/content/suppl/2013/08/16/1303170110.DCSupplemental/pnas.201303170SI.pdf The same principle that underlies head movement compensation thus also holds for other potential confounds, including the ones mentioned by you. Best, Arjen 2017-01-30 5:27 GMT-08:00 Zita Eva Patai : > Dear FT-ers, > > I have an obvious question, but would still appreciate input from those > more wise than myself: > > Can I put any sort of confound in to regress out of my data? For example > things relating to > > -eye-movements (ICA done but I still have obvious condition differences) > -experimentally uncontrolled stimulus changes > -or any other environmental effects i'd like to control for > > Thank you > zita > > > -- > Eva Zita Patai, DPhil > Postdoctoral Researcher > Institute of Behavioural Neuroscience > UCL > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.patai at ucl.ac.uk Mon Jan 30 21:50:45 2017 From: e.patai at ucl.ac.uk (Zita Eva Patai) Date: Mon, 30 Jan 2017 20:50:45 +0000 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data In-Reply-To: References: Message-ID: That's great thank you Arjen! On Mon, Jan 30, 2017 at 6:00 PM, Arjen Stolk wrote: > Dear Zita, > > The short answer is yes, as you guessed already. Ideally, the confound is > measured independently from the dependent measure, e.g. eye tracker > activity to filter against eye movement related confounds in neural > activity. But in the past we've also successfully regressed out eye > movement related contributions as captured with EOG from frontal > (source-reconstructed) neural activity, despite that both signals may have > been partially correlated due to field spread. See 'General assessments of > neurophysiologic data' & Fig S3 of this pdf: > http://www.pnas.org/content/suppl/2013/08/16/1303170110. > DCSupplemental/pnas.201303170SI.pdf > The same principle that underlies head movement compensation thus also > holds for other potential confounds, including the ones mentioned by you. > > Best, > Arjen > > > > 2017-01-30 5:27 GMT-08:00 Zita Eva Patai : > >> Dear FT-ers, >> >> I have an obvious question, but would still appreciate input from those >> more wise than myself: >> >> Can I put any sort of confound in to regress out of my data? For example >> things relating to >> >> -eye-movements (ICA done but I still have obvious condition differences) >> -experimentally uncontrolled stimulus changes >> -or any other environmental effects i'd like to control for >> >> Thank you >> zita >> >> >> -- >> Eva Zita Patai, DPhil >> Postdoctoral Researcher >> Institute of Behavioural Neuroscience >> UCL >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Eva Zita Patai, DPhil Postdoctoral Researcher Institute of Behavioural Neuroscience UCL -------------- next part -------------- An HTML attachment was scrubbed... URL: From alba.xifraporxas at mail.mcgill.ca Mon Jan 30 22:53:38 2017 From: alba.xifraporxas at mail.mcgill.ca (Alba Xifra Porxas, Ms) Date: Mon, 30 Jan 2017 21:53:38 +0000 Subject: [FieldTrip] Error reading fif file during ft_read_headshape Message-ID: Dear FieldTrippers, My name is Alba Xifra Porxas and I am working in the Biosignals and Systems Analysis Lab at McGill University. Currently I am analyzing MEG data from a motor-task paradigm from young and elderly subjects. I am following the tutorial: Source reconstruction of event-related fields using minimum-norm estimate (http://fieldtrip.fcdonders.nl/tutorial/minimumnormestimate). I am having problems reading the downsampled mesh from MNE suite. When I call FT_READ_HEADSHAPE, I receive the following error message: >> sourcespace = ft_read_headshape('s003-oct-6-src.fif', 'format', 'mne_source'); Error using fiff_read_tag (line 178) Only two and three dimensional matrices are supported at this time Error in mne_read_source_spaces/read_source_space/find_tag (line 288) tag = fiff_read_tag(fid,node.dir(p).pos); Error in mne_read_source_spaces/read_source_space (line 254) tag2 = find_tag(this,FIFF.FIFF_MNE_SOURCE_SPACE_NEAREST_DIST); Error in mne_read_source_spaces (line 111) this = read_source_space(spaces(k)); Error in ft_read_headshape (line 391) src = mne_read_source_spaces(filename, 1); However, I can visualize it correctly in MNE. The command I used to create the source space is: mne_setup_source_space --ico -6. Since I have the meshes from FreeSurfer, I tried a workaround. I call FT_READ_HEADSHAPE using lh.orig and rh.orig, which works. I successfully coregister the source space with the sensor-space and compute source reconstruction using minimum-norm estimation. However, when I try to downsample the output of FT_SOURCEANALYSIS calling FT_VOLUMEDOWNSAMPLE before parcellation, I receive the following error: Reference to non-existent field 'dim'. Error in ft_volumedownsample (line 100) xsel = 1:cfg.downsample:source.dim(1); Even if I manually introduce this missing field 'dim', it seems the number of vertices is too big: >> source.dim(1) = length(source.pos);source.dim(2) = length(source.pos);source.dim(3) = length(source.pos); >> cfg = [];cfg.downsample = 4;source_down = ft_volumedownsample(cfg,source); Error using repmat Maximum variable size allowed by the program is exceeded. Error in ndgrid (line 73) varargout{i} = repmat(x,s); Error in pos2transform (line 25) [X,Y,Z] = ndgrid(x, y, z); Error in ft_checkdata>source2volume (line 1286) data.transform = pos2transform(data.pos, data.dim); Error in ft_checkdata (line 350) data = source2volume(data); Error in ft_volumedownsample (line 69) source = ft_checkdata(source, 'datatype', 'volume', 'feedback', 'no'); The source I use is as follows: >> display(source) source = time: [1x3900 double] inside: [255462x1 logical] pos: [255462x3 double] method: 'average' avg: [1x1 struct] cfg: [1x1 struct] dim: [255462 255462 255462] Therefore, I am back to where I started. I need to read the fif file from MNE suite. I uploaded my fif file in Dropbox. Here is the link: https://www.dropbox.com/sh/uq181l76353hd8q/AACjTu8KI_rGaXlaDMyw-Diba?dl=0 Could someone tell me if there is something wrong with the file or with my workaround? Any help would be really appreciated. I am using Fieldtrip version 20170118. Best, Alba Xifra Porxas PhD student, Biosignals and Systems Analysis Lab McGill University, Montréal, Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From timeehan at gmail.com Mon Jan 30 23:10:40 2017 From: timeehan at gmail.com (Tim Meehan) Date: Mon, 30 Jan 2017 17:10:40 -0500 Subject: [FieldTrip] preprocessing procedures for ECoG/iEEG data Message-ID: Hello all, I am a new user of fieldtrip and new to analyzing electrophysiological data. I have familiarized myself with some basics of preprocessing of EEG data, but I would like to know if there are special considerations for dealing with ECoG/iEEG data -- our dataset has recordings from both subdural surface electrodes and depth electrodes, sampled at 2kHz. We are initially most interested in extracting the high-gamma band (70-150 Hz) envelope as a measure of local activity. First a general question: is there anyone who could point me to or provide me with a preprocessing procedure in fieldtrip that is tailored for ECoG/iEEG? I've perused the ECoG section in the wiki but there is no information on preprocessing there. If this is too vague, some specific questions I have are: 1) What cutoffs do people tend to use for low and high-pass filters? 2) What is your choice for re-referencing, if any? Our initial reference/ground are the left and right mastoids. I have seen papers that re-reference to the nearest neighbor. I think I need to use ft_apply_montage to do this, but beyond that I could use some guidance. 3) At what point do you epoch into trials? My guess is after high/low-pass filtering and re-referencing but before artifact detection and removal? Any feedback on these would be very much appreciated. If you need more details please let me know. Thanks! Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielle.farrar at gmail.com Tue Jan 31 17:40:14 2017 From: danielle.farrar at gmail.com (Danielle Farrar) Date: Tue, 31 Jan 2017 11:40:14 -0500 Subject: [FieldTrip] Starting at ft_timelockstatistics Message-ID: Hello, My apologies if this has been covered before, I just joined the list and am having trouble searching the archives. I have a set of EEG data that was recorded from a Biosemi apparatus using a 128-channel cap. The dataset is in text files, is post-processed and is the result of filtering, epoching, and averaging, and has been imported into matlab. I created trial structs out of the datasets. It is a dataset of 21 subjects with two conditions. I'm trying to do some non-parametric clustering statistics on the dataset and I don't have access to the original bdf files. I have the electrode names and coordinates saved in matlab matrices. Now, I'd like to do clustering analysis using a monte carlo simulation to determine areas of significant differences between the two conditions, but am having trouble ensuring that my datasets are structured appropriately for input. It seems that the tutorials mostly assume that the data is in a raw output format from one of the systems. I know that for ft_timelockstatistics, the data is supposed to be output from the ft_timelockanalysis. I was trying to use ft_timelockanalysis as an entry point However, I am having trouble constructing the data struct appropriate for the timelock function. Can this be done? Should I be starting further upstream? I'm attaching some of the code. I'm know the data struct needs additional information but am not sure how to go about using it. The error I get when I run the following code is "Error using ft_checkdata (line 480). This function requires raw+comp or raw data as input." Thanks! Danielle ******************************** for i=size(CD_condition.data,3), CD_trial{i} = CD_condition.data(:,:,i); end CD.trial = CD_trial; cfg.channel = 'all'; cfg.trials = 'all'; cfg.covariance = 'yes'; cfg.covariancewindow = 'prestim'; cfg.removemean = 'yes'; cfg.vartrllength = 0; CD.type = 'raw+comp'; ft_timelockanalysis(cfg,CD); -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 12:41:56 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 11:41:56 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* From jan.schoffelen at donders.ru.nl Mon Jan 2 12:50:28 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Mon, 2 Jan 2017 11:50:28 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> Message-ID: Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From mehmetakifozcoban at gmail.com Mon Jan 2 13:05:52 2017 From: mehmetakifozcoban at gmail.com (=?UTF-8?B?TWVobWV0IEFraWYgw5Z6w6dvYmFu?=) Date: Mon, 2 Jan 2017 15:05:52 +0300 Subject: [FieldTrip] Whole band EEG Message-ID: ​Dear filedtripper and professors; How can İ intepret the phase scores in whole (full-0.5-50Hz) EEG band... Please can you help me with tutorial or paper about significant of whole EEG band​ -- Mehmet Akif ÖZÇOBAN Cd.PhD. Istanbul University -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 13:20:07 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 12:20:07 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de>, Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From michelic72 at gmail.com Mon Jan 2 13:43:57 2017 From: michelic72 at gmail.com (Cristiano Micheli) Date: Mon, 2 Jan 2017 13:43:57 +0100 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> Message-ID: Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: *Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)};* might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option *dbstop if error *(toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus wrote: > Dear Jan-Mathijs, > > thank you for you fast reply. But unfortunately, removing the fields does > not change the error message et all. > > Best, > Markus > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > > ________________________________________ > Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" > im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [ > jan.schoffelen at donders.ru.nl] > Gesendet: Montag, 2. Januar 2017 12:50 > An: FieldTrip discussion list > Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source > input data > > Markus, > > Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again > please? > Thanks, > BW, > JM > > > J.M.Schoffelen > Senior Researcher, VIDI-fellow > Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > > > > > > > > On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: > > > > > > Dear Fieldtrippers, > > > > > > happy new year to everyone here! > > > > This is the second attempt to get help on an issue with > ft_sourcestatistics. As I still can not figure out where the problem > resides, I give it a new try. > > > > My goal is to use a common DICS filter to reconstruct single-trial data > in three conditions. Afterwards, I want to run a test for a linear effect > across the conditions. I thought to follow closely the descriptions in > http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , > especially in the way I extract the single-trial data. However, when I run > ft_sourcestatistics, the single trial source data is not recognized as > source data ... > > > > Any ideas on what went wrong? > > > > Below is the code and error-messages: > > > > > > > > When I run the code below: > > > > %----------------------------------------------------------- > ----------------------------------------------- > > src_descrcfg = []; > > src_descrcfg.keeptrials = 'yes'; > > src00 = ft_sourcedescriptives(src_descrcfg,src00); > > src01 = ft_sourcedescriptives(src_descrcfg,src01); > > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > > > > src_statscfg = []; > > src_statscfg.parameter = 'trial.pow'; > > src_statscfg.method = 'analytic'; > > src_statscfg.statistic = 'indepsamplesregrT'; > > src_statscfg.alpha = 0.05; > > src_statscfg.correctm = 'no'; > > > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) > 3*ones(1,src11.df)]; > > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the > independent variable > > > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > > %----------------------------------------------------------- > ----------------------------------------------- > > > > I get the following output and error message: > > > > original data contained 201 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 48 MB > > original data contained 113 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 0 MB > > original data contained 46 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 0 MB > > Index exceeds matrix dimensions. > > > > Error in ft_datatype_source (line 187) > > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > > > Error in ft_checkdata (line 251) > > data = ft_datatype_source(data); > > > > Error in ft_sourcestatistics (line 100) > > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', > 'feedback', 'no'); > > > > > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with > the following content: > > > > > > src00 = > > > > freq: 9.7656 > > cumtapcnt: [201x1 double] > > dim: [27 36 30] > > inside: [29160x1 logical] > > pos: [29160x3 double] > > method: 'rawtrial' > > trial: [1x201 struct] > > df: 201 > > cfg: [1x1 struct] > > sampleinfo: [201x2 double] > > rating: [201x2 double] > > stim: {201x3 cell} > > > > > > The source-solutions were based on a common dics-filter after running > the following code: > > > > %----------------------------------------------------------- > ----------------------------------------------- > > % compute single trial spectra > > mtmfftcfg.keeptrials = 'yes'; > > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > > > % project all trials through common spatial filter % > > dics_alltrl_cfg = []; > > dics_alltrl_cfg = dics_commoncfg; > > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common > filter computed in the previous step! > > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial > through the filter. Only necessary if you are interested in reconstructing > single trial data > > > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % > contains the source estimates for all trials/both > > %----------------------------------------------------------- > ----------------------------------------------- > > > > > > Any ideas, why the data is not recognized as source-data when calling > ft_sourcestatistics (obviously it is recognized correctly with > ft_sourcedescriptives ...). > > > > > > Thank you very much for your help. > > > > Best regards, > > Markus > > > > > > > > ********************************************************************* > > Dr. Markus Werkle-Bergner, Dipl. Psych. > > Senior Research Scientist (W2) > > > > Jacobs Foundation Research Fellow 2017-2019 > > > > Max Planck Institute for Human Development > > Center for Lifespan Psychology > > > > Lentzeallee 94, 14195 Berlin > > > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > > Mail: werkle at mpib-berlin.mpg.de > > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > > ********************************************************************* > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 14:03:23 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 13:03:23 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de>, Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: >> src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] >> src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Mon Jan 2 14:17:35 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Mon, 2 Jan 2017 13:17:35 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> Message-ID: <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> Markus, Can you switch off the ‘keepfilter’ option before you do the ‘rawtrial’ business? The error context suggests that MATLAB tries to allocate data to a cell-array, which is probably the spatial filter (or possibly the label). Since this information is not needed for the statistical inference, you can discard it. Best, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 14:03, Werkle, Markus > wrote: Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 15:09:07 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 14:09:07 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de>, <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F631@MaxMail04.mpib-berlin.mpg.de> Dear Jan-Mathijs, yes, that did the trick! Setting cfg.dics.keepfilter = 'no' before passing the single trials through the common filter helped. Thank you and Cristiano for your quick and efficient support! Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 14:17 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you switch off the ‘keepfilter’ option before you do the ‘rawtrial’ business? The error context suggests that MATLAB tries to allocate data to a cell-array, which is probably the spatial filter (or possibly the label). Since this information is not needed for the statistical inference, you can discard it. Best, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 14:03, Werkle, Markus > wrote: Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From suhasg10495 at gmail.com Tue Jan 3 13:02:11 2017 From: suhasg10495 at gmail.com (Suhas G) Date: Tue, 3 Jan 2017 17:32:11 +0530 Subject: [FieldTrip] Request for help in debugging error in compilation of biosemi2ft.cc Message-ID: Hi, We are working on a BCI project, where we want to acquire data in real-time from Biosemi. We are using 128 channel Biosemi Active Two device. We are trying to incorporate fieldtrip real time buffer for our real time data acquisition. For the implementation we are following the steps provided on the fieldtrip website. We are getting certain errors during this implementation for which we request your guidance. Ubuntu: We are using Ubuntu 14.04 64 bit. The gcc compiler version used is 4.8.5. We are using Matlab 2015 1. The matlab outside part of buffer is compiled successfully using 'make' on command prompt in the directory src/buffer/src/. 2. The matlab inside part of buffer compilation, i.e creation of mex file was successful on matlab using 'compile' in src/buffer/matlab directory. These warning was displayed, but the mex completed successfully. *Warning: You are using gcc version '4.8.5-2ubuntu1~14.04.1)'. The version of gcc is not supported. Theversion currently supported with MEX is '4.7.x'. For a list of currently supported compilers see:http://www.mathworks.com/support/compilers/current_release . * 3. For compiling the biosemi2ft tool, this is the error which we get *eeg-egi at eeg-egi:~/Desktop/fieldtrip-20161228/realtime/src/acquisition/biosemi$ makeg++ -o ../../../../realtime/bin/glnxa64/biosemi2ft biosemi2ft.o BioSemiClient.o -L../../../../realtime/src/buffer/src -L../../../../realtime/src/buffer/src -lbuffer ../../../../realtime/src/buffer/cpp/SignalConfiguration.o ../../../../realtime/src/buffer/cpp/GdfWriter.o ../../../../realtime/src/buffer/cpp/FtConnection.o ../../../../realtime/src/buffer/cpp/StringServer.o -lbuffer -lpthread -ldl -lrtg++: error: ../../../../realtime/src/buffer/cpp/SignalConfiguration.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/GdfWriter.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/FtConnection.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/StringServer.o: No such file or directorymake: *** [../../../../realtime/bin/glnxa64/biosemi2ft] Error 1* The compilers which are installed are g++, g++-4.8, g++-4.8-multilib, g++-multilib, gcc, gcc-4.8, gcc-4.8-multilib, gcc-multilib, libllvm3.6:amd64 Please help us debug the same. Thank you. Suhas G -------------- next part -------------- An HTML attachment was scrubbed... URL: From suhasg10495 at gmail.com Tue Jan 3 13:02:13 2017 From: suhasg10495 at gmail.com (Suhas G) Date: Tue, 3 Jan 2017 17:32:13 +0530 Subject: [FieldTrip] Request for help in debugging real-time buffer compilation error Message-ID: Hi, We are using 128 channel Biosemi Active Two device. We are working on a BCI project, where we want to acquire data in real-time from Biosemi. We are trying to incorporate fieldtrip real time buffer for our real time data acquisition. For the implementation we are following the steps provided on the fieldtrip website. We are getting certain errors during this implementation for which we request your guidance. Windows: We are using Windows 7, 64 bit system. Installed Softwares: Microsoft Visual C++ 2005, 2008, 2010, 2012 and 2013 Microsoft Windows SDK 7.1 MinGW compiler and MSYS Cygwin 1. The matlab inside part of buffer compilation, i.e creation of mex file on matlab using 'compile' in src/buffer/matlab directory, gave the following error. We tried it using Visual Studio and minGW compilers. *>> mex -setup * *MEX configured to use 'Microsoft Windows SDK 7.1 (C)' for C language compilation.* *Warning: The MATLAB C and Fortran API has changed to support MATLAB* * variables with more than 2^32-1 elements. In the near future* * you will be required to update your code to utilize the* * new API. You can find more information about this at:* * http://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html .* *To choose a different language, select one from the following:* * mex -setup C++ * * mex -setup FORTRAN* *>> compile('vc')* *Compiling library functions in util.c ...* *Building with 'Microsoft Windows SDK 7.1 (C)'.* *Error using mex* *util.c* *C:\Program* *Files\MATLAB\R2016a\toolbox\fieldtrip-20170102\fieldtrip-20170102\realtime\src\buffer\src\util.c(13) : fatal* *error C1083: Cannot open include file: 'sys/time.h': No such file or directory* *Error in compile (line 156)* * eval(cmd);* *>> compile('mingw','C:/MinGW/lib')* *Compiling library functions in util.c ...* *Building with 'Microsoft Windows SDK 7.1 (C)'.* *Error using mex* *util.c* *C:\Program* *Files\MATLAB\R2016a\toolbox\fieldtrip-20170102\fieldtrip-20170102\realtime\src\buffer\src\util.c(13) : fatal* *error C1083: Cannot open include file: 'sys/time.h': No such file or directory* *Error in compile (line 156)* * eval(cmd);* 2. The matlab outside part compilation of buffer in src/buffer/src directory was attempted using make in cygwin terminal. We got the following error: EEG-EGI at EEG-EGI-PC /cygdrive/c/Program Files/MATLAB/R2016a/toolbox/fieldtrip-201 70102/fieldtrip-20170102/realtime/src/buffer/src $ make gcc -I. -Wunused -Wall -pedantic -O0 -fPIC -g -c -o tcpserver.o tcpserver.c tcpserver.c:1:0: warning: -fPIC ignored for target (all code is position indepen dent) /* ^ tcpserver.c: In function ‘cleanup_tcpserver’: tcpserver.c:31:5: warning: implicit declaration of function ‘closesocket’ [-Wimp licit-function-declaration] closesocket(threadlocal->fd); ^ tcpserver.c: In function ‘tcpserver’: tcpserver.c:51:22: error: storage size of ‘sa’ isn’t known struct sockaddr_in sa; ^ tcpserver.c:102:12: warning: implicit declaration of function ‘socket’ [-Wimplic it-function-declaration] if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:102:19: error: ‘PF_INET’ undeclared (first use in this function) if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:102:19: note: each undeclared identifier is reported only once for e ach function it appears in tcpserver.c:102:28: error: ‘SOCK_STREAM’ undeclared (first use in this function) if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:136:7: warning: implicit declaration of function ‘setsockopt’ [-Wimp licit-function-declaration] if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:136:21: error: ‘SOL_SOCKET’ undeclared (first use in this function) if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:136:33: error: ‘SO_REUSEADDR’ undeclared (first use in this function ) if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:142:19: error: ‘AF_INET’ undeclared (first use in this function) sa.sin_family = AF_INET; ^ tcpserver.c:143:19: warning: implicit declaration of function ‘htons’ [-Wimplici t-function-declaration] sa.sin_port = htons(host->port); ^ tcpserver.c:145:7: error: ‘INADDR_ANY’ undeclared (first use in this function) if (INADDR_ANY) ^ tcpserver.c:146:26: warning: implicit declaration of function ‘htonl’ [-Wimplici t-function-declaration] sa.sin_addr.s_addr = htonl(INADDR_ANY); ^ tcpserver.c:148:7: warning: implicit declaration of function ‘bind’ [-Wimplicit- function-declaration] if (bind(s, (struct sockaddr *)&sa, sizeof sa) < 0) { ^ tcpserver.c:153:7: warning: implicit declaration of function ‘listen’ [-Wimplici t-function-declaration] if (listen(s, BACKLOG)<0) { ^ tcpserver.c:168:9: warning: implicit declaration of function ‘accept’ [-Wimplici t-function-declaration] c = accept(s, (struct sockaddr *)&sa, &b); ^ tcpserver.c:186:9: warning: implicit declaration of function ‘usleep’ [-Wimplici t-function-declaration] usleep(ACCEPTSLEEP); ^ tcpserver.c:202:23: error: storage size of ‘lg’ isn’t known struct linger lg; ^ tcpserver.c:207:35: error: ‘SO_LINGER’ undeclared (first use in this function) setsockopt(s, SOL_SOCKET, SO_LINGER, (char *) &lg, sizeof(lg)); ^ tcpserver.c:202:23: warning: unused variable ‘lg’ [-Wunused-variable] struct linger lg; ^ tcpserver.c:213:37: error: ‘SO_RCVBUF’ undeclared (first use in this function) if (setsockopt(c, SOL_SOCKET, SO_RCVBUF, (const char*)&optval, sizeof(opt val)) < 0) { ^ tcpserver.c:220:37: error: ‘SO_SNDBUF’ undeclared (first use in this function) if (setsockopt(c, SOL_SOCKET, SO_SNDBUF, (const char*)&optval, sizeof(opt val)) < 0) { ^ tcpserver.c:249:50: warning: cast to pointer from integer of different size [-Wi nt-to-pointer-cast] rc = pthread_create(&tid, NULL, tcpsocket, (void *)c); ^ tcpserver.c:267:10: warning: zero-length gnu_printf format string [-Wformat-zero -length] printf(""); ^ tcpserver.c:267:10: warning: zero-length gnu_printf format string [-Wformat-zero -length] tcpserver.c:56:23: warning: unused variable ‘oldcanceltype’ [-Wunused-variable] int oldcancelstate, oldcanceltype; ^ tcpserver.c:56:7: warning: unused variable ‘oldcancelstate’ [-Wunused-variable] int oldcancelstate, oldcanceltype; ^ tcpserver.c:51:22: warning: unused variable ‘sa’ [-Wunused-variable] struct sockaddr_in sa; ^ make: *** [: tcpserver.o] Error 1 Please help us debug the same. Thank you. Suhas G -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Wed Jan 4 10:56:31 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Wed, 4 Jan 2017 10:56:31 +0100 Subject: [FieldTrip] Getting "nan" from ft_read_cifti Message-ID: <2B64515C-C06C-4BFB-B61F-4C981076523C@estudiant.upf.edu> Dear all, I am new to this subject, so I apologize if this is a very simple error. I have downloaded parcellated fMRI time series from HCP and when I apply the function: >> TC = ft_read_cifti('100206.dtseries.nii’); Then the TC.dtseries has 200 columns (parcels) and 96854 rows, which I understand they are the values for each timestep. The problem is that quite a lot of these rows are purely “NaN” values. Does anybody experienced the same problem? What I am missing? Thank you in advanced! Joan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.klinzing at uni-tuebingen.de Wed Jan 4 16:47:12 2017 From: jens.klinzing at uni-tuebingen.de (=?UTF-8?B?IkplbnMgS2xpbnppbmcsIFVuaXZlcnNpdMOkdCBUw7xiaW5nZW4i?=) Date: Wed, 04 Jan 2017 16:47:12 +0100 Subject: [FieldTrip] Keeptrials using "pcc" for source analysis In-Reply-To: References: Message-ID: <586D1900.3080804@uni-tuebingen.de> Hi Xie, are you sure your output does not contain trial data? If you look in source.avg.mom you should see a cell array containing for each inside source point another cell array with as many entries as there are trials (I know it is confusing because you expect .avg to contain averages, but it may not). The field .csd (cross-spectral density) should contain only one (complex-valued) entry per source point since it is averaged across trials (or calculated on the average over all trials, not sure right now). By the way: In case you get errors in downstream functions with your current output (e.g. when using ft_sourcegrandaverage) check the bugzilla on PCC output containing the spatial filter (e.g. http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2861 or 3184). If you don't really need the filter you can use cfg.keepfilter = 'no' on ft_sourceanalysis or remove the filter and filterdimord fields when calling functions that would otherwise fail. Best, Jens > Xie Wanze > Samstag, 31. Dezember 2016 15:09 > Dear Fieldtrip community, > I have a question about using the "keeptrials" option when do the > source analysis with the beamformer ('PCC') method. The issue I met > was that the cfg.keeptrials = 'yes' did not work, i.e., the > calculation was not done for all the trials but generated averaged > output. > Has anyone met this issue before? And does anyone know how to fix it? > It did not work for my data nor for the data I downloaded from the FT > database. I attached the codes that I copied from the FT website using > the FT's example data. > I would like to keep the trials information in the source analysis > because I plan to do the source space connectivity analysis later, > which needs the individual trials information. Or maybe the > "crsspctrm" matrix. > > Codes: > > cfg = []; > > cfg.frequency = freq.freq; > > cfg.method = 'pcc'; > > cfg.grid = lf; > > cfg.headmodel = hdm; > > cfg.keeptrials = 'yes'; > > cfg.pcc.lambda = '10%'; > > cfg.pcc.projectnoise = 'yes'; > > cfg.pcc.keepfilter = 'yes'; > > cfg.pcc.fixedori = 'yes'; > > source = ft_sourceanalysis(cfg, freq); > > > Output ("source"): > > freq: 10 > > cumtapcnt: [268x1 double] > > tri: [16000x3 double] > > inside: [8004x1 logical] > > pos: [8004x3 double] > > method: 'average' > > avg: [1x1 struct] > > cfg: [1x1 struct] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiew1202 at gmail.com Thu Jan 5 02:06:20 2017 From: xiew1202 at gmail.com (Xie Wanze) Date: Thu, 5 Jan 2017 09:06:20 +0800 Subject: [FieldTrip] Keeptrials using "pcc" for source analysis In-Reply-To: <586D1900.3080804@uni-tuebingen.de> References: <586D1900.3080804@uni-tuebingen.de> Message-ID: Hi Jens, Thank you for your response. I figured out where the problem resided. It seems to me that the 'PCC' temporarily does not work with the option "rawtrial = 'yes'". So, the output from using "keeptrials = 'yes'" does not contain the pow and mom information for individual trials. However, this information can be reconstructed for each trial using the ft_sourcedescriptive function with "keeptrials = 'yes' ". For source analysis of time series (e.g., lcmv and eloreta), individual trial information can be obtained by setting "keeptrials = 'yes' and rawtrial = 'yes' ". No need for the ft_sourcedescriptive function. I don't know if this was only my case or someone else also had come across the same situation. 2017-01-04 10:47 GMT-05:00 "Jens Klinzing, Universität Tübingen" < jens.klinzing at uni-tuebingen.de>: > Hi Xie, > are you sure your output does not contain trial data? > > If you look in source.avg.mom you should see a cell array containing for > each inside source point another cell array with as many entries as there > are trials (I know it is confusing because you expect .avg to contain > averages, but it may not). The field .csd (cross-spectral density) should > contain only one (complex-valued) entry per source point since it is > averaged across trials (or calculated on the average over all trials, not > sure right now). > > By the way: In case you get errors in downstream functions with your > current output (e.g. when using ft_sourcegrandaverage) check the bugzilla > on PCC output containing the spatial filter (e.g. http://bugzilla. > fieldtriptoolbox.org/show_bug.cgi?id=2861 or 3184). > If you don't really need the filter you can use cfg.keepfilter = 'no' on > ft_sourceanalysis or remove the filter and filterdimord fields when calling > functions that would otherwise fail. > > Best, > Jens > > Xie Wanze > Samstag, 31. Dezember 2016 15:09 > Dear Fieldtrip community, > I have a question about using the "keeptrials" option when do the source > analysis with the beamformer ('PCC') method. The issue I met was that the > cfg.keeptrials = 'yes' did not work, i.e., the calculation was not done for > all the trials but generated averaged output. > Has anyone met this issue before? And does anyone know how to fix it? > It did not work for my data nor for the data I downloaded from the FT > database. I attached the codes that I copied from the FT website using the > FT's example data. > I would like to keep the trials information in the source analysis > because I plan to do the source space connectivity analysis later, which > needs the individual trials information. Or maybe the "crsspctrm" matrix. > > Codes: > > cfg = []; > > cfg.frequency = freq.freq; > > cfg.method = 'pcc'; > > cfg.grid = lf; > > cfg.headmodel = hdm; > > cfg.keeptrials = 'yes'; > > cfg.pcc.lambda = '10%'; > > cfg.pcc.projectnoise = 'yes'; > > cfg.pcc.keepfilter = 'yes'; > > cfg.pcc.fixedori = 'yes'; > > source = ft_sourceanalysis(cfg, freq); > > > Output ("source"): > > freq: 10 > > cumtapcnt: [268x1 double] > > tri: [16000x3 double] > > inside: [8004x1 logical] > > pos: [8004x3 double] > > method: 'average' > > avg: [1x1 struct] > > cfg: [1x1 struct] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Jan 5 22:15:59 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 5 Jan 2017 21:15:59 +0000 Subject: [FieldTrip] Fwd: Time-frequency analysis: cfg.foi/T meaning References: Message-ID: <90BC228E-9B2F-4A4E-9F7B-3DAA3F93D120@donders.ru.nl> Begin forwarded message: From: Michał Komorowski > Subject: Time-frequency analysis: cfg.foi/T meaning Date: 5 January 2017 at 19:00:29 GMT+1 To: > Hello, http://www.fieldtriptoolbox.org/faq/why_does_my_output.freq_not_match_my_cfg.foi_when_using_mtmconvol_in_ft_freqanalyis I am trying to fit my time windows/simulated data frequencies in time-frequency analysis to make Fieldtrip not correcting my cfg.foi. In other words I want my output frequencies to be EXACTLY the same as cfg.foi. In the mentioned page a following criterion for time-frequency analysis was proposed: "Is the length of my data such, that the frequency resolution 1/T can capture all cfg.foi? This means, in other words, that cfg.foi/T should be integer numbers." I am not sure If the number cfg.foi/T makes sense, because the units of that ratio is [1/s*s = Hz*Hz]. Please correct me if I am wrong. I also tried many other ways of tweaking my parameters, but with no result. All in all, at that moment, from my perspective it looks like Fieldtrip will always correct my cfg.foi and I must not expect that my output frequencies will match with cfg.foi,. I am also almost equally sure that this is not true. I would be very happy if you can help me. Kind regards, Michał Komorowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From krugliakova.es at gmail.com Mon Jan 9 12:48:20 2017 From: krugliakova.es at gmail.com (Elena Krugliakova) Date: Mon, 9 Jan 2017 11:48:20 +0000 Subject: [FieldTrip] EEG source reconstruction using DICS method Message-ID: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> Dear Fieldtrip community, I have a question regarding source reconstruction using the 'dics' method applied to EEG data. I have two problems: first, even with 32GB of RAM it takes 9 hours to call one ft_sourceanalysis. Maybe, there is a way to optimise the procedure somehow? Second, at the end of analysis I obtain a very strange figure, on which I see activity localised outside the mri scan. Mistake on which step of analysis might cause this problem? As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer Please, find my script below. Thank you in advance! Kind Regards, Elena Script: % freqanalysis cfg = []; cfg.toilim = [-0.5 -0.1]; % prestimulus Pre = ft_redefinetrial(cfg, MyData); cfg = []; cfg.toilim = [0.9 1.3]; % poststimulus Post = ft_redefinetrial(cfg, MyData); cfg = []; dataAll = ft_appenddata([], Pre, Post); cfg = []; cfg.method = 'mtmfft'; cfg.output = 'powandcsd' cfg.keeptrials = 'no'; cfg.taper = 'dpss'; cfg.foi = 35; cfg.tapsmofrq = 4; freq_Pre = ft_freqanalysis(cfg, Pre); freq_Post = ft_freqanalysis(cfg, Post); freq_PrePost = ft_freqanalysis(cfg, dataAll); %% headmodel preparation --- with standard brain mri = ft_read_mri('Subject01.mri'); cfg = []; cfg.dim = mri.dim; mri = ft_volumereslice(cfg,mri); cfg = []; cfg.output = {'gray','white','csf','skull','scalp'} segmentedmri = ft_volumesegment(cfg, mri); cfg = []; cfg.shift = 0.3; cfg.method = 'hexahedral'; cfg.tissue = {'gray','white','csf','skull','scalp'} cfg.numvertices = [800, 800, 800, 400, 200]; cfg.unit = segmentedmri.unit bndFEM = ft_prepare_mesh(cfg,segmentedmri); cfg = []; cfg.method ='simbio'; cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); %% loading aligned electrodes load elec_aligned % 109 EEG electrodes %% leadfield preparation cfg = []; cfg.elec = elec_aligned; cfg.vol = vol_simbio_lowresol; cfg.channel = 'all'; cfg.reducerank = 3; % 3 for eeg cfg.grid.unit = 'mm'; cfg.grid.resolution = 10; leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); %% sourceanalysis cfg = []; cfg.frequency = 35; cfg.vol = vol_simbio_lowresol; cfg.grid = leadfield_FEM_lowresol cfg.projectnoise = 'yes'; cfg.method = 'dics'; cfg.dics.projectnoise = 'yes'; cfg.dics.lambda = '5%'; cfg.dics.keepfilter = 'yes'; cfg.dics.realfilter = 'yes'; sourceAll = ft_sourceanalysis(cfg, freq_PrePost); cfg.grid.filter = sourceAll.avg.filter; sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); sourcePost_con = ft_sourceanalysis(cfg, freq_Post); sourceDiff = sourcePost_con; sourceDiff.avg.pow = (sourcePost_con.avg.pow - sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; %% sourceplot cfg = []; cfg.downsample = 2; cfg.parameter = 'pow'; sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); cfg = []; sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); cfg = []; cfg.method = 'glassbrain'; cfg.funparameter = 'pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceDiffIntNorm); -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.chait at ucl.ac.uk Mon Jan 9 14:07:25 2017 From: m.chait at ucl.ac.uk (Chait, Maria) Date: Mon, 9 Jan 2017 13:07:25 +0000 Subject: [FieldTrip] Post-Doc position at UCL Ear Institute Message-ID: (please forward) A postdoctoral research associate position is available at the UCL Ear Institute's 'Auditory Cognitive Neuroscience Lab'. The project, titled "How the brain detects patterns in sound sequences", will be supervised by Dr Maria Chait and conducted in collaboration with Dr. Marcus Pearce (Queen Mary University, London) and colleagues at the UCL Wellcome Trust centre for neuroimaging. The post is funded for 34 months in the first instance and involves a combination of behavioural, computational, eye tracking, and functional brain imaging (EEG, MEG, fMRI) experiments in humans. For more information about the post please see the lab website: http://www.ucl.ac.uk/ear/research/chaitlab/vacancies The Ear Institute is a leading interdisciplinary centre for hearing research in Europe, situated within one of the strongest neuroscience communities in the world at University College London Key Requirements The successful applicant will have a PhD in neuroscience or a neuroscience-related discipline and proven ability to conduct high-quality original research and prepare results for publication. Essential skills include excellent time-management and organizational ability; proficiency in computer programming and good interpersonal, oral and written communication skills. Previous experience with functional brain imaging, neural data analysis, psychophysical assessment, and/or auditory science or acoustics would be desirable. Further Details You should apply for this post (Ref #: 1618836) through UCL's online recruitment website, www.ucl.ac.uk/hr/jobs, where you can download a job description and person specifications. Closing Date for applications is: 1 Feb 2017 For an informal discussion please contact Dr. Maria Chait (m.chait at ucl.ac.uk). Maria Chait PhD m.chait at ucl.ac.uk Reader in Auditory Cognitive Neuroscience Lab site: http://www.ucl.ac.uk/ear/research/chaitlab/ UCL Ear Institute 332 Gray's Inn Road London WC1X 8EE -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Mon Jan 9 22:44:18 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Mon, 9 Jan 2017 21:44:18 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Message-ID: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom -------------- next part -------------- An HTML attachment was scrubbed... URL: From son.ta.dinh at tum.de Tue Jan 10 08:20:58 2017 From: son.ta.dinh at tum.de (Ta Dinh, Son) Date: Tue, 10 Jan 2017 07:20:58 +0000 Subject: [FieldTrip] LCMV beamforming, source.avg.pow is not the power? Message-ID: Hi Fieldtrippers, I have been trying to do a source analysis on my (resting-state) data using LCMV beamforming and as part of a sanity check, I wanted to plot the alpha power. Using ft_sourceanalysis I get a source structure containing avg.pow and intuitively I expected this field to contain the averaged power of the time series. Therefore, I band-passed the data on the sensor level before doing the LCMV source reconstruction. Surprisingly however, when I used the resulting LCMV spatial filter to construct virtual channels and calculated the alpha power spectrum of the resulting time series using ft_freqanalysis, the average power between these 2 approaches differed by several orders of magnitude over many voxels. Did I make some conceptual misunderstanding? Are the 2 approaches I used not equivalent? Or does source.avg.pow not contain the average power at all? Any comments would be greatly appreciated! Best regards, Son Son Ta Dinh, M.Sc. PhD student in Human Pain Research Klinikum rechts der Isar Technische Universität München Munich, Germany Phone: +49 89 4140 7664 http://www.painlabmunich.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Tue Jan 10 11:01:28 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Tue, 10 Jan 2017 10:01:28 +0000 Subject: [FieldTrip] Post-Doc Position (2 years) at MPIB Berlin - Personalized Cognitive Neuroscience Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA65091@MaxMail04.mpib-berlin.mpg.de> Dear Colleagues, within the research area "Cognitive and Neural Dynamics of Memory Across the Lifespan", headed by Myriam Sander and myself, at the Max Planck Institute for Human Development, Berlin, we are looking for a post-doc to work in our group. Please check the attached advertisement for additional information. The successful candidate will work on a unique data set with intense micro-longitudinal within-person EEG measurements (up to 12 repeated sessions) conducted in the context of a working memory training study. The goal of the project is to develop novel analytical approaches to link cognitive and neural process models on the within-person level. Please spread the news! Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Ta Dinh, Son [son.ta.dinh at tum.de] Gesendet: Dienstag, 10. Januar 2017 08:20 An: fieldtrip at science.ru.nl Betreff: [FieldTrip] LCMV beamforming, source.avg.pow is not the power? Hi Fieldtrippers, I have been trying to do a source analysis on my (resting-state) data using LCMV beamforming and as part of a sanity check, I wanted to plot the alpha power. Using ft_sourceanalysis I get a source structure containing avg.pow and intuitively I expected this field to contain the averaged power of the time series. Therefore, I band-passed the data on the sensor level before doing the LCMV source reconstruction. Surprisingly however, when I used the resulting LCMV spatial filter to construct virtual channels and calculated the alpha power spectrum of the resulting time series using ft_freqanalysis, the average power between these 2 approaches differed by several orders of magnitude over many voxels. Did I make some conceptual misunderstanding? Are the 2 approaches I used not equivalent? Or does source.avg.pow not contain the average power at all? Any comments would be greatly appreciated! Best regards, Son Son Ta Dinh, M.Sc. PhD student in Human Pain Research Klinikum rechts der Isar Technische Universität München Munich, Germany Phone: +49 89 4140 7664 http://www.painlabmunich.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PostDoc_CONMEM_2017.pdf Type: application/pdf Size: 50077 bytes Desc: PostDoc_CONMEM_2017.pdf URL: From jan.schoffelen at donders.ru.nl Tue Jan 10 14:40:58 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Tue, 10 Jan 2017 13:40:58 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: Message-ID: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Tue Jan 10 15:36:48 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Tue, 10 Jan 2017 14:36:48 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> References: , <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Message-ID: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Jan 10 16:19:14 2017 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 10 Jan 2017 16:19:14 +0100 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) Message-ID: Dear all, Robert told me there is something implemented, yet undocumented, that would facilitate computing bipolar derivations when re-referencing EEG data. (I have many SEEG electrodes with multiple contact points and would like to have bipolar contacts for each electrode). I don't remember exactly what it was, though. Does anyone know what that would be/has used it before? (Possibly with ft_preprocessing, with a boolean in cfg.refchannel?) Thanks a lot, Vitória -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Jan 10 16:32:53 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Tue, 10 Jan 2017 15:32:53 +0000 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) In-Reply-To: References: Message-ID: <76DED69E-B3C3-4DD5-B6C6-2E803BBB99C3@donders.ru.nl> Hi Vitoria, ft_apply_montage is your friend. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 16:19, Vitoria Piai > wrote: Dear all, Robert told me there is something implemented, yet undocumented, that would facilitate computing bipolar derivations when re-referencing EEG data. (I have many SEEG electrodes with multiple contact points and would like to have bipolar contacts for each electrode). I don't remember exactly what it was, though. Does anyone know what that would be/has used it before? (Possibly with ft_preprocessing, with a boolean in cfg.refchannel?) Thanks a lot, Vitória _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Jan 10 16:37:47 2017 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 10 Jan 2017 16:37:47 +0100 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) Message-ID: Yep, that's him! Thanks! On 10 January 2017 at 16:32, Schoffelen, J.M. (Jan Mathijs) < jan.schoffelen at donders.ru.nl> wrote: > Hi Vitoria, > > ft_apply_montage is your friend. > > Best, > Jan-Mathijs > > > J.M.Schoffelen > Senior Researcher, VIDI-fellow > Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > > > > > On 10 Jan 2017, at 16:19, Vitoria Piai wrote: > > Dear all, > > Robert told me there is something implemented, yet undocumented, that > would facilitate computing bipolar derivations when re-referencing EEG > data. (I have many SEEG electrodes with multiple contact points and would > like to have bipolar contacts for each electrode). > > I don't remember exactly what it was, though. Does anyone know what that > would be/has used it before? (Possibly with ft_preprocessing, with a > boolean in cfg.refchannel?) > > Thanks a lot, Vitória > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmadsen at emory.edu Tue Jan 10 21:01:31 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Tue, 10 Jan 2017 15:01:31 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Thanks for the reference. In return, I also recommend reading Ciuparu and Mures an's recent rebuttal: European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, doi:10.1111/ejn.13179 TECHNICAL SPOTLIGHT Sources of bias in single-trial normalization procedures They demonstrate that the positive bias Grandchamp and Delorme warned about with single-trial baseline normalization was, in fact, due to the correlated numerators and denominators in each of the baseline normalization procedures they tested, which was, in turn, caused by the skewed distributions of baseline power values. They demonstrate that this bias is reduced by using a much longer baseline, ideally incorporated into the experimental design, but when that's not possible, stitching together the baselines of many trials. Neither article addresses my specific question of whether it would be even better to log-transform the raw power values before averaging, so I suppose I'll have to test it myself and write my own methods article! 🤓 I will go ahead and incorporate some of these alternative baseline normalization methods in my git fork of FieldTrip as I go along with my own analyses, so let me know if anyone else would find them useful, and I'll submit a pull request to contribute them to the master branch. Thanks for the fruitful discussion, all! ~Teresa On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: > Indeed, in a separate thread with Michael Cohen several months back he > suggested precisely that paper. > > On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" > wrote: > >> I think this paper is relevant to this discussion. >> >> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >> >> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >> >> >> >> On 19 December 2016 at 13:08, Teresa Madsen wrote: >> >>> I appreciate everyone's feedback, but I still wonder if something is >>> being missed. I understand that the non-normally distributed power values >>> may be less of an issue when performing non-parametric stats or even a >>> paired-samples t-test that looks at difference values which may be normal >>> even when the raw data isn't. However, my concern comes into play even >>> before these statistical comparisons are made, whenever any averaging is >>> done to freq-type data across times, frequencies, trials, electrodes, >>> subjects, etc. That means any time any of these configuration options are >>> used for any of these functions, and probably more: >>> >>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>> cfg.avgoverfreq = 'yes'; >>> ft_freqbaseline: cfg.baseline = anything but 'no' >>> >>> In each case, if raw power values are averaged, the result will be >>> positively skewed. Maybe it's not a huge problem if all of the data is >>> treated identically, but the specific case that triggered my concern was in >>> ft_freqbaseline, where the individual time-frequency bins are compared to >>> the mean over time for the baseline period. For example, when using >>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>> data does indeed have a more normal distribution over time, but the mean >>> over the baseline time period is performed *before* the log transform, when >>> the distribution is still highly skewed: >>> >>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>> size(data, 3)]); >>> data = 10*log10(data ./ meanVals); >>> >>> That's what I had originally done when analyzing data for my SfN poster, >>> when I realized the background noise that shouldn't have changed much from >>> baseline was mostly showing a decrease from baseline of about -3dB. >>> >>> Now, I've realized I'm seeing this as more of a problem than others >>> because of another tweak I made, which was to use a long, separate baseline >>> recording to normalize my trial data, rather than a short pre-trial period >>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>> for a baseline power estimate might be okay because overlapping time points >>> in the original data are used to calculate those power values anyway, >>> probably making them less skewed, but also (it seems to me) more arbitrary >>> and prone to error. I already offered my custom function BLnorm.m to one >>> person who was asking about this issue of normalizing to a separate >>> baseline recording, and I would be happy to contribute it to FieldTrip if >>> others would appreciate it. >>> >>> Since a few people suggested using the median, and it is also suggested >>> in Cohen's textbook >>> as >>> an alternative measure of the central tendency for skewed raw power values, >>> I wonder if the simplest fix might be to add an option to select mean or >>> median in each of the functions listed above. Another possibility would be >>> adding an option to transform the power values upon output from >>> ft_freqanalysis. >>> >>> Would anyone else find such changes useful? >>> >>> Thanks, >>> Teresa >>> >>> >>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>> J.Herring at donders.ru.nl> wrote: >>> >>>> In terms of statistics it is the distribution of values that you do the >>>> statistics on that matters. In case of a paired-samples t-test when >>>> comparing two conditions, it is the distribution of difference values that >>>> has to be normally distributed. The distribution of difference values is >>>> often normal given two similarly non-normal distributions, offering no >>>> complications for a regular parametric test. >>>> >>>> >>>> >>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>> normality, so you should have no problem there either. >>>> >>>> >>>> >>>> >>>> >>>> *From:* fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at scie >>>> nce.ru.nl] *On Behalf Of *Alik Widge >>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>> *To:* FieldTrip discussion list >>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>> data analysis >>>> >>>> >>>> >>>> In this, Teresa is right and we have observed this in our own EEG data >>>> -- depending on one's level of noise and number of trials/patients, the >>>> mean can be a very poor estimator of central tendency. My students are >>>> still arguing about what we really want to do with it, but at least one of >>>> them has shifted to using the median as a matter of course for baseline >>>> normalization. >>>> >>>> >>>> Alik Widge >>>> alik.widge at gmail.com >>>> (206) 866-5435 >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>> wrote: >>>> >>>> That may very well be true; to be honest, I haven't looked that deeply >>>> into the stats offerings yet. However, my plan is to express each >>>> electrode's experimental data in terms of change from their respective >>>> baseline recordings before attempting any group averaging or statistical >>>> testing, and this problem shows up first in the baseline correction step, >>>> where FieldTrip averages raw power over time. >>>> >>>> ~Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>> statistics implemented by fieldtrip, the data does not need to be normally >>>> distributed. >>>> >>>> >>>> >>>> On 12 December 2016 at 13:39, Teresa Madsen wrote: >>>> >>>> No, sorry, that's not what I meant, but thanks for giving me the >>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>> across frequencies, but the distribution across time (and according to the >>>> poster, also across space), also has an extremely skewed, negative >>>> exponential distribution. I probably confused everyone by trying to show >>>> too much data in my figure, but each color represents the distribution of >>>> power values for a single frequency over time, using a histogram and a line >>>> above with circles at the mean +/- one standard deviation. >>>> >>>> My main point was that the mean is not representative of the central >>>> tendency of such an asymmetrical distribution of power values over time. >>>> It's even more obvious which is more representative of their actual >>>> distributions when I plot e^mean(logpower) on the raw plot and >>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>> busy and confusing. >>>> >>>> I hope that helps, >>>> Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Hi Teresa, >>>> >>>> >>>> >>>> I think what you are discussing is the 1/f power scaling of the power >>>> spectrum. This is one of the reasons that comparisons are made within >>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>> as such the assumption is that within bands there should be a relative >>>> change against baseline and this is what the statistics are performed on. >>>> That is, baseline correction is assumed to be the mean for a specific >>>> frequency and not a mean across frequencies. >>>> >>>> >>>> >>>> And this leads to another point that when you are selecting a >>>> frequency range to do the non-parametric statistics on you should not do >>>> 1-64 Hz but break it up based on the bands. >>>> >>>> >>>> >>>> Hope my interpretation of your point is correct. I sent in >>>> individually, as I wanted to ensure I followed your point. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Nick >>>> >>>> >>>> >>>> >>>> >>>> On 12 December 2016 at 08:23, Teresa Madsen wrote: >>>> >>>> FieldTrippers, >>>> >>>> >>>> >>>> While analyzing my data for the annual Society for Neuroscience >>>> meeting, I developed a concern that was quickly validated by another poster >>>> (full abstract copied and linked below) focusing on the root of the >>>> problem: neural oscillatory power is not normally distributed across time, >>>> frequency, or space. The specific problem I had encountered was in >>>> baseline-correcting my experimental data, where, regardless of >>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>> However, I found that the distribution of raw power over time is so skewed >>>> that the mean was not a reasonable approximation of the central tendency of >>>> the baseline power, so it made most of my experimental data look like it >>>> had decreased power compared to baseline. The more I think about it, the >>>> more I realize that averaging is everywhere in the way we analyze neural >>>> oscillations (across time points, frequency bins, electrodes, trials, >>>> subjects, etc.), and many of the standard statistics people use also rely >>>> on assumptions of normality. >>>> >>>> >>>> >>>> The most obvious solution for me was to log transform the data first, >>>> as it appears to be fairly log normal, and I always use log-scale >>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>> that this would at least "restore (some) symmetry to the error >>>> distribution." I used a natural log transform, sort of arbitrarily to >>>> differentiate from the standard decibel transform included in FieldTrip as >>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>> across several frequency bands (using power values from a wavelet >>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>> cortex). The lines at the top represent the mean +/- one standard >>>> deviation for each frequency band, and you can see how those descriptive >>>> stats are much more representative of the actual distributions in the log >>>> scale. >>>> >>>> >>>> >>>> >>>> ​​ >>>> >>>> For my analysis, I also calculated a z-score on the log transformed >>>> power to assess how my experimental data compared to the variability of the >>>> noise in a long baseline recording from before conditioning, rather than a >>>> short pre-trial baseline period, since I find that more informative than >>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>> functions I wrote for this if people think it would be a useful addition to >>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>> poster, if anyone wants more detail - I just didn't want to make this email >>>> too big. >>>> >>>> >>>> >>>> Mostly, I'm just hoping to start some discussion here as to how to >>>> address this. I searched the wiki >>>> , listserv >>>> >>>> archives >>>> , >>>> and bugzilla >>>> for >>>> anything related and came up with a few topics surrounding normalization >>>> and baseline correction, but only skirting this issue. It seems important, >>>> so I want to find out whether others agree with my approach or already have >>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>> be changed or just documentation added, or what? >>>> >>>> >>>> >>>> Thanks for any insights, >>>> >>>> Teresa >>>> >>>> >>>> >>>> >>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>> across time >>>> >>>> >>>> *Authors* >>>> >>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>> Cognitive Sci., UCSD, San Diego, CA >>>> >>>> *Disclosures* >>>> >>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>> >>>> *Abstract* >>>> >>>> Neural oscillations are important in organizing activity across the >>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>> to numerous disease states. Oscillations are known to vary by frequency and >>>> amplitude across time and between different brain regions; however, this >>>> variability has never been well characterized. We examined human and animal >>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>> distribution of power and frequency across time, space and species. We >>>> report that between data types, subjects, frequencies, electrodes, and >>>> time, an inverse power law, or negative exponential distribution, is >>>> present in all recordings. This is contrary to, and not compatible with, >>>> the Gaussian noise assumption made in many digital signal processing >>>> techniques. The statistical assumptions underlying common algorithms for >>>> power spectral estimation, such as Welch's method, are being violated >>>> resulting in non-trivial misestimates of oscillatory power. Different >>>> statistical approaches are warranted. >>>> >>>> >>>> >>>> -- >>>> >>>> Teresa E. Madsen, PhD >>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>> analysis >>>> >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> >>>> Emory University >>>> >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> >>>> (770) 296-9119 >>>> >>>> braingirl at gmail.com >>>> >>>> https://www.linkedin.com/in/temadsen >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Teresa E. Madsen, PhD >>> Division of Behavioral Neuroscience and Psychiatric Disorders >>> Yerkes National Primate Research Center >>> Emory University >>> Rainnie Lab, NSB 5233 >>> 954 Gatewood Rd. NE >>> Atlanta, GA 30329 >>> (770) 296-9119 >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Nicholas Peatfield, PhD >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38279 bytes Desc: not available URL: From selene.petit at hotmail.fr Wed Jan 11 01:53:40 2017 From: selene.petit at hotmail.fr (=?iso-8859-1?Q?S=E9l=E8ne_Petit?=) Date: Wed, 11 Jan 2017 00:53:40 +0000 Subject: [FieldTrip] Help needed for an Emotiv layout Message-ID: Hi, I want to analyze some Emotiv EPOC+ data using cluster permutation. My problem is I don't know how to get a layout or a neighbour matrix for this system. Does someone have a .lay file and a neighbour file for Emotiv? Or should I create my own? I'm not sure how to do that, even after reading the documentation for ft_prepapre_layout. Thanks a lot in advance, Kindly, Selene Selene Petit PhD Candidate Department of Cognitive Science | Level 3, Australia Hearing Hub 16 University Avenue Macquarie University NSW 2109 Australia T: 0404602281 | ccd.edu.au | mq.edu.au -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Thu Jan 12 11:39:09 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Thu, 12 Jan 2017 10:39:09 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data Message-ID: Hello everyone! I am dealing with HPC timeseries from rfMRI (dtseries.nii) data and I it has a 200 dimensionality ("parcellated”). I want to know which area of the brain corresponds to each parcel but I could not manage to find it out. When I read the file with ft_read_cifti in Matlab, it returns me the following struct: struct with fields: dimord: 'pos_time' time: [1×200 double] hdr: [1×1 struct] unit: 'mm' brainstructure: [96854×1 double] brainstructurelabel: {1×21 cell} dim: [91 109 91] pos: [96854×3 double] transform: [4×4 double] dtseries: [96854×200 double] But any of those variables is linking the parcel with any brain area. Thank you all in advanced! Joan From jan.schoffelen at donders.ru.nl Thu Jan 12 12:19:58 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 12 Jan 2017 11:19:58 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Message-ID: <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Thu Jan 12 12:24:19 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Thu, 12 Jan 2017 11:24:19 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data References: Message-ID: <834270EE-34AE-4B5D-83B0-F5F27277A238@estudiant.upf.edu> Hello everyone! I am dealing with HPC timeseries from rfMRI (dtseries.nii) data and I it has a 200 dimensionality ("parcellated”). I want to know which area of the brain corresponds to each parcel but I could not manage to find it out. When I read the file with ft_read_cifti in Matlab, it returns me the following struct: struct with fields dimord: ‘pos_time' time: [1×200 double] hdr: [1×1 struct] unit: ‘mm' brainstructure: [96854×1 double] brainstructurelabel: {1×21 cell} dim: [91 109 91] pos: [96854×3 double] transform: [4×4 double] dtseries: [96854×200 double But any of those variables is linking the parcel with any brain area. Thank you all in advanced! Joan From mikexcohen at gmail.com Thu Jan 12 13:28:53 2017 From: mikexcohen at gmail.com (Mike X Cohen) Date: Thu, 12 Jan 2017 13:28:53 +0100 Subject: [FieldTrip] CONFERENCE: ICON2017, 5-8 AUGUST, AMSTERDAM Message-ID: [image: Inline image 1]  We are happy to send a reminder for the ICON XIII conference, which will take place on 5-8 August 2017 in Amsterdam (the Netherlands). Amsterdam is an easily-accessible and progressive city. The venue is the Beurs van Berlage, located in downtown Amsterdam and one of the most beautiful conference venues in Europe! Visit the website: http://www.icon2017.org NOTE THE DEADLINES!! 2 January : Registration opened 1 February : Symposia/ask-the-experts/hackathons submissions close! 31 March : Poster submissions close 1 May : Notification of submission acceptance 15 May : Early-bird discount registration ends PRE-CONFERENCE WORKSHOPS/SATELLITES We welcome pre-conference satellites, and will be happy to advertise them on the ICON website. Note that satellites are independent from ICON in terms of organization, registration, and costs. FOLLOW US ON TWITTER For up-to-date announcements before and during the ICON meeting, follow @icon2017 (see also "Media" tab on the website). QUESTIONS ABOUT THE MEETING OR SPONSORSHIP? email icon2017 at icon2017.org http://www.icon2017.org We look forward to seeing you in beautiful Amsterdam! Mike X Cohen and Birte Forstmann -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 105912 bytes Desc: not available URL: From mikexcohen at gmail.com Thu Jan 12 14:37:18 2017 From: mikexcohen at gmail.com (Mike X Cohen) Date: Thu, 12 Jan 2017 14:37:18 +0100 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Interesting discussion here. I think we should take a step back and distinguish between trivial and nontrivial causes and consequences for the skewed distribution. To some extent, the non-normal distribution is simply the result of defining power as a squared distance -- distances are always positive and squaring them means big values become really big. Consider the following: d = randn(10000,1); % random numbers subplot(311), hist(d,500); % their distribution subplot(312), hist(d.^2,500); % "power" distribution, also try a log-scaled y-axis subplot(313), hist(log(d.^2),500); % log-power distribution The fact that power values have a power-law-like distribution is therefore trivial. But this leads to two non-trivial questions: 1) Is this distribution meaningful for brain function (beyond simply the result of taking squared values)? People who study "the log-brain" and fractal-like (or scale-free) organization of brain function would argue that these distributions reveal meaningful insights into brain function, and therefore it is not really an artifact for analyses. In other words, large values are large for a reason; they might not be outliers that we should attempt to compress. 2) Does it matter for real data analysis? I think this is Teresa's initial concern. I'm inclined to think that it doesn't really matter, but that's just based on the idea (hope!) that if it did really matter and the way we do it is wrong, the field would have discovered this a long time ago. On the other hand, this wouldn't be the first time that people have gotten things wrong for decades. I think the best way to investigate #2 would be with simulated data, showing that a "true" effect is missed when not first computing log-power, presumably because the effect was overshadowed by large-amplitude "noise" (but somehow this would have to be physiological noise that wouldn't get rejected during data cleaning). In empirical data, all you'd be able to do is show a difference without knowing the right answer. btw, make sure to be careful with baselining log-power -- any divisions (e.g., dB or percent change) will be unstable/run off to infinity when baseline power is close to zero, i.e., raw power is close to 1. The sign might also get weird. Probably best to use a baseline subtraction. Mike --------------------------------------------><------------------------------------------------ Thanks for the reference. In return, I also recommend reading Ciuparu and Mures an's recent rebuttal: European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, doi:10.1111/ejn.13179 TECHNICAL SPOTLIGHT Sources of bias in single-trial normalization procedures They demonstrate that the positive bias Grandchamp and Delorme warned about with single-trial baseline normalization was, in fact, due to the correlated numerators and denominators in each of the baseline normalization procedures they tested, which was, in turn, caused by the skewed distributions of baseline power values. They demonstrate that this bias is reduced by using a much longer baseline, ideally incorporated into the experimental design, but when that's not possible, stitching together the baselines of many trials. Neither article addresses my specific question of whether it would be even better to log-transform the raw power values before averaging, so I suppose I'll have to test it myself and write my own methods article! 🤓 I will go ahead and incorporate some of these alternative baseline normalization methods in my git fork of FieldTrip as I go along with my own analyses, so let me know if anyone else would find them useful, and I'll submit a pull request to contribute them to the master branch. Thanks for the fruitful discussion, all! ~Teresa On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: > Indeed, in a separate thread with Michael Cohen several months back he > suggested precisely that paper. > > On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" > wrote: > >> I think this paper is relevant to this discussion. >> >> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >> >> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >> >> >> >> On 19 December 2016 at 13:08, Teresa Madsen wrote: >> >>> I appreciate everyone's feedback, but I still wonder if something is >>> being missed. I understand that the non-normally distributed power values >>> may be less of an issue when performing non-parametric stats or even a >>> paired-samples t-test that looks at difference values which may be normal >>> even when the raw data isn't. However, my concern comes into play even >>> before these statistical comparisons are made, whenever any averaging is >>> done to freq-type data across times, frequencies, trials, electrodes, >>> subjects, etc. That means any time any of these configuration options are >>> used for any of these functions, and probably more: >>> >>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>> cfg.avgoverfreq = 'yes'; >>> ft_freqbaseline: cfg.baseline = anything but 'no' >>> >>> In each case, if raw power values are averaged, the result will be >>> positively skewed. Maybe it's not a huge problem if all of the data is >>> treated identically, but the specific case that triggered my concern was in >>> ft_freqbaseline, where the individual time-frequency bins are compared to >>> the mean over time for the baseline period. For example, when using >>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>> data does indeed have a more normal distribution over time, but the mean >>> over the baseline time period is performed *before* the log transform, when >>> the distribution is still highly skewed: >>> >>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>> size(data, 3)]); >>> data = 10*log10(data ./ meanVals); >>> >>> That's what I had originally done when analyzing data for my SfN poster, >>> when I realized the background noise that shouldn't have changed much from >>> baseline was mostly showing a decrease from baseline of about -3dB. >>> >>> Now, I've realized I'm seeing this as more of a problem than others >>> because of another tweak I made, which was to use a long, separate baseline >>> recording to normalize my trial data, rather than a short pre-trial period >>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>> for a baseline power estimate might be okay because overlapping time points >>> in the original data are used to calculate those power values anyway, >>> probably making them less skewed, but also (it seems to me) more arbitrary >>> and prone to error. I already offered my custom function BLnorm.m to one >>> person who was asking about this issue of normalizing to a separate >>> baseline recording, and I would be happy to contribute it to FieldTrip if >>> others would appreciate it. >>> >>> Since a few people suggested using the median, and it is also suggested >>> in Cohen's textbook >>> as >>> an alternative measure of the central tendency for skewed raw power values, >>> I wonder if the simplest fix might be to add an option to select mean or >>> median in each of the functions listed above. Another possibility would be >>> adding an option to transform the power values upon output from >>> ft_freqanalysis. >>> >>> Would anyone else find such changes useful? >>> >>> Thanks, >>> Teresa >>> >>> >>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>> J.Herring at donders.ru.nl> wrote: >>> >>>> In terms of statistics it is the distribution of values that you do the >>>> statistics on that matters. In case of a paired-samples t-test when >>>> comparing two conditions, it is the distribution of difference values that >>>> has to be normally distributed. The distribution of difference values is >>>> often normal given two similarly non-normal distributions, offering no >>>> complications for a regular parametric test. >>>> >>>> >>>> >>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>> normality, so you should have no problem there either. >>>> >>>> >>>> >>>> >>>> >>>> *From:* fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at scie >>>> nce.ru.nl] *On Behalf Of *Alik Widge >>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>> *To:* FieldTrip discussion list >>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>> data analysis >>>> >>>> >>>> >>>> In this, Teresa is right and we have observed this in our own EEG data >>>> -- depending on one's level of noise and number of trials/patients, the >>>> mean can be a very poor estimator of central tendency. My students are >>>> still arguing about what we really want to do with it, but at least one of >>>> them has shifted to using the median as a matter of course for baseline >>>> normalization. >>>> >>>> >>>> Alik Widge >>>> alik.widge at gmail.com >>>> (206) 866-5435 >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>> wrote: >>>> >>>> That may very well be true; to be honest, I haven't looked that deeply >>>> into the stats offerings yet. However, my plan is to express each >>>> electrode's experimental data in terms of change from their respective >>>> baseline recordings before attempting any group averaging or statistical >>>> testing, and this problem shows up first in the baseline correction step, >>>> where FieldTrip averages raw power over time. >>>> >>>> ~Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>> statistics implemented by fieldtrip, the data does not need to be normally >>>> distributed. >>>> >>>> >>>> >>>> On 12 December 2016 at 13:39, Teresa Madsen wrote: >>>> >>>> No, sorry, that's not what I meant, but thanks for giving me the >>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>> across frequencies, but the distribution across time (and according to the >>>> poster, also across space), also has an extremely skewed, negative >>>> exponential distribution. I probably confused everyone by trying to show >>>> too much data in my figure, but each color represents the distribution of >>>> power values for a single frequency over time, using a histogram and a line >>>> above with circles at the mean +/- one standard deviation. >>>> >>>> My main point was that the mean is not representative of the central >>>> tendency of such an asymmetrical distribution of power values over time. >>>> It's even more obvious which is more representative of their actual >>>> distributions when I plot e^mean(logpower) on the raw plot and >>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>> busy and confusing. >>>> >>>> I hope that helps, >>>> Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Hi Teresa, >>>> >>>> >>>> >>>> I think what you are discussing is the 1/f power scaling of the power >>>> spectrum. This is one of the reasons that comparisons are made within >>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>> as such the assumption is that within bands there should be a relative >>>> change against baseline and this is what the statistics are performed on. >>>> That is, baseline correction is assumed to be the mean for a specific >>>> frequency and not a mean across frequencies. >>>> >>>> >>>> >>>> And this leads to another point that when you are selecting a >>>> frequency range to do the non-parametric statistics on you should not do >>>> 1-64 Hz but break it up based on the bands. >>>> >>>> >>>> >>>> Hope my interpretation of your point is correct. I sent in >>>> individually, as I wanted to ensure I followed your point. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Nick >>>> >>>> >>>> >>>> >>>> >>>> On 12 December 2016 at 08:23, Teresa Madsen wrote: >>>> >>>> FieldTrippers, >>>> >>>> >>>> >>>> While analyzing my data for the annual Society for Neuroscience >>>> meeting, I developed a concern that was quickly validated by another poster >>>> (full abstract copied and linked below) focusing on the root of the >>>> problem: neural oscillatory power is not normally distributed across time, >>>> frequency, or space. The specific problem I had encountered was in >>>> baseline-correcting my experimental data, where, regardless of >>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>> However, I found that the distribution of raw power over time is so skewed >>>> that the mean was not a reasonable approximation of the central tendency of >>>> the baseline power, so it made most of my experimental data look like it >>>> had decreased power compared to baseline. The more I think about it, the >>>> more I realize that averaging is everywhere in the way we analyze neural >>>> oscillations (across time points, frequency bins, electrodes, trials, >>>> subjects, etc.), and many of the standard statistics people use also rely >>>> on assumptions of normality. >>>> >>>> >>>> >>>> The most obvious solution for me was to log transform the data first, >>>> as it appears to be fairly log normal, and I always use log-scale >>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>> that this would at least "restore (some) symmetry to the error >>>> distribution." I used a natural log transform, sort of arbitrarily to >>>> differentiate from the standard decibel transform included in FieldTrip as >>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>> across several frequency bands (using power values from a wavelet >>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>> cortex). The lines at the top represent the mean +/- one standard >>>> deviation for each frequency band, and you can see how those descriptive >>>> stats are much more representative of the actual distributions in the log >>>> scale. >>>> >>>> >>>> >>>> >>>> ​​ >>>> >>>> For my analysis, I also calculated a z-score on the log transformed >>>> power to assess how my experimental data compared to the variability of the >>>> noise in a long baseline recording from before conditioning, rather than a >>>> short pre-trial baseline period, since I find that more informative than >>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>> functions I wrote for this if people think it would be a useful addition to >>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>> poster, if anyone wants more detail - I just didn't want to make this email >>>> too big. >>>> >>>> >>>> >>>> Mostly, I'm just hoping to start some discussion here as to how to >>>> address this. I searched the wiki >>>> , listserv >>>> < https://mailman.science.ru.nl/pipermail/fieldtrip/2006-December/000773.html> >>>> archives >>>> < https://mailman.science.ru.nl/pipermail/fieldtrip/2010-March/002718.html>, >>>> and bugzilla >>>> for >>>> anything related and came up with a few topics surrounding normalization >>>> and baseline correction, but only skirting this issue. It seems important, >>>> so I want to find out whether others agree with my approach or already have >>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>> be changed or just documentation added, or what? >>>> >>>> >>>> >>>> Thanks for any insights, >>>> >>>> Teresa >>>> >>>> >>>> >>>> >>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>> across time >>>> >>>> >>>> *Authors* >>>> >>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>> Cognitive Sci., UCSD, San Diego, CA >>>> >>>> *Disclosures* >>>> >>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>> >>>> *Abstract* >>>> >>>> Neural oscillations are important in organizing activity across the >>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>> to numerous disease states. Oscillations are known to vary by frequency and >>>> amplitude across time and between different brain regions; however, this >>>> variability has never been well characterized. We examined human and animal >>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>> distribution of power and frequency across time, space and species. We >>>> report that between data types, subjects, frequencies, electrodes, and >>>> time, an inverse power law, or negative exponential distribution, is >>>> present in all recordings. This is contrary to, and not compatible with, >>>> the Gaussian noise assumption made in many digital signal processing >>>> techniques. The statistical assumptions underlying common algorithms for >>>> power spectral estimation, such as Welch's method, are being violated >>>> resulting in non-trivial misestimates of oscillatory power. Different >>>> statistical approaches are warranted. >>>> >>>> >>>> >>>> -- >>>> >>>> Teresa E. Madsen, PhD >>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>> analysis >>>> >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> >>>> Emory University >>>> >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> >>>> (770) 296-9119 >>>> >>>> braingirl at gmail.com >>>> >>>> https://www.linkedin.com/in/temadsen >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Teresa E. Madsen, PhD >>> Division of Behavioral Neuroscience and Psychiatric Disorders >>> Yerkes National Primate Research Center >>> Emory University >>> Rainnie Lab, NSB 5233 >>> 954 Gatewood Rd. NE >>> Atlanta, GA 30329 >>> (770) 296-9119 >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Nicholas Peatfield, PhD >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -- Mike X Cohen, PhD mikexcohen.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From seymourr at aston.ac.uk Thu Jan 12 14:59:32 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Thu, 12 Jan 2017 13:59:32 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data Message-ID: Hi Joan, To me your dtseries.nii looks like it has been parcellated/segmented in time, not space, as the time field is a 1x200 array. You might also want to look at brain structurelabel field and how this relates to the brainstucture field. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Thu Jan 12 16:17:11 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Thu, 12 Jan 2017 15:17:11 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> , <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Message-ID: Thank you for your help Jan. Indeed, it was as simple as adding 'cfg.keeptrials = 'yes'' in my initial time-frequency analyses. Sorry to have encumbered you with what turned out to be a very trivial problem. Your help is much appreciated! K ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 12 January 2017 11:19 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Jan 12 17:06:05 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 12 Jan 2017 16:06:05 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Message-ID: <15BD5312-6EEB-453C-8D65-CB1C8D2176BF@donders.ru.nl> No worries, Kelly, but just to be sure: from your initial e-mail I got the impression that you wanted to do statistical inference across subjects, not across trials (within a signle subject). Specifying cfg.keeptrials before calling ft_freqanalysis should be done for the latter, not for the former type of statistical inference. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 12 Jan 2017, at 16:17, Murphy, Kelly (Research Student) > wrote: Thank you for your help Jan. Indeed, it was as simple as adding 'cfg.keeptrials = 'yes'' in my initial time-frequency analyses. Sorry to have encumbered you with what turned out to be a very trivial problem. Your help is much appreciated! K ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 12 January 2017 11:19 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From mona at sdsc.edu Fri Jan 13 01:04:02 2017 From: mona at sdsc.edu (Wong-Barnum, Mona) Date: Fri, 13 Jan 2017 00:04:02 +0000 Subject: [FieldTrip] NeuroMag 389 channel map Message-ID: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Hello fellow NeuroMag users: Does someone have a location map of the 389 channels on the head? I have been searching but haven’t found anything. These channels are labelled as MEG 0013, MEG 0012, …, MEG 2641, STI 001, STI 002, …, STI 016, EEG 001, EEG 002, …, EEG 060, EOG 061, EOG 062, ECG 063, EMG 064, EEG 065, EEG 066, …, EEG 074 Any help is appreciated. thanks, Mona ********************************************* Mona Wong Web & Mobile Application Developer San Diego Supercomputer Center Believing we are in control is an illusion that brings suffering. ********************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.hauswald at me.com Fri Jan 13 09:12:17 2017 From: anne.hauswald at me.com (anne Hauswald) Date: Fri, 13 Jan 2017 09:12:17 +0100 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Message-ID: Dear Mona, generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. For other purposes you might need the grad structure (data.grad) which is a result of ft_preprocessing and contains information like channel orientation, channel position, etc. for all 306 MEG channels. Hope this helps Best Anne > Am 13.01.2017 um 01:04 schrieb Wong-Barnum, Mona : > > > Hello fellow NeuroMag users: > > Does someone have a location map of the 389 channels on the head? I have been searching but haven’t found anything. These channels are labelled as MEG 0013, MEG 0012, …, MEG 2641, STI 001, STI 002, …, STI 016, EEG 001, EEG 002, …, EEG 060, EOG 061, EOG 062, ECG 063, EMG 064, EEG 065, EEG 066, …, EEG 074 > > Any help is appreciated. > > thanks, > Mona > > ********************************************* > Mona Wong > Web & Mobile Application Developer > San Diego Supercomputer Center > > Believing we are in control is an > illusion that brings suffering. > ********************************************* > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From m.p.craddock at leeds.ac.uk Fri Jan 13 15:51:32 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Fri, 13 Jan 2017 14:51:32 +0000 Subject: [FieldTrip] impact of skewed power distributions on data analysis In-Reply-To: References: Message-ID: Hi all, I'm fiddling around with simulations at the moment but not got a lot of free time, and every time I do fiddle with them the more complicated I seem to make them... correct me if i'm wrong, but there are a couple of different issues here. About the skewness of the distribution - you're not usually comparing two skewed distributions statistically (which even then would probably be ok if they're similary skewed), usually it's a bunch of means from those distributions, and the distribution of the means will often be normally distributed (as will their differences), and thus ok for parametric stats. So the main problem is really whether the mean is a good summary statistic for capturing differences between the underlying distributions or not (similar debates about reaction times) - it's certainly not robust to outliers. Median might be better in some ways, but it's a biased estimator of the population median and might have consequences on stat power - that's one for the simulations at some point. Taking the log first won't necessarily help. As the code Michael Cohen provides shows, taking the log can still result in skewed distributions - power is right-skewed but its log is left-skewed. Taking the square root would obviously be better in this case but that's because it just returns it to the original unsquared normal distribution - whether that's true of real data needs checking out. In addition if you take the log you're no longer testing the same thing when you compare the means - you're testing the geometric mean instead of the arithmetic mean. Differences in the arithmetic means across conditions will not necessarily translate into differences in the geometric means and vice versa. If you use a subtractive baseline, using the median or mean of power will only change what constant you subtract from the data. If you baseline correct using the average of all trials rather than condition specific baselines, it should make no difference to the stats if you use the mean or the median of baseline power (or indeed if you don't use baseline correction at all). If you test differences across electrodes as well as condition, and use electrode but not condition specific baselines - which seems reasonable, since you might expect bigger baseline differences across than within electrodes, it'll only change the main electrode effect, not the condition effect or the interaction between condition and electrode. If you use condition and electrode specific baselines, then it influences *everything*, and you also no longer know if the differences between conditions/electrodes are due to baseline or post-stimulus differences. Using the median over the mean will change the stats if you use divisive baselines, but whether that's a good or bad difference is another question for simulations. Cheers, Matt On 12/01/2017 13:37, Mike X Cohen wrote: > Interesting discussion here. I think we should take a step back and > distinguish between trivial and nontrivial causes and consequences for > the skewed distribution. To some extent, the non-normal distribution is > simply the result of defining power as a squared distance -- distances > are always positive and squaring them means big values become really > big. Consider the following: > > d = randn(10000,1); % random numbers > subplot(311), hist(d,500); % their distribution > subplot(312), hist(d.^2,500); % "power" distribution, also try a > log-scaled y-axis > subplot(313), hist(log(d.^2),500); % log-power distribution > > The fact that power values have a power-law-like distribution is > therefore trivial. > > But this leads to two non-trivial questions: > 1) Is this distribution meaningful for brain function (beyond simply the > result of taking squared values)? People who study "the log-brain" and > fractal-like (or scale-free) organization of brain function would argue > that these distributions reveal meaningful insights into brain function, > and therefore it is not really an artifact for analyses. In other words, > large values are large for a reason; they might not be outliers that we > should attempt to compress. > > 2) Does it matter for real data analysis? I think this is Teresa's > initial concern. I'm inclined to think that it doesn't really matter, > but that's just based on the idea (hope!) that if it did really matter > and the way we do it is wrong, the field would have discovered this a > long time ago. On the other hand, this wouldn't be the first time that > people have gotten things wrong for decades. > > I think the best way to investigate #2 would be with simulated data, > showing that a "true" effect is missed when not first computing > log-power, presumably because the effect was overshadowed by > large-amplitude "noise" (but somehow this would have to be physiological > noise that wouldn't get rejected during data cleaning). In empirical > data, all you'd be able to do is show a difference without knowing the > right answer. > > btw, make sure to be careful with baselining log-power -- any divisions > (e.g., dB or percent change) will be unstable/run off to infinity when > baseline power is close to zero, i.e., raw power is close to 1. The sign > might also get weird. Probably best to use a baseline subtraction. > > Mike > > > > > > --------------------------------------------><------------------------------------------------ > > Thanks for the reference. In return, I also recommend reading Ciuparu and > Mures an's recent rebuttal: > > European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, > doi:10.1111/ejn.13179 > TECHNICAL SPOTLIGHT > Sources of bias in single-trial normalization procedures > > They demonstrate that the positive bias Grandchamp and Delorme warned about > with single-trial baseline normalization was, in fact, due to the > correlated numerators and denominators in each of the baseline > normalization procedures they tested, which was, in turn, caused by the > skewed distributions of baseline power values. They demonstrate that this > bias is reduced by using a much longer baseline, ideally incorporated into > the experimental design, but when that's not possible, stitching together > the baselines of many trials. > > Neither article addresses my specific question of whether it would be even > better to log-transform the raw power values before averaging, so I suppose > I'll have to test it myself and write my own methods article! 🤓 > > I will go ahead and incorporate some of these alternative baseline > normalization methods in my git fork of FieldTrip as I go along with my own > analyses, so let me know if anyone else would find them useful, and I'll > submit a pull request to contribute them to the master branch. > > Thanks for the fruitful discussion, all! > ~Teresa > > > On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge > wrote: > >> Indeed, in a separate thread with Michael Cohen several months back he >> suggested precisely that paper. >> >> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" gmail.com > >> wrote: >> >>> I think this paper is relevant to this discussion. >>> >>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy > Trials. *Frontiers >>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>> >>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>> >>> >>> >>> On 19 December 2016 at 13:08, Teresa Madsen > wrote: >>> >>>> I appreciate everyone's feedback, but I still wonder if something is >>>> being missed. I understand that the non-normally distributed power > values >>>> may be less of an issue when performing non-parametric stats or even a >>>> paired-samples t-test that looks at difference values which may be > normal >>>> even when the raw data isn't. However, my concern comes into play even >>>> before these statistical comparisons are made, whenever any averaging is >>>> done to freq-type data across times, frequencies, trials, electrodes, >>>> subjects, etc. That means any time any of these configuration > options are >>>> used for any of these functions, and probably more: >>>> >>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>> cfg.avgoverfreq = 'yes'; >>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>> >>>> In each case, if raw power values are averaged, the result will be >>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>> treated identically, but the specific case that triggered my concern > was in >>>> ft_freqbaseline, where the individual time-frequency bins are > compared to >>>> the mean over time for the baseline period. For example, when using >>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output > freq >>>> data does indeed have a more normal distribution over time, but the mean >>>> over the baseline time period is performed *before* the log > transform, when >>>> the distribution is still highly skewed: >>>> >>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>> size(data, 3)]); >>>> data = 10*log10(data ./ meanVals); >>>> >>>> That's what I had originally done when analyzing data for my SfN poster, >>>> when I realized the background noise that shouldn't have changed > much from >>>> baseline was mostly showing a decrease from baseline of about -3dB. >>>> >>>> Now, I've realized I'm seeing this as more of a problem than others >>>> because of another tweak I made, which was to use a long, separate > baseline >>>> recording to normalize my trial data, rather than a short pre-trial > period >>>> as ft_freqbaseline is designed to do. Averaging a few hundred > milliseconds >>>> for a baseline power estimate might be okay because overlapping time > points >>>> in the original data are used to calculate those power values anyway, >>>> probably making them less skewed, but also (it seems to me) more > arbitrary >>>> and prone to error. I already offered my custom function BLnorm.m > to one >>>> person who was asking about this issue of normalizing to a separate >>>> baseline recording, and I would be happy to contribute it to > FieldTrip if >>>> others would appreciate it. >>>> >>>> Since a few people suggested using the median, and it is also suggested >>>> in Cohen's textbook >>>> as >>>> an alternative measure of the central tendency for skewed raw power > values, >>>> I wonder if the simplest fix might be to add an option to select mean or >>>> median in each of the functions listed above. Another possibility > would be >>>> adding an option to transform the power values upon output from >>>> ft_freqanalysis. >>>> >>>> Would anyone else find such changes useful? >>>> >>>> Thanks, >>>> Teresa >>>> >>>> >>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>> J.Herring at donders.ru.nl > wrote: >>>> >>>>> In terms of statistics it is the distribution of values that you do the >>>>> statistics on that matters. In case of a paired-samples t-test when >>>>> comparing two conditions, it is the distribution of difference > values that >>>>> has to be normally distributed. The distribution of difference > values is >>>>> often normal given two similarly non-normal distributions, offering no >>>>> complications for a regular parametric test. >>>>> >>>>> >>>>> >>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>> normality, so you should have no problem there either. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* fieldtrip-bounces at science.ru.nl > [mailto:fieldtrip-bounces at scie >>>>> nce.ru.nl ] *On Behalf Of *Alik Widge >>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>> *To:* FieldTrip discussion list > >>>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>> data analysis >>>>> >>>>> >>>>> >>>>> In this, Teresa is right and we have observed this in our own EEG data >>>>> -- depending on one's level of noise and number of trials/patients, the >>>>> mean can be a very poor estimator of central tendency. My students are >>>>> still arguing about what we really want to do with it, but at least > one of >>>>> them has shifted to using the median as a matter of course for baseline >>>>> normalization. >>>>> >>>>> >>>>> Alik Widge >>>>> alik.widge at gmail.com >>>>> (206) 866-5435 >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen emory.edu > >>>>> wrote: >>>>> >>>>> That may very well be true; to be honest, I haven't looked that deeply >>>>> into the stats offerings yet. However, my plan is to express each >>>>> electrode's experimental data in terms of change from their respective >>>>> baseline recordings before attempting any group averaging or > statistical >>>>> testing, and this problem shows up first in the baseline correction > step, >>>>> where FieldTrip averages raw power over time. >>>>> >>>>> ~Teresa >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>> nick.peatfield at gmail.com > wrote: >>>>> >>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>> statistics implemented by fieldtrip, the data does not need to be > normally >>>>> distributed. >>>>> >>>>> >>>>> >>>>> On 12 December 2016 at 13:39, Teresa Madsen > wrote: >>>>> >>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>> opportunity to clarify. Of course everyone is familiar with the 1/f > pattern >>>>> across frequencies, but the distribution across time (and according > to the >>>>> poster, also across space), also has an extremely skewed, negative >>>>> exponential distribution. I probably confused everyone by trying to > show >>>>> too much data in my figure, but each color represents the > distribution of >>>>> power values for a single frequency over time, using a histogram > and a line >>>>> above with circles at the mean +/- one standard deviation. >>>>> >>>>> My main point was that the mean is not representative of the central >>>>> tendency of such an asymmetrical distribution of power values over > time. >>>>> It's even more obvious which is more representative of their actual >>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>>> busy and confusing. >>>>> >>>>> I hope that helps, >>>>> Teresa >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>> nick.peatfield at gmail.com > wrote: >>>>> >>>>> Hi Teresa, >>>>> >>>>> >>>>> >>>>> I think what you are discussing is the 1/f power scaling of the power >>>>> spectrum. This is one of the reasons that comparisons are made within >>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to > gamma), >>>>> as such the assumption is that within bands there should be a relative >>>>> change against baseline and this is what the statistics are > performed on. >>>>> That is, baseline correction is assumed to be the mean for a specific >>>>> frequency and not a mean across frequencies. >>>>> >>>>> >>>>> >>>>> And this leads to another point that when you are selecting a >>>>> frequency range to do the non-parametric statistics on you should > not do >>>>> 1-64 Hz but break it up based on the bands. >>>>> >>>>> >>>>> >>>>> Hope my interpretation of your point is correct. I sent in >>>>> individually, as I wanted to ensure I followed your point. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> Nick >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12 December 2016 at 08:23, Teresa Madsen > wrote: >>>>> >>>>> FieldTrippers, >>>>> >>>>> >>>>> >>>>> While analyzing my data for the annual Society for Neuroscience >>>>> meeting, I developed a concern that was quickly validated by > another poster >>>>> (full abstract copied and linked below) focusing on the root of the >>>>> problem: neural oscillatory power is not normally distributed > across time, >>>>> frequency, or space. The specific problem I had encountered was in >>>>> baseline-correcting my experimental data, where, regardless of >>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>> However, I found that the distribution of raw power over time is so > skewed >>>>> that the mean was not a reasonable approximation of the central > tendency of >>>>> the baseline power, so it made most of my experimental data look > like it >>>>> had decreased power compared to baseline. The more I think about > it, the >>>>> more I realize that averaging is everywhere in the way we analyze > neural >>>>> oscillations (across time points, frequency bins, electrodes, trials, >>>>> subjects, etc.), and many of the standard statistics people use > also rely >>>>> on assumptions of normality. >>>>> >>>>> >>>>> >>>>> The most obvious solution for me was to log transform the data first, >>>>> as it appears to be fairly log normal, and I always use log-scale >>>>> visualizations anyway. Erik Peterson, middle author on the poster, > agreed >>>>> that this would at least "restore (some) symmetry to the error >>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>> differentiate from the standard decibel transform included in > FieldTrip as >>>>> cfg.baselinetype = 'db'. The following figures compare the 2 > distributions >>>>> across several frequency bands (using power values from a wavelet >>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>> cortex). The lines at the top represent the mean +/- one standard >>>>> deviation for each frequency band, and you can see how those > descriptive >>>>> stats are much more representative of the actual distributions in > the log >>>>> scale. >>>>> >>>>> >>>>> >>>>> >>>>> ​​ >>>>> >>>>> For my analysis, I also calculated a z-score on the log transformed >>>>> power to assess how my experimental data compared to the > variability of the >>>>> noise in a long baseline recording from before conditioning, rather > than a >>>>> short pre-trial baseline period, since I find that more informative > than >>>>> any of FieldTrip's built-in baseline types. I'm happy to share the > custom >>>>> functions I wrote for this if people think it would be a useful > addition to >>>>> FieldTrip. I can also share more about my analysis and/or a copy > of the >>>>> poster, if anyone wants more detail - I just didn't want to make > this email >>>>> too big. >>>>> >>>>> >>>>> >>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>> address this. I searched the wiki >>>>> , listserv >>>>> > >>>>> archives >>>>> > , >>>>> and bugzilla >>>>> for >>>>> anything related and came up with a few topics surrounding > normalization >>>>> and baseline correction, but only skirting this issue. It seems > important, >>>>> so I want to find out whether others agree with my approach or > already have >>>>> other ways of avoiding the problem, and whether FieldTrip's code > needs to >>>>> be changed or just documentation added, or what? >>>>> >>>>> >>>>> >>>>> Thanks for any insights, >>>>> >>>>> Teresa >>>>> >>>>> >>>>> >>>>> >>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>> across time >>>>> >>>>> >>>>> *Authors* >>>>> >>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>> Cognitive Sci., UCSD, San Diego, CA >>>>> >>>>> *Disclosures* >>>>> >>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>> >>>>> *Abstract* >>>>> >>>>> Neural oscillations are important in organizing activity across the >>>>> human brain in healthy cognition, while oscillatory disruptions are > linked >>>>> to numerous disease states. Oscillations are known to vary by > frequency and >>>>> amplitude across time and between different brain regions; however, > this >>>>> variability has never been well characterized. We examined human > and animal >>>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>> distribution of power and frequency across time, space and species. We >>>>> report that between data types, subjects, frequencies, electrodes, and >>>>> time, an inverse power law, or negative exponential distribution, is >>>>> present in all recordings. This is contrary to, and not compatible > with, >>>>> the Gaussian noise assumption made in many digital signal processing >>>>> techniques. The statistical assumptions underlying common > algorithms for >>>>> power spectral estimation, such as Welch's method, are being violated >>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>> statistical approaches are warranted. >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Teresa E. Madsen, PhD >>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>> analysis >>>>> >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> >>>>> Emory University >>>>> >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> >>>>> (770) 296-9119 >>>>> >>>>> braingirl at gmail.com >>>>> >>>>> https://www.linkedin.com/in/temadsen >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Nicholas Peatfield, PhD >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Nicholas Peatfield, PhD >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> >>>> >>>> -- >>>> Teresa E. Madsen, PhD >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> Emory University >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> (770) 296-9119 >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Nicholas Peatfield, PhD >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Teresa E. Madsen, PhD > Division of Behavioral Neuroscience and Psychiatric Disorders > Yerkes National Primate Research Center > Emory University > Rainnie Lab, NSB 5233 > 954 Gatewood Rd. NE > Atlanta, GA 30329 > (770) 296-9119 > > -- > Mike X Cohen, PhD > mikexcohen.com > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From mona at sdsc.edu Fri Jan 13 19:20:06 2017 From: mona at sdsc.edu (Wong-Barnum, Mona) Date: Fri, 13 Jan 2017 18:20:06 +0000 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Message-ID: <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> Hi Anne: Thank you so much for your reply. > generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. Is there an explanation of the 5 different neuromag layout files? I have the following: neuromag306all.lay neuromag306eeg1005_natmeg.lay neuromag306planar.lay neuromag306cmb.lay neuromag306mag.lay I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay files are for. I found http://www.fieldtriptoolbox.org/tutorial/layout page but if there is anything that’s useful, please point me to it. thanks, Mona ********************************************* Mona Wong Web & Mobile Application Developer San Diego Supercomputer Center "Believe you can and you are half way there." -- Theodore Roosevelt ********************************************* From acskwara at ucdavis.edu Sat Jan 14 02:14:20 2017 From: acskwara at ucdavis.edu (Alea Skwara) Date: Fri, 13 Jan 2017 17:14:20 -0800 Subject: [FieldTrip] Downloading sample data from the Fieldtrip ftp Message-ID: Hi All, I've been trying (unsuccessfully) to download some of the tutorial sample data from the fieldtrip ftp server. I tried several different ftp clients and was finally able to connect and view the files using Cyberduck, but when I actually attempt to download anything the connection fails. Has anyone had a similar problem and found a solution? Thank you, Alea -- Alea C. Skwara Graduate Student | Saron Lab http://mindbrain.ucdavis.edu/labs/Saron Center for Mind and Brain | University of California, Davis 267 Cousteau Place | Davis CA 95616 Cell: (828) 273-8595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From na.so.ir at gmail.com Sat Jan 14 15:12:49 2017 From: na.so.ir at gmail.com (Narjes Soltani) Date: Sat, 14 Jan 2017 17:42:49 +0330 Subject: [FieldTrip] error while removing ecg Message-ID: Dear all Hi, I am trying to remove ecg artifact from some neuromag MEG data using the “ ft_artifact_ecg” method, but unfortunately I encounter the following error: "Undefined function or variable "labelmlt"." When I traced the code, I found that the error is raised from “ft_channelselection” method. In this method, line 340, the value of variable "findmlt" is set to some index, in my code to 1, via the following code snippet: findmlt = find(strcmp(channel, 'MLT')); Then in line 428 of method “ft_channelselection”, the following line of code produces the above error: if findmlt, channel = [channel; labelmlt]; end I found that the only place in method “ft_channelselection” where variable “ labelmlt” is set is in line 249 which is not accessible in my code as it seems to only be accessible for the CTF file format. To solve the problem, I just copied lien 249 at the end of the switch case statements, i.e. after line 298 as follows: labelmlt = datachannel(strncmp('MLT', *datachannel*, length('MLT'))); and I replaced the bold “*datachannel*" variable with “channel” variable and this way the error was solved, but I am not really sure what I have done is correct or not. Would you please help me with this issue? I had the same problem with labelmrt and I solved it in the same way. Besides, I wonder if there is any better and more straightforward way to remove ECG artifact as even after solving the above errors, I have to manually answer to the following line at each run: current zvalue threshold = 3.000 keep the current value (y/n) ? Best, Narjes -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfibm at yahoo.com Mon Jan 16 09:08:02 2017 From: mfibm at yahoo.com (Mohamed Fawzy) Date: Mon, 16 Jan 2017 08:08:02 +0000 (UTC) Subject: [FieldTrip] i need help References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> Message-ID: <1609558455.3967220.1484554082497@mail.yahoo.com> hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing,Faculty of Computers and Informatics,Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14Mobile:00201220577416Tel:0020133188266    Fax:0020133188256E-mail: mohamed.issa at fci.bu.edu.eg ,  mfibm at yahoo.com,  -------------- next part -------------- An HTML attachment was scrubbed... URL: From stan.vanpelt at donders.ru.nl Mon Jan 16 09:27:55 2017 From: stan.vanpelt at donders.ru.nl (Pelt, S. van (Stan)) Date: Mon, 16 Jan 2017 08:27:55 +0000 Subject: [FieldTrip] i need help In-Reply-To: <1609558455.3967220.1484554082497@mail.yahoo.com> References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> <1609558455.3967220.1484554082497@mail.yahoo.com> Message-ID: <7CCA2706D7A4DA45931A892DF3C2894C521E1517@exprd03.hosting.ru.nl> Dear Mohamed, Fieldtrip is not stand-alone software, but a toolbox for Matlab. As such, it is platform-independent, but requires you to have a (Windows/Mac/Linux version of) Matlab installed on your computer. FieldTrip is freeware, but Matlab requires a license. Best, Stan -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour Radboud University Montessorilaan 3, B.01.34 6525 HR Nijmegen, the Netherlands tel: +31 24 3616288 From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Mohamed Fawzy Sent: maandag 16 januari 2017 9:08 To: fieldtrip at science.ru.nl Subject: [FieldTrip] i need help hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing, Faculty of Computers and Informatics, Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14 Mobile:00201220577416 Tel:0020133188266 Fax:0020133188256 E-mail: mohamed.issa at fci.bu.edu.eg , mfibm at yahoo.com, -------------- next part -------------- An HTML attachment was scrubbed... URL: From litvak.vladimir at gmail.com Mon Jan 16 11:36:11 2017 From: litvak.vladimir at gmail.com (Vladimir Litvak) Date: Mon, 16 Jan 2017 10:36:11 +0000 Subject: [FieldTrip] post-doc for cryogen-free MEG system Message-ID: ---------- Forwarded message ---------- From: Barnes, Gareth Date: Mon, Jan 16, 2017 at 9:22 AM Subject: [SPM] post-doc for cryogen-free MEG system To: SPM at jiscmail.ac.uk Dear All We’re looking for someone to join our team working on the development of a new cryogen-free MEG system (see below). Could you please pass this on to anyone who might be interested. Best Gareth UCL link: https://atsv7.wcn.co.uk/search_engine/jobs.cgi?SID= amNvZGU9MTYyMzE0MiZ2dF90ZW1wbGF0ZT05NjUmb3duZXI9NTA0MTE3OCZv d25lcnR5cGU9ZmFpciZicmFuZF9pZD0wJnZhY194dHJhNTA0MTE3OC41MF81 MDQxMTc4PTkyNzg2JnZhY3R5cGU9MTI3NiZwb3N0aW5nX2NvZGU9MjI0JnJl cXNpZz0xNDg0NTU3MjM5LWFlMGZlZDk2OTk2MDUyNjAwM2NiNTRlODM0MmEzMWE0YTA0NmY1ZDY= Research Associate , - Ref:1623142 *UCL Department / Division* UCL Institute of Neurology *Specific unit / Sub department* Wellcome Trust Centre for Neuroimaging *Grade* 7 *Hours* Full Time *Salary (inclusive of London allowance)* £34,056 - £36,923 per annum *Duties and Responsibilities* The Wellcome Trust Centre for Neuroimaging, UCL Institute of Neurology, is seeking to recruit a post-doctoral research fellow in the field of magnetoencephalography (MEG). This is part of a Wellcome-funded programme, in collaboration with the University of Nottingham, to develop a new generation of MEG system based on a optically pumped magnetometers (OPMs). Optically pumped magnetometers are ultra-sensitive magnetic field detectors which can operate at room temperature, and so can be brought closer to the head than the cryogenically-cooled field detectors that are currently used in MEG imaging. The aim is to build a multi-channel OPM MEG device which can be worn on the head allowing the subject to move freely in an open and natural environment. The prospect of an affordable and wearable system has a number of exciting applications including novel paediatric and clinical imaging systems. The post is available from 1st April 2017 and is funded by a grant from the Wellcome Trust for three years in the first instance. *Key Requirements* Applicants should have a PhD in Neuroscience or related area and strong proven expertise in physics / engineering or related discipline. Strong expertise in programming, ideally Matlab, is essential, as is an excellent academic record with evidence of independent, creative work, a strong mathematical background, expertise in modelling / simulation and experience in M/EEG. It would also be desirable to have experience with one or more M/EEG software packages and the use of different volume conductor models. *Further Details* A job description and person specification can be accessed at the bottom of this page. To apply for the vacancy please click on the ‘Apply Now’ button below. If you have any queries regarding the application process, please contact Samantha Robinson, HR Officer, UCL Institute of Neurology - *IoN.HRAdmin at ucl.ac.uk* For informal enquiries please contact Gareth Barnes (*g.barnes at ucl.ac.uk* ) *UCL Taking Action for Equality* *Closing Date* 12 Feb 2017 *Our department holds an Athena SWAN Silver award, in recognition of our commitment and success in addressing gender equality.* *This appointment is subject to UCL Terms and Conditions of Service for Research and Support Staff. Please use these links to find out more about the UCL Terms and Conditions related to this job, employee benefits that we offer and further information about UCL .* *JD and Person Specification* -------------- next part -------------- An HTML attachment was scrubbed... URL: From Darren.Price at mrc-cbu.cam.ac.uk Mon Jan 16 11:47:57 2017 From: Darren.Price at mrc-cbu.cam.ac.uk (Darren Price) Date: Mon, 16 Jan 2017 10:47:57 +0000 Subject: [FieldTrip] i need help In-Reply-To: <1609558455.3967220.1484554082497@mail.yahoo.com> References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> <1609558455.3967220.1484554082497@mail.yahoo.com> Message-ID: Hi You may need to recompile the mex files if you want to use more than 2GB of RAM. http://www.fieldtriptoolbox.org/faq/how_can_i_compile_the_mex_files_on_64_bit_windows You could also use something like VMware player to create a virtual operating system within windows. However, you would need a powerful computer with lots of spare RAM and CPUs cores for this option as it tends to be much slower. Another obvious solution is to dual boot your computer with Linux, but that’s not really what you’re asking is it? Is there a specific reason you would like to use Windows? Darren ------------------------------------------------------- Dr. Darren Price Investigator Scientist and Cam-CAN Data Manager MRC Cognition & Brain Sciences Unit 15 Chaucer Road Cambridge, CB2 7EF England EMAIL: darren.price at mrc-cbu.cam.ac.uk URL: http://www.mrc-cbu.cam.ac.uk/people/darren.price TEL +44 (0)1223 355 294 x202 FAX +44 (0)1223 359 062 MOB +44 (0)7717822431 ------------------------------------------------------- From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Mohamed Fawzy Sent: 16 January 2017 08:08 To: fieldtrip at science.ru.nl Subject: [FieldTrip] i need help hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing, Faculty of Computers and Informatics, Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14 Mobile:00201220577416 Tel:0020133188266 Fax:0020133188256 E-mail: mohamed.issa at fci.bu.edu.eg , mfibm at yahoo.com, -------------- next part -------------- An HTML attachment was scrubbed... URL: From giskeopheim at nru.dk Tue Jan 17 15:59:48 2017 From: giskeopheim at nru.dk (giskeopheim) Date: Tue, 17 Jan 2017 15:59:48 +0100 Subject: [FieldTrip] Fwd: Wavelet-transform based SAM beamforming In-Reply-To: <03f6d3b27e0a09a36897a8a82b7127b4@nru.dk> References: <03f6d3b27e0a09a36897a8a82b7127b4@nru.dk> Message-ID: Dear fieldtrip experts, I hope it is okay to ask a more general "pipeline" question, instead of one specifically related to some issue with code, since I do not know anyone who has experience with it. Is there currently any way to perform wavelet-based SAM beamforming with fieldtrip? I'm thinking something like 'cfg.wavelet' = 'yes' during preprocessing.., or, by all means, a way to convert output from transform functions to desired structs to use in both averaging and analysis functions? Transforming with ft_specest_wavelet to get the convolution in the time domain, gives a 'chan X freqoi X timeoi complex double', which of course is not the struct neccessary for performing the beamforming. Using the ft_freqanalysis with cfg.method = 'wavelet' does not give time domain output neccessary for SAM method, since it does a multiplication with the frequencies. I am working on a project where I want to build something crudely comparable to the algorithms used in the MEG Processor software up until its accumulated spectrograms (assuming you are familiar), but am facing the obvious problems mentioned above. I am of course open to the possibility of me misunderstanding of something essential, but I send this email in hope of getting some input even if that's the case.. Best regards, Giske (graduate student) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 11:57:11 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 11:57:11 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed Message-ID: Hi there, I was wondering if anyone could provide some advice on the specifics of calculating coherence on planar gradiometers (Elekta Neuromag system). In short I would like to calculate coherence between an average of several sensor based on the topography of the power (a seed virtual channel if you want), and all the MEG sensors. I would rather deal with combined gradiometers when in the spectral domain, given that those give me a clear and consistent topography within and between subjects. However, I can imagine combining gradiometers at different stages of the analysis: 1) Combine gradiometers on the timecourse data before spectral analysis. 2) Combine gradiometers after the spectral analysis, but before the coherence analysis. 3) Combine gradiometers after the coherence analysis. Option 2 has the advantage of staying in the same topographical representation in the spectral power estimates (to determine sensors) as well as in the coherence, making it easier to compare topographies of power and coherence. However, this does not allow me to use a 'pre-computed' average, i.e. virtual channel, of several *combined *gradiometers as the seed, since those are specified already in spectral estimate (ft_freqanalysis using fourier or fft). A solution for this might be to determine the seed based on combined gradiometers, then 'cut up' those channel labels into their original gradiometer labels, and use those(uncombined) gradiometers as the seeds in ft_freqanalysis. After the spectral analysis I can then first combine the gradiometers, then average the different seed channels, before and calculate the coherence with those as the seed. Does this sound valid to you people? I would like to check with you people if there are any concerns doing this. There might also be a simpler way doing it... As far as I am aware, there is no FieldTrip tutorial or FAQ where coherence analysis is applied to Neuromag data, so I hope this might also help other people. Regards, Stephen p.s. I am probably using the word 'seed' wrong here - feel free to update my nomenclature :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 12:43:44 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 12:43:44 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed In-Reply-To: References: Message-ID: Hi there, It seems I might be able to solve it using the fourier method in ft_freqanalysis, after which I can select and combine gradiometers and feed those into ft_connectivityanalysis. Thanks for your time, Stephen On 18 January 2017 at 11:57, Stephen Whitmarsh wrote: > Hi there, > > I was wondering if anyone could provide some advice on the specifics of > calculating coherence on planar gradiometers (Elekta Neuromag system). In > short I would like to calculate coherence between an average of several > sensor based on the topography of the power (a seed virtual channel if you > want), and all the MEG sensors. > > I would rather deal with combined gradiometers when in the spectral > domain, given that those give me a clear and consistent topography within > and between subjects. However, I can imagine combining gradiometers at > different stages of the analysis: > > 1) Combine gradiometers on the timecourse data before spectral analysis. > 2) Combine gradiometers after the spectral analysis, but before the > coherence analysis. > 3) Combine gradiometers after the coherence analysis. > > Option 2 has the advantage of staying in the same topographical > representation in the spectral power estimates (to determine sensors) as > well as in the coherence, making it easier to compare topographies of power > and coherence. However, this does not allow me to use a 'pre-computed' > average, i.e. virtual channel, of several *combined *gradiometers as the > seed, since those are specified already in spectral estimate > (ft_freqanalysis using fourier or fft). > > A solution for this might be to determine the seed based on combined > gradiometers, then 'cut up' those channel labels into their original > gradiometer labels, and use those(uncombined) gradiometers as the seeds in > ft_freqanalysis. After the spectral analysis I can then first combine the > gradiometers, then average the different seed channels, before and > calculate the coherence with those as the seed. > > Does this sound valid to you people? I would like to check with you people > if there are any concerns doing this. There might also be a simpler way > doing it... > > As far as I am aware, there is no FieldTrip tutorial or FAQ where > coherence analysis is applied to Neuromag data, so I hope this might also > help other people. > > Regards, > Stephen > > p.s. I am probably using the word 'seed' wrong here - feel free to update > my nomenclature :-) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 13:47:54 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 13:47:54 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed In-Reply-To: References: Message-ID: Hi there, Oops, no that does not fly either. Best, Stephen On 18 January 2017 at 12:43, Stephen Whitmarsh wrote: > Hi there, > > It seems I might be able to solve it using the fourier method in > ft_freqanalysis, after which I can select and combine gradiometers and feed > those into ft_connectivityanalysis. > > Thanks for your time, > Stephen > > On 18 January 2017 at 11:57, Stephen Whitmarsh < > stephen.whitmarsh at gmail.com> wrote: > >> Hi there, >> >> I was wondering if anyone could provide some advice on the specifics of >> calculating coherence on planar gradiometers (Elekta Neuromag system). In >> short I would like to calculate coherence between an average of several >> sensor based on the topography of the power (a seed virtual channel if you >> want), and all the MEG sensors. >> >> I would rather deal with combined gradiometers when in the spectral >> domain, given that those give me a clear and consistent topography within >> and between subjects. However, I can imagine combining gradiometers at >> different stages of the analysis: >> >> 1) Combine gradiometers on the timecourse data before spectral analysis. >> 2) Combine gradiometers after the spectral analysis, but before the >> coherence analysis. >> 3) Combine gradiometers after the coherence analysis. >> >> Option 2 has the advantage of staying in the same topographical >> representation in the spectral power estimates (to determine sensors) as >> well as in the coherence, making it easier to compare topographies of power >> and coherence. However, this does not allow me to use a 'pre-computed' >> average, i.e. virtual channel, of several *combined *gradiometers as the >> seed, since those are specified already in spectral estimate >> (ft_freqanalysis using fourier or fft). >> >> A solution for this might be to determine the seed based on combined >> gradiometers, then 'cut up' those channel labels into their original >> gradiometer labels, and use those(uncombined) gradiometers as the seeds in >> ft_freqanalysis. After the spectral analysis I can then first combine the >> gradiometers, then average the different seed channels, before and >> calculate the coherence with those as the seed. >> >> Does this sound valid to you people? I would like to check with you >> people if there are any concerns doing this. There might also be a simpler >> way doing it... >> >> As far as I am aware, there is no FieldTrip tutorial or FAQ where >> coherence analysis is applied to Neuromag data, so I hope this might also >> help other people. >> >> Regards, >> Stephen >> >> p.s. I am probably using the word 'seed' wrong here - feel free to update >> my nomenclature :-) >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.hauswald at me.com Wed Jan 18 13:57:03 2017 From: anne.hauswald at me.com (anne Hauswald) Date: Wed, 18 Jan 2017 13:57:03 +0100 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> Message-ID: <5B0FF59B-A01B-4559-A085-F5F2DDDF80D0@me.com> Hi Mona, as said, the layout files are mainly meant for 2-d plotting. Here http://www.fieldtriptoolbox.org/template/layout under „Neuromag array“ you find specifics for the different files. - neuromag306all.lay includes all 306 sensors - neuromag306mag.lay includes all 102 magnetometers - neuromag306cmb.lay includes 102 positions of 204 combined gradiometers (two at each position) - neuromag306planar.lay includes 204 positions of all planar gradiometers - neuromag306eeg1005_natmeg.lay includes 128 EEG positions Basically, with the Neuromag system you have 102 sensor elements with three sensors each (1 magnetometer and two orthogonal planar gradiometers). Hoper that helps Best Anne > > I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay > Am 13.01.2017 um 19:20 schrieb Wong-Barnum, Mona : > > > Hi Anne: > > Thank you so much for your reply. > >> generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. > > Is there an explanation of the 5 different neuromag layout files? I have the following: > > neuromag306all.lay neuromag306eeg1005_natmeg.lay neuromag306planar.lay > neuromag306cmb.lay neuromag306mag.lay > > I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay files are for. > > I found http://www.fieldtriptoolbox.org/tutorial/layout page but if there is anything that’s useful, please point me to it. > > thanks, > Mona > > ********************************************* > Mona Wong > Web & Mobile Application Developer > San Diego Supercomputer Center > > "Believe you can and you are half > way there." > -- Theodore Roosevelt > ********************************************* > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From tmadsen at emory.edu Wed Jan 18 16:41:58 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Wed, 18 Jan 2017 10:41:58 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Thanks for the additional feedback, Mike and Matt. I agree that the skewness of the power distribution is "trivial" in that it is skewed *by definition* as a squared value, but you're right that my concern is whether it has a nontrivial impact on the analysis of real data. I do intend to do further simulations to test this and various potential solutions, but I need to get another paper submitted first. I will report my findings back to this listserv when possible. Thanks again, Teresa On Fri, Jan 13, 2017 at 9:51 AM, Matt Craddock wrote: > Hi all, > > I'm fiddling around with simulations at the moment but not got a lot of > free time, and every time I do fiddle with them the more complicated I seem > to make them... > > correct me if i'm wrong, but there are a couple of different issues here. > > About the skewness of the distribution - you're not usually comparing two > skewed distributions statistically (which even then would probably be ok if > they're similary skewed), usually it's a bunch of means from those > distributions, and the distribution of the means will often be normally > distributed (as will their differences), and thus ok for parametric stats. > So the main problem is really whether the mean is a good summary statistic > for capturing differences between the underlying distributions or not > (similar debates about reaction times) - it's certainly not robust to > outliers. Median might be better in some ways, but it's a biased estimator > of the population median and might have consequences on stat power - that's > one for the simulations at some point. > > Taking the log first won't necessarily help. As the code Michael Cohen > provides shows, taking the log can still result in skewed distributions - > power is right-skewed but its log is left-skewed. Taking the square root > would obviously be better in this case but that's because it just returns > it to the original unsquared normal distribution - whether that's true of > real data needs checking out. In addition if you take the log you're no > longer testing the same thing when you compare the means - you're testing > the geometric mean instead of the arithmetic mean. Differences in the > arithmetic means across conditions will not necessarily translate into > differences in the geometric means and vice versa. > > If you use a subtractive baseline, using the median or mean of power will > only change what constant you subtract from the data. If you baseline > correct using the average of all trials rather than condition specific > baselines, it should make no difference to the stats if you use the mean or > the median of baseline power (or indeed if you don't use baseline > correction at all). If you test differences across electrodes as well as > condition, and use electrode but not condition specific baselines - which > seems reasonable, since you might expect bigger baseline differences across > than within electrodes, it'll only change the main electrode effect, not > the condition effect or the interaction between condition and electrode. If > you use condition and electrode specific baselines, then it influences > *everything*, and you also no longer know if the differences between > conditions/electrodes are due to baseline or post-stimulus differences. > > Using the median over the mean will change the stats if you use divisive > baselines, but whether that's a good or bad difference is another question > for simulations. > > Cheers, > Matt > > > On 12/01/2017 13:37, Mike X Cohen wrote: > >> Interesting discussion here. I think we should take a step back and >> distinguish between trivial and nontrivial causes and consequences for >> the skewed distribution. To some extent, the non-normal distribution is >> simply the result of defining power as a squared distance -- distances >> are always positive and squaring them means big values become really >> big. Consider the following: >> >> d = randn(10000,1); % random numbers >> subplot(311), hist(d,500); % their distribution >> subplot(312), hist(d.^2,500); % "power" distribution, also try a >> log-scaled y-axis >> subplot(313), hist(log(d.^2),500); % log-power distribution >> >> The fact that power values have a power-law-like distribution is >> therefore trivial. >> >> But this leads to two non-trivial questions: >> 1) Is this distribution meaningful for brain function (beyond simply the >> result of taking squared values)? People who study "the log-brain" and >> fractal-like (or scale-free) organization of brain function would argue >> that these distributions reveal meaningful insights into brain function, >> and therefore it is not really an artifact for analyses. In other words, >> large values are large for a reason; they might not be outliers that we >> should attempt to compress. >> >> 2) Does it matter for real data analysis? I think this is Teresa's >> initial concern. I'm inclined to think that it doesn't really matter, >> but that's just based on the idea (hope!) that if it did really matter >> and the way we do it is wrong, the field would have discovered this a >> long time ago. On the other hand, this wouldn't be the first time that >> people have gotten things wrong for decades. >> >> I think the best way to investigate #2 would be with simulated data, >> showing that a "true" effect is missed when not first computing >> log-power, presumably because the effect was overshadowed by >> large-amplitude "noise" (but somehow this would have to be physiological >> noise that wouldn't get rejected during data cleaning). In empirical >> data, all you'd be able to do is show a difference without knowing the >> right answer. >> >> btw, make sure to be careful with baselining log-power -- any divisions >> (e.g., dB or percent change) will be unstable/run off to infinity when >> baseline power is close to zero, i.e., raw power is close to 1. The sign >> might also get weird. Probably best to use a baseline subtraction. >> >> Mike >> >> >> >> >> >> --------------------------------------------><-------------- >> ---------------------------------- >> >> Thanks for the reference. In return, I also recommend reading Ciuparu and >> Mures an's recent rebuttal: >> >> European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, >> doi:10.1111/ejn.13179 >> TECHNICAL SPOTLIGHT >> Sources of bias in single-trial normalization procedures >> >> They demonstrate that the positive bias Grandchamp and Delorme warned >> about >> with single-trial baseline normalization was, in fact, due to the >> correlated numerators and denominators in each of the baseline >> normalization procedures they tested, which was, in turn, caused by the >> skewed distributions of baseline power values. They demonstrate that this >> bias is reduced by using a much longer baseline, ideally incorporated into >> the experimental design, but when that's not possible, stitching together >> the baselines of many trials. >> >> Neither article addresses my specific question of whether it would be even >> better to log-transform the raw power values before averaging, so I >> suppose >> I'll have to test it myself and write my own methods article! 🤓 >> >> I will go ahead and incorporate some of these alternative baseline >> normalization methods in my git fork of FieldTrip as I go along with my >> own >> analyses, so let me know if anyone else would find them useful, and I'll >> submit a pull request to contribute them to the master branch. >> >> Thanks for the fruitful discussion, all! >> ~Teresa >> >> >> On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge > > wrote: >> >> Indeed, in a separate thread with Michael Cohen several months back he >>> suggested precisely that paper. >>> >>> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" >> >> gmail.com > >> >>> wrote: >>> >>> I think this paper is relevant to this discussion. >>>> >>>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy >>>> >>> Trials. *Frontiers >> >>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>>> >>>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>>> >>>> >>>> >>>> On 19 December 2016 at 13:08, Teresa Madsen >>> >>> > wrote: >> >>> >>>> I appreciate everyone's feedback, but I still wonder if something is >>>>> being missed. I understand that the non-normally distributed power >>>>> >>>> values >> >>> may be less of an issue when performing non-parametric stats or even a >>>>> paired-samples t-test that looks at difference values which may be >>>>> >>>> normal >> >>> even when the raw data isn't. However, my concern comes into play even >>>>> before these statistical comparisons are made, whenever any averaging >>>>> is >>>>> done to freq-type data across times, frequencies, trials, electrodes, >>>>> subjects, etc. That means any time any of these configuration >>>>> >>>> options are >> >>> used for any of these functions, and probably more: >>>>> >>>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>>> cfg.avgoverfreq = 'yes'; >>>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>>> >>>>> In each case, if raw power values are averaged, the result will be >>>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>>> treated identically, but the specific case that triggered my concern >>>>> >>>> was in >> >>> ft_freqbaseline, where the individual time-frequency bins are >>>>> >>>> compared to >> >>> the mean over time for the baseline period. For example, when using >>>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output >>>>> >>>> freq >> >>> data does indeed have a more normal distribution over time, but the mean >>>>> over the baseline time period is performed *before* the log >>>>> >>>> transform, when >> >>> the distribution is still highly skewed: >>>>> >>>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>>> size(data, 3)]); >>>>> data = 10*log10(data ./ meanVals); >>>>> >>>>> That's what I had originally done when analyzing data for my SfN >>>>> poster, >>>>> when I realized the background noise that shouldn't have changed >>>>> >>>> much from >> >>> baseline was mostly showing a decrease from baseline of about -3dB. >>>>> >>>>> Now, I've realized I'm seeing this as more of a problem than others >>>>> because of another tweak I made, which was to use a long, separate >>>>> >>>> baseline >> >>> recording to normalize my trial data, rather than a short pre-trial >>>>> >>>> period >> >>> as ft_freqbaseline is designed to do. Averaging a few hundred >>>>> >>>> milliseconds >> >>> for a baseline power estimate might be okay because overlapping time >>>>> >>>> points >> >>> in the original data are used to calculate those power values anyway, >>>>> probably making them less skewed, but also (it seems to me) more >>>>> >>>> arbitrary >> >>> and prone to error. I already offered my custom function BLnorm.m >>>>> >>>> to one >> >>> person who was asking about this issue of normalizing to a separate >>>>> baseline recording, and I would be happy to contribute it to >>>>> >>>> FieldTrip if >> >>> others would appreciate it. >>>>> >>>>> Since a few people suggested using the median, and it is also suggested >>>>> in Cohen's textbook >>>>> as >>>>> an alternative measure of the central tendency for skewed raw power >>>>> >>>> values, >> >>> I wonder if the simplest fix might be to add an option to select mean or >>>>> median in each of the functions listed above. Another possibility >>>>> >>>> would be >> >>> adding an option to transform the power values upon output from >>>>> ft_freqanalysis. >>>>> >>>>> Would anyone else find such changes useful? >>>>> >>>>> Thanks, >>>>> Teresa >>>>> >>>>> >>>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>>> J.Herring at donders.ru.nl > wrote: >>>>> >>>>> In terms of statistics it is the distribution of values that you do the >>>>>> statistics on that matters. In case of a paired-samples t-test when >>>>>> comparing two conditions, it is the distribution of difference >>>>>> >>>>> values that >> >>> has to be normally distributed. The distribution of difference >>>>>> >>>>> values is >> >>> often normal given two similarly non-normal distributions, offering no >>>>>> complications for a regular parametric test. >>>>>> >>>>>> >>>>>> >>>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>>> normality, so you should have no problem there either. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* fieldtrip-bounces at science.ru.nl >>>>>> >>>>> [mailto:fieldtrip-bounces at scie >> >>> nce.ru.nl ] *On Behalf Of *Alik Widge >>>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>>> *To:* FieldTrip discussion list >>>>> >>>>> > >> >>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>>> data analysis >>>>>> >>>>>> >>>>>> >>>>>> In this, Teresa is right and we have observed this in our own EEG data >>>>>> -- depending on one's level of noise and number of trials/patients, >>>>>> the >>>>>> mean can be a very poor estimator of central tendency. My students are >>>>>> still arguing about what we really want to do with it, but at least >>>>>> >>>>> one of >> >>> them has shifted to using the median as a matter of course for baseline >>>>>> normalization. >>>>>> >>>>>> >>>>>> Alik Widge >>>>>> alik.widge at gmail.com >>>>>> (206) 866-5435 >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>>> >>>>> emory.edu > >> >>> wrote: >>>>>> >>>>>> That may very well be true; to be honest, I haven't looked that deeply >>>>>> into the stats offerings yet. However, my plan is to express each >>>>>> electrode's experimental data in terms of change from their respective >>>>>> baseline recordings before attempting any group averaging or >>>>>> >>>>> statistical >> >>> testing, and this problem shows up first in the baseline correction >>>>>> >>>>> step, >> >>> where FieldTrip averages raw power over time. >>>>>> >>>>>> ~Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com > wrote: >>>>>> >>>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>>> statistics implemented by fieldtrip, the data does not need to be >>>>>> >>>>> normally >> >>> distributed. >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 13:39, Teresa Madsen >>>>> >>>>> > wrote: >> >>> >>>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>>> opportunity to clarify. Of course everyone is familiar with the 1/f >>>>>> >>>>> pattern >> >>> across frequencies, but the distribution across time (and according >>>>>> >>>>> to the >> >>> poster, also across space), also has an extremely skewed, negative >>>>>> exponential distribution. I probably confused everyone by trying to >>>>>> >>>>> show >> >>> too much data in my figure, but each color represents the >>>>>> >>>>> distribution of >> >>> power values for a single frequency over time, using a histogram >>>>>> >>>>> and a line >> >>> above with circles at the mean +/- one standard deviation. >>>>>> >>>>>> My main point was that the mean is not representative of the central >>>>>> tendency of such an asymmetrical distribution of power values over >>>>>> >>>>> time. >> >>> It's even more obvious which is more representative of their actual >>>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>>> log(mean(rawpower)) on the log plot, but that made the figure even >>>>>> more >>>>>> busy and confusing. >>>>>> >>>>>> I hope that helps, >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com > wrote: >>>>>> >>>>>> Hi Teresa, >>>>>> >>>>>> >>>>>> >>>>>> I think what you are discussing is the 1/f power scaling of the power >>>>>> spectrum. This is one of the reasons that comparisons are made within >>>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to >>>>>> >>>>> gamma), >> >>> as such the assumption is that within bands there should be a relative >>>>>> change against baseline and this is what the statistics are >>>>>> >>>>> performed on. >> >>> That is, baseline correction is assumed to be the mean for a specific >>>>>> frequency and not a mean across frequencies. >>>>>> >>>>>> >>>>>> >>>>>> And this leads to another point that when you are selecting a >>>>>> frequency range to do the non-parametric statistics on you should >>>>>> >>>>> not do >> >>> 1-64 Hz but break it up based on the bands. >>>>>> >>>>>> >>>>>> >>>>>> Hope my interpretation of your point is correct. I sent in >>>>>> individually, as I wanted to ensure I followed your point. >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 08:23, Teresa Madsen >>>>> >>>>> > wrote: >> >>> >>>>>> FieldTrippers, >>>>>> >>>>>> >>>>>> >>>>>> While analyzing my data for the annual Society for Neuroscience >>>>>> meeting, I developed a concern that was quickly validated by >>>>>> >>>>> another poster >> >>> (full abstract copied and linked below) focusing on the root of the >>>>>> problem: neural oscillatory power is not normally distributed >>>>>> >>>>> across time, >> >>> frequency, or space. The specific problem I had encountered was in >>>>>> baseline-correcting my experimental data, where, regardless of >>>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>>> However, I found that the distribution of raw power over time is so >>>>>> >>>>> skewed >> >>> that the mean was not a reasonable approximation of the central >>>>>> >>>>> tendency of >> >>> the baseline power, so it made most of my experimental data look >>>>>> >>>>> like it >> >>> had decreased power compared to baseline. The more I think about >>>>>> >>>>> it, the >> >>> more I realize that averaging is everywhere in the way we analyze >>>>>> >>>>> neural >> >>> oscillations (across time points, frequency bins, electrodes, trials, >>>>>> subjects, etc.), and many of the standard statistics people use >>>>>> >>>>> also rely >> >>> on assumptions of normality. >>>>>> >>>>>> >>>>>> >>>>>> The most obvious solution for me was to log transform the data first, >>>>>> as it appears to be fairly log normal, and I always use log-scale >>>>>> visualizations anyway. Erik Peterson, middle author on the poster, >>>>>> >>>>> agreed >> >>> that this would at least "restore (some) symmetry to the error >>>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>>> differentiate from the standard decibel transform included in >>>>>> >>>>> FieldTrip as >> >>> cfg.baselinetype = 'db'. The following figures compare the 2 >>>>>> >>>>> distributions >> >>> across several frequency bands (using power values from a wavelet >>>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>>> cortex). The lines at the top represent the mean +/- one standard >>>>>> deviation for each frequency band, and you can see how those >>>>>> >>>>> descriptive >> >>> stats are much more representative of the actual distributions in >>>>>> >>>>> the log >> >>> scale. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ​​ >>>>>> >>>>>> For my analysis, I also calculated a z-score on the log transformed >>>>>> power to assess how my experimental data compared to the >>>>>> >>>>> variability of the >> >>> noise in a long baseline recording from before conditioning, rather >>>>>> >>>>> than a >> >>> short pre-trial baseline period, since I find that more informative >>>>>> >>>>> than >> >>> any of FieldTrip's built-in baseline types. I'm happy to share the >>>>>> >>>>> custom >> >>> functions I wrote for this if people think it would be a useful >>>>>> >>>>> addition to >> >>> FieldTrip. I can also share more about my analysis and/or a copy >>>>>> >>>>> of the >> >>> poster, if anyone wants more detail - I just didn't want to make >>>>>> >>>>> this email >> >>> too big. >>>>>> >>>>>> >>>>>> >>>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>>> address this. I searched the wiki >>>>>> , listserv >>>>>> >>>>>> > mber/000773.html> >> >>> archives >>>>>> >>>>>> > h/002718.html>, >> >>> and bugzilla >>>>>> for >>>>>> anything related and came up with a few topics surrounding >>>>>> >>>>> normalization >> >>> and baseline correction, but only skirting this issue. It seems >>>>>> >>>>> important, >> >>> so I want to find out whether others agree with my approach or >>>>>> >>>>> already have >> >>> other ways of avoiding the problem, and whether FieldTrip's code >>>>>> >>>>> needs to >> >>> be changed or just documentation added, or what? >>>>>> >>>>>> >>>>>> >>>>>> Thanks for any insights, >>>>>> >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>>> across time >>>>>> >>>>>> >>>>>> *Authors* >>>>>> >>>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>>> Cognitive Sci., UCSD, San Diego, CA >>>>>> >>>>>> *Disclosures* >>>>>> >>>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>>> >>>>>> *Abstract* >>>>>> >>>>>> Neural oscillations are important in organizing activity across the >>>>>> human brain in healthy cognition, while oscillatory disruptions are >>>>>> >>>>> linked >> >>> to numerous disease states. Oscillations are known to vary by >>>>>> >>>>> frequency and >> >>> amplitude across time and between different brain regions; however, >>>>>> >>>>> this >> >>> variability has never been well characterized. We examined human >>>>>> >>>>> and animal >> >>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>>> distribution of power and frequency across time, space and species. We >>>>>> report that between data types, subjects, frequencies, electrodes, and >>>>>> time, an inverse power law, or negative exponential distribution, is >>>>>> present in all recordings. This is contrary to, and not compatible >>>>>> >>>>> with, >> >>> the Gaussian noise assumption made in many digital signal processing >>>>>> techniques. The statistical assumptions underlying common >>>>>> >>>>> algorithms for >> >>> power spectral estimation, such as Welch's method, are being violated >>>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>>> statistical approaches are warranted. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Teresa E. Madsen, PhD >>>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>>> analysis >>>>>> >>>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>>> Yerkes National Primate Research Center >>>>>> >>>>>> Emory University >>>>>> >>>>>> Rainnie Lab, NSB 5233 >>>>>> 954 Gatewood Rd. NE >>>>>> Atlanta, GA 30329 >>>>>> >>>>>> (770) 296-9119 >>>>>> >>>>>> braingirl at gmail.com >>>>>> >>>>>> https://www.linkedin.com/in/temadsen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Teresa E. Madsen, PhD >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> Emory University >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> (770) 296-9119 >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >> >> >> -- >> Teresa E. Madsen, PhD >> Division of Behavioral Neuroscience and Psychiatric Disorders >> Yerkes National Primate Research Center >> Emory University >> Rainnie Lab, NSB 5233 >> 954 Gatewood Rd. NE >> Atlanta, GA 30329 >> (770) 296-9119 >> >> -- >> Mike X Cohen, PhD >> mikexcohen.com >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.klinzing at uni-tuebingen.de Thu Jan 19 10:09:15 2017 From: jens.klinzing at uni-tuebingen.de (=?ISO-8859-1?Q?=22Jens_Klinzing=2C_Uni_T=FCbingen=22?=) Date: Thu, 19 Jan 2017 10:09:15 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> Message-ID: <5880823B.2050806@uni-tuebingen.de> Dear Elena, Question 1: I assume the reason it takes so long is that you are using a FEM-based headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - sb_transfer) every time you do a source reconstruction. For more information see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 . You can circumvent the issue by computing the transfer matrix beforehand and changing the code in a way that it doesnt compute a new transfer matrix if you have already provided one. Alternatively you could use a BEM headmodel (dipoli if possible since bemcp seems to have issues http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2817). Question 2: Did you check your segmentation, the headmodel and the coregistration of electrodes/head every step of the way? If you fill all inside voxels with 1s and plot that, do you see an obvious shift/rotation of the "activity" in relation to the MRI? Best, Jens > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' > method applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to > call one ft_sourceanalysis. Maybe, there is a way to optimise the > procedure somehow? > > Second, at the end of analysis I obtain a very strange figure, on > which I see activity localised outside the mri scan. Mistake on which > step of analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - > sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjj11033 at kaist.ac.kr Thu Jan 19 11:26:52 2017 From: kjj11033 at kaist.ac.kr (=?UTF-8?B?6rmA7J6s7KSR?=) Date: Thu, 19 Jan 2017 19:26:52 +0900 (KST) Subject: [FieldTrip] =?utf-8?q?Questions_about_probability_variation_by_se?= =?utf-8?q?tting_different_tail_of_cluster_based_permutation_test?= Message-ID: <5880960c3fb3_@_imoxion.com> Dear group, Hi I'm Jaejoong of KAIST korea First of all, thanks for such a nice toolbox I have a question with tail of cluster based permutation test I compared difference between 2 conditions with test Weird thing is, when I run test with cfg.clustertail=0; negative cluster of probability 0.038 returned, which is not significant However, when I run test with clustertail=-1 and +1 both, negative cluster of probability of 0.021 returned, which is significant if I adjust with bonferroni correction for both positive one sied test and negative one sided test In my understanding, probability of negative cluster above should be same. So my question is 1) Why does probability of same negative cluster is varied by tail of permutation test? 2) Is it reasonable to run test with clustertail=+1/-1 and apply bonferroni correction for 2 tests? I would really appreciate your comments Sincerely Jaejoong -------------- next part -------------- An HTML attachment was scrubbed... URL: From krugliakova.es at gmail.com Thu Jan 19 13:55:49 2017 From: krugliakova.es at gmail.com (Elena Krugliakova) Date: Thu, 19 Jan 2017 13:55:49 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: <5880823B.2050806@uni-tuebingen.de> References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> <5880823B.2050806@uni-tuebingen.de> Message-ID: Dear Jens, Thank you for your answer! 1. Indeed, I found where ft_sourceanalysis starts to recompute transfer matrix and just loaded precomputed headmodel and sensors. Now everything is fine, and it takes several seconds to run ft_sourceanalysis. 2. About homogeneous "noise outside the mri scan". Noise appears after I calculate difference between two sources, following tutorial http://www.fieldtriptoolbox.org/tutorial/beamformer. However, sourceplot for not-contrasted conditions looks good. Maybe you could give me an advice, how to get rid of this background noise. Kind Regards, Elena With difference calculation: cfg = []; cfg.elec = elec; cfg.headmodel = vol; cfg.grid = leadfield; cfg.keepleadfield = 'yes' cfg.projectnoise = 'yes'; cfg.frequency = [10 15]; cfg.method = 'dics'; cfg.dics.projectnoise = 'yes'; cfg.dics.lambda = '5%'; cfg.dics.keepfilter = 'yes'; cfg.dics.realfilter = 'yes'; sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); cfg.grid.filter = sourcePNandBS.avg.filter; sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); sourceBS = ft_sourceanalysis(cfg, freq_BS_Post); *sourceDiff.avg.pow = (sourcePN.avg.pow - sourceBS.avg.pow) ./ sourceBS.avg.pow;* cfg = []; cfg.parameter = 'avg.pow'; sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); cfg = []; sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg, sourceDiffIntNorm); figure [image: Inline images 1] Without difference calculation: cfg = []; cfg.elec = elec; .......... sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); cfg.grid.filter = sourcePNandBS.avg.filter; sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); sourcePN.avg.pow = sourcePN.avg.pow ./ sourcePN.avg.noise; cfg = []; cfg.parameter = 'avg.pow'; sourcePN = ft_sourceinterpolate(cfg, sourcePN, mri); cfg = []; sourcePNIntNorm = ft_volumenormalise(cfg, sourcePNInt); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg, sourcePNIntNorm); figure [image: Inline images 2] On 19 January 2017 at 10:09, "Jens Klinzing, Uni Tübingen" < jens.klinzing at uni-tuebingen.de> wrote: > Dear Elena, > > Question 1: > I assume the reason it takes so long is that you are using a FEM-based > headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix > on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - > sb_transfer) every time you do a source reconstruction. For more > information see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 > . > > You can circumvent the issue by computing the transfer matrix beforehand > and changing the code in a way that it doesnt compute a new transfer matrix > if you have already provided one. > > Alternatively you could use a BEM headmodel (dipoli if possible since > bemcp seems to have issues http://bugzilla.fieldtriptoolbox.org/show_bug. > cgi?id=2817). > > Question 2: > Did you check your segmentation, the headmodel and the coregistration of > electrodes/head every step of the way? If you fill all inside voxels with > 1s and plot that, do you see an obvious shift/rotation of the "activity" in > relation to the MRI? > > Best, > Jens > > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' method > applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to call > one ft_sourceanalysis. Maybe, there is a way to optimise the procedure > somehow? > > Second, at the end of analysis I obtain a very strange figure, on which I > see activity localised outside the mri scan. Mistake on which step of > analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - sourcePre_con.avg.pow) > ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 144484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165407 bytes Desc: not available URL: From mehdy.dousty at gmail.com Fri Jan 20 01:05:06 2017 From: mehdy.dousty at gmail.com (mehdy dousty) Date: Fri, 20 Jan 2017 00:05:06 +0000 Subject: [FieldTrip] Extracting Default mode network from AAL Message-ID: Hello all, I am working on source localization based on the Inverse problem of MEG Human Connectome project. I used eLoreta to investigate the sources in the brain, and the results are projected to MNI 116, AAL116, I would like to know how I can identify the different networks such as DMN? Thanks Mehdy -------------- next part -------------- An HTML attachment was scrubbed... URL: From seymourr at aston.ac.uk Fri Jan 20 10:29:36 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Fri, 20 Jan 2017 09:29:36 +0000 Subject: [FieldTrip] [HCP-Users] Extracting Default mode network from AAL In-Reply-To: References: Message-ID: Hi Mehdy, I believe the AAL atlas came before the DMN and other large-scale brain networks were popular in neuroimaging, so there's no easy 1:1 mapping between them. Perhaps you could download the Yeo 7/17 network parcellations, overlay the AAL atlas points and see which ROIs overlap with the DMN? Otherwise you could repeat your analysis using a more up-to-date atlas such as the HCP MMP (https://balsa.wustl.edu/WN56)... Robert ________________________________ From: hcp-users-bounces at humanconnectome.org on behalf of mehdy dousty Sent: 20 January 2017 00:05:06 To: FieldTrip discussion list; hcp-users at humanconnectome.org Subject: [HCP-Users] Extracting Default mode network from AAL Hello all, I am working on source localization based on the Inverse problem of MEG Human Connectome project. I used eLoreta to investigate the sources in the brain, and the results are projected to MNI 116, AAL116, I would like to know how I can identify the different networks such as DMN? Thanks Mehdy _______________________________________________ HCP-Users mailing list HCP-Users at humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehdy.dousty at gmail.com Sun Jan 22 05:31:49 2017 From: mehdy.dousty at gmail.com (mehdy dousty) Date: Sun, 22 Jan 2017 04:31:49 +0000 Subject: [FieldTrip] HCP MEG SOURCE TO DMN Message-ID: Hi all, Firstly I give my special thanks to fieldtrip and human connectome project discussion list. Secondly, I have a question which needs the expert's attentions. I am using MEG resting state in HCP, and I would like to project the data to some atlases to extract DMN network. Since the AAL 116 does not give me the aforementioned network, and it is not clear from HCP instruction how to interpolate the computed grid points to other atlases, there is 1:1 interpolation between AAL and calculated source points, I am sending the email to help me through the issue. Thanks Mehdy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Horn at charite.de Sun Jan 22 14:50:43 2017 From: Andreas.Horn at charite.de (Horn, Andreas) Date: Sun, 22 Jan 2017 13:50:43 +0000 Subject: [FieldTrip] HCP MEG SOURCE TO DMN In-Reply-To: References: Message-ID: Hi Mehdy, There are two reference masks of the DMM being deployed within the GIFT ICA toolbox - they are potentially a bit old but should work for the purpose. Also, for a list of available whole-brain parcellation atlases (I.e. AAL alternatives, see http://www.lead-dbs.org/?page_id=1004). Best, Andy Am 21.01.2017 um 23:33 schrieb mehdy dousty >: Hi all, Firstly I give my special thanks to fieldtrip and human connectome project discussion list. Secondly, I have a question which needs the expert's attentions. I am using MEG resting state in HCP, and I would like to project the data to some atlases to extract DMN network. Since the AAL 116 does not give me the aforementioned network, and it is not clear from HCP instruction how to interpolate the computed grid points to other atlases, there is 1:1 interpolation between AAL and calculated source points, I am sending the email to help me through the issue. Thanks Mehdy _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.wilson at med.einstein.yu.edu Mon Jan 23 22:00:10 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Mon, 23 Jan 2017 21:00:10 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel Message-ID: Hi all, I'm working with EEG data and I'm trying to get some basic source fitting up and running. Unfortunately, I don't have individual subject MRIs, so I'm using the templates provided by fieldtrip. I've co-registered my 160 Biosemi electrodes to the standard_bem template (see attached picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid (picture attached, overlaid on standard_bem). I can prepare the leadfield from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. To test this configuration, I've selected a time window in my data and averaged across it (the covariance matrix was also calculated); the topography of this averaged data is attached. I then attempted a source fit with the LCMV beamformer: cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); After interpolating to the single_subj_T1.nii provided with ft_sourceinterpolate and plotting with ft_sourceplot, I am given a sourceplot that is highly focal in nature (see attached picture). I'd find it very surprising if this topography were generated primarily by a source that isn't even inside the brain (as the sourceplot indicates). So, I'm not sure exactly where/how I'm going wrong with this one, nor am I sure how to trouble shoot it. Any guidance you might provide would be greatly appreciated. Thanks so much, Tommy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Grid.PNG Type: image/png Size: 42603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Electrode localization.PNG Type: image/png Size: 94200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Source.PNG Type: image/png Size: 134694 bytes Desc: not available URL: From singht at musc.edu Tue Jan 24 02:43:10 2017 From: singht at musc.edu (Singh, Tarkeshwar) Date: Tue, 24 Jan 2017 01:43:10 +0000 Subject: [FieldTrip] FEM volume conduction model for stroke survivors Message-ID: <6B351597-5A9A-4027-8DA5-A7AD7D9E88D2@musc.edu> Dear Fieldtrip Community, Has anyone tried developing an FEM volume conduction model for stroke survivors (http://www.fieldtriptoolbox.org/tutorial/headmodel_eeg_fem). I was wondering, how have you modeled the lesioned volume? Have you modeled it as CSF, and if so, how did you do that? I used the code shown below and it appears to me that the lesions are not getting modeled as CSF; they appear to be modeled as scalp and skull. cfg = []; cfg.output = {'gray','white','csf','skull','scalp'}; segmentedmri = ft_volumesegment(cfg, mri); seg_i = ft_datatype_segmentation(segmentedmri,'segmentationstyle','indexed'); Any help would be sincerely appreciated. Regards, Tarkesh -- Tarkeshwar Singh Postdoctoral Scholar Department of Health Sciences and Research Medical University of South Carolina 77 President Street, Room C305 Charleston, SC 29425 singht at musc.edu ------------------------------------------------------------------------- This message was secured via TLS by MUSC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.keil at gmail.com Tue Jan 24 09:40:06 2017 From: julian.keil at gmail.com (Julian Keil) Date: Tue, 24 Jan 2017 09:40:06 +0100 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: Message-ID: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Hi Tommy, did you do some sort of contrast (e.g. with the noise estimate or a baseline) after your source analysis? Right now, it's not clear what you are looking at. Could you paste your code not only of the sourceanalysis, but the rest after which got you to the plot? It might also be the case that the automatic scaling in the source plot throws you off - maybe try setting it by hand. Good luck, Julian Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > Hi all, > > I'm working with EEG data and I'm trying to get some basic source fitting up and running. Unfortunately, I don't have individual subject MRIs, so I'm using the templates provided by fieldtrip. I've co-registered my 160 Biosemi electrodes to the standard_bem template (see attached picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid (picture attached, overlaid on standard_bem). I can prepare the leadfield from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. > > To test this configuration, I've selected a time window in my data and averaged across it (the covariance matrix was also calculated); the topography of this averaged data is attached. I then attempted a source fit with the LCMV beamformer: > > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > > After interpolating to the single_subj_T1.nii provided with ft_sourceinterpolate and plotting with ft_sourceplot, I am given a sourceplot that is highly focal in nature (see attached picture). > > I'd find it very surprising if this topography were generated primarily by a source that isn't even inside the brain (as the sourceplot indicates). So, I'm not sure exactly where/how I'm going wrong with this one, nor am I sure how to trouble shoot it. Any guidance you might provide would be greatly appreciated. > > Thanks so much, > > Tommy > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From michak at is.umk.pl Tue Jan 24 15:21:17 2017 From: michak at is.umk.pl (=?UTF-8?Q?Micha=C5=82_Komorowski?=) Date: Tue, 24 Jan 2017 15:21:17 +0100 Subject: [FieldTrip] Source statistic issue - between trials Message-ID: Dear community, Currently I am working on source analysis from EEG data. I have some trouble using ft_sourcestatistics do a between-trials analysis (single subject). I am trying to compare source from trials from task type A (ctrl) to with trials from task type B (task). Mainly I rely on http://www.fieldtriptoolbox.org/example/source_statistics . For almost week I am trying find a solution, inculding testing ft_sourcestatistics with different combinations of data: 1) source 1 : no ft_sourcedescriptives and no ft_sourceinterpolate used 2) source 2 : used ft_sourcedescriptives and no ft_sourceinterpolate used 3) source 3 : used ft_sourcedescriptives and used ft_sourceinterpolate For cases 1) and 2) I get very similar errors "Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering" (full error messages at the bottom). In case 3) I cannot run ft_statistics because there are no trials anymore. I have tried changing design matrix, search community messages for some advice and read related articles on fieldtriptoolbox site, but I have not find the answer. Any help would be appreciated. Michał Komorowski Statistics code: cfg = []; %cfg.dim = source.dim; % there is no such field in the data cfg.method = 'montecarlo'; cfg.statistic = 'ft_statfun_depsamplesT'; cfg.parameter = 'pow'; cfg.correctm = 'cluster'; cfg.numrandomization = 100; cfg.alpha = 0.05; cfg.correcttail = 'alpha'; % http://www.fieldtriptoolbox.org/faq/why_should_i_use_the_cfg.correcttail_option_when_using_statistics_montecarlo cfg.tail = 0; % two sided test cfg.design(1,:) = design; % condition code cfg.design(2,:) = [1:length(find(design==1)) 1:length(find(design==2))]; % trial indices cfg.uvar = 2; % unit of observation variable: trials cfg.ivar = 1; % independent variable: condition code % I think design matrix is ok according to: http://www.fieldtriptoolbox.org/walkthrough#paired_comparison) stat = ft_sourcestatistics(cfg, source); Data structures and error messages Case 1) no ft_sourcedescriptives and no ft_sourceinterpolate used source = freq: 10 cumtapcnt: [21x1 double] inside: [231420x1 logical] pos: [231420x3 double] method: 'rawtrial' trial: [1x21 struct] df: 21 cfg: [1x1 struct] the call to "ft_selectdata" took 1 seconds using "ft_statistics_montecarlo" for the statistical testing using connectivity of voxels in 3-D volume using "ft_statfun_depsamplesT" for the single-sample statistics constructing randomized design total number of measurements = 21 total number of variables = 2 number of independent variables = 1 number of unit variables = 1 number of within-cell variables = 0 number of control variables = 0 using a permutation resampling approach repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 computing a parametric threshold for clustering Error using ft_statfun_depsamplesT (line 84) Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering Error in ft_sourcestatistics (line 205) [stat, cfg] = statmethod(cfg, dat, design); >> cfg.design ans = 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 Case 2) used ft_sourcedescriptives and no ft_sourceinterpolate used source_app = freq: 10 cumtapcnt: [21x1 double] inside: [231420x1 logical] pos: [231420x3 double] method: 'rawtrial' trial: [1x21 struct] df: 21 cfg: [1x1 struct] the call to "ft_selectdata" took 0 seconds using "ft_statistics_montecarlo" for the statistical testing using connectivity of voxels in 3-D volume using "ft_statfun_depsamplesT" for the single-sample statistics constructing randomized design total number of measurements = 21 total number of variables = 2 number of independent variables = 1 number of unit variables = 1 number of within-cell variables = 0 number of control variables = 0 using a permutation resampling approach repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 computing a parametric threshold for clustering Error using ft_statfun_depsamplesT (line 84) Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering Error in ft_sourcestatistics (line 205) [stat, cfg] = statmethod(cfg, dat, design); Case 3) used ft_sourcedescriptives and used ft_sourceinterpolate source_mri_align_ctrl = freq: 10 anatomy: [128x128x128 double] coordsys: 'spm' dim: [128 128 128] pos: [2097152x3 double] transform: [4x4 double] unit: 'mm' inside: [128x128x128 logical] pow: [2097152x1 double] cfg: [1x1 struct] % there is no trials so one cannot conduct between-trials statistics ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.wilson at med.einstein.yu.edu Tue Jan 24 17:36:20 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Tue, 24 Jan 2017 16:36:20 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Julian, Thank you so much for your reply. I've pasted the commented code below (I apologize for the code dump). I've also attached an m-file to this email if you'd prefer to download it that way. If relevant, you can download the leadfield, headmodel and electrode locations here (that file also includes the raw data stored in variables A and U that I am attempting to source-fit). As per your questions: I do indeed have a contrast between attended (A) and unattended (U) conditions. I've written the code below to source-fit both conditions and create the contrast. However, despite that the raw topographies (see attached images) are different, the source-fits are the same (...?). As a consequence, the contrast has no non-zero values. If instead, I normalize to noise (i.e. generate the Neural Activity Index ) and look at a contrast there, we again see no non-zero values. Outside of the contrast, I've implemented your other suggestions. I've rescaled the original ft_sourceplot such that you can see the extent of it (see attached image). To my mind, it shouldn't look like this, but having never done this before, I'm not quite sure what to expect. I've also included an image of the ft_sourceplot for the Neural Activity Index of sourceA which also appears to me to be artefactual. More to the point, I'd expect that since the topographies for A and U are different, the NAIs should be different, which is not the case. I'm sort of at a loss about how to proceed here. So, thank you very much for taking the time to look into this. If I can supply anything else to help, please don't hesitate to let me know. Best, Tommy Wilson --- CODE --- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); On Tue, Jan 24, 2017 at 3:42 AM Julian Keil wrote: > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste your > code not only of the sourceanalysis, but the rest after which got you to > the plot? > It might also be the case that the automatic scaling in the source plot > throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual subject > MRIs, so I'm using the templates provided by fieldtrip. I've co-registered > my 160 Biosemi electrodes to the standard_bem template (see attached > picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid > (picture attached, overlaid on standard_bem). I can prepare the leadfield > from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the > LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data and > averaged across it (the covariance matrix was also calculated); the > topography of this averaged data is attached. I then attempted a source fit > with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated primarily > by a source that isn't even inside the brain (as the sourceplot indicates). > So, I'm not sure exactly where/how I'm going wrong with this one, nor am I > sure how to trouble shoot it. Any guidance you might provide would be > greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Attended.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Unattended.PNG Type: image/png Size: 91677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceA_sourceplot.PNG Type: image/png Size: 143463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceA_NAI_sourceplot.PNG Type: image/png Size: 147302 bytes Desc: not available URL: From tommy.wilson at med.einstein.yu.edu Tue Jan 24 17:55:56 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Tue, 24 Jan 2017 16:55:56 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi there, I apologize. I found a small bug in that script regarding the fieldtrip directory. The revised version is attached. Best, Tommy On Tue, Jan 24, 2017 at 11:36 AM Tommy Wilson < tommy.wilson at med.einstein.yu.edu> wrote: > Hi Julian, > > Thank you so much for your reply. > > I've pasted the commented code below (I apologize for the code dump). I've > also attached an m-file to this email if you'd prefer to download it that > way. If relevant, you can download the leadfield, headmodel and electrode > locations here > > (that file also includes the raw data stored in variables A and U that I am > attempting to source-fit). > > As per your questions: I do indeed have a contrast between attended (A) > and unattended (U) conditions. I've written the code below to source-fit > both conditions and create the contrast. However, despite that the raw > topographies (see attached images) are different, the source-fits are the > same (...?). As a consequence, the contrast has no non-zero values. If > instead, I normalize to noise (i.e. generate the Neural Activity Index > ) > and look at a contrast there, we again see no non-zero values. > > Outside of the contrast, I've implemented your other suggestions. I've > rescaled the original ft_sourceplot such that you can see the extent of it > (see attached image). To my mind, it shouldn't look like this, but having > never done this before, I'm not quite sure what to expect. I've also > included an image of the ft_sourceplot for the Neural Activity Index of > sourceA which also appears to me to be artefactual. More to the point, I'd > expect that since the topographies for A and U are different, the NAIs > should be different, which is not the case. > > I'm sort of at a loss about how to proceed here. So, thank you very much > for taking the time to look into this. If I can supply anything else to > help, please don't hesitate to let me know. > > Best, > > Tommy Wilson > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\'; > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrast > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > % Check to see if any non-zero values exist in the contrast > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > warning('No non-zero contast values exist. ft_sourceplot will give an > error. Do not plot.'); > end > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > % See: > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > sourceA_NAI = sourceA; > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > sourceU_NAI = sourceU; > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > warning('No non-zero contast values exist. ft_sourceplot will give an > error. Do not plot.') > end > > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [0 3e3]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_NAI_interp); > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil wrote: > > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste your > code not only of the sourceanalysis, but the rest after which got you to > the plot? > It might also be the case that the automatic scaling in the source plot > throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual subject > MRIs, so I'm using the templates provided by fieldtrip. I've co-registered > my 160 Biosemi electrodes to the standard_bem template (see attached > picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid > (picture attached, overlaid on standard_bem). I can prepare the leadfield > from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the > LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data and > averaged across it (the covariance matrix was also calculated); the > topography of this averaged data is attached. I then attempted a source fit > with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated primarily > by a source that isn't even inside the brain (as the sourceplot indicates). > So, I'm not sure exactly where/how I'm going wrong with this one, nor am I > sure how to trouble shoot it. Any guidance you might provide would be > greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); From m.p.craddock at leeds.ac.uk Tue Jan 24 22:07:05 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Tue, 24 Jan 2017 21:07:05 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Tommy, > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > This is the problem. ft_sourceanalysis is using the covariance matrix and leadfield to construct a spatial filter for each grid point; if the covariance matrices are equivalent, the source solutions will be too. What you need to do is something like run the source analysis on data averaged over both conditions first, then take the filter from the combined analysis and run source analysis on each condition seperately. so say sourceAll is the result of ft_sourceanalysis(cfg,bothConditions) You'd do cfg.grid.filter = sourceAll.avg.filter then ft_sourceanalysis(cfg,A) ft_sourceanalysis(cfg,U) As a quick and dirty version I just replaced the covariance matrix in A with the average of the two A.cov and U.cov, ran sourceanalysis on that, then put A.cov back to its original value and ran sourceanalysis on each condition seperately. Spoiler: the unattended condition has lower activity everywhere :) There's some weirdness around the boundaries of the headmodel, not sure what's causing that exactly. Maybe try using a different source grid instead of the standard one... Cheers, Matt On 24/01/2017 16:36, Tommy Wilson wrote: > Hi Julian, > > Thank you so much for your reply. > > I've pasted the commented code below (I apologize for the code dump). > I've also attached an m-file to this email if you'd prefer to download > it that way. If relevant, you can download the leadfield, headmodel and > electrode locations here > > (that file also includes the raw data stored in variables A and U that I > am attempting to source-fit). > > As per your questions: I do indeed have a contrast between attended (A) > and unattended (U) conditions. I've written the code below to source-fit > both conditions and create the contrast. However, despite that the raw > topographies (see attached images) are different, the source-fits are > the same (...?). As a consequence, the contrast has no non-zero values. > If instead, I normalize to noise (i.e. generate the Neural Activity > Index > ) > and look at a contrast there, we again see no non-zero values. > > Outside of the contrast, I've implemented your other suggestions. I've > rescaled the original ft_sourceplot such that you can see the extent of > it (see attached image). To my mind, it shouldn't look like this, but > having never done this before, I'm not quite sure what to expect. I've > also included an image of the ft_sourceplot for the Neural Activity > Index of sourceA which also appears to me to be artefactual. More to the > point, I'd expect that since the topographies for A and U are different, > the NAIs should be different, which is not the case. > > I'm sort of at a loss about how to proceed here. So, thank you very much > for taking the time to look into this. If I can supply anything else to > help, please don't hesitate to let me know. > > Best, > > Tommy Wilson > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\'; > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrast > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > % Check to see if any non-zero values exist in the contrast > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > warning('No non-zero contast values exist. ft_sourceplot will give > an error. Do not plot.'); > end > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > % See: > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > sourceA_NAI = sourceA; > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > sourceU_NAI = sourceU; > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > warning('No non-zero contast values exist. ft_sourceplot will give > an error. Do not plot.') > end > > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [0 3e3]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_NAI_interp); > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > wrote: > > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste > your code not only of the sourceanalysis, but the rest after which > got you to the plot? > It might also be the case that the automatic scaling in the source > plot throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual > subject MRIs, so I'm using the templates provided by fieldtrip. I've > co-registered my 160 Biosemi electrodes to the standard_bem template > (see attached picture). For the sourcemodel, I'm using the > standard_sourcemodel3d5mm grid (picture attached, overlaid on > standard_bem). I can prepare the leadfield from there with > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data > and averaged across it (the covariance matrix was also calculated); > the topography of this averaged data is attached. I then attempted a > source fit with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated > primarily by a source that isn't even inside the brain (as the > sourceplot indicates). So, I'm not sure exactly where/how I'm going > wrong with this one, nor am I sure how to trouble shoot it. Any > guidance you might provide would be greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From jens.klinzing at uni-tuebingen.de Wed Jan 25 10:29:29 2017 From: jens.klinzing at uni-tuebingen.de (=?UTF-8?B?IkplbnMgS2xpbnppbmcsIFVuaSBUw7xiaW5nZW4i?=) Date: Wed, 25 Jan 2017 10:29:29 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> <5880823B.2050806@uni-tuebingen.de> Message-ID: <58886FF9.3050904@uni-tuebingen.de> Dear Elena, I'm glad the first problem is solved. About the second one: Are you referring to the yellowish background outside of the brain? My first guess would be that this is a mere plotting issue. Can you check whether there actually are non-NAN or even non-zero values for grid points marked as 'outside' (before interpolation and before and after contrasting)? If not, you know it is a problem with the plotting. Best, Jens > Elena Krugliakova > Donnerstag, 19. Januar 2017 13:55 > Dear Jens, > > Thank you for your answer! > 1. Indeed, I found where ft_sourceanalysis starts to recompute > transfer matrix and just loaded precomputed headmodel and sensors. Now > everything is fine, and it takes several seconds to run ft_sourceanalysis. > 2. About homogeneous "noise outside the mri scan". > Noise appears after I calculate difference between two sources, > following tutorial > http://www.fieldtriptoolbox.org/tutorial/beamformer. However, > sourceplot for not-contrasted conditions looks good. Maybe you could > give me an advice, how to get rid of this background noise. > > Kind Regards, > Elena > > > > > With difference calculation: > > cfg = []; > cfg.elec = elec; > cfg.headmodel = vol; > cfg.grid = leadfield; > cfg.keepleadfield = 'yes' > cfg.projectnoise = 'yes'; > cfg.frequency = [10 15]; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); > cfg.grid.filter = sourcePNandBS.avg.filter; > sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); > sourceBS = ft_sourceanalysis(cfg, freq_BS_Post); > *sourceDiff.avg.pow = (sourcePN.avg.pow - sourceBS.avg.pow) ./ > sourceBS.avg.pow;* > > cfg = []; > cfg.parameter = 'avg.pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > cfg.opacitymap = 'rampup'; > ft_sourceplot(cfg, sourceDiffIntNorm); > > figure > Inline images 1 > > > > > Without difference calculation: > > cfg = []; > cfg.elec = elec; > .......... > sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); > > cfg.grid.filter = sourcePNandBS.avg.filter; > > sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); > sourcePN.avg.pow = sourcePN.avg.pow ./ sourcePN.avg.noise; > > cfg = []; > cfg.parameter = 'avg.pow'; > sourcePN = ft_sourceinterpolate(cfg, sourcePN, mri); > > cfg = []; > sourcePNIntNorm = ft_volumenormalise(cfg, sourcePNInt); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > cfg.opacitymap = 'rampup'; > ft_sourceplot(cfg, sourcePNIntNorm); > > figure > Inline images 2 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > Jens Klinzing, Uni Tübingen > Donnerstag, 19. Januar 2017 10:09 > Dear Elena, > > Question 1: > I assume the reason it takes so long is that you are using a FEM-based > headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix > on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - > sb_transfer) every time you do a source reconstruction. For more > information see > http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 . > > You can circumvent the issue by computing the transfer matrix > beforehand and changing the code in a way that it doesnt compute a new > transfer matrix if you have already provided one. > > Alternatively you could use a BEM headmodel (dipoli if possible since > bemcp seems to have issues > http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2817). > > Question 2: > Did you check your segmentation, the headmodel and the coregistration > of electrodes/head every step of the way? If you fill all inside > voxels with 1s and plot that, do you see an obvious shift/rotation of > the "activity" in relation to the MRI? > > Best, > Jens > > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' > method applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to > call one ft_sourceanalysis. Maybe, there is a way to optimise the > procedure somehow? > > Second, at the end of analysis I obtain a very strange figure, on > which I see activity localised outside the mri scan. Mistake on which > step of analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - > sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 154917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 181508 bytes Desc: not available URL: From tommy.wilson at med.einstein.yu.edu Wed Jan 25 17:13:23 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Wed, 25 Jan 2017 11:13:23 -0500 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Matt, Thanks so much for your reply here! I believe I've correctly implemented your comments: I computed a common filter by source analyzing the combined (read: averaged) data/covariance matrix. In a second step, I used this filter to source localize each condition separately. I subsequently contrasted the two conditions, but I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the voxels. I attached an image of the ft_sourceplot to this email. (I don't know why the NaNs aren't masking appropriately, but I can figure that out on my own time). I also attempted your quick and dirty solution to see if I could reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow > sourceA.avg.pow in 99% of voxels), which is exactly the opposite of what you said you came up with. (The ft_sourceplot for this scenario looks identical to the first, which is unsurprising--in both cases, we used the average covariance matrix to construct the filters, so they ought to be identical). I must be doing something wrong here, but alas, I can't seem to put the pieces together. Any help/guidance you could provide would be deeply appreciated. I've attached the updated script to this email (and printed it below for posterity), and as before, the data can be found here . Again, thank you for taking the time to respond. Best, Tommy --- CODE --- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Average both conditions to generate common filter M = ft_timelockgrandaverage(struct(),A,U); M.cov = mean(cat(3,A.cov,U.cov),3); % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances % A.cov = U.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common filter sourceM = ft_sourceanalysis(cfg,M); % Add the common filter to the cfg cfg.grid.filter = sourceM.avg.filter; % Source fit the originals sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Matt's quick and dirty version % Replace A's cov matrix with an average of A.cov and U.cov tmp = A.cov; A.cov = mean(cat(3,tmp,U.cov),3); cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common test filter sourceA_common_test = ft_sourceanalysis(cfg,A); % Add common filter to configuration cfg.grid.filter = sourceA_common_test.avg.filter; % Replace original covariance matrix A.cov = tmp; % Now fit both A and U with the common test filter sourceA_test = ft_sourceanalysis(cfg,A); sourceU_test = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrasts sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; sourceContrast_test = sourceA_test; sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; % Gauge what percent of the contrast is negative (i.e. sourceU power > % sourceA power) perc_neg = sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); perc_neg_test = sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); sourceContrast_test_interp = ft_sourceinterpolate(cfg, sourceContrast_test, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_test_interp); On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock wrote: > Hi Tommy, > > > % Equate covariance matrices for now to rule out any differences in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > This is the problem. ft_sourceanalysis is using the covariance matrix > and leadfield to construct a spatial filter for each grid point; if the > covariance matrices are equivalent, the source solutions will be too. > > What you need to do is something like run the source analysis on data > averaged over both conditions first, then take the filter from the > combined analysis and run source analysis on each condition seperately. > > so say sourceAll is the result of > ft_sourceanalysis(cfg,bothConditions) > > You'd do > > cfg.grid.filter = sourceAll.avg.filter > > then > > ft_sourceanalysis(cfg,A) > ft_sourceanalysis(cfg,U) > > As a quick and dirty version I just replaced the covariance matrix in A > with the average of the two A.cov and U.cov, ran sourceanalysis on that, > then put A.cov back to its original value and ran sourceanalysis on each > condition seperately. Spoiler: the unattended condition has lower > activity everywhere :) > > There's some weirdness around the boundaries of the headmodel, not sure > what's causing that exactly. Maybe try using a different source grid > instead of the standard one... > > Cheers, > Matt > > On 24/01/2017 16:36, Tommy Wilson wrote: > > Hi Julian, > > > > Thank you so much for your reply. > > > > I've pasted the commented code below (I apologize for the code dump). > > I've also attached an m-file to this email if you'd prefer to download > > it that way. If relevant, you can download the leadfield, headmodel and > > electrode locations here > > > > (that file also includes the raw data stored in variables A and U that I > > am attempting to source-fit). > > > > As per your questions: I do indeed have a contrast between attended (A) > > and unattended (U) conditions. I've written the code below to source-fit > > both conditions and create the contrast. However, despite that the raw > > topographies (see attached images) are different, the source-fits are > > the same (...?). As a consequence, the contrast has no non-zero values. > > If instead, I normalize to noise (i.e. generate the Neural Activity > > Index > > neural_activity_index>) > > and look at a contrast there, we again see no non-zero values. > > > > Outside of the contrast, I've implemented your other suggestions. I've > > rescaled the original ft_sourceplot such that you can see the extent of > > it (see attached image). To my mind, it shouldn't look like this, but > > having never done this before, I'm not quite sure what to expect. I've > > also included an image of the ft_sourceplot for the Neural Activity > > Index of sourceA which also appears to me to be artefactual. More to the > > point, I'd expect that since the topographies for A and U are different, > > the NAIs should be different, which is not the case. > > > > I'm sort of at a loss about how to proceed here. So, thank you very much > > for taking the time to look into this. If I can supply anything else to > > help, please don't hesitate to let me know. > > > > Best, > > > > Tommy Wilson > > > > --- CODE --- > > > > %% Source fitting protocol > > % Fieldtrip path (to find template MRI) > > ftdir = 'your\path\here\'; > > > > % Equate covariance matrices for now to rule out any differences in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > %%% Do the LCMV sourcefitting > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > sourceU = ft_sourceanalysis(cfg,U); > > > > > > %%% Attempt a contrast > > % Create the contrast > > sourceContrast = sourceA; > > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > > > % Check to see if any non-zero values exist in the contrast > > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.'); > > end > > > > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > > % See: > > http://www.fieldtriptoolbox.org/tutorial/beamformer# > neural_activity_index > > sourceA_NAI = sourceA; > > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > > sourceU_NAI = sourceU; > > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.') > > end > > > > > > %%% Visualize the output > > % Load template MRI > > mri = ft_read_mri([ftdir > > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > > > % Interpolate source onto MRI > > cfg = []; > > cfg.parameter = 'avg.pow'; > > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > > > % Visualize with ft_sourceplot > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.funcolorlim = [0 3e3]; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_interp); > > > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_NAI_interp); > > > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > > wrote: > > > > Hi Tommy, > > > > did you do some sort of contrast (e.g. with the noise estimate or a > > baseline) after your source analysis? > > Right now, it's not clear what you are looking at. Could you paste > > your code not only of the sourceanalysis, but the rest after which > > got you to the plot? > > It might also be the case that the automatic scaling in the source > > plot throws you off - maybe try setting it by hand. > > > > Good luck, > > > > Julian > > > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > > > Hi all, > > > > > > I'm working with EEG data and I'm trying to get some basic source > > fitting up and running. Unfortunately, I don't have individual > > subject MRIs, so I'm using the templates provided by fieldtrip. I've > > co-registered my 160 Biosemi electrodes to the standard_bem template > > (see attached picture). For the sourcemodel, I'm using the > > standard_sourcemodel3d5mm grid (picture attached, overlaid on > > standard_bem). I can prepare the leadfield from there with > > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV > tutorial. > > > > > > To test this configuration, I've selected a time window in my data > > and averaged across it (the covariance matrix was also calculated); > > the topography of this averaged data is attached. I then attempted a > > source fit with the LCMV beamformer: > > > > > > cfg = []; > > > cfg.method = 'lcmv'; > > > cfg.grid = leadfield; > > > cfg.vol = vol; > > > cfg.elec = elec; > > > cfg.lcmv.lambda = '15%'; > > > cfg.lcmv.keepfilter = 'yes'; > > > cfg.lcmv.fixedori = 'yes'; > > > cfg.lcmv.projectnoise = 'yes'; > > > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > > > After interpolating to the single_subj_T1.nii provided with > > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > > sourceplot that is highly focal in nature (see attached picture). > > > > > > I'd find it very surprising if this topography were generated > > primarily by a source that isn't even inside the brain (as the > > sourceplot indicates). So, I'm not sure exactly where/how I'm going > > wrong with this one, nor am I sure how to trouble shoot it. Any > > guidance you might provide would be greatly appreciated. > > > > > > Thanks so much, > > > > > > Tommy > > > > > > > localization.PNG>___________________ > ____________________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Average both conditions to generate common filter M = ft_timelockgrandaverage(struct(),A,U); M.cov = mean(cat(3,A.cov,U.cov),3); % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances % A.cov = U.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common filter sourceM = ft_sourceanalysis(cfg,M); % Add the common filter to the cfg cfg.grid.filter = sourceM.avg.filter; % Source fit the originals sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Matt's quick and dirty version % Replace A's cov matrix with an average of A.cov and U.cov tmp = A.cov; A.cov = mean(cat(3,tmp,U.cov),3); cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common test filter sourceA_common_test = ft_sourceanalysis(cfg,A); % Add common filter to configuration cfg.grid.filter = sourceA_common_test.avg.filter; % Replace original covariance matrix A.cov = tmp; % Now fit both A and U with the common test filter sourceA_test = ft_sourceanalysis(cfg,A); sourceU_test = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrasts sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; sourceContrast_test = sourceA_test; sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; % Gauge what percent of the contrast is negative (i.e. sourceU power > % sourceA power) perc_neg = sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); perc_neg_test = sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); sourceContrast_test_interp = ft_sourceinterpolate(cfg, sourceContrast_test, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_test_interp); -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceContrast_sourceplot.PNG Type: image/png Size: 128252 bytes Desc: not available URL: From m.p.craddock at leeds.ac.uk Wed Jan 25 18:11:41 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Wed, 25 Jan 2017 17:11:41 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> Sorry Tommy, I misread the sign of my results - they're the same as yours :) I get the NaNs plotting thing sometimes too, never totally sure why as it seems intermittent. Cheers, Matt On 25/01/2017 16:13, Tommy Wilson wrote: > Hi Matt, > > Thanks so much for your reply here! > > I believe I've correctly implemented your comments: I computed a common > filter by source analyzing the combined (read: averaged) data/covariance > matrix. In a second step, I used this filter to source localize each > condition separately. I subsequently contrasted the two conditions, but > I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the > voxels. I attached an image of the ft_sourceplot to this email. (I don't > know why the NaNs aren't masking appropriately, but I can figure that > out on my own time). > > I also attempted your quick and dirty solution to see if I could > reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow >> sourceA.avg.pow in 99% of voxels), which is exactly the opposite of > what you said you came up with. (The ft_sourceplot for this scenario > looks identical to the first, which is unsurprising--in both cases, we > used the average covariance matrix to construct the filters, so they > ought to be identical). I must be doing something wrong here, but alas, > I can't seem to put the pieces together. > > Any help/guidance you could provide would be deeply appreciated. I've > attached the updated script to this email (and printed it below for > posterity), and as before, the data can be found here > . > > Again, thank you for taking the time to respond. > > Best, > > Tommy > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\fieldtrip-20160309'; > > % Average both conditions to generate common filter > M = ft_timelockgrandaverage(struct(),A,U); > M.cov = mean(cat(3,A.cov,U.cov),3); > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > % A.cov = U.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > % Generate common filter > sourceM = ft_sourceanalysis(cfg,M); > > % Add the common filter to the cfg > cfg.grid.filter = sourceM.avg.filter; > > % Source fit the originals > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > %%% Matt's quick and dirty version > % Replace A's cov matrix with an average of A.cov and U.cov > tmp = A.cov; > A.cov = mean(cat(3,tmp,U.cov),3); > > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > % Generate common test filter > sourceA_common_test = ft_sourceanalysis(cfg,A); > > % Add common filter to configuration > cfg.grid.filter = sourceA_common_test.avg.filter; > > % Replace original covariance matrix > A.cov = tmp; > > % Now fit both A and U with the common test filter > sourceA_test = ft_sourceanalysis(cfg,A); > sourceU_test = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrasts > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > sourceContrast_test = sourceA_test; > sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; > > % Gauge what percent of the contrast is negative (i.e. sourceU power > > % sourceA power) > perc_neg = > sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); > perc_neg_test = > sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); > sourceContrast_test_interp = ft_sourceinterpolate(cfg, > sourceContrast_test, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [-100 5]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceContrast_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [-100 5]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceContrast_test_interp); > > On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock > wrote: > > Hi Tommy, > > > % Equate covariance matrices for now to rule out any differences > in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > This is the problem. ft_sourceanalysis is using the covariance matrix > and leadfield to construct a spatial filter for each grid point; if the > covariance matrices are equivalent, the source solutions will be too. > > What you need to do is something like run the source analysis on data > averaged over both conditions first, then take the filter from the > combined analysis and run source analysis on each condition seperately. > > so say sourceAll is the result of > ft_sourceanalysis(cfg,bothConditions) > > You'd do > > cfg.grid.filter = sourceAll.avg.filter > > then > > ft_sourceanalysis(cfg,A) > ft_sourceanalysis(cfg,U) > > As a quick and dirty version I just replaced the covariance matrix in A > with the average of the two A.cov and U.cov, ran sourceanalysis on that, > then put A.cov back to its original value and ran sourceanalysis on each > condition seperately. Spoiler: the unattended condition has lower > activity everywhere :) > > There's some weirdness around the boundaries of the headmodel, not sure > what's causing that exactly. Maybe try using a different source grid > instead of the standard one... > > Cheers, > Matt > > On 24/01/2017 16:36, Tommy Wilson wrote: > > Hi Julian, > > > > Thank you so much for your reply. > > > > I've pasted the commented code below (I apologize for the code dump). > > I've also attached an m-file to this email if you'd prefer to download > > it that way. If relevant, you can download the leadfield, > headmodel and > > electrode locations here > > > > > > (that file also includes the raw data stored in variables A and U > that I > > am attempting to source-fit). > > > > As per your questions: I do indeed have a contrast between > attended (A) > > and unattended (U) conditions. I've written the code below to > source-fit > > both conditions and create the contrast. However, despite that the raw > > topographies (see attached images) are different, the source-fits are > > the same (...?). As a consequence, the contrast has no non-zero > values. > > If instead, I normalize to noise (i.e. generate the Neural Activity > > Index > > > >) > > and look at a contrast there, we again see no non-zero values. > > > > Outside of the contrast, I've implemented your other suggestions. I've > > rescaled the original ft_sourceplot such that you can see the > extent of > > it (see attached image). To my mind, it shouldn't look like this, but > > having never done this before, I'm not quite sure what to expect. I've > > also included an image of the ft_sourceplot for the Neural Activity > > Index of sourceA which also appears to me to be artefactual. More > to the > > point, I'd expect that since the topographies for A and U are > different, > > the NAIs should be different, which is not the case. > > > > I'm sort of at a loss about how to proceed here. So, thank you > very much > > for taking the time to look into this. If I can supply anything > else to > > help, please don't hesitate to let me know. > > > > Best, > > > > Tommy Wilson > > > > --- CODE --- > > > > %% Source fitting protocol > > % Fieldtrip path (to find template MRI) > > ftdir = 'your\path\here\'; > > > > % Equate covariance matrices for now to rule out any differences > in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > %%% Do the LCMV sourcefitting > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > sourceU = ft_sourceanalysis(cfg,U); > > > > > > %%% Attempt a contrast > > % Create the contrast > > sourceContrast = sourceA; > > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > > > % Check to see if any non-zero values exist in the contrast > > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.'); > > end > > > > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > > % See: > > > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > > > sourceA_NAI = sourceA; > > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > > sourceU_NAI = sourceU; > > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.') > > end > > > > > > %%% Visualize the output > > % Load template MRI > > mri = ft_read_mri([ftdir > > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > > > % Interpolate source onto MRI > > cfg = []; > > cfg.parameter = 'avg.pow'; > > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > > > % Visualize with ft_sourceplot > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.funcolorlim = [0 3e3]; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_interp); > > > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_NAI_interp); > > > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > > >> wrote: > > > > Hi Tommy, > > > > did you do some sort of contrast (e.g. with the noise estimate > or a > > baseline) after your source analysis? > > Right now, it's not clear what you are looking at. Could you paste > > your code not only of the sourceanalysis, but the rest after which > > got you to the plot? > > It might also be the case that the automatic scaling in the source > > plot throws you off - maybe try setting it by hand. > > > > Good luck, > > > > Julian > > > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > > > Hi all, > > > > > > I'm working with EEG data and I'm trying to get some basic > source > > fitting up and running. Unfortunately, I don't have individual > > subject MRIs, so I'm using the templates provided by > fieldtrip. I've > > co-registered my 160 Biosemi electrodes to the standard_bem > template > > (see attached picture). For the sourcemodel, I'm using the > > standard_sourcemodel3d5mm grid (picture attached, overlaid on > > standard_bem). I can prepare the leadfield from there with > > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV > tutorial. > > > > > > To test this configuration, I've selected a time window in > my data > > and averaged across it (the covariance matrix was also > calculated); > > the topography of this averaged data is attached. I then > attempted a > > source fit with the LCMV beamformer: > > > > > > cfg = []; > > > cfg.method = 'lcmv'; > > > cfg.grid = leadfield; > > > cfg.vol = vol; > > > cfg.elec = elec; > > > cfg.lcmv.lambda = '15%'; > > > cfg.lcmv.keepfilter = 'yes'; > > > cfg.lcmv.fixedori = 'yes'; > > > cfg.lcmv.projectnoise = 'yes'; > > > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > > > After interpolating to the single_subj_T1.nii provided with > > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > > sourceplot that is highly focal in nature (see attached picture). > > > > > > I'd find it very surprising if this topography were generated > > primarily by a source that isn't even inside the brain (as the > > sourceplot indicates). So, I'm not sure exactly where/how I'm > going > > wrong with this one, nor am I sure how to trouble shoot it. Any > > guidance you might provide would be greatly appreciated. > > > > > > Thanks so much, > > > > > > Tommy > > > > > > > > localization.PNG>_______________________________________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From tommy.wilson at med.einstein.yu.edu Wed Jan 25 20:47:13 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Wed, 25 Jan 2017 14:47:13 -0500 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> Message-ID: Oh! Whew. Well, at least there's that. (It's the small things, you know?) But, doesn't that lead to another question? As you can see from the topographies attached, the Attended topography is much higher in amplitude than the unattended (they are on the same color scale). Perhaps this is a moment when my intuition doesn't matter, but wouldn't you expect that the source generating the Attended topography would have greater power than the Unattended source? Or is there something I don't understand here? Thanks again for taking the time to respond. I truly appreciate your help. Best, Tommy On Wed, Jan 25, 2017 at 12:11 PM, Matt Craddock wrote: > Sorry Tommy, I misread the sign of my results - they're the same as yours > :) I get the NaNs plotting thing sometimes too, never totally sure why as > it seems intermittent. > > Cheers, > Matt > > On 25/01/2017 16:13, Tommy Wilson wrote: > >> Hi Matt, >> >> Thanks so much for your reply here! >> >> I believe I've correctly implemented your comments: I computed a common >> filter by source analyzing the combined (read: averaged) data/covariance >> matrix. In a second step, I used this filter to source localize each >> condition separately. I subsequently contrasted the two conditions, but >> I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the >> voxels. I attached an image of the ft_sourceplot to this email. (I don't >> know why the NaNs aren't masking appropriately, but I can figure that >> out on my own time). >> >> I also attempted your quick and dirty solution to see if I could >> reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow >> >>> sourceA.avg.pow in 99% of voxels), which is exactly the opposite of >>> >> what you said you came up with. (The ft_sourceplot for this scenario >> looks identical to the first, which is unsurprising--in both cases, we >> used the average covariance matrix to construct the filters, so they >> ought to be identical). I must be doing something wrong here, but alas, >> I can't seem to put the pieces together. >> >> Any help/guidance you could provide would be deeply appreciated. I've >> attached the updated script to this email (and printed it below for >> posterity), and as before, the data can be found here >> . >> >> >> Again, thank you for taking the time to respond. >> >> Best, >> >> Tommy >> >> --- CODE --- >> >> %% Source fitting protocol >> % Fieldtrip path (to find template MRI) >> ftdir = 'your\path\here\fieldtrip-20160309'; >> >> % Average both conditions to generate common filter >> M = ft_timelockgrandaverage(struct(),A,U); >> M.cov = mean(cat(3,A.cov,U.cov),3); >> >> % Equate covariance matrices for now to rule out any differences in the >> % source fit due to differences in covariances >> % A.cov = U.cov; >> >> %%% Do the LCMV sourcefitting >> cfg = []; >> cfg.method = 'lcmv'; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.elec = elec; >> cfg.lcmv.lambda = '15%'; >> cfg.lcmv.keepfilter = 'yes'; >> cfg.lcmv.fixedori = 'yes'; >> cfg.lcmv.projectnoise = 'yes'; >> >> % Generate common filter >> sourceM = ft_sourceanalysis(cfg,M); >> >> % Add the common filter to the cfg >> cfg.grid.filter = sourceM.avg.filter; >> >> % Source fit the originals >> sourceA = ft_sourceanalysis(cfg,A); >> sourceU = ft_sourceanalysis(cfg,U); >> >> %%% Matt's quick and dirty version >> % Replace A's cov matrix with an average of A.cov and U.cov >> tmp = A.cov; >> A.cov = mean(cat(3,tmp,U.cov),3); >> >> cfg = []; >> cfg.method = 'lcmv'; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.elec = elec; >> cfg.lcmv.lambda = '15%'; >> cfg.lcmv.keepfilter = 'yes'; >> cfg.lcmv.fixedori = 'yes'; >> cfg.lcmv.projectnoise = 'yes'; >> >> % Generate common test filter >> sourceA_common_test = ft_sourceanalysis(cfg,A); >> >> % Add common filter to configuration >> cfg.grid.filter = sourceA_common_test.avg.filter; >> >> % Replace original covariance matrix >> A.cov = tmp; >> >> % Now fit both A and U with the common test filter >> sourceA_test = ft_sourceanalysis(cfg,A); >> sourceU_test = ft_sourceanalysis(cfg,U); >> >> >> %%% Attempt a contrast >> % Create the contrasts >> sourceContrast = sourceA; >> sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; >> sourceContrast_test = sourceA_test; >> sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; >> >> % Gauge what percent of the contrast is negative (i.e. sourceU power > >> % sourceA power) >> perc_neg = >> sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./num >> el(sourceContrast.avg.pow(sourceContrast.inside(:))); >> perc_neg_test = >> sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(: >> ))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); >> >> %%% Visualize the output >> % Load template MRI >> mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); >> >> % Interpolate source onto MRI >> cfg = []; >> cfg.parameter = 'avg.pow'; >> sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); >> sourceContrast_test_interp = ft_sourceinterpolate(cfg, >> sourceContrast_test, mri); >> >> % Visualize with ft_sourceplot >> cfg = []; >> cfg.method = 'ortho'; >> cfg.funparameter = 'avg.pow'; >> cfg.funcolorlim = [-100 5]; >> cfg.maskparameter = cfg.funparameter; >> ft_sourceplot(cfg, sourceContrast_interp); >> >> cfg = []; >> cfg.method = 'ortho'; >> cfg.funparameter = 'avg.pow'; >> cfg.funcolorlim = [-100 5]; >> cfg.maskparameter = cfg.funparameter; >> ft_sourceplot(cfg, sourceContrast_test_interp); >> >> On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock > > wrote: >> >> Hi Tommy, >> >> > % Equate covariance matrices for now to rule out any differences >> in the >> > % source fit due to differences in covariances >> > U.cov = A.cov; >> > >> >> This is the problem. ft_sourceanalysis is using the covariance matrix >> and leadfield to construct a spatial filter for each grid point; if >> the >> covariance matrices are equivalent, the source solutions will be too. >> >> What you need to do is something like run the source analysis on data >> averaged over both conditions first, then take the filter from the >> combined analysis and run source analysis on each condition >> seperately. >> >> so say sourceAll is the result of >> ft_sourceanalysis(cfg,bothConditions) >> >> You'd do >> >> cfg.grid.filter = sourceAll.avg.filter >> >> then >> >> ft_sourceanalysis(cfg,A) >> ft_sourceanalysis(cfg,U) >> >> As a quick and dirty version I just replaced the covariance matrix in >> A >> with the average of the two A.cov and U.cov, ran sourceanalysis on >> that, >> then put A.cov back to its original value and ran sourceanalysis on >> each >> condition seperately. Spoiler: the unattended condition has lower >> activity everywhere :) >> >> There's some weirdness around the boundaries of the headmodel, not >> sure >> what's causing that exactly. Maybe try using a different source grid >> instead of the standard one... >> >> Cheers, >> Matt >> >> On 24/01/2017 16:36, Tommy Wilson wrote: >> > Hi Julian, >> > >> > Thank you so much for your reply. >> > >> > I've pasted the commented code below (I apologize for the code >> dump). >> > I've also attached an m-file to this email if you'd prefer to >> download >> > it that way. If relevant, you can download the leadfield, >> headmodel and >> > electrode locations here >> > >> > dump.mat?dl=0 >> > dump.mat?dl=0>> >> > (that file also includes the raw data stored in variables A and U >> that I >> > am attempting to source-fit). >> > >> > As per your questions: I do indeed have a contrast between >> attended (A) >> > and unattended (U) conditions. I've written the code below to >> source-fit >> > both conditions and create the contrast. However, despite that the >> raw >> > topographies (see attached images) are different, the source-fits >> are >> > the same (...?). As a consequence, the contrast has no non-zero >> values. >> > If instead, I normalize to noise (i.e. generate the Neural Activity >> > Index >> > >> > activity_index >> > activity_index>>) >> > and look at a contrast there, we again see no non-zero values. >> > >> > Outside of the contrast, I've implemented your other suggestions. >> I've >> > rescaled the original ft_sourceplot such that you can see the >> extent of >> > it (see attached image). To my mind, it shouldn't look like this, >> but >> > having never done this before, I'm not quite sure what to expect. >> I've >> > also included an image of the ft_sourceplot for the Neural Activity >> > Index of sourceA which also appears to me to be artefactual. More >> to the >> > point, I'd expect that since the topographies for A and U are >> different, >> > the NAIs should be different, which is not the case. >> > >> > I'm sort of at a loss about how to proceed here. So, thank you >> very much >> > for taking the time to look into this. If I can supply anything >> else to >> > help, please don't hesitate to let me know. >> > >> > Best, >> > >> > Tommy Wilson >> > >> > --- CODE --- >> > >> > %% Source fitting protocol >> > % Fieldtrip path (to find template MRI) >> > ftdir = 'your\path\here\'; >> > >> > % Equate covariance matrices for now to rule out any differences >> in the >> > % source fit due to differences in covariances >> > U.cov = A.cov; >> > >> > %%% Do the LCMV sourcefitting >> > cfg = []; >> > cfg.method = 'lcmv'; >> > cfg.grid = leadfield; >> > cfg.vol = vol; >> > cfg.elec = elec; >> > cfg.lcmv.lambda = '15%'; >> > cfg.lcmv.keepfilter = 'yes'; >> > cfg.lcmv.fixedori = 'yes'; >> > cfg.lcmv.projectnoise = 'yes'; >> > >> > sourceA = ft_sourceanalysis(cfg,A); >> > sourceU = ft_sourceanalysis(cfg,U); >> > >> > >> > %%% Attempt a contrast >> > % Create the contrast >> > sourceContrast = sourceA; >> > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; >> > >> > % Check to see if any non-zero values exist in the contrast >> > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) >> > warning('No non-zero contast values exist. ft_sourceplot will >> give >> > an error. Do not plot.'); >> > end >> > >> > >> > %%% Instead of a contrast, look at the Neural Activity Index (NAI) >> > % See: >> > >> http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_ >> activity_index >> > activity_index> >> > sourceA_NAI = sourceA; >> > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; >> > sourceU_NAI = sourceU; >> > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; >> > >> > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - >> > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) >> > warning('No non-zero contast values exist. ft_sourceplot will >> give >> > an error. Do not plot.') >> > end >> > >> > >> > %%% Visualize the output >> > % Load template MRI >> > mri = ft_read_mri([ftdir >> > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); >> > >> > % Interpolate source onto MRI >> > cfg = []; >> > cfg.parameter = 'avg.pow'; >> > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); >> > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); >> > >> > % Visualize with ft_sourceplot >> > cfg = []; >> > cfg.method = 'ortho'; >> > cfg.funparameter = 'avg.pow'; >> > cfg.funcolorlim = [0 3e3]; >> > cfg.maskparameter = cfg.funparameter; >> > ft_sourceplot(cfg, sourceA_interp); >> > >> > cfg = []; >> > cfg.method = 'ortho'; >> > cfg.funparameter = 'avg.pow'; >> > cfg.maskparameter = cfg.funparameter; >> > ft_sourceplot(cfg, sourceA_NAI_interp); >> > >> > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > >> > >> >> wrote: >> > >> > Hi Tommy, >> > >> > did you do some sort of contrast (e.g. with the noise estimate >> or a >> > baseline) after your source analysis? >> > Right now, it's not clear what you are looking at. Could you >> paste >> > your code not only of the sourceanalysis, but the rest after >> which >> > got you to the plot? >> > It might also be the case that the automatic scaling in the >> source >> > plot throws you off - maybe try setting it by hand. >> > >> > Good luck, >> > >> > Julian >> > >> > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: >> > >> > > Hi all, >> > > >> > > I'm working with EEG data and I'm trying to get some basic >> source >> > fitting up and running. Unfortunately, I don't have individual >> > subject MRIs, so I'm using the templates provided by >> fieldtrip. I've >> > co-registered my 160 Biosemi electrodes to the standard_bem >> template >> > (see attached picture). For the sourcemodel, I'm using the >> > standard_sourcemodel3d5mm grid (picture attached, overlaid on >> > standard_bem). I can prepare the leadfield from there with >> > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV >> tutorial. >> > > >> > > To test this configuration, I've selected a time window in >> my data >> > and averaged across it (the covariance matrix was also >> calculated); >> > the topography of this averaged data is attached. I then >> attempted a >> > source fit with the LCMV beamformer: >> > > >> > > cfg = []; >> > > cfg.method = 'lcmv'; >> > > cfg.grid = leadfield; >> > > cfg.vol = vol; >> > > cfg.elec = elec; >> > > cfg.lcmv.lambda = '15%'; >> > > cfg.lcmv.keepfilter = 'yes'; >> > > cfg.lcmv.fixedori = 'yes'; >> > > cfg.lcmv.projectnoise = 'yes'; >> > > >> > > sourceA = ft_sourceanalysis(cfg,A); >> > > >> > > After interpolating to the single_subj_T1.nii provided with >> > ft_sourceinterpolate and plotting with ft_sourceplot, I am >> given a >> > sourceplot that is highly focal in nature (see attached >> picture). >> > > >> > > I'd find it very surprising if this topography were generated >> > primarily by a source that isn't even inside the brain (as the >> > sourceplot indicates). So, I'm not sure exactly where/how I'm >> going >> > wrong with this one, nor am I sure how to trouble shoot it. Any >> > guidance you might provide would be greatly appreciated. >> > > >> > > Thanks so much, >> > > >> > > Tommy >> > > >> > > > > >> localization.PNG>____________________ >> ___________________________ >> > > fieldtrip mailing list >> > > fieldtrip at donders.ru.nl >> > >> > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > >> > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Attended.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Unattended.PNG Type: image/png Size: 91677 bytes Desc: not available URL: From suzannevdveldt at gmail.com Wed Jan 25 22:55:44 2017 From: suzannevdveldt at gmail.com (Suzanne van der Veldt) Date: Wed, 25 Jan 2017 16:55:44 -0500 Subject: [FieldTrip] extracting spikes from new Message-ID: Hello all, Sorry to trouble you. I am excited to get starting with using FieldTrip for my data analysis, using in vivo ephys data recorded with plexon. I have my sorted spikes in .nex format. Unfortunately, field trip does not seem to be able to import my data. >> [rec1] = ft_read_spike('test', 'plexon_nex', '/Users/username/Documents/export’) Error using ft_read_spike (line 276) unsupported data format (unknown The .nex file is a regular file. I am running Matlab R2015b from Mac OSx Sierra 10.12.2. I hope someone might be able to give me a hint of what might be the problem. Kind regards, Suzanne van der Veldt PhD student McGill & Université de Bordeaux From tfkustermann at gmail.com Thu Jan 26 17:34:11 2017 From: tfkustermann at gmail.com (Thomas Kustermann) Date: Thu, 26 Jan 2017 17:34:11 +0100 Subject: [FieldTrip] Source statistic issue - between trials In-Reply-To: References: Message-ID: Hey Michał, I think your problem lies within the use of "ft_statfun_depsamplesT". FieldTrip then assumes that each trial index from condition one is paired with the same trial index from condition two which is why you get the output "repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 " In your case the design matrix should only include your first row and no uvar, statfun being ft_statfun_indepsamplesT. See: http://www.fieldtriptoolbox.org/tutorial/cluster_permutation _freq#permutation_test Cheers On Tue, Jan 24, 2017 at 3:21 PM, Michał Komorowski wrote: > Dear community, > > Currently I am working on source analysis from EEG data. I have some > trouble using ft_sourcestatistics do a between-trials analysis (single > subject). > I am trying to compare source from trials from task type A (ctrl) to with > trials from task type B (task). Mainly I rely on > http://www.fieldtriptoolbox.org/example/source_statistics . > > For almost week I am trying find a solution, inculding testing > ft_sourcestatistics with different combinations of data: > 1) source 1 : no ft_sourcedescriptives and no ft_sourceinterpolate used > 2) source 2 : used ft_sourcedescriptives and no ft_sourceinterpolate used > 3) source 3 : used ft_sourcedescriptives and used ft_sourceinterpolate > > For cases 1) and 2) I get very similar errors "Invalid specification of > the design array. Error using ft_statistics_montecarlo (line 242) could not > determine the parametric critical value for clustering" (full error > messages at the bottom). In case 3) I cannot run ft_statistics because > there are no trials anymore. > I have tried changing design matrix, search community messages for some > advice and read related articles on fieldtriptoolbox site, but I have not > find the answer. > > Any help would be appreciated. > > Michał Komorowski > > > Statistics code: > > cfg = []; > %cfg.dim = source.dim; % there is no such field in the data > cfg.method = 'montecarlo'; > cfg.statistic = 'ft_statfun_depsamplesT'; > cfg.parameter = 'pow'; > cfg.correctm = 'cluster'; > cfg.numrandomization = 100; > cfg.alpha = 0.05; > cfg.correcttail = 'alpha'; % http://www.fieldtriptoolbox.or > g/faq/why_should_i_use_the_cfg.correcttail_option_when_using > _statistics_montecarlo > cfg.tail = 0; % two sided test > cfg.design(1,:) = design; % condition code > cfg.design(2,:) = [1:length(find(design==1)) 1:length(find(design==2))]; % > trial indices > cfg.uvar = 2; % unit of observation variable: trials > cfg.ivar = 1; % independent variable: condition code > % I think design matrix is ok according to: http://www.fieldtriptoolbox.or > g/walkthrough#paired_comparison) > > stat = ft_sourcestatistics(cfg, source); > > > > > Data structures and error messages > > Case 1) no ft_sourcedescriptives and no ft_sourceinterpolate used > > source = > > freq: 10 > cumtapcnt: [21x1 double] > inside: [231420x1 logical] > pos: [231420x3 double] > method: 'rawtrial' > trial: [1x21 struct] > df: 21 > cfg: [1x1 struct] > > the call to "ft_selectdata" took 1 seconds > using "ft_statistics_montecarlo" for the statistical testing > using connectivity of voxels in 3-D volume > using "ft_statfun_depsamplesT" for the single-sample statistics > constructing randomized design > total number of measurements = 21 > total number of variables = 2 > number of independent variables = 1 > number of unit variables = 1 > number of within-cell variables = 0 > number of control variables = 0 > using a permutation resampling approach > repeated measurement in variable 2 over 11 levels > number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 > computing a parametric threshold for clustering > Error using ft_statfun_depsamplesT (line 84) > Invalid specification of the design array. > Error using ft_statistics_montecarlo (line 242) > could not determine the parametric critical value for clustering > > Error in ft_sourcestatistics (line 205) > [stat, cfg] = statmethod(cfg, dat, design); > > >> cfg.design > > ans = > > 1 1 1 1 1 1 1 1 1 1 1 2 > 2 2 2 2 2 2 2 2 2 > 1 2 3 4 5 6 7 8 9 10 11 1 > 2 3 4 5 6 7 8 9 10 > > > > Case 2) used ft_sourcedescriptives and no ft_sourceinterpolate used > > source_app = > > freq: 10 > cumtapcnt: [21x1 double] > inside: [231420x1 logical] > pos: [231420x3 double] > method: 'rawtrial' > trial: [1x21 struct] > df: 21 > cfg: [1x1 struct] > > the call to "ft_selectdata" took 0 seconds > using "ft_statistics_montecarlo" for the statistical testing > using connectivity of voxels in 3-D volume > using "ft_statfun_depsamplesT" for the single-sample statistics > constructing randomized design > total number of measurements = 21 > total number of variables = 2 > number of independent variables = 1 > number of unit variables = 1 > number of within-cell variables = 0 > number of control variables = 0 > using a permutation resampling approach > repeated measurement in variable 2 over 11 levels > number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 > computing a parametric threshold for clustering > Error using ft_statfun_depsamplesT (line 84) > Invalid specification of the design array. > Error using ft_statistics_montecarlo (line 242) > could not determine the parametric critical value for clustering > > Error in ft_sourcestatistics (line 205) > [stat, cfg] = statmethod(cfg, dat, design); > > > > Case 3) used ft_sourcedescriptives and used ft_sourceinterpolate > > source_mri_align_ctrl = > > freq: 10 > anatomy: [128x128x128 double] > coordsys: 'spm' > dim: [128 128 128] > pos: [2097152x3 double] > transform: [4x4 double] > unit: 'mm' > inside: [128x128x128 logical] > pow: [2097152x1 double] > cfg: [1x1 struct] > > % there is no trials so one cannot conduct between-trials statistics ... > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behzadiravani at gmail.com Thu Jan 26 17:36:28 2017 From: behzadiravani at gmail.com (Behzad Iravani) Date: Thu, 26 Jan 2017 17:36:28 +0100 Subject: [FieldTrip] Symmetric Source Reconstruction Message-ID: Dear FieldTrip experts , I'm interested to perform symmetric source reconstruction on time lock data. However I encountered an error. here is my code: cfg = []; cfg.grid.unit = 'mm'; cfg.grid.resolution = 5; cfg.grid.tight = 'yes'; cfg.inwardshift = -2; cfg.headmodel = vol; cfg.symmetric ='y'; % symmetric sources grid = ft_prepare_sourcemodel(cfg); % timelock data for two conditions load timelockA %co-variance computed load timelockB %co-variance computed load timeloackAB %co-variance computed load elecfile.mat % sensor positions load vol.mat % pre-compute head model cfg = []; cfg.method = 'lcmv'; cfg.grid = grid; cfg.headmodel = vol; cfg.elec = elecfile; cfg.keepfilter = 'yes'; source = ft_sourceanalysis(timeloackAB); % compute common filter cfg.keepfilter = 'no'; cfg.grid.filter =source.avg.filter sourceA = ft_sourceanalysis(timeloackA); % compute common filter sourceB = ft_sourceanalysis(timeloackA); % compute common filter % Contrast Condition A versus B cfg = []; cfg.parameter = 'pow'; cfg.operation = '(x1./x2-1)'; SourceC= ft_math(cfg,sourceA ,sourceB); load mri.mat % load anatomical image cfg = []; cfg.parameter = 'pow'; sourcePostInt = ft_sourceinterpolate(cfg, SourceC ,mri); here I get error in ft_warp_apply because the grid.pos is 6*n which it is supposed to be 3*n, since I chose the symmetric option it turned to 6*n. How can I solve this problem? Thanks in advance Best Behzad -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.chait at ucl.ac.uk Thu Jan 26 18:11:34 2017 From: m.chait at ucl.ac.uk (Chait, Maria) Date: Thu, 26 Jan 2017 17:11:34 +0000 Subject: [FieldTrip] (deadline approaching) Post-Doc position at UCL Ear Institute Message-ID: (please forward) A postdoctoral research associate position is available at the UCL Ear Institute's 'Auditory Cognitive Neuroscience Lab'. The project, titled "How the brain detects patterns in sound sequences", will be supervised by Dr Maria Chait and conducted in collaboration with Dr. Marcus Pearce (Queen Mary University, London) and colleagues at the UCL Wellcome Trust centre for neuroimaging. The post is funded for 34 months in the first instance and involves a combination of behavioural, computational, eye tracking, and functional brain imaging (EEG, MEG, fMRI) experiments in humans. For more information about the post please see the lab website: http://www.ucl.ac.uk/ear/research/chaitlab/vacancies The Ear Institute is a leading interdisciplinary centre for hearing research in Europe, situated within one of the strongest neuroscience communities in the world at University College London Key Requirements The successful applicant will have a PhD in neuroscience or a neuroscience-related discipline and proven ability to conduct high-quality original research and prepare results for publication. Essential skills include excellent time-management and organizational ability; proficiency in computer programming and good interpersonal, oral and written communication skills. Previous experience with functional brain imaging, neural data analysis, psychophysical assessment, and/or auditory science or acoustics would be desirable. Further Details You should apply for this post (Ref #: 1618836) through UCL's online recruitment website, www.ucl.ac.uk/hr/jobs, where you can download a job description and person specifications. Closing Date for applications is: 1 Feb 2017 For an informal discussion please contact Dr. Maria Chait (m.chait at ucl.ac.uk). Maria Chait PhD m.chait at ucl.ac.uk Reader in Auditory Cognitive Neuroscience Lab site: http://www.ucl.ac.uk/ear/research/chaitlab/ UCL Ear Institute 332 Gray's Inn Road London WC1X 8EE -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.oostenveld at donders.ru.nl Fri Jan 27 08:45:20 2017 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Fri, 27 Jan 2017 08:45:20 +0100 Subject: [FieldTrip] Week-long summer course on data analysis in MATLAB References: Message-ID: <9640D9F6-AABC-4214-AE79-DC23FA95757A@donders.ru.nl> Dear FieldTrip users My colleague Mike X Cohen will be teaching a week-long course coming summer in Nijmegen, Netherlands, called "Math and Matlab for Neuroscientists." It is designed for PhDs/postdocs. He taught this course last year and it was very successful. See attached for details and feel free to distribute this flyer as you see fit. best regards, Robert PS we will also be organizing the "Advanced MEG/EEG analysis toolkit course” (a.k.a. the FieldTrip course) in spring of this year. Once the date for that has been settled, it will be announced on this email list and details will be posted on http://www.fieldtriptoolbox.org/workshop -------------- next part -------------- A non-text attachment was scrubbed... Name: MathMatlab_Radboud2017.pdf Type: application/pdf Size: 1403012 bytes Desc: not available URL: -------------- next part -------------- From tmadsen at emory.edu Fri Jan 27 17:44:31 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Fri, 27 Jan 2017 11:44:31 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis In-Reply-To: References: Message-ID: Yes, thank you! That's exactly what I was thinking - I'll be glad to have your paper to cite in my methods section. ;-) I'm forwarding your email back to the listserv and other interested parties for reference. Thanks, Teresa On Thu, Jan 26, 2017 at 10:07 AM, berry van den berg wrote: > Hi Teresa, > > Maybe the following helps to gain a bit more insight. > > Thanks for the interesting discussion. We recently published an article > using what you describe: the log(power) and subsequently z-scoring across > trials on each time/ freq point. See http://rdcu.be/oOjc > > For the frequency analysis we were mostly interested in prestimulus > activity related to RTs and time-in-session which basically makes the use > of a prestimulus baseline correction invalid. Using the log transformed > power and z-scoring those gave pretty solid model fits. > > The data is not completely normal yet but pretty close (see plot below, > which comes from the prestimulus period [-700 to stim onset] in the alpha > [8 to 14Hz] range). For fitting a linear (or nonlinear) model, log > transforming the data was a necessary step. > > [image: Inline images 1] > > > > > > > > > On 10 January 2017 at 21:01, Teresa Madsen wrote: > >> Thanks for the reference. In return, I also recommend reading Ciuparu >> and Mures an's recent rebuttal: >> >> European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, >> doi:10.1111/ejn.13179 >> TECHNICAL SPOTLIGHT >> Sources of bias in single-trial normalization procedures >> >> They demonstrate that the positive bias Grandchamp and Delorme warned >> about with single-trial baseline normalization was, in fact, due to the >> correlated numerators and denominators in each of the baseline >> normalization procedures they tested, which was, in turn, caused by the >> skewed distributions of baseline power values. They demonstrate that this >> bias is reduced by using a much longer baseline, ideally incorporated into >> the experimental design, but when that's not possible, stitching together >> the baselines of many trials. >> >> Neither article addresses my specific question of whether it would be >> even better to log-transform the raw power values before averaging, so I >> suppose I'll have to test it myself and write my own methods article! 🤓 >> >> I will go ahead and incorporate some of these alternative baseline >> normalization methods in my git fork of FieldTrip as I go along with my own >> analyses, so let me know if anyone else would find them useful, and I'll >> submit a pull request to contribute them to the master branch. >> >> Thanks for the fruitful discussion, all! >> ~Teresa >> >> >> On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: >> >>> Indeed, in a separate thread with Michael Cohen several months back he >>> suggested precisely that paper. >>> >>> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" < >>> nick.peatfield at gmail.com> wrote: >>> >>>> I think this paper is relevant to this discussion. >>>> >>>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >>>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>>> >>>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>>> >>>> >>>> >>>> On 19 December 2016 at 13:08, Teresa Madsen wrote: >>>> >>>>> I appreciate everyone's feedback, but I still wonder if something is >>>>> being missed. I understand that the non-normally distributed power values >>>>> may be less of an issue when performing non-parametric stats or even a >>>>> paired-samples t-test that looks at difference values which may be normal >>>>> even when the raw data isn't. However, my concern comes into play even >>>>> before these statistical comparisons are made, whenever any averaging is >>>>> done to freq-type data across times, frequencies, trials, electrodes, >>>>> subjects, etc. That means any time any of these configuration options are >>>>> used for any of these functions, and probably more: >>>>> >>>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>>> cfg.avgoverfreq = 'yes'; >>>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>>> >>>>> In each case, if raw power values are averaged, the result will be >>>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>>> treated identically, but the specific case that triggered my concern was in >>>>> ft_freqbaseline, where the individual time-frequency bins are compared to >>>>> the mean over time for the baseline period. For example, when using >>>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>>>> data does indeed have a more normal distribution over time, but the mean >>>>> over the baseline time period is performed *before* the log transform, when >>>>> the distribution is still highly skewed: >>>>> >>>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>>> size(data, 3)]); >>>>> data = 10*log10(data ./ meanVals); >>>>> >>>>> That's what I had originally done when analyzing data for my SfN >>>>> poster, when I realized the background noise that shouldn't have changed >>>>> much from baseline was mostly showing a decrease from baseline of about >>>>> -3dB. >>>>> >>>>> Now, I've realized I'm seeing this as more of a problem than others >>>>> because of another tweak I made, which was to use a long, separate baseline >>>>> recording to normalize my trial data, rather than a short pre-trial period >>>>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>>>> for a baseline power estimate might be okay because overlapping time points >>>>> in the original data are used to calculate those power values anyway, >>>>> probably making them less skewed, but also (it seems to me) more arbitrary >>>>> and prone to error. I already offered my custom function BLnorm.m to one >>>>> person who was asking about this issue of normalizing to a separate >>>>> baseline recording, and I would be happy to contribute it to FieldTrip if >>>>> others would appreciate it. >>>>> >>>>> Since a few people suggested using the median, and it is also >>>>> suggested in Cohen's textbook >>>>> as >>>>> an alternative measure of the central tendency for skewed raw power values, >>>>> I wonder if the simplest fix might be to add an option to select mean or >>>>> median in each of the functions listed above. Another possibility would be >>>>> adding an option to transform the power values upon output from >>>>> ft_freqanalysis. >>>>> >>>>> Would anyone else find such changes useful? >>>>> >>>>> Thanks, >>>>> Teresa >>>>> >>>>> >>>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>>> J.Herring at donders.ru.nl> wrote: >>>>> >>>>>> In terms of statistics it is the distribution of values that you do >>>>>> the statistics on that matters. In case of a paired-samples t-test when >>>>>> comparing two conditions, it is the distribution of difference values that >>>>>> has to be normally distributed. The distribution of difference values is >>>>>> often normal given two similarly non-normal distributions, offering no >>>>>> complications for a regular parametric test. >>>>>> >>>>>> >>>>>> >>>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>>> normality, so you should have no problem there either. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* fieldtrip-bounces at science.ru.nl [mailto: >>>>>> fieldtrip-bounces at science.ru.nl] *On Behalf Of *Alik Widge >>>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>>> *To:* FieldTrip discussion list >>>>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>>> data analysis >>>>>> >>>>>> >>>>>> >>>>>> In this, Teresa is right and we have observed this in our own EEG >>>>>> data -- depending on one's level of noise and number of trials/patients, >>>>>> the mean can be a very poor estimator of central tendency. My students are >>>>>> still arguing about what we really want to do with it, but at least one of >>>>>> them has shifted to using the median as a matter of course for baseline >>>>>> normalization. >>>>>> >>>>>> >>>>>> Alik Widge >>>>>> alik.widge at gmail.com >>>>>> (206) 866-5435 >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> That may very well be true; to be honest, I haven't looked that >>>>>> deeply into the stats offerings yet. However, my plan is to express each >>>>>> electrode's experimental data in terms of change from their respective >>>>>> baseline recordings before attempting any group averaging or statistical >>>>>> testing, and this problem shows up first in the baseline correction step, >>>>>> where FieldTrip averages raw power over time. >>>>>> >>>>>> ~Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com> wrote: >>>>>> >>>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>>> statistics implemented by fieldtrip, the data does not need to be normally >>>>>> distributed. >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 13:39, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>>>> across frequencies, but the distribution across time (and according to the >>>>>> poster, also across space), also has an extremely skewed, negative >>>>>> exponential distribution. I probably confused everyone by trying to show >>>>>> too much data in my figure, but each color represents the distribution of >>>>>> power values for a single frequency over time, using a histogram and a line >>>>>> above with circles at the mean +/- one standard deviation. >>>>>> >>>>>> My main point was that the mean is not representative of the central >>>>>> tendency of such an asymmetrical distribution of power values over time. >>>>>> It's even more obvious which is more representative of their actual >>>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>>>> busy and confusing. >>>>>> >>>>>> I hope that helps, >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com> wrote: >>>>>> >>>>>> Hi Teresa, >>>>>> >>>>>> >>>>>> >>>>>> I think what you are discussing is the 1/f power scaling of the power >>>>>> spectrum. This is one of the reasons that comparisons are made within >>>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>>>> as such the assumption is that within bands there should be a relative >>>>>> change against baseline and this is what the statistics are performed on. >>>>>> That is, baseline correction is assumed to be the mean for a specific >>>>>> frequency and not a mean across frequencies. >>>>>> >>>>>> >>>>>> >>>>>> And this leads to another point that when you are selecting a >>>>>> frequency range to do the non-parametric statistics on you should not do >>>>>> 1-64 Hz but break it up based on the bands. >>>>>> >>>>>> >>>>>> >>>>>> Hope my interpretation of your point is correct. I sent in >>>>>> individually, as I wanted to ensure I followed your point. >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 08:23, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> FieldTrippers, >>>>>> >>>>>> >>>>>> >>>>>> While analyzing my data for the annual Society for Neuroscience >>>>>> meeting, I developed a concern that was quickly validated by another poster >>>>>> (full abstract copied and linked below) focusing on the root of the >>>>>> problem: neural oscillatory power is not normally distributed across time, >>>>>> frequency, or space. The specific problem I had encountered was in >>>>>> baseline-correcting my experimental data, where, regardless of >>>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>>> However, I found that the distribution of raw power over time is so skewed >>>>>> that the mean was not a reasonable approximation of the central tendency of >>>>>> the baseline power, so it made most of my experimental data look like it >>>>>> had decreased power compared to baseline. The more I think about it, the >>>>>> more I realize that averaging is everywhere in the way we analyze neural >>>>>> oscillations (across time points, frequency bins, electrodes, trials, >>>>>> subjects, etc.), and many of the standard statistics people use also rely >>>>>> on assumptions of normality. >>>>>> >>>>>> >>>>>> >>>>>> The most obvious solution for me was to log transform the data first, >>>>>> as it appears to be fairly log normal, and I always use log-scale >>>>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>>>> that this would at least "restore (some) symmetry to the error >>>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>>> differentiate from the standard decibel transform included in FieldTrip as >>>>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>>>> across several frequency bands (using power values from a wavelet >>>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>>> cortex). The lines at the top represent the mean +/- one standard >>>>>> deviation for each frequency band, and you can see how those descriptive >>>>>> stats are much more representative of the actual distributions in the log >>>>>> scale. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ​​ >>>>>> >>>>>> For my analysis, I also calculated a z-score on the log transformed >>>>>> power to assess how my experimental data compared to the variability of the >>>>>> noise in a long baseline recording from before conditioning, rather than a >>>>>> short pre-trial baseline period, since I find that more informative than >>>>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>>>> functions I wrote for this if people think it would be a useful addition to >>>>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>>>> poster, if anyone wants more detail - I just didn't want to make this email >>>>>> too big. >>>>>> >>>>>> >>>>>> >>>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>>> address this. I searched the wiki >>>>>> , listserv >>>>>> >>>>>> archives >>>>>> , >>>>>> and bugzilla >>>>>> for >>>>>> anything related and came up with a few topics surrounding normalization >>>>>> and baseline correction, but only skirting this issue. It seems important, >>>>>> so I want to find out whether others agree with my approach or already have >>>>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>>>> be changed or just documentation added, or what? >>>>>> >>>>>> >>>>>> >>>>>> Thanks for any insights, >>>>>> >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>>> across time >>>>>> >>>>>> >>>>>> *Authors* >>>>>> >>>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>>> Cognitive Sci., UCSD, San Diego, CA >>>>>> >>>>>> *Disclosures* >>>>>> >>>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>>> >>>>>> *Abstract* >>>>>> >>>>>> Neural oscillations are important in organizing activity across the >>>>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>>>> to numerous disease states. Oscillations are known to vary by frequency and >>>>>> amplitude across time and between different brain regions; however, this >>>>>> variability has never been well characterized. We examined human and animal >>>>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>>> distribution of power and frequency across time, space and species. We >>>>>> report that between data types, subjects, frequencies, electrodes, and >>>>>> time, an inverse power law, or negative exponential distribution, is >>>>>> present in all recordings. This is contrary to, and not compatible with, >>>>>> the Gaussian noise assumption made in many digital signal processing >>>>>> techniques. The statistical assumptions underlying common algorithms for >>>>>> power spectral estimation, such as Welch's method, are being violated >>>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>>> statistical approaches are warranted. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Teresa E. Madsen, PhD >>>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>>> analysis >>>>>> >>>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>>> Yerkes National Primate Research Center >>>>>> >>>>>> Emory University >>>>>> >>>>>> Rainnie Lab, NSB 5233 >>>>>> 954 Gatewood Rd. NE >>>>>> Atlanta, GA 30329 >>>>>> >>>>>> (770) 296-9119 >>>>>> >>>>>> braingirl at gmail.com >>>>>> >>>>>> https://www.linkedin.com/in/temadsen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Teresa E. Madsen, PhD >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> Emory University >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> (770) 296-9119 >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> >>>> >>>> -- >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Teresa E. Madsen, PhD >> Division of Behavioral Neuroscience and Psychiatric Disorders >> Yerkes National Primate Research Center >> Emory University >> Rainnie Lab, NSB 5233 >> 954 Gatewood Rd. NE >> Atlanta, GA 30329 >> (770) 296-9119 >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Berry van den Berg > email: berryv.dberg at gmail.com > website: berryvdberg.org > mobile: +31612585275 <+31%206%2012585275> > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 30063 bytes Desc: not available URL: From seymourr at aston.ac.uk Sun Jan 29 13:05:23 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Sun, 29 Jan 2017 12:05:23 +0000 Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing Message-ID: Dear FT Users, I am currently writing a function where ft_preprocessing is called iteratively; however computation is being slowed down by the display of text/output in the MATLAB command window (e.g. "the input is raw data with 1 channel and 62 trials"). Apart from hard-coding, I was wondering if there was an option to turn off logging in the FT code? Many thanks, Robert Seymour (PhD Student, Aston Brain Centre) -------------- next part -------------- An HTML attachment was scrubbed... URL: From leventmeister at gmail.com Sun Jan 29 18:25:34 2017 From: leventmeister at gmail.com (Levent Kandemir) Date: Sun, 29 Jan 2017 20:25:34 +0300 Subject: [FieldTrip] Fwd: Partial Source Model In-Reply-To: References: Message-ID: Hello, I calculate coherence from HCP data using http://www. fieldtriptoolbox.org/tutorial/beamformer but I get results as below; [image: Satır içi resim 1] What do you think the problem is? Thanks in advance, Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 133674 bytes Desc: not available URL: From ekenaykut at gmail.com Sun Jan 29 19:10:44 2017 From: ekenaykut at gmail.com (Aykut Eken) Date: Sun, 29 Jan 2017 21:10:44 +0300 Subject: [FieldTrip] Fwd: Partial Source Model In-Reply-To: References: Message-ID: <2AF1E465-2408-41E8-ADAF-05F74D997F1E@gmail.com> You can change the scale of color map or your data may be noisy. > On 29 Jan 2017, at 20:25, Levent Kandemir wrote: > > > Hello, > > I calculate coherence from HCP data using http://www.fieldtriptoolbox.org/tutorial/beamformer but I get results as below; > > > > What do you think the problem is? > > Thanks in advance, > Best regards, > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.urai at gmail.com Mon Jan 30 10:36:09 2017 From: anne.urai at gmail.com (Anne Urai) Date: Mon, 30 Jan 2017 10:36:09 +0100 Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing In-Reply-To: References: Message-ID: Hi Robert, many FieldTrip functions have the (sometimes undocumented) input option cfg.feedback. When set to 'none', output in the command line is suppressed. — Anne E. Urai, MSc PhD student | Institut für Neurophysiologie und Pathophysiologie Universitätsklinikum Hamburg-Eppendorf | Martinistrasse 52, 20246 | Hamburg, Germany www.anneurai.net / @AnneEUrai From: Seymour, Robert (Research Student) Reply: FieldTrip discussion list Date: 29 January 2017 at 13:05:23 To: fieldtrip at science.ru.nl Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing Dear FT Users, I am currently writing a function where ft_preprocessing is called iteratively; however computation is being slowed down by the display of text/output in the MATLAB command window (e.g. "the input is raw data with 1 channel and 62 trials"). Apart from hard-coding, I was wondering if there was an option to turn off logging in the FT code? Many thanks, Robert Seymour (PhD Student, Aston Brain Centre) _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.patai at ucl.ac.uk Mon Jan 30 14:27:22 2017 From: e.patai at ucl.ac.uk (Zita Eva Patai) Date: Mon, 30 Jan 2017 13:27:22 +0000 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data Message-ID: Dear FT-ers, I have an obvious question, but would still appreciate input from those more wise than myself: Can I put any sort of confound in to regress out of my data? For example things relating to -eye-movements (ICA done but I still have obvious condition differences) -experimentally uncontrolled stimulus changes -or any other environmental effects i'd like to control for Thank you zita -- Eva Zita Patai, DPhil Postdoctoral Researcher Institute of Behavioural Neuroscience UCL -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmadsen at emory.edu Mon Jan 30 17:30:30 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Mon, 30 Jan 2017 11:30:30 -0500 Subject: [FieldTrip] extracting spikes from new Message-ID: Suzanne, I think it may be a simple error in the way you formatted the inputs to that command. According to the help comments at the beginning of the function: % Use as % [spike] = ft_read_spike(filename, ...) % % Additional options should be specified in key-value pairs and can be % 'spikeformat' = string, described the fileformat (default is automatic) I don't see any other input arguments being used, so I'm assuming your 1st argument is the filename and guessing your 3rd argument is its location? If so, the correct format would be: >> [rec1] = ft_read_spike('/Users/username/Documents/export/test.nex'); Including the .nex extension in the filename will allow ft_filetype to automatically detect the format as 'plexon_nex', so you don't need to specify a spikeformat, but if that doesn't work for some reason, I believe the correct formatting (what is meant by key-value pairs) would be: >> [rec1] = ft_read_spike('test', 'spikeformat', 'plexon_nex’); If neither of those work, I'd be happy to help you troubleshoot this further, as I also use Plexon for data acquisition, have been working on improving FieldTrip's NEX handling, and will be moving into spike analysis soon. Let me know if that helps. ~Teresa On Wed, Jan 25, 2017 at 4:55 PM, Suzanne van der Veldt < suzannevdveldt at gmail.com> wrote: > Hello all, > > Sorry to trouble you. I am excited to get starting with using FieldTrip > for my data analysis, using in vivo ephys data recorded with plexon. I have > my sorted spikes in .nex format. Unfortunately, field trip does not seem to > be able to import my data. > > >> [rec1] = ft_read_spike('test', 'plexon_nex', '/Users/username/Documents/ > export’) > Error using ft_read_spike (line 276) > unsupported data format (unknown > > The .nex file is a regular file. I am running Matlab R2015b from Mac OSx > Sierra 10.12.2. > > I hope someone might be able to give me a hint of what might be the > problem. > > Kind regards, > Suzanne van der Veldt > > PhD student McGill & Université de Bordeaux > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.stolk8 at gmail.com Mon Jan 30 19:00:44 2017 From: a.stolk8 at gmail.com (Arjen Stolk) Date: Mon, 30 Jan 2017 10:00:44 -0800 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data In-Reply-To: References: Message-ID: Dear Zita, The short answer is yes, as you guessed already. Ideally, the confound is measured independently from the dependent measure, e.g. eye tracker activity to filter against eye movement related confounds in neural activity. But in the past we've also successfully regressed out eye movement related contributions as captured with EOG from frontal (source-reconstructed) neural activity, despite that both signals may have been partially correlated due to field spread. See 'General assessments of neurophysiologic data' & Fig S3 of this pdf: http://www.pnas.org/content/suppl/2013/08/16/1303170110.DCSupplemental/pnas.201303170SI.pdf The same principle that underlies head movement compensation thus also holds for other potential confounds, including the ones mentioned by you. Best, Arjen 2017-01-30 5:27 GMT-08:00 Zita Eva Patai : > Dear FT-ers, > > I have an obvious question, but would still appreciate input from those > more wise than myself: > > Can I put any sort of confound in to regress out of my data? For example > things relating to > > -eye-movements (ICA done but I still have obvious condition differences) > -experimentally uncontrolled stimulus changes > -or any other environmental effects i'd like to control for > > Thank you > zita > > > -- > Eva Zita Patai, DPhil > Postdoctoral Researcher > Institute of Behavioural Neuroscience > UCL > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.patai at ucl.ac.uk Mon Jan 30 21:50:45 2017 From: e.patai at ucl.ac.uk (Zita Eva Patai) Date: Mon, 30 Jan 2017 20:50:45 +0000 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data In-Reply-To: References: Message-ID: That's great thank you Arjen! On Mon, Jan 30, 2017 at 6:00 PM, Arjen Stolk wrote: > Dear Zita, > > The short answer is yes, as you guessed already. Ideally, the confound is > measured independently from the dependent measure, e.g. eye tracker > activity to filter against eye movement related confounds in neural > activity. But in the past we've also successfully regressed out eye > movement related contributions as captured with EOG from frontal > (source-reconstructed) neural activity, despite that both signals may have > been partially correlated due to field spread. See 'General assessments of > neurophysiologic data' & Fig S3 of this pdf: > http://www.pnas.org/content/suppl/2013/08/16/1303170110. > DCSupplemental/pnas.201303170SI.pdf > The same principle that underlies head movement compensation thus also > holds for other potential confounds, including the ones mentioned by you. > > Best, > Arjen > > > > 2017-01-30 5:27 GMT-08:00 Zita Eva Patai : > >> Dear FT-ers, >> >> I have an obvious question, but would still appreciate input from those >> more wise than myself: >> >> Can I put any sort of confound in to regress out of my data? For example >> things relating to >> >> -eye-movements (ICA done but I still have obvious condition differences) >> -experimentally uncontrolled stimulus changes >> -or any other environmental effects i'd like to control for >> >> Thank you >> zita >> >> >> -- >> Eva Zita Patai, DPhil >> Postdoctoral Researcher >> Institute of Behavioural Neuroscience >> UCL >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Eva Zita Patai, DPhil Postdoctoral Researcher Institute of Behavioural Neuroscience UCL -------------- next part -------------- An HTML attachment was scrubbed... URL: From alba.xifraporxas at mail.mcgill.ca Mon Jan 30 22:53:38 2017 From: alba.xifraporxas at mail.mcgill.ca (Alba Xifra Porxas, Ms) Date: Mon, 30 Jan 2017 21:53:38 +0000 Subject: [FieldTrip] Error reading fif file during ft_read_headshape Message-ID: Dear FieldTrippers, My name is Alba Xifra Porxas and I am working in the Biosignals and Systems Analysis Lab at McGill University. Currently I am analyzing MEG data from a motor-task paradigm from young and elderly subjects. I am following the tutorial: Source reconstruction of event-related fields using minimum-norm estimate (http://fieldtrip.fcdonders.nl/tutorial/minimumnormestimate). I am having problems reading the downsampled mesh from MNE suite. When I call FT_READ_HEADSHAPE, I receive the following error message: >> sourcespace = ft_read_headshape('s003-oct-6-src.fif', 'format', 'mne_source'); Error using fiff_read_tag (line 178) Only two and three dimensional matrices are supported at this time Error in mne_read_source_spaces/read_source_space/find_tag (line 288) tag = fiff_read_tag(fid,node.dir(p).pos); Error in mne_read_source_spaces/read_source_space (line 254) tag2 = find_tag(this,FIFF.FIFF_MNE_SOURCE_SPACE_NEAREST_DIST); Error in mne_read_source_spaces (line 111) this = read_source_space(spaces(k)); Error in ft_read_headshape (line 391) src = mne_read_source_spaces(filename, 1); However, I can visualize it correctly in MNE. The command I used to create the source space is: mne_setup_source_space --ico -6. Since I have the meshes from FreeSurfer, I tried a workaround. I call FT_READ_HEADSHAPE using lh.orig and rh.orig, which works. I successfully coregister the source space with the sensor-space and compute source reconstruction using minimum-norm estimation. However, when I try to downsample the output of FT_SOURCEANALYSIS calling FT_VOLUMEDOWNSAMPLE before parcellation, I receive the following error: Reference to non-existent field 'dim'. Error in ft_volumedownsample (line 100) xsel = 1:cfg.downsample:source.dim(1); Even if I manually introduce this missing field 'dim', it seems the number of vertices is too big: >> source.dim(1) = length(source.pos);source.dim(2) = length(source.pos);source.dim(3) = length(source.pos); >> cfg = [];cfg.downsample = 4;source_down = ft_volumedownsample(cfg,source); Error using repmat Maximum variable size allowed by the program is exceeded. Error in ndgrid (line 73) varargout{i} = repmat(x,s); Error in pos2transform (line 25) [X,Y,Z] = ndgrid(x, y, z); Error in ft_checkdata>source2volume (line 1286) data.transform = pos2transform(data.pos, data.dim); Error in ft_checkdata (line 350) data = source2volume(data); Error in ft_volumedownsample (line 69) source = ft_checkdata(source, 'datatype', 'volume', 'feedback', 'no'); The source I use is as follows: >> display(source) source = time: [1x3900 double] inside: [255462x1 logical] pos: [255462x3 double] method: 'average' avg: [1x1 struct] cfg: [1x1 struct] dim: [255462 255462 255462] Therefore, I am back to where I started. I need to read the fif file from MNE suite. I uploaded my fif file in Dropbox. Here is the link: https://www.dropbox.com/sh/uq181l76353hd8q/AACjTu8KI_rGaXlaDMyw-Diba?dl=0 Could someone tell me if there is something wrong with the file or with my workaround? Any help would be really appreciated. I am using Fieldtrip version 20170118. Best, Alba Xifra Porxas PhD student, Biosignals and Systems Analysis Lab McGill University, Montréal, Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From timeehan at gmail.com Mon Jan 30 23:10:40 2017 From: timeehan at gmail.com (Tim Meehan) Date: Mon, 30 Jan 2017 17:10:40 -0500 Subject: [FieldTrip] preprocessing procedures for ECoG/iEEG data Message-ID: Hello all, I am a new user of fieldtrip and new to analyzing electrophysiological data. I have familiarized myself with some basics of preprocessing of EEG data, but I would like to know if there are special considerations for dealing with ECoG/iEEG data -- our dataset has recordings from both subdural surface electrodes and depth electrodes, sampled at 2kHz. We are initially most interested in extracting the high-gamma band (70-150 Hz) envelope as a measure of local activity. First a general question: is there anyone who could point me to or provide me with a preprocessing procedure in fieldtrip that is tailored for ECoG/iEEG? I've perused the ECoG section in the wiki but there is no information on preprocessing there. If this is too vague, some specific questions I have are: 1) What cutoffs do people tend to use for low and high-pass filters? 2) What is your choice for re-referencing, if any? Our initial reference/ground are the left and right mastoids. I have seen papers that re-reference to the nearest neighbor. I think I need to use ft_apply_montage to do this, but beyond that I could use some guidance. 3) At what point do you epoch into trials? My guess is after high/low-pass filtering and re-referencing but before artifact detection and removal? Any feedback on these would be very much appreciated. If you need more details please let me know. Thanks! Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielle.farrar at gmail.com Tue Jan 31 17:40:14 2017 From: danielle.farrar at gmail.com (Danielle Farrar) Date: Tue, 31 Jan 2017 11:40:14 -0500 Subject: [FieldTrip] Starting at ft_timelockstatistics Message-ID: Hello, My apologies if this has been covered before, I just joined the list and am having trouble searching the archives. I have a set of EEG data that was recorded from a Biosemi apparatus using a 128-channel cap. The dataset is in text files, is post-processed and is the result of filtering, epoching, and averaging, and has been imported into matlab. I created trial structs out of the datasets. It is a dataset of 21 subjects with two conditions. I'm trying to do some non-parametric clustering statistics on the dataset and I don't have access to the original bdf files. I have the electrode names and coordinates saved in matlab matrices. Now, I'd like to do clustering analysis using a monte carlo simulation to determine areas of significant differences between the two conditions, but am having trouble ensuring that my datasets are structured appropriately for input. It seems that the tutorials mostly assume that the data is in a raw output format from one of the systems. I know that for ft_timelockstatistics, the data is supposed to be output from the ft_timelockanalysis. I was trying to use ft_timelockanalysis as an entry point However, I am having trouble constructing the data struct appropriate for the timelock function. Can this be done? Should I be starting further upstream? I'm attaching some of the code. I'm know the data struct needs additional information but am not sure how to go about using it. The error I get when I run the following code is "Error using ft_checkdata (line 480). This function requires raw+comp or raw data as input." Thanks! Danielle ******************************** for i=size(CD_condition.data,3), CD_trial{i} = CD_condition.data(:,:,i); end CD.trial = CD_trial; cfg.channel = 'all'; cfg.trials = 'all'; cfg.covariance = 'yes'; cfg.covariancewindow = 'prestim'; cfg.removemean = 'yes'; cfg.vartrllength = 0; CD.type = 'raw+comp'; ft_timelockanalysis(cfg,CD); -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 12:41:56 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 11:41:56 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* From jan.schoffelen at donders.ru.nl Mon Jan 2 12:50:28 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Mon, 2 Jan 2017 11:50:28 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> Message-ID: Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From mehmetakifozcoban at gmail.com Mon Jan 2 13:05:52 2017 From: mehmetakifozcoban at gmail.com (=?UTF-8?B?TWVobWV0IEFraWYgw5Z6w6dvYmFu?=) Date: Mon, 2 Jan 2017 15:05:52 +0300 Subject: [FieldTrip] Whole band EEG Message-ID: ​Dear filedtripper and professors; How can İ intepret the phase scores in whole (full-0.5-50Hz) EEG band... Please can you help me with tutorial or paper about significant of whole EEG band​ -- Mehmet Akif ÖZÇOBAN Cd.PhD. Istanbul University -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 13:20:07 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 12:20:07 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de>, Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From michelic72 at gmail.com Mon Jan 2 13:43:57 2017 From: michelic72 at gmail.com (Cristiano Micheli) Date: Mon, 2 Jan 2017 13:43:57 +0100 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> Message-ID: Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: *Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)};* might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option *dbstop if error *(toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus wrote: > Dear Jan-Mathijs, > > thank you for you fast reply. But unfortunately, removing the fields does > not change the error message et all. > > Best, > Markus > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > > ________________________________________ > Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" > im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [ > jan.schoffelen at donders.ru.nl] > Gesendet: Montag, 2. Januar 2017 12:50 > An: FieldTrip discussion list > Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source > input data > > Markus, > > Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again > please? > Thanks, > BW, > JM > > > J.M.Schoffelen > Senior Researcher, VIDI-fellow > Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > > > > > > > > On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: > > > > > > Dear Fieldtrippers, > > > > > > happy new year to everyone here! > > > > This is the second attempt to get help on an issue with > ft_sourcestatistics. As I still can not figure out where the problem > resides, I give it a new try. > > > > My goal is to use a common DICS filter to reconstruct single-trial data > in three conditions. Afterwards, I want to run a test for a linear effect > across the conditions. I thought to follow closely the descriptions in > http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , > especially in the way I extract the single-trial data. However, when I run > ft_sourcestatistics, the single trial source data is not recognized as > source data ... > > > > Any ideas on what went wrong? > > > > Below is the code and error-messages: > > > > > > > > When I run the code below: > > > > %----------------------------------------------------------- > ----------------------------------------------- > > src_descrcfg = []; > > src_descrcfg.keeptrials = 'yes'; > > src00 = ft_sourcedescriptives(src_descrcfg,src00); > > src01 = ft_sourcedescriptives(src_descrcfg,src01); > > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > > > > src_statscfg = []; > > src_statscfg.parameter = 'trial.pow'; > > src_statscfg.method = 'analytic'; > > src_statscfg.statistic = 'indepsamplesregrT'; > > src_statscfg.alpha = 0.05; > > src_statscfg.correctm = 'no'; > > > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) > 3*ones(1,src11.df)]; > > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the > independent variable > > > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > > %----------------------------------------------------------- > ----------------------------------------------- > > > > I get the following output and error message: > > > > original data contained 201 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 48 MB > > original data contained 113 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 0 MB > > original data contained 46 trials > > the call to "ft_sourcedescriptives" took 0 seconds and required the > additional allocation of an estimated 0 MB > > Index exceeds matrix dimensions. > > > > Error in ft_datatype_source (line 187) > > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > > > Error in ft_checkdata (line 251) > > data = ft_datatype_source(data); > > > > Error in ft_sourcestatistics (line 100) > > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', > 'feedback', 'no'); > > > > > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with > the following content: > > > > > > src00 = > > > > freq: 9.7656 > > cumtapcnt: [201x1 double] > > dim: [27 36 30] > > inside: [29160x1 logical] > > pos: [29160x3 double] > > method: 'rawtrial' > > trial: [1x201 struct] > > df: 201 > > cfg: [1x1 struct] > > sampleinfo: [201x2 double] > > rating: [201x2 double] > > stim: {201x3 cell} > > > > > > The source-solutions were based on a common dics-filter after running > the following code: > > > > %----------------------------------------------------------- > ----------------------------------------------- > > % compute single trial spectra > > mtmfftcfg.keeptrials = 'yes'; > > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > > > % project all trials through common spatial filter % > > dics_alltrl_cfg = []; > > dics_alltrl_cfg = dics_commoncfg; > > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common > filter computed in the previous step! > > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial > through the filter. Only necessary if you are interested in reconstructing > single trial data > > > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % > contains the source estimates for all trials/both > > %----------------------------------------------------------- > ----------------------------------------------- > > > > > > Any ideas, why the data is not recognized as source-data when calling > ft_sourcestatistics (obviously it is recognized correctly with > ft_sourcedescriptives ...). > > > > > > Thank you very much for your help. > > > > Best regards, > > Markus > > > > > > > > ********************************************************************* > > Dr. Markus Werkle-Bergner, Dipl. Psych. > > Senior Research Scientist (W2) > > > > Jacobs Foundation Research Fellow 2017-2019 > > > > Max Planck Institute for Human Development > > Center for Lifespan Psychology > > > > Lentzeallee 94, 14195 Berlin > > > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > > Mail: werkle at mpib-berlin.mpg.de > > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > > ********************************************************************* > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 14:03:23 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 13:03:23 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de>, Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: >> src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] >> src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: > > > Dear Fieldtrippers, > > > happy new year to everyone here! > > This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. > > My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... > > Any ideas on what went wrong? > > Below is the code and error-messages: > > > > When I run the code below: > > %---------------------------------------------------------------------------------------------------------- > src_descrcfg = []; > src_descrcfg.keeptrials = 'yes'; > src00 = ft_sourcedescriptives(src_descrcfg,src00); > src01 = ft_sourcedescriptives(src_descrcfg,src01); > src11 = ft_sourcedescriptives(src_descrcfg,src11); > > > src_statscfg = []; > src_statscfg.parameter = 'trial.pow'; > src_statscfg.method = 'analytic'; > src_statscfg.statistic = 'indepsamplesregrT'; > src_statscfg.alpha = 0.05; > src_statscfg.correctm = 'no'; > > src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; > src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable > > src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); > %---------------------------------------------------------------------------------------------------------- > > I get the following output and error message: > > original data contained 201 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB > original data contained 113 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > original data contained 46 trials > the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB > Index exceeds matrix dimensions. > > Error in ft_datatype_source (line 187) > val{indx(k)}(1,:,:,:) = dat{indx(k)}; > > Error in ft_checkdata (line 251) > data = ft_datatype_source(data); > > Error in ft_sourcestatistics (line 100) > varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); > > > > src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: > > > src00 = > > freq: 9.7656 > cumtapcnt: [201x1 double] > dim: [27 36 30] > inside: [29160x1 logical] > pos: [29160x3 double] > method: 'rawtrial' > trial: [1x201 struct] > df: 201 > cfg: [1x1 struct] > sampleinfo: [201x2 double] > rating: [201x2 double] > stim: {201x3 cell} > > > The source-solutions were based on a common dics-filter after running the following code: > > %---------------------------------------------------------------------------------------------------------- > % compute single trial spectra > mtmfftcfg.keeptrials = 'yes'; > mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); > > % project all trials through common spatial filter % > dics_alltrl_cfg = []; > dics_alltrl_cfg = dics_commoncfg; > dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! > dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data > > tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both > %---------------------------------------------------------------------------------------------------------- > > > Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). > > > Thank you very much for your help. > > Best regards, > Markus > > > > ********************************************************************* > Dr. Markus Werkle-Bergner, Dipl. Psych. > Senior Research Scientist (W2) > > Jacobs Foundation Research Fellow 2017-2019 > > Max Planck Institute for Human Development > Center for Lifespan Psychology > > Lentzeallee 94, 14195 Berlin > > Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 > Mail: werkle at mpib-berlin.mpg.de > http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner > ********************************************************************* > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Mon Jan 2 14:17:35 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Mon, 2 Jan 2017 13:17:35 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de> Message-ID: <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> Markus, Can you switch off the ‘keepfilter’ option before you do the ‘rawtrial’ business? The error context suggests that MATLAB tries to allocate data to a cell-array, which is probably the spatial filter (or possibly the label). Since this information is not needed for the statistical inference, you can discard it. Best, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 14:03, Werkle, Markus > wrote: Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Mon Jan 2 15:09:07 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Mon, 2 Jan 2017 14:09:07 +0000 Subject: [FieldTrip] ft_sourcestatistics does not recognize source input data In-Reply-To: <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> References: <4C4CCFA964C0894591C5AB8330717647BBA5F5A0@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F5C7@MaxMail04.mpib-berlin.mpg.de> <4C4CCFA964C0894591C5AB8330717647BBA5F605@MaxMail04.mpib-berlin.mpg.de>, <413CCD1F-684D-4F35-8211-D00C5ACD1B38@donders.ru.nl> Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA5F631@MaxMail04.mpib-berlin.mpg.de> Dear Jan-Mathijs, yes, that did the trick! Setting cfg.dics.keepfilter = 'no' before passing the single trials through the common filter helped. Thank you and Cristiano for your quick and efficient support! Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 14:17 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you switch off the ‘keepfilter’ option before you do the ‘rawtrial’ business? The error context suggests that MATLAB tries to allocate data to a cell-array, which is probably the spatial filter (or possibly the label). Since this information is not needed for the statistical inference, you can discard it. Best, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 14:03, Werkle, Markus > wrote: Dear Cristiano, thank you very much for this suggestion. This is how my source-structures look like: src00 src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] src00.trial(1) ans = pow: [29160x1 double] noise: [29160x1 double] filter: {29160x1 cell} label: {60x1 cell} filterdimord: '{pos}_ori_chan' As you can see, the field 'inside' is included. And the dimension of the trial data match it too. I guess, I need to dig deeper into the FT-functions ... Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Cristiano Micheli [michelic72 at gmail.com] Gesendet: Montag, 2. Januar 2017 13:43 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Dear Markus Happy new year to you! It might be about the number of sources declared as 'inside' in your head volume. Please double check the indices of your source.inside field because an error of the type: Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; might indicate that there is a problem there. In fact if the source.inside field is empty I would imagine that this error would pop up. However I am not 100% sure because you did not include your src structures as attachments. You might want also to try the option dbstop if error (toggle back with 'dbstop if clear') to identify the contents of your variable without interrupting the running functions/scripts (it's an automatic breakpoint). Best of luck! Cris Micheli On Mon, Jan 2, 2017 at 1:20 PM, Werkle, Markus > wrote: Dear Jan-Mathijs, thank you for you fast reply. But unfortunately, removing the fields does not change the error message et all. Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Gesendet: Montag, 2. Januar 2017 12:50 An: FieldTrip discussion list Betreff: Re: [FieldTrip] ft_sourcestatistics does not recognize source input data Markus, Can you remove the self-baked fields ‘stim’ and ‘rating’ and try again please? Thanks, BW, JM J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 02 Jan 2017, at 12:41, Werkle, Markus > wrote: Dear Fieldtrippers, happy new year to everyone here! This is the second attempt to get help on an issue with ft_sourcestatistics. As I still can not figure out where the problem resides, I give it a new try. My goal is to use a common DICS filter to reconstruct single-trial data in three conditions. Afterwards, I want to run a test for a linear effect across the conditions. I thought to follow closely the descriptions in http://www.fieldtriptoolbox.org/example/common_filters_in_beamforming , especially in the way I extract the single-trial data. However, when I run ft_sourcestatistics, the single trial source data is not recognized as source data ... Any ideas on what went wrong? Below is the code and error-messages: When I run the code below: %---------------------------------------------------------------------------------------------------------- src_descrcfg = []; src_descrcfg.keeptrials = 'yes'; src00 = ft_sourcedescriptives(src_descrcfg,src00); src01 = ft_sourcedescriptives(src_descrcfg,src01); src11 = ft_sourcedescriptives(src_descrcfg,src11); src_statscfg = []; src_statscfg.parameter = 'trial.pow'; src_statscfg.method = 'analytic'; src_statscfg.statistic = 'indepsamplesregrT'; src_statscfg.alpha = 0.05; src_statscfg.correctm = 'no'; src_statscfg.design(1,:) = [ones(1,src00.df) 2*ones(1,src01.df) 3*ones(1,src11.df)]; src_statscfg.ivar = 1; % the 1st row in cfg.design contains the independent variable src_stat = ft_sourcestatistics(src_statscfg, src00, src01, src11); %---------------------------------------------------------------------------------------------------------- I get the following output and error message: original data contained 201 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 48 MB original data contained 113 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB original data contained 46 trials the call to "ft_sourcedescriptives" took 0 seconds and required the additional allocation of an estimated 0 MB Index exceeds matrix dimensions. Error in ft_datatype_source (line 187) val{indx(k)}(1,:,:,:) = dat{indx(k)}; Error in ft_checkdata (line 251) data = ft_datatype_source(data); Error in ft_sourcestatistics (line 100) varargin{i} = ft_checkdata(varargin{i}, 'datatype', 'source', 'feedback', 'no'); src00, src01, and src11 are source-solutions from a dics-beamformer with the following content: src00 = freq: 9.7656 cumtapcnt: [201x1 double] dim: [27 36 30] inside: [29160x1 logical] pos: [29160x3 double] method: 'rawtrial' trial: [1x201 struct] df: 201 cfg: [1x1 struct] sampleinfo: [201x2 double] rating: [201x2 double] stim: {201x3 cell} The source-solutions were based on a common dics-filter after running the following code: %---------------------------------------------------------------------------------------------------------- % compute single trial spectra mtmfftcfg.keeptrials = 'yes'; mtmfft_singletrl = ft_freqanalysis(mtmfftcfg,data); % project all trials through common spatial filter % dics_alltrl_cfg = []; dics_alltrl_cfg = dics_commoncfg; dics_alltrl_cfg.grid.filter = dics_common.avg.filter; % use the common filter computed in the previous step! dics_alltrl_cfg.rawtrial = 'yes'; % project each single trial through the filter. Only necessary if you are interested in reconstructing single trial data tmp_dics_all = ft_sourceanalysis(dics_alltrl_cfg, mtmfft_singletrl); % contains the source estimates for all trials/both %---------------------------------------------------------------------------------------------------------- Any ideas, why the data is not recognized as source-data when calling ft_sourcestatistics (obviously it is recognized correctly with ft_sourcedescriptives ...). Thank you very much for your help. Best regards, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From suhasg10495 at gmail.com Tue Jan 3 13:02:11 2017 From: suhasg10495 at gmail.com (Suhas G) Date: Tue, 3 Jan 2017 17:32:11 +0530 Subject: [FieldTrip] Request for help in debugging error in compilation of biosemi2ft.cc Message-ID: Hi, We are working on a BCI project, where we want to acquire data in real-time from Biosemi. We are using 128 channel Biosemi Active Two device. We are trying to incorporate fieldtrip real time buffer for our real time data acquisition. For the implementation we are following the steps provided on the fieldtrip website. We are getting certain errors during this implementation for which we request your guidance. Ubuntu: We are using Ubuntu 14.04 64 bit. The gcc compiler version used is 4.8.5. We are using Matlab 2015 1. The matlab outside part of buffer is compiled successfully using 'make' on command prompt in the directory src/buffer/src/. 2. The matlab inside part of buffer compilation, i.e creation of mex file was successful on matlab using 'compile' in src/buffer/matlab directory. These warning was displayed, but the mex completed successfully. *Warning: You are using gcc version '4.8.5-2ubuntu1~14.04.1)'. The version of gcc is not supported. Theversion currently supported with MEX is '4.7.x'. For a list of currently supported compilers see:http://www.mathworks.com/support/compilers/current_release . * 3. For compiling the biosemi2ft tool, this is the error which we get *eeg-egi at eeg-egi:~/Desktop/fieldtrip-20161228/realtime/src/acquisition/biosemi$ makeg++ -o ../../../../realtime/bin/glnxa64/biosemi2ft biosemi2ft.o BioSemiClient.o -L../../../../realtime/src/buffer/src -L../../../../realtime/src/buffer/src -lbuffer ../../../../realtime/src/buffer/cpp/SignalConfiguration.o ../../../../realtime/src/buffer/cpp/GdfWriter.o ../../../../realtime/src/buffer/cpp/FtConnection.o ../../../../realtime/src/buffer/cpp/StringServer.o -lbuffer -lpthread -ldl -lrtg++: error: ../../../../realtime/src/buffer/cpp/SignalConfiguration.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/GdfWriter.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/FtConnection.o: No such file or directoryg++: error: ../../../../realtime/src/buffer/cpp/StringServer.o: No such file or directorymake: *** [../../../../realtime/bin/glnxa64/biosemi2ft] Error 1* The compilers which are installed are g++, g++-4.8, g++-4.8-multilib, g++-multilib, gcc, gcc-4.8, gcc-4.8-multilib, gcc-multilib, libllvm3.6:amd64 Please help us debug the same. Thank you. Suhas G -------------- next part -------------- An HTML attachment was scrubbed... URL: From suhasg10495 at gmail.com Tue Jan 3 13:02:13 2017 From: suhasg10495 at gmail.com (Suhas G) Date: Tue, 3 Jan 2017 17:32:13 +0530 Subject: [FieldTrip] Request for help in debugging real-time buffer compilation error Message-ID: Hi, We are using 128 channel Biosemi Active Two device. We are working on a BCI project, where we want to acquire data in real-time from Biosemi. We are trying to incorporate fieldtrip real time buffer for our real time data acquisition. For the implementation we are following the steps provided on the fieldtrip website. We are getting certain errors during this implementation for which we request your guidance. Windows: We are using Windows 7, 64 bit system. Installed Softwares: Microsoft Visual C++ 2005, 2008, 2010, 2012 and 2013 Microsoft Windows SDK 7.1 MinGW compiler and MSYS Cygwin 1. The matlab inside part of buffer compilation, i.e creation of mex file on matlab using 'compile' in src/buffer/matlab directory, gave the following error. We tried it using Visual Studio and minGW compilers. *>> mex -setup * *MEX configured to use 'Microsoft Windows SDK 7.1 (C)' for C language compilation.* *Warning: The MATLAB C and Fortran API has changed to support MATLAB* * variables with more than 2^32-1 elements. In the near future* * you will be required to update your code to utilize the* * new API. You can find more information about this at:* * http://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html .* *To choose a different language, select one from the following:* * mex -setup C++ * * mex -setup FORTRAN* *>> compile('vc')* *Compiling library functions in util.c ...* *Building with 'Microsoft Windows SDK 7.1 (C)'.* *Error using mex* *util.c* *C:\Program* *Files\MATLAB\R2016a\toolbox\fieldtrip-20170102\fieldtrip-20170102\realtime\src\buffer\src\util.c(13) : fatal* *error C1083: Cannot open include file: 'sys/time.h': No such file or directory* *Error in compile (line 156)* * eval(cmd);* *>> compile('mingw','C:/MinGW/lib')* *Compiling library functions in util.c ...* *Building with 'Microsoft Windows SDK 7.1 (C)'.* *Error using mex* *util.c* *C:\Program* *Files\MATLAB\R2016a\toolbox\fieldtrip-20170102\fieldtrip-20170102\realtime\src\buffer\src\util.c(13) : fatal* *error C1083: Cannot open include file: 'sys/time.h': No such file or directory* *Error in compile (line 156)* * eval(cmd);* 2. The matlab outside part compilation of buffer in src/buffer/src directory was attempted using make in cygwin terminal. We got the following error: EEG-EGI at EEG-EGI-PC /cygdrive/c/Program Files/MATLAB/R2016a/toolbox/fieldtrip-201 70102/fieldtrip-20170102/realtime/src/buffer/src $ make gcc -I. -Wunused -Wall -pedantic -O0 -fPIC -g -c -o tcpserver.o tcpserver.c tcpserver.c:1:0: warning: -fPIC ignored for target (all code is position indepen dent) /* ^ tcpserver.c: In function ‘cleanup_tcpserver’: tcpserver.c:31:5: warning: implicit declaration of function ‘closesocket’ [-Wimp licit-function-declaration] closesocket(threadlocal->fd); ^ tcpserver.c: In function ‘tcpserver’: tcpserver.c:51:22: error: storage size of ‘sa’ isn’t known struct sockaddr_in sa; ^ tcpserver.c:102:12: warning: implicit declaration of function ‘socket’ [-Wimplic it-function-declaration] if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:102:19: error: ‘PF_INET’ undeclared (first use in this function) if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:102:19: note: each undeclared identifier is reported only once for e ach function it appears in tcpserver.c:102:28: error: ‘SOCK_STREAM’ undeclared (first use in this function) if ((s = socket(PF_INET, SOCK_STREAM, 0)) < 0) { ^ tcpserver.c:136:7: warning: implicit declaration of function ‘setsockopt’ [-Wimp licit-function-declaration] if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:136:21: error: ‘SOL_SOCKET’ undeclared (first use in this function) if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:136:33: error: ‘SO_REUSEADDR’ undeclared (first use in this function ) if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (const char*)&optval, sizeof(optv al)) < 0) { ^ tcpserver.c:142:19: error: ‘AF_INET’ undeclared (first use in this function) sa.sin_family = AF_INET; ^ tcpserver.c:143:19: warning: implicit declaration of function ‘htons’ [-Wimplici t-function-declaration] sa.sin_port = htons(host->port); ^ tcpserver.c:145:7: error: ‘INADDR_ANY’ undeclared (first use in this function) if (INADDR_ANY) ^ tcpserver.c:146:26: warning: implicit declaration of function ‘htonl’ [-Wimplici t-function-declaration] sa.sin_addr.s_addr = htonl(INADDR_ANY); ^ tcpserver.c:148:7: warning: implicit declaration of function ‘bind’ [-Wimplicit- function-declaration] if (bind(s, (struct sockaddr *)&sa, sizeof sa) < 0) { ^ tcpserver.c:153:7: warning: implicit declaration of function ‘listen’ [-Wimplici t-function-declaration] if (listen(s, BACKLOG)<0) { ^ tcpserver.c:168:9: warning: implicit declaration of function ‘accept’ [-Wimplici t-function-declaration] c = accept(s, (struct sockaddr *)&sa, &b); ^ tcpserver.c:186:9: warning: implicit declaration of function ‘usleep’ [-Wimplici t-function-declaration] usleep(ACCEPTSLEEP); ^ tcpserver.c:202:23: error: storage size of ‘lg’ isn’t known struct linger lg; ^ tcpserver.c:207:35: error: ‘SO_LINGER’ undeclared (first use in this function) setsockopt(s, SOL_SOCKET, SO_LINGER, (char *) &lg, sizeof(lg)); ^ tcpserver.c:202:23: warning: unused variable ‘lg’ [-Wunused-variable] struct linger lg; ^ tcpserver.c:213:37: error: ‘SO_RCVBUF’ undeclared (first use in this function) if (setsockopt(c, SOL_SOCKET, SO_RCVBUF, (const char*)&optval, sizeof(opt val)) < 0) { ^ tcpserver.c:220:37: error: ‘SO_SNDBUF’ undeclared (first use in this function) if (setsockopt(c, SOL_SOCKET, SO_SNDBUF, (const char*)&optval, sizeof(opt val)) < 0) { ^ tcpserver.c:249:50: warning: cast to pointer from integer of different size [-Wi nt-to-pointer-cast] rc = pthread_create(&tid, NULL, tcpsocket, (void *)c); ^ tcpserver.c:267:10: warning: zero-length gnu_printf format string [-Wformat-zero -length] printf(""); ^ tcpserver.c:267:10: warning: zero-length gnu_printf format string [-Wformat-zero -length] tcpserver.c:56:23: warning: unused variable ‘oldcanceltype’ [-Wunused-variable] int oldcancelstate, oldcanceltype; ^ tcpserver.c:56:7: warning: unused variable ‘oldcancelstate’ [-Wunused-variable] int oldcancelstate, oldcanceltype; ^ tcpserver.c:51:22: warning: unused variable ‘sa’ [-Wunused-variable] struct sockaddr_in sa; ^ make: *** [: tcpserver.o] Error 1 Please help us debug the same. Thank you. Suhas G -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Wed Jan 4 10:56:31 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Wed, 4 Jan 2017 10:56:31 +0100 Subject: [FieldTrip] Getting "nan" from ft_read_cifti Message-ID: <2B64515C-C06C-4BFB-B61F-4C981076523C@estudiant.upf.edu> Dear all, I am new to this subject, so I apologize if this is a very simple error. I have downloaded parcellated fMRI time series from HCP and when I apply the function: >> TC = ft_read_cifti('100206.dtseries.nii’); Then the TC.dtseries has 200 columns (parcels) and 96854 rows, which I understand they are the values for each timestep. The problem is that quite a lot of these rows are purely “NaN” values. Does anybody experienced the same problem? What I am missing? Thank you in advanced! Joan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.klinzing at uni-tuebingen.de Wed Jan 4 16:47:12 2017 From: jens.klinzing at uni-tuebingen.de (=?UTF-8?B?IkplbnMgS2xpbnppbmcsIFVuaXZlcnNpdMOkdCBUw7xiaW5nZW4i?=) Date: Wed, 04 Jan 2017 16:47:12 +0100 Subject: [FieldTrip] Keeptrials using "pcc" for source analysis In-Reply-To: References: Message-ID: <586D1900.3080804@uni-tuebingen.de> Hi Xie, are you sure your output does not contain trial data? If you look in source.avg.mom you should see a cell array containing for each inside source point another cell array with as many entries as there are trials (I know it is confusing because you expect .avg to contain averages, but it may not). The field .csd (cross-spectral density) should contain only one (complex-valued) entry per source point since it is averaged across trials (or calculated on the average over all trials, not sure right now). By the way: In case you get errors in downstream functions with your current output (e.g. when using ft_sourcegrandaverage) check the bugzilla on PCC output containing the spatial filter (e.g. http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2861 or 3184). If you don't really need the filter you can use cfg.keepfilter = 'no' on ft_sourceanalysis or remove the filter and filterdimord fields when calling functions that would otherwise fail. Best, Jens > Xie Wanze > Samstag, 31. Dezember 2016 15:09 > Dear Fieldtrip community, > I have a question about using the "keeptrials" option when do the > source analysis with the beamformer ('PCC') method. The issue I met > was that the cfg.keeptrials = 'yes' did not work, i.e., the > calculation was not done for all the trials but generated averaged > output. > Has anyone met this issue before? And does anyone know how to fix it? > It did not work for my data nor for the data I downloaded from the FT > database. I attached the codes that I copied from the FT website using > the FT's example data. > I would like to keep the trials information in the source analysis > because I plan to do the source space connectivity analysis later, > which needs the individual trials information. Or maybe the > "crsspctrm" matrix. > > Codes: > > cfg = []; > > cfg.frequency = freq.freq; > > cfg.method = 'pcc'; > > cfg.grid = lf; > > cfg.headmodel = hdm; > > cfg.keeptrials = 'yes'; > > cfg.pcc.lambda = '10%'; > > cfg.pcc.projectnoise = 'yes'; > > cfg.pcc.keepfilter = 'yes'; > > cfg.pcc.fixedori = 'yes'; > > source = ft_sourceanalysis(cfg, freq); > > > Output ("source"): > > freq: 10 > > cumtapcnt: [268x1 double] > > tri: [16000x3 double] > > inside: [8004x1 logical] > > pos: [8004x3 double] > > method: 'average' > > avg: [1x1 struct] > > cfg: [1x1 struct] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiew1202 at gmail.com Thu Jan 5 02:06:20 2017 From: xiew1202 at gmail.com (Xie Wanze) Date: Thu, 5 Jan 2017 09:06:20 +0800 Subject: [FieldTrip] Keeptrials using "pcc" for source analysis In-Reply-To: <586D1900.3080804@uni-tuebingen.de> References: <586D1900.3080804@uni-tuebingen.de> Message-ID: Hi Jens, Thank you for your response. I figured out where the problem resided. It seems to me that the 'PCC' temporarily does not work with the option "rawtrial = 'yes'". So, the output from using "keeptrials = 'yes'" does not contain the pow and mom information for individual trials. However, this information can be reconstructed for each trial using the ft_sourcedescriptive function with "keeptrials = 'yes' ". For source analysis of time series (e.g., lcmv and eloreta), individual trial information can be obtained by setting "keeptrials = 'yes' and rawtrial = 'yes' ". No need for the ft_sourcedescriptive function. I don't know if this was only my case or someone else also had come across the same situation. 2017-01-04 10:47 GMT-05:00 "Jens Klinzing, Universität Tübingen" < jens.klinzing at uni-tuebingen.de>: > Hi Xie, > are you sure your output does not contain trial data? > > If you look in source.avg.mom you should see a cell array containing for > each inside source point another cell array with as many entries as there > are trials (I know it is confusing because you expect .avg to contain > averages, but it may not). The field .csd (cross-spectral density) should > contain only one (complex-valued) entry per source point since it is > averaged across trials (or calculated on the average over all trials, not > sure right now). > > By the way: In case you get errors in downstream functions with your > current output (e.g. when using ft_sourcegrandaverage) check the bugzilla > on PCC output containing the spatial filter (e.g. http://bugzilla. > fieldtriptoolbox.org/show_bug.cgi?id=2861 or 3184). > If you don't really need the filter you can use cfg.keepfilter = 'no' on > ft_sourceanalysis or remove the filter and filterdimord fields when calling > functions that would otherwise fail. > > Best, > Jens > > Xie Wanze > Samstag, 31. Dezember 2016 15:09 > Dear Fieldtrip community, > I have a question about using the "keeptrials" option when do the source > analysis with the beamformer ('PCC') method. The issue I met was that the > cfg.keeptrials = 'yes' did not work, i.e., the calculation was not done for > all the trials but generated averaged output. > Has anyone met this issue before? And does anyone know how to fix it? > It did not work for my data nor for the data I downloaded from the FT > database. I attached the codes that I copied from the FT website using the > FT's example data. > I would like to keep the trials information in the source analysis > because I plan to do the source space connectivity analysis later, which > needs the individual trials information. Or maybe the "crsspctrm" matrix. > > Codes: > > cfg = []; > > cfg.frequency = freq.freq; > > cfg.method = 'pcc'; > > cfg.grid = lf; > > cfg.headmodel = hdm; > > cfg.keeptrials = 'yes'; > > cfg.pcc.lambda = '10%'; > > cfg.pcc.projectnoise = 'yes'; > > cfg.pcc.keepfilter = 'yes'; > > cfg.pcc.fixedori = 'yes'; > > source = ft_sourceanalysis(cfg, freq); > > > Output ("source"): > > freq: 10 > > cumtapcnt: [268x1 double] > > tri: [16000x3 double] > > inside: [8004x1 logical] > > pos: [8004x3 double] > > method: 'average' > > avg: [1x1 struct] > > cfg: [1x1 struct] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Jan 5 22:15:59 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 5 Jan 2017 21:15:59 +0000 Subject: [FieldTrip] Fwd: Time-frequency analysis: cfg.foi/T meaning References: Message-ID: <90BC228E-9B2F-4A4E-9F7B-3DAA3F93D120@donders.ru.nl> Begin forwarded message: From: Michał Komorowski > Subject: Time-frequency analysis: cfg.foi/T meaning Date: 5 January 2017 at 19:00:29 GMT+1 To: > Hello, http://www.fieldtriptoolbox.org/faq/why_does_my_output.freq_not_match_my_cfg.foi_when_using_mtmconvol_in_ft_freqanalyis I am trying to fit my time windows/simulated data frequencies in time-frequency analysis to make Fieldtrip not correcting my cfg.foi. In other words I want my output frequencies to be EXACTLY the same as cfg.foi. In the mentioned page a following criterion for time-frequency analysis was proposed: "Is the length of my data such, that the frequency resolution 1/T can capture all cfg.foi? This means, in other words, that cfg.foi/T should be integer numbers." I am not sure If the number cfg.foi/T makes sense, because the units of that ratio is [1/s*s = Hz*Hz]. Please correct me if I am wrong. I also tried many other ways of tweaking my parameters, but with no result. All in all, at that moment, from my perspective it looks like Fieldtrip will always correct my cfg.foi and I must not expect that my output frequencies will match with cfg.foi,. I am also almost equally sure that this is not true. I would be very happy if you can help me. Kind regards, Michał Komorowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From krugliakova.es at gmail.com Mon Jan 9 12:48:20 2017 From: krugliakova.es at gmail.com (Elena Krugliakova) Date: Mon, 9 Jan 2017 11:48:20 +0000 Subject: [FieldTrip] EEG source reconstruction using DICS method Message-ID: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> Dear Fieldtrip community, I have a question regarding source reconstruction using the 'dics' method applied to EEG data. I have two problems: first, even with 32GB of RAM it takes 9 hours to call one ft_sourceanalysis. Maybe, there is a way to optimise the procedure somehow? Second, at the end of analysis I obtain a very strange figure, on which I see activity localised outside the mri scan. Mistake on which step of analysis might cause this problem? As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer Please, find my script below. Thank you in advance! Kind Regards, Elena Script: % freqanalysis cfg = []; cfg.toilim = [-0.5 -0.1]; % prestimulus Pre = ft_redefinetrial(cfg, MyData); cfg = []; cfg.toilim = [0.9 1.3]; % poststimulus Post = ft_redefinetrial(cfg, MyData); cfg = []; dataAll = ft_appenddata([], Pre, Post); cfg = []; cfg.method = 'mtmfft'; cfg.output = 'powandcsd' cfg.keeptrials = 'no'; cfg.taper = 'dpss'; cfg.foi = 35; cfg.tapsmofrq = 4; freq_Pre = ft_freqanalysis(cfg, Pre); freq_Post = ft_freqanalysis(cfg, Post); freq_PrePost = ft_freqanalysis(cfg, dataAll); %% headmodel preparation --- with standard brain mri = ft_read_mri('Subject01.mri'); cfg = []; cfg.dim = mri.dim; mri = ft_volumereslice(cfg,mri); cfg = []; cfg.output = {'gray','white','csf','skull','scalp'} segmentedmri = ft_volumesegment(cfg, mri); cfg = []; cfg.shift = 0.3; cfg.method = 'hexahedral'; cfg.tissue = {'gray','white','csf','skull','scalp'} cfg.numvertices = [800, 800, 800, 400, 200]; cfg.unit = segmentedmri.unit bndFEM = ft_prepare_mesh(cfg,segmentedmri); cfg = []; cfg.method ='simbio'; cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); %% loading aligned electrodes load elec_aligned % 109 EEG electrodes %% leadfield preparation cfg = []; cfg.elec = elec_aligned; cfg.vol = vol_simbio_lowresol; cfg.channel = 'all'; cfg.reducerank = 3; % 3 for eeg cfg.grid.unit = 'mm'; cfg.grid.resolution = 10; leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); %% sourceanalysis cfg = []; cfg.frequency = 35; cfg.vol = vol_simbio_lowresol; cfg.grid = leadfield_FEM_lowresol cfg.projectnoise = 'yes'; cfg.method = 'dics'; cfg.dics.projectnoise = 'yes'; cfg.dics.lambda = '5%'; cfg.dics.keepfilter = 'yes'; cfg.dics.realfilter = 'yes'; sourceAll = ft_sourceanalysis(cfg, freq_PrePost); cfg.grid.filter = sourceAll.avg.filter; sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); sourcePost_con = ft_sourceanalysis(cfg, freq_Post); sourceDiff = sourcePost_con; sourceDiff.avg.pow = (sourcePost_con.avg.pow - sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; %% sourceplot cfg = []; cfg.downsample = 2; cfg.parameter = 'pow'; sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); cfg = []; sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); cfg = []; cfg.method = 'glassbrain'; cfg.funparameter = 'pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceDiffIntNorm); -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.chait at ucl.ac.uk Mon Jan 9 14:07:25 2017 From: m.chait at ucl.ac.uk (Chait, Maria) Date: Mon, 9 Jan 2017 13:07:25 +0000 Subject: [FieldTrip] Post-Doc position at UCL Ear Institute Message-ID: (please forward) A postdoctoral research associate position is available at the UCL Ear Institute's 'Auditory Cognitive Neuroscience Lab'. The project, titled "How the brain detects patterns in sound sequences", will be supervised by Dr Maria Chait and conducted in collaboration with Dr. Marcus Pearce (Queen Mary University, London) and colleagues at the UCL Wellcome Trust centre for neuroimaging. The post is funded for 34 months in the first instance and involves a combination of behavioural, computational, eye tracking, and functional brain imaging (EEG, MEG, fMRI) experiments in humans. For more information about the post please see the lab website: http://www.ucl.ac.uk/ear/research/chaitlab/vacancies The Ear Institute is a leading interdisciplinary centre for hearing research in Europe, situated within one of the strongest neuroscience communities in the world at University College London Key Requirements The successful applicant will have a PhD in neuroscience or a neuroscience-related discipline and proven ability to conduct high-quality original research and prepare results for publication. Essential skills include excellent time-management and organizational ability; proficiency in computer programming and good interpersonal, oral and written communication skills. Previous experience with functional brain imaging, neural data analysis, psychophysical assessment, and/or auditory science or acoustics would be desirable. Further Details You should apply for this post (Ref #: 1618836) through UCL's online recruitment website, www.ucl.ac.uk/hr/jobs, where you can download a job description and person specifications. Closing Date for applications is: 1 Feb 2017 For an informal discussion please contact Dr. Maria Chait (m.chait at ucl.ac.uk). Maria Chait PhD m.chait at ucl.ac.uk Reader in Auditory Cognitive Neuroscience Lab site: http://www.ucl.ac.uk/ear/research/chaitlab/ UCL Ear Institute 332 Gray's Inn Road London WC1X 8EE -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Mon Jan 9 22:44:18 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Mon, 9 Jan 2017 21:44:18 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Message-ID: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom -------------- next part -------------- An HTML attachment was scrubbed... URL: From son.ta.dinh at tum.de Tue Jan 10 08:20:58 2017 From: son.ta.dinh at tum.de (Ta Dinh, Son) Date: Tue, 10 Jan 2017 07:20:58 +0000 Subject: [FieldTrip] LCMV beamforming, source.avg.pow is not the power? Message-ID: Hi Fieldtrippers, I have been trying to do a source analysis on my (resting-state) data using LCMV beamforming and as part of a sanity check, I wanted to plot the alpha power. Using ft_sourceanalysis I get a source structure containing avg.pow and intuitively I expected this field to contain the averaged power of the time series. Therefore, I band-passed the data on the sensor level before doing the LCMV source reconstruction. Surprisingly however, when I used the resulting LCMV spatial filter to construct virtual channels and calculated the alpha power spectrum of the resulting time series using ft_freqanalysis, the average power between these 2 approaches differed by several orders of magnitude over many voxels. Did I make some conceptual misunderstanding? Are the 2 approaches I used not equivalent? Or does source.avg.pow not contain the average power at all? Any comments would be greatly appreciated! Best regards, Son Son Ta Dinh, M.Sc. PhD student in Human Pain Research Klinikum rechts der Isar Technische Universität München Munich, Germany Phone: +49 89 4140 7664 http://www.painlabmunich.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From werkle at mpib-berlin.mpg.de Tue Jan 10 11:01:28 2017 From: werkle at mpib-berlin.mpg.de (Werkle, Markus) Date: Tue, 10 Jan 2017 10:01:28 +0000 Subject: [FieldTrip] Post-Doc Position (2 years) at MPIB Berlin - Personalized Cognitive Neuroscience Message-ID: <4C4CCFA964C0894591C5AB8330717647BBA65091@MaxMail04.mpib-berlin.mpg.de> Dear Colleagues, within the research area "Cognitive and Neural Dynamics of Memory Across the Lifespan", headed by Myriam Sander and myself, at the Max Planck Institute for Human Development, Berlin, we are looking for a post-doc to work in our group. Please check the attached advertisement for additional information. The successful candidate will work on a unique data set with intense micro-longitudinal within-person EEG measurements (up to 12 repeated sessions) conducted in the context of a working memory training study. The goal of the project is to develop novel analytical approaches to link cognitive and neural process models on the within-person level. Please spread the news! Best, Markus ********************************************************************* Dr. Markus Werkle-Bergner, Dipl. Psych. Senior Research Scientist (W2) Jacobs Foundation Research Fellow 2017-2019 Max Planck Institute for Human Development Center for Lifespan Psychology Lentzeallee 94, 14195 Berlin Tel.: 0049 (0)30 82406 447 Fax.: 0049 (0)30 824 99 39 Mail: werkle at mpib-berlin.mpg.de http://www.mpib-berlin.mpg.de/en/staff/markus-werkle-bergner ********************************************************************* ________________________________________ Von: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl]" im Auftrag von "Ta Dinh, Son [son.ta.dinh at tum.de] Gesendet: Dienstag, 10. Januar 2017 08:20 An: fieldtrip at science.ru.nl Betreff: [FieldTrip] LCMV beamforming, source.avg.pow is not the power? Hi Fieldtrippers, I have been trying to do a source analysis on my (resting-state) data using LCMV beamforming and as part of a sanity check, I wanted to plot the alpha power. Using ft_sourceanalysis I get a source structure containing avg.pow and intuitively I expected this field to contain the averaged power of the time series. Therefore, I band-passed the data on the sensor level before doing the LCMV source reconstruction. Surprisingly however, when I used the resulting LCMV spatial filter to construct virtual channels and calculated the alpha power spectrum of the resulting time series using ft_freqanalysis, the average power between these 2 approaches differed by several orders of magnitude over many voxels. Did I make some conceptual misunderstanding? Are the 2 approaches I used not equivalent? Or does source.avg.pow not contain the average power at all? Any comments would be greatly appreciated! Best regards, Son Son Ta Dinh, M.Sc. PhD student in Human Pain Research Klinikum rechts der Isar Technische Universität München Munich, Germany Phone: +49 89 4140 7664 http://www.painlabmunich.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PostDoc_CONMEM_2017.pdf Type: application/pdf Size: 50077 bytes Desc: PostDoc_CONMEM_2017.pdf URL: From jan.schoffelen at donders.ru.nl Tue Jan 10 14:40:58 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Tue, 10 Jan 2017 13:40:58 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: Message-ID: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Tue Jan 10 15:36:48 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Tue, 10 Jan 2017 14:36:48 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> References: , <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Message-ID: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Jan 10 16:19:14 2017 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 10 Jan 2017 16:19:14 +0100 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) Message-ID: Dear all, Robert told me there is something implemented, yet undocumented, that would facilitate computing bipolar derivations when re-referencing EEG data. (I have many SEEG electrodes with multiple contact points and would like to have bipolar contacts for each electrode). I don't remember exactly what it was, though. Does anyone know what that would be/has used it before? (Possibly with ft_preprocessing, with a boolean in cfg.refchannel?) Thanks a lot, Vitória -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Jan 10 16:32:53 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Tue, 10 Jan 2017 15:32:53 +0000 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) In-Reply-To: References: Message-ID: <76DED69E-B3C3-4DD5-B6C6-2E803BBB99C3@donders.ru.nl> Hi Vitoria, ft_apply_montage is your friend. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 16:19, Vitoria Piai > wrote: Dear all, Robert told me there is something implemented, yet undocumented, that would facilitate computing bipolar derivations when re-referencing EEG data. (I have many SEEG electrodes with multiple contact points and would like to have bipolar contacts for each electrode). I don't remember exactly what it was, though. Does anyone know what that would be/has used it before? (Possibly with ft_preprocessing, with a boolean in cfg.refchannel?) Thanks a lot, Vitória _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Jan 10 16:37:47 2017 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 10 Jan 2017 16:37:47 +0100 Subject: [FieldTrip] undocumented re-referencing schemes (bipolar) Message-ID: Yep, that's him! Thanks! On 10 January 2017 at 16:32, Schoffelen, J.M. (Jan Mathijs) < jan.schoffelen at donders.ru.nl> wrote: > Hi Vitoria, > > ft_apply_montage is your friend. > > Best, > Jan-Mathijs > > > J.M.Schoffelen > Senior Researcher, VIDI-fellow > Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands > > > > > On 10 Jan 2017, at 16:19, Vitoria Piai wrote: > > Dear all, > > Robert told me there is something implemented, yet undocumented, that > would facilitate computing bipolar derivations when re-referencing EEG > data. (I have many SEEG electrodes with multiple contact points and would > like to have bipolar contacts for each electrode). > > I don't remember exactly what it was, though. Does anyone know what that > would be/has used it before? (Possibly with ft_preprocessing, with a > boolean in cfg.refchannel?) > > Thanks a lot, Vitória > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmadsen at emory.edu Tue Jan 10 21:01:31 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Tue, 10 Jan 2017 15:01:31 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Thanks for the reference. In return, I also recommend reading Ciuparu and Mures an's recent rebuttal: European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, doi:10.1111/ejn.13179 TECHNICAL SPOTLIGHT Sources of bias in single-trial normalization procedures They demonstrate that the positive bias Grandchamp and Delorme warned about with single-trial baseline normalization was, in fact, due to the correlated numerators and denominators in each of the baseline normalization procedures they tested, which was, in turn, caused by the skewed distributions of baseline power values. They demonstrate that this bias is reduced by using a much longer baseline, ideally incorporated into the experimental design, but when that's not possible, stitching together the baselines of many trials. Neither article addresses my specific question of whether it would be even better to log-transform the raw power values before averaging, so I suppose I'll have to test it myself and write my own methods article! 🤓 I will go ahead and incorporate some of these alternative baseline normalization methods in my git fork of FieldTrip as I go along with my own analyses, so let me know if anyone else would find them useful, and I'll submit a pull request to contribute them to the master branch. Thanks for the fruitful discussion, all! ~Teresa On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: > Indeed, in a separate thread with Michael Cohen several months back he > suggested precisely that paper. > > On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" > wrote: > >> I think this paper is relevant to this discussion. >> >> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >> >> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >> >> >> >> On 19 December 2016 at 13:08, Teresa Madsen wrote: >> >>> I appreciate everyone's feedback, but I still wonder if something is >>> being missed. I understand that the non-normally distributed power values >>> may be less of an issue when performing non-parametric stats or even a >>> paired-samples t-test that looks at difference values which may be normal >>> even when the raw data isn't. However, my concern comes into play even >>> before these statistical comparisons are made, whenever any averaging is >>> done to freq-type data across times, frequencies, trials, electrodes, >>> subjects, etc. That means any time any of these configuration options are >>> used for any of these functions, and probably more: >>> >>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>> cfg.avgoverfreq = 'yes'; >>> ft_freqbaseline: cfg.baseline = anything but 'no' >>> >>> In each case, if raw power values are averaged, the result will be >>> positively skewed. Maybe it's not a huge problem if all of the data is >>> treated identically, but the specific case that triggered my concern was in >>> ft_freqbaseline, where the individual time-frequency bins are compared to >>> the mean over time for the baseline period. For example, when using >>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>> data does indeed have a more normal distribution over time, but the mean >>> over the baseline time period is performed *before* the log transform, when >>> the distribution is still highly skewed: >>> >>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>> size(data, 3)]); >>> data = 10*log10(data ./ meanVals); >>> >>> That's what I had originally done when analyzing data for my SfN poster, >>> when I realized the background noise that shouldn't have changed much from >>> baseline was mostly showing a decrease from baseline of about -3dB. >>> >>> Now, I've realized I'm seeing this as more of a problem than others >>> because of another tweak I made, which was to use a long, separate baseline >>> recording to normalize my trial data, rather than a short pre-trial period >>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>> for a baseline power estimate might be okay because overlapping time points >>> in the original data are used to calculate those power values anyway, >>> probably making them less skewed, but also (it seems to me) more arbitrary >>> and prone to error. I already offered my custom function BLnorm.m to one >>> person who was asking about this issue of normalizing to a separate >>> baseline recording, and I would be happy to contribute it to FieldTrip if >>> others would appreciate it. >>> >>> Since a few people suggested using the median, and it is also suggested >>> in Cohen's textbook >>> as >>> an alternative measure of the central tendency for skewed raw power values, >>> I wonder if the simplest fix might be to add an option to select mean or >>> median in each of the functions listed above. Another possibility would be >>> adding an option to transform the power values upon output from >>> ft_freqanalysis. >>> >>> Would anyone else find such changes useful? >>> >>> Thanks, >>> Teresa >>> >>> >>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>> J.Herring at donders.ru.nl> wrote: >>> >>>> In terms of statistics it is the distribution of values that you do the >>>> statistics on that matters. In case of a paired-samples t-test when >>>> comparing two conditions, it is the distribution of difference values that >>>> has to be normally distributed. The distribution of difference values is >>>> often normal given two similarly non-normal distributions, offering no >>>> complications for a regular parametric test. >>>> >>>> >>>> >>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>> normality, so you should have no problem there either. >>>> >>>> >>>> >>>> >>>> >>>> *From:* fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at scie >>>> nce.ru.nl] *On Behalf Of *Alik Widge >>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>> *To:* FieldTrip discussion list >>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>> data analysis >>>> >>>> >>>> >>>> In this, Teresa is right and we have observed this in our own EEG data >>>> -- depending on one's level of noise and number of trials/patients, the >>>> mean can be a very poor estimator of central tendency. My students are >>>> still arguing about what we really want to do with it, but at least one of >>>> them has shifted to using the median as a matter of course for baseline >>>> normalization. >>>> >>>> >>>> Alik Widge >>>> alik.widge at gmail.com >>>> (206) 866-5435 >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>> wrote: >>>> >>>> That may very well be true; to be honest, I haven't looked that deeply >>>> into the stats offerings yet. However, my plan is to express each >>>> electrode's experimental data in terms of change from their respective >>>> baseline recordings before attempting any group averaging or statistical >>>> testing, and this problem shows up first in the baseline correction step, >>>> where FieldTrip averages raw power over time. >>>> >>>> ~Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>> statistics implemented by fieldtrip, the data does not need to be normally >>>> distributed. >>>> >>>> >>>> >>>> On 12 December 2016 at 13:39, Teresa Madsen wrote: >>>> >>>> No, sorry, that's not what I meant, but thanks for giving me the >>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>> across frequencies, but the distribution across time (and according to the >>>> poster, also across space), also has an extremely skewed, negative >>>> exponential distribution. I probably confused everyone by trying to show >>>> too much data in my figure, but each color represents the distribution of >>>> power values for a single frequency over time, using a histogram and a line >>>> above with circles at the mean +/- one standard deviation. >>>> >>>> My main point was that the mean is not representative of the central >>>> tendency of such an asymmetrical distribution of power values over time. >>>> It's even more obvious which is more representative of their actual >>>> distributions when I plot e^mean(logpower) on the raw plot and >>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>> busy and confusing. >>>> >>>> I hope that helps, >>>> Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Hi Teresa, >>>> >>>> >>>> >>>> I think what you are discussing is the 1/f power scaling of the power >>>> spectrum. This is one of the reasons that comparisons are made within >>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>> as such the assumption is that within bands there should be a relative >>>> change against baseline and this is what the statistics are performed on. >>>> That is, baseline correction is assumed to be the mean for a specific >>>> frequency and not a mean across frequencies. >>>> >>>> >>>> >>>> And this leads to another point that when you are selecting a >>>> frequency range to do the non-parametric statistics on you should not do >>>> 1-64 Hz but break it up based on the bands. >>>> >>>> >>>> >>>> Hope my interpretation of your point is correct. I sent in >>>> individually, as I wanted to ensure I followed your point. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Nick >>>> >>>> >>>> >>>> >>>> >>>> On 12 December 2016 at 08:23, Teresa Madsen wrote: >>>> >>>> FieldTrippers, >>>> >>>> >>>> >>>> While analyzing my data for the annual Society for Neuroscience >>>> meeting, I developed a concern that was quickly validated by another poster >>>> (full abstract copied and linked below) focusing on the root of the >>>> problem: neural oscillatory power is not normally distributed across time, >>>> frequency, or space. The specific problem I had encountered was in >>>> baseline-correcting my experimental data, where, regardless of >>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>> However, I found that the distribution of raw power over time is so skewed >>>> that the mean was not a reasonable approximation of the central tendency of >>>> the baseline power, so it made most of my experimental data look like it >>>> had decreased power compared to baseline. The more I think about it, the >>>> more I realize that averaging is everywhere in the way we analyze neural >>>> oscillations (across time points, frequency bins, electrodes, trials, >>>> subjects, etc.), and many of the standard statistics people use also rely >>>> on assumptions of normality. >>>> >>>> >>>> >>>> The most obvious solution for me was to log transform the data first, >>>> as it appears to be fairly log normal, and I always use log-scale >>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>> that this would at least "restore (some) symmetry to the error >>>> distribution." I used a natural log transform, sort of arbitrarily to >>>> differentiate from the standard decibel transform included in FieldTrip as >>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>> across several frequency bands (using power values from a wavelet >>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>> cortex). The lines at the top represent the mean +/- one standard >>>> deviation for each frequency band, and you can see how those descriptive >>>> stats are much more representative of the actual distributions in the log >>>> scale. >>>> >>>> >>>> >>>> >>>> ​​ >>>> >>>> For my analysis, I also calculated a z-score on the log transformed >>>> power to assess how my experimental data compared to the variability of the >>>> noise in a long baseline recording from before conditioning, rather than a >>>> short pre-trial baseline period, since I find that more informative than >>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>> functions I wrote for this if people think it would be a useful addition to >>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>> poster, if anyone wants more detail - I just didn't want to make this email >>>> too big. >>>> >>>> >>>> >>>> Mostly, I'm just hoping to start some discussion here as to how to >>>> address this. I searched the wiki >>>> , listserv >>>> >>>> archives >>>> , >>>> and bugzilla >>>> for >>>> anything related and came up with a few topics surrounding normalization >>>> and baseline correction, but only skirting this issue. It seems important, >>>> so I want to find out whether others agree with my approach or already have >>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>> be changed or just documentation added, or what? >>>> >>>> >>>> >>>> Thanks for any insights, >>>> >>>> Teresa >>>> >>>> >>>> >>>> >>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>> across time >>>> >>>> >>>> *Authors* >>>> >>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>> Cognitive Sci., UCSD, San Diego, CA >>>> >>>> *Disclosures* >>>> >>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>> >>>> *Abstract* >>>> >>>> Neural oscillations are important in organizing activity across the >>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>> to numerous disease states. Oscillations are known to vary by frequency and >>>> amplitude across time and between different brain regions; however, this >>>> variability has never been well characterized. We examined human and animal >>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>> distribution of power and frequency across time, space and species. We >>>> report that between data types, subjects, frequencies, electrodes, and >>>> time, an inverse power law, or negative exponential distribution, is >>>> present in all recordings. This is contrary to, and not compatible with, >>>> the Gaussian noise assumption made in many digital signal processing >>>> techniques. The statistical assumptions underlying common algorithms for >>>> power spectral estimation, such as Welch's method, are being violated >>>> resulting in non-trivial misestimates of oscillatory power. Different >>>> statistical approaches are warranted. >>>> >>>> >>>> >>>> -- >>>> >>>> Teresa E. Madsen, PhD >>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>> analysis >>>> >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> >>>> Emory University >>>> >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> >>>> (770) 296-9119 >>>> >>>> braingirl at gmail.com >>>> >>>> https://www.linkedin.com/in/temadsen >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Teresa E. Madsen, PhD >>> Division of Behavioral Neuroscience and Psychiatric Disorders >>> Yerkes National Primate Research Center >>> Emory University >>> Rainnie Lab, NSB 5233 >>> 954 Gatewood Rd. NE >>> Atlanta, GA 30329 >>> (770) 296-9119 >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Nicholas Peatfield, PhD >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38279 bytes Desc: not available URL: From selene.petit at hotmail.fr Wed Jan 11 01:53:40 2017 From: selene.petit at hotmail.fr (=?iso-8859-1?Q?S=E9l=E8ne_Petit?=) Date: Wed, 11 Jan 2017 00:53:40 +0000 Subject: [FieldTrip] Help needed for an Emotiv layout Message-ID: Hi, I want to analyze some Emotiv EPOC+ data using cluster permutation. My problem is I don't know how to get a layout or a neighbour matrix for this system. Does someone have a .lay file and a neighbour file for Emotiv? Or should I create my own? I'm not sure how to do that, even after reading the documentation for ft_prepapre_layout. Thanks a lot in advance, Kindly, Selene Selene Petit PhD Candidate Department of Cognitive Science | Level 3, Australia Hearing Hub 16 University Avenue Macquarie University NSW 2109 Australia T: 0404602281 | ccd.edu.au | mq.edu.au -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Thu Jan 12 11:39:09 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Thu, 12 Jan 2017 10:39:09 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data Message-ID: Hello everyone! I am dealing with HPC timeseries from rfMRI (dtseries.nii) data and I it has a 200 dimensionality ("parcellated”). I want to know which area of the brain corresponds to each parcel but I could not manage to find it out. When I read the file with ft_read_cifti in Matlab, it returns me the following struct: struct with fields: dimord: 'pos_time' time: [1×200 double] hdr: [1×1 struct] unit: 'mm' brainstructure: [96854×1 double] brainstructurelabel: {1×21 cell} dim: [91 109 91] pos: [96854×3 double] transform: [4×4 double] dtseries: [96854×200 double] But any of those variables is linking the parcel with any brain area. Thank you all in advanced! Joan From jan.schoffelen at donders.ru.nl Thu Jan 12 12:19:58 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 12 Jan 2017 11:19:58 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> Message-ID: <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From joan.rue01 at estudiant.upf.edu Thu Jan 12 12:24:19 2017 From: joan.rue01 at estudiant.upf.edu (Joan Rue Queralt) Date: Thu, 12 Jan 2017 11:24:19 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data References: Message-ID: <834270EE-34AE-4B5D-83B0-F5F27277A238@estudiant.upf.edu> Hello everyone! I am dealing with HPC timeseries from rfMRI (dtseries.nii) data and I it has a 200 dimensionality ("parcellated”). I want to know which area of the brain corresponds to each parcel but I could not manage to find it out. When I read the file with ft_read_cifti in Matlab, it returns me the following struct: struct with fields dimord: ‘pos_time' time: [1×200 double] hdr: [1×1 struct] unit: ‘mm' brainstructure: [96854×1 double] brainstructurelabel: {1×21 cell} dim: [91 109 91] pos: [96854×3 double] transform: [4×4 double] dtseries: [96854×200 double But any of those variables is linking the parcel with any brain area. Thank you all in advanced! Joan From mikexcohen at gmail.com Thu Jan 12 13:28:53 2017 From: mikexcohen at gmail.com (Mike X Cohen) Date: Thu, 12 Jan 2017 13:28:53 +0100 Subject: [FieldTrip] CONFERENCE: ICON2017, 5-8 AUGUST, AMSTERDAM Message-ID: [image: Inline image 1]  We are happy to send a reminder for the ICON XIII conference, which will take place on 5-8 August 2017 in Amsterdam (the Netherlands). Amsterdam is an easily-accessible and progressive city. The venue is the Beurs van Berlage, located in downtown Amsterdam and one of the most beautiful conference venues in Europe! Visit the website: http://www.icon2017.org NOTE THE DEADLINES!! 2 January : Registration opened 1 February : Symposia/ask-the-experts/hackathons submissions close! 31 March : Poster submissions close 1 May : Notification of submission acceptance 15 May : Early-bird discount registration ends PRE-CONFERENCE WORKSHOPS/SATELLITES We welcome pre-conference satellites, and will be happy to advertise them on the ICON website. Note that satellites are independent from ICON in terms of organization, registration, and costs. FOLLOW US ON TWITTER For up-to-date announcements before and during the ICON meeting, follow @icon2017 (see also "Media" tab on the website). QUESTIONS ABOUT THE MEETING OR SPONSORSHIP? email icon2017 at icon2017.org http://www.icon2017.org We look forward to seeing you in beautiful Amsterdam! Mike X Cohen and Birte Forstmann -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 105912 bytes Desc: not available URL: From mikexcohen at gmail.com Thu Jan 12 14:37:18 2017 From: mikexcohen at gmail.com (Mike X Cohen) Date: Thu, 12 Jan 2017 14:37:18 +0100 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Interesting discussion here. I think we should take a step back and distinguish between trivial and nontrivial causes and consequences for the skewed distribution. To some extent, the non-normal distribution is simply the result of defining power as a squared distance -- distances are always positive and squaring them means big values become really big. Consider the following: d = randn(10000,1); % random numbers subplot(311), hist(d,500); % their distribution subplot(312), hist(d.^2,500); % "power" distribution, also try a log-scaled y-axis subplot(313), hist(log(d.^2),500); % log-power distribution The fact that power values have a power-law-like distribution is therefore trivial. But this leads to two non-trivial questions: 1) Is this distribution meaningful for brain function (beyond simply the result of taking squared values)? People who study "the log-brain" and fractal-like (or scale-free) organization of brain function would argue that these distributions reveal meaningful insights into brain function, and therefore it is not really an artifact for analyses. In other words, large values are large for a reason; they might not be outliers that we should attempt to compress. 2) Does it matter for real data analysis? I think this is Teresa's initial concern. I'm inclined to think that it doesn't really matter, but that's just based on the idea (hope!) that if it did really matter and the way we do it is wrong, the field would have discovered this a long time ago. On the other hand, this wouldn't be the first time that people have gotten things wrong for decades. I think the best way to investigate #2 would be with simulated data, showing that a "true" effect is missed when not first computing log-power, presumably because the effect was overshadowed by large-amplitude "noise" (but somehow this would have to be physiological noise that wouldn't get rejected during data cleaning). In empirical data, all you'd be able to do is show a difference without knowing the right answer. btw, make sure to be careful with baselining log-power -- any divisions (e.g., dB or percent change) will be unstable/run off to infinity when baseline power is close to zero, i.e., raw power is close to 1. The sign might also get weird. Probably best to use a baseline subtraction. Mike --------------------------------------------><------------------------------------------------ Thanks for the reference. In return, I also recommend reading Ciuparu and Mures an's recent rebuttal: European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, doi:10.1111/ejn.13179 TECHNICAL SPOTLIGHT Sources of bias in single-trial normalization procedures They demonstrate that the positive bias Grandchamp and Delorme warned about with single-trial baseline normalization was, in fact, due to the correlated numerators and denominators in each of the baseline normalization procedures they tested, which was, in turn, caused by the skewed distributions of baseline power values. They demonstrate that this bias is reduced by using a much longer baseline, ideally incorporated into the experimental design, but when that's not possible, stitching together the baselines of many trials. Neither article addresses my specific question of whether it would be even better to log-transform the raw power values before averaging, so I suppose I'll have to test it myself and write my own methods article! 🤓 I will go ahead and incorporate some of these alternative baseline normalization methods in my git fork of FieldTrip as I go along with my own analyses, so let me know if anyone else would find them useful, and I'll submit a pull request to contribute them to the master branch. Thanks for the fruitful discussion, all! ~Teresa On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: > Indeed, in a separate thread with Michael Cohen several months back he > suggested precisely that paper. > > On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" > wrote: > >> I think this paper is relevant to this discussion. >> >> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >> >> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >> >> >> >> On 19 December 2016 at 13:08, Teresa Madsen wrote: >> >>> I appreciate everyone's feedback, but I still wonder if something is >>> being missed. I understand that the non-normally distributed power values >>> may be less of an issue when performing non-parametric stats or even a >>> paired-samples t-test that looks at difference values which may be normal >>> even when the raw data isn't. However, my concern comes into play even >>> before these statistical comparisons are made, whenever any averaging is >>> done to freq-type data across times, frequencies, trials, electrodes, >>> subjects, etc. That means any time any of these configuration options are >>> used for any of these functions, and probably more: >>> >>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>> cfg.avgoverfreq = 'yes'; >>> ft_freqbaseline: cfg.baseline = anything but 'no' >>> >>> In each case, if raw power values are averaged, the result will be >>> positively skewed. Maybe it's not a huge problem if all of the data is >>> treated identically, but the specific case that triggered my concern was in >>> ft_freqbaseline, where the individual time-frequency bins are compared to >>> the mean over time for the baseline period. For example, when using >>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>> data does indeed have a more normal distribution over time, but the mean >>> over the baseline time period is performed *before* the log transform, when >>> the distribution is still highly skewed: >>> >>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>> size(data, 3)]); >>> data = 10*log10(data ./ meanVals); >>> >>> That's what I had originally done when analyzing data for my SfN poster, >>> when I realized the background noise that shouldn't have changed much from >>> baseline was mostly showing a decrease from baseline of about -3dB. >>> >>> Now, I've realized I'm seeing this as more of a problem than others >>> because of another tweak I made, which was to use a long, separate baseline >>> recording to normalize my trial data, rather than a short pre-trial period >>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>> for a baseline power estimate might be okay because overlapping time points >>> in the original data are used to calculate those power values anyway, >>> probably making them less skewed, but also (it seems to me) more arbitrary >>> and prone to error. I already offered my custom function BLnorm.m to one >>> person who was asking about this issue of normalizing to a separate >>> baseline recording, and I would be happy to contribute it to FieldTrip if >>> others would appreciate it. >>> >>> Since a few people suggested using the median, and it is also suggested >>> in Cohen's textbook >>> as >>> an alternative measure of the central tendency for skewed raw power values, >>> I wonder if the simplest fix might be to add an option to select mean or >>> median in each of the functions listed above. Another possibility would be >>> adding an option to transform the power values upon output from >>> ft_freqanalysis. >>> >>> Would anyone else find such changes useful? >>> >>> Thanks, >>> Teresa >>> >>> >>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>> J.Herring at donders.ru.nl> wrote: >>> >>>> In terms of statistics it is the distribution of values that you do the >>>> statistics on that matters. In case of a paired-samples t-test when >>>> comparing two conditions, it is the distribution of difference values that >>>> has to be normally distributed. The distribution of difference values is >>>> often normal given two similarly non-normal distributions, offering no >>>> complications for a regular parametric test. >>>> >>>> >>>> >>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>> normality, so you should have no problem there either. >>>> >>>> >>>> >>>> >>>> >>>> *From:* fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at scie >>>> nce.ru.nl] *On Behalf Of *Alik Widge >>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>> *To:* FieldTrip discussion list >>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>> data analysis >>>> >>>> >>>> >>>> In this, Teresa is right and we have observed this in our own EEG data >>>> -- depending on one's level of noise and number of trials/patients, the >>>> mean can be a very poor estimator of central tendency. My students are >>>> still arguing about what we really want to do with it, but at least one of >>>> them has shifted to using the median as a matter of course for baseline >>>> normalization. >>>> >>>> >>>> Alik Widge >>>> alik.widge at gmail.com >>>> (206) 866-5435 >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>> wrote: >>>> >>>> That may very well be true; to be honest, I haven't looked that deeply >>>> into the stats offerings yet. However, my plan is to express each >>>> electrode's experimental data in terms of change from their respective >>>> baseline recordings before attempting any group averaging or statistical >>>> testing, and this problem shows up first in the baseline correction step, >>>> where FieldTrip averages raw power over time. >>>> >>>> ~Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>> statistics implemented by fieldtrip, the data does not need to be normally >>>> distributed. >>>> >>>> >>>> >>>> On 12 December 2016 at 13:39, Teresa Madsen wrote: >>>> >>>> No, sorry, that's not what I meant, but thanks for giving me the >>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>> across frequencies, but the distribution across time (and according to the >>>> poster, also across space), also has an extremely skewed, negative >>>> exponential distribution. I probably confused everyone by trying to show >>>> too much data in my figure, but each color represents the distribution of >>>> power values for a single frequency over time, using a histogram and a line >>>> above with circles at the mean +/- one standard deviation. >>>> >>>> My main point was that the mean is not representative of the central >>>> tendency of such an asymmetrical distribution of power values over time. >>>> It's even more obvious which is more representative of their actual >>>> distributions when I plot e^mean(logpower) on the raw plot and >>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>> busy and confusing. >>>> >>>> I hope that helps, >>>> Teresa >>>> >>>> >>>> >>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>> nick.peatfield at gmail.com> wrote: >>>> >>>> Hi Teresa, >>>> >>>> >>>> >>>> I think what you are discussing is the 1/f power scaling of the power >>>> spectrum. This is one of the reasons that comparisons are made within >>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>> as such the assumption is that within bands there should be a relative >>>> change against baseline and this is what the statistics are performed on. >>>> That is, baseline correction is assumed to be the mean for a specific >>>> frequency and not a mean across frequencies. >>>> >>>> >>>> >>>> And this leads to another point that when you are selecting a >>>> frequency range to do the non-parametric statistics on you should not do >>>> 1-64 Hz but break it up based on the bands. >>>> >>>> >>>> >>>> Hope my interpretation of your point is correct. I sent in >>>> individually, as I wanted to ensure I followed your point. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Nick >>>> >>>> >>>> >>>> >>>> >>>> On 12 December 2016 at 08:23, Teresa Madsen wrote: >>>> >>>> FieldTrippers, >>>> >>>> >>>> >>>> While analyzing my data for the annual Society for Neuroscience >>>> meeting, I developed a concern that was quickly validated by another poster >>>> (full abstract copied and linked below) focusing on the root of the >>>> problem: neural oscillatory power is not normally distributed across time, >>>> frequency, or space. The specific problem I had encountered was in >>>> baseline-correcting my experimental data, where, regardless of >>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>> However, I found that the distribution of raw power over time is so skewed >>>> that the mean was not a reasonable approximation of the central tendency of >>>> the baseline power, so it made most of my experimental data look like it >>>> had decreased power compared to baseline. The more I think about it, the >>>> more I realize that averaging is everywhere in the way we analyze neural >>>> oscillations (across time points, frequency bins, electrodes, trials, >>>> subjects, etc.), and many of the standard statistics people use also rely >>>> on assumptions of normality. >>>> >>>> >>>> >>>> The most obvious solution for me was to log transform the data first, >>>> as it appears to be fairly log normal, and I always use log-scale >>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>> that this would at least "restore (some) symmetry to the error >>>> distribution." I used a natural log transform, sort of arbitrarily to >>>> differentiate from the standard decibel transform included in FieldTrip as >>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>> across several frequency bands (using power values from a wavelet >>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>> cortex). The lines at the top represent the mean +/- one standard >>>> deviation for each frequency band, and you can see how those descriptive >>>> stats are much more representative of the actual distributions in the log >>>> scale. >>>> >>>> >>>> >>>> >>>> ​​ >>>> >>>> For my analysis, I also calculated a z-score on the log transformed >>>> power to assess how my experimental data compared to the variability of the >>>> noise in a long baseline recording from before conditioning, rather than a >>>> short pre-trial baseline period, since I find that more informative than >>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>> functions I wrote for this if people think it would be a useful addition to >>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>> poster, if anyone wants more detail - I just didn't want to make this email >>>> too big. >>>> >>>> >>>> >>>> Mostly, I'm just hoping to start some discussion here as to how to >>>> address this. I searched the wiki >>>> , listserv >>>> < https://mailman.science.ru.nl/pipermail/fieldtrip/2006-December/000773.html> >>>> archives >>>> < https://mailman.science.ru.nl/pipermail/fieldtrip/2010-March/002718.html>, >>>> and bugzilla >>>> for >>>> anything related and came up with a few topics surrounding normalization >>>> and baseline correction, but only skirting this issue. It seems important, >>>> so I want to find out whether others agree with my approach or already have >>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>> be changed or just documentation added, or what? >>>> >>>> >>>> >>>> Thanks for any insights, >>>> >>>> Teresa >>>> >>>> >>>> >>>> >>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>> across time >>>> >>>> >>>> *Authors* >>>> >>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>> Cognitive Sci., UCSD, San Diego, CA >>>> >>>> *Disclosures* >>>> >>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>> >>>> *Abstract* >>>> >>>> Neural oscillations are important in organizing activity across the >>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>> to numerous disease states. Oscillations are known to vary by frequency and >>>> amplitude across time and between different brain regions; however, this >>>> variability has never been well characterized. We examined human and animal >>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>> distribution of power and frequency across time, space and species. We >>>> report that between data types, subjects, frequencies, electrodes, and >>>> time, an inverse power law, or negative exponential distribution, is >>>> present in all recordings. This is contrary to, and not compatible with, >>>> the Gaussian noise assumption made in many digital signal processing >>>> techniques. The statistical assumptions underlying common algorithms for >>>> power spectral estimation, such as Welch's method, are being violated >>>> resulting in non-trivial misestimates of oscillatory power. Different >>>> statistical approaches are warranted. >>>> >>>> >>>> >>>> -- >>>> >>>> Teresa E. Madsen, PhD >>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>> analysis >>>> >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> >>>> Emory University >>>> >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> >>>> (770) 296-9119 >>>> >>>> braingirl at gmail.com >>>> >>>> https://www.linkedin.com/in/temadsen >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Teresa E. Madsen, PhD >>> Division of Behavioral Neuroscience and Psychiatric Disorders >>> Yerkes National Primate Research Center >>> Emory University >>> Rainnie Lab, NSB 5233 >>> 954 Gatewood Rd. NE >>> Atlanta, GA 30329 >>> (770) 296-9119 >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Nicholas Peatfield, PhD >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -- Mike X Cohen, PhD mikexcohen.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From seymourr at aston.ac.uk Thu Jan 12 14:59:32 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Thu, 12 Jan 2017 13:59:32 +0000 Subject: [FieldTrip] Problem determining parcellations with HPC data Message-ID: Hi Joan, To me your dtseries.nii looks like it has been parcellated/segmented in time, not space, as the time field is a 1x200 array. You might also want to look at brain structurelabel field and how this relates to the brainstucture field. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From murphyk5 at aston.ac.uk Thu Jan 12 16:17:11 2017 From: murphyk5 at aston.ac.uk (Murphy, Kelly (Research Student)) Date: Thu, 12 Jan 2017 15:17:11 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> , <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Message-ID: Thank you for your help Jan. Indeed, it was as simple as adding 'cfg.keeptrials = 'yes'' in my initial time-frequency analyses. Sorry to have encumbered you with what turned out to be a very trivial problem. Your help is much appreciated! K ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 12 January 2017 11:19 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Jan 12 17:06:05 2017 From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs)) Date: Thu, 12 Jan 2017 16:06:05 +0000 Subject: [FieldTrip] ft_freqstatistics on grandaveraged TFR data In-Reply-To: References: <96F1A7A0-BEED-4AD5-9AC6-3955281EF671@donders.ru.nl> <2E58578E-8B6C-4E8B-AB9B-870AE348C0FB@donders.ru.nl> Message-ID: <15BD5312-6EEB-453C-8D65-CB1C8D2176BF@donders.ru.nl> No worries, Kelly, but just to be sure: from your initial e-mail I got the impression that you wanted to do statistical inference across subjects, not across trials (within a signle subject). Specifying cfg.keeptrials before calling ft_freqanalysis should be done for the latter, not for the former type of statistical inference. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 12 Jan 2017, at 16:17, Murphy, Kelly (Research Student) > wrote: Thank you for your help Jan. Indeed, it was as simple as adding 'cfg.keeptrials = 'yes'' in my initial time-frequency analyses. Sorry to have encumbered you with what turned out to be a very trivial problem. Your help is much appreciated! K ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 12 January 2017 11:19 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, Well, obviously ‘chan_freq_time’ as a dimord is not appropriate to do an inferential statistical test. You need a ‘rpt’ (or ‘subj’) dimension in your data. As long as this has not been sorted out, it is no use to call ft_clusterplot. The best current practice is to input into ft_freqstatistics a cell-array of structures (so ft_freqgrandaverage should not be used). An alternative would be to use ft_appendfreq The following pseudo-code should get you on track. If not, please consult the fieldtrip-wiki for similar examples Nsubj = for k = 1:Nsubj load(); S1{k} = data; load(); S2{k} = data; end cfg = []; cfg …. cfg.design = [ones(1,Nsubj) ones(1,Nsubj)*2;1:Nsubj 1:Nsubj]; cfg.ivar = 1; cfg.uvar = 2; cfg.statistic = ‘depsamplesT’; stat = ft_freqstatistics(cfg, S1{:}, S2{:}); Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 10 Jan 2017, at 15:36, Murphy, Kelly (Research Student) > wrote: Many thanks for your reply Jan-Mathijs, Indeed for both structures, '.dimord' reads 'chan_freq_time'. I can now get ft_freqstatistics to run sensibly but only when I add code so design(2,:) to show 18 and 28 (i.e. group 1 n=8, group 2 n=8). However, when I try to run ft_clusterplot I get the following error message, when stat.stat has the same chan_freq_time dimensions as ft_freqanalysis and ft_freqstatistics outputs (204x48x76). This leads me to believe you are correct in pointing out that I have made a mistake in formatting my variables along the line: "Error using ft_clusterplot (line 144) this only works if either frequency or time is a singleton dimension" Your help so far has been very valuable; but I am still unsure as to where I have gone wrong. Thank you Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Schoffelen, J.M. (Jan Mathijs) [jan.schoffelen at donders.ru.nl] Sent: 10 January 2017 13:40 To: FieldTrip discussion list Subject: Re: [FieldTrip] ft_freqstatistics on grandaveraged TFR data Hi Kelly, It could be that you made a small mistake in formatting the input data to ft_freqstatistics (T_LLL and T_LLH). You may want to check whether these data structures have a ‘dimord’ which reads ‘rpt_chan_freq(_time)' or ‘subj_chan_freq(_time)’. Best, Jan-Mathijs J.M.Schoffelen Senior Researcher, VIDI-fellow Donders Centre for Cognitive Neuroimaging, Nijmegen, The Netherlands On 09 Jan 2017, at 22:44, Murphy, Kelly (Research Student) > wrote: Hello Fieldtrippers, I am trying to use a monte carlo permutation test using ft_freqstatistics on grandaveraged data over 8 participants for two independent conditions but I am struggling to create the correct design matrix using the following code: cfg = []; cfg.method = 'montecarlo'; cfg.computestat = 'yes'; cfg.statistic = 'indepsamplesT'; cfg.numrandomization = 500; cfg.correctm = 'fdr'; cfg.computecritval = 'yes'; cfg.alpha = 0.025; cfg.tail = 0; cfg.clustertail = 0; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; design = zeros(1,size(T_LLL.powspctrm,1) + size(T_LLH.powspctrm,1)); design(1,1:size(T_LLL.powspctrm,1)) = 1; design(1,(size(T_LLL.powspctrm,1)+1):(size(T_LLL.powspctrm,1)+size(T_LLH.powspctrm,1))) = 2; cfg.design = design; cfg.ivar = 1; [stat] = ft_freqstatistics(cfg, T_LLL, T_LLH); I am left with the following error message: "Error using ft_freqstatistics (line 174) the length of the design matrix (1) does not match the number of observations in the data (2)" I am struggling to see what errors I am making and I have tried my best to adhere to the guidelines outlined on the Fieldtrip tutorials, so if anyone with a keen eye can offer any help it would be most appreciated! Many thanks Kelly PhD candidate Department of Psychology Aston University Birmingham B4 7ET United Kingdom _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From mona at sdsc.edu Fri Jan 13 01:04:02 2017 From: mona at sdsc.edu (Wong-Barnum, Mona) Date: Fri, 13 Jan 2017 00:04:02 +0000 Subject: [FieldTrip] NeuroMag 389 channel map Message-ID: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Hello fellow NeuroMag users: Does someone have a location map of the 389 channels on the head? I have been searching but haven’t found anything. These channels are labelled as MEG 0013, MEG 0012, …, MEG 2641, STI 001, STI 002, …, STI 016, EEG 001, EEG 002, …, EEG 060, EOG 061, EOG 062, ECG 063, EMG 064, EEG 065, EEG 066, …, EEG 074 Any help is appreciated. thanks, Mona ********************************************* Mona Wong Web & Mobile Application Developer San Diego Supercomputer Center Believing we are in control is an illusion that brings suffering. ********************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.hauswald at me.com Fri Jan 13 09:12:17 2017 From: anne.hauswald at me.com (anne Hauswald) Date: Fri, 13 Jan 2017 09:12:17 +0100 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Message-ID: Dear Mona, generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. For other purposes you might need the grad structure (data.grad) which is a result of ft_preprocessing and contains information like channel orientation, channel position, etc. for all 306 MEG channels. Hope this helps Best Anne > Am 13.01.2017 um 01:04 schrieb Wong-Barnum, Mona : > > > Hello fellow NeuroMag users: > > Does someone have a location map of the 389 channels on the head? I have been searching but haven’t found anything. These channels are labelled as MEG 0013, MEG 0012, …, MEG 2641, STI 001, STI 002, …, STI 016, EEG 001, EEG 002, …, EEG 060, EOG 061, EOG 062, ECG 063, EMG 064, EEG 065, EEG 066, …, EEG 074 > > Any help is appreciated. > > thanks, > Mona > > ********************************************* > Mona Wong > Web & Mobile Application Developer > San Diego Supercomputer Center > > Believing we are in control is an > illusion that brings suffering. > ********************************************* > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From m.p.craddock at leeds.ac.uk Fri Jan 13 15:51:32 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Fri, 13 Jan 2017 14:51:32 +0000 Subject: [FieldTrip] impact of skewed power distributions on data analysis In-Reply-To: References: Message-ID: Hi all, I'm fiddling around with simulations at the moment but not got a lot of free time, and every time I do fiddle with them the more complicated I seem to make them... correct me if i'm wrong, but there are a couple of different issues here. About the skewness of the distribution - you're not usually comparing two skewed distributions statistically (which even then would probably be ok if they're similary skewed), usually it's a bunch of means from those distributions, and the distribution of the means will often be normally distributed (as will their differences), and thus ok for parametric stats. So the main problem is really whether the mean is a good summary statistic for capturing differences between the underlying distributions or not (similar debates about reaction times) - it's certainly not robust to outliers. Median might be better in some ways, but it's a biased estimator of the population median and might have consequences on stat power - that's one for the simulations at some point. Taking the log first won't necessarily help. As the code Michael Cohen provides shows, taking the log can still result in skewed distributions - power is right-skewed but its log is left-skewed. Taking the square root would obviously be better in this case but that's because it just returns it to the original unsquared normal distribution - whether that's true of real data needs checking out. In addition if you take the log you're no longer testing the same thing when you compare the means - you're testing the geometric mean instead of the arithmetic mean. Differences in the arithmetic means across conditions will not necessarily translate into differences in the geometric means and vice versa. If you use a subtractive baseline, using the median or mean of power will only change what constant you subtract from the data. If you baseline correct using the average of all trials rather than condition specific baselines, it should make no difference to the stats if you use the mean or the median of baseline power (or indeed if you don't use baseline correction at all). If you test differences across electrodes as well as condition, and use electrode but not condition specific baselines - which seems reasonable, since you might expect bigger baseline differences across than within electrodes, it'll only change the main electrode effect, not the condition effect or the interaction between condition and electrode. If you use condition and electrode specific baselines, then it influences *everything*, and you also no longer know if the differences between conditions/electrodes are due to baseline or post-stimulus differences. Using the median over the mean will change the stats if you use divisive baselines, but whether that's a good or bad difference is another question for simulations. Cheers, Matt On 12/01/2017 13:37, Mike X Cohen wrote: > Interesting discussion here. I think we should take a step back and > distinguish between trivial and nontrivial causes and consequences for > the skewed distribution. To some extent, the non-normal distribution is > simply the result of defining power as a squared distance -- distances > are always positive and squaring them means big values become really > big. Consider the following: > > d = randn(10000,1); % random numbers > subplot(311), hist(d,500); % their distribution > subplot(312), hist(d.^2,500); % "power" distribution, also try a > log-scaled y-axis > subplot(313), hist(log(d.^2),500); % log-power distribution > > The fact that power values have a power-law-like distribution is > therefore trivial. > > But this leads to two non-trivial questions: > 1) Is this distribution meaningful for brain function (beyond simply the > result of taking squared values)? People who study "the log-brain" and > fractal-like (or scale-free) organization of brain function would argue > that these distributions reveal meaningful insights into brain function, > and therefore it is not really an artifact for analyses. In other words, > large values are large for a reason; they might not be outliers that we > should attempt to compress. > > 2) Does it matter for real data analysis? I think this is Teresa's > initial concern. I'm inclined to think that it doesn't really matter, > but that's just based on the idea (hope!) that if it did really matter > and the way we do it is wrong, the field would have discovered this a > long time ago. On the other hand, this wouldn't be the first time that > people have gotten things wrong for decades. > > I think the best way to investigate #2 would be with simulated data, > showing that a "true" effect is missed when not first computing > log-power, presumably because the effect was overshadowed by > large-amplitude "noise" (but somehow this would have to be physiological > noise that wouldn't get rejected during data cleaning). In empirical > data, all you'd be able to do is show a difference without knowing the > right answer. > > btw, make sure to be careful with baselining log-power -- any divisions > (e.g., dB or percent change) will be unstable/run off to infinity when > baseline power is close to zero, i.e., raw power is close to 1. The sign > might also get weird. Probably best to use a baseline subtraction. > > Mike > > > > > > --------------------------------------------><------------------------------------------------ > > Thanks for the reference. In return, I also recommend reading Ciuparu and > Mures an's recent rebuttal: > > European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, > doi:10.1111/ejn.13179 > TECHNICAL SPOTLIGHT > Sources of bias in single-trial normalization procedures > > They demonstrate that the positive bias Grandchamp and Delorme warned about > with single-trial baseline normalization was, in fact, due to the > correlated numerators and denominators in each of the baseline > normalization procedures they tested, which was, in turn, caused by the > skewed distributions of baseline power values. They demonstrate that this > bias is reduced by using a much longer baseline, ideally incorporated into > the experimental design, but when that's not possible, stitching together > the baselines of many trials. > > Neither article addresses my specific question of whether it would be even > better to log-transform the raw power values before averaging, so I suppose > I'll have to test it myself and write my own methods article! 🤓 > > I will go ahead and incorporate some of these alternative baseline > normalization methods in my git fork of FieldTrip as I go along with my own > analyses, so let me know if anyone else would find them useful, and I'll > submit a pull request to contribute them to the master branch. > > Thanks for the fruitful discussion, all! > ~Teresa > > > On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge > wrote: > >> Indeed, in a separate thread with Michael Cohen several months back he >> suggested precisely that paper. >> >> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" gmail.com > >> wrote: >> >>> I think this paper is relevant to this discussion. >>> >>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy > Trials. *Frontiers >>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>> >>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>> >>> >>> >>> On 19 December 2016 at 13:08, Teresa Madsen > wrote: >>> >>>> I appreciate everyone's feedback, but I still wonder if something is >>>> being missed. I understand that the non-normally distributed power > values >>>> may be less of an issue when performing non-parametric stats or even a >>>> paired-samples t-test that looks at difference values which may be > normal >>>> even when the raw data isn't. However, my concern comes into play even >>>> before these statistical comparisons are made, whenever any averaging is >>>> done to freq-type data across times, frequencies, trials, electrodes, >>>> subjects, etc. That means any time any of these configuration > options are >>>> used for any of these functions, and probably more: >>>> >>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>> cfg.avgoverfreq = 'yes'; >>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>> >>>> In each case, if raw power values are averaged, the result will be >>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>> treated identically, but the specific case that triggered my concern > was in >>>> ft_freqbaseline, where the individual time-frequency bins are > compared to >>>> the mean over time for the baseline period. For example, when using >>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output > freq >>>> data does indeed have a more normal distribution over time, but the mean >>>> over the baseline time period is performed *before* the log > transform, when >>>> the distribution is still highly skewed: >>>> >>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>> size(data, 3)]); >>>> data = 10*log10(data ./ meanVals); >>>> >>>> That's what I had originally done when analyzing data for my SfN poster, >>>> when I realized the background noise that shouldn't have changed > much from >>>> baseline was mostly showing a decrease from baseline of about -3dB. >>>> >>>> Now, I've realized I'm seeing this as more of a problem than others >>>> because of another tweak I made, which was to use a long, separate > baseline >>>> recording to normalize my trial data, rather than a short pre-trial > period >>>> as ft_freqbaseline is designed to do. Averaging a few hundred > milliseconds >>>> for a baseline power estimate might be okay because overlapping time > points >>>> in the original data are used to calculate those power values anyway, >>>> probably making them less skewed, but also (it seems to me) more > arbitrary >>>> and prone to error. I already offered my custom function BLnorm.m > to one >>>> person who was asking about this issue of normalizing to a separate >>>> baseline recording, and I would be happy to contribute it to > FieldTrip if >>>> others would appreciate it. >>>> >>>> Since a few people suggested using the median, and it is also suggested >>>> in Cohen's textbook >>>> as >>>> an alternative measure of the central tendency for skewed raw power > values, >>>> I wonder if the simplest fix might be to add an option to select mean or >>>> median in each of the functions listed above. Another possibility > would be >>>> adding an option to transform the power values upon output from >>>> ft_freqanalysis. >>>> >>>> Would anyone else find such changes useful? >>>> >>>> Thanks, >>>> Teresa >>>> >>>> >>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>> J.Herring at donders.ru.nl > wrote: >>>> >>>>> In terms of statistics it is the distribution of values that you do the >>>>> statistics on that matters. In case of a paired-samples t-test when >>>>> comparing two conditions, it is the distribution of difference > values that >>>>> has to be normally distributed. The distribution of difference > values is >>>>> often normal given two similarly non-normal distributions, offering no >>>>> complications for a regular parametric test. >>>>> >>>>> >>>>> >>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>> normality, so you should have no problem there either. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* fieldtrip-bounces at science.ru.nl > [mailto:fieldtrip-bounces at scie >>>>> nce.ru.nl ] *On Behalf Of *Alik Widge >>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>> *To:* FieldTrip discussion list > >>>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>> data analysis >>>>> >>>>> >>>>> >>>>> In this, Teresa is right and we have observed this in our own EEG data >>>>> -- depending on one's level of noise and number of trials/patients, the >>>>> mean can be a very poor estimator of central tendency. My students are >>>>> still arguing about what we really want to do with it, but at least > one of >>>>> them has shifted to using the median as a matter of course for baseline >>>>> normalization. >>>>> >>>>> >>>>> Alik Widge >>>>> alik.widge at gmail.com >>>>> (206) 866-5435 >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen emory.edu > >>>>> wrote: >>>>> >>>>> That may very well be true; to be honest, I haven't looked that deeply >>>>> into the stats offerings yet. However, my plan is to express each >>>>> electrode's experimental data in terms of change from their respective >>>>> baseline recordings before attempting any group averaging or > statistical >>>>> testing, and this problem shows up first in the baseline correction > step, >>>>> where FieldTrip averages raw power over time. >>>>> >>>>> ~Teresa >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>> nick.peatfield at gmail.com > wrote: >>>>> >>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>> statistics implemented by fieldtrip, the data does not need to be > normally >>>>> distributed. >>>>> >>>>> >>>>> >>>>> On 12 December 2016 at 13:39, Teresa Madsen > wrote: >>>>> >>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>> opportunity to clarify. Of course everyone is familiar with the 1/f > pattern >>>>> across frequencies, but the distribution across time (and according > to the >>>>> poster, also across space), also has an extremely skewed, negative >>>>> exponential distribution. I probably confused everyone by trying to > show >>>>> too much data in my figure, but each color represents the > distribution of >>>>> power values for a single frequency over time, using a histogram > and a line >>>>> above with circles at the mean +/- one standard deviation. >>>>> >>>>> My main point was that the mean is not representative of the central >>>>> tendency of such an asymmetrical distribution of power values over > time. >>>>> It's even more obvious which is more representative of their actual >>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>>> busy and confusing. >>>>> >>>>> I hope that helps, >>>>> Teresa >>>>> >>>>> >>>>> >>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>> nick.peatfield at gmail.com > wrote: >>>>> >>>>> Hi Teresa, >>>>> >>>>> >>>>> >>>>> I think what you are discussing is the 1/f power scaling of the power >>>>> spectrum. This is one of the reasons that comparisons are made within >>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to > gamma), >>>>> as such the assumption is that within bands there should be a relative >>>>> change against baseline and this is what the statistics are > performed on. >>>>> That is, baseline correction is assumed to be the mean for a specific >>>>> frequency and not a mean across frequencies. >>>>> >>>>> >>>>> >>>>> And this leads to another point that when you are selecting a >>>>> frequency range to do the non-parametric statistics on you should > not do >>>>> 1-64 Hz but break it up based on the bands. >>>>> >>>>> >>>>> >>>>> Hope my interpretation of your point is correct. I sent in >>>>> individually, as I wanted to ensure I followed your point. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> Nick >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 12 December 2016 at 08:23, Teresa Madsen > wrote: >>>>> >>>>> FieldTrippers, >>>>> >>>>> >>>>> >>>>> While analyzing my data for the annual Society for Neuroscience >>>>> meeting, I developed a concern that was quickly validated by > another poster >>>>> (full abstract copied and linked below) focusing on the root of the >>>>> problem: neural oscillatory power is not normally distributed > across time, >>>>> frequency, or space. The specific problem I had encountered was in >>>>> baseline-correcting my experimental data, where, regardless of >>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>> However, I found that the distribution of raw power over time is so > skewed >>>>> that the mean was not a reasonable approximation of the central > tendency of >>>>> the baseline power, so it made most of my experimental data look > like it >>>>> had decreased power compared to baseline. The more I think about > it, the >>>>> more I realize that averaging is everywhere in the way we analyze > neural >>>>> oscillations (across time points, frequency bins, electrodes, trials, >>>>> subjects, etc.), and many of the standard statistics people use > also rely >>>>> on assumptions of normality. >>>>> >>>>> >>>>> >>>>> The most obvious solution for me was to log transform the data first, >>>>> as it appears to be fairly log normal, and I always use log-scale >>>>> visualizations anyway. Erik Peterson, middle author on the poster, > agreed >>>>> that this would at least "restore (some) symmetry to the error >>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>> differentiate from the standard decibel transform included in > FieldTrip as >>>>> cfg.baselinetype = 'db'. The following figures compare the 2 > distributions >>>>> across several frequency bands (using power values from a wavelet >>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>> cortex). The lines at the top represent the mean +/- one standard >>>>> deviation for each frequency band, and you can see how those > descriptive >>>>> stats are much more representative of the actual distributions in > the log >>>>> scale. >>>>> >>>>> >>>>> >>>>> >>>>> ​​ >>>>> >>>>> For my analysis, I also calculated a z-score on the log transformed >>>>> power to assess how my experimental data compared to the > variability of the >>>>> noise in a long baseline recording from before conditioning, rather > than a >>>>> short pre-trial baseline period, since I find that more informative > than >>>>> any of FieldTrip's built-in baseline types. I'm happy to share the > custom >>>>> functions I wrote for this if people think it would be a useful > addition to >>>>> FieldTrip. I can also share more about my analysis and/or a copy > of the >>>>> poster, if anyone wants more detail - I just didn't want to make > this email >>>>> too big. >>>>> >>>>> >>>>> >>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>> address this. I searched the wiki >>>>> , listserv >>>>> > >>>>> archives >>>>> > , >>>>> and bugzilla >>>>> for >>>>> anything related and came up with a few topics surrounding > normalization >>>>> and baseline correction, but only skirting this issue. It seems > important, >>>>> so I want to find out whether others agree with my approach or > already have >>>>> other ways of avoiding the problem, and whether FieldTrip's code > needs to >>>>> be changed or just documentation added, or what? >>>>> >>>>> >>>>> >>>>> Thanks for any insights, >>>>> >>>>> Teresa >>>>> >>>>> >>>>> >>>>> >>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>> across time >>>>> >>>>> >>>>> *Authors* >>>>> >>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>> Cognitive Sci., UCSD, San Diego, CA >>>>> >>>>> *Disclosures* >>>>> >>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>> >>>>> *Abstract* >>>>> >>>>> Neural oscillations are important in organizing activity across the >>>>> human brain in healthy cognition, while oscillatory disruptions are > linked >>>>> to numerous disease states. Oscillations are known to vary by > frequency and >>>>> amplitude across time and between different brain regions; however, > this >>>>> variability has never been well characterized. We examined human > and animal >>>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>> distribution of power and frequency across time, space and species. We >>>>> report that between data types, subjects, frequencies, electrodes, and >>>>> time, an inverse power law, or negative exponential distribution, is >>>>> present in all recordings. This is contrary to, and not compatible > with, >>>>> the Gaussian noise assumption made in many digital signal processing >>>>> techniques. The statistical assumptions underlying common > algorithms for >>>>> power spectral estimation, such as Welch's method, are being violated >>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>> statistical approaches are warranted. >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Teresa E. Madsen, PhD >>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>> analysis >>>>> >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> >>>>> Emory University >>>>> >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> >>>>> (770) 296-9119 >>>>> >>>>> braingirl at gmail.com >>>>> >>>>> https://www.linkedin.com/in/temadsen >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Nicholas Peatfield, PhD >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Nicholas Peatfield, PhD >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> >>>> >>>> -- >>>> Teresa E. Madsen, PhD >>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>> Yerkes National Primate Research Center >>>> Emory University >>>> Rainnie Lab, NSB 5233 >>>> 954 Gatewood Rd. NE >>>> Atlanta, GA 30329 >>>> (770) 296-9119 >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> >>> >>> -- >>> Nicholas Peatfield, PhD >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Teresa E. Madsen, PhD > Division of Behavioral Neuroscience and Psychiatric Disorders > Yerkes National Primate Research Center > Emory University > Rainnie Lab, NSB 5233 > 954 Gatewood Rd. NE > Atlanta, GA 30329 > (770) 296-9119 > > -- > Mike X Cohen, PhD > mikexcohen.com > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From mona at sdsc.edu Fri Jan 13 19:20:06 2017 From: mona at sdsc.edu (Wong-Barnum, Mona) Date: Fri, 13 Jan 2017 18:20:06 +0000 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> Message-ID: <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> Hi Anne: Thank you so much for your reply. > generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. Is there an explanation of the 5 different neuromag layout files? I have the following: neuromag306all.lay neuromag306eeg1005_natmeg.lay neuromag306planar.lay neuromag306cmb.lay neuromag306mag.lay I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay files are for. I found http://www.fieldtriptoolbox.org/tutorial/layout page but if there is anything that’s useful, please point me to it. thanks, Mona ********************************************* Mona Wong Web & Mobile Application Developer San Diego Supercomputer Center "Believe you can and you are half way there." -- Theodore Roosevelt ********************************************* From acskwara at ucdavis.edu Sat Jan 14 02:14:20 2017 From: acskwara at ucdavis.edu (Alea Skwara) Date: Fri, 13 Jan 2017 17:14:20 -0800 Subject: [FieldTrip] Downloading sample data from the Fieldtrip ftp Message-ID: Hi All, I've been trying (unsuccessfully) to download some of the tutorial sample data from the fieldtrip ftp server. I tried several different ftp clients and was finally able to connect and view the files using Cyberduck, but when I actually attempt to download anything the connection fails. Has anyone had a similar problem and found a solution? Thank you, Alea -- Alea C. Skwara Graduate Student | Saron Lab http://mindbrain.ucdavis.edu/labs/Saron Center for Mind and Brain | University of California, Davis 267 Cousteau Place | Davis CA 95616 Cell: (828) 273-8595 -------------- next part -------------- An HTML attachment was scrubbed... URL: From na.so.ir at gmail.com Sat Jan 14 15:12:49 2017 From: na.so.ir at gmail.com (Narjes Soltani) Date: Sat, 14 Jan 2017 17:42:49 +0330 Subject: [FieldTrip] error while removing ecg Message-ID: Dear all Hi, I am trying to remove ecg artifact from some neuromag MEG data using the “ ft_artifact_ecg” method, but unfortunately I encounter the following error: "Undefined function or variable "labelmlt"." When I traced the code, I found that the error is raised from “ft_channelselection” method. In this method, line 340, the value of variable "findmlt" is set to some index, in my code to 1, via the following code snippet: findmlt = find(strcmp(channel, 'MLT')); Then in line 428 of method “ft_channelselection”, the following line of code produces the above error: if findmlt, channel = [channel; labelmlt]; end I found that the only place in method “ft_channelselection” where variable “ labelmlt” is set is in line 249 which is not accessible in my code as it seems to only be accessible for the CTF file format. To solve the problem, I just copied lien 249 at the end of the switch case statements, i.e. after line 298 as follows: labelmlt = datachannel(strncmp('MLT', *datachannel*, length('MLT'))); and I replaced the bold “*datachannel*" variable with “channel” variable and this way the error was solved, but I am not really sure what I have done is correct or not. Would you please help me with this issue? I had the same problem with labelmrt and I solved it in the same way. Besides, I wonder if there is any better and more straightforward way to remove ECG artifact as even after solving the above errors, I have to manually answer to the following line at each run: current zvalue threshold = 3.000 keep the current value (y/n) ? Best, Narjes -------------- next part -------------- An HTML attachment was scrubbed... URL: From mfibm at yahoo.com Mon Jan 16 09:08:02 2017 From: mfibm at yahoo.com (Mohamed Fawzy) Date: Mon, 16 Jan 2017 08:08:02 +0000 (UTC) Subject: [FieldTrip] i need help References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> Message-ID: <1609558455.3967220.1484554082497@mail.yahoo.com> hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing,Faculty of Computers and Informatics,Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14Mobile:00201220577416Tel:0020133188266    Fax:0020133188256E-mail: mohamed.issa at fci.bu.edu.eg ,  mfibm at yahoo.com,  -------------- next part -------------- An HTML attachment was scrubbed... URL: From stan.vanpelt at donders.ru.nl Mon Jan 16 09:27:55 2017 From: stan.vanpelt at donders.ru.nl (Pelt, S. van (Stan)) Date: Mon, 16 Jan 2017 08:27:55 +0000 Subject: [FieldTrip] i need help In-Reply-To: <1609558455.3967220.1484554082497@mail.yahoo.com> References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> <1609558455.3967220.1484554082497@mail.yahoo.com> Message-ID: <7CCA2706D7A4DA45931A892DF3C2894C521E1517@exprd03.hosting.ru.nl> Dear Mohamed, Fieldtrip is not stand-alone software, but a toolbox for Matlab. As such, it is platform-independent, but requires you to have a (Windows/Mac/Linux version of) Matlab installed on your computer. FieldTrip is freeware, but Matlab requires a license. Best, Stan -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour Radboud University Montessorilaan 3, B.01.34 6525 HR Nijmegen, the Netherlands tel: +31 24 3616288 From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Mohamed Fawzy Sent: maandag 16 januari 2017 9:08 To: fieldtrip at science.ru.nl Subject: [FieldTrip] i need help hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing, Faculty of Computers and Informatics, Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14 Mobile:00201220577416 Tel:0020133188266 Fax:0020133188256 E-mail: mohamed.issa at fci.bu.edu.eg , mfibm at yahoo.com, -------------- next part -------------- An HTML attachment was scrubbed... URL: From litvak.vladimir at gmail.com Mon Jan 16 11:36:11 2017 From: litvak.vladimir at gmail.com (Vladimir Litvak) Date: Mon, 16 Jan 2017 10:36:11 +0000 Subject: [FieldTrip] post-doc for cryogen-free MEG system Message-ID: ---------- Forwarded message ---------- From: Barnes, Gareth Date: Mon, Jan 16, 2017 at 9:22 AM Subject: [SPM] post-doc for cryogen-free MEG system To: SPM at jiscmail.ac.uk Dear All We’re looking for someone to join our team working on the development of a new cryogen-free MEG system (see below). Could you please pass this on to anyone who might be interested. Best Gareth UCL link: https://atsv7.wcn.co.uk/search_engine/jobs.cgi?SID= amNvZGU9MTYyMzE0MiZ2dF90ZW1wbGF0ZT05NjUmb3duZXI9NTA0MTE3OCZv d25lcnR5cGU9ZmFpciZicmFuZF9pZD0wJnZhY194dHJhNTA0MTE3OC41MF81 MDQxMTc4PTkyNzg2JnZhY3R5cGU9MTI3NiZwb3N0aW5nX2NvZGU9MjI0JnJl cXNpZz0xNDg0NTU3MjM5LWFlMGZlZDk2OTk2MDUyNjAwM2NiNTRlODM0MmEzMWE0YTA0NmY1ZDY= Research Associate , - Ref:1623142 *UCL Department / Division* UCL Institute of Neurology *Specific unit / Sub department* Wellcome Trust Centre for Neuroimaging *Grade* 7 *Hours* Full Time *Salary (inclusive of London allowance)* £34,056 - £36,923 per annum *Duties and Responsibilities* The Wellcome Trust Centre for Neuroimaging, UCL Institute of Neurology, is seeking to recruit a post-doctoral research fellow in the field of magnetoencephalography (MEG). This is part of a Wellcome-funded programme, in collaboration with the University of Nottingham, to develop a new generation of MEG system based on a optically pumped magnetometers (OPMs). Optically pumped magnetometers are ultra-sensitive magnetic field detectors which can operate at room temperature, and so can be brought closer to the head than the cryogenically-cooled field detectors that are currently used in MEG imaging. The aim is to build a multi-channel OPM MEG device which can be worn on the head allowing the subject to move freely in an open and natural environment. The prospect of an affordable and wearable system has a number of exciting applications including novel paediatric and clinical imaging systems. The post is available from 1st April 2017 and is funded by a grant from the Wellcome Trust for three years in the first instance. *Key Requirements* Applicants should have a PhD in Neuroscience or related area and strong proven expertise in physics / engineering or related discipline. Strong expertise in programming, ideally Matlab, is essential, as is an excellent academic record with evidence of independent, creative work, a strong mathematical background, expertise in modelling / simulation and experience in M/EEG. It would also be desirable to have experience with one or more M/EEG software packages and the use of different volume conductor models. *Further Details* A job description and person specification can be accessed at the bottom of this page. To apply for the vacancy please click on the ‘Apply Now’ button below. If you have any queries regarding the application process, please contact Samantha Robinson, HR Officer, UCL Institute of Neurology - *IoN.HRAdmin at ucl.ac.uk* For informal enquiries please contact Gareth Barnes (*g.barnes at ucl.ac.uk* ) *UCL Taking Action for Equality* *Closing Date* 12 Feb 2017 *Our department holds an Athena SWAN Silver award, in recognition of our commitment and success in addressing gender equality.* *This appointment is subject to UCL Terms and Conditions of Service for Research and Support Staff. Please use these links to find out more about the UCL Terms and Conditions related to this job, employee benefits that we offer and further information about UCL .* *JD and Person Specification* -------------- next part -------------- An HTML attachment was scrubbed... URL: From Darren.Price at mrc-cbu.cam.ac.uk Mon Jan 16 11:47:57 2017 From: Darren.Price at mrc-cbu.cam.ac.uk (Darren Price) Date: Mon, 16 Jan 2017 10:47:57 +0000 Subject: [FieldTrip] i need help In-Reply-To: <1609558455.3967220.1484554082497@mail.yahoo.com> References: <1609558455.3967220.1484554082497.ref@mail.yahoo.com> <1609558455.3967220.1484554082497@mail.yahoo.com> Message-ID: Hi You may need to recompile the mex files if you want to use more than 2GB of RAM. http://www.fieldtriptoolbox.org/faq/how_can_i_compile_the_mex_files_on_64_bit_windows You could also use something like VMware player to create a virtual operating system within windows. However, you would need a powerful computer with lots of spare RAM and CPUs cores for this option as it tends to be much slower. Another obvious solution is to dual boot your computer with Linux, but that’s not really what you’re asking is it? Is there a specific reason you would like to use Windows? Darren ------------------------------------------------------- Dr. Darren Price Investigator Scientist and Cam-CAN Data Manager MRC Cognition & Brain Sciences Unit 15 Chaucer Road Cambridge, CB2 7EF England EMAIL: darren.price at mrc-cbu.cam.ac.uk URL: http://www.mrc-cbu.cam.ac.uk/people/darren.price TEL +44 (0)1223 355 294 x202 FAX +44 (0)1223 359 062 MOB +44 (0)7717822431 ------------------------------------------------------- From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Mohamed Fawzy Sent: 16 January 2017 08:08 To: fieldtrip at science.ru.nl Subject: [FieldTrip] i need help hi , I need help about how i can use the fieldtrip in windows. Accept all My Regards Mohamed F. Issa Lecturer Assistant, Department of Scientific Computing, Faculty of Computers and Informatics, Benha University , Benha, 13518 , Egypt http://www.bu.edu.eg/staff/mohamedissa14 Mobile:00201220577416 Tel:0020133188266 Fax:0020133188256 E-mail: mohamed.issa at fci.bu.edu.eg , mfibm at yahoo.com, -------------- next part -------------- An HTML attachment was scrubbed... URL: From giskeopheim at nru.dk Tue Jan 17 15:59:48 2017 From: giskeopheim at nru.dk (giskeopheim) Date: Tue, 17 Jan 2017 15:59:48 +0100 Subject: [FieldTrip] Fwd: Wavelet-transform based SAM beamforming In-Reply-To: <03f6d3b27e0a09a36897a8a82b7127b4@nru.dk> References: <03f6d3b27e0a09a36897a8a82b7127b4@nru.dk> Message-ID: Dear fieldtrip experts, I hope it is okay to ask a more general "pipeline" question, instead of one specifically related to some issue with code, since I do not know anyone who has experience with it. Is there currently any way to perform wavelet-based SAM beamforming with fieldtrip? I'm thinking something like 'cfg.wavelet' = 'yes' during preprocessing.., or, by all means, a way to convert output from transform functions to desired structs to use in both averaging and analysis functions? Transforming with ft_specest_wavelet to get the convolution in the time domain, gives a 'chan X freqoi X timeoi complex double', which of course is not the struct neccessary for performing the beamforming. Using the ft_freqanalysis with cfg.method = 'wavelet' does not give time domain output neccessary for SAM method, since it does a multiplication with the frequencies. I am working on a project where I want to build something crudely comparable to the algorithms used in the MEG Processor software up until its accumulated spectrograms (assuming you are familiar), but am facing the obvious problems mentioned above. I am of course open to the possibility of me misunderstanding of something essential, but I send this email in hope of getting some input even if that's the case.. Best regards, Giske (graduate student) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 11:57:11 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 11:57:11 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed Message-ID: Hi there, I was wondering if anyone could provide some advice on the specifics of calculating coherence on planar gradiometers (Elekta Neuromag system). In short I would like to calculate coherence between an average of several sensor based on the topography of the power (a seed virtual channel if you want), and all the MEG sensors. I would rather deal with combined gradiometers when in the spectral domain, given that those give me a clear and consistent topography within and between subjects. However, I can imagine combining gradiometers at different stages of the analysis: 1) Combine gradiometers on the timecourse data before spectral analysis. 2) Combine gradiometers after the spectral analysis, but before the coherence analysis. 3) Combine gradiometers after the coherence analysis. Option 2 has the advantage of staying in the same topographical representation in the spectral power estimates (to determine sensors) as well as in the coherence, making it easier to compare topographies of power and coherence. However, this does not allow me to use a 'pre-computed' average, i.e. virtual channel, of several *combined *gradiometers as the seed, since those are specified already in spectral estimate (ft_freqanalysis using fourier or fft). A solution for this might be to determine the seed based on combined gradiometers, then 'cut up' those channel labels into their original gradiometer labels, and use those(uncombined) gradiometers as the seeds in ft_freqanalysis. After the spectral analysis I can then first combine the gradiometers, then average the different seed channels, before and calculate the coherence with those as the seed. Does this sound valid to you people? I would like to check with you people if there are any concerns doing this. There might also be a simpler way doing it... As far as I am aware, there is no FieldTrip tutorial or FAQ where coherence analysis is applied to Neuromag data, so I hope this might also help other people. Regards, Stephen p.s. I am probably using the word 'seed' wrong here - feel free to update my nomenclature :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 12:43:44 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 12:43:44 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed In-Reply-To: References: Message-ID: Hi there, It seems I might be able to solve it using the fourier method in ft_freqanalysis, after which I can select and combine gradiometers and feed those into ft_connectivityanalysis. Thanks for your time, Stephen On 18 January 2017 at 11:57, Stephen Whitmarsh wrote: > Hi there, > > I was wondering if anyone could provide some advice on the specifics of > calculating coherence on planar gradiometers (Elekta Neuromag system). In > short I would like to calculate coherence between an average of several > sensor based on the topography of the power (a seed virtual channel if you > want), and all the MEG sensors. > > I would rather deal with combined gradiometers when in the spectral > domain, given that those give me a clear and consistent topography within > and between subjects. However, I can imagine combining gradiometers at > different stages of the analysis: > > 1) Combine gradiometers on the timecourse data before spectral analysis. > 2) Combine gradiometers after the spectral analysis, but before the > coherence analysis. > 3) Combine gradiometers after the coherence analysis. > > Option 2 has the advantage of staying in the same topographical > representation in the spectral power estimates (to determine sensors) as > well as in the coherence, making it easier to compare topographies of power > and coherence. However, this does not allow me to use a 'pre-computed' > average, i.e. virtual channel, of several *combined *gradiometers as the > seed, since those are specified already in spectral estimate > (ft_freqanalysis using fourier or fft). > > A solution for this might be to determine the seed based on combined > gradiometers, then 'cut up' those channel labels into their original > gradiometer labels, and use those(uncombined) gradiometers as the seeds in > ft_freqanalysis. After the spectral analysis I can then first combine the > gradiometers, then average the different seed channels, before and > calculate the coherence with those as the seed. > > Does this sound valid to you people? I would like to check with you people > if there are any concerns doing this. There might also be a simpler way > doing it... > > As far as I am aware, there is no FieldTrip tutorial or FAQ where > coherence analysis is applied to Neuromag data, so I hope this might also > help other people. > > Regards, > Stephen > > p.s. I am probably using the word 'seed' wrong here - feel free to update > my nomenclature :-) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Wed Jan 18 13:47:54 2017 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Wed, 18 Jan 2017 13:47:54 +0100 Subject: [FieldTrip] A puzzle: Coherence on planar gradiometers using virtual channel as seed In-Reply-To: References: Message-ID: Hi there, Oops, no that does not fly either. Best, Stephen On 18 January 2017 at 12:43, Stephen Whitmarsh wrote: > Hi there, > > It seems I might be able to solve it using the fourier method in > ft_freqanalysis, after which I can select and combine gradiometers and feed > those into ft_connectivityanalysis. > > Thanks for your time, > Stephen > > On 18 January 2017 at 11:57, Stephen Whitmarsh < > stephen.whitmarsh at gmail.com> wrote: > >> Hi there, >> >> I was wondering if anyone could provide some advice on the specifics of >> calculating coherence on planar gradiometers (Elekta Neuromag system). In >> short I would like to calculate coherence between an average of several >> sensor based on the topography of the power (a seed virtual channel if you >> want), and all the MEG sensors. >> >> I would rather deal with combined gradiometers when in the spectral >> domain, given that those give me a clear and consistent topography within >> and between subjects. However, I can imagine combining gradiometers at >> different stages of the analysis: >> >> 1) Combine gradiometers on the timecourse data before spectral analysis. >> 2) Combine gradiometers after the spectral analysis, but before the >> coherence analysis. >> 3) Combine gradiometers after the coherence analysis. >> >> Option 2 has the advantage of staying in the same topographical >> representation in the spectral power estimates (to determine sensors) as >> well as in the coherence, making it easier to compare topographies of power >> and coherence. However, this does not allow me to use a 'pre-computed' >> average, i.e. virtual channel, of several *combined *gradiometers as the >> seed, since those are specified already in spectral estimate >> (ft_freqanalysis using fourier or fft). >> >> A solution for this might be to determine the seed based on combined >> gradiometers, then 'cut up' those channel labels into their original >> gradiometer labels, and use those(uncombined) gradiometers as the seeds in >> ft_freqanalysis. After the spectral analysis I can then first combine the >> gradiometers, then average the different seed channels, before and >> calculate the coherence with those as the seed. >> >> Does this sound valid to you people? I would like to check with you >> people if there are any concerns doing this. There might also be a simpler >> way doing it... >> >> As far as I am aware, there is no FieldTrip tutorial or FAQ where >> coherence analysis is applied to Neuromag data, so I hope this might also >> help other people. >> >> Regards, >> Stephen >> >> p.s. I am probably using the word 'seed' wrong here - feel free to update >> my nomenclature :-) >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.hauswald at me.com Wed Jan 18 13:57:03 2017 From: anne.hauswald at me.com (anne Hauswald) Date: Wed, 18 Jan 2017 13:57:03 +0100 Subject: [FieldTrip] NeuroMag 389 channel map In-Reply-To: <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> References: <96786BCD-50C6-4A8E-99AA-4FA700DC51E0@mail.ucsd.edu> <51F2ED7F-9CAF-4B68-8C9B-15C34BB52E0E@mail.ucsd.edu> Message-ID: <5B0FF59B-A01B-4559-A085-F5F2DDDF80D0@me.com> Hi Mona, as said, the layout files are mainly meant for 2-d plotting. Here http://www.fieldtriptoolbox.org/template/layout under „Neuromag array“ you find specifics for the different files. - neuromag306all.lay includes all 306 sensors - neuromag306mag.lay includes all 102 magnetometers - neuromag306cmb.lay includes 102 positions of 204 combined gradiometers (two at each position) - neuromag306planar.lay includes 204 positions of all planar gradiometers - neuromag306eeg1005_natmeg.lay includes 128 EEG positions Basically, with the Neuromag system you have 102 sensor elements with three sensors each (1 magnetometer and two orthogonal planar gradiometers). Hoper that helps Best Anne > > I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay > Am 13.01.2017 um 19:20 schrieb Wong-Barnum, Mona : > > > Hi Anne: > > Thank you so much for your reply. > >> generally you should be fine using the positions of only the MEG channels, as the location of the EEG channels is user specific. Depending on the purpose, you might be good with the layout file that is stored in the template/layout folder of field trip, neuromag306mag.lay, neuromag306all.lay or neuromag306cmb.lay. This works fine for stuff like plotting the topographies. > > Is there an explanation of the 5 different neuromag layout files? I have the following: > > neuromag306all.lay neuromag306eeg1005_natmeg.lay neuromag306planar.lay > neuromag306cmb.lay neuromag306mag.lay > > I’m not sure what the neuromag306eeg1005_natmeg.lay and neuromag306cmb.lay files are for. > > I found http://www.fieldtriptoolbox.org/tutorial/layout page but if there is anything that’s useful, please point me to it. > > thanks, > Mona > > ********************************************* > Mona Wong > Web & Mobile Application Developer > San Diego Supercomputer Center > > "Believe you can and you are half > way there." > -- Theodore Roosevelt > ********************************************* > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip From tmadsen at emory.edu Wed Jan 18 16:41:58 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Wed, 18 Jan 2017 10:41:58 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis Message-ID: Thanks for the additional feedback, Mike and Matt. I agree that the skewness of the power distribution is "trivial" in that it is skewed *by definition* as a squared value, but you're right that my concern is whether it has a nontrivial impact on the analysis of real data. I do intend to do further simulations to test this and various potential solutions, but I need to get another paper submitted first. I will report my findings back to this listserv when possible. Thanks again, Teresa On Fri, Jan 13, 2017 at 9:51 AM, Matt Craddock wrote: > Hi all, > > I'm fiddling around with simulations at the moment but not got a lot of > free time, and every time I do fiddle with them the more complicated I seem > to make them... > > correct me if i'm wrong, but there are a couple of different issues here. > > About the skewness of the distribution - you're not usually comparing two > skewed distributions statistically (which even then would probably be ok if > they're similary skewed), usually it's a bunch of means from those > distributions, and the distribution of the means will often be normally > distributed (as will their differences), and thus ok for parametric stats. > So the main problem is really whether the mean is a good summary statistic > for capturing differences between the underlying distributions or not > (similar debates about reaction times) - it's certainly not robust to > outliers. Median might be better in some ways, but it's a biased estimator > of the population median and might have consequences on stat power - that's > one for the simulations at some point. > > Taking the log first won't necessarily help. As the code Michael Cohen > provides shows, taking the log can still result in skewed distributions - > power is right-skewed but its log is left-skewed. Taking the square root > would obviously be better in this case but that's because it just returns > it to the original unsquared normal distribution - whether that's true of > real data needs checking out. In addition if you take the log you're no > longer testing the same thing when you compare the means - you're testing > the geometric mean instead of the arithmetic mean. Differences in the > arithmetic means across conditions will not necessarily translate into > differences in the geometric means and vice versa. > > If you use a subtractive baseline, using the median or mean of power will > only change what constant you subtract from the data. If you baseline > correct using the average of all trials rather than condition specific > baselines, it should make no difference to the stats if you use the mean or > the median of baseline power (or indeed if you don't use baseline > correction at all). If you test differences across electrodes as well as > condition, and use electrode but not condition specific baselines - which > seems reasonable, since you might expect bigger baseline differences across > than within electrodes, it'll only change the main electrode effect, not > the condition effect or the interaction between condition and electrode. If > you use condition and electrode specific baselines, then it influences > *everything*, and you also no longer know if the differences between > conditions/electrodes are due to baseline or post-stimulus differences. > > Using the median over the mean will change the stats if you use divisive > baselines, but whether that's a good or bad difference is another question > for simulations. > > Cheers, > Matt > > > On 12/01/2017 13:37, Mike X Cohen wrote: > >> Interesting discussion here. I think we should take a step back and >> distinguish between trivial and nontrivial causes and consequences for >> the skewed distribution. To some extent, the non-normal distribution is >> simply the result of defining power as a squared distance -- distances >> are always positive and squaring them means big values become really >> big. Consider the following: >> >> d = randn(10000,1); % random numbers >> subplot(311), hist(d,500); % their distribution >> subplot(312), hist(d.^2,500); % "power" distribution, also try a >> log-scaled y-axis >> subplot(313), hist(log(d.^2),500); % log-power distribution >> >> The fact that power values have a power-law-like distribution is >> therefore trivial. >> >> But this leads to two non-trivial questions: >> 1) Is this distribution meaningful for brain function (beyond simply the >> result of taking squared values)? People who study "the log-brain" and >> fractal-like (or scale-free) organization of brain function would argue >> that these distributions reveal meaningful insights into brain function, >> and therefore it is not really an artifact for analyses. In other words, >> large values are large for a reason; they might not be outliers that we >> should attempt to compress. >> >> 2) Does it matter for real data analysis? I think this is Teresa's >> initial concern. I'm inclined to think that it doesn't really matter, >> but that's just based on the idea (hope!) that if it did really matter >> and the way we do it is wrong, the field would have discovered this a >> long time ago. On the other hand, this wouldn't be the first time that >> people have gotten things wrong for decades. >> >> I think the best way to investigate #2 would be with simulated data, >> showing that a "true" effect is missed when not first computing >> log-power, presumably because the effect was overshadowed by >> large-amplitude "noise" (but somehow this would have to be physiological >> noise that wouldn't get rejected during data cleaning). In empirical >> data, all you'd be able to do is show a difference without knowing the >> right answer. >> >> btw, make sure to be careful with baselining log-power -- any divisions >> (e.g., dB or percent change) will be unstable/run off to infinity when >> baseline power is close to zero, i.e., raw power is close to 1. The sign >> might also get weird. Probably best to use a baseline subtraction. >> >> Mike >> >> >> >> >> >> --------------------------------------------><-------------- >> ---------------------------------- >> >> Thanks for the reference. In return, I also recommend reading Ciuparu and >> Mures an's recent rebuttal: >> >> European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, >> doi:10.1111/ejn.13179 >> TECHNICAL SPOTLIGHT >> Sources of bias in single-trial normalization procedures >> >> They demonstrate that the positive bias Grandchamp and Delorme warned >> about >> with single-trial baseline normalization was, in fact, due to the >> correlated numerators and denominators in each of the baseline >> normalization procedures they tested, which was, in turn, caused by the >> skewed distributions of baseline power values. They demonstrate that this >> bias is reduced by using a much longer baseline, ideally incorporated into >> the experimental design, but when that's not possible, stitching together >> the baselines of many trials. >> >> Neither article addresses my specific question of whether it would be even >> better to log-transform the raw power values before averaging, so I >> suppose >> I'll have to test it myself and write my own methods article! 🤓 >> >> I will go ahead and incorporate some of these alternative baseline >> normalization methods in my git fork of FieldTrip as I go along with my >> own >> analyses, so let me know if anyone else would find them useful, and I'll >> submit a pull request to contribute them to the master branch. >> >> Thanks for the fruitful discussion, all! >> ~Teresa >> >> >> On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge > > wrote: >> >> Indeed, in a separate thread with Michael Cohen several months back he >>> suggested precisely that paper. >>> >>> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" >> >> gmail.com > >> >>> wrote: >>> >>> I think this paper is relevant to this discussion. >>>> >>>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy >>>> >>> Trials. *Frontiers >> >>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>>> >>>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>>> >>>> >>>> >>>> On 19 December 2016 at 13:08, Teresa Madsen >>> >>> > wrote: >> >>> >>>> I appreciate everyone's feedback, but I still wonder if something is >>>>> being missed. I understand that the non-normally distributed power >>>>> >>>> values >> >>> may be less of an issue when performing non-parametric stats or even a >>>>> paired-samples t-test that looks at difference values which may be >>>>> >>>> normal >> >>> even when the raw data isn't. However, my concern comes into play even >>>>> before these statistical comparisons are made, whenever any averaging >>>>> is >>>>> done to freq-type data across times, frequencies, trials, electrodes, >>>>> subjects, etc. That means any time any of these configuration >>>>> >>>> options are >> >>> used for any of these functions, and probably more: >>>>> >>>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>>> cfg.avgoverfreq = 'yes'; >>>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>>> >>>>> In each case, if raw power values are averaged, the result will be >>>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>>> treated identically, but the specific case that triggered my concern >>>>> >>>> was in >> >>> ft_freqbaseline, where the individual time-frequency bins are >>>>> >>>> compared to >> >>> the mean over time for the baseline period. For example, when using >>>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output >>>>> >>>> freq >> >>> data does indeed have a more normal distribution over time, but the mean >>>>> over the baseline time period is performed *before* the log >>>>> >>>> transform, when >> >>> the distribution is still highly skewed: >>>>> >>>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>>> size(data, 3)]); >>>>> data = 10*log10(data ./ meanVals); >>>>> >>>>> That's what I had originally done when analyzing data for my SfN >>>>> poster, >>>>> when I realized the background noise that shouldn't have changed >>>>> >>>> much from >> >>> baseline was mostly showing a decrease from baseline of about -3dB. >>>>> >>>>> Now, I've realized I'm seeing this as more of a problem than others >>>>> because of another tweak I made, which was to use a long, separate >>>>> >>>> baseline >> >>> recording to normalize my trial data, rather than a short pre-trial >>>>> >>>> period >> >>> as ft_freqbaseline is designed to do. Averaging a few hundred >>>>> >>>> milliseconds >> >>> for a baseline power estimate might be okay because overlapping time >>>>> >>>> points >> >>> in the original data are used to calculate those power values anyway, >>>>> probably making them less skewed, but also (it seems to me) more >>>>> >>>> arbitrary >> >>> and prone to error. I already offered my custom function BLnorm.m >>>>> >>>> to one >> >>> person who was asking about this issue of normalizing to a separate >>>>> baseline recording, and I would be happy to contribute it to >>>>> >>>> FieldTrip if >> >>> others would appreciate it. >>>>> >>>>> Since a few people suggested using the median, and it is also suggested >>>>> in Cohen's textbook >>>>> as >>>>> an alternative measure of the central tendency for skewed raw power >>>>> >>>> values, >> >>> I wonder if the simplest fix might be to add an option to select mean or >>>>> median in each of the functions listed above. Another possibility >>>>> >>>> would be >> >>> adding an option to transform the power values upon output from >>>>> ft_freqanalysis. >>>>> >>>>> Would anyone else find such changes useful? >>>>> >>>>> Thanks, >>>>> Teresa >>>>> >>>>> >>>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>>> J.Herring at donders.ru.nl > wrote: >>>>> >>>>> In terms of statistics it is the distribution of values that you do the >>>>>> statistics on that matters. In case of a paired-samples t-test when >>>>>> comparing two conditions, it is the distribution of difference >>>>>> >>>>> values that >> >>> has to be normally distributed. The distribution of difference >>>>>> >>>>> values is >> >>> often normal given two similarly non-normal distributions, offering no >>>>>> complications for a regular parametric test. >>>>>> >>>>>> >>>>>> >>>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>>> normality, so you should have no problem there either. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* fieldtrip-bounces at science.ru.nl >>>>>> >>>>> [mailto:fieldtrip-bounces at scie >> >>> nce.ru.nl ] *On Behalf Of *Alik Widge >>>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>>> *To:* FieldTrip discussion list >>>>> >>>>> > >> >>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>>> data analysis >>>>>> >>>>>> >>>>>> >>>>>> In this, Teresa is right and we have observed this in our own EEG data >>>>>> -- depending on one's level of noise and number of trials/patients, >>>>>> the >>>>>> mean can be a very poor estimator of central tendency. My students are >>>>>> still arguing about what we really want to do with it, but at least >>>>>> >>>>> one of >> >>> them has shifted to using the median as a matter of course for baseline >>>>>> normalization. >>>>>> >>>>>> >>>>>> Alik Widge >>>>>> alik.widge at gmail.com >>>>>> (206) 866-5435 >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>>> >>>>> emory.edu > >> >>> wrote: >>>>>> >>>>>> That may very well be true; to be honest, I haven't looked that deeply >>>>>> into the stats offerings yet. However, my plan is to express each >>>>>> electrode's experimental data in terms of change from their respective >>>>>> baseline recordings before attempting any group averaging or >>>>>> >>>>> statistical >> >>> testing, and this problem shows up first in the baseline correction >>>>>> >>>>> step, >> >>> where FieldTrip averages raw power over time. >>>>>> >>>>>> ~Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com > wrote: >>>>>> >>>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>>> statistics implemented by fieldtrip, the data does not need to be >>>>>> >>>>> normally >> >>> distributed. >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 13:39, Teresa Madsen >>>>> >>>>> > wrote: >> >>> >>>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>>> opportunity to clarify. Of course everyone is familiar with the 1/f >>>>>> >>>>> pattern >> >>> across frequencies, but the distribution across time (and according >>>>>> >>>>> to the >> >>> poster, also across space), also has an extremely skewed, negative >>>>>> exponential distribution. I probably confused everyone by trying to >>>>>> >>>>> show >> >>> too much data in my figure, but each color represents the >>>>>> >>>>> distribution of >> >>> power values for a single frequency over time, using a histogram >>>>>> >>>>> and a line >> >>> above with circles at the mean +/- one standard deviation. >>>>>> >>>>>> My main point was that the mean is not representative of the central >>>>>> tendency of such an asymmetrical distribution of power values over >>>>>> >>>>> time. >> >>> It's even more obvious which is more representative of their actual >>>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>>> log(mean(rawpower)) on the log plot, but that made the figure even >>>>>> more >>>>>> busy and confusing. >>>>>> >>>>>> I hope that helps, >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com > wrote: >>>>>> >>>>>> Hi Teresa, >>>>>> >>>>>> >>>>>> >>>>>> I think what you are discussing is the 1/f power scaling of the power >>>>>> spectrum. This is one of the reasons that comparisons are made within >>>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to >>>>>> >>>>> gamma), >> >>> as such the assumption is that within bands there should be a relative >>>>>> change against baseline and this is what the statistics are >>>>>> >>>>> performed on. >> >>> That is, baseline correction is assumed to be the mean for a specific >>>>>> frequency and not a mean across frequencies. >>>>>> >>>>>> >>>>>> >>>>>> And this leads to another point that when you are selecting a >>>>>> frequency range to do the non-parametric statistics on you should >>>>>> >>>>> not do >> >>> 1-64 Hz but break it up based on the bands. >>>>>> >>>>>> >>>>>> >>>>>> Hope my interpretation of your point is correct. I sent in >>>>>> individually, as I wanted to ensure I followed your point. >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 08:23, Teresa Madsen >>>>> >>>>> > wrote: >> >>> >>>>>> FieldTrippers, >>>>>> >>>>>> >>>>>> >>>>>> While analyzing my data for the annual Society for Neuroscience >>>>>> meeting, I developed a concern that was quickly validated by >>>>>> >>>>> another poster >> >>> (full abstract copied and linked below) focusing on the root of the >>>>>> problem: neural oscillatory power is not normally distributed >>>>>> >>>>> across time, >> >>> frequency, or space. The specific problem I had encountered was in >>>>>> baseline-correcting my experimental data, where, regardless of >>>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>>> However, I found that the distribution of raw power over time is so >>>>>> >>>>> skewed >> >>> that the mean was not a reasonable approximation of the central >>>>>> >>>>> tendency of >> >>> the baseline power, so it made most of my experimental data look >>>>>> >>>>> like it >> >>> had decreased power compared to baseline. The more I think about >>>>>> >>>>> it, the >> >>> more I realize that averaging is everywhere in the way we analyze >>>>>> >>>>> neural >> >>> oscillations (across time points, frequency bins, electrodes, trials, >>>>>> subjects, etc.), and many of the standard statistics people use >>>>>> >>>>> also rely >> >>> on assumptions of normality. >>>>>> >>>>>> >>>>>> >>>>>> The most obvious solution for me was to log transform the data first, >>>>>> as it appears to be fairly log normal, and I always use log-scale >>>>>> visualizations anyway. Erik Peterson, middle author on the poster, >>>>>> >>>>> agreed >> >>> that this would at least "restore (some) symmetry to the error >>>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>>> differentiate from the standard decibel transform included in >>>>>> >>>>> FieldTrip as >> >>> cfg.baselinetype = 'db'. The following figures compare the 2 >>>>>> >>>>> distributions >> >>> across several frequency bands (using power values from a wavelet >>>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>>> cortex). The lines at the top represent the mean +/- one standard >>>>>> deviation for each frequency band, and you can see how those >>>>>> >>>>> descriptive >> >>> stats are much more representative of the actual distributions in >>>>>> >>>>> the log >> >>> scale. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ​​ >>>>>> >>>>>> For my analysis, I also calculated a z-score on the log transformed >>>>>> power to assess how my experimental data compared to the >>>>>> >>>>> variability of the >> >>> noise in a long baseline recording from before conditioning, rather >>>>>> >>>>> than a >> >>> short pre-trial baseline period, since I find that more informative >>>>>> >>>>> than >> >>> any of FieldTrip's built-in baseline types. I'm happy to share the >>>>>> >>>>> custom >> >>> functions I wrote for this if people think it would be a useful >>>>>> >>>>> addition to >> >>> FieldTrip. I can also share more about my analysis and/or a copy >>>>>> >>>>> of the >> >>> poster, if anyone wants more detail - I just didn't want to make >>>>>> >>>>> this email >> >>> too big. >>>>>> >>>>>> >>>>>> >>>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>>> address this. I searched the wiki >>>>>> , listserv >>>>>> >>>>>> > mber/000773.html> >> >>> archives >>>>>> >>>>>> > h/002718.html>, >> >>> and bugzilla >>>>>> for >>>>>> anything related and came up with a few topics surrounding >>>>>> >>>>> normalization >> >>> and baseline correction, but only skirting this issue. It seems >>>>>> >>>>> important, >> >>> so I want to find out whether others agree with my approach or >>>>>> >>>>> already have >> >>> other ways of avoiding the problem, and whether FieldTrip's code >>>>>> >>>>> needs to >> >>> be changed or just documentation added, or what? >>>>>> >>>>>> >>>>>> >>>>>> Thanks for any insights, >>>>>> >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>>> across time >>>>>> >>>>>> >>>>>> *Authors* >>>>>> >>>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>>> Cognitive Sci., UCSD, San Diego, CA >>>>>> >>>>>> *Disclosures* >>>>>> >>>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>>> >>>>>> *Abstract* >>>>>> >>>>>> Neural oscillations are important in organizing activity across the >>>>>> human brain in healthy cognition, while oscillatory disruptions are >>>>>> >>>>> linked >> >>> to numerous disease states. Oscillations are known to vary by >>>>>> >>>>> frequency and >> >>> amplitude across time and between different brain regions; however, >>>>>> >>>>> this >> >>> variability has never been well characterized. We examined human >>>>>> >>>>> and animal >> >>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>>> distribution of power and frequency across time, space and species. We >>>>>> report that between data types, subjects, frequencies, electrodes, and >>>>>> time, an inverse power law, or negative exponential distribution, is >>>>>> present in all recordings. This is contrary to, and not compatible >>>>>> >>>>> with, >> >>> the Gaussian noise assumption made in many digital signal processing >>>>>> techniques. The statistical assumptions underlying common >>>>>> >>>>> algorithms for >> >>> power spectral estimation, such as Welch's method, are being violated >>>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>>> statistical approaches are warranted. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Teresa E. Madsen, PhD >>>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>>> analysis >>>>>> >>>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>>> Yerkes National Primate Research Center >>>>>> >>>>>> Emory University >>>>>> >>>>>> Rainnie Lab, NSB 5233 >>>>>> 954 Gatewood Rd. NE >>>>>> Atlanta, GA 30329 >>>>>> >>>>>> (770) 296-9119 >>>>>> >>>>>> braingirl at gmail.com >>>>>> >>>>>> https://www.linkedin.com/in/temadsen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Teresa E. Madsen, PhD >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> Emory University >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> (770) 296-9119 >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >> >> >> -- >> Teresa E. Madsen, PhD >> Division of Behavioral Neuroscience and Psychiatric Disorders >> Yerkes National Primate Research Center >> Emory University >> Rainnie Lab, NSB 5233 >> 954 Gatewood Rd. NE >> Atlanta, GA 30329 >> (770) 296-9119 >> >> -- >> Mike X Cohen, PhD >> mikexcohen.com >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens.klinzing at uni-tuebingen.de Thu Jan 19 10:09:15 2017 From: jens.klinzing at uni-tuebingen.de (=?ISO-8859-1?Q?=22Jens_Klinzing=2C_Uni_T=FCbingen=22?=) Date: Thu, 19 Jan 2017 10:09:15 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> Message-ID: <5880823B.2050806@uni-tuebingen.de> Dear Elena, Question 1: I assume the reason it takes so long is that you are using a FEM-based headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - sb_transfer) every time you do a source reconstruction. For more information see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 . You can circumvent the issue by computing the transfer matrix beforehand and changing the code in a way that it doesnt compute a new transfer matrix if you have already provided one. Alternatively you could use a BEM headmodel (dipoli if possible since bemcp seems to have issues http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2817). Question 2: Did you check your segmentation, the headmodel and the coregistration of electrodes/head every step of the way? If you fill all inside voxels with 1s and plot that, do you see an obvious shift/rotation of the "activity" in relation to the MRI? Best, Jens > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' > method applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to > call one ft_sourceanalysis. Maybe, there is a way to optimise the > procedure somehow? > > Second, at the end of analysis I obtain a very strange figure, on > which I see activity localised outside the mri scan. Mistake on which > step of analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - > sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From kjj11033 at kaist.ac.kr Thu Jan 19 11:26:52 2017 From: kjj11033 at kaist.ac.kr (=?UTF-8?B?6rmA7J6s7KSR?=) Date: Thu, 19 Jan 2017 19:26:52 +0900 (KST) Subject: [FieldTrip] =?utf-8?q?Questions_about_probability_variation_by_se?= =?utf-8?q?tting_different_tail_of_cluster_based_permutation_test?= Message-ID: <5880960c3fb3_@_imoxion.com> Dear group, Hi I'm Jaejoong of KAIST korea First of all, thanks for such a nice toolbox I have a question with tail of cluster based permutation test I compared difference between 2 conditions with test Weird thing is, when I run test with cfg.clustertail=0; negative cluster of probability 0.038 returned, which is not significant However, when I run test with clustertail=-1 and +1 both, negative cluster of probability of 0.021 returned, which is significant if I adjust with bonferroni correction for both positive one sied test and negative one sided test In my understanding, probability of negative cluster above should be same. So my question is 1) Why does probability of same negative cluster is varied by tail of permutation test? 2) Is it reasonable to run test with clustertail=+1/-1 and apply bonferroni correction for 2 tests? I would really appreciate your comments Sincerely Jaejoong -------------- next part -------------- An HTML attachment was scrubbed... URL: From krugliakova.es at gmail.com Thu Jan 19 13:55:49 2017 From: krugliakova.es at gmail.com (Elena Krugliakova) Date: Thu, 19 Jan 2017 13:55:49 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: <5880823B.2050806@uni-tuebingen.de> References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> <5880823B.2050806@uni-tuebingen.de> Message-ID: Dear Jens, Thank you for your answer! 1. Indeed, I found where ft_sourceanalysis starts to recompute transfer matrix and just loaded precomputed headmodel and sensors. Now everything is fine, and it takes several seconds to run ft_sourceanalysis. 2. About homogeneous "noise outside the mri scan". Noise appears after I calculate difference between two sources, following tutorial http://www.fieldtriptoolbox.org/tutorial/beamformer. However, sourceplot for not-contrasted conditions looks good. Maybe you could give me an advice, how to get rid of this background noise. Kind Regards, Elena With difference calculation: cfg = []; cfg.elec = elec; cfg.headmodel = vol; cfg.grid = leadfield; cfg.keepleadfield = 'yes' cfg.projectnoise = 'yes'; cfg.frequency = [10 15]; cfg.method = 'dics'; cfg.dics.projectnoise = 'yes'; cfg.dics.lambda = '5%'; cfg.dics.keepfilter = 'yes'; cfg.dics.realfilter = 'yes'; sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); cfg.grid.filter = sourcePNandBS.avg.filter; sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); sourceBS = ft_sourceanalysis(cfg, freq_BS_Post); *sourceDiff.avg.pow = (sourcePN.avg.pow - sourceBS.avg.pow) ./ sourceBS.avg.pow;* cfg = []; cfg.parameter = 'avg.pow'; sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); cfg = []; sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg, sourceDiffIntNorm); figure [image: Inline images 1] Without difference calculation: cfg = []; cfg.elec = elec; .......... sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); cfg.grid.filter = sourcePNandBS.avg.filter; sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); sourcePN.avg.pow = sourcePN.avg.pow ./ sourcePN.avg.noise; cfg = []; cfg.parameter = 'avg.pow'; sourcePN = ft_sourceinterpolate(cfg, sourcePN, mri); cfg = []; sourcePNIntNorm = ft_volumenormalise(cfg, sourcePNInt); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg, sourcePNIntNorm); figure [image: Inline images 2] On 19 January 2017 at 10:09, "Jens Klinzing, Uni Tübingen" < jens.klinzing at uni-tuebingen.de> wrote: > Dear Elena, > > Question 1: > I assume the reason it takes so long is that you are using a FEM-based > headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix > on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - > sb_transfer) every time you do a source reconstruction. For more > information see http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 > . > > You can circumvent the issue by computing the transfer matrix beforehand > and changing the code in a way that it doesnt compute a new transfer matrix > if you have already provided one. > > Alternatively you could use a BEM headmodel (dipoli if possible since > bemcp seems to have issues http://bugzilla.fieldtriptoolbox.org/show_bug. > cgi?id=2817). > > Question 2: > Did you check your segmentation, the headmodel and the coregistration of > electrodes/head every step of the way? If you fill all inside voxels with > 1s and plot that, do you see an obvious shift/rotation of the "activity" in > relation to the MRI? > > Best, > Jens > > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' method > applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to call > one ft_sourceanalysis. Maybe, there is a way to optimise the procedure > somehow? > > Second, at the end of analysis I obtain a very strange figure, on which I > see activity localised outside the mri scan. Mistake on which step of > analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - sourcePre_con.avg.pow) > ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 144484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 165407 bytes Desc: not available URL: From mehdy.dousty at gmail.com Fri Jan 20 01:05:06 2017 From: mehdy.dousty at gmail.com (mehdy dousty) Date: Fri, 20 Jan 2017 00:05:06 +0000 Subject: [FieldTrip] Extracting Default mode network from AAL Message-ID: Hello all, I am working on source localization based on the Inverse problem of MEG Human Connectome project. I used eLoreta to investigate the sources in the brain, and the results are projected to MNI 116, AAL116, I would like to know how I can identify the different networks such as DMN? Thanks Mehdy -------------- next part -------------- An HTML attachment was scrubbed... URL: From seymourr at aston.ac.uk Fri Jan 20 10:29:36 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Fri, 20 Jan 2017 09:29:36 +0000 Subject: [FieldTrip] [HCP-Users] Extracting Default mode network from AAL In-Reply-To: References: Message-ID: Hi Mehdy, I believe the AAL atlas came before the DMN and other large-scale brain networks were popular in neuroimaging, so there's no easy 1:1 mapping between them. Perhaps you could download the Yeo 7/17 network parcellations, overlay the AAL atlas points and see which ROIs overlap with the DMN? Otherwise you could repeat your analysis using a more up-to-date atlas such as the HCP MMP (https://balsa.wustl.edu/WN56)... Robert ________________________________ From: hcp-users-bounces at humanconnectome.org on behalf of mehdy dousty Sent: 20 January 2017 00:05:06 To: FieldTrip discussion list; hcp-users at humanconnectome.org Subject: [HCP-Users] Extracting Default mode network from AAL Hello all, I am working on source localization based on the Inverse problem of MEG Human Connectome project. I used eLoreta to investigate the sources in the brain, and the results are projected to MNI 116, AAL116, I would like to know how I can identify the different networks such as DMN? Thanks Mehdy _______________________________________________ HCP-Users mailing list HCP-Users at humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehdy.dousty at gmail.com Sun Jan 22 05:31:49 2017 From: mehdy.dousty at gmail.com (mehdy dousty) Date: Sun, 22 Jan 2017 04:31:49 +0000 Subject: [FieldTrip] HCP MEG SOURCE TO DMN Message-ID: Hi all, Firstly I give my special thanks to fieldtrip and human connectome project discussion list. Secondly, I have a question which needs the expert's attentions. I am using MEG resting state in HCP, and I would like to project the data to some atlases to extract DMN network. Since the AAL 116 does not give me the aforementioned network, and it is not clear from HCP instruction how to interpolate the computed grid points to other atlases, there is 1:1 interpolation between AAL and calculated source points, I am sending the email to help me through the issue. Thanks Mehdy -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Horn at charite.de Sun Jan 22 14:50:43 2017 From: Andreas.Horn at charite.de (Horn, Andreas) Date: Sun, 22 Jan 2017 13:50:43 +0000 Subject: [FieldTrip] HCP MEG SOURCE TO DMN In-Reply-To: References: Message-ID: Hi Mehdy, There are two reference masks of the DMM being deployed within the GIFT ICA toolbox - they are potentially a bit old but should work for the purpose. Also, for a list of available whole-brain parcellation atlases (I.e. AAL alternatives, see http://www.lead-dbs.org/?page_id=1004). Best, Andy Am 21.01.2017 um 23:33 schrieb mehdy dousty >: Hi all, Firstly I give my special thanks to fieldtrip and human connectome project discussion list. Secondly, I have a question which needs the expert's attentions. I am using MEG resting state in HCP, and I would like to project the data to some atlases to extract DMN network. Since the AAL 116 does not give me the aforementioned network, and it is not clear from HCP instruction how to interpolate the computed grid points to other atlases, there is 1:1 interpolation between AAL and calculated source points, I am sending the email to help me through the issue. Thanks Mehdy _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.wilson at med.einstein.yu.edu Mon Jan 23 22:00:10 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Mon, 23 Jan 2017 21:00:10 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel Message-ID: Hi all, I'm working with EEG data and I'm trying to get some basic source fitting up and running. Unfortunately, I don't have individual subject MRIs, so I'm using the templates provided by fieldtrip. I've co-registered my 160 Biosemi electrodes to the standard_bem template (see attached picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid (picture attached, overlaid on standard_bem). I can prepare the leadfield from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. To test this configuration, I've selected a time window in my data and averaged across it (the covariance matrix was also calculated); the topography of this averaged data is attached. I then attempted a source fit with the LCMV beamformer: cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); After interpolating to the single_subj_T1.nii provided with ft_sourceinterpolate and plotting with ft_sourceplot, I am given a sourceplot that is highly focal in nature (see attached picture). I'd find it very surprising if this topography were generated primarily by a source that isn't even inside the brain (as the sourceplot indicates). So, I'm not sure exactly where/how I'm going wrong with this one, nor am I sure how to trouble shoot it. Any guidance you might provide would be greatly appreciated. Thanks so much, Tommy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Grid.PNG Type: image/png Size: 42603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Electrode localization.PNG Type: image/png Size: 94200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Source.PNG Type: image/png Size: 134694 bytes Desc: not available URL: From singht at musc.edu Tue Jan 24 02:43:10 2017 From: singht at musc.edu (Singh, Tarkeshwar) Date: Tue, 24 Jan 2017 01:43:10 +0000 Subject: [FieldTrip] FEM volume conduction model for stroke survivors Message-ID: <6B351597-5A9A-4027-8DA5-A7AD7D9E88D2@musc.edu> Dear Fieldtrip Community, Has anyone tried developing an FEM volume conduction model for stroke survivors (http://www.fieldtriptoolbox.org/tutorial/headmodel_eeg_fem). I was wondering, how have you modeled the lesioned volume? Have you modeled it as CSF, and if so, how did you do that? I used the code shown below and it appears to me that the lesions are not getting modeled as CSF; they appear to be modeled as scalp and skull. cfg = []; cfg.output = {'gray','white','csf','skull','scalp'}; segmentedmri = ft_volumesegment(cfg, mri); seg_i = ft_datatype_segmentation(segmentedmri,'segmentationstyle','indexed'); Any help would be sincerely appreciated. Regards, Tarkesh -- Tarkeshwar Singh Postdoctoral Scholar Department of Health Sciences and Research Medical University of South Carolina 77 President Street, Room C305 Charleston, SC 29425 singht at musc.edu ------------------------------------------------------------------------- This message was secured via TLS by MUSC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.keil at gmail.com Tue Jan 24 09:40:06 2017 From: julian.keil at gmail.com (Julian Keil) Date: Tue, 24 Jan 2017 09:40:06 +0100 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: Message-ID: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Hi Tommy, did you do some sort of contrast (e.g. with the noise estimate or a baseline) after your source analysis? Right now, it's not clear what you are looking at. Could you paste your code not only of the sourceanalysis, but the rest after which got you to the plot? It might also be the case that the automatic scaling in the source plot throws you off - maybe try setting it by hand. Good luck, Julian Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > Hi all, > > I'm working with EEG data and I'm trying to get some basic source fitting up and running. Unfortunately, I don't have individual subject MRIs, so I'm using the templates provided by fieldtrip. I've co-registered my 160 Biosemi electrodes to the standard_bem template (see attached picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid (picture attached, overlaid on standard_bem). I can prepare the leadfield from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. > > To test this configuration, I've selected a time window in my data and averaged across it (the covariance matrix was also calculated); the topography of this averaged data is attached. I then attempted a source fit with the LCMV beamformer: > > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > > After interpolating to the single_subj_T1.nii provided with ft_sourceinterpolate and plotting with ft_sourceplot, I am given a sourceplot that is highly focal in nature (see attached picture). > > I'd find it very surprising if this topography were generated primarily by a source that isn't even inside the brain (as the sourceplot indicates). So, I'm not sure exactly where/how I'm going wrong with this one, nor am I sure how to trouble shoot it. Any guidance you might provide would be greatly appreciated. > > Thanks so much, > > Tommy > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From michak at is.umk.pl Tue Jan 24 15:21:17 2017 From: michak at is.umk.pl (=?UTF-8?Q?Micha=C5=82_Komorowski?=) Date: Tue, 24 Jan 2017 15:21:17 +0100 Subject: [FieldTrip] Source statistic issue - between trials Message-ID: Dear community, Currently I am working on source analysis from EEG data. I have some trouble using ft_sourcestatistics do a between-trials analysis (single subject). I am trying to compare source from trials from task type A (ctrl) to with trials from task type B (task). Mainly I rely on http://www.fieldtriptoolbox.org/example/source_statistics . For almost week I am trying find a solution, inculding testing ft_sourcestatistics with different combinations of data: 1) source 1 : no ft_sourcedescriptives and no ft_sourceinterpolate used 2) source 2 : used ft_sourcedescriptives and no ft_sourceinterpolate used 3) source 3 : used ft_sourcedescriptives and used ft_sourceinterpolate For cases 1) and 2) I get very similar errors "Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering" (full error messages at the bottom). In case 3) I cannot run ft_statistics because there are no trials anymore. I have tried changing design matrix, search community messages for some advice and read related articles on fieldtriptoolbox site, but I have not find the answer. Any help would be appreciated. Michał Komorowski Statistics code: cfg = []; %cfg.dim = source.dim; % there is no such field in the data cfg.method = 'montecarlo'; cfg.statistic = 'ft_statfun_depsamplesT'; cfg.parameter = 'pow'; cfg.correctm = 'cluster'; cfg.numrandomization = 100; cfg.alpha = 0.05; cfg.correcttail = 'alpha'; % http://www.fieldtriptoolbox.org/faq/why_should_i_use_the_cfg.correcttail_option_when_using_statistics_montecarlo cfg.tail = 0; % two sided test cfg.design(1,:) = design; % condition code cfg.design(2,:) = [1:length(find(design==1)) 1:length(find(design==2))]; % trial indices cfg.uvar = 2; % unit of observation variable: trials cfg.ivar = 1; % independent variable: condition code % I think design matrix is ok according to: http://www.fieldtriptoolbox.org/walkthrough#paired_comparison) stat = ft_sourcestatistics(cfg, source); Data structures and error messages Case 1) no ft_sourcedescriptives and no ft_sourceinterpolate used source = freq: 10 cumtapcnt: [21x1 double] inside: [231420x1 logical] pos: [231420x3 double] method: 'rawtrial' trial: [1x21 struct] df: 21 cfg: [1x1 struct] the call to "ft_selectdata" took 1 seconds using "ft_statistics_montecarlo" for the statistical testing using connectivity of voxels in 3-D volume using "ft_statfun_depsamplesT" for the single-sample statistics constructing randomized design total number of measurements = 21 total number of variables = 2 number of independent variables = 1 number of unit variables = 1 number of within-cell variables = 0 number of control variables = 0 using a permutation resampling approach repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 computing a parametric threshold for clustering Error using ft_statfun_depsamplesT (line 84) Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering Error in ft_sourcestatistics (line 205) [stat, cfg] = statmethod(cfg, dat, design); >> cfg.design ans = 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 Case 2) used ft_sourcedescriptives and no ft_sourceinterpolate used source_app = freq: 10 cumtapcnt: [21x1 double] inside: [231420x1 logical] pos: [231420x3 double] method: 'rawtrial' trial: [1x21 struct] df: 21 cfg: [1x1 struct] the call to "ft_selectdata" took 0 seconds using "ft_statistics_montecarlo" for the statistical testing using connectivity of voxels in 3-D volume using "ft_statfun_depsamplesT" for the single-sample statistics constructing randomized design total number of measurements = 21 total number of variables = 2 number of independent variables = 1 number of unit variables = 1 number of within-cell variables = 0 number of control variables = 0 using a permutation resampling approach repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 computing a parametric threshold for clustering Error using ft_statfun_depsamplesT (line 84) Invalid specification of the design array. Error using ft_statistics_montecarlo (line 242) could not determine the parametric critical value for clustering Error in ft_sourcestatistics (line 205) [stat, cfg] = statmethod(cfg, dat, design); Case 3) used ft_sourcedescriptives and used ft_sourceinterpolate source_mri_align_ctrl = freq: 10 anatomy: [128x128x128 double] coordsys: 'spm' dim: [128 128 128] pos: [2097152x3 double] transform: [4x4 double] unit: 'mm' inside: [128x128x128 logical] pow: [2097152x1 double] cfg: [1x1 struct] % there is no trials so one cannot conduct between-trials statistics ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From tommy.wilson at med.einstein.yu.edu Tue Jan 24 17:36:20 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Tue, 24 Jan 2017 16:36:20 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Julian, Thank you so much for your reply. I've pasted the commented code below (I apologize for the code dump). I've also attached an m-file to this email if you'd prefer to download it that way. If relevant, you can download the leadfield, headmodel and electrode locations here (that file also includes the raw data stored in variables A and U that I am attempting to source-fit). As per your questions: I do indeed have a contrast between attended (A) and unattended (U) conditions. I've written the code below to source-fit both conditions and create the contrast. However, despite that the raw topographies (see attached images) are different, the source-fits are the same (...?). As a consequence, the contrast has no non-zero values. If instead, I normalize to noise (i.e. generate the Neural Activity Index ) and look at a contrast there, we again see no non-zero values. Outside of the contrast, I've implemented your other suggestions. I've rescaled the original ft_sourceplot such that you can see the extent of it (see attached image). To my mind, it shouldn't look like this, but having never done this before, I'm not quite sure what to expect. I've also included an image of the ft_sourceplot for the Neural Activity Index of sourceA which also appears to me to be artefactual. More to the point, I'd expect that since the topographies for A and U are different, the NAIs should be different, which is not the case. I'm sort of at a loss about how to proceed here. So, thank you very much for taking the time to look into this. If I can supply anything else to help, please don't hesitate to let me know. Best, Tommy Wilson --- CODE --- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); On Tue, Jan 24, 2017 at 3:42 AM Julian Keil wrote: > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste your > code not only of the sourceanalysis, but the rest after which got you to > the plot? > It might also be the case that the automatic scaling in the source plot > throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual subject > MRIs, so I'm using the templates provided by fieldtrip. I've co-registered > my 160 Biosemi electrodes to the standard_bem template (see attached > picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid > (picture attached, overlaid on standard_bem). I can prepare the leadfield > from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the > LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data and > averaged across it (the covariance matrix was also calculated); the > topography of this averaged data is attached. I then attempted a source fit > with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated primarily > by a source that isn't even inside the brain (as the sourceplot indicates). > So, I'm not sure exactly where/how I'm going wrong with this one, nor am I > sure how to trouble shoot it. Any guidance you might provide would be > greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Attended.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Unattended.PNG Type: image/png Size: 91677 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceA_sourceplot.PNG Type: image/png Size: 143463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceA_NAI_sourceplot.PNG Type: image/png Size: 147302 bytes Desc: not available URL: From tommy.wilson at med.einstein.yu.edu Tue Jan 24 17:55:56 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Tue, 24 Jan 2017 16:55:56 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi there, I apologize. I found a small bug in that script regarding the fieldtrip directory. The revised version is attached. Best, Tommy On Tue, Jan 24, 2017 at 11:36 AM Tommy Wilson < tommy.wilson at med.einstein.yu.edu> wrote: > Hi Julian, > > Thank you so much for your reply. > > I've pasted the commented code below (I apologize for the code dump). I've > also attached an m-file to this email if you'd prefer to download it that > way. If relevant, you can download the leadfield, headmodel and electrode > locations here > > (that file also includes the raw data stored in variables A and U that I am > attempting to source-fit). > > As per your questions: I do indeed have a contrast between attended (A) > and unattended (U) conditions. I've written the code below to source-fit > both conditions and create the contrast. However, despite that the raw > topographies (see attached images) are different, the source-fits are the > same (...?). As a consequence, the contrast has no non-zero values. If > instead, I normalize to noise (i.e. generate the Neural Activity Index > ) > and look at a contrast there, we again see no non-zero values. > > Outside of the contrast, I've implemented your other suggestions. I've > rescaled the original ft_sourceplot such that you can see the extent of it > (see attached image). To my mind, it shouldn't look like this, but having > never done this before, I'm not quite sure what to expect. I've also > included an image of the ft_sourceplot for the Neural Activity Index of > sourceA which also appears to me to be artefactual. More to the point, I'd > expect that since the topographies for A and U are different, the NAIs > should be different, which is not the case. > > I'm sort of at a loss about how to proceed here. So, thank you very much > for taking the time to look into this. If I can supply anything else to > help, please don't hesitate to let me know. > > Best, > > Tommy Wilson > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\'; > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrast > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > % Check to see if any non-zero values exist in the contrast > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > warning('No non-zero contast values exist. ft_sourceplot will give an > error. Do not plot.'); > end > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > % See: > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > sourceA_NAI = sourceA; > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > sourceU_NAI = sourceU; > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > warning('No non-zero contast values exist. ft_sourceplot will give an > error. Do not plot.') > end > > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [0 3e3]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_NAI_interp); > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil wrote: > > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste your > code not only of the sourceanalysis, but the rest after which got you to > the plot? > It might also be the case that the automatic scaling in the source plot > throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual subject > MRIs, so I'm using the templates provided by fieldtrip. I've co-registered > my 160 Biosemi electrodes to the standard_bem template (see attached > picture). For the sourcemodel, I'm using the standard_sourcemodel3d5mm grid > (picture attached, overlaid on standard_bem). I can prepare the leadfield > from there with ft_prepare_leadfield (cfg.normalize = 'yes'), as per the > LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data and > averaged across it (the covariance matrix was also calculated); the > topography of this averaged data is attached. I then attempted a source fit > with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated primarily > by a source that isn't even inside the brain (as the sourceplot indicates). > So, I'm not sure exactly where/how I'm going wrong with this one, nor am I > sure how to trouble shoot it. Any guidance you might provide would be > greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances U.cov = A.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrast sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; % Check to see if any non-zero values exist in the contrast if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.'); end %%% Instead of a contrast, look at the Neural Activity Index (NAI) % See: http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index sourceA_NAI = sourceA; sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; sourceU_NAI = sourceU; sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) warning('No non-zero contast values exist. ft_sourceplot will give an error. Do not plot.') end %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [0 3e3]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceA_NAI_interp); From m.p.craddock at leeds.ac.uk Tue Jan 24 22:07:05 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Tue, 24 Jan 2017 21:07:05 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Tommy, > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > This is the problem. ft_sourceanalysis is using the covariance matrix and leadfield to construct a spatial filter for each grid point; if the covariance matrices are equivalent, the source solutions will be too. What you need to do is something like run the source analysis on data averaged over both conditions first, then take the filter from the combined analysis and run source analysis on each condition seperately. so say sourceAll is the result of ft_sourceanalysis(cfg,bothConditions) You'd do cfg.grid.filter = sourceAll.avg.filter then ft_sourceanalysis(cfg,A) ft_sourceanalysis(cfg,U) As a quick and dirty version I just replaced the covariance matrix in A with the average of the two A.cov and U.cov, ran sourceanalysis on that, then put A.cov back to its original value and ran sourceanalysis on each condition seperately. Spoiler: the unattended condition has lower activity everywhere :) There's some weirdness around the boundaries of the headmodel, not sure what's causing that exactly. Maybe try using a different source grid instead of the standard one... Cheers, Matt On 24/01/2017 16:36, Tommy Wilson wrote: > Hi Julian, > > Thank you so much for your reply. > > I've pasted the commented code below (I apologize for the code dump). > I've also attached an m-file to this email if you'd prefer to download > it that way. If relevant, you can download the leadfield, headmodel and > electrode locations here > > (that file also includes the raw data stored in variables A and U that I > am attempting to source-fit). > > As per your questions: I do indeed have a contrast between attended (A) > and unattended (U) conditions. I've written the code below to source-fit > both conditions and create the contrast. However, despite that the raw > topographies (see attached images) are different, the source-fits are > the same (...?). As a consequence, the contrast has no non-zero values. > If instead, I normalize to noise (i.e. generate the Neural Activity > Index > ) > and look at a contrast there, we again see no non-zero values. > > Outside of the contrast, I've implemented your other suggestions. I've > rescaled the original ft_sourceplot such that you can see the extent of > it (see attached image). To my mind, it shouldn't look like this, but > having never done this before, I'm not quite sure what to expect. I've > also included an image of the ft_sourceplot for the Neural Activity > Index of sourceA which also appears to me to be artefactual. More to the > point, I'd expect that since the topographies for A and U are different, > the NAIs should be different, which is not the case. > > I'm sort of at a loss about how to proceed here. So, thank you very much > for taking the time to look into this. If I can supply anything else to > help, please don't hesitate to let me know. > > Best, > > Tommy Wilson > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\'; > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > U.cov = A.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrast > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > % Check to see if any non-zero values exist in the contrast > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > warning('No non-zero contast values exist. ft_sourceplot will give > an error. Do not plot.'); > end > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > % See: > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > sourceA_NAI = sourceA; > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > sourceU_NAI = sourceU; > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > warning('No non-zero contast values exist. ft_sourceplot will give > an error. Do not plot.') > end > > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [0 3e3]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceA_NAI_interp); > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > wrote: > > Hi Tommy, > > did you do some sort of contrast (e.g. with the noise estimate or a > baseline) after your source analysis? > Right now, it's not clear what you are looking at. Could you paste > your code not only of the sourceanalysis, but the rest after which > got you to the plot? > It might also be the case that the automatic scaling in the source > plot throws you off - maybe try setting it by hand. > > Good luck, > > Julian > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > Hi all, > > > > I'm working with EEG data and I'm trying to get some basic source > fitting up and running. Unfortunately, I don't have individual > subject MRIs, so I'm using the templates provided by fieldtrip. I've > co-registered my 160 Biosemi electrodes to the standard_bem template > (see attached picture). For the sourcemodel, I'm using the > standard_sourcemodel3d5mm grid (picture attached, overlaid on > standard_bem). I can prepare the leadfield from there with > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV tutorial. > > > > To test this configuration, I've selected a time window in my data > and averaged across it (the covariance matrix was also calculated); > the topography of this averaged data is attached. I then attempted a > source fit with the LCMV beamformer: > > > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > After interpolating to the single_subj_T1.nii provided with > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > sourceplot that is highly focal in nature (see attached picture). > > > > I'd find it very surprising if this topography were generated > primarily by a source that isn't even inside the brain (as the > sourceplot indicates). So, I'm not sure exactly where/how I'm going > wrong with this one, nor am I sure how to trouble shoot it. Any > guidance you might provide would be greatly appreciated. > > > > Thanks so much, > > > > Tommy > > > > localization.PNG>_______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From jens.klinzing at uni-tuebingen.de Wed Jan 25 10:29:29 2017 From: jens.klinzing at uni-tuebingen.de (=?UTF-8?B?IkplbnMgS2xpbnppbmcsIFVuaSBUw7xiaW5nZW4i?=) Date: Wed, 25 Jan 2017 10:29:29 +0100 Subject: [FieldTrip] EEG source reconstruction using DICS method In-Reply-To: References: <7cd6ae18b167496c939bc39a69057d44@EXPRD01.hosting.ru.nl> <5880823B.2050806@uni-tuebingen.de> Message-ID: <58886FF9.3050904@uni-tuebingen.de> Dear Elena, I'm glad the first problem is solved. About the second one: Are you referring to the yellowish background outside of the brain? My first guess would be that this is a mere plotting issue. Can you check whether there actually are non-NAN or even non-zero values for grid points marked as 'outside' (before interpolation and before and after contrasting)? If not, you know it is a problem with the plotting. Best, Jens > Elena Krugliakova > Donnerstag, 19. Januar 2017 13:55 > Dear Jens, > > Thank you for your answer! > 1. Indeed, I found where ft_sourceanalysis starts to recompute > transfer matrix and just loaded precomputed headmodel and sensors. Now > everything is fine, and it takes several seconds to run ft_sourceanalysis. > 2. About homogeneous "noise outside the mri scan". > Noise appears after I calculate difference between two sources, > following tutorial > http://www.fieldtriptoolbox.org/tutorial/beamformer. However, > sourceplot for not-contrasted conditions looks good. Maybe you could > give me an advice, how to get rid of this background noise. > > Kind Regards, > Elena > > > > > With difference calculation: > > cfg = []; > cfg.elec = elec; > cfg.headmodel = vol; > cfg.grid = leadfield; > cfg.keepleadfield = 'yes' > cfg.projectnoise = 'yes'; > cfg.frequency = [10 15]; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); > cfg.grid.filter = sourcePNandBS.avg.filter; > sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); > sourceBS = ft_sourceanalysis(cfg, freq_BS_Post); > *sourceDiff.avg.pow = (sourcePN.avg.pow - sourceBS.avg.pow) ./ > sourceBS.avg.pow;* > > cfg = []; > cfg.parameter = 'avg.pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > cfg.opacitymap = 'rampup'; > ft_sourceplot(cfg, sourceDiffIntNorm); > > figure > Inline images 1 > > > > > Without difference calculation: > > cfg = []; > cfg.elec = elec; > .......... > sourcePNandBS = ft_sourceanalysis(cfg, freq_PNandBS); > > cfg.grid.filter = sourcePNandBS.avg.filter; > > sourcePN = ft_sourceanalysis(cfg, freq_PN_Post); > sourcePN.avg.pow = sourcePN.avg.pow ./ sourcePN.avg.noise; > > cfg = []; > cfg.parameter = 'avg.pow'; > sourcePN = ft_sourceinterpolate(cfg, sourcePN, mri); > > cfg = []; > sourcePNIntNorm = ft_volumenormalise(cfg, sourcePNInt); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.maskparameter = cfg.funparameter; > cfg.opacitymap = 'rampup'; > ft_sourceplot(cfg, sourcePNIntNorm); > > figure > Inline images 2 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > Jens Klinzing, Uni Tübingen > Donnerstag, 19. Januar 2017 10:09 > Dear Elena, > > Question 1: > I assume the reason it takes so long is that you are using a FEM-based > headmodel. For FEM, ft_sourceanalysis computes a huge transfer matrix > on-the-fly (by calling prepare_headmodel - ft_prepare_vol_sens - > sb_transfer) every time you do a source reconstruction. For more > information see > http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=1967 . > > You can circumvent the issue by computing the transfer matrix > beforehand and changing the code in a way that it doesnt compute a new > transfer matrix if you have already provided one. > > Alternatively you could use a BEM headmodel (dipoli if possible since > bemcp seems to have issues > http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2817). > > Question 2: > Did you check your segmentation, the headmodel and the coregistration > of electrodes/head every step of the way? If you fill all inside > voxels with 1s and plot that, do you see an obvious shift/rotation of > the "activity" in relation to the MRI? > > Best, > Jens > > Elena Krugliakova > Montag, 9. Januar 2017 12:48 > Dear Fieldtrip community, > > I have a question regarding source reconstruction using the 'dics' > method applied to EEG data. > I have two problems: first, even with 32GB of RAM it takes 9 hours to > call one ft_sourceanalysis. Maybe, there is a way to optimise the > procedure somehow? > > Second, at the end of analysis I obtain a very strange figure, on > which I see activity localised outside the mri scan. Mistake on which > step of analysis might cause this problem? > > As a template I used http://www.fieldtriptoolbox.org/tutorial/beamformer > Please, find my script below. > > Thank you in advance! > > Kind Regards, > Elena > > > Script: > > % freqanalysis > cfg = []; > cfg.toilim = [-0.5 -0.1]; % prestimulus > Pre = ft_redefinetrial(cfg, MyData); > cfg = []; > cfg.toilim = [0.9 1.3]; % poststimulus > Post = ft_redefinetrial(cfg, MyData); > cfg = []; > dataAll = ft_appenddata([], Pre, Post); > > cfg = []; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd' > cfg.keeptrials = 'no'; > cfg.taper = 'dpss'; > cfg.foi = 35; > cfg.tapsmofrq = 4; > > freq_Pre = ft_freqanalysis(cfg, Pre); > freq_Post = ft_freqanalysis(cfg, Post); > freq_PrePost = ft_freqanalysis(cfg, dataAll); > > %% headmodel preparation --- with standard brain > mri = ft_read_mri('Subject01.mri'); > cfg = []; > cfg.dim = mri.dim; > mri = ft_volumereslice(cfg,mri); > > cfg = []; > cfg.output = {'gray','white','csf','skull','scalp'} > segmentedmri = ft_volumesegment(cfg, mri); > > cfg = []; > cfg.shift = 0.3; > cfg.method = 'hexahedral'; > cfg.tissue = {'gray','white','csf','skull','scalp'} > cfg.numvertices = [800, 800, 800, 400, 200]; > cfg.unit = segmentedmri.unit > bndFEM = ft_prepare_mesh(cfg,segmentedmri); > > cfg = []; > cfg.method ='simbio'; > cfg.conductivity = [0.33 0.14 1.79 0.01 0.43]; > vol_simbio_lowresol = ft_prepare_headmodel(cfg, bndFEM); > > %% loading aligned electrodes > load elec_aligned % 109 EEG electrodes > > %% leadfield preparation > cfg = []; > cfg.elec = elec_aligned; > cfg.vol = vol_simbio_lowresol; > cfg.channel = 'all'; > cfg.reducerank = 3; % 3 for eeg > cfg.grid.unit = 'mm'; > cfg.grid.resolution = 10; > leadfield_FEM_lowresol = ft_prepare_leadfield(cfg); > > %% sourceanalysis > cfg = []; > cfg.frequency = 35; > cfg.vol = vol_simbio_lowresol; > cfg.grid = leadfield_FEM_lowresol > cfg.projectnoise = 'yes'; > cfg.method = 'dics'; > cfg.dics.projectnoise = 'yes'; > cfg.dics.lambda = '5%'; > cfg.dics.keepfilter = 'yes'; > cfg.dics.realfilter = 'yes'; > sourceAll = ft_sourceanalysis(cfg, freq_PrePost); > cfg.grid.filter = sourceAll.avg.filter; > > sourcePre_con = ft_sourceanalysis(cfg, freq_Pre); > > sourcePost_con = ft_sourceanalysis(cfg, freq_Post); > > sourceDiff = sourcePost_con; > sourceDiff.avg.pow = (sourcePost_con.avg.pow - > sourcePre_con.avg.pow) ./ sourcePre_con.avg.pow; > > %% sourceplot > cfg = []; > cfg.downsample = 2; > cfg.parameter = 'pow'; > sourceDiffInt = ft_sourceinterpolate(cfg, sourceDiff, mri); > > cfg = []; > sourceDiffIntNorm = ft_volumenormalise(cfg, sourceDiffInt); > > cfg = []; > cfg.method = 'glassbrain'; > cfg.funparameter = 'pow'; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceDiffIntNorm); > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 154917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 181508 bytes Desc: not available URL: From tommy.wilson at med.einstein.yu.edu Wed Jan 25 17:13:23 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Wed, 25 Jan 2017 11:13:23 -0500 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: Hi Matt, Thanks so much for your reply here! I believe I've correctly implemented your comments: I computed a common filter by source analyzing the combined (read: averaged) data/covariance matrix. In a second step, I used this filter to source localize each condition separately. I subsequently contrasted the two conditions, but I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the voxels. I attached an image of the ft_sourceplot to this email. (I don't know why the NaNs aren't masking appropriately, but I can figure that out on my own time). I also attempted your quick and dirty solution to see if I could reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow > sourceA.avg.pow in 99% of voxels), which is exactly the opposite of what you said you came up with. (The ft_sourceplot for this scenario looks identical to the first, which is unsurprising--in both cases, we used the average covariance matrix to construct the filters, so they ought to be identical). I must be doing something wrong here, but alas, I can't seem to put the pieces together. Any help/guidance you could provide would be deeply appreciated. I've attached the updated script to this email (and printed it below for posterity), and as before, the data can be found here . Again, thank you for taking the time to respond. Best, Tommy --- CODE --- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Average both conditions to generate common filter M = ft_timelockgrandaverage(struct(),A,U); M.cov = mean(cat(3,A.cov,U.cov),3); % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances % A.cov = U.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common filter sourceM = ft_sourceanalysis(cfg,M); % Add the common filter to the cfg cfg.grid.filter = sourceM.avg.filter; % Source fit the originals sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Matt's quick and dirty version % Replace A's cov matrix with an average of A.cov and U.cov tmp = A.cov; A.cov = mean(cat(3,tmp,U.cov),3); cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common test filter sourceA_common_test = ft_sourceanalysis(cfg,A); % Add common filter to configuration cfg.grid.filter = sourceA_common_test.avg.filter; % Replace original covariance matrix A.cov = tmp; % Now fit both A and U with the common test filter sourceA_test = ft_sourceanalysis(cfg,A); sourceU_test = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrasts sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; sourceContrast_test = sourceA_test; sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; % Gauge what percent of the contrast is negative (i.e. sourceU power > % sourceA power) perc_neg = sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); perc_neg_test = sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); sourceContrast_test_interp = ft_sourceinterpolate(cfg, sourceContrast_test, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_test_interp); On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock wrote: > Hi Tommy, > > > % Equate covariance matrices for now to rule out any differences in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > This is the problem. ft_sourceanalysis is using the covariance matrix > and leadfield to construct a spatial filter for each grid point; if the > covariance matrices are equivalent, the source solutions will be too. > > What you need to do is something like run the source analysis on data > averaged over both conditions first, then take the filter from the > combined analysis and run source analysis on each condition seperately. > > so say sourceAll is the result of > ft_sourceanalysis(cfg,bothConditions) > > You'd do > > cfg.grid.filter = sourceAll.avg.filter > > then > > ft_sourceanalysis(cfg,A) > ft_sourceanalysis(cfg,U) > > As a quick and dirty version I just replaced the covariance matrix in A > with the average of the two A.cov and U.cov, ran sourceanalysis on that, > then put A.cov back to its original value and ran sourceanalysis on each > condition seperately. Spoiler: the unattended condition has lower > activity everywhere :) > > There's some weirdness around the boundaries of the headmodel, not sure > what's causing that exactly. Maybe try using a different source grid > instead of the standard one... > > Cheers, > Matt > > On 24/01/2017 16:36, Tommy Wilson wrote: > > Hi Julian, > > > > Thank you so much for your reply. > > > > I've pasted the commented code below (I apologize for the code dump). > > I've also attached an m-file to this email if you'd prefer to download > > it that way. If relevant, you can download the leadfield, headmodel and > > electrode locations here > > > > (that file also includes the raw data stored in variables A and U that I > > am attempting to source-fit). > > > > As per your questions: I do indeed have a contrast between attended (A) > > and unattended (U) conditions. I've written the code below to source-fit > > both conditions and create the contrast. However, despite that the raw > > topographies (see attached images) are different, the source-fits are > > the same (...?). As a consequence, the contrast has no non-zero values. > > If instead, I normalize to noise (i.e. generate the Neural Activity > > Index > > neural_activity_index>) > > and look at a contrast there, we again see no non-zero values. > > > > Outside of the contrast, I've implemented your other suggestions. I've > > rescaled the original ft_sourceplot such that you can see the extent of > > it (see attached image). To my mind, it shouldn't look like this, but > > having never done this before, I'm not quite sure what to expect. I've > > also included an image of the ft_sourceplot for the Neural Activity > > Index of sourceA which also appears to me to be artefactual. More to the > > point, I'd expect that since the topographies for A and U are different, > > the NAIs should be different, which is not the case. > > > > I'm sort of at a loss about how to proceed here. So, thank you very much > > for taking the time to look into this. If I can supply anything else to > > help, please don't hesitate to let me know. > > > > Best, > > > > Tommy Wilson > > > > --- CODE --- > > > > %% Source fitting protocol > > % Fieldtrip path (to find template MRI) > > ftdir = 'your\path\here\'; > > > > % Equate covariance matrices for now to rule out any differences in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > %%% Do the LCMV sourcefitting > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > sourceU = ft_sourceanalysis(cfg,U); > > > > > > %%% Attempt a contrast > > % Create the contrast > > sourceContrast = sourceA; > > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > > > % Check to see if any non-zero values exist in the contrast > > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.'); > > end > > > > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > > % See: > > http://www.fieldtriptoolbox.org/tutorial/beamformer# > neural_activity_index > > sourceA_NAI = sourceA; > > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > > sourceU_NAI = sourceU; > > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.') > > end > > > > > > %%% Visualize the output > > % Load template MRI > > mri = ft_read_mri([ftdir > > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > > > % Interpolate source onto MRI > > cfg = []; > > cfg.parameter = 'avg.pow'; > > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > > > % Visualize with ft_sourceplot > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.funcolorlim = [0 3e3]; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_interp); > > > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_NAI_interp); > > > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > > wrote: > > > > Hi Tommy, > > > > did you do some sort of contrast (e.g. with the noise estimate or a > > baseline) after your source analysis? > > Right now, it's not clear what you are looking at. Could you paste > > your code not only of the sourceanalysis, but the rest after which > > got you to the plot? > > It might also be the case that the automatic scaling in the source > > plot throws you off - maybe try setting it by hand. > > > > Good luck, > > > > Julian > > > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > > > Hi all, > > > > > > I'm working with EEG data and I'm trying to get some basic source > > fitting up and running. Unfortunately, I don't have individual > > subject MRIs, so I'm using the templates provided by fieldtrip. I've > > co-registered my 160 Biosemi electrodes to the standard_bem template > > (see attached picture). For the sourcemodel, I'm using the > > standard_sourcemodel3d5mm grid (picture attached, overlaid on > > standard_bem). I can prepare the leadfield from there with > > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV > tutorial. > > > > > > To test this configuration, I've selected a time window in my data > > and averaged across it (the covariance matrix was also calculated); > > the topography of this averaged data is attached. I then attempted a > > source fit with the LCMV beamformer: > > > > > > cfg = []; > > > cfg.method = 'lcmv'; > > > cfg.grid = leadfield; > > > cfg.vol = vol; > > > cfg.elec = elec; > > > cfg.lcmv.lambda = '15%'; > > > cfg.lcmv.keepfilter = 'yes'; > > > cfg.lcmv.fixedori = 'yes'; > > > cfg.lcmv.projectnoise = 'yes'; > > > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > > > After interpolating to the single_subj_T1.nii provided with > > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > > sourceplot that is highly focal in nature (see attached picture). > > > > > > I'd find it very surprising if this topography were generated > > primarily by a source that isn't even inside the brain (as the > > sourceplot indicates). So, I'm not sure exactly where/how I'm going > > wrong with this one, nor am I sure how to trouble shoot it. Any > > guidance you might provide would be greatly appreciated. > > > > > > Thanks so much, > > > > > > Tommy > > > > > > > localization.PNG>___________________ > ____________________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- %% Source fitting protocol % Fieldtrip path (to find template MRI) ftdir = 'your\path\here\fieldtrip-20160309'; % Average both conditions to generate common filter M = ft_timelockgrandaverage(struct(),A,U); M.cov = mean(cat(3,A.cov,U.cov),3); % Equate covariance matrices for now to rule out any differences in the % source fit due to differences in covariances % A.cov = U.cov; %%% Do the LCMV sourcefitting cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common filter sourceM = ft_sourceanalysis(cfg,M); % Add the common filter to the cfg cfg.grid.filter = sourceM.avg.filter; % Source fit the originals sourceA = ft_sourceanalysis(cfg,A); sourceU = ft_sourceanalysis(cfg,U); %%% Matt's quick and dirty version % Replace A's cov matrix with an average of A.cov and U.cov tmp = A.cov; A.cov = mean(cat(3,tmp,U.cov),3); cfg = []; cfg.method = 'lcmv'; cfg.grid = leadfield; cfg.vol = vol; cfg.elec = elec; cfg.lcmv.lambda = '15%'; cfg.lcmv.keepfilter = 'yes'; cfg.lcmv.fixedori = 'yes'; cfg.lcmv.projectnoise = 'yes'; % Generate common test filter sourceA_common_test = ft_sourceanalysis(cfg,A); % Add common filter to configuration cfg.grid.filter = sourceA_common_test.avg.filter; % Replace original covariance matrix A.cov = tmp; % Now fit both A and U with the common test filter sourceA_test = ft_sourceanalysis(cfg,A); sourceU_test = ft_sourceanalysis(cfg,U); %%% Attempt a contrast % Create the contrasts sourceContrast = sourceA; sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; sourceContrast_test = sourceA_test; sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; % Gauge what percent of the contrast is negative (i.e. sourceU power > % sourceA power) perc_neg = sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); perc_neg_test = sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); %%% Visualize the output % Load template MRI mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); % Interpolate source onto MRI cfg = []; cfg.parameter = 'avg.pow'; sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); sourceContrast_test_interp = ft_sourceinterpolate(cfg, sourceContrast_test, mri); % Visualize with ft_sourceplot cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_interp); cfg = []; cfg.method = 'ortho'; cfg.funparameter = 'avg.pow'; cfg.funcolorlim = [-100 5]; cfg.maskparameter = cfg.funparameter; ft_sourceplot(cfg, sourceContrast_test_interp); -------------- next part -------------- A non-text attachment was scrubbed... Name: sourceContrast_sourceplot.PNG Type: image/png Size: 128252 bytes Desc: not available URL: From m.p.craddock at leeds.ac.uk Wed Jan 25 18:11:41 2017 From: m.p.craddock at leeds.ac.uk (Matt Craddock) Date: Wed, 25 Jan 2017 17:11:41 +0000 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> Message-ID: <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> Sorry Tommy, I misread the sign of my results - they're the same as yours :) I get the NaNs plotting thing sometimes too, never totally sure why as it seems intermittent. Cheers, Matt On 25/01/2017 16:13, Tommy Wilson wrote: > Hi Matt, > > Thanks so much for your reply here! > > I believe I've correctly implemented your comments: I computed a common > filter by source analyzing the combined (read: averaged) data/covariance > matrix. In a second step, I used this filter to source localize each > condition separately. I subsequently contrasted the two conditions, but > I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the > voxels. I attached an image of the ft_sourceplot to this email. (I don't > know why the NaNs aren't masking appropriately, but I can figure that > out on my own time). > > I also attempted your quick and dirty solution to see if I could > reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow >> sourceA.avg.pow in 99% of voxels), which is exactly the opposite of > what you said you came up with. (The ft_sourceplot for this scenario > looks identical to the first, which is unsurprising--in both cases, we > used the average covariance matrix to construct the filters, so they > ought to be identical). I must be doing something wrong here, but alas, > I can't seem to put the pieces together. > > Any help/guidance you could provide would be deeply appreciated. I've > attached the updated script to this email (and printed it below for > posterity), and as before, the data can be found here > . > > Again, thank you for taking the time to respond. > > Best, > > Tommy > > --- CODE --- > > %% Source fitting protocol > % Fieldtrip path (to find template MRI) > ftdir = 'your\path\here\fieldtrip-20160309'; > > % Average both conditions to generate common filter > M = ft_timelockgrandaverage(struct(),A,U); > M.cov = mean(cat(3,A.cov,U.cov),3); > > % Equate covariance matrices for now to rule out any differences in the > % source fit due to differences in covariances > % A.cov = U.cov; > > %%% Do the LCMV sourcefitting > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > % Generate common filter > sourceM = ft_sourceanalysis(cfg,M); > > % Add the common filter to the cfg > cfg.grid.filter = sourceM.avg.filter; > > % Source fit the originals > sourceA = ft_sourceanalysis(cfg,A); > sourceU = ft_sourceanalysis(cfg,U); > > %%% Matt's quick and dirty version > % Replace A's cov matrix with an average of A.cov and U.cov > tmp = A.cov; > A.cov = mean(cat(3,tmp,U.cov),3); > > cfg = []; > cfg.method = 'lcmv'; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.elec = elec; > cfg.lcmv.lambda = '15%'; > cfg.lcmv.keepfilter = 'yes'; > cfg.lcmv.fixedori = 'yes'; > cfg.lcmv.projectnoise = 'yes'; > > % Generate common test filter > sourceA_common_test = ft_sourceanalysis(cfg,A); > > % Add common filter to configuration > cfg.grid.filter = sourceA_common_test.avg.filter; > > % Replace original covariance matrix > A.cov = tmp; > > % Now fit both A and U with the common test filter > sourceA_test = ft_sourceanalysis(cfg,A); > sourceU_test = ft_sourceanalysis(cfg,U); > > > %%% Attempt a contrast > % Create the contrasts > sourceContrast = sourceA; > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > sourceContrast_test = sourceA_test; > sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; > > % Gauge what percent of the contrast is negative (i.e. sourceU power > > % sourceA power) > perc_neg = > sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./numel(sourceContrast.avg.pow(sourceContrast.inside(:))); > perc_neg_test = > sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); > > %%% Visualize the output > % Load template MRI > mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); > > % Interpolate source onto MRI > cfg = []; > cfg.parameter = 'avg.pow'; > sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); > sourceContrast_test_interp = ft_sourceinterpolate(cfg, > sourceContrast_test, mri); > > % Visualize with ft_sourceplot > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [-100 5]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceContrast_interp); > > cfg = []; > cfg.method = 'ortho'; > cfg.funparameter = 'avg.pow'; > cfg.funcolorlim = [-100 5]; > cfg.maskparameter = cfg.funparameter; > ft_sourceplot(cfg, sourceContrast_test_interp); > > On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock > wrote: > > Hi Tommy, > > > % Equate covariance matrices for now to rule out any differences > in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > This is the problem. ft_sourceanalysis is using the covariance matrix > and leadfield to construct a spatial filter for each grid point; if the > covariance matrices are equivalent, the source solutions will be too. > > What you need to do is something like run the source analysis on data > averaged over both conditions first, then take the filter from the > combined analysis and run source analysis on each condition seperately. > > so say sourceAll is the result of > ft_sourceanalysis(cfg,bothConditions) > > You'd do > > cfg.grid.filter = sourceAll.avg.filter > > then > > ft_sourceanalysis(cfg,A) > ft_sourceanalysis(cfg,U) > > As a quick and dirty version I just replaced the covariance matrix in A > with the average of the two A.cov and U.cov, ran sourceanalysis on that, > then put A.cov back to its original value and ran sourceanalysis on each > condition seperately. Spoiler: the unattended condition has lower > activity everywhere :) > > There's some weirdness around the boundaries of the headmodel, not sure > what's causing that exactly. Maybe try using a different source grid > instead of the standard one... > > Cheers, > Matt > > On 24/01/2017 16:36, Tommy Wilson wrote: > > Hi Julian, > > > > Thank you so much for your reply. > > > > I've pasted the commented code below (I apologize for the code dump). > > I've also attached an m-file to this email if you'd prefer to download > > it that way. If relevant, you can download the leadfield, > headmodel and > > electrode locations here > > > > > > (that file also includes the raw data stored in variables A and U > that I > > am attempting to source-fit). > > > > As per your questions: I do indeed have a contrast between > attended (A) > > and unattended (U) conditions. I've written the code below to > source-fit > > both conditions and create the contrast. However, despite that the raw > > topographies (see attached images) are different, the source-fits are > > the same (...?). As a consequence, the contrast has no non-zero > values. > > If instead, I normalize to noise (i.e. generate the Neural Activity > > Index > > > >) > > and look at a contrast there, we again see no non-zero values. > > > > Outside of the contrast, I've implemented your other suggestions. I've > > rescaled the original ft_sourceplot such that you can see the > extent of > > it (see attached image). To my mind, it shouldn't look like this, but > > having never done this before, I'm not quite sure what to expect. I've > > also included an image of the ft_sourceplot for the Neural Activity > > Index of sourceA which also appears to me to be artefactual. More > to the > > point, I'd expect that since the topographies for A and U are > different, > > the NAIs should be different, which is not the case. > > > > I'm sort of at a loss about how to proceed here. So, thank you > very much > > for taking the time to look into this. If I can supply anything > else to > > help, please don't hesitate to let me know. > > > > Best, > > > > Tommy Wilson > > > > --- CODE --- > > > > %% Source fitting protocol > > % Fieldtrip path (to find template MRI) > > ftdir = 'your\path\here\'; > > > > % Equate covariance matrices for now to rule out any differences > in the > > % source fit due to differences in covariances > > U.cov = A.cov; > > > > %%% Do the LCMV sourcefitting > > cfg = []; > > cfg.method = 'lcmv'; > > cfg.grid = leadfield; > > cfg.vol = vol; > > cfg.elec = elec; > > cfg.lcmv.lambda = '15%'; > > cfg.lcmv.keepfilter = 'yes'; > > cfg.lcmv.fixedori = 'yes'; > > cfg.lcmv.projectnoise = 'yes'; > > > > sourceA = ft_sourceanalysis(cfg,A); > > sourceU = ft_sourceanalysis(cfg,U); > > > > > > %%% Attempt a contrast > > % Create the contrast > > sourceContrast = sourceA; > > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; > > > > % Check to see if any non-zero values exist in the contrast > > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.'); > > end > > > > > > %%% Instead of a contrast, look at the Neural Activity Index (NAI) > > % See: > > > http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_activity_index > > > sourceA_NAI = sourceA; > > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; > > sourceU_NAI = sourceU; > > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; > > > > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - > > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) > > warning('No non-zero contast values exist. ft_sourceplot will give > > an error. Do not plot.') > > end > > > > > > %%% Visualize the output > > % Load template MRI > > mri = ft_read_mri([ftdir > > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); > > > > % Interpolate source onto MRI > > cfg = []; > > cfg.parameter = 'avg.pow'; > > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); > > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); > > > > % Visualize with ft_sourceplot > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.funcolorlim = [0 3e3]; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_interp); > > > > cfg = []; > > cfg.method = 'ortho'; > > cfg.funparameter = 'avg.pow'; > > cfg.maskparameter = cfg.funparameter; > > ft_sourceplot(cfg, sourceA_NAI_interp); > > > > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > > >> wrote: > > > > Hi Tommy, > > > > did you do some sort of contrast (e.g. with the noise estimate > or a > > baseline) after your source analysis? > > Right now, it's not clear what you are looking at. Could you paste > > your code not only of the sourceanalysis, but the rest after which > > got you to the plot? > > It might also be the case that the automatic scaling in the source > > plot throws you off - maybe try setting it by hand. > > > > Good luck, > > > > Julian > > > > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: > > > > > Hi all, > > > > > > I'm working with EEG data and I'm trying to get some basic > source > > fitting up and running. Unfortunately, I don't have individual > > subject MRIs, so I'm using the templates provided by > fieldtrip. I've > > co-registered my 160 Biosemi electrodes to the standard_bem > template > > (see attached picture). For the sourcemodel, I'm using the > > standard_sourcemodel3d5mm grid (picture attached, overlaid on > > standard_bem). I can prepare the leadfield from there with > > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV > tutorial. > > > > > > To test this configuration, I've selected a time window in > my data > > and averaged across it (the covariance matrix was also > calculated); > > the topography of this averaged data is attached. I then > attempted a > > source fit with the LCMV beamformer: > > > > > > cfg = []; > > > cfg.method = 'lcmv'; > > > cfg.grid = leadfield; > > > cfg.vol = vol; > > > cfg.elec = elec; > > > cfg.lcmv.lambda = '15%'; > > > cfg.lcmv.keepfilter = 'yes'; > > > cfg.lcmv.fixedori = 'yes'; > > > cfg.lcmv.projectnoise = 'yes'; > > > > > > sourceA = ft_sourceanalysis(cfg,A); > > > > > > After interpolating to the single_subj_T1.nii provided with > > ft_sourceinterpolate and plotting with ft_sourceplot, I am given a > > sourceplot that is highly focal in nature (see attached picture). > > > > > > I'd find it very surprising if this topography were generated > > primarily by a source that isn't even inside the brain (as the > > sourceplot indicates). So, I'm not sure exactly where/how I'm > going > > wrong with this one, nor am I sure how to trouble shoot it. Any > > guidance you might provide would be greatly appreciated. > > > > > > Thanks so much, > > > > > > Tommy > > > > > > > > localization.PNG>_______________________________________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From tommy.wilson at med.einstein.yu.edu Wed Jan 25 20:47:13 2017 From: tommy.wilson at med.einstein.yu.edu (Tommy Wilson) Date: Wed, 25 Jan 2017 14:47:13 -0500 Subject: [FieldTrip] Source fitting with template MRI/Headmodel In-Reply-To: <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> References: <5E76C2D6-CA5B-4E6D-90F9-B3A97AFAA58E@gmail.com> <4614a9bb-7dee-6ff7-12b6-2fed8c10e96d@leeds.ac.uk> Message-ID: Oh! Whew. Well, at least there's that. (It's the small things, you know?) But, doesn't that lead to another question? As you can see from the topographies attached, the Attended topography is much higher in amplitude than the unattended (they are on the same color scale). Perhaps this is a moment when my intuition doesn't matter, but wouldn't you expect that the source generating the Attended topography would have greater power than the Unattended source? Or is there something I don't understand here? Thanks again for taking the time to respond. I truly appreciate your help. Best, Tommy On Wed, Jan 25, 2017 at 12:11 PM, Matt Craddock wrote: > Sorry Tommy, I misread the sign of my results - they're the same as yours > :) I get the NaNs plotting thing sometimes too, never totally sure why as > it seems intermittent. > > Cheers, > Matt > > On 25/01/2017 16:13, Tommy Wilson wrote: > >> Hi Matt, >> >> Thanks so much for your reply here! >> >> I believe I've correctly implemented your comments: I computed a common >> filter by source analyzing the combined (read: averaged) data/covariance >> matrix. In a second step, I used this filter to source localize each >> condition separately. I subsequently contrasted the two conditions, but >> I'm seeing that sourceU.avg.pow > sourceA.avg.pow at about 99% of the >> voxels. I attached an image of the ft_sourceplot to this email. (I don't >> know why the NaNs aren't masking appropriately, but I can figure that >> out on my own time). >> >> I also attempted your quick and dirty solution to see if I could >> reproduce that, and I'm seeing the same thing as above (sourceU.avg.pow >> >>> sourceA.avg.pow in 99% of voxels), which is exactly the opposite of >>> >> what you said you came up with. (The ft_sourceplot for this scenario >> looks identical to the first, which is unsurprising--in both cases, we >> used the average covariance matrix to construct the filters, so they >> ought to be identical). I must be doing something wrong here, but alas, >> I can't seem to put the pieces together. >> >> Any help/guidance you could provide would be deeply appreciated. I've >> attached the updated script to this email (and printed it below for >> posterity), and as before, the data can be found here >> . >> >> >> Again, thank you for taking the time to respond. >> >> Best, >> >> Tommy >> >> --- CODE --- >> >> %% Source fitting protocol >> % Fieldtrip path (to find template MRI) >> ftdir = 'your\path\here\fieldtrip-20160309'; >> >> % Average both conditions to generate common filter >> M = ft_timelockgrandaverage(struct(),A,U); >> M.cov = mean(cat(3,A.cov,U.cov),3); >> >> % Equate covariance matrices for now to rule out any differences in the >> % source fit due to differences in covariances >> % A.cov = U.cov; >> >> %%% Do the LCMV sourcefitting >> cfg = []; >> cfg.method = 'lcmv'; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.elec = elec; >> cfg.lcmv.lambda = '15%'; >> cfg.lcmv.keepfilter = 'yes'; >> cfg.lcmv.fixedori = 'yes'; >> cfg.lcmv.projectnoise = 'yes'; >> >> % Generate common filter >> sourceM = ft_sourceanalysis(cfg,M); >> >> % Add the common filter to the cfg >> cfg.grid.filter = sourceM.avg.filter; >> >> % Source fit the originals >> sourceA = ft_sourceanalysis(cfg,A); >> sourceU = ft_sourceanalysis(cfg,U); >> >> %%% Matt's quick and dirty version >> % Replace A's cov matrix with an average of A.cov and U.cov >> tmp = A.cov; >> A.cov = mean(cat(3,tmp,U.cov),3); >> >> cfg = []; >> cfg.method = 'lcmv'; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.elec = elec; >> cfg.lcmv.lambda = '15%'; >> cfg.lcmv.keepfilter = 'yes'; >> cfg.lcmv.fixedori = 'yes'; >> cfg.lcmv.projectnoise = 'yes'; >> >> % Generate common test filter >> sourceA_common_test = ft_sourceanalysis(cfg,A); >> >> % Add common filter to configuration >> cfg.grid.filter = sourceA_common_test.avg.filter; >> >> % Replace original covariance matrix >> A.cov = tmp; >> >> % Now fit both A and U with the common test filter >> sourceA_test = ft_sourceanalysis(cfg,A); >> sourceU_test = ft_sourceanalysis(cfg,U); >> >> >> %%% Attempt a contrast >> % Create the contrasts >> sourceContrast = sourceA; >> sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; >> sourceContrast_test = sourceA_test; >> sourceContrast_test.avg.pow = sourceA_test.avg.pow - sourceU_test.avg.pow; >> >> % Gauge what percent of the contrast is negative (i.e. sourceU power > >> % sourceA power) >> perc_neg = >> sum(sourceContrast.avg.pow(sourceContrast.inside(:))<0)./num >> el(sourceContrast.avg.pow(sourceContrast.inside(:))); >> perc_neg_test = >> sum(sourceContrast_test.avg.pow(sourceContrast_test.inside(: >> ))<0)./numel(sourceContrast_test.avg.pow(sourceContrast_test.inside(:))); >> >> %%% Visualize the output >> % Load template MRI >> mri = ft_read_mri([ftdir '\template\anatomy\single_subj_T1.nii']); >> >> % Interpolate source onto MRI >> cfg = []; >> cfg.parameter = 'avg.pow'; >> sourceContrast_interp = ft_sourceinterpolate(cfg, sourceContrast, mri); >> sourceContrast_test_interp = ft_sourceinterpolate(cfg, >> sourceContrast_test, mri); >> >> % Visualize with ft_sourceplot >> cfg = []; >> cfg.method = 'ortho'; >> cfg.funparameter = 'avg.pow'; >> cfg.funcolorlim = [-100 5]; >> cfg.maskparameter = cfg.funparameter; >> ft_sourceplot(cfg, sourceContrast_interp); >> >> cfg = []; >> cfg.method = 'ortho'; >> cfg.funparameter = 'avg.pow'; >> cfg.funcolorlim = [-100 5]; >> cfg.maskparameter = cfg.funparameter; >> ft_sourceplot(cfg, sourceContrast_test_interp); >> >> On Tue, Jan 24, 2017 at 4:12 PM Matt Craddock > > wrote: >> >> Hi Tommy, >> >> > % Equate covariance matrices for now to rule out any differences >> in the >> > % source fit due to differences in covariances >> > U.cov = A.cov; >> > >> >> This is the problem. ft_sourceanalysis is using the covariance matrix >> and leadfield to construct a spatial filter for each grid point; if >> the >> covariance matrices are equivalent, the source solutions will be too. >> >> What you need to do is something like run the source analysis on data >> averaged over both conditions first, then take the filter from the >> combined analysis and run source analysis on each condition >> seperately. >> >> so say sourceAll is the result of >> ft_sourceanalysis(cfg,bothConditions) >> >> You'd do >> >> cfg.grid.filter = sourceAll.avg.filter >> >> then >> >> ft_sourceanalysis(cfg,A) >> ft_sourceanalysis(cfg,U) >> >> As a quick and dirty version I just replaced the covariance matrix in >> A >> with the average of the two A.cov and U.cov, ran sourceanalysis on >> that, >> then put A.cov back to its original value and ran sourceanalysis on >> each >> condition seperately. Spoiler: the unattended condition has lower >> activity everywhere :) >> >> There's some weirdness around the boundaries of the headmodel, not >> sure >> what's causing that exactly. Maybe try using a different source grid >> instead of the standard one... >> >> Cheers, >> Matt >> >> On 24/01/2017 16:36, Tommy Wilson wrote: >> > Hi Julian, >> > >> > Thank you so much for your reply. >> > >> > I've pasted the commented code below (I apologize for the code >> dump). >> > I've also attached an m-file to this email if you'd prefer to >> download >> > it that way. If relevant, you can download the leadfield, >> headmodel and >> > electrode locations here >> > >> > dump.mat?dl=0 >> > dump.mat?dl=0>> >> > (that file also includes the raw data stored in variables A and U >> that I >> > am attempting to source-fit). >> > >> > As per your questions: I do indeed have a contrast between >> attended (A) >> > and unattended (U) conditions. I've written the code below to >> source-fit >> > both conditions and create the contrast. However, despite that the >> raw >> > topographies (see attached images) are different, the source-fits >> are >> > the same (...?). As a consequence, the contrast has no non-zero >> values. >> > If instead, I normalize to noise (i.e. generate the Neural Activity >> > Index >> > >> > activity_index >> > activity_index>>) >> > and look at a contrast there, we again see no non-zero values. >> > >> > Outside of the contrast, I've implemented your other suggestions. >> I've >> > rescaled the original ft_sourceplot such that you can see the >> extent of >> > it (see attached image). To my mind, it shouldn't look like this, >> but >> > having never done this before, I'm not quite sure what to expect. >> I've >> > also included an image of the ft_sourceplot for the Neural Activity >> > Index of sourceA which also appears to me to be artefactual. More >> to the >> > point, I'd expect that since the topographies for A and U are >> different, >> > the NAIs should be different, which is not the case. >> > >> > I'm sort of at a loss about how to proceed here. So, thank you >> very much >> > for taking the time to look into this. If I can supply anything >> else to >> > help, please don't hesitate to let me know. >> > >> > Best, >> > >> > Tommy Wilson >> > >> > --- CODE --- >> > >> > %% Source fitting protocol >> > % Fieldtrip path (to find template MRI) >> > ftdir = 'your\path\here\'; >> > >> > % Equate covariance matrices for now to rule out any differences >> in the >> > % source fit due to differences in covariances >> > U.cov = A.cov; >> > >> > %%% Do the LCMV sourcefitting >> > cfg = []; >> > cfg.method = 'lcmv'; >> > cfg.grid = leadfield; >> > cfg.vol = vol; >> > cfg.elec = elec; >> > cfg.lcmv.lambda = '15%'; >> > cfg.lcmv.keepfilter = 'yes'; >> > cfg.lcmv.fixedori = 'yes'; >> > cfg.lcmv.projectnoise = 'yes'; >> > >> > sourceA = ft_sourceanalysis(cfg,A); >> > sourceU = ft_sourceanalysis(cfg,U); >> > >> > >> > %%% Attempt a contrast >> > % Create the contrast >> > sourceContrast = sourceA; >> > sourceContrast.avg.pow = sourceA.avg.pow - sourceU.avg.pow; >> > >> > % Check to see if any non-zero values exist in the contrast >> > if all(sourceContrast.avg.pow(sourceContrast.inside(:)) == 0) >> > warning('No non-zero contast values exist. ft_sourceplot will >> give >> > an error. Do not plot.'); >> > end >> > >> > >> > %%% Instead of a contrast, look at the Neural Activity Index (NAI) >> > % See: >> > >> http://www.fieldtriptoolbox.org/tutorial/beamformer#neural_ >> activity_index >> > activity_index> >> > sourceA_NAI = sourceA; >> > sourceA_NAI.avg.pow = sourceA.avg.pow./sourceA.avg.noise; >> > sourceU_NAI = sourceU; >> > sourceU_NAI.avg.pow = sourceU.avg.pow./sourceU.avg.noise; >> > >> > if all(sourceA_NAI.avg.pow(sourceA_NAI.inside(:)) - >> > sourceU_NAI.avg.pow(sourceU_NAI.inside(:))==0) >> > warning('No non-zero contast values exist. ft_sourceplot will >> give >> > an error. Do not plot.') >> > end >> > >> > >> > %%% Visualize the output >> > % Load template MRI >> > mri = ft_read_mri([ftdir >> > '\fieldtrip-20160309\template\anatomy\single_subj_T1.nii']); >> > >> > % Interpolate source onto MRI >> > cfg = []; >> > cfg.parameter = 'avg.pow'; >> > sourceA_interp = ft_sourceinterpolate(cfg, sourceA, mri); >> > sourceA_NAI_interp = ft_sourceinterpolate(cfg, sourceA_NAI, mri); >> > >> > % Visualize with ft_sourceplot >> > cfg = []; >> > cfg.method = 'ortho'; >> > cfg.funparameter = 'avg.pow'; >> > cfg.funcolorlim = [0 3e3]; >> > cfg.maskparameter = cfg.funparameter; >> > ft_sourceplot(cfg, sourceA_interp); >> > >> > cfg = []; >> > cfg.method = 'ortho'; >> > cfg.funparameter = 'avg.pow'; >> > cfg.maskparameter = cfg.funparameter; >> > ft_sourceplot(cfg, sourceA_NAI_interp); >> > >> > On Tue, Jan 24, 2017 at 3:42 AM Julian Keil > >> > >> >> wrote: >> > >> > Hi Tommy, >> > >> > did you do some sort of contrast (e.g. with the noise estimate >> or a >> > baseline) after your source analysis? >> > Right now, it's not clear what you are looking at. Could you >> paste >> > your code not only of the sourceanalysis, but the rest after >> which >> > got you to the plot? >> > It might also be the case that the automatic scaling in the >> source >> > plot throws you off - maybe try setting it by hand. >> > >> > Good luck, >> > >> > Julian >> > >> > Am 23.01.2017 um 22:00 schrieb Tommy Wilson: >> > >> > > Hi all, >> > > >> > > I'm working with EEG data and I'm trying to get some basic >> source >> > fitting up and running. Unfortunately, I don't have individual >> > subject MRIs, so I'm using the templates provided by >> fieldtrip. I've >> > co-registered my 160 Biosemi electrodes to the standard_bem >> template >> > (see attached picture). For the sourcemodel, I'm using the >> > standard_sourcemodel3d5mm grid (picture attached, overlaid on >> > standard_bem). I can prepare the leadfield from there with >> > ft_prepare_leadfield (cfg.normalize = 'yes'), as per the LCMV >> tutorial. >> > > >> > > To test this configuration, I've selected a time window in >> my data >> > and averaged across it (the covariance matrix was also >> calculated); >> > the topography of this averaged data is attached. I then >> attempted a >> > source fit with the LCMV beamformer: >> > > >> > > cfg = []; >> > > cfg.method = 'lcmv'; >> > > cfg.grid = leadfield; >> > > cfg.vol = vol; >> > > cfg.elec = elec; >> > > cfg.lcmv.lambda = '15%'; >> > > cfg.lcmv.keepfilter = 'yes'; >> > > cfg.lcmv.fixedori = 'yes'; >> > > cfg.lcmv.projectnoise = 'yes'; >> > > >> > > sourceA = ft_sourceanalysis(cfg,A); >> > > >> > > After interpolating to the single_subj_T1.nii provided with >> > ft_sourceinterpolate and plotting with ft_sourceplot, I am >> given a >> > sourceplot that is highly focal in nature (see attached >> picture). >> > > >> > > I'd find it very surprising if this topography were generated >> > primarily by a source that isn't even inside the brain (as the >> > sourceplot indicates). So, I'm not sure exactly where/how I'm >> going >> > wrong with this one, nor am I sure how to trouble shoot it. Any >> > guidance you might provide would be greatly appreciated. >> > > >> > > Thanks so much, >> > > >> > > Tommy >> > > >> > > > > >> localization.PNG>____________________ >> ___________________________ >> > > fieldtrip mailing list >> > > fieldtrip at donders.ru.nl >> > >> > > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > >> > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Attended.PNG Type: image/png Size: 92946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Topo_Unattended.PNG Type: image/png Size: 91677 bytes Desc: not available URL: From suzannevdveldt at gmail.com Wed Jan 25 22:55:44 2017 From: suzannevdveldt at gmail.com (Suzanne van der Veldt) Date: Wed, 25 Jan 2017 16:55:44 -0500 Subject: [FieldTrip] extracting spikes from new Message-ID: Hello all, Sorry to trouble you. I am excited to get starting with using FieldTrip for my data analysis, using in vivo ephys data recorded with plexon. I have my sorted spikes in .nex format. Unfortunately, field trip does not seem to be able to import my data. >> [rec1] = ft_read_spike('test', 'plexon_nex', '/Users/username/Documents/export’) Error using ft_read_spike (line 276) unsupported data format (unknown The .nex file is a regular file. I am running Matlab R2015b from Mac OSx Sierra 10.12.2. I hope someone might be able to give me a hint of what might be the problem. Kind regards, Suzanne van der Veldt PhD student McGill & Université de Bordeaux From tfkustermann at gmail.com Thu Jan 26 17:34:11 2017 From: tfkustermann at gmail.com (Thomas Kustermann) Date: Thu, 26 Jan 2017 17:34:11 +0100 Subject: [FieldTrip] Source statistic issue - between trials In-Reply-To: References: Message-ID: Hey Michał, I think your problem lies within the use of "ft_statfun_depsamplesT". FieldTrip then assumes that each trial index from condition one is paired with the same trial index from condition two which is why you get the output "repeated measurement in variable 2 over 11 levels number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 " In your case the design matrix should only include your first row and no uvar, statfun being ft_statfun_indepsamplesT. See: http://www.fieldtriptoolbox.org/tutorial/cluster_permutation _freq#permutation_test Cheers On Tue, Jan 24, 2017 at 3:21 PM, Michał Komorowski wrote: > Dear community, > > Currently I am working on source analysis from EEG data. I have some > trouble using ft_sourcestatistics do a between-trials analysis (single > subject). > I am trying to compare source from trials from task type A (ctrl) to with > trials from task type B (task). Mainly I rely on > http://www.fieldtriptoolbox.org/example/source_statistics . > > For almost week I am trying find a solution, inculding testing > ft_sourcestatistics with different combinations of data: > 1) source 1 : no ft_sourcedescriptives and no ft_sourceinterpolate used > 2) source 2 : used ft_sourcedescriptives and no ft_sourceinterpolate used > 3) source 3 : used ft_sourcedescriptives and used ft_sourceinterpolate > > For cases 1) and 2) I get very similar errors "Invalid specification of > the design array. Error using ft_statistics_montecarlo (line 242) could not > determine the parametric critical value for clustering" (full error > messages at the bottom). In case 3) I cannot run ft_statistics because > there are no trials anymore. > I have tried changing design matrix, search community messages for some > advice and read related articles on fieldtriptoolbox site, but I have not > find the answer. > > Any help would be appreciated. > > Michał Komorowski > > > Statistics code: > > cfg = []; > %cfg.dim = source.dim; % there is no such field in the data > cfg.method = 'montecarlo'; > cfg.statistic = 'ft_statfun_depsamplesT'; > cfg.parameter = 'pow'; > cfg.correctm = 'cluster'; > cfg.numrandomization = 100; > cfg.alpha = 0.05; > cfg.correcttail = 'alpha'; % http://www.fieldtriptoolbox.or > g/faq/why_should_i_use_the_cfg.correcttail_option_when_using > _statistics_montecarlo > cfg.tail = 0; % two sided test > cfg.design(1,:) = design; % condition code > cfg.design(2,:) = [1:length(find(design==1)) 1:length(find(design==2))]; % > trial indices > cfg.uvar = 2; % unit of observation variable: trials > cfg.ivar = 1; % independent variable: condition code > % I think design matrix is ok according to: http://www.fieldtriptoolbox.or > g/walkthrough#paired_comparison) > > stat = ft_sourcestatistics(cfg, source); > > > > > Data structures and error messages > > Case 1) no ft_sourcedescriptives and no ft_sourceinterpolate used > > source = > > freq: 10 > cumtapcnt: [21x1 double] > inside: [231420x1 logical] > pos: [231420x3 double] > method: 'rawtrial' > trial: [1x21 struct] > df: 21 > cfg: [1x1 struct] > > the call to "ft_selectdata" took 1 seconds > using "ft_statistics_montecarlo" for the statistical testing > using connectivity of voxels in 3-D volume > using "ft_statfun_depsamplesT" for the single-sample statistics > constructing randomized design > total number of measurements = 21 > total number of variables = 2 > number of independent variables = 1 > number of unit variables = 1 > number of within-cell variables = 0 > number of control variables = 0 > using a permutation resampling approach > repeated measurement in variable 2 over 11 levels > number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 > computing a parametric threshold for clustering > Error using ft_statfun_depsamplesT (line 84) > Invalid specification of the design array. > Error using ft_statistics_montecarlo (line 242) > could not determine the parametric critical value for clustering > > Error in ft_sourcestatistics (line 205) > [stat, cfg] = statmethod(cfg, dat, design); > > >> cfg.design > > ans = > > 1 1 1 1 1 1 1 1 1 1 1 2 > 2 2 2 2 2 2 2 2 2 > 1 2 3 4 5 6 7 8 9 10 11 1 > 2 3 4 5 6 7 8 9 10 > > > > Case 2) used ft_sourcedescriptives and no ft_sourceinterpolate used > > source_app = > > freq: 10 > cumtapcnt: [21x1 double] > inside: [231420x1 logical] > pos: [231420x3 double] > method: 'rawtrial' > trial: [1x21 struct] > df: 21 > cfg: [1x1 struct] > > the call to "ft_selectdata" took 0 seconds > using "ft_statistics_montecarlo" for the statistical testing > using connectivity of voxels in 3-D volume > using "ft_statfun_depsamplesT" for the single-sample statistics > constructing randomized design > total number of measurements = 21 > total number of variables = 2 > number of independent variables = 1 > number of unit variables = 1 > number of within-cell variables = 0 > number of control variables = 0 > using a permutation resampling approach > repeated measurement in variable 2 over 11 levels > number of repeated measurements in each level is 2 2 2 2 2 2 2 2 2 2 1 > computing a parametric threshold for clustering > Error using ft_statfun_depsamplesT (line 84) > Invalid specification of the design array. > Error using ft_statistics_montecarlo (line 242) > could not determine the parametric critical value for clustering > > Error in ft_sourcestatistics (line 205) > [stat, cfg] = statmethod(cfg, dat, design); > > > > Case 3) used ft_sourcedescriptives and used ft_sourceinterpolate > > source_mri_align_ctrl = > > freq: 10 > anatomy: [128x128x128 double] > coordsys: 'spm' > dim: [128 128 128] > pos: [2097152x3 double] > transform: [4x4 double] > unit: 'mm' > inside: [128x128x128 logical] > pow: [2097152x1 double] > cfg: [1x1 struct] > > % there is no trials so one cannot conduct between-trials statistics ... > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behzadiravani at gmail.com Thu Jan 26 17:36:28 2017 From: behzadiravani at gmail.com (Behzad Iravani) Date: Thu, 26 Jan 2017 17:36:28 +0100 Subject: [FieldTrip] Symmetric Source Reconstruction Message-ID: Dear FieldTrip experts , I'm interested to perform symmetric source reconstruction on time lock data. However I encountered an error. here is my code: cfg = []; cfg.grid.unit = 'mm'; cfg.grid.resolution = 5; cfg.grid.tight = 'yes'; cfg.inwardshift = -2; cfg.headmodel = vol; cfg.symmetric ='y'; % symmetric sources grid = ft_prepare_sourcemodel(cfg); % timelock data for two conditions load timelockA %co-variance computed load timelockB %co-variance computed load timeloackAB %co-variance computed load elecfile.mat % sensor positions load vol.mat % pre-compute head model cfg = []; cfg.method = 'lcmv'; cfg.grid = grid; cfg.headmodel = vol; cfg.elec = elecfile; cfg.keepfilter = 'yes'; source = ft_sourceanalysis(timeloackAB); % compute common filter cfg.keepfilter = 'no'; cfg.grid.filter =source.avg.filter sourceA = ft_sourceanalysis(timeloackA); % compute common filter sourceB = ft_sourceanalysis(timeloackA); % compute common filter % Contrast Condition A versus B cfg = []; cfg.parameter = 'pow'; cfg.operation = '(x1./x2-1)'; SourceC= ft_math(cfg,sourceA ,sourceB); load mri.mat % load anatomical image cfg = []; cfg.parameter = 'pow'; sourcePostInt = ft_sourceinterpolate(cfg, SourceC ,mri); here I get error in ft_warp_apply because the grid.pos is 6*n which it is supposed to be 3*n, since I chose the symmetric option it turned to 6*n. How can I solve this problem? Thanks in advance Best Behzad -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.chait at ucl.ac.uk Thu Jan 26 18:11:34 2017 From: m.chait at ucl.ac.uk (Chait, Maria) Date: Thu, 26 Jan 2017 17:11:34 +0000 Subject: [FieldTrip] (deadline approaching) Post-Doc position at UCL Ear Institute Message-ID: (please forward) A postdoctoral research associate position is available at the UCL Ear Institute's 'Auditory Cognitive Neuroscience Lab'. The project, titled "How the brain detects patterns in sound sequences", will be supervised by Dr Maria Chait and conducted in collaboration with Dr. Marcus Pearce (Queen Mary University, London) and colleagues at the UCL Wellcome Trust centre for neuroimaging. The post is funded for 34 months in the first instance and involves a combination of behavioural, computational, eye tracking, and functional brain imaging (EEG, MEG, fMRI) experiments in humans. For more information about the post please see the lab website: http://www.ucl.ac.uk/ear/research/chaitlab/vacancies The Ear Institute is a leading interdisciplinary centre for hearing research in Europe, situated within one of the strongest neuroscience communities in the world at University College London Key Requirements The successful applicant will have a PhD in neuroscience or a neuroscience-related discipline and proven ability to conduct high-quality original research and prepare results for publication. Essential skills include excellent time-management and organizational ability; proficiency in computer programming and good interpersonal, oral and written communication skills. Previous experience with functional brain imaging, neural data analysis, psychophysical assessment, and/or auditory science or acoustics would be desirable. Further Details You should apply for this post (Ref #: 1618836) through UCL's online recruitment website, www.ucl.ac.uk/hr/jobs, where you can download a job description and person specifications. Closing Date for applications is: 1 Feb 2017 For an informal discussion please contact Dr. Maria Chait (m.chait at ucl.ac.uk). Maria Chait PhD m.chait at ucl.ac.uk Reader in Auditory Cognitive Neuroscience Lab site: http://www.ucl.ac.uk/ear/research/chaitlab/ UCL Ear Institute 332 Gray's Inn Road London WC1X 8EE -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.oostenveld at donders.ru.nl Fri Jan 27 08:45:20 2017 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Fri, 27 Jan 2017 08:45:20 +0100 Subject: [FieldTrip] Week-long summer course on data analysis in MATLAB References: Message-ID: <9640D9F6-AABC-4214-AE79-DC23FA95757A@donders.ru.nl> Dear FieldTrip users My colleague Mike X Cohen will be teaching a week-long course coming summer in Nijmegen, Netherlands, called "Math and Matlab for Neuroscientists." It is designed for PhDs/postdocs. He taught this course last year and it was very successful. See attached for details and feel free to distribute this flyer as you see fit. best regards, Robert PS we will also be organizing the "Advanced MEG/EEG analysis toolkit course” (a.k.a. the FieldTrip course) in spring of this year. Once the date for that has been settled, it will be announced on this email list and details will be posted on http://www.fieldtriptoolbox.org/workshop -------------- next part -------------- A non-text attachment was scrubbed... Name: MathMatlab_Radboud2017.pdf Type: application/pdf Size: 1403012 bytes Desc: not available URL: -------------- next part -------------- From tmadsen at emory.edu Fri Jan 27 17:44:31 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Fri, 27 Jan 2017 11:44:31 -0500 Subject: [FieldTrip] impact of skewed power distributions on data analysis In-Reply-To: References: Message-ID: Yes, thank you! That's exactly what I was thinking - I'll be glad to have your paper to cite in my methods section. ;-) I'm forwarding your email back to the listserv and other interested parties for reference. Thanks, Teresa On Thu, Jan 26, 2017 at 10:07 AM, berry van den berg wrote: > Hi Teresa, > > Maybe the following helps to gain a bit more insight. > > Thanks for the interesting discussion. We recently published an article > using what you describe: the log(power) and subsequently z-scoring across > trials on each time/ freq point. See http://rdcu.be/oOjc > > For the frequency analysis we were mostly interested in prestimulus > activity related to RTs and time-in-session which basically makes the use > of a prestimulus baseline correction invalid. Using the log transformed > power and z-scoring those gave pretty solid model fits. > > The data is not completely normal yet but pretty close (see plot below, > which comes from the prestimulus period [-700 to stim onset] in the alpha > [8 to 14Hz] range). For fitting a linear (or nonlinear) model, log > transforming the data was a necessary step. > > [image: Inline images 1] > > > > > > > > > On 10 January 2017 at 21:01, Teresa Madsen wrote: > >> Thanks for the reference. In return, I also recommend reading Ciuparu >> and Mures an's recent rebuttal: >> >> European Journal of Neuroscience, Vol. 43, pp. 861–869, 2016, >> doi:10.1111/ejn.13179 >> TECHNICAL SPOTLIGHT >> Sources of bias in single-trial normalization procedures >> >> They demonstrate that the positive bias Grandchamp and Delorme warned >> about with single-trial baseline normalization was, in fact, due to the >> correlated numerators and denominators in each of the baseline >> normalization procedures they tested, which was, in turn, caused by the >> skewed distributions of baseline power values. They demonstrate that this >> bias is reduced by using a much longer baseline, ideally incorporated into >> the experimental design, but when that's not possible, stitching together >> the baselines of many trials. >> >> Neither article addresses my specific question of whether it would be >> even better to log-transform the raw power values before averaging, so I >> suppose I'll have to test it myself and write my own methods article! 🤓 >> >> I will go ahead and incorporate some of these alternative baseline >> normalization methods in my git fork of FieldTrip as I go along with my own >> analyses, so let me know if anyone else would find them useful, and I'll >> submit a pull request to contribute them to the master branch. >> >> Thanks for the fruitful discussion, all! >> ~Teresa >> >> >> On Mon, Dec 19, 2016 at 8:01 PM, Alik Widge wrote: >> >>> Indeed, in a separate thread with Michael Cohen several months back he >>> suggested precisely that paper. >>> >>> On Dec 19, 2016 5:07 PM, "Nicholas A. Peatfield" < >>> nick.peatfield at gmail.com> wrote: >>> >>>> I think this paper is relevant to this discussion. >>>> >>>> Grandchamp, R., & Delorme, A. (2011). Single-Trial Normalization for >>>> Event-Related Spectral Decomposition Reduces Sensitivity to Noisy Trials. *Frontiers >>>> in Psychology*, *2*, 236. http://doi.org/10.3389/fpsyg.2011.00236 >>>> >>>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3183439/ >>>> >>>> >>>> >>>> On 19 December 2016 at 13:08, Teresa Madsen wrote: >>>> >>>>> I appreciate everyone's feedback, but I still wonder if something is >>>>> being missed. I understand that the non-normally distributed power values >>>>> may be less of an issue when performing non-parametric stats or even a >>>>> paired-samples t-test that looks at difference values which may be normal >>>>> even when the raw data isn't. However, my concern comes into play even >>>>> before these statistical comparisons are made, whenever any averaging is >>>>> done to freq-type data across times, frequencies, trials, electrodes, >>>>> subjects, etc. That means any time any of these configuration options are >>>>> used for any of these functions, and probably more: >>>>> >>>>> ft_freqanalysis: cfg.keeptrials or cfg.keeptapers = 'no'; >>>>> ft_freqgrandaverage: cfg.keepindividual = 'no'; >>>>> ft_freqstatistics: cfg.avgoverchan, cfg.avgovertime, or >>>>> cfg.avgoverfreq = 'yes'; >>>>> ft_freqbaseline: cfg.baseline = anything but 'no' >>>>> >>>>> In each case, if raw power values are averaged, the result will be >>>>> positively skewed. Maybe it's not a huge problem if all of the data is >>>>> treated identically, but the specific case that triggered my concern was in >>>>> ft_freqbaseline, where the individual time-frequency bins are compared to >>>>> the mean over time for the baseline period. For example, when using >>>>> cfg.baselinetype = 'db', as Giuseppe Pellizzer suggested, the output freq >>>>> data does indeed have a more normal distribution over time, but the mean >>>>> over the baseline time period is performed *before* the log transform, when >>>>> the distribution is still highly skewed: >>>>> >>>>> meanVals = repmat(nanmean(data(:,:,baselineTimes), 3), [1 1 >>>>> size(data, 3)]); >>>>> data = 10*log10(data ./ meanVals); >>>>> >>>>> That's what I had originally done when analyzing data for my SfN >>>>> poster, when I realized the background noise that shouldn't have changed >>>>> much from baseline was mostly showing a decrease from baseline of about >>>>> -3dB. >>>>> >>>>> Now, I've realized I'm seeing this as more of a problem than others >>>>> because of another tweak I made, which was to use a long, separate baseline >>>>> recording to normalize my trial data, rather than a short pre-trial period >>>>> as ft_freqbaseline is designed to do. Averaging a few hundred milliseconds >>>>> for a baseline power estimate might be okay because overlapping time points >>>>> in the original data are used to calculate those power values anyway, >>>>> probably making them less skewed, but also (it seems to me) more arbitrary >>>>> and prone to error. I already offered my custom function BLnorm.m to one >>>>> person who was asking about this issue of normalizing to a separate >>>>> baseline recording, and I would be happy to contribute it to FieldTrip if >>>>> others would appreciate it. >>>>> >>>>> Since a few people suggested using the median, and it is also >>>>> suggested in Cohen's textbook >>>>> as >>>>> an alternative measure of the central tendency for skewed raw power values, >>>>> I wonder if the simplest fix might be to add an option to select mean or >>>>> median in each of the functions listed above. Another possibility would be >>>>> adding an option to transform the power values upon output from >>>>> ft_freqanalysis. >>>>> >>>>> Would anyone else find such changes useful? >>>>> >>>>> Thanks, >>>>> Teresa >>>>> >>>>> >>>>> On Wed, Dec 14, 2016 at 4:22 AM, Herring, J.D. (Jim) < >>>>> J.Herring at donders.ru.nl> wrote: >>>>> >>>>>> In terms of statistics it is the distribution of values that you do >>>>>> the statistics on that matters. In case of a paired-samples t-test when >>>>>> comparing two conditions, it is the distribution of difference values that >>>>>> has to be normally distributed. The distribution of difference values is >>>>>> often normal given two similarly non-normal distributions, offering no >>>>>> complications for a regular parametric test. >>>>>> >>>>>> >>>>>> >>>>>> The non-parametric tests offered in fieldtrip indeed do not assume >>>>>> normality, so you should have no problem there either. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* fieldtrip-bounces at science.ru.nl [mailto: >>>>>> fieldtrip-bounces at science.ru.nl] *On Behalf Of *Alik Widge >>>>>> *Sent:* Tuesday, December 13, 2016 3:10 PM >>>>>> *To:* FieldTrip discussion list >>>>>> *Subject:* Re: [FieldTrip] impact of skewed power distributions on >>>>>> data analysis >>>>>> >>>>>> >>>>>> >>>>>> In this, Teresa is right and we have observed this in our own EEG >>>>>> data -- depending on one's level of noise and number of trials/patients, >>>>>> the mean can be a very poor estimator of central tendency. My students are >>>>>> still arguing about what we really want to do with it, but at least one of >>>>>> them has shifted to using the median as a matter of course for baseline >>>>>> normalization. >>>>>> >>>>>> >>>>>> Alik Widge >>>>>> alik.widge at gmail.com >>>>>> (206) 866-5435 >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 6:45 PM, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> That may very well be true; to be honest, I haven't looked that >>>>>> deeply into the stats offerings yet. However, my plan is to express each >>>>>> electrode's experimental data in terms of change from their respective >>>>>> baseline recordings before attempting any group averaging or statistical >>>>>> testing, and this problem shows up first in the baseline correction step, >>>>>> where FieldTrip averages raw power over time. >>>>>> >>>>>> ~Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 4:56 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com> wrote: >>>>>> >>>>>> Correct me if I'm wrong, but, if you are using the non-parametric >>>>>> statistics implemented by fieldtrip, the data does not need to be normally >>>>>> distributed. >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 13:39, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> No, sorry, that's not what I meant, but thanks for giving me the >>>>>> opportunity to clarify. Of course everyone is familiar with the 1/f pattern >>>>>> across frequencies, but the distribution across time (and according to the >>>>>> poster, also across space), also has an extremely skewed, negative >>>>>> exponential distribution. I probably confused everyone by trying to show >>>>>> too much data in my figure, but each color represents the distribution of >>>>>> power values for a single frequency over time, using a histogram and a line >>>>>> above with circles at the mean +/- one standard deviation. >>>>>> >>>>>> My main point was that the mean is not representative of the central >>>>>> tendency of such an asymmetrical distribution of power values over time. >>>>>> It's even more obvious which is more representative of their actual >>>>>> distributions when I plot e^mean(logpower) on the raw plot and >>>>>> log(mean(rawpower)) on the log plot, but that made the figure even more >>>>>> busy and confusing. >>>>>> >>>>>> I hope that helps, >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 12, 2016 at 3:47 PM Nicholas A. Peatfield < >>>>>> nick.peatfield at gmail.com> wrote: >>>>>> >>>>>> Hi Teresa, >>>>>> >>>>>> >>>>>> >>>>>> I think what you are discussing is the 1/f power scaling of the power >>>>>> spectrum. This is one of the reasons that comparisons are made within >>>>>> a band (i.e. alpha to alpha) and not between bands (i.e. alpha to gamma), >>>>>> as such the assumption is that within bands there should be a relative >>>>>> change against baseline and this is what the statistics are performed on. >>>>>> That is, baseline correction is assumed to be the mean for a specific >>>>>> frequency and not a mean across frequencies. >>>>>> >>>>>> >>>>>> >>>>>> And this leads to another point that when you are selecting a >>>>>> frequency range to do the non-parametric statistics on you should not do >>>>>> 1-64 Hz but break it up based on the bands. >>>>>> >>>>>> >>>>>> >>>>>> Hope my interpretation of your point is correct. I sent in >>>>>> individually, as I wanted to ensure I followed your point. >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 12 December 2016 at 08:23, Teresa Madsen >>>>>> wrote: >>>>>> >>>>>> FieldTrippers, >>>>>> >>>>>> >>>>>> >>>>>> While analyzing my data for the annual Society for Neuroscience >>>>>> meeting, I developed a concern that was quickly validated by another poster >>>>>> (full abstract copied and linked below) focusing on the root of the >>>>>> problem: neural oscillatory power is not normally distributed across time, >>>>>> frequency, or space. The specific problem I had encountered was in >>>>>> baseline-correcting my experimental data, where, regardless of >>>>>> cfg.baselinetype, ft_freqbaseline depends on the mean power over time. >>>>>> However, I found that the distribution of raw power over time is so skewed >>>>>> that the mean was not a reasonable approximation of the central tendency of >>>>>> the baseline power, so it made most of my experimental data look like it >>>>>> had decreased power compared to baseline. The more I think about it, the >>>>>> more I realize that averaging is everywhere in the way we analyze neural >>>>>> oscillations (across time points, frequency bins, electrodes, trials, >>>>>> subjects, etc.), and many of the standard statistics people use also rely >>>>>> on assumptions of normality. >>>>>> >>>>>> >>>>>> >>>>>> The most obvious solution for me was to log transform the data first, >>>>>> as it appears to be fairly log normal, and I always use log-scale >>>>>> visualizations anyway. Erik Peterson, middle author on the poster, agreed >>>>>> that this would at least "restore (some) symmetry to the error >>>>>> distribution." I used a natural log transform, sort of arbitrarily to >>>>>> differentiate from the standard decibel transform included in FieldTrip as >>>>>> cfg.baselinetype = 'db'. The following figures compare the 2 distributions >>>>>> across several frequency bands (using power values from a wavelet >>>>>> spectrogram obtained from a baseline LFP recorded in rat prelimbic >>>>>> cortex). The lines at the top represent the mean +/- one standard >>>>>> deviation for each frequency band, and you can see how those descriptive >>>>>> stats are much more representative of the actual distributions in the log >>>>>> scale. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ​​ >>>>>> >>>>>> For my analysis, I also calculated a z-score on the log transformed >>>>>> power to assess how my experimental data compared to the variability of the >>>>>> noise in a long baseline recording from before conditioning, rather than a >>>>>> short pre-trial baseline period, since I find that more informative than >>>>>> any of FieldTrip's built-in baseline types. I'm happy to share the custom >>>>>> functions I wrote for this if people think it would be a useful addition to >>>>>> FieldTrip. I can also share more about my analysis and/or a copy of the >>>>>> poster, if anyone wants more detail - I just didn't want to make this email >>>>>> too big. >>>>>> >>>>>> >>>>>> >>>>>> Mostly, I'm just hoping to start some discussion here as to how to >>>>>> address this. I searched the wiki >>>>>> , listserv >>>>>> >>>>>> archives >>>>>> , >>>>>> and bugzilla >>>>>> for >>>>>> anything related and came up with a few topics surrounding normalization >>>>>> and baseline correction, but only skirting this issue. It seems important, >>>>>> so I want to find out whether others agree with my approach or already have >>>>>> other ways of avoiding the problem, and whether FieldTrip's code needs to >>>>>> be changed or just documentation added, or what? >>>>>> >>>>>> >>>>>> >>>>>> Thanks for any insights, >>>>>> >>>>>> Teresa >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 271.03 / LLL17 - Neural oscillatory power is not Gaussian distributed >>>>>> across time >>>>>> >>>>>> >>>>>> *Authors* >>>>>> >>>>>> **L. IZHIKEVICH*, E. PETERSON, B. VOYTEK; >>>>>> Cognitive Sci., UCSD, San Diego, CA >>>>>> >>>>>> *Disclosures* >>>>>> >>>>>> *L. Izhikevich:* None. *E. Peterson:* None. *B. Voytek:* None. >>>>>> >>>>>> *Abstract* >>>>>> >>>>>> Neural oscillations are important in organizing activity across the >>>>>> human brain in healthy cognition, while oscillatory disruptions are linked >>>>>> to numerous disease states. Oscillations are known to vary by frequency and >>>>>> amplitude across time and between different brain regions; however, this >>>>>> variability has never been well characterized. We examined human and animal >>>>>> EEG, LFP, MEG, and ECoG data from over 100 subjects to analyze the >>>>>> distribution of power and frequency across time, space and species. We >>>>>> report that between data types, subjects, frequencies, electrodes, and >>>>>> time, an inverse power law, or negative exponential distribution, is >>>>>> present in all recordings. This is contrary to, and not compatible with, >>>>>> the Gaussian noise assumption made in many digital signal processing >>>>>> techniques. The statistical assumptions underlying common algorithms for >>>>>> power spectral estimation, such as Welch's method, are being violated >>>>>> resulting in non-trivial misestimates of oscillatory power. Different >>>>>> statistical approaches are warranted. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Teresa E. Madsen, PhD >>>>>> Research Technical Specialist: *in vivo *electrophysiology & data >>>>>> analysis >>>>>> >>>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>>> Yerkes National Primate Research Center >>>>>> >>>>>> Emory University >>>>>> >>>>>> Rainnie Lab, NSB 5233 >>>>>> 954 Gatewood Rd. NE >>>>>> Atlanta, GA 30329 >>>>>> >>>>>> (770) 296-9119 >>>>>> >>>>>> braingirl at gmail.com >>>>>> >>>>>> https://www.linkedin.com/in/temadsen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nicholas Peatfield, PhD >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Teresa E. Madsen, PhD >>>>> Division of Behavioral Neuroscience and Psychiatric Disorders >>>>> Yerkes National Primate Research Center >>>>> Emory University >>>>> Rainnie Lab, NSB 5233 >>>>> 954 Gatewood Rd. NE >>>>> Atlanta, GA 30329 >>>>> (770) 296-9119 >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> >>>> >>>> -- >>>> Nicholas Peatfield, PhD >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Teresa E. Madsen, PhD >> Division of Behavioral Neuroscience and Psychiatric Disorders >> Yerkes National Primate Research Center >> Emory University >> Rainnie Lab, NSB 5233 >> 954 Gatewood Rd. NE >> Atlanta, GA 30329 >> (770) 296-9119 >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Berry van den Berg > email: berryv.dberg at gmail.com > website: berryvdberg.org > mobile: +31612585275 <+31%206%2012585275> > -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 38279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 30063 bytes Desc: not available URL: From seymourr at aston.ac.uk Sun Jan 29 13:05:23 2017 From: seymourr at aston.ac.uk (Seymour, Robert (Research Student)) Date: Sun, 29 Jan 2017 12:05:23 +0000 Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing Message-ID: Dear FT Users, I am currently writing a function where ft_preprocessing is called iteratively; however computation is being slowed down by the display of text/output in the MATLAB command window (e.g. "the input is raw data with 1 channel and 62 trials"). Apart from hard-coding, I was wondering if there was an option to turn off logging in the FT code? Many thanks, Robert Seymour (PhD Student, Aston Brain Centre) -------------- next part -------------- An HTML attachment was scrubbed... URL: From leventmeister at gmail.com Sun Jan 29 18:25:34 2017 From: leventmeister at gmail.com (Levent Kandemir) Date: Sun, 29 Jan 2017 20:25:34 +0300 Subject: [FieldTrip] Fwd: Partial Source Model In-Reply-To: References: Message-ID: Hello, I calculate coherence from HCP data using http://www. fieldtriptoolbox.org/tutorial/beamformer but I get results as below; [image: Satır içi resim 1] What do you think the problem is? Thanks in advance, Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 133674 bytes Desc: not available URL: From ekenaykut at gmail.com Sun Jan 29 19:10:44 2017 From: ekenaykut at gmail.com (Aykut Eken) Date: Sun, 29 Jan 2017 21:10:44 +0300 Subject: [FieldTrip] Fwd: Partial Source Model In-Reply-To: References: Message-ID: <2AF1E465-2408-41E8-ADAF-05F74D997F1E@gmail.com> You can change the scale of color map or your data may be noisy. > On 29 Jan 2017, at 20:25, Levent Kandemir wrote: > > > Hello, > > I calculate coherence from HCP data using http://www.fieldtriptoolbox.org/tutorial/beamformer but I get results as below; > > > > What do you think the problem is? > > Thanks in advance, > Best regards, > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From anne.urai at gmail.com Mon Jan 30 10:36:09 2017 From: anne.urai at gmail.com (Anne Urai) Date: Mon, 30 Jan 2017 10:36:09 +0100 Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing In-Reply-To: References: Message-ID: Hi Robert, many FieldTrip functions have the (sometimes undocumented) input option cfg.feedback. When set to 'none', output in the command line is suppressed. — Anne E. Urai, MSc PhD student | Institut für Neurophysiologie und Pathophysiologie Universitätsklinikum Hamburg-Eppendorf | Martinistrasse 52, 20246 | Hamburg, Germany www.anneurai.net / @AnneEUrai From: Seymour, Robert (Research Student) Reply: FieldTrip discussion list Date: 29 January 2017 at 13:05:23 To: fieldtrip at science.ru.nl Subject: [FieldTrip] Turn off text display/logging during ft_preprocessing Dear FT Users, I am currently writing a function where ft_preprocessing is called iteratively; however computation is being slowed down by the display of text/output in the MATLAB command window (e.g. "the input is raw data with 1 channel and 62 trials"). Apart from hard-coding, I was wondering if there was an option to turn off logging in the FT code? Many thanks, Robert Seymour (PhD Student, Aston Brain Centre) _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.patai at ucl.ac.uk Mon Jan 30 14:27:22 2017 From: e.patai at ucl.ac.uk (Zita Eva Patai) Date: Mon, 30 Jan 2017 13:27:22 +0000 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data Message-ID: Dear FT-ers, I have an obvious question, but would still appreciate input from those more wise than myself: Can I put any sort of confound in to regress out of my data? For example things relating to -eye-movements (ICA done but I still have obvious condition differences) -experimentally uncontrolled stimulus changes -or any other environmental effects i'd like to control for Thank you zita -- Eva Zita Patai, DPhil Postdoctoral Researcher Institute of Behavioural Neuroscience UCL -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmadsen at emory.edu Mon Jan 30 17:30:30 2017 From: tmadsen at emory.edu (Teresa Madsen) Date: Mon, 30 Jan 2017 11:30:30 -0500 Subject: [FieldTrip] extracting spikes from new Message-ID: Suzanne, I think it may be a simple error in the way you formatted the inputs to that command. According to the help comments at the beginning of the function: % Use as % [spike] = ft_read_spike(filename, ...) % % Additional options should be specified in key-value pairs and can be % 'spikeformat' = string, described the fileformat (default is automatic) I don't see any other input arguments being used, so I'm assuming your 1st argument is the filename and guessing your 3rd argument is its location? If so, the correct format would be: >> [rec1] = ft_read_spike('/Users/username/Documents/export/test.nex'); Including the .nex extension in the filename will allow ft_filetype to automatically detect the format as 'plexon_nex', so you don't need to specify a spikeformat, but if that doesn't work for some reason, I believe the correct formatting (what is meant by key-value pairs) would be: >> [rec1] = ft_read_spike('test', 'spikeformat', 'plexon_nex’); If neither of those work, I'd be happy to help you troubleshoot this further, as I also use Plexon for data acquisition, have been working on improving FieldTrip's NEX handling, and will be moving into spike analysis soon. Let me know if that helps. ~Teresa On Wed, Jan 25, 2017 at 4:55 PM, Suzanne van der Veldt < suzannevdveldt at gmail.com> wrote: > Hello all, > > Sorry to trouble you. I am excited to get starting with using FieldTrip > for my data analysis, using in vivo ephys data recorded with plexon. I have > my sorted spikes in .nex format. Unfortunately, field trip does not seem to > be able to import my data. > > >> [rec1] = ft_read_spike('test', 'plexon_nex', '/Users/username/Documents/ > export’) > Error using ft_read_spike (line 276) > unsupported data format (unknown > > The .nex file is a regular file. I am running Matlab R2015b from Mac OSx > Sierra 10.12.2. > > I hope someone might be able to give me a hint of what might be the > problem. > > Kind regards, > Suzanne van der Veldt > > PhD student McGill & Université de Bordeaux > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Teresa E. Madsen, PhD Division of Behavioral Neuroscience and Psychiatric Disorders Yerkes National Primate Research Center Emory University Rainnie Lab, NSB 5233 954 Gatewood Rd. NE Atlanta, GA 30329 (770) 296-9119 -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.stolk8 at gmail.com Mon Jan 30 19:00:44 2017 From: a.stolk8 at gmail.com (Arjen Stolk) Date: Mon, 30 Jan 2017 10:00:44 -0800 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data In-Reply-To: References: Message-ID: Dear Zita, The short answer is yes, as you guessed already. Ideally, the confound is measured independently from the dependent measure, e.g. eye tracker activity to filter against eye movement related confounds in neural activity. But in the past we've also successfully regressed out eye movement related contributions as captured with EOG from frontal (source-reconstructed) neural activity, despite that both signals may have been partially correlated due to field spread. See 'General assessments of neurophysiologic data' & Fig S3 of this pdf: http://www.pnas.org/content/suppl/2013/08/16/1303170110.DCSupplemental/pnas.201303170SI.pdf The same principle that underlies head movement compensation thus also holds for other potential confounds, including the ones mentioned by you. Best, Arjen 2017-01-30 5:27 GMT-08:00 Zita Eva Patai : > Dear FT-ers, > > I have an obvious question, but would still appreciate input from those > more wise than myself: > > Can I put any sort of confound in to regress out of my data? For example > things relating to > > -eye-movements (ICA done but I still have obvious condition differences) > -experimentally uncontrolled stimulus changes > -or any other environmental effects i'd like to control for > > Thank you > zita > > > -- > Eva Zita Patai, DPhil > Postdoctoral Researcher > Institute of Behavioural Neuroscience > UCL > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.patai at ucl.ac.uk Mon Jan 30 21:50:45 2017 From: e.patai at ucl.ac.uk (Zita Eva Patai) Date: Mon, 30 Jan 2017 20:50:45 +0000 Subject: [FieldTrip] FT_REGRESSCONFOUND: usage on other confounds in data In-Reply-To: References: Message-ID: That's great thank you Arjen! On Mon, Jan 30, 2017 at 6:00 PM, Arjen Stolk wrote: > Dear Zita, > > The short answer is yes, as you guessed already. Ideally, the confound is > measured independently from the dependent measure, e.g. eye tracker > activity to filter against eye movement related confounds in neural > activity. But in the past we've also successfully regressed out eye > movement related contributions as captured with EOG from frontal > (source-reconstructed) neural activity, despite that both signals may have > been partially correlated due to field spread. See 'General assessments of > neurophysiologic data' & Fig S3 of this pdf: > http://www.pnas.org/content/suppl/2013/08/16/1303170110. > DCSupplemental/pnas.201303170SI.pdf > The same principle that underlies head movement compensation thus also > holds for other potential confounds, including the ones mentioned by you. > > Best, > Arjen > > > > 2017-01-30 5:27 GMT-08:00 Zita Eva Patai : > >> Dear FT-ers, >> >> I have an obvious question, but would still appreciate input from those >> more wise than myself: >> >> Can I put any sort of confound in to regress out of my data? For example >> things relating to >> >> -eye-movements (ICA done but I still have obvious condition differences) >> -experimentally uncontrolled stimulus changes >> -or any other environmental effects i'd like to control for >> >> Thank you >> zita >> >> >> -- >> Eva Zita Patai, DPhil >> Postdoctoral Researcher >> Institute of Behavioural Neuroscience >> UCL >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > https://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Eva Zita Patai, DPhil Postdoctoral Researcher Institute of Behavioural Neuroscience UCL -------------- next part -------------- An HTML attachment was scrubbed... URL: From alba.xifraporxas at mail.mcgill.ca Mon Jan 30 22:53:38 2017 From: alba.xifraporxas at mail.mcgill.ca (Alba Xifra Porxas, Ms) Date: Mon, 30 Jan 2017 21:53:38 +0000 Subject: [FieldTrip] Error reading fif file during ft_read_headshape Message-ID: Dear FieldTrippers, My name is Alba Xifra Porxas and I am working in the Biosignals and Systems Analysis Lab at McGill University. Currently I am analyzing MEG data from a motor-task paradigm from young and elderly subjects. I am following the tutorial: Source reconstruction of event-related fields using minimum-norm estimate (http://fieldtrip.fcdonders.nl/tutorial/minimumnormestimate). I am having problems reading the downsampled mesh from MNE suite. When I call FT_READ_HEADSHAPE, I receive the following error message: >> sourcespace = ft_read_headshape('s003-oct-6-src.fif', 'format', 'mne_source'); Error using fiff_read_tag (line 178) Only two and three dimensional matrices are supported at this time Error in mne_read_source_spaces/read_source_space/find_tag (line 288) tag = fiff_read_tag(fid,node.dir(p).pos); Error in mne_read_source_spaces/read_source_space (line 254) tag2 = find_tag(this,FIFF.FIFF_MNE_SOURCE_SPACE_NEAREST_DIST); Error in mne_read_source_spaces (line 111) this = read_source_space(spaces(k)); Error in ft_read_headshape (line 391) src = mne_read_source_spaces(filename, 1); However, I can visualize it correctly in MNE. The command I used to create the source space is: mne_setup_source_space --ico -6. Since I have the meshes from FreeSurfer, I tried a workaround. I call FT_READ_HEADSHAPE using lh.orig and rh.orig, which works. I successfully coregister the source space with the sensor-space and compute source reconstruction using minimum-norm estimation. However, when I try to downsample the output of FT_SOURCEANALYSIS calling FT_VOLUMEDOWNSAMPLE before parcellation, I receive the following error: Reference to non-existent field 'dim'. Error in ft_volumedownsample (line 100) xsel = 1:cfg.downsample:source.dim(1); Even if I manually introduce this missing field 'dim', it seems the number of vertices is too big: >> source.dim(1) = length(source.pos);source.dim(2) = length(source.pos);source.dim(3) = length(source.pos); >> cfg = [];cfg.downsample = 4;source_down = ft_volumedownsample(cfg,source); Error using repmat Maximum variable size allowed by the program is exceeded. Error in ndgrid (line 73) varargout{i} = repmat(x,s); Error in pos2transform (line 25) [X,Y,Z] = ndgrid(x, y, z); Error in ft_checkdata>source2volume (line 1286) data.transform = pos2transform(data.pos, data.dim); Error in ft_checkdata (line 350) data = source2volume(data); Error in ft_volumedownsample (line 69) source = ft_checkdata(source, 'datatype', 'volume', 'feedback', 'no'); The source I use is as follows: >> display(source) source = time: [1x3900 double] inside: [255462x1 logical] pos: [255462x3 double] method: 'average' avg: [1x1 struct] cfg: [1x1 struct] dim: [255462 255462 255462] Therefore, I am back to where I started. I need to read the fif file from MNE suite. I uploaded my fif file in Dropbox. Here is the link: https://www.dropbox.com/sh/uq181l76353hd8q/AACjTu8KI_rGaXlaDMyw-Diba?dl=0 Could someone tell me if there is something wrong with the file or with my workaround? Any help would be really appreciated. I am using Fieldtrip version 20170118. Best, Alba Xifra Porxas PhD student, Biosignals and Systems Analysis Lab McGill University, Montréal, Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: From timeehan at gmail.com Mon Jan 30 23:10:40 2017 From: timeehan at gmail.com (Tim Meehan) Date: Mon, 30 Jan 2017 17:10:40 -0500 Subject: [FieldTrip] preprocessing procedures for ECoG/iEEG data Message-ID: Hello all, I am a new user of fieldtrip and new to analyzing electrophysiological data. I have familiarized myself with some basics of preprocessing of EEG data, but I would like to know if there are special considerations for dealing with ECoG/iEEG data -- our dataset has recordings from both subdural surface electrodes and depth electrodes, sampled at 2kHz. We are initially most interested in extracting the high-gamma band (70-150 Hz) envelope as a measure of local activity. First a general question: is there anyone who could point me to or provide me with a preprocessing procedure in fieldtrip that is tailored for ECoG/iEEG? I've perused the ECoG section in the wiki but there is no information on preprocessing there. If this is too vague, some specific questions I have are: 1) What cutoffs do people tend to use for low and high-pass filters? 2) What is your choice for re-referencing, if any? Our initial reference/ground are the left and right mastoids. I have seen papers that re-reference to the nearest neighbor. I think I need to use ft_apply_montage to do this, but beyond that I could use some guidance. 3) At what point do you epoch into trials? My guess is after high/low-pass filtering and re-referencing but before artifact detection and removal? Any feedback on these would be very much appreciated. If you need more details please let me know. Thanks! Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielle.farrar at gmail.com Tue Jan 31 17:40:14 2017 From: danielle.farrar at gmail.com (Danielle Farrar) Date: Tue, 31 Jan 2017 11:40:14 -0500 Subject: [FieldTrip] Starting at ft_timelockstatistics Message-ID: Hello, My apologies if this has been covered before, I just joined the list and am having trouble searching the archives. I have a set of EEG data that was recorded from a Biosemi apparatus using a 128-channel cap. The dataset is in text files, is post-processed and is the result of filtering, epoching, and averaging, and has been imported into matlab. I created trial structs out of the datasets. It is a dataset of 21 subjects with two conditions. I'm trying to do some non-parametric clustering statistics on the dataset and I don't have access to the original bdf files. I have the electrode names and coordinates saved in matlab matrices. Now, I'd like to do clustering analysis using a monte carlo simulation to determine areas of significant differences between the two conditions, but am having trouble ensuring that my datasets are structured appropriately for input. It seems that the tutorials mostly assume that the data is in a raw output format from one of the systems. I know that for ft_timelockstatistics, the data is supposed to be output from the ft_timelockanalysis. I was trying to use ft_timelockanalysis as an entry point However, I am having trouble constructing the data struct appropriate for the timelock function. Can this be done? Should I be starting further upstream? I'm attaching some of the code. I'm know the data struct needs additional information but am not sure how to go about using it. The error I get when I run the following code is "Error using ft_checkdata (line 480). This function requires raw+comp or raw data as input." Thanks! Danielle ******************************** for i=size(CD_condition.data,3), CD_trial{i} = CD_condition.data(:,:,i); end CD.trial = CD_trial; cfg.channel = 'all'; cfg.trials = 'all'; cfg.covariance = 'yes'; cfg.covariancewindow = 'prestim'; cfg.removemean = 'yes'; cfg.vartrllength = 0; CD.type = 'raw+comp'; ft_timelockanalysis(cfg,CD); -------------- next part -------------- An HTML attachment was scrubbed... URL: