From u.pomper at ucl.ac.uk  Mon Nov  2 10:58:15 2020
From: u.pomper at ucl.ac.uk (Pomper, Ulrich)
Date: Mon, 2 Nov 2020 09:58:15 +0000
Subject: [FieldTrip] Ph.D. Position in Cognitive Neuroscience (EEG)
In-Reply-To: <VI1PR01MB2959FA107E70A979482B908AD2100@VI1PR01MB2959.eurprd01.prod.exchangelabs.com>
References: <VI1PR01MB29590851FF45275AABC26A47D2100@VI1PR01MB2959.eurprd01.prod.exchangelabs.com>,
 <VI1PR01MB295988E8C18D8F2CBFC2C5A7D2100@VI1PR01MB2959.eurprd01.prod.exchangelabs.com>,
 <VI1PR01MB2959FA107E70A979482B908AD2100@VI1PR01MB2959.eurprd01.prod.exchangelabs.com>
Message-ID: <VI1PR01MB29598D276A91FA657A33A544D2100@VI1PR01MB2959.eurprd01.prod.exchangelabs.com>


The University of Vienna, Austria, is offering a

Ph.D. Position in Cognitive Neuroscience (EEG)



Job Description:

Applications are invited for a Ph.D. student (F/M/D) position at the Faculty of Psychology, University of Vienna, Austria. The successful candidate will use human EEG and behavioural measures to investigate neural mechanisms underlying auditory predictive processes.
The position is part of the Young Independent Researcher Group “Dynamates”, working on dynamic auditory predictions in humans and marmoset monkeys. This interdisciplinary project combines computational modelling, cognitive neuroscience and cognitive biology to study how humans and monkeys use auditory information when making predictions about the future. For more details, please visit the Dynamates website<https://www.kfs.oeaw.ac.at/index.php?option=com_content&view=article&id=1181:lang-en-yirg-dynamates-dynamic-auditory-predictions-in-human-an-non-human-primates-lang-lang-de-zk-dynamates-dynamiken-der-auditiven-praediktion-in-menschlichen-und-anderen-primaten-lang&catid=103&Itemid=768&lang=en>. The Ph.D. student will also be part of the Vienna Doctoral School network CoBeNe<https://vds-cobene.univie.ac.at/>.




Responsibilities:

  *   Independently conduct human EEG and behavioural experiments (including designing and programming experiments, collecting and analysing the data)
  *   Communication of results in scientific publications and at scientific meetings
  *   Close collaboration with the other members of the project
  *   Co-supervision of MSc and BSc students



Profile:

  *   Master’s degree or diploma in Psychology, Cognitive Science, Neuroscience or a related field
  *   Strong interest in EEG methodology, auditory perception and predictive processing
  *   Very good command of written and spoken English
  *   Experience with EEG or MEG signal processing and analysis is highly advantageous
  *   Strong statistical skills and experience with coding (e.g. Matlab, R, SPSS) are advantageous
  *   Flexibility, ability to work independently as well as in a scientific team are important

Application documents:

  *   Letter describing motivations, personal qualifications and research interest
  *   Academic CV including a list of publications and presentations
  *   Contact details of two referees



Extent of Employment:

We offer a part-time position (30h/week), initially limited to 3 years. The contract will be renewable for a fourth year if the candidate performs well. The position is available immediately. The annual gross salary is EUR 30,754.50 (before taxes, 14 payments a year) according to the collective agreement of the University of Vienna.



Applications, as well as informal inquiries and questions should be submitted to Dr. Ulrich Pomper (ulrich.pomper at univie.ac.at). Applications will be accepted until an adequate candidate has been found. The first round of evaluation will start on the 23.11.2020.

The University of Vienna pursues a non-discriminatory employment policy and values equal opportunities, as well as diversity (http://diversity.univie.ac.at/). The University lays special emphasis on increasing the number of women in academic positions. Given equal qualifications, preference will be given to female applicants.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201102/1651f14d/attachment.htm>

From amie.FAIRS at univ-amu.fr  Mon Nov  2 15:32:04 2020
From: amie.FAIRS at univ-amu.fr (FAIRS Amie)
Date: Mon, 2 Nov 2020 14:32:04 +0000
Subject: [FieldTrip] ft_singleplotER plotting help
Message-ID: <6042e45e145143319729d2837b2dd8e5@univ-amu.fr>

Hi everyone,

This is a very basic question but I'm at a loss as to how to solve it. I hope the explanation below is clear enough.

I want to plot ERPs from some different conditions using ft_singleplotER, with the different conditions overlaid. The different conditions are all subsets of one big dataset, where (simplified) I have a condition of word frequency of the stims presented in the experiment (high vs low). I created subsets of data by high vs low, using ft_timelockgrandaverage over all participants. From these big grand averages, I have then pulled out smaller subsets relating to channel groups (frontal, central, posterior).
For plotting, I want to plot something like:
Ft_singleplotER(cfg, highFreqFrontal, lowFreqFrontal, highFreqCentral, lowFreqCentral, highFreqPosterior, lowFreqPosterior)

However, with this I am getting an error about ylim:
Error using ylim (line 31)
Limits must be a 2-element vector of increasing numeric values.

Error in ft_singleplotER (line 460)
  ylim([ymin ymax]);

When I then manually specify y limits (as anything reasonable considering the data), with all 6 sets being plotted, I get a blank plot.
I don't think it is something in the datasets, because I can do individual plots of pairs. These all work:
Ft_singleplotER(cfg, highFreqFrontal, lowFreqFrontal)
Ft_singleplotER(cfg, highFreqCentral, lowFreqCentral)
Ft_singleplotER(cfg, highFreqPosterior, lowFreqPosterior)

But the minute I try to plot 3 of the sets, the plot becomes blank (if ylim is set), or crashes (if I don't specify).

Can anyone see what I am doing wrong? Or have I gone wrong earlier in the pipeline?

Best,

Amie

------------------
Dr. Amie Fairs
Post-doctorant
Aix-Marseille Université
Laboratoire Parole et Langage (LPL) | CNRS UMR 7309 | 5 Avenue Pasteur | 13100 Aix-en-Provence
Email : amie.fairs at univ-amu.fr<mailto:amie.fairs at univ-amu.fr>

While I may send this email outside of typical working hours, I have no expectation to receive an email outside of your typical hours.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201102/8bf0d9b4/attachment.htm>

From RICHARDS at mailbox.sc.edu  Tue Nov  3 23:23:41 2020
From: RICHARDS at mailbox.sc.edu (RICHARDS, JOHN)
Date: Tue, 3 Nov 2020 22:23:41 +0000
Subject: [FieldTrip] tetra for source model and head model
Message-ID: <MN2PR19MB294497A9FB13B172AE8EFDB6F6110@MN2PR19MB2944.namprd19.prod.outlook.com>

Hi all.

I have been working on a tetrahedral source model, and head model.  The reason for the source model is that we have infant participants and use the gm segment as the brain part for the source model.  Our GM has "limbs" that are fairly narrow, like 1 to 3 mm.    We use a 2mm grid which results in nearly 50K source locations and even then the limbs are poorly covered.  Typical source models are 10mm or greater, and this misses large areas of GM.  So, I used the iso2mesh with cgalsurf (or cgalmesh) to create [node face elem}, and create .pos based on the node(s).  I also either create the other parts of the grid by scratch (dim, xvalues yvalues zvaluse inside), or use a grid based on a head mask to get the pos and other, and then change the inside to match the locations of the node(s).  This works and gives better coverage.  I can tune the iso2mesh to have 20k to 60k source dipoles.  These are "sort of large" quantities of source models, but we have a linux cluster with very large mem nodes.  I would be glad to share the code.

I also have worked on the tetrahedral mesh for the head model.  We use FEM models with the simbio external module.  The ft_prepare_headmodel will do "hex" or "tetra" head models for simbio.  The ft_prepare_mesh will use "tetrahedral" as the mesh, but "prepare_mesh_tetrahedral" does not add the tissue and tissuelabel members, so the ft_prepare_headmodel crashes.  The "prepare_mesh_hexahedral" includes the following code for these:

labels = mesh.labels;
mesh = rmfield(mesh, 'labels');

mesh.tissue = zeros(size(labels));
numlabels = size(unique(labels), 1);
mesh.tissuelabel = {};
ulabel = sort(unique(labels));
for i = 1:numlabels
  mesh.tissue(labels == ulabel(i)) = i;
  mesh.tissuelabel{i} = tissue{i};
end

I think these could be added to the prepare_mesh_tetrahedral.  I added the following code to it.  The prepare_mesh_tet..  uses the iso2mesh and node, elem, and face are returned.  The "reorient" is due to simbio complaining to reorient the tetra columns.  I might compare this to the code above to see if it works.
%JER add this for tissue and tissuelabel
[newelem evol]=meshreorient(node(:,1:3),elem(:,1:4));
elem(:,1:4)=newelem;
mesh.tet = elem(:,1:4);
mesh.tissue=elem(:,5);
mesh.tissuelabel=cfg.tissue;


All of these "work", e.g., they create reasonable files and the ft_prepare_headmodel gives a reasonable struct and files.   We will try these with some empirical data to compare
Hex source model and hex head model
Hex source model and tet head model
Tet source model and hex head model
Tet source model and tet head model

The motivation for doing the tet head model over the hex model is that the tet is known to work better with small areas nested in other areas, better than the hex.  We use full FEM segmented head models with 10 elements and have a lot of twists and turns, small areas with limbs or small encapsulated media areas, etc.  I am pretty sure with our segmented heads that  it could easily be shown the tetra model does better than the hex model.  I suspect this will not have extensive effects on the source reconstruction results but use the best method possible.

John

***********************************************
John E. Richards
Carolina Distinguished Professor
Department of Psychology
University of South Carolina
Columbia, SC  29208
Dept Phone: 803 777 2079
Fax: 803 777 9558
Email: richards-john at sc.edu<mailto:richards-john at sc.edu>
https://jerlab.sc.edu
*************************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201103/2bd9bd33/attachment.htm>

From jan.schoffelen at donders.ru.nl  Wed Nov  4 08:48:30 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Wed, 4 Nov 2020 07:48:30 +0000
Subject: [FieldTrip] tetra for source model and head model
In-Reply-To: <MN2PR19MB294497A9FB13B172AE8EFDB6F6110@MN2PR19MB2944.namprd19.prod.outlook.com>
References: <MN2PR19MB294497A9FB13B172AE8EFDB6F6110@MN2PR19MB2944.namprd19.prod.outlook.com>
Message-ID: <2101F7C2-4191-4850-B46F-04F438E4D0FE@donders.ru.nl>

Dear John,

This all looks like a good change. Normally I’d have asked to send us this code change as a PR to github.

But, as a matter of fact, the current version in the code already seems to have this in place (https://github.com/fieldtrip/fieldtrip/blob/master/private/prepare_mesh_tetrahedral.m). I’d recommend to upgrade to a more recent version of FieldTrip, and verify whether it works for you.

Best wishes,
Jan-Mathijs




On 3 Nov 2020, at 23:23, RICHARDS, JOHN <RICHARDS at mailbox.sc.edu<mailto:RICHARDS at mailbox.sc.edu>> wrote:

Hi all.

I have been working on a tetrahedral source model, and head model.  The reason for the source model is that we have infant participants and use the gm segment as the brain part for the source model.  Our GM has “limbs” that are fairly narrow, like 1 to 3 mm.    We use a 2mm grid which results in nearly 50K source locations and even then the limbs are poorly covered.  Typical source models are 10mm or greater, and this misses large areas of GM.  So, I used the iso2mesh with cgalsurf (or cgalmesh) to create [node face elem}, and create .pos based on the node(s).  I also either create the other parts of the grid by scratch (dim, xvalues yvalues zvaluse inside), or use a grid based on a head mask to get the pos and other, and then change the inside to match the locations of the node(s).  This works and gives better coverage.  I can tune the iso2mesh to have 20k to 60k source dipoles.  These are “sort of large” quantities of source models, but we have a linux cluster with very large mem nodes.  I would be glad to share the code.

I also have worked on the tetrahedral mesh for the head model.  We use FEM models with the simbio external module.  The ft_prepare_headmodel will do “hex” or “tetra” head models for simbio.  The ft_prepare_mesh will use “tetrahedral” as the mesh, but “prepare_mesh_tetrahedral” does not add the tissue and tissuelabel members, so the ft_prepare_headmodel crashes.  The “prepare_mesh_hexahedral” includes the following code for these:

labels = mesh.labels;
mesh = rmfield(mesh, 'labels');

mesh.tissue = zeros(size(labels));
numlabels = size(unique(labels), 1);
mesh.tissuelabel = {};
ulabel = sort(unique(labels));
for i = 1:numlabels
  mesh.tissue(labels == ulabel(i)) = i;
  mesh.tissuelabel{i} = tissue{i};
end

I think these could be added to the prepare_mesh_tetrahedral.  I added the following code to it.  The prepare_mesh_tet..  uses the iso2mesh and node, elem, and face are returned.  The “reorient” is due to simbio complaining to reorient the tetra columns.  I might compare this to the code above to see if it works.
%JER add this for tissue and tissuelabel
[newelem evol]=meshreorient(node(:,1:3),elem(:,1:4));
elem(:,1:4)=newelem;
mesh.tet = elem(:,1:4);
mesh.tissue=elem(:,5);
mesh.tissuelabel=cfg.tissue;


All of these “work”, e.g., they create reasonable files and the ft_prepare_headmodel gives a reasonable struct and files.   We will try these with some empirical data to compare
Hex source model and hex head model
Hex source model and tet head model
Tet source model and hex head model
Tet source model and tet head model

The motivation for doing the tet head model over the hex model is that the tet is known to work better with small areas nested in other areas, better than the hex.  We use full FEM segmented head models with 10 elements and have a lot of twists and turns, small areas with limbs or small encapsulated media areas, etc.  I am pretty sure with our segmented heads that  it could easily be shown the tetra model does better than the hex model.  I suspect this will not have extensive effects on the source reconstruction results but use the best method possible.

John

***********************************************
John E. Richards
Carolina Distinguished Professor
Department of Psychology
University of South Carolina
Columbia, SC  29208
Dept Phone: 803 777 2079
Fax: 803 777 9558
Email: richards-john at sc.edu<mailto:richards-john at sc.edu>
https://jerlab.sc.edu<https://jerlab.sc.edu/>
*************************************************


_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/4a25189a/attachment.htm>

From Alexandra.Steina at uni-duesseldorf.de  Wed Nov  4 13:38:19 2020
From: Alexandra.Steina at uni-duesseldorf.de (Alexandra Steina)
Date: Wed, 04 Nov 2020 13:38:19 +0100
Subject: [FieldTrip] Results from source analysis with different fieldtrip
 versions differ!?
In-Reply-To: <422deac53087aed1f4867a374b20f854@uni-duesseldorf.de>
References: <422deac53087aed1f4867a374b20f854@uni-duesseldorf.de>
Message-ID: <c3ac3540a0b7b28b2666541bca5908bc@uni-duesseldorf.de>

Hello everyone,

I used the following pipeline to perform a source analysis on MEG-LFP 
data. I noticed different results when using different Fieldtrip 
Versions for the exact same data and analysis pipeline.
I read that there was a bug in the 'ft_prepare_leadfield' function in 
the release of June and it says that the bug was fixed, but I got some 
weird results when doing dics source reconstruction on the MEG data with 
the Fieldtrip releases from August on (I also just tried the release 
from yesterday). I attached some sourceplots (all from the exact same 
data) that are all done with a different Fieldtrip Version.
Does anyone know if there is still a bug in the newest fieldtrip 
releases or why these differences occur?

     mri  = ft_read_mri(mri_path);
     mri.anatomy=double(mri.anatomy);
     fidu = importdata([fidu_path,'fiducial.txt']);
     cfg=[];
     cfg.coordsys='neuromag';
     cfg.method = 'fiducial';
     cfg.fiducial.nas    = fidu.data(2,:);
     cfg.fiducial.lpa    = fidu.data(3,:);
     cfg.fiducial.rpa    = fidu.data(1,:);
     real_mri=ft_volumerealign(cfg,mri);

     cfg                = [];
     cfg.keepintermediate = 'no';
     cfg.write          = 'no';
     cfg.name          = [folder_intermediate,'spmtmp'];
     segmentedmri   = ft_volumesegment(cfg, real_mri);

     cfg                = [];
     cfg.method = 'singleshell';
     hdm                = ft_prepare_headmodel(cfg,segmentedmri);
     hdm = ft_convert_units(hdm,'cm');

     template = 
load(fullfile('fieldtrip/template/sourcemodel/standard_sourcemodel3d10mm'));

     cfg                = [];
     cfg.grid.warpmni   = 'yes';
     cfg.grid.template  = template.sourcemodel;  % template_grid
     cfg.grid.nonlinear = 'yes';
     cfg.mri            = real_mri;
     cfg.grid.unit      ='cm';
     grid               = ft_prepare_sourcemodel(cfg);

     cfg = [];
     cfg.dataset = dataset;
     cfg.dftfilter = 'yes';
     cfg.trl = trl;
     cfg.channel = 
['MEG***2','MEG***3',Info_et.(subj).(cond).(file).bad_meg];
     meg = ft_preprocessing(cfg);


     cfg = [];
     cfg.dataset = dataset;
     cfg.dftfilter = 'yes';
     cfg.trl = trl;
     cfg.channel = Info_et.(subj).(cond).(file).old_lfp_labels;
     cfg.montage = Info_et.(subj).(cond).(file).montage;
     lfp = ft_preprocessing(cfg);

    data = ft_appenddata([],meg,lfp);

     cfg = [];
     cfg.length = 1;
     cfg.overlap = 0.5;
     data_seg = ft_redefinetrial(cfg,data);


     centerfreq = 12;
     chan = ‘LFP-right-1-2A’;
     bandwidth = 2;

     cfg = [];
     cfg.method = 'mtmfft';
     cfg.output = 'powandcsd';
     cfg.foi = centerfreq;
     cfg.tapsmofrq = bandwidth;
     cfg.keeptrials = 'yes';
     freq = ft_freqanalysis(cfg,data_seg);

     cfg=[];
     cfg.method='dics';
     cfg.dics.lambda='5%';
     cfg.headmodel=hdm;
     cfg.sourcemodel=grid;
     cfg.frequency = centerfreq;
     cfg.reducerank=2;
     cfg.refchan = chan;
     source=ft_sourceanalysis(cfg,freq);
     source.pos = template.sourcemodel.pos;
     source.dim = template.sourcemodel.dim;

     [maxval, maxcohindx] = max(source.avg.coh);
     max_pos = source.pos(maxcohindx, :);

      cfg = [];
      cfg.parameter = 'coh';
      cfg.interpmethod        = 'nearest';
      it = ft_sourceinterpolate(cfg,source,p); % p

      cfg =  [];
      cfg.method = ‘ortho’;
      cfg.funparameter = 'coh';
      cfg.maskparameter = 'coh';
      ft_sourceplot(cfg,it);

Thanks and greetings,
Alexandra Steina
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ft_2019.png
Type: image/png
Size: 85514 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/89e1233c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ft_april2020.png
Type: image/png
Size: 85514 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/89e1233c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ft_june2020.png
Type: image/png
Size: 85178 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/89e1233c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ft_november2020.png
Type: image/png
Size: 83671 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/89e1233c/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ft_october2020.png
Type: image/png
Size: 83503 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/89e1233c/attachment-0004.png>

From RICHARDS at mailbox.sc.edu  Wed Nov  4 13:43:08 2020
From: RICHARDS at mailbox.sc.edu (RICHARDS, JOHN)
Date: Wed, 4 Nov 2020 12:43:08 +0000
Subject: [FieldTrip] fieldtrip Digest, Vol 120, Issue 3
In-Reply-To: <mailman.15.1604487603.15063.fieldtrip@science.ru.nl>
References: <mailman.15.1604487603.15063.fieldtrip@science.ru.nl>
Message-ID: <MN2PR19MB2944E86B22E0F2081BF866C8F6EF0@MN2PR19MB2944.namprd19.prod.outlook.com>

Jan-Mathijs

Thanks for the update.  I have the May 2020 version, this looks like it was updated in July 2020.  I'll upload the latest version and check.

John'

***********************************************
John E. Richards
Carolina Distinguished Professor
Department of Psychology
University of South Carolina
Columbia, SC  29208
Dept Phone: 803 777 2079
Fax: 803 777 9558
Email: richards-john at sc.edu
https://jerlab.sc.edu
*************************************************


-----Original Message-----
From: fieldtrip <fieldtrip-bounces at science.ru.nl> On Behalf Of fieldtrip-request at science.ru.nl
Sent: Wednesday, November 4, 2020 6:00 AM
To: fieldtrip at science.ru.nl
Subject: fieldtrip Digest, Vol 120, Issue 3

Send fieldtrip mailing list submissions to
	fieldtrip at science.ru.nl

To subscribe or unsubscribe via the World Wide Web, visit
	https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
or, via email, send a message with subject or body 'help' to
	fieldtrip-request at science.ru.nl

You can reach the person managing the list at
	fieldtrip-owner at science.ru.nl

When replying, please edit your Subject line so it is more specific than "Re: Contents of fieldtrip digest..."


Today's Topics:

   1. tetra for source model and head model (RICHARDS, JOHN)
   2. Re: tetra for source model and head model
      (Schoffelen, J.M. (Jan Mathijs))


----------------------------------------------------------------------

Message: 1
Date: Tue, 3 Nov 2020 22:23:41 +0000
From: "RICHARDS, JOHN" <RICHARDS at mailbox.sc.edu>
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: [FieldTrip] tetra for source model and head model
Message-ID:
	<MN2PR19MB294497A9FB13B172AE8EFDB6F6110 at MN2PR19MB2944.namprd19.prod.outlook.com>
	
Content-Type: text/plain; charset="utf-8"

Hi all.

I have been working on a tetrahedral source model, and head model.  The reason for the source model is that we have infant participants and use the gm segment as the brain part for the source model.  Our GM has "limbs" that are fairly narrow, like 1 to 3 mm.    We use a 2mm grid which results in nearly 50K source locations and even then the limbs are poorly covered.  Typical source models are 10mm or greater, and this misses large areas of GM.  So, I used the iso2mesh with cgalsurf (or cgalmesh) to create [node face elem}, and create .pos based on the node(s).  I also either create the other parts of the grid by scratch (dim, xvalues yvalues zvaluse inside), or use a grid based on a head mask to get the pos and other, and then change the inside to match the locations of the node(s).  This works and gives better coverage.  I can tune the iso2mesh to have 20k to 60k source dipoles.  These are "sort of large" quantities of source models, but we have a linux cluster with very large mem nodes.  I would be glad to share the code.

I also have worked on the tetrahedral mesh for the head model.  We use FEM models with the simbio external module.  The ft_prepare_headmodel will do "hex" or "tetra" head models for simbio.  The ft_prepare_mesh will use "tetrahedral" as the mesh, but "prepare_mesh_tetrahedral" does not add the tissue and tissuelabel members, so the ft_prepare_headmodel crashes.  The "prepare_mesh_hexahedral" includes the following code for these:

labels = mesh.labels;
mesh = rmfield(mesh, 'labels');

mesh.tissue = zeros(size(labels));
numlabels = size(unique(labels), 1);
mesh.tissuelabel = {};
ulabel = sort(unique(labels));
for i = 1:numlabels
  mesh.tissue(labels == ulabel(i)) = i;
  mesh.tissuelabel{i} = tissue{i};
end

I think these could be added to the prepare_mesh_tetrahedral.  I added the following code to it.  The prepare_mesh_tet..  uses the iso2mesh and node, elem, and face are returned.  The "reorient" is due to simbio complaining to reorient the tetra columns.  I might compare this to the code above to see if it works.
%JER add this for tissue and tissuelabel [newelem evol]=meshreorient(node(:,1:3),elem(:,1:4));
elem(:,1:4)=newelem;
mesh.tet = elem(:,1:4);
mesh.tissue=elem(:,5);
mesh.tissuelabel=cfg.tissue;


All of these "work", e.g., they create reasonable files and the ft_prepare_headmodel gives a reasonable struct and files.   We will try these with some empirical data to compare
Hex source model and hex head model
Hex source model and tet head model
Tet source model and hex head model
Tet source model and tet head model

The motivation for doing the tet head model over the hex model is that the tet is known to work better with small areas nested in other areas, better than the hex.  We use full FEM segmented head models with 10 elements and have a lot of twists and turns, small areas with limbs or small encapsulated media areas, etc.  I am pretty sure with our segmented heads that  it could easily be shown the tetra model does better than the hex model.  I suspect this will not have extensive effects on the source reconstruction results but use the best method possible.

John

***********************************************
John E. Richards
Carolina Distinguished Professor
Department of Psychology
University of South Carolina
Columbia, SC  29208
Dept Phone: 803 777 2079
Fax: 803 777 9558
Email: richards-john at sc.edu<mailto:richards-john at sc.edu>
https://jerlab.sc.edu
*************************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201103/2bd9bd33/attachment-0001.htm>

------------------------------

Message: 2
Date: Wed, 4 Nov 2020 07:48:30 +0000
From: "Schoffelen, J.M. (Jan Mathijs)" <jan.schoffelen at donders.ru.nl>
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] tetra for source model and head model
Message-ID: <2101F7C2-4191-4850-B46F-04F438E4D0FE at donders.ru.nl>
Content-Type: text/plain; charset="utf-8"

Dear John,

This all looks like a good change. Normally I’d have asked to send us this code change as a PR to github.

But, as a matter of fact, the current version in the code already seems to have this in place (https://protect2.fireeye.com/v1/url?k=6cc55fff-335e672c-6cc5113e-86d3f8f67bce-d5f21a2832ac511e&q=1&e=c2d660d7-d8da-42b9-a1a6-e6113c1478ec&u=https%3A%2F%2Fgithub.com%2Ffieldtrip%2Ffieldtrip%2Fblob%2Fmaster%2Fprivate%2Fprepare_mesh_tetrahedral.m). I’d recommend to upgrade to a more recent version of FieldTrip, and verify whether it works for you.

Best wishes,
Jan-Mathijs




On 3 Nov 2020, at 23:23, RICHARDS, JOHN <RICHARDS at mailbox.sc.edu<mailto:RICHARDS at mailbox.sc.edu>> wrote:

Hi all.

I have been working on a tetrahedral source model, and head model.  The reason for the source model is that we have infant participants and use the gm segment as the brain part for the source model.  Our GM has “limbs” that are fairly narrow, like 1 to 3 mm.    We use a 2mm grid which results in nearly 50K source locations and even then the limbs are poorly covered.  Typical source models are 10mm or greater, and this misses large areas of GM.  So, I used the iso2mesh with cgalsurf (or cgalmesh) to create [node face elem}, and create .pos based on the node(s).  I also either create the other parts of the grid by scratch (dim, xvalues yvalues zvaluse inside), or use a grid based on a head mask to get the pos and other, and then change the inside to match the locations of the node(s).  This works and gives better coverage.  I can tune the iso2mesh to have 20k to 60k source dipoles.  These are “sort of large” quantities of source models, but we have a linux cluster with very large mem nodes.  I would be glad to share the code.

I also have worked on the tetrahedral mesh for the head model.  We use FEM models with the simbio external module.  The ft_prepare_headmodel will do “hex” or “tetra” head models for simbio.  The ft_prepare_mesh will use “tetrahedral” as the mesh, but “prepare_mesh_tetrahedral” does not add the tissue and tissuelabel members, so the ft_prepare_headmodel crashes.  The “prepare_mesh_hexahedral” includes the following code for these:

labels = mesh.labels;
mesh = rmfield(mesh, 'labels');

mesh.tissue = zeros(size(labels));
numlabels = size(unique(labels), 1);
mesh.tissuelabel = {};
ulabel = sort(unique(labels));
for i = 1:numlabels
  mesh.tissue(labels == ulabel(i)) = i;
  mesh.tissuelabel{i} = tissue{i};
end

I think these could be added to the prepare_mesh_tetrahedral.  I added the following code to it.  The prepare_mesh_tet..  uses the iso2mesh and node, elem, and face are returned.  The “reorient” is due to simbio complaining to reorient the tetra columns.  I might compare this to the code above to see if it works.
%JER add this for tissue and tissuelabel [newelem evol]=meshreorient(node(:,1:3),elem(:,1:4));
elem(:,1:4)=newelem;
mesh.tet = elem(:,1:4);
mesh.tissue=elem(:,5);
mesh.tissuelabel=cfg.tissue;


All of these “work”, e.g., they create reasonable files and the ft_prepare_headmodel gives a reasonable struct and files.   We will try these with some empirical data to compare
Hex source model and hex head model
Hex source model and tet head model
Tet source model and hex head model
Tet source model and tet head model

The motivation for doing the tet head model over the hex model is that the tet is known to work better with small areas nested in other areas, better than the hex.  We use full FEM segmented head models with 10 elements and have a lot of twists and turns, small areas with limbs or small encapsulated media areas, etc.  I am pretty sure with our segmented heads that  it could easily be shown the tetra model does better than the hex model.  I suspect this will not have extensive effects on the source reconstruction results but use the best method possible.

John

***********************************************
John E. Richards
Carolina Distinguished Professor
Department of Psychology
University of South Carolina
Columbia, SC  29208
Dept Phone: 803 777 2079
Fax: 803 777 9558
Email: richards-john at sc.edu<mailto:richards-john at sc.edu>
https://jerlab.sc.edu<https://jerlab.sc.edu/>
*************************************************


_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/4a25189a/attachment-0001.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202


------------------------------

End of fieldtrip Digest, Vol 120, Issue 3
*****************************************



From jan.schoffelen at donders.ru.nl  Wed Nov  4 14:09:58 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Wed, 4 Nov 2020 13:09:58 +0000
Subject: [FieldTrip] Results from source analysis with different
 fieldtrip versions differ!?
In-Reply-To: <c3ac3540a0b7b28b2666541bca5908bc@uni-duesseldorf.de>
References: <422deac53087aed1f4867a374b20f854@uni-duesseldorf.de>
 <c3ac3540a0b7b28b2666541bca5908bc@uni-duesseldorf.de>
Message-ID: <00A2B5A4-3C23-419E-BB94-342C1CE722DB@donders.ru.nl>

Hi Alexandra,

Hmmm, that’s not good. We have recently tried to clean up the codebase that is doing various inverse calculations, which was indeed around the time at which you identified a change in figure quality. I don’t think this has to do with the leadfield computation.

Just as a first step, could you check whether the ‘freq’ structures are the same in the different FieldTrip versions? Just to be sure that indeed the cause of this lies in ft_sourceanalysis or ft_inverse_dics.

Best wishes,
Jan-Mathijs



> On 4 Nov 2020, at 13:38, Alexandra Steina <Alexandra.Steina at uni-duesseldorf.de> wrote:
> 
> Hello everyone,
> 
> I used the following pipeline to perform a source analysis on MEG-LFP data. I noticed different results when using different Fieldtrip Versions for the exact same data and analysis pipeline.
> I read that there was a bug in the 'ft_prepare_leadfield' function in the release of June and it says that the bug was fixed, but I got some weird results when doing dics source reconstruction on the MEG data with the Fieldtrip releases from August on (I also just tried the release from yesterday). I attached some sourceplots (all from the exact same data) that are all done with a different Fieldtrip Version.
> Does anyone know if there is still a bug in the newest fieldtrip releases or why these differences occur?
> 
>    mri  = ft_read_mri(mri_path);
>    mri.anatomy=double(mri.anatomy);
>    fidu = importdata([fidu_path,'fiducial.txt']);
>    cfg=[];
>    cfg.coordsys='neuromag';
>    cfg.method = 'fiducial';
>    cfg.fiducial.nas    = fidu.data(2,:);
>    cfg.fiducial.lpa    = fidu.data(3,:);
>    cfg.fiducial.rpa    = fidu.data(1,:);
>    real_mri=ft_volumerealign(cfg,mri);
> 
>    cfg                = [];
>    cfg.keepintermediate = 'no';
>    cfg.write          = 'no';
>    cfg.name          = [folder_intermediate,'spmtmp'];
>    segmentedmri   = ft_volumesegment(cfg, real_mri);
> 
>    cfg                = [];
>    cfg.method = 'singleshell';
>    hdm                = ft_prepare_headmodel(cfg,segmentedmri);
>    hdm = ft_convert_units(hdm,'cm');
> 
>    template = load(fullfile('fieldtrip/template/sourcemodel/standard_sourcemodel3d10mm'));
> 
>    cfg                = [];
>    cfg.grid.warpmni   = 'yes';
>    cfg.grid.template  = template.sourcemodel;  % template_grid
>    cfg.grid.nonlinear = 'yes';
>    cfg.mri            = real_mri;
>    cfg.grid.unit      ='cm';
>    grid               = ft_prepare_sourcemodel(cfg);
> 
>    cfg = [];
>    cfg.dataset = dataset;
>    cfg.dftfilter = 'yes';
>    cfg.trl = trl;
>    cfg.channel = ['MEG***2','MEG***3',Info_et.(subj).(cond).(file).bad_meg];
>    meg = ft_preprocessing(cfg);
> 
> 
>    cfg = [];
>    cfg.dataset = dataset;
>    cfg.dftfilter = 'yes';
>    cfg.trl = trl;
>    cfg.channel = Info_et.(subj).(cond).(file).old_lfp_labels;
>    cfg.montage = Info_et.(subj).(cond).(file).montage;
>    lfp = ft_preprocessing(cfg);
> 
>   data = ft_appenddata([],meg,lfp);
> 
>    cfg = [];
>    cfg.length = 1;
>    cfg.overlap = 0.5;
>    data_seg = ft_redefinetrial(cfg,data);
> 
> 
>    centerfreq = 12;
>    chan = ‘LFP-right-1-2A’;
>    bandwidth = 2;
> 
>    cfg = [];
>    cfg.method = 'mtmfft';
>    cfg.output = 'powandcsd';
>    cfg.foi = centerfreq;
>    cfg.tapsmofrq = bandwidth;
>    cfg.keeptrials = 'yes';
>    freq = ft_freqanalysis(cfg,data_seg);
> 
>    cfg=[];
>    cfg.method='dics';
>    cfg.dics.lambda='5%';
>    cfg.headmodel=hdm;
>    cfg.sourcemodel=grid;
>    cfg.frequency = centerfreq;
>    cfg.reducerank=2;
>    cfg.refchan = chan;
>    source=ft_sourceanalysis(cfg,freq);
>    source.pos = template.sourcemodel.pos;
>    source.dim = template.sourcemodel.dim;
> 
>    [maxval, maxcohindx] = max(source.avg.coh);
>    max_pos = source.pos(maxcohindx, :);
> 
>     cfg = [];
>     cfg.parameter = 'coh';
>     cfg.interpmethod        = 'nearest';
>     it = ft_sourceinterpolate(cfg,source,p); % p
> 
>     cfg =  [];
>     cfg.method = ‘ortho’;
>     cfg.funparameter = 'coh';
>     cfg.maskparameter = 'coh';
>     ft_sourceplot(cfg,it);
> 
> Thanks and greetings,
> Alexandra Steina<ft_2019.png><ft_april2020.png><ft_june2020.png><ft_november2020.png><ft_october2020.png>_______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202




From patrick.wiegel at sport.uni-freiburg.de  Wed Nov  4 14:21:16 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Wed, 4 Nov 2020 13:21:16 +0000
Subject: [FieldTrip] MultiplotTFR
Message-ID: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>

Dear community,

I am trying to use the function ft_multiplotTFR for time-frequency data generated by ft_frequanalyses (wavelet method) using the following code:

cfg = [];
cfg.layout = 'biosemi64.lay';
cfg.parameter = 'powspctrm';
cfg.xlim = [0 0.9];
ft_multiplotTFR(cfg, tfr_grandavg)

The result of the multiplot function is a single TF plot (see attachment) rather than 64 single channel TF plots arranged in the specified layout. It might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since the plot is correctly generated using older versions (e.g. fieldtrip-20200508). It would be great if anyone could test the function.

Best, Patrick

[cid:C5316CEC-9B39-490E-B0F1-1BC8A2388A8D at w2k.sport.uni-freiburg.de]
Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/aadeda86/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiplotTFR.jpg
Type: image/jpeg
Size: 32948 bytes
Desc: multiplotTFR.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/aadeda86/attachment.jpg>

From jan.schoffelen at donders.ru.nl  Wed Nov  4 14:45:37 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Wed, 4 Nov 2020 13:45:37 +0000
Subject: [FieldTrip] MultiplotTFR
In-Reply-To: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
References: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
Message-ID: <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>

Hi Patrick,

It works fine for me, so I cannot reproduce your issue. Have you tried closing all open figures in MATLAB before calling ft_multiplotTFR?


Since this is the second e-mail today that explicitly mentions a ‘break’ in functionality, let me seize the opportunity to point to the possibility that users can already play a little bit more detective than just mentioning ‘it worked in version X and not anymore in version Y’. If you go to the github repository https://github.com/fieldtrip/fieldtrip you can actually check the changes to the code in more detail, by investigating the ‘history’ of the function. This already could give you a headstart in describing the problem, and would give people inclined to look into this with you some handles to work with.



Best wishes,

Jan-Mathijs



On 4 Nov 2020, at 14:21, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Dear community,

I am trying to use the function ft_multiplotTFR for time-frequency data generated by ft_frequanalyses (wavelet method) using the following code:

cfg = [];
cfg.layout = 'biosemi64.lay';
cfg.parameter = 'powspctrm';
cfg.xlim = [0 0.9];
ft_multiplotTFR(cfg, tfr_grandavg)

The result of the multiplot function is a single TF plot (see attachment) rather than 64 single channel TF plots arranged in the specified layout. It might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since the plot is correctly generated using older versions (e.g. fieldtrip-20200508). It would be great if anyone could test the function.

Best, Patrick

<multiplotTFR.jpg>
Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/736911ee/attachment.htm>

From patrick.wiegel at sport.uni-freiburg.de  Wed Nov  4 15:11:22 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Wed, 4 Nov 2020 14:11:22 +0000
Subject: [FieldTrip] MultiplotTFR
In-Reply-To: <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>
References: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
 <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>
Message-ID: <BB11D07D-4EDB-4806-AFD8-37291B05F737@sport.uni-freiburg.de>

Hi Jan-Mathijs,

thanks for the fast response. I don’t have any other matlab figures opened. I had a look in the history of the function but was not able to identify the problem.

However, if it working for you, then it is probably something related to my script/setup.

Best, Patrick

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

Am 04.11.2020 um 14:45 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

It works fine for me, so I cannot reproduce your issue. Have you tried closing all open figures in MATLAB before calling ft_multiplotTFR?


Since this is the second e-mail today that explicitly mentions a ‘break’ in functionality, let me seize the opportunity to point to the possibility that users can already play a little bit more detective than just mentioning ‘it worked in version X and not anymore in version Y’. If you go to the github repository https://github.com/fieldtrip/fieldtrip you can actually check the changes to the code in more detail, by investigating the ‘history’ of the function. This already could give you a headstart in describing the problem, and would give people inclined to look into this with you some handles to work with.



Best wishes,

Jan-Mathijs



On 4 Nov 2020, at 14:21, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Dear community,

I am trying to use the function ft_multiplotTFR for time-frequency data generated by ft_frequanalyses (wavelet method) using the following code:

cfg = [];
cfg.layout = 'biosemi64.lay';
cfg.parameter = 'powspctrm';
cfg.xlim = [0 0.9];
ft_multiplotTFR(cfg, tfr_grandavg)

The result of the multiplot function is a single TF plot (see attachment) rather than 64 single channel TF plots arranged in the specified layout. It might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since the plot is correctly generated using older versions (e.g. fieldtrip-20200508). It would be great if anyone could test the function.

Best, Patrick

<multiplotTFR.jpg>
Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/763f645e/attachment.htm>

From jan.schoffelen at donders.ru.nl  Wed Nov  4 16:27:57 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Wed, 4 Nov 2020 15:27:57 +0000
Subject: [FieldTrip] MultiplotTFR
In-Reply-To: <BB11D07D-4EDB-4806-AFD8-37291B05F737@sport.uni-freiburg.de>
References: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
 <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>
 <BB11D07D-4EDB-4806-AFD8-37291B05F737@sport.uni-freiburg.de>
Message-ID: <13D35B4A-FF44-410D-9EE6-3680C7C5C9DE@donders.ru.nl>

Hi Patrick,

The only thing that can be done, is to try and reproduce the issue using your specific data. If this data is not too big, you can send it (off list), or even better: file an issue on github + a link to get the data, so that we (i.e. one of the FT developers) can have a look.

Best wishes,
Jan-Mathijs


On 4 Nov 2020, at 15:11, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Hi Jan-Mathijs,

thanks for the fast response. I don’t have any other matlab figures opened. I had a look in the history of the function but was not able to identify the problem.

However, if it working for you, then it is probably something related to my script/setup.

Best, Patrick

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de>

Am 04.11.2020 um 14:45 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

It works fine for me, so I cannot reproduce your issue. Have you tried closing all open figures in MATLAB before calling ft_multiplotTFR?


Since this is the second e-mail today that explicitly mentions a ‘break’ in functionality, let me seize the opportunity to point to the possibility that users can already play a little bit more detective than just mentioning ‘it worked in version X and not anymore in version Y’. If you go to the github repository https://github.com/fieldtrip/fieldtrip you can actually check the changes to the code in more detail, by investigating the ‘history’ of the function. This already could give you a headstart in describing the problem, and would give people inclined to look into this with you some handles to work with.



Best wishes,

Jan-Mathijs



On 4 Nov 2020, at 14:21, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Dear community,

I am trying to use the function ft_multiplotTFR for time-frequency data generated by ft_frequanalyses (wavelet method) using the following code:

cfg = [];
cfg.layout = 'biosemi64.lay';
cfg.parameter = 'powspctrm';
cfg.xlim = [0 0.9];
ft_multiplotTFR(cfg, tfr_grandavg)

The result of the multiplot function is a single TF plot (see attachment) rather than 64 single channel TF plots arranged in the specified layout. It might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since the plot is correctly generated using older versions (e.g. fieldtrip-20200508). It would be great if anyone could test the function.

Best, Patrick

<multiplotTFR.jpg>
Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/0bf0512f/attachment.htm>

From patrick.wiegel at sport.uni-freiburg.de  Wed Nov  4 17:25:08 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Wed, 4 Nov 2020 16:25:08 +0000
Subject: [FieldTrip] MultiplotTFR
In-Reply-To: <13D35B4A-FF44-410D-9EE6-3680C7C5C9DE@donders.ru.nl>
References: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
 <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>
 <BB11D07D-4EDB-4806-AFD8-37291B05F737@sport.uni-freiburg.de>
 <13D35B4A-FF44-410D-9EE6-3680C7C5C9DE@donders.ru.nl>
Message-ID: <42F1EF94-7527-49B3-8424-6E4A9183082B@sport.uni-freiburg.de>

Hi Jan-Mathijs,

I uploaded the code and the data to (https://github.com/PatrickWiegel/MultiplotTFR_plotting.git).

It would be interesting to see whether you experience the same problem with my data.

Best wishes,
Patrick



Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

Am 04.11.2020 um 16:27 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

The only thing that can be done, is to try and reproduce the issue using your specific data. If this data is not too big, you can send it (off list), or even better: file an issue on github + a link to get the data, so that we (i.e. one of the FT developers) can have a look.

Best wishes,
Jan-Mathijs


On 4 Nov 2020, at 15:11, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Hi Jan-Mathijs,

thanks for the fast response. I don’t have any other matlab figures opened. I had a look in the history of the function but was not able to identify the problem.

However, if it working for you, then it is probably something related to my script/setup.

Best, Patrick

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 04.11.2020 um 14:45 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

It works fine for me, so I cannot reproduce your issue. Have you tried closing all open figures in MATLAB before calling ft_multiplotTFR?


Since this is the second e-mail today that explicitly mentions a ‘break’ in functionality, let me seize the opportunity to point to the possibility that users can already play a little bit more detective than just mentioning ‘it worked in version X and not anymore in version Y’. If you go to the github repository https://github.com/fieldtrip/fieldtrip you can actually check the changes to the code in more detail, by investigating the ‘history’ of the function. This already could give you a headstart in describing the problem, and would give people inclined to look into this with you some handles to work with.



Best wishes,

Jan-Mathijs



On 4 Nov 2020, at 14:21, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Dear community,

I am trying to use the function ft_multiplotTFR for time-frequency data generated by ft_frequanalyses (wavelet method) using the following code:

cfg = [];
cfg.layout = 'biosemi64.lay';
cfg.parameter = 'powspctrm';
cfg.xlim = [0 0.9];
ft_multiplotTFR(cfg, tfr_grandavg)

The result of the multiplot function is a single TF plot (see attachment) rather than 64 single channel TF plots arranged in the specified layout. It might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since the plot is correctly generated using older versions (e.g. fieldtrip-20200508). It would be great if anyone could test the function.

Best, Patrick

<multiplotTFR.jpg>
Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/bfa7214d/attachment.htm>

From bianca.trovo at alumni.unitn.it  Wed Nov  4 21:26:19 2020
From: bianca.trovo at alumni.unitn.it (=?UTF-8?Q?Bianca_Trov=C3=B2?=)
Date: Wed, 4 Nov 2020 21:26:19 +0100
Subject: [FieldTrip] MEX file error (Sendy Caffarra)
In-Reply-To: <2096524568.343625.1580917771538.JavaMail.zimbra@bcbl.eu>
References: <FA0BDF57-98D0-4C4B-AB7A-737BD7570281@gmail.com>
 <2096524568.343625.1580917771538.JavaMail.zimbra@bcbl.eu>
Message-ID: <CAED=t8m7--ynfS=B1bQ9N7Q3wQhzTcGCQKzRo8jkTVtjirt5eQ@mail.gmail.com>

Hi,

Just following up on this discussion as I recently encountered the same
problem and none of the solutions proposed above worked for me (but still
thanks Sendy for your prompt reply!). Before I had also tried (without
success) similar solutions that other users suggested *in this forum*:
https://sourceforge.net/p/erppcatoolkit/discussion/767176/thread/23854347b4/
.
At some point, I was even going to reinstall some previous OS through Time
Machine... Gladly, some FT dev (?) saved me before I had to do that. So, in
case someone else stumbles upon this discussion in the mailing list or in
that forum, I report here that for me *the only method that worked was* the
one directly proposed by Fieldtrip here:
*https://www.fieldtriptoolbox.org/faq/mexmaci64_cannot_be_opened_because_the_developer_cannot_be_verified/.*
<https://www.fieldtriptoolbox.org/faq/mexmaci64_cannot_be_opened_because_the_developer_cannot_be_verified/.>

Best,

*------------------------------------------------------------
<http://internationaloffice.ceasaclay.com/>*
*Bianca Trovò,*

*Ph.D. candidate in Brain, Behaviour, Cognition*


On Wed, Feb 5, 2020 at 5:28 PM Sendy Caffarra <s.caffarra at bcbl.eu> wrote:

> Thank you Craig,
>
> I could fix it by updating Catalina, Xcode and allowing all Apps in the
> Security panel.
>
> Best,
> Sendy
>
> Sendy Caffarra
> BCBL Staff Scientist & Stanford Visiting Scholar
> https://sites.google.com/view/sendycaffarra
> http://www.bcbl.eu/people/staff/sendy-caffarra/
>
> ----- Original Message -----
> From: "Craig Richter" <craiggrichter at gmail.com>
> To: "fieldtrip" <fieldtrip at science.ru.nl>
> Cc: "s caffarra" <s.caffarra at bcbl.eu>
> Sent: Wednesday, February 5, 2020 3:43:55 AM
> Subject: Re: MEX file error (Sendy Caffarra)
>
> Hi Sendy,
>
> This appears to arise due to a ‘feature’ of the new MacOS, as the try to
> turn our PCs into iPhones... Catalina is applying very deep security, so
> since it doesn’t ‘know’ this mex, i.e. it hasn’t been notarized by Apple,
> the OS will not allow the access to libraries, etc. that it needs, hence
> the problem. See the attached discussion of the issue. Towards the bottom,
> it is suggested that with the current Catalina release, authorization may
> be given manually. If anybody knows how to do this, perhaps this is the
> workaround, or otherwise I suppose some submission will need to be made to
> Apple, i.e. got through the notarization process. As a rule-of-thumb, I try
> to stay an OS or two behind the current Apple release since they seem to
> becoming increasingly damaging with their updates.
>
> https://bugs.launchpad.net/gcc-arm-embedded/+bug/1832620
>
> Best,
>
> Craig
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201104/473378c8/attachment.htm>

From politzerahless at gmail.com  Thu Nov  5 04:11:36 2020
From: politzerahless at gmail.com (Stephen Politzer-Ahles)
Date: Thu, 5 Nov 2020 11:11:36 +0800
Subject: [FieldTrip] Preparing layout from list of 3d coordinates
Message-ID: <CAJT2k_93wioURSD+fBf1ddS6sWC16sT9y7gJDdAm+o4qouTSTw@mail.gmail.com>

Hello,

I have electrode channel locations (in x,y,z coordinates) in a file format
that I think is not supported by ft_read_sens. I would like to use
ft_prepare_layout to project these locations into a 2d layout (for plotting
and for cluster-based permutation tests). I see from
https://www.fieldtriptoolbox.org/tutorial/layout/ that it's possible to do,
but I can't figure out exactly how (it just says "you can use
ft_prepare_layout", but not exactly how; I've tried the following two ways
but I get a "no layout detected" error:

cfg = [];
cfg.elec = <the filename for my channel locations>;
lay = ft_prepare_layout(cfg);

cfg = [];
cfg.elec = <a 69x3 matrix of my xyz coordinates>;
lay = ft_prepare_layout(cfg);

Is there an example online somewhere of how to use ft_prepare_layout with
just a set of xyz coordinates rather than loading a filename or template?

Thanks,
Steve


---
Stephen Politzer-Ahles
The Hong Kong Polytechnic University
Department of Chinese and Bilingual Studies
http://www.polyu.edu.hk/cbs/sjpolit/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/dd766127/attachment.htm>

From hyxer1998 at 163.com  Thu Nov  5 05:03:54 2020
From: hyxer1998 at 163.com (hyxer1998 at 163.com)
Date: Thu, 5 Nov 2020 12:03:54 +0800
Subject: [FieldTrip] Problem with downsampling
Message-ID: <30168522-6B91-4F1D-8483-A0A13E36914D@163.com>

Dear FieldTrip Community,

My name is Yuxin He. I’m learning how to use ICA to reject EOG artifacts from this tutorial https://www.fieldtriptoolbox.org/example/use_independent_component_analysis_ica_to_remove_eog_artifacts/. 
However, when I ran the part code of downsampling in this tutorial, there was an error

Error in ft_resampledata (line 230)
        newdat = transpose(resample(transpose(olddat),fsres,fsorig));

I don’t know how to deal with and hope anyone can help me with this trivial problem. 

Thank you very much. 

Yuxin He
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/158d7cfa/attachment.htm>

From alexandra.steina at uni-duesseldorf.de  Thu Nov  5 08:27:35 2020
From: alexandra.steina at uni-duesseldorf.de (Alexandra Steina)
Date: Thu, 5 Nov 2020 08:27:35 +0100
Subject: [FieldTrip] Results from source analysis with different
 fieldtrip versions differ!?
In-Reply-To: <00A2B5A4-3C23-419E-BB94-342C1CE722DB@donders.ru.nl>
References: <422deac53087aed1f4867a374b20f854@uni-duesseldorf.de>
 <c3ac3540a0b7b28b2666541bca5908bc@uni-duesseldorf.de>
 <00A2B5A4-3C23-419E-BB94-342C1CE722DB@donders.ru.nl>
Message-ID: <2fb5e64b-70aa-506e-8e8a-d7536ea336ab@uni-duesseldorf.de>

Hi  Jan-Mathijs,

Thanks for the quick reply.
I've checked it for the april and october version and the 'freq' 
structures are the same.

Greetings,
Alexandra

Am 04.11.2020 um 14:09 schrieb Schoffelen, J.M. (Jan Mathijs):
> Hi Alexandra,
>
> Hmmm, that’s not good. We have recently tried to clean up the codebase that is doing various inverse calculations, which was indeed around the time at which you identified a change in figure quality. I don’t think this has to do with the leadfield computation.
>
> Just as a first step, could you check whether the ‘freq’ structures are the same in the different FieldTrip versions? Just to be sure that indeed the cause of this lies in ft_sourceanalysis or ft_inverse_dics.
>
> Best wishes,
> Jan-Mathijs
>
>
>
>> On 4 Nov 2020, at 13:38, Alexandra Steina <Alexandra.Steina at uni-duesseldorf.de> wrote:
>>
>> Hello everyone,
>>
>> I used the following pipeline to perform a source analysis on MEG-LFP data. I noticed different results when using different Fieldtrip Versions for the exact same data and analysis pipeline.
>> I read that there was a bug in the 'ft_prepare_leadfield' function in the release of June and it says that the bug was fixed, but I got some weird results when doing dics source reconstruction on the MEG data with the Fieldtrip releases from August on (I also just tried the release from yesterday). I attached some sourceplots (all from the exact same data) that are all done with a different Fieldtrip Version.
>> Does anyone know if there is still a bug in the newest fieldtrip releases or why these differences occur?
>>
>>     mri  = ft_read_mri(mri_path);
>>     mri.anatomy=double(mri.anatomy);
>>     fidu = importdata([fidu_path,'fiducial.txt']);
>>     cfg=[];
>>     cfg.coordsys='neuromag';
>>     cfg.method = 'fiducial';
>>     cfg.fiducial.nas    = fidu.data(2,:);
>>     cfg.fiducial.lpa    = fidu.data(3,:);
>>     cfg.fiducial.rpa    = fidu.data(1,:);
>>     real_mri=ft_volumerealign(cfg,mri);
>>
>>     cfg                = [];
>>     cfg.keepintermediate = 'no';
>>     cfg.write          = 'no';
>>     cfg.name          = [folder_intermediate,'spmtmp'];
>>     segmentedmri   = ft_volumesegment(cfg, real_mri);
>>
>>     cfg                = [];
>>     cfg.method = 'singleshell';
>>     hdm                = ft_prepare_headmodel(cfg,segmentedmri);
>>     hdm = ft_convert_units(hdm,'cm');
>>
>>     template = load(fullfile('fieldtrip/template/sourcemodel/standard_sourcemodel3d10mm'));
>>
>>     cfg                = [];
>>     cfg.grid.warpmni   = 'yes';
>>     cfg.grid.template  = template.sourcemodel;  % template_grid
>>     cfg.grid.nonlinear = 'yes';
>>     cfg.mri            = real_mri;
>>     cfg.grid.unit      ='cm';
>>     grid               = ft_prepare_sourcemodel(cfg);
>>
>>     cfg = [];
>>     cfg.dataset = dataset;
>>     cfg.dftfilter = 'yes';
>>     cfg.trl = trl;
>>     cfg.channel = ['MEG***2','MEG***3',Info_et.(subj).(cond).(file).bad_meg];
>>     meg = ft_preprocessing(cfg);
>>
>>
>>     cfg = [];
>>     cfg.dataset = dataset;
>>     cfg.dftfilter = 'yes';
>>     cfg.trl = trl;
>>     cfg.channel = Info_et.(subj).(cond).(file).old_lfp_labels;
>>     cfg.montage = Info_et.(subj).(cond).(file).montage;
>>     lfp = ft_preprocessing(cfg);
>>
>>    data = ft_appenddata([],meg,lfp);
>>
>>     cfg = [];
>>     cfg.length = 1;
>>     cfg.overlap = 0.5;
>>     data_seg = ft_redefinetrial(cfg,data);
>>
>>
>>     centerfreq = 12;
>>     chan = ‘LFP-right-1-2A’;
>>     bandwidth = 2;
>>
>>     cfg = [];
>>     cfg.method = 'mtmfft';
>>     cfg.output = 'powandcsd';
>>     cfg.foi = centerfreq;
>>     cfg.tapsmofrq = bandwidth;
>>     cfg.keeptrials = 'yes';
>>     freq = ft_freqanalysis(cfg,data_seg);
>>
>>     cfg=[];
>>     cfg.method='dics';
>>     cfg.dics.lambda='5%';
>>     cfg.headmodel=hdm;
>>     cfg.sourcemodel=grid;
>>     cfg.frequency = centerfreq;
>>     cfg.reducerank=2;
>>     cfg.refchan = chan;
>>     source=ft_sourceanalysis(cfg,freq);
>>     source.pos = template.sourcemodel.pos;
>>     source.dim = template.sourcemodel.dim;
>>
>>     [maxval, maxcohindx] = max(source.avg.coh);
>>     max_pos = source.pos(maxcohindx, :);
>>
>>      cfg = [];
>>      cfg.parameter = 'coh';
>>      cfg.interpmethod        = 'nearest';
>>      it = ft_sourceinterpolate(cfg,source,p); % p
>>
>>      cfg =  [];
>>      cfg.method = ‘ortho’;
>>      cfg.funparameter = 'coh';
>>      cfg.maskparameter = 'coh';
>>      ft_sourceplot(cfg,it);
>>
>> Thanks and greetings,
>> Alexandra Steina<ft_2019.png><ft_april2020.png><ft_june2020.png><ft_november2020.png><ft_october2020.png>_______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202




From jan.schoffelen at donders.ru.nl  Thu Nov  5 08:52:27 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Thu, 5 Nov 2020 07:52:27 +0000
Subject: [FieldTrip] Preparing layout from list of 3d coordinates
In-Reply-To: <CAJT2k_93wioURSD+fBf1ddS6sWC16sT9y7gJDdAm+o4qouTSTw@mail.gmail.com>
References: <CAJT2k_93wioURSD+fBf1ddS6sWC16sT9y7gJDdAm+o4qouTSTw@mail.gmail.com>
Message-ID: <3E270AEF-12DF-433B-84A2-A767B068FC8C@donders.ru.nl>

Hi Steve,

I think the easiest way to get started for you would be to consult the layout<https://www.fieldtriptoolbox.org/tutorial/layout/> tutorial. At the top it mentions a box which shows what a ‘layout’ variable more or less should look like after reading it in with ft_prepare_layout. In other words, if you manage to convert the x,y,z positions into a nice 2D-projected x,y positions, you’re almost there.
Alternatively, you might need to use ft_prepare_layout to make this 2D projection for you. In that case you probably need to consult the section ‘making a layout from MEG sensors’ and replace the MEG sensor array for your EEG sensor array. This needs to be defined according to https://www.fieldtriptoolbox.org/reference/ft_datatype_sens/

Best wishes,
Jan-Mathijs

On 5 Nov 2020, at 04:11, Stephen Politzer-Ahles <politzerahless at gmail.com<mailto:politzerahless at gmail.com>> wrote:

Hello,

I have electrode channel locations (in x,y,z coordinates) in a file format that I think is not supported by ft_read_sens. I would like to use ft_prepare_layout to project these locations into a 2d layout (for plotting and for cluster-based permutation tests). I see from https://www.fieldtriptoolbox.org/tutorial/layout/ that it's possible to do, but I can't figure out exactly how (it just says "you can use ft_prepare_layout", but not exactly how; I've tried the following two ways but I get a "no layout detected" error:

cfg = [];
cfg.elec = <the filename for my channel locations>;
lay = ft_prepare_layout(cfg);

cfg = [];
cfg.elec = <a 69x3 matrix of my xyz coordinates>;
lay = ft_prepare_layout(cfg);

Is there an example online somewhere of how to use ft_prepare_layout with just a set of xyz coordinates rather than loading a filename or template?

Thanks,
Steve


---
Stephen Politzer-Ahles
The Hong Kong Polytechnic University
Department of Chinese and Bilingual Studies
http://www.polyu.edu.hk/cbs/sjpolit/
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/18359d69/attachment.htm>

From jan.schoffelen at donders.ru.nl  Thu Nov  5 08:52:56 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Thu, 5 Nov 2020 07:52:56 +0000
Subject: [FieldTrip] Problem with downsampling
In-Reply-To: <30168522-6B91-4F1D-8483-A0A13E36914D@163.com>
References: <30168522-6B91-4F1D-8483-A0A13E36914D@163.com>
Message-ID: <63972648-3DD5-4821-B6AC-494E7AE5AAEC@donders.ru.nl>

What is the error?

On 5 Nov 2020, at 05:03, hyxer1998 at 163.com<mailto:hyxer1998 at 163.com> wrote:

Dear FieldTrip Community,

My name is Yuxin He. I’m learning how to use ICA to reject EOG artifacts from this tutorial https://www.fieldtriptoolbox.org/example/use_independent_component_analysis_ica_to_remove_eog_artifacts/.
However, when I ran the part code of downsampling in this tutorial, there was an error

Error in ft_resampledata (line 230)
        newdat = transpose(resample(transpose(olddat),fsres,fsorig));

I don’t know how to deal with and hope anyone can help me with this trivial problem.

Thank you very much.

Yuxin He
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/fa8dfd0d/attachment.htm>

From stephen.whitmarsh at gmail.com  Thu Nov  5 09:01:08 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Thu, 5 Nov 2020 09:01:08 +0100
Subject: [FieldTrip] MultiplotTFR
In-Reply-To: <42F1EF94-7527-49B3-8424-6E4A9183082B@sport.uni-freiburg.de>
References: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
 <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>
 <BB11D07D-4EDB-4806-AFD8-37291B05F737@sport.uni-freiburg.de>
 <13D35B4A-FF44-410D-9EE6-3680C7C5C9DE@donders.ru.nl>
 <42F1EF94-7527-49B3-8424-6E4A9183082B@sport.uni-freiburg.de>
Message-ID: <CAFrxm=yRoAjgq3rDqi2YyeN_nei=BHsCAuOgpOaE7RifBf_Ucg@mail.gmail.com>

Hi Patrick,

I couldn't resist to try your example and on my Windows 10 computer, MATLAB
2019b, current FT version, your problem replicates.
All seems well with ft_topoplot_TFR (also interactive mode) and
ft_singleplot_TFR, but ft_multiplotTFR behaves strangely indeed (attached).

Cheers,
Stephen

Op wo 4 nov. 2020 om 17:27 schreef Patrick Wiegel <
patrick.wiegel at sport.uni-freiburg.de>:

> Hi Jan-Mathijs,
>
> I uploaded the code and the data to (
> https://github.com/PatrickWiegel/MultiplotTFR_plotting.git).
>
> It would be interesting to see whether you experience the same problem
> with my data.
>
> Best wishes,
> Patrick
>
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> Am 04.11.2020 um 16:27 schrieb Schoffelen, J.M. (Jan Mathijs) <
> jan.schoffelen at donders.ru.nl>:
>
> Hi Patrick,
>
> The only thing that can be done, is to try and reproduce the issue using
> your specific data. If this data is not too big, you can send it (off
> list), or even better: file an issue on github + a link to get the data, so
> that we (i.e. one of the FT developers) can have a look.
>
> Best wishes,
> Jan-Mathijs
>
>
> On 4 Nov 2020, at 15:11, Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de> wrote:
>
> Hi Jan-Mathijs,
>
> thanks for the fast response. I don’t have any other matlab figures
> opened. I had a look in the history of the function but was not able to
> identify the problem.
>
> However, if it working for you, then it is probably something related to
> my script/setup.
>
> Best, Patrick
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> Am 04.11.2020 um 14:45 schrieb Schoffelen, J.M. (Jan Mathijs) <
> jan.schoffelen at donders.ru.nl>:
>
> Hi Patrick,
>
> It works fine for me, so I cannot reproduce your issue. Have you tried
> closing all open figures in MATLAB before calling ft_multiplotTFR?
>
>
> Since this is the second e-mail today that explicitly mentions a ‘break’
> in functionality, let me seize the opportunity to point to the possibility
> that users can already play a little bit more detective than just
> mentioning ‘it worked in version X and not anymore in version Y’. If you go
> to the github repository https://github.com/fieldtrip/fieldtrip you can
> actually check the changes to the code in more detail, by investigating the
> ‘history’ of the function. This already could give you a headstart in
> describing the problem, and would give people inclined to look into this
> with you some handles to work with.
>
>
>
> Best wishes,
>
> Jan-Mathijs
>
>
>
> On 4 Nov 2020, at 14:21, Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de> wrote:
>
> Dear community,
>
> I am trying to use the function ft_multiplotTFR for time-frequency data
> generated by ft_frequanalyses (wavelet method) using the following code:
>
> cfg = [];
> cfg.layout = 'biosemi64.lay';
> cfg.parameter = 'powspctrm';
> cfg.xlim = [0 0.9];
> ft_multiplotTFR(cfg, tfr_grandavg)
>
> The result of the multiplot function is a single TF plot (see attachment)
> rather than 64 single channel TF plots arranged in the specified layout. It
> might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since
> the plot is correctly generated using older versions (e.g.
> fieldtrip-20200508). It would be great if anyone could test the function.
>
> Best, Patrick
>
> <multiplotTFR.jpg>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/0f679602/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: singleplot.jpg
Type: image/jpeg
Size: 27335 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/0f679602/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiplot.jpg
Type: image/jpeg
Size: 14700 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/0f679602/attachment-0001.jpg>

From jan.schoffelen at donders.ru.nl  Thu Nov  5 09:39:15 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Thu, 5 Nov 2020 08:39:15 +0000
Subject: [FieldTrip] Results from source analysis with different
 fieldtrip versions differ!?
In-Reply-To: <2fb5e64b-70aa-506e-8e8a-d7536ea336ab@uni-duesseldorf.de>
References: <422deac53087aed1f4867a374b20f854@uni-duesseldorf.de>
 <c3ac3540a0b7b28b2666541bca5908bc@uni-duesseldorf.de>
 <00A2B5A4-3C23-419E-BB94-342C1CE722DB@donders.ru.nl>
 <2fb5e64b-70aa-506e-8e8a-d7536ea336ab@uni-duesseldorf.de>
Message-ID: <EBFD5CCB-00B6-4926-B933-C38C177A82B1@donders.ru.nl>

Thanks Alexandra,

This sounds like something that might need to be looked into a bit more thoroughly.

I see several possible ways forward.

1) The most straightforward way would be to have one of your local technical experts look along. I might be mistaken, but given your affiliation I have the impression that there might be quite some people around that 1) know the MEG system that you are using, and 2) use very similar analyses. Have you already consulted locally, to see whether people have experienced similar issues? Or have you asked people to look along with you, to diagnose the issue a bit further?

2) You could file an issue on https://github.com/fieldtrip/fieldtrip, which at a minimum would include some code and data to reproduce the issue. In itself, this is a little bit less preferred, because in this case one of the developers needs to look into this (individually), (s)he might solve and fix it, and report back to you that it has been fixed. The problems I see with this approach is that 1) the person looking into the problem is doing some unrewarding problem solving, and 2) the person whose problem hopefully will be solved does not really gain a lot of insight into what was wrong in the first place.

So, I would vote for option 3: why don’t we work on this together?

At the DCCN we have a weekly MEEG-‘hackaton’, usually on the Thursday afternoons (15.00-17.00), in which we team up to work on something together. One of these ’something’s could be to fix issues that people are experiencing in their analysis pipelines. As such there is no reason to constrain these meetings to local people, so I’d say why don’t you join the club for one of the upcoming meetings? Just drop me a line off-list.

Best wishes,

Jan-Mathijs


On 5 Nov 2020, at 08:27, Alexandra Steina <Alexandra.Steina at uni-duesseldorf.de<mailto:Alexandra.Steina at uni-duesseldorf.de>> wrote:

Hi  Jan-Mathijs,

Thanks for the quick reply.
I've checked it for the april and october version and the 'freq' structures are the same.

Greetings,
Alexandra

Am 04.11.2020 um 14:09 schrieb Schoffelen, J.M. (Jan Mathijs):
Hi Alexandra,

Hmmm, that’s not good. We have recently tried to clean up the codebase that is doing various inverse calculations, which was indeed around the time at which you identified a change in figure quality. I don’t think this has to do with the leadfield computation.

Just as a first step, could you check whether the ‘freq’ structures are the same in the different FieldTrip versions? Just to be sure that indeed the cause of this lies in ft_sourceanalysis or ft_inverse_dics.

Best wishes,
Jan-Mathijs



On 4 Nov 2020, at 13:38, Alexandra Steina <Alexandra.Steina at uni-duesseldorf.de<mailto:Alexandra.Steina at uni-duesseldorf.de>> wrote:

Hello everyone,

I used the following pipeline to perform a source analysis on MEG-LFP data. I noticed different results when using different Fieldtrip Versions for the exact same data and analysis pipeline.
I read that there was a bug in the 'ft_prepare_leadfield' function in the release of June and it says that the bug was fixed, but I got some weird results when doing dics source reconstruction on the MEG data with the Fieldtrip releases from August on (I also just tried the release from yesterday). I attached some sourceplots (all from the exact same data) that are all done with a different Fieldtrip Version.
Does anyone know if there is still a bug in the newest fieldtrip releases or why these differences occur?

   mri  = ft_read_mri(mri_path);
   mri.anatomy=double(mri.anatomy);
   fidu = importdata([fidu_path,'fiducial.txt']);
   cfg=[];
   cfg.coordsys='neuromag';
   cfg.method = 'fiducial';
   cfg.fiducial.nas    = fidu.data(2,:);
   cfg.fiducial.lpa    = fidu.data(3,:);
   cfg.fiducial.rpa    = fidu.data(1,:);
   real_mri=ft_volumerealign(cfg,mri);

   cfg                = [];
   cfg.keepintermediate = 'no';
   cfg.write          = 'no';
   cfg.name          = [folder_intermediate,'spmtmp'];
   segmentedmri   = ft_volumesegment(cfg, real_mri);

   cfg                = [];
   cfg.method = 'singleshell';
   hdm                = ft_prepare_headmodel(cfg,segmentedmri);
   hdm = ft_convert_units(hdm,'cm');

   template = load(fullfile('fieldtrip/template/sourcemodel/standard_sourcemodel3d10mm'));

   cfg                = [];
   cfg.grid.warpmni   = 'yes';
   cfg.grid.template  = template.sourcemodel;  % template_grid
   cfg.grid.nonlinear = 'yes';
   cfg.mri            = real_mri;
   cfg.grid.unit      ='cm';
   grid               = ft_prepare_sourcemodel(cfg);

   cfg = [];
   cfg.dataset = dataset;
   cfg.dftfilter = 'yes';
   cfg.trl = trl;
   cfg.channel = ['MEG***2','MEG***3',Info_et.(subj).(cond).(file).bad_meg];
   meg = ft_preprocessing(cfg);


   cfg = [];
   cfg.dataset = dataset;
   cfg.dftfilter = 'yes';
   cfg.trl = trl;
   cfg.channel = Info_et.(subj).(cond).(file).old_lfp_labels;
   cfg.montage = Info_et.(subj).(cond).(file).montage;
   lfp = ft_preprocessing(cfg);

  data = ft_appenddata([],meg,lfp);

   cfg = [];
   cfg.length = 1;
   cfg.overlap = 0.5;
   data_seg = ft_redefinetrial(cfg,data);


   centerfreq = 12;
   chan = ‘LFP-right-1-2A’;
   bandwidth = 2;

   cfg = [];
   cfg.method = 'mtmfft';
   cfg.output = 'powandcsd';
   cfg.foi = centerfreq;
   cfg.tapsmofrq = bandwidth;
   cfg.keeptrials = 'yes';
   freq = ft_freqanalysis(cfg,data_seg);

   cfg=[];
   cfg.method='dics';
   cfg.dics.lambda='5%';
   cfg.headmodel=hdm;
   cfg.sourcemodel=grid;
   cfg.frequency = centerfreq;
   cfg.reducerank=2;
   cfg.refchan = chan;
   source=ft_sourceanalysis(cfg,freq);
   source.pos = template.sourcemodel.pos;
   source.dim = template.sourcemodel.dim;

   [maxval, maxcohindx] = max(source.avg.coh);
   max_pos = source.pos(maxcohindx, :);

    cfg = [];
    cfg.parameter = 'coh';
    cfg.interpmethod        = 'nearest';
    it = ft_sourceinterpolate(cfg,source,p); % p

    cfg =  [];
    cfg.method = ‘ortho’;
    cfg.funparameter = 'coh';
    cfg.maskparameter = 'coh';
    ft_sourceplot(cfg,it);

Thanks and greetings,
Alexandra Steina<ft_2019.png><ft_april2020.png><ft_june2020.png><ft_november2020.png><ft_october2020.png>_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202


_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/439f5e20/attachment.htm>

From jan.schoffelen at donders.ru.nl  Thu Nov  5 09:41:35 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Thu, 5 Nov 2020 08:41:35 +0000
Subject: [FieldTrip] MultiplotTFR
In-Reply-To: <CAFrxm=yRoAjgq3rDqi2YyeN_nei=BHsCAuOgpOaE7RifBf_Ucg@mail.gmail.com>
References: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
 <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>
 <BB11D07D-4EDB-4806-AFD8-37291B05F737@sport.uni-freiburg.de>
 <13D35B4A-FF44-410D-9EE6-3680C7C5C9DE@donders.ru.nl>
 <42F1EF94-7527-49B3-8424-6E4A9183082B@sport.uni-freiburg.de>
 <CAFrxm=yRoAjgq3rDqi2YyeN_nei=BHsCAuOgpOaE7RifBf_Ucg@mail.gmail.com>
Message-ID: <52E91D53-CE6D-4077-A5F5-9212D45F0CE1@donders.ru.nl>

Hi Stephen and Patrick,

Indeed I was a bit rash earlier when stating that I couldn’t reproduce the issue. Somehow, I was working on a local branch of the code (which branched off from the master branch before the code changes were done that caused the problem apparently). I have created an issue on github https://github.com/fieldtrip/fieldtrip/issues/1583 so it is on our radar. Stay tuned and healthy!

Best wishes,
JM


On 5 Nov 2020, at 09:01, Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>> wrote:

Hi Patrick,

I couldn't resist to try your example and on my Windows 10 computer, MATLAB 2019b, current FT version, your problem replicates.
All seems well with ft_topoplot_TFR (also interactive mode) and ft_singleplot_TFR, but ft_multiplotTFR behaves strangely indeed (attached).

Cheers,
Stephen

Op wo 4 nov. 2020 om 17:27 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Hi Jan-Mathijs,

I uploaded the code and the data to (https://github.com/PatrickWiegel/MultiplotTFR_plotting.git).

It would be interesting to see whether you experience the same problem with my data.

Best wishes,
Patrick



Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 04.11.2020 um 16:27 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

The only thing that can be done, is to try and reproduce the issue using your specific data. If this data is not too big, you can send it (off list), or even better: file an issue on github + a link to get the data, so that we (i.e. one of the FT developers) can have a look.

Best wishes,
Jan-Mathijs


On 4 Nov 2020, at 15:11, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Hi Jan-Mathijs,

thanks for the fast response. I don’t have any other matlab figures opened. I had a look in the history of the function but was not able to identify the problem.

However, if it working for you, then it is probably something related to my script/setup.

Best, Patrick

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 04.11.2020 um 14:45 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

It works fine for me, so I cannot reproduce your issue. Have you tried closing all open figures in MATLAB before calling ft_multiplotTFR?


Since this is the second e-mail today that explicitly mentions a ‘break’ in functionality, let me seize the opportunity to point to the possibility that users can already play a little bit more detective than just mentioning ‘it worked in version X and not anymore in version Y’. If you go to the github repository https://github.com/fieldtrip/fieldtrip you can actually check the changes to the code in more detail, by investigating the ‘history’ of the function. This already could give you a headstart in describing the problem, and would give people inclined to look into this with you some handles to work with.



Best wishes,

Jan-Mathijs



On 4 Nov 2020, at 14:21, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Dear community,

I am trying to use the function ft_multiplotTFR for time-frequency data generated by ft_frequanalyses (wavelet method) using the following code:

cfg = [];
cfg.layout = 'biosemi64.lay';
cfg.parameter = 'powspctrm';
cfg.xlim = [0 0.9];
ft_multiplotTFR(cfg, tfr_grandavg)

The result of the multiplot function is a single TF plot (see attachment) rather than 64 single channel TF plots arranged in the specified layout. It might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since the plot is correctly generated using older versions (e.g. fieldtrip-20200508). It would be great if anyone could test the function.

Best, Patrick

<multiplotTFR.jpg>
Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
<singleplot.jpg><multiplot.jpg>_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/d9b09492/attachment.htm>

From hyxer1998 at 163.com  Thu Nov  5 13:07:03 2020
From: hyxer1998 at 163.com (hyxer1998 at 163.com)
Date: Thu, 5 Nov 2020 20:07:03 +0800
Subject: [FieldTrip] Problem with downsampling
Message-ID: <F1B3C0AE-F1FA-4C2E-9475-19676F7B04FA@163.com>

﻿Sorry, I forgot to describe the specific error.  It said when I called the function ‘resample’, the parameters were not enough or type was wrong. And the error happened in ft_resampledata.m line 230, i.e. Error in ft_resampledata (line 230) newdat = transpose(resample(transpose(olddat),fsres,fsorig)); 
But, I used the exactly same dataset and code in the tutorial, so I don’t get where mistook. 


> 在 2020年11月5日，17:13，Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl> 写道：
> ﻿ What is the error?
> 
>> On 5 Nov 2020, at 05:03, hyxer1998 at 163.com wrote:
>> 
>> Dear FieldTrip Community,
>> 
>> My name is Yuxin He. I’m learning how to use ICA to reject EOG artifacts from this tutorial https://www.fieldtriptoolbox.org/example/use_independent_component_analysis_ica_to_remove_eog_artifacts/. 
>> However, when I ran the part code of downsampling in this tutorial, there was an error
>> 
>> Error in ft_resampledata (line 230)
>>         newdat = transpose(resample(transpose(olddat),fsres,fsorig));
>> 
>> I don’t know how to deal with and hope anyone can help me with this trivial problem. 
>> 
>> Thank you very much. 
>> 
>> Yuxin He
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
> 
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/4efe5857/attachment.htm>

From jan.schoffelen at donders.ru.nl  Thu Nov  5 14:43:03 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Thu, 5 Nov 2020 13:43:03 +0000
Subject: [FieldTrip] Results from source analysis with different
 fieldtrip versions differ!?
In-Reply-To: <8c28439b-6779-274d-0b1d-2111b368b0db@uni-duesseldorf.de>
References: <422deac53087aed1f4867a374b20f854@uni-duesseldorf.de>
 <c3ac3540a0b7b28b2666541bca5908bc@uni-duesseldorf.de>
 <00A2B5A4-3C23-419E-BB94-342C1CE722DB@donders.ru.nl>
 <2fb5e64b-70aa-506e-8e8a-d7536ea336ab@uni-duesseldorf.de>
 <EBFD5CCB-00B6-4926-B933-C38C177A82B1@donders.ru.nl>
 <8c28439b-6779-274d-0b1d-2111b368b0db@uni-duesseldorf.de>
Message-ID: <74A4F8DB-5A6E-4644-BBF7-E549531725FB@donders.ru.nl>

Hi Alexandra,

We use Zoom to meet. I would assume you are familiar with it. Once you have an invite link you can easily join. Then we typically discuss a bit and create ‘breakout rooms’ where we can work in teams. Zoom allows for remote control of other people’s computer, so ideally we’d then be able to work on your problem locally. This would require zoom to run (on your end) on a machine that has access to the graphical interface that is running matlab. If you then could set up a matlab session that is in a ’state’ that allows for easy reproduction of the problem (i.e. freq data loaded in, and the relevant script open in the editor), we could hit the ground running.

I will send you a link, if you’d like to join today (I’ll send this off list).

Best wishes,
Jan-Mathijs


On 5 Nov 2020, at 13:40, Alexandra Steina <alexandra.steina at uni-duesseldorf.de<mailto:alexandra.steina at uni-duesseldorf.de>> wrote:

Hi Jan-Mathijs,

Option 3 sounds great to me as well! It's probably the best way to fix this issue. So what format does the meeting have in times of Corona?
I do my PhD in Jan Hirschmann's group and I talked to him and to other people from my group, but there is nobody who has been using 'dics' beamforming and source localisation with Fieldtrip recently, so that I can not tell if anyone experienced similar issues. That's why Jan suggested to contact the Fieldtrip Mailing List.

Greetings,
Alexandra

Am 05.11.2020 um 09:39 schrieb Schoffelen, J.M. (Jan Mathijs):
Thanks Alexandra,

This sounds like something that might need to be looked into a bit more thoroughly.

I see several possible ways forward.

1) The most straightforward way would be to have one of your local technical experts look along. I might be mistaken, but given your affiliation I have the impression that there might be quite some people around that 1) know the MEG system that you are using, and 2) use very similar analyses. Have you already consulted locally, to see whether people have experienced similar issues? Or have you asked people to look along with you, to diagnose the issue a bit further?

2) You could file an issue on https://github.com/fieldtrip/fieldtrip, which at a minimum would include some code and data to reproduce the issue. In itself, this is a little bit less preferred, because in this case one of the developers needs to look into this (individually), (s)he might solve and fix it, and report back to you that it has been fixed. The problems I see with this approach is that 1) the person looking into the problem is doing some unrewarding problem solving, and 2) the person whose problem hopefully will be solved does not really gain a lot of insight into what was wrong in the first place.

So, I would vote for option 3: why don’t we work on this together?

At the DCCN we have a weekly MEEG-‘hackaton’, usually on the Thursday afternoons (15.00-17.00), in which we team up to work on something together. One of these ’something’s could be to fix issues that people are experiencing in their analysis pipelines. As such there is no reason to constrain these meetings to local people, so I’d say why don’t you join the club for one of the upcoming meetings? Just drop me a line off-list.

Best wishes,

Jan-Mathijs


On 5 Nov 2020, at 08:27, Alexandra Steina <Alexandra.Steina at uni-duesseldorf.de<mailto:Alexandra.Steina at uni-duesseldorf.de>> wrote:

Hi  Jan-Mathijs,

Thanks for the quick reply.
I've checked it for the april and october version and the 'freq' structures are the same.

Greetings,
Alexandra

Am 04.11.2020 um 14:09 schrieb Schoffelen, J.M. (Jan Mathijs):
Hi Alexandra,

Hmmm, that’s not good. We have recently tried to clean up the codebase that is doing various inverse calculations, which was indeed around the time at which you identified a change in figure quality. I don’t think this has to do with the leadfield computation.

Just as a first step, could you check whether the ‘freq’ structures are the same in the different FieldTrip versions? Just to be sure that indeed the cause of this lies in ft_sourceanalysis or ft_inverse_dics.

Best wishes,
Jan-Mathijs



On 4 Nov 2020, at 13:38, Alexandra Steina <Alexandra.Steina at uni-duesseldorf.de<mailto:Alexandra.Steina at uni-duesseldorf.de>> wrote:

Hello everyone,

I used the following pipeline to perform a source analysis on MEG-LFP data. I noticed different results when using different Fieldtrip Versions for the exact same data and analysis pipeline.
I read that there was a bug in the 'ft_prepare_leadfield' function in the release of June and it says that the bug was fixed, but I got some weird results when doing dics source reconstruction on the MEG data with the Fieldtrip releases from August on (I also just tried the release from yesterday). I attached some sourceplots (all from the exact same data) that are all done with a different Fieldtrip Version.
Does anyone know if there is still a bug in the newest fieldtrip releases or why these differences occur?

   mri  = ft_read_mri(mri_path);
   mri.anatomy=double(mri.anatomy);
   fidu = importdata([fidu_path,'fiducial.txt']);
   cfg=[];
   cfg.coordsys='neuromag';
   cfg.method = 'fiducial';
   cfg.fiducial.nas    = fidu.data(2,:);
   cfg.fiducial.lpa    = fidu.data(3,:);
   cfg.fiducial.rpa    = fidu.data(1,:);
   real_mri=ft_volumerealign(cfg,mri);

   cfg                = [];
   cfg.keepintermediate = 'no';
   cfg.write          = 'no';
   cfg.name          = [folder_intermediate,'spmtmp'];
   segmentedmri   = ft_volumesegment(cfg, real_mri);

   cfg                = [];
   cfg.method = 'singleshell';
   hdm                = ft_prepare_headmodel(cfg,segmentedmri);
   hdm = ft_convert_units(hdm,'cm');

   template = load(fullfile('fieldtrip/template/sourcemodel/standard_sourcemodel3d10mm'));

   cfg                = [];
   cfg.grid.warpmni   = 'yes';
   cfg.grid.template  = template.sourcemodel;  % template_grid
   cfg.grid.nonlinear = 'yes';
   cfg.mri            = real_mri;
   cfg.grid.unit      ='cm';
   grid               = ft_prepare_sourcemodel(cfg);

   cfg = [];
   cfg.dataset = dataset;
   cfg.dftfilter = 'yes';
   cfg.trl = trl;
   cfg.channel = ['MEG***2','MEG***3',Info_et.(subj).(cond).(file).bad_meg];
   meg = ft_preprocessing(cfg);


   cfg = [];
   cfg.dataset = dataset;
   cfg.dftfilter = 'yes';
   cfg.trl = trl;
   cfg.channel = Info_et.(subj).(cond).(file).old_lfp_labels;
   cfg.montage = Info_et.(subj).(cond).(file).montage;
   lfp = ft_preprocessing(cfg);

  data = ft_appenddata([],meg,lfp);

   cfg = [];
   cfg.length = 1;
   cfg.overlap = 0.5;
   data_seg = ft_redefinetrial(cfg,data);


   centerfreq = 12;
   chan = ‘LFP-right-1-2A’;
   bandwidth = 2;

   cfg = [];
   cfg.method = 'mtmfft';
   cfg.output = 'powandcsd';
   cfg.foi = centerfreq;
   cfg.tapsmofrq = bandwidth;
   cfg.keeptrials = 'yes';
   freq = ft_freqanalysis(cfg,data_seg);

   cfg=[];
   cfg.method='dics';
   cfg.dics.lambda='5%';
   cfg.headmodel=hdm;
   cfg.sourcemodel=grid;
   cfg.frequency = centerfreq;
   cfg.reducerank=2;
   cfg.refchan = chan;
   source=ft_sourceanalysis(cfg,freq);
   source.pos = template.sourcemodel.pos;
   source.dim = template.sourcemodel.dim;

   [maxval, maxcohindx] = max(source.avg.coh);
   max_pos = source.pos(maxcohindx, :);

    cfg = [];
    cfg.parameter = 'coh';
    cfg.interpmethod        = 'nearest';
    it = ft_sourceinterpolate(cfg,source,p); % p

    cfg =  [];
    cfg.method = ‘ortho’;
    cfg.funparameter = 'coh';
    cfg.maskparameter = 'coh';
    ft_sourceplot(cfg,it);

Thanks and greetings,
Alexandra Steina<ft_2019.png><ft_april2020.png><ft_june2020.png><ft_november2020.png><ft_october2020.png>_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202


_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202




_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201105/550046f9/attachment.htm>

From jan.schoffelen at donders.ru.nl  Mon Nov  9 11:48:20 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Mon, 9 Nov 2020 10:48:20 +0000
Subject: [FieldTrip] MultiplotTFR
In-Reply-To: <CAFrxm=yRoAjgq3rDqi2YyeN_nei=BHsCAuOgpOaE7RifBf_Ucg@mail.gmail.com>
References: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
 <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>
 <BB11D07D-4EDB-4806-AFD8-37291B05F737@sport.uni-freiburg.de>
 <13D35B4A-FF44-410D-9EE6-3680C7C5C9DE@donders.ru.nl>
 <42F1EF94-7527-49B3-8424-6E4A9183082B@sport.uni-freiburg.de>
 <CAFrxm=yRoAjgq3rDqi2YyeN_nei=BHsCAuOgpOaE7RifBf_Ucg@mail.gmail.com>
Message-ID: <F272D9C6-CBA0-42E8-AD94-26D30B788436@donders.ru.nl>

Hi Patrick,

Thanks for reporting the issue! Indeed, it was a genuine ‘bug’ in the code, which caused the multiplot to be wrong. Long story short, when introducing some changes to the code, which were intended to make the set of functions that do data visualization in FT a bit more internally consistent, the ‘hold on’ commands disappeared from the multiplot functions by accident. This causes the individual channel TFRs (which are plotted one after the other) to replace each other in the figure, rather than to be placed within the same figure. Interestingly, that you identified this only now, because this code change was done a while ago.

We have now fixed it in the master branch of the FieldTrip repository. Once the most recent changes to the codebase survive our battery of test functions, the fix will be available in the release version very soon. Stay tuned, and thanks again for reporting.

Best wishes,
Jan-Mathijs


On 5 Nov 2020, at 09:01, Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>> wrote:

Hi Patrick,

I couldn't resist to try your example and on my Windows 10 computer, MATLAB 2019b, current FT version, your problem replicates.
All seems well with ft_topoplot_TFR (also interactive mode) and ft_singleplot_TFR, but ft_multiplotTFR behaves strangely indeed (attached).

Cheers,
Stephen

Op wo 4 nov. 2020 om 17:27 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Hi Jan-Mathijs,

I uploaded the code and the data to (https://github.com/PatrickWiegel/MultiplotTFR_plotting.git).

It would be interesting to see whether you experience the same problem with my data.

Best wishes,
Patrick



Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 04.11.2020 um 16:27 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

The only thing that can be done, is to try and reproduce the issue using your specific data. If this data is not too big, you can send it (off list), or even better: file an issue on github + a link to get the data, so that we (i.e. one of the FT developers) can have a look.

Best wishes,
Jan-Mathijs


On 4 Nov 2020, at 15:11, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Hi Jan-Mathijs,

thanks for the fast response. I don’t have any other matlab figures opened. I had a look in the history of the function but was not able to identify the problem.

However, if it working for you, then it is probably something related to my script/setup.

Best, Patrick

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 04.11.2020 um 14:45 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

It works fine for me, so I cannot reproduce your issue. Have you tried closing all open figures in MATLAB before calling ft_multiplotTFR?


Since this is the second e-mail today that explicitly mentions a ‘break’ in functionality, let me seize the opportunity to point to the possibility that users can already play a little bit more detective than just mentioning ‘it worked in version X and not anymore in version Y’. If you go to the github repository https://github.com/fieldtrip/fieldtrip you can actually check the changes to the code in more detail, by investigating the ‘history’ of the function. This already could give you a headstart in describing the problem, and would give people inclined to look into this with you some handles to work with.



Best wishes,

Jan-Mathijs



On 4 Nov 2020, at 14:21, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Dear community,

I am trying to use the function ft_multiplotTFR for time-frequency data generated by ft_frequanalyses (wavelet method) using the following code:

cfg = [];
cfg.layout = 'biosemi64.lay';
cfg.parameter = 'powspctrm';
cfg.xlim = [0 0.9];
ft_multiplotTFR(cfg, tfr_grandavg)

The result of the multiplot function is a single TF plot (see attachment) rather than 64 single channel TF plots arranged in the specified layout. It might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since the plot is correctly generated using older versions (e.g. fieldtrip-20200508). It would be great if anyone could test the function.

Best, Patrick

<multiplotTFR.jpg>
Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
<singleplot.jpg><multiplot.jpg>_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201109/860e27a7/attachment.htm>

From Alexandra.Steina at uni-duesseldorf.de  Mon Nov  9 12:56:02 2020
From: Alexandra.Steina at uni-duesseldorf.de (Alexandra Steina)
Date: Mon, 09 Nov 2020 12:56:02 +0100
Subject: [FieldTrip] PhD,
 postdoc and clinician scientist position available a in Duesseldorf
In-Reply-To: <94584fa9692f51d87afecde7e2a872d5@uni-duesseldorf.de>
References: <94584fa9692f51d87afecde7e2a872d5@uni-duesseldorf.de>
Message-ID: <92893678f1b68d99d6a15438d39c1e9e@uni-duesseldorf.de>

We are looking for a PhD student, a postdoc and a clinician scientist to
join our research project Improving deep brain stimulation through
artificial intelligence. The aim of the project is to generate
clinically relevant recommendations for DBS therapy based on
electrophysiological and imaging markers of movement disorders. More
info here:
https://www.uniklinik-duesseldorf.de/en/institute-of-clinical-neuroscience-and-medical-psychology/about-our-research/ag-hirschmann/dbs-ai.

In this project, you will collect data from movement disorder patients
using simultaneous MEG and intracranial recordings. In addition, we will
obtain kinematic data and anatomical images of the brain using MRI.
Besides neuroscientific measurements, data science plays an important
role. The project involves the creation of a scientific database and
sophisticated data analysis, using dedicated software tools for MEG/MRI
and the implementation and application of machine learning algorithms.

You will become part of a young, interdisciplinary team, providing
responsible supervision and room for creativity. You will become
familiar with various concepts and research tools and develop your own
ideas for getting new insights into the human brain and its alteration
in movement disorders. The Institute of Clinical Neuroscience and
Medical Psychology at the Heinrich Heine University Düsseldorf provides
everything you need: state-of-the-art technical equipment, including the
rare possibility to combine MEG with intracranial recordings, scientific
and clinical expertise in neuronal oscillations and movement disorders,
profound knowhow in data analysis and, last but not least, a very
friendly and open atmosphere.

The project is supported by a five-year grant of the Brunhilde Moll
Foundation to Prof. Alfons Schnitzler and Dr. Jan Hirschmann. We offer
fixed-term contracts for three years initially, with the possibility of
prolongation. The positions are available from 1st of January 2021 and
will be open until filled. Payment accords to the regulations for the
German public sector (Tarifvertrag für den öffentlichen Dienst der
Länder/Tarifvertrag für Ärztinnen und Ärzte an Universitätskliniken).

The applications should include a statement of research interests and
reasons for applying to the project, a curriculum vitae including a list
publications, a certificate of the PhD and/or Master’s degree, a copy of
the master’s thesis and grades of Master’s level studies, and the names
and e-mail addresses of two referees. Please send applications to
Jan.Hirschmann at med.uni-duesseldorf.de

Doctoral researchers
The doctoral researcher will conduct neuroscientific experiments,
analyze and present the data, and prepare publications under
supervision, resulting in a PhD thesis.
Requirements
•       Master of Science in the natural sciences, computer science or
psychology
•       Intrinsic motivation and a passion for brain research
•       First experience and a profound interest in scientific data 
analysis
and programming (preferably Python or Matlab)
•       First experience in at least one of the following: M/EEG, 
machine
learning/AI, local field potential recordings, motion tracking, MRI,
scientific databases

Postdoctoral researchers
The postdoctoral researcher conducts experiments and data analyses
independently, contributes own ideas, prepares publications and supports
the group leader in supervision and organizational tasks.
Requirements
•       PhD in the natural sciences, computer science, engineering or
psychology
•       Intrinsic motivation and a passion for brain research
•       Expertise in scientific data analysis and programming 
(preferably
Python or Matlab)
•       Expertise in at least two of the following, evidenced by first 
author
publications in peer-reviewed, academic journals: M/EEG, machine
learning/AI, local field potential recordings, motion tracking, MRI,
scientific databases
•       Experience in preparing scientific publications and in 
presenting
•       Knowledge about movement disorders and deep brain stimulation
(optional)

Clinician Scientist
The clinician scientists works on his or her own scientific project and
takes care of all clinical aspects of the research project, such as DBS
stimulator programming, quantification of symptoms and medical
supervision of study participants. A combination of scientific and
clinical work is possible.
Requirements
•       License to practice medicine in Germany
•       Fluent in German and English
•       At least 1 year of training in neurology
•       Passion for clinical neuroscience and interest in academic 
career
•       Knowledge in movement disorders and deep brain stimulation
•       Skills in scientific data analysis, or willingness to learn



From patrick.wiegel at sport.uni-freiburg.de  Mon Nov  9 14:37:36 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Mon, 9 Nov 2020 13:37:36 +0000
Subject: [FieldTrip] MultiplotTFR
In-Reply-To: <F272D9C6-CBA0-42E8-AD94-26D30B788436@donders.ru.nl>
References: <6568B89A-C9BE-4346-81AF-BEE984C3DAC1@sport.uni-freiburg.de>
 <F3757E91-269C-472F-B865-9375043C972C@donders.ru.nl>
 <BB11D07D-4EDB-4806-AFD8-37291B05F737@sport.uni-freiburg.de>
 <13D35B4A-FF44-410D-9EE6-3680C7C5C9DE@donders.ru.nl>
 <42F1EF94-7527-49B3-8424-6E4A9183082B@sport.uni-freiburg.de>
 <CAFrxm=yRoAjgq3rDqi2YyeN_nei=BHsCAuOgpOaE7RifBf_Ucg@mail.gmail.com>
 <F272D9C6-CBA0-42E8-AD94-26D30B788436@donders.ru.nl>
Message-ID: <451280F9-8AF6-40FA-80B2-C940AFD36E41@sport.uni-freiburg.de>

Hi Jan Mathijs,

thanks for the quick fix and your response. And good that it was „only“ the missing hold on command. Then it also makes sense that only one TFR survived in the end.

All the best,
Patrick


Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

Am 09.11.2020 um 11:48 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

Thanks for reporting the issue! Indeed, it was a genuine ‘bug’ in the code, which caused the multiplot to be wrong. Long story short, when introducing some changes to the code, which were intended to make the set of functions that do data visualization in FT a bit more internally consistent, the ‘hold on’ commands disappeared from the multiplot functions by accident. This causes the individual channel TFRs (which are plotted one after the other) to replace each other in the figure, rather than to be placed within the same figure. Interestingly, that you identified this only now, because this code change was done a while ago.

We have now fixed it in the master branch of the FieldTrip repository. Once the most recent changes to the codebase survive our battery of test functions, the fix will be available in the release version very soon. Stay tuned, and thanks again for reporting.

Best wishes,
Jan-Mathijs


On 5 Nov 2020, at 09:01, Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>> wrote:

Hi Patrick,

I couldn't resist to try your example and on my Windows 10 computer, MATLAB 2019b, current FT version, your problem replicates.
All seems well with ft_topoplot_TFR (also interactive mode) and ft_singleplot_TFR, but ft_multiplotTFR behaves strangely indeed (attached).

Cheers,
Stephen

Op wo 4 nov. 2020 om 17:27 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Hi Jan-Mathijs,

I uploaded the code and the data to (https://github.com/PatrickWiegel/MultiplotTFR_plotting.git).

It would be interesting to see whether you experience the same problem with my data.

Best wishes,
Patrick



Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 04.11.2020 um 16:27 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

The only thing that can be done, is to try and reproduce the issue using your specific data. If this data is not too big, you can send it (off list), or even better: file an issue on github + a link to get the data, so that we (i.e. one of the FT developers) can have a look.

Best wishes,
Jan-Mathijs


On 4 Nov 2020, at 15:11, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Hi Jan-Mathijs,

thanks for the fast response. I don’t have any other matlab figures opened. I had a look in the history of the function but was not able to identify the problem.

However, if it working for you, then it is probably something related to my script/setup.

Best, Patrick

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 04.11.2020 um 14:45 schrieb Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl<mailto:jan.schoffelen at donders.ru.nl>>:

Hi Patrick,

It works fine for me, so I cannot reproduce your issue. Have you tried closing all open figures in MATLAB before calling ft_multiplotTFR?


Since this is the second e-mail today that explicitly mentions a ‘break’ in functionality, let me seize the opportunity to point to the possibility that users can already play a little bit more detective than just mentioning ‘it worked in version X and not anymore in version Y’. If you go to the github repository https://github.com/fieldtrip/fieldtrip you can actually check the changes to the code in more detail, by investigating the ‘history’ of the function. This already could give you a headstart in describing the problem, and would give people inclined to look into this with you some handles to work with.



Best wishes,

Jan-Mathijs



On 4 Nov 2020, at 14:21, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>> wrote:

Dear community,

I am trying to use the function ft_multiplotTFR for time-frequency data generated by ft_frequanalyses (wavelet method) using the following code:

cfg = [];
cfg.layout = 'biosemi64.lay';
cfg.parameter = 'powspctrm';
cfg.xlim = [0 0.9];
ft_multiplotTFR(cfg, tfr_grandavg)

The result of the multiplot function is a single TF plot (see attachment) rather than 64 single channel TF plots arranged in the specified layout. It might be a bug in the newer fieldtrip versions (fieldtrip-20201103) since the plot is correctly generated using older versions (e.g. fieldtrip-20200508). It would be great if anyone could test the function.

Best, Patrick

<multiplotTFR.jpg>
Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
<singleplot.jpg><multiplot.jpg>_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201109/e871054b/attachment.htm>

From pnc9 at georgetown.edu  Wed Nov 11 04:12:38 2020
From: pnc9 at georgetown.edu (Philip Cho)
Date: Tue, 10 Nov 2020 22:12:38 -0500
Subject: [FieldTrip] matrix multiplication error in ft_sourcedescriptives
Message-ID: <CAFk21gjH4eshOqngLoazr+886DUUUF2LFOJHs163HWKFHRw06g@mail.gmail.com>

Hello Fieldtrip Community,

I'm a new Fieldtrip user, and I'd appreciate any help I can receive. I'm
currently working on MEG source reconstruction of an averaged event-related
field from a single subject. I believe I have completed most of the steps,
and I'm able to view my results at a given time using ft_plot_mesh. What I
want to do now is view a movie of the activity, but for reasons I do not
fully understand, I am having trouble obtaining the descriptive parameters
of my results, which I believe is a parameter I must feed into
ft_sourcemovie.

In particular, when I run ft_sourcedescriptives, I obtain the following
error:

Error using  *
Incorrect dimensions for matrix multiplication. Check that the number of
columns in the first matrix matches the number of rows in the second
matrix. To perform elementwise multiplication, use
'.*'.

Error in ft_sourcedescriptives (line 619)
        source.avg.phi(diplop) = source.avg.ori{diplop}*nrm(diplop,:)';

Error in mous_sourcemovie (line 7)
sd  = ft_sourcedescriptives(cfg,source_allWords);



It looks like source.avg.ori{diplop}  is a 1x2 array, while nrm(diplop,:)'
is a 3x1 array. Please let me know if there is a possible fix to this
error. If any additional information is needed, I would also be happy to
send it out. Any advice would be deeply appreciated.


Best,
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201110/714834b2/attachment.htm>

From jan.schoffelen at donders.ru.nl  Wed Nov 11 09:32:21 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Wed, 11 Nov 2020 08:32:21 +0000
Subject: [FieldTrip] matrix multiplication error in ft_sourcedescriptives
In-Reply-To: <CAFk21gjH4eshOqngLoazr+886DUUUF2LFOJHs163HWKFHRw06g@mail.gmail.com>
References: <CAFk21gjH4eshOqngLoazr+886DUUUF2LFOJHs163HWKFHRw06g@mail.gmail.com>
Message-ID: <331B8399-639C-4072-97B6-2667335E6F25@donders.ru.nl>

Hi Philip,

It could be that your error is caused by the fact that you computed your forward model (ft_prepare_leadfield), using cfg.backproject = ’no’. Consequently, the dipole specific leadfields are of dimensionality Nchan x 2, rather than the ’normal’, Nchan x 3. Some of the derived measures obtained from ft_sourceanlaysis (using the Nchan x 2 leadfields) then have dimensions that are 2 x something, or something x 2, rather than the more conventional … x 3. One of these derived measures might be the ‘ori’ field, that ft_sourcedescriptives complains about. Long story short, the cfg.backproject = ’no’ option in ft_prepare_leadfield is apparently incompatible with the computation of the ‘phi’ variable in ft_sourcedescriptives.
The phi variable seems to quantify the (cosine of) the angle between the orientation of the reconstructed source, and the local normal of the cortical sheet. With un-backprojected (and rank reduced) leadfields, the (implicit) axes of the coordinate system that spans the plane in which the leadfield lives are incompatible with the implicit axes of the coordinate system that spans the 3D space in which the cortex lives. In other words, the issue is not only an incompatibility between the numbers 2 and 3, but it goes a bit deeper than that.

Assuming that my diagnosis is correct, the short term solution for you would be to re-run the source reconstruction pipeline (including the ft_prepare_leadfield step with cfg.backproject = ‘yes’).
The somewhat longer term solution would be to implement an error check (dispreferred because it’s more like a band aid), or impose some stricter consistency between the assumed coordinate systems of the different attributes of individual dipoles.

Best wishes,
Jan-Mathijs



On 11 Nov 2020, at 04:12, Philip Cho <pnc9 at georgetown.edu<mailto:pnc9 at georgetown.edu>> wrote:

Hello Fieldtrip Community,

I'm a new Fieldtrip user, and I'd appreciate any help I can receive. I'm currently working on MEG source reconstruction of an averaged event-related field from a single subject. I believe I have completed most of the steps, and I'm able to view my results at a given time using ft_plot_mesh. What I want to do now is view a movie of the activity, but for reasons I do not fully understand, I am having trouble obtaining the descriptive parameters of my results, which I believe is a parameter I must feed into ft_sourcemovie.

In particular, when I run ft_sourcedescriptives, I obtain the following error:

Error using  *
Incorrect dimensions for matrix multiplication. Check that the number of columns in the first matrix matches the number of rows in the second matrix. To perform elementwise multiplication, use
'.*'.

Error in ft_sourcedescriptives (line 619)
        source.avg.phi(diplop) = source.avg.ori{diplop}*nrm(diplop,:)';

Error in mous_sourcemovie (line 7)
sd  = ft_sourcedescriptives(cfg,source_allWords);



It looks like source.avg.ori{diplop}  is a 1x2 array, while nrm(diplop,:)' is a 3x1 array. Please let me know if there is a possible fix to this error. If any additional information is needed, I would also be happy to send it out. Any advice would be deeply appreciated.


Best,
Philip
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201111/8aa9a280/attachment.htm>

From Cecilia.Mazzetti at unige.ch  Wed Nov 11 18:37:55 2020
From: Cecilia.Mazzetti at unige.ch (=?iso-8859-1?Q?C=E9cilia_Mazzetti?=)
Date: Wed, 11 Nov 2020 17:37:55 +0000
Subject: [FieldTrip] Source statistics after applying a priori mask on
 gridpoints (or atlas?)
Message-ID: <15b2e658262d4214918a8ef9823f1cd6@unige.ch>

Hello fieldtrippers,

Have a question regarding ft_sourcestatistics.

I have a priori defined mask around central gridpoints which i would like to apply before running source statistics over two groups/conditions.

Is there a way/configuration option to do so in fieldtrip? Does it make sense or that is actually not commonly done? (if so why?)


another option could be to use an atlas (although it'd be more precise to be able to apply a mask based on gridpoints in my case)



Thanks in advance for sharing your wisdom!


Cecilia


Cecilia Mazzetti, Postdoc Researcher

Faculté de médecine de l'Université de Genève

Chemin des Mines 9, 1202 Genève

+41 2237 90992
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201111/2eff159e/attachment.htm>

From liang134 at mail.chapman.edu  Thu Nov 12 01:38:06 2020
From: liang134 at mail.chapman.edu (Andy Liang)
Date: Wed, 11 Nov 2020 16:38:06 -0800
Subject: [FieldTrip] Output dimension of eLORETA
Message-ID: <CAMmeW0G4GRVQaS8UAeb_oz2a7Vw0LyvcBCpDitmsHBqhNfnJvA@mail.gmail.com>

Dear all fieldtrip experts,

Hope all is well. I am a PhD student working on my thesis applying source
localization to some MEG data. I am now stuck at a technical problem that I
am a bit confused and wasn't able to find a straightforward answer. Let me
know if you have a quick answer for this:

In fieldtrip, I can input a time series (the source data) or the
frequency power of a particular frequency band (eg. alpha band after
ft_freqanalysis) to ft_sourceanalysis with eLORETA method and get the
source output. However, the structure of the output is a little bit
confusing. I would assume that if I am inputting a time series with
n_channels x n_timepoints, I will get an output of also a time series, with
dimension n_source_location x n_timepoints. But in reality, I am getting an
output of n_source_location x 1 no matter what the input is. It seems like
eLORETA takes the time series and produces a summarized score for each of
the source points. I have done quite a bit of research on these algorithms
and I think eLORETA is similar to wMNE which takes in a time series and
outputs a time series except that it adopts a different normalization
function.

Am I missing any parameters that I need to specify or I am just
misunderstanding eLORETA? If you can point me to any resource, it will be
much appreciated.

Thank you very much!
Andy Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201111/41b415ff/attachment.htm>

From patrick.wiegel at sport.uni-freiburg.de  Fri Nov 13 11:20:11 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Fri, 13 Nov 2020 10:20:11 +0000
Subject: [FieldTrip] Why are time-frequency results so much different from
 Beamformer source localization?
Message-ID: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>

Dear Field-trip community,

I am working on EEG data from a motor learning task. in the first part of my analysis, I performed a time-frequency analysis (Morlet wavelet method) and cluster-based permutation test. I compared two different conditions (correct & incorrect movements) within subjects and found a significant difference in the beta band (20-35 Hz) when subjects were provided with feedback. I attached the topographical plot from one subject that illustrates the difference between the conditions at the selected time point and frequency (dif_morlet). As you can see, beta power was higher in one condition in lateral frontal electrodes.

Now, I would like to better spatially locate the effect for this single subject. For this purpose, I followed the Beamformer tutorial on the website. In the first step, I selected the raw data of interest (at the time where the effect was seen) and performed frequency analyses for the 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft). There is an apparent difference between dif_morlet and dif_mtmfft and I am wondering why this is the case? One apparent reason is that the time-frequency data were baseline corrected and the frequency data from mtmfft not.

Using the power and CSD data from mtmfft, I performed the source analysis with a standard MRI and head model. The source was located in the left hemisphere (source plot), which is in stark contrast to the time-frequency data (dif_morlet). I am aware that the source analysis is based on a lot of assumptions (conductivity etc.) that influence the calculations but it is very difficult to make sense of such discrepancy.
Maybe it is necessary to also baseline correct the mtmfft data before inputting them to the source analysis? Or doing the contrasting source localization betwee a single condition and the corresponding baseline data before contrasting the 2 conditions?

I am providing all necessary files and scripts (TF_analysis & BEAMFORMER) if anyone is interested to reproduce the results that I am showing and reporting for this single subject (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).

I would appreciate any help and discussion on that.

All the best,
Patrick





Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201113/f0ac079f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dif_morlet.eps
Type: application/postscript
Size: 85673 bytes
Desc: dif_morlet.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201113/f0ac079f/attachment.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dif_mtmfft.eps
Type: application/postscript
Size: 71334 bytes
Desc: dif_mtmfft.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201113/f0ac079f/attachment-0001.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sourceplot.eps
Type: application/postscript
Size: 117081 bytes
Desc: sourceplot.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201113/f0ac079f/attachment-0002.eps>

From tzvetan.popov at uni-konstanz.de  Fri Nov 13 12:31:41 2020
From: tzvetan.popov at uni-konstanz.de (Tzvetan Popov)
Date: Fri, 13 Nov 2020 12:31:41 +0100
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
Message-ID: <7A84C185-397B-4674-9A39-F5C70FB9F713@uni-konstanz.de>

Dear Patrick,

As you have already noticed the answer to your question is because you do the different things. I assume that what you did in the wavelet case was the following: you performed tf-decomposition on the epochs (correct and incorrect), applied a baseline correction and contrasted the baselined data. After subtraction of the two baselined conditions you found your effect in beta. If this is correct, in order to reproduce the same approach in source space I suggest you do the following.

1. Within each condition select the data into pre and post intervals of interest. For example, say your effect is in the latency from .5 to 1 sec after stimulus onset. Select for each condition a pre period (-1 to -.5) and post period (.5 to 1sec).
2. Append all the data using ft_appenddata and call ft_sourceanalysis as you did so far but with cfg.dics.keepfilter = ‘yes’;
3. Make 4 additional calls to ft_sourceanalysis for the pre and post intervals of the 2 conditions. Key here is to pass on the filters computed in the 2nd step by specifying cfg.sourcemodel.filter = outputfrom2ndstep.filter;
Why and how you should do this is further explained here https://www.fieldtriptoolbox.org/example/common_filters_in_beamforming/ <https://www.fieldtriptoolbox.org/example/common_filters_in_beamforming/>
4. Make a contrast baseline vs. Poststim activity per condition. This way you end up with two source maps, one for correct and one for incorrect. Use ft_math to compute a difference score and plot the result. 
The left-right flip has to do with the coordinates of the MR you are using. One easy fix is to follow the steps in the beamforming tutorial, i.e. ft_volumenormalise.

Good luck,
Tzvetan


> On 13 Nov 2020, at 11:20, Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de> wrote:
> 
> Dear Field-trip community,
> 
> I am working on EEG data from a motor learning task. in the first part of my analysis, I performed a time-frequency analysis (Morlet wavelet method) and cluster-based permutation test. I compared two different conditions (correct & incorrect movements) within subjects and found a significant difference in the beta band (20-35 Hz) when subjects were provided with feedback. I attached the topographical plot from one subject that illustrates the difference between the conditions at the selected time point and frequency (dif_morlet). As you can see, beta power was higher in one condition in lateral frontal electrodes.
> 
> Now, I would like to better spatially locate the effect for this single subject. For this purpose, I followed the Beamformer tutorial on the website. In the first step, I selected the raw data of interest (at the time where the effect was seen) and performed frequency analyses for the 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft). There is an apparent difference between dif_morlet and dif_mtmfft and I am wondering why this is the case? One apparent reason is that the time-frequency data were baseline corrected and the frequency data from mtmfft not.
> 
> Using the power and CSD data from mtmfft, I performed the source analysis with a standard MRI and head model. The source was located in the left hemisphere (source plot), which is in stark contrast to the time-frequency data (dif_morlet). I am aware that the source analysis is based on a lot of assumptions (conductivity etc.) that influence the calculations but it is very difficult to make sense of such discrepancy. 
> Maybe it is necessary to also baseline correct the mtmfft data before inputting them to the source analysis? Or doing the contrasting source localization betwee a single condition and the corresponding baseline data before contrasting the 2 conditions? 
> 
> I am providing all necessary files and scripts (TF_analysis & BEAMFORMER) if anyone is interested to reproduce the results that I am showing and reporting for this single subject (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation <https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation>). 
> 
> I would appreciate any help and discussion on that.
> 
> All the best,
> Patrick
> 
> 
> 
> 
> 
> Patrick Wiegel
> Department of Sport and Sport Science
> 
> University of Freiburg 
> Sandfangweg 4
> 79117 Freiburg i. Br . 
> 
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de <mailto:patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
> 
> <dif_morlet.eps><dif_mtmfft.eps><sourceplot.eps>_______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201113/2a66423b/attachment.htm>

From tzvetan.popov at uni-konstanz.de  Fri Nov 13 12:43:53 2020
From: tzvetan.popov at uni-konstanz.de (Tzvetan Popov)
Date: Fri, 13 Nov 2020 12:43:53 +0100
Subject: [FieldTrip] Source statistics after applying a priori mask on
 gridpoints (or atlas?)
In-Reply-To: <15b2e658262d4214918a8ef9823f1cd6@unige.ch>
References: <15b2e658262d4214918a8ef9823f1cd6@unige.ch>
Message-ID: <8876853C-D3DD-4F3E-AD4B-4C359DED3844@uni-konstanz.de>

Dear Cecilia,

> Hello fieldtrippers,
> Have a question regarding ft_sourcestatistics.
> I have a priori defined mask around central gridpoints which i would like to apply before running source statistics over two groups/conditions.
> Is there a way/configuration option to do so in fieldtrip?
I am not aware of it. 
> Does it make sense or that is actually not commonly done?
Whether or not it makes sense is up to you to narrate. Indeed it is not commonly done.
> (if so why?)
The goal of the statistic machinery as implemented in FieldTrip (both sensor and source level) is to provide you with a principled decision whether or not the data from 2 or more conditions is exchangeable. If you happen to find a cluster of sensors/voxels regardless of where in the brain, you reject this H0. Thats it. The machinery does not tell you much about where in the brain, time and freq etc. 

In your case, I would simply extract the values from your mask of interest and apply Bonferroni correction. Wouldn’t that suffice?

> 
> another option could be to use an atlas (although it'd be more precise to be able to apply a mask based on gridpoints in my case)
As explained here https://www.fieldtriptoolbox.org/tutorial/salzburg/#compute-the-leadfield <https://www.fieldtriptoolbox.org/tutorial/salzburg/#compute-the-leadfield> you can use your binary mask to constrain your source model. Then you use grand averaging and source statistic as you deem appropriate. 

Good luck,
Tzvetan
 
> 
> 
> Thanks in advance for sharing your wisdom!
> 
> Cecilia
> 
> Cecilia Mazzetti, Postdoc Researcher
> Faculté de médecine de l'Université de Genève
> Chemin des Mines 9, 1202 Genève
> +41 2237 90992
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip <https://mailman.science.ru.nl/mailman/listinfo/fieldtrip>
> https://doi.org/10.1371/journal.pcbi.1002202 <https://doi.org/10.1371/journal.pcbi.1002202>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201113/80485d6b/attachment.htm>

From stephen.whitmarsh at gmail.com  Fri Nov 13 12:48:26 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Fri, 13 Nov 2020 12:48:26 +0100
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
Message-ID: <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>

Hi Patrick, (and Tzvetan - who responded in the meantime),

I agree that you should start with a good correspondence between your
initial results (wavelets), and the power difference you are trying to
localize (with mtmfft).

Wavelets and fft methods can result in very similar - practically identical
- results, but that depends on a number of parameters, especially
concerning frequency-smoothing; Wavelets are typically defined in terms of
nr. of cycles, while fft methods are defined in terms of time-windows.
Wavelets defined in nr. of cycles will have a decreasing time-windows with
increasing frequency, while with mtmfft time windows will remain the same.
Because of this, frequency smoothing will increase with frequency with
wavelets, and stay the same with a constant time window. Of course, you can
make the fft time window frequency-dependent, as is described in the
frequency-analyses tutorial, to make them more comparable. Secondly, the
fft method allows you to specify frequency smoothing when you use Sleppian
multitapers (cfg.taper = 'dpss'). To be clear, you should be able to
recognize these differences in frequency smoothing/resolution when looking
at the different TFR plots. Currently they look too different, probably
because of something else (baseline?) than a wavelet-fft difference.

I would advise making a 'full' TFR with mtmfft similar as your wavelet
results so that you can properly compare them. This allows you to also set
the best parameters for smoothing/timeperiods. In fact, you can use the
multitaper approach to more accurately extract the power in a certain
frequency band. Only then compare the topo's, and only then do the
beamformer, so you will pick up any unexpected results.

Because of different contrasts/baseline correction, I cannot compare the
topo's / beamformer results.

Bon courage,
Stephen









Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <
patrick.wiegel at sport.uni-freiburg.de>:

> Dear Field-trip community,
>
> I am working on EEG data from a motor learning task. in the first part of
> my analysis, I performed a time-frequency analysis (Morlet wavelet method)
> and cluster-based permutation test. I compared two different conditions
> (correct & incorrect movements) within subjects and found a significant
> difference in the beta band (20-35 Hz) when subjects were provided with
> feedback. I attached the topographical plot from one subject that
> illustrates the difference between the conditions at the selected time
> point and frequency (dif_morlet). As you can see, beta power was higher in
> one condition in lateral frontal electrodes.
>
> Now, I would like to better spatially locate the effect for this single
> subject. For this purpose, I followed the Beamformer tutorial on the
> website. In the first step, I selected the raw data of interest (at the
> time where the effect was seen) and performed frequency analyses for the
> 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft).
> There is an apparent difference between dif_morlet and dif_mtmfft and I am
> wondering why this is the case? One apparent reason is that the
> time-frequency data were baseline corrected and the frequency data from
> mtmfft not.
>
> Using the power and CSD data from mtmfft, I performed the source analysis
> with a standard MRI and head model. The source was located in the left
> hemisphere (source plot), which is in stark contrast to the time-frequency
> data (dif_morlet). I am aware that the source analysis is based on a lot of
> assumptions (conductivity etc.) that influence the calculations but it is
> very difficult to make sense of such discrepancy.
> Maybe it is necessary to also baseline correct the mtmfft data before
> inputting them to the source analysis? Or doing the contrasting source
> localization betwee a single condition and the corresponding baseline data
> before contrasting the 2 conditions?
>
> I am providing all necessary files and scripts (TF_analysis & BEAMFORMER)
> if anyone is interested to reproduce the results that I am showing and
> reporting for this single subject (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>
> I would appreciate any help and discussion on that.
>
> All the best,
> Patrick
>
>
>
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201113/fa0774ac/attachment.htm>

From Cecilia.Mazzetti at unige.ch  Sat Nov 14 15:44:50 2020
From: Cecilia.Mazzetti at unige.ch (=?Windows-1252?Q?C=E9cilia_Mazzetti?=)
Date: Sat, 14 Nov 2020 14:44:50 +0000
Subject: [FieldTrip] Source statistics after applying a priori mask on
 gridpoints (or atlas?)
In-Reply-To: <8876853C-D3DD-4F3E-AD4B-4C359DED3844@uni-konstanz.de>
References: <15b2e658262d4214918a8ef9823f1cd6@unige.ch>,
 <8876853C-D3DD-4F3E-AD4B-4C359DED3844@uni-konstanz.de>
Message-ID: <274d60755d864a01ad5fb8a7223078a0@unige.ch>

Thanks Tzvetan!

Yes, applying boferrroni to the extracted masks would actually be good enough I think..

Out of curiosity, do you think it would be ok to set all the power values outside the mask(defined grid of interest) to nan and perform source statistics as common with the manually masked power data for all conditions?


Thanks again for the help!!


Cecilia


Cecilia Mazzetti, Postdoc Researcher

Faculté de médecine de l'Université de Genève

Chemin des Mines 9, 1202 Genève

+41 2237 90992

________________________________
From: fieldtrip <fieldtrip-bounces at science.ru.nl> on behalf of Tzvetan Popov <tzvetan.popov at uni-konstanz.de>
Sent: Friday, November 13, 2020 12:43:53 PM
To: FieldTrip discussion list
Subject: Re: [FieldTrip] Source statistics after applying a priori mask on gridpoints (or atlas?)

Dear Cecilia,

Hello fieldtrippers,
Have a question regarding ft_sourcestatistics.
I have a priori defined mask around central gridpoints which i would like to apply before running source statistics over two groups/conditions.
Is there a way/configuration option to do so in fieldtrip?
I am not aware of it.
Does it make sense or that is actually not commonly done?
Whether or not it makes sense is up to you to narrate. Indeed it is not commonly done.
(if so why?)
The goal of the statistic machinery as implemented in FieldTrip (both sensor and source level) is to provide you with a principled decision whether or not the data from 2 or more conditions is exchangeable. If you happen to find a cluster of sensors/voxels regardless of where in the brain, you reject this H0. Thats it. The machinery does not tell you much about where in the brain, time and freq etc.

In your case, I would simply extract the values from your mask of interest and apply Bonferroni correction. Wouldn’t that suffice?


another option could be to use an atlas (although it'd be more precise to be able to apply a mask based on gridpoints in my case)
As explained here https://www.fieldtriptoolbox.org/tutorial/salzburg/#compute-the-leadfield you can use your binary mask to constrain your source model. Then you use grand averaging and source statistic as you deem appropriate.

Good luck,
Tzvetan



Thanks in advance for sharing your wisdom!

Cecilia

Cecilia Mazzetti, Postdoc Researcher
Faculté de médecine de l'Université de Genève
Chemin des Mines 9, 1202 Genève
+41 2237 90992
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201114/625d49b2/attachment.htm>

From pnc9 at georgetown.edu  Sat Nov 14 22:04:39 2020
From: pnc9 at georgetown.edu (Philip Cho)
Date: Sat, 14 Nov 2020 16:04:39 -0500
Subject: [FieldTrip] matrix multiplication error in ft_sourcedescriptives
In-Reply-To: <331B8399-639C-4072-97B6-2667335E6F25@donders.ru.nl>
References: <CAFk21gjH4eshOqngLoazr+886DUUUF2LFOJHs163HWKFHRw06g@mail.gmail.com>
 <331B8399-639C-4072-97B6-2667335E6F25@donders.ru.nl>
Message-ID: <CAFk21ghyCO1wk9Hn9WFa4JWVwYQTgc0t3zv0GROUrbFy742MUA@mail.gmail.com>

Hi Jan-Mathijs,

Thank you so much for your help. That did seem to fix the bulk of my
problem, and I'm now able to view the movie. That being said, I am somewhat
surprised by this fix. I had never explicitly written cfg.backproject =
'no' in my previous code, and the description of the ft_prepare_leadfield
function claims that the default setting for cfg.backproject is 'yes'. I
strangely have to explicitly write cfg.backproject = 'yes' in my forward
model script. Is this expected?

Additionally, although I'm now able to view the movies, I am getting a
warning claiming

Warning could not determine dimord of "noisecov" in:
 time: [1×1020 double]
         cfg: [1×1 struct]
      inside: [8196×1 logical]
         pos: [8196×3 double]
         tri: [16384×3 int32]
         mom: {8196×1 cell}
         pow: [8196×1020 double]
    noisecov: {8196×1 cell}
         phi: [8196×1 double]
         ori: {8196×1 cell}
       noise: [8196×1 double]

If any input can be given as to what this might mean, it would also be
greatly appreciated. I suspect that this should be the last obstacle I face
with this analysis. Thank you!

Best,
Philip

On Wed, Nov 11, 2020 at 3:43 AM Schoffelen, J.M. (Jan Mathijs) <
jan.schoffelen at donders.ru.nl> wrote:

> Hi Philip,
>
> It could be that your error is caused by the fact that you computed your
> forward model (ft_prepare_leadfield), using cfg.backproject = ’no’.
> Consequently, the dipole specific leadfields are of dimensionality Nchan x
> 2, rather than the ’normal’, Nchan x 3. Some of the derived measures
> obtained from ft_sourceanlaysis (using the Nchan x 2 leadfields) then have
> dimensions that are 2 x something, or something x 2, rather than the more
> conventional … x 3. One of these derived measures might be the ‘ori’ field,
> that ft_sourcedescriptives complains about. Long story short, the
> cfg.backproject = ’no’ option in ft_prepare_leadfield is apparently
> incompatible with the computation of the ‘phi’ variable in
> ft_sourcedescriptives.
> The phi variable seems to quantify the (cosine of) the angle between the
> orientation of the reconstructed source, and the local normal of the
> cortical sheet. With un-backprojected (and rank reduced) leadfields, the
> (implicit) axes of the coordinate system that spans the plane in which the
> leadfield lives are incompatible with the implicit axes of the coordinate
> system that spans the 3D space in which the cortex lives. In other words,
> the issue is not only an incompatibility between the numbers 2 and 3, but
> it goes a bit deeper than that.
>
> Assuming that my diagnosis is correct, the short term solution for you
> would be to re-run the source reconstruction pipeline (including the
> ft_prepare_leadfield step with cfg.backproject = ‘yes’).
> The somewhat longer term solution would be to implement an error check
> (dispreferred because it’s more like a band aid), or impose some stricter
> consistency between the assumed coordinate systems of the different
> attributes of individual dipoles.
>
> Best wishes,
> Jan-Mathijs
>
>
>
> On 11 Nov 2020, at 04:12, Philip Cho <pnc9 at georgetown.edu> wrote:
>
> Hello Fieldtrip Community,
>
> I'm a new Fieldtrip user, and I'd appreciate any help I can receive. I'm
> currently working on MEG source reconstruction of an averaged event-related
> field from a single subject. I believe I have completed most of the steps,
> and I'm able to view my results at a given time using ft_plot_mesh. What I
> want to do now is view a movie of the activity, but for reasons I do not
> fully understand, I am having trouble obtaining the descriptive parameters
> of my results, which I believe is a parameter I must feed into
> ft_sourcemovie.
>
> In particular, when I run ft_sourcedescriptives, I obtain the following
> error:
>
> Error using  *
> Incorrect dimensions for matrix multiplication. Check that the number of
> columns in the first matrix matches the number of rows in the second
> matrix. To perform elementwise multiplication, use
> '.*'.
>
> Error in ft_sourcedescriptives (line 619)
>         source.avg.phi(diplop) = source.avg.ori{diplop}*nrm(diplop,:)';
>
> Error in mous_sourcemovie (line 7)
> sd  = ft_sourcedescriptives(cfg,source_allWords);
>
>
>
> It looks like source.avg.ori{diplop}  is a 1x2 array, while nrm(diplop,:)'
> is a 3x1 array. Please let me know if there is a possible fix to this
> error. If any additional information is needed, I would also be happy to
> send it out. Any advice would be deeply appreciated.
>
>
> Best,
> Philip
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201114/90463bf0/attachment.htm>

From erfan1994vi at gmail.com  Tue Nov 17 15:23:59 2020
From: erfan1994vi at gmail.com (Erfan Vi)
Date: Tue, 17 Nov 2020 17:53:59 +0330
Subject: [FieldTrip] Specifying the ROI of reconstructed time series of
 brain sources
Message-ID: <CAOY-aAuZ1JEPsrZQvA4fmxA_mWQXRdrgotzCy=_PSq0Cw9RaFA@mail.gmail.com>

Subject: Specifying the ROI of reconstructed time series of brain sources
Dear community,
My name is Erfan Vajdi and I am working in the Biomedical lab in Tehran,
Iran on brain network connectivity measurement. Currently, I am analyzing
data of EEG and MEG.
In solving the inverse problem of MEG and EEG, I used the Multiple Sparse
Prior (MSP) technique to reconstruct the time series of the brain sources.
I have reconstructed the time series of brain sources by the SPM toolbox.
8196 dipoles were reconstructed.
Now I want to determine the anatomical regions of the dipoles as the
Regions of Interests (ROIs) by registering the AAL atlas (
http://www.fieldtriptoolbox.org/template/atlas) onto the patient's MRI. But
I don't have any idea about how I can do that. I couldn't find any useful
documents. Can someone tell me what to do? Or introduce a related link?
Best,
Erfan Vajdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201117/413d3b1f/attachment.htm>

From Alexander.Aabedi at ucsf.edu  Tue Nov 17 20:00:57 2020
From: Alexander.Aabedi at ucsf.edu (Aabedi, Alexander)
Date: Tue, 17 Nov 2020 19:00:57 +0000
Subject: [FieldTrip] Unable to mask sub-threshold statistics when plotting
 with ft_sourceplot
Message-ID: <BYAPR05MB5718AC6A410F661DBDB09107EBE20@BYAPR05MB5718.namprd05.prod.outlook.com>

Hi FieldTrip community!

My name is Alex Aabedi. I'm a medical student at the University of California San Francisco researching speech responses in patients with brain tumors undergoing invasive electrophysiology. I'm very excited and grateful to be joining the FieldTrip ecosystem to perform our analyses.

I'm having trouble masking the subthreshold t-statistics I derived from ft_freqstatistics with ft_sourceplot. It appears that ft_sourceplot is ignoring the cfg.maskparameter call altogether (for instance, I don't get an error even if I specify a non-existent field in my stats structure). It looks like a colleague asked a similar question back in 2015 (https://mailman.science.ru.nl/pipermail/fieldtrip/2015-February/008924.html) but I don't see a response.

Here's a snippet of the code used to generate the sourceplot. It works fine, except it doesn't mask the channels with 0s in the mask field. The 'stats' structure (and all subfields) in the ft_sourceplot call is directly from ft_freqstatistics. I also tried masking with a dummy mask with all zeros, but to no avail.


cfg              = [];

cfg.funparameter = 'stat';

cfg.maskparameter = 'mask';

cfg.funcolormap = 'jet';

cfg.funcolorlim  = [-4 4];

cfg.method       = 'surface';

cfg.interpmethod = 'sphere_weighteddistance';

cfg.sphereradius = 8;

cfg.camlight     = 'no';

ft_sourceplot(cfg, stats, mesh);

view([-90 20]);

material dull;

lighting gouraud;

camlight;

Thank you so much for the support.

All the best,
Alex Aabedi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201117/652ff261/attachment.htm>

From tzvetan.popov at uni-konstanz.de  Wed Nov 18 14:17:31 2020
From: tzvetan.popov at uni-konstanz.de (Tzvetan Popov)
Date: Wed, 18 Nov 2020 14:17:31 +0100
Subject: [FieldTrip] Unable to mask sub-threshold statistics when
 plotting with ft_sourceplot
In-Reply-To: <BYAPR05MB5718AC6A410F661DBDB09107EBE20@BYAPR05MB5718.namprd05.prod.outlook.com>
References: <BYAPR05MB5718AC6A410F661DBDB09107EBE20@BYAPR05MB5718.namprd05.prod.outlook.com>
Message-ID: <C7060378-3499-47F7-8ECA-D3FF6239EAA0@uni-konstanz.de>

Dear Alex,

Can you please check 
1. Is your mask containing 0 and 1 or only 0
2. Can you use ft_sourceplot with method ‘ortho’ and report whether you see your desired result

If the answer to 1 and 2 is yes, I suggest using ft_volumenormalise prior to ft_sourceplot with the method ’surface’. Make 2 calls to ft_volumenormalise for cfg.parameter = ’stat’; and cfg.parameter = ‘mask’;

Hope this works.
Good luck
tzvetan


> On 17 Nov 2020, at 20:00, Aabedi, Alexander <Alexander.Aabedi at ucsf.edu> wrote:
> 
> Hi FieldTrip community!
> 
> My name is Alex Aabedi. I'm a medical student at the University of California San Francisco researching speech responses in patients with brain tumors undergoing invasive electrophysiology. I'm very excited and grateful to be joining the FieldTrip ecosystem to perform our analyses.
> 
> I'm having trouble masking the subthreshold t-statistics I derived from ft_freqstatistics with ft_sourceplot. It appears that ft_sourceplot is ignoring the cfg.maskparameter call altogether (for instance, I don't get an error even if I specify a non-existent field in my stats structure). It looks like a colleague asked a similar question back in 2015 (https://mailman.science.ru.nl/pipermail/fieldtrip/2015-February/008924.html <https://mailman.science.ru.nl/pipermail/fieldtrip/2015-February/008924.html>) but I don't see a response.
> 
> Here's a snippet of the code used to generate the sourceplot. It works fine, except it doesn't mask the channels with 0s in the mask field. The 'stats' structure (and all subfields) in the ft_sourceplot call is directly from ft_freqstatistics. I also tried masking with a dummy mask with all zeros, but to no avail. 
> 
> cfg              = [];
> cfg.funparameter = 'stat';
> cfg.maskparameter = 'mask';
> cfg.funcolormap = 'jet';
> cfg.funcolorlim  = [-4 4];
> cfg.method       = 'surface';
> cfg.interpmethod = 'sphere_weighteddistance';
> cfg.sphereradius = 8;
> cfg.camlight     = 'no';
> ft_sourceplot(cfg, stats, mesh);
> view([-90 20]);
> material dull;
> lighting gouraud;
> camlight;
> 
> Thank you so much for the support.
> 
> All the best,
> Alex Aabedi
> 
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip <https://mailman.science.ru.nl/mailman/listinfo/fieldtrip>
> https://doi.org/10.1371/journal.pcbi.1002202 <https://doi.org/10.1371/journal.pcbi.1002202>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201118/32da8642/attachment.htm>

From katarina.bendtz at gmail.com  Wed Nov 18 18:50:38 2020
From: katarina.bendtz at gmail.com (Katarina Bendtz)
Date: Wed, 18 Nov 2020 12:50:38 -0500
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n
Message-ID: <63425210-9257-4B41-88A4-CCD000361C6A@gmail.com>

Dear experts:
Me and my colleague at another university idependently I get this warning when we try to open an edf file:

Warning OPENEDF: Physical Minimum larger than Maximum\n


I’m using fieldtrip 2020113. Looking at the source code 
> 
> https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m

I read:

if (any(EDF.PhysMin >= EDF.PhysMax))

fprintf(2,'Warning OPENEDF: Physical Minimum larger than Maximum\n');

	EDF.PhysMin = EDF.DigMin;

        EDF.PhysMax = EDF.DigMax;

end

but then a couple of lines up, I see both EDF.PhysMin and EDF.PhysMax, (and also EDF.DigMin and EDF.DigMax) being set to the same thing:

EDF.PhysMin= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
EDF.PhysMax= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
EDF.DigMin = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %
EDF.DigMax = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %

So it is quite reasonable that I will get this warning. I’m puzzled. 

1. What’s purpose of this warning?
2. Why are the variables set to the same value?
3. Can I safely ignore this warning?
4. Or is there something I misunderstood.

Thanks a lot,

Best,
Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle 
Boston, USA




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201118/9918571d/attachment.htm>

From simeon.wong at sickkids.ca  Wed Nov 18 19:22:36 2020
From: simeon.wong at sickkids.ca (Simeon Wong)
Date: Wed, 18 Nov 2020 18:22:36 +0000
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than
 Maximum\n
In-Reply-To: <63425210-9257-4B41-88A4-CCD000361C6A@gmail.com>
References: <63425210-9257-4B41-88A4-CCD000361C6A@gmail.com>
Message-ID: <YTOPR0101MB0988643DDCCC1640CEDC7B56FDE10@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>

Hi Katarina,

The fread command advances the file pointer. Therefore the 4 lines are reading consecutive values from the EDF file.
https://www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle#d122e421874:~:text=and%20positions%20the%20file%20pointer%20after%20the%20last%20value%20read

With that being said, some EDF export software (for better or for worse) set identical physical values if channels are switched off or for channels without physical units (ie. trigger channels or misc channels).




All the best,
Simeon


[cid:a581ee8a-f956-4ec0-896f-a88e64846b6f]

Simeon Wong

Ibrahim Lab

Neurosciences & Mental Health


686 Bay Street, Toronto ON  M5G 0A4

P 416.813.7654  x303697

________________________________
From: fieldtrip <fieldtrip-bounces at science.ru.nl> on behalf of Katarina Bendtz <katarina.bendtz at gmail.com>
Sent: November 18, 2020 12:50
To: fieldtrip at science.ru.nl <fieldtrip at science.ru.nl>
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n

Dear experts:
Me and my colleague at another university idependently I get this warning when we try to open an edf file:

Warning OPENEDF: Physical Minimum larger than Maximum\n


I’m using fieldtrip 2020113. Looking at the source code
https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m<https://urldefense.com/v3/__https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m__;!!D0zGoin7BXfl!tHOzBhC87IDZICVPmzh1QeJQI1pBz7wzlyRm7uCUqe_WlgHxjVh2sShWYk0yjAhO9UAo$>

I read:

if (any(EDF.PhysMin >= EDF.PhysMax))

fprintf(2,'Warning OPENEDF: Physical Minimum larger than Maximum\n');

EDF.PhysMin = EDF.DigMin;

        EDF.PhysMax = EDF.DigMax;

end

but then a couple of lines up, I see both EDF.PhysMin and EDF.PhysMax, (and also EDF.DigMin and EDF.DigMax) being set to the same thing:

EDF.PhysMin= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
EDF.PhysMax= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
EDF.DigMin = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %
EDF.DigMax = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %

So it is quite reasonable that I will get this warning. I’m puzzled.

1. What’s purpose of this warning?
2. Why are the variables set to the same value?
3. Can I safely ignore this warning?
4. Or is there something I misunderstood.

Thanks a lot,

Best,
Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA





________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201118/c8fc062a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-gb44xqtx.png
Type: image/png
Size: 1756 bytes
Desc: Outlook-gb44xqtx.png
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201118/c8fc062a/attachment.png>

From katarina.bendtz at gmail.com  Wed Nov 18 20:20:13 2020
From: katarina.bendtz at gmail.com (Katarina Bendtz)
Date: Wed, 18 Nov 2020 14:20:13 -0500
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than
 Maximum\n
In-Reply-To: <YTOPR0101MB0988643DDCCC1640CEDC7B56FDE10@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>
References: <63425210-9257-4B41-88A4-CCD000361C6A@gmail.com>
 <YTOPR0101MB0988643DDCCC1640CEDC7B56FDE10@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <03559953-E06B-4EA4-9329-8D0D5002F0C5@gmail.com>

Dear Simeon!

Thank you so much for your quick reply! I understand!

Do you think I can safely ignore this or should I try to find out which channels this applies to? That is, if the trigger channels are set to identical values, will this in some way compromise/change the data?

best,
Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle 
Boston, USA




> On Nov 18, 2020, at 1:22 PM, Simeon Wong <simeon.wong at sickkids.ca> wrote:
> 
> Hi Katarina,
> 
> The fread command advances the file pointer. Therefore the 4 lines are reading consecutive values from the EDF file.
> https://www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle#d122e421874:~:text=and%20positions%20the%20file%20pointer%20after%20the%20last%20value%20read <https://www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle#d122e421874:~:text=and%20positions%20the%20file%20pointer%20after%20the%20last%20value%20read>
> 
> With that being said, some EDF export software (for better or for worse) set identical physical values if channels are switched off or for channels without physical units (ie. trigger channels or misc channels).
> 
> 
> 
> 
> All the best,
> Simeon
> 
> 
> <Outlook-gb44xqtx.png>
> Simeon Wong
> Ibrahim Lab
> Neurosciences & Mental Health
> 
> 686 Bay Street, Toronto ON  M5G 0A4
> P 416.813.7654  x303697
> 
> From: fieldtrip <fieldtrip-bounces at science.ru.nl> on behalf of Katarina Bendtz <katarina.bendtz at gmail.com>
> Sent: November 18, 2020 12:50
> To: fieldtrip at science.ru.nl <fieldtrip at science.ru.nl>
> Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n
>  
> Dear experts:
> Me and my colleague at another university idependently I get this warning when we try to open an edf file:
> 
> Warning OPENEDF: Physical
>  Minimum larger than Maximum\n
> 
> 
> 
> I’m using fieldtrip 2020113. Looking at the source code 
>> 
>> https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m <https://urldefense.com/v3/__https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m__;!!D0zGoin7BXfl!tHOzBhC87IDZICVPmzh1QeJQI1pBz7wzlyRm7uCUqe_WlgHxjVh2sShWYk0yjAhO9UAo$>
> I read:
> 
> if (any(EDF.PhysMin >= EDF.PhysMax))
> 
> fprintf(2,'Warning OPENEDF: Physical Minimum larger than Maximum\n');
> 
> EDF.PhysMin = EDF.DigMin;
> 
>         EDF.PhysMax = EDF.DigMax;
> 
> end
> 
> but then a couple of lines up, I see both EDF.PhysMin and EDF.PhysMax, (and also EDF.DigMin and EDF.DigMax) being set to the same thing:
> 
> EDF.PhysMin= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
> EDF.PhysMax= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
> EDF.DigMin = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %
> EDF.DigMax = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %
> 
> So it is quite reasonable that I will get this warning. I’m puzzled. 
> 
> 1. What’s purpose of this warning?
> 2. Why are the variables set to the same value?
> 3. Can I safely ignore this warning?
> 4. Or is there something I misunderstood.
> 
> Thanks a lot,
> 
> Best,
> Kat
> 
> 
> 
> Katarina Bendtz, PhD
> Research Fellow
> Kreiman Lab
> Boston Children's Hospital
> Harvard University
> 
> +1 (617) 390 45 16
> 3 Blackfan Circle 
> Boston, USA
> 
> 
> 
> 
> 
> 
> This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip <https://mailman.science.ru.nl/mailman/listinfo/fieldtrip>
> https://doi.org/10.1371/journal.pcbi.1002202 <https://doi.org/10.1371/journal.pcbi.1002202>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201118/db93b784/attachment.htm>

From patrick.wiegel at sport.uni-freiburg.de  Thu Nov 19 13:20:21 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Thu, 19 Nov 2020 12:20:21 +0000
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
 <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
Message-ID: <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>

Dear fieldtrip community,

first of all, thank you for your valuable responses @Tzvetan and Stephen. They were both very helpful and got me to dig deeper into the analysis.

You were absolutely right in describing my approach for my Morlet wavelet TF analysis. The data were baseline corrected (in db). When contrasting the 2 conditions of interest, I receive the attached figure (dif_morlet). After your responses, I took the same approach for the mtmfft data with cfg.tapsmofrq = 8 (center frequency at 28 Hz) to reproduce the effect that I found between 20-35 Hz in the morlet wavelet analyses. I calculated frequency analysis (mtmfft) for both conditions (data_1, data_0) and their baseline periods (data_1_bas, data_0_bas) separately and then „baseline corrected“ the data from both conditions (also in db, see dif_mtmfft). The differences between conditions are now very similar between both approaches (morlet vs mtmfft).

In the next step. I followed your advice and performed source analyses of frequency_data for all 4 conditions separately (pow_1, pow_0, pow_1_baseline, pow_0_baseline) as well as from all_data from ft_appenddata. For the source_analyses from all 4 conditions, I am using the common filter from all_data as well as the source model (ft_prepare_leadfieldds) from all_data. After performing the ft_source_analysis function for all 4 conditions, I am trying to replicate what I have done with the power data ( in db). For this reason, I am using ft_math with source_1_dif = 10*log10 (source_1/source_1_baseline) and the same for source_0. After this, I am subtracting source_0_dif from source_1_dif as done during the frequency analysis yielding my final source data.

After interpolating the source differences, I am using ft_volumenormalise. The result from this approach is attached in dif_sources.

I am a bit puzzled since I would not expect these source data based on my power mtmfft data. I made sure that the coordinate systems and units are the same across models (volume_conduction_model, electrodes, MRI) but I am wondering whether I am doing something wrong in performing the source_analysis or whether the source results are reasonable.

Again, I uploaded the script and the data such that my analysis pipeline could be reproduced by everyone who is interested (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation). Below, I am attaching the code for the source_analyses steps. Any comments on my results or approach are welcome.

All the Best from Germany,
Patrick



.








cfg              = [];
cfg.method       = 'dics';
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.dics.projectnoise = 'yes';
cfg.dics.lambda       = '5%';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
cfg.sourcemodel  = sourcemodel_beta;
source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
source_beta_1_bas = ft_sourceanalysis(cfg, data_beta_1_bas);
source_beta_0_bas = ft_sourceanalysis(cfg, data_beta_0_bas);





%%
cfg            = [];
cfg.parameter = 'pow';
cfg.operation = '10*log10(x1/x2)';
sourceDiff1_beta = ft_math(cfg, source_beta_1,source_beta_1_bas);
sourceDiff0_beta = ft_math(cfg, source_beta_0,source_beta_0_bas);



sourceDiff_beta_dif = sourceDiff1_beta;
sourceDiff_beta_dif.pow = sourceDiff1_beta.pow - sourceDiff0_beta.pow;



%%
cfg            = [];
cfg.downsample = 2;
cfg.parameter  = 'pow';
sourceDiffInt_beta_dif  = ft_sourceinterpolate(cfg, sourceDiff_beta_dif , mri_realigned);



%%
maxval_beta = max(sourceDiffInt_beta_dif.pow);
%%
cfg = [];
cfg.nonlinear     = 'no';



sourceDiffIntNorm_beta_dif = ft_volumenormalise(cfg, sourceDiffInt_beta_dif);



%%
cfg = [];
cfg.method        = 'ortho';
cfg.interactive   = 'yes';
cfg.funparameter  = 'pow';
cfg.maskparameter = cfg.funparameter;
cfg.funcolorlim   = [0.0 maxval_beta];
cfg.opacitylim    = [0.0 maxval_beta];
cfg.opacitymap    = 'rampup';
ft_sourceplot(cfg, sourceDiffIntNorm_beta_dif);
%%


Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

Am 13.11.2020 um 12:48 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Hi Patrick, (and Tzvetan - who responded in the meantime),

I agree that you should start with a good correspondence between your initial results (wavelets), and the power difference you are trying to localize (with mtmfft).

Wavelets and fft methods can result in very similar - practically identical - results, but that depends on a number of parameters, especially concerning frequency-smoothing; Wavelets are typically defined in terms of nr. of cycles, while fft methods are defined in terms of time-windows. Wavelets defined in nr. of cycles will have a decreasing time-windows with increasing frequency, while with mtmfft time windows will remain the same. Because of this, frequency smoothing will increase with frequency with wavelets, and stay the same with a constant time window. Of course, you can make the fft time window frequency-dependent, as is described in the frequency-analyses tutorial, to make them more comparable. Secondly, the fft method allows you to specify frequency smoothing when you use Sleppian multitapers (cfg.taper = 'dpss'). To be clear, you should be able to recognize these differences in frequency smoothing/resolution when looking at the different TFR plots. Currently they look too different, probably because of something else (baseline?) than a wavelet-fft difference.

I would advise making a 'full' TFR with mtmfft similar as your wavelet results so that you can properly compare them. This allows you to also set the best parameters for smoothing/timeperiods. In fact, you can use the multitaper approach to more accurately extract the power in a certain frequency band. Only then compare the topo's, and only then do the beamformer, so you will pick up any unexpected results.

Because of different contrasts/baseline correction, I cannot compare the topo's / beamformer results.

Bon courage,
Stephen









Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear Field-trip community,

I am working on EEG data from a motor learning task. in the first part of my analysis, I performed a time-frequency analysis (Morlet wavelet method) and cluster-based permutation test. I compared two different conditions (correct & incorrect movements) within subjects and found a significant difference in the beta band (20-35 Hz) when subjects were provided with feedback. I attached the topographical plot from one subject that illustrates the difference between the conditions at the selected time point and frequency (dif_morlet). As you can see, beta power was higher in one condition in lateral frontal electrodes.

Now, I would like to better spatially locate the effect for this single subject. For this purpose, I followed the Beamformer tutorial on the website. In the first step, I selected the raw data of interest (at the time where the effect was seen) and performed frequency analyses for the 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft). There is an apparent difference between dif_morlet and dif_mtmfft and I am wondering why this is the case? One apparent reason is that the time-frequency data were baseline corrected and the frequency data from mtmfft not.

Using the power and CSD data from mtmfft, I performed the source analysis with a standard MRI and head model. The source was located in the left hemisphere (source plot), which is in stark contrast to the time-frequency data (dif_morlet). I am aware that the source analysis is based on a lot of assumptions (conductivity etc.) that influence the calculations but it is very difficult to make sense of such discrepancy.
Maybe it is necessary to also baseline correct the mtmfft data before inputting them to the source analysis? Or doing the contrasting source localization betwee a single condition and the corresponding baseline data before contrasting the 2 conditions?

I am providing all necessary files and scripts (TF_analysis & BEAMFORMER) if anyone is interested to reproduce the results that I am showing and reporting for this single subject (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).

I would appreciate any help and discussion on that.

All the best,
Patrick





Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201119/31450154/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dif_morlet.eps
Type: application/postscript
Size: 85673 bytes
Desc: dif_morlet.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201119/31450154/attachment.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dif_mtmfft.eps
Type: application/postscript
Size: 69764 bytes
Desc: dif_mtmfft.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201119/31450154/attachment-0001.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source_dif.eps
Type: application/postscript
Size: 267264 bytes
Desc: source_dif.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201119/31450154/attachment-0002.eps>

From alex.lepauvre at ae.mpg.de  Thu Nov 19 14:00:54 2020
From: alex.lepauvre at ae.mpg.de (Lepauvre, Alex)
Date: Thu, 19 Nov 2020 13:00:54 +0000
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than
 Maximum\n
In-Reply-To: <03559953-E06B-4EA4-9329-8D0D5002F0C5@gmail.com>
References: <63425210-9257-4B41-88A4-CCD000361C6A@gmail.com>
 <YTOPR0101MB0988643DDCCC1640CEDC7B56FDE10@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>
 <03559953-E06B-4EA4-9329-8D0D5002F0C5@gmail.com>
Message-ID: <55d2470b820e4801a92e8216c2253e52@ae.mpg.de>

Dear Simeon, deaf Fieldtrip community

Thanks a lot for your helpful feedback. To give you a little bit more context, our EDFs are from iEEG data.  I have been digging a little bit more into this issue with our data. First of all, it turns out that the warning isn’t thrown by the opnedEDF function, but by the read_edf.m one. It seems that in our files, the accessed PhysMin and PhysMax are reversed. Indeed, most values in the PhysMax are negative (-8711uV, except for some misc channels), while the PhysMin is the exact opposite (+8711), which seems to be the prime reason for this error.  I am not sure why that is the case. According to what you were saying @Simeon, this might be due to our EDF export software doing something odd with the headers? Can this harm our data?

Also, another aspect I am confused about is that we are currently using fieldtrip to chop our single big EDFs into smaller more manageable files. We therefore load the data triggering the warning, then chop them and adjust the headers, and save the chunks separately. However, when reloading the newly saved data, the warning isn’t there anymore, which has me worried that the data have been altered in some way.
After digging in the function write_edf a little bit more, I am supposing that the issue doesn’t appear anymore because fieldtrip compute the max and min amplitude of the signal, and fill it in in the PhyMax and PhysMin headers itself, correct?

Finally, another issue we are facing is that for some of our EDF files, the write_EDF function doesn’t work with some of our EDFs (I am unfortunately not allowed to share any data due to strong data privacy policies In our project, my apologies). While for some of our files it did work, for at least one, the write_edf returns the following error:
[cid:image001.jpg at 01D6BE7C.60ED60C0]

I again dived into the function write_edf and located the issue here:

[cid:image002.jpg at 01D6BE7C.60ED60C0]
I am not entirely sure what the purpose of these statements is. It seems to reduce the decimal places of the physical minimum (and then maximum) to find which approximation fits the expected size (8*nchans). However, none of the 5 options fit. Surprisingly enough, going one more would work: in my signal %-8.2g fits exactly nchans*8. I am not sure why that is the case nor what it would entail for my data if I were to change it in the code myself. Could someone enlighten me?

From: fieldtrip <fieldtrip-bounces at science.ru.nl> On Behalf Of Katarina Bendtz
Sent: Wednesday, 18 November 2020 20:20
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n

Dear Simeon!

Thank you so much for your quick reply! I understand!

Do you think I can safely ignore this or should I try to find out which channels this applies to? That is, if the trigger channels are set to identical values, will this in some way compromise/change the data?

best,
Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA




On Nov 18, 2020, at 1:22 PM, Simeon Wong <simeon.wong at sickkids.ca<mailto:simeon.wong at sickkids.ca>> wrote:

Hi Katarina,

The fread command advances the file pointer. Therefore the 4 lines are reading consecutive values from the EDF file.
https://www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle#d122e421874:~:text=and%20positions%20the%20file%20pointer%20after%20the%20last%20value%20read

With that being said, some EDF export software (for better or for worse) set identical physical values if channels are switched off or for channels without physical units (ie. trigger channels or misc channels).




All the best,
Simeon


<Outlook-gb44xqtx.png>

Simeon Wong
Ibrahim Lab
Neurosciences & Mental Health

686 Bay Street, Toronto ON  M5G 0A4
P 416.813.7654  x303697


________________________________
From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> on behalf of Katarina Bendtz <katarina.bendtz at gmail.com<mailto:katarina.bendtz at gmail.com>>
Sent: November 18, 2020 12:50
To: fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl> <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n

Dear experts:
Me and my colleague at another university idependently I get this warning when we try to open an edf file:

Warning OPENEDF: Physical
Minimum larger than Maximum\n



I’m using fieldtrip 2020113. Looking at the source code
https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m<https://urldefense.com/v3/__https:/github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m__;!!D0zGoin7BXfl!tHOzBhC87IDZICVPmzh1QeJQI1pBz7wzlyRm7uCUqe_WlgHxjVh2sShWYk0yjAhO9UAo$>

I read:

if (any(EDF.PhysMin >= EDF.PhysMax))

fprintf(2,'Warning OPENEDF: Physical Minimum larger than Maximum\n');

EDF.PhysMin = EDF.DigMin;

        EDF.PhysMax = EDF.DigMax;

end

but then a couple of lines up, I see both EDF.PhysMin and EDF.PhysMax, (and also EDF.DigMin and EDF.DigMax) being set to the same thing:

EDF.PhysMin= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
EDF.PhysMax= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
EDF.DigMin = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %
EDF.DigMax = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %

So it is quite reasonable that I will get this warning. I’m puzzled.

1. What’s purpose of this warning?
2. Why are the variables set to the same value?
3. Can I safely ignore this warning?
4. Or is there something I misunderstood.

Thanks a lot,

Best,
Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA




________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201119/e54a7050/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 70309 bytes
Desc: image001.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201119/e54a7050/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 96343 bytes
Desc: image002.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201119/e54a7050/attachment-0001.jpg>

From stephen.whitmarsh at gmail.com  Thu Nov 19 14:59:40 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Thu, 19 Nov 2020 14:59:40 +0100
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
 <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
 <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>
Message-ID: <CAFrxm=wdQ1qSnWkRk+Bkb+nY14WaJEwkRCf89PaCevU6amTg7g@mail.gmail.com>

Dear Patrick,

Nice to see you are progressing. The TFR topoplots look nice (and the
effect seems even stronger in the mtmfft version)!

I agree the source reconstruction looks pretty iffy. A single dot like that
shouldn't be there - no source in Beamformer is so focal. It suggests
something is off, which could be as simple as a single electrode doing
something weird (given how focal and superficial the artefact is).

I would take another step back;
I would first look at the distribution of your absolute beta, i.e. without
baseline correction. For both conditions.
I would then look at the distribution of your baseline beta, i.e. only your
baseline. For both conditions.
You should satisfy yourself that the results make sense, i.e. nothing too
drastic, focal, etc., and some density of beta power around the central
sulcus (?).

Now I understand your contrast better, I have to ask why you do the
baseline correction as you do. In this way you are using a separate BL for
each condition, meaning that after BL-correction you are actually also
comparing BL as much as you are comparing post-BL activity - after
BL-correction any differences in BL become difference in your active
period.
If you assume differences in BL you might want to compare those separately
before you 'add' them to your active period. If you have a randomized
design, you might not want to do any BL correction in your contrast at all.
Also, if there are no differences in BL, then it would make no difference...
So, when you have a good sense of the absolute values and source
distributions, you might want to try just comparing active period A vs B,
relative (/) or absolute (-), and forget about the BL. Sometimes the BL is
more noisy than the active period even.

Anyway, your script looks fine to me, but it's been a while. However, I
suspect that one of your datasets (A, A_BL, B, or B_BL) has some artefact
that is introduced in the contrast.

Cheers,
Stephen











Op do 19 nov. 2020 om 13:27 schreef Patrick Wiegel <
patrick.wiegel at sport.uni-freiburg.de>:

> Dear fieldtrip community,
>
> first of all, thank you for your valuable responses @Tzvetan and Stephen.
> They were both very helpful and got me to dig deeper into the analysis.
>
> You were absolutely right in describing my approach for my Morlet wavelet
> TF analysis. The data were baseline corrected (in db). When contrasting the
> 2 conditions of interest, I receive the attached figure (dif_morlet). After
> your responses, I took the same approach for the mtmfft data
> with cfg.tapsmofrq = 8 (center frequency at 28 Hz) to reproduce the effect
> that I found between 20-35 Hz in the morlet wavelet analyses. I
> calculated frequency analysis (mtmfft) for both conditions (data_1, data_0)
> and their baseline periods (data_1_bas, data_0_bas) separately and then
> „baseline corrected“ the data from both conditions (also in db, see
> dif_mtmfft). The differences between conditions are now very similar
> between both approaches (morlet vs mtmfft).
>
> In the next step. I followed your advice and performed source analyses of
> frequency_data for all 4 conditions separately (pow_1, pow_0,
> pow_1_baseline, pow_0_baseline) as well as from all_data from
> ft_appenddata. For the source_analyses from all 4 conditions, I am using
> the common filter from all_data as well as the source model
> (ft_prepare_leadfieldds) from all_data. After performing the
> ft_source_analysis function for all 4 conditions, I am trying to replicate
> what I have done with the power data ( in db). For this reason, I am using
> ft_math with source_1_dif = 10*log10 (source_1/source_1_baseline) and the
> same for source_0. After this, I am subtracting source_0_dif
> from source_1_dif as done during the frequency analysis yielding my final
> source data.
>
> After interpolating the source differences, I am using ft_volumenormalise.
> The result from this approach is attached in dif_sources.
>
> I am a bit puzzled since I would not expect these source data based on my
> power mtmfft data. I made sure that the coordinate systems and units are
> the same across models (volume_conduction_model, electrodes, MRI) but I am
> wondering whether I am doing something wrong in performing the
> source_analysis or whether the source results are reasonable.
>
> Again, I uploaded the script and the data such that my analysis pipeline
> could be reproduced by everyone who is interested (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
> Below, I am attaching the code for the source_analyses steps. Any comments
> on my results or approach are welcome.
>
> All the Best from Germany,
> Patrick
>
>
>
> .
>
>
>
>
>
>
> cfg              = [];
> cfg.method       = 'dics';
> cfg.headmodel    = vol;
> cfg.elec         = elec_aligned;
> cfg.dics.projectnoise = 'yes';
> cfg.dics.lambda       = '5%';
> cfg.dics.keepfilter   = 'yes';
> cfg.dics.realfilter   = 'yes';
> cfg.sourcemodel  = sourcemodel_beta;
> source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
> source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
> source_beta_1_bas = ft_sourceanalysis(cfg, data_beta_1_bas);
> source_beta_0_bas = ft_sourceanalysis(cfg, data_beta_0_bas);
>
>
>
>
> %%
> cfg            = [];
> cfg.parameter = 'pow';
> cfg.operation = '10*log10(x1/x2)';
> sourceDiff1_beta = ft_math(cfg, source_beta_1,source_beta_1_bas);
> sourceDiff0_beta = ft_math(cfg, source_beta_0,source_beta_0_bas);
>
>
> sourceDiff_beta_dif = sourceDiff1_beta;
> sourceDiff_beta_dif.pow = sourceDiff1_beta.pow - sourceDiff0_beta.pow;
>
>
> %%
> cfg            = [];
> cfg.downsample = 2;
> cfg.parameter  = 'pow';
> sourceDiffInt_beta_dif  = ft_sourceinterpolate(cfg, sourceDiff_beta_dif ,
> mri_realigned);
>
>
> %%
> maxval_beta = max(sourceDiffInt_beta_dif.pow);
> %%
> cfg = [];
> cfg.nonlinear     = 'no';
>
>
> sourceDiffIntNorm_beta_dif = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif);
>
>
> %%
> cfg = [];
> cfg.method        = 'ortho';
> cfg.interactive   = 'yes';
> cfg.funparameter  = 'pow';
> cfg.maskparameter = cfg.funparameter;
> cfg.funcolorlim   = [0.0 maxval_beta];
> cfg.opacitylim    = [0.0 maxval_beta];
> cfg.opacitymap    = 'rampup';
> ft_sourceplot(cfg, sourceDiffIntNorm_beta_dif);
> %%
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> Am 13.11.2020 um 12:48 schrieb Stephen Whitmarsh <
> stephen.whitmarsh at gmail.com>:
>
> Hi Patrick, (and Tzvetan - who responded in the meantime),
>
> I agree that you should start with a good correspondence between your
> initial results (wavelets), and the power difference you are trying to
> localize (with mtmfft).
>
> Wavelets and fft methods can result in very similar - practically
> identical - results, but that depends on a number of parameters, especially
> concerning frequency-smoothing; Wavelets are typically defined in terms of
> nr. of cycles, while fft methods are defined in terms of time-windows.
> Wavelets defined in nr. of cycles will have a decreasing time-windows with
> increasing frequency, while with mtmfft time windows will remain the same.
> Because of this, frequency smoothing will increase with frequency with
> wavelets, and stay the same with a constant time window. Of course, you can
> make the fft time window frequency-dependent, as is described in the
> frequency-analyses tutorial, to make them more comparable. Secondly, the
> fft method allows you to specify frequency smoothing when you use Sleppian
> multitapers (cfg.taper = 'dpss'). To be clear, you should be able to
> recognize these differences in frequency smoothing/resolution when looking
> at the different TFR plots. Currently they look too different, probably
> because of something else (baseline?) than a wavelet-fft difference.
>
> I would advise making a 'full' TFR with mtmfft similar as your wavelet
> results so that you can properly compare them. This allows you to also set
> the best parameters for smoothing/timeperiods. In fact, you can use the
> multitaper approach to more accurately extract the power in a certain
> frequency band. Only then compare the topo's, and only then do the
> beamformer, so you will pick up any unexpected results.
>
> Because of different contrasts/baseline correction, I cannot compare the
> topo's / beamformer results.
>
> Bon courage,
> Stephen
>
>
>
>
>
>
>
>
>
> Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de>:
>
> Dear Field-trip community,
>
> I am working on EEG data from a motor learning task. in the first part of
> my analysis, I performed a time-frequency analysis (Morlet wavelet method)
> and cluster-based permutation test. I compared two different conditions
> (correct & incorrect movements) within subjects and found a significant
> difference in the beta band (20-35 Hz) when subjects were provided with
> feedback. I attached the topographical plot from one subject that
> illustrates the difference between the conditions at the selected time
> point and frequency (dif_morlet). As you can see, beta power was higher in
> one condition in lateral frontal electrodes.
>
> Now, I would like to better spatially locate the effect for this single
> subject. For this purpose, I followed the Beamformer tutorial on the
> website. In the first step, I selected the raw data of interest (at the
> time where the effect was seen) and performed frequency analyses for the
> 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft).
> There is an apparent difference between dif_morlet and dif_mtmfft and I am
> wondering why this is the case? One apparent reason is that the
> time-frequency data were baseline corrected and the frequency data from
> mtmfft not.
>
> Using the power and CSD data from mtmfft, I performed the source analysis
> with a standard MRI and head model. The source was located in the left
> hemisphere (source plot), which is in stark contrast to the time-frequency
> data (dif_morlet). I am aware that the source analysis is based on a lot of
> assumptions (conductivity etc.) that influence the calculations but it is
> very difficult to make sense of such discrepancy.
> Maybe it is necessary to also baseline correct the mtmfft data before
> inputting them to the source analysis? Or doing the contrasting source
> localization betwee a single condition and the corresponding baseline data
> before contrasting the 2 conditions?
>
> I am providing all necessary files and scripts (TF_analysis & BEAMFORMER)
> if anyone is interested to reproduce the results that I am showing and
> reporting for this single subject (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>
> I would appreciate any help and discussion on that.
>
> All the best,
> Patrick
>
>
>
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201119/e0f19368/attachment.htm>

From alex.lepauvre at ae.mpg.de  Fri Nov 20 12:12:47 2020
From: alex.lepauvre at ae.mpg.de (Lepauvre, Alex)
Date: Fri, 20 Nov 2020 11:12:47 +0000
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than
 Maximum\n
In-Reply-To: <55d2470b820e4801a92e8216c2253e52@ae.mpg.de>
References: <63425210-9257-4B41-88A4-CCD000361C6A@gmail.com>
 <YTOPR0101MB0988643DDCCC1640CEDC7B56FDE10@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>
 <03559953-E06B-4EA4-9329-8D0D5002F0C5@gmail.com>
 <55d2470b820e4801a92e8216c2253e52@ae.mpg.de>
Message-ID: <1642a8d00a9247da85aa52777c9a1aca@ae.mpg.de>

Dear Fieldtrip community,

Following on the messages below, I performed comparison between the saved signal and the original signal. To give a little more context, our single goal here is to load our EDF signal in fieldtrip to then chop it into pieces to be able to save each piece separately. We are required to do so as we are having very long EDFs and because we have to format our data in these specific pieces for data ingestion in XNAT.

The written function (see attached) loads the EDF of interest and using a photodiode trigger channel, we parse our signal in “blocks”, enabling the user of the code to adjust detected onsets manually to account for misdetection by our algorithm. The EDF signal is cut from onsets to onsets and stored in separated files. We need to make sure that this procedure doesn’t alter our raw signal in any ways. To check whether this happens, following the data saving, the saved data are being reloaded and compared to the original data that were parsed. If the comparison yields anything else than 0s, then it means that the data were altered in some way.

When running the function, the first thing I notice is that following saving, the size of the signal.trial{1,1} matrices has been changed. Following some digging in the edf write function, I noticed that the data are being saved to the EDF in 1 seconds chunks, while it is not in our original signal (0.625seconds instead). I assume that this is not a big deal as this doesn’t really alter the data. However, what I believe is problematic is that the signal gets altered after the second decimal place across all channels. I am assuming that this has something to do with the conversion to uint16? I am a bit puzzled about why this is the case and how we can get around this issue to save our data and keep them pristine. Has anyone been encountering similar issues and/or knows a way?

Kind regards,

Alex

From: fieldtrip <fieldtrip-bounces at science.ru.nl> On Behalf Of Lepauvre, Alex
Sent: Thursday, 19 November 2020 14:01
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n

Dear Simeon, deaf Fieldtrip community

Thanks a lot for your helpful feedback. To give you a little bit more context, our EDFs are from iEEG data.  I have been digging a little bit more into this issue with our data. First of all, it turns out that the warning isn’t thrown by the opnedEDF function, but by the read_edf.m one. It seems that in our files, the accessed PhysMin and PhysMax are reversed. Indeed, most values in the PhysMax are negative (-8711uV, except for some misc channels), while the PhysMin is the exact opposite (+8711), which seems to be the prime reason for this error.  I am not sure why that is the case. According to what you were saying @Simeon, this might be due to our EDF export software doing something odd with the headers? Can this harm our data?

Also, another aspect I am confused about is that we are currently using fieldtrip to chop our single big EDFs into smaller more manageable files. We therefore load the data triggering the warning, then chop them and adjust the headers, and save the chunks separately. However, when reloading the newly saved data, the warning isn’t there anymore, which has me worried that the data have been altered in some way.
After digging in the function write_edf a little bit more, I am supposing that the issue doesn’t appear anymore because fieldtrip compute the max and min amplitude of the signal, and fill it in in the PhyMax and PhysMin headers itself, correct?

Finally, another issue we are facing is that for some of our EDF files, the write_EDF function doesn’t work with some of our EDFs (I am unfortunately not allowed to share any data due to strong data privacy policies In our project, my apologies). While for some of our files it did work, for at least one, the write_edf returns the following error:
[cid:image003.jpg at 01D6BF33.9D87D350]

I again dived into the function write_edf and located the issue here:

[cid:image005.jpg at 01D6BF33.9D87D350]
I am not entirely sure what the purpose of these statements is. It seems to reduce the decimal places of the physical minimum (and then maximum) to find which approximation fits the expected size (8*nchans). However, none of the 5 options fit. Surprisingly enough, going one more would work: in my signal %-8.2g fits exactly nchans*8. I am not sure why that is the case nor what it would entail for my data if I were to change it in the code myself. Could someone enlighten me?

From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> On Behalf Of Katarina Bendtz
Sent: Wednesday, 18 November 2020 20:20
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n

Dear Simeon!

Thank you so much for your quick reply! I understand!

Do you think I can safely ignore this or should I try to find out which channels this applies to? That is, if the trigger channels are set to identical values, will this in some way compromise/change the data?

best,
Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA



On Nov 18, 2020, at 1:22 PM, Simeon Wong <simeon.wong at sickkids.ca<mailto:simeon.wong at sickkids.ca>> wrote:

Hi Katarina,

The fread command advances the file pointer. Therefore the 4 lines are reading consecutive values from the EDF file.
https://www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle#d122e421874:~:text=and%20positions%20the%20file%20pointer%20after%20the%20last%20value%20read

With that being said, some EDF export software (for better or for worse) set identical physical values if channels are switched off or for channels without physical units (ie. trigger channels or misc channels).




All the best,
Simeon


<Outlook-gb44xqtx.png>

Simeon Wong
Ibrahim Lab
Neurosciences & Mental Health

686 Bay Street, Toronto ON  M5G 0A4
P 416.813.7654  x303697


________________________________
From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> on behalf of Katarina Bendtz <katarina.bendtz at gmail.com<mailto:katarina.bendtz at gmail.com>>
Sent: November 18, 2020 12:50
To: fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl> <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n

Dear experts:
Me and my colleague at another university idependently I get this warning when we try to open an edf file:

Warning OPENEDF: Physical
Minimum larger than Maximum\n


I’m using fieldtrip 2020113. Looking at the source code
https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m<https://urldefense.com/v3/__https:/github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m__;!!D0zGoin7BXfl!tHOzBhC87IDZICVPmzh1QeJQI1pBz7wzlyRm7uCUqe_WlgHxjVh2sShWYk0yjAhO9UAo$>

I read:

if (any(EDF.PhysMin >= EDF.PhysMax))

fprintf(2,'Warning OPENEDF: Physical Minimum larger than Maximum\n');

EDF.PhysMin = EDF.DigMin;

        EDF.PhysMax = EDF.DigMax;

end

but then a couple of lines up, I see both EDF.PhysMin and EDF.PhysMax, (and also EDF.DigMin and EDF.DigMax) being set to the same thing:

EDF.PhysMin= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
EDF.PhysMax= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));
EDF.DigMin = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %
EDF.DigMax = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %

So it is quite reasonable that I will get this warning. I’m puzzled.

1. What’s purpose of this warning?
2. Why are the variables set to the same value?
3. Can I safely ignore this warning?
4. Or is there something I misunderstood.

Thanks a lot,

Best,
Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA




________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/e03a4bba/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 69416 bytes
Desc: image003.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/e03a4bba/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 94776 bytes
Desc: image005.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/e03a4bba/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ECoGPruner.m
Type: application/octet-stream
Size: 17365 bytes
Desc: ECoGPruner.m
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/e03a4bba/attachment.obj>

From patrick.wiegel at sport.uni-freiburg.de  Fri Nov 20 12:19:41 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Fri, 20 Nov 2020 11:19:41 +0000
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <CAFrxm=wdQ1qSnWkRk+Bkb+nY14WaJEwkRCf89PaCevU6amTg7g@mail.gmail.com>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
 <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
 <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>
 <CAFrxm=wdQ1qSnWkRk+Bkb+nY14WaJEwkRCf89PaCevU6amTg7g@mail.gmail.com>
Message-ID: <BB83D822-468A-4C28-AF6F-BE2807F76DBB@sport.uni-freiburg.de>

Dear Stephen,

thanks for the response.

I followed your suggestions and attached the plots. I performed Morlet wavelets TF analyses and mtmfft for conditions A and B. I did not use a baseline correction to see whether this is necessary. As you can see in the topographical plots, both conditions (A and B) have high power in 2 posterior electrodes (I guess some kind of artifact or noise is the reason). Using the abs. difference between A and B does not get rid of that fact, probably because one condition is more affected than the other. Using the rel. difference does a better job and resembles my previous baseline-corrected results. I also compared the baselines and they were not different. The two conditions were furthermore randomized within the same protocol. I assume that adding a baseline is thus unnecessary.

Regarding the source_analysis, the results for individual conditions A and B (NAI) as well as abs dif between A and B look weird again. But that’s very likely due to the same problem as for the power. For rel dif between A and B, the source plot seems more reasonable, although I expect the source to be in the right hemisphere and not in the left as shown in the plot. I controlled that all my input data (electrodes, volume condition model, MRI) have the same definition of the axes (x+ pointing right, y+ pointing anterior, z+ pointing superior) so I don’t think there is a right-left mix-up!?

Now I am wondering whether I have to accept the result for the rel difference in sources between A and B (which is very hard to interpret and justify after what I am observing in the TF analysis, namely an effect in the other hemisphere) or whether there might be still some issue in my approach. It is very hard for me to believe that the source analysis does have so strong assumptions such that it can be in such strong contrast to my power data.

If I am correct, what I input into the source analyses (apart from my models) for conditions A and B are 1) the corresponding power matrix (64 channels x 1 power value) and the CSD (2016 * 1). It could of course be that the source analysis is very sensitive to the large abs differences in power/CSD data between electrodes. However, I also used cfg.supchan (suppressing specific channels) in the source analysis for the 2 channels that were „off“ to see whether this makes it different.However, the source result is similar.

Any comment is appreciated.   All plots, data and scripts are at (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).

Best, Patrick

%%

cfg                  = [];
cfg.headmodel        = vol;
cfg.elec             = elec_aligned;
cfg.reducerank       = 2;
cfg.resolution       = 1;
sourcemodel_beta = ft_prepare_leadfield(cfg,data_beta);

%%

cfg              = [];
cfg.method       = 'dics';
cfg.sourcemodel  = sourcemodel_beta;
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.frequency    = 28;
cfg.dics.projectnoise = 'yes';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
sourceAll_beta = ft_sourceanalysis(cfg, data_beta);

%%

cfg              = [];
cfg.method       = 'dics';
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.dics.projectnoise = 'yes';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
cfg.sourcemodel  = sourcemodel_beta;
cfg.sourcemodel.filter = sourceAll_beta.avg.filter;

source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);


%%

sourceNAI1 = source_beta_1;
sourceNAI1.avg.pow = source_beta_1.avg.pow ./ source_beta_1.avg.noise;

sourceNAI0 = source_beta_0;
sourceNAI0.avg.pow = source_beta_0.avg.pow ./ source_beta_0.avg.noise;

cfg            = [];
cfg.parameter = 'pow';
cfg.operation = 'x1./x2';
sourceDiff_beta_rel = ft_math(cfg, source_beta_1,source_beta_0);

cfg            = [];
cfg.parameter = 'pow';
cfg.operation = 'x1 - x2';
sourceDiff_beta_abs = ft_math(cfg, source_beta_1,source_beta_0);

%%
cfg            = [];
cfg.downsample = 2;
cfg.parameter  = 'pow';
sourceDiffInt_beta_dif_rel  = ft_sourceinterpolate(cfg, sourceDiff_beta_rel , mri_realigned);
sourceDiffInt_beta_dif_abs  = ft_sourceinterpolate(cfg, sourceDiff_beta_abs , mri_realigned);
sourceDiffInt_beta_dif_0  = ft_sourceinterpolate(cfg, sourceNAI0 , mri_realigned);
sourceDiffInt_beta_dif_1  = ft_sourceinterpolate(cfg, sourceNAI1 , mri_realigned);

%%
maxval_beta_rel = max(sourceDiffInt_beta_dif_rel.pow);
maxval_beta_abs = max(sourceDiffInt_beta_dif_abs.pow);

%%
cfg = [];
cfg.nonlinear     = 'no';
sourceDiffIntNorm_beta_dif_rel = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_rel);
sourceDiffIntNorm_beta_dif_abs = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_abs);
sourceDiffIntNorm_beta_dif_0 = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_0);
sourceDiffIntNorm_beta_dif_1 = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_1);

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

Am 19.11.2020 um 14:59 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Dear Patrick,

Nice to see you are progressing. The TFR topoplots look nice (and the effect seems even stronger in the mtmfft version)!

I agree the source reconstruction looks pretty iffy. A single dot like that shouldn't be there - no source in Beamformer is so focal. It suggests something is off, which could be as simple as a single electrode doing something weird (given how focal and superficial the artefact is).

I would take another step back;
I would first look at the distribution of your absolute beta, i.e. without baseline correction. For both conditions.
I would then look at the distribution of your baseline beta, i.e. only your baseline. For both conditions.
You should satisfy yourself that the results make sense, i.e. nothing too drastic, focal, etc., and some density of beta power around the central sulcus (?).

Now I understand your contrast better, I have to ask why you do the baseline correction as you do. In this way you are using a separate BL for each condition, meaning that after BL-correction you are actually also comparing BL as much as you are comparing post-BL activity - after BL-correction any differences in BL become difference in your active period.
If you assume differences in BL you might want to compare those separately before you 'add' them to your active period. If you have a randomized design, you might not want to do any BL correction in your contrast at all. Also, if there are no differences in BL, then it would make no difference...
So, when you have a good sense of the absolute values and source distributions, you might want to try just comparing active period A vs B, relative (/) or absolute (-), and forget about the BL. Sometimes the BL is more noisy than the active period even.

Anyway, your script looks fine to me, but it's been a while. However, I suspect that one of your datasets (A, A_BL, B, or B_BL) has some artefact that is introduced in the contrast.

Cheers,
Stephen











Op do 19 nov. 2020 om 13:27 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear fieldtrip community,

first of all, thank you for your valuable responses @Tzvetan and Stephen. They were both very helpful and got me to dig deeper into the analysis.

You were absolutely right in describing my approach for my Morlet wavelet TF analysis. The data were baseline corrected (in db). When contrasting the 2 conditions of interest, I receive the attached figure (dif_morlet). After your responses, I took the same approach for the mtmfft data with cfg.tapsmofrq = 8 (center frequency at 28 Hz) to reproduce the effect that I found between 20-35 Hz in the morlet wavelet analyses. I calculated frequency analysis (mtmfft) for both conditions (data_1, data_0) and their baseline periods (data_1_bas, data_0_bas) separately and then „baseline corrected“ the data from both conditions (also in db, see dif_mtmfft). The differences between conditions are now very similar between both approaches (morlet vs mtmfft).

In the next step. I followed your advice and performed source analyses of frequency_data for all 4 conditions separately (pow_1, pow_0, pow_1_baseline, pow_0_baseline) as well as from all_data from ft_appenddata. For the source_analyses from all 4 conditions, I am using the common filter from all_data as well as the source model (ft_prepare_leadfieldds) from all_data. After performing the ft_source_analysis function for all 4 conditions, I am trying to replicate what I have done with the power data ( in db). For this reason, I am using ft_math with source_1_dif = 10*log10 (source_1/source_1_baseline) and the same for source_0. After this, I am subtracting source_0_dif from source_1_dif as done during the frequency analysis yielding my final source data.

After interpolating the source differences, I am using ft_volumenormalise. The result from this approach is attached in dif_sources.

I am a bit puzzled since I would not expect these source data based on my power mtmfft data. I made sure that the coordinate systems and units are the same across models (volume_conduction_model, electrodes, MRI) but I am wondering whether I am doing something wrong in performing the source_analysis or whether the source results are reasonable.

Again, I uploaded the script and the data such that my analysis pipeline could be reproduced by everyone who is interested (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation). Below, I am attaching the code for the source_analyses steps. Any comments on my results or approach are welcome.

All the Best from Germany,
Patrick



.






cfg              = [];
cfg.method       = 'dics';
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.dics.projectnoise = 'yes';
cfg.dics.lambda       = '5%';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
cfg.sourcemodel  = sourcemodel_beta;
source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
source_beta_1_bas = ft_sourceanalysis(cfg, data_beta_1_bas);
source_beta_0_bas = ft_sourceanalysis(cfg, data_beta_0_bas);


%%
cfg            = [];
cfg.parameter = 'pow';
cfg.operation = '10*log10(x1/x2)';
sourceDiff1_beta = ft_math(cfg, source_beta_1,source_beta_1_bas);
sourceDiff0_beta = ft_math(cfg, source_beta_0,source_beta_0_bas);

sourceDiff_beta_dif = sourceDiff1_beta;
sourceDiff_beta_dif.pow = sourceDiff1_beta.pow - sourceDiff0_beta.pow;

%%
cfg            = [];
cfg.downsample = 2;
cfg.parameter  = 'pow';
sourceDiffInt_beta_dif  = ft_sourceinterpolate(cfg, sourceDiff_beta_dif , mri_realigned);

%%
maxval_beta = max(sourceDiffInt_beta_dif.pow);
%%
cfg = [];
cfg.nonlinear     = 'no';

sourceDiffIntNorm_beta_dif = ft_volumenormalise(cfg, sourceDiffInt_beta_dif);

%%
cfg = [];
cfg.method        = 'ortho';
cfg.interactive   = 'yes';
cfg.funparameter  = 'pow';
cfg.maskparameter = cfg.funparameter;
cfg.funcolorlim   = [0.0 maxval_beta];
cfg.opacitylim    = [0.0 maxval_beta];
cfg.opacitymap    = 'rampup';
ft_sourceplot(cfg, sourceDiffIntNorm_beta_dif);
%%


Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 13.11.2020 um 12:48 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Hi Patrick, (and Tzvetan - who responded in the meantime),

I agree that you should start with a good correspondence between your initial results (wavelets), and the power difference you are trying to localize (with mtmfft).

Wavelets and fft methods can result in very similar - practically identical - results, but that depends on a number of parameters, especially concerning frequency-smoothing; Wavelets are typically defined in terms of nr. of cycles, while fft methods are defined in terms of time-windows. Wavelets defined in nr. of cycles will have a decreasing time-windows with increasing frequency, while with mtmfft time windows will remain the same. Because of this, frequency smoothing will increase with frequency with wavelets, and stay the same with a constant time window. Of course, you can make the fft time window frequency-dependent, as is described in the frequency-analyses tutorial, to make them more comparable. Secondly, the fft method allows you to specify frequency smoothing when you use Sleppian multitapers (cfg.taper = 'dpss'). To be clear, you should be able to recognize these differences in frequency smoothing/resolution when looking at the different TFR plots. Currently they look too different, probably because of something else (baseline?) than a wavelet-fft difference.

I would advise making a 'full' TFR with mtmfft similar as your wavelet results so that you can properly compare them. This allows you to also set the best parameters for smoothing/timeperiods. In fact, you can use the multitaper approach to more accurately extract the power in a certain frequency band. Only then compare the topo's, and only then do the beamformer, so you will pick up any unexpected results.

Because of different contrasts/baseline correction, I cannot compare the topo's / beamformer results.

Bon courage,
Stephen









Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear Field-trip community,

I am working on EEG data from a motor learning task. in the first part of my analysis, I performed a time-frequency analysis (Morlet wavelet method) and cluster-based permutation test. I compared two different conditions (correct & incorrect movements) within subjects and found a significant difference in the beta band (20-35 Hz) when subjects were provided with feedback. I attached the topographical plot from one subject that illustrates the difference between the conditions at the selected time point and frequency (dif_morlet). As you can see, beta power was higher in one condition in lateral frontal electrodes.

Now, I would like to better spatially locate the effect for this single subject. For this purpose, I followed the Beamformer tutorial on the website. In the first step, I selected the raw data of interest (at the time where the effect was seen) and performed frequency analyses for the 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft). There is an apparent difference between dif_morlet and dif_mtmfft and I am wondering why this is the case? One apparent reason is that the time-frequency data were baseline corrected and the frequency data from mtmfft not.

Using the power and CSD data from mtmfft, I performed the source analysis with a standard MRI and head model. The source was located in the left hemisphere (source plot), which is in stark contrast to the time-frequency data (dif_morlet). I am aware that the source analysis is based on a lot of assumptions (conductivity etc.) that influence the calculations but it is very difficult to make sense of such discrepancy.
Maybe it is necessary to also baseline correct the mtmfft data before inputting them to the source analysis? Or doing the contrasting source localization betwee a single condition and the corresponding baseline data before contrasting the 2 conditions?

I am providing all necessary files and scripts (TF_analysis & BEAMFORMER) if anyone is interested to reproduce the results that I am showing and reporting for this single subject (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).

I would appreciate any help and discussion on that.

All the best,
Patrick





Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/2ab40d49/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: morlet_dif.eps
Type: application/postscript
Size: 173198 bytes
Desc: morlet_dif.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/2ab40d49/attachment.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtmfft_dif.eps
Type: application/postscript
Size: 170765 bytes
Desc: mtmfft_dif.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/2ab40d49/attachment-0001.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source_rel.eps
Type: application/postscript
Size: 265307 bytes
Desc: source_rel.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/2ab40d49/attachment-0002.eps>

From stephen.whitmarsh at gmail.com  Fri Nov 20 13:02:19 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Fri, 20 Nov 2020 13:02:19 +0100
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <BB83D822-468A-4C28-AF6F-BE2807F76DBB@sport.uni-freiburg.de>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
 <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
 <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>
 <CAFrxm=wdQ1qSnWkRk+Bkb+nY14WaJEwkRCf89PaCevU6amTg7g@mail.gmail.com>
 <BB83D822-468A-4C28-AF6F-BE2807F76DBB@sport.uni-freiburg.de>
Message-ID: <CAFrxm=yjQ6th0_=07bjUWYkAbOVDoYpQ7Aa8+jVmfBHi6k0-ng@mail.gmail.com>

Hi Patrick,

Things are becoming clearer now, good to see.

So yes, that artefact in the back of the head: I would definitely take care
of that. Maybe do another run of (visual) artefact rejection, or remove
those channels.
That the effect is less apparent in the relative difference is not
surprising as the absolute differences are expected to be bigger than on
other channels due to large amplitudes of the artefacts, which will be
'normalized' over channels when using a relative difference.

I would be careful about interpreting left-right on the plot. Note that you
assume you are looking from the top/front of the head downwards/backwards -
but there is no way of confirming that based on the picture! People often
place some kind of marker on the left or right side of the head when doing
an MRI scan - e.g. a vitamin D (?) capsule I think so that one can verify
the radiological versus anatomical (?) representation (LR is flipped in
radiological plots). You could do this once, and verify your pipeline, if
you want to be 100% sure.

Lastly, it seems that the source picture could benefit from using a
slightly larger beamformer scanning grid so to overlap more with the edge
of the brain/skull. I used to do that using a negative value for the inward
shift parameter (cfg.inwardshift) in ft_prepare_sourcemodel. Maybe there is
an easy way for you to do that in your pipeline as well.

Looking good!
Stephen





Op vr 20 nov. 2020 om 12:31 schreef Patrick Wiegel <
patrick.wiegel at sport.uni-freiburg.de>:

> Dear Stephen,
>
> thanks for the response.
>
> I followed your suggestions and attached the plots. I performed Morlet
> wavelets TF analyses and mtmfft for conditions A and B. I did not use a
> baseline correction to see whether this is necessary. As you can see in the
> topographical plots, both conditions (A and B) have high power in 2
> posterior electrodes (I guess some kind of artifact or noise is the
> reason). Using the abs. difference between A and B does not get rid of that
> fact, probably because one condition is more affected than the other. Using
> the rel. difference does a better job and resembles my previous
> baseline-corrected results. I also compared the baselines and they were not
> different. The two conditions were furthermore randomized within the same
> protocol. I assume that adding a baseline is thus unnecessary.
>
> Regarding the source_analysis, the results for individual conditions A and
> B (NAI) as well as abs dif between A and B look weird again. But that’s
> very likely due to the same problem as for the power. For rel dif between A
> and B, the source plot seems more reasonable, although I expect the source
> to be in the right hemisphere and not in the left as shown in the plot. I
> controlled that all my input data (electrodes, volume condition model, MRI)
> have the same definition of the axes (x+ pointing right, y+ pointing
> anterior, z+ pointing superior) so I don’t think there is a right-left
> mix-up!?
>
> Now I am wondering whether I have to accept the result for the rel
> difference in sources between A and B (which is very hard to interpret and
> justify after what I am observing in the TF analysis, namely an effect in
> the other hemisphere) or whether there might be still some issue in my
> approach. It is very hard for me to believe that the source analysis does
> have so strong assumptions such that it can be in such strong contrast to
> my power data.
>
> If I am correct, what I input into the source analyses (apart from my
> models) for conditions A and B are 1) the corresponding power matrix (64
> channels x 1 power value) and the CSD (2016 * 1). It could of course be
> that the source analysis is very sensitive to the large abs differences in
> power/CSD data between electrodes. However, I also used cfg.supchan
> (suppressing specific channels) in the source analysis for the 2 channels
> that were „off“ to see whether this makes it different.However, the source
> result is similar.
>
> Any comment is appreciated.   All plots, data and scripts are at (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>
> Best, Patrick
>
> %%
>
> cfg                  = [];
> cfg.headmodel        = vol;
> cfg.elec             = elec_aligned;
> cfg.reducerank       = 2;
> cfg.resolution       = 1;
> sourcemodel_beta = ft_prepare_leadfield(cfg,data_beta);
>
> %%
>
> cfg              = [];
> cfg.method       = 'dics';
> cfg.sourcemodel  = sourcemodel_beta;
> cfg.headmodel    = vol;
> cfg.elec         = elec_aligned;
> cfg.frequency    = 28;
> cfg.dics.projectnoise = 'yes';
> cfg.dics.keepfilter   = 'yes';
> cfg.dics.realfilter   = 'yes';
> sourceAll_beta = ft_sourceanalysis(cfg, data_beta);
>
> %%
>
> cfg              = [];
> cfg.method       = 'dics';
> cfg.headmodel    = vol;
> cfg.elec         = elec_aligned;
> cfg.dics.projectnoise = 'yes';
> cfg.dics.keepfilter   = 'yes';
> cfg.dics.realfilter   = 'yes';
> cfg.sourcemodel  = sourcemodel_beta;
> cfg.sourcemodel.filter = sourceAll_beta.avg.filter;
>
> source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
> source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
>
>
> %%
>
> sourceNAI1 = source_beta_1;
> sourceNAI1.avg.pow = source_beta_1.avg.pow ./ source_beta_1.avg.noise;
>
> sourceNAI0 = source_beta_0;
> sourceNAI0.avg.pow = source_beta_0.avg.pow ./ source_beta_0.avg.noise;
>
> cfg            = [];
> cfg.parameter = 'pow';
> cfg.operation = 'x1./x2';
> sourceDiff_beta_rel = ft_math(cfg, source_beta_1,source_beta_0);
>
> cfg            = [];
> cfg.parameter = 'pow';
> cfg.operation = 'x1 - x2';
> sourceDiff_beta_abs = ft_math(cfg, source_beta_1,source_beta_0);
>
> %%
> cfg            = [];
> cfg.downsample = 2;
> cfg.parameter  = 'pow';
> sourceDiffInt_beta_dif_rel  = ft_sourceinterpolate(cfg,
> sourceDiff_beta_rel , mri_realigned);
> sourceDiffInt_beta_dif_abs  = ft_sourceinterpolate(cfg,
> sourceDiff_beta_abs , mri_realigned);
> sourceDiffInt_beta_dif_0  = ft_sourceinterpolate(cfg, sourceNAI0 ,
> mri_realigned);
> sourceDiffInt_beta_dif_1  = ft_sourceinterpolate(cfg, sourceNAI1 ,
> mri_realigned);
>
> %%
> maxval_beta_rel = max(sourceDiffInt_beta_dif_rel.pow);
> maxval_beta_abs = max(sourceDiffInt_beta_dif_abs.pow);
>
> %%
> cfg = [];
> cfg.nonlinear     = 'no';
> sourceDiffIntNorm_beta_dif_rel = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif_rel);
> sourceDiffIntNorm_beta_dif_abs = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif_abs);
> sourceDiffIntNorm_beta_dif_0 = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif_0);
> sourceDiffIntNorm_beta_dif_1 = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif_1);
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> Am 19.11.2020 um 14:59 schrieb Stephen Whitmarsh <
> stephen.whitmarsh at gmail.com>:
>
> Dear Patrick,
>
> Nice to see you are progressing. The TFR topoplots look nice (and the
> effect seems even stronger in the mtmfft version)!
>
> I agree the source reconstruction looks pretty iffy. A single dot like
> that shouldn't be there - no source in Beamformer is so focal. It suggests
> something is off, which could be as simple as a single electrode doing
> something weird (given how focal and superficial the artefact is).
>
> I would take another step back;
> I would first look at the distribution of your absolute beta, i.e. without
> baseline correction. For both conditions.
> I would then look at the distribution of your baseline beta, i.e. only
> your baseline. For both conditions.
> You should satisfy yourself that the results make sense, i.e. nothing too
> drastic, focal, etc., and some density of beta power around the central
> sulcus (?).
>
> Now I understand your contrast better, I have to ask why you do the
> baseline correction as you do. In this way you are using a separate BL for
> each condition, meaning that after BL-correction you are actually also
> comparing BL as much as you are comparing post-BL activity - after
> BL-correction any differences in BL become difference in your active
> period.
> If you assume differences in BL you might want to compare those separately
> before you 'add' them to your active period. If you have a randomized
> design, you might not want to do any BL correction in your contrast at all.
> Also, if there are no differences in BL, then it would make no difference...
> So, when you have a good sense of the absolute values and source
> distributions, you might want to try just comparing active period A vs B,
> relative (/) or absolute (-), and forget about the BL. Sometimes the BL is
> more noisy than the active period even.
>
> Anyway, your script looks fine to me, but it's been a while. However, I
> suspect that one of your datasets (A, A_BL, B, or B_BL) has some artefact
> that is introduced in the contrast.
>
> Cheers,
> Stephen
>
>
>
>
>
>
>
>
>
>
>
> Op do 19 nov. 2020 om 13:27 schreef Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de>:
>
> Dear fieldtrip community,
>
> first of all, thank you for your valuable responses @Tzvetan and Stephen.
> They were both very helpful and got me to dig deeper into the analysis.
>
> You were absolutely right in describing my approach for my Morlet wavelet
> TF analysis. The data were baseline corrected (in db). When contrasting the
> 2 conditions of interest, I receive the attached figure (dif_morlet). After
> your responses, I took the same approach for the mtmfft data
> with cfg.tapsmofrq = 8 (center frequency at 28 Hz) to reproduce the effect
> that I found between 20-35 Hz in the morlet wavelet analyses. I
> calculated frequency analysis (mtmfft) for both conditions (data_1, data_0)
> and their baseline periods (data_1_bas, data_0_bas) separately and then
> „baseline corrected“ the data from both conditions (also in db, see
> dif_mtmfft). The differences between conditions are now very similar
> between both approaches (morlet vs mtmfft).
>
> In the next step. I followed your advice and performed source analyses of
> frequency_data for all 4 conditions separately (pow_1, pow_0,
> pow_1_baseline, pow_0_baseline) as well as from all_data from
> ft_appenddata. For the source_analyses from all 4 conditions, I am using
> the common filter from all_data as well as the source model
> (ft_prepare_leadfieldds) from all_data. After performing the
> ft_source_analysis function for all 4 conditions, I am trying to replicate
> what I have done with the power data ( in db). For this reason, I am using
> ft_math with source_1_dif = 10*log10 (source_1/source_1_baseline) and the
> same for source_0. After this, I am subtracting source_0_dif
> from source_1_dif as done during the frequency analysis yielding my final
> source data.
>
> After interpolating the source differences, I am using ft_volumenormalise.
> The result from this approach is attached in dif_sources.
>
> I am a bit puzzled since I would not expect these source data based on my
> power mtmfft data. I made sure that the coordinate systems and units are
> the same across models (volume_conduction_model, electrodes, MRI) but I am
> wondering whether I am doing something wrong in performing the
> source_analysis or whether the source results are reasonable.
>
> Again, I uploaded the script and the data such that my analysis pipeline
> could be reproduced by everyone who is interested (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
> Below, I am attaching the code for the source_analyses steps. Any comments
> on my results or approach are welcome.
>
> All the Best from Germany,
> Patrick
>
>
>
> .
>
>
>
>
>
>
> cfg              = [];
> cfg.method       = 'dics';
> cfg.headmodel    = vol;
> cfg.elec         = elec_aligned;
> cfg.dics.projectnoise = 'yes';
> cfg.dics.lambda       = '5%';
> cfg.dics.keepfilter   = 'yes';
> cfg.dics.realfilter   = 'yes';
> cfg.sourcemodel  = sourcemodel_beta;
> source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
> source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
> source_beta_1_bas = ft_sourceanalysis(cfg, data_beta_1_bas);
> source_beta_0_bas = ft_sourceanalysis(cfg, data_beta_0_bas);
>
>
> %%
> cfg            = [];
> cfg.parameter = 'pow';
> cfg.operation = '10*log10(x1/x2)';
> sourceDiff1_beta = ft_math(cfg, source_beta_1,source_beta_1_bas);
> sourceDiff0_beta = ft_math(cfg, source_beta_0,source_beta_0_bas);
>
> sourceDiff_beta_dif = sourceDiff1_beta;
> sourceDiff_beta_dif.pow = sourceDiff1_beta.pow - sourceDiff0_beta.pow;
>
> %%
> cfg            = [];
> cfg.downsample = 2;
> cfg.parameter  = 'pow';
> sourceDiffInt_beta_dif  = ft_sourceinterpolate(cfg, sourceDiff_beta_dif ,
> mri_realigned);
>
> %%
> maxval_beta = max(sourceDiffInt_beta_dif.pow);
> %%
> cfg = [];
> cfg.nonlinear     = 'no';
>
> sourceDiffIntNorm_beta_dif = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif);
>
> %%
> cfg = [];
> cfg.method        = 'ortho';
> cfg.interactive   = 'yes';
> cfg.funparameter  = 'pow';
> cfg.maskparameter = cfg.funparameter;
> cfg.funcolorlim   = [0.0 maxval_beta];
> cfg.opacitylim    = [0.0 maxval_beta];
> cfg.opacitymap    = 'rampup';
> ft_sourceplot(cfg, sourceDiffIntNorm_beta_dif);
> %%
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> Am 13.11.2020 um 12:48 schrieb Stephen Whitmarsh <
> stephen.whitmarsh at gmail.com>:
>
> Hi Patrick, (and Tzvetan - who responded in the meantime),
>
> I agree that you should start with a good correspondence between your
> initial results (wavelets), and the power difference you are trying to
> localize (with mtmfft).
>
> Wavelets and fft methods can result in very similar - practically
> identical - results, but that depends on a number of parameters, especially
> concerning frequency-smoothing; Wavelets are typically defined in terms of
> nr. of cycles, while fft methods are defined in terms of time-windows.
> Wavelets defined in nr. of cycles will have a decreasing time-windows with
> increasing frequency, while with mtmfft time windows will remain the same.
> Because of this, frequency smoothing will increase with frequency with
> wavelets, and stay the same with a constant time window. Of course, you can
> make the fft time window frequency-dependent, as is described in the
> frequency-analyses tutorial, to make them more comparable. Secondly, the
> fft method allows you to specify frequency smoothing when you use Sleppian
> multitapers (cfg.taper = 'dpss'). To be clear, you should be able to
> recognize these differences in frequency smoothing/resolution when looking
> at the different TFR plots. Currently they look too different, probably
> because of something else (baseline?) than a wavelet-fft difference.
>
> I would advise making a 'full' TFR with mtmfft similar as your wavelet
> results so that you can properly compare them. This allows you to also set
> the best parameters for smoothing/timeperiods. In fact, you can use the
> multitaper approach to more accurately extract the power in a certain
> frequency band. Only then compare the topo's, and only then do the
> beamformer, so you will pick up any unexpected results.
>
> Because of different contrasts/baseline correction, I cannot compare the
> topo's / beamformer results.
>
> Bon courage,
> Stephen
>
>
>
>
>
>
>
>
>
> Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de>:
>
> Dear Field-trip community,
>
> I am working on EEG data from a motor learning task. in the first part of
> my analysis, I performed a time-frequency analysis (Morlet wavelet method)
> and cluster-based permutation test. I compared two different conditions
> (correct & incorrect movements) within subjects and found a significant
> difference in the beta band (20-35 Hz) when subjects were provided with
> feedback. I attached the topographical plot from one subject that
> illustrates the difference between the conditions at the selected time
> point and frequency (dif_morlet). As you can see, beta power was higher in
> one condition in lateral frontal electrodes.
>
> Now, I would like to better spatially locate the effect for this single
> subject. For this purpose, I followed the Beamformer tutorial on the
> website. In the first step, I selected the raw data of interest (at the
> time where the effect was seen) and performed frequency analyses for the
> 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft).
> There is an apparent difference between dif_morlet and dif_mtmfft and I am
> wondering why this is the case? One apparent reason is that the
> time-frequency data were baseline corrected and the frequency data from
> mtmfft not.
>
> Using the power and CSD data from mtmfft, I performed the source analysis
> with a standard MRI and head model. The source was located in the left
> hemisphere (source plot), which is in stark contrast to the time-frequency
> data (dif_morlet). I am aware that the source analysis is based on a lot of
> assumptions (conductivity etc.) that influence the calculations but it is
> very difficult to make sense of such discrepancy.
> Maybe it is necessary to also baseline correct the mtmfft data before
> inputting them to the source analysis? Or doing the contrasting source
> localization betwee a single condition and the corresponding baseline data
> before contrasting the 2 conditions?
>
> I am providing all necessary files and scripts (TF_analysis & BEAMFORMER)
> if anyone is interested to reproduce the results that I am showing and
> reporting for this single subject (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>
> I would appreciate any help and discussion on that.
>
> All the best,
> Patrick
>
>
>
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/a2bbe8e3/attachment.htm>

From simeon.wong at sickkids.ca  Fri Nov 20 16:02:42 2020
From: simeon.wong at sickkids.ca (Simeon Wong)
Date: Fri, 20 Nov 2020 15:02:42 +0000
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than
 Maximum\n
In-Reply-To: <1642a8d00a9247da85aa52777c9a1aca@ae.mpg.de>
References: <63425210-9257-4B41-88A4-CCD000361C6A@gmail.com>
 <YTOPR0101MB0988643DDCCC1640CEDC7B56FDE10@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>
 <03559953-E06B-4EA4-9329-8D0D5002F0C5@gmail.com>
 <55d2470b820e4801a92e8216c2253e52@ae.mpg.de>,
 <1642a8d00a9247da85aa52777c9a1aca@ae.mpg.de>
Message-ID: <YTOPR0101MB09884E87ADF6B6A3EB9D58B6FDFF0@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>

Hi Alex and Katarina,

According to the EDF standard, inverted physical min/max values are used to implement the negative-up convention in clinical neurophysiology: https://www.edfplus.info/specs/edfplus.html#:~:text=5.%20'Digital%20maximum'%20must%20be%20larger,by%200'%20errors%20by%20some%20viewers).

Therefore, it would appear (without further evidence to the contrary) that your data is ok, and the headers are simply indicating a negative gain.

If you're trying to only copy the data, I'd suggest doing it digitally (ie. without any conversion into physical units) using lower-level functions. This will ensure the data is not "altered". In our lab, we also have a similar use case where we extract only scalp electrodes during specified times into separate EDF files. We do this in Python using pyedflib, mainly because some of our other analysis code was already in Python, not for any particular advantage of the language or toolbox over Fieldtrip: https://gist.github.com/dtxe/a74bd43f4106281b86b9171bf5efe73d

I'm speculating the reason the data changes after the 2nd decimal place is due to rounding:

  1.  Data is stored in EDF format as 16-bit integers (ref)<https://www.edfplus.info/specs/edf.html#:~:text=each%20sample%20value%20is%20represented%20as%20a%202%2Dbyte%20integer>
  2.  On import, the data is converted into physical units using digital min/max, physical min/max
  3.  On export, the data is converted back into digital units
     *   The header field for physical min/max only accommodates 8 characters, hence lines 91-95
     *   Fieldtrip optimizes the dynamic range by using the physical signal's min/max, which is likely different than the original EDF file's physical min/max
     *   After converting back into digital units, the data is rounded to the nearest int16.


I hope this helps,

Simeon





[cid:2cc287ba-1b09-4751-9231-2940fe7f4f40]

Simeon Wong

Ibrahim Lab

Neurosciences & Mental Health


686 Bay Street, Toronto ON  M5G 0A4

P 416.813.7654  x303697

________________________________
From: fieldtrip <fieldtrip-bounces at science.ru.nl> on behalf of Lepauvre, Alex <alex.lepauvre at ae.mpg.de>
Sent: November 20, 2020 06:12
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n


Dear Fieldtrip community,



Following on the messages below, I performed comparison between the saved signal and the original signal. To give a little more context, our single goal here is to load our EDF signal in fieldtrip to then chop it into pieces to be able to save each piece separately. We are required to do so as we are having very long EDFs and because we have to format our data in these specific pieces for data ingestion in XNAT.



The written function (see attached) loads the EDF of interest and using a photodiode trigger channel, we parse our signal in “blocks”, enabling the user of the code to adjust detected onsets manually to account for misdetection by our algorithm. The EDF signal is cut from onsets to onsets and stored in separated files. We need to make sure that this procedure doesn’t alter our raw signal in any ways. To check whether this happens, following the data saving, the saved data are being reloaded and compared to the original data that were parsed. If the comparison yields anything else than 0s, then it means that the data were altered in some way.



When running the function, the first thing I notice is that following saving, the size of the signal.trial{1,1} matrices has been changed. Following some digging in the edf write function, I noticed that the data are being saved to the EDF in 1 seconds chunks, while it is not in our original signal (0.625seconds instead). I assume that this is not a big deal as this doesn’t really alter the data. However, what I believe is problematic is that the signal gets altered after the second decimal place across all channels. I am assuming that this has something to do with the conversion to uint16? I am a bit puzzled about why this is the case and how we can get around this issue to save our data and keep them pristine. Has anyone been encountering similar issues and/or knows a way?



Kind regards,



Alex



From: fieldtrip <fieldtrip-bounces at science.ru.nl> On Behalf Of Lepauvre, Alex
Sent: Thursday, 19 November 2020 14:01
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n



Dear Simeon, deaf Fieldtrip community



Thanks a lot for your helpful feedback. To give you a little bit more context, our EDFs are from iEEG data.  I have been digging a little bit more into this issue with our data. First of all, it turns out that the warning isn’t thrown by the opnedEDF function, but by the read_edf.m one. It seems that in our files, the accessed PhysMin and PhysMax are reversed. Indeed, most values in the PhysMax are negative (-8711uV, except for some misc channels), while the PhysMin is the exact opposite (+8711), which seems to be the prime reason for this error.  I am not sure why that is the case. According to what you were saying @Simeon, this might be due to our EDF export software doing something odd with the headers? Can this harm our data?



Also, another aspect I am confused about is that we are currently using fieldtrip to chop our single big EDFs into smaller more manageable files. We therefore load the data triggering the warning, then chop them and adjust the headers, and save the chunks separately. However, when reloading the newly saved data, the warning isn’t there anymore, which has me worried that the data have been altered in some way.

After digging in the function write_edf a little bit more, I am supposing that the issue doesn’t appear anymore because fieldtrip compute the max and min amplitude of the signal, and fill it in in the PhyMax and PhysMin headers itself, correct?



Finally, another issue we are facing is that for some of our EDF files, the write_EDF function doesn’t work with some of our EDFs (I am unfortunately not allowed to share any data due to strong data privacy policies In our project, my apologies). While for some of our files it did work, for at least one, the write_edf returns the following error:

[cid:image003.jpg at 01D6BF33.9D87D350]



I again dived into the function write_edf and located the issue here:



[cid:image005.jpg at 01D6BF33.9D87D350]

I am not entirely sure what the purpose of these statements is. It seems to reduce the decimal places of the physical minimum (and then maximum) to find which approximation fits the expected size (8*nchans). However, none of the 5 options fit. Surprisingly enough, going one more would work: in my signal %-8.2g fits exactly nchans*8. I am not sure why that is the case nor what it would entail for my data if I were to change it in the code myself. Could someone enlighten me?



From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> On Behalf Of Katarina Bendtz
Sent: Wednesday, 18 November 2020 20:20
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n



Dear Simeon!



Thank you so much for your quick reply! I understand!



Do you think I can safely ignore this or should I try to find out which channels this applies to? That is, if the trigger channels are set to identical values, will this in some way compromise/change the data?



best,

Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA







On Nov 18, 2020, at 1:22 PM, Simeon Wong <simeon.wong at sickkids.ca<mailto:simeon.wong at sickkids.ca>> wrote:



Hi Katarina,



The fread command advances the file pointer. Therefore the 4 lines are reading consecutive values from the EDF file.

https://www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle#d122e421874:~:text=and%20positions%20the%20file%20pointer%20after%20the%20last%20value%20read<https://urldefense.com/v3/__https://www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle*d122e421874:*:text=and*20positions*20the*20file*20pointer*20after*20the*20last*20value*20read__;I34lJSUlJSUlJSU!!D0zGoin7BXfl!r4QJaRIZ-3FdVMHleuLbLlEDUz6WEdLbbNCQa6ENyxDrfsWOU5abThVtTfOyf5ZSROzo$>



With that being said, some EDF export software (for better or for worse) set identical physical values if channels are switched off or for channels without physical units (ie. trigger channels or misc channels).









All the best,

Simeon





<Outlook-gb44xqtx.png>

Simeon Wong

Ibrahim Lab

Neurosciences & Mental Health



686 Bay Street, Toronto ON  M5G 0A4

P 416.813.7654  x303697



________________________________

From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> on behalf of Katarina Bendtz <katarina.bendtz at gmail.com<mailto:katarina.bendtz at gmail.com>>
Sent: November 18, 2020 12:50
To: fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl> <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n



Dear experts:

Me and my colleague at another university idependently I get this warning when we try to open an edf file:



Warning OPENEDF: Physical

Minimum larger than Maximum\n





I’m using fieldtrip 2020113. Looking at the source code

https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m<https://urldefense.com/v3/__https:/github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m__;!!D0zGoin7BXfl!tHOzBhC87IDZICVPmzh1QeJQI1pBz7wzlyRm7uCUqe_WlgHxjVh2sShWYk0yjAhO9UAo$>



I read:



if (any(EDF.PhysMin >= EDF.PhysMax))



fprintf(2,'Warning OPENEDF: Physical Minimum larger than Maximum\n');



EDF.PhysMin = EDF.DigMin;



        EDF.PhysMax = EDF.DigMax;



end



but then a couple of lines up, I see both EDF.PhysMin and EDF.PhysMax, (and also EDF.DigMin and EDF.DigMax) being set to the same thing:



EDF.PhysMin= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));

EDF.PhysMax= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));

EDF.DigMin = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %

EDF.DigMax = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %



So it is quite reasonable that I will get this warning. I’m puzzled.



1. What’s purpose of this warning?

2. Why are the variables set to the same value?

3. Can I safely ignore this warning?

4. Or is there something I misunderstood.



Thanks a lot,



Best,

Kat




Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA









________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip<https://urldefense.com/v3/__https://mailman.science.ru.nl/mailman/listinfo/fieldtrip__;!!D0zGoin7BXfl!r4QJaRIZ-3FdVMHleuLbLlEDUz6WEdLbbNCQa6ENyxDrfsWOU5abThVtTfOyf5sM8xsl$>
https://doi.org/10.1371/journal.pcbi.1002202<https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!D0zGoin7BXfl!r4QJaRIZ-3FdVMHleuLbLlEDUz6WEdLbbNCQa6ENyxDrfsWOU5abThVtTfOyfw9x0Kj7$>



________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/53c652af/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 69416 bytes
Desc: image003.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/53c652af/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 94776 bytes
Desc: image005.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/53c652af/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-53mcdynt.png
Type: image/png
Size: 1756 bytes
Desc: Outlook-53mcdynt.png
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/53c652af/attachment.png>

From martin.j.p.gallagher at gmail.com  Fri Nov 20 20:07:11 2020
From: martin.j.p.gallagher at gmail.com (Martin Gallagher)
Date: Fri, 20 Nov 2020 13:07:11 -0600
Subject: [FieldTrip] Cluster based permutation post-hoc after
 ft_statfun_indepsamplesF
Message-ID: <CAO-CxMBvTywxjrhSanqfNS_NhVTCFbtBz2TNHnbhzQwbtSckwQ@mail.gmail.com>

Hello,

This is my first post to the group. I've Googled this question and have
seen it asked, but I'm still unsure of the definitive answer.

I have time frequency analyses of three groups (three seizure types --
absence, myoclonic, and tonic).  I am performing independent comparisons
tests of the three groups.  The data are organized as subjects X channel X
frequency   with 15-20 subjects in each group, 19 channels, and 19
frequencies (2-20 Hz) and only 1 time point.

I am using ft_statfun_indepsamplesF to determine differences among the
groups.  After performing this initial cluster-based permutation test, what
is the appropriate post-hoc.  I think if I did three pairwise
comparisons and made a  Bonferroni correction it would be too strict.
Would it be appropriate to use the electrode/frequency clusters identified
in the initial 3 way comparison as channels and frequencies of interest and
then perform three pairwise comparisons and multiply the resulting pairwise
p-values by 3?

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201120/53377915/attachment.htm>

From alex.lepauvre at ae.mpg.de  Mon Nov 23 10:20:50 2020
From: alex.lepauvre at ae.mpg.de (Lepauvre, Alex)
Date: Mon, 23 Nov 2020 09:20:50 +0000
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than
 Maximum\n
In-Reply-To: <YTOPR0101MB09884E87ADF6B6A3EB9D58B6FDFF0@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>
References: <63425210-9257-4B41-88A4-CCD000361C6A@gmail.com>
 <YTOPR0101MB0988643DDCCC1640CEDC7B56FDE10@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>
 <03559953-E06B-4EA4-9329-8D0D5002F0C5@gmail.com>
 <55d2470b820e4801a92e8216c2253e52@ae.mpg.de>,
 <1642a8d00a9247da85aa52777c9a1aca@ae.mpg.de>
 <YTOPR0101MB09884E87ADF6B6A3EB9D58B6FDFF0@YTOPR0101MB0988.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <b25936feebac4457994b12dd019f98b5@ae.mpg.de>

Dear Simeon, dear fieldtrip community,

Thanks a lot, this is super useful information! I imagine that by lower-level functions you are referring to functions that do not load the data to resave them, but rather chop up the file digitally, correct? Do you happen to know what such functions are in Fieldtrip? While I have no issues moving to python, people that might use the code might prefer matlab.

Thanks again for this precious support,

Kind regards,

Alex
From: fieldtrip <fieldtrip-bounces at science.ru.nl> On Behalf Of Simeon Wong
Sent: Friday, 20 November 2020 16:03
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n

Hi Alex and Katarina,

According to the EDF standard, inverted physical min/max values are used to implement the negative-up convention in clinical neurophysiology: https://www.edfplus.info/specs/edfplus.html#:~:text=5.%20'Digital%20maximum'%20must%20be%20larger,by%200'%20errors%20by%20some%20viewers).

Therefore, it would appear (without further evidence to the contrary) that your data is ok, and the headers are simply indicating a negative gain.

If you're trying to only copy the data, I'd suggest doing it digitally (ie. without any conversion into physical units) using lower-level functions. This will ensure the data is not "altered". In our lab, we also have a similar use case where we extract only scalp electrodes during specified times into separate EDF files. We do this in Python using pyedflib, mainly because some of our other analysis code was already in Python, not for any particular advantage of the language or toolbox over Fieldtrip: https://gist.github.com/dtxe/a74bd43f4106281b86b9171bf5efe73d

I'm speculating the reason the data changes after the 2nd decimal place is due to rounding:

  1.  Data is stored in EDF format as 16-bit integers (ref)<https://www.edfplus.info/specs/edf.html#:~:text=each%20sample%20value%20is%20represented%20as%20a%202%2Dbyte%20integer>
  2.  On import, the data is converted into physical units using digital min/max, physical min/max
  3.  On export, the data is converted back into digital units

     *   The header field for physical min/max only accommodates 8 characters, hence lines 91-95
     *   Fieldtrip optimizes the dynamic range by using the physical signal's min/max, which is likely different than the original EDF file's physical min/max
     *   After converting back into digital units, the data is rounded to the nearest int16.


I hope this helps,

Simeon




[cid:image001.png at 01D6C182.4EB5B9D0]


Simeon Wong

Ibrahim Lab

Neurosciences & Mental Health



686 Bay Street, Toronto ON  M5G 0A4

P 416.813.7654  x303697


________________________________
From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> on behalf of Lepauvre, Alex <alex.lepauvre at ae.mpg.de<mailto:alex.lepauvre at ae.mpg.de>>
Sent: November 20, 2020 06:12
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n


Dear Fieldtrip community,



Following on the messages below, I performed comparison between the saved signal and the original signal. To give a little more context, our single goal here is to load our EDF signal in fieldtrip to then chop it into pieces to be able to save each piece separately. We are required to do so as we are having very long EDFs and because we have to format our data in these specific pieces for data ingestion in XNAT.



The written function (see attached) loads the EDF of interest and using a photodiode trigger channel, we parse our signal in "blocks", enabling the user of the code to adjust detected onsets manually to account for misdetection by our algorithm. The EDF signal is cut from onsets to onsets and stored in separated files. We need to make sure that this procedure doesn't alter our raw signal in any ways. To check whether this happens, following the data saving, the saved data are being reloaded and compared to the original data that were parsed. If the comparison yields anything else than 0s, then it means that the data were altered in some way.



When running the function, the first thing I notice is that following saving, the size of the signal.trial{1,1} matrices has been changed. Following some digging in the edf write function, I noticed that the data are being saved to the EDF in 1 seconds chunks, while it is not in our original signal (0.625seconds instead). I assume that this is not a big deal as this doesn't really alter the data. However, what I believe is problematic is that the signal gets altered after the second decimal place across all channels. I am assuming that this has something to do with the conversion to uint16? I am a bit puzzled about why this is the case and how we can get around this issue to save our data and keep them pristine. Has anyone been encountering similar issues and/or knows a way?



Kind regards,



Alex



From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> On Behalf Of Lepauvre, Alex
Sent: Thursday, 19 November 2020 14:01
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n



Dear Simeon, deaf Fieldtrip community



Thanks a lot for your helpful feedback. To give you a little bit more context, our EDFs are from iEEG data.  I have been digging a little bit more into this issue with our data. First of all, it turns out that the warning isn't thrown by the opnedEDF function, but by the read_edf.m one. It seems that in our files, the accessed PhysMin and PhysMax are reversed. Indeed, most values in the PhysMax are negative (-8711uV, except for some misc channels), while the PhysMin is the exact opposite (+8711), which seems to be the prime reason for this error.  I am not sure why that is the case. According to what you were saying @Simeon, this might be due to our EDF export software doing something odd with the headers? Can this harm our data?



Also, another aspect I am confused about is that we are currently using fieldtrip to chop our single big EDFs into smaller more manageable files. We therefore load the data triggering the warning, then chop them and adjust the headers, and save the chunks separately. However, when reloading the newly saved data, the warning isn't there anymore, which has me worried that the data have been altered in some way.

After digging in the function write_edf a little bit more, I am supposing that the issue doesn't appear anymore because fieldtrip compute the max and min amplitude of the signal, and fill it in in the PhyMax and PhysMin headers itself, correct?



Finally, another issue we are facing is that for some of our EDF files, the write_EDF function doesn't work with some of our EDFs (I am unfortunately not allowed to share any data due to strong data privacy policies In our project, my apologies). While for some of our files it did work, for at least one, the write_edf returns the following error:

[cid:image002.jpg at 01D6C182.4EB5B9D0]



I again dived into the function write_edf and located the issue here:



[cid:image004.jpg at 01D6C182.4EB5B9D0]

I am not entirely sure what the purpose of these statements is. It seems to reduce the decimal places of the physical minimum (and then maximum) to find which approximation fits the expected size (8*nchans). However, none of the 5 options fit. Surprisingly enough, going one more would work: in my signal %-8.2g fits exactly nchans*8. I am not sure why that is the case nor what it would entail for my data if I were to change it in the code myself. Could someone enlighten me?



From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> On Behalf Of Katarina Bendtz
Sent: Wednesday, 18 November 2020 20:20
To: FieldTrip discussion list <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: Re: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n



Dear Simeon!



Thank you so much for your quick reply! I understand!



Do you think I can safely ignore this or should I try to find out which channels this applies to? That is, if the trigger channels are set to identical values, will this in some way compromise/change the data?



best,

Kat



Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA







On Nov 18, 2020, at 1:22 PM, Simeon Wong <simeon.wong at sickkids.ca<mailto:simeon.wong at sickkids.ca>> wrote:



Hi Katarina,



The fread command advances the file pointer. Therefore the 4 lines are reading consecutive values from the EDF file.

https://www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle#d122e421874:~:text=and%20positions%20the%20file%20pointer%20after%20the%20last%20value%20read<https://urldefense.com/v3/__https:/www.mathworks.com/help/matlab/ref/fread.html?searchHighlight=fread&s_tid=doc_srchtitle*d122e421874:*:text=and*20positions*20the*20file*20pointer*20after*20the*20last*20value*20read__;I34lJSUlJSUlJSU!!D0zGoin7BXfl!r4QJaRIZ-3FdVMHleuLbLlEDUz6WEdLbbNCQa6ENyxDrfsWOU5abThVtTfOyf5ZSROzo$>



With that being said, some EDF export software (for better or for worse) set identical physical values if channels are switched off or for channels without physical units (ie. trigger channels or misc channels).









All the best,

Simeon





<Outlook-gb44xqtx.png>


Simeon Wong

Ibrahim Lab

Neurosciences & Mental Health



686 Bay Street, Toronto ON  M5G 0A4

P 416.813.7654  x303697




________________________________

From: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> on behalf of Katarina Bendtz <katarina.bendtz at gmail.com<mailto:katarina.bendtz at gmail.com>>
Sent: November 18, 2020 12:50
To: fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl> <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>>
Subject: [FieldTrip] Warning OPENEDF: Physical Minimum larger than Maximum\n



Dear experts:

Me and my colleague at another university idependently I get this warning when we try to open an edf file:



Warning OPENEDF: Physical

Minimum larger than Maximum\n





I'm using fieldtrip 2020113. Looking at the source code

https://github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m<https://urldefense.com/v3/__https:/github.com/fieldtrip/fieldtrip/blob/master/private/openedf.m__;!!D0zGoin7BXfl!tHOzBhC87IDZICVPmzh1QeJQI1pBz7wzlyRm7uCUqe_WlgHxjVh2sShWYk0yjAhO9UAo$>



I read:



if (any(EDF.PhysMin >= EDF.PhysMax))



fprintf(2,'Warning OPENEDF: Physical Minimum larger than Maximum\n');



EDF.PhysMin = EDF.DigMin;



        EDF.PhysMax = EDF.DigMax;



end



but then a couple of lines up, I see both EDF.PhysMin and EDF.PhysMax, (and also EDF.DigMin and EDF.DigMax) being set to the same thing:



EDF.PhysMin= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));

EDF.PhysMax= str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')'));

EDF.DigMin = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %

EDF.DigMax = str2num(char(fread(EDF.FILE.FID,[8,EDF.NS],'char')')); %



So it is quite reasonable that I will get this warning. I'm puzzled.



1. What's purpose of this warning?

2. Why are the variables set to the same value?

3. Can I safely ignore this warning?

4. Or is there something I misunderstood.



Thanks a lot,



Best,

Kat




Katarina Bendtz, PhD
Research Fellow
Kreiman Lab
Boston Children's Hospital
Harvard University

+1 (617) 390 45 16
3 Blackfan Circle
Boston, USA









________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip<https://urldefense.com/v3/__https:/mailman.science.ru.nl/mailman/listinfo/fieldtrip__;!!D0zGoin7BXfl!r4QJaRIZ-3FdVMHleuLbLlEDUz6WEdLbbNCQa6ENyxDrfsWOU5abThVtTfOyf5sM8xsl$>
https://doi.org/10.1371/journal.pcbi.1002202<https://urldefense.com/v3/__https:/doi.org/10.1371/journal.pcbi.1002202__;!!D0zGoin7BXfl!r4QJaRIZ-3FdVMHleuLbLlEDUz6WEdLbbNCQa6ENyxDrfsWOU5abThVtTfOyfw9x0Kj7$>



________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201123/d70f3658/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1756 bytes
Desc: image001.png
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201123/d70f3658/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 69252 bytes
Desc: image002.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201123/d70f3658/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 94612 bytes
Desc: image004.jpg
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201123/d70f3658/attachment-0001.jpg>

From christian.merkel at med.ovgu.de  Mon Nov 23 13:47:34 2020
From: christian.merkel at med.ovgu.de (christian.merkel at med.ovgu.de)
Date: Mon, 23 Nov 2020 12:47:34 +0000
Subject: [FieldTrip] calculate DICS Beamformer on a group level?
Message-ID: <ca32d26830a546fdab79caaf4d1e5130@med.ovgu.de>

Hello,


I hope some of you can give me some advice regarding a more conceptual problem with localizing specific oscillations within MEG data:

I wanted to use the DICS-approach to localize a specific spectral effect in my MEG-data within the source space. Now I don't know whether this can be done on an averaged dataset across multiple subjects, since in this case the cross-spectral-density matrices of all the subjects would have to be averaged as well and I am not sure whether such an averaged CSD-matrix still makes sense.

In more detail, I have spectral timeseries (complex) of several seconds within one specific frequency-band (sens x time). I calculate the grand average across time to get the evolution of the topography of this effect over time. Additionally, I ran a PCA on that averaged timecourse to extract the specific source (component) in sensorspace that I am interested in. Then I used the resulting unmixing-matrix to multiply that components weights with each subjects timecourses (sens x time). Thus I have one overall topography of that effect in sensorspace and its timecourse + variance (which I can run statistics on). Now I thought I can also look for the same effect in sourcespace but I actually just have the topography without the CSD-Matrix. And even if one could average the single-subjects CSDs, how would I retain the CSD for a specific component after a pca?


Thanks for any help,


Christian M.



From stephen.whitmarsh at gmail.com  Mon Nov 23 14:40:09 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Mon, 23 Nov 2020 14:40:09 +0100
Subject: [FieldTrip] calculate DICS Beamformer on a group level?
In-Reply-To: <ca32d26830a546fdab79caaf4d1e5130@med.ovgu.de>
References: <ca32d26830a546fdab79caaf4d1e5130@med.ovgu.de>
Message-ID: <CAFrxm=zm4t5O5=3hzfXwgg_f6p9s+piB-kVebv59N5yOTGgvPg@mail.gmail.com>

Dear Christian,

Here are my 2 cents;

If I understand you correctly (*) you are asking whether you can beamform
your PCA components? That does seem a redundant mix of source-localization
techniques to me (of which PCA is one). Technically I would be at a loss
explaining why I wouldn't expect this, but conceptually I would say that
PCA already took care of the source-extraction, in this case a
time-course + sensor-topography. That time-course is one 'side' of your
source (the temporal part), and belongs to that topography - the other
(spatial) side of that coin. Which is to say, you already did a spatial
source analysis by manually selecting the spatial topography.

You could, for reasons of validation perhaps, beamform the power in a
particular frequency / time period (the 'traditional way'), and see if it
is also able to separate your source spatio-temporally in a similar way,
but that would be a qualitative comparison between source-localization
techniques.

Anyway, that's probably what you were thinking about anyway :)

Concerning the beamformer specifically; you do not beamform an average. The
whole point is to use subject-specific headmodels (based on individual
MRIs) and individual subject's CSDs to be able to estimate power on a
gridpoint-by-gridpoint basis. This then also allows you to better 'average'
or 'normalize' those individual brains and their activity-topographies,
namely based on their individual headshape and headmodel, than a
sensor-level averaging would do, given the undetermined relationship
between brain and MEG helmet in the latter. However, your PCA method
already got rid of this problem by removing the spatial part (the manual
selection of the component).

So, you *could* do a 'traditional' DICS beamformer, but because you already
done your statistics on your sources, that might be only for some
qualitative source-location validation that might not be worth the effort?

Anyway, that's all the change I have in my pocket :)

Cheers,
Stephen

*) If you are doing your statistical test on the same effect as the one you
used to select the PCA component, you are of course double-dipping.













Op ma 23 nov. 2020 om 13:48 schreef christian.merkel at med.ovgu.de <
christian.merkel at med.ovgu.de>:

> Hello,
>
>
> I hope some of you can give me some advice regarding a more conceptual
> problem with localizing specific oscillations within MEG data:
>
> I wanted to use the DICS-approach to localize a specific spectral effect
> in my MEG-data within the source space. Now I don't know whether this can
> be done on an averaged dataset across multiple subjects, since in this case
> the cross-spectral-density matrices of all the subjects would have to be
> averaged as well and I am not sure whether such an averaged CSD-matrix
> still makes sense.
>
> In more detail, I have spectral timeseries (complex) of several seconds
> within one specific frequency-band (sens x time). I calculate the grand
> average across time to get the evolution of the topography of this effect
> over time. Additionally, I ran a PCA on that averaged timecourse to extract
> the specific source (component) in sensorspace that I am interested in.
> Then I used the resulting unmixing-matrix to multiply that components
> weights with each subjects timecourses (sens x time). Thus I have one
> overall topography of that effect in sensorspace and its timecourse +
> variance (which I can run statistics on). Now I thought I can also look for
> the same effect in sourcespace but I actually just have the topography
> without the CSD-Matrix. And even if one could average the single-subjects
> CSDs, how would I retain the CSD for a specific component after a pca?
>
>
> Thanks for any help,
>
>
> Christian M.
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201123/3be8f4aa/attachment.htm>

From christian.merkel at med.ovgu.de  Mon Nov 23 15:17:01 2020
From: christian.merkel at med.ovgu.de (christian.merkel at med.ovgu.de)
Date: Mon, 23 Nov 2020 14:17:01 +0000
Subject: [FieldTrip] calculate DICS Beamformer on a group level?
In-Reply-To: <6422_1606139385_5FBBBDF9_6422_784_1_CAFrxm=zm4t5O5=3hzfXwgg_f6p9s+piB-kVebv59N5yOTGgvPg@mail.gmail.com>
References: <ca32d26830a546fdab79caaf4d1e5130@med.ovgu.de>,
 <6422_1606139385_5FBBBDF9_6422_784_1_CAFrxm=zm4t5O5=3hzfXwgg_f6p9s+piB-kVebv59N5yOTGgvPg@mail.gmail.com>
Message-ID: <a3349977a6504d9ba8ef469b3d649019@med.ovgu.de>

Hello,


First of all, thanks for the in-depth input.

- Regarding the double-dipping of the pca-approach: The statistical test is a between-subject comparison. So I use the pca in order to identify the source for which i want to test whether its timecourse differs between two groups of subjects. So I average ALL subjects for one particular frequency, select the source and use the weights on each single subject to calculate the amplitude differences over time between groups. So the H0 is formulated in a way that double-dipping wouldn't be the issue.


- So but why do I want now those results in source space? Although I identified the source with my pca already I want to show that there are no artifacts explaining the effect. The frequency-range in question is a high-gamma range. Its source is bilateral occipital for a specific motion stimulus. I had lots of discussion about this effect and as you can imagine the most critical point are microsaccades potentially interfering. I applied initial ICA-algorithms of the raw datasets + p2p-artefact rejection. As one last step to show that this are no microsaccades I just wanted a describtive source distribution showing the bilateral occipital sources without any frontal contamination. Beamformer filters apparently inherently remove those kind of high-frequency artefacts (Hipp/Siegel, 2013).


Thank you again,


Christian



________________________________
Von: fieldtrip <fieldtrip-bounces at science.ru.nl> im Auftrag von Stephen Whitmarsh <stephen.whitmarsh at gmail.com>
Gesendet: Montag, 23. November 2020 14:40:09
An: FieldTrip discussion list
Betreff: Re: [FieldTrip] calculate DICS Beamformer on a group level?

Dear Christian,

Here are my 2 cents;

If I understand you correctly (*) you are asking whether you can beamform your PCA components? That does seem a redundant mix of source-localization techniques to me (of which PCA is one). Technically I would be at a loss explaining why I wouldn't expect this, but conceptually I would say that PCA already took care of the source-extraction, in this case a time-course + sensor-topography. That time-course is one 'side' of your source (the temporal part), and belongs to that topography - the other (spatial) side of that coin. Which is to say, you already did a spatial source analysis by manually selecting the spatial topography.

You could, for reasons of validation perhaps, beamform the power in a particular frequency / time period (the 'traditional way'), and see if it is also able to separate your source spatio-temporally in a similar way, but that would be a qualitative comparison between source-localization techniques.

Anyway, that's probably what you were thinking about anyway :)

Concerning the beamformer specifically; you do not beamform an average. The whole point is to use subject-specific headmodels (based on individual MRIs) and individual subject's CSDs to be able to estimate power on a gridpoint-by-gridpoint basis. This then also allows you to better 'average' or 'normalize' those individual brains and their activity-topographies, namely based on their individual headshape and headmodel, than a sensor-level averaging would do, given the undetermined relationship between brain and MEG helmet in the latter. However, your PCA method already got rid of this problem by removing the spatial part (the manual selection of the component).

So, you could do a 'traditional' DICS beamformer, but because you already done your statistics on your sources, that might be only for some qualitative source-location validation that might not be worth the effort?

Anyway, that's all the change I have in my pocket :)

Cheers,
Stephen

*) If you are doing your statistical test on the same effect as the one you used to select the PCA component, you are of course double-dipping.













Op ma 23 nov. 2020 om 13:48 schreef christian.merkel at med.ovgu.de<mailto:christian.merkel at med.ovgu.de> <christian.merkel at med.ovgu.de<mailto:christian.merkel at med.ovgu.de>>:
Hello,


I hope some of you can give me some advice regarding a more conceptual problem with localizing specific oscillations within MEG data:

I wanted to use the DICS-approach to localize a specific spectral effect in my MEG-data within the source space. Now I don't know whether this can be done on an averaged dataset across multiple subjects, since in this case the cross-spectral-density matrices of all the subjects would have to be averaged as well and I am not sure whether such an averaged CSD-matrix still makes sense.

In more detail, I have spectral timeseries (complex) of several seconds within one specific frequency-band (sens x time). I calculate the grand average across time to get the evolution of the topography of this effect over time. Additionally, I ran a PCA on that averaged timecourse to extract the specific source (component) in sensorspace that I am interested in. Then I used the resulting unmixing-matrix to multiply that components weights with each subjects timecourses (sens x time). Thus I have one overall topography of that effect in sensorspace and its timecourse + variance (which I can run statistics on). Now I thought I can also look for the same effect in sourcespace but I actually just have the topography without the CSD-Matrix. And even if one could average the single-subjects CSDs, how would I retain the CSD for a specific component after a pca?


Thanks for any help,


Christian M.

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202



From stephen.whitmarsh at gmail.com  Mon Nov 23 15:46:26 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Mon, 23 Nov 2020 15:46:26 +0100
Subject: [FieldTrip] calculate DICS Beamformer on a group level?
In-Reply-To: <a3349977a6504d9ba8ef469b3d649019@med.ovgu.de>
References: <ca32d26830a546fdab79caaf4d1e5130@med.ovgu.de>
 <6422_1606139385_5FBBBDF9_6422_784_1_CAFrxm=zm4t5O5=3hzfXwgg_f6p9s+piB-kVebv59N5yOTGgvPg@mail.gmail.com>
 <a3349977a6504d9ba8ef469b3d649019@med.ovgu.de>
Message-ID: <CAFrxm=y0HJegbrCDE=BH06QUO23MVYuFVT2ujH=WAvu8O1RvUw@mail.gmail.com>

Hi Christian,

That's interesting. I'm sure more people on the list have had to deal with
a possible effect of (micro)saccades on occipital gamma sources. I hope
they can chime in.

Beamformer is good at removing EOG artefacts, yes.

Not sure beamformer will help to exclude the potential confound you mention
though. As I understand it, (micro)saccade creates perceptual motion or
something that is in any case processed in the visual cortex, creating
gamma activity; i.e, they are not ocular/muscular artefacts, rather real
signal brain signal, albeit not the one you are interested in, and a
potential confound. I guess it will be a real problem is there is any
indication or reason to suspect that (micro)saccades are more prevalent in
one condition/time period vs. another.

Perhaps you can analyse something like the variance (of amplitude (V) over
trials) of your EOG channels, to show there is no correlation/difference of
EOG activity when comparing your signal/contrast/timepoints?

There is another nifty trick you might try in this regard - when you remove
EOG artefacts with PCA, keep those 'ocular artefact' components and
combine them as you did the remaining components. Then analyse them as you
did your MEG. Any activity that was correlated with the EOG (to the point
of being part of those components), should not show any 'effect' in that
data. It won't be full-proof, but it is additional evidence against the
effect of EOG/saccades.

Good luck, and perhaps someone else can chime in as well.

Cheers,
Stephen



Op ma 23 nov. 2020 om 15:17 schreef christian.merkel at med.ovgu.de <
christian.merkel at med.ovgu.de>:

> Hello,
>
>
> First of all, thanks for the in-depth input.
>
> - Regarding the double-dipping of the pca-approach: The statistical test
> is a between-subject comparison. So I use the pca in order to identify the
> source for which i want to test whether its timecourse differs between two
> groups of subjects. So I average ALL subjects for one particular frequency,
> select the source and use the weights on each single subject to calculate
> the amplitude differences over time between groups. So the H0 is formulated
> in a way that double-dipping wouldn't be the issue.
>
>
> - So but why do I want now those results in source space? Although I
> identified the source with my pca already I want to show that there are no
> artifacts explaining the effect. The frequency-range in question is a
> high-gamma range. Its source is bilateral occipital for a specific motion
> stimulus. I had lots of discussion about this effect and as you can imagine
> the most critical point are microsaccades potentially interfering. I
> applied initial ICA-algorithms of the raw datasets + p2p-artefact
> rejection. As one last step to show that this are no microsaccades I just
> wanted a describtive source distribution showing the bilateral occipital
> sources without any frontal contamination. Beamformer filters apparently
> inherently remove those kind of high-frequency artefacts (Hipp/Siegel,
> 2013).
>
>
> Thank you again,
>
>
> Christian
>
>
>
> ________________________________
> Von: fieldtrip <fieldtrip-bounces at science.ru.nl> im Auftrag von Stephen
> Whitmarsh <stephen.whitmarsh at gmail.com>
> Gesendet: Montag, 23. November 2020 14:40:09
> An: FieldTrip discussion list
> Betreff: Re: [FieldTrip] calculate DICS Beamformer on a group level?
>
> Dear Christian,
>
> Here are my 2 cents;
>
> If I understand you correctly (*) you are asking whether you can beamform
> your PCA components? That does seem a redundant mix of source-localization
> techniques to me (of which PCA is one). Technically I would be at a loss
> explaining why I wouldn't expect this, but conceptually I would say that
> PCA already took care of the source-extraction, in this case a time-course
> + sensor-topography. That time-course is one 'side' of your source (the
> temporal part), and belongs to that topography - the other (spatial) side
> of that coin. Which is to say, you already did a spatial source analysis by
> manually selecting the spatial topography.
>
> You could, for reasons of validation perhaps, beamform the power in a
> particular frequency / time period (the 'traditional way'), and see if it
> is also able to separate your source spatio-temporally in a similar way,
> but that would be a qualitative comparison between source-localization
> techniques.
>
> Anyway, that's probably what you were thinking about anyway :)
>
> Concerning the beamformer specifically; you do not beamform an average.
> The whole point is to use subject-specific headmodels (based on individual
> MRIs) and individual subject's CSDs to be able to estimate power on a
> gridpoint-by-gridpoint basis. This then also allows you to better 'average'
> or 'normalize' those individual brains and their activity-topographies,
> namely based on their individual headshape and headmodel, than a
> sensor-level averaging would do, given the undetermined relationship
> between brain and MEG helmet in the latter. However, your PCA method
> already got rid of this problem by removing the spatial part (the manual
> selection of the component).
>
> So, you could do a 'traditional' DICS beamformer, but because you already
> done your statistics on your sources, that might be only for some
> qualitative source-location validation that might not be worth the effort?
>
> Anyway, that's all the change I have in my pocket :)
>
> Cheers,
> Stephen
>
> *) If you are doing your statistical test on the same effect as the one
> you used to select the PCA component, you are of course double-dipping.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Op ma 23 nov. 2020 om 13:48 schreef christian.merkel at med.ovgu.de<mailto:
> christian.merkel at med.ovgu.de> <christian.merkel at med.ovgu.de<mailto:
> christian.merkel at med.ovgu.de>>:
> Hello,
>
>
> I hope some of you can give me some advice regarding a more conceptual
> problem with localizing specific oscillations within MEG data:
>
> I wanted to use the DICS-approach to localize a specific spectral effect
> in my MEG-data within the source space. Now I don't know whether this can
> be done on an averaged dataset across multiple subjects, since in this case
> the cross-spectral-density matrices of all the subjects would have to be
> averaged as well and I am not sure whether such an averaged CSD-matrix
> still makes sense.
>
> In more detail, I have spectral timeseries (complex) of several seconds
> within one specific frequency-band (sens x time). I calculate the grand
> average across time to get the evolution of the topography of this effect
> over time. Additionally, I ran a PCA on that averaged timecourse to extract
> the specific source (component) in sensorspace that I am interested in.
> Then I used the resulting unmixing-matrix to multiply that components
> weights with each subjects timecourses (sens x time). Thus I have one
> overall topography of that effect in sensorspace and its timecourse +
> variance (which I can run statistics on). Now I thought I can also look for
> the same effect in sourcespace but I actually just have the topography
> without the CSD-Matrix. And even if one could average the single-subjects
> CSDs, how would I retain the CSD for a specific component after a pca?
>
>
> Thanks for any help,
>
>
> Christian M.
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201123/fb664b64/attachment.htm>

From carolinedebooij at msn.com  Mon Nov 23 15:54:26 2020
From: carolinedebooij at msn.com (Caroline de Booij)
Date: Mon, 23 Nov 2020 14:54:26 +0000
Subject: [FieldTrip] calculate DICS Beamformer on a group level?
In-Reply-To: <CAFrxm=y0HJegbrCDE=BH06QUO23MVYuFVT2ujH=WAvu8O1RvUw@mail.gmail.com>
References: <ca32d26830a546fdab79caaf4d1e5130@med.ovgu.de>
 <6422_1606139385_5FBBBDF9_6422_784_1_CAFrxm=zm4t5O5=3hzfXwgg_f6p9s+piB-kVebv59N5yOTGgvPg@mail.gmail.com>
 <a3349977a6504d9ba8ef469b3d649019@med.ovgu.de>,
 <CAFrxm=y0HJegbrCDE=BH06QUO23MVYuFVT2ujH=WAvu8O1RvUw@mail.gmail.com>
Message-ID: <AM9PR03MB6946E85AD1FFA9D531561D66B4FC0@AM9PR03MB6946.eurprd03.prod.outlook.com>

Good afternoon,

Could I be removed from this mailinglist?

Thanks in advance and have a nice day all,
Caroline
________________________________
Van: fieldtrip <fieldtrip-bounces at science.ru.nl> namens Stephen Whitmarsh <stephen.whitmarsh at gmail.com>
Verzonden: maandag 23 november 2020 15:46
Aan: FieldTrip discussion list <fieldtrip at science.ru.nl>
Onderwerp: Re: [FieldTrip] calculate DICS Beamformer on a group level?

Hi Christian,

That's interesting. I'm sure more people on the list have had to deal with a possible effect of (micro)saccades on occipital gamma sources. I hope they can chime in.

Beamformer is good at removing EOG artefacts, yes.

Not sure beamformer will help to exclude the potential confound you mention though. As I understand it, (micro)saccade creates perceptual motion or something that is in any case processed in the visual cortex, creating gamma activity; i.e, they are not ocular/muscular artefacts, rather real signal brain signal, albeit not the one you are interested in, and a potential confound. I guess it will be a real problem is there is any indication or reason to suspect that (micro)saccades are more prevalent in one condition/time period vs. another.

Perhaps you can analyse something like the variance (of amplitude (V) over trials) of your EOG channels, to show there is no correlation/difference of EOG activity when comparing your signal/contrast/timepoints?

There is another nifty trick you might try in this regard - when you remove EOG artefacts with PCA, keep those 'ocular artefact' components and combine them as you did the remaining components. Then analyse them as you did your MEG. Any activity that was correlated with the EOG (to the point of being part of those components), should not show any 'effect' in that data. It won't be full-proof, but it is additional evidence against the effect of EOG/saccades.

Good luck, and perhaps someone else can chime in as well.

Cheers,
Stephen



Op ma 23 nov. 2020 om 15:17 schreef christian.merkel at med.ovgu.de<mailto:christian.merkel at med.ovgu.de> <christian.merkel at med.ovgu.de<mailto:christian.merkel at med.ovgu.de>>:
Hello,


First of all, thanks for the in-depth input.

- Regarding the double-dipping of the pca-approach: The statistical test is a between-subject comparison. So I use the pca in order to identify the source for which i want to test whether its timecourse differs between two groups of subjects. So I average ALL subjects for one particular frequency, select the source and use the weights on each single subject to calculate the amplitude differences over time between groups. So the H0 is formulated in a way that double-dipping wouldn't be the issue.


- So but why do I want now those results in source space? Although I identified the source with my pca already I want to show that there are no artifacts explaining the effect. The frequency-range in question is a high-gamma range. Its source is bilateral occipital for a specific motion stimulus. I had lots of discussion about this effect and as you can imagine the most critical point are microsaccades potentially interfering. I applied initial ICA-algorithms of the raw datasets + p2p-artefact rejection. As one last step to show that this are no microsaccades I just wanted a describtive source distribution showing the bilateral occipital sources without any frontal contamination. Beamformer filters apparently inherently remove those kind of high-frequency artefacts (Hipp/Siegel, 2013).


Thank you again,


Christian



________________________________
Von: fieldtrip <fieldtrip-bounces at science.ru.nl<mailto:fieldtrip-bounces at science.ru.nl>> im Auftrag von Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>
Gesendet: Montag, 23. November 2020 14:40:09
An: FieldTrip discussion list
Betreff: Re: [FieldTrip] calculate DICS Beamformer on a group level?

Dear Christian,

Here are my 2 cents;

If I understand you correctly (*) you are asking whether you can beamform your PCA components? That does seem a redundant mix of source-localization techniques to me (of which PCA is one). Technically I would be at a loss explaining why I wouldn't expect this, but conceptually I would say that PCA already took care of the source-extraction, in this case a time-course + sensor-topography. That time-course is one 'side' of your source (the temporal part), and belongs to that topography - the other (spatial) side of that coin. Which is to say, you already did a spatial source analysis by manually selecting the spatial topography.

You could, for reasons of validation perhaps, beamform the power in a particular frequency / time period (the 'traditional way'), and see if it is also able to separate your source spatio-temporally in a similar way, but that would be a qualitative comparison between source-localization techniques.

Anyway, that's probably what you were thinking about anyway :)

Concerning the beamformer specifically; you do not beamform an average. The whole point is to use subject-specific headmodels (based on individual MRIs) and individual subject's CSDs to be able to estimate power on a gridpoint-by-gridpoint basis. This then also allows you to better 'average' or 'normalize' those individual brains and their activity-topographies, namely based on their individual headshape and headmodel, than a sensor-level averaging would do, given the undetermined relationship between brain and MEG helmet in the latter. However, your PCA method already got rid of this problem by removing the spatial part (the manual selection of the component).

So, you could do a 'traditional' DICS beamformer, but because you already done your statistics on your sources, that might be only for some qualitative source-location validation that might not be worth the effort?

Anyway, that's all the change I have in my pocket :)

Cheers,
Stephen

*) If you are doing your statistical test on the same effect as the one you used to select the PCA component, you are of course double-dipping.













Op ma 23 nov. 2020 om 13:48 schreef christian.merkel at med.ovgu.de<mailto:christian.merkel at med.ovgu.de><mailto:christian.merkel at med.ovgu.de<mailto:christian.merkel at med.ovgu.de>> <christian.merkel at med.ovgu.de<mailto:christian.merkel at med.ovgu.de><mailto:christian.merkel at med.ovgu.de<mailto:christian.merkel at med.ovgu.de>>>:
Hello,


I hope some of you can give me some advice regarding a more conceptual problem with localizing specific oscillations within MEG data:

I wanted to use the DICS-approach to localize a specific spectral effect in my MEG-data within the source space. Now I don't know whether this can be done on an averaged dataset across multiple subjects, since in this case the cross-spectral-density matrices of all the subjects would have to be averaged as well and I am not sure whether such an averaged CSD-matrix still makes sense.

In more detail, I have spectral timeseries (complex) of several seconds within one specific frequency-band (sens x time). I calculate the grand average across time to get the evolution of the topography of this effect over time. Additionally, I ran a PCA on that averaged timecourse to extract the specific source (component) in sensorspace that I am interested in. Then I used the resulting unmixing-matrix to multiply that components weights with each subjects timecourses (sens x time). Thus I have one overall topography of that effect in sensorspace and its timecourse + variance (which I can run statistics on). Now I thought I can also look for the same effect in sourcespace but I actually just have the topography without the CSD-Matrix. And even if one could average the single-subjects CSDs, how would I retain the CSD for a specific component after a pca?


Thanks for any help,


Christian M.

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201123/1273deb7/attachment.htm>

From m.yavuz.18 at ogr.iu.edu.tr  Tue Nov 24 02:18:08 2020
From: m.yavuz.18 at ogr.iu.edu.tr (MUSTAFA YAVUZ)
Date: Tue, 24 Nov 2020 04:18:08 +0300
Subject: [FieldTrip] Adding Manual Markers
Message-ID: <CAFWATv_t56DXhBtMmGda=Tx+HArbhRbZqSU1iWtxB+wvEhWNFQ@mail.gmail.com>

Hi all,

I've been trying to adjust my EEG data (segmented and .mat file) to be
analyzed by FT. I already have separate trials and have temporal
information about the event markers' time courses. I constructed a Nx3 trl
structure and passed it as cfg.trl while calling ft_preprocessing. Whilst
the function worked and I can see the cfg.trl field in the output
structure, when I call ft_databrowser, the event markers are not displayed
on trials. Do you have any idea/solution for this situation?

Thank you in advance,
Mustafa

-- 
*Mustafa Yavuz *

Ph.D. Candidate in Neuroscience

Department of Neuroscience
İstanbul University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201124/2efe1e9d/attachment.htm>

From stephen.whitmarsh at gmail.com  Tue Nov 24 08:48:29 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Tue, 24 Nov 2020 08:48:29 +0100
Subject: [FieldTrip] Adding Manual Markers
In-Reply-To: <CAFWATv_t56DXhBtMmGda=Tx+HArbhRbZqSU1iWtxB+wvEhWNFQ@mail.gmail.com>
References: <CAFWATv_t56DXhBtMmGda=Tx+HArbhRbZqSU1iWtxB+wvEhWNFQ@mail.gmail.com>
Message-ID: <CAFrxm=yjk1=zFCO0TJbb7ZUdZsix8MdWPU59+JWJXVJ_GqdqrQ@mail.gmail.com>

Merhaba Mustafa,

Welcome to FieldTrip!
Just to be clear - I assume you segmented your continuous data into trials
by passing your marker timing as a cfg.trl in ft_preprocessing, right?
When you did, the temporal information about the markers became irrelevant,
because the trials are then expressed *not *in samples from the onset of
the continuous data anymore, but instead as time relative to the markers.
I.e. each trial now starts at t=0s (-offset), rather and, say [13, 104,
206, ...] samples (i.e. your initial trl). See the resultant data.time
field.
Secondly, ft_databrowser does not take cfg.trl as the location of markers,
rather it does so in cfg.artfctdef.xxx.artifact (yes, a bit strange, partly
historical, and because databrowser is typically used to manually scan for
artifacts).

So, in your case, you could either:

Use ft_databrowser to plot the original, unsegmented, continuous, data, and
pass your trialinfo (as a Nx2 matrix, with only start and end sample) to
cfg.artfctdef.xxx.artifact. Replace xxx with whatever your want, e.g.
"trialnumber"
Use ft_databrowser to plot the segmented data, as trials, with new
time-axis, without the markers.

Note that ft_databrowser will try to fit your cfg.artfctdef.xxx.artifact to
your segmented trial data as well, by doing some intelligent checking of
your past cfg (which is tracked in your segmented data structure and
beyond), and treating your data as continuous data. That might work, or it
might not, but now you know why!

Happy fieldtripping,
Stephen



Op di 24 nov. 2020 om 02:29 schreef MUSTAFA YAVUZ <m.yavuz.18 at ogr.iu.edu.tr
>:

> Hi all,
>
> I've been trying to adjust my EEG data (segmented and .mat file) to be
> analyzed by FT. I already have separate trials and have temporal
> information about the event markers' time courses. I constructed a Nx3 trl
> structure and passed it as cfg.trl while calling ft_preprocessing. Whilst
> the function worked and I can see the cfg.trl field in the output
> structure, when I call ft_databrowser, the event markers are not displayed
> on trials. Do you have any idea/solution for this situation?
>
> Thank you in advance,
> Mustafa
>
> --
> *Mustafa Yavuz *
>
> Ph.D. Candidate in Neuroscience
>
> Department of Neuroscience
> İstanbul University
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201124/7570ec42/attachment.htm>

From patrick.wiegel at sport.uni-freiburg.de  Tue Nov 24 10:21:35 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Tue, 24 Nov 2020 09:21:35 +0000
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <CAFrxm=yjQ6th0_=07bjUWYkAbOVDoYpQ7Aa8+jVmfBHi6k0-ng@mail.gmail.com>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
 <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
 <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>
 <CAFrxm=wdQ1qSnWkRk+Bkb+nY14WaJEwkRCf89PaCevU6amTg7g@mail.gmail.com>
 <BB83D822-468A-4C28-AF6F-BE2807F76DBB@sport.uni-freiburg.de>
 <CAFrxm=yjQ6th0_=07bjUWYkAbOVDoYpQ7Aa8+jVmfBHi6k0-ng@mail.gmail.com>
Message-ID: <D2858661-926F-4328-9E20-054752DD7C16@sport.uni-freiburg.de>

Hi Stephen, hi fiedltrip community

first of all, thanks for the good discussion that we have:-).

The 2 channels in the back were indeed a bit noisy, so I removed those. I attached the results from the new mtmfft analysis. The abs and rel differences between A and B become clearer now, although you could still argue to remove the most right posterior channel. However, I don’t want to loose too much information and I think it is okay to stick with this.

Your argumentation on the right/left behavior in MRIs was helpful. I had to think/read about that for a while. Since I am using the standard_MRI from the fieldtrip page (https://github.com/fieldtrip/fieldtrip/tree/master/template/headmodel), I cannot certainly tell where left and right is. the transformation matrix of the standard MRI is the following which leads me to assume that right is right?

    0.1000         0         0  -12.8500
         0    0.1000         0  -12.8500
         0         0    0.1000  -12.8500
         0         0         0    1.0000


I tried to use a larger grid during ft_prepare_sourcemodel, however, it seems that as soon as I use a negative inward shift, the ft_sourceanalysis function does not work. I get the following error.


Error using svd
Input to SVD must not contain NaN or Inf.

Error in ft_inverse_dics>pinv (line 590)
  [U,S,V] = svd(A,0);

Error in ft_inverse_dics (line 475)
        filt = pinv(lf' * invC * lf) * lf' * invC; % Gross eqn. 3 & van Veen eqn. 23, use PINV/SVD to cover rank
        deficient leadfield

Error in ft_sourceanalysis (line 763)
          dip(i) = ft_inverse_dics(sourcemodel, sens, headmodel, [],  squeeze_Cf, methodopt{:}, leadfieldopt{:});

Error in FT_example_without_baseline (line 121)
sourceAll_beta = ft_sourceanalysis(cfg, data_beta);


Not using a negative inward-shift results in the attached source-differences between conditions.
Best, Patrick



Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

Am 20.11.2020 um 13:02 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Hi Patrick,

Things are becoming clearer now, good to see.

So yes, that artefact in the back of the head: I would definitely take care of that. Maybe do another run of (visual) artefact rejection, or remove those channels.
That the effect is less apparent in the relative difference is not surprising as the absolute differences are expected to be bigger than on other channels due to large amplitudes of the artefacts, which will be 'normalized' over channels when using a relative difference.

I would be careful about interpreting left-right on the plot. Note that you assume you are looking from the top/front of the head downwards/backwards - but there is no way of confirming that based on the picture! People often place some kind of marker on the left or right side of the head when doing an MRI scan - e.g. a vitamin D (?) capsule I think so that one can verify the radiological versus anatomical (?) representation (LR is flipped in radiological plots). You could do this once, and verify your pipeline, if you want to be 100% sure.

Lastly, it seems that the source picture could benefit from using a slightly larger beamformer scanning grid so to overlap more with the edge of the brain/skull. I used to do that using a negative value for the inward shift parameter (cfg.inwardshift) in ft_prepare_sourcemodel. Maybe there is an easy way for you to do that in your pipeline as well.

Looking good!
Stephen





Op vr 20 nov. 2020 om 12:31 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear Stephen,

thanks for the response.

I followed your suggestions and attached the plots. I performed Morlet wavelets TF analyses and mtmfft for conditions A and B. I did not use a baseline correction to see whether this is necessary. As you can see in the topographical plots, both conditions (A and B) have high power in 2 posterior electrodes (I guess some kind of artifact or noise is the reason). Using the abs. difference between A and B does not get rid of that fact, probably because one condition is more affected than the other. Using the rel. difference does a better job and resembles my previous baseline-corrected results. I also compared the baselines and they were not different. The two conditions were furthermore randomized within the same protocol. I assume that adding a baseline is thus unnecessary.

Regarding the source_analysis, the results for individual conditions A and B (NAI) as well as abs dif between A and B look weird again. But that’s very likely due to the same problem as for the power. For rel dif between A and B, the source plot seems more reasonable, although I expect the source to be in the right hemisphere and not in the left as shown in the plot. I controlled that all my input data (electrodes, volume condition model, MRI) have the same definition of the axes (x+ pointing right, y+ pointing anterior, z+ pointing superior) so I don’t think there is a right-left mix-up!?

Now I am wondering whether I have to accept the result for the rel difference in sources between A and B (which is very hard to interpret and justify after what I am observing in the TF analysis, namely an effect in the other hemisphere) or whether there might be still some issue in my approach. It is very hard for me to believe that the source analysis does have so strong assumptions such that it can be in such strong contrast to my power data.

If I am correct, what I input into the source analyses (apart from my models) for conditions A and B are 1) the corresponding power matrix (64 channels x 1 power value) and the CSD (2016 * 1). It could of course be that the source analysis is very sensitive to the large abs differences in power/CSD data between electrodes. However, I also used cfg.supchan (suppressing specific channels) in the source analysis for the 2 channels that were „off“ to see whether this makes it different.However, the source result is similar.

Any comment is appreciated.   All plots, data and scripts are at (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).

Best, Patrick

%%

cfg                  = [];
cfg.headmodel        = vol;
cfg.elec             = elec_aligned;
cfg.reducerank       = 2;
cfg.resolution       = 1;
sourcemodel_beta = ft_prepare_leadfield(cfg,data_beta);

%%

cfg              = [];
cfg.method       = 'dics';
cfg.sourcemodel  = sourcemodel_beta;
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.frequency    = 28;
cfg.dics.projectnoise = 'yes';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
sourceAll_beta = ft_sourceanalysis(cfg, data_beta);

%%

cfg              = [];
cfg.method       = 'dics';
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.dics.projectnoise = 'yes';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
cfg.sourcemodel  = sourcemodel_beta;
cfg.sourcemodel.filter = sourceAll_beta.avg.filter;

source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);


%%

sourceNAI1 = source_beta_1;
sourceNAI1.avg.pow = source_beta_1.avg.pow ./ source_beta_1.avg.noise;

sourceNAI0 = source_beta_0;
sourceNAI0.avg.pow = source_beta_0.avg.pow ./ source_beta_0.avg.noise;

cfg            = [];
cfg.parameter = 'pow';
cfg.operation = 'x1./x2';
sourceDiff_beta_rel = ft_math(cfg, source_beta_1,source_beta_0);

cfg            = [];
cfg.parameter = 'pow';
cfg.operation = 'x1 - x2';
sourceDiff_beta_abs = ft_math(cfg, source_beta_1,source_beta_0);

%%
cfg            = [];
cfg.downsample = 2;
cfg.parameter  = 'pow';
sourceDiffInt_beta_dif_rel  = ft_sourceinterpolate(cfg, sourceDiff_beta_rel , mri_realigned);
sourceDiffInt_beta_dif_abs  = ft_sourceinterpolate(cfg, sourceDiff_beta_abs , mri_realigned);
sourceDiffInt_beta_dif_0  = ft_sourceinterpolate(cfg, sourceNAI0 , mri_realigned);
sourceDiffInt_beta_dif_1  = ft_sourceinterpolate(cfg, sourceNAI1 , mri_realigned);

%%
maxval_beta_rel = max(sourceDiffInt_beta_dif_rel.pow);
maxval_beta_abs = max(sourceDiffInt_beta_dif_abs.pow);

%%
cfg = [];
cfg.nonlinear     = 'no';
sourceDiffIntNorm_beta_dif_rel = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_rel);
sourceDiffIntNorm_beta_dif_abs = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_abs);
sourceDiffIntNorm_beta_dif_0 = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_0);
sourceDiffIntNorm_beta_dif_1 = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_1);

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 19.11.2020 um 14:59 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Dear Patrick,

Nice to see you are progressing. The TFR topoplots look nice (and the effect seems even stronger in the mtmfft version)!

I agree the source reconstruction looks pretty iffy. A single dot like that shouldn't be there - no source in Beamformer is so focal. It suggests something is off, which could be as simple as a single electrode doing something weird (given how focal and superficial the artefact is).

I would take another step back;
I would first look at the distribution of your absolute beta, i.e. without baseline correction. For both conditions.
I would then look at the distribution of your baseline beta, i.e. only your baseline. For both conditions.
You should satisfy yourself that the results make sense, i.e. nothing too drastic, focal, etc., and some density of beta power around the central sulcus (?).

Now I understand your contrast better, I have to ask why you do the baseline correction as you do. In this way you are using a separate BL for each condition, meaning that after BL-correction you are actually also comparing BL as much as you are comparing post-BL activity - after BL-correction any differences in BL become difference in your active period.
If you assume differences in BL you might want to compare those separately before you 'add' them to your active period. If you have a randomized design, you might not want to do any BL correction in your contrast at all. Also, if there are no differences in BL, then it would make no difference...
So, when you have a good sense of the absolute values and source distributions, you might want to try just comparing active period A vs B, relative (/) or absolute (-), and forget about the BL. Sometimes the BL is more noisy than the active period even.

Anyway, your script looks fine to me, but it's been a while. However, I suspect that one of your datasets (A, A_BL, B, or B_BL) has some artefact that is introduced in the contrast.

Cheers,
Stephen











Op do 19 nov. 2020 om 13:27 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear fieldtrip community,

first of all, thank you for your valuable responses @Tzvetan and Stephen. They were both very helpful and got me to dig deeper into the analysis.

You were absolutely right in describing my approach for my Morlet wavelet TF analysis. The data were baseline corrected (in db). When contrasting the 2 conditions of interest, I receive the attached figure (dif_morlet). After your responses, I took the same approach for the mtmfft data with cfg.tapsmofrq = 8 (center frequency at 28 Hz) to reproduce the effect that I found between 20-35 Hz in the morlet wavelet analyses. I calculated frequency analysis (mtmfft) for both conditions (data_1, data_0) and their baseline periods (data_1_bas, data_0_bas) separately and then „baseline corrected“ the data from both conditions (also in db, see dif_mtmfft). The differences between conditions are now very similar between both approaches (morlet vs mtmfft).

In the next step. I followed your advice and performed source analyses of frequency_data for all 4 conditions separately (pow_1, pow_0, pow_1_baseline, pow_0_baseline) as well as from all_data from ft_appenddata. For the source_analyses from all 4 conditions, I am using the common filter from all_data as well as the source model (ft_prepare_leadfieldds) from all_data. After performing the ft_source_analysis function for all 4 conditions, I am trying to replicate what I have done with the power data ( in db). For this reason, I am using ft_math with source_1_dif = 10*log10 (source_1/source_1_baseline) and the same for source_0. After this, I am subtracting source_0_dif from source_1_dif as done during the frequency analysis yielding my final source data.

After interpolating the source differences, I am using ft_volumenormalise. The result from this approach is attached in dif_sources.

I am a bit puzzled since I would not expect these source data based on my power mtmfft data. I made sure that the coordinate systems and units are the same across models (volume_conduction_model, electrodes, MRI) but I am wondering whether I am doing something wrong in performing the source_analysis or whether the source results are reasonable.

Again, I uploaded the script and the data such that my analysis pipeline could be reproduced by everyone who is interested (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation). Below, I am attaching the code for the source_analyses steps. Any comments on my results or approach are welcome.

All the Best from Germany,
Patrick



.






cfg              = [];
cfg.method       = 'dics';
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.dics.projectnoise = 'yes';
cfg.dics.lambda       = '5%';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
cfg.sourcemodel  = sourcemodel_beta;
source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
source_beta_1_bas = ft_sourceanalysis(cfg, data_beta_1_bas);
source_beta_0_bas = ft_sourceanalysis(cfg, data_beta_0_bas);


%%
cfg            = [];
cfg.parameter = 'pow';
cfg.operation = '10*log10(x1/x2)';
sourceDiff1_beta = ft_math(cfg, source_beta_1,source_beta_1_bas);
sourceDiff0_beta = ft_math(cfg, source_beta_0,source_beta_0_bas);

sourceDiff_beta_dif = sourceDiff1_beta;
sourceDiff_beta_dif.pow = sourceDiff1_beta.pow - sourceDiff0_beta.pow;

%%
cfg            = [];
cfg.downsample = 2;
cfg.parameter  = 'pow';
sourceDiffInt_beta_dif  = ft_sourceinterpolate(cfg, sourceDiff_beta_dif , mri_realigned);

%%
maxval_beta = max(sourceDiffInt_beta_dif.pow);
%%
cfg = [];
cfg.nonlinear     = 'no';

sourceDiffIntNorm_beta_dif = ft_volumenormalise(cfg, sourceDiffInt_beta_dif);

%%
cfg = [];
cfg.method        = 'ortho';
cfg.interactive   = 'yes';
cfg.funparameter  = 'pow';
cfg.maskparameter = cfg.funparameter;
cfg.funcolorlim   = [0.0 maxval_beta];
cfg.opacitylim    = [0.0 maxval_beta];
cfg.opacitymap    = 'rampup';
ft_sourceplot(cfg, sourceDiffIntNorm_beta_dif);
%%


Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 13.11.2020 um 12:48 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Hi Patrick, (and Tzvetan - who responded in the meantime),

I agree that you should start with a good correspondence between your initial results (wavelets), and the power difference you are trying to localize (with mtmfft).

Wavelets and fft methods can result in very similar - practically identical - results, but that depends on a number of parameters, especially concerning frequency-smoothing; Wavelets are typically defined in terms of nr. of cycles, while fft methods are defined in terms of time-windows. Wavelets defined in nr. of cycles will have a decreasing time-windows with increasing frequency, while with mtmfft time windows will remain the same. Because of this, frequency smoothing will increase with frequency with wavelets, and stay the same with a constant time window. Of course, you can make the fft time window frequency-dependent, as is described in the frequency-analyses tutorial, to make them more comparable. Secondly, the fft method allows you to specify frequency smoothing when you use Sleppian multitapers (cfg.taper = 'dpss'). To be clear, you should be able to recognize these differences in frequency smoothing/resolution when looking at the different TFR plots. Currently they look too different, probably because of something else (baseline?) than a wavelet-fft difference.

I would advise making a 'full' TFR with mtmfft similar as your wavelet results so that you can properly compare them. This allows you to also set the best parameters for smoothing/timeperiods. In fact, you can use the multitaper approach to more accurately extract the power in a certain frequency band. Only then compare the topo's, and only then do the beamformer, so you will pick up any unexpected results.

Because of different contrasts/baseline correction, I cannot compare the topo's / beamformer results.

Bon courage,
Stephen









Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear Field-trip community,

I am working on EEG data from a motor learning task. in the first part of my analysis, I performed a time-frequency analysis (Morlet wavelet method) and cluster-based permutation test. I compared two different conditions (correct & incorrect movements) within subjects and found a significant difference in the beta band (20-35 Hz) when subjects were provided with feedback. I attached the topographical plot from one subject that illustrates the difference between the conditions at the selected time point and frequency (dif_morlet). As you can see, beta power was higher in one condition in lateral frontal electrodes.

Now, I would like to better spatially locate the effect for this single subject. For this purpose, I followed the Beamformer tutorial on the website. In the first step, I selected the raw data of interest (at the time where the effect was seen) and performed frequency analyses for the 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft). There is an apparent difference between dif_morlet and dif_mtmfft and I am wondering why this is the case? One apparent reason is that the time-frequency data were baseline corrected and the frequency data from mtmfft not.

Using the power and CSD data from mtmfft, I performed the source analysis with a standard MRI and head model. The source was located in the left hemisphere (source plot), which is in stark contrast to the time-frequency data (dif_morlet). I am aware that the source analysis is based on a lot of assumptions (conductivity etc.) that influence the calculations but it is very difficult to make sense of such discrepancy.
Maybe it is necessary to also baseline correct the mtmfft data before inputting them to the source analysis? Or doing the contrasting source localization betwee a single condition and the corresponding baseline data before contrasting the 2 conditions?

I am providing all necessary files and scripts (TF_analysis & BEAMFORMER) if anyone is interested to reproduce the results that I am showing and reporting for this single subject (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).

I would appreciate any help and discussion on that.

All the best,
Patrick





Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201124/458e4ef0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dif_mtmfft2.eps
Type: application/postscript
Size: 182485 bytes
Desc: dif_mtmfft2.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201124/458e4ef0/attachment.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source_dif2.eps
Type: application/postscript
Size: 296216 bytes
Desc: source_dif2.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201124/458e4ef0/attachment-0001.eps>

From stephen.whitmarsh at gmail.com  Tue Nov 24 11:00:31 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Tue, 24 Nov 2020 11:00:31 +0100
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <D2858661-926F-4328-9E20-054752DD7C16@sport.uni-freiburg.de>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
 <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
 <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>
 <CAFrxm=wdQ1qSnWkRk+Bkb+nY14WaJEwkRCf89PaCevU6amTg7g@mail.gmail.com>
 <BB83D822-468A-4C28-AF6F-BE2807F76DBB@sport.uni-freiburg.de>
 <CAFrxm=yjQ6th0_=07bjUWYkAbOVDoYpQ7Aa8+jVmfBHi6k0-ng@mail.gmail.com>
 <D2858661-926F-4328-9E20-054752DD7C16@sport.uni-freiburg.de>
Message-ID: <CAFrxm=wULQG5iKcxgNqCNcgxj9GURaLg3pG3PzaLKSCMztvsnw@mail.gmail.com>

Hi Patrick,

Concerning L-R, it's not about the MRI, but rather how you are looking at
it - top to bottom, or bottom-to-up, left as left (anatomical), or left as
right (radiological). One thing you can do is to not use the 'ortho', but
rather 'surface' method of plotting - that would give you a real 3D
representation. If that ends up looking like how you would expect it then
perhaps that would be enough :).

I don't know why inward_shift doesn't work for you; but check this tutorial
in which it is used:
https://www.fieldtriptoolbox.org/tutorial/beamformer_lcmv/

What I also don't really get is how you get those very dramatic
pixelated edges in the source plot, while you keep very smooth / highres
grid inside?

Anyway, that sourceplot doesn't look very good, it seems even worse/weirder
than the previous one. The way you mask isn't helping either - you are
cutting away one whole part of the contrast and I don't see why you would
want to do that. Perhaps use rel







Op di 24 nov. 2020 om 10:29 schreef Patrick Wiegel <
patrick.wiegel at sport.uni-freiburg.de>:

> Hi Stephen, hi fiedltrip community
>
> first of all, thanks for the good discussion that we have:-).
>
> The 2 channels in the back were indeed a bit noisy, so I removed those. I
> attached the results from the new mtmfft analysis. The abs and rel
> differences between A and B become clearer now, although you could still
> argue to remove the most right posterior channel. However, I don’t want to
> loose too much information and I think it is okay to stick with this.
>
> Your argumentation on the right/left behavior in MRIs was helpful. I had
> to think/read about that for a while. Since I am using the standard_MRI
> from the fieldtrip page (
> https://github.com/fieldtrip/fieldtrip/tree/master/template/headmodel), I
> cannot certainly tell where left and right is. the transformation matrix of
> the standard MRI is the following which leads me to assume that right is
> right?
>
>     0.1000         0         0  -12.8500
>          0    0.1000         0  -12.8500
>          0         0    0.1000  -12.8500
>          0         0         0    1.0000
>
>
> I tried to use a larger grid during ft_prepare_sourcemodel, however, it
> seems that as soon as I use a negative inward shift, the ft_sourceanalysis
> function does not work. I get the following error.
>
>
> Error using svd
> Input to SVD must not contain NaN or Inf.
>
> Error in ft_inverse_dics>pinv (line 590)
>   [U,S,V] = svd(A,0);
>
> Error in ft_inverse_dics (line 475)
>         filt = pinv(lf' * invC * lf) * lf' * invC; % Gross eqn. 3 & van
> Veen eqn. 23, use PINV/SVD to cover rank
>         deficient leadfield
>
> Error in ft_sourceanalysis (line 763)
>           dip(i) = ft_inverse_dics(sourcemodel, sens, headmodel, [],
>  squeeze_Cf, methodopt{:}, leadfieldopt{:});
>
> Error in FT_example_without_baseline (line 121)
> sourceAll_beta = ft_sourceanalysis(cfg, data_beta);
>
>
> Not using a negative inward-shift results in the attached
> source-differences between conditions.
> Best, Patrick
>
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> Am 20.11.2020 um 13:02 schrieb Stephen Whitmarsh <
> stephen.whitmarsh at gmail.com>:
>
> Hi Patrick,
>
> Things are becoming clearer now, good to see.
>
> So yes, that artefact in the back of the head: I would definitely take
> care of that. Maybe do another run of (visual) artefact rejection, or
> remove those channels.
> That the effect is less apparent in the relative difference is not
> surprising as the absolute differences are expected to be bigger than on
> other channels due to large amplitudes of the artefacts, which will be
> 'normalized' over channels when using a relative difference.
>
> I would be careful about interpreting left-right on the plot. Note that
> you assume you are looking from the top/front of the head
> downwards/backwards - but there is no way of confirming that based on the
> picture! People often place some kind of marker on the left or right side
> of the head when doing an MRI scan - e.g. a vitamin D (?) capsule I think
> so that one can verify the radiological versus anatomical (?)
> representation (LR is flipped in radiological plots). You could do this
> once, and verify your pipeline, if you want to be 100% sure.
>
> Lastly, it seems that the source picture could benefit from using a
> slightly larger beamformer scanning grid so to overlap more with the edge
> of the brain/skull. I used to do that using a negative value for the inward
> shift parameter (cfg.inwardshift) in ft_prepare_sourcemodel. Maybe there is
> an easy way for you to do that in your pipeline as well.
>
> Looking good!
> Stephen
>
>
>
>
>
> Op vr 20 nov. 2020 om 12:31 schreef Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de>:
>
> Dear Stephen,
>
> thanks for the response.
>
> I followed your suggestions and attached the plots. I performed Morlet
> wavelets TF analyses and mtmfft for conditions A and B. I did not use a
> baseline correction to see whether this is necessary. As you can see in the
> topographical plots, both conditions (A and B) have high power in 2
> posterior electrodes (I guess some kind of artifact or noise is the
> reason). Using the abs. difference between A and B does not get rid of that
> fact, probably because one condition is more affected than the other. Using
> the rel. difference does a better job and resembles my previous
> baseline-corrected results. I also compared the baselines and they were not
> different. The two conditions were furthermore randomized within the same
> protocol. I assume that adding a baseline is thus unnecessary.
>
> Regarding the source_analysis, the results for individual conditions A and
> B (NAI) as well as abs dif between A and B look weird again. But that’s
> very likely due to the same problem as for the power. For rel dif between A
> and B, the source plot seems more reasonable, although I expect the source
> to be in the right hemisphere and not in the left as shown in the plot. I
> controlled that all my input data (electrodes, volume condition model, MRI)
> have the same definition of the axes (x+ pointing right, y+ pointing
> anterior, z+ pointing superior) so I don’t think there is a right-left
> mix-up!?
>
> Now I am wondering whether I have to accept the result for the rel
> difference in sources between A and B (which is very hard to interpret and
> justify after what I am observing in the TF analysis, namely an effect in
> the other hemisphere) or whether there might be still some issue in my
> approach. It is very hard for me to believe that the source analysis does
> have so strong assumptions such that it can be in such strong contrast to
> my power data.
>
> If I am correct, what I input into the source analyses (apart from my
> models) for conditions A and B are 1) the corresponding power matrix (64
> channels x 1 power value) and the CSD (2016 * 1). It could of course be
> that the source analysis is very sensitive to the large abs differences in
> power/CSD data between electrodes. However, I also used cfg.supchan
> (suppressing specific channels) in the source analysis for the 2 channels
> that were „off“ to see whether this makes it different.However, the source
> result is similar.
>
> Any comment is appreciated.   All plots, data and scripts are at (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>
> Best, Patrick
>
> %%
>
> cfg                  = [];
> cfg.headmodel        = vol;
> cfg.elec             = elec_aligned;
> cfg.reducerank       = 2;
> cfg.resolution       = 1;
> sourcemodel_beta = ft_prepare_leadfield(cfg,data_beta);
>
> %%
>
> cfg              = [];
> cfg.method       = 'dics';
> cfg.sourcemodel  = sourcemodel_beta;
> cfg.headmodel    = vol;
> cfg.elec         = elec_aligned;
> cfg.frequency    = 28;
> cfg.dics.projectnoise = 'yes';
> cfg.dics.keepfilter   = 'yes';
> cfg.dics.realfilter   = 'yes';
> sourceAll_beta = ft_sourceanalysis(cfg, data_beta);
>
> %%
>
> cfg              = [];
> cfg.method       = 'dics';
> cfg.headmodel    = vol;
> cfg.elec         = elec_aligned;
> cfg.dics.projectnoise = 'yes';
> cfg.dics.keepfilter   = 'yes';
> cfg.dics.realfilter   = 'yes';
> cfg.sourcemodel  = sourcemodel_beta;
> cfg.sourcemodel.filter = sourceAll_beta.avg.filter;
>
> source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
> source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
>
>
> %%
>
> sourceNAI1 = source_beta_1;
> sourceNAI1.avg.pow = source_beta_1.avg.pow ./ source_beta_1.avg.noise;
>
> sourceNAI0 = source_beta_0;
> sourceNAI0.avg.pow = source_beta_0.avg.pow ./ source_beta_0.avg.noise;
>
> cfg            = [];
> cfg.parameter = 'pow';
> cfg.operation = 'x1./x2';
> sourceDiff_beta_rel = ft_math(cfg, source_beta_1,source_beta_0);
>
> cfg            = [];
> cfg.parameter = 'pow';
> cfg.operation = 'x1 - x2';
> sourceDiff_beta_abs = ft_math(cfg, source_beta_1,source_beta_0);
>
> %%
> cfg            = [];
> cfg.downsample = 2;
> cfg.parameter  = 'pow';
> sourceDiffInt_beta_dif_rel  = ft_sourceinterpolate(cfg,
> sourceDiff_beta_rel , mri_realigned);
> sourceDiffInt_beta_dif_abs  = ft_sourceinterpolate(cfg,
> sourceDiff_beta_abs , mri_realigned);
> sourceDiffInt_beta_dif_0  = ft_sourceinterpolate(cfg, sourceNAI0 ,
> mri_realigned);
> sourceDiffInt_beta_dif_1  = ft_sourceinterpolate(cfg, sourceNAI1 ,
> mri_realigned);
>
> %%
> maxval_beta_rel = max(sourceDiffInt_beta_dif_rel.pow);
> maxval_beta_abs = max(sourceDiffInt_beta_dif_abs.pow);
>
> %%
> cfg = [];
> cfg.nonlinear     = 'no';
> sourceDiffIntNorm_beta_dif_rel = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif_rel);
> sourceDiffIntNorm_beta_dif_abs = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif_abs);
> sourceDiffIntNorm_beta_dif_0 = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif_0);
> sourceDiffIntNorm_beta_dif_1 = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif_1);
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> Am 19.11.2020 um 14:59 schrieb Stephen Whitmarsh <
> stephen.whitmarsh at gmail.com>:
>
> Dear Patrick,
>
> Nice to see you are progressing. The TFR topoplots look nice (and the
> effect seems even stronger in the mtmfft version)!
>
> I agree the source reconstruction looks pretty iffy. A single dot like
> that shouldn't be there - no source in Beamformer is so focal. It suggests
> something is off, which could be as simple as a single electrode doing
> something weird (given how focal and superficial the artefact is).
>
> I would take another step back;
> I would first look at the distribution of your absolute beta, i.e. without
> baseline correction. For both conditions.
> I would then look at the distribution of your baseline beta, i.e. only
> your baseline. For both conditions.
> You should satisfy yourself that the results make sense, i.e. nothing too
> drastic, focal, etc., and some density of beta power around the central
> sulcus (?).
>
> Now I understand your contrast better, I have to ask why you do the
> baseline correction as you do. In this way you are using a separate BL for
> each condition, meaning that after BL-correction you are actually also
> comparing BL as much as you are comparing post-BL activity - after
> BL-correction any differences in BL become difference in your active
> period.
> If you assume differences in BL you might want to compare those separately
> before you 'add' them to your active period. If you have a randomized
> design, you might not want to do any BL correction in your contrast at all.
> Also, if there are no differences in BL, then it would make no difference...
> So, when you have a good sense of the absolute values and source
> distributions, you might want to try just comparing active period A vs B,
> relative (/) or absolute (-), and forget about the BL. Sometimes the BL is
> more noisy than the active period even.
>
> Anyway, your script looks fine to me, but it's been a while. However, I
> suspect that one of your datasets (A, A_BL, B, or B_BL) has some artefact
> that is introduced in the contrast.
>
> Cheers,
> Stephen
>
>
>
>
>
>
>
>
>
>
>
> Op do 19 nov. 2020 om 13:27 schreef Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de>:
>
> Dear fieldtrip community,
>
> first of all, thank you for your valuable responses @Tzvetan and Stephen.
> They were both very helpful and got me to dig deeper into the analysis.
>
> You were absolutely right in describing my approach for my Morlet wavelet
> TF analysis. The data were baseline corrected (in db). When contrasting the
> 2 conditions of interest, I receive the attached figure (dif_morlet). After
> your responses, I took the same approach for the mtmfft data
> with cfg.tapsmofrq = 8 (center frequency at 28 Hz) to reproduce the effect
> that I found between 20-35 Hz in the morlet wavelet analyses. I
> calculated frequency analysis (mtmfft) for both conditions (data_1, data_0)
> and their baseline periods (data_1_bas, data_0_bas) separately and then
> „baseline corrected“ the data from both conditions (also in db, see
> dif_mtmfft). The differences between conditions are now very similar
> between both approaches (morlet vs mtmfft).
>
> In the next step. I followed your advice and performed source analyses of
> frequency_data for all 4 conditions separately (pow_1, pow_0,
> pow_1_baseline, pow_0_baseline) as well as from all_data from
> ft_appenddata. For the source_analyses from all 4 conditions, I am using
> the common filter from all_data as well as the source model
> (ft_prepare_leadfieldds) from all_data. After performing the
> ft_source_analysis function for all 4 conditions, I am trying to replicate
> what I have done with the power data ( in db). For this reason, I am using
> ft_math with source_1_dif = 10*log10 (source_1/source_1_baseline) and the
> same for source_0. After this, I am subtracting source_0_dif
> from source_1_dif as done during the frequency analysis yielding my final
> source data.
>
> After interpolating the source differences, I am using ft_volumenormalise.
> The result from this approach is attached in dif_sources.
>
> I am a bit puzzled since I would not expect these source data based on my
> power mtmfft data. I made sure that the coordinate systems and units are
> the same across models (volume_conduction_model, electrodes, MRI) but I am
> wondering whether I am doing something wrong in performing the
> source_analysis or whether the source results are reasonable.
>
> Again, I uploaded the script and the data such that my analysis pipeline
> could be reproduced by everyone who is interested (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
> Below, I am attaching the code for the source_analyses steps. Any comments
> on my results or approach are welcome.
>
> All the Best from Germany,
> Patrick
>
>
>
> .
>
>
>
>
>
>
> cfg              = [];
> cfg.method       = 'dics';
> cfg.headmodel    = vol;
> cfg.elec         = elec_aligned;
> cfg.dics.projectnoise = 'yes';
> cfg.dics.lambda       = '5%';
> cfg.dics.keepfilter   = 'yes';
> cfg.dics.realfilter   = 'yes';
> cfg.sourcemodel  = sourcemodel_beta;
> source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
> source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
> source_beta_1_bas = ft_sourceanalysis(cfg, data_beta_1_bas);
> source_beta_0_bas = ft_sourceanalysis(cfg, data_beta_0_bas);
>
>
> %%
> cfg            = [];
> cfg.parameter = 'pow';
> cfg.operation = '10*log10(x1/x2)';
> sourceDiff1_beta = ft_math(cfg, source_beta_1,source_beta_1_bas);
> sourceDiff0_beta = ft_math(cfg, source_beta_0,source_beta_0_bas);
>
> sourceDiff_beta_dif = sourceDiff1_beta;
> sourceDiff_beta_dif.pow = sourceDiff1_beta.pow - sourceDiff0_beta.pow;
>
> %%
> cfg            = [];
> cfg.downsample = 2;
> cfg.parameter  = 'pow';
> sourceDiffInt_beta_dif  = ft_sourceinterpolate(cfg, sourceDiff_beta_dif ,
> mri_realigned);
>
> %%
> maxval_beta = max(sourceDiffInt_beta_dif.pow);
> %%
> cfg = [];
> cfg.nonlinear     = 'no';
>
> sourceDiffIntNorm_beta_dif = ft_volumenormalise(cfg,
> sourceDiffInt_beta_dif);
>
> %%
> cfg = [];
> cfg.method        = 'ortho';
> cfg.interactive   = 'yes';
> cfg.funparameter  = 'pow';
> cfg.maskparameter = cfg.funparameter;
> cfg.funcolorlim   = [0.0 maxval_beta];
> cfg.opacitylim    = [0.0 maxval_beta];
> cfg.opacitymap    = 'rampup';
> ft_sourceplot(cfg, sourceDiffIntNorm_beta_dif);
> %%
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> Am 13.11.2020 um 12:48 schrieb Stephen Whitmarsh <
> stephen.whitmarsh at gmail.com>:
>
> Hi Patrick, (and Tzvetan - who responded in the meantime),
>
> I agree that you should start with a good correspondence between your
> initial results (wavelets), and the power difference you are trying to
> localize (with mtmfft).
>
> Wavelets and fft methods can result in very similar - practically
> identical - results, but that depends on a number of parameters, especially
> concerning frequency-smoothing; Wavelets are typically defined in terms of
> nr. of cycles, while fft methods are defined in terms of time-windows.
> Wavelets defined in nr. of cycles will have a decreasing time-windows with
> increasing frequency, while with mtmfft time windows will remain the same.
> Because of this, frequency smoothing will increase with frequency with
> wavelets, and stay the same with a constant time window. Of course, you can
> make the fft time window frequency-dependent, as is described in the
> frequency-analyses tutorial, to make them more comparable. Secondly, the
> fft method allows you to specify frequency smoothing when you use Sleppian
> multitapers (cfg.taper = 'dpss'). To be clear, you should be able to
> recognize these differences in frequency smoothing/resolution when looking
> at the different TFR plots. Currently they look too different, probably
> because of something else (baseline?) than a wavelet-fft difference.
>
> I would advise making a 'full' TFR with mtmfft similar as your wavelet
> results so that you can properly compare them. This allows you to also set
> the best parameters for smoothing/timeperiods. In fact, you can use the
> multitaper approach to more accurately extract the power in a certain
> frequency band. Only then compare the topo's, and only then do the
> beamformer, so you will pick up any unexpected results.
>
> Because of different contrasts/baseline correction, I cannot compare the
> topo's / beamformer results.
>
> Bon courage,
> Stephen
>
>
>
>
>
>
>
>
>
> Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de>:
>
> Dear Field-trip community,
>
> I am working on EEG data from a motor learning task. in the first part of
> my analysis, I performed a time-frequency analysis (Morlet wavelet method)
> and cluster-based permutation test. I compared two different conditions
> (correct & incorrect movements) within subjects and found a significant
> difference in the beta band (20-35 Hz) when subjects were provided with
> feedback. I attached the topographical plot from one subject that
> illustrates the difference between the conditions at the selected time
> point and frequency (dif_morlet). As you can see, beta power was higher in
> one condition in lateral frontal electrodes.
>
> Now, I would like to better spatially locate the effect for this single
> subject. For this purpose, I followed the Beamformer tutorial on the
> website. In the first step, I selected the raw data of interest (at the
> time where the effect was seen) and performed frequency analyses for the
> 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft).
> There is an apparent difference between dif_morlet and dif_mtmfft and I am
> wondering why this is the case? One apparent reason is that the
> time-frequency data were baseline corrected and the frequency data from
> mtmfft not.
>
> Using the power and CSD data from mtmfft, I performed the source analysis
> with a standard MRI and head model. The source was located in the left
> hemisphere (source plot), which is in stark contrast to the time-frequency
> data (dif_morlet). I am aware that the source analysis is based on a lot of
> assumptions (conductivity etc.) that influence the calculations but it is
> very difficult to make sense of such discrepancy.
> Maybe it is necessary to also baseline correct the mtmfft data before
> inputting them to the source analysis? Or doing the contrasting source
> localization betwee a single condition and the corresponding baseline data
> before contrasting the 2 conditions?
>
> I am providing all necessary files and scripts (TF_analysis & BEAMFORMER)
> if anyone is interested to reproduce the results that I am showing and
> reporting for this single subject (
> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>
> I would appreciate any help and discussion on that.
>
> All the best,
> Patrick
>
>
>
>
>
> *Patrick Wiegel*
> Department of Sport and Sport Science
>
> University of Freiburg
> Sandfangweg 4
> 79117 Freiburg i. Br .
>
> phone: +49 (0)761/ 203-4550
> email: patrick.wiegel at sport.uni-freiburg.de
> <patrick.wiegel at sport.uni-freiburg.de>
> web: www.sport.uni-freiburg.de
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201124/80e2c6b3/attachment.htm>

From stephen.whitmarsh at gmail.com  Tue Nov 24 11:06:37 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Tue, 24 Nov 2020 11:06:37 +0100
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <CAFrxm=wULQG5iKcxgNqCNcgxj9GURaLg3pG3PzaLKSCMztvsnw@mail.gmail.com>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
 <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
 <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>
 <CAFrxm=wdQ1qSnWkRk+Bkb+nY14WaJEwkRCf89PaCevU6amTg7g@mail.gmail.com>
 <BB83D822-468A-4C28-AF6F-BE2807F76DBB@sport.uni-freiburg.de>
 <CAFrxm=yjQ6th0_=07bjUWYkAbOVDoYpQ7Aa8+jVmfBHi6k0-ng@mail.gmail.com>
 <D2858661-926F-4328-9E20-054752DD7C16@sport.uni-freiburg.de>
 <CAFrxm=wULQG5iKcxgNqCNcgxj9GURaLg3pG3PzaLKSCMztvsnw@mail.gmail.com>
Message-ID: <CAFrxm=ziDuKt4QRgftZt63vorGGGtHnnQqgZE91HvYTZ1Aksfg@mail.gmail.com>

[send too early - completed response here]

Hi Patrick,

Concerning L-R, it's not about the MRI, but rather how you are looking at
it - top to bottom, or bottom-to-up, left as left (anatomical), or left as
right (radiological). One thing you can do is to not use the 'ortho', but
rather 'surface' method of plotting - that would give you a real 3D
representation. If that ends up looking like how you would expect it then
perhaps that would be enough :).

I don't know why inward_shift doesn't work for you; but check this tutorial
in which it is used:
https://www.fieldtriptoolbox.org/tutorial/beamformer_lcmv/

What I also don't really get is how you get those very dramatic
pixelated edges in the source plot, while you keep very smooth / highres
grid inside?

Anyway, that sourceplot doesn't look very good, it seems even worse/weirder
than the previous one. The way you mask isn't helping either - you are
cutting away one whole part of the contrast and I don't see why you would
want to do that. Perhaps use relative-change (sometime like (A-B)/B) and
center your colormap (make it symmetrical) around 1. And don't mask
according to the values. That strange deep source does suggest you might
need to remove that posterior channel as it might screw up your beamformer
filter...

In the end, I guess this is just a single subject, and the real proof is in
looking at the whole cohort and some estimates with averages etc. Maybe
start on a second subject, and see if you find similar problems or not.
That would be another way of checking your pipeline.

Cheers,
stephen






Op di 24 nov. 2020 om 11:00 schreef Stephen Whitmarsh <
stephen.whitmarsh at gmail.com>:

> Hi Patrick,
>
> Concerning L-R, it's not about the MRI, but rather how you are looking at
> it - top to bottom, or bottom-to-up, left as left (anatomical), or left as
> right (radiological). One thing you can do is to not use the 'ortho', but
> rather 'surface' method of plotting - that would give you a real 3D
> representation. If that ends up looking like how you would expect it then
> perhaps that would be enough :).
>
> I don't know why inward_shift doesn't work for you; but check this
> tutorial in which it is used:
> https://www.fieldtriptoolbox.org/tutorial/beamformer_lcmv/
>
> What I also don't really get is how you get those very dramatic
> pixelated edges in the source plot, while you keep very smooth / highres
> grid inside?
>
> Anyway, that sourceplot doesn't look very good, it seems even
> worse/weirder than the previous one. The way you mask isn't helping either
> - you are cutting away one whole part of the contrast and I don't see why
> you would want to do that. Perhaps use rel
>
>
>
>
>
>
>
> Op di 24 nov. 2020 om 10:29 schreef Patrick Wiegel <
> patrick.wiegel at sport.uni-freiburg.de>:
>
>> Hi Stephen, hi fiedltrip community
>>
>> first of all, thanks for the good discussion that we have:-).
>>
>> The 2 channels in the back were indeed a bit noisy, so I removed those. I
>> attached the results from the new mtmfft analysis. The abs and rel
>> differences between A and B become clearer now, although you could still
>> argue to remove the most right posterior channel. However, I don’t want to
>> loose too much information and I think it is okay to stick with this.
>>
>> Your argumentation on the right/left behavior in MRIs was helpful. I had
>> to think/read about that for a while. Since I am using the standard_MRI
>> from the fieldtrip page (
>> https://github.com/fieldtrip/fieldtrip/tree/master/template/headmodel),
>> I cannot certainly tell where left and right is. the transformation matrix
>> of the standard MRI is the following which leads me to assume that right is
>> right?
>>
>>     0.1000         0         0  -12.8500
>>          0    0.1000         0  -12.8500
>>          0         0    0.1000  -12.8500
>>          0         0         0    1.0000
>>
>>
>> I tried to use a larger grid during ft_prepare_sourcemodel, however, it
>> seems that as soon as I use a negative inward shift, the ft_sourceanalysis
>> function does not work. I get the following error.
>>
>>
>> Error using svd
>> Input to SVD must not contain NaN or Inf.
>>
>> Error in ft_inverse_dics>pinv (line 590)
>>   [U,S,V] = svd(A,0);
>>
>> Error in ft_inverse_dics (line 475)
>>         filt = pinv(lf' * invC * lf) * lf' * invC; % Gross eqn. 3 & van
>> Veen eqn. 23, use PINV/SVD to cover rank
>>         deficient leadfield
>>
>> Error in ft_sourceanalysis (line 763)
>>           dip(i) = ft_inverse_dics(sourcemodel, sens, headmodel, [],
>>  squeeze_Cf, methodopt{:}, leadfieldopt{:});
>>
>> Error in FT_example_without_baseline (line 121)
>> sourceAll_beta = ft_sourceanalysis(cfg, data_beta);
>>
>>
>> Not using a negative inward-shift results in the attached
>> source-differences between conditions.
>> Best, Patrick
>>
>>
>>
>> *Patrick Wiegel*
>> Department of Sport and Sport Science
>>
>> University of Freiburg
>> Sandfangweg 4
>> 79117 Freiburg i. Br .
>>
>> phone: +49 (0)761/ 203-4550
>> email: patrick.wiegel at sport.uni-freiburg.de
>> <patrick.wiegel at sport.uni-freiburg.de>
>> web: www.sport.uni-freiburg.de
>>
>> Am 20.11.2020 um 13:02 schrieb Stephen Whitmarsh <
>> stephen.whitmarsh at gmail.com>:
>>
>> Hi Patrick,
>>
>> Things are becoming clearer now, good to see.
>>
>> So yes, that artefact in the back of the head: I would definitely take
>> care of that. Maybe do another run of (visual) artefact rejection, or
>> remove those channels.
>> That the effect is less apparent in the relative difference is not
>> surprising as the absolute differences are expected to be bigger than on
>> other channels due to large amplitudes of the artefacts, which will be
>> 'normalized' over channels when using a relative difference.
>>
>> I would be careful about interpreting left-right on the plot. Note that
>> you assume you are looking from the top/front of the head
>> downwards/backwards - but there is no way of confirming that based on the
>> picture! People often place some kind of marker on the left or right side
>> of the head when doing an MRI scan - e.g. a vitamin D (?) capsule I think
>> so that one can verify the radiological versus anatomical (?)
>> representation (LR is flipped in radiological plots). You could do this
>> once, and verify your pipeline, if you want to be 100% sure.
>>
>> Lastly, it seems that the source picture could benefit from using a
>> slightly larger beamformer scanning grid so to overlap more with the edge
>> of the brain/skull. I used to do that using a negative value for the inward
>> shift parameter (cfg.inwardshift) in ft_prepare_sourcemodel. Maybe there is
>> an easy way for you to do that in your pipeline as well.
>>
>> Looking good!
>> Stephen
>>
>>
>>
>>
>>
>> Op vr 20 nov. 2020 om 12:31 schreef Patrick Wiegel <
>> patrick.wiegel at sport.uni-freiburg.de>:
>>
>> Dear Stephen,
>>
>> thanks for the response.
>>
>> I followed your suggestions and attached the plots. I performed Morlet
>> wavelets TF analyses and mtmfft for conditions A and B. I did not use a
>> baseline correction to see whether this is necessary. As you can see in the
>> topographical plots, both conditions (A and B) have high power in 2
>> posterior electrodes (I guess some kind of artifact or noise is the
>> reason). Using the abs. difference between A and B does not get rid of that
>> fact, probably because one condition is more affected than the other. Using
>> the rel. difference does a better job and resembles my previous
>> baseline-corrected results. I also compared the baselines and they were not
>> different. The two conditions were furthermore randomized within the same
>> protocol. I assume that adding a baseline is thus unnecessary.
>>
>> Regarding the source_analysis, the results for individual conditions A
>> and B (NAI) as well as abs dif between A and B look weird again. But that’s
>> very likely due to the same problem as for the power. For rel dif between A
>> and B, the source plot seems more reasonable, although I expect the source
>> to be in the right hemisphere and not in the left as shown in the plot. I
>> controlled that all my input data (electrodes, volume condition model, MRI)
>> have the same definition of the axes (x+ pointing right, y+ pointing
>> anterior, z+ pointing superior) so I don’t think there is a right-left
>> mix-up!?
>>
>> Now I am wondering whether I have to accept the result for the rel
>> difference in sources between A and B (which is very hard to interpret and
>> justify after what I am observing in the TF analysis, namely an effect in
>> the other hemisphere) or whether there might be still some issue in my
>> approach. It is very hard for me to believe that the source analysis does
>> have so strong assumptions such that it can be in such strong contrast to
>> my power data.
>>
>> If I am correct, what I input into the source analyses (apart from my
>> models) for conditions A and B are 1) the corresponding power matrix (64
>> channels x 1 power value) and the CSD (2016 * 1). It could of course be
>> that the source analysis is very sensitive to the large abs differences in
>> power/CSD data between electrodes. However, I also used cfg.supchan
>> (suppressing specific channels) in the source analysis for the 2 channels
>> that were „off“ to see whether this makes it different.However, the source
>> result is similar.
>>
>> Any comment is appreciated.   All plots, data and scripts are at (
>> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>>
>> Best, Patrick
>>
>> %%
>>
>> cfg                  = [];
>> cfg.headmodel        = vol;
>> cfg.elec             = elec_aligned;
>> cfg.reducerank       = 2;
>> cfg.resolution       = 1;
>> sourcemodel_beta = ft_prepare_leadfield(cfg,data_beta);
>>
>> %%
>>
>> cfg              = [];
>> cfg.method       = 'dics';
>> cfg.sourcemodel  = sourcemodel_beta;
>> cfg.headmodel    = vol;
>> cfg.elec         = elec_aligned;
>> cfg.frequency    = 28;
>> cfg.dics.projectnoise = 'yes';
>> cfg.dics.keepfilter   = 'yes';
>> cfg.dics.realfilter   = 'yes';
>> sourceAll_beta = ft_sourceanalysis(cfg, data_beta);
>>
>> %%
>>
>> cfg              = [];
>> cfg.method       = 'dics';
>> cfg.headmodel    = vol;
>> cfg.elec         = elec_aligned;
>> cfg.dics.projectnoise = 'yes';
>> cfg.dics.keepfilter   = 'yes';
>> cfg.dics.realfilter   = 'yes';
>> cfg.sourcemodel  = sourcemodel_beta;
>> cfg.sourcemodel.filter = sourceAll_beta.avg.filter;
>>
>> source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
>> source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
>>
>>
>> %%
>>
>> sourceNAI1 = source_beta_1;
>> sourceNAI1.avg.pow = source_beta_1.avg.pow ./ source_beta_1.avg.noise;
>>
>> sourceNAI0 = source_beta_0;
>> sourceNAI0.avg.pow = source_beta_0.avg.pow ./ source_beta_0.avg.noise;
>>
>> cfg            = [];
>> cfg.parameter = 'pow';
>> cfg.operation = 'x1./x2';
>> sourceDiff_beta_rel = ft_math(cfg, source_beta_1,source_beta_0);
>>
>> cfg            = [];
>> cfg.parameter = 'pow';
>> cfg.operation = 'x1 - x2';
>> sourceDiff_beta_abs = ft_math(cfg, source_beta_1,source_beta_0);
>>
>> %%
>> cfg            = [];
>> cfg.downsample = 2;
>> cfg.parameter  = 'pow';
>> sourceDiffInt_beta_dif_rel  = ft_sourceinterpolate(cfg,
>> sourceDiff_beta_rel , mri_realigned);
>> sourceDiffInt_beta_dif_abs  = ft_sourceinterpolate(cfg,
>> sourceDiff_beta_abs , mri_realigned);
>> sourceDiffInt_beta_dif_0  = ft_sourceinterpolate(cfg, sourceNAI0 ,
>> mri_realigned);
>> sourceDiffInt_beta_dif_1  = ft_sourceinterpolate(cfg, sourceNAI1 ,
>> mri_realigned);
>>
>> %%
>> maxval_beta_rel = max(sourceDiffInt_beta_dif_rel.pow);
>> maxval_beta_abs = max(sourceDiffInt_beta_dif_abs.pow);
>>
>> %%
>> cfg = [];
>> cfg.nonlinear     = 'no';
>> sourceDiffIntNorm_beta_dif_rel = ft_volumenormalise(cfg,
>> sourceDiffInt_beta_dif_rel);
>> sourceDiffIntNorm_beta_dif_abs = ft_volumenormalise(cfg,
>> sourceDiffInt_beta_dif_abs);
>> sourceDiffIntNorm_beta_dif_0 = ft_volumenormalise(cfg,
>> sourceDiffInt_beta_dif_0);
>> sourceDiffIntNorm_beta_dif_1 = ft_volumenormalise(cfg,
>> sourceDiffInt_beta_dif_1);
>>
>> *Patrick Wiegel*
>> Department of Sport and Sport Science
>>
>> University of Freiburg
>> Sandfangweg 4
>> 79117 Freiburg i. Br .
>>
>> phone: +49 (0)761/ 203-4550
>> email: patrick.wiegel at sport.uni-freiburg.de
>> <patrick.wiegel at sport.uni-freiburg.de>
>> web: www.sport.uni-freiburg.de
>>
>> Am 19.11.2020 um 14:59 schrieb Stephen Whitmarsh <
>> stephen.whitmarsh at gmail.com>:
>>
>> Dear Patrick,
>>
>> Nice to see you are progressing. The TFR topoplots look nice (and the
>> effect seems even stronger in the mtmfft version)!
>>
>> I agree the source reconstruction looks pretty iffy. A single dot like
>> that shouldn't be there - no source in Beamformer is so focal. It suggests
>> something is off, which could be as simple as a single electrode doing
>> something weird (given how focal and superficial the artefact is).
>>
>> I would take another step back;
>> I would first look at the distribution of your absolute beta, i.e.
>> without baseline correction. For both conditions.
>> I would then look at the distribution of your baseline beta, i.e. only
>> your baseline. For both conditions.
>> You should satisfy yourself that the results make sense, i.e. nothing too
>> drastic, focal, etc., and some density of beta power around the central
>> sulcus (?).
>>
>> Now I understand your contrast better, I have to ask why you do the
>> baseline correction as you do. In this way you are using a separate BL for
>> each condition, meaning that after BL-correction you are actually also
>> comparing BL as much as you are comparing post-BL activity - after
>> BL-correction any differences in BL become difference in your active
>> period.
>> If you assume differences in BL you might want to compare those
>> separately before you 'add' them to your active period. If you have a
>> randomized design, you might not want to do any BL correction in your
>> contrast at all. Also, if there are no differences in BL, then it would
>> make no difference...
>> So, when you have a good sense of the absolute values and source
>> distributions, you might want to try just comparing active period A vs B,
>> relative (/) or absolute (-), and forget about the BL. Sometimes the BL is
>> more noisy than the active period even.
>>
>> Anyway, your script looks fine to me, but it's been a while. However, I
>> suspect that one of your datasets (A, A_BL, B, or B_BL) has some artefact
>> that is introduced in the contrast.
>>
>> Cheers,
>> Stephen
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Op do 19 nov. 2020 om 13:27 schreef Patrick Wiegel <
>> patrick.wiegel at sport.uni-freiburg.de>:
>>
>> Dear fieldtrip community,
>>
>> first of all, thank you for your valuable responses @Tzvetan and Stephen.
>> They were both very helpful and got me to dig deeper into the analysis.
>>
>> You were absolutely right in describing my approach for my Morlet wavelet
>> TF analysis. The data were baseline corrected (in db). When contrasting the
>> 2 conditions of interest, I receive the attached figure (dif_morlet). After
>> your responses, I took the same approach for the mtmfft data
>> with cfg.tapsmofrq = 8 (center frequency at 28 Hz) to reproduce the effect
>> that I found between 20-35 Hz in the morlet wavelet analyses. I
>> calculated frequency analysis (mtmfft) for both conditions (data_1, data_0)
>> and their baseline periods (data_1_bas, data_0_bas) separately and then
>> „baseline corrected“ the data from both conditions (also in db, see
>> dif_mtmfft). The differences between conditions are now very similar
>> between both approaches (morlet vs mtmfft).
>>
>> In the next step. I followed your advice and performed source analyses of
>> frequency_data for all 4 conditions separately (pow_1, pow_0,
>> pow_1_baseline, pow_0_baseline) as well as from all_data from
>> ft_appenddata. For the source_analyses from all 4 conditions, I am using
>> the common filter from all_data as well as the source model
>> (ft_prepare_leadfieldds) from all_data. After performing the
>> ft_source_analysis function for all 4 conditions, I am trying to replicate
>> what I have done with the power data ( in db). For this reason, I am using
>> ft_math with source_1_dif = 10*log10 (source_1/source_1_baseline) and the
>> same for source_0. After this, I am subtracting source_0_dif
>> from source_1_dif as done during the frequency analysis yielding my final
>> source data.
>>
>> After interpolating the source differences, I am
>> using ft_volumenormalise. The result from this approach is attached in
>> dif_sources.
>>
>> I am a bit puzzled since I would not expect these source data based on my
>> power mtmfft data. I made sure that the coordinate systems and units are
>> the same across models (volume_conduction_model, electrodes, MRI) but I am
>> wondering whether I am doing something wrong in performing the
>> source_analysis or whether the source results are reasonable.
>>
>> Again, I uploaded the script and the data such that my analysis pipeline
>> could be reproduced by everyone who is interested (
>> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>> Below, I am attaching the code for the source_analyses steps. Any comments
>> on my results or approach are welcome.
>>
>> All the Best from Germany,
>> Patrick
>>
>>
>>
>> .
>>
>>
>>
>>
>>
>>
>> cfg              = [];
>> cfg.method       = 'dics';
>> cfg.headmodel    = vol;
>> cfg.elec         = elec_aligned;
>> cfg.dics.projectnoise = 'yes';
>> cfg.dics.lambda       = '5%';
>> cfg.dics.keepfilter   = 'yes';
>> cfg.dics.realfilter   = 'yes';
>> cfg.sourcemodel  = sourcemodel_beta;
>> source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
>> source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
>> source_beta_1_bas = ft_sourceanalysis(cfg, data_beta_1_bas);
>> source_beta_0_bas = ft_sourceanalysis(cfg, data_beta_0_bas);
>>
>>
>> %%
>> cfg            = [];
>> cfg.parameter = 'pow';
>> cfg.operation = '10*log10(x1/x2)';
>> sourceDiff1_beta = ft_math(cfg, source_beta_1,source_beta_1_bas);
>> sourceDiff0_beta = ft_math(cfg, source_beta_0,source_beta_0_bas);
>>
>> sourceDiff_beta_dif = sourceDiff1_beta;
>> sourceDiff_beta_dif.pow = sourceDiff1_beta.pow - sourceDiff0_beta.pow;
>>
>> %%
>> cfg            = [];
>> cfg.downsample = 2;
>> cfg.parameter  = 'pow';
>> sourceDiffInt_beta_dif  = ft_sourceinterpolate(cfg, sourceDiff_beta_dif ,
>> mri_realigned);
>>
>> %%
>> maxval_beta = max(sourceDiffInt_beta_dif.pow);
>> %%
>> cfg = [];
>> cfg.nonlinear     = 'no';
>>
>> sourceDiffIntNorm_beta_dif = ft_volumenormalise(cfg,
>> sourceDiffInt_beta_dif);
>>
>> %%
>> cfg = [];
>> cfg.method        = 'ortho';
>> cfg.interactive   = 'yes';
>> cfg.funparameter  = 'pow';
>> cfg.maskparameter = cfg.funparameter;
>> cfg.funcolorlim   = [0.0 maxval_beta];
>> cfg.opacitylim    = [0.0 maxval_beta];
>> cfg.opacitymap    = 'rampup';
>> ft_sourceplot(cfg, sourceDiffIntNorm_beta_dif);
>> %%
>>
>>
>> *Patrick Wiegel*
>> Department of Sport and Sport Science
>>
>> University of Freiburg
>> Sandfangweg 4
>> 79117 Freiburg i. Br .
>>
>> phone: +49 (0)761/ 203-4550
>> email: patrick.wiegel at sport.uni-freiburg.de
>> <patrick.wiegel at sport.uni-freiburg.de>
>> web: www.sport.uni-freiburg.de
>>
>> Am 13.11.2020 um 12:48 schrieb Stephen Whitmarsh <
>> stephen.whitmarsh at gmail.com>:
>>
>> Hi Patrick, (and Tzvetan - who responded in the meantime),
>>
>> I agree that you should start with a good correspondence between your
>> initial results (wavelets), and the power difference you are trying to
>> localize (with mtmfft).
>>
>> Wavelets and fft methods can result in very similar - practically
>> identical - results, but that depends on a number of parameters, especially
>> concerning frequency-smoothing; Wavelets are typically defined in terms of
>> nr. of cycles, while fft methods are defined in terms of time-windows.
>> Wavelets defined in nr. of cycles will have a decreasing time-windows with
>> increasing frequency, while with mtmfft time windows will remain the same.
>> Because of this, frequency smoothing will increase with frequency with
>> wavelets, and stay the same with a constant time window. Of course, you can
>> make the fft time window frequency-dependent, as is described in the
>> frequency-analyses tutorial, to make them more comparable. Secondly, the
>> fft method allows you to specify frequency smoothing when you use Sleppian
>> multitapers (cfg.taper = 'dpss'). To be clear, you should be able to
>> recognize these differences in frequency smoothing/resolution when looking
>> at the different TFR plots. Currently they look too different, probably
>> because of something else (baseline?) than a wavelet-fft difference.
>>
>> I would advise making a 'full' TFR with mtmfft similar as your wavelet
>> results so that you can properly compare them. This allows you to also set
>> the best parameters for smoothing/timeperiods. In fact, you can use the
>> multitaper approach to more accurately extract the power in a certain
>> frequency band. Only then compare the topo's, and only then do the
>> beamformer, so you will pick up any unexpected results.
>>
>> Because of different contrasts/baseline correction, I cannot compare the
>> topo's / beamformer results.
>>
>> Bon courage,
>> Stephen
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <
>> patrick.wiegel at sport.uni-freiburg.de>:
>>
>> Dear Field-trip community,
>>
>> I am working on EEG data from a motor learning task. in the first part of
>> my analysis, I performed a time-frequency analysis (Morlet wavelet method)
>> and cluster-based permutation test. I compared two different conditions
>> (correct & incorrect movements) within subjects and found a significant
>> difference in the beta band (20-35 Hz) when subjects were provided with
>> feedback. I attached the topographical plot from one subject that
>> illustrates the difference between the conditions at the selected time
>> point and frequency (dif_morlet). As you can see, beta power was higher in
>> one condition in lateral frontal electrodes.
>>
>> Now, I would like to better spatially locate the effect for this single
>> subject. For this purpose, I followed the Beamformer tutorial on the
>> website. In the first step, I selected the raw data of interest (at the
>> time where the effect was seen) and performed frequency analyses for the
>> 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft).
>> There is an apparent difference between dif_morlet and dif_mtmfft and I am
>> wondering why this is the case? One apparent reason is that the
>> time-frequency data were baseline corrected and the frequency data from
>> mtmfft not.
>>
>> Using the power and CSD data from mtmfft, I performed the source analysis
>> with a standard MRI and head model. The source was located in the left
>> hemisphere (source plot), which is in stark contrast to the time-frequency
>> data (dif_morlet). I am aware that the source analysis is based on a lot of
>> assumptions (conductivity etc.) that influence the calculations but it is
>> very difficult to make sense of such discrepancy.
>> Maybe it is necessary to also baseline correct the mtmfft data before
>> inputting them to the source analysis? Or doing the contrasting source
>> localization betwee a single condition and the corresponding baseline data
>> before contrasting the 2 conditions?
>>
>> I am providing all necessary files and scripts (TF_analysis & BEAMFORMER)
>> if anyone is interested to reproduce the results that I am showing and
>> reporting for this single subject (
>> https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).
>>
>> I would appreciate any help and discussion on that.
>>
>> All the best,
>> Patrick
>>
>>
>>
>>
>>
>> *Patrick Wiegel*
>> Department of Sport and Sport Science
>>
>> University of Freiburg
>> Sandfangweg 4
>> 79117 Freiburg i. Br .
>>
>> phone: +49 (0)761/ 203-4550
>> email: patrick.wiegel at sport.uni-freiburg.de
>> <patrick.wiegel at sport.uni-freiburg.de>
>> web: www.sport.uni-freiburg.de
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201124/f24f386c/attachment.htm>

From tom.marshall at psy.ox.ac.uk  Tue Nov 24 17:15:46 2020
From: tom.marshall at psy.ox.ac.uk (Tom Marshall)
Date: Tue, 24 Nov 2020 16:15:46 +0000
Subject: [FieldTrip] default behaviour of singleplot changed?
Message-ID: <CWLP265MB21932B1C2D0734C124782687F9FB0@CWLP265MB2193.GBRP265.PROD.OUTLOOK.COM>

Hi fieldtrippers,

Has the default behaviour of the ft_singleplotXXX functions changed recently? Because I'm used to grouping several of them together using 'subplot' something like this...

% plot the TFR of the first five channels
figure
for i = 1:5
    cfg.channel = i;
    subplot(1, 5, i)
    ft_singleplotTFR(cfg, data)
end

Previously, executing this would give me five nicely arranged subplots within a single figure. However, using the bleeding-edge fieldtrip version, this code now creates five separate figures, each with a blank subplot, and the last TFR in its own sixth figure.

So it seems like 'subplot' is being executed (because matlab is drawing the subplot in a figure), but ft_singleplotTFR isn't drawing into the subplot, but rather creating a new figure.

checked:

which singleplotTFR
/home/common/matlab/fieldtrip/ft_singleplotTFR.m  (working on donders cluster - seems correct)

which subplot
/opt/matlab/R2020b/toolbox/matlab/graph2d/subplot.m (seems correct)


replacing ft_singleplotTFR(cfg, data) in the above code with a built-in plot function - e.g., imagesc(rand(10)) - gives the expected row of subplots, so it seems like some (new?) behaviour of ft_singleplotTFR is causing matlab to treat it differently to its own plots.


help ft_singleplotTFR: Nothing here about subplots or handles.


Can somebody advise? Something simple I'm missing?


Best,

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201124/34564a3f/attachment.htm>

From m.yavuz.18 at ogr.iu.edu.tr  Wed Nov 25 02:03:20 2020
From: m.yavuz.18 at ogr.iu.edu.tr (MUSTAFA YAVUZ)
Date: Wed, 25 Nov 2020 04:03:20 +0300
Subject: [FieldTrip] Adding Manual Markers
In-Reply-To: <CAFrxm=yjk1=zFCO0TJbb7ZUdZsix8MdWPU59+JWJXVJ_GqdqrQ@mail.gmail.com>
References: <CAFWATv_t56DXhBtMmGda=Tx+HArbhRbZqSU1iWtxB+wvEhWNFQ@mail.gmail.com>
 <CAFrxm=yjk1=zFCO0TJbb7ZUdZsix8MdWPU59+JWJXVJ_GqdqrQ@mail.gmail.com>
Message-ID: <CAFWATv9NfM87EJhsYTubX9X2O6FG=XR1BCPN4Dy8YU6c-6eQgA@mail.gmail.com>

Merhaba Stephen :),

Thank you for your informative response! Indeed, I already have data as
separate segments (trials) before any initiation with Fieldtrip. I was just
wondering if I can plot the event markers just for visualization purposes.
However, I've learnt why it is the case now. In my case, I believe a
solution would be ; concatenating the trials and manipulating the time axis
to arbitrarily create a single trial (continuous?) data  structure and then
building a custom trialfun to be able to visualize markers in
ft_databrowser.

Thank you again,
All the best,
Mustafa

Stephen Whitmarsh <stephen.whitmarsh at gmail.com>, 24 Kas 2020 Sal, 11:04
tarihinde şunu yazdı:

> Merhaba Mustafa,
>
> Welcome to FieldTrip!
> Just to be clear - I assume you segmented your continuous data into trials
> by passing your marker timing as a cfg.trl in ft_preprocessing, right?
> When you did, the temporal information about the markers became
> irrelevant, because the trials are then expressed *not *in samples from
> the onset of the continuous data anymore, but instead as time relative to
> the markers. I.e. each trial now starts at t=0s (-offset), rather and, say
> [13, 104, 206, ...] samples (i.e. your initial trl). See the resultant
> data.time field.
> Secondly, ft_databrowser does not take cfg.trl as the location of markers,
> rather it does so in cfg.artfctdef.xxx.artifact (yes, a bit strange, partly
> historical, and because databrowser is typically used to manually scan for
> artifacts).
>
> So, in your case, you could either:
>
> Use ft_databrowser to plot the original, unsegmented, continuous, data,
> and pass your trialinfo (as a Nx2 matrix, with only start and end sample)
> to cfg.artfctdef.xxx.artifact. Replace xxx with whatever your want, e.g.
> "trialnumber"
> Use ft_databrowser to plot the segmented data, as trials, with new
> time-axis, without the markers.
>
> Note that ft_databrowser will try to fit your cfg.artfctdef.xxx.artifact
> to your segmented trial data as well, by doing some intelligent checking of
> your past cfg (which is tracked in your segmented data structure and
> beyond), and treating your data as continuous data. That might work, or it
> might not, but now you know why!
>
> Happy fieldtripping,
> Stephen
>
>
>
> Op di 24 nov. 2020 om 02:29 schreef MUSTAFA YAVUZ <
> m.yavuz.18 at ogr.iu.edu.tr>:
>
>> Hi all,
>>
>> I've been trying to adjust my EEG data (segmented and .mat file) to be
>> analyzed by FT. I already have separate trials and have temporal
>> information about the event markers' time courses. I constructed a Nx3 trl
>> structure and passed it as cfg.trl while calling ft_preprocessing. Whilst
>> the function worked and I can see the cfg.trl field in the output
>> structure, when I call ft_databrowser, the event markers are not displayed
>> on trials. Do you have any idea/solution for this situation?
>>
>> Thank you in advance,
>> Mustafa
>>
>> --
>> *Mustafa Yavuz *
>>
>> Ph.D. Candidate in Neuroscience
>>
>> Department of Neuroscience
>> İstanbul University
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>


-- 
*Mustafa Yavuz *

M.Sc. Candidate in Neuroscience

Department of Neuroscience
İstanbul University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/cc681d60/attachment.htm>

From stephen.whitmarsh at gmail.com  Wed Nov 25 07:56:42 2020
From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh)
Date: Wed, 25 Nov 2020 07:56:42 +0100
Subject: [FieldTrip] Adding Manual Markers
In-Reply-To: <CAFWATv9NfM87EJhsYTubX9X2O6FG=XR1BCPN4Dy8YU6c-6eQgA@mail.gmail.com>
References: <CAFWATv_t56DXhBtMmGda=Tx+HArbhRbZqSU1iWtxB+wvEhWNFQ@mail.gmail.com>
 <CAFrxm=yjk1=zFCO0TJbb7ZUdZsix8MdWPU59+JWJXVJ_GqdqrQ@mail.gmail.com>
 <CAFWATv9NfM87EJhsYTubX9X2O6FG=XR1BCPN4Dy8YU6c-6eQgA@mail.gmail.com>
Message-ID: <CAFrxm=xs06U7Jg9AT5+pND_xjtUcYTrZ2DUk7hRk6-hn1DF_jQ@mail.gmail.com>

Hi Mustafa,

Okay, great! I would first see if ft_databrowser won't just be able to
treat your data as continuous (note cfg.continuous option in it's cfg), and
then giving it your start-end markers as a Nx2 matrix in (e.g.)
cfg.artfctdef.mymarker.artifact when you call it. Pretty sure that'll work,
and it would remove the need of restructuring your data. You'll only need
to add cumulative samples to your label samples at each trial, if you get
my drift.

Hope it works out for you,
Stephen





Op wo 25 nov. 2020 om 02:35 schreef MUSTAFA YAVUZ <m.yavuz.18 at ogr.iu.edu.tr
>:

> Merhaba Stephen :),
>
> Thank you for your informative response! Indeed, I already have data as
> separate segments (trials) before any initiation with Fieldtrip. I was just
> wondering if I can plot the event markers just for visualization purposes.
> However, I've learnt why it is the case now. In my case, I believe a
> solution would be ; concatenating the trials and manipulating the time axis
> to arbitrarily create a single trial (continuous?) data  structure and then
> building a custom trialfun to be able to visualize markers in
> ft_databrowser.
>
> Thank you again,
> All the best,
> Mustafa
>
> Stephen Whitmarsh <stephen.whitmarsh at gmail.com>, 24 Kas 2020 Sal, 11:04
> tarihinde şunu yazdı:
>
>> Merhaba Mustafa,
>>
>> Welcome to FieldTrip!
>> Just to be clear - I assume you segmented your continuous data into
>> trials by passing your marker timing as a cfg.trl in ft_preprocessing,
>> right?
>> When you did, the temporal information about the markers became
>> irrelevant, because the trials are then expressed *not *in samples from
>> the onset of the continuous data anymore, but instead as time relative to
>> the markers. I.e. each trial now starts at t=0s (-offset), rather and, say
>> [13, 104, 206, ...] samples (i.e. your initial trl). See the resultant
>> data.time field.
>> Secondly, ft_databrowser does not take cfg.trl as the location of
>> markers, rather it does so in cfg.artfctdef.xxx.artifact (yes, a bit
>> strange, partly historical, and because databrowser is typically used to
>> manually scan for artifacts).
>>
>> So, in your case, you could either:
>>
>> Use ft_databrowser to plot the original, unsegmented, continuous, data,
>> and pass your trialinfo (as a Nx2 matrix, with only start and end sample)
>> to cfg.artfctdef.xxx.artifact. Replace xxx with whatever your want, e.g.
>> "trialnumber"
>> Use ft_databrowser to plot the segmented data, as trials, with new
>> time-axis, without the markers.
>>
>> Note that ft_databrowser will try to fit your cfg.artfctdef.xxx.artifact
>> to your segmented trial data as well, by doing some intelligent checking of
>> your past cfg (which is tracked in your segmented data structure and
>> beyond), and treating your data as continuous data. That might work, or it
>> might not, but now you know why!
>>
>> Happy fieldtripping,
>> Stephen
>>
>>
>>
>> Op di 24 nov. 2020 om 02:29 schreef MUSTAFA YAVUZ <
>> m.yavuz.18 at ogr.iu.edu.tr>:
>>
>>> Hi all,
>>>
>>> I've been trying to adjust my EEG data (segmented and .mat file) to be
>>> analyzed by FT. I already have separate trials and have temporal
>>> information about the event markers' time courses. I constructed a Nx3 trl
>>> structure and passed it as cfg.trl while calling ft_preprocessing. Whilst
>>> the function worked and I can see the cfg.trl field in the output
>>> structure, when I call ft_databrowser, the event markers are not displayed
>>> on trials. Do you have any idea/solution for this situation?
>>>
>>> Thank you in advance,
>>> Mustafa
>>>
>>> --
>>> *Mustafa Yavuz *
>>>
>>> Ph.D. Candidate in Neuroscience
>>>
>>> Department of Neuroscience
>>> İstanbul University
>>>
>>> _______________________________________________
>>> fieldtrip mailing list
>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>>> https://doi.org/10.1371/journal.pcbi.1002202
>>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
>
>
> --
> *Mustafa Yavuz *
>
> M.Sc. Candidate in Neuroscience
>
> Department of Neuroscience
> İstanbul University
>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/5fb346bb/attachment.htm>

From m.yavuz.18 at ogr.iu.edu.tr  Wed Nov 25 08:52:55 2020
From: m.yavuz.18 at ogr.iu.edu.tr (MUSTAFA YAVUZ)
Date: Wed, 25 Nov 2020 10:52:55 +0300
Subject: [FieldTrip] Adding Manual Markers
In-Reply-To: <CAFrxm=xs06U7Jg9AT5+pND_xjtUcYTrZ2DUk7hRk6-hn1DF_jQ@mail.gmail.com>
References: <CAFWATv_t56DXhBtMmGda=Tx+HArbhRbZqSU1iWtxB+wvEhWNFQ@mail.gmail.com>
 <CAFrxm=yjk1=zFCO0TJbb7ZUdZsix8MdWPU59+JWJXVJ_GqdqrQ@mail.gmail.com>
 <CAFWATv9NfM87EJhsYTubX9X2O6FG=XR1BCPN4Dy8YU6c-6eQgA@mail.gmail.com>
 <CAFrxm=xs06U7Jg9AT5+pND_xjtUcYTrZ2DUk7hRk6-hn1DF_jQ@mail.gmail.com>
Message-ID: <CAFWATv8Ou49Mk8U0pBfBxOFpBZ9n64EiTta03gScszpPGwJ2cg@mail.gmail.com>

Hi again Stephen,

Yeah It worked with the cfg.artfct matrix, I can now visualize the area
between my two markers as red-shaded segments in the whole trial.

Thank you!

Stephen Whitmarsh <stephen.whitmarsh at gmail.com>, 25 Kas 2020 Çar, 10:00
tarihinde şunu yazdı:

> Hi Mustafa,
>
> Okay, great! I would first see if ft_databrowser won't just be able to
> treat your data as continuous (note cfg.continuous option in it's cfg), and
> then giving it your start-end markers as a Nx2 matrix in (e.g.)
> cfg.artfctdef.mymarker.artifact when you call it. Pretty sure that'll work,
> and it would remove the need of restructuring your data. You'll only need
> to add cumulative samples to your label samples at each trial, if you get
> my drift.
>
> Hope it works out for you,
> Stephen
>
>
>
>
>
> Op wo 25 nov. 2020 om 02:35 schreef MUSTAFA YAVUZ <
> m.yavuz.18 at ogr.iu.edu.tr>:
>
>> Merhaba Stephen :),
>>
>> Thank you for your informative response! Indeed, I already have data as
>> separate segments (trials) before any initiation with Fieldtrip. I was just
>> wondering if I can plot the event markers just for visualization purposes.
>> However, I've learnt why it is the case now. In my case, I believe a
>> solution would be ; concatenating the trials and manipulating the time axis
>> to arbitrarily create a single trial (continuous?) data  structure and then
>> building a custom trialfun to be able to visualize markers in
>> ft_databrowser.
>>
>> Thank you again,
>> All the best,
>> Mustafa
>>
>> Stephen Whitmarsh <stephen.whitmarsh at gmail.com>, 24 Kas 2020 Sal, 11:04
>> tarihinde şunu yazdı:
>>
>>> Merhaba Mustafa,
>>>
>>> Welcome to FieldTrip!
>>> Just to be clear - I assume you segmented your continuous data into
>>> trials by passing your marker timing as a cfg.trl in ft_preprocessing,
>>> right?
>>> When you did, the temporal information about the markers became
>>> irrelevant, because the trials are then expressed *not *in samples from
>>> the onset of the continuous data anymore, but instead as time relative to
>>> the markers. I.e. each trial now starts at t=0s (-offset), rather and, say
>>> [13, 104, 206, ...] samples (i.e. your initial trl). See the resultant
>>> data.time field.
>>> Secondly, ft_databrowser does not take cfg.trl as the location of
>>> markers, rather it does so in cfg.artfctdef.xxx.artifact (yes, a bit
>>> strange, partly historical, and because databrowser is typically used to
>>> manually scan for artifacts).
>>>
>>> So, in your case, you could either:
>>>
>>> Use ft_databrowser to plot the original, unsegmented, continuous, data,
>>> and pass your trialinfo (as a Nx2 matrix, with only start and end sample)
>>> to cfg.artfctdef.xxx.artifact. Replace xxx with whatever your want, e.g.
>>> "trialnumber"
>>> Use ft_databrowser to plot the segmented data, as trials, with new
>>> time-axis, without the markers.
>>>
>>> Note that ft_databrowser will try to fit your cfg.artfctdef.xxx.artifact
>>> to your segmented trial data as well, by doing some intelligent checking of
>>> your past cfg (which is tracked in your segmented data structure and
>>> beyond), and treating your data as continuous data. That might work, or it
>>> might not, but now you know why!
>>>
>>> Happy fieldtripping,
>>> Stephen
>>>
>>>
>>>
>>> Op di 24 nov. 2020 om 02:29 schreef MUSTAFA YAVUZ <
>>> m.yavuz.18 at ogr.iu.edu.tr>:
>>>
>>>> Hi all,
>>>>
>>>> I've been trying to adjust my EEG data (segmented and .mat file) to be
>>>> analyzed by FT. I already have separate trials and have temporal
>>>> information about the event markers' time courses. I constructed a Nx3 trl
>>>> structure and passed it as cfg.trl while calling ft_preprocessing. Whilst
>>>> the function worked and I can see the cfg.trl field in the output
>>>> structure, when I call ft_databrowser, the event markers are not displayed
>>>> on trials. Do you have any idea/solution for this situation?
>>>>
>>>> Thank you in advance,
>>>> Mustafa
>>>>
>>>> --
>>>> *Mustafa Yavuz *
>>>>
>>>> Ph.D. Candidate in Neuroscience
>>>>
>>>> Department of Neuroscience
>>>> İstanbul University
>>>>
>>>> _______________________________________________
>>>> fieldtrip mailing list
>>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>>>> https://doi.org/10.1371/journal.pcbi.1002202
>>>>
>>> _______________________________________________
>>> fieldtrip mailing list
>>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>>> https://doi.org/10.1371/journal.pcbi.1002202
>>>
>>
>>
>> --
>> *Mustafa Yavuz *
>>
>> M.Sc. Candidate in Neuroscience
>>
>> Department of Neuroscience
>> İstanbul University
>>
>> _______________________________________________
>> fieldtrip mailing list
>> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> https://doi.org/10.1371/journal.pcbi.1002202
>>
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202
>


-- 
*Mustafa Yavuz *

M.Sc. Candidate in Neuroscience

Department of Neuroscience
İstanbul University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/30302660/attachment.htm>

From jan.schoffelen at donders.ru.nl  Wed Nov 25 09:06:35 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Wed, 25 Nov 2020 08:06:35 +0000
Subject: [FieldTrip] default behaviour of singleplot changed?
In-Reply-To: <CWLP265MB21932B1C2D0734C124782687F9FB0@CWLP265MB2193.GBRP265.PROD.OUTLOOK.COM>
References: <CWLP265MB21932B1C2D0734C124782687F9FB0@CWLP265MB2193.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <4BE22737-C7BE-4C3C-87D1-8BBF0625F58C@donders.ru.nl>

Dear Tom,

I can confirm your problem. The issue you report results from an overhaul (intended to improve overall code consistency) of the plotting functions, intending to make the creation of new figures/overwriting of open figures etc. better behaved. Long story short, all plotting functions now have a call to open_figure (which is in fieldtrip/private) that does the low-level figure handling. I suspect that the default behavior is to create a clean figure each time the high-level plotting function is called (or to clear the current figure axes), which is at odds with what you want to achieve. I think that it should work if you add cfg.figure = ‘gcf’ to the cfg to ft_singleplotTFR.
Sorry for the inconvenience and keep up the good work.

Best wishes,
JM



On 24 Nov 2020, at 17:15, Tom Marshall <tom.marshall at psy.ox.ac.uk<mailto:tom.marshall at psy.ox.ac.uk>> wrote:

Hi fieldtrippers,

Has the default behaviour of the ft_singleplotXXX functions changed recently? Because I'm used to grouping several of them together using 'subplot' something like this...

% plot the TFR of the first five channels
figure
for i = 1:5
    cfg.channel = i;
    subplot(1, 5, i)
    ft_singleplotTFR(cfg, data)
end

Previously, executing this would give me five nicely arranged subplots within a single figure. However, using the bleeding-edge fieldtrip version, this code now creates five separate figures, each with a blank subplot, and the last TFR in its own sixth figure.

So it seems like 'subplot' is being executed (because matlab is drawing the subplot in a figure), but ft_singleplotTFR isn't drawing into the subplot, but rather creating a new figure.

checked:

which singleplotTFR
/home/common/matlab/fieldtrip/ft_singleplotTFR.m  (working on donders cluster - seems correct)

which subplot
/opt/matlab/R2020b/toolbox/matlab/graph2d/subplot.m (seems correct)

replacing ft_singleplotTFR(cfg, data) in the above code with a built-in plot function - e.g.,imagesc(rand(10)) - gives the expected row of subplots, so it seems like some (new?) behaviour of ft_singleplotTFR is causing matlab to treat it differently to its own plots.

help ft_singleplotTFR: Nothing here about subplots or handles.

Can somebody advise? Something simple I'm missing?

Best,
Tom
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/79614a5d/attachment.htm>

From tom.marshall at psy.ox.ac.uk  Wed Nov 25 10:15:30 2020
From: tom.marshall at psy.ox.ac.uk (Tom Marshall)
Date: Wed, 25 Nov 2020 09:15:30 +0000
Subject: [FieldTrip] default behaviour of singleplot changed?
In-Reply-To: <4BE22737-C7BE-4C3C-87D1-8BBF0625F58C@donders.ru.nl>
References: <CWLP265MB21932B1C2D0734C124782687F9FB0@CWLP265MB2193.GBRP265.PROD.OUTLOOK.COM>,
 <4BE22737-C7BE-4C3C-87D1-8BBF0625F58C@donders.ru.nl>
Message-ID: <CWXP265MB22007B620E6C9D83AEC09C10F9FA0@CWXP265MB2200.GBRP265.PROD.OUTLOOK.COM>

I think that it should work if you add cfg.figure = ‘gcf’ to the cfg to ft_singleplotTFR.

Confirmed. With this extra line in the cfg I get my subplots back.

Cheers JM!

Best,
Tom
________________________________
From: fieldtrip <fieldtrip-bounces at science.ru.nl> on behalf of Schoffelen, J.M. (Jan Mathijs) <jan.schoffelen at donders.ru.nl>
Sent: Wednesday, November 25, 2020 8:06 AM
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] default behaviour of singleplot changed?

Dear Tom,

I can confirm your problem. The issue you report results from an overhaul (intended to improve overall code consistency) of the plotting functions, intending to make the creation of new figures/overwriting of open figures etc. better behaved. Long story short, all plotting functions now have a call to open_figure (which is in fieldtrip/private) that does the low-level figure handling. I suspect that the default behavior is to create a clean figure each time the high-level plotting function is called (or to clear the current figure axes), which is at odds with what you want to achieve. I think that it should work if you add cfg.figure = ‘gcf’ to the cfg to ft_singleplotTFR.
Sorry for the inconvenience and keep up the good work.

Best wishes,
JM



On 24 Nov 2020, at 17:15, Tom Marshall <tom.marshall at psy.ox.ac.uk<mailto:tom.marshall at psy.ox.ac.uk>> wrote:

Hi fieldtrippers,

Has the default behaviour of the ft_singleplotXXX functions changed recently? Because I'm used to grouping several of them together using 'subplot' something like this...

% plot the TFR of the first five channels
figure
for i = 1:5
    cfg.channel = i;
    subplot(1, 5, i)
    ft_singleplotTFR(cfg, data)
end

Previously, executing this would give me five nicely arranged subplots within a single figure. However, using the bleeding-edge fieldtrip version, this code now creates five separate figures, each with a blank subplot, and the last TFR in its own sixth figure.

So it seems like 'subplot' is being executed (because matlab is drawing the subplot in a figure), but ft_singleplotTFR isn't drawing into the subplot, but rather creating a new figure.

checked:

which singleplotTFR
/home/common/matlab/fieldtrip/ft_singleplotTFR.m  (working on donders cluster - seems correct)

which subplot
/opt/matlab/R2020b/toolbox/matlab/graph2d/subplot.m (seems correct)

replacing ft_singleplotTFR(cfg, data) in the above code with a built-in plot function - e.g.,imagesc(rand(10)) - gives the expected row of subplots, so it seems like some (new?) behaviour of ft_singleplotTFR is causing matlab to treat it differently to its own plots.

help ft_singleplotTFR: Nothing here about subplots or handles.

Can somebody advise? Something simple I'm missing?

Best,
Tom
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/7027ca1e/attachment.htm>

From patrick.wiegel at sport.uni-freiburg.de  Wed Nov 25 13:24:38 2020
From: patrick.wiegel at sport.uni-freiburg.de (Patrick Wiegel)
Date: Wed, 25 Nov 2020 12:24:38 +0000
Subject: [FieldTrip] Why are time-frequency results so much different
 from Beamformer source localization?
In-Reply-To: <CAFrxm=ziDuKt4QRgftZt63vorGGGtHnnQqgZE91HvYTZ1Aksfg@mail.gmail.com>
References: <6326F32F-1DD7-4E99-AA99-C844B56DC52E@sport.uni-freiburg.de>
 <CAFrxm=wxX6zH+w9jLzjyk8z1tHWQW_9gYGrJdoS2AuP4g3OCGQ@mail.gmail.com>
 <3E025D0F-DF23-4FD7-8B4B-2B3C42D969EF@sport.uni-freiburg.de>
 <CAFrxm=wdQ1qSnWkRk+Bkb+nY14WaJEwkRCf89PaCevU6amTg7g@mail.gmail.com>
 <BB83D822-468A-4C28-AF6F-BE2807F76DBB@sport.uni-freiburg.de>
 <CAFrxm=yjQ6th0_=07bjUWYkAbOVDoYpQ7Aa8+jVmfBHi6k0-ng@mail.gmail.com>
 <D2858661-926F-4328-9E20-054752DD7C16@sport.uni-freiburg.de>
 <CAFrxm=wULQG5iKcxgNqCNcgxj9GURaLg3pG3PzaLKSCMztvsnw@mail.gmail.com>
 <CAFrxm=ziDuKt4QRgftZt63vorGGGtHnnQqgZE91HvYTZ1Aksfg@mail.gmail.com>
Message-ID: <A5C71BFE-F71F-45AF-862D-2255FA5999EA@sport.uni-freiburg.de>

Hi Stephen,

I understand the issue with the MRI. I took the surface template as you suggested. It turned out that right is right and left is left.

The inward shift does not work. As soon as I use a shift < -0.2 cm, an error pops up during source analysis. I also get a warning during preparation of the leadfield that says that one of the dipoles collides with an electrode. This warning is absent when using an inward shift > -0.2 cm, so that seems to be a problem.

I removed the noisy channel and attached the result for the new source analysis for this subject. It is now located over the right hemisphere and relatively broad. I also changed the plotting options to better illustrate the contrast in both directions (0 is no difference since I used (a-b)/b). I think the plot looks at least more reasonable, though still edgy...

You are right that it is only a single subject and I have to run the grand average.

Thanks again, Patrick




Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de

Am 24.11.2020 um 11:06 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

[send too early - completed response here]

Hi Patrick,

Concerning L-R, it's not about the MRI, but rather how you are looking at it - top to bottom, or bottom-to-up, left as left (anatomical), or left as right (radiological). One thing you can do is to not use the 'ortho', but rather 'surface' method of plotting - that would give you a real 3D representation. If that ends up looking like how you would expect it then perhaps that would be enough :).

I don't know why inward_shift doesn't work for you; but check this tutorial in which it is used: https://www.fieldtriptoolbox.org/tutorial/beamformer_lcmv/

What I also don't really get is how you get those very dramatic pixelated edges in the source plot, while you keep very smooth / highres grid inside?

Anyway, that sourceplot doesn't look very good, it seems even worse/weirder than the previous one. The way you mask isn't helping either - you are cutting away one whole part of the contrast and I don't see why you would want to do that. Perhaps use relative-change (sometime like (A-B)/B) and center your colormap (make it symmetrical) around 1. And don't mask according to the values. That strange deep source does suggest you might need to remove that posterior channel as it might screw up your beamformer filter...

In the end, I guess this is just a single subject, and the real proof is in looking at the whole cohort and some estimates with averages etc. Maybe start on a second subject, and see if you find similar problems or not. That would be another way of checking your pipeline.

Cheers,
stephen






Op di 24 nov. 2020 om 11:00 schreef Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:
Hi Patrick,

Concerning L-R, it's not about the MRI, but rather how you are looking at it - top to bottom, or bottom-to-up, left as left (anatomical), or left as right (radiological). One thing you can do is to not use the 'ortho', but rather 'surface' method of plotting - that would give you a real 3D representation. If that ends up looking like how you would expect it then perhaps that would be enough :).

I don't know why inward_shift doesn't work for you; but check this tutorial in which it is used: https://www.fieldtriptoolbox.org/tutorial/beamformer_lcmv/

What I also don't really get is how you get those very dramatic pixelated edges in the source plot, while you keep very smooth / highres grid inside?

Anyway, that sourceplot doesn't look very good, it seems even worse/weirder than the previous one. The way you mask isn't helping either - you are cutting away one whole part of the contrast and I don't see why you would want to do that. Perhaps use rel







Op di 24 nov. 2020 om 10:29 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Hi Stephen, hi fiedltrip community

first of all, thanks for the good discussion that we have:-).

The 2 channels in the back were indeed a bit noisy, so I removed those. I attached the results from the new mtmfft analysis. The abs and rel differences between A and B become clearer now, although you could still argue to remove the most right posterior channel. However, I don’t want to loose too much information and I think it is okay to stick with this.

Your argumentation on the right/left behavior in MRIs was helpful. I had to think/read about that for a while. Since I am using the standard_MRI from the fieldtrip page (https://github.com/fieldtrip/fieldtrip/tree/master/template/headmodel), I cannot certainly tell where left and right is. the transformation matrix of the standard MRI is the following which leads me to assume that right is right?

    0.1000         0         0  -12.8500
         0    0.1000         0  -12.8500
         0         0    0.1000  -12.8500
         0         0         0    1.0000


I tried to use a larger grid during ft_prepare_sourcemodel, however, it seems that as soon as I use a negative inward shift, the ft_sourceanalysis function does not work. I get the following error.


Error using svd
Input to SVD must not contain NaN or Inf.

Error in ft_inverse_dics>pinv (line 590)
  [U,S,V] = svd(A,0);

Error in ft_inverse_dics (line 475)
        filt = pinv(lf' * invC * lf) * lf' * invC; % Gross eqn. 3 & van Veen eqn. 23, use PINV/SVD to cover rank
        deficient leadfield

Error in ft_sourceanalysis (line 763)
          dip(i) = ft_inverse_dics(sourcemodel, sens, headmodel, [],  squeeze_Cf, methodopt{:}, leadfieldopt{:});

Error in FT_example_without_baseline (line 121)
sourceAll_beta = ft_sourceanalysis(cfg, data_beta);


Not using a negative inward-shift results in the attached source-differences between conditions.
Best, Patrick



Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 20.11.2020 um 13:02 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Hi Patrick,

Things are becoming clearer now, good to see.

So yes, that artefact in the back of the head: I would definitely take care of that. Maybe do another run of (visual) artefact rejection, or remove those channels.
That the effect is less apparent in the relative difference is not surprising as the absolute differences are expected to be bigger than on other channels due to large amplitudes of the artefacts, which will be 'normalized' over channels when using a relative difference.

I would be careful about interpreting left-right on the plot. Note that you assume you are looking from the top/front of the head downwards/backwards - but there is no way of confirming that based on the picture! People often place some kind of marker on the left or right side of the head when doing an MRI scan - e.g. a vitamin D (?) capsule I think so that one can verify the radiological versus anatomical (?) representation (LR is flipped in radiological plots). You could do this once, and verify your pipeline, if you want to be 100% sure.

Lastly, it seems that the source picture could benefit from using a slightly larger beamformer scanning grid so to overlap more with the edge of the brain/skull. I used to do that using a negative value for the inward shift parameter (cfg.inwardshift) in ft_prepare_sourcemodel. Maybe there is an easy way for you to do that in your pipeline as well.

Looking good!
Stephen





Op vr 20 nov. 2020 om 12:31 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear Stephen,

thanks for the response.

I followed your suggestions and attached the plots. I performed Morlet wavelets TF analyses and mtmfft for conditions A and B. I did not use a baseline correction to see whether this is necessary. As you can see in the topographical plots, both conditions (A and B) have high power in 2 posterior electrodes (I guess some kind of artifact or noise is the reason). Using the abs. difference between A and B does not get rid of that fact, probably because one condition is more affected than the other. Using the rel. difference does a better job and resembles my previous baseline-corrected results. I also compared the baselines and they were not different. The two conditions were furthermore randomized within the same protocol. I assume that adding a baseline is thus unnecessary.

Regarding the source_analysis, the results for individual conditions A and B (NAI) as well as abs dif between A and B look weird again. But that’s very likely due to the same problem as for the power. For rel dif between A and B, the source plot seems more reasonable, although I expect the source to be in the right hemisphere and not in the left as shown in the plot. I controlled that all my input data (electrodes, volume condition model, MRI) have the same definition of the axes (x+ pointing right, y+ pointing anterior, z+ pointing superior) so I don’t think there is a right-left mix-up!?

Now I am wondering whether I have to accept the result for the rel difference in sources between A and B (which is very hard to interpret and justify after what I am observing in the TF analysis, namely an effect in the other hemisphere) or whether there might be still some issue in my approach. It is very hard for me to believe that the source analysis does have so strong assumptions such that it can be in such strong contrast to my power data.

If I am correct, what I input into the source analyses (apart from my models) for conditions A and B are 1) the corresponding power matrix (64 channels x 1 power value) and the CSD (2016 * 1). It could of course be that the source analysis is very sensitive to the large abs differences in power/CSD data between electrodes. However, I also used cfg.supchan (suppressing specific channels) in the source analysis for the 2 channels that were „off“ to see whether this makes it different.However, the source result is similar.

Any comment is appreciated.   All plots, data and scripts are at (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).

Best, Patrick

%%

cfg                  = [];
cfg.headmodel        = vol;
cfg.elec             = elec_aligned;
cfg.reducerank       = 2;
cfg.resolution       = 1;
sourcemodel_beta = ft_prepare_leadfield(cfg,data_beta);

%%

cfg              = [];
cfg.method       = 'dics';
cfg.sourcemodel  = sourcemodel_beta;
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.frequency    = 28;
cfg.dics.projectnoise = 'yes';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
sourceAll_beta = ft_sourceanalysis(cfg, data_beta);

%%

cfg              = [];
cfg.method       = 'dics';
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.dics.projectnoise = 'yes';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
cfg.sourcemodel  = sourcemodel_beta;
cfg.sourcemodel.filter = sourceAll_beta.avg.filter;

source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);


%%

sourceNAI1 = source_beta_1;
sourceNAI1.avg.pow = source_beta_1.avg.pow ./ source_beta_1.avg.noise;

sourceNAI0 = source_beta_0;
sourceNAI0.avg.pow = source_beta_0.avg.pow ./ source_beta_0.avg.noise;

cfg            = [];
cfg.parameter = 'pow';
cfg.operation = 'x1./x2';
sourceDiff_beta_rel = ft_math(cfg, source_beta_1,source_beta_0);

cfg            = [];
cfg.parameter = 'pow';
cfg.operation = 'x1 - x2';
sourceDiff_beta_abs = ft_math(cfg, source_beta_1,source_beta_0);

%%
cfg            = [];
cfg.downsample = 2;
cfg.parameter  = 'pow';
sourceDiffInt_beta_dif_rel  = ft_sourceinterpolate(cfg, sourceDiff_beta_rel , mri_realigned);
sourceDiffInt_beta_dif_abs  = ft_sourceinterpolate(cfg, sourceDiff_beta_abs , mri_realigned);
sourceDiffInt_beta_dif_0  = ft_sourceinterpolate(cfg, sourceNAI0 , mri_realigned);
sourceDiffInt_beta_dif_1  = ft_sourceinterpolate(cfg, sourceNAI1 , mri_realigned);

%%
maxval_beta_rel = max(sourceDiffInt_beta_dif_rel.pow);
maxval_beta_abs = max(sourceDiffInt_beta_dif_abs.pow);

%%
cfg = [];
cfg.nonlinear     = 'no';
sourceDiffIntNorm_beta_dif_rel = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_rel);
sourceDiffIntNorm_beta_dif_abs = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_abs);
sourceDiffIntNorm_beta_dif_0 = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_0);
sourceDiffIntNorm_beta_dif_1 = ft_volumenormalise(cfg, sourceDiffInt_beta_dif_1);

Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 19.11.2020 um 14:59 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Dear Patrick,

Nice to see you are progressing. The TFR topoplots look nice (and the effect seems even stronger in the mtmfft version)!

I agree the source reconstruction looks pretty iffy. A single dot like that shouldn't be there - no source in Beamformer is so focal. It suggests something is off, which could be as simple as a single electrode doing something weird (given how focal and superficial the artefact is).

I would take another step back;
I would first look at the distribution of your absolute beta, i.e. without baseline correction. For both conditions.
I would then look at the distribution of your baseline beta, i.e. only your baseline. For both conditions.
You should satisfy yourself that the results make sense, i.e. nothing too drastic, focal, etc., and some density of beta power around the central sulcus (?).

Now I understand your contrast better, I have to ask why you do the baseline correction as you do. In this way you are using a separate BL for each condition, meaning that after BL-correction you are actually also comparing BL as much as you are comparing post-BL activity - after BL-correction any differences in BL become difference in your active period.
If you assume differences in BL you might want to compare those separately before you 'add' them to your active period. If you have a randomized design, you might not want to do any BL correction in your contrast at all. Also, if there are no differences in BL, then it would make no difference...
So, when you have a good sense of the absolute values and source distributions, you might want to try just comparing active period A vs B, relative (/) or absolute (-), and forget about the BL. Sometimes the BL is more noisy than the active period even.

Anyway, your script looks fine to me, but it's been a while. However, I suspect that one of your datasets (A, A_BL, B, or B_BL) has some artefact that is introduced in the contrast.

Cheers,
Stephen











Op do 19 nov. 2020 om 13:27 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear fieldtrip community,

first of all, thank you for your valuable responses @Tzvetan and Stephen. They were both very helpful and got me to dig deeper into the analysis.

You were absolutely right in describing my approach for my Morlet wavelet TF analysis. The data were baseline corrected (in db). When contrasting the 2 conditions of interest, I receive the attached figure (dif_morlet). After your responses, I took the same approach for the mtmfft data with cfg.tapsmofrq = 8 (center frequency at 28 Hz) to reproduce the effect that I found between 20-35 Hz in the morlet wavelet analyses. I calculated frequency analysis (mtmfft) for both conditions (data_1, data_0) and their baseline periods (data_1_bas, data_0_bas) separately and then „baseline corrected“ the data from both conditions (also in db, see dif_mtmfft). The differences between conditions are now very similar between both approaches (morlet vs mtmfft).

In the next step. I followed your advice and performed source analyses of frequency_data for all 4 conditions separately (pow_1, pow_0, pow_1_baseline, pow_0_baseline) as well as from all_data from ft_appenddata. For the source_analyses from all 4 conditions, I am using the common filter from all_data as well as the source model (ft_prepare_leadfieldds) from all_data. After performing the ft_source_analysis function for all 4 conditions, I am trying to replicate what I have done with the power data ( in db). For this reason, I am using ft_math with source_1_dif = 10*log10 (source_1/source_1_baseline) and the same for source_0. After this, I am subtracting source_0_dif from source_1_dif as done during the frequency analysis yielding my final source data.

After interpolating the source differences, I am using ft_volumenormalise. The result from this approach is attached in dif_sources.

I am a bit puzzled since I would not expect these source data based on my power mtmfft data. I made sure that the coordinate systems and units are the same across models (volume_conduction_model, electrodes, MRI) but I am wondering whether I am doing something wrong in performing the source_analysis or whether the source results are reasonable.

Again, I uploaded the script and the data such that my analysis pipeline could be reproduced by everyone who is interested (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation). Below, I am attaching the code for the source_analyses steps. Any comments on my results or approach are welcome.

All the Best from Germany,
Patrick



.






cfg              = [];
cfg.method       = 'dics';
cfg.headmodel    = vol;
cfg.elec         = elec_aligned;
cfg.dics.projectnoise = 'yes';
cfg.dics.lambda       = '5%';
cfg.dics.keepfilter   = 'yes';
cfg.dics.realfilter   = 'yes';
cfg.sourcemodel  = sourcemodel_beta;
source_beta_1 = ft_sourceanalysis(cfg, data_beta_1);
source_beta_0 = ft_sourceanalysis(cfg, data_beta_0);
source_beta_1_bas = ft_sourceanalysis(cfg, data_beta_1_bas);
source_beta_0_bas = ft_sourceanalysis(cfg, data_beta_0_bas);


%%
cfg            = [];
cfg.parameter = 'pow';
cfg.operation = '10*log10(x1/x2)';
sourceDiff1_beta = ft_math(cfg, source_beta_1,source_beta_1_bas);
sourceDiff0_beta = ft_math(cfg, source_beta_0,source_beta_0_bas);

sourceDiff_beta_dif = sourceDiff1_beta;
sourceDiff_beta_dif.pow = sourceDiff1_beta.pow - sourceDiff0_beta.pow;

%%
cfg            = [];
cfg.downsample = 2;
cfg.parameter  = 'pow';
sourceDiffInt_beta_dif  = ft_sourceinterpolate(cfg, sourceDiff_beta_dif , mri_realigned);

%%
maxval_beta = max(sourceDiffInt_beta_dif.pow);
%%
cfg = [];
cfg.nonlinear     = 'no';

sourceDiffIntNorm_beta_dif = ft_volumenormalise(cfg, sourceDiffInt_beta_dif);

%%
cfg = [];
cfg.method        = 'ortho';
cfg.interactive   = 'yes';
cfg.funparameter  = 'pow';
cfg.maskparameter = cfg.funparameter;
cfg.funcolorlim   = [0.0 maxval_beta];
cfg.opacitylim    = [0.0 maxval_beta];
cfg.opacitymap    = 'rampup';
ft_sourceplot(cfg, sourceDiffIntNorm_beta_dif);
%%


Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

Am 13.11.2020 um 12:48 schrieb Stephen Whitmarsh <stephen.whitmarsh at gmail.com<mailto:stephen.whitmarsh at gmail.com>>:

Hi Patrick, (and Tzvetan - who responded in the meantime),

I agree that you should start with a good correspondence between your initial results (wavelets), and the power difference you are trying to localize (with mtmfft).

Wavelets and fft methods can result in very similar - practically identical - results, but that depends on a number of parameters, especially concerning frequency-smoothing; Wavelets are typically defined in terms of nr. of cycles, while fft methods are defined in terms of time-windows. Wavelets defined in nr. of cycles will have a decreasing time-windows with increasing frequency, while with mtmfft time windows will remain the same. Because of this, frequency smoothing will increase with frequency with wavelets, and stay the same with a constant time window. Of course, you can make the fft time window frequency-dependent, as is described in the frequency-analyses tutorial, to make them more comparable. Secondly, the fft method allows you to specify frequency smoothing when you use Sleppian multitapers (cfg.taper = 'dpss'). To be clear, you should be able to recognize these differences in frequency smoothing/resolution when looking at the different TFR plots. Currently they look too different, probably because of something else (baseline?) than a wavelet-fft difference.

I would advise making a 'full' TFR with mtmfft similar as your wavelet results so that you can properly compare them. This allows you to also set the best parameters for smoothing/timeperiods. In fact, you can use the multitaper approach to more accurately extract the power in a certain frequency band. Only then compare the topo's, and only then do the beamformer, so you will pick up any unexpected results.

Because of different contrasts/baseline correction, I cannot compare the topo's / beamformer results.

Bon courage,
Stephen









Op vr 13 nov. 2020 om 11:30 schreef Patrick Wiegel <patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>>:
Dear Field-trip community,

I am working on EEG data from a motor learning task. in the first part of my analysis, I performed a time-frequency analysis (Morlet wavelet method) and cluster-based permutation test. I compared two different conditions (correct & incorrect movements) within subjects and found a significant difference in the beta band (20-35 Hz) when subjects were provided with feedback. I attached the topographical plot from one subject that illustrates the difference between the conditions at the selected time point and frequency (dif_morlet). As you can see, beta power was higher in one condition in lateral frontal electrodes.

Now, I would like to better spatially locate the effect for this single subject. For this purpose, I followed the Beamformer tutorial on the website. In the first step, I selected the raw data of interest (at the time where the effect was seen) and performed frequency analyses for the 20-35 Hz range (mtmfft, contrast between conditions shown in dif_mtmfft). There is an apparent difference between dif_morlet and dif_mtmfft and I am wondering why this is the case? One apparent reason is that the time-frequency data were baseline corrected and the frequency data from mtmfft not.

Using the power and CSD data from mtmfft, I performed the source analysis with a standard MRI and head model. The source was located in the left hemisphere (source plot), which is in stark contrast to the time-frequency data (dif_morlet). I am aware that the source analysis is based on a lot of assumptions (conductivity etc.) that influence the calculations but it is very difficult to make sense of such discrepancy.
Maybe it is necessary to also baseline correct the mtmfft data before inputting them to the source analysis? Or doing the contrasting source localization betwee a single condition and the corresponding baseline data before contrasting the 2 conditions?

I am providing all necessary files and scripts (TF_analysis & BEAMFORMER) if anyone is interested to reproduce the results that I am showing and reporting for this single subject (https://github.com/PatrickWiegel/EEG-Beamformer-Source-localisation).

I would appreciate any help and discussion on that.

All the best,
Patrick





Patrick Wiegel
Department of Sport and Sport Science

University of Freiburg
Sandfangweg 4
79117 Freiburg i. Br .

phone: +49 (0)761/ 203-4550
email: patrick.wiegel at sport.uni-freiburg.de<mailto:patrick.wiegel at sport.uni-freiburg.de>
web: www.sport.uni-freiburg.de<http://www.sport.uni-freiburg.de/>

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/7511d542/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: source_dif_new.eps
Type: application/postscript
Size: 258001 bytes
Desc: source_dif_new.eps
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/7511d542/attachment.eps>

From conbke at sjtu.edu.cn  Wed Nov 25 14:59:03 2020
From: conbke at sjtu.edu.cn (ConBke)
Date: Wed, 25 Nov 2020 21:59:03 +0800
Subject: [FieldTrip] About the usage of FieldTirp toolbox to analysis data
 obtained by LIF models
Message-ID: <C7612E8A-9BE9-4D42-BB8F-7E45BEEB30DA@sjtu.edu.cn>

	Hi, I am trying to use FieldTrip to do some analysis with the data I obtained by running leaky integrate-and fire models of a network. I currently only have my data (LFPs, spike times) stored in txt and mat format. I read the documents of some functions like ft_preprocessing, ft_spiketriggeredspectrum, ft_definetrial and so on, but still confused about some the information I have to provide described in the document, as I only have some trials of LFPs and spike times of some neurons.

	I stored the LFP and spike times like ‘LFP.mat’ and ’spike.mat’, and define a struct “ cfg = [];  cfg.dataset = ‘LFP.mat’, cfg.trl = [0 60000 0 ];”.
And then used the ft_preprocessing like “ ft_preprocessing(cfg)”. Then Matlab gives me error like “Error using feval, attempt to execute SCRIPT matlab as a function”, “hdr = feval(headerformat, filename);” , “  hdr = ft_read_header(cfg.headerfile, headeropt{:}); “. I have no idea how to fix this issue, because I seem not to have information about the header file. Can you give me any advice? Thank you very much! Looking forward to your reply!

Best Wishes!
Τao


From daphne.kamino at sickkids.ca  Wed Nov 25 20:22:58 2020
From: daphne.kamino at sickkids.ca (Daphne Kamino)
Date: Wed, 25 Nov 2020 19:22:58 +0000
Subject: [FieldTrip] Post-doctoral Research Fellow position in clinical
 neurophysiology at The Hospital for Sick Children
Message-ID: <CEB30B3F-3742-47B9-9CE1-302B33B8A61E@contoso.com>

Post-doctoral Research Fellow position in clinical neurophysiology

Neurological Outcome of Glycemia in Neonatal Encephalopathy

The Neurosciences & Mental Health Program at the Hospital for Sick Children Research Institute is seeking an enthusiastic postdoc researcher to work in close collaboration with neurologists, neurophysiologists, and neuroradiologists in analysing pre-existing continuous glucose, EEG, and clinical data.

With the direction of principal supervisors Drs. Emily Tam and Cecil Hahn, you will work closely with affiliated staff and students who form a group that use neuroimaging and neurophysiology to study newborn brain disorders.

Despite therapeutic hypothermia for hypoxic-ischemic encephalopathy (HIE), rates of death and major disability continue to be high. Using continuous glucose monitoring, we have found that hyperglycemia occurs in more than 50% of HIE, associated with brain injury and possibly long-term outcomes. This study uses continuous glucose data paired with continuous electroencephalography (cEEG) and detailed clinical data to determine the temporal relationships between abnormal glycemia and brain function.

This is part of an ongoing project that is funded by the Canadian Institutes of Health Research (CIHR) and the National Institutes of Health (NIH).

A substantial amount of data already exists for this project and the motivated researcher will be able to jump straight into analysis.

Requirements

  *   PhD in a relevant area (engineering or computer sciences) required.
  *   Must have experience with EEG analyses
  *   Well developed skills in data science is required.
  *   Computer programming (Matlab, Python, or R) and/or signal processing/time series analyses.
  *   Proven experience in research commensurate with your level of experience post-PhD.
  *   Experience in analysis of neurophysiological data is preferred.
  *   Experience in clinical research would be an asset.
  *   Excellent communication skills (oral and written).
  *   Be able to work independently and meet deadlines.

We offer

  *   Initial contract will be for a period of 1 year, with the possibility of extension for a second year.
  *   We offer a competitive salary based on qualifications and experience.
  *   In addition, we offer an attractive benefits package, that includes extended health and dental coverage.
  *   Toronto is a world-class rated in the top ten cities worldwide for livability that has a large and rich neuroscience community.
  *   The Research Institute offers many opportunities for career development and additional training as part of the Research Training Centre.

Additional information

The post is available from 4th January 2021.

Contact Dr. Emily Tam via emily.tam at sickkids.ca<mailto:emily.tam at sickkids.ca> for more information.
If you wish to apply directly, please send a CV, a cover letter with research statement/interests, and the names of two references.

Please use the following direct link to the job posting to apply to the position via the SickKids website:

https://career.sickkids.ca:8001/psc/CRPRD/CAREER/HRMS/c/HRS_HRAM.HRS_APP_SCHJOB.GBL?Page=HRS_APP_JBPST&Action=U&FOCUS=Applicant&SiteId=1&JobOpeningId=13321&PostingSeq=1


[/Users/daphne kamino/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_955064418]

________________________________

This e-mail may contain confidential, personal and/or health information(information which may be subject to legal restrictions on use, retention and/or disclosure) for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/e154dce0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 267967 bytes
Desc: image001.png
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201125/e154dce0/attachment.png>

From zika.ondra at gmail.com  Thu Nov 26 13:49:04 2020
From: zika.ondra at gmail.com (Ondrej Zika)
Date: Thu, 26 Nov 2020 13:49:04 +0100
Subject: [FieldTrip] cluster-based permutation test with linear mixed
 effects models
Message-ID: <CAEsn0az120BgSYt4bAVMJFHgisxwQCsMfJbZG84FNDsz8kwEMA@mail.gmail.com>

Dear all,

I have a theoretical question about shuffling strategies in permutation
tests using linear mixed effects models.

I have created a minimal working example, so that you can refer to specific
points with code if necessary here: https://ozika.github.io/perm_test_lme/

Scenario 1:
(I just made these examples up, i tried to keep the dimensions unique in
size for identifiability)
Dependent variable (DV)

   - pupil size (measured every second after onset, for 5 seconds)

Fixed effects

   - background color (within subject, 2 levels)
   - congruency (within subject, 2 levels)

Random effects

   - participant (10 participants/levels)

Each participant completes 40 trials, 10 one of each kind in the 2x2
design. The overall DV dataset is therefore 400x5 matrix.

Analysis (code [here](https://github.com/ozika/perm_test_lme) to be
specific):
1) Run LMM for each data point using: pupil ~ bgcolor + congruency +
bgcolor*congruency + (1|sub)
2) Collect t-values
3) Identify clusters
4) Generate null distribution by shuffling labels of bgcolor and
congruency within
each subject. Include (?) permutations where no cluster was above the
threshold and assign them 0 cluster mass.
5) Calculate desired threshold based on the null distribution
6) Evaluate actual clusters for each effect.

---

Scenario 2:
Dependent variable (DV)

   - pupil size (measured every second after onset, for 5 seconds)

Fixed effects

   - background color (within subject, 2 levels)
   - drug/placebo (between subject, 2 levels)

Random effects

   - participant (10 participants/levels)

This is the same scenario as above but one factor is now a between subject
variable. Would the right randomization strategy be to shuffle bgcolor
within subject and then shuffle labels for entire subjects? (e.g. if each
sub has 100 sampels altogether, shuffle the entire blocks of 100)
Is there a disadvantage in shuffling ALL variables across all
samples/subjects?

Thank you for any comments that you might have!

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201126/5d533e66/attachment.htm>

From craiggrichter at gmail.com  Thu Nov 26 15:11:21 2020
From: craiggrichter at gmail.com (Craig Richter)
Date: Thu, 26 Nov 2020 15:11:21 +0100
Subject: [FieldTrip] Elekta neuromag I/O box
Message-ID: <C5930959-78E6-45C7-A844-F9C612A7F642@gmail.com>

Hi everyone,

This probably isn’t the best place for this question, but I’m getting desperate. We’re upgrading our stim computer for our Elekta neuromag system (not a Triux), so I need to build a new parallel interface cable between the stimulus I/O box, and some outboard devices. The connector on the I/O box is a 37 pin D-sub. Does anybody know the pinout for this connector, or know anybody that may know?

Sorry for the spam!

Thank you!!!

Craig 


From matti.stenroos at aalto.fi  Thu Nov 26 15:43:06 2020
From: matti.stenroos at aalto.fi (Stenroos Matti)
Date: Thu, 26 Nov 2020 14:43:06 +0000
Subject: [FieldTrip] Elekta neuromag I/O box
In-Reply-To: <C5930959-78E6-45C7-A844-F9C612A7F642@gmail.com>
References: <C5930959-78E6-45C7-A844-F9C612A7F642@gmail.com>
Message-ID: <faa11cde02db4f1ea2e004f424a6cfd1@aalto.fi>

Hello Craig,


Have you tried MEGIN customer support?


https://megin.fi/meg-service-2/


Cheers,

 Matti

________________________________
Lähettäjä: fieldtrip <fieldtrip-bounces at science.ru.nl> käyttäjän Craig Richter <craiggrichter at gmail.com> puolesta
Lähetetty: 26. marraskuuta 2020 16:11:21
Vastaanottaja: fieldtrip at science.ru.nl
Aihe: [FieldTrip] Elekta neuromag I/O box

Hi everyone,

This probably isn’t the best place for this question, but I’m getting desperate. We’re upgrading our stim computer for our Elekta neuromag system (not a Triux), so I need to build a new parallel interface cable between the stimulus I/O box, and some outboard devices. The connector on the I/O box is a 37 pin D-sub. Does anybody know the pinout for this connector, or know anybody that may know?

Sorry for the spam!

Thank you!!!

Craig
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201126/466fd12e/attachment.htm>

From christodoylos_k at hotmail.com  Thu Nov 26 16:15:23 2020
From: christodoylos_k at hotmail.com (Christodoylos Karittevlis)
Date: Thu, 26 Nov 2020 15:15:23 +0000
Subject: [FieldTrip] Power from LCMV method ?
Message-ID: <AM7PR04MB7142687065A220078E64225C81F90@AM7PR04MB7142.eurprd04.prod.outlook.com>

Dear Fieldtrip community,

I have one question. I am using the beamformer LCMV method for source localization of simulated data (1 dipole in a sphere).
I am trying to figure out how the source.avg.power is estimated from the function ft_sourceanalysis. Can anyone give me some explanation on that or maybe some directions where I can find more details on the estimation of power/noise using the function ft_sourceanalysis.
I tried to estimate it from the source.avg.mom but I could not really produce the power.

Thank you in advance.

Kind regards,
Christodoulos Karittevlis
PhD Candidate, ESR11- iCONN network

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201126/039e6c51/attachment.htm>

From gianpaolo.demarchi at gmail.com  Thu Nov 26 16:28:52 2020
From: gianpaolo.demarchi at gmail.com (Gianpaolo Demarchi)
Date: Thu, 26 Nov 2020 16:28:52 +0100
Subject: [FieldTrip] Elekta neuromag I/O box
In-Reply-To: <C5930959-78E6-45C7-A844-F9C612A7F642@gmail.com>
References: <C5930959-78E6-45C7-A844-F9C612A7F642@gmail.com>
Message-ID: <5931B8DE-CCA4-436E-AC8E-7EBF2D7E7C6A@gmail.com>

Hi Craig,
It’s in the “Elekta Neuromag System Hardware” manual, chapter 7 “Auxiliary Electronics” …
Dunno whether I can post this info here, but just google for the manual if don’t have it … (or contact me off list)
Best,
-g


> On 26.11.2020, at 15:11, Craig Richter <craiggrichter at gmail.com> wrote:
> 
> Hi everyone,
> 
> This probably isn’t the best place for this question, but I’m getting desperate. We’re upgrading our stim computer for our Elekta neuromag system (not a Triux), so I need to build a new parallel interface cable between the stimulus I/O box, and some outboard devices. The connector on the I/O box is a 37 pin D-sub. Does anybody know the pinout for this connector, or know anybody that may know?
> 
> Sorry for the spam!
> 
> Thank you!!!
> 
> Craig 
> _______________________________________________
> fieldtrip mailing list
> https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> https://doi.org/10.1371/journal.pcbi.1002202




From jan.schoffelen at donders.ru.nl  Thu Nov 26 17:17:02 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Thu, 26 Nov 2020 16:17:02 +0000
Subject: [FieldTrip] Power from LCMV method ?
In-Reply-To: <AM7PR04MB7142687065A220078E64225C81F90@AM7PR04MB7142.eurprd04.prod.outlook.com>
References: <AM7PR04MB7142687065A220078E64225C81F90@AM7PR04MB7142.eurprd04.prod.outlook.com>
Message-ID: <78AA3BEC-25A8-45B4-8273-6F8774C786B2@donders.ru.nl>

Dear Christodoulos,

The ‘pow’ field is obtained by sandwiching the sensor level covariance between the spatial filter, i.e.   w’ * C * w.
The ‘mom’ field is obtained by left multiplication of the spatial filter with  the sensor level average,  w’ * avg.
Computing the variance from the w’*avg will indeed yield something that is different from the ‘pow’.

This is because the sensor-level covariance is typically the average of the single trial covariances, and not the covariance of the trial average.

Best wishes,
Jan-Mathijs

PS: the ’noise’ is typically obtained by sandwiching a scaled identity matrix between the spatial filters, i.e. w’ * Identitymatrix * w * <a number>, where the <a number> is usually the smallest singular value of the matrix. I would take this with a grain of salt, since the noise is rarely diagonal, nor does the smallest singular value accurately reflect the noise level.



On 26 Nov 2020, at 16:15, Christodoylos Karittevlis <christodoylos_k at hotmail.com<mailto:christodoylos_k at hotmail.com>> wrote:

Dear Fieldtrip community,

I have one question. I am using the beamformer LCMV method for source localization of simulated data (1 dipole in a sphere).
I am trying to figure out how the source.avg.power is estimated from the function ft_sourceanalysis. Can anyone give me some explanation on that or maybe some directions where I can find more details on the estimation of power/noise using the function ft_sourceanalysis.
I tried to estimate it from the source.avg.mom but I could not really produce the power.

Thank you in advance.

Kind regards,
Christodoulos Karittevlis
PhD Candidate, ESR11- iCONN network

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201126/7a99dc0b/attachment.htm>

From m.yavuz.18 at ogr.iu.edu.tr  Fri Nov 27 01:11:15 2020
From: m.yavuz.18 at ogr.iu.edu.tr (MUSTAFA YAVUZ)
Date: Fri, 27 Nov 2020 03:11:15 +0300
Subject: [FieldTrip] Trial-based Channel Repair
Message-ID: <CAFWATv8sT1OYHM9bBEjW-ssHt9vJR3QAVN9wBvxFVc8euDzpwA@mail.gmail.com>

Hi Ft family,

The following question might be trivial, I am sorry if it is, in advance.

Is there any way to repair bad channels (interpolate) but only for certain
trials. When I call ft_channelrepair and pass cfg.trial as a 1xN vector of
trial numbers which the given channel is bad, the resulting data contains
only the trials in the cfg.trial vector. When I call the ft_rejectvisual
and select certain channels to repair, the function interpolates the
selected channels for all trials.

Am I missing something big?
Any help would be much appreciated,
Thanks in advance,
Mustafa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201127/9c42725e/attachment.htm>

From huiyu_kang at fudan.edu.cn  Fri Nov 27 02:47:12 2020
From: huiyu_kang at fudan.edu.cn (Huiyu Kang)
Date: Fri, 27 Nov 2020 09:47:12 +0800
Subject: [FieldTrip] Post-doc Position | Neural and Intelligence Engineering
 Center, Institute of Science and Technology for Brain-inspired Intelligence,
 Fudan University, Shanghai, China
Message-ID: <5FC05AA0.364609.08558@fudan.edu.cn>


Post-doc Position | Neural and Intelligence Engineering Center, Institute of Science and Technology for Brain-inspired Intelligence, Fudan University, Shanghai, China

Location
Shanghai, China
Salary
¥250k ~400k+ /year ($35k~58k+ / year) 
Employment period
2 years initially, extendable up to 4 years
Hours
Full Time
The positions are supported by Shanghai Government Key Project of ‘Brain and Brain-inspired Intelligence’ ($125 Millions), and are affiliated with the Neural and Intelligence Engineering Center led by Prof. Shouyan Wang, Vice-dean of Institute of Science and Technology for Brain-Inspired Intelligence (ISTBI), Fudan University. The projects will collaborate with Huashan Hospital Fudan University, Beijing Tiantan Hospital Capital Medical University, The General Hospital of the People's Liberation Army, University of Oxford, University of Cambridge and Harvard University, etc.

Research Projects: 
* EEG nerve signal processing, Brain-computer interface and Electrical nerve stimulation
* Biomedical signal processing, Medical big data analysis and Telemedicine
* Brain disease mechanism and clinical neurophysiology, Neuroimaging

Qualifications:
(1) Researchers who will receive PhD soon or graduated within last five years.
(2) Under 35 years old. Excellent candidates aged 35 to 38 may be considered.
(3) Research experience in machine learning, neural signal processing, biomedical electronics or neurophysiology in pain, movement disorders or depression, or related research experience in neuroscience or psychology.

Benefits：
1. The initial employment period is 2 years and extendable up to 4 years according to project progress.
2. Salary is ¥250k ~400k+ /year ($35k~58k+ / year).
3. Additional research funding up to $30k provided to support researchers with excellent ideas and independent capability.
4. Opportunities to top-up salaries up to $14k / year with grant from Shanghai Government.
5. Opportunities to have research visiting at University of Oxford, University of Cambridge or Harvard University.
6. Opportunities to transfer to faculty position with start-up of $72k~144k.
7. In accordance with the policies of Fudan University, assist children of the candidates to apply for admission to kindergartens or primary school affiliated to Fudan University.

Application Procedure：
Send CV with contact information of referees, cover letter and PDF of key publications to huiyu_kang at fudan.edu.cn with e-mail subject Post-doc Application

Additional Information
Fudan University is one of the top five universities in China, and ranked at #105 in Times Higher Education World University Ranking. ISTBI is a leading institute in brain-inspired artificial intelligence, neuroimaging, biomedical big data and neural engineering in China. More information can be found from https://www.fudan.edu.cn/en/ and https://istbi.fudan.edu.cn/lnen/. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201127/93a2a12a/attachment.htm>

From jan.schoffelen at donders.ru.nl  Fri Nov 27 10:35:55 2020
From: jan.schoffelen at donders.ru.nl (Schoffelen, J.M. (Jan Mathijs))
Date: Fri, 27 Nov 2020 09:35:55 +0000
Subject: [FieldTrip] new release with critical fix for DICS
Message-ID: <E70C8F4B-DDAD-4945-A921-5258E17632A2@donders.ru.nl>

Dear all,


Regretfully we identified a bug in FieldTrip releases starting from release 20200701<https://github.com/fieldtrip/fieldtrip/releases/tag/20200701> onward, which might have affected your results.

Specifically, if you have been using ft_sourceanalysis with DICS as a method, and if the order of the channels of the input data structure was not alphabetical, the results are incorrect. This is caused by an accidental alphabetical reordering of the channels in the cross-spectral density matrix, which was not reflected by a similar reordering in the leadfields. We are grateful to Alexandra Steina to help us identify and resolve it. See issue #1587<https://github.com/fieldtrip/fieldtrip/issues/1587> on GitHub for more information.

Are you affected? If you used a FieldTrip version between 20200701 and 20201126, and you used ft_sourceanalysis with method DICS, and your channels are not in alphabetical order, then you are likely affected. For CTF MEG data the channels are usually in alphabetical order. Neuromag/Elekta MEG data, and MEG data from other systems often have the channels not in alphabetical order. The same holds for EEG data, so your results are likely affected if you are working with EEG data, or non-CTF MEG data.

To resolve the problem, please update to the latest 20201126 release version from the FTP server or from the GitHub release page<https://github.com/fieldtrip/fieldtrip/releases>, recompute your source estimates, and your downstream results.

Sorry for the inconvenience, and keep up the good work.

Best regards,

Jan-Mathijs and Robert


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201127/1c2f20c3/attachment.htm>

From martin.schaefer at ki.se  Fri Nov 27 11:58:20 2020
From: martin.schaefer at ki.se (Martin Schaefer)
Date: Fri, 27 Nov 2020 10:58:20 +0000
Subject: [FieldTrip] Problems with ft_icabrowser
Message-ID: <HE1PR08MB2923A0A87056397CF9451E9EEEF80@HE1PR08MB2923.eurprd08.prod.outlook.com>

Dear FT community,

I'm in the process of doing an ICA on my EEG data, but run into the following error using ft_icabrowser:
Error using topoplot_common (line 529)
labels in data and labels in layout do not match

Error in ft_topoplotIC (line 185)
  [cfg] = topoplot_common(cfg, comp);

Error in ft_icabrowser (line 151)
        ft_topoplotIC(cfgtopo, comp);

I tried to step through the code and debug it and noticed that when ft_icabrowser calls ft_topoplotIC (on line 151) the cfg.layout.label changes.
It removes all my channel labels and only leaves:
'COMNT'
'SCALE'

These configuration settings are then used for calling topoplot_common.
I assume that this is the reason why I get the error that labels in data and labels in layout do not match.

Does anyone know why this happens and how to solve it?

My code:

    cfg = [];
    cfg.method         = 'runica';
    cfg.runica.pca     = 32;
    comps{subject}  = ft_componentanalysis(cfg, data_repaired_channels);

    % visualise components and decide which to keep/reject
    cfg = [];
    cfg.elec         = elec;
    cfg.layout     = ft_prepare_layout(cfg,elec);
    cfg.path        = Path2Save;
    cfg.prefix      = ( ['component_' num2str(subject)] );
    ft_databrowser(cfg,comps{subject});
    rejcomp        = ft_icabrowser(cfg,comps{subject});


Best regards,
Martin

------------

Martin Schaefer | PhD Student

https://www.perceptionlab.se/

Department of Clinical Neuroscience (CNS), K8

Karolinska Institutet | 17 177 Stockholm | Nobels väg 9

martin.schaefer at ki.se<mailto:artin.arshamian at ki.se>

______________________________________
Karolinska Institutet – a Medical University




När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter. Här finns information om hur KI behandlar personuppgifter<https://ki.se/medarbetare/integritetsskyddspolicy>.


Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI’s processing of personal data here<https://ki.se/en/staff/data-protection-policy>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201127/8062ee44/attachment.htm>

From psc.dav at gmail.com  Mon Nov 30 17:08:26 2020
From: psc.dav at gmail.com (David Pascucci)
Date: Mon, 30 Nov 2020 17:08:26 +0100
Subject: [FieldTrip] Post-doctoral Position at the Icelandic Vision Lab
Message-ID: <CAN1646-amm0kUmaQH8D1FNxa4BwHXLH2V6ZV4N4qupxNrzRQXg@mail.gmail.com>

The *Icelandic Vision Lab* (www.visionlab.is) is opening a two-year
post-doctoral position, potentially extendable for one year, funded by a
grant from the *Icelandic Research Fund* (*IRF*). The successful candidates
will work in the context of a collaborative project between Professor *Árni
Kristjánsson* (*University of Iceland*) and Dr. *David Pascucci* (*EPFL
Lausanne*).



People with a Ph.D. in various disciplines will be considered,
including *Neuroscience,
Biology, Psychology, Mathematics, Engineering.*



The position involves research into the role of statistical variations and
temporal context in human perception and attention. Recent evidence
suggests that humans can rapidly learn and retain rich and detailed
representations of the distributional properties of features in a visual
scene. The work will focus on how *feature distribution learning* is shaped
by the temporal context of visual events.

Research findings relevant to the project have been published in various
prominent academic journals (see for example www.visionlab.is/publications).


The project includes *behavioral studies*, *computational modeling*, and
*EEG*. The primary place of work will be the Icelandic Vision Lab in
Reykjavik, but the work will include extensive collaboration with the
laboratory of Psychophysics at EPFL in Lausanne.



Experience with experimental psychology software (PsychoPy/Psychtoolbox),
programming (Python/MATLAB/C/C++), statistical software such as R,
computational modeling in vision, are all definite benefits but promising
candidates showing enthusiasm and willingness to learn these methods will
also be considered.


The Icelandic Vision Lab offers a stimulating academic environment and is
headed by professors Árni Kristjánsson, Heiða María Sigurðardóttir, and
Árni Gunnar Ásgeirsson. The laboratory has an extended network of
collaborations, from all over the world and is in many ways unique in this
international aspect. The planned collaboration will involve potential
periods abroad at EPFL, one of the leading universities in Europe.

The successful candidates will join this vibrant community of graduate
students, post-docs, and faculty who all work on varied aspects of visual
perception. The lab is well funded with grants from the Icelandic Research
Fund, The European Research Council, and the Research Fund of the
University of Iceland. There is good access to the necessary equipment for
the studies. The lab has high-end equipment for EEG, eye movement studies
as well as extensive experience with high-quality psychophysical studies.


Iceland consistently ranks as one of the best places in the world to live: (
http://worldhappiness.report/ed/2019/), life satisfaction is among the
highest in the world (
http://www.oecdbetterlifeindex.org/topics/life-satisfaction), and the
country is consistently rated the most peaceful in the world (
http://worldpopulationreview.com/countries/most-peaceful-countries/).
Iceland also ranks at the top of the world in terms of gender equality (
https://www.weforum.org/agenda/2019/12/gender-gap-equality-women-parity-countries/).
Applicants of any gender are strongly encouraged to apply.



The position will start in 2021, as early as possible.

Please send applications or inquiries to IVLapplications2020 at gmail.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201130/741e52be/attachment.htm>

