From jan.schoffelen at donders.ru.nl Fri Nov 1 10:00:08 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 1 Nov 2013 10:00:08 +0100 Subject: [FieldTrip] new functionality for inverse modelling Message-ID: <444DEF5C-40D5-4143-9ED6-1B3DBCBD113A@donders.ru.nl> Dear FT-community, We are happy to announce that we just added some now functionality to the toolbox. Thanks to generous code contributions by Guido Nolte and Marlene Boenstrup from UKE Hamburg it is now possible to specify eloreta as a method in ft_sourceanalysis. It should work both on frequency and time domain data. Please feel free to try it out, and be generous with feedback/comments etc. Happy computing, also on behalf of Guido and Marlene, Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.vanlier at bsse.ethz.ch Fri Nov 1 12:33:02 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 1 Nov 2013 11:33:02 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: Hi Eric, Thanks for the answer. I really just dont see it... Where does the permutation distribution of the max cluster stat come from if you don't do a permutation test? But you don't actually need that distribution just the statistic?? how do you know then where your max stat (and the other clusterstats) is compared to the critical value at alpha? lets say your max clusterstat = 10 P(max(clusterstat) _> cv) = 0.05 so the probability that we see 10 or higher is 5% if h0 is in fact true. we actually are seeing 10 and thus (falsely) reject h0. so that always happens when h0 is true - you always reject the max cluster when h0 is true? doesn't make sense :( Thanks, Ben From e.maris at psych.ru.nl Fri Nov 1 22:40:10 2013 From: e.maris at psych.ru.nl (Eric Maris) Date: Fri, 1 Nov 2013 22:40:10 +0100 (CET) Subject: [FieldTrip] repeated measures ANOVA (statfun_depsamplesF): dfdenom problems In-Reply-To: <008D1219-3AC8-4011-985E-7396B0A9D64C@uos.de> References: <008D1219-3AC8-4011-985E-7396B0A9D64C@uos.de> Message-ID: <04ba01ced74a$efce27a0$cf6a76e0$@maris@psych.ru.nl> Dear Tim, > We have recently run into problems using the implementation of a > repeated measures ANOVA in statfun_depsamplesF.m. In our experiment, we > have recorded data of 16 subjects, and the factor of the repeated- > measures ANOVA has 37 levels (admittedly quite a few but that's just > how it is). > > Now if I am not mistaken, then for a repeated measures ANOVA, the > degrees of freedom in above case should be: df1 = 36 and df2 = 540 > (this is in line with the results of SPSS, too). However, the > statfun_depsamplesF.m function seems to compute dfdenom as nunits - > ncontrasts (nunits is the number of subjects, and ncontrasts is > nlevels-1). This of course leads to a different value as compared to > SPSS and what I found in the literature, in which dfdenom is computed > as (K-1)*(n-1), so in the current case as (nunits-1)*ncontrasts. > > For a one-factor repeated measures ANOVA, I could so far not find a > principled reason why the number of levels should not exceed the number > of subjects (which is the error message we get). In fact, SPSS works > just fine in above scenario. Could someone please explain the logic > behind the dfdenom computation in fieldtrip? Could it be that there is > an error in how the degrees of freedom are computed, or am I missing > something obvious here? For a MANOVA, the story would be different of > course. Here, you suggest the answer yourself: in Fieldtrip, we (I) have implemented the MANOVA dependent samples F-test, which requires more units than repeated measures. However, within the permutation framework, nothing prevents you from using the mixed F-statistic that you want to use (probably because it can deal with the situation of less units than repeated measures). You can write your own statfun, e.g. statfun_depsamplesFmixedmodel, and call this function in Fieldtrip's higher level statistics functions. Good to know, the false alarm rate control of your p-value-based inference does not depend on the sphericity assumption behind the use of the mixed model dependent samples F-test in a parametric context. Best, Eric Maris > > I should add that we are currently interfacing fieldtrip from eeglab > and get above error only if we choose the nonparametric fieldtrip > statistics (with cluster correction), but the parametric tests > implemented in eeglab work just fine. > > > Thank you very much for your help, I am looking forward to your > responses Tim > > > From pgoodin at swin.edu.au Sat Nov 2 07:15:27 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Sat, 2 Nov 2013 06:15:27 +0000 Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files In-Reply-To: References: Message-ID: Hi Neils, I use the ft_preprocessing function to load both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs. I haven't had a problem with dropped triggers / incorrect trial lengths etc. Please find the code I use below (and excuse any clunkiness): As for your second question re: cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. Hope the above (and below) helps and happy MEGing, Peter. %% %Read data into matlab cfg = []; cfg.dataset = megdata1; %first fif file cfg.channel = 'MEG'; d1 = ft_preprocessing(cfg); cfg = []; cfg.dataset = megdata2; %second fif file cfg.channel = 'MEG'; d2 = ft_preprocessing(cfg); %% %concatenate data dfull = d1; dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly. dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); dfull.sampleinfo = [1 length(dfull.trial{1,1})]; for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR. i = i + 1; end __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [aestnth at hum.au.dk] Sent: Friday, 1 November 2013 3:16 AM To: fieldtrip at science.ru.nl Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files Dear FieldTrip community. Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. ( http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? I'm looking forward to hear any comments, suggestions or solutions. Greetings Niels. Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital Denmark E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From russgport at gmail.com Sat Nov 2 23:19:41 2013 From: russgport at gmail.com (Russell G Port) Date: Sat, 2 Nov 2013 17:19:41 -0500 Subject: [FieldTrip] volume normalizing to mni template from ctf space mri Message-ID: Hi All, I just wanted to confirm this, because although I seen hints about this on the emails and websites that fieldtrip kindly archives; I worry. If I have a CTF coordinate system single subject MRI, and I want to normalize that onto the AVG152 brain in MNI space for example, ft_volumenormalization should handle this. What I mean by this is that I do not have to reslice/realign my image first to MNI space and then normalize... am I correct or misled? Best, Russ -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at psych.ru.nl Sun Nov 3 11:41:22 2013 From: e.maris at psych.ru.nl (Eric Maris) Date: Sun, 3 Nov 2013 11:41:22 +0100 (CET) Subject: [FieldTrip] maximum statistic in cluster correction In-Reply-To: References: Message-ID: <055001ced881$3baa4b40$b2fee1c0$@maris@psych.ru.nl> Hi Ben, (When you reply to a post, please also keep the post to which you reply. This is useful for others that want to follow the discussion.) > Thanks for the answer. I really just dont see it... Where does the > permutation distribution of the max cluster stat come from if you don't > do a permutation test? Without a permutation test, there is no permutation distribution. You construct the permutation distribution as a part of the test. > > But you don't actually need that distribution just the statistic?? You need both the distribution and the statistic, just like in parametric (Neyman-Pearson) statistics. However, unlike parametric statistics, in permutation statistics you construct your own reference distribution (i.c., the permutation distribution). how > do you know then where your max stat (and the other clusterstats) is > compared to the critical value at alpha? > > lets say your max clusterstat = 10 > > P(max(clusterstat) _> cv) = 0.05 > so the probability that we see 10 or higher is 5% if h0 is in fact > true. we actually are seeing 10 and thus (falsely) reject h0. so that > always happens when h0 is true - you always reject the max cluster when > h0 is true? doesn't make sense :( Your conceptual problem probably is due to the fact that you do not see how the maximum cluster statistic is generated under the permutation distribution. Under this distribution, this statistic really is a random variable. Maybe there is someone in your university to discuss this point. These conceptual issues are much faster clarified in a one-to-one discussion. Alternatively, attend one of our Fieldtrip courses. Best, Eric Maris > > Thanks, > Ben > From kgm at tf.uni-kiel.de Mon Nov 4 14:30:57 2013 From: kgm at tf.uni-kiel.de (kgm at tf.uni-kiel.de) Date: Mon, 4 Nov 2013 14:30:57 +0100 Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat Message-ID: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> Hi, I am working with the combined EEG and MEG recording and would like to do the forward model for the EEG. So I was trying to use the 'bemcp' and 'openmeeg' as am working on windows platform. I have the anatomy of my subject (DICOM file stacked and cleaned using SPM). When I try to use openmeeg, vol.mat is missing from the vol structure giving an error message om_minverser.exe doesn't function anymore. When I try to use 'bemcp', vol.mat contains all NaNs which resulted from the c12 and c21 matrices being not a square matrix which makes the inverse to be non-existent and also those matrices consists a large number of 'Inf' entries. Like it was mentioned on one of the forums, the error might come when the meshes are generated. I was able to find the index of the vertices from the Cij matrix, but I couldn't find the actual relation to the vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either brain, skull or scalp. Here are all the steps that I have followed. % reading MRI mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); % segment the brain cfg = []; cfg.output = {'brain', 'skull', 'scalp'}; cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- interauricular segmentedmri = ft_volumesegment(cfg, mri); segmentedmri.anatomy = mri.anatomy; % prepare mesh cfg = []; cfg.tissue = {'brain','skull', 'scalp'}; cfg.numvertices = [3000 2000 1000]; cfg.transform = segmentedmri.transform; bnd = ft_prepare_mesh(cfg, segmentedmri); % create head model cfg = []; cfg.method = 'openmeeg'; cfg.conductivity = [0.33 0.0041 0.33]; vol = ft_prepare_headmodel(cfg, bnd); figure; ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain figure; ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull figure; ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp Any help? Thanks. Kidist From s.rombetto at cib.na.cnr.it Mon Nov 4 17:16:33 2013 From: s.rombetto at cib.na.cnr.it (s.rombetto at cib.na.cnr.it) Date: Mon, 4 Nov 2013 17:16:33 +0100 Subject: [FieldTrip] question on SPIKE structure Message-ID: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> Dear Fieldtrip users I've just read the Tutorial concerning "Preprocessing and analysis of spike and local field potential data". Now I am wondering if it is possible to create a SPIKE structure, starting from recorded data, even without using any electrophysiology data acquisition system. Anybody can answer to this question? Maybe it is trivial, but I hhave never worked with these systems, but I am interested to this kind of analysis. Regards ------------------------- Dott.ssa Sara Rombetto Istituto di Cibernetica "E. Caianiello" Via Campi Flegrei, 34 80078 Pozzuoli (NA) Italy mob +39 3401689815 tel +39 0818675361 fax +39 0818675128 -------------------------- "I disapprove of what you say, but I will defend to the death your right to say it." [Evelyn Beatrice Hall, The Friends Of Voltaire] ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From r.oostenveld at donders.ru.nl Mon Nov 4 22:24:09 2013 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Mon, 4 Nov 2013 22:24:09 +0100 Subject: [FieldTrip] question on SPIKE structure In-Reply-To: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> References: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> Message-ID: <252AD1B6-7925-4BCA-9541-15E28EB11741@donders.ru.nl> Dear Sara, Please have a look at ft_datatype_spike in the utilities directory (or do "help ft_datatype_spike"). It explains the various fields in the spike data structure. We have such ft_datatype_xxx functions for all FieldTrip data structures. Their help serves to define the data structure (also for the developers), and the code in the functions serves to do some sanity checks and to update older data structures (e.g. stored in a mat file on disk) to the standards of the fieldtrip version that has to process them. best regards, Robert On 4 Nov 2013, at 17:16, s.rombetto at cib.na.cnr.it wrote: > Dear Fieldtrip users > > I've just read the Tutorial concerning "Preprocessing and analysis of spike and local field potential data". > Now I am wondering if it is possible to create a SPIKE structure, starting from recorded data, even without using any electrophysiology data acquisition system. > Anybody can answer to this question? Maybe it is trivial, but I hhave never worked with these systems, but I am interested to this kind of analysis. > > Regards > ------------------------- > Dott.ssa Sara Rombetto > Istituto di Cibernetica > "E. Caianiello" > Via Campi Flegrei, 34 > 80078 Pozzuoli (NA) > Italy > mob +39 3401689815 > tel +39 0818675361 > fax +39 0818675128 > -------------------------- > "I disapprove of what you say, but I will defend to the death your right to say > it." [Evelyn Beatrice Hall, The Friends Of Voltaire] > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 5 09:43:18 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 5 Nov 2013 09:43:18 +0100 Subject: [FieldTrip] question about coregistration References: Message-ID: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Dear Nicola, I am forwarding your question to the list, "ter lering ende vermaak": Begin forwarded message: > From: Nicola Molinaro > Date: November 4, 2013 2:16:20 PM GMT+01:00 > To: jan-mathijs schoffelen > Subject: mm -> voxels ?? > > Hi Jan, > I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? > I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). > > Thanks > > Nicola Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). Best wishes, Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Tue Nov 5 16:56:59 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Tue, 05 Nov 2013 16:56:59 +0100 Subject: [FieldTrip] =?utf-8?q?Reading_data_and_trigger_events_from_Neurom?= =?utf-8?q?ag_=09fif=09dataset__spli?= In-Reply-To: References: Message-ID: Thanks Peter. The concatenation of the data by using horzcat works fine. However, I don't know how to define the trials by refering to the concatenated data. Is it possible to automatically define the trials based on trigger signals in the concatenated data by using ft_definetrial or ft_redefinetrial? I get the error message (see below) about the missing headerfile. I tried to define cfg.header = dfull.hdr and cfg.headerfile = dfull.hdr , but it didn't seem to work. Greetings Niels. >> cfg = []; cfg.data = dfull cfg.trialfun = 'ft_trialfun_general' % this is the default cfg.trialdef.eventtype = 'STI101'; % trigger channel cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds trl = ft_definetrial(cfg); cfg = data: [1x1 struct] cfg = data: [1x1 struct] trialfun: 'ft_trialfun_general' evaluating trialfunction 'ft_trialfun_general' Reference to non-existent field 'headerfile'. Error in ft_trialfun_general (line 71) hdr = ft_read_header(cfg.headerfile, 'headerformat', cfg.headerformat); Error in ft_definetrial (line 162) [trl, event] = feval(cfg.trialfun, cfg); FieldTrip discussion list writes: >Hi Neils,� > > >I use the ft_preprocessing function to load � both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs.� > > >I haven't had a problem with dropped triggers / incorrect trial lengths etc.� > > >Please find the code I use below (and excuse any clunkiness): > > >As for your second question re:� cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. � > > >Hope the above (and below) helps and happy MEGing,� > > >Peter. > > > > >%% >%Read data into matlab > > >cfg = []; >cfg.dataset = megdata1; %first fif file >cfg.channel = 'MEG'; >d1 = ft_preprocessing(cfg); > > >cfg = []; >cfg.dataset = megdata2;� %second fif file >cfg.channel = 'MEG'; >d2 = ft_preprocessing(cfg); > > >%% >%concatenate� data > > >dfull = d1; >dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly.� >dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); >dfull.sampleinfo = [1 length(dfull.trial{1,1})]; > > >for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. >dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR.� >i = i + 1; >end� � > > >__________________________ >Peter Goodin,� >BSc (Hons), Ph.D Candidate. > > >Brain and Psychological Sciences Research Centre (BPsych) >Swinburne University,� >Hawthorn, Vic, 3122 > > >Monash Alfred Psychiatry Research Centre (MAPrc) >Level 4, 607 St Kilda Road, >Melbourne 3004 > >--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >-From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [aestnth at hum.au.dk] >Sent: Friday, 1 November 2013 3:16 AM >To: fieldtrip at science.ru.nl >Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files > > >Dear FieldTrip community. > >Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? > >The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. >FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. >( [ http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ]http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) > >I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. >The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. > >When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. � > >I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? > >I'm looking forward to hear any comments, suggestions or solutions. > >Greetings >Niels. > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >Denmark >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From joramvandriel at gmail.com Wed Nov 6 10:06:39 2013 From: joramvandriel at gmail.com (Joram van Driel) Date: Wed, 6 Nov 2013 10:06:39 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: Hi Nicola, I also did coregistration in MRI-lab using isotrak data. Importing the fif files in fieldtrip worked fine, I don’t think you have to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial ingredient. This worked for me: mri = ft_read_mri(); %%% read the MRI; the fif file is in mm but FT changes it into meters mri = ft_convert_units(mri,'mm'); %%% make it mm as it originally was mri = ft_volumereslice([], mri); %%% after this function the ficual points in the MEG header match the coordinates in the MRI Then you should indeed check this with ft_sourceplot, where in the cfg you can fill in fiducial points to check if they make sense, e.g.: cfg = []; cfg.location = [0 90.5 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly cfg.locationcoordinates = 'head'; ft_sourceplot(cfg,mri); Hope this helps. Best, Joram On 05 Nov 2013, at 09:43, jan-mathijs schoffelen wrote: > Dear Nicola, > > I am forwarding your question to the list, "ter lering ende vermaak": > > Begin forwarded message: > >> From: Nicola Molinaro >> Date: November 4, 2013 2:16:20 PM GMT+01:00 >> To: jan-mathijs schoffelen >> Subject: mm -> voxels ?? >> >> Hi Jan, >> I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? >> I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). >> >> Thanks >> >> Nicola > > > Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? > To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. > Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. > I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). > > Best wishes, > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Wed Nov 6 11:52:19 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Wed, 6 Nov 2013 11:52:19 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: Thanks guys for any possible help. Really appreciate it! I will summarize my tests: 1. reading the COR-.fif produced by MRIlab with ft_read_mri Well, it seems that ft_read_mri reads the original (not coregistered) .fif file produced in earlier steps of the forward model calculation (COR.fif). For example, if I delete the COR.fif file, ft_read_mri gives an error. ft_read_mri applied to the COR-.fif should be able to read some header, and for this reason I tried the option suggested by Joram (including ft_volumereslice). However, when I plot the volume head model with *hs=ft_read_headshape(.fif. 'unit','mm'); %get headshape points* *ft_plot_vol(vol)* *ft_plot_headshape(hs)* There is an evident misalignment between isotrack points and the brain volume. I mean NO coregistration is done. you can also appreciate it when plotting a prearicular instead of the nasion with *cfg = [];* *cfg.location = [66.4 0 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly* *cfg.locationcoordinates = 'head';* *ft_sourceplot(cfg,mri);* Take home message: Fieldtrip does not read the coregistration done in MRIlab, and you have to coregister MEG and MRI again. 2. Using cfg.method = 'headshape' cfg.headshape = 'XXX.pos' for ft_volumerealign. I played with it, but in neuromag the polhemous data are within the header of the *.fif* file. You can export the isotrack point however from MRIlab. After importing then with File>Import>Isotrack data you can then export them with File>Export>Points and specifying the coordinate system in which you want your point (either Head, or MRI or Voxel). This file cannot be read by ft_volumerealign with the headshape method. However, the first three lines of the resulting .txt file will give you the nasion and the two pre-auricolar points positions. I tried importing the voxel positions of the three points in ft_volumerealign using the method cfg.coordsys = 'neuromag'; cfg.method = 'fiducial'; And it worked, the brain volume is aligned with the isotrack points. This is the only solution that is visually reliable to perform On Wed, Nov 6, 2013 at 10:06 AM, Joram van Driel wrote: > Hi Nicola, > > I also did coregistration in MRI-lab using isotrak data. > Importing the fif files in fieldtrip worked fine, I don’t think you have > to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial > ingredient. > This worked for me: > > mri = ft_read_mri(); %%% read the MRI; the fif > file is in mm but FT changes it into meters > mri = ft_convert_units(mri,'mm'); %%% make it mm as it > originally was > mri = ft_volumereslice([], mri); %%% after this function the > ficual points in the MEG header match the coordinates in the MRI > > Then you should indeed check this with ft_sourceplot, where in the cfg you > can fill in fiducial points to check if they make sense, e.g.: > > cfg = []; > cfg.location = [0 90.5 0]; %%% fill in a fiducial point from > the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > > ft_sourceplot(cfg,mri); > > Hope this helps. > Best, > Joram > > On 05 Nov 2013, at 09:43, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > > Dear Nicola, > > I am forwarding your question to the list, "ter lering ende vermaak": > > Begin forwarded message: > > *From: *Nicola Molinaro > *Date: *November 4, 2013 2:16:20 PM GMT+01:00 > *To: *jan-mathijs schoffelen > *Subject: **mm -> voxels ??* > > Hi Jan, > I am trying to align the T1 images with isotrak data using MRIlab and then > import the coregistrated image to fieldtrip. Comparing the headshape points > with the volume, we can see that Fieldtrip is not taking into account the > coregistration. Thus, we are trying to do the corregistration applying the > ft_volumerealign function with the method='fiducial' in Fieldtrip. I have > the information of the landmarks' position obtained with MRIlab in 'mm' and > the function ft_volumerealign need them in voxel index. How can you convert > that? > I don´t know if you ever used MRIlab to obtain this information or another > software (MNE?). > > > Thanks > > Nicola > > > > Indeed I have never used MRIlab for coregistration purposes, so I may not > be of much help here. However, I suspect that the coregistration procedure > in MRIlab allows you to export your MRI after coregistration, thus creating > an file with an anatomical image in register with what you want to achieve. > If this is the case, then I don't think that you need FieldTrip to > coregister again. I am therefore a bit confused with respect to your remark > that 'FieldTrip is not taking into account the coregistration'. If you read > in an MRI into FieldTrip, the resulting MRI-structure will contain a > transform field, that provides the mapping from voxel space into a more > meaningful coordinate system. FieldTrip will not 'guess' the nature of this > coordinate system: it just takes the values as they are in the file. Once > you have read in your MRI, you can use the ft_sourceplot function for > visualization. With cfg.method = 'ortho', the figure will also display the > coordinates that you click on (both in voxel indices and in real world > coordinates). Now, do you mean by 'FieldTrip does not take into account the > coregistration' that these real world coordinates are not as expected? > To answer your question regarding the conversion of landmark positions in > 'mm' back into voxel indices: this requires information from the > mri.transform matrix, but this implies that the mri is already in register, > so there would be no need anymore to call ft_volumerealign. > Either way, you could also do the coregistration entirely in FieldTrip. > This requires a two-step approach, calling ft_volumerealign twice (starting > from the raw DICOM files, i.e. prior to having used MRIlab). In the first > step you will use cfg.interactive = 'yes' and identify the fiducials that > define your corodinate system. Assuming that you are working with your MEG > data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). > The output to this funcion call is an MRI structure that is approximately > in register with the MEG-device. In the next step you can refine this > coregistration by calling ft_volumerealign (with the approximately > registered MRI in the input, and) with cfg.method = 'headshape', and > cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should > result (providing that the isotrak data can be read ;-) ) in an interactive > figure, that allows you to further align the MRI with the polhemus point > cloud that describes the headshape. Once you are happy enough, the figure > can be closed, and an iterative-closest-point algorithm is applied for > further refinement of the coregistration. > I hope this helps, and might inspire you to try out the coregistration in > FieldTrip (and give feedback to us about it, in order to make the procedure > more robust). > > Best wishes, > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -- ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Wed Nov 6 22:57:54 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Wed, 06 Nov 2013 22:57:54 +0100 Subject: [FieldTrip] =?utf-8?q?Reading_data_and_trigger_events_from_Neurom?= =?utf-8?q?ag_=09fif=09dataset___sp?= In-Reply-To: References: <, > <,> Message-ID: Sorry, the previously posted example was wrong. Below is a correction to the previous example. Does the error shown below mean that you can only define trials based on the raw data files, and you can not define trials based on the data, which has already been converted to FieldTrip data? If so, I assume that it's necessary to: 1. Apply ft_definetrial on each one of the splitted raw fif files. 2. In the first two rows in the trial definition matrix from the second splitted file (i.e. the trial begin sample and trial end sample) add the number of samples in the preceeding raw fif file + 1. 3. Use vertcat to concatenate the corrected trial definition matrices from both files into one trial definition. 4. Then use ft_redefinetrial to apply the concatenated trial definitions on the concatenated data. Have anyone tried succesfully to concatenate trial definitions and apply them on concatenated data (in cases with raw fif files splitted into 2 files due to 2 GB file limitation during raw data recording)? Greetings Niels. >> cfg = []; cfg.dataset = dfull cfg.trialfun = 'ft_trialfun_general' % this is the default cfg.trialdef.eventtype = 'STI101'; % trigger channel cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds trl = ft_definetrial(cfg); cfg = dataset: [1x1 struct] cfg = dataset: [1x1 struct] trialfun: 'ft_trialfun_general' Warning: -clear > In utilities/private/warning_once at 116 In utilities/private/ft_preamble_init at 26 In ft_preamble at 54 In ft_definetrial at 112 Error using fileparts (line 31) Input must be a row vector of characters. Error in ft_filetype (line 146) [p, f, x] = fileparts(filename); Error in dataset2files (line 14) format = ft_filetype(filename); Error in ft_checkconfig (line 503) [cfg.dataset, cfg.headerfile, cfg.datafile] = dataset2files(cfg.dataset, []); Error in ft_definetrial (line 116) cfg = ft_checkconfig(cfg, 'dataset2files', {'yes'}); FieldTrip discussion list writes: >Thanks Peter. > >The concatenation of the data by using horzcat works fine. > >However, I don't know how to define the trials by refering to the concatenated data. >Is it possible to automatically define the trials based on trigger signals in the concatenated data by using ft_definetrial or ft_redefinetrial? > >I get the error message (see below) about the missing headerfile. I tried to define cfg.header = dfull.hdr and cfg.headerfile = dfull.hdr , but it didn't seem to work. > >Greetings >Niels. > >>> cfg = []; >cfg.data = dfull >cfg.trialfun = 'ft_trialfun_general' % this is the default >cfg.trialdef.eventtype = 'STI101'; % trigger channel >cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers >cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds >cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds >trl � = ft_definetrial(cfg); > >cfg = > >� � � � data: [1x1 struct] > > >cfg = > >� � � � � � � � data: [1x1 struct] > � � � trialfun: 'ft_trialfun_general' > >evaluating trialfunction 'ft_trialfun_general' >Reference to non-existent field 'headerfile'. > >Error in ft_trialfun_general (line 71) >hdr = ft_read_header(cfg.headerfile, 'headerformat', cfg.headerformat); > >Error in ft_definetrial (line 162) > � � � [trl, event] = feval(cfg.trialfun, cfg); > > >FieldTrip discussion list <[ mailto:fieldtrip at science.ru.nl ]fieldtrip at science.ru.nl> writes: >Hi Neils,� > > >I use the ft_preprocessing function to load � both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs.� > > >I haven't had a problem with dropped triggers / incorrect trial lengths etc.� > > >Please find the code I use below (and excuse any clunkiness): > > >As for your second question re:� cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. � > > >Hope the above (and below) helps and happy MEGing,� > > >Peter. > > > > >%% >%Read data into matlab > > >cfg = []; >cfg.dataset = megdata1; %first fif file >cfg.channel = 'MEG'; >d1 = ft_preprocessing(cfg); > > >cfg = []; >cfg.dataset = megdata2;� %second fif file >cfg.channel = 'MEG'; >d2 = ft_preprocessing(cfg); > > >%% >%concatenate� data > > >dfull = d1; >dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly.� >dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); >dfull.sampleinfo = [1 length(dfull.trial{1,1})]; > > >for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. >dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR.� >i = i + 1; >end� � > > >__________________________ >Peter Goodin,� � >BSc (Hons), Ph.D Candidate. > > >Brain and Psychological Sciences Research Centre (BPsych) >Swinburne University,� >Hawthorn, Vic, 3122 > > >Monash Alfred Psychiatry Research Centre (MAPrc) >Level 4, 607 St Kilda Road, >Melbourne 3004 > > >--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >- >From: [ mailto:fieldtrip-bounces at science.ru.nl ]fieldtrip-bounces at science.ru.nl� [[ mailto:fieldtrip-bounces at science.ru.nl ]fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [[ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk] >Sent: Friday, 1 November 2013 3:16 AM >To: [ mailto:fieldtrip at science.ru.nl ]fieldtrip at science.ru.nl >Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files > > >Dear FieldTrip community. > >Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? > >The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. >FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. >( [ http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ]http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) > >I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. >The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. > >When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. � > >I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? > >I'm looking forward to hear any comments, suggestions or solutions. > >Greetings >Niels. > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >Denmark >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >[ mailto:fieldtrip at donders.ru.nl ]fieldtrip at donders.ru.nl >[ http://mailman.science.ru.nl/mailman/listinfo/fieldtrip ]http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.oostenveld at donders.ru.nl Thu Nov 7 09:28:30 2013 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Thu, 7 Nov 2013 09:28:30 +0100 Subject: [FieldTrip] Fwd: MEG postdoc vacancy - Aarhus Univ, DK References: <4494422563576817.WA.yury.shtyrovcfin.au.dk@www.jiscmail.ac.uk> Message-ID: <8D6628F1-BF71-4019-916D-1289BA520D0D@donders.ru.nl> Begin forwarded message: > From: Yury Shtyrov > Date: 6 November 2013 19:23:18 CET > To: NEUROMEG at JISCMAIL.AC.UK > Subject: MEG postdoc vacancy - Aarhus Univ, DK > Reply-To: Yury Shtyrov > > Dear all, > > Apologies for possible cross-postings - could you please circulate this MEG job to anyone who could be interested. > > Thanks, > /yury/ > > Yury Shtyrov, DPhil > Professor - Head of MEG Group > MINDLab - Center of Functionally Integrative Neuroscience (CFIN) > Institute for Clinical Medicine > Aarhus University, Denmark > > > ------------------ > > Post-doctoral Position in MEG/Neuroscience of Language > Center of Functionally Integrative Neuroscience, Aarhus University > > Applications are invited for a postdoctoral scientist to support research into neurobiological foundations of language at the Center of Functionally Integrative Neuroscience (CFIN), Aarhus University, Denmark. The postholder’s research will be centred on using MEG and on the spatio-temporal dynamics of the neural activity underlying speech and language processing in the human brain. Ideal candidates will therefore have experience in neuroimaging and in language research. Previous experience in using EEG or/and MEG is essential. Eligible candidates should hold a PhD or similar degree in a relevant discipline, including (but not limited to) psychology, neuroinformatics, psycholinguisitcs or neuroscience. The position is to be filled as soon as possible and is initially open for 1 year with a possibility of extension and/or permanent post for a good candidate. > > CFIN is an international multidisciplinary research centre based at Aarhus University’s Institute for Clinical Medicine, Denmark. Our research groups are supported by state-of-the-art cognitive neuroscience facilities including research-only 306-channel TRIUX MEG system (Elekta Neuromag), fMRI systems (Siemens TIM Trio 3T, Magnetom Skyra 3T), PET, navigated TMS, EEG and eye-tracking equipment, Two-Photon Microscopy, etc., and have well-established clinical and other collaborations. See cfin.au.dk for more inromation. Aarhus University provides an inspiring international research environment with top neuroscience facilties, and is consistently named among the world's best 100 universities. > > To apply, please go to http://www.au.dk/en/about/job/sun/academicpositions/ > > Additional information regarding this position can be obtained by contacting Professor Yury Shtyrov, head of MEG, CFIN: Yury.Shtyrov at cfin.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lilla.Magyari at mpi.nl Thu Nov 7 09:44:35 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 7 Nov 2013 09:44:35 +0100 (CET) Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> Message-ID: <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> hi Kidist, I am wondering if you have installed openmeeg properly. Here is a site to explain it: http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling Have you followed this? Lilla > Hi, > > I am working with the combined EEG and MEG recording and would like to do > the forward model for the EEG. > > So I was trying to use the 'bemcp' and 'openmeeg' as am working on windows > platform. I have the anatomy of my subject (DICOM file stacked and cleaned > using SPM). > > When I try to use openmeeg, vol.mat is missing from the vol structure > giving an error message om_minverser.exe doesn't function anymore. > > When I try to use 'bemcp', vol.mat contains all NaNs which resulted from > the c12 and c21 matrices being not a square matrix which makes the inverse > to be non-existent and also those matrices consists a large number of > 'Inf' entries. > > Like it was mentioned on one of the forums, the error might come when the > meshes are generated. I was able to find the index of the vertices from > the Cij matrix, but I couldn't find the actual relation to the > vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either brain, > skull or scalp. > > Here are all the steps that I have followed. > > % reading MRI > mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); > > % segment the brain > cfg = []; > cfg.output = {'brain', 'skull', 'scalp'}; > cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- > interauricular > segmentedmri = ft_volumesegment(cfg, mri); > segmentedmri.anatomy = mri.anatomy; > > % prepare mesh > cfg = []; > cfg.tissue = {'brain','skull', 'scalp'}; > cfg.numvertices = [3000 2000 1000]; > cfg.transform = segmentedmri.transform; > bnd = ft_prepare_mesh(cfg, segmentedmri); > > % create head model > cfg = []; > cfg.method = 'openmeeg'; > cfg.conductivity = [0.33 0.0041 0.33]; > vol = ft_prepare_headmodel(cfg, bnd); > > figure; > ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain > figure; > ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull > figure; > ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp > > Any help? > > Thanks. > Kidist > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From Lilla.Magyari at mpi.nl Thu Nov 7 10:35:54 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 7 Nov 2013 10:35:54 +0100 (CET) Subject: [FieldTrip] volume normalizing to mni template from ctf space mri In-Reply-To: References: Message-ID: <2065.84.86.187.191.1383816954.squirrel@84.86.187.191> hi Russ, you do not need to worry. Your original volume is converted to spm space from ctf during normalization and then the original volume and the template are matched to each other. Although the ctf to spm conversion is an approximation, it is sufficient to produce OK result. So, you do not need to realign or reslice your volume prior to normalization. And just a remark for others: The automatic conversion happens only if the original volume defined in ctf (or bti) or in itab (neuromag) coordinates. Otherwise, the original volume should be aligned to spm space. Lilla > Hi All, > > I just wanted to confirm this, because although I seen hints about this on > the emails and websites that fieldtrip kindly archives; I worry. If I have > a CTF coordinate system single subject MRI, and I want to normalize that > onto the AVG152 brain in MNI space for example, ft_volumenormalization > should handle this. What I mean by this is that I do not have to > reslice/realign my image first to MNI space and then normalize... am I > correct or misled? Best, Russ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From nuria.donamayor at neuro.uni-luebeck.de Thu Nov 7 15:54:31 2013 From: nuria.donamayor at neuro.uni-luebeck.de (=?iso-8859-1?Q?Nuria_Do=F1amayor_Alonso?=) Date: Thu, 7 Nov 2013 15:54:31 +0100 Subject: [FieldTrip] =?iso-8859-1?q?PhD_position_-_University_of_L=FCbeck?= =?iso-8859-1?q?=2C_Germany?= In-Reply-To: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF6@solaris.neuro.uni-luebeck.de> References: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF6@solaris.neuro.uni-luebeck.de> Message-ID: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF8@solaris.neuro.uni-luebeck.de> Dear fieldtrippers, could you please circulate this PhD opening to anyone who might be interested? Thanks, Nuria -------------- The Department of Neurology, University of Lübeck seeks to recruit a Ph.D. student from the 1st of January 2014 onwards. The candidate will be working on a project on the neural basis of primary food reward in humans using multimodal imaging (EEG-fMRI). An essential part of the project will be the development of methods of electrophysiological-hemodynamic coupling. Applicants must hold a Diplom, MSc or equivalent degree in Mathematics, Physics, Engineering or a relevant discipline. They should have a strong interest in cognitive neuroscience and excellent programming skills. Preference will be given to applicants experienced in functional imaging and/or cognitive electrophysiology. The position is initially for 2 years with the possibility of renewal. The salary will be according to an E13 (TV-L, 50%) position. The University of Lübeck is an equal opportunities employer. Applications from female candidates are strongly encouraged. In case of compatible qualifications, preference will be given to people with disabilities. Applications should include CV, copies of certificates and letters of recommendation. Please send initial enquiries and/or applications directly to Dr. Nuria Doñamayor Alonso (nuria.donamayor at neuro.uni-luebeck.de). -------------- next part -------------- A non-text attachment was scrubbed... Name: PhD_position.pdf Type: application/pdf Size: 53874 bytes Desc: PhD_position.pdf URL: From kgm at tf.uni-kiel.de Thu Nov 7 15:56:54 2013 From: kgm at tf.uni-kiel.de (kgm at tf.uni-kiel.de) Date: Thu, 7 Nov 2013 15:56:54 +0100 Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> Message-ID: <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> Hi Lilla, Thank you for your reply. The openmeeg works well for the mri (subject01.mri) that is used in the fieldtrip tutorial. But the error comes when I use my subject's mri whose anatomy is 256*256*192. I have also tried to use mri = ft_volumereslice(cfg,mri) thinking that the error might be due to the inequality of the size of the anatomical volume into each direction. Kidist > hi Kidist, > > I am wondering if you have installed openmeeg properly. Here is a site to > explain it: > http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling > > Have you followed this? > > Lilla > > > >> Hi, >> >> I am working with the combined EEG and MEG recording and would like to >> do >> the forward model for the EEG. >> >> So I was trying to use the 'bemcp' and 'openmeeg' as am working on >> windows >> platform. I have the anatomy of my subject (DICOM file stacked and >> cleaned >> using SPM). >> >> When I try to use openmeeg, vol.mat is missing from the vol structure >> giving an error message om_minverser.exe doesn't function anymore. >> >> When I try to use 'bemcp', vol.mat contains all NaNs which resulted from >> the c12 and c21 matrices being not a square matrix which makes the >> inverse >> to be non-existent and also those matrices consists a large number of >> 'Inf' entries. >> >> Like it was mentioned on one of the forums, the error might come when >> the >> meshes are generated. I was able to find the index of the vertices from >> the Cij matrix, but I couldn't find the actual relation to the >> vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either >> brain, >> skull or scalp. >> >> Here are all the steps that I have followed. >> >> % reading MRI >> mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); >> >> % segment the brain >> cfg = []; >> cfg.output = {'brain', 'skull', 'scalp'}; >> cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- >> interauricular >> segmentedmri = ft_volumesegment(cfg, mri); >> segmentedmri.anatomy = mri.anatomy; >> >> % prepare mesh >> cfg = []; >> cfg.tissue = {'brain','skull', 'scalp'}; >> cfg.numvertices = [3000 2000 1000]; >> cfg.transform = segmentedmri.transform; >> bnd = ft_prepare_mesh(cfg, segmentedmri); >> >> % create head model >> cfg = []; >> cfg.method = 'openmeeg'; >> cfg.conductivity = [0.33 0.0041 0.33]; >> vol = ft_prepare_headmodel(cfg, bnd); >> >> figure; >> ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain >> figure; >> ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull >> figure; >> ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp >> >> Any help? >> >> Thanks. >> Kidist >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From mattmizumi at gmail.com Thu Nov 7 20:38:50 2013 From: mattmizumi at gmail.com (mattmizumi at gmail.com) Date: Thu, 07 Nov 2013 14:38:50 -0500 Subject: [FieldTrip] selecting which dimension to average over in ft_singleplotER Message-ID: <527BEC4A.5070401@gmail.com> A simple newbie question about ft_singleplotER: given a coherence spectrum, as follows, fd = labelcmb: {'vStr1' 'vStr2'} dimord: 'chan_freq_time' cohspctrm: [1x100x101 double] freq: [1x100 double] time: [1x101 double] dof: [1x100 double] cfg: [1x1 struct] how can I plot frequency against coherence? The default behavior of ft_singleplotER in this case is to average over frequency: cfg = []; cfg.parameter = 'cohspctrm'; cfg.refchannel = 'vStr2'; cfg.channel = 'vStr1'; ft_singleplotER(cfg, fd); selected 1 channels for cohspctrm selection cohspctrm along dimension 2 averaging cohspctrm over freq the call to "ft_singleplotER" took 0 seconds ..but I cannot find a way to get it to average over time instead. How can I do this? (Of course, I know I can plot this manually. But I would like to understand how to use the ft plotting functions. I can't find anything pertinent in the coherence and plotting tutorials, or the help for ft_singleplotER.) Thanks! -- Matt From s.caffarra at bcbl.eu Fri Nov 8 10:47:20 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Fri, 8 Nov 2013 10:47:20 +0100 (CET) Subject: [FieldTrip] help Message-ID: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu From jan.schoffelen at donders.ru.nl Fri Nov 8 11:08:56 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 8 Nov 2013 11:08:56 +0100 Subject: [FieldTrip] help In-Reply-To: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Fri Nov 8 11:14:31 2013 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Fri, 8 Nov 2013 11:14:31 +0100 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > > Hi Sendy, > > You may want to have a look at the following link: > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > I assume that your data has been passed through the MaxFilter, which > massively reduces the rank of your data, causing the ICA algorithm to spit > out complex valued numbers. > You need to reduce the rank of your data prior to running the component > decomposition, to be less that then true rank in your data. > > Best > Jan-Mathijs > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as > following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components > using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that > should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic > distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', > 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not > work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From polomacnenad at gmail.com Fri Nov 8 16:34:16 2013 From: polomacnenad at gmail.com (Nenad Polomac) Date: Fri, 8 Nov 2013 16:34:16 +0100 Subject: [FieldTrip] 'powandcsd' on short time window Message-ID: Dear Fieldtrip users, I have one problem and I hope that somebody has idea. For my source and connectivity analysis I need cross spectrum matrix at 40Hz and for time window of 50 ms(the effect is evoked gamma and it last less then 50 ms). The problem is that for this very narrow window the best I can get is the frequency resolution of 20Hz and that is far to low. I am trying now different padding options but it seems it doesn't help. If I band pass filter(35-45Hz) data before fft then result is as expected, but without filtering I pickup wide range of frequencies(probably from 20-60Hz) even if I specify cfg.foilim=[40 40]. Furthermore, all this stuff is included in my cross spectrum and brought into the further calculations. my code: cfg=[]; cfg.toilim = [0.03 0.08]; data_redef= ft_redefinetrial(cfg, data); cfg = []; cfg.trials = 'all'; cfg.keeptrials = 'no'; cfg.channel = 'MEG'; cfg.method = 'mtmfft'; cfg.output = 'powandcsd'; cfg.tapsmofrq = 1; cfg.foilim = [40 40]; cfg.taper = 'hanning'; cfg.pad =2; cfg.padtype='zero'; gamma = ft_freqanalysis(cfg, data_redef); Thank you in advance! Cheers, Nenad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.vanlier at bsse.ethz.ch Fri Nov 8 18:15:17 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 8 Nov 2013 17:15:17 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: I think I just had my aha-moment. Or actually more of a d'oh-moment. I was already wrong at step 0 which led to a whole cascade of thinking errors. I somehow thought that the t statistics were calculated per channel for a whole trial (so a single comparison) instead of every timepoint within a trial. every one of those t values that reaches a threshold is considered to be part of a cluster. then sum the t values within each cluster and get the maximum cluster stat. this is your observed statistic. now mix the trials and randomly assign them to subset1 and subset2. repeat the above to get another max cluster stat. do this many times (monte carlo) to create the permutation distribution of the max cluster stat. compare all the cluster stats you actually observed originally with your permutation distribution to find their p values. the FA rate is controlled because no other cluster will show a smaller p value than the max stat cluster and the chance on a type I error for the max cluster stat is alpha in "his own" distribution. not completely sure about that last sentence but i think its time for weekend now :) Thanks Eric Cheers, Ben From ben.vanlier at bsse.ethz.ch Fri Nov 8 18:23:09 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 8 Nov 2013 17:23:09 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: sorry, i am trying to reply to the previous posts but its not obvious. maybe "RE:" is capital sensitive? very irritating how there is no word wrap either, in my emails. From eelke.spaak at donders.ru.nl Sun Nov 10 01:11:04 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Sun, 10 Nov 2013 01:11:04 +0100 Subject: [FieldTrip] 'powandcsd' on short time window In-Reply-To: References: Message-ID: Dear Nenad, Unfortunately the limit to the frequency resolution is fundamental and not practical. It is impossible to get a better frequency resolution than 20 Hz with only 50ms of data. (It might help to think of this as analogous to Heisenberg's uncertainty principle in physics.) Why do you need a better frequency resolution? Perhaps there are alternatives to what you are trying. Best, Eelke On Nov 8, 2013 7:44 AM, "Nenad Polomac" wrote: > Dear Fieldtrip users, > > I have one problem and I hope that somebody has idea. For my source and > connectivity analysis I need cross spectrum matrix at 40Hz and for time > window of 50 ms(the effect is evoked gamma and it last less then 50 ms). > The problem is that for this very narrow window the best I can get is the > frequency resolution of 20Hz and that is far to low. I am trying now > different padding options but it seems it doesn't help. If I band pass > filter(35-45Hz) data before fft then result is as expected, but without > filtering I pickup wide range of frequencies(probably from 20-60Hz) even if > I specify cfg.foilim=[40 40]. Furthermore, all this stuff is included in my > cross spectrum and brought into the further calculations. > my code: > cfg=[]; > cfg.toilim = [0.03 0.08]; > data_redef= ft_redefinetrial(cfg, data); > > cfg = []; > cfg.trials = 'all'; > cfg.keeptrials = 'no'; > cfg.channel = 'MEG'; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd'; > cfg.tapsmofrq = 1; > cfg.foilim = [40 40]; > cfg.taper = 'hanning'; > cfg.pad =2; > cfg.padtype='zero'; > gamma = ft_freqanalysis(cfg, data_redef); > > Thank you in advance! > Cheers, > > Nenad > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Mon Nov 11 16:46:53 2013 From: mcantor at umich.edu (Max Cantor) Date: Mon, 11 Nov 2013 10:46:53 -0500 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com> wrote: > Hi Sendy, JM, > > In addition, that error also happens (or used to, at least) when you have > not selected MEG as channels, therefor applying ICA e.g. also on your EOG > channels etc. as well. > > Cheers, > Stephen > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> >> Hi Sendy, >> >> You may want to have a look at the following link: >> >> >> http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component >> >> I assume that your data has been passed through the MaxFilter, which >> massively reduces the rank of your data, causing the ICA algorithm to spit >> out complex valued numbers. >> You need to reduce the rank of your data prior to running the component >> decomposition, to be less that then true rank in your data. >> >> Best >> Jan-Mathijs >> >> On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: >> >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as >> following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components >> using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file >> that should be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic >> distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', >> 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not >> work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.caffarra at bcbl.eu Mon Nov 11 17:33:08 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Mon, 11 Nov 2013 17:33:08 +0100 (CET) Subject: [FieldTrip] help In-Reply-To: Message-ID: <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From pgoodin at swin.edu.au Tue Nov 12 04:41:57 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Tue, 12 Nov 2013 03:41:57 +0000 Subject: [FieldTrip] help In-Reply-To: <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, TL;DR - Use fastica. Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). Hope this helps, Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] Sent: Tuesday, 12 November 2013 3:33 AM To: FieldTrip discussion list Cc: FieldTrip discussion list Subject: Re: [FieldTrip] help Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 12 09:06:01 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 09:06:01 +0100 Subject: [FieldTrip] help In-Reply-To: References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Message-ID: <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> Dear all, As a comment to Peter's reply: the fastica code internally applies PCA to the data by removing all small signal components. In this respect runica does not behave differently if you specify cfg.runica.pca = 70 (provided that fastica estimates the number of components to retain is 70). Best, Jan-Mathijs On Nov 12, 2013, at 4:41 AM, Peter Goodin wrote: > Hi Sendy, > > TL;DR - Use fastica. > > Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). > > Hope this helps, > > Peter > > __________________________ > Peter Goodin, > BSc (Hons), Ph.D Candidate. > > Brain and Psychological Sciences Research Centre (BPsych) > Swinburne University, > Hawthorn, Vic, 3122 > > Monash Alfred Psychiatry Research Centre (MAPrc) > Level 4, 607 St Kilda Road, > Melbourne 3004 > > ________________________________________ > From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] > Sent: Tuesday, 12 November 2013 3:33 AM > To: FieldTrip discussion list > Cc: FieldTrip discussion list > Subject: Re: [FieldTrip] help > > Hi Fieldtrip users, > > I tried to select MEG as channels and I reduced the rank of my data, as following: > > cfg=[]; > cfg.runica.pca = 306; > cfg.channel = 'MEG'; > comp = ft_componentanalysis(cfg, data); > > ...but I still get the same error as before. > Are there any other reasons that could produce this error? > > Thanks in advance, > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > ----- Original Message ----- > From: "Max Cantor" > To: "FieldTrip discussion list" > Sent: Monday, November 11, 2013 4:46:53 PM > Subject: Re: [FieldTrip] help > > > > I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. > > > Thank you, > Max > > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: > > > > Hi Sendy, JM, > > > In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. > > > Cheers, > Stephen > > > > > > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: > > > > > > > Hi Sendy, > > > You may want to have a look at the following link: > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > > I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. > You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. > > > Best > Jan-Mathijs > > > > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgoodin at swin.edu.au Tue Nov 12 09:36:28 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Tue, 12 Nov 2013 08:36:28 +0000 Subject: [FieldTrip] help In-Reply-To: <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> , <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> Message-ID: Hi Jan-Mathijs, Very good to know, thank you! Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of jan-mathijs schoffelen [jan.schoffelen at donders.ru.nl] Sent: Tuesday, 12 November 2013 7:06 PM To: FieldTrip discussion list Subject: Re: [FieldTrip] help Dear all, As a comment to Peter's reply: the fastica code internally applies PCA to the data by removing all small signal components. In this respect runica does not behave differently if you specify cfg.runica.pca = 70 (provided that fastica estimates the number of components to retain is 70). Best, Jan-Mathijs On Nov 12, 2013, at 4:41 AM, Peter Goodin wrote: Hi Sendy, TL;DR - Use fastica. Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). Hope this helps, Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] Sent: Tuesday, 12 November 2013 3:33 AM To: FieldTrip discussion list Cc: FieldTrip discussion list Subject: Re: [FieldTrip] help Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 09:48:13 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 09:48:13 +0100 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> Hi Max, When you specify the channel to be left out, you have to name it according to how it's named in your data. I believe that the 'refchan' is only called like that for the purpose of the example. So, when you have a single reference channel, named 'thisisthenameofyourreferencechannel', you need to specify '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for exaggerating, but perhaps the silly name brings across the message more clearly. Note, that when you have applied a common average reference, you could at random remove a channel (not advisable). In that case I'd specify the dimensionality of your data space prior to calling ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG channels). Best, Jan-Mathijs On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: > I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. > > Thank you, > Max > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh wrote: > Hi Sendy, JM, > > In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. > > Cheers, > Stephen > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen wrote: > > Hi Sendy, > > You may want to have a look at the following link: > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. > You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. > > Best > Jan-Mathijs > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.caffarra at bcbl.eu Tue Nov 12 10:30:50 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Tue, 12 Nov 2013 10:30:50 +0100 (CET) Subject: [FieldTrip] help In-Reply-To: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> Message-ID: <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Thanks a lot. Now it works ;) Sendy ----- Original Message ----- From: "jan-mathijs schoffelen" To: "FieldTrip discussion list" Sent: Tuesday, November 12, 2013 9:48:13 AM Subject: Re: [FieldTrip] help Hi Max, When you specify the channel to be left out, you have to name it according to how it's named in your data. I believe that the 'refchan' is only called like that for the purpose of the example. So, when you have a single reference channel, named 'thisisthenameofyourreferencechannel', you need to specify '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for exaggerating, but perhaps the silly name brings across the message more clearly. Note, that when you have applied a common average reference, you could at random remove a channel (not advisable). In that case I'd specify the dimensionality of your data space prior to calling ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG channels). Best, Jan-Mathijs On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 12 10:53:17 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 10:53:17 +0100 Subject: [FieldTrip] selecting which dimension to average over in ft_singleplotER In-Reply-To: <527BEC4A.5070401@gmail.com> References: <527BEC4A.5070401@gmail.com> Message-ID: <03828B8D-5EBC-414F-9EAB-596C0C043EEF@donders.ru.nl> Hi Matt, In general, when dealing with time-frequency data, it is advisable to use ft_singleplotTFR, rather than ft_singleplotER. This will show the data both as a function of time and frequency. Interesting that ft_singleplotER works in the first place. If you want to visualize coherence as a function of frequency (i.e. collapsing across time) you can easily do this 'by hand': C = mean(fd.cohspctrm,3); figure;plot(fd.freq, C); Alternatively, you could use 'mtmfft' as a method for your spectral estimation, which yields frequency domain info without a time dimension. Once you have this, you can use ft_singleplotER (now it is ER confusingly) to visualize the data. Best, Jan-Mathijs On Nov 7, 2013, at 8:38 PM, mattmizumi at gmail.com wrote: > A simple newbie question about ft_singleplotER: given a coherence spectrum, as follows, > > fd = > > labelcmb: {'vStr1' 'vStr2'} > dimord: 'chan_freq_time' > cohspctrm: [1x100x101 double] > freq: [1x100 double] > time: [1x101 double] > dof: [1x100 double] > cfg: [1x1 struct] > > how can I plot frequency against coherence? The default behavior of ft_singleplotER in this case is to average over frequency: > > cfg = []; > cfg.parameter = 'cohspctrm'; > cfg.refchannel = 'vStr2'; > cfg.channel = 'vStr1'; > ft_singleplotER(cfg, fd); > > selected 1 channels for cohspctrm > selection cohspctrm along dimension 2 > averaging cohspctrm over freq > the call to "ft_singleplotER" took 0 seconds > > ..but I cannot find a way to get it to average over time instead. How can I do this? > > (Of course, I know I can plot this manually. But I would like to understand how to use the ft plotting functions. I can't find anything pertinent in the coherence and plotting tutorials, or the help for ft_singleplotER.) > > Thanks! > > -- Matt > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 10:58:42 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 10:58:42 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: <6625F8BF-815B-40B6-8F2C-6D4C68CB8675@donders.ru.nl> Hi Nicola, Would it make sense to look into the possibility to improve support for using the polhemus info from the .fif file directly? It sounds a bit silly that you have to go through another piece of software to be able to read in the data. From ft_read_headshape it seems that *.fif files are supported, could it be that your data is not recognized as such? Best, JM On Nov 6, 2013, at 11:52 AM, Nicola Molinaro wrote: > Thanks guys for any possible help. Really appreciate it! > > I will summarize my tests: > > 1. reading the COR-.fif produced by MRIlab with ft_read_mri > > Well, it seems that ft_read_mri reads the original (not coregistered) .fif file produced in earlier steps of the forward model calculation (COR.fif). For example, if I delete the COR.fif file, ft_read_mri gives an error. ft_read_mri applied to the COR-.fif should be able to read some header, and for this reason I tried the option suggested by Joram (including ft_volumereslice). However, when I plot the volume head model with > > hs=ft_read_headshape(.fif. 'unit','mm'); %get headshape points > ft_plot_vol(vol) > ft_plot_headshape(hs) > > There is an evident misalignment between isotrack points and the brain volume. I mean NO coregistration is done. you can also appreciate it when plotting a prearicular instead of the nasion with > > cfg = []; > cfg.location = [66.4 0 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > ft_sourceplot(cfg,mri); > > Take home message: Fieldtrip does not read the coregistration done in MRIlab, and you have to coregister MEG and MRI again. > > 2. Using > > cfg.method = 'headshape' > cfg.headshape = 'XXX.pos' > > for ft_volumerealign. I played with it, but in neuromag the polhemous data are within the header of the .fif file. You can export the isotrack point however from MRIlab. After importing then with > > File>Import>Isotrack data > > you can then export them with > > File>Export>Points > > and specifying the coordinate system in which you want your point (either Head, or MRI or Voxel). This file cannot be read by ft_volumerealign with the headshape method. However, the first three lines of the resulting .txt file will give you the nasion and the two pre-auricolar points positions. I tried importing the voxel positions of the three points in ft_volumerealign using the method > > cfg.coordsys = 'neuromag'; > cfg.method = 'fiducial'; > > And it worked, the brain volume is aligned with the isotrack points. This is the only solution that is visually reliable to perform > > > On Wed, Nov 6, 2013 at 10:06 AM, Joram van Driel wrote: > Hi Nicola, > > I also did coregistration in MRI-lab using isotrak data. > Importing the fif files in fieldtrip worked fine, I don’t think you have to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial ingredient. > This worked for me: > > mri = ft_read_mri(); %%% read the MRI; the fif file is in mm but FT changes it into meters > mri = ft_convert_units(mri,'mm'); %%% make it mm as it originally was > mri = ft_volumereslice([], mri); %%% after this function the ficual points in the MEG header match the coordinates in the MRI > > Then you should indeed check this with ft_sourceplot, where in the cfg you can fill in fiducial points to check if they make sense, e.g.: > > cfg = []; > cfg.location = [0 90.5 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > > ft_sourceplot(cfg,mri); > > Hope this helps. > Best, > Joram > > On 05 Nov 2013, at 09:43, jan-mathijs schoffelen wrote: > >> Dear Nicola, >> >> I am forwarding your question to the list, "ter lering ende vermaak": >> >> Begin forwarded message: >> >>> From: Nicola Molinaro >>> Date: November 4, 2013 2:16:20 PM GMT+01:00 >>> To: jan-mathijs schoffelen >>> Subject: mm -> voxels ?? >>> >>> Hi Jan, >>> I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? >>> I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). >>> >>> Thanks >>> >>> Nicola >> >> >> Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? >> To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. >> Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. >> I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). >> >> Best wishes, >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > -- > > ------------------------------ > Nicola Molinaro, Phd > Staff Scientist > www.bcbl.eu > > Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hanneke.vanDijk at med.uni-duesseldorf.de Tue Nov 12 11:28:33 2013 From: Hanneke.vanDijk at med.uni-duesseldorf.de (Hanneke.vanDijk at med.uni-duesseldorf.de) Date: Tue, 12 Nov 2013 10:28:33 +0000 Subject: [FieldTrip] [Fieldtrip] question about coregistration Message-ID: <495873C58A622E45A3ABF4813B9451EC6E3EF242@MAIL3-UKD.VMED.UKD> Hi Nicola and Jan-Mathijs, A simple solution can also be to save the points (the fiducials) that you have collected in MRIlab in 'voxel'. After we do the realignment with the polhemus data, we delete all points. We then create points at the final fiducial locations and export these. In this 'Export points' window you can select if you want to save them in head or voxel coordinates. The resulting .txt files can be read in matlab, and you can use them to realign the MRI in fieldtrip. Good luck! Thanks for the info as well, Jan-Mathijs! I didn't know about the two step solution in Fieldtrip, but will certainly give it a try! Groetjes Hanneke __________________________________________ Hanneke van Dijk, PhD http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html Institute for Clinical Neuroscience, Heinrich Heine Universität Düsseldorf, Germany Hanneke.vanDijk at med.uni-duesseldorf.de Tel. +49 (0) 211 81 13074 __________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 11:57:59 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 11:57:59 +0100 Subject: [FieldTrip] connectivity analysis In-Reply-To: References: Message-ID: <19A3518D-5E2A-452B-BA89-918B8FD18BC5@donders.ru.nl> Hi Bart, If you 7 frequency bins within each frequency bin are considered to belong to the same frequency band, I'd suggest to use the multitaper approach to estimate the spectral parameters per frequency band, using just a single frequency bin to represent the whole band of interest. So, rather than for example estimating from 15 until 21 Hz in steps of 1 Hz, you can also estimate only at 18, using cfg.tapsmofrq = 3 in ft_freqanalysis. I suggest to have a look at the documentation on the FT-wiki that is concerned with frequency analysis. I would certainly not average the spectral representation prior to computing the coherence, neither across the individual frequency bins, and even more certainly not across trials. Regarding statistics, I don't want to discourage you, but I don't think it makes sense to attempt doing statistics at the channel level to begin with, due to the effects of volume conduction. Also, in any group comparison (but also when doing a comparison across conditions), if there is any between groups in terms of SNR (e.g. more or less alpha power across groups) you are bound to find a statistically significant difference in estimated connectivity as well. It remains to be motivated in such a case, that the change in estimated connectivity actually reflects a change in true connectivity. If you want to do statistics irrespective of these caveats, you may want to look into FieldTrip's implementation of the non-parametric permutation testing framework. There is ample documentation about this on our wiki as well. Best wishes, Jan-Mathijs On Oct 30, 2013, at 1:22 PM, Bart Michiels wrote: > Hi, > > I have 30 patients and 30 controls and I'm investigating their coherence (EEG, 128 electrodes). Every patient has ~30 trials resting state eyes open consisting of 7 frequency bins with 7 frequencies in each bin. My goal is to show connectivity differences between different brain regions in the control and patient group (doing electrode-level analysis now, source-level analysis is next step). > > - Is it more appropriate to keep the averaging step as the latest step (ie. calculate all coherence for all the different subjects, for all trials, for all different frequencies in frequency bins) or is it better to do the averaging asap (ie. average all frequencies in 1 frequency bin at the time-frequency analysis step, average all trials at the ft_freqdescriptives step, ...) > > - Is there any better way to do some statistics on the 128x128x7x7 (128 electrodes, 7 frequency bins, 7 frequencies in each bin) besides using the ttest2() matlab function? > > Any tips & tricks are more then welcome! > > Bart > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 12:01:56 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 12:01:56 +0100 Subject: [FieldTrip] event related fields from source space In-Reply-To: References: Message-ID: <883F9839-5A9F-47C4-AC26-8B6C26C65060@donders.ru.nl> Dear Kaelasha, Yes indeed, the source.avg.mom contains per dipole location an estimate of the event-related field/potential in the x/y/z direction. You can reduce the dimensionality of these 3D time series by subsequently calling ft_sourcedescriptives with cfg.projectmom='yes'; Best, Jan-Mathijs On Oct 31, 2013, at 12:44 AM, Kaelasha Tyler wrote: > FieldTripers, > > I am wanting to reconstruct event related fields from source space and have been beamforming with ft_sourceanalysis using cfg.method='lcmv'. > > I have not been able to find any clear instructors on this, but can any one tell me, does ft_sourceanalysis output 'data.avg.mom' contain the averaged ERPs reconstructed in source space? > > data.avg.mom appears to be a column of cells, one cell for each point in my 3d grid, with each cell containing 3 time series (ERFs), one for each 3d orientation??, x, y, z? > > Can any one tell me if this is indeed what I am looking at in data.avg.mom? > > Regards, > Kaelasha Tyler > PhD candidate > Swinbunre University of Technology > Australia > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 12:05:52 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 12:05:52 +0100 Subject: [FieldTrip] visualize source localization data In-Reply-To: References: Message-ID: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> Hi Leo, Could you just do a simple plot to first get a feel of what the range of the data is, i.e. plot(source.time, source.avg.pow); This will inform you about sensible axis limits. Then, don't use a maskparameter for the time being (only a funparameter). Does this allow you to see the data in ft_sourcemovie? Best, Jan-Mathijs On Oct 29, 2013, at 10:30 AM, Leopold Zizlsperger wrote: > Dear all, > I have a question concerning source localization implementation. I need help in the very last step of visualizing a difference between 2 conditions over time: > > I get there by using the tutorial steps on single subject functional EEG data (fieldtrip-20130914; tried both WIN and MAC): > > clear all; > load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_rHFdemeanktkt.mat') > load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_lHFdemeanktkt.mat') > load leadfield; > load vol; > load elec_aligned; > > > cfg = []; > cfg.method = 'mne'; > cfg.elec = elec_aligned; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.mne.prewhiten = 'yes'; > cfg.mne.lambda = 3; > cfg.mne.scalesourcecov = 'yes'; > cfg.mne.normalize = 'yes'; > sourcerHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_rHFdemeanktkt); > sourcelHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_lHFdemeanktkt); > > save source sourcerHF sourcelHF; > > clear all; > > load source; > load sourcespace; > > bnd.pnt = sourcespace.pnt; > bnd.tri = sourcespace.tri; > m=sourcerHF.avg.pow(:,1200); > ft_plot_mesh(bnd, 'vertexcolor', m); > > > > > In ft_defaults at 74 > In ft_sourceanalysis at 146 > the input is timelock data with 32 channels and 7000 timebins > using headmodel specified in the configuration > using electrodes specified in the configuration > determining source compartment (3) > projecting electrodes on skin surface > combining electrode transfer and system matrix > creating dipole grid based on user specified dipole positions > using headmodel specified in the configuration > using gradiometers specified in the configuration > 8196 dipoles inside, 0 dipoles outside brain > the call to "ft_prepare_sourcemodel" took 0 seconds > estimating current density distribution for repetition 1 > using pre-computed leadfields: some of the specified options will not have an effect > computing the solution where the noise covariance is used for regularisation > prewhitening the leadfields using the noise covariance > scaling the source covariance > the call to "ft_sourceanalysis" took 10 seconds > the input is timelock data with 32 channels and 7000 timebins > using headmodel specified in the configuration > using electrodes specified in the configuration > determining source compartment (3) > projecting electrodes on skin surface > combining electrode transfer and system matrix > creating dipole grid based on user specified dipole positions > using headmodel specified in the configuration > using gradiometers specified in the configuration > 8196 dipoles inside, 0 dipoles outside brain > the call to "ft_prepare_sourcemodel" took 0 seconds > estimating current density distribution for repetition 1 > using pre-computed leadfields: some of the specified options will not have an effect > computing the solution where the noise covariance is used for regularisation > prewhitening the leadfields using the noise covariance > scaling the source covariance > the call to "ft_sourceanalysis" took 87 seconds > >> > > cfg = []; > cfg.projectmom = 'yes'; > sdrHF = ft_sourcedescriptives(cfg,sourcerHF); > sdlHF = ft_sourcedescriptives(cfg, sourcelHF); > > sdDIFF = sdrHF; > sdDIFF.avg.pow = sdrHF.avg.pow - sdlHF.avg.pow; > sdDIFF.tri = sourcespace.tri; > > save sd sdrHF sdlHF sdDIFF; > > Then I tried different suggestions from the tutorial or the mailing list: > > cfg = []; > cfg.mask = 'avg.pow'; > ft_sourcemovie(cfg,sdDIFF); > > the input is source data with 8196 positions > baseline correcting dipole moments [--------------------------------------\] > projecting dipole moment [------------------------------------------------/] > computing power [---------------------------------------------------------|] > the call to "ft_sourcedescriptives" took 32 seconds > the input is source data with 8196 positions > baseline correcting dipole moments [---------------------------------------] > projecting dipole moment [------------------------------------------------\] > computing power [----------------------------------------------------------] > the call to "ft_sourcedescriptives" took 33 seconds > the input is source data with 8196 vertex positions and 16384 triangles > Warning: use cfg.maskparameter instead of cfg.mask > > In ft_checkconfig at 120 > In ft_sourcemovie at 48 > ??? Error using ==> set > Bad property value found. > Object Name : axes > Property Name : 'CLim' > Values must be increasing and non-NaN. > > Error in ==> caxis at 80 > set(ax,'CLim',arg); > > Error in ==> ft_sourcemovie at 263 > caxis(cfg.zlim); > > > > If I set a break before this point I can see that "arg" indeed contains two NaNs only. > > Do you have any suggestions why the script above fails to determine the axes properties? > > Alternatively I tried: > > figure > sdDIFF.tri = sourcespace.tri; > cfg = []; > cfg.alim = [0 0.5]; > cfg.zlim = [0 0.5]; > cfg.maskparameter = 'avg.pow'; > ft_sourcemovie(cfg,sdDIFF); > > > That results in a GUI that does seem to work but in the time course there is no activity displayed. > > Any advice how to visualize the difference properly? > Thanks in advance. > Best > Leo > RWTH Aachen Neurology > > > P.S. > structure of the difference sdDIFF: > > time: [1x7000 double] > pos: [8196x3 double] > inside: [8196x1 double] > outside: [1x0 double] > method: 'average' > avg: [1x1 struct] > cfg: [1x1 struct] > tri: [16384x3 int32] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Tue Nov 12 14:51:49 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Tue, 12 Nov 2013 14:51:49 +0100 Subject: [FieldTrip] fieldtrip Digest, Vol 36, Issue 16 In-Reply-To: References: Message-ID: Dear Hanneke, this is exactly what I did, however, for better exploring the possibilities I also added an extra z point: lpa = [187.46 179.33 153.30]; nas = [127.59 147.10 244.07]; rpa = [ 69.76 185.61 147.85]; zpoint = [ 99.19 83.57 132.39]; and running ft_volumerealign with 'fiducials' everything calculated in voxel coordinates and since I was curiously biased by this webpage (outdated maybe but did not find anything updated): http://fieldtrip.fcdonders.nl/example/read_neuromag_mri_and_create_single-subject_grids_in_individual_head_space_that_are_all_aligned_in_mni_space I tried to switch a little bit the coordinates exchanging 'y' and 'x' (and it does not work) and exchanging lpa and rpa (I should have the zpoint that saves me anyway). When I plot all these points with the MEG channel's coordinates and the brain volume: vol = ft_convert_units(vol,'cm'); mri_real = ft_convert_units(mri_real,'cm'); hs=ft_read_headshape('.fif', 'unit','cm'); %get headshape points ft_plot_vol(vol) ft_plot_headshape(hs) hold plot3(hs.fid.pnt(:,1),hs.fid.pnt(:,2),hs.fid.pnt(:,3),'b+') plot3(DATA.grad.chanpos(:,1),DATA.grad.chanpos(:,2),DATA.grad.chanpos(:,3),'k*') everything seems perfect independently from switching lpa and rpa. However, after source reconstruction, when I interpolate cfg=[]; cfg.parameter='avg.pow'; inter_lcmv=ft_sourceinterpolate(cfg, lcmvdiff, mri_real); and plot my data cfg = []; cfg.method = 'slice'; cfg.coordsys = 'neuromag'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.funcolorlim = [4 10]; cfg.opacitylim = [4 10]; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg,inter_lcmv); everything changes (unpredictably) depending on the coordinates of the lpa and rpa. I suspect there is something about ft_sourceinterpolate and ft_sourceplot I don't control. Actually, I tried also doing fine-grained realignment also with the headshape points as suggested by Jan (pretty slow ft_volumerealign with method headshape and isotrack points read form a .fif file). A part that realignment was not really nice (maybe because we took many isotrack points along the nose), ft_sourceplot gave new different results... Now I am kind of lost. Nicola > Message: 1 > Date: Tue, 12 Nov 2013 10:28:33 +0000 > From: > To: > Subject: Re: [FieldTrip] [Fieldtrip] question about coregistration > Message-ID: > <495873C58A622E45A3ABF4813B9451EC6E3EF242 at MAIL3-UKD.VMED.UKD> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nicola and Jan-Mathijs, > > > A simple solution can also be to save the points (the fiducials) that you > have collected in MRIlab in 'voxel'. After we do the realignment with the > polhemus data, we delete all points. We then create points at the final > fiducial locations and export these. In this 'Export points' window you can > select if you want to save them in head or voxel coordinates. The resulting > .txt files can be read in matlab, and you can use them to realign the MRI > in fieldtrip. > > Good luck! > > Thanks for the info as well, Jan-Mathijs! I didn't know about the two step > solution in Fieldtrip, but will certainly give it a try! > > Groetjes Hanneke > > > __________________________________________ > > Hanneke van Dijk, PhD > > http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html > Institute for Clinical Neuroscience, > Heinrich Heine Universit?t D?sseldorf, Germany > Hanneke.vanDijk at med.uni-duesseldorf.de Hanneke.vanDijk at med.uni-duesseldorf.de> > Tel. +49 (0) 211 81 13074 > __________________________________________ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131112/b96925a5/attachment-0001.html > > > ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 12 15:11:34 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 12 Nov 2013 09:11:34 -0500 Subject: [FieldTrip] help In-Reply-To: <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> References: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Message-ID: Hi Jan-Mathijs, I had assumed that 'refchan' was a built in fieldtrip thing, that makes more sense now! However, I'm unsure of whether I am supposed to be removing the implicit reference, or the (in my case) linked mastoid references. I ran the data using the cfg.runica.pca = N-1 parameters (I did it as N-2 actually, for the linked mastoid references) as described in the fieldtrip FAQ, Peter, and you, but the data did come out a bit weird, and I would prefer ICA over PCA, so I'll definitely try this as well and see if I get results that make more sense to me. On Tue, Nov 12, 2013 at 4:30 AM, Sendy Caffarra wrote: > Thanks a lot. > Now it works ;) > > > Sendy > > ----- Original Message ----- > From: "jan-mathijs schoffelen" > To: "FieldTrip discussion list" > Sent: Tuesday, November 12, 2013 9:48:13 AM > Subject: Re: [FieldTrip] help > > > Hi Max, > > > When you specify the channel to be left out, you have to name it according > to how it's named in your data. I believe that the 'refchan' is only called > like that for the purpose of the example. > So, when you have a single reference channel, named > 'thisisthenameofyourreferencechannel', you need to specify > '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for > exaggerating, but perhaps the silly name brings across the message more > clearly. Note, that when you have applied a common average reference, you > could at random remove a channel (not advisable). In that case I'd specify > the dimensionality of your data space prior to calling > ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG > channels). > > > Best, > Jan-Mathijs > > > > On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: > > > > I'm having this issue as well, only with EEG data, and at resamplefs = > 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and > also set path for EEGlab toolbox, but the issue persists. Any help would be > greatly appreciated. > > > Thank you, > Max > > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < > stephen.whitmarsh at gmail.com > wrote: > > > > Hi Sendy, JM, > > > In addition, that error also happens (or used to, at least) when you have > not selected MEG as channels, therefor applying ICA e.g. also on your EOG > channels etc. as well. > > > Cheers, > Stephen > > > > > > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl > wrote: > > > > > > > Hi Sendy, > > > You may want to have a look at the following link: > > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > > I assume that your data has been passed through the MaxFilter, which > massively reduces the rank of your data, causing the ICA algorithm to spit > out complex valued numbers. > You need to reduce the rank of your data prior to running the component > decomposition, to be less that then true rank in your data. > > > Best > Jan-Mathijs > > > > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as > following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components > using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should > be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic > distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', > 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not > work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 15:59:54 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 15:59:54 +0100 Subject: [FieldTrip] coregistration question In-Reply-To: References: Message-ID: Ciao Nicola, What do you mean with 'everything changes (unpredictably) depending on the coordinates of the lpa and rpa.'? The interpolation of the source-reconstructed results and the visualization of the interpolated results will be wrong if the initial coregistration is wrong to begin with. But this should already show up as a strange topography in the source reconstructed data. JM > > > > > > > > Message: 1 > Date: Tue, 12 Nov 2013 10:28:33 +0000 > From: > To: > Subject: Re: [FieldTrip] [Fieldtrip] question about coregistration > Message-ID: > <495873C58A622E45A3ABF4813B9451EC6E3EF242 at MAIL3-UKD.VMED.UKD> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nicola and Jan-Mathijs, > > > A simple solution can also be to save the points (the fiducials) that you have collected in MRIlab in 'voxel'. After we do the realignment with the polhemus data, we delete all points. We then create points at the final fiducial locations and export these. In this 'Export points' window you can select if you want to save them in head or voxel coordinates. The resulting .txt files can be read in matlab, and you can use them to realign the MRI in fieldtrip. > > Good luck! > > Thanks for the info as well, Jan-Mathijs! I didn't know about the two step solution in Fieldtrip, but will certainly give it a try! > > Groetjes Hanneke > > > __________________________________________ > > Hanneke van Dijk, PhD > http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html > Institute for Clinical Neuroscience, > Heinrich Heine Universit?t D?sseldorf, Germany > Hanneke.vanDijk at med.uni-duesseldorf.de > Tel. +49 (0) 211 81 13074 > __________________________________________ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > Nicola Molinaro, Phd > Staff Scientist > www.bcbl.eu > > Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.trautmann-lengsfeld at uke.de Tue Nov 12 17:26:18 2013 From: s.trautmann-lengsfeld at uke.de (Dr. Sina A. Trautmann-Lengsfeld) Date: Tue, 12 Nov 2013 17:26:18 +0100 Subject: [FieldTrip] Announcing Symposium 2014 in Hamburg: Synaesthesia in Perspective: Development, Networks, and Multisensory Processing Message-ID: <528256AA.1070508@uke.de> *Synaesthesia in Perspective: Development, Networks, and* *Multisensory Processing* ** *Organizers*: Tessa M. van Leeuwen, Sina A. Trautmann-Lengsfeld, Peter König, Jianwei Zhang, Andreas K. Engel *Location*: Universitätsklinikum Hamburg-Eppendorf, Hamburg, Germany *Date*: February 28th - March 1st 2014 *Website and registration*: http://www.multisense.org/index.php/symposium-2014 Dear Fieldtriplist! We are pleased to announce our symposium on synaesthesia and multisensory processing from February 28th to March 1st 2014 in Hamburg. Synaesthesia is a fascinating phenomenon in which different senses are mixed: for synaesthetes, specific sensory stimuli automatically trigger additional perceptual experiences that are not normally perceived by non-synaesthetes. Studying synaesthesia is interesting by itself, allowing for exploration of the nature of conscious experiences. The aim of the planned symposium, however, is to put synaesthesia in perspective by also emphasizing the relevance of synaesthesia for other fields of study, such as multisensory processing, sensory substitution, development of sensory processing, and connectivity in sensory systems. Participation is free of charge but registration via the website is required. Participants are welcome to present a poster during one of the two poster sessions. We are looking forward to seeing you in Hamburg! * Confirmed speakers* Amir Amedi, /Jerusalem, Israel / Andreas Engel, /Hamburg, Germany / Anil Seth, /Brighton, United Kingdom/ Brigitte Röder, /Hamburg, Germany / Charles Spence, /Oxford, United Kingdom/ Christoph Kayser, /Glasgow, United Kingdom / Christopher Sinke, /Hamburg, Germany/ Danko Nikolic, /Frankfurt am Main, Germany / David Brang, /Chicago, USA/ Devin Blair Terhune, /Oxford, United Kingdom/ Jamie Ward, /Brighton, United Kingdom/ Jianwei Zhang, /Hamburg, Germany/ Julia Simner, /Edinburgh, United Kingdom/ Ladan Shams, /Los Angeles, USA/ Micah Murray, /Lausanne, Switzerland / Nicolas Rothen, /Brighton, United Kingdom/ Olympia Colizoli/, Amsterdam, the Netherlands / Peter König, /Osnabru?ck, Germany / Petra Stoerig, /Du?sseldorf, Germany/ Roi Cohen Kadosh, /Oxford, United Kingdom / Romke Rouw, /Amsterdam, the Netherlands/ Sina A. Trautmann-Lengsfeld, /Hamburg, Germany/ Tessa van Leeuwen/, Frankfurt am Main, Germany/ Virginie van Wassenhove, /Paris, France/ -- Dr. Sina Alexa Trautmann-Lengsfeld Postdoc Dept. of Neurophysiology and Pathophysiology University Medical Center Hamburg-Eppendorf Martinistr. 52 20246 Hamburg Germany Phone: +49-40-7410-57238 Fax: +49-40-7410-57752 Email: s.trautmann-lengsfeld at uke.de -- Besuchen Sie uns auf: www.uke.de _____________________________________________________________________ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik _____________________________________________________________________ SAVE PAPER - THINK BEFORE PRINTING -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Tue Nov 12 17:48:36 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Tue, 12 Nov 2013 17:48:36 +0100 Subject: [FieldTrip] coregistration question Message-ID: Hi Jan-Mathijs, everything started from the fact that I tried to source reconstruct a M1 ERF visual response as a test. The effect at the source level was clearly posterior in the MEG sensors. However, the source reconstruction gave me a solution with its maximum in the orbitofrontal regions of the brain. This result emerged when I employed the "correct fiducials" extracted from the Neuromag software. I thought that maybe I had to flip some landmarks to have the effect on the back of the brain. That's why I switched rpa and lpa, with however a more sparse solution. I suspect that grid, isotrack points and MEG channels are ok (when I plot them together in Matlab they are well aligned). Somehow, when I interpolate the power with the realigned brain something goes wrong, and the ft_sourceplot (the one of my previous e-mail) give me the results I described above. I also have to admit that ft_sourceplot in 'neuromag' coordinates shows the brain upside-down. N -- ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 12 19:13:25 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 12 Nov 2013 13:13:25 -0500 Subject: [FieldTrip] help In-Reply-To: References: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Message-ID: So we decided to remove both linked mastoid references for the ICA, and it works just fine now. Thank you so much! On Tue, Nov 12, 2013 at 9:11 AM, Max Cantor wrote: > Hi Jan-Mathijs, > > I had assumed that 'refchan' was a built in fieldtrip thing, that makes > more sense now! However, I'm unsure of whether I am supposed to be removing > the implicit reference, or the (in my case) linked mastoid references. I > ran the data using the cfg.runica.pca = N-1 parameters (I did it as N-2 > actually, for the linked mastoid references) as described in the fieldtrip > FAQ, Peter, and you, but the data did come out a bit weird, and I would > prefer ICA over PCA, so I'll definitely try this as well and see if I get > results that make more sense to me. > > > On Tue, Nov 12, 2013 at 4:30 AM, Sendy Caffarra wrote: > >> Thanks a lot. >> Now it works ;) >> >> >> Sendy >> >> ----- Original Message ----- >> From: "jan-mathijs schoffelen" >> To: "FieldTrip discussion list" >> Sent: Tuesday, November 12, 2013 9:48:13 AM >> Subject: Re: [FieldTrip] help >> >> >> Hi Max, >> >> >> When you specify the channel to be left out, you have to name it >> according to how it's named in your data. I believe that the 'refchan' is >> only called like that for the purpose of the example. >> So, when you have a single reference channel, named >> 'thisisthenameofyourreferencechannel', you need to specify >> '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for >> exaggerating, but perhaps the silly name brings across the message more >> clearly. Note, that when you have applied a common average reference, you >> could at random remove a channel (not advisable). In that case I'd specify >> the dimensionality of your data space prior to calling >> ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG >> channels). >> >> >> Best, >> Jan-Mathijs >> >> >> >> On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: >> >> >> >> I'm having this issue as well, only with EEG data, and at resamplefs = >> 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and >> also set path for EEGlab toolbox, but the issue persists. Any help would be >> greatly appreciated. >> >> >> Thank you, >> Max >> >> >> >> On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < >> stephen.whitmarsh at gmail.com > wrote: >> >> >> >> Hi Sendy, JM, >> >> >> In addition, that error also happens (or used to, at least) when you have >> not selected MEG as channels, therefor applying ICA e.g. also on your EOG >> channels etc. as well. >> >> >> Cheers, >> Stephen >> >> >> >> >> >> >> >> >> >> On 8 November 2013 11:08, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl > wrote: >> >> >> >> >> >> >> Hi Sendy, >> >> >> You may want to have a look at the following link: >> >> >> >> http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component >> >> >> I assume that your data has been passed through the MaxFilter, which >> massively reduces the rank of your data, causing the ICA algorithm to spit >> out complex valued numbers. >> You need to reduce the rank of your data prior to running the component >> decomposition, to be less that then true rank in your data. >> >> >> Best >> Jan-Mathijs >> >> >> >> >> On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: >> >> >> >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as >> following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components >> using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should >> be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic >> distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', >> 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not >> work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> >> >> >> >> >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> >> >> >> >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajatthomas at gmail.com Wed Nov 13 01:25:55 2013 From: rajatthomas at gmail.com (Rajat Thomas) Date: Wed, 13 Nov 2013 01:25:55 +0100 Subject: [FieldTrip] Plotting network arrows Message-ID: Dear all, Can FT do the following: I get a bunch of connected nodes (channels, sources whatever) and their connection strength. If there any way of plotting like curved arrows from node to the other (with varying thickness to reflect strength) ? Thanks. Rajat -- Rajat Mani Thomas Netherlands Institute for Neuroscience Amsterdam, The Netherlands http://www.cita.utoronto.ca/~thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.trautmann-lengsfeld at uke.de Wed Nov 13 13:03:10 2013 From: s.trautmann-lengsfeld at uke.de (Dr. Sina A. Trautmann-Lengsfeld) Date: Wed, 13 Nov 2013 13:03:10 +0100 Subject: [FieldTrip] Announcing Symposium 2014 in Hamburg: Synaesthesia in Perspective: Development, Networks, and Multisensory Processing In-Reply-To: <528256AA.1070508@uke.de> References: <528256AA.1070508@uke.de> Message-ID: <52836A7E.50409@uke.de> Dear Fieldtriplist, unfortunately, the link of our symposium website did not work in some cases. I apologize for that. Here is the corrected link and the announcement one more time. www.multisense.org/index.php/symposium-2014 > *Synaesthesia in Perspective: Development, Networks, and* > > *Multisensory Processing* > > ** > > *Organizers*: Tessa M. van Leeuwen, Sina A. Trautmann-Lengsfeld, > > Peter König, Jianwei Zhang, Andreas K. Engel > > *Location*: Universitätsklinikum Hamburg-Eppendorf, Hamburg, Germany > > *Date*: February 28th - March 1st 2014 > > *Website and registration*: > www.multisense.org/index.php/symposium-2014 > > > Dear Fieldtriplist! > > We are pleased to announce our symposium on synaesthesia and > multisensory processing from February 28th to March 1st 2014 in Hamburg. > > > Synaesthesia is a fascinating phenomenon in which different senses are > mixed: for synaesthetes, specific sensory stimuli automatically > trigger additional perceptual experiences that are not normally > perceived by non-synaesthetes. > > > Studying synaesthesia is interesting by itself, allowing for > exploration of the nature of conscious experiences. The aim of the > planned symposium, however, is to put synaesthesia in perspective by > also emphasizing the relevance of synaesthesia for other fields of > study, such as multisensory processing, sensory substitution, > development of sensory processing, and connectivity in sensory > systems. Participation is free of charge but registration via the > website is required. Participants are welcome to present a poster > during one of the two poster sessions. We are looking forward to > seeing you in Hamburg! > > * > Confirmed speakers* > > Amir Amedi, /Jerusalem, Israel / > > Andreas Engel, /Hamburg, Germany / > > Anil Seth, /Brighton, United Kingdom/ > > Brigitte Röder, /Hamburg, Germany / > > Charles Spence, /Oxford, United Kingdom/ > > Christoph Kayser, /Glasgow, United Kingdom / > > Christopher Sinke, /Hamburg, Germany/ > > Danko Nikolic, /Frankfurt am Main, Germany / > > David Brang, /Chicago, USA/ > > Devin Blair Terhune, /Oxford, United Kingdom/ > > Jamie Ward, /Brighton, United Kingdom/ > > Jianwei Zhang, /Hamburg, Germany/ > > Julia Simner, /Edinburgh, United Kingdom/ > > Ladan Shams, /Los Angeles, USA/ > > Micah Murray, /Lausanne, Switzerland / > > Nicolas Rothen, /Brighton, United Kingdom/ > > Olympia Colizoli/, Amsterdam, the Netherlands / > > Peter König, /Osnabru?ck, Germany / > > Petra Stoerig, /Du?sseldorf, Germany/ > > Roi Cohen Kadosh, /Oxford, United Kingdom / > > Romke Rouw, /Amsterdam, the Netherlands/ > > Sina A. Trautmann-Lengsfeld, /Hamburg, Germany/ > > Tessa van Leeuwen/, Frankfurt am Main, Germany/ > > Virginie van Wassenhove, /Paris, France/ > > -- > Dr. Sina Alexa Trautmann-Lengsfeld > Postdoc > Dept. of Neurophysiology and Pathophysiology > University Medical Center Hamburg-Eppendorf > Martinistr. 52 > 20246 Hamburg > Germany > Phone: +49-40-7410-57238 > Fax: +49-40-7410-57752 > Email:s.trautmann-lengsfeld at uke.de > > Besuchen Sie uns auf: www.uke.de > > ------------------------------------------------------------------------ > > Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen > Rechts; Gerichtsstand: Hamburg > Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. > Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik > > ------------------------------------------------------------------------ > > SAVE PAPER - THINK BEFORE PRINTING > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Dr. Sina Alexa Trautmann-Lengsfeld Postdoc Dept. of Neurophysiology and Pathophysiology University Medical Center Hamburg-Eppendorf Martinistr. 52 20246 Hamburg Germany Phone: +49-40-7410-57238 Fax: +49-40-7410-57752 Email: s.trautmann-lengsfeld at uke.de -- Besuchen Sie uns auf: www.uke.de _____________________________________________________________________ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik _____________________________________________________________________ SAVE PAPER - THINK BEFORE PRINTING -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony.passaro at gmail.com Wed Nov 13 17:40:20 2013 From: antony.passaro at gmail.com (Antony Passaro) Date: Wed, 13 Nov 2013 11:40:20 -0500 Subject: [FieldTrip] Plotting network arrows In-Reply-To: References: Message-ID: Hi Rajat, The intended Fieldtrip function for plotting connected nodes as you describe it is ft_topoplotCC: http://fieldtrip.fcdonders.nl/reference/ft_topoplotcc Best of luck, -Tony On Tue, Nov 12, 2013 at 7:25 PM, Rajat Thomas wrote: > Dear all, > > Can FT do the following: > > I get a bunch of connected nodes (channels, sources whatever) and their > connection strength. > > If there any way of plotting like curved arrows from node to the other > (with varying thickness to reflect strength) ? > > Thanks. > > Rajat > > -- > Rajat Mani Thomas > Netherlands Institute for Neuroscience > Amsterdam, The Netherlands > http://www.cita.utoronto.ca/~thomas > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Wed Nov 13 18:53:15 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Wed, 13 Nov 2013 18:53:15 +0100 Subject: [FieldTrip] Pre-processing on orthogonal planar gradiometers? Message-ID: Dear FieldTrip users. I want to detect and remove EOG and ECG by using ICA. My data is from a Neuromag 306 MEG scanner with magnetometers and two orthogonal planar gradiometers. I assume that it is recommendable to do the ICA separately on each sensor type separately, i.e. on 1. magnetomers, 2. horizontal planar gradiometers, and then 3. vertical planar gradiometers, because they measure magnetic field changes at different scales and in different directions. Would you recommend to do ICA and other pre-processing steps separately on the horizontal and vertical planar gradiometers, or would you just combine the planar gradiometers with ft_combineplanar immediately? I'm worried that combining the two different gradiometer sensor types would violate underlying assumptions of the pre-processing algorithms, i.e. ICA, filters and baseline correction, because the planar gradiometer values are only positive valued estimates from the combinations of the original gradiometer measures, which do not seem to have oscillatory deflections around a baseline zero valued point. Hope you can help. Greetings Niels. Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcgoiv0 at wfu.edu Wed Nov 13 19:49:34 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Wed, 13 Nov 2013 13:49:34 -0500 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data Message-ID: Hello everybody, I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the ft_timelockanalysis(cfg, data) function? I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. Another way to ask this question is: what is the format/structure of the second input (timelock) in the ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? Thanks, Inna -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Nov 14 09:02:17 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 14 Nov 2013 09:02:17 +0100 Subject: [FieldTrip] Pre-processing on orthogonal planar gradiometers? In-Reply-To: References: Message-ID: Hi Niels, It's perfectly fine to do the ICA etc on the horizontal and vertical planar gradients together. The reason being that the topographies of the artifacts cause (just like the neural sources) gradient fields with arbitrary orientation in 3D space, for which you need both the horizontal and vertical gradient channels to optimally capture this. For that matter it is even better to use them both in the same ICA step. It's absolutely forbidden to first do combineplanar and then try to do ICA on the combined data, because after the combination step (which is non-linear) the linear mixing assumption cannot be made anymore. Combining with the magnetometers would in principle be possible (differences in magnitude are addressed by the prewhitening step in most ICA algorithms), but I don't know how common this is in the field. Perhaps other people could comment on this. Best wishes, Jan-Mathijs On Nov 13, 2013, at 6:53 PM, Niels Trusbak Haumann wrote: > Dear FieldTrip users. > > I want to detect and remove EOG and ECG by using ICA. My data is from a Neuromag 306 MEG scanner with magnetometers and two orthogonal planar gradiometers. > > I assume that it is recommendable to do the ICA separately on each sensor type separately, i.e. on 1. magnetomers, 2. horizontal planar gradiometers, and then 3. vertical planar gradiometers, because they measure magnetic field changes at different scales and in different directions. > > Would you recommend to do ICA and other pre-processing steps separately on the horizontal and vertical planar gradiometers, or would you just combine the planar gradiometers with ft_combineplanarimmediately? > > I'm worried that combining the two different gradiometer sensor types would violate underlying assumptions of the pre-processing algorithms, i.e. ICA, filters and baseline correction, because the planar gradiometer values are only positive valued estimates from the combinations of the original gradiometer measures, which do not seem to have oscillatory deflections around a baseline zero valued point. > > Hope you can help. > > Greetings > Niels. > > Niels Trusbak Haumann > M.A. / PhD student > Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience > Aarhus University / Aarhus University Hospital > E-mail: aestnth at hum.au.dk > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From schuessler at cbs.mpg.de Thu Nov 14 09:41:42 2013 From: schuessler at cbs.mpg.de (Ellen Schuessler) Date: Thu, 14 Nov 2013 09:41:42 +0100 (CET) Subject: [FieldTrip] Append/Average same conditions over sessions In-Reply-To: <777653177.992.1384417995707.JavaMail.root@zimbra> Message-ID: <1301619942.1071.1384418502084.JavaMail.root@zimbra> Dear all, Here a short description of the issue: My data was conducted in 2 sessions (a week in between), both sessions contain all conditions (e.g. A B C D). For each session I will have a bit more than 400 trials to run ICA on. After ICA and after I redefine trials I will have separate files per condition (trials x time) for each session. Then, I want to concatenate conditions over sessions. That is, condition A session 2 should be appended to condition A of session 1 before I average. Now here is my question: I understand that ft_appenddata is mainly used to append different conditions. Additionally I read that files of different days might confuse in the sampleinfo (cf. http://fieldtrip.fcdonders.nl/faq/i_used_to_work_with_trl-matrices_that_have_more_than_3_columns._why_is_this_not_supported_anymore - middle part of the text). This might be true in may case as well? If not, can I just add the two matrices (sessions) horizontally (which sounds a bit too simple in my ears)? Anyway, what would be the best way to average my conditions over sessions and at which operational step? Thank you all very much in advance! If you have any further question please do not hesitate to contact me! Your help is very much appreciated. Ellen -- Ellen Schüßler, Dipl.-Psych. PhD Student Max Planck Institute for Human Cognitive and Brain Sciences Research Group "Subcortical Contributions to Comprehension" Department of Neuropsychology Stephanstraße 1a D-04103 Leipzig Germany Phone: +49 (0) 341 / 99 40 - 2474 Fax: +49 (0) 341 / 99 40 - 2260 Email: schuessler at cbs.mpg.de Web: www.cbs.mpg.de/~schuessler From Lilla.Magyari at mpi.nl Thu Nov 14 12:23:24 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 14 Nov 2013 12:23:24 +0100 (CET) Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> Message-ID: <62505.131.174.46.51.1384428204.squirrel@131.174.46.51> Hi Kidist, Have you checked if the segmentation is OK? The segmentation for a BEM model should contain binary masks of the brain, skull and skin tissues. But these tissues should not overlap and they should form a closed shape without empty space between. One way to check this, if you plot the different tissue-types in the same image. For this, you can convert your binary segmentation to an indexed type segmentation. Here is a FAQ which explains how to do that: http://fieldtrip.fcdonders.nl/faq/how_is_the_segmentation_defined#conversion_between_probabilistic_and_indexed_representations Best, Lilla > Hi Lilla, > > Thank you for your reply. > > The openmeeg works well for the mri (subject01.mri) that is used in the > fieldtrip tutorial. > > But the error comes when I use my subject's mri whose anatomy is > 256*256*192. I have also tried to use mri = ft_volumereslice(cfg,mri) > thinking that the error might be due to the inequality of the size of the > anatomical volume into each direction. > > Kidist > > >> hi Kidist, >> >> I am wondering if you have installed openmeeg properly. Here is a site >> to >> explain it: >> http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling >> >> Have you followed this? >> >> Lilla >> >> >> >>> Hi, >>> >>> I am working with the combined EEG and MEG recording and would like to >>> do >>> the forward model for the EEG. >>> >>> So I was trying to use the 'bemcp' and 'openmeeg' as am working on >>> windows >>> platform. I have the anatomy of my subject (DICOM file stacked and >>> cleaned >>> using SPM). >>> >>> When I try to use openmeeg, vol.mat is missing from the vol structure >>> giving an error message om_minverser.exe doesn't function anymore. >>> >>> When I try to use 'bemcp', vol.mat contains all NaNs which resulted >>> from >>> the c12 and c21 matrices being not a square matrix which makes the >>> inverse >>> to be non-existent and also those matrices consists a large number of >>> 'Inf' entries. >>> >>> Like it was mentioned on one of the forums, the error might come when >>> the >>> meshes are generated. I was able to find the index of the vertices from >>> the Cij matrix, but I couldn't find the actual relation to the >>> vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either >>> brain, >>> skull or scalp. >>> >>> Here are all the steps that I have followed. >>> >>> % reading MRI >>> mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); >>> >>> % segment the brain >>> cfg = []; >>> cfg.output = {'brain', 'skull', 'scalp'}; >>> cfg.coordsys = ''; % here I use the RAS coordsys and for the origin >>> 'i'- >>> interauricular >>> segmentedmri = ft_volumesegment(cfg, mri); >>> segmentedmri.anatomy = mri.anatomy; >>> >>> % prepare mesh >>> cfg = []; >>> cfg.tissue = {'brain','skull', 'scalp'}; >>> cfg.numvertices = [3000 2000 1000]; >>> cfg.transform = segmentedmri.transform; >>> bnd = ft_prepare_mesh(cfg, segmentedmri); >>> >>> % create head model >>> cfg = []; >>> cfg.method = 'openmeeg'; >>> cfg.conductivity = [0.33 0.0041 0.33]; >>> vol = ft_prepare_headmodel(cfg, bnd); >>> >>> figure; >>> ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain >>> figure; >>> ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull >>> figure; >>> ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp >>> >>> Any help? >>> >>> Thanks. >>> Kidist >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From ggonesc at upo.es Fri Nov 15 11:26:52 2013 From: ggonesc at upo.es (Gabriel Gonzalez Escamilla) Date: Fri, 15 Nov 2013 11:26:52 +0100 Subject: [FieldTrip] problem with comparecorr Message-ID: <4ac7c1744427c47.528604fc@upo.es> Dear FildTrip experts, We have two groups and we are performing within group correlations with ft_sourcestatistics using cfg.method='montecarlo';cfg.statistic='corrcoef'; cfg.measure='stat'; cfg.correctm='cluster'; cfg.clusterstatistic='maxsum'; everything looks good on the analysis of every group. We've got negative correlation in GP1, and no correlation in GP2. Then we are performing between-group correlations to compare the regression lines by using cfg.method='montecarlo'; cfg.statistic='comparecorr'; cfg.measure='stat'; cfg.correctm='cluster'; cfg.clusterstatistic='maxsum' on ft_sourcestatistics. for which we are getting a difference between the correlations of the groups (GP1 Vs GP2, as input to ft_sourcestatistics a grandavg matrix containing firstly the subjects on GP1 followed by the subjects of the GP2). This seems to be ok when we perform the between correlation of GP1 Vs GP2, but then we invert the matrix to perform GP2 Vs GP1 (we have checked that the second matrix has the subjects in the correct order, all subjects of the GP2 now followed by subjects of GP1), which should result in the same results as GP1 Vs GP2 but with opposite direction; but instead of showing this, it shows no results. We have perform 1000 and 2000 montecarlo (MC)-permutations to ensure that this results are not biased by little MC-permutations, but every time we get, that in the first direction we get results, but in the inverse direction we never get any results. Is this somehow normal? Can anyone give us so guidence on this? Many thanks in advanced, Gabriel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Fri Nov 15 17:40:04 2013 From: mcantor at umich.edu (Max Cantor) Date: Fri, 15 Nov 2013 11:40:04 -0500 Subject: [FieldTrip] ft_channelrepair not finding electrodes Message-ID: Hi all, I'm trying to perform channel repair on EEG data that has undergone jump, muscle, and visual artifact rejection, and ICA to remove eog and ecg components, unmixed back into the original channels. It's a 61 channel system using a modified easycap layout and neighbours template. The layout has been shown to work on topographic displays, and the template seems to work in that it creates a neighbours object when ft_prepare_neighbours is run on it without any errors. However, I'm getting an error when I attempt to run ft_channelrepair: Error using ft_fetch_sens (line 179) no electrodes or gradiometers specified. Error in ft_channelrepair (line 112) sens = ft_fetch_sens(cfg, data); I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not really sure what elec/sens file I should be reading or how to go about creating it. I was hoping that the template, my data, and/or the layout would contain the necessary information, but given the error on ft_fetch_sens, that doesn't seem to be the case. Any help on this issue would be greatly appreciated. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Sat Nov 16 15:31:52 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Sat, 16 Nov 2013 15:31:52 +0100 Subject: [FieldTrip] failed segmentation Message-ID: <528781D8.1030107@gmail.com> Hi all, has anyone ever had a failed segmentation that looks like the one in the figure? My script works for all participants, I mean, for all other participants the brain is only inside the skull :) But it fails terribly for this one. I thought it could have to do with the placement of the fiducials, and I've played around a bit with that but it didn't solve the problem. If anyone recognises this type of error, I'd be help to hear if/how it can be fixed. Thanks a lot, Vitória -------------- next part -------------- A non-text attachment was scrubbed... Name: segmentation.png Type: image/png Size: 138624 bytes Desc: not available URL: From michelic72 at gmail.com Sat Nov 16 20:18:13 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Sat, 16 Nov 2013 14:18:13 -0500 Subject: [FieldTrip] failed segmentation In-Reply-To: <528781D8.1030107@gmail.com> References: <528781D8.1030107@gmail.com> Message-ID: Hi Vitoria, it looks like there is an artifact on the top of the head. It happened to me already and I had to preprocess the mri volume by using an appropriate cutoff and by thresholding (after plotting the histogram of the grey levels). mri.anatomy = (mri.anatomy>thr).*mri.anatomy; or mri.anatomy(:,:,230:256) = 0; If thresholding is still not effective you might consider applying morphological operators (erode, dilate, open, close), after taking care that you voxel dimensions are cubic (diagonal values of the canonic form of mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. I hope this helps, Cristiano On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai wrote: > Hi all, > > has anyone ever had a failed segmentation that looks like the one in the > figure? > My script works for all participants, I mean, for all other participants > the brain is only inside the skull :) > But it fails terribly for this one. I thought it could have to do with the > placement of the fiducials, and I've played around a bit with that but it > didn't solve the problem. > If anyone recognises this type of error, I'd be help to hear if/how it can > be fixed. > > Thanks a lot, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lilla.Magyari at mpi.nl Sun Nov 17 12:03:15 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Sun, 17 Nov 2013 12:03:15 +0100 (CET) Subject: [FieldTrip] failed segmentation In-Reply-To: References: <528781D8.1030107@gmail.com> Message-ID: <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> hi Vitoria, is this a tpm (the default output of ft_volumesegment)? Have you also tried to segment this mri with an output for 'brain','skull','scalp'? because when you have a binary representation for these tissue-types, they do not overlap, and are closed. So, I am wondering if you end up with a brainmask which do not contain the artifact at the top of the head. Lilla > Hi Vitoria, > it looks like there is an artifact on the top of the head. It happened to > me already and I had to preprocess the mri volume by using an appropriate > cutoff and by thresholding (after plotting the histogram of the grey > levels). > > mri.anatomy = (mri.anatomy>thr).*mri.anatomy; > > or > > mri.anatomy(:,:,230:256) = 0; > > If thresholding is still not effective you might consider applying > morphological operators (erode, dilate, open, close), after taking care > that you voxel dimensions are cubic (diagonal values of the canonic form > of > mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. > > I hope this helps, > Cristiano > > > > On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai > wrote: > >> Hi all, >> >> has anyone ever had a failed segmentation that looks like the one in the >> figure? >> My script works for all participants, I mean, for all other participants >> the brain is only inside the skull :) >> But it fails terribly for this one. I thought it could have to do with >> the >> placement of the fiducials, and I've played around a bit with that but >> it >> didn't solve the problem. >> If anyone recognises this type of error, I'd be help to hear if/how it >> can >> be fixed. >> >> Thanks a lot, Vitória >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From zizlsperger at gmail.com Sun Nov 17 12:26:42 2013 From: zizlsperger at gmail.com (Zizlsperger Leopold) Date: Sun, 17 Nov 2013 12:26:42 +0100 Subject: [FieldTrip] visualize source localization data In-Reply-To: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> References: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> Message-ID: Hello Jan-Mathijs, thanks, you made my day ! Using funparameter instead of maskparameter and rescaling the plot worked fine, now I can see the data in ft_sourcemovie. All the best Leo On Nov 12, 2013, at 12:05 PM, jan-mathijs schoffelen wrote: > Hi Leo, > > Could you just do a simple plot to first get a feel of what the range of the data is, i.e. plot(source.time, source.avg.pow); > > This will inform you about sensible axis limits. Then, don't use a maskparameter for the time being (only a funparameter). > > Does this allow you to see the data in ft_sourcemovie? > > Best, > Jan-Mathijs > > > > > On Oct 29, 2013, at 10:30 AM, Leopold Zizlsperger wrote: > >> Dear all, >> I have a question concerning source localization implementation. I need help in the very last step of visualizing a difference between 2 conditions over time: >> >> I get there by using the tutorial steps on single subject functional EEG data (fieldtrip-20130914; tried both WIN and MAC): >> >> clear all; >> load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_rHFdemeanktkt.mat') >> load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_lHFdemeanktkt.mat') >> load leadfield; >> load vol; >> load elec_aligned; >> >> >> cfg = []; >> cfg.method = 'mne'; >> cfg.elec = elec_aligned; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.mne.prewhiten = 'yes'; >> cfg.mne.lambda = 3; >> cfg.mne.scalesourcecov = 'yes'; >> cfg.mne.normalize = 'yes'; >> sourcerHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_rHFdemeanktkt); >> sourcelHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_lHFdemeanktkt); >> >> save source sourcerHF sourcelHF; >> >> clear all; >> >> load source; >> load sourcespace; >> >> bnd.pnt = sourcespace.pnt; >> bnd.tri = sourcespace.tri; >> m=sourcerHF.avg.pow(:,1200); >> ft_plot_mesh(bnd, 'vertexcolor', m); >> >> >> >> > In ft_defaults at 74 >> In ft_sourceanalysis at 146 >> the input is timelock data with 32 channels and 7000 timebins >> using headmodel specified in the configuration >> using electrodes specified in the configuration >> determining source compartment (3) >> projecting electrodes on skin surface >> combining electrode transfer and system matrix >> creating dipole grid based on user specified dipole positions >> using headmodel specified in the configuration >> using gradiometers specified in the configuration >> 8196 dipoles inside, 0 dipoles outside brain >> the call to "ft_prepare_sourcemodel" took 0 seconds >> estimating current density distribution for repetition 1 >> using pre-computed leadfields: some of the specified options will not have an effect >> computing the solution where the noise covariance is used for regularisation >> prewhitening the leadfields using the noise covariance >> scaling the source covariance >> the call to "ft_sourceanalysis" took 10 seconds >> the input is timelock data with 32 channels and 7000 timebins >> using headmodel specified in the configuration >> using electrodes specified in the configuration >> determining source compartment (3) >> projecting electrodes on skin surface >> combining electrode transfer and system matrix >> creating dipole grid based on user specified dipole positions >> using headmodel specified in the configuration >> using gradiometers specified in the configuration >> 8196 dipoles inside, 0 dipoles outside brain >> the call to "ft_prepare_sourcemodel" took 0 seconds >> estimating current density distribution for repetition 1 >> using pre-computed leadfields: some of the specified options will not have an effect >> computing the solution where the noise covariance is used for regularisation >> prewhitening the leadfields using the noise covariance >> scaling the source covariance >> the call to "ft_sourceanalysis" took 87 seconds >> >> >> >> cfg = []; >> cfg.projectmom = 'yes'; >> sdrHF = ft_sourcedescriptives(cfg,sourcerHF); >> sdlHF = ft_sourcedescriptives(cfg, sourcelHF); >> >> sdDIFF = sdrHF; >> sdDIFF.avg.pow = sdrHF.avg.pow - sdlHF.avg.pow; >> sdDIFF.tri = sourcespace.tri; >> >> save sd sdrHF sdlHF sdDIFF; >> >> Then I tried different suggestions from the tutorial or the mailing list: >> >> cfg = []; >> cfg.mask = 'avg.pow'; >> ft_sourcemovie(cfg,sdDIFF); >> >> the input is source data with 8196 positions >> baseline correcting dipole moments [--------------------------------------\] >> projecting dipole moment [------------------------------------------------/] >> computing power [---------------------------------------------------------|] >> the call to "ft_sourcedescriptives" took 32 seconds >> the input is source data with 8196 positions >> baseline correcting dipole moments [---------------------------------------] >> projecting dipole moment [------------------------------------------------\] >> computing power [----------------------------------------------------------] >> the call to "ft_sourcedescriptives" took 33 seconds >> the input is source data with 8196 vertex positions and 16384 triangles >> Warning: use cfg.maskparameter instead of cfg.mask >> > In ft_checkconfig at 120 >> In ft_sourcemovie at 48 >> ??? Error using ==> set >> Bad property value found. >> Object Name : axes >> Property Name : 'CLim' >> Values must be increasing and non-NaN. >> >> Error in ==> caxis at 80 >> set(ax,'CLim',arg); >> >> Error in ==> ft_sourcemovie at 263 >> caxis(cfg.zlim); >> >> >> >> If I set a break before this point I can see that "arg" indeed contains two NaNs only. >> >> Do you have any suggestions why the script above fails to determine the axes properties? >> >> Alternatively I tried: >> >> figure >> sdDIFF.tri = sourcespace.tri; >> cfg = []; >> cfg.alim = [0 0.5]; >> cfg.zlim = [0 0.5]; >> cfg.maskparameter = 'avg.pow'; >> ft_sourcemovie(cfg,sdDIFF); >> >> >> That results in a GUI that does seem to work but in the time course there is no activity displayed. >> >> Any advice how to visualize the difference properly? >> Thanks in advance. >> Best >> Leo >> RWTH Aachen Neurology >> >> >> P.S. >> structure of the difference sdDIFF: >> >> time: [1x7000 double] >> pos: [8196x3 double] >> inside: [8196x1 double] >> outside: [1x0 double] >> method: 'average' >> avg: [1x1 struct] >> cfg: [1x1 struct] >> tri: [16384x3 int32] >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozancag at gmail.com Mon Nov 18 10:56:37 2013 From: ozancag at gmail.com (=?UTF-8?B?T3phbiDDh2HEn2xheWFu?=) Date: Mon, 18 Nov 2013 11:56:37 +0200 Subject: [FieldTrip] Some fixes to suppress gcc warnings in libbuffer Message-ID: Hi, Trying to build libbuffer, I got a lot of warnings. I'm sending a patch to fix those warnings. I didn't test if this breaks anything so it is up to you to take and/or ignore this. Thanks :) -- Ozan Çağlayan Research Assistant Galatasaray University - Computer Engineering Dept. http://www.ozancaglayan.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fieldtrip-fixes.patch Type: text/x-patch Size: 6226 bytes Desc: not available URL: From jm.horschig at donders.ru.nl Mon Nov 18 11:15:32 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Mon, 18 Nov 2013 11:15:32 +0100 Subject: [FieldTrip] ft_channelrepair not finding electrodes In-Reply-To: References: Message-ID: <5289E8C4.9060605@donders.ru.nl> Hi Max, check out Fieldtrip/template/electrode and see if you can use one of the templates in there. Best would be to use electrode measurements that you actually performed yourself (to get the distances between electrodes right), but using a template might be good as well. Once you found a good template-file, you can set cfg.elecfile = 'folder/filename' and FieldTrip will handle the rest. Otherwise, if some of your colleagues have electrode measurements, you can also ask them for advice. Best, Jörn On 11/15/2013 5:40 PM, Max Cantor wrote: > Hi all, > > I'm trying to perform channel repair on EEG data that has undergone > jump, muscle, and visual artifact rejection, and ICA to remove eog and > ecg components, unmixed back into the original channels. It's a 61 > channel system using a modified easycap layout and neighbours template. > > The layout has been shown to work on topographic displays, and the > template seems to work in that it creates a neighbours object when > ft_prepare_neighbours is run on it without any errors. > > However, I'm getting an error when I attempt to run ft_channelrepair: > > Error using ft_fetch_sens (line 179) > no electrodes or gradiometers specified. > > Error in ft_channelrepair (line 112) > sens = ft_fetch_sens(cfg, data); > > I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not > really sure what elec/sens file I should be reading or how to go about > creating it. I was hoping that the template, my data, and/or the > layout would contain the necessary information, but given the error on > ft_fetch_sens, that doesn't seem to be the case. > > Any help on this issue would be greatly appreciated. > > Thanks, > > Max > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Mon Nov 18 15:33:12 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Mon, 18 Nov 2013 15:33:12 +0100 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline Message-ID: <528A2528.5020302@gmail.com> Hi everyone, In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? I'm looking forward to hearing any thoughts you may want to share! Cheers, Vitória From mcgoiv0 at wfu.edu Mon Nov 18 15:51:07 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Mon, 18 Nov 2013 09:51:07 -0500 Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hello everybody, I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the ft_timelockanalysis(cfg, data) function? I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. Another way to ask this question is: what is the format/structure of the second input (timelock) in the ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? Thanks, Inna -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.stolk8 at gmail.com Mon Nov 18 16:42:43 2013 From: a.stolk8 at gmail.com (Arjen Stolk) Date: Mon, 18 Nov 2013 16:42:43 +0100 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hi Inna, Ft_regressconfound will remove trial by trial variability of signal amplitude or frequency power that can be explained by variability in head position over those trials. The input, whether sensor or source level, should contain a trial field (keep trials in the previous step - eg at timelockanalysis). Also variance due to head position can only be reliably estimated when the neural signal is consistent over trials (as with an event related modulation or potential). I would not know how to segment a resting state into trials (for further analysis, given that those analyses typically involve connectivity measures over the resting period) but if you an idea on how to do this, you could give ft_regressconfound a try. Note that the output will also be in the trials format. Hope this has made its use a bit more clear. Yours, arjen Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het volgende: > > Hello everybody, > > I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. > It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the > > ft_timelockanalysis(cfg, data) function? > > I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. > > > Another way to ask this question is: > what is the format/structure of the second input (timelock) in the > ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? > > > Thanks, > > Inna > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From arno at cerco.ups-tlse.fr Mon Nov 18 17:27:40 2013 From: arno at cerco.ups-tlse.fr (Arnaud Delorme) Date: Mon, 18 Nov 2013 08:27:40 -0800 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline In-Reply-To: <528A2528.5020302@gmail.com> References: <528A2528.5020302@gmail.com> Message-ID: Dear Vitoria, there is no need to "export" data from Fieldtrip to EEGLAB to plot ERPimage figures. Simply call the "erpimage" function of EEGLAB and fill in the parameter using your fieldtrip data. The only thing you might have to do it is transform your data from a cell array to a regular 2-D array containing sample points in one dimension and trials in the other. Anything that is being shown on the EEGLAB ERPimage figure can be reproduced using this function on the command line. To sort single trials by alpha power or alpha phase (for example), you do not need a baseline period. You can compare ERPimage accross subjects and perform statistics on them using the STUDY structure of EEGLAB. Best, Arno -- Arnaud Delorme, PhD Centre de Recherche Cerveau et Cognition - UMR 5549 Pavillon Baudot, Hopital Purpan, BP 25202 31052 Toulouse Cedex, France On Nov 18, 2013, at 6:33 AM, Vitoria Piai wrote: > Hi everyone, > > In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: > http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif > Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? > I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) > I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. > > The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. > The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? > > I'm looking forward to hearing any thoughts you may want to share! > Cheers, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From arno at cerco.ups-tlse.fr Mon Nov 18 17:27:40 2013 From: arno at cerco.ups-tlse.fr (Arnaud Delorme) Date: Mon, 18 Nov 2013 08:27:40 -0800 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline In-Reply-To: <528A2528.5020302@gmail.com> References: <528A2528.5020302@gmail.com> Message-ID: Dear Vitoria, there is no need to "export" data from Fieldtrip to EEGLAB to plot ERPimage figures. Simply call the "erpimage" function of EEGLAB and fill in the parameter using your fieldtrip data. The only thing you might have to do it is transform your data from a cell array to a regular 2-D array containing sample points in one dimension and trials in the other. Anything that is being shown on the EEGLAB ERPimage figure can be reproduced using this function on the command line. To sort single trials by alpha power or alpha phase (for example), you do not need a baseline period. You can compare ERPimage accross subjects and perform statistics on them using the STUDY structure of EEGLAB. Best, Arno -- Arnaud Delorme, PhD Centre de Recherche Cerveau et Cognition - UMR 5549 Pavillon Baudot, Hopital Purpan, BP 25202 31052 Toulouse Cedex, France On Nov 18, 2013, at 6:33 AM, Vitoria Piai wrote: > Hi everyone, > > In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: > http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif > Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? > I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) > I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. > > The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. > The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? > > I'm looking forward to hearing any thoughts you may want to share! > Cheers, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From ww.peng0923 at gmail.com Tue Nov 19 13:50:18 2013 From: ww.peng0923 at gmail.com (PWW) Date: Tue, 19 Nov 2013 13:50:18 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source Message-ID: Dear Fieldtrippers, In the beamformer tutorial ( http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of (post-pre)/pre was calculated to circumvent the noise bias towards the center of the head. However, I wonder whether it is possible to only localize the pre-stimulus oscillation source, such as pre-stimulus alpha power for example, just like localizing the sources of spontaneous oscillatory activity. Actually, I tried to do it, and use neural activity index to remove the center of the head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't work so well. Does anyone have any suggestions about localizing the cortical sources of spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it any difference with the procedures described in the tutorial? Any pointers would be much appreciated. Thanks. Regards, Weiwei -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Tue Nov 19 14:05:37 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Tue, 19 Nov 2013 14:05:37 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source In-Reply-To: References: Message-ID: Dear Weiwei, After using cfg.dics.projectnoise = 'yes', did you also compute the "Neural Activity Index" by computing source.avg.pow = source.avg.pow ./ source.avg.noise? If not, the noise estimate remains unused. Best, Eelke On 19 November 2013 13:50, PWW wrote: > Dear Fieldtrippers, > > In the beamformer tutorial > (http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of > (post-pre)/pre was calculated to circumvent the noise bias towards the > center of the head. > > However, I wonder whether it is possible to only localize the pre-stimulus > oscillation source, such as pre-stimulus alpha power for example, just like > localizing the sources of spontaneous oscillatory activity. Actually, I > tried to do it, and use neural activity index to remove the center of the > head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't > work so well. > > Does anyone have any suggestions about localizing the cortical sources of > spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it > any difference with the procedures described in the tutorial? > > Any pointers would be much appreciated. > > Thanks. > > Regards, > > Weiwei > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jm.horschig at donders.ru.nl Tue Nov 19 14:12:09 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Tue, 19 Nov 2013 14:12:09 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source In-Reply-To: References: Message-ID: <528B63A9.4050104@donders.ru.nl> Dear Weiwei, as an alternative to computing the NAI (as Eelke pointed to), you can normalize the leadfield by settings cfg.normalize = 'yes' prior to calling ft_compute_leadfield. I've heard from high places that this works pretty well, but haven't compared both methods myself. Best, Jörn Eelke Spaak wrote: > Dear Weiwei, > > After using cfg.dics.projectnoise = 'yes', did you also compute the > "Neural Activity Index" by computing source.avg.pow = source.avg.pow > ./ source.avg.noise? If not, the noise estimate remains unused. > > Best, > Eelke > > On 19 November 2013 13:50, PWW wrote: > >> Dear Fieldtrippers, >> >> In the beamformer tutorial >> (http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of >> (post-pre)/pre was calculated to circumvent the noise bias towards the >> center of the head. >> >> However, I wonder whether it is possible to only localize the pre-stimulus >> oscillation source, such as pre-stimulus alpha power for example, just like >> localizing the sources of spontaneous oscillatory activity. Actually, I >> tried to do it, and use neural activity index to remove the center of the >> head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't >> work so well. >> >> Does anyone have any suggestions about localizing the cortical sources of >> spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it >> any difference with the procedures described in the tutorial? >> >> Any pointers would be much appreciated. >> >> Thanks. >> >> Regards, >> >> Weiwei >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From jean-baptiste.versini at etu.univ-lyon1.fr Tue Nov 19 14:36:10 2013 From: jean-baptiste.versini at etu.univ-lyon1.fr (VERSINI JEAN-BAPTISTE p1207642) Date: Tue, 19 Nov 2013 13:36:10 +0000 Subject: [FieldTrip] Is it safe to overlap trials ? In-Reply-To: <5271B6068CD8D94DB8225422823792880179014E@mbx2010-02.univ-lyon1.fr> References: <5271B6068CD8D94DB8225422823792880179014E@mbx2010-02.univ-lyon1.fr> Message-ID: <5271B6068CD8D94DB82254228237928801790161@mbx2010-02.univ-lyon1.fr> Dear all, I analyze EEG data and I would like to define trials in a way that they may overlap. I know it causes some problems with the databrowser because for a given time, the sample may have different values. Apart from that, are there other things I should worry about or is it totally okay for me to overlap my trials ? If it causes some troubles I will adjust sampleinfo to fake contiguous trials but I'd like to avoid that. Regards, JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Nov 19 18:29:03 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 19 Nov 2013 18:29:03 +0100 Subject: [FieldTrip] failed segmentation In-Reply-To: <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> References: <528781D8.1030107@gmail.com> <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> Message-ID: <528B9FDF.1010404@gmail.com> Hi Lilla and Christiano, Thanks a lot for the suggestions. I think I've managed to fix it by applying Lilla's suggestion, i.e., instead of using the tpm default, I specified the output for 'brain','skull','scalp'. Cheers, Vitória On 11/17/2013 12:03 PM, Lilla.Magyari at mpi.nl wrote: > hi Vitoria, > > is this a tpm (the default output of ft_volumesegment)? Have you also > tried to segment this mri with an output for 'brain','skull','scalp'? > because when you have a binary representation for these tissue-types, they > do not overlap, and are closed. So, I am wondering if you end up with a > brainmask which do not contain the artifact at the top of the head. > > > Lilla > > >> Hi Vitoria, >> it looks like there is an artifact on the top of the head. It happened to >> me already and I had to preprocess the mri volume by using an appropriate >> cutoff and by thresholding (after plotting the histogram of the grey >> levels). >> >> mri.anatomy = (mri.anatomy>thr).*mri.anatomy; >> >> or >> >> mri.anatomy(:,:,230:256) = 0; >> >> If thresholding is still not effective you might consider applying >> morphological operators (erode, dilate, open, close), after taking care >> that you voxel dimensions are cubic (diagonal values of the canonic form >> of >> mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. >> >> I hope this helps, >> Cristiano >> >> >> >> On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai >> wrote: >> >>> Hi all, >>> >>> has anyone ever had a failed segmentation that looks like the one in the >>> figure? >>> My script works for all participants, I mean, for all other participants >>> the brain is only inside the skull :) >>> But it fails terribly for this one. I thought it could have to do with >>> the >>> placement of the fiducials, and I've played around a bit with that but >>> it >>> didn't solve the problem. >>> If anyone recognises this type of error, I'd be help to hear if/how it >>> can >>> be fixed. >>> >>> Thanks a lot, Vitória >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From mcgoiv0 at wfu.edu Tue Nov 19 20:01:17 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Tue, 19 Nov 2013 14:01:17 -0500 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Thank you Arjen for clarifications, Bcs the output is in the trial format anyway, technically, I can proceed with the head motion regression method on the resting state by dividing the data into smaller segments; which I did. I have 120 sec of MEG data (SR=600 Hz) that I divided into 10, or 20, or 30 sec trials and run the ft_regressconfound. Every time I run into the out of memory problem. Matlab error message: ??? Error using==>mldivide Out of memory. Error in ==> ft_regressconfound at 213 beta = regr\dat; % B= X\Y The error appears in the part of the code where the linear equation is solved directly. I tried to only work with a subset of all trials (half for example) with no luck. I rum MatlabR2010a on Windows XP 32-bit with the following memory allocation in Matlab: Max possible array: 851 Mb Memory available for all array: 1703 Mb Memory used by Matlab: 850 Mb RAM: 3317 Mb Were anybody else able to run this motion regression algorithm in Matlab without out of memory? Is there anything I can do to avoid the problem? I can share the code if needed. Thanks in advance, Inna Inna McGowin On Mon, Nov 18, 2013 at 10:42 AM, Arjen Stolk wrote: > Hi Inna, > Ft_regressconfound will remove trial by trial variability of signal > amplitude or frequency power that can be explained by variability in head > position over those trials. The input, whether sensor or source level, > should contain a trial field (keep trials in the previous step - eg at > timelockanalysis). Also variance due to head position can only be reliably > estimated when the neural signal is consistent over trials (as with an > event related modulation or potential). I would not know how to segment a > resting state into trials (for further analysis, given that those analyses > typically involve connectivity measures over the resting period) but if you > an idea on how to do this, you could give ft_regressconfound a try. Note > that the output will also be in the trials format. Hope this has made its > use a bit more clear. Yours, arjen > > Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het > volgende: > > > > > Hello everybody, > > > > I would like to use the ft_regressconfound function to remove/reduce > the head motion in a continuous MEG data. > > It's a resting state data and no averaging can be applied. Is there a > way to apply the correction without using the > > > > ft_timelockanalysis(cfg, data) function? > > > > I understand that the ft_regressconfound function has limits and caveats > but I still would like to see the results of its correction. > > > > > > Another way to ask this question is: > > what is the format/structure of the second input (timelock) in the > > ft_regressconfound(cfg, timelock) function and how it can be created > without ft_timelockanalysis? > > > > > > Thanks, > > > > Inna > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Wed Nov 20 20:08:53 2013 From: mcantor at umich.edu (Max Cantor) Date: Wed, 20 Nov 2013 14:08:53 -0500 Subject: [FieldTrip] ft_channelrepair not finding electrodes In-Reply-To: <5289E8C4.9060605@donders.ru.nl> References: <5289E8C4.9060605@donders.ru.nl> Message-ID: Hi Jorn, Sorry for the late response. I had to create a template for our cap, which had it's own issues, but I think at this point I have it working. Even if there are still some trigonometric issues, at the very least I have the fieldtrip issue resolved. For future reference, because I don't remember seeing anything on the fieldtrip FAQ about this and it may be useful to somebody else, the important thing is to turn the phi/theta from degrees into radians, and then applying a trigonometric function to get the X, Y, and Z coordinates. You can do all of these steps in 3 excel functions: X = COS(RADIANS(Phi))*SIN(RADIANS(Theta)) Y = SIN(RADIANS(Theta))*SIN(RADIANS(Phi)) Z = =COS(RADIANS(Theta)) This link on the easycap website ( http://www.easycap.de/easycap/e/downloads/how_to_read_3d.htm) explains the coordinate system. I then typed up the channel name, x, y, and z coordinates in a four column notepad document saved as a .sfp file, and used that as my cfg.elecfile. Thank you for the support, Max On Mon, Nov 18, 2013 at 5:15 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl> wrote: > Hi Max, > > check out Fieldtrip/template/electrode and see if you can use one of the > templates in there. Best would be to use electrode measurements that you > actually performed yourself (to get the distances between electrodes > right), but using a template might be good as well. Once you found a good > template-file, you can set cfg.elecfile = 'folder/filename' and FieldTrip > will handle the rest. > Otherwise, if some of your colleagues have electrode measurements, you can > also ask them for advice. > > Best, > Jörn > > > On 11/15/2013 5:40 PM, Max Cantor wrote: > > Hi all, > > I'm trying to perform channel repair on EEG data that has undergone > jump, muscle, and visual artifact rejection, and ICA to remove eog and ecg > components, unmixed back into the original channels. It's a 61 channel > system using a modified easycap layout and neighbours template. > > The layout has been shown to work on topographic displays, and the > template seems to work in that it creates a neighbours object when > ft_prepare_neighbours is run on it without any errors. > > However, I'm getting an error when I attempt to run ft_channelrepair: > > Error using ft_fetch_sens (line 179) > no electrodes or gradiometers specified. > > Error in ft_channelrepair (line 112) > sens = ft_fetch_sens(cfg, data); > > I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not > really sure what elec/sens file I should be reading or how to go about > creating it. I was hoping that the template, my data, and/or the layout > would contain the necessary information, but given the error on > ft_fetch_sens, that doesn't seem to be the case. > > Any help on this issue would be greatly appreciated. > > Thanks, > > Max > > > _______________________________________________ > fieldtrip mailing listfieldtrip at donders.ru.nlhttp://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From polomacnenad at gmail.com Thu Nov 21 12:29:32 2013 From: polomacnenad at gmail.com (Nenad Polomac) Date: Thu, 21 Nov 2013 12:29:32 +0100 Subject: [FieldTrip] ft_databrowser doesnt plot channel names Message-ID: Hi, I just realized that ft_databrowser in FT version 20131120 for some reason doesn't plot labels of the channels on y axis. Earlier version works fine. I have also read http://bugzilla.fcdonders.nl/show_bug.cgi?id=2065 cfg=[]; cfg.viewmode ='vertical'; cfg.plotlabels = 'yes'; cfg.eegscale=.5; cfg.trl = 'all'; cfg.continuous = 'no'; cfg.channel ='EEG'; ft_databrowser(cfg, data); My guess is something is wrong with the line 1696 of the ft_databrowser ft_plot_text(labelx(laysel), labely(laysel), opt.hdr.label(chanindx(i)), 'tag', 'chanlabel', 'HorizontalAlignment', 'right','interpreter','none','FontUnits','normalized','FontSize',8); It is not that I urgently need this, I just wanted to contribute a little. :) all the best! Nenad -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.brovelli at univ-amu.fr Thu Nov 21 15:41:25 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Thu, 21 Nov 2013 15:41:25 +0100 (CET) Subject: [FieldTrip] Conjunction analysis Message-ID: <1795812587.19187.1385044885611.JavaMail.root@bureau-frontal1> Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea From a.stolk8 at gmail.com Thu Nov 21 16:35:37 2013 From: a.stolk8 at gmail.com (A.stolk) Date: Thu, 21 Nov 2013 08:35:37 -0700 Subject: [FieldTrip] Conjunction analysis Message-ID: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjenandrea brovelli schreef:Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.brovelli at univ-amu.fr Thu Nov 21 16:58:54 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Thu, 21 Nov 2013 16:58:54 +0100 (CET) Subject: [FieldTrip] Conjunction analysis In-Reply-To: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> References: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> Message-ID: <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> Thanks a lot for your reply, Arjen. It's clearer now. In fact, I am using a parametric tests, so I think I would need to use the Nichols 2005 method for the conjunction analysis. Does anyone have the code to do this or does anyone know how to recover it within SPM ? Thanks a lot Andrea "A.stolk" wrote:Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjen andrea brovelli schreef: Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Thu Nov 21 17:36:38 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 21 Nov 2013 17:36:38 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? Message-ID: Fellow FieldTrippers, Currently I am looking at a contrast for left- versus right-hand index finger button presses. As expected, on sensor level (combined planar gradient, grand average) I see a clear lateralisation in beta band power starting at least 0.5s before the button press (see https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is clearly more beta power ipsilateral to the response hand. I would prefer to do further analyses on source level, so I attempt to reconstruct the sources for this effect using DICS beamformer (common filter, applied to both conditions separately; fixedori and realfilter = 'yes'). The grand average results for this (again contrast left vs right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the R/L-flip, this is radiological convention.) As you can see, the source level solution is much more blurry than on sensor level. This picture is without using any regularisation (lambda parameter), the results are even worse when I use lambda = '5%'. The negative blob (right hand higher power than left) becomes 'marginally significant' on source level (p ~ 0.06) where it was p < 0.001 on sensor level. The positive blob is nowhere near significant. Also, the individual results are much less topographically consistent on source than on sensor level (explaining the worse statistics). I have checked the segmentation of my MRIs, the 'gray' seems to be nicely within the head all the time. Also, I have manually verified the alignment of headmodel, sourcemodel, and gradiometer information for all subjects. As a final note, the above sensor-level plot was taken from a 'slice' out of a planar-gradient time-frequency analysis (mtmconvol). The ingredient for the beamformer was an mtmfft fourier spectrum on the axial gradiometer data, obtained for just the time-frequency range of interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). When I compute condition-averaged power based on these fourier spectra and look at the contrast, the results are again as expected: https://db.tt/n2P3UKcQ (of course less localised because of axial gradient vs planar). The freq structures underlying this contrast are exactly the same as those going into ft_sourceanalysis, so the problem must be in the source analysis step (and/or in the preparation of the geometric information, although these seem fine by visual inspection). Does anyone have any idea that might explain these seemingly contradictory results? I would have expected demixing to improve signal-to-noise ratio, rather than worsen it. Thanks! Best, Eelke From v.piai.research at gmail.com Thu Nov 21 17:51:00 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Thu, 21 Nov 2013 17:51:00 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: <528E39F4.9070105@gmail.com> Hi all, Eelke, Maybe adding to Eelke's remark, although I'm not working with motor beta activity and lateralised index. I'm also using DICS and my very clear, focal sensor-level effects all of a sudden become localised to the whole brain or a whole hemisphere! I happen to have heard from Jan-Mathijs that there may something going on at the moment, but at least for now, Eelke, I don't think this error is unique to our data (and I was actually going to post my incompatible sensor-source results here soon, so now it's less work for me :) Looking forward to hearing your updates, (I'm interrupting my source-level analyses for the time to get a better feeling for the sensor-level data first) Vitória On 21-11-2013 17:36, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Vitória Piai PhD Candidate Donders Institute for Brain, Cognition and Behaviour Centre for Cognition, Radboud University Nijmegen Montessorilaan 3, B.01.05 6525 HR Nijmegen The Netherlands Email : V.piai at donders.ru.nl Phone : +31 24 3612635 www.vitoriapiai.com From eelke.spaak at donders.ru.nl Thu Nov 21 18:27:43 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 21 Nov 2013 18:27:43 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <528E39F4.9070105@gmail.com> References: <528E39F4.9070105@gmail.com> Message-ID: Thanks for the input Vitória. Are you using Fourier input to sourceanalysis, or 'powandcsd'? I'm wondering whether the csd computation inside sourceanalysis might be to blame. Will investigate this tomorrow :) Eelke On Nov 21, 2013 6:01 PM, "Vitoria Piai" wrote: > Hi all, Eelke, > > Maybe adding to Eelke's remark, although I'm not working with motor beta > activity and lateralised index. > I'm also using DICS and my very clear, focal sensor-level effects all of a > sudden become localised to the whole brain or a whole hemisphere! > I happen to have heard from Jan-Mathijs that there may something going on > at the moment, but at least for now, Eelke, I don't think this error is > unique to our data (and I was actually going to post my incompatible > sensor-source results here soon, so now it's less work for me :) > > Looking forward to hearing your updates, > (I'm interrupting my source-level analyses for the time to get a better > feeling for the sensor-level data first) > Vitória > > On 21-11-2013 17:36, Eelke Spaak wrote: > >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus right-hand index >> finger button presses. As expected, on sensor level (combined planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer (common >> filter, applied to both conditions separately; fixedori and realfilter >> = 'yes'). The grand average results for this (again contrast left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry than on >> sensor level. This picture is without using any regularisation (lambda >> parameter), the results are even worse when I use lambda = '5%'. The >> negative blob (right hand higher power than left) becomes 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. Also, the >> individual results are much less topographically consistent on source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually verified >> the alignment of headmodel, sourcemodel, and gradiometer information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum on the >> axial gradiometer data, obtained for just the time-frequency range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this contrast are >> exactly the same as those going into ft_sourceanalysis, so the problem >> must be in the source analysis step (and/or in the preparation of the >> geometric information, although these seem fine by visual inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Vitória Piai > PhD Candidate > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognition, Radboud University Nijmegen > Montessorilaan 3, B.01.05 > 6525 HR Nijmegen > The Netherlands > > Email : V.piai at donders.ru.nl > Phone : +31 24 3612635 > www.vitoriapiai.com > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Thu Nov 21 19:39:30 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Thu, 21 Nov 2013 13:39:30 -0500 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Dear Eelke, very interesting topic. Please find my two cents below: On Thu, Nov 21, 2013 at 11:36 AM, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > There might be issues with: - head positions/distance of single subjects in the dewar - something happening in the transition axial -> planar gradiometers conversion - orientation of the brain motor sources - inverse problem reconstruction - magnitude of the power effects for the different subjects - forward model issues Let me comment briefly on point 4. If the sources in the motor cortex are bilateral (as expected to different extents from ipsi to contra) and are temporally correlated, this constitutes an issue for the beamformer algorithm (van Veen et al.1993) especially if the sources are near (and lead fields highly correlated). There are workarounds to localize the single contributions of primary/secondary motor sources, but this implies the use of regional suppression (a nulling beamformer) and it is a tedious procedure to apply. Might be worth to look into that though. Let me know if you have interest in this. > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > On this point: using regularization is useful to invert the real(csd) matrix if it is ill-conditioned, but might blur the source reconstruction. On the other hand not using it might also be detrimental on the source reconstruction. Therefore applying it depends on the condition number of your csd. Is the matrix full rank? If not you might consider regularizing. Did you previously use ICA/PCA to get rid of artifacts? If yes that will have a negative effect on the condition number. and you might consider cranking down the ICA components rejection to the big spiky components -if any- and let the beamformer filter reject the smaller ones (in magnitude). Are you using cluster statistics based on the maxval? Maybe another statistics might give different results, given that the maxval might be due to artifacts (muscular, heart, ...) > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > Do all subjects sit with the top of the head at the same distance from the dewar? This is easily visualized by plotting the headmodel together with the head coordinates' sensors. By experience with CTF systems not all subjects' heads are at the same distance from the top (because they slip down, or they reposition 'cause they can't see out of the dewar, they also move!). This might hinder the SNR of the raw data to start with. It seems the grand average is still significant, but might be due to the contribution of a few good subjects. You may also want to consider the movement correction GLM method at the source level. Maybe it gives you back some SNR. > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > Yes, but it can also depend on different extents from FFT-level analysis. Have you played around with spectral smoothing, by for example lowering the number of tapers, or changing to a single condition contrast like activation vs baseline in the beamformer? What is the grand average vs single subject lateralization effect/single condition effect/ planar or axial effect? Is it there for all single subjects? I hope the comments helped a bit. All the best! Cristiano > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stan.vanpelt at fcdonders.ru.nl Thu Nov 21 21:45:49 2013 From: stan.vanpelt at fcdonders.ru.nl (Stan van Pelt) Date: Thu, 21 Nov 2013 21:45:49 +0100 (CET) Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: Message-ID: <513733919.261511.1385066749005.JavaMail.root@indus.zimbra.ru.nl> Hi Eelke, Have you tried comparing the results with a time-domain beamformer? You could e.g. try LCMV on 15-25Hz-bandpassed data. This should give you in theory similar results. Best, Stan ----- Oorspronkelijk bericht ----- > Van: "Eelke Spaak" > Aan: "FieldTrip discussion list" > Verzonden: Donderdag 21 november 2013 18:27:43 > Onderwerp: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Thanks for the input Vitória. Are you using Fourier input to > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd > computation inside sourceanalysis might be to blame. Will investigate > this tomorrow :) > Eelke > On Nov 21, 2013 6:01 PM, "Vitoria Piai" < v.piai.research at gmail.com > > wrote: > > Hi all, Eelke, > > Maybe adding to Eelke's remark, although I'm not working with motor > > beta activity and lateralised index. > > I'm also using DICS and my very clear, focal sensor-level effects > > all > > of a sudden become localised to the whole brain or a whole > > hemisphere! > > I happen to have heard from Jan-Mathijs that there may something > > going > > on at the moment, but at least for now, Eelke, I don't think this > > error is unique to our data (and I was actually going to post my > > incompatible sensor-source results here soon, so now it's less work > > for me :) > > Looking forward to hearing your updates, > > (I'm interrupting my source-level analyses for the time to get a > > better feeling for the sensor-level data first) > > Vitória > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > Fellow FieldTrippers, > > > Currently I am looking at a contrast for left- versus right-hand > > > index > > > finger button presses. As expected, on sensor level (combined > > > planar > > > gradient, grand average) I see a clear lateralisation in beta band > > > power starting at least 0.5s before the button press (see > > > https://db.tt/Rtch3Qjy ). Both 'blobs' are significant; there is > > > clearly more beta power ipsilateral to the response hand. I would > > > prefer to do further analyses on source level, so I attempt to > > > reconstruct the sources for this effect using DICS beamformer > > > (common > > > filter, applied to both conditions separately; fixedori and > > > realfilter > > > = 'yes'). The grand average results for this (again contrast left > > > vs > > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore > > > the > > > R/L-flip, this is radiological convention.) > > > As you can see, the source level solution is much more blurry than > > > on > > > sensor level. This picture is without using any regularisation > > > (lambda > > > parameter), the results are even worse when I use lambda = '5%'. > > > The > > > negative blob (right hand higher power than left) becomes > > > 'marginally > > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > > sensor level. The positive blob is nowhere near significant. Also, > > > the > > > individual results are much less topographically consistent on > > > source > > > than on sensor level (explaining the worse statistics). > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > > nicely within the head all the time. Also, I have manually > > > verified > > > the alignment of headmodel, sourcemodel, and gradiometer > > > information > > > for all subjects. > > > As a final note, the above sensor-level plot was taken from a > > > 'slice' > > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > > ingredient for the beamformer was an mtmfft fourier spectrum on > > > the > > > axial gradiometer data, obtained for just the time-frequency range > > > of > > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = > > > 7). > > > When I compute condition-averaged power based on these fourier > > > spectra > > > and look at the contrast, the results are again as expected: > > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > > gradient vs planar). The freq structures underlying this contrast > > > are > > > exactly the same as those going into ft_sourceanalysis, so the > > > problem > > > must be in the source analysis step (and/or in the preparation of > > > the > > > geometric information, although these seem fine by visual > > > inspection). > > > Does anyone have any idea that might explain these seemingly > > > contradictory results? I would have expected demixing to improve > > > signal-to-noise ratio, rather than worsen it. > > > Thanks! > > > Best, > > > Eelke > > > ______________________________ _________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > -- > > Vitória Piai > > PhD Candidate > > Donders Institute for Brain, Cognition and Behaviour > > Centre for Cognition, Radboud University Nijmegen > > Montessorilaan 3, B.01.05 > > 6525 HR Nijmegen > > The Netherlands > > Email : V.piai at donders.ru.nl > > Phone : +31 24 3612635 > > www.vitoriapiai.com > > ______________________________ _________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour Centre for Cognition Montessorilaan 3, B.01.19 6525 HR Nijmegen tel: 024-3616288 -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiteng.jiang at gmail.com Thu Nov 21 22:49:50 2013 From: haiteng.jiang at gmail.com (Haiteng Jiang) Date: Thu, 21 Nov 2013 22:49:50 +0100 Subject: [FieldTrip] =?utf-8?q?Motor_beta_activity_-_DICS_solution_more_no?= =?utf-8?q?isy_than_=E3=80=80sensor_data=3F?= Message-ID: On 21 November 2013 21:46, wrote: > Send fieldtrip mailing list submissions to > fieldtrip at science.ru.nl > > To subscribe or unsubscribe via the World Wide Web, visit > http://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. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Eelke Spaak) > 2. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Cristiano Micheli) > 3. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Stan van Pelt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Nov 2013 18:27:43 +0100 > From: Eelke Spaak > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > zBvahNkAp9rO9LTRimRWR09GbeC3vfEv1sXHg at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thanks for the input Vit?ria. Are you using Fourier input to > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd computation > inside sourceanalysis might be to blame. Will investigate this tomorrow :) > > Eelke > On Nov 21, 2013 6:01 PM, "Vitoria Piai" wrote: > > > Hi all, Eelke, > > > > Maybe adding to Eelke's remark, although I'm not working with motor beta > > activity and lateralised index. > > I'm also using DICS and my very clear, focal sensor-level effects all of > a > > sudden become localised to the whole brain or a whole hemisphere! > > I happen to have heard from Jan-Mathijs that there may something going on > > at the moment, but at least for now, Eelke, I don't think this error is > > unique to our data (and I was actually going to post my incompatible > > sensor-source results here soon, so now it's less work for me :) > > > > Looking forward to hearing your updates, > > (I'm interrupting my source-level analyses for the time to get a better > > feeling for the sensor-level data first) > > Vit?ria > > > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > >> Fellow FieldTrippers, > >> > >> Currently I am looking at a contrast for left- versus right-hand index > >> finger button presses. As expected, on sensor level (combined planar > >> gradient, grand average) I see a clear lateralisation in beta band > >> power starting at least 0.5s before the button press (see > >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > >> clearly more beta power ipsilateral to the response hand. I would > >> prefer to do further analyses on source level, so I attempt to > >> reconstruct the sources for this effect using DICS beamformer (common > >> filter, applied to both conditions separately; fixedori and realfilter > >> = 'yes'). The grand average results for this (again contrast left vs > >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > >> R/L-flip, this is radiological convention.) > >> > >> As you can see, the source level solution is much more blurry than on > >> sensor level. This picture is without using any regularisation (lambda > >> parameter), the results are even worse when I use lambda = '5%'. The > >> negative blob (right hand higher power than left) becomes 'marginally > >> significant' on source level (p ~ 0.06) where it was p < 0.001 on > >> sensor level. The positive blob is nowhere near significant. Also, the > >> individual results are much less topographically consistent on source > >> than on sensor level (explaining the worse statistics). > >> > >> I have checked the segmentation of my MRIs, the 'gray' seems to be > >> nicely within the head all the time. Also, I have manually verified > >> the alignment of headmodel, sourcemodel, and gradiometer information > >> for all subjects. > >> > >> As a final note, the above sensor-level plot was taken from a 'slice' > >> out of a planar-gradient time-frequency analysis (mtmconvol). The > >> ingredient for the beamformer was an mtmfft fourier spectrum on the > >> axial gradiometer data, obtained for just the time-frequency range of > >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > >> When I compute condition-averaged power based on these fourier spectra > >> and look at the contrast, the results are again as expected: > >> https://db.tt/n2P3UKcQ (of course less localised because of axial > >> gradient vs planar). The freq structures underlying this contrast are > >> exactly the same as those going into ft_sourceanalysis, so the problem > >> must be in the source analysis step (and/or in the preparation of the > >> geometric information, although these seem fine by visual inspection). > >> > >> Does anyone have any idea that might explain these seemingly > >> contradictory results? I would have expected demixing to improve > >> signal-to-noise ratio, rather than worsen it. > >> > >> Thanks! > >> Best, > >> Eelke > >> _______________________________________________ > >> fieldtrip mailing list > >> fieldtrip at donders.ru.nl > >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > > > > > > -- > > Vit?ria Piai > > PhD Candidate > > Donders Institute for Brain, Cognition and Behaviour > > Centre for Cognition, Radboud University Nijmegen > > Montessorilaan 3, B.01.05 > > 6525 HR Nijmegen > > The Netherlands > > > > Email : V.piai at donders.ru.nl > > Phone : +31 24 3612635 > > www.vitoriapiai.com > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/00fab2a3/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 21 Nov 2013 13:39:30 -0500 > From: Cristiano Micheli > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > < > CADW7XCCf9aAPYFTF9iCuMnRgYHA6hhoPBbex0ihkJNB_b3ah5Q at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Dear Eelke, very interesting topic. Please find my two cents below: > > > On Thu, Nov 21, 2013 at 11:36 AM, Eelke Spaak >wrote: > > > Fellow FieldTrippers, > > > > Currently I am looking at a contrast for left- versus right-hand index > > finger button presses. As expected, on sensor level (combined planar > > gradient, grand average) I see a clear lateralisation in beta band > > power starting at least 0.5s before the button press (see > > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > > clearly more beta power ipsilateral to the response hand. I would > > prefer to do further analyses on source level, so I attempt to > > reconstruct the sources for this effect using DICS beamformer (common > > filter, applied to both conditions separately; fixedori and realfilter > > = 'yes'). The grand average results for this (again contrast left vs > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > > R/L-flip, this is radiological convention.) > > > > > There might be issues with: > - head positions/distance of single subjects in the dewar > - something happening in the transition axial -> planar gradiometers > conversion > - orientation of the brain motor sources > - inverse problem reconstruction > - magnitude of the power effects for the different subjects > - forward model issues > > Let me comment briefly on point 4. If the sources in the motor cortex are > bilateral (as expected to different extents from ipsi to contra) and are > temporally correlated, this constitutes an issue for the beamformer > algorithm (van Veen et al.1993) especially if the sources are near (and > lead fields highly correlated). > There are workarounds to localize the single contributions of > primary/secondary motor sources, but this implies the use of regional > suppression (a nulling beamformer) and it is a tedious procedure to apply. > Might be worth to look into that though. Let me know if you have interest > in this. > > > > > As you can see, the source level solution is much more blurry than on > > sensor level. This picture is without using any regularisation (lambda > > parameter), the results are even worse when I use lambda = '5%'. The > > negative blob (right hand higher power than left) becomes 'marginally > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > sensor level. The positive blob is nowhere near significant. Also, the > > individual results are much less topographically consistent on source > > than on sensor level (explaining the worse statistics). > > > > On this point: using regularization is useful to invert the real(csd) > matrix if it is ill-conditioned, but might blur the source reconstruction. > On the other hand not using it might also be detrimental on the source > reconstruction. Therefore applying it depends on the condition number of > your csd. Is the matrix full rank? If not you might consider regularizing. > Did you previously use ICA/PCA to get rid of artifacts? If yes that will > have a negative effect on the condition number. and you might consider > cranking down the ICA components rejection to the big spiky components -if > any- and let the beamformer filter reject the smaller ones (in magnitude). > Are you using cluster statistics based on the maxval? Maybe another > statistics might give different results, given that the maxval might be due > to artifacts (muscular, heart, ...) > > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > nicely within the head all the time. Also, I have manually verified > > the alignment of headmodel, sourcemodel, and gradiometer information > > for all subjects. > > > > Do all subjects sit with the top of the head at the same distance from the > dewar? This is easily visualized by plotting the headmodel together with > the head coordinates' sensors. > By experience with CTF systems not all subjects' heads are at the same > distance from the top (because they slip down, or they reposition 'cause > they can't see out of the dewar, they also move!). This might hinder the > SNR of the raw data to start with. > It seems the grand average is still significant, but might be due to the > contribution of a few good subjects. > You may also want to consider the movement correction GLM method at the > source level. Maybe it gives you back some SNR. > > > > As a final note, the above sensor-level plot was taken from a 'slice' > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > ingredient for the beamformer was an mtmfft fourier spectrum on the > > axial gradiometer data, obtained for just the time-frequency range of > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > > When I compute condition-averaged power based on these fourier spectra > > and look at the contrast, the results are again as expected: > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > gradient vs planar). The freq structures underlying this contrast are > > exactly the same as those going into ft_sourceanalysis, so the problem > > must be in the source analysis step (and/or in the preparation of the > > geometric information, although these seem fine by visual inspection). > > > > Does anyone have any idea that might explain these seemingly > > contradictory results? I would have expected demixing to improve > > signal-to-noise ratio, rather than worsen it. > > > > Yes, but it can also depend on different extents from FFT-level analysis. > Have you played around with spectral smoothing, by for example lowering the > number of tapers, or changing to a single condition contrast like > activation vs baseline in the beamformer? > What is the grand average vs single subject lateralization effect/single > condition effect/ planar or axial effect? Is it there for all single > subjects? > > I hope the comments helped a bit. > > All the best! > Cristiano > > > > > > Thanks! > > Best, > > Eelke > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/283a4f1b/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Nov 2013 21:45:49 +0100 (CET) > From: Stan van Pelt > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > <513733919.261511.1385066749005.JavaMail.root at indus.zimbra.ru.nl> > Content-Type: text/plain; charset="utf-8" > > Hi Eelke, Have you tried comparing the results with a time-domain > beamformer? You could e.g. try LCMV on 15-25Hz-bandpassed data. This should > give you in theory similar results. Best, Stan ----- Oorspronkelijk bericht > ----- > > Van: "Eelke Spaak" > > Aan: "FieldTrip discussion list" > > Verzonden: Donderdag 21 november 2013 18:27:43 > > Onderwerp: Re: [FieldTrip] Motor beta activity - DICS solution more > > noisy than sensor data? > > Thanks for the input Vit?ria. Are you using Fourier input to > > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd > > computation inside sourceanalysis might be to blame. Will investigate > > this tomorrow :) > > Eelke > > On Nov 21, 2013 6:01 PM, "Vitoria Piai" < v.piai.research at gmail.com > > > wrote: > > > Hi all, Eelke, > > > Maybe adding to Eelke's remark, although I'm not working with motor > > > beta activity and lateralised index. > > > I'm also using DICS and my very clear, focal sensor-level effects > > > all > > > of a sudden become localised to the whole brain or a whole > > > hemisphere! > > > I happen to have heard from Jan-Mathijs that there may something > > > going > > > on at the moment, but at least for now, Eelke, I don't think this > > > error is unique to our data (and I was actually going to post my > > > incompatible sensor-source results here soon, so now it's less work > > > for me :) > > > Looking forward to hearing your updates, > > > (I'm interrupting my source-level analyses for the time to get a > > > better feeling for the sensor-level data first) > > > Vit?ria > > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > > Fellow FieldTrippers, > > > > Currently I am looking at a contrast for left- versus right-hand > > > > index > > > > finger button presses. As expected, on sensor level (combined > > > > planar > > > > gradient, grand average) I see a clear lateralisation in beta band > > > > power starting at least 0.5s before the button press (see > > > > https://db.tt/Rtch3Qjy ). Both 'blobs' are significant; there is > > > > clearly more beta power ipsilateral to the response hand. I would > > > > prefer to do further analyses on source level, so I attempt to > > > > reconstruct the sources for this effect using DICS beamformer > > > > (common > > > > filter, applied to both conditions separately; fixedori and > > > > realfilter > > > > = 'yes'). The grand average results for this (again contrast left > > > > vs > > > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore > > > > the > > > > R/L-flip, this is radiological convention.) > > > > As you can see, the source level solution is much more blurry than > > > > on > > > > sensor level. This picture is without using any regularisation > > > > (lambda > > > > parameter), the results are even worse when I use lambda = '5%'. > > > > The > > > > negative blob (right hand higher power than left) becomes > > > > 'marginally > > > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > > > sensor level. The positive blob is nowhere near significant. Also, > > > > the > > > > individual results are much less topographically consistent on > > > > source > > > > than on sensor level (explaining the worse statistics). > > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > > > nicely within the head all the time. Also, I have manually > > > > verified > > > > the alignment of headmodel, sourcemodel, and gradiometer > > > > information > > > > for all subjects. > > > > As a final note, the above sensor-level plot was taken from a > > > > 'slice' > > > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > > > ingredient for the beamformer was an mtmfft fourier spectrum on > > > > the > > > > axial gradiometer data, obtained for just the time-frequency range > > > > of > > > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = > > > > 7). > > > > When I compute condition-averaged power based on these fourier > > > > spectra > > > > and look at the contrast, the results are again as expected: > > > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > > > gradient vs planar). The freq structures underlying this contrast > > > > are > > > > exactly the same as those going into ft_sourceanalysis, so the > > > > problem > > > > must be in the source analysis step (and/or in the preparation of > > > > the > > > > geometric information, although these seem fine by visual > > > > inspection). > > > > Does anyone have any idea that might explain these seemingly > > > > contradictory results? I would have expected demixing to improve > > > > signal-to-noise ratio, rather than worsen it. > > > > Thanks! > > > > Best, > > > > Eelke > > > > ______________________________ _________________ > > > > fieldtrip mailing list > > > > fieldtrip at donders.ru.nl > > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > > -- > > > Vit?ria Piai > > > PhD Candidate > > > Donders Institute for Brain, Cognition and Behaviour > > > Centre for Cognition, Radboud University Nijmegen > > > Montessorilaan 3, B.01.05 > > > 6525 HR Nijmegen > > > The Netherlands > > > Email : V.piai at donders.ru.nl > > > Phone : +31 24 3612635 > > > www.vitoriapiai.com > > > ______________________________ _________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour > Centre for Cognition Montessorilaan 3, B.01.19 6525 HR Nijmegen tel: > 024-3616288 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/60bb5dee/attachment.html > > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 36, Issue 34 > ***************************************** > -- Haiteng Jiang PhD candidate Neuronal Oscillations Group Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Visiting address Room 2.32 Donders Centre for Cognitive Neuroimaging Kapittelweg 29 6525 EN Nijmegen the Netherlands Tel.: +31 (0)243668291 Web: https://sites.google.com/site/haitengjiang/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From haristz at gmail.com Fri Nov 22 01:09:36 2013 From: haristz at gmail.com (Charidimos Tzagarakis) Date: Thu, 21 Nov 2013 18:09:36 -0600 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Hi Eelke, Provided there is no major recent revision of the DICS code, I would have expected motor desynchronisation to show up pretty well. Are the maps shown at source and channel level straight differences of L and Right hand conditions at the beta band (I hope I am correctly interpreting your paradigm) ? If so it might be helpful in pinpointing the problem/as a sanity check to see what happens when you use beta desynchonisation (ie change relative to the baseline) instead for each condition, and see source/channel maps of that separately for L and R and then when you take the difference. I suppose the main element this checks for is whether L and R conditions have the same baseline. This doesn't immediately explain why source and channel results are different but in the absence of any other clues it may be a way to 2ble check the whole process. Another point to consider is that, although beta changes should appear in all subjects, it is possibly true that there are individual differences in the actual beta range and frequency bin of maximum effect. If you are using the same settings for all subjects when you beamform with DICS you may be missing some of the effect (true, this is also the case for channel data but there may be subtle differences that add up - there are many voxels and few channels). I believe it may be useful to see what happens when you run the beamformer tailored to each subject's particular beta characteristics (ie change the "foi" for each subject, keep the tapsmofrq the same - possibly smaller) and then combine everything (you'll need of course to come up with a relative metric such as perc. change when you combine all subjects to account for the slightly different frequencies you used ) Best, Haris Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych University of Minnesota Dept of Neuroscience and Brain Sciences Center On 21 November 2013 10:36, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haristz at gmail.com Fri Nov 22 07:07:59 2013 From: haristz at gmail.com (Charidimos Tzagarakis) Date: Fri, 22 Nov 2013 00:07:59 -0600 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Eelke, Thinking again about my second suggestion (regarding individual variability) I actually can't think of a case where this could realistically produce what you get. On the other hand, looking at TF maps per subject and channel (on the "helmet" layout), normalised with a "rest" epoch, may help spot something unusual. Best, Haris Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych University of Minnesota Dept of Neuroscience and Brain Sciences Center On 21 November 2013 18:09, Charidimos Tzagarakis wrote: > Hi Eelke, > Provided there is no major recent revision of the DICS code, I would have > expected motor desynchronisation to show up pretty well. Are the maps shown > at source and channel level straight differences of L and Right hand > conditions at the beta band (I hope I am correctly interpreting your > paradigm) ? If so it might be helpful in pinpointing the problem/as a > sanity check to see what happens when you use beta desynchonisation (ie > change relative to the baseline) instead for each condition, and see > source/channel maps of that separately for L and R and then when you take > the difference. I suppose the main element this checks for is whether L and > R conditions have the same baseline. > This doesn't immediately explain why source and channel results are > different but in the absence of any other clues it may be a way to 2ble > check the whole process. > > > Another point to consider is that, although beta changes should appear in > all subjects, it is possibly true that there are individual differences in > the actual beta range and frequency bin of maximum effect. If you are using > the same settings for all subjects when you beamform with DICS you may be > missing some of the effect (true, this is also the case for channel data > but there may be subtle differences that add up - there are many voxels and > few channels). I believe it may be useful to see what happens when you run > the beamformer tailored to each subject's particular beta characteristics > (ie change the "foi" for each subject, keep the tapsmofrq the same - > possibly smaller) and then combine everything (you'll need of course to > come up with a relative metric such as perc. change when you combine all > subjects to account for the slightly different frequencies you used ) > > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak wrote: > >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus right-hand index >> finger button presses. As expected, on sensor level (combined planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer (common >> filter, applied to both conditions separately; fixedori and realfilter >> = 'yes'). The grand average results for this (again contrast left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry than on >> sensor level. This picture is without using any regularisation (lambda >> parameter), the results are even worse when I use lambda = '5%'. The >> negative blob (right hand higher power than left) becomes 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. Also, the >> individual results are much less topographically consistent on source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually verified >> the alignment of headmodel, sourcemodel, and gradiometer information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum on the >> axial gradiometer data, obtained for just the time-frequency range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this contrast are >> exactly the same as those going into ft_sourceanalysis, so the problem >> must be in the source analysis step (and/or in the preparation of the >> geometric information, although these seem fine by visual inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jm.horschig at donders.ru.nl Fri Nov 22 08:06:31 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Fri, 22 Nov 2013 08:06:31 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: <528F0277.5070200@donders.ru.nl> Hi Eelke, since everyone jumped on the train, here my 2 cents: To verify whether this is a newly introduced bug, maybe run a tutorial test script that includes beamforming. If they look alright, it gets more likely that it is you or your data and not fieldtrip :) It's not definite evidence of course though. SinceVitoria also experiences strange things, it might be something worthwhile to investigate. My initial guess from the plots is that there is something wrong with the forward model. All unit problems should have been resolved, but just to be sure you could check whether all objects are in the same unit (make it 'cm' as the grads are). Best, Jörn Charidimos Tzagarakis wrote: > Eelke, > Thinking again about my second suggestion (regarding individual > variability) I actually can't think of a case where this could > realistically produce what you get. On the other hand, looking at TF > maps per subject and channel (on the "helmet" layout), normalised with > a "rest" epoch, may help spot something unusual. > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > On 21 November 2013 18:09, Charidimos Tzagarakis > wrote: > > Hi Eelke, > Provided there is no major recent revision of the DICS code, I > would have expected motor desynchronisation to show up pretty > well. Are the maps shown at source and channel level straight > differences of L and Right hand conditions at the beta band (I > hope I am correctly interpreting your paradigm) ? If so it might > be helpful in pinpointing the problem/as a sanity check to see > what happens when you use beta desynchonisation (ie change > relative to the baseline) instead for each condition, and see > source/channel maps of that separately for L and R and then when > you take the difference. I suppose the main element this checks > for is whether L and R conditions have the same baseline. > This doesn't immediately explain why source and channel results > are different but in the absence of any other clues it may be a > way to 2ble check the whole process. > > > Another point to consider is that, although beta changes should > appear in all subjects, it is possibly true that there are > individual differences in the actual beta range and frequency bin > of maximum effect. If you are using the same settings for all > subjects when you beamform with DICS you may be missing some of > the effect (true, this is also the case for channel data but there > may be subtle differences that add up - there are many voxels and > few channels). I believe it may be useful to see what happens when > you run the beamformer tailored to each subject's particular beta > characteristics (ie change the "foi" for each subject, keep the > tapsmofrq the same - possibly smaller) and then combine everything > (you'll need of course to come up with a relative metric such as > perc. change when you combine all subjects to account for the > slightly different frequencies you used ) > > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak > wrote: > > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus > right-hand index > finger button presses. As expected, on sensor level (combined > planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer > (common > filter, applied to both conditions separately; fixedori and > realfilter > = 'yes'). The grand average results for this (again contrast > left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . > (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry > than on > sensor level. This picture is without using any regularisation > (lambda > parameter), the results are even worse when I use lambda = > '5%'. The > negative blob (right hand higher power than left) becomes > 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. > Also, the > individual results are much less topographically consistent on > source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually > verified > the alignment of headmodel, sourcemodel, and gradiometer > information > for all subjects. > > As a final note, the above sensor-level plot was taken from a > 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum > on the > axial gradiometer data, obtained for just the time-frequency > range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, > tapsmofrq = 7). > When I compute condition-averaged power based on these fourier > spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this > contrast are > exactly the same as those going into ft_sourceanalysis, so the > problem > must be in the source analysis step (and/or in the preparation > of the > geometric information, although these seem fine by visual > inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > ------------------------------------------------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Fri Nov 22 08:41:35 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 08:41:35 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <528F0277.5070200@donders.ru.nl> References: <528F0277.5070200@donders.ru.nl> Message-ID: Hi everyone, Thanks very much for your great input so far! Actually, as Jörn suggested, I did the very straightforward check (thanks for the tip :) ) of running one of our tutorial test scripts (test_beamforming_extended), and it turns out this one does not produce the same results as depicted here: http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most likely somewhere a bug has been introduced... Hopefully I can find out what it is today and fix it. Will keep you posted! Best, Eelke On 22 November 2013 08:06, "Jörn M. Horschig" wrote: > Hi Eelke, > > since everyone jumped on the train, here my 2 cents: > To verify whether this is a newly introduced bug, maybe run a tutorial test > script that includes beamforming. If they look alright, it gets more likely > that it is you or your data and not fieldtrip :) It's not definite evidence > of course though. SinceVitoria also experiences strange things, it might be > something worthwhile to investigate. > > My initial guess from the plots is that there is something wrong with the > forward model. All unit problems should have been resolved, but just to be > sure you could check whether all objects are in the same unit (make it 'cm' > as the grads are). > > Best, > Jörn > > Charidimos Tzagarakis wrote: >> >> Eelke, >> Thinking again about my second suggestion (regarding individual >> variability) I actually can't think of a case where this could realistically >> produce what you get. On the other hand, looking at TF maps per subject and >> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >> spot something unusual. >> Best, >> Haris >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> On 21 November 2013 18:09, Charidimos Tzagarakis > > wrote: >> >> Hi Eelke, >> Provided there is no major recent revision of the DICS code, I >> would have expected motor desynchronisation to show up pretty >> well. Are the maps shown at source and channel level straight >> differences of L and Right hand conditions at the beta band (I >> hope I am correctly interpreting your paradigm) ? If so it might >> be helpful in pinpointing the problem/as a sanity check to see >> what happens when you use beta desynchonisation (ie change >> relative to the baseline) instead for each condition, and see >> source/channel maps of that separately for L and R and then when >> you take the difference. I suppose the main element this checks >> for is whether L and R conditions have the same baseline. >> This doesn't immediately explain why source and channel results >> are different but in the absence of any other clues it may be a >> way to 2ble check the whole process. >> >> >> Another point to consider is that, although beta changes should >> appear in all subjects, it is possibly true that there are >> individual differences in the actual beta range and frequency bin >> of maximum effect. If you are using the same settings for all >> subjects when you beamform with DICS you may be missing some of >> the effect (true, this is also the case for channel data but there >> may be subtle differences that add up - there are many voxels and >> few channels). I believe it may be useful to see what happens when >> you run the beamformer tailored to each subject's particular beta >> characteristics (ie change the "foi" for each subject, keep the >> tapsmofrq the same - possibly smaller) and then combine everything >> (you'll need of course to come up with a relative metric such as >> perc. change when you combine all subjects to account for the >> slightly different frequencies you used ) >> >> Best, >> Haris >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> On 21 November 2013 10:36, Eelke Spaak > > wrote: >> >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus >> right-hand index >> finger button presses. As expected, on sensor level (combined >> planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer >> (common >> filter, applied to both conditions separately; fixedori and >> realfilter >> = 'yes'). The grand average results for this (again contrast >> left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . >> (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry >> than on >> sensor level. This picture is without using any regularisation >> (lambda >> parameter), the results are even worse when I use lambda = >> '5%'. The >> negative blob (right hand higher power than left) becomes >> 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. >> Also, the >> individual results are much less topographically consistent on >> source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually >> verified >> the alignment of headmodel, sourcemodel, and gradiometer >> information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a >> 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum >> on the >> axial gradiometer data, obtained for just the time-frequency >> range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >> tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier >> spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this >> contrast are >> exactly the same as those going into ft_sourceanalysis, so the >> problem >> must be in the source analysis step (and/or in the preparation >> of the >> geometric information, although these seem fine by visual >> inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Fri Nov 22 09:03:00 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 22 Nov 2013 09:03:00 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> Message-ID: Hoi Eelke, Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de forward module verwacht. Ik gok dat de high-level functies dit niet afdwingen, waardoor de leadfields er bekaaid van af komen. Gr, JM On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > Hi everyone, > > Thanks very much for your great input so far! Actually, as Jörn > suggested, I did the very straightforward check (thanks for the tip :) > ) of running one of our tutorial test scripts > (test_beamforming_extended), and it turns out this one does not > produce the same results as depicted here: > http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most > likely somewhere a bug has been introduced... > > Hopefully I can find out what it is today and fix it. Will keep you posted! > > Best, > Eelke > > On 22 November 2013 08:06, "Jörn M. Horschig" wrote: >> Hi Eelke, >> >> since everyone jumped on the train, here my 2 cents: >> To verify whether this is a newly introduced bug, maybe run a tutorial test >> script that includes beamforming. If they look alright, it gets more likely >> that it is you or your data and not fieldtrip :) It's not definite evidence >> of course though. SinceVitoria also experiences strange things, it might be >> something worthwhile to investigate. >> >> My initial guess from the plots is that there is something wrong with the >> forward model. All unit problems should have been resolved, but just to be >> sure you could check whether all objects are in the same unit (make it 'cm' >> as the grads are). >> >> Best, >> Jörn >> >> Charidimos Tzagarakis wrote: >>> >>> Eelke, >>> Thinking again about my second suggestion (regarding individual >>> variability) I actually can't think of a case where this could realistically >>> produce what you get. On the other hand, looking at TF maps per subject and >>> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >>> spot something unusual. >>> Best, >>> Haris >>> >>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>> >>> >>> >>> On 21 November 2013 18:09, Charidimos Tzagarakis >> > wrote: >>> >>> Hi Eelke, >>> Provided there is no major recent revision of the DICS code, I >>> would have expected motor desynchronisation to show up pretty >>> well. Are the maps shown at source and channel level straight >>> differences of L and Right hand conditions at the beta band (I >>> hope I am correctly interpreting your paradigm) ? If so it might >>> be helpful in pinpointing the problem/as a sanity check to see >>> what happens when you use beta desynchonisation (ie change >>> relative to the baseline) instead for each condition, and see >>> source/channel maps of that separately for L and R and then when >>> you take the difference. I suppose the main element this checks >>> for is whether L and R conditions have the same baseline. >>> This doesn't immediately explain why source and channel results >>> are different but in the absence of any other clues it may be a >>> way to 2ble check the whole process. >>> >>> >>> Another point to consider is that, although beta changes should >>> appear in all subjects, it is possibly true that there are >>> individual differences in the actual beta range and frequency bin >>> of maximum effect. If you are using the same settings for all >>> subjects when you beamform with DICS you may be missing some of >>> the effect (true, this is also the case for channel data but there >>> may be subtle differences that add up - there are many voxels and >>> few channels). I believe it may be useful to see what happens when >>> you run the beamformer tailored to each subject's particular beta >>> characteristics (ie change the "foi" for each subject, keep the >>> tapsmofrq the same - possibly smaller) and then combine everything >>> (you'll need of course to come up with a relative metric such as >>> perc. change when you combine all subjects to account for the >>> slightly different frequencies you used ) >>> >>> Best, >>> Haris >>> >>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>> >>> >>> >>> On 21 November 2013 10:36, Eelke Spaak >> > wrote: >>> >>> Fellow FieldTrippers, >>> >>> Currently I am looking at a contrast for left- versus >>> right-hand index >>> finger button presses. As expected, on sensor level (combined >>> planar >>> gradient, grand average) I see a clear lateralisation in beta band >>> power starting at least 0.5s before the button press (see >>> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >>> clearly more beta power ipsilateral to the response hand. I would >>> prefer to do further analyses on source level, so I attempt to >>> reconstruct the sources for this effect using DICS beamformer >>> (common >>> filter, applied to both conditions separately; fixedori and >>> realfilter >>> = 'yes'). The grand average results for this (again contrast >>> left vs >>> right response hand) are shown at https://db.tt/IBQZG0d8 . >>> (Ignore the >>> R/L-flip, this is radiological convention.) >>> >>> As you can see, the source level solution is much more blurry >>> than on >>> sensor level. This picture is without using any regularisation >>> (lambda >>> parameter), the results are even worse when I use lambda = >>> '5%'. The >>> negative blob (right hand higher power than left) becomes >>> 'marginally >>> significant' on source level (p ~ 0.06) where it was p < 0.001 on >>> sensor level. The positive blob is nowhere near significant. >>> Also, the >>> individual results are much less topographically consistent on >>> source >>> than on sensor level (explaining the worse statistics). >>> >>> I have checked the segmentation of my MRIs, the 'gray' seems to be >>> nicely within the head all the time. Also, I have manually >>> verified >>> the alignment of headmodel, sourcemodel, and gradiometer >>> information >>> for all subjects. >>> >>> As a final note, the above sensor-level plot was taken from a >>> 'slice' >>> out of a planar-gradient time-frequency analysis (mtmconvol). The >>> ingredient for the beamformer was an mtmfft fourier spectrum >>> on the >>> axial gradiometer data, obtained for just the time-frequency >>> range of >>> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >>> tapsmofrq = 7). >>> When I compute condition-averaged power based on these fourier >>> spectra >>> and look at the contrast, the results are again as expected: >>> https://db.tt/n2P3UKcQ (of course less localised because of axial >>> gradient vs planar). The freq structures underlying this >>> contrast are >>> exactly the same as those going into ft_sourceanalysis, so the >>> problem >>> must be in the source analysis step (and/or in the preparation >>> of the >>> geometric information, although these seem fine by visual >>> inspection). >>> >>> Does anyone have any idea that might explain these seemingly >>> contradictory results? I would have expected demixing to improve >>> signal-to-noise ratio, rather than worsen it. >>> >>> Thanks! >>> Best, >>> Eelke >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Fri Nov 22 09:11:25 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 22 Nov 2013 09:11:25 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> Message-ID: <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> To all, This reply should have gone to Eelke and not to the whole list. Apologies for that. For those who understand Dutch: doe er je voordeel mee. Groeten, Jan-Mathijs On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: > Hoi Eelke, > > Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de forward module verwacht. Ik gok dat de high-level functies dit niet afdwingen, waardoor de leadfields er bekaaid van af komen. > > Gr, > JM > > On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > >> Hi everyone, >> >> Thanks very much for your great input so far! Actually, as Jörn >> suggested, I did the very straightforward check (thanks for the tip :) >> ) of running one of our tutorial test scripts >> (test_beamforming_extended), and it turns out this one does not >> produce the same results as depicted here: >> http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most >> likely somewhere a bug has been introduced... >> >> Hopefully I can find out what it is today and fix it. Will keep you posted! >> >> Best, >> Eelke >> >> On 22 November 2013 08:06, "Jörn M. Horschig" wrote: >>> Hi Eelke, >>> >>> since everyone jumped on the train, here my 2 cents: >>> To verify whether this is a newly introduced bug, maybe run a tutorial test >>> script that includes beamforming. If they look alright, it gets more likely >>> that it is you or your data and not fieldtrip :) It's not definite evidence >>> of course though. SinceVitoria also experiences strange things, it might be >>> something worthwhile to investigate. >>> >>> My initial guess from the plots is that there is something wrong with the >>> forward model. All unit problems should have been resolved, but just to be >>> sure you could check whether all objects are in the same unit (make it 'cm' >>> as the grads are). >>> >>> Best, >>> Jörn >>> >>> Charidimos Tzagarakis wrote: >>>> >>>> Eelke, >>>> Thinking again about my second suggestion (regarding individual >>>> variability) I actually can't think of a case where this could realistically >>>> produce what you get. On the other hand, looking at TF maps per subject and >>>> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >>>> spot something unusual. >>>> Best, >>>> Haris >>>> >>>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>>> >>>> >>>> >>>> On 21 November 2013 18:09, Charidimos Tzagarakis >>> > wrote: >>>> >>>> Hi Eelke, >>>> Provided there is no major recent revision of the DICS code, I >>>> would have expected motor desynchronisation to show up pretty >>>> well. Are the maps shown at source and channel level straight >>>> differences of L and Right hand conditions at the beta band (I >>>> hope I am correctly interpreting your paradigm) ? If so it might >>>> be helpful in pinpointing the problem/as a sanity check to see >>>> what happens when you use beta desynchonisation (ie change >>>> relative to the baseline) instead for each condition, and see >>>> source/channel maps of that separately for L and R and then when >>>> you take the difference. I suppose the main element this checks >>>> for is whether L and R conditions have the same baseline. >>>> This doesn't immediately explain why source and channel results >>>> are different but in the absence of any other clues it may be a >>>> way to 2ble check the whole process. >>>> >>>> >>>> Another point to consider is that, although beta changes should >>>> appear in all subjects, it is possibly true that there are >>>> individual differences in the actual beta range and frequency bin >>>> of maximum effect. If you are using the same settings for all >>>> subjects when you beamform with DICS you may be missing some of >>>> the effect (true, this is also the case for channel data but there >>>> may be subtle differences that add up - there are many voxels and >>>> few channels). I believe it may be useful to see what happens when >>>> you run the beamformer tailored to each subject's particular beta >>>> characteristics (ie change the "foi" for each subject, keep the >>>> tapsmofrq the same - possibly smaller) and then combine everything >>>> (you'll need of course to come up with a relative metric such as >>>> perc. change when you combine all subjects to account for the >>>> slightly different frequencies you used ) >>>> >>>> Best, >>>> Haris >>>> >>>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>>> >>>> >>>> >>>> On 21 November 2013 10:36, Eelke Spaak >>> > wrote: >>>> >>>> Fellow FieldTrippers, >>>> >>>> Currently I am looking at a contrast for left- versus >>>> right-hand index >>>> finger button presses. As expected, on sensor level (combined >>>> planar >>>> gradient, grand average) I see a clear lateralisation in beta band >>>> power starting at least 0.5s before the button press (see >>>> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >>>> clearly more beta power ipsilateral to the response hand. I would >>>> prefer to do further analyses on source level, so I attempt to >>>> reconstruct the sources for this effect using DICS beamformer >>>> (common >>>> filter, applied to both conditions separately; fixedori and >>>> realfilter >>>> = 'yes'). The grand average results for this (again contrast >>>> left vs >>>> right response hand) are shown at https://db.tt/IBQZG0d8 . >>>> (Ignore the >>>> R/L-flip, this is radiological convention.) >>>> >>>> As you can see, the source level solution is much more blurry >>>> than on >>>> sensor level. This picture is without using any regularisation >>>> (lambda >>>> parameter), the results are even worse when I use lambda = >>>> '5%'. The >>>> negative blob (right hand higher power than left) becomes >>>> 'marginally >>>> significant' on source level (p ~ 0.06) where it was p < 0.001 on >>>> sensor level. The positive blob is nowhere near significant. >>>> Also, the >>>> individual results are much less topographically consistent on >>>> source >>>> than on sensor level (explaining the worse statistics). >>>> >>>> I have checked the segmentation of my MRIs, the 'gray' seems to be >>>> nicely within the head all the time. Also, I have manually >>>> verified >>>> the alignment of headmodel, sourcemodel, and gradiometer >>>> information >>>> for all subjects. >>>> >>>> As a final note, the above sensor-level plot was taken from a >>>> 'slice' >>>> out of a planar-gradient time-frequency analysis (mtmconvol). The >>>> ingredient for the beamformer was an mtmfft fourier spectrum >>>> on the >>>> axial gradiometer data, obtained for just the time-frequency >>>> range of >>>> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >>>> tapsmofrq = 7). >>>> When I compute condition-averaged power based on these fourier >>>> spectra >>>> and look at the contrast, the results are again as expected: >>>> https://db.tt/n2P3UKcQ (of course less localised because of axial >>>> gradient vs planar). The freq structures underlying this >>>> contrast are >>>> exactly the same as those going into ft_sourceanalysis, so the >>>> problem >>>> must be in the source analysis step (and/or in the preparation >>>> of the >>>> geometric information, although these seem fine by visual >>>> inspection). >>>> >>>> Does anyone have any idea that might explain these seemingly >>>> contradictory results? I would have expected demixing to improve >>>> signal-to-noise ratio, rather than worsen it. >>>> >>>> Thanks! >>>> Best, >>>> Eelke >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Fri Nov 22 11:51:08 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 11:51:08 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> References: <528F0277.5070200@donders.ru.nl> <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> Message-ID: Following this up: Jan-Mathijs' suggestion did the trick (as usual, thanks), at least for the tutorial code. It turns out that it is now required to explicitly convert the geometric objects to 'm' before doing source analysis. I am certain that this was not required in the past, as I taught workshops with the beamforming-extended tutorial where we did not do the unit conversion and results looked fine. So now we will investigate what exactly changed and make sure that either the conversion is done automatically or the user is informed of non-matching units. Best, Eelke On 22 November 2013 09:11, jan-mathijs schoffelen wrote: > To all, > > This reply should have gone to Eelke and not to the whole list. Apologies > for that. For those who understand Dutch: doe er je voordeel mee. > > Groeten, > Jan-Mathijs > > > > On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: > > Hoi Eelke, > > Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, > sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de > forward module verwacht. Ik gok dat de high-level functies dit niet > afdwingen, waardoor de leadfields er bekaaid van af komen. > > Gr, > JM > > On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > > Hi everyone, > > Thanks very much for your great input so far! Actually, as Jörn > suggested, I did the very straightforward check (thanks for the tip :) > ) of running one of our tutorial test scripts > (test_beamforming_extended), and it turns out this one does not > produce the same results as depicted here: > http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most > likely somewhere a bug has been introduced... > > Hopefully I can find out what it is today and fix it. Will keep you posted! > > Best, > Eelke > > On 22 November 2013 08:06, "Jörn M. Horschig" > wrote: > > Hi Eelke, > > > since everyone jumped on the train, here my 2 cents: > > To verify whether this is a newly introduced bug, maybe run a tutorial test > > script that includes beamforming. If they look alright, it gets more likely > > that it is you or your data and not fieldtrip :) It's not definite evidence > > of course though. SinceVitoria also experiences strange things, it might be > > something worthwhile to investigate. > > > My initial guess from the plots is that there is something wrong with the > > forward model. All unit problems should have been resolved, but just to be > > sure you could check whether all objects are in the same unit (make it 'cm' > > as the grads are). > > > Best, > > Jörn > > > Charidimos Tzagarakis wrote: > > > Eelke, > > Thinking again about my second suggestion (regarding individual > > variability) I actually can't think of a case where this could realistically > > produce what you get. On the other hand, looking at TF maps per subject and > > channel (on the "helmet" layout), normalised with a "rest" epoch, may help > > spot something unusual. > > Best, > > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 18:09, Charidimos Tzagarakis > > wrote: > > > Hi Eelke, > > Provided there is no major recent revision of the DICS code, I > > would have expected motor desynchronisation to show up pretty > > well. Are the maps shown at source and channel level straight > > differences of L and Right hand conditions at the beta band (I > > hope I am correctly interpreting your paradigm) ? If so it might > > be helpful in pinpointing the problem/as a sanity check to see > > what happens when you use beta desynchonisation (ie change > > relative to the baseline) instead for each condition, and see > > source/channel maps of that separately for L and R and then when > > you take the difference. I suppose the main element this checks > > for is whether L and R conditions have the same baseline. > > This doesn't immediately explain why source and channel results > > are different but in the absence of any other clues it may be a > > way to 2ble check the whole process. > > > > Another point to consider is that, although beta changes should > > appear in all subjects, it is possibly true that there are > > individual differences in the actual beta range and frequency bin > > of maximum effect. If you are using the same settings for all > > subjects when you beamform with DICS you may be missing some of > > the effect (true, this is also the case for channel data but there > > may be subtle differences that add up - there are many voxels and > > few channels). I believe it may be useful to see what happens when > > you run the beamformer tailored to each subject's particular beta > > characteristics (ie change the "foi" for each subject, keep the > > tapsmofrq the same - possibly smaller) and then combine everything > > (you'll need of course to come up with a relative metric such as > > perc. change when you combine all subjects to account for the > > slightly different frequencies you used ) > > > Best, > > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak > > wrote: > > > Fellow FieldTrippers, > > > Currently I am looking at a contrast for left- versus > > right-hand index > > finger button presses. As expected, on sensor level (combined > > planar > > gradient, grand average) I see a clear lateralisation in beta band > > power starting at least 0.5s before the button press (see > > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > > clearly more beta power ipsilateral to the response hand. I would > > prefer to do further analyses on source level, so I attempt to > > reconstruct the sources for this effect using DICS beamformer > > (common > > filter, applied to both conditions separately; fixedori and > > realfilter > > = 'yes'). The grand average results for this (again contrast > > left vs > > right response hand) are shown at https://db.tt/IBQZG0d8 . > > (Ignore the > > R/L-flip, this is radiological convention.) > > > As you can see, the source level solution is much more blurry > > than on > > sensor level. This picture is without using any regularisation > > (lambda > > parameter), the results are even worse when I use lambda = > > '5%'. The > > negative blob (right hand higher power than left) becomes > > 'marginally > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > sensor level. The positive blob is nowhere near significant. > > Also, the > > individual results are much less topographically consistent on > > source > > than on sensor level (explaining the worse statistics). > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > nicely within the head all the time. Also, I have manually > > verified > > the alignment of headmodel, sourcemodel, and gradiometer > > information > > for all subjects. > > > As a final note, the above sensor-level plot was taken from a > > 'slice' > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > ingredient for the beamformer was an mtmfft fourier spectrum > > on the > > axial gradiometer data, obtained for just the time-frequency > > range of > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, > > tapsmofrq = 7). > > When I compute condition-averaged power based on these fourier > > spectra > > and look at the contrast, the results are again as expected: > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > gradient vs planar). The freq structures underlying this > > contrast are > > exactly the same as those going into ft_sourceanalysis, so the > > problem > > must be in the source analysis step (and/or in the preparation > > of the > > geometric information, although these seem fine by visual > > inspection). > > > Does anyone have any idea that might explain these seemingly > > contradictory results? I would have expected demixing to improve > > signal-to-noise ratio, rather than worsen it. > > > Thanks! > > Best, > > Eelke > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Fri Nov 22 12:59:34 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 12:59:34 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> Message-ID: As confirmed by Robert, there is indeed a bug in the handling of distance units in ft_prepare_leadfield. This function will now (FTP release as of tonight) throw an error if units are not in agreement. Discussion of this bug will continue at http://bugzilla.fcdonders.nl/show_bug.cgi?id=2387 or at one of the related bugs. Cheers, Eelke On 22 November 2013 11:51, Eelke Spaak wrote: > Following this up: Jan-Mathijs' suggestion did the trick (as usual, > thanks), at least for the tutorial code. It turns out that it is now > required to explicitly convert the geometric objects to 'm' before > doing source analysis. > > I am certain that this was not required in the past, as I taught > workshops with the beamforming-extended tutorial where we did not do > the unit conversion and results looked fine. So now we will > investigate what exactly changed and make sure that either the > conversion is done automatically or the user is informed of > non-matching units. > > Best, > Eelke > > > On 22 November 2013 09:11, jan-mathijs schoffelen > wrote: >> To all, >> >> This reply should have gone to Eelke and not to the whole list. Apologies >> for that. For those who understand Dutch: doe er je voordeel mee. >> >> Groeten, >> Jan-Mathijs >> >> >> >> On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: >> >> Hoi Eelke, >> >> Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, >> sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de >> forward module verwacht. Ik gok dat de high-level functies dit niet >> afdwingen, waardoor de leadfields er bekaaid van af komen. >> >> Gr, >> JM >> >> On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: >> >> Hi everyone, >> >> Thanks very much for your great input so far! Actually, as Jörn >> suggested, I did the very straightforward check (thanks for the tip :) >> ) of running one of our tutorial test scripts >> (test_beamforming_extended), and it turns out this one does not >> produce the same results as depicted here: >> http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most >> likely somewhere a bug has been introduced... >> >> Hopefully I can find out what it is today and fix it. Will keep you posted! >> >> Best, >> Eelke >> >> On 22 November 2013 08:06, "Jörn M. Horschig" >> wrote: >> >> Hi Eelke, >> >> >> since everyone jumped on the train, here my 2 cents: >> >> To verify whether this is a newly introduced bug, maybe run a tutorial test >> >> script that includes beamforming. If they look alright, it gets more likely >> >> that it is you or your data and not fieldtrip :) It's not definite evidence >> >> of course though. SinceVitoria also experiences strange things, it might be >> >> something worthwhile to investigate. >> >> >> My initial guess from the plots is that there is something wrong with the >> >> forward model. All unit problems should have been resolved, but just to be >> >> sure you could check whether all objects are in the same unit (make it 'cm' >> >> as the grads are). >> >> >> Best, >> >> Jörn >> >> >> Charidimos Tzagarakis wrote: >> >> >> Eelke, >> >> Thinking again about my second suggestion (regarding individual >> >> variability) I actually can't think of a case where this could realistically >> >> produce what you get. On the other hand, looking at TF maps per subject and >> >> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >> >> spot something unusual. >> >> Best, >> >> Haris >> >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> >> On 21 November 2013 18:09, Charidimos Tzagarakis > >> > wrote: >> >> >> Hi Eelke, >> >> Provided there is no major recent revision of the DICS code, I >> >> would have expected motor desynchronisation to show up pretty >> >> well. Are the maps shown at source and channel level straight >> >> differences of L and Right hand conditions at the beta band (I >> >> hope I am correctly interpreting your paradigm) ? If so it might >> >> be helpful in pinpointing the problem/as a sanity check to see >> >> what happens when you use beta desynchonisation (ie change >> >> relative to the baseline) instead for each condition, and see >> >> source/channel maps of that separately for L and R and then when >> >> you take the difference. I suppose the main element this checks >> >> for is whether L and R conditions have the same baseline. >> >> This doesn't immediately explain why source and channel results >> >> are different but in the absence of any other clues it may be a >> >> way to 2ble check the whole process. >> >> >> >> Another point to consider is that, although beta changes should >> >> appear in all subjects, it is possibly true that there are >> >> individual differences in the actual beta range and frequency bin >> >> of maximum effect. If you are using the same settings for all >> >> subjects when you beamform with DICS you may be missing some of >> >> the effect (true, this is also the case for channel data but there >> >> may be subtle differences that add up - there are many voxels and >> >> few channels). I believe it may be useful to see what happens when >> >> you run the beamformer tailored to each subject's particular beta >> >> characteristics (ie change the "foi" for each subject, keep the >> >> tapsmofrq the same - possibly smaller) and then combine everything >> >> (you'll need of course to come up with a relative metric such as >> >> perc. change when you combine all subjects to account for the >> >> slightly different frequencies you used ) >> >> >> Best, >> >> Haris >> >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> >> On 21 November 2013 10:36, Eelke Spaak > >> > wrote: >> >> >> Fellow FieldTrippers, >> >> >> Currently I am looking at a contrast for left- versus >> >> right-hand index >> >> finger button presses. As expected, on sensor level (combined >> >> planar >> >> gradient, grand average) I see a clear lateralisation in beta band >> >> power starting at least 0.5s before the button press (see >> >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> >> clearly more beta power ipsilateral to the response hand. I would >> >> prefer to do further analyses on source level, so I attempt to >> >> reconstruct the sources for this effect using DICS beamformer >> >> (common >> >> filter, applied to both conditions separately; fixedori and >> >> realfilter >> >> = 'yes'). The grand average results for this (again contrast >> >> left vs >> >> right response hand) are shown at https://db.tt/IBQZG0d8 . >> >> (Ignore the >> >> R/L-flip, this is radiological convention.) >> >> >> As you can see, the source level solution is much more blurry >> >> than on >> >> sensor level. This picture is without using any regularisation >> >> (lambda >> >> parameter), the results are even worse when I use lambda = >> >> '5%'. The >> >> negative blob (right hand higher power than left) becomes >> >> 'marginally >> >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> >> sensor level. The positive blob is nowhere near significant. >> >> Also, the >> >> individual results are much less topographically consistent on >> >> source >> >> than on sensor level (explaining the worse statistics). >> >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> >> nicely within the head all the time. Also, I have manually >> >> verified >> >> the alignment of headmodel, sourcemodel, and gradiometer >> >> information >> >> for all subjects. >> >> >> As a final note, the above sensor-level plot was taken from a >> >> 'slice' >> >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> >> ingredient for the beamformer was an mtmfft fourier spectrum >> >> on the >> >> axial gradiometer data, obtained for just the time-frequency >> >> range of >> >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >> >> tapsmofrq = 7). >> >> When I compute condition-averaged power based on these fourier >> >> spectra >> >> and look at the contrast, the results are again as expected: >> >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> >> gradient vs planar). The freq structures underlying this >> >> contrast are >> >> exactly the same as those going into ft_sourceanalysis, so the >> >> problem >> >> must be in the source analysis step (and/or in the preparation >> >> of the >> >> geometric information, although these seem fine by visual >> >> inspection). >> >> >> Does anyone have any idea that might explain these seemingly >> >> contradictory results? I would have expected demixing to improve >> >> signal-to-noise ratio, rather than worsen it. >> >> >> Thanks! >> >> Best, >> >> Eelke >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From andrea.brovelli at univ-amu.fr Fri Nov 22 13:33:35 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Fri, 22 Nov 2013 13:33:35 +0100 (CET) Subject: [FieldTrip] Conjunction analysis In-Reply-To: <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> References: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> Message-ID: <85141893.13184.1385123615804.JavaMail.root@bureau-frontal2> Last comment on Conjunction analysis: I got an email from Thomas Nichols (2005, Neuroimage). In fact, things are much easier than expected, no special code is required. The conjunction is just the minimum of the two statistics (t-valeus, for example, or, equivalently, the maximum of the two p-values).  And this is independent of the type of statistical test used  (parametric or non-parametric). So, the implementation in ft_conjunctionanalysis should be safe. Bye Andrea andrea brovelli wrote:Thanks a lot for your reply, Arjen. It's clearer now. In fact, I am using a parametric tests, so I think I would need to use the Nichols 2005 method for the conjunction analysis. Does anyone have the code to do this or does anyone know how to recover it within SPM ? Thanks a lot Andrea "A.stolk" wrote:Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjen andrea brovelli schreef: Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip_______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From caspervanheck at gmail.com Fri Nov 22 13:36:22 2013 From: caspervanheck at gmail.com (Casper van Heck) Date: Fri, 22 Nov 2013 13:36:22 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Eelke, I was busy with some other stuff, and just now revisited the analysis. Even with a newer version of Fieldtrip, this is still happening, and I still do not know why... Have you had time to take a look at it? Sincerely, Casper On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck wrote: > Dear Eelke, > > I've put up an exerpt of my code, with the data from a single subject > (no.10, 9MB) in a separate folder here > . > It also includes a screenshot of what I see with when I run the code with > this exact dataset, and a small program 'filehandler', which I've been to > lazy to replace. > > Note that this specific subject only has about 60 seconds of data (and I'm > still waiting for the student to tell me why). > > I'm hoping you'll get the same result as the screenshot, and you'll be > able to tell me why... > > Best regards, > > Casper > > > On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak wrote: > >> Dear Casper, >> >> Could you maybe post a snippet online somewhere (e.g. dropbox) of data >> corresponding to this plot (i.e. the output of ft_freqanalysis that >> you input to ft_singleplotTFR, assuming that it's averaged over trials >> and therefore small)? Then we can see whether this is reproducable on >> our systems. >> >> Best, >> Eelke >> >> On 16 September 2013 17:12, Casper van Heck >> wrote: >> > Dear Fieldtrippers, >> > >> > I've been doing some exploratory plotting of a dataset where several >> > subjects were exposed to a continuous stimulus (CPM) over the course of >> > three minutes. One of the things that was asked was a time-frequency >> plot, >> > over those three minutes. While I'm not quite sure a TFR can be used on >> that >> > scale without problems, I went ahead with it just to see what Fieldtrip >> > would do. What I got, was this: >> > http://tinypic.com/r/zx2tqs/5| >> > And I have no idea what went wrong (note that this specific subject >> only got >> > a 60s stimulus). Quality of the picture and the validity of the analysis >> > aside, I have a severe problem with the axes, which seem to be all over >> the >> > place. >> > >> > I simply read the data using ft_preprocessing (no filters or anything, >> since >> > the student in charge already used a 10Hz high-pass and a 150Hz low-pass >> > filter). >> > The only field in 'cfg' is 'headerfile'. >> > >> > Next, I call ft_freqanalysis with: >> > cfg.output = 'pow'; >> > cfg.method = 'wavelet'; % default; Morlet wavelet >> > cfg.taper = 'hanning'; >> > cfg.tapsmofrq = 4; >> > cfg.channel = 'Cz'; >> > cfg.foi = [20:0.5:30]; >> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; >> > cfg.toi = 0:0.5:60; >> > >> > And finally, I end up with the monstrocity shown earlier. This problem >> only >> > presents itself with Fieldtrip-related functions, the normal >> Matlab-plots >> > work as well as they've ever done, so I'm thinking it's something in >> > Fieldtrip that's causing this. >> > >> > My hope is that someone has encountered this problem before, and knows >> how >> > to solve it... >> > >> > Sincerely, >> > >> > Casper >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Fri Nov 22 16:40:28 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 16:40:28 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Casper, See attached the plots I get when running your script (on Windows/Linux Matlab 2011b/2012a). They seem quite OK to me, so I suspect the issue is in your Matlab installation and/or system (e.g. video drivers). One thing that could possibly help (though I would not understand why exactly) is to change the renderer, by trying out all three options for cfg.renderer = 'painters'/'zbuffer'/'opengl'. Or maybe you could try running another Matlab version? Sorry this is not more helpful, good luck figuring it out! Best, Eelke On 22 November 2013 13:36, Casper van Heck wrote: > Dear Eelke, > > I was busy with some other stuff, and just now revisited the analysis. Even > with a newer version of Fieldtrip, this is still happening, and I still do > not know why... > Have you had time to take a look at it? > > Sincerely, > > Casper > > > On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck > wrote: >> >> Dear Eelke, >> >> I've put up an exerpt of my code, with the data from a single subject >> (no.10, 9MB) in a separate folder here. >> It also includes a screenshot of what I see with when I run the code with >> this exact dataset, and a small program 'filehandler', which I've been to >> lazy to replace. >> >> Note that this specific subject only has about 60 seconds of data (and I'm >> still waiting for the student to tell me why). >> >> I'm hoping you'll get the same result as the screenshot, and you'll be >> able to tell me why... >> >> Best regards, >> >> Casper >> >> >> On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak >> wrote: >>> >>> Dear Casper, >>> >>> Could you maybe post a snippet online somewhere (e.g. dropbox) of data >>> corresponding to this plot (i.e. the output of ft_freqanalysis that >>> you input to ft_singleplotTFR, assuming that it's averaged over trials >>> and therefore small)? Then we can see whether this is reproducable on >>> our systems. >>> >>> Best, >>> Eelke >>> >>> On 16 September 2013 17:12, Casper van Heck >>> wrote: >>> > Dear Fieldtrippers, >>> > >>> > I've been doing some exploratory plotting of a dataset where several >>> > subjects were exposed to a continuous stimulus (CPM) over the course of >>> > three minutes. One of the things that was asked was a time-frequency >>> > plot, >>> > over those three minutes. While I'm not quite sure a TFR can be used on >>> > that >>> > scale without problems, I went ahead with it just to see what Fieldtrip >>> > would do. What I got, was this: >>> > http://tinypic.com/r/zx2tqs/5| >>> > And I have no idea what went wrong (note that this specific subject >>> > only got >>> > a 60s stimulus). Quality of the picture and the validity of the >>> > analysis >>> > aside, I have a severe problem with the axes, which seem to be all over >>> > the >>> > place. >>> > >>> > I simply read the data using ft_preprocessing (no filters or anything, >>> > since >>> > the student in charge already used a 10Hz high-pass and a 150Hz >>> > low-pass >>> > filter). >>> > The only field in 'cfg' is 'headerfile'. >>> > >>> > Next, I call ft_freqanalysis with: >>> > cfg.output = 'pow'; >>> > cfg.method = 'wavelet'; % default; Morlet wavelet >>> > cfg.taper = 'hanning'; >>> > cfg.tapsmofrq = 4; >>> > cfg.channel = 'Cz'; >>> > cfg.foi = [20:0.5:30]; >>> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; >>> > cfg.toi = 0:0.5:60; >>> > >>> > And finally, I end up with the monstrocity shown earlier. This problem >>> > only >>> > presents itself with Fieldtrip-related functions, the normal >>> > Matlab-plots >>> > work as well as they've ever done, so I'm thinking it's something in >>> > Fieldtrip that's causing this. >>> > >>> > My hope is that someone has encountered this problem before, and knows >>> > how >>> > to solve it... >>> > >>> > Sincerely, >>> > >>> > Casper >>> > >>> > >>> > _______________________________________________ >>> > fieldtrip mailing list >>> > fieldtrip at donders.ru.nl >>> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- A non-text attachment was scrubbed... Name: mytfr-linux-matlab2012a-64bit.png Type: image/png Size: 25742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mytfr-windows-matlab2011b-64bit.png Type: image/png Size: 34916 bytes Desc: not available URL: From trdavenp at cogsci.ucsd.edu Fri Nov 22 20:35:31 2013 From: trdavenp at cogsci.ucsd.edu (Tristan Davenport) Date: Fri, 22 Nov 2013 11:35:31 -0800 Subject: [FieldTrip] ft_artifact_threshold and the return of the "unit circle" error Message-ID: I'm trying to import and analyze some Neuromag 306 data, and I keep running into the following error message whenever I try to detect blink artifacts with the threshold method: *??? Error using ==> filter_with_correction at 44 Calculated filter coefficients have poles on or outside the unit circle and will not be stable. Try a higher cutoff frequency or a different type/order of filter.Error in ==> filter_with_correction at 44 error('Calculated filter coefficients have poles on or outside the unit circle and will not be stable. Try a higher cutoff frequency or a different type/order of filter.');Error in ==> ft_preproc_bandpassfilter at 148 filt = filter_with_correction(B,A,dat,dir);Error in ==> preproc at 299if strcmp(cfg.bpfilter, 'yes'), dat = ft_preproc_bandpassfilter(dat, fsample, cfg.bpfreq, cfg.bpfiltord, cfg.bpfilttype, cfg.bpfiltdir, cfg.bpinstabilityfix); endError in ==> ft_artifact_threshold at 148 dat = preproc(dat, channel, offset2time(cfg.trl(trlop,3), hdr.Fs, size(dat,2)), artfctdef); * Based on previous advice in these threads, I have tried changing the cutoff frequency, order, direction, and type of filtering of my data using cfg fields like bpfreq, bpfilttype, bpfiltdir, and bpinstabilityfix. Long story short, I've tried every logically possible combination of filter settings (including no filtering at all), and I get the same error regardless. Does anyone have some insight into this? Take care, Tristan Davenport UC San Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Mon Nov 25 17:16:41 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Mon, 25 Nov 2013 17:16:41 +0100 Subject: [FieldTrip] Error in ft_fetch_data (line 99) Message-ID: Dear Field Trip user. I sometimes experience an error in ft_fetch_data (line 99) usually with the last trial after epoching continuous Neuromag 306 channel FIF data into trials. I suspect that there might be something wrong with my trial definitions or the data, but I don't understand the error messages. I had to concatenate the continuous data and the trial definitions, because the raw data was split into two files during recording, however all the concatenated continuous data can be seen clearly by using the ft_databrowser and the trial definition onset times and event values also looks reasonable. I wonder what could be the problem, and if there could be a solution to avoid this occasional error? (The simple solution would of course be just to remove the occasional trials with error, but then to loose some trials). Thank you if you have any comments or suggestions. Greetings Niels. This is the error messages that shows up if I try to show the "problematic" trial in ft_databrowser: Error in ft_fetch_data (line 99) count(trlbeg:trlend) = count(trlbeg:trlend) + 1; Error in ft_databrowser>redraw_cb (line 1458) dat = ft_fetch_data(opt.orgdata, 'header', opt.hdr, 'begsample', begsample, 'endsample', endsample, 'chanindx', chanindx, 'allowoverlap', true); % ALLOWING OVERLAPPING TRIALS Error in ft_databrowser>keyboard_cb (line 1232) redraw_cb(h, eventdata); Error while evaluating uicontrol Callback This is the error messages that is shown when I try to run ft_artifact_zvalue on the trials: Warning: -clear > In utilities/private/warning_once at 116 In utilities/private/ft_preamble_init at 26 In ft_preamble at 54 In ft_artifact_zvalue at 110 searching for artifacts in 102 channels searching trials.Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Index exceeds matrix dimensions. Error in ft_fetch_data (line 99) count(trlbeg:trlend) = count(trlbeg:trlend) + 1; Error in ft_artifact_zvalue (line 262) dat{trlop} = ft_fetch_data(data, 'header', hdr, 'begsample', trl(trlop,1)-fltpadding, 'endsample', trl(trlop,2)+fltpadding, 'chanindx', sgnind, 'checkboundary', strcmp(cfg.continuous,'no Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Mon Nov 25 17:26:17 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Mon, 25 Nov 2013 17:26:17 +0100 Subject: [FieldTrip] Error in ft_fetch_data (line 99) In-Reply-To: References: Message-ID: PS: Apparently, ft_rejectvisual can succesfully process show the occasional trials that causes errors with ft_databrowser and ft_artifact_zvalue. FieldTrip discussion list writes: >Dear Field Trip user. > >I sometimes experience an error in ft_fetch_data (line 99) usually with the last trial after epoching continuous Neuromag 306 channel FIF data into trials. I suspect that there might be something wrong with my trial definitions or the data, but I don't understand the error messages. I had to concatenate the continuous data and the trial definitions, because the raw data was split into two files during recording, however all the concatenated continuous data can be seen clearly by using the >ft_databrowser and the trial definition onset times and event values also looks reasonable. > >I wonder what could be the problem, and if there could be a solution to avoid this occasional error? > >(The simple solution would of course be just to remove the occasional trials with error, but then to loose some trials). > >Thank you if you have any comments or suggestions. > >Greetings >Niels. > >This is the error messages that shows up if I try to show the "problematic" trial in ft_databrowser: > >Error in ft_fetch_data (line 99) > � � � � � count(trlbeg:trlend) = count(trlbeg:trlend) + 1; > >Error in ft_databrowser>redraw_cb (line 1458) > � dat = ft_fetch_data(opt.orgdata, 'header', opt.hdr, 'begsample', begsample, 'endsample', endsample, > � 'chanindx', chanindx, 'allowoverlap', true); % ALLOWING OVERLAPPING TRIALS > >Error in ft_databrowser>keyboard_cb (line 1232) > � � � redraw_cb(h, eventdata); > >Error while evaluating uicontrol Callback > >This is the error messages that is shown when I try to run ft_artifact_zvalue on the trials: > >Warning: -clear >> In utilities/private/warning_once at 116 > � In utilities/private/ft_preamble_init at 26 > � In ft_preamble at 54 > � In ft_artifact_zvalue at 110 >searching for artifacts in 102 channels >searching trials.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Index exceeds matrix dimensions. > >Error in ft_fetch_data (line 99) > � � � � � count(trlbeg:trlend) = count(trlbeg:trlend) + 1; > >Error in ft_artifact_zvalue (line 262) > � � � � � dat{trlop} = ft_fetch_data(data, � � � � � � � 'header', hdr, 'begsample', trl(trlop,1)-fltpadding, > � � � � � 'endsample', trl(trlop,2)+fltpadding, 'chanindx', sgnind, 'checkboundary', > � � � � � strcmp(cfg.continuous,'no > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayobimpe2004 at hotmail.com Tue Nov 26 01:49:51 2013 From: ayobimpe2004 at hotmail.com (Azeez Adebimpe) Date: Tue, 26 Nov 2013 01:49:51 +0100 Subject: [FieldTrip] trial definition Message-ID: Hello everyone,I have a continuous cnt eeg file. There is no event and I want to divide it into several epochs. please it is normal to use this:?cfg.trialdef.triallength = duration in seconds (can also be 1 or Inf) cfg.trialdef.ntrials = number of trials (can also be 1 or Inf)Please if there is other way to define the trial, please kindly let me know. Best regards, Azeez Adebimpe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-baptiste.versini at etu.univ-lyon1.fr Tue Nov 26 11:12:36 2013 From: jean-baptiste.versini at etu.univ-lyon1.fr (VERSINI JEAN-BAPTISTE p1207642) Date: Tue, 26 Nov 2013 10:12:36 +0000 Subject: [FieldTrip] RE : trial definition In-Reply-To: References: Message-ID: <5271B6068CD8D94DB82254228237928801790560@mbx2010-02.univ-lyon1.fr> Hello, I have no idea if what you're currently doing works but maybe you should consider making your own trial function : http://fieldtrip.fcdonders.nl/example/making_your_own_trialfun_for_conditional_trial_definition regards, JB ________________________________ De : fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] de la part de Azeez Adebimpe [ayobimpe2004 at hotmail.com] Date d'envoi : mardi 26 novembre 2013 01:49 À : fieldtrip at science.ru.nl Objet : [FieldTrip] trial definition Hello everyone, I have a continuous cnt eeg file. There is no event and I want to divide it into several epochs. please it is normal to use this:? cfg.trialdef.triallength = duration in seconds (can also be 1 or Inf) cfg.trialdef.ntrials = number of trials (can also be 1 or Inf) Please if there is other way to define the trial, please kindly let me know. Best regards, Azeez Adebimpe -------------- next part -------------- An HTML attachment was scrubbed... URL: From caspervanheck at gmail.com Tue Nov 26 12:25:11 2013 From: caspervanheck at gmail.com (Casper van Heck) Date: Tue, 26 Nov 2013 12:25:11 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Eelke, I've tried it with the painters, zbuffer, and opengl, using Matlab 2011a and 2013a (giving me the 'not yet supported'-error), with the same results. I think I'll try it at home, later, and if that fails, I'll get the ICT-people to reinstall the whole thing. Thanks! Casper On Fri, Nov 22, 2013 at 4:40 PM, Eelke Spaak wrote: > Dear Casper, > > See attached the plots I get when running your script (on > Windows/Linux Matlab 2011b/2012a). They seem quite OK to me, so I > suspect the issue is in your Matlab installation and/or system (e.g. > video drivers). > > One thing that could possibly help (though I would not understand why > exactly) is to change the renderer, by trying out all three options > for cfg.renderer = 'painters'/'zbuffer'/'opengl'. Or maybe you could > try running another Matlab version? > > Sorry this is not more helpful, good luck figuring it out! > > Best, > Eelke > > On 22 November 2013 13:36, Casper van Heck > wrote: > > Dear Eelke, > > > > I was busy with some other stuff, and just now revisited the analysis. > Even > > with a newer version of Fieldtrip, this is still happening, and I still > do > > not know why... > > Have you had time to take a look at it? > > > > Sincerely, > > > > Casper > > > > > > On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck < > caspervanheck at gmail.com> > > wrote: > >> > >> Dear Eelke, > >> > >> I've put up an exerpt of my code, with the data from a single subject > >> (no.10, 9MB) in a separate folder here. > >> It also includes a screenshot of what I see with when I run the code > with > >> this exact dataset, and a small program 'filehandler', which I've been > to > >> lazy to replace. > >> > >> Note that this specific subject only has about 60 seconds of data (and > I'm > >> still waiting for the student to tell me why). > >> > >> I'm hoping you'll get the same result as the screenshot, and you'll be > >> able to tell me why... > >> > >> Best regards, > >> > >> Casper > >> > >> > >> On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak > > >> wrote: > >>> > >>> Dear Casper, > >>> > >>> Could you maybe post a snippet online somewhere (e.g. dropbox) of data > >>> corresponding to this plot (i.e. the output of ft_freqanalysis that > >>> you input to ft_singleplotTFR, assuming that it's averaged over trials > >>> and therefore small)? Then we can see whether this is reproducable on > >>> our systems. > >>> > >>> Best, > >>> Eelke > >>> > >>> On 16 September 2013 17:12, Casper van Heck > >>> wrote: > >>> > Dear Fieldtrippers, > >>> > > >>> > I've been doing some exploratory plotting of a dataset where several > >>> > subjects were exposed to a continuous stimulus (CPM) over the course > of > >>> > three minutes. One of the things that was asked was a time-frequency > >>> > plot, > >>> > over those three minutes. While I'm not quite sure a TFR can be used > on > >>> > that > >>> > scale without problems, I went ahead with it just to see what > Fieldtrip > >>> > would do. What I got, was this: > >>> > http://tinypic.com/r/zx2tqs/5| > >>> > And I have no idea what went wrong (note that this specific subject > >>> > only got > >>> > a 60s stimulus). Quality of the picture and the validity of the > >>> > analysis > >>> > aside, I have a severe problem with the axes, which seem to be all > over > >>> > the > >>> > place. > >>> > > >>> > I simply read the data using ft_preprocessing (no filters or > anything, > >>> > since > >>> > the student in charge already used a 10Hz high-pass and a 150Hz > >>> > low-pass > >>> > filter). > >>> > The only field in 'cfg' is 'headerfile'. > >>> > > >>> > Next, I call ft_freqanalysis with: > >>> > cfg.output = 'pow'; > >>> > cfg.method = 'wavelet'; % default; Morlet wavelet > >>> > cfg.taper = 'hanning'; > >>> > cfg.tapsmofrq = 4; > >>> > cfg.channel = 'Cz'; > >>> > cfg.foi = [20:0.5:30]; > >>> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; > >>> > cfg.toi = 0:0.5:60; > >>> > > >>> > And finally, I end up with the monstrocity shown earlier. This > problem > >>> > only > >>> > presents itself with Fieldtrip-related functions, the normal > >>> > Matlab-plots > >>> > work as well as they've ever done, so I'm thinking it's something in > >>> > Fieldtrip that's causing this. > >>> > > >>> > My hope is that someone has encountered this problem before, and > knows > >>> > how > >>> > to solve it... > >>> > > >>> > Sincerely, > >>> > > >>> > Casper > >>> > > >>> > > >>> > _______________________________________________ > >>> > fieldtrip mailing list > >>> > fieldtrip at donders.ru.nl > >>> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >>> _______________________________________________ > >>> fieldtrip mailing list > >>> fieldtrip at donders.ru.nl > >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > >> > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bingshuo.li at student.uni-tuebingen.de Tue Nov 26 18:26:26 2013 From: bingshuo.li at student.uni-tuebingen.de (Bingshuo Li) Date: Tue, 26 Nov 2013 18:26:26 +0100 Subject: [FieldTrip] ICA in TMS-EEG Message-ID: Dear FieldTrip Community, I recently started to analyze some TMS-EEG datasets and I encountered some questions regarding to using ICA to remove eye movement/muscle artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to inquire the FT community for some hints or suggestions. Below are the details of my questions: //Description of Data Processing// - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance less than 5 kOhm - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per subject) - TMS contaminated data points were cut out symmetrically -18ms to +18ms relative to TMS onset. Cubic spline interpolation is used to fill in the cut. - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line noise - Visual inspection and rejection of trials with obvious unstable signal or channels. //ICA// - ICA algorithm: runica - Demeaned data for ICA training (baseline is defined as the entire epoch -1 to +1s) - Unmixing matrix applied to non-demeaned data for component removal /////QUESTIONS///// Please see the image below for a typical result of ICA from a subject with TMS applied at M1 (32 epochs for ICA training): https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. However, what about component 5, 12, 20, 28? Topology-wise, they seem to have a very anterior origin, but data in the time domain does not seem to correlate with component 1 and 2 very well (judging visually..) Q2: What can you say about components 7, 9, 13 and 18? Are these cranial muscle artifacts? Q3: Also, for components 42 and 54, given their high focality, are these more or less a indication of bad/unstable electrodes? - I guess maybe I am asking too many questions. I think my main problem here is that I do not know what can be a good procedure / rules in manually selecting ICA components for rejection? (I tried to look in the literature but I couldn't find any that can answer my questions). And sometime I have the feeling that my ICA results look like a mess and maybe there were something wrong with my pre-processing or even data collection? Thank you guys in advance for any input! I look forward to hearing from you! Regards, Bingshuo Li MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 26 19:30:06 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 26 Nov 2013 13:30:06 -0500 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: Message-ID: Hi Bingshuo, I'm not sure what your code for the ICA is, but it may be beneficial to have the topoplots lined up with the signal, as I find it easier to recognize EOG and ECG artifacts in the signal. The following tutorials explain ICA: http://fieldtrip.fcdonders.nl/example/use_independent_component_analysis_ica_to_remove_ecg_artifacts http://fieldtrip.fcdonders.nl/example/use_independent_component_analysis_ica_to_remove_eog_artifacts In the ECG tutorial, they give a line of code: cfg = []; cfg.channel = {comp.label{2:5} comp.label{15:18}}; % components to be plotted cfg.layout = 'CTF275.lay'; % specify the layout file that should be used for plotting ft_databrowser(cfg, comp) Which outputs the topoplot and the time course of the signal together in a component browser. As far as criteria for correction, our policy is to err on the conservative side; only rejecting EOG and ECG artifacts, even if we find other components that are clearly artifactual (such as are picking up line noise). Without seeing your script, I can't really think of anything offhand that you are doing wrong, but I'm also not very familiar with TMS so there may be someone else who could answer that part of the question better. Good luck, Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Tue, Nov 26, 2013 at 12:26 PM, Bingshuo Li < bingshuo.li at student.uni-tuebingen.de> wrote: > Dear FieldTrip Community, > > I recently started to analyze some TMS-EEG datasets and I encountered some > questions regarding to using ICA to remove eye movement/muscle artifacts in > our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to > inquire the FT community for some hints or suggestions. Below are the > details of my questions: > > //Description of Data Processing// > - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance > less than 5 kOhm > - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per > subject) > - TMS contaminated data points were cut out symmetrically -18ms to +18ms > relative to TMS onset. Cubic spline interpolation is used to fill in the > cut. > - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. > - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line > noise > - Visual inspection and rejection of trials with obvious unstable signal > or channels. > > //ICA// > - ICA algorithm: runica > - Demeaned data for ICA training (baseline is defined as the entire epoch > -1 to +1s) > - Unmixing matrix applied to non-demeaned data for component removal > > /////QUESTIONS///// > Please see the image below for a typical result of ICA from a subject with > TMS applied at M1 (32 epochs for ICA training): > https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png > > Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. > However, what about component 5, 12, 20, 28? Topology-wise, they seem to > have a very anterior origin, but data in the time domain does not seem to > correlate with component 1 and 2 very well (judging visually..) > > Q2: What can you say about components 7, 9, 13 and 18? Are these cranial > muscle artifacts? > > Q3: Also, for components 42 and 54, given their high focality, are these > more or less a indication of bad/unstable electrodes? > > - I guess maybe I am asking too many questions. I think my main problem > here is that I do not know what can be a good procedure / rules in manually > selecting ICA components for rejection? (I tried to look in the literature > but I couldn't find any that can answer my questions). And sometime I have > the feeling that my ICA results look like a mess and maybe there were > something wrong with my pre-processing or even data collection? > > Thank you guys in advance for any input! I look forward to hearing from > you! > > Regards, > > Bingshuo Li > MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.herring at fcdonders.ru.nl Wed Nov 27 09:28:56 2013 From: j.herring at fcdonders.ru.nl (Herring, J.D. (Jim)) Date: Wed, 27 Nov 2013 09:28:56 +0100 (CET) Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: Message-ID: <012d01ceeb4a$b6ff3950$24fdabf0$@herring@fcdonders.ru.nl> Dear Bingshuo, I agree with Max that it would be beneficial to see the timecourses as well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock average the time courses of the ICA components to the onset of the TMS pulse. That helps in identifying components that are related to the TMS pulse. Just from looking at the topographies I would say that component 7 is too posterior for being a cranial muscle artifact given that you are stimulating M1. Also, cranial muscle artifacts related to the TMS pulse usually last up to about 15ms after stimulation onset (see for example: http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.p ng?id=tutorial%3Atms-eeg ) unless you are actually referring to a decay artifact (http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tu torial%3Atms-eeg) , which can last up to one second. You said that you cut and interpolated up to 18ms after stimulation so you should not see any cranial muscle artifacts related to TMS. Too me component 7 looks more like a topography related to posterior alpha oscillations, however, to be sure we need to see the time courses. Component 13 and 18 might be neck muscle artifacts, however, without performing a timelock analysis of the ICA components and inspecting the time courses it is hard to tell whether these are due to the TMS-pulse. Component 42 and 54 could indeed just reflect two bad channels, at least they seem to contain some variance that cannot be explained by a combination of the other channels. Best, Jim From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Bingshuo Li Sent: dinsdag 26 november 2013 18:26 To: fieldtrip at science.ru.nl Subject: [FieldTrip] ICA in TMS-EEG Dear FieldTrip Community, I recently started to analyze some TMS-EEG datasets and I encountered some questions regarding to using ICA to remove eye movement/muscle artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to inquire the FT community for some hints or suggestions. Below are the details of my questions: //Description of Data Processing// - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance less than 5 kOhm - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per subject) - TMS contaminated data points were cut out symmetrically -18ms to +18ms relative to TMS onset. Cubic spline interpolation is used to fill in the cut. - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line noise - Visual inspection and rejection of trials with obvious unstable signal or channels. //ICA// - ICA algorithm: runica - Demeaned data for ICA training (baseline is defined as the entire epoch -1 to +1s) - Unmixing matrix applied to non-demeaned data for component removal /////QUESTIONS///// Please see the image below for a typical result of ICA from a subject with TMS applied at M1 (32 epochs for ICA training): https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. However, what about component 5, 12, 20, 28? Topology-wise, they seem to have a very anterior origin, but data in the time domain does not seem to correlate with component 1 and 2 very well (judging visually..) Q2: What can you say about components 7, 9, 13 and 18? Are these cranial muscle artifacts? Q3: Also, for components 42 and 54, given their high focality, are these more or less a indication of bad/unstable electrodes? - I guess maybe I am asking too many questions. I think my main problem here is that I do not know what can be a good procedure / rules in manually selecting ICA components for rejection? (I tried to look in the literature but I couldn't find any that can answer my questions). And sometime I have the feeling that my ICA results look like a mess and maybe there were something wrong with my pre-processing or even data collection? Thank you guys in advance for any input! I look forward to hearing from you! Regards, Bingshuo Li MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Wed Nov 27 14:59:16 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Wed, 27 Nov 2013 08:59:16 -0500 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> References: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Dear J.D., Max and Bingshuo, A brief comment: to be more confident about the correlative nature of an artifact being an artifact (a.k.a. unwanted interference) I always consider three things: topographies, time courses and spectra. The last one too, since it might inform about spectral components not evident at the bare eye from the time courses. I'm not familiar with artifacts in TMS, but in all cases experience helps, especially if you see the same pattern in many subjects, in other published studies, from colleagues' data or from independent evidence (e.g. concomitant electromiography recorded from the facial muscles, for muscular artifacts identification). HTH Cristiano On Wed, Nov 27, 2013 at 3:28 AM, Herring, J.D. (Jim) < j.herring at fcdonders.ru.nl> wrote: > Dear Bingshuo, > > > > I agree with Max that it would be beneficial to see the timecourses as > well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock > average the time courses of the ICA components to the onset of the TMS > pulse. That helps in identifying components that are related to the TMS > pulse. > > > > Just from looking at the topographies I would say that component 7 is too > posterior for being a cranial muscle artifact given that you are > stimulating M1. Also, cranial muscle artifacts related to the TMS pulse > usually last up to about 15ms after stimulation onset (see for example: > http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.png?id=tutorial%3Atms-eeg) unless you are actually referring to a decay artifact ( > http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tutorial%3Atms-eeg) > , which can last up to one second. You said that you cut and interpolated > up to 18ms after stimulation so you should not see any cranial muscle > artifacts related to TMS. > > > > Too me component 7 looks more like a topography related to posterior alpha > oscillations, however, to be sure we need to see the time courses. > Component 13 and 18 might be neck muscle artifacts, however, without > performing a timelock analysis of the ICA components and inspecting the > time courses it is hard to tell whether these are due to the TMS-pulse. > > > > Component 42 and 54 could indeed just reflect two bad channels, at least > they seem to contain some variance that cannot be explained by a > combination of the other channels. > > > > Best, > > > > Jim > > > > *From:* fieldtrip-bounces at science.ru.nl [mailto: > fieldtrip-bounces at science.ru.nl] *On Behalf Of *Bingshuo Li > *Sent:* dinsdag 26 november 2013 18:26 > *To:* fieldtrip at science.ru.nl > *Subject:* [FieldTrip] ICA in TMS-EEG > > > > Dear FieldTrip Community, > > I recently started to analyze some TMS-EEG datasets and I encountered some > questions regarding to using ICA to remove eye movement/muscle artifacts in > our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to > inquire the FT community for some hints or suggestions. Below are the > details of my questions: > > //Description of Data Processing// > > - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance > less than 5 kOhm > > - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per > subject) > > - TMS contaminated data points were cut out symmetrically -18ms to +18ms > relative to TMS onset. Cubic spline interpolation is used to fill in the > cut. > > - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. > - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line > noise > > - Visual inspection and rejection of trials with obvious unstable signal > or channels. > > //ICA// > > - ICA algorithm: runica > > - Demeaned data for ICA training (baseline is defined as the entire epoch > -1 to +1s) > > - Unmixing matrix applied to non-demeaned data for component removal > > /////QUESTIONS///// > > Please see the image below for a typical result of ICA from a subject with > TMS applied at M1 (32 epochs for ICA training): > https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png > > Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. > However, what about component 5, 12, 20, 28? Topology-wise, they seem to > have a very anterior origin, but data in the time domain does not seem to > correlate with component 1 and 2 very well (judging visually..) > > Q2: What can you say about components 7, 9, 13 and 18? Are these cranial > muscle artifacts? > > Q3: Also, for components 42 and 54, given their high focality, are these > more or less a indication of bad/unstable electrodes? > > - I guess maybe I am asking too many questions. I think my main problem > here is that I do not know what can be a good procedure / rules in manually > selecting ICA components for rejection? (I tried to look in the literature > but I couldn't find any that can answer my questions). And sometime I have > the feeling that my ICA results look like a mess and maybe there were > something wrong with my pre-processing or even data collection? > > Thank you guys in advance for any input! I look forward to hearing from > you! > > Regards, > > Bingshuo Li > > MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgrande at cbs.mpg.de Wed Nov 27 16:28:46 2013 From: fgrande at cbs.mpg.de (Federico Grande) Date: Wed, 27 Nov 2013 16:28:46 +0100 (CET) Subject: [FieldTrip] Channel_selection Message-ID: <1142014025.14097.1385566126242.JavaMail.root@zimbra> Hello everyone, In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. Any suggestion? Thank you very much!! All the best, Federico Grande From jm.horschig at donders.ru.nl Wed Nov 27 16:46:56 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Wed, 27 Nov 2013 16:46:56 +0100 Subject: [FieldTrip] Channel_selection In-Reply-To: <1142014025.14097.1385566126242.JavaMail.root@zimbra> References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> Message-ID: <529613F0.7030801@donders.ru.nl> Hi Frederico, I think the best solution is to not use fieldtrip but plain matlab function. This is a small example that might help you: >> allchans = {'Fz', 'Cz', 'CPz'}; >> badchans = {'Fz', 'Cz'}; >> idx = ismember(allchans, badchans) idx = 1 1 0 You can then use the idx variable and logical indexing to get the good channels: >> allchans(~idx) ans = 'CPz' And then use cfg.channel = allchans(~idx). Be aware that ismember is a tricky function, because it returns the indices of the first vector as the first return variable and the respective same for the second vector as the second return variable, so order does matter. Just give it a try and play a bit around with it and you'll see. Best, Jörn Federico Grande wrote: > Hello everyone, > > In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. > > Any suggestion? > > Thank you very much!! > > All the best, > > Federico Grande > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands From mcantor at umich.edu Wed Nov 27 17:13:07 2013 From: mcantor at umich.edu (Max Cantor) Date: Wed, 27 Nov 2013 11:13:07 -0500 Subject: [FieldTrip] Channel_selection In-Reply-To: <529613F0.7030801@donders.ru.nl> References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> <529613F0.7030801@donders.ru.nl> Message-ID: Here is how I do it: allchan = ft_read_header(dataset); (preprocess) allchan.label = [allchan.label; implicitref]; (after artifact rejection/ICA/etc.) badchan = ft_channelselection('gui', allchan.label); This gives me the channel labels for all channels, with the implicitref added back in (normally this is removed), then a gui which lets me remove bad channels manually after preprocessing/artifact rejection/ICA/etc. Hope this helps. Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl> wrote: > Hi Frederico, > > I think the best solution is to not use fieldtrip but plain matlab > function. This is a small example that might help you: > > >> allchans = {'Fz', 'Cz', 'CPz'}; > >> badchans = {'Fz', 'Cz'}; > >> idx = ismember(allchans, badchans) > > idx = > > 1 1 0 > > You can then use the idx variable and logical indexing to get the good > channels: > > >> allchans(~idx) > > ans = > > 'CPz' > > And then use cfg.channel = allchans(~idx). > > Be aware that ismember is a tricky function, because it returns the > indices of the first vector as the first return variable and the respective > same for the second vector as the second return variable, so order does > matter. Just give it a try and play a bit around with it and you'll see. > > Best, > Jörn > > > > Federico Grande wrote: > >> Hello everyone, >> >> In order to clean a little bit more my measurements, I have developed a >> method which detects bad channels, and now, once I have the labels of the >> bad channels, I want to give it to ft_preprocessing, but I don't know how. >> I've been looking on ft_channelselection, and it seems that there is an >> option , by using some like channel={'all','-channel to exclude'}. I have >> an array with the labels of this channels that I want to exclude, but I >> don't know why, it seems that I am not using it in the proper way. I have >> tried with cfg.channel= {'all','-badSelections'} (badSelections is my >> array), and it doesn't work, since after processing, still appear all the >> channels in the dat.label. >> >> Any suggestion? >> >> Thank you very much!! >> >> All the best, >> >> Federico Grande >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.roux at bcbl.eu Wed Nov 27 19:14:26 2013 From: f.roux at bcbl.eu (=?utf-8?B?RnLDqWTDqXJpYw==?= Roux) Date: Wed, 27 Nov 2013 19:14:26 +0100 (CET) Subject: [FieldTrip] MEG-Ph.D. Studentship in Glasgow In-Reply-To: Message-ID: <1590326653.92591.1385576066623.JavaMail.root@bcbl.eu> On behalf of Peter Uhlhaas: Dear colleagues, I would like to alert you to a fully funded 3 ½ year Ph.D. studentship which is available at the Centre for Cognitive Neuroimaging , University of Glasgow. The project will use MEG to examine sensory predictions in patients with schizophrenia and will start in October 2014. The Ph.D. student will be supervised by Prof. Joachim Gross and Dr. Peter Uhlhaas. Details of the project are attached. Further infos on the studentship can be found here: http://www.gla.ac.uk/colleges/mvls/graduateschool/researchopportunities/studentshipopportunities/medicalresearchcouncil/ Inquiries can be forwarded to either one of the supervisors. Best wishes, Peter Uhlhaas Dr. Peter J. Uhlhaas Reader Institute for Neuroscience and Psychology University of Glasgow 58 Hillhead Street Glasgow G12 8QB Telephone +44 (0)141 330 8730 -- Frédéric Roux -------------- next part -------------- A non-text attachment was scrubbed... Name: MRC_Studentship_MEG in Schizophrenia.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 14535 bytes Desc: not available URL: From mcgoiv0 at wfu.edu Wed Nov 27 19:58:47 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Wed, 27 Nov 2013 13:58:47 -0500 Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hello, I am trying to apply head motion correction to a continuous MEG recording with Ft_regressconfound. Bcs the output of the Ft_regressconfound function is in the trial format , technically, I can proceed with the head motion regression method on the continuous data by dividing the data into smaller segments; which I did. I have 120 sec of MEG data (SR=600 Hz) that were divided into 10, or 20, or 30 sec trials. I run ft_regressconfound on these trials. No matter what the trial length or the total number of trials are, I get out of memory message in Matlab. Matlab error message: ??? Error using==>mldivide Out of memory. Error in ==> ft_regressconfound at 213 beta = regr\dat; % B= X\Y The error appears in the part of the code where the linear equation is solved directly. I tried to only work with a subset of all trials (half for example) with no luck. I rum MatlabR2010a on Windows XP 32-bit with the following memory allocation in Matlab: Max possible array: 851 Mb Memory available for all array: 1703 Mb Memory used by Matlab: 850 Mb RAM: 3317 Mb Were anybody else able to run this motion regression algorithm in Matlab without out of memory? Is there anything I can do to avoid the problem? I can share the code if needed. Thanks in advance, Inna Inna McGowin On Mon, Nov 18, 2013 at 10:42 AM, Arjen Stolk wrote: > Hi Inna, > Ft_regressconfound will remove trial by trial variability of signal > amplitude or frequency power that can be explained by variability in head > position over those trials. The input, whether sensor or source level, > should contain a trial field (keep trials in the previous step - eg at > timelockanalysis). Also variance due to head position can only be reliably > estimated when the neural signal is consistent over trials (as with an > event related modulation or potential). I would not know how to segment a > resting state into trials (for further analysis, given that those analyses > typically involve connectivity measures over the resting period) but if you > an idea on how to do this, you could give ft_regressconfound a try. Note > that the output will also be in the trials format. Hope this has made its > use a bit more clear. Yours, arjen > > Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het > volgende: > > > > > Hello everybody, > > > > I would like to use the ft_regressconfound function to remove/reduce > the head motion in a continuous MEG data. > > It's a resting state data and no averaging can be applied. Is there a > way to apply the correction without using the > > > > ft_timelockanalysis(cfg, data) function? > > > > I understand that the ft_regressconfound function has limits and caveats > but I still would like to see the results of its correction. > > > > > > Another way to ask this question is: > > what is the format/structure of the second input (timelock) in the > > ft_regressconfound(cfg, timelock) function and how it can be created > without ft_timelockanalysis? > > > > > > Thanks, > > > > Inna > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Thu Nov 28 03:11:12 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Wed, 27 Nov 2013 21:11:12 -0500 Subject: [FieldTrip] Channel_selection In-Reply-To: References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> <529613F0.7030801@donders.ru.nl> Message-ID: Dear Federico il Grande Allow 'badchstr' to be a cellarray of strings like this: badchstr = {'label2' 'labe8' ... 'label199'}; Try this: chstr = {'all'}; for i=1:numel(badchstr) chstr(i+1) = cellstr(sprintf('-%s ',badchstr{i})); end cfg = []; cfg.channel = chstr; dataclean = ft_preprocessing(cfg,data); Best, Cristiano On Wed, Nov 27, 2013 at 11:13 AM, Max Cantor wrote: > Here is how I do it: > > allchan = ft_read_header(dataset); > > (preprocess) > > allchan.label = [allchan.label; implicitref]; > > (after artifact rejection/ICA/etc.) > > badchan = ft_channelselection('gui', allchan.label); > > This gives me the channel labels for all channels, with the implicitref > added back in (normally this is removed), then a gui which lets me remove > bad channels manually after preprocessing/artifact rejection/ICA/etc. > > Hope this helps. > > Max Cantor > Research Assistant > Computational Neurolinguistics Lab > University of Michigan > > > On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < > jm.horschig at donders.ru.nl> wrote: > >> Hi Frederico, >> >> I think the best solution is to not use fieldtrip but plain matlab >> function. This is a small example that might help you: >> >> >> allchans = {'Fz', 'Cz', 'CPz'}; >> >> badchans = {'Fz', 'Cz'}; >> >> idx = ismember(allchans, badchans) >> >> idx = >> >> 1 1 0 >> >> You can then use the idx variable and logical indexing to get the good >> channels: >> >> >> allchans(~idx) >> >> ans = >> >> 'CPz' >> >> And then use cfg.channel = allchans(~idx). >> >> Be aware that ismember is a tricky function, because it returns the >> indices of the first vector as the first return variable and the respective >> same for the second vector as the second return variable, so order does >> matter. Just give it a try and play a bit around with it and you'll see. >> >> Best, >> Jörn >> >> >> >> Federico Grande wrote: >> >>> Hello everyone, >>> >>> In order to clean a little bit more my measurements, I have developed a >>> method which detects bad channels, and now, once I have the labels of the >>> bad channels, I want to give it to ft_preprocessing, but I don't know how. >>> I've been looking on ft_channelselection, and it seems that there is an >>> option , by using some like channel={'all','-channel to exclude'}. I have >>> an array with the labels of this channels that I want to exclude, but I >>> don't know why, it seems that I am not using it in the proper way. I have >>> tried with cfg.channel= {'all','-badSelections'} (badSelections is my >>> array), and it doesn't work, since after processing, still appear all the >>> channels in the dat.label. >>> >>> Any suggestion? >>> >>> Thank you very much!! >>> >>> All the best, >>> >>> Federico Grande >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> -- >> Jörn M. Horschig >> PhD Student >> Donders Institute for Brain, Cognition and Behaviour >> Centre for Cognitive Neuroimaging >> Radboud University Nijmegen >> Neuronal Oscillations Group >> FieldTrip Development Team >> >> P.O. Box 9101 >> NL-6500 HB Nijmegen >> The Netherlands >> >> Contact: >> E-Mail: jm.horschig at donders.ru.nl >> Tel: +31-(0)24-36-68493 >> Web: http://www.ru.nl/donders >> >> Visiting address: >> Trigon, room 2.30 >> Kapittelweg 29 >> NL-6525 EN Nijmegen >> The Netherlands >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bingshuo.li at student.uni-tuebingen.de Thu Nov 28 09:16:16 2013 From: bingshuo.li at student.uni-tuebingen.de (Bingshuo Li) Date: Thu, 28 Nov 2013 09:16:16 +0100 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Dear Max, Jim and Cristiano, Thank you so much for sharing your experiences! I found your comments very helpful. I will certain try the things you suggested and see how the ICA works this time. In addition, given that I have EOG and ECG recorded (but with different references), maybe it will also be beneficial if I calculate the coherence between the ICA components and EOG and ECG signals. Furthermore, I think it will be very beneficial to the field if someone with rich experiences in applying ICA in TMS-EEG can write a paper on manual artifactual components recognition! ;) Regards, ----- Bingshuo Li (MSc. candidate), Neuroprosthetic Group, CIN, Uni Tübingen On Wed, Nov 27, 2013 at 2:59 PM, Cristiano Micheli wrote: > Dear J.D., Max and Bingshuo, > > A brief comment: to be more confident about the correlative nature of an > artifact being an artifact (a.k.a. unwanted interference) I always consider > three things: topographies, time courses and spectra. The last one too, > since it might inform about spectral components not evident at the bare eye > from the time courses. > I'm not familiar with artifacts in TMS, but in all cases experience helps, > especially if you see the same pattern in many subjects, in other published > studies, from colleagues' data or from independent evidence (e.g. > concomitant electromiography recorded from the facial muscles, for muscular > artifacts identification). > > HTH > Cristiano > > > > > > On Wed, Nov 27, 2013 at 3:28 AM, Herring, J.D. (Jim) < > j.herring at fcdonders.ru.nl> wrote: > >> Dear Bingshuo, >> >> >> >> I agree with Max that it would be beneficial to see the timecourses as >> well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock >> average the time courses of the ICA components to the onset of the TMS >> pulse. That helps in identifying components that are related to the TMS >> pulse. >> >> >> >> Just from looking at the topographies I would say that component 7 is too >> posterior for being a cranial muscle artifact given that you are >> stimulating M1. Also, cranial muscle artifacts related to the TMS pulse >> usually last up to about 15ms after stimulation onset (see for example: >> http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.png?id=tutorial%3Atms-eeg) unless you are actually referring to a decay artifact ( >> http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tutorial%3Atms-eeg) >> , which can last up to one second. You said that you cut and interpolated >> up to 18ms after stimulation so you should not see any cranial muscle >> artifacts related to TMS. >> >> >> >> Too me component 7 looks more like a topography related to posterior >> alpha oscillations, however, to be sure we need to see the time courses. >> Component 13 and 18 might be neck muscle artifacts, however, without >> performing a timelock analysis of the ICA components and inspecting the >> time courses it is hard to tell whether these are due to the TMS-pulse. >> >> >> >> Component 42 and 54 could indeed just reflect two bad channels, at least >> they seem to contain some variance that cannot be explained by a >> combination of the other channels. >> >> >> >> Best, >> >> >> >> Jim >> >> >> >> *From:* fieldtrip-bounces at science.ru.nl [mailto: >> fieldtrip-bounces at science.ru.nl] *On Behalf Of *Bingshuo Li >> *Sent:* dinsdag 26 november 2013 18:26 >> *To:* fieldtrip at science.ru.nl >> *Subject:* [FieldTrip] ICA in TMS-EEG >> >> >> >> Dear FieldTrip Community, >> >> I recently started to analyze some TMS-EEG datasets and I encountered >> some questions regarding to using ICA to remove eye movement/muscle >> artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I >> would like to inquire the FT community for some hints or suggestions. Below >> are the details of my questions: >> >> //Description of Data Processing// >> >> - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance >> less than 5 kOhm >> >> - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials >> per subject) >> >> - TMS contaminated data points were cut out symmetrically -18ms to +18ms >> relative to TMS onset. Cubic spline interpolation is used to fill in the >> cut. >> >> - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. >> - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line >> noise >> >> - Visual inspection and rejection of trials with obvious unstable signal >> or channels. >> >> //ICA// >> >> - ICA algorithm: runica >> >> - Demeaned data for ICA training (baseline is defined as the entire epoch >> -1 to +1s) >> >> - Unmixing matrix applied to non-demeaned data for component removal >> >> /////QUESTIONS///// >> >> Please see the image below for a typical result of ICA from a subject >> with TMS applied at M1 (32 epochs for ICA training): >> https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png >> >> Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. >> However, what about component 5, 12, 20, 28? Topology-wise, they seem to >> have a very anterior origin, but data in the time domain does not seem to >> correlate with component 1 and 2 very well (judging visually..) >> >> Q2: What can you say about components 7, 9, 13 and 18? Are these cranial >> muscle artifacts? >> >> Q3: Also, for components 42 and 54, given their high focality, are these >> more or less a indication of bad/unstable electrodes? >> >> - I guess maybe I am asking too many questions. I think my main problem >> here is that I do not know what can be a good procedure / rules in manually >> selecting ICA components for rejection? (I tried to look in the literature >> but I couldn't find any that can answer my questions). And sometime I have >> the feeling that my ICA results look like a mess and maybe there were >> something wrong with my pre-processing or even data collection? >> >> Thank you guys in advance for any input! I look forward to hearing from >> you! >> >> Regards, >> >> Bingshuo Li >> >> MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgrande at cbs.mpg.de Thu Nov 28 09:49:21 2013 From: fgrande at cbs.mpg.de (Federico Grande) Date: Thu, 28 Nov 2013 09:49:21 +0100 (CET) Subject: [FieldTrip] Channel_selection In-Reply-To: Message-ID: <875544209.1015.1385628561634.JavaMail.root@zimbra> Thank you all! All the best, Federico ----- Original Message ----- From: "Cristiano Micheli" To: "FieldTrip discussion list" Sent: Thursday, November 28, 2013 3:11:12 AM Subject: Re: [FieldTrip] Channel_selection Dear Federico il Grande Allow 'badchstr' to be a cellarray of strings like this: badchstr = {'label2' 'labe8' ... 'label199'}; Try this: chstr = { 'all' }; for i=1:numel(badchstr) chstr(i+1) = cellstr(sprintf( '-%s ' ,badchstr{i})); end cfg = []; cfg.channel = chstr; dataclean = ft_preprocessing(cfg,data); Best, Cristiano On Wed, Nov 27, 2013 at 11:13 AM, Max Cantor < mcantor at umich.edu > wrote: Here is how I do it: allchan = ft_read_header(dataset); (preprocess) allchan.label = [allchan.label; implicitref]; (after artifact rejection/ICA/etc.) badchan = ft_channelselection('gui', allchan.label); This gives me the channel labels for all channels, with the implicitref added back in (normally this is removed), then a gui which lets me remove bad channels manually after preprocessing/artifact rejection/ICA/etc. Hope this helps. Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl > wrote: Hi Frederico, I think the best solution is to not use fieldtrip but plain matlab function. This is a small example that might help you: >> allchans = {'Fz', 'Cz', 'CPz'}; >> badchans = {'Fz', 'Cz'}; >> idx = ismember(allchans, badchans) idx = 1 1 0 You can then use the idx variable and logical indexing to get the good channels: >> allchans(~idx) ans = 'CPz' And then use cfg.channel = allchans(~idx). Be aware that ismember is a tricky function, because it returns the indices of the first vector as the first return variable and the respective same for the second vector as the second return variable, so order does matter. Just give it a try and play a bit around with it and you'll see. Best, Jörn Federico Grande wrote: Hello everyone, In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. Any suggestion? Thank you very much!! All the best, Federico Grande ______________________________ _________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands ______________________________ _________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Thu Nov 28 11:22:04 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 28 Nov 2013 11:22:04 +0100 Subject: [FieldTrip] LCMV giving conflicting results vs SAM and DICS In-Reply-To: References: <6D713918-6272-4E96-8CDF-0ECE2B95DE5A@ucdenver.edu> Message-ID: Hi Haris, Sorry for the slow reply, I had other stuff to do for a while. It seems that you have indeed stumbled on a bug, unfortunately. Let's move the discussion over to bugzilla: http://bugzilla.fcdonders.nl/show_bug.cgi?id=2395 Feel free to contribute anything there if you like (you can create an account if you don't have one yet). Hopefully we will be able to fix this soon. Best, Eelke On 29 October 2013 00:02, Charidimos Tzagarakis wrote: > Hi Eelke, > I have now run a test which I think does what you describe. > cfg.keeptrials='yes' for the calls to ft_timelockanalysis and > ft_sourcenalysis that generate the filter. > cfg.keeptrials='no' for all the other calls to these 2 functions (those that > generate the 2 conditions to be compared). > The result is still the same (ie not what I would call the 'correct' one, > but rather what seems to be based on an evoked response covariance matrix). > I should stress again that how I set keeptrials in ft_timelockanalysis is > also how I set it for the "matched" call to ft_sourceanalysis (It didn't > seem to me that this matters anyway as unless cfg.rawtrial='yes', > ft_sourceanalysis handles both cases so that what is used further down is > the same but I may be wrong in this) . > Best, > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 28 October 2013 05:26, Eelke Spaak wrote: >> >> Hi Charidimos, >> >> If I understand you correctly, you specified cfg.keeptrials = 'no' in >> the calls to ft_timelockanalysis prior to the *first* call of >> ft_sourceanalysis, right? Could you try what happens when you specify >> it in ft_timelockanalysis prior to the second call to >> ft_sourceanalysis (so the step where the precomputed filter is >> applied)? >> >> Thanks, >> Eelke >> >> On 25 October 2013 01:06, Charidimos Tzagarakis wrote: >> > Hi Eelke, >> > Thank you for looking into this! >> > The piece of code I commented out is indeed [790:836] (changing line 784 >> > accordingly or alternatively adding a copy of 785-789 after 790). >> > I did try running ft_timelockanalysis with keeptrials='no' for all 3 >> > calls >> > and that resulted in the same behaviour as before for LCMV (ie not the >> > "correct" one). I also tried it setting keeptrials='no' in >> > ft_sourceanalysis at the same time (ie keeptrials='no' for both >> > ft_timelockanalysis and ft_sourceanalysis) which had the same outcome (I >> > actually had run these tests before posting but wanted to 2ble check). >> > I may however be confused here because there are some other possible >> > combinations with keeptrials since for each subject there is a total of >> > 6 >> > calls to functions that accept it as an input and the filter is >> > estimated >> > with only 2 of them. >> > Do let me know if there is another combination I should run and I will >> > do >> > that. >> > Best, >> > Haris >> > >> > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> > University of Minnesota Dept of Neuroscience and Brain Sciences Center >> > >> > >> > On 24 October 2013 03:08, Eelke Spaak wrote: >> >> >> >> Hi Charidimos, >> >> >> >> Thanks for your elaborate e-mail. We discussed this issue in >> >> yesterday's FieldTrip meeting. It is very reasonable that you expect >> >> the three methods to produce the same results, and the code/interface >> >> indeed suggests that this would be the case. In other words, we need >> >> to clean up this part of the code to produce consistent results; >> >> however, this might take a while. >> >> >> >> We believe the discrepancy is caused by the fact that you compute the >> >> covariance while specifying cfg.keeptrials = 'yes', which is >> >> unnecessary while computing the filter. This results in a covariance >> >> matrix with dimensions trial X channel X channel, which then is >> >> subsequently averaged over trials during ft_sourceanalysis. Likely the >> >> filter is still in fact computed on the averaged covariance, as it >> >> should be. However, the subsequent projection of data through the >> >> filter will not first average the covariance, and will in essence only >> >> project the first trial through the filter. (This is because the dip{} >> >> fields will be struct arrays of dimension nTrial X 1, and in an >> >> assignment a(1).b = 2; a(2).b = 3; x = a; then x will be 2, so >> >> everything but the first element of a struct array is ignored in an >> >> assignment statement.) >> >> >> >> Could you try to compute the covariance with cfg.keeptrials = 'no' and >> >> then run LCMV again? This will still compute the covariance on the raw >> >> traces, not on the average. If our hunch is right, you should get the >> >> correct results then. >> >> >> >> As said, this is indeed messy and unclear, our apologies for that. >> >> >> >> Finally, could you tell us what part of the code you commented out to >> >> make the results consistent? We suspect it will be between lines 790 >> >> and 835, but it would be helpful to know for sure. >> >> >> >> Best, >> >> Eelke >> >> >> >> >> >> On 23 October 2013 21:43, Charidimos Tzagarakis >> >> wrote: >> >> > Hi Don, >> >> > Thanks for your reply. I do agree that some of these beamformers >> >> > are probably better suited than others to study beta >> >> > desynchronisation, >> >> > or >> >> > generally questions in the frequency domain. I in fact started from >> >> > DICS. >> >> > The reason I looked at LCMV and SAM is to be sure that I get >> >> > consistent >> >> > results (and also because my experiment can also address some >> >> > additional >> >> > time domain questions, so I wanted to see what happens when my data >> >> > goes >> >> > from one to the other). I therefore tried to set them up so I that >> >> > the >> >> > results from all 3 are similar. So you are correct in pointing out >> >> > that >> >> > my >> >> > question is why SAM and LCMV produce different results. Based on >> >> > their >> >> > description within the fieldtrip website and mailing list (if I have >> >> > interpreted these correctly) they should be treating the covariance >> >> > matrix >> >> > in the same way (to get a true evoked response covariance matrix you >> >> > would >> >> > normally need the extra call to ft_timelockanalysis that I show at >> >> > the >> >> > last >> >> > piece of code in my post). Also , if the covariance matrix is indeed >> >> > the >> >> > issue, it seems that the change in how it is treated in the >> >> > ft_sourceanalysis code (based on the "hack" I described) is unique to >> >> > LCMV >> >> > (none of the other beamformer options share that piece of code) and >> >> > is >> >> > active only when LCMV is given a precomputed filter which is (I >> >> > think) >> >> > unusual. >> >> > Hence my question! >> >> > Best, >> >> > Haris >> >> > >> >> > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> > University of Minnesota Dept of Neuroscience and Brain Sciences >> >> > Center >> >> > >> >> > >> >> > >> >> > On 23 October 2013 13:31, Rojas, Don wrote: >> >> >> >> >> >> Haris, >> >> >> >> >> >> Sorry - In my last post, I mistakenly put DICS and the Fieldtrip >> >> >> implementation of SAM into the same frequency domain category. In >> >> >> Fieldtrip, >> >> >> SAM is a time-domain technique and is not the same as the >> >> >> implementation of >> >> >> SAM that has been used in the published literature for beta ERD. So, >> >> >> are you >> >> >> then wondering why the two time-domain approaches produce differing >> >> >> results? >> >> >> That probably does depend on how the covariance matrix is >> >> >> calculated. >> >> >> Although I still think it is a bad idea to use a time-domain >> >> >> beamformer >> >> >> on >> >> >> motor beta ERD/ERS. >> >> >> >> >> >> Best, >> >> >> >> >> >> Don >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> fieldtrip mailing list >> >> >> fieldtrip at donders.ru.nl >> >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > fieldtrip mailing list >> >> > fieldtrip at donders.ru.nl >> >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From a.stolk at fcdonders.ru.nl Thu Nov 28 18:23:16 2013 From: a.stolk at fcdonders.ru.nl (Stolk, A. (Arjen)) Date: Thu, 28 Nov 2013 18:23:16 +0100 (CET) Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: Message-ID: <2046766750.4089031.1385659396420.JavaMail.root@sculptor.zimbra.ru.nl> Hi Inna, Are you using the same design matrix as on the wiki page? That one covers the primary head translations and rotations, but also their derivatives. You could try using the primary measures only (3 translastions, and 3 rotations of the circumcenter, totaling 6 + 1 constant regressors). It is also mentionworthy that there should be a balance between the number of regressors and the number of observations (i.e. trials). I believe on the respective wiki page on head movement regression it states that the ratio is recommended to be not larger than 1:10 (regressors:trials), accompanied with a reference. Accordingly, I'd suggest to use those 7 regressors, and your data (120s resting state) split in segments of 1 or 2 seconds, totaling 60 or 120 trials. These specifications might hopefully also allow working around your memory issue. Second, it may be worth mentioning what you would like to do with the data post-movement-regression. Namely, the movement compensation will remove contributions from head movement to the signal. But this requires that signal to behave consistently over trials, which does not seem the case with the signal in your resting study? That is, with an ERP study, the signal fluctuations appear consistent over trials, with amplitudes being modulated by head movement (i.e. sensor-source distance, see our neuroimage paper - 2013) in a predictable fashion. So if you're planning on doing frequency analysis, or maybe connectivity analysis, after head movement compensation, I'd recommend reversing that order. The rule of thumb is to use ft_regressconfound just prior to ft_xxxstatistics, removing otherwise unexplained variance (over trials) due to head movement, benefitting your statistical assessments. Hope these suggestions may help you with further analyses. I'm not familiar with anyone implementing this method to resting state analyses, but maybe someone else has some first-hand experience here. Furthermore, too late for your current dataset, but for a next one I'd recommend using the online head position monitoring/respositioning tool that we have developed for CTF systems (a neuromag version is approaching the final stage). This tool is routinely used in our lab to monitor and reduce head movment throughout recording (after which ft_regressconfound is being used to deal with the trial-by-trial crumbles). Yours, Arjen -------------- next part -------------- An HTML attachment was scrubbed... URL: From faranak.farzan at gmail.com Thu Nov 28 22:46:17 2013 From: faranak.farzan at gmail.com (Faranak Farzan) Date: Thu, 28 Nov 2013 16:46:17 -0500 Subject: [FieldTrip] Question regarding cluster-based permutation test Message-ID: Hi There, Hope this finds you well. We have a question in regards to 4 Dimensional cluster-based analysis meaning Data = Time X Freq X Channel X Subjects. Does fieldtrip allow us to produce clusters on a 3D matrix (TIME X FREQ X CHANNEL) while shuffling between/within subjects/groups? Or one should go about doing Time and Freq permutation separately (2D clusters at one specific frequency (or time))? Many thanks in advance, Regards, Faranak -------------- next part -------------- An HTML attachment was scrubbed... URL: From politzerahless at gmail.com Fri Nov 29 12:14:26 2013 From: politzerahless at gmail.com (Stephen Politzer-Ahles) Date: Fri, 29 Nov 2013 15:14:26 +0400 Subject: [FieldTrip] Question regarding cluster-based permutation test Message-ID: Hello Faranak, If you're doing a within-subjects design, then testing channels*time*freq on grand average data should be possible; see http://fieldtrip.fcdonders.nl/tutorial/cluster_permutation_freq#within_subjects_experiments . Best, Steve Stephen Politzer-Ahles New York University, Abu Dhabi Neuroscience of Language Lab http://www.nyu.edu/projects/politzer-ahles/ > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Nov 2013 16:46:17 -0500 > From: Faranak Farzan > To: fieldtrip at science.ru.nl > Subject: [FieldTrip] Question regarding cluster-based permutation test > Message-ID: > < CAEq_seaWYL87ZjXa0OX20xO1BqkGXHxODQrAVtbFsVg-6PuvHA at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi There, > > Hope this finds you well. We have a question in regards to 4 Dimensional > cluster-based analysis meaning Data = Time X Freq X Channel X Subjects. > Does fieldtrip allow us to produce clusters on a 3D matrix (TIME X FREQ X > CHANNEL) while shuffling between/within subjects/groups? Or one should go > about doing Time and Freq permutation separately (2D clusters at one > specific frequency (or time))? > > Many thanks in advance, > > Regards, > > Faranak > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131128/e67e370e/attachment-0001.html > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 36, Issue 52 > ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbirot at gmail.com Fri Nov 29 13:15:16 2013 From: gbirot at gmail.com (Gwenael Birot) Date: Fri, 29 Nov 2013 13:15:16 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables Message-ID: Dear all, I am trying to use the simbio package available in fieldtrip in order to compute the FEM headmodel. My OS is windows 7 64bits. When executing ft_headmodel_simbio I have got the following error: Error using sb_calc_stiff (line 89) Error executing mex-file. Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables are required. I installed these packages but I still have the error. It looks like there is several versions of these packages. Do I need one in particular or does any version is supposed to work? Thanks a lot, Gwenael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jm.horschig at donders.ru.nl Fri Nov 29 14:03:09 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Fri, 29 Nov 2013 14:03:09 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables In-Reply-To: References: Message-ID: <5298908D.2000005@donders.ru.nl> Hi Gwenael, I am not sure how much you know about mex-files, so this might go a bit over the top. The error you are describing probably stems from the fact that there are additional dependencies to other files on the mexed-version. We encountered similar things in the past with other FieldTrip functions, and found that the 2008 compiler actually should be compatible with any Windows version. Maybe the one who compiled the simbio toolbox did something other funky? Anyway, long story short, since the simbio toolbox is an external toolbox, we as the FieldTrip team do not maintain it. I don't know what you precisely need to install. You can use http://dependencywalker.com/ to find dependencies of the respective mexw64 file and try to find the respective packages containing these files. Just to assure you, when I try to execute the mex-file on Windows, I also get that error. On Linux it works fine though. I will bring this up in the next FieldTrip meeting and we will discuss this. We'll let you know about a solution. You could also go ahead and contact the Simbio guys directly (and share whatever the solution is with us, please) Best, Jörn Gwenael Birot wrote: > Dear all, > > I am trying to use the simbio package available in fieldtrip in order > to compute the FEM headmodel. My OS is windows 7 64bits. When > executing ft_headmodel_simbio I have got the following error: > > Error using sb_calc_stiff (line 89) > Error executing mex-file. Microsoft Visual C++ 2008 Redistributables > and Intel Visual Fortran Redistributables are required. > > I installed these packages but I still have the error. It looks like > there is several versions of these packages. Do I need one in > particular or does any version is supposed to work? > > Thanks a lot, > Gwenael > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands From jochem.rieger at uni-oldenburg.de Fri Nov 29 14:11:36 2013 From: jochem.rieger at uni-oldenburg.de (Jochem Rieger) Date: Fri, 29 Nov 2013 14:11:36 +0100 Subject: [FieldTrip] Post-doc with focus on statistical learning for analysis of speech coding in the human brain. Message-ID: <52989288.8090802@uni-oldenburg.de> The Department of Applied Neurocognitive Psychology at Oldenburg University, Germany, offers a Post-doctoral position (salary level E13 TVL, 3 years) with a focus on signal processing / statistical learning for analysis of speech coding in the human brain. The position is linked to the collaborative research center "The Active Auditory System" SFB-TR 31. The research center aims to characterize and model mechanism of auditory object formation and scene analysis by combining psychophysical, neurophysiological, and quantitative modelling. It complements the Excellence Cluster "Hearing 4 All" which was recently awarded to the University of Oldenburg. The combined effort of these centers will establish a strong link between neurophysiological models of auditory object representation and subjective perception. The post-doctoral position is situated in a project that applies statistical learning methods to human intracranial recordings (ECoG) and fMRI to derive and test quantitative statistical models of speech coding in the human brain. The experiments are performed in a highly interdisciplinary lab environment and in close collaboration with the University of California Berkeley and Stanford University. The quantitative nature of the research project will require highly motivated candidates with strong quantitative and experimental skills. Successful candidates will perform cutting edge research and should have a background in one or more of the following fields: signal processing, statistical learning, brain-machine-interfacing, non-invasive or invasive human neurophysiology of the auditory system. Applicants must have an academic university degree (Master or equivalent) and a PhD (or equivalent). Successful candidates will work in an interdisciplinary network with opportunities for international exchange. The post-doctoral position is initially limited to three years, with an option for extension, and can be split. Applications should include your CV, a list of most recent publications, two recommendation letters, and a research statement (max. 3 pages). The University of Oldenburg is an equal opportunity employer. The University of Oldenburg is dedicated to increasing the percentage of women in science. Therefore, equally qualified female candidates will be given preference. Applicants with disabilities will be preferentially considered in case of equal qualification. Please send inquiries and electronic applications per email (preferred) to Professor Dr. Jochem Rieger: Jochem.rieger(at)uni-oldenburg.de or paper applications per regular mail to: Margrit Jung Dept. of Applied Neurocognitive Psychology Institute of Psychology Oldenburg University 26111 Oldenburg Germany Application deadline is December 16th, 2013. -- Prof. Dr. rer. nat. Jochem Rieger Director, Institute of Psychology Head of Applied Neurocognitive | Knight Lab Psychology | Helen Wills Neuroscience Institute Faculty VI | University of California Carl-von-Ossietzky University | 132 Barker Hall 26111 Oldenburg | Berkeley, CA 94720-3192 Germany | USA Phone: +49(0)4417984533 Fax: +49(0)4417983865 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbirot at gmail.com Fri Nov 29 16:27:05 2013 From: gbirot at gmail.com (Gwenael Birot) Date: Fri, 29 Nov 2013 16:27:05 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables In-Reply-To: <5298908D.2000005@donders.ru.nl> References: <5298908D.2000005@donders.ru.nl> Message-ID: Dear Jörn, Thank you for your answer. Problem has been randomly solved by rebooting my computer. I should have know that Windows always needs to be restarted... Best, Gwenael 2013/11/29 "Jörn M. Horschig" > Hi Gwenael, > > I am not sure how much you know about mex-files, so this might go a bit > over the top. The error you are describing probably stems from the fact > that there are additional dependencies to other files on the mexed-version. > We encountered similar things in the past with other FieldTrip functions, > and found that the 2008 compiler actually should be compatible with any > Windows version. Maybe the one who compiled the simbio toolbox did > something other funky? Anyway, long story short, since the simbio toolbox > is an external toolbox, we as the FieldTrip team do not maintain it. I > don't know what you precisely need to install. You can use > http://dependencywalker.com/ to find dependencies of the respective > mexw64 file and try to find the respective packages containing these files. > Just to assure you, when I try to execute the mex-file on Windows, I also > get that error. On Linux it works fine though. I will bring this up in the > next FieldTrip meeting and we will discuss this. We'll let you know about a > solution. You could also go ahead and contact the Simbio guys directly (and > share whatever the solution is with us, please) > > Best, > Jörn > > > Gwenael Birot wrote: > >> Dear all, >> >> I am trying to use the simbio package available in fieldtrip in order to >> compute the FEM headmodel. My OS is windows 7 64bits. When executing >> ft_headmodel_simbio I have got the following error: >> >> Error using sb_calc_stiff (line 89) >> Error executing mex-file. Microsoft Visual C++ 2008 Redistributables and >> Intel Visual Fortran Redistributables are required. >> >> I installed these packages but I still have the error. It looks like >> there is several versions of these packages. Do I need one in particular or >> does any version is supposed to work? >> >> Thanks a lot, >> Gwenael >> >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Fri Nov 1 10:00:08 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 1 Nov 2013 10:00:08 +0100 Subject: [FieldTrip] new functionality for inverse modelling Message-ID: <444DEF5C-40D5-4143-9ED6-1B3DBCBD113A@donders.ru.nl> Dear FT-community, We are happy to announce that we just added some now functionality to the toolbox. Thanks to generous code contributions by Guido Nolte and Marlene Boenstrup from UKE Hamburg it is now possible to specify eloreta as a method in ft_sourceanalysis. It should work both on frequency and time domain data. Please feel free to try it out, and be generous with feedback/comments etc. Happy computing, also on behalf of Guido and Marlene, Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.vanlier at bsse.ethz.ch Fri Nov 1 12:33:02 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 1 Nov 2013 11:33:02 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: Hi Eric, Thanks for the answer. I really just dont see it... Where does the permutation distribution of the max cluster stat come from if you don't do a permutation test? But you don't actually need that distribution just the statistic?? how do you know then where your max stat (and the other clusterstats) is compared to the critical value at alpha? lets say your max clusterstat = 10 P(max(clusterstat) _> cv) = 0.05 so the probability that we see 10 or higher is 5% if h0 is in fact true. we actually are seeing 10 and thus (falsely) reject h0. so that always happens when h0 is true - you always reject the max cluster when h0 is true? doesn't make sense :( Thanks, Ben From e.maris at psych.ru.nl Fri Nov 1 22:40:10 2013 From: e.maris at psych.ru.nl (Eric Maris) Date: Fri, 1 Nov 2013 22:40:10 +0100 (CET) Subject: [FieldTrip] repeated measures ANOVA (statfun_depsamplesF): dfdenom problems In-Reply-To: <008D1219-3AC8-4011-985E-7396B0A9D64C@uos.de> References: <008D1219-3AC8-4011-985E-7396B0A9D64C@uos.de> Message-ID: <04ba01ced74a$efce27a0$cf6a76e0$@maris@psych.ru.nl> Dear Tim, > We have recently run into problems using the implementation of a > repeated measures ANOVA in statfun_depsamplesF.m. In our experiment, we > have recorded data of 16 subjects, and the factor of the repeated- > measures ANOVA has 37 levels (admittedly quite a few but that's just > how it is). > > Now if I am not mistaken, then for a repeated measures ANOVA, the > degrees of freedom in above case should be: df1 = 36 and df2 = 540 > (this is in line with the results of SPSS, too). However, the > statfun_depsamplesF.m function seems to compute dfdenom as nunits - > ncontrasts (nunits is the number of subjects, and ncontrasts is > nlevels-1). This of course leads to a different value as compared to > SPSS and what I found in the literature, in which dfdenom is computed > as (K-1)*(n-1), so in the current case as (nunits-1)*ncontrasts. > > For a one-factor repeated measures ANOVA, I could so far not find a > principled reason why the number of levels should not exceed the number > of subjects (which is the error message we get). In fact, SPSS works > just fine in above scenario. Could someone please explain the logic > behind the dfdenom computation in fieldtrip? Could it be that there is > an error in how the degrees of freedom are computed, or am I missing > something obvious here? For a MANOVA, the story would be different of > course. Here, you suggest the answer yourself: in Fieldtrip, we (I) have implemented the MANOVA dependent samples F-test, which requires more units than repeated measures. However, within the permutation framework, nothing prevents you from using the mixed F-statistic that you want to use (probably because it can deal with the situation of less units than repeated measures). You can write your own statfun, e.g. statfun_depsamplesFmixedmodel, and call this function in Fieldtrip's higher level statistics functions. Good to know, the false alarm rate control of your p-value-based inference does not depend on the sphericity assumption behind the use of the mixed model dependent samples F-test in a parametric context. Best, Eric Maris > > I should add that we are currently interfacing fieldtrip from eeglab > and get above error only if we choose the nonparametric fieldtrip > statistics (with cluster correction), but the parametric tests > implemented in eeglab work just fine. > > > Thank you very much for your help, I am looking forward to your > responses Tim > > > From pgoodin at swin.edu.au Sat Nov 2 07:15:27 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Sat, 2 Nov 2013 06:15:27 +0000 Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files In-Reply-To: References: Message-ID: Hi Neils, I use the ft_preprocessing function to load both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs. I haven't had a problem with dropped triggers / incorrect trial lengths etc. Please find the code I use below (and excuse any clunkiness): As for your second question re: cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. Hope the above (and below) helps and happy MEGing, Peter. %% %Read data into matlab cfg = []; cfg.dataset = megdata1; %first fif file cfg.channel = 'MEG'; d1 = ft_preprocessing(cfg); cfg = []; cfg.dataset = megdata2; %second fif file cfg.channel = 'MEG'; d2 = ft_preprocessing(cfg); %% %concatenate data dfull = d1; dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly. dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); dfull.sampleinfo = [1 length(dfull.trial{1,1})]; for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR. i = i + 1; end __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [aestnth at hum.au.dk] Sent: Friday, 1 November 2013 3:16 AM To: fieldtrip at science.ru.nl Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files Dear FieldTrip community. Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. ( http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? I'm looking forward to hear any comments, suggestions or solutions. Greetings Niels. Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital Denmark E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From russgport at gmail.com Sat Nov 2 23:19:41 2013 From: russgport at gmail.com (Russell G Port) Date: Sat, 2 Nov 2013 17:19:41 -0500 Subject: [FieldTrip] volume normalizing to mni template from ctf space mri Message-ID: Hi All, I just wanted to confirm this, because although I seen hints about this on the emails and websites that fieldtrip kindly archives; I worry. If I have a CTF coordinate system single subject MRI, and I want to normalize that onto the AVG152 brain in MNI space for example, ft_volumenormalization should handle this. What I mean by this is that I do not have to reslice/realign my image first to MNI space and then normalize... am I correct or misled? Best, Russ -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at psych.ru.nl Sun Nov 3 11:41:22 2013 From: e.maris at psych.ru.nl (Eric Maris) Date: Sun, 3 Nov 2013 11:41:22 +0100 (CET) Subject: [FieldTrip] maximum statistic in cluster correction In-Reply-To: References: Message-ID: <055001ced881$3baa4b40$b2fee1c0$@maris@psych.ru.nl> Hi Ben, (When you reply to a post, please also keep the post to which you reply. This is useful for others that want to follow the discussion.) > Thanks for the answer. I really just dont see it... Where does the > permutation distribution of the max cluster stat come from if you don't > do a permutation test? Without a permutation test, there is no permutation distribution. You construct the permutation distribution as a part of the test. > > But you don't actually need that distribution just the statistic?? You need both the distribution and the statistic, just like in parametric (Neyman-Pearson) statistics. However, unlike parametric statistics, in permutation statistics you construct your own reference distribution (i.c., the permutation distribution). how > do you know then where your max stat (and the other clusterstats) is > compared to the critical value at alpha? > > lets say your max clusterstat = 10 > > P(max(clusterstat) _> cv) = 0.05 > so the probability that we see 10 or higher is 5% if h0 is in fact > true. we actually are seeing 10 and thus (falsely) reject h0. so that > always happens when h0 is true - you always reject the max cluster when > h0 is true? doesn't make sense :( Your conceptual problem probably is due to the fact that you do not see how the maximum cluster statistic is generated under the permutation distribution. Under this distribution, this statistic really is a random variable. Maybe there is someone in your university to discuss this point. These conceptual issues are much faster clarified in a one-to-one discussion. Alternatively, attend one of our Fieldtrip courses. Best, Eric Maris > > Thanks, > Ben > From kgm at tf.uni-kiel.de Mon Nov 4 14:30:57 2013 From: kgm at tf.uni-kiel.de (kgm at tf.uni-kiel.de) Date: Mon, 4 Nov 2013 14:30:57 +0100 Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat Message-ID: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> Hi, I am working with the combined EEG and MEG recording and would like to do the forward model for the EEG. So I was trying to use the 'bemcp' and 'openmeeg' as am working on windows platform. I have the anatomy of my subject (DICOM file stacked and cleaned using SPM). When I try to use openmeeg, vol.mat is missing from the vol structure giving an error message om_minverser.exe doesn't function anymore. When I try to use 'bemcp', vol.mat contains all NaNs which resulted from the c12 and c21 matrices being not a square matrix which makes the inverse to be non-existent and also those matrices consists a large number of 'Inf' entries. Like it was mentioned on one of the forums, the error might come when the meshes are generated. I was able to find the index of the vertices from the Cij matrix, but I couldn't find the actual relation to the vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either brain, skull or scalp. Here are all the steps that I have followed. % reading MRI mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); % segment the brain cfg = []; cfg.output = {'brain', 'skull', 'scalp'}; cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- interauricular segmentedmri = ft_volumesegment(cfg, mri); segmentedmri.anatomy = mri.anatomy; % prepare mesh cfg = []; cfg.tissue = {'brain','skull', 'scalp'}; cfg.numvertices = [3000 2000 1000]; cfg.transform = segmentedmri.transform; bnd = ft_prepare_mesh(cfg, segmentedmri); % create head model cfg = []; cfg.method = 'openmeeg'; cfg.conductivity = [0.33 0.0041 0.33]; vol = ft_prepare_headmodel(cfg, bnd); figure; ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain figure; ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull figure; ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp Any help? Thanks. Kidist From s.rombetto at cib.na.cnr.it Mon Nov 4 17:16:33 2013 From: s.rombetto at cib.na.cnr.it (s.rombetto at cib.na.cnr.it) Date: Mon, 4 Nov 2013 17:16:33 +0100 Subject: [FieldTrip] question on SPIKE structure Message-ID: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> Dear Fieldtrip users I've just read the Tutorial concerning "Preprocessing and analysis of spike and local field potential data". Now I am wondering if it is possible to create a SPIKE structure, starting from recorded data, even without using any electrophysiology data acquisition system. Anybody can answer to this question? Maybe it is trivial, but I hhave never worked with these systems, but I am interested to this kind of analysis. Regards ------------------------- Dott.ssa Sara Rombetto Istituto di Cibernetica "E. Caianiello" Via Campi Flegrei, 34 80078 Pozzuoli (NA) Italy mob +39 3401689815 tel +39 0818675361 fax +39 0818675128 -------------------------- "I disapprove of what you say, but I will defend to the death your right to say it." [Evelyn Beatrice Hall, The Friends Of Voltaire] ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From r.oostenveld at donders.ru.nl Mon Nov 4 22:24:09 2013 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Mon, 4 Nov 2013 22:24:09 +0100 Subject: [FieldTrip] question on SPIKE structure In-Reply-To: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> References: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> Message-ID: <252AD1B6-7925-4BCA-9541-15E28EB11741@donders.ru.nl> Dear Sara, Please have a look at ft_datatype_spike in the utilities directory (or do "help ft_datatype_spike"). It explains the various fields in the spike data structure. We have such ft_datatype_xxx functions for all FieldTrip data structures. Their help serves to define the data structure (also for the developers), and the code in the functions serves to do some sanity checks and to update older data structures (e.g. stored in a mat file on disk) to the standards of the fieldtrip version that has to process them. best regards, Robert On 4 Nov 2013, at 17:16, s.rombetto at cib.na.cnr.it wrote: > Dear Fieldtrip users > > I've just read the Tutorial concerning "Preprocessing and analysis of spike and local field potential data". > Now I am wondering if it is possible to create a SPIKE structure, starting from recorded data, even without using any electrophysiology data acquisition system. > Anybody can answer to this question? Maybe it is trivial, but I hhave never worked with these systems, but I am interested to this kind of analysis. > > Regards > ------------------------- > Dott.ssa Sara Rombetto > Istituto di Cibernetica > "E. Caianiello" > Via Campi Flegrei, 34 > 80078 Pozzuoli (NA) > Italy > mob +39 3401689815 > tel +39 0818675361 > fax +39 0818675128 > -------------------------- > "I disapprove of what you say, but I will defend to the death your right to say > it." [Evelyn Beatrice Hall, The Friends Of Voltaire] > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 5 09:43:18 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 5 Nov 2013 09:43:18 +0100 Subject: [FieldTrip] question about coregistration References: Message-ID: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Dear Nicola, I am forwarding your question to the list, "ter lering ende vermaak": Begin forwarded message: > From: Nicola Molinaro > Date: November 4, 2013 2:16:20 PM GMT+01:00 > To: jan-mathijs schoffelen > Subject: mm -> voxels ?? > > Hi Jan, > I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? > I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). > > Thanks > > Nicola Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). Best wishes, Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Tue Nov 5 16:56:59 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Tue, 05 Nov 2013 16:56:59 +0100 Subject: [FieldTrip] =?utf-8?q?Reading_data_and_trigger_events_from_Neurom?= =?utf-8?q?ag_=09fif=09dataset__spli?= In-Reply-To: References: Message-ID: Thanks Peter. The concatenation of the data by using horzcat works fine. However, I don't know how to define the trials by refering to the concatenated data. Is it possible to automatically define the trials based on trigger signals in the concatenated data by using ft_definetrial or ft_redefinetrial? I get the error message (see below) about the missing headerfile. I tried to define cfg.header = dfull.hdr and cfg.headerfile = dfull.hdr , but it didn't seem to work. Greetings Niels. >> cfg = []; cfg.data = dfull cfg.trialfun = 'ft_trialfun_general' % this is the default cfg.trialdef.eventtype = 'STI101'; % trigger channel cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds trl = ft_definetrial(cfg); cfg = data: [1x1 struct] cfg = data: [1x1 struct] trialfun: 'ft_trialfun_general' evaluating trialfunction 'ft_trialfun_general' Reference to non-existent field 'headerfile'. Error in ft_trialfun_general (line 71) hdr = ft_read_header(cfg.headerfile, 'headerformat', cfg.headerformat); Error in ft_definetrial (line 162) [trl, event] = feval(cfg.trialfun, cfg); FieldTrip discussion list writes: >Hi Neils,� > > >I use the ft_preprocessing function to load � both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs.� > > >I haven't had a problem with dropped triggers / incorrect trial lengths etc.� > > >Please find the code I use below (and excuse any clunkiness): > > >As for your second question re:� cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. � > > >Hope the above (and below) helps and happy MEGing,� > > >Peter. > > > > >%% >%Read data into matlab > > >cfg = []; >cfg.dataset = megdata1; %first fif file >cfg.channel = 'MEG'; >d1 = ft_preprocessing(cfg); > > >cfg = []; >cfg.dataset = megdata2;� %second fif file >cfg.channel = 'MEG'; >d2 = ft_preprocessing(cfg); > > >%% >%concatenate� data > > >dfull = d1; >dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly.� >dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); >dfull.sampleinfo = [1 length(dfull.trial{1,1})]; > > >for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. >dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR.� >i = i + 1; >end� � > > >__________________________ >Peter Goodin,� >BSc (Hons), Ph.D Candidate. > > >Brain and Psychological Sciences Research Centre (BPsych) >Swinburne University,� >Hawthorn, Vic, 3122 > > >Monash Alfred Psychiatry Research Centre (MAPrc) >Level 4, 607 St Kilda Road, >Melbourne 3004 > >--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >-From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [aestnth at hum.au.dk] >Sent: Friday, 1 November 2013 3:16 AM >To: fieldtrip at science.ru.nl >Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files > > >Dear FieldTrip community. > >Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? > >The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. >FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. >( [ http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ]http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) > >I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. >The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. > >When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. � > >I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? > >I'm looking forward to hear any comments, suggestions or solutions. > >Greetings >Niels. > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >Denmark >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From joramvandriel at gmail.com Wed Nov 6 10:06:39 2013 From: joramvandriel at gmail.com (Joram van Driel) Date: Wed, 6 Nov 2013 10:06:39 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: Hi Nicola, I also did coregistration in MRI-lab using isotrak data. Importing the fif files in fieldtrip worked fine, I don’t think you have to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial ingredient. This worked for me: mri = ft_read_mri(); %%% read the MRI; the fif file is in mm but FT changes it into meters mri = ft_convert_units(mri,'mm'); %%% make it mm as it originally was mri = ft_volumereslice([], mri); %%% after this function the ficual points in the MEG header match the coordinates in the MRI Then you should indeed check this with ft_sourceplot, where in the cfg you can fill in fiducial points to check if they make sense, e.g.: cfg = []; cfg.location = [0 90.5 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly cfg.locationcoordinates = 'head'; ft_sourceplot(cfg,mri); Hope this helps. Best, Joram On 05 Nov 2013, at 09:43, jan-mathijs schoffelen wrote: > Dear Nicola, > > I am forwarding your question to the list, "ter lering ende vermaak": > > Begin forwarded message: > >> From: Nicola Molinaro >> Date: November 4, 2013 2:16:20 PM GMT+01:00 >> To: jan-mathijs schoffelen >> Subject: mm -> voxels ?? >> >> Hi Jan, >> I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? >> I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). >> >> Thanks >> >> Nicola > > > Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? > To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. > Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. > I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). > > Best wishes, > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Wed Nov 6 11:52:19 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Wed, 6 Nov 2013 11:52:19 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: Thanks guys for any possible help. Really appreciate it! I will summarize my tests: 1. reading the COR-.fif produced by MRIlab with ft_read_mri Well, it seems that ft_read_mri reads the original (not coregistered) .fif file produced in earlier steps of the forward model calculation (COR.fif). For example, if I delete the COR.fif file, ft_read_mri gives an error. ft_read_mri applied to the COR-.fif should be able to read some header, and for this reason I tried the option suggested by Joram (including ft_volumereslice). However, when I plot the volume head model with *hs=ft_read_headshape(.fif. 'unit','mm'); %get headshape points* *ft_plot_vol(vol)* *ft_plot_headshape(hs)* There is an evident misalignment between isotrack points and the brain volume. I mean NO coregistration is done. you can also appreciate it when plotting a prearicular instead of the nasion with *cfg = [];* *cfg.location = [66.4 0 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly* *cfg.locationcoordinates = 'head';* *ft_sourceplot(cfg,mri);* Take home message: Fieldtrip does not read the coregistration done in MRIlab, and you have to coregister MEG and MRI again. 2. Using cfg.method = 'headshape' cfg.headshape = 'XXX.pos' for ft_volumerealign. I played with it, but in neuromag the polhemous data are within the header of the *.fif* file. You can export the isotrack point however from MRIlab. After importing then with File>Import>Isotrack data you can then export them with File>Export>Points and specifying the coordinate system in which you want your point (either Head, or MRI or Voxel). This file cannot be read by ft_volumerealign with the headshape method. However, the first three lines of the resulting .txt file will give you the nasion and the two pre-auricolar points positions. I tried importing the voxel positions of the three points in ft_volumerealign using the method cfg.coordsys = 'neuromag'; cfg.method = 'fiducial'; And it worked, the brain volume is aligned with the isotrack points. This is the only solution that is visually reliable to perform On Wed, Nov 6, 2013 at 10:06 AM, Joram van Driel wrote: > Hi Nicola, > > I also did coregistration in MRI-lab using isotrak data. > Importing the fif files in fieldtrip worked fine, I don’t think you have > to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial > ingredient. > This worked for me: > > mri = ft_read_mri(); %%% read the MRI; the fif > file is in mm but FT changes it into meters > mri = ft_convert_units(mri,'mm'); %%% make it mm as it > originally was > mri = ft_volumereslice([], mri); %%% after this function the > ficual points in the MEG header match the coordinates in the MRI > > Then you should indeed check this with ft_sourceplot, where in the cfg you > can fill in fiducial points to check if they make sense, e.g.: > > cfg = []; > cfg.location = [0 90.5 0]; %%% fill in a fiducial point from > the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > > ft_sourceplot(cfg,mri); > > Hope this helps. > Best, > Joram > > On 05 Nov 2013, at 09:43, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > > Dear Nicola, > > I am forwarding your question to the list, "ter lering ende vermaak": > > Begin forwarded message: > > *From: *Nicola Molinaro > *Date: *November 4, 2013 2:16:20 PM GMT+01:00 > *To: *jan-mathijs schoffelen > *Subject: **mm -> voxels ??* > > Hi Jan, > I am trying to align the T1 images with isotrak data using MRIlab and then > import the coregistrated image to fieldtrip. Comparing the headshape points > with the volume, we can see that Fieldtrip is not taking into account the > coregistration. Thus, we are trying to do the corregistration applying the > ft_volumerealign function with the method='fiducial' in Fieldtrip. I have > the information of the landmarks' position obtained with MRIlab in 'mm' and > the function ft_volumerealign need them in voxel index. How can you convert > that? > I don´t know if you ever used MRIlab to obtain this information or another > software (MNE?). > > > Thanks > > Nicola > > > > Indeed I have never used MRIlab for coregistration purposes, so I may not > be of much help here. However, I suspect that the coregistration procedure > in MRIlab allows you to export your MRI after coregistration, thus creating > an file with an anatomical image in register with what you want to achieve. > If this is the case, then I don't think that you need FieldTrip to > coregister again. I am therefore a bit confused with respect to your remark > that 'FieldTrip is not taking into account the coregistration'. If you read > in an MRI into FieldTrip, the resulting MRI-structure will contain a > transform field, that provides the mapping from voxel space into a more > meaningful coordinate system. FieldTrip will not 'guess' the nature of this > coordinate system: it just takes the values as they are in the file. Once > you have read in your MRI, you can use the ft_sourceplot function for > visualization. With cfg.method = 'ortho', the figure will also display the > coordinates that you click on (both in voxel indices and in real world > coordinates). Now, do you mean by 'FieldTrip does not take into account the > coregistration' that these real world coordinates are not as expected? > To answer your question regarding the conversion of landmark positions in > 'mm' back into voxel indices: this requires information from the > mri.transform matrix, but this implies that the mri is already in register, > so there would be no need anymore to call ft_volumerealign. > Either way, you could also do the coregistration entirely in FieldTrip. > This requires a two-step approach, calling ft_volumerealign twice (starting > from the raw DICOM files, i.e. prior to having used MRIlab). In the first > step you will use cfg.interactive = 'yes' and identify the fiducials that > define your corodinate system. Assuming that you are working with your MEG > data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). > The output to this funcion call is an MRI structure that is approximately > in register with the MEG-device. In the next step you can refine this > coregistration by calling ft_volumerealign (with the approximately > registered MRI in the input, and) with cfg.method = 'headshape', and > cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should > result (providing that the isotrak data can be read ;-) ) in an interactive > figure, that allows you to further align the MRI with the polhemus point > cloud that describes the headshape. Once you are happy enough, the figure > can be closed, and an iterative-closest-point algorithm is applied for > further refinement of the coregistration. > I hope this helps, and might inspire you to try out the coregistration in > FieldTrip (and give feedback to us about it, in order to make the procedure > more robust). > > Best wishes, > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -- ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Wed Nov 6 22:57:54 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Wed, 06 Nov 2013 22:57:54 +0100 Subject: [FieldTrip] =?utf-8?q?Reading_data_and_trigger_events_from_Neurom?= =?utf-8?q?ag_=09fif=09dataset___sp?= In-Reply-To: References: <, > <,> Message-ID: Sorry, the previously posted example was wrong. Below is a correction to the previous example. Does the error shown below mean that you can only define trials based on the raw data files, and you can not define trials based on the data, which has already been converted to FieldTrip data? If so, I assume that it's necessary to: 1. Apply ft_definetrial on each one of the splitted raw fif files. 2. In the first two rows in the trial definition matrix from the second splitted file (i.e. the trial begin sample and trial end sample) add the number of samples in the preceeding raw fif file + 1. 3. Use vertcat to concatenate the corrected trial definition matrices from both files into one trial definition. 4. Then use ft_redefinetrial to apply the concatenated trial definitions on the concatenated data. Have anyone tried succesfully to concatenate trial definitions and apply them on concatenated data (in cases with raw fif files splitted into 2 files due to 2 GB file limitation during raw data recording)? Greetings Niels. >> cfg = []; cfg.dataset = dfull cfg.trialfun = 'ft_trialfun_general' % this is the default cfg.trialdef.eventtype = 'STI101'; % trigger channel cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds trl = ft_definetrial(cfg); cfg = dataset: [1x1 struct] cfg = dataset: [1x1 struct] trialfun: 'ft_trialfun_general' Warning: -clear > In utilities/private/warning_once at 116 In utilities/private/ft_preamble_init at 26 In ft_preamble at 54 In ft_definetrial at 112 Error using fileparts (line 31) Input must be a row vector of characters. Error in ft_filetype (line 146) [p, f, x] = fileparts(filename); Error in dataset2files (line 14) format = ft_filetype(filename); Error in ft_checkconfig (line 503) [cfg.dataset, cfg.headerfile, cfg.datafile] = dataset2files(cfg.dataset, []); Error in ft_definetrial (line 116) cfg = ft_checkconfig(cfg, 'dataset2files', {'yes'}); FieldTrip discussion list writes: >Thanks Peter. > >The concatenation of the data by using horzcat works fine. > >However, I don't know how to define the trials by refering to the concatenated data. >Is it possible to automatically define the trials based on trigger signals in the concatenated data by using ft_definetrial or ft_redefinetrial? > >I get the error message (see below) about the missing headerfile. I tried to define cfg.header = dfull.hdr and cfg.headerfile = dfull.hdr , but it didn't seem to work. > >Greetings >Niels. > >>> cfg = []; >cfg.data = dfull >cfg.trialfun = 'ft_trialfun_general' % this is the default >cfg.trialdef.eventtype = 'STI101'; % trigger channel >cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers >cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds >cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds >trl � = ft_definetrial(cfg); > >cfg = > >� � � � data: [1x1 struct] > > >cfg = > >� � � � � � � � data: [1x1 struct] > � � � trialfun: 'ft_trialfun_general' > >evaluating trialfunction 'ft_trialfun_general' >Reference to non-existent field 'headerfile'. > >Error in ft_trialfun_general (line 71) >hdr = ft_read_header(cfg.headerfile, 'headerformat', cfg.headerformat); > >Error in ft_definetrial (line 162) > � � � [trl, event] = feval(cfg.trialfun, cfg); > > >FieldTrip discussion list <[ mailto:fieldtrip at science.ru.nl ]fieldtrip at science.ru.nl> writes: >Hi Neils,� > > >I use the ft_preprocessing function to load � both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs.� > > >I haven't had a problem with dropped triggers / incorrect trial lengths etc.� > > >Please find the code I use below (and excuse any clunkiness): > > >As for your second question re:� cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. � > > >Hope the above (and below) helps and happy MEGing,� > > >Peter. > > > > >%% >%Read data into matlab > > >cfg = []; >cfg.dataset = megdata1; %first fif file >cfg.channel = 'MEG'; >d1 = ft_preprocessing(cfg); > > >cfg = []; >cfg.dataset = megdata2;� %second fif file >cfg.channel = 'MEG'; >d2 = ft_preprocessing(cfg); > > >%% >%concatenate� data > > >dfull = d1; >dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly.� >dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); >dfull.sampleinfo = [1 length(dfull.trial{1,1})]; > > >for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. >dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR.� >i = i + 1; >end� � > > >__________________________ >Peter Goodin,� � >BSc (Hons), Ph.D Candidate. > > >Brain and Psychological Sciences Research Centre (BPsych) >Swinburne University,� >Hawthorn, Vic, 3122 > > >Monash Alfred Psychiatry Research Centre (MAPrc) >Level 4, 607 St Kilda Road, >Melbourne 3004 > > >--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >- >From: [ mailto:fieldtrip-bounces at science.ru.nl ]fieldtrip-bounces at science.ru.nl� [[ mailto:fieldtrip-bounces at science.ru.nl ]fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [[ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk] >Sent: Friday, 1 November 2013 3:16 AM >To: [ mailto:fieldtrip at science.ru.nl ]fieldtrip at science.ru.nl >Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files > > >Dear FieldTrip community. > >Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? > >The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. >FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. >( [ http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ]http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) > >I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. >The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. > >When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. � > >I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? > >I'm looking forward to hear any comments, suggestions or solutions. > >Greetings >Niels. > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >Denmark >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >[ mailto:fieldtrip at donders.ru.nl ]fieldtrip at donders.ru.nl >[ http://mailman.science.ru.nl/mailman/listinfo/fieldtrip ]http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.oostenveld at donders.ru.nl Thu Nov 7 09:28:30 2013 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Thu, 7 Nov 2013 09:28:30 +0100 Subject: [FieldTrip] Fwd: MEG postdoc vacancy - Aarhus Univ, DK References: <4494422563576817.WA.yury.shtyrovcfin.au.dk@www.jiscmail.ac.uk> Message-ID: <8D6628F1-BF71-4019-916D-1289BA520D0D@donders.ru.nl> Begin forwarded message: > From: Yury Shtyrov > Date: 6 November 2013 19:23:18 CET > To: NEUROMEG at JISCMAIL.AC.UK > Subject: MEG postdoc vacancy - Aarhus Univ, DK > Reply-To: Yury Shtyrov > > Dear all, > > Apologies for possible cross-postings - could you please circulate this MEG job to anyone who could be interested. > > Thanks, > /yury/ > > Yury Shtyrov, DPhil > Professor - Head of MEG Group > MINDLab - Center of Functionally Integrative Neuroscience (CFIN) > Institute for Clinical Medicine > Aarhus University, Denmark > > > ------------------ > > Post-doctoral Position in MEG/Neuroscience of Language > Center of Functionally Integrative Neuroscience, Aarhus University > > Applications are invited for a postdoctoral scientist to support research into neurobiological foundations of language at the Center of Functionally Integrative Neuroscience (CFIN), Aarhus University, Denmark. The postholder’s research will be centred on using MEG and on the spatio-temporal dynamics of the neural activity underlying speech and language processing in the human brain. Ideal candidates will therefore have experience in neuroimaging and in language research. Previous experience in using EEG or/and MEG is essential. Eligible candidates should hold a PhD or similar degree in a relevant discipline, including (but not limited to) psychology, neuroinformatics, psycholinguisitcs or neuroscience. The position is to be filled as soon as possible and is initially open for 1 year with a possibility of extension and/or permanent post for a good candidate. > > CFIN is an international multidisciplinary research centre based at Aarhus University’s Institute for Clinical Medicine, Denmark. Our research groups are supported by state-of-the-art cognitive neuroscience facilities including research-only 306-channel TRIUX MEG system (Elekta Neuromag), fMRI systems (Siemens TIM Trio 3T, Magnetom Skyra 3T), PET, navigated TMS, EEG and eye-tracking equipment, Two-Photon Microscopy, etc., and have well-established clinical and other collaborations. See cfin.au.dk for more inromation. Aarhus University provides an inspiring international research environment with top neuroscience facilties, and is consistently named among the world's best 100 universities. > > To apply, please go to http://www.au.dk/en/about/job/sun/academicpositions/ > > Additional information regarding this position can be obtained by contacting Professor Yury Shtyrov, head of MEG, CFIN: Yury.Shtyrov at cfin.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lilla.Magyari at mpi.nl Thu Nov 7 09:44:35 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 7 Nov 2013 09:44:35 +0100 (CET) Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> Message-ID: <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> hi Kidist, I am wondering if you have installed openmeeg properly. Here is a site to explain it: http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling Have you followed this? Lilla > Hi, > > I am working with the combined EEG and MEG recording and would like to do > the forward model for the EEG. > > So I was trying to use the 'bemcp' and 'openmeeg' as am working on windows > platform. I have the anatomy of my subject (DICOM file stacked and cleaned > using SPM). > > When I try to use openmeeg, vol.mat is missing from the vol structure > giving an error message om_minverser.exe doesn't function anymore. > > When I try to use 'bemcp', vol.mat contains all NaNs which resulted from > the c12 and c21 matrices being not a square matrix which makes the inverse > to be non-existent and also those matrices consists a large number of > 'Inf' entries. > > Like it was mentioned on one of the forums, the error might come when the > meshes are generated. I was able to find the index of the vertices from > the Cij matrix, but I couldn't find the actual relation to the > vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either brain, > skull or scalp. > > Here are all the steps that I have followed. > > % reading MRI > mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); > > % segment the brain > cfg = []; > cfg.output = {'brain', 'skull', 'scalp'}; > cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- > interauricular > segmentedmri = ft_volumesegment(cfg, mri); > segmentedmri.anatomy = mri.anatomy; > > % prepare mesh > cfg = []; > cfg.tissue = {'brain','skull', 'scalp'}; > cfg.numvertices = [3000 2000 1000]; > cfg.transform = segmentedmri.transform; > bnd = ft_prepare_mesh(cfg, segmentedmri); > > % create head model > cfg = []; > cfg.method = 'openmeeg'; > cfg.conductivity = [0.33 0.0041 0.33]; > vol = ft_prepare_headmodel(cfg, bnd); > > figure; > ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain > figure; > ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull > figure; > ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp > > Any help? > > Thanks. > Kidist > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From Lilla.Magyari at mpi.nl Thu Nov 7 10:35:54 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 7 Nov 2013 10:35:54 +0100 (CET) Subject: [FieldTrip] volume normalizing to mni template from ctf space mri In-Reply-To: References: Message-ID: <2065.84.86.187.191.1383816954.squirrel@84.86.187.191> hi Russ, you do not need to worry. Your original volume is converted to spm space from ctf during normalization and then the original volume and the template are matched to each other. Although the ctf to spm conversion is an approximation, it is sufficient to produce OK result. So, you do not need to realign or reslice your volume prior to normalization. And just a remark for others: The automatic conversion happens only if the original volume defined in ctf (or bti) or in itab (neuromag) coordinates. Otherwise, the original volume should be aligned to spm space. Lilla > Hi All, > > I just wanted to confirm this, because although I seen hints about this on > the emails and websites that fieldtrip kindly archives; I worry. If I have > a CTF coordinate system single subject MRI, and I want to normalize that > onto the AVG152 brain in MNI space for example, ft_volumenormalization > should handle this. What I mean by this is that I do not have to > reslice/realign my image first to MNI space and then normalize... am I > correct or misled? Best, Russ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From nuria.donamayor at neuro.uni-luebeck.de Thu Nov 7 15:54:31 2013 From: nuria.donamayor at neuro.uni-luebeck.de (=?iso-8859-1?Q?Nuria_Do=F1amayor_Alonso?=) Date: Thu, 7 Nov 2013 15:54:31 +0100 Subject: [FieldTrip] =?iso-8859-1?q?PhD_position_-_University_of_L=FCbeck?= =?iso-8859-1?q?=2C_Germany?= In-Reply-To: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF6@solaris.neuro.uni-luebeck.de> References: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF6@solaris.neuro.uni-luebeck.de> Message-ID: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF8@solaris.neuro.uni-luebeck.de> Dear fieldtrippers, could you please circulate this PhD opening to anyone who might be interested? Thanks, Nuria -------------- The Department of Neurology, University of Lübeck seeks to recruit a Ph.D. student from the 1st of January 2014 onwards. The candidate will be working on a project on the neural basis of primary food reward in humans using multimodal imaging (EEG-fMRI). An essential part of the project will be the development of methods of electrophysiological-hemodynamic coupling. Applicants must hold a Diplom, MSc or equivalent degree in Mathematics, Physics, Engineering or a relevant discipline. They should have a strong interest in cognitive neuroscience and excellent programming skills. Preference will be given to applicants experienced in functional imaging and/or cognitive electrophysiology. The position is initially for 2 years with the possibility of renewal. The salary will be according to an E13 (TV-L, 50%) position. The University of Lübeck is an equal opportunities employer. Applications from female candidates are strongly encouraged. In case of compatible qualifications, preference will be given to people with disabilities. Applications should include CV, copies of certificates and letters of recommendation. Please send initial enquiries and/or applications directly to Dr. Nuria Doñamayor Alonso (nuria.donamayor at neuro.uni-luebeck.de). -------------- next part -------------- A non-text attachment was scrubbed... Name: PhD_position.pdf Type: application/pdf Size: 53874 bytes Desc: PhD_position.pdf URL: From kgm at tf.uni-kiel.de Thu Nov 7 15:56:54 2013 From: kgm at tf.uni-kiel.de (kgm at tf.uni-kiel.de) Date: Thu, 7 Nov 2013 15:56:54 +0100 Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> Message-ID: <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> Hi Lilla, Thank you for your reply. The openmeeg works well for the mri (subject01.mri) that is used in the fieldtrip tutorial. But the error comes when I use my subject's mri whose anatomy is 256*256*192. I have also tried to use mri = ft_volumereslice(cfg,mri) thinking that the error might be due to the inequality of the size of the anatomical volume into each direction. Kidist > hi Kidist, > > I am wondering if you have installed openmeeg properly. Here is a site to > explain it: > http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling > > Have you followed this? > > Lilla > > > >> Hi, >> >> I am working with the combined EEG and MEG recording and would like to >> do >> the forward model for the EEG. >> >> So I was trying to use the 'bemcp' and 'openmeeg' as am working on >> windows >> platform. I have the anatomy of my subject (DICOM file stacked and >> cleaned >> using SPM). >> >> When I try to use openmeeg, vol.mat is missing from the vol structure >> giving an error message om_minverser.exe doesn't function anymore. >> >> When I try to use 'bemcp', vol.mat contains all NaNs which resulted from >> the c12 and c21 matrices being not a square matrix which makes the >> inverse >> to be non-existent and also those matrices consists a large number of >> 'Inf' entries. >> >> Like it was mentioned on one of the forums, the error might come when >> the >> meshes are generated. I was able to find the index of the vertices from >> the Cij matrix, but I couldn't find the actual relation to the >> vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either >> brain, >> skull or scalp. >> >> Here are all the steps that I have followed. >> >> % reading MRI >> mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); >> >> % segment the brain >> cfg = []; >> cfg.output = {'brain', 'skull', 'scalp'}; >> cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- >> interauricular >> segmentedmri = ft_volumesegment(cfg, mri); >> segmentedmri.anatomy = mri.anatomy; >> >> % prepare mesh >> cfg = []; >> cfg.tissue = {'brain','skull', 'scalp'}; >> cfg.numvertices = [3000 2000 1000]; >> cfg.transform = segmentedmri.transform; >> bnd = ft_prepare_mesh(cfg, segmentedmri); >> >> % create head model >> cfg = []; >> cfg.method = 'openmeeg'; >> cfg.conductivity = [0.33 0.0041 0.33]; >> vol = ft_prepare_headmodel(cfg, bnd); >> >> figure; >> ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain >> figure; >> ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull >> figure; >> ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp >> >> Any help? >> >> Thanks. >> Kidist >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From mattmizumi at gmail.com Thu Nov 7 20:38:50 2013 From: mattmizumi at gmail.com (mattmizumi at gmail.com) Date: Thu, 07 Nov 2013 14:38:50 -0500 Subject: [FieldTrip] selecting which dimension to average over in ft_singleplotER Message-ID: <527BEC4A.5070401@gmail.com> A simple newbie question about ft_singleplotER: given a coherence spectrum, as follows, fd = labelcmb: {'vStr1' 'vStr2'} dimord: 'chan_freq_time' cohspctrm: [1x100x101 double] freq: [1x100 double] time: [1x101 double] dof: [1x100 double] cfg: [1x1 struct] how can I plot frequency against coherence? The default behavior of ft_singleplotER in this case is to average over frequency: cfg = []; cfg.parameter = 'cohspctrm'; cfg.refchannel = 'vStr2'; cfg.channel = 'vStr1'; ft_singleplotER(cfg, fd); selected 1 channels for cohspctrm selection cohspctrm along dimension 2 averaging cohspctrm over freq the call to "ft_singleplotER" took 0 seconds ..but I cannot find a way to get it to average over time instead. How can I do this? (Of course, I know I can plot this manually. But I would like to understand how to use the ft plotting functions. I can't find anything pertinent in the coherence and plotting tutorials, or the help for ft_singleplotER.) Thanks! -- Matt From s.caffarra at bcbl.eu Fri Nov 8 10:47:20 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Fri, 8 Nov 2013 10:47:20 +0100 (CET) Subject: [FieldTrip] help Message-ID: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu From jan.schoffelen at donders.ru.nl Fri Nov 8 11:08:56 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 8 Nov 2013 11:08:56 +0100 Subject: [FieldTrip] help In-Reply-To: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Fri Nov 8 11:14:31 2013 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Fri, 8 Nov 2013 11:14:31 +0100 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > > Hi Sendy, > > You may want to have a look at the following link: > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > I assume that your data has been passed through the MaxFilter, which > massively reduces the rank of your data, causing the ICA algorithm to spit > out complex valued numbers. > You need to reduce the rank of your data prior to running the component > decomposition, to be less that then true rank in your data. > > Best > Jan-Mathijs > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as > following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components > using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that > should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic > distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', > 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not > work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From polomacnenad at gmail.com Fri Nov 8 16:34:16 2013 From: polomacnenad at gmail.com (Nenad Polomac) Date: Fri, 8 Nov 2013 16:34:16 +0100 Subject: [FieldTrip] 'powandcsd' on short time window Message-ID: Dear Fieldtrip users, I have one problem and I hope that somebody has idea. For my source and connectivity analysis I need cross spectrum matrix at 40Hz and for time window of 50 ms(the effect is evoked gamma and it last less then 50 ms). The problem is that for this very narrow window the best I can get is the frequency resolution of 20Hz and that is far to low. I am trying now different padding options but it seems it doesn't help. If I band pass filter(35-45Hz) data before fft then result is as expected, but without filtering I pickup wide range of frequencies(probably from 20-60Hz) even if I specify cfg.foilim=[40 40]. Furthermore, all this stuff is included in my cross spectrum and brought into the further calculations. my code: cfg=[]; cfg.toilim = [0.03 0.08]; data_redef= ft_redefinetrial(cfg, data); cfg = []; cfg.trials = 'all'; cfg.keeptrials = 'no'; cfg.channel = 'MEG'; cfg.method = 'mtmfft'; cfg.output = 'powandcsd'; cfg.tapsmofrq = 1; cfg.foilim = [40 40]; cfg.taper = 'hanning'; cfg.pad =2; cfg.padtype='zero'; gamma = ft_freqanalysis(cfg, data_redef); Thank you in advance! Cheers, Nenad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.vanlier at bsse.ethz.ch Fri Nov 8 18:15:17 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 8 Nov 2013 17:15:17 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: I think I just had my aha-moment. Or actually more of a d'oh-moment. I was already wrong at step 0 which led to a whole cascade of thinking errors. I somehow thought that the t statistics were calculated per channel for a whole trial (so a single comparison) instead of every timepoint within a trial. every one of those t values that reaches a threshold is considered to be part of a cluster. then sum the t values within each cluster and get the maximum cluster stat. this is your observed statistic. now mix the trials and randomly assign them to subset1 and subset2. repeat the above to get another max cluster stat. do this many times (monte carlo) to create the permutation distribution of the max cluster stat. compare all the cluster stats you actually observed originally with your permutation distribution to find their p values. the FA rate is controlled because no other cluster will show a smaller p value than the max stat cluster and the chance on a type I error for the max cluster stat is alpha in "his own" distribution. not completely sure about that last sentence but i think its time for weekend now :) Thanks Eric Cheers, Ben From ben.vanlier at bsse.ethz.ch Fri Nov 8 18:23:09 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 8 Nov 2013 17:23:09 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: sorry, i am trying to reply to the previous posts but its not obvious. maybe "RE:" is capital sensitive? very irritating how there is no word wrap either, in my emails. From eelke.spaak at donders.ru.nl Sun Nov 10 01:11:04 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Sun, 10 Nov 2013 01:11:04 +0100 Subject: [FieldTrip] 'powandcsd' on short time window In-Reply-To: References: Message-ID: Dear Nenad, Unfortunately the limit to the frequency resolution is fundamental and not practical. It is impossible to get a better frequency resolution than 20 Hz with only 50ms of data. (It might help to think of this as analogous to Heisenberg's uncertainty principle in physics.) Why do you need a better frequency resolution? Perhaps there are alternatives to what you are trying. Best, Eelke On Nov 8, 2013 7:44 AM, "Nenad Polomac" wrote: > Dear Fieldtrip users, > > I have one problem and I hope that somebody has idea. For my source and > connectivity analysis I need cross spectrum matrix at 40Hz and for time > window of 50 ms(the effect is evoked gamma and it last less then 50 ms). > The problem is that for this very narrow window the best I can get is the > frequency resolution of 20Hz and that is far to low. I am trying now > different padding options but it seems it doesn't help. If I band pass > filter(35-45Hz) data before fft then result is as expected, but without > filtering I pickup wide range of frequencies(probably from 20-60Hz) even if > I specify cfg.foilim=[40 40]. Furthermore, all this stuff is included in my > cross spectrum and brought into the further calculations. > my code: > cfg=[]; > cfg.toilim = [0.03 0.08]; > data_redef= ft_redefinetrial(cfg, data); > > cfg = []; > cfg.trials = 'all'; > cfg.keeptrials = 'no'; > cfg.channel = 'MEG'; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd'; > cfg.tapsmofrq = 1; > cfg.foilim = [40 40]; > cfg.taper = 'hanning'; > cfg.pad =2; > cfg.padtype='zero'; > gamma = ft_freqanalysis(cfg, data_redef); > > Thank you in advance! > Cheers, > > Nenad > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Mon Nov 11 16:46:53 2013 From: mcantor at umich.edu (Max Cantor) Date: Mon, 11 Nov 2013 10:46:53 -0500 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com> wrote: > Hi Sendy, JM, > > In addition, that error also happens (or used to, at least) when you have > not selected MEG as channels, therefor applying ICA e.g. also on your EOG > channels etc. as well. > > Cheers, > Stephen > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> >> Hi Sendy, >> >> You may want to have a look at the following link: >> >> >> http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component >> >> I assume that your data has been passed through the MaxFilter, which >> massively reduces the rank of your data, causing the ICA algorithm to spit >> out complex valued numbers. >> You need to reduce the rank of your data prior to running the component >> decomposition, to be less that then true rank in your data. >> >> Best >> Jan-Mathijs >> >> On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: >> >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as >> following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components >> using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file >> that should be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic >> distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', >> 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not >> work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.caffarra at bcbl.eu Mon Nov 11 17:33:08 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Mon, 11 Nov 2013 17:33:08 +0100 (CET) Subject: [FieldTrip] help In-Reply-To: Message-ID: <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From pgoodin at swin.edu.au Tue Nov 12 04:41:57 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Tue, 12 Nov 2013 03:41:57 +0000 Subject: [FieldTrip] help In-Reply-To: <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, TL;DR - Use fastica. Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). Hope this helps, Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] Sent: Tuesday, 12 November 2013 3:33 AM To: FieldTrip discussion list Cc: FieldTrip discussion list Subject: Re: [FieldTrip] help Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 12 09:06:01 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 09:06:01 +0100 Subject: [FieldTrip] help In-Reply-To: References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Message-ID: <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> Dear all, As a comment to Peter's reply: the fastica code internally applies PCA to the data by removing all small signal components. In this respect runica does not behave differently if you specify cfg.runica.pca = 70 (provided that fastica estimates the number of components to retain is 70). Best, Jan-Mathijs On Nov 12, 2013, at 4:41 AM, Peter Goodin wrote: > Hi Sendy, > > TL;DR - Use fastica. > > Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). > > Hope this helps, > > Peter > > __________________________ > Peter Goodin, > BSc (Hons), Ph.D Candidate. > > Brain and Psychological Sciences Research Centre (BPsych) > Swinburne University, > Hawthorn, Vic, 3122 > > Monash Alfred Psychiatry Research Centre (MAPrc) > Level 4, 607 St Kilda Road, > Melbourne 3004 > > ________________________________________ > From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] > Sent: Tuesday, 12 November 2013 3:33 AM > To: FieldTrip discussion list > Cc: FieldTrip discussion list > Subject: Re: [FieldTrip] help > > Hi Fieldtrip users, > > I tried to select MEG as channels and I reduced the rank of my data, as following: > > cfg=[]; > cfg.runica.pca = 306; > cfg.channel = 'MEG'; > comp = ft_componentanalysis(cfg, data); > > ...but I still get the same error as before. > Are there any other reasons that could produce this error? > > Thanks in advance, > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > ----- Original Message ----- > From: "Max Cantor" > To: "FieldTrip discussion list" > Sent: Monday, November 11, 2013 4:46:53 PM > Subject: Re: [FieldTrip] help > > > > I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. > > > Thank you, > Max > > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: > > > > Hi Sendy, JM, > > > In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. > > > Cheers, > Stephen > > > > > > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: > > > > > > > Hi Sendy, > > > You may want to have a look at the following link: > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > > I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. > You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. > > > Best > Jan-Mathijs > > > > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgoodin at swin.edu.au Tue Nov 12 09:36:28 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Tue, 12 Nov 2013 08:36:28 +0000 Subject: [FieldTrip] help In-Reply-To: <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> , <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> Message-ID: Hi Jan-Mathijs, Very good to know, thank you! Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of jan-mathijs schoffelen [jan.schoffelen at donders.ru.nl] Sent: Tuesday, 12 November 2013 7:06 PM To: FieldTrip discussion list Subject: Re: [FieldTrip] help Dear all, As a comment to Peter's reply: the fastica code internally applies PCA to the data by removing all small signal components. In this respect runica does not behave differently if you specify cfg.runica.pca = 70 (provided that fastica estimates the number of components to retain is 70). Best, Jan-Mathijs On Nov 12, 2013, at 4:41 AM, Peter Goodin wrote: Hi Sendy, TL;DR - Use fastica. Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). Hope this helps, Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] Sent: Tuesday, 12 November 2013 3:33 AM To: FieldTrip discussion list Cc: FieldTrip discussion list Subject: Re: [FieldTrip] help Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 09:48:13 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 09:48:13 +0100 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> Hi Max, When you specify the channel to be left out, you have to name it according to how it's named in your data. I believe that the 'refchan' is only called like that for the purpose of the example. So, when you have a single reference channel, named 'thisisthenameofyourreferencechannel', you need to specify '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for exaggerating, but perhaps the silly name brings across the message more clearly. Note, that when you have applied a common average reference, you could at random remove a channel (not advisable). In that case I'd specify the dimensionality of your data space prior to calling ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG channels). Best, Jan-Mathijs On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: > I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. > > Thank you, > Max > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh wrote: > Hi Sendy, JM, > > In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. > > Cheers, > Stephen > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen wrote: > > Hi Sendy, > > You may want to have a look at the following link: > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. > You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. > > Best > Jan-Mathijs > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.caffarra at bcbl.eu Tue Nov 12 10:30:50 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Tue, 12 Nov 2013 10:30:50 +0100 (CET) Subject: [FieldTrip] help In-Reply-To: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> Message-ID: <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Thanks a lot. Now it works ;) Sendy ----- Original Message ----- From: "jan-mathijs schoffelen" To: "FieldTrip discussion list" Sent: Tuesday, November 12, 2013 9:48:13 AM Subject: Re: [FieldTrip] help Hi Max, When you specify the channel to be left out, you have to name it according to how it's named in your data. I believe that the 'refchan' is only called like that for the purpose of the example. So, when you have a single reference channel, named 'thisisthenameofyourreferencechannel', you need to specify '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for exaggerating, but perhaps the silly name brings across the message more clearly. Note, that when you have applied a common average reference, you could at random remove a channel (not advisable). In that case I'd specify the dimensionality of your data space prior to calling ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG channels). Best, Jan-Mathijs On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 12 10:53:17 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 10:53:17 +0100 Subject: [FieldTrip] selecting which dimension to average over in ft_singleplotER In-Reply-To: <527BEC4A.5070401@gmail.com> References: <527BEC4A.5070401@gmail.com> Message-ID: <03828B8D-5EBC-414F-9EAB-596C0C043EEF@donders.ru.nl> Hi Matt, In general, when dealing with time-frequency data, it is advisable to use ft_singleplotTFR, rather than ft_singleplotER. This will show the data both as a function of time and frequency. Interesting that ft_singleplotER works in the first place. If you want to visualize coherence as a function of frequency (i.e. collapsing across time) you can easily do this 'by hand': C = mean(fd.cohspctrm,3); figure;plot(fd.freq, C); Alternatively, you could use 'mtmfft' as a method for your spectral estimation, which yields frequency domain info without a time dimension. Once you have this, you can use ft_singleplotER (now it is ER confusingly) to visualize the data. Best, Jan-Mathijs On Nov 7, 2013, at 8:38 PM, mattmizumi at gmail.com wrote: > A simple newbie question about ft_singleplotER: given a coherence spectrum, as follows, > > fd = > > labelcmb: {'vStr1' 'vStr2'} > dimord: 'chan_freq_time' > cohspctrm: [1x100x101 double] > freq: [1x100 double] > time: [1x101 double] > dof: [1x100 double] > cfg: [1x1 struct] > > how can I plot frequency against coherence? The default behavior of ft_singleplotER in this case is to average over frequency: > > cfg = []; > cfg.parameter = 'cohspctrm'; > cfg.refchannel = 'vStr2'; > cfg.channel = 'vStr1'; > ft_singleplotER(cfg, fd); > > selected 1 channels for cohspctrm > selection cohspctrm along dimension 2 > averaging cohspctrm over freq > the call to "ft_singleplotER" took 0 seconds > > ..but I cannot find a way to get it to average over time instead. How can I do this? > > (Of course, I know I can plot this manually. But I would like to understand how to use the ft plotting functions. I can't find anything pertinent in the coherence and plotting tutorials, or the help for ft_singleplotER.) > > Thanks! > > -- Matt > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 10:58:42 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 10:58:42 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: <6625F8BF-815B-40B6-8F2C-6D4C68CB8675@donders.ru.nl> Hi Nicola, Would it make sense to look into the possibility to improve support for using the polhemus info from the .fif file directly? It sounds a bit silly that you have to go through another piece of software to be able to read in the data. From ft_read_headshape it seems that *.fif files are supported, could it be that your data is not recognized as such? Best, JM On Nov 6, 2013, at 11:52 AM, Nicola Molinaro wrote: > Thanks guys for any possible help. Really appreciate it! > > I will summarize my tests: > > 1. reading the COR-.fif produced by MRIlab with ft_read_mri > > Well, it seems that ft_read_mri reads the original (not coregistered) .fif file produced in earlier steps of the forward model calculation (COR.fif). For example, if I delete the COR.fif file, ft_read_mri gives an error. ft_read_mri applied to the COR-.fif should be able to read some header, and for this reason I tried the option suggested by Joram (including ft_volumereslice). However, when I plot the volume head model with > > hs=ft_read_headshape(.fif. 'unit','mm'); %get headshape points > ft_plot_vol(vol) > ft_plot_headshape(hs) > > There is an evident misalignment between isotrack points and the brain volume. I mean NO coregistration is done. you can also appreciate it when plotting a prearicular instead of the nasion with > > cfg = []; > cfg.location = [66.4 0 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > ft_sourceplot(cfg,mri); > > Take home message: Fieldtrip does not read the coregistration done in MRIlab, and you have to coregister MEG and MRI again. > > 2. Using > > cfg.method = 'headshape' > cfg.headshape = 'XXX.pos' > > for ft_volumerealign. I played with it, but in neuromag the polhemous data are within the header of the .fif file. You can export the isotrack point however from MRIlab. After importing then with > > File>Import>Isotrack data > > you can then export them with > > File>Export>Points > > and specifying the coordinate system in which you want your point (either Head, or MRI or Voxel). This file cannot be read by ft_volumerealign with the headshape method. However, the first three lines of the resulting .txt file will give you the nasion and the two pre-auricolar points positions. I tried importing the voxel positions of the three points in ft_volumerealign using the method > > cfg.coordsys = 'neuromag'; > cfg.method = 'fiducial'; > > And it worked, the brain volume is aligned with the isotrack points. This is the only solution that is visually reliable to perform > > > On Wed, Nov 6, 2013 at 10:06 AM, Joram van Driel wrote: > Hi Nicola, > > I also did coregistration in MRI-lab using isotrak data. > Importing the fif files in fieldtrip worked fine, I don’t think you have to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial ingredient. > This worked for me: > > mri = ft_read_mri(); %%% read the MRI; the fif file is in mm but FT changes it into meters > mri = ft_convert_units(mri,'mm'); %%% make it mm as it originally was > mri = ft_volumereslice([], mri); %%% after this function the ficual points in the MEG header match the coordinates in the MRI > > Then you should indeed check this with ft_sourceplot, where in the cfg you can fill in fiducial points to check if they make sense, e.g.: > > cfg = []; > cfg.location = [0 90.5 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > > ft_sourceplot(cfg,mri); > > Hope this helps. > Best, > Joram > > On 05 Nov 2013, at 09:43, jan-mathijs schoffelen wrote: > >> Dear Nicola, >> >> I am forwarding your question to the list, "ter lering ende vermaak": >> >> Begin forwarded message: >> >>> From: Nicola Molinaro >>> Date: November 4, 2013 2:16:20 PM GMT+01:00 >>> To: jan-mathijs schoffelen >>> Subject: mm -> voxels ?? >>> >>> Hi Jan, >>> I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? >>> I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). >>> >>> Thanks >>> >>> Nicola >> >> >> Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? >> To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. >> Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. >> I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). >> >> Best wishes, >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > -- > > ------------------------------ > Nicola Molinaro, Phd > Staff Scientist > www.bcbl.eu > > Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hanneke.vanDijk at med.uni-duesseldorf.de Tue Nov 12 11:28:33 2013 From: Hanneke.vanDijk at med.uni-duesseldorf.de (Hanneke.vanDijk at med.uni-duesseldorf.de) Date: Tue, 12 Nov 2013 10:28:33 +0000 Subject: [FieldTrip] [Fieldtrip] question about coregistration Message-ID: <495873C58A622E45A3ABF4813B9451EC6E3EF242@MAIL3-UKD.VMED.UKD> Hi Nicola and Jan-Mathijs, A simple solution can also be to save the points (the fiducials) that you have collected in MRIlab in 'voxel'. After we do the realignment with the polhemus data, we delete all points. We then create points at the final fiducial locations and export these. In this 'Export points' window you can select if you want to save them in head or voxel coordinates. The resulting .txt files can be read in matlab, and you can use them to realign the MRI in fieldtrip. Good luck! Thanks for the info as well, Jan-Mathijs! I didn't know about the two step solution in Fieldtrip, but will certainly give it a try! Groetjes Hanneke __________________________________________ Hanneke van Dijk, PhD http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html Institute for Clinical Neuroscience, Heinrich Heine Universität Düsseldorf, Germany Hanneke.vanDijk at med.uni-duesseldorf.de Tel. +49 (0) 211 81 13074 __________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 11:57:59 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 11:57:59 +0100 Subject: [FieldTrip] connectivity analysis In-Reply-To: References: Message-ID: <19A3518D-5E2A-452B-BA89-918B8FD18BC5@donders.ru.nl> Hi Bart, If you 7 frequency bins within each frequency bin are considered to belong to the same frequency band, I'd suggest to use the multitaper approach to estimate the spectral parameters per frequency band, using just a single frequency bin to represent the whole band of interest. So, rather than for example estimating from 15 until 21 Hz in steps of 1 Hz, you can also estimate only at 18, using cfg.tapsmofrq = 3 in ft_freqanalysis. I suggest to have a look at the documentation on the FT-wiki that is concerned with frequency analysis. I would certainly not average the spectral representation prior to computing the coherence, neither across the individual frequency bins, and even more certainly not across trials. Regarding statistics, I don't want to discourage you, but I don't think it makes sense to attempt doing statistics at the channel level to begin with, due to the effects of volume conduction. Also, in any group comparison (but also when doing a comparison across conditions), if there is any between groups in terms of SNR (e.g. more or less alpha power across groups) you are bound to find a statistically significant difference in estimated connectivity as well. It remains to be motivated in such a case, that the change in estimated connectivity actually reflects a change in true connectivity. If you want to do statistics irrespective of these caveats, you may want to look into FieldTrip's implementation of the non-parametric permutation testing framework. There is ample documentation about this on our wiki as well. Best wishes, Jan-Mathijs On Oct 30, 2013, at 1:22 PM, Bart Michiels wrote: > Hi, > > I have 30 patients and 30 controls and I'm investigating their coherence (EEG, 128 electrodes). Every patient has ~30 trials resting state eyes open consisting of 7 frequency bins with 7 frequencies in each bin. My goal is to show connectivity differences between different brain regions in the control and patient group (doing electrode-level analysis now, source-level analysis is next step). > > - Is it more appropriate to keep the averaging step as the latest step (ie. calculate all coherence for all the different subjects, for all trials, for all different frequencies in frequency bins) or is it better to do the averaging asap (ie. average all frequencies in 1 frequency bin at the time-frequency analysis step, average all trials at the ft_freqdescriptives step, ...) > > - Is there any better way to do some statistics on the 128x128x7x7 (128 electrodes, 7 frequency bins, 7 frequencies in each bin) besides using the ttest2() matlab function? > > Any tips & tricks are more then welcome! > > Bart > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 12:01:56 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 12:01:56 +0100 Subject: [FieldTrip] event related fields from source space In-Reply-To: References: Message-ID: <883F9839-5A9F-47C4-AC26-8B6C26C65060@donders.ru.nl> Dear Kaelasha, Yes indeed, the source.avg.mom contains per dipole location an estimate of the event-related field/potential in the x/y/z direction. You can reduce the dimensionality of these 3D time series by subsequently calling ft_sourcedescriptives with cfg.projectmom='yes'; Best, Jan-Mathijs On Oct 31, 2013, at 12:44 AM, Kaelasha Tyler wrote: > FieldTripers, > > I am wanting to reconstruct event related fields from source space and have been beamforming with ft_sourceanalysis using cfg.method='lcmv'. > > I have not been able to find any clear instructors on this, but can any one tell me, does ft_sourceanalysis output 'data.avg.mom' contain the averaged ERPs reconstructed in source space? > > data.avg.mom appears to be a column of cells, one cell for each point in my 3d grid, with each cell containing 3 time series (ERFs), one for each 3d orientation??, x, y, z? > > Can any one tell me if this is indeed what I am looking at in data.avg.mom? > > Regards, > Kaelasha Tyler > PhD candidate > Swinbunre University of Technology > Australia > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 12:05:52 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 12:05:52 +0100 Subject: [FieldTrip] visualize source localization data In-Reply-To: References: Message-ID: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> Hi Leo, Could you just do a simple plot to first get a feel of what the range of the data is, i.e. plot(source.time, source.avg.pow); This will inform you about sensible axis limits. Then, don't use a maskparameter for the time being (only a funparameter). Does this allow you to see the data in ft_sourcemovie? Best, Jan-Mathijs On Oct 29, 2013, at 10:30 AM, Leopold Zizlsperger wrote: > Dear all, > I have a question concerning source localization implementation. I need help in the very last step of visualizing a difference between 2 conditions over time: > > I get there by using the tutorial steps on single subject functional EEG data (fieldtrip-20130914; tried both WIN and MAC): > > clear all; > load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_rHFdemeanktkt.mat') > load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_lHFdemeanktkt.mat') > load leadfield; > load vol; > load elec_aligned; > > > cfg = []; > cfg.method = 'mne'; > cfg.elec = elec_aligned; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.mne.prewhiten = 'yes'; > cfg.mne.lambda = 3; > cfg.mne.scalesourcecov = 'yes'; > cfg.mne.normalize = 'yes'; > sourcerHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_rHFdemeanktkt); > sourcelHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_lHFdemeanktkt); > > save source sourcerHF sourcelHF; > > clear all; > > load source; > load sourcespace; > > bnd.pnt = sourcespace.pnt; > bnd.tri = sourcespace.tri; > m=sourcerHF.avg.pow(:,1200); > ft_plot_mesh(bnd, 'vertexcolor', m); > > > > > In ft_defaults at 74 > In ft_sourceanalysis at 146 > the input is timelock data with 32 channels and 7000 timebins > using headmodel specified in the configuration > using electrodes specified in the configuration > determining source compartment (3) > projecting electrodes on skin surface > combining electrode transfer and system matrix > creating dipole grid based on user specified dipole positions > using headmodel specified in the configuration > using gradiometers specified in the configuration > 8196 dipoles inside, 0 dipoles outside brain > the call to "ft_prepare_sourcemodel" took 0 seconds > estimating current density distribution for repetition 1 > using pre-computed leadfields: some of the specified options will not have an effect > computing the solution where the noise covariance is used for regularisation > prewhitening the leadfields using the noise covariance > scaling the source covariance > the call to "ft_sourceanalysis" took 10 seconds > the input is timelock data with 32 channels and 7000 timebins > using headmodel specified in the configuration > using electrodes specified in the configuration > determining source compartment (3) > projecting electrodes on skin surface > combining electrode transfer and system matrix > creating dipole grid based on user specified dipole positions > using headmodel specified in the configuration > using gradiometers specified in the configuration > 8196 dipoles inside, 0 dipoles outside brain > the call to "ft_prepare_sourcemodel" took 0 seconds > estimating current density distribution for repetition 1 > using pre-computed leadfields: some of the specified options will not have an effect > computing the solution where the noise covariance is used for regularisation > prewhitening the leadfields using the noise covariance > scaling the source covariance > the call to "ft_sourceanalysis" took 87 seconds > >> > > cfg = []; > cfg.projectmom = 'yes'; > sdrHF = ft_sourcedescriptives(cfg,sourcerHF); > sdlHF = ft_sourcedescriptives(cfg, sourcelHF); > > sdDIFF = sdrHF; > sdDIFF.avg.pow = sdrHF.avg.pow - sdlHF.avg.pow; > sdDIFF.tri = sourcespace.tri; > > save sd sdrHF sdlHF sdDIFF; > > Then I tried different suggestions from the tutorial or the mailing list: > > cfg = []; > cfg.mask = 'avg.pow'; > ft_sourcemovie(cfg,sdDIFF); > > the input is source data with 8196 positions > baseline correcting dipole moments [--------------------------------------\] > projecting dipole moment [------------------------------------------------/] > computing power [---------------------------------------------------------|] > the call to "ft_sourcedescriptives" took 32 seconds > the input is source data with 8196 positions > baseline correcting dipole moments [---------------------------------------] > projecting dipole moment [------------------------------------------------\] > computing power [----------------------------------------------------------] > the call to "ft_sourcedescriptives" took 33 seconds > the input is source data with 8196 vertex positions and 16384 triangles > Warning: use cfg.maskparameter instead of cfg.mask > > In ft_checkconfig at 120 > In ft_sourcemovie at 48 > ??? Error using ==> set > Bad property value found. > Object Name : axes > Property Name : 'CLim' > Values must be increasing and non-NaN. > > Error in ==> caxis at 80 > set(ax,'CLim',arg); > > Error in ==> ft_sourcemovie at 263 > caxis(cfg.zlim); > > > > If I set a break before this point I can see that "arg" indeed contains two NaNs only. > > Do you have any suggestions why the script above fails to determine the axes properties? > > Alternatively I tried: > > figure > sdDIFF.tri = sourcespace.tri; > cfg = []; > cfg.alim = [0 0.5]; > cfg.zlim = [0 0.5]; > cfg.maskparameter = 'avg.pow'; > ft_sourcemovie(cfg,sdDIFF); > > > That results in a GUI that does seem to work but in the time course there is no activity displayed. > > Any advice how to visualize the difference properly? > Thanks in advance. > Best > Leo > RWTH Aachen Neurology > > > P.S. > structure of the difference sdDIFF: > > time: [1x7000 double] > pos: [8196x3 double] > inside: [8196x1 double] > outside: [1x0 double] > method: 'average' > avg: [1x1 struct] > cfg: [1x1 struct] > tri: [16384x3 int32] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Tue Nov 12 14:51:49 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Tue, 12 Nov 2013 14:51:49 +0100 Subject: [FieldTrip] fieldtrip Digest, Vol 36, Issue 16 In-Reply-To: References: Message-ID: Dear Hanneke, this is exactly what I did, however, for better exploring the possibilities I also added an extra z point: lpa = [187.46 179.33 153.30]; nas = [127.59 147.10 244.07]; rpa = [ 69.76 185.61 147.85]; zpoint = [ 99.19 83.57 132.39]; and running ft_volumerealign with 'fiducials' everything calculated in voxel coordinates and since I was curiously biased by this webpage (outdated maybe but did not find anything updated): http://fieldtrip.fcdonders.nl/example/read_neuromag_mri_and_create_single-subject_grids_in_individual_head_space_that_are_all_aligned_in_mni_space I tried to switch a little bit the coordinates exchanging 'y' and 'x' (and it does not work) and exchanging lpa and rpa (I should have the zpoint that saves me anyway). When I plot all these points with the MEG channel's coordinates and the brain volume: vol = ft_convert_units(vol,'cm'); mri_real = ft_convert_units(mri_real,'cm'); hs=ft_read_headshape('.fif', 'unit','cm'); %get headshape points ft_plot_vol(vol) ft_plot_headshape(hs) hold plot3(hs.fid.pnt(:,1),hs.fid.pnt(:,2),hs.fid.pnt(:,3),'b+') plot3(DATA.grad.chanpos(:,1),DATA.grad.chanpos(:,2),DATA.grad.chanpos(:,3),'k*') everything seems perfect independently from switching lpa and rpa. However, after source reconstruction, when I interpolate cfg=[]; cfg.parameter='avg.pow'; inter_lcmv=ft_sourceinterpolate(cfg, lcmvdiff, mri_real); and plot my data cfg = []; cfg.method = 'slice'; cfg.coordsys = 'neuromag'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.funcolorlim = [4 10]; cfg.opacitylim = [4 10]; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg,inter_lcmv); everything changes (unpredictably) depending on the coordinates of the lpa and rpa. I suspect there is something about ft_sourceinterpolate and ft_sourceplot I don't control. Actually, I tried also doing fine-grained realignment also with the headshape points as suggested by Jan (pretty slow ft_volumerealign with method headshape and isotrack points read form a .fif file). A part that realignment was not really nice (maybe because we took many isotrack points along the nose), ft_sourceplot gave new different results... Now I am kind of lost. Nicola > Message: 1 > Date: Tue, 12 Nov 2013 10:28:33 +0000 > From: > To: > Subject: Re: [FieldTrip] [Fieldtrip] question about coregistration > Message-ID: > <495873C58A622E45A3ABF4813B9451EC6E3EF242 at MAIL3-UKD.VMED.UKD> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nicola and Jan-Mathijs, > > > A simple solution can also be to save the points (the fiducials) that you > have collected in MRIlab in 'voxel'. After we do the realignment with the > polhemus data, we delete all points. We then create points at the final > fiducial locations and export these. In this 'Export points' window you can > select if you want to save them in head or voxel coordinates. The resulting > .txt files can be read in matlab, and you can use them to realign the MRI > in fieldtrip. > > Good luck! > > Thanks for the info as well, Jan-Mathijs! I didn't know about the two step > solution in Fieldtrip, but will certainly give it a try! > > Groetjes Hanneke > > > __________________________________________ > > Hanneke van Dijk, PhD > > http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html > Institute for Clinical Neuroscience, > Heinrich Heine Universit?t D?sseldorf, Germany > Hanneke.vanDijk at med.uni-duesseldorf.de Hanneke.vanDijk at med.uni-duesseldorf.de> > Tel. +49 (0) 211 81 13074 > __________________________________________ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131112/b96925a5/attachment-0001.html > > > ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 12 15:11:34 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 12 Nov 2013 09:11:34 -0500 Subject: [FieldTrip] help In-Reply-To: <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> References: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Message-ID: Hi Jan-Mathijs, I had assumed that 'refchan' was a built in fieldtrip thing, that makes more sense now! However, I'm unsure of whether I am supposed to be removing the implicit reference, or the (in my case) linked mastoid references. I ran the data using the cfg.runica.pca = N-1 parameters (I did it as N-2 actually, for the linked mastoid references) as described in the fieldtrip FAQ, Peter, and you, but the data did come out a bit weird, and I would prefer ICA over PCA, so I'll definitely try this as well and see if I get results that make more sense to me. On Tue, Nov 12, 2013 at 4:30 AM, Sendy Caffarra wrote: > Thanks a lot. > Now it works ;) > > > Sendy > > ----- Original Message ----- > From: "jan-mathijs schoffelen" > To: "FieldTrip discussion list" > Sent: Tuesday, November 12, 2013 9:48:13 AM > Subject: Re: [FieldTrip] help > > > Hi Max, > > > When you specify the channel to be left out, you have to name it according > to how it's named in your data. I believe that the 'refchan' is only called > like that for the purpose of the example. > So, when you have a single reference channel, named > 'thisisthenameofyourreferencechannel', you need to specify > '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for > exaggerating, but perhaps the silly name brings across the message more > clearly. Note, that when you have applied a common average reference, you > could at random remove a channel (not advisable). In that case I'd specify > the dimensionality of your data space prior to calling > ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG > channels). > > > Best, > Jan-Mathijs > > > > On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: > > > > I'm having this issue as well, only with EEG data, and at resamplefs = > 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and > also set path for EEGlab toolbox, but the issue persists. Any help would be > greatly appreciated. > > > Thank you, > Max > > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < > stephen.whitmarsh at gmail.com > wrote: > > > > Hi Sendy, JM, > > > In addition, that error also happens (or used to, at least) when you have > not selected MEG as channels, therefor applying ICA e.g. also on your EOG > channels etc. as well. > > > Cheers, > Stephen > > > > > > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl > wrote: > > > > > > > Hi Sendy, > > > You may want to have a look at the following link: > > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > > I assume that your data has been passed through the MaxFilter, which > massively reduces the rank of your data, causing the ICA algorithm to spit > out complex valued numbers. > You need to reduce the rank of your data prior to running the component > decomposition, to be less that then true rank in your data. > > > Best > Jan-Mathijs > > > > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as > following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components > using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should > be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic > distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', > 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not > work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 15:59:54 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 15:59:54 +0100 Subject: [FieldTrip] coregistration question In-Reply-To: References: Message-ID: Ciao Nicola, What do you mean with 'everything changes (unpredictably) depending on the coordinates of the lpa and rpa.'? The interpolation of the source-reconstructed results and the visualization of the interpolated results will be wrong if the initial coregistration is wrong to begin with. But this should already show up as a strange topography in the source reconstructed data. JM > > > > > > > > Message: 1 > Date: Tue, 12 Nov 2013 10:28:33 +0000 > From: > To: > Subject: Re: [FieldTrip] [Fieldtrip] question about coregistration > Message-ID: > <495873C58A622E45A3ABF4813B9451EC6E3EF242 at MAIL3-UKD.VMED.UKD> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nicola and Jan-Mathijs, > > > A simple solution can also be to save the points (the fiducials) that you have collected in MRIlab in 'voxel'. After we do the realignment with the polhemus data, we delete all points. We then create points at the final fiducial locations and export these. In this 'Export points' window you can select if you want to save them in head or voxel coordinates. The resulting .txt files can be read in matlab, and you can use them to realign the MRI in fieldtrip. > > Good luck! > > Thanks for the info as well, Jan-Mathijs! I didn't know about the two step solution in Fieldtrip, but will certainly give it a try! > > Groetjes Hanneke > > > __________________________________________ > > Hanneke van Dijk, PhD > http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html > Institute for Clinical Neuroscience, > Heinrich Heine Universit?t D?sseldorf, Germany > Hanneke.vanDijk at med.uni-duesseldorf.de > Tel. +49 (0) 211 81 13074 > __________________________________________ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > Nicola Molinaro, Phd > Staff Scientist > www.bcbl.eu > > Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.trautmann-lengsfeld at uke.de Tue Nov 12 17:26:18 2013 From: s.trautmann-lengsfeld at uke.de (Dr. Sina A. Trautmann-Lengsfeld) Date: Tue, 12 Nov 2013 17:26:18 +0100 Subject: [FieldTrip] Announcing Symposium 2014 in Hamburg: Synaesthesia in Perspective: Development, Networks, and Multisensory Processing Message-ID: <528256AA.1070508@uke.de> *Synaesthesia in Perspective: Development, Networks, and* *Multisensory Processing* ** *Organizers*: Tessa M. van Leeuwen, Sina A. Trautmann-Lengsfeld, Peter König, Jianwei Zhang, Andreas K. Engel *Location*: Universitätsklinikum Hamburg-Eppendorf, Hamburg, Germany *Date*: February 28th - March 1st 2014 *Website and registration*: http://www.multisense.org/index.php/symposium-2014 Dear Fieldtriplist! We are pleased to announce our symposium on synaesthesia and multisensory processing from February 28th to March 1st 2014 in Hamburg. Synaesthesia is a fascinating phenomenon in which different senses are mixed: for synaesthetes, specific sensory stimuli automatically trigger additional perceptual experiences that are not normally perceived by non-synaesthetes. Studying synaesthesia is interesting by itself, allowing for exploration of the nature of conscious experiences. The aim of the planned symposium, however, is to put synaesthesia in perspective by also emphasizing the relevance of synaesthesia for other fields of study, such as multisensory processing, sensory substitution, development of sensory processing, and connectivity in sensory systems. Participation is free of charge but registration via the website is required. Participants are welcome to present a poster during one of the two poster sessions. We are looking forward to seeing you in Hamburg! * Confirmed speakers* Amir Amedi, /Jerusalem, Israel / Andreas Engel, /Hamburg, Germany / Anil Seth, /Brighton, United Kingdom/ Brigitte Röder, /Hamburg, Germany / Charles Spence, /Oxford, United Kingdom/ Christoph Kayser, /Glasgow, United Kingdom / Christopher Sinke, /Hamburg, Germany/ Danko Nikolic, /Frankfurt am Main, Germany / David Brang, /Chicago, USA/ Devin Blair Terhune, /Oxford, United Kingdom/ Jamie Ward, /Brighton, United Kingdom/ Jianwei Zhang, /Hamburg, Germany/ Julia Simner, /Edinburgh, United Kingdom/ Ladan Shams, /Los Angeles, USA/ Micah Murray, /Lausanne, Switzerland / Nicolas Rothen, /Brighton, United Kingdom/ Olympia Colizoli/, Amsterdam, the Netherlands / Peter König, /Osnabru?ck, Germany / Petra Stoerig, /Du?sseldorf, Germany/ Roi Cohen Kadosh, /Oxford, United Kingdom / Romke Rouw, /Amsterdam, the Netherlands/ Sina A. Trautmann-Lengsfeld, /Hamburg, Germany/ Tessa van Leeuwen/, Frankfurt am Main, Germany/ Virginie van Wassenhove, /Paris, France/ -- Dr. Sina Alexa Trautmann-Lengsfeld Postdoc Dept. of Neurophysiology and Pathophysiology University Medical Center Hamburg-Eppendorf Martinistr. 52 20246 Hamburg Germany Phone: +49-40-7410-57238 Fax: +49-40-7410-57752 Email: s.trautmann-lengsfeld at uke.de -- Besuchen Sie uns auf: www.uke.de _____________________________________________________________________ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik _____________________________________________________________________ SAVE PAPER - THINK BEFORE PRINTING -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Tue Nov 12 17:48:36 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Tue, 12 Nov 2013 17:48:36 +0100 Subject: [FieldTrip] coregistration question Message-ID: Hi Jan-Mathijs, everything started from the fact that I tried to source reconstruct a M1 ERF visual response as a test. The effect at the source level was clearly posterior in the MEG sensors. However, the source reconstruction gave me a solution with its maximum in the orbitofrontal regions of the brain. This result emerged when I employed the "correct fiducials" extracted from the Neuromag software. I thought that maybe I had to flip some landmarks to have the effect on the back of the brain. That's why I switched rpa and lpa, with however a more sparse solution. I suspect that grid, isotrack points and MEG channels are ok (when I plot them together in Matlab they are well aligned). Somehow, when I interpolate the power with the realigned brain something goes wrong, and the ft_sourceplot (the one of my previous e-mail) give me the results I described above. I also have to admit that ft_sourceplot in 'neuromag' coordinates shows the brain upside-down. N -- ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 12 19:13:25 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 12 Nov 2013 13:13:25 -0500 Subject: [FieldTrip] help In-Reply-To: References: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Message-ID: So we decided to remove both linked mastoid references for the ICA, and it works just fine now. Thank you so much! On Tue, Nov 12, 2013 at 9:11 AM, Max Cantor wrote: > Hi Jan-Mathijs, > > I had assumed that 'refchan' was a built in fieldtrip thing, that makes > more sense now! However, I'm unsure of whether I am supposed to be removing > the implicit reference, or the (in my case) linked mastoid references. I > ran the data using the cfg.runica.pca = N-1 parameters (I did it as N-2 > actually, for the linked mastoid references) as described in the fieldtrip > FAQ, Peter, and you, but the data did come out a bit weird, and I would > prefer ICA over PCA, so I'll definitely try this as well and see if I get > results that make more sense to me. > > > On Tue, Nov 12, 2013 at 4:30 AM, Sendy Caffarra wrote: > >> Thanks a lot. >> Now it works ;) >> >> >> Sendy >> >> ----- Original Message ----- >> From: "jan-mathijs schoffelen" >> To: "FieldTrip discussion list" >> Sent: Tuesday, November 12, 2013 9:48:13 AM >> Subject: Re: [FieldTrip] help >> >> >> Hi Max, >> >> >> When you specify the channel to be left out, you have to name it >> according to how it's named in your data. I believe that the 'refchan' is >> only called like that for the purpose of the example. >> So, when you have a single reference channel, named >> 'thisisthenameofyourreferencechannel', you need to specify >> '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for >> exaggerating, but perhaps the silly name brings across the message more >> clearly. Note, that when you have applied a common average reference, you >> could at random remove a channel (not advisable). In that case I'd specify >> the dimensionality of your data space prior to calling >> ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG >> channels). >> >> >> Best, >> Jan-Mathijs >> >> >> >> On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: >> >> >> >> I'm having this issue as well, only with EEG data, and at resamplefs = >> 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and >> also set path for EEGlab toolbox, but the issue persists. Any help would be >> greatly appreciated. >> >> >> Thank you, >> Max >> >> >> >> On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < >> stephen.whitmarsh at gmail.com > wrote: >> >> >> >> Hi Sendy, JM, >> >> >> In addition, that error also happens (or used to, at least) when you have >> not selected MEG as channels, therefor applying ICA e.g. also on your EOG >> channels etc. as well. >> >> >> Cheers, >> Stephen >> >> >> >> >> >> >> >> >> >> On 8 November 2013 11:08, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl > wrote: >> >> >> >> >> >> >> Hi Sendy, >> >> >> You may want to have a look at the following link: >> >> >> >> http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component >> >> >> I assume that your data has been passed through the MaxFilter, which >> massively reduces the rank of your data, causing the ICA algorithm to spit >> out complex valued numbers. >> You need to reduce the rank of your data prior to running the component >> decomposition, to be less that then true rank in your data. >> >> >> Best >> Jan-Mathijs >> >> >> >> >> On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: >> >> >> >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as >> following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components >> using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should >> be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic >> distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', >> 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not >> work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> >> >> >> >> >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> >> >> >> >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajatthomas at gmail.com Wed Nov 13 01:25:55 2013 From: rajatthomas at gmail.com (Rajat Thomas) Date: Wed, 13 Nov 2013 01:25:55 +0100 Subject: [FieldTrip] Plotting network arrows Message-ID: Dear all, Can FT do the following: I get a bunch of connected nodes (channels, sources whatever) and their connection strength. If there any way of plotting like curved arrows from node to the other (with varying thickness to reflect strength) ? Thanks. Rajat -- Rajat Mani Thomas Netherlands Institute for Neuroscience Amsterdam, The Netherlands http://www.cita.utoronto.ca/~thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.trautmann-lengsfeld at uke.de Wed Nov 13 13:03:10 2013 From: s.trautmann-lengsfeld at uke.de (Dr. Sina A. Trautmann-Lengsfeld) Date: Wed, 13 Nov 2013 13:03:10 +0100 Subject: [FieldTrip] Announcing Symposium 2014 in Hamburg: Synaesthesia in Perspective: Development, Networks, and Multisensory Processing In-Reply-To: <528256AA.1070508@uke.de> References: <528256AA.1070508@uke.de> Message-ID: <52836A7E.50409@uke.de> Dear Fieldtriplist, unfortunately, the link of our symposium website did not work in some cases. I apologize for that. Here is the corrected link and the announcement one more time. www.multisense.org/index.php/symposium-2014 > *Synaesthesia in Perspective: Development, Networks, and* > > *Multisensory Processing* > > ** > > *Organizers*: Tessa M. van Leeuwen, Sina A. Trautmann-Lengsfeld, > > Peter König, Jianwei Zhang, Andreas K. Engel > > *Location*: Universitätsklinikum Hamburg-Eppendorf, Hamburg, Germany > > *Date*: February 28th - March 1st 2014 > > *Website and registration*: > www.multisense.org/index.php/symposium-2014 > > > Dear Fieldtriplist! > > We are pleased to announce our symposium on synaesthesia and > multisensory processing from February 28th to March 1st 2014 in Hamburg. > > > Synaesthesia is a fascinating phenomenon in which different senses are > mixed: for synaesthetes, specific sensory stimuli automatically > trigger additional perceptual experiences that are not normally > perceived by non-synaesthetes. > > > Studying synaesthesia is interesting by itself, allowing for > exploration of the nature of conscious experiences. The aim of the > planned symposium, however, is to put synaesthesia in perspective by > also emphasizing the relevance of synaesthesia for other fields of > study, such as multisensory processing, sensory substitution, > development of sensory processing, and connectivity in sensory > systems. Participation is free of charge but registration via the > website is required. Participants are welcome to present a poster > during one of the two poster sessions. We are looking forward to > seeing you in Hamburg! > > * > Confirmed speakers* > > Amir Amedi, /Jerusalem, Israel / > > Andreas Engel, /Hamburg, Germany / > > Anil Seth, /Brighton, United Kingdom/ > > Brigitte Röder, /Hamburg, Germany / > > Charles Spence, /Oxford, United Kingdom/ > > Christoph Kayser, /Glasgow, United Kingdom / > > Christopher Sinke, /Hamburg, Germany/ > > Danko Nikolic, /Frankfurt am Main, Germany / > > David Brang, /Chicago, USA/ > > Devin Blair Terhune, /Oxford, United Kingdom/ > > Jamie Ward, /Brighton, United Kingdom/ > > Jianwei Zhang, /Hamburg, Germany/ > > Julia Simner, /Edinburgh, United Kingdom/ > > Ladan Shams, /Los Angeles, USA/ > > Micah Murray, /Lausanne, Switzerland / > > Nicolas Rothen, /Brighton, United Kingdom/ > > Olympia Colizoli/, Amsterdam, the Netherlands / > > Peter König, /Osnabru?ck, Germany / > > Petra Stoerig, /Du?sseldorf, Germany/ > > Roi Cohen Kadosh, /Oxford, United Kingdom / > > Romke Rouw, /Amsterdam, the Netherlands/ > > Sina A. Trautmann-Lengsfeld, /Hamburg, Germany/ > > Tessa van Leeuwen/, Frankfurt am Main, Germany/ > > Virginie van Wassenhove, /Paris, France/ > > -- > Dr. Sina Alexa Trautmann-Lengsfeld > Postdoc > Dept. of Neurophysiology and Pathophysiology > University Medical Center Hamburg-Eppendorf > Martinistr. 52 > 20246 Hamburg > Germany > Phone: +49-40-7410-57238 > Fax: +49-40-7410-57752 > Email:s.trautmann-lengsfeld at uke.de > > Besuchen Sie uns auf: www.uke.de > > ------------------------------------------------------------------------ > > Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen > Rechts; Gerichtsstand: Hamburg > Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. > Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik > > ------------------------------------------------------------------------ > > SAVE PAPER - THINK BEFORE PRINTING > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Dr. Sina Alexa Trautmann-Lengsfeld Postdoc Dept. of Neurophysiology and Pathophysiology University Medical Center Hamburg-Eppendorf Martinistr. 52 20246 Hamburg Germany Phone: +49-40-7410-57238 Fax: +49-40-7410-57752 Email: s.trautmann-lengsfeld at uke.de -- Besuchen Sie uns auf: www.uke.de _____________________________________________________________________ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik _____________________________________________________________________ SAVE PAPER - THINK BEFORE PRINTING -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony.passaro at gmail.com Wed Nov 13 17:40:20 2013 From: antony.passaro at gmail.com (Antony Passaro) Date: Wed, 13 Nov 2013 11:40:20 -0500 Subject: [FieldTrip] Plotting network arrows In-Reply-To: References: Message-ID: Hi Rajat, The intended Fieldtrip function for plotting connected nodes as you describe it is ft_topoplotCC: http://fieldtrip.fcdonders.nl/reference/ft_topoplotcc Best of luck, -Tony On Tue, Nov 12, 2013 at 7:25 PM, Rajat Thomas wrote: > Dear all, > > Can FT do the following: > > I get a bunch of connected nodes (channels, sources whatever) and their > connection strength. > > If there any way of plotting like curved arrows from node to the other > (with varying thickness to reflect strength) ? > > Thanks. > > Rajat > > -- > Rajat Mani Thomas > Netherlands Institute for Neuroscience > Amsterdam, The Netherlands > http://www.cita.utoronto.ca/~thomas > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Wed Nov 13 18:53:15 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Wed, 13 Nov 2013 18:53:15 +0100 Subject: [FieldTrip] Pre-processing on orthogonal planar gradiometers? Message-ID: Dear FieldTrip users. I want to detect and remove EOG and ECG by using ICA. My data is from a Neuromag 306 MEG scanner with magnetometers and two orthogonal planar gradiometers. I assume that it is recommendable to do the ICA separately on each sensor type separately, i.e. on 1. magnetomers, 2. horizontal planar gradiometers, and then 3. vertical planar gradiometers, because they measure magnetic field changes at different scales and in different directions. Would you recommend to do ICA and other pre-processing steps separately on the horizontal and vertical planar gradiometers, or would you just combine the planar gradiometers with ft_combineplanar immediately? I'm worried that combining the two different gradiometer sensor types would violate underlying assumptions of the pre-processing algorithms, i.e. ICA, filters and baseline correction, because the planar gradiometer values are only positive valued estimates from the combinations of the original gradiometer measures, which do not seem to have oscillatory deflections around a baseline zero valued point. Hope you can help. Greetings Niels. Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcgoiv0 at wfu.edu Wed Nov 13 19:49:34 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Wed, 13 Nov 2013 13:49:34 -0500 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data Message-ID: Hello everybody, I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the ft_timelockanalysis(cfg, data) function? I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. Another way to ask this question is: what is the format/structure of the second input (timelock) in the ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? Thanks, Inna -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Nov 14 09:02:17 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 14 Nov 2013 09:02:17 +0100 Subject: [FieldTrip] Pre-processing on orthogonal planar gradiometers? In-Reply-To: References: Message-ID: Hi Niels, It's perfectly fine to do the ICA etc on the horizontal and vertical planar gradients together. The reason being that the topographies of the artifacts cause (just like the neural sources) gradient fields with arbitrary orientation in 3D space, for which you need both the horizontal and vertical gradient channels to optimally capture this. For that matter it is even better to use them both in the same ICA step. It's absolutely forbidden to first do combineplanar and then try to do ICA on the combined data, because after the combination step (which is non-linear) the linear mixing assumption cannot be made anymore. Combining with the magnetometers would in principle be possible (differences in magnitude are addressed by the prewhitening step in most ICA algorithms), but I don't know how common this is in the field. Perhaps other people could comment on this. Best wishes, Jan-Mathijs On Nov 13, 2013, at 6:53 PM, Niels Trusbak Haumann wrote: > Dear FieldTrip users. > > I want to detect and remove EOG and ECG by using ICA. My data is from a Neuromag 306 MEG scanner with magnetometers and two orthogonal planar gradiometers. > > I assume that it is recommendable to do the ICA separately on each sensor type separately, i.e. on 1. magnetomers, 2. horizontal planar gradiometers, and then 3. vertical planar gradiometers, because they measure magnetic field changes at different scales and in different directions. > > Would you recommend to do ICA and other pre-processing steps separately on the horizontal and vertical planar gradiometers, or would you just combine the planar gradiometers with ft_combineplanarimmediately? > > I'm worried that combining the two different gradiometer sensor types would violate underlying assumptions of the pre-processing algorithms, i.e. ICA, filters and baseline correction, because the planar gradiometer values are only positive valued estimates from the combinations of the original gradiometer measures, which do not seem to have oscillatory deflections around a baseline zero valued point. > > Hope you can help. > > Greetings > Niels. > > Niels Trusbak Haumann > M.A. / PhD student > Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience > Aarhus University / Aarhus University Hospital > E-mail: aestnth at hum.au.dk > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From schuessler at cbs.mpg.de Thu Nov 14 09:41:42 2013 From: schuessler at cbs.mpg.de (Ellen Schuessler) Date: Thu, 14 Nov 2013 09:41:42 +0100 (CET) Subject: [FieldTrip] Append/Average same conditions over sessions In-Reply-To: <777653177.992.1384417995707.JavaMail.root@zimbra> Message-ID: <1301619942.1071.1384418502084.JavaMail.root@zimbra> Dear all, Here a short description of the issue: My data was conducted in 2 sessions (a week in between), both sessions contain all conditions (e.g. A B C D). For each session I will have a bit more than 400 trials to run ICA on. After ICA and after I redefine trials I will have separate files per condition (trials x time) for each session. Then, I want to concatenate conditions over sessions. That is, condition A session 2 should be appended to condition A of session 1 before I average. Now here is my question: I understand that ft_appenddata is mainly used to append different conditions. Additionally I read that files of different days might confuse in the sampleinfo (cf. http://fieldtrip.fcdonders.nl/faq/i_used_to_work_with_trl-matrices_that_have_more_than_3_columns._why_is_this_not_supported_anymore - middle part of the text). This might be true in may case as well? If not, can I just add the two matrices (sessions) horizontally (which sounds a bit too simple in my ears)? Anyway, what would be the best way to average my conditions over sessions and at which operational step? Thank you all very much in advance! If you have any further question please do not hesitate to contact me! Your help is very much appreciated. Ellen -- Ellen Schüßler, Dipl.-Psych. PhD Student Max Planck Institute for Human Cognitive and Brain Sciences Research Group "Subcortical Contributions to Comprehension" Department of Neuropsychology Stephanstraße 1a D-04103 Leipzig Germany Phone: +49 (0) 341 / 99 40 - 2474 Fax: +49 (0) 341 / 99 40 - 2260 Email: schuessler at cbs.mpg.de Web: www.cbs.mpg.de/~schuessler From Lilla.Magyari at mpi.nl Thu Nov 14 12:23:24 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 14 Nov 2013 12:23:24 +0100 (CET) Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> Message-ID: <62505.131.174.46.51.1384428204.squirrel@131.174.46.51> Hi Kidist, Have you checked if the segmentation is OK? The segmentation for a BEM model should contain binary masks of the brain, skull and skin tissues. But these tissues should not overlap and they should form a closed shape without empty space between. One way to check this, if you plot the different tissue-types in the same image. For this, you can convert your binary segmentation to an indexed type segmentation. Here is a FAQ which explains how to do that: http://fieldtrip.fcdonders.nl/faq/how_is_the_segmentation_defined#conversion_between_probabilistic_and_indexed_representations Best, Lilla > Hi Lilla, > > Thank you for your reply. > > The openmeeg works well for the mri (subject01.mri) that is used in the > fieldtrip tutorial. > > But the error comes when I use my subject's mri whose anatomy is > 256*256*192. I have also tried to use mri = ft_volumereslice(cfg,mri) > thinking that the error might be due to the inequality of the size of the > anatomical volume into each direction. > > Kidist > > >> hi Kidist, >> >> I am wondering if you have installed openmeeg properly. Here is a site >> to >> explain it: >> http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling >> >> Have you followed this? >> >> Lilla >> >> >> >>> Hi, >>> >>> I am working with the combined EEG and MEG recording and would like to >>> do >>> the forward model for the EEG. >>> >>> So I was trying to use the 'bemcp' and 'openmeeg' as am working on >>> windows >>> platform. I have the anatomy of my subject (DICOM file stacked and >>> cleaned >>> using SPM). >>> >>> When I try to use openmeeg, vol.mat is missing from the vol structure >>> giving an error message om_minverser.exe doesn't function anymore. >>> >>> When I try to use 'bemcp', vol.mat contains all NaNs which resulted >>> from >>> the c12 and c21 matrices being not a square matrix which makes the >>> inverse >>> to be non-existent and also those matrices consists a large number of >>> 'Inf' entries. >>> >>> Like it was mentioned on one of the forums, the error might come when >>> the >>> meshes are generated. I was able to find the index of the vertices from >>> the Cij matrix, but I couldn't find the actual relation to the >>> vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either >>> brain, >>> skull or scalp. >>> >>> Here are all the steps that I have followed. >>> >>> % reading MRI >>> mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); >>> >>> % segment the brain >>> cfg = []; >>> cfg.output = {'brain', 'skull', 'scalp'}; >>> cfg.coordsys = ''; % here I use the RAS coordsys and for the origin >>> 'i'- >>> interauricular >>> segmentedmri = ft_volumesegment(cfg, mri); >>> segmentedmri.anatomy = mri.anatomy; >>> >>> % prepare mesh >>> cfg = []; >>> cfg.tissue = {'brain','skull', 'scalp'}; >>> cfg.numvertices = [3000 2000 1000]; >>> cfg.transform = segmentedmri.transform; >>> bnd = ft_prepare_mesh(cfg, segmentedmri); >>> >>> % create head model >>> cfg = []; >>> cfg.method = 'openmeeg'; >>> cfg.conductivity = [0.33 0.0041 0.33]; >>> vol = ft_prepare_headmodel(cfg, bnd); >>> >>> figure; >>> ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain >>> figure; >>> ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull >>> figure; >>> ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp >>> >>> Any help? >>> >>> Thanks. >>> Kidist >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From ggonesc at upo.es Fri Nov 15 11:26:52 2013 From: ggonesc at upo.es (Gabriel Gonzalez Escamilla) Date: Fri, 15 Nov 2013 11:26:52 +0100 Subject: [FieldTrip] problem with comparecorr Message-ID: <4ac7c1744427c47.528604fc@upo.es> Dear FildTrip experts, We have two groups and we are performing within group correlations with ft_sourcestatistics using cfg.method='montecarlo';cfg.statistic='corrcoef'; cfg.measure='stat'; cfg.correctm='cluster'; cfg.clusterstatistic='maxsum'; everything looks good on the analysis of every group. We've got negative correlation in GP1, and no correlation in GP2. Then we are performing between-group correlations to compare the regression lines by using cfg.method='montecarlo'; cfg.statistic='comparecorr'; cfg.measure='stat'; cfg.correctm='cluster'; cfg.clusterstatistic='maxsum' on ft_sourcestatistics. for which we are getting a difference between the correlations of the groups (GP1 Vs GP2, as input to ft_sourcestatistics a grandavg matrix containing firstly the subjects on GP1 followed by the subjects of the GP2). This seems to be ok when we perform the between correlation of GP1 Vs GP2, but then we invert the matrix to perform GP2 Vs GP1 (we have checked that the second matrix has the subjects in the correct order, all subjects of the GP2 now followed by subjects of GP1), which should result in the same results as GP1 Vs GP2 but with opposite direction; but instead of showing this, it shows no results. We have perform 1000 and 2000 montecarlo (MC)-permutations to ensure that this results are not biased by little MC-permutations, but every time we get, that in the first direction we get results, but in the inverse direction we never get any results. Is this somehow normal? Can anyone give us so guidence on this? Many thanks in advanced, Gabriel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Fri Nov 15 17:40:04 2013 From: mcantor at umich.edu (Max Cantor) Date: Fri, 15 Nov 2013 11:40:04 -0500 Subject: [FieldTrip] ft_channelrepair not finding electrodes Message-ID: Hi all, I'm trying to perform channel repair on EEG data that has undergone jump, muscle, and visual artifact rejection, and ICA to remove eog and ecg components, unmixed back into the original channels. It's a 61 channel system using a modified easycap layout and neighbours template. The layout has been shown to work on topographic displays, and the template seems to work in that it creates a neighbours object when ft_prepare_neighbours is run on it without any errors. However, I'm getting an error when I attempt to run ft_channelrepair: Error using ft_fetch_sens (line 179) no electrodes or gradiometers specified. Error in ft_channelrepair (line 112) sens = ft_fetch_sens(cfg, data); I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not really sure what elec/sens file I should be reading or how to go about creating it. I was hoping that the template, my data, and/or the layout would contain the necessary information, but given the error on ft_fetch_sens, that doesn't seem to be the case. Any help on this issue would be greatly appreciated. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Sat Nov 16 15:31:52 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Sat, 16 Nov 2013 15:31:52 +0100 Subject: [FieldTrip] failed segmentation Message-ID: <528781D8.1030107@gmail.com> Hi all, has anyone ever had a failed segmentation that looks like the one in the figure? My script works for all participants, I mean, for all other participants the brain is only inside the skull :) But it fails terribly for this one. I thought it could have to do with the placement of the fiducials, and I've played around a bit with that but it didn't solve the problem. If anyone recognises this type of error, I'd be help to hear if/how it can be fixed. Thanks a lot, Vitória -------------- next part -------------- A non-text attachment was scrubbed... Name: segmentation.png Type: image/png Size: 138624 bytes Desc: not available URL: From michelic72 at gmail.com Sat Nov 16 20:18:13 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Sat, 16 Nov 2013 14:18:13 -0500 Subject: [FieldTrip] failed segmentation In-Reply-To: <528781D8.1030107@gmail.com> References: <528781D8.1030107@gmail.com> Message-ID: Hi Vitoria, it looks like there is an artifact on the top of the head. It happened to me already and I had to preprocess the mri volume by using an appropriate cutoff and by thresholding (after plotting the histogram of the grey levels). mri.anatomy = (mri.anatomy>thr).*mri.anatomy; or mri.anatomy(:,:,230:256) = 0; If thresholding is still not effective you might consider applying morphological operators (erode, dilate, open, close), after taking care that you voxel dimensions are cubic (diagonal values of the canonic form of mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. I hope this helps, Cristiano On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai wrote: > Hi all, > > has anyone ever had a failed segmentation that looks like the one in the > figure? > My script works for all participants, I mean, for all other participants > the brain is only inside the skull :) > But it fails terribly for this one. I thought it could have to do with the > placement of the fiducials, and I've played around a bit with that but it > didn't solve the problem. > If anyone recognises this type of error, I'd be help to hear if/how it can > be fixed. > > Thanks a lot, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lilla.Magyari at mpi.nl Sun Nov 17 12:03:15 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Sun, 17 Nov 2013 12:03:15 +0100 (CET) Subject: [FieldTrip] failed segmentation In-Reply-To: References: <528781D8.1030107@gmail.com> Message-ID: <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> hi Vitoria, is this a tpm (the default output of ft_volumesegment)? Have you also tried to segment this mri with an output for 'brain','skull','scalp'? because when you have a binary representation for these tissue-types, they do not overlap, and are closed. So, I am wondering if you end up with a brainmask which do not contain the artifact at the top of the head. Lilla > Hi Vitoria, > it looks like there is an artifact on the top of the head. It happened to > me already and I had to preprocess the mri volume by using an appropriate > cutoff and by thresholding (after plotting the histogram of the grey > levels). > > mri.anatomy = (mri.anatomy>thr).*mri.anatomy; > > or > > mri.anatomy(:,:,230:256) = 0; > > If thresholding is still not effective you might consider applying > morphological operators (erode, dilate, open, close), after taking care > that you voxel dimensions are cubic (diagonal values of the canonic form > of > mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. > > I hope this helps, > Cristiano > > > > On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai > wrote: > >> Hi all, >> >> has anyone ever had a failed segmentation that looks like the one in the >> figure? >> My script works for all participants, I mean, for all other participants >> the brain is only inside the skull :) >> But it fails terribly for this one. I thought it could have to do with >> the >> placement of the fiducials, and I've played around a bit with that but >> it >> didn't solve the problem. >> If anyone recognises this type of error, I'd be help to hear if/how it >> can >> be fixed. >> >> Thanks a lot, Vitória >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From zizlsperger at gmail.com Sun Nov 17 12:26:42 2013 From: zizlsperger at gmail.com (Zizlsperger Leopold) Date: Sun, 17 Nov 2013 12:26:42 +0100 Subject: [FieldTrip] visualize source localization data In-Reply-To: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> References: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> Message-ID: Hello Jan-Mathijs, thanks, you made my day ! Using funparameter instead of maskparameter and rescaling the plot worked fine, now I can see the data in ft_sourcemovie. All the best Leo On Nov 12, 2013, at 12:05 PM, jan-mathijs schoffelen wrote: > Hi Leo, > > Could you just do a simple plot to first get a feel of what the range of the data is, i.e. plot(source.time, source.avg.pow); > > This will inform you about sensible axis limits. Then, don't use a maskparameter for the time being (only a funparameter). > > Does this allow you to see the data in ft_sourcemovie? > > Best, > Jan-Mathijs > > > > > On Oct 29, 2013, at 10:30 AM, Leopold Zizlsperger wrote: > >> Dear all, >> I have a question concerning source localization implementation. I need help in the very last step of visualizing a difference between 2 conditions over time: >> >> I get there by using the tutorial steps on single subject functional EEG data (fieldtrip-20130914; tried both WIN and MAC): >> >> clear all; >> load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_rHFdemeanktkt.mat') >> load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_lHFdemeanktkt.mat') >> load leadfield; >> load vol; >> load elec_aligned; >> >> >> cfg = []; >> cfg.method = 'mne'; >> cfg.elec = elec_aligned; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.mne.prewhiten = 'yes'; >> cfg.mne.lambda = 3; >> cfg.mne.scalesourcecov = 'yes'; >> cfg.mne.normalize = 'yes'; >> sourcerHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_rHFdemeanktkt); >> sourcelHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_lHFdemeanktkt); >> >> save source sourcerHF sourcelHF; >> >> clear all; >> >> load source; >> load sourcespace; >> >> bnd.pnt = sourcespace.pnt; >> bnd.tri = sourcespace.tri; >> m=sourcerHF.avg.pow(:,1200); >> ft_plot_mesh(bnd, 'vertexcolor', m); >> >> >> >> > In ft_defaults at 74 >> In ft_sourceanalysis at 146 >> the input is timelock data with 32 channels and 7000 timebins >> using headmodel specified in the configuration >> using electrodes specified in the configuration >> determining source compartment (3) >> projecting electrodes on skin surface >> combining electrode transfer and system matrix >> creating dipole grid based on user specified dipole positions >> using headmodel specified in the configuration >> using gradiometers specified in the configuration >> 8196 dipoles inside, 0 dipoles outside brain >> the call to "ft_prepare_sourcemodel" took 0 seconds >> estimating current density distribution for repetition 1 >> using pre-computed leadfields: some of the specified options will not have an effect >> computing the solution where the noise covariance is used for regularisation >> prewhitening the leadfields using the noise covariance >> scaling the source covariance >> the call to "ft_sourceanalysis" took 10 seconds >> the input is timelock data with 32 channels and 7000 timebins >> using headmodel specified in the configuration >> using electrodes specified in the configuration >> determining source compartment (3) >> projecting electrodes on skin surface >> combining electrode transfer and system matrix >> creating dipole grid based on user specified dipole positions >> using headmodel specified in the configuration >> using gradiometers specified in the configuration >> 8196 dipoles inside, 0 dipoles outside brain >> the call to "ft_prepare_sourcemodel" took 0 seconds >> estimating current density distribution for repetition 1 >> using pre-computed leadfields: some of the specified options will not have an effect >> computing the solution where the noise covariance is used for regularisation >> prewhitening the leadfields using the noise covariance >> scaling the source covariance >> the call to "ft_sourceanalysis" took 87 seconds >> >> >> >> cfg = []; >> cfg.projectmom = 'yes'; >> sdrHF = ft_sourcedescriptives(cfg,sourcerHF); >> sdlHF = ft_sourcedescriptives(cfg, sourcelHF); >> >> sdDIFF = sdrHF; >> sdDIFF.avg.pow = sdrHF.avg.pow - sdlHF.avg.pow; >> sdDIFF.tri = sourcespace.tri; >> >> save sd sdrHF sdlHF sdDIFF; >> >> Then I tried different suggestions from the tutorial or the mailing list: >> >> cfg = []; >> cfg.mask = 'avg.pow'; >> ft_sourcemovie(cfg,sdDIFF); >> >> the input is source data with 8196 positions >> baseline correcting dipole moments [--------------------------------------\] >> projecting dipole moment [------------------------------------------------/] >> computing power [---------------------------------------------------------|] >> the call to "ft_sourcedescriptives" took 32 seconds >> the input is source data with 8196 positions >> baseline correcting dipole moments [---------------------------------------] >> projecting dipole moment [------------------------------------------------\] >> computing power [----------------------------------------------------------] >> the call to "ft_sourcedescriptives" took 33 seconds >> the input is source data with 8196 vertex positions and 16384 triangles >> Warning: use cfg.maskparameter instead of cfg.mask >> > In ft_checkconfig at 120 >> In ft_sourcemovie at 48 >> ??? Error using ==> set >> Bad property value found. >> Object Name : axes >> Property Name : 'CLim' >> Values must be increasing and non-NaN. >> >> Error in ==> caxis at 80 >> set(ax,'CLim',arg); >> >> Error in ==> ft_sourcemovie at 263 >> caxis(cfg.zlim); >> >> >> >> If I set a break before this point I can see that "arg" indeed contains two NaNs only. >> >> Do you have any suggestions why the script above fails to determine the axes properties? >> >> Alternatively I tried: >> >> figure >> sdDIFF.tri = sourcespace.tri; >> cfg = []; >> cfg.alim = [0 0.5]; >> cfg.zlim = [0 0.5]; >> cfg.maskparameter = 'avg.pow'; >> ft_sourcemovie(cfg,sdDIFF); >> >> >> That results in a GUI that does seem to work but in the time course there is no activity displayed. >> >> Any advice how to visualize the difference properly? >> Thanks in advance. >> Best >> Leo >> RWTH Aachen Neurology >> >> >> P.S. >> structure of the difference sdDIFF: >> >> time: [1x7000 double] >> pos: [8196x3 double] >> inside: [8196x1 double] >> outside: [1x0 double] >> method: 'average' >> avg: [1x1 struct] >> cfg: [1x1 struct] >> tri: [16384x3 int32] >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozancag at gmail.com Mon Nov 18 10:56:37 2013 From: ozancag at gmail.com (=?UTF-8?B?T3phbiDDh2HEn2xheWFu?=) Date: Mon, 18 Nov 2013 11:56:37 +0200 Subject: [FieldTrip] Some fixes to suppress gcc warnings in libbuffer Message-ID: Hi, Trying to build libbuffer, I got a lot of warnings. I'm sending a patch to fix those warnings. I didn't test if this breaks anything so it is up to you to take and/or ignore this. Thanks :) -- Ozan Çağlayan Research Assistant Galatasaray University - Computer Engineering Dept. http://www.ozancaglayan.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fieldtrip-fixes.patch Type: text/x-patch Size: 6226 bytes Desc: not available URL: From jm.horschig at donders.ru.nl Mon Nov 18 11:15:32 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Mon, 18 Nov 2013 11:15:32 +0100 Subject: [FieldTrip] ft_channelrepair not finding electrodes In-Reply-To: References: Message-ID: <5289E8C4.9060605@donders.ru.nl> Hi Max, check out Fieldtrip/template/electrode and see if you can use one of the templates in there. Best would be to use electrode measurements that you actually performed yourself (to get the distances between electrodes right), but using a template might be good as well. Once you found a good template-file, you can set cfg.elecfile = 'folder/filename' and FieldTrip will handle the rest. Otherwise, if some of your colleagues have electrode measurements, you can also ask them for advice. Best, Jörn On 11/15/2013 5:40 PM, Max Cantor wrote: > Hi all, > > I'm trying to perform channel repair on EEG data that has undergone > jump, muscle, and visual artifact rejection, and ICA to remove eog and > ecg components, unmixed back into the original channels. It's a 61 > channel system using a modified easycap layout and neighbours template. > > The layout has been shown to work on topographic displays, and the > template seems to work in that it creates a neighbours object when > ft_prepare_neighbours is run on it without any errors. > > However, I'm getting an error when I attempt to run ft_channelrepair: > > Error using ft_fetch_sens (line 179) > no electrodes or gradiometers specified. > > Error in ft_channelrepair (line 112) > sens = ft_fetch_sens(cfg, data); > > I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not > really sure what elec/sens file I should be reading or how to go about > creating it. I was hoping that the template, my data, and/or the > layout would contain the necessary information, but given the error on > ft_fetch_sens, that doesn't seem to be the case. > > Any help on this issue would be greatly appreciated. > > Thanks, > > Max > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Mon Nov 18 15:33:12 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Mon, 18 Nov 2013 15:33:12 +0100 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline Message-ID: <528A2528.5020302@gmail.com> Hi everyone, In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? I'm looking forward to hearing any thoughts you may want to share! Cheers, Vitória From mcgoiv0 at wfu.edu Mon Nov 18 15:51:07 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Mon, 18 Nov 2013 09:51:07 -0500 Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hello everybody, I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the ft_timelockanalysis(cfg, data) function? I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. Another way to ask this question is: what is the format/structure of the second input (timelock) in the ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? Thanks, Inna -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.stolk8 at gmail.com Mon Nov 18 16:42:43 2013 From: a.stolk8 at gmail.com (Arjen Stolk) Date: Mon, 18 Nov 2013 16:42:43 +0100 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hi Inna, Ft_regressconfound will remove trial by trial variability of signal amplitude or frequency power that can be explained by variability in head position over those trials. The input, whether sensor or source level, should contain a trial field (keep trials in the previous step - eg at timelockanalysis). Also variance due to head position can only be reliably estimated when the neural signal is consistent over trials (as with an event related modulation or potential). I would not know how to segment a resting state into trials (for further analysis, given that those analyses typically involve connectivity measures over the resting period) but if you an idea on how to do this, you could give ft_regressconfound a try. Note that the output will also be in the trials format. Hope this has made its use a bit more clear. Yours, arjen Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het volgende: > > Hello everybody, > > I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. > It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the > > ft_timelockanalysis(cfg, data) function? > > I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. > > > Another way to ask this question is: > what is the format/structure of the second input (timelock) in the > ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? > > > Thanks, > > Inna > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From arno at cerco.ups-tlse.fr Mon Nov 18 17:27:40 2013 From: arno at cerco.ups-tlse.fr (Arnaud Delorme) Date: Mon, 18 Nov 2013 08:27:40 -0800 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline In-Reply-To: <528A2528.5020302@gmail.com> References: <528A2528.5020302@gmail.com> Message-ID: Dear Vitoria, there is no need to "export" data from Fieldtrip to EEGLAB to plot ERPimage figures. Simply call the "erpimage" function of EEGLAB and fill in the parameter using your fieldtrip data. The only thing you might have to do it is transform your data from a cell array to a regular 2-D array containing sample points in one dimension and trials in the other. Anything that is being shown on the EEGLAB ERPimage figure can be reproduced using this function on the command line. To sort single trials by alpha power or alpha phase (for example), you do not need a baseline period. You can compare ERPimage accross subjects and perform statistics on them using the STUDY structure of EEGLAB. Best, Arno -- Arnaud Delorme, PhD Centre de Recherche Cerveau et Cognition - UMR 5549 Pavillon Baudot, Hopital Purpan, BP 25202 31052 Toulouse Cedex, France On Nov 18, 2013, at 6:33 AM, Vitoria Piai wrote: > Hi everyone, > > In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: > http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif > Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? > I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) > I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. > > The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. > The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? > > I'm looking forward to hearing any thoughts you may want to share! > Cheers, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From arno at cerco.ups-tlse.fr Mon Nov 18 17:27:40 2013 From: arno at cerco.ups-tlse.fr (Arnaud Delorme) Date: Mon, 18 Nov 2013 08:27:40 -0800 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline In-Reply-To: <528A2528.5020302@gmail.com> References: <528A2528.5020302@gmail.com> Message-ID: Dear Vitoria, there is no need to "export" data from Fieldtrip to EEGLAB to plot ERPimage figures. Simply call the "erpimage" function of EEGLAB and fill in the parameter using your fieldtrip data. The only thing you might have to do it is transform your data from a cell array to a regular 2-D array containing sample points in one dimension and trials in the other. Anything that is being shown on the EEGLAB ERPimage figure can be reproduced using this function on the command line. To sort single trials by alpha power or alpha phase (for example), you do not need a baseline period. You can compare ERPimage accross subjects and perform statistics on them using the STUDY structure of EEGLAB. Best, Arno -- Arnaud Delorme, PhD Centre de Recherche Cerveau et Cognition - UMR 5549 Pavillon Baudot, Hopital Purpan, BP 25202 31052 Toulouse Cedex, France On Nov 18, 2013, at 6:33 AM, Vitoria Piai wrote: > Hi everyone, > > In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: > http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif > Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? > I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) > I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. > > The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. > The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? > > I'm looking forward to hearing any thoughts you may want to share! > Cheers, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From ww.peng0923 at gmail.com Tue Nov 19 13:50:18 2013 From: ww.peng0923 at gmail.com (PWW) Date: Tue, 19 Nov 2013 13:50:18 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source Message-ID: Dear Fieldtrippers, In the beamformer tutorial ( http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of (post-pre)/pre was calculated to circumvent the noise bias towards the center of the head. However, I wonder whether it is possible to only localize the pre-stimulus oscillation source, such as pre-stimulus alpha power for example, just like localizing the sources of spontaneous oscillatory activity. Actually, I tried to do it, and use neural activity index to remove the center of the head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't work so well. Does anyone have any suggestions about localizing the cortical sources of spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it any difference with the procedures described in the tutorial? Any pointers would be much appreciated. Thanks. Regards, Weiwei -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Tue Nov 19 14:05:37 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Tue, 19 Nov 2013 14:05:37 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source In-Reply-To: References: Message-ID: Dear Weiwei, After using cfg.dics.projectnoise = 'yes', did you also compute the "Neural Activity Index" by computing source.avg.pow = source.avg.pow ./ source.avg.noise? If not, the noise estimate remains unused. Best, Eelke On 19 November 2013 13:50, PWW wrote: > Dear Fieldtrippers, > > In the beamformer tutorial > (http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of > (post-pre)/pre was calculated to circumvent the noise bias towards the > center of the head. > > However, I wonder whether it is possible to only localize the pre-stimulus > oscillation source, such as pre-stimulus alpha power for example, just like > localizing the sources of spontaneous oscillatory activity. Actually, I > tried to do it, and use neural activity index to remove the center of the > head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't > work so well. > > Does anyone have any suggestions about localizing the cortical sources of > spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it > any difference with the procedures described in the tutorial? > > Any pointers would be much appreciated. > > Thanks. > > Regards, > > Weiwei > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jm.horschig at donders.ru.nl Tue Nov 19 14:12:09 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Tue, 19 Nov 2013 14:12:09 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source In-Reply-To: References: Message-ID: <528B63A9.4050104@donders.ru.nl> Dear Weiwei, as an alternative to computing the NAI (as Eelke pointed to), you can normalize the leadfield by settings cfg.normalize = 'yes' prior to calling ft_compute_leadfield. I've heard from high places that this works pretty well, but haven't compared both methods myself. Best, Jörn Eelke Spaak wrote: > Dear Weiwei, > > After using cfg.dics.projectnoise = 'yes', did you also compute the > "Neural Activity Index" by computing source.avg.pow = source.avg.pow > ./ source.avg.noise? If not, the noise estimate remains unused. > > Best, > Eelke > > On 19 November 2013 13:50, PWW wrote: > >> Dear Fieldtrippers, >> >> In the beamformer tutorial >> (http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of >> (post-pre)/pre was calculated to circumvent the noise bias towards the >> center of the head. >> >> However, I wonder whether it is possible to only localize the pre-stimulus >> oscillation source, such as pre-stimulus alpha power for example, just like >> localizing the sources of spontaneous oscillatory activity. Actually, I >> tried to do it, and use neural activity index to remove the center of the >> head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't >> work so well. >> >> Does anyone have any suggestions about localizing the cortical sources of >> spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it >> any difference with the procedures described in the tutorial? >> >> Any pointers would be much appreciated. >> >> Thanks. >> >> Regards, >> >> Weiwei >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From jean-baptiste.versini at etu.univ-lyon1.fr Tue Nov 19 14:36:10 2013 From: jean-baptiste.versini at etu.univ-lyon1.fr (VERSINI JEAN-BAPTISTE p1207642) Date: Tue, 19 Nov 2013 13:36:10 +0000 Subject: [FieldTrip] Is it safe to overlap trials ? In-Reply-To: <5271B6068CD8D94DB8225422823792880179014E@mbx2010-02.univ-lyon1.fr> References: <5271B6068CD8D94DB8225422823792880179014E@mbx2010-02.univ-lyon1.fr> Message-ID: <5271B6068CD8D94DB82254228237928801790161@mbx2010-02.univ-lyon1.fr> Dear all, I analyze EEG data and I would like to define trials in a way that they may overlap. I know it causes some problems with the databrowser because for a given time, the sample may have different values. Apart from that, are there other things I should worry about or is it totally okay for me to overlap my trials ? If it causes some troubles I will adjust sampleinfo to fake contiguous trials but I'd like to avoid that. Regards, JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Nov 19 18:29:03 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 19 Nov 2013 18:29:03 +0100 Subject: [FieldTrip] failed segmentation In-Reply-To: <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> References: <528781D8.1030107@gmail.com> <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> Message-ID: <528B9FDF.1010404@gmail.com> Hi Lilla and Christiano, Thanks a lot for the suggestions. I think I've managed to fix it by applying Lilla's suggestion, i.e., instead of using the tpm default, I specified the output for 'brain','skull','scalp'. Cheers, Vitória On 11/17/2013 12:03 PM, Lilla.Magyari at mpi.nl wrote: > hi Vitoria, > > is this a tpm (the default output of ft_volumesegment)? Have you also > tried to segment this mri with an output for 'brain','skull','scalp'? > because when you have a binary representation for these tissue-types, they > do not overlap, and are closed. So, I am wondering if you end up with a > brainmask which do not contain the artifact at the top of the head. > > > Lilla > > >> Hi Vitoria, >> it looks like there is an artifact on the top of the head. It happened to >> me already and I had to preprocess the mri volume by using an appropriate >> cutoff and by thresholding (after plotting the histogram of the grey >> levels). >> >> mri.anatomy = (mri.anatomy>thr).*mri.anatomy; >> >> or >> >> mri.anatomy(:,:,230:256) = 0; >> >> If thresholding is still not effective you might consider applying >> morphological operators (erode, dilate, open, close), after taking care >> that you voxel dimensions are cubic (diagonal values of the canonic form >> of >> mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. >> >> I hope this helps, >> Cristiano >> >> >> >> On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai >> wrote: >> >>> Hi all, >>> >>> has anyone ever had a failed segmentation that looks like the one in the >>> figure? >>> My script works for all participants, I mean, for all other participants >>> the brain is only inside the skull :) >>> But it fails terribly for this one. I thought it could have to do with >>> the >>> placement of the fiducials, and I've played around a bit with that but >>> it >>> didn't solve the problem. >>> If anyone recognises this type of error, I'd be help to hear if/how it >>> can >>> be fixed. >>> >>> Thanks a lot, Vitória >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From mcgoiv0 at wfu.edu Tue Nov 19 20:01:17 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Tue, 19 Nov 2013 14:01:17 -0500 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Thank you Arjen for clarifications, Bcs the output is in the trial format anyway, technically, I can proceed with the head motion regression method on the resting state by dividing the data into smaller segments; which I did. I have 120 sec of MEG data (SR=600 Hz) that I divided into 10, or 20, or 30 sec trials and run the ft_regressconfound. Every time I run into the out of memory problem. Matlab error message: ??? Error using==>mldivide Out of memory. Error in ==> ft_regressconfound at 213 beta = regr\dat; % B= X\Y The error appears in the part of the code where the linear equation is solved directly. I tried to only work with a subset of all trials (half for example) with no luck. I rum MatlabR2010a on Windows XP 32-bit with the following memory allocation in Matlab: Max possible array: 851 Mb Memory available for all array: 1703 Mb Memory used by Matlab: 850 Mb RAM: 3317 Mb Were anybody else able to run this motion regression algorithm in Matlab without out of memory? Is there anything I can do to avoid the problem? I can share the code if needed. Thanks in advance, Inna Inna McGowin On Mon, Nov 18, 2013 at 10:42 AM, Arjen Stolk wrote: > Hi Inna, > Ft_regressconfound will remove trial by trial variability of signal > amplitude or frequency power that can be explained by variability in head > position over those trials. The input, whether sensor or source level, > should contain a trial field (keep trials in the previous step - eg at > timelockanalysis). Also variance due to head position can only be reliably > estimated when the neural signal is consistent over trials (as with an > event related modulation or potential). I would not know how to segment a > resting state into trials (for further analysis, given that those analyses > typically involve connectivity measures over the resting period) but if you > an idea on how to do this, you could give ft_regressconfound a try. Note > that the output will also be in the trials format. Hope this has made its > use a bit more clear. Yours, arjen > > Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het > volgende: > > > > > Hello everybody, > > > > I would like to use the ft_regressconfound function to remove/reduce > the head motion in a continuous MEG data. > > It's a resting state data and no averaging can be applied. Is there a > way to apply the correction without using the > > > > ft_timelockanalysis(cfg, data) function? > > > > I understand that the ft_regressconfound function has limits and caveats > but I still would like to see the results of its correction. > > > > > > Another way to ask this question is: > > what is the format/structure of the second input (timelock) in the > > ft_regressconfound(cfg, timelock) function and how it can be created > without ft_timelockanalysis? > > > > > > Thanks, > > > > Inna > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Wed Nov 20 20:08:53 2013 From: mcantor at umich.edu (Max Cantor) Date: Wed, 20 Nov 2013 14:08:53 -0500 Subject: [FieldTrip] ft_channelrepair not finding electrodes In-Reply-To: <5289E8C4.9060605@donders.ru.nl> References: <5289E8C4.9060605@donders.ru.nl> Message-ID: Hi Jorn, Sorry for the late response. I had to create a template for our cap, which had it's own issues, but I think at this point I have it working. Even if there are still some trigonometric issues, at the very least I have the fieldtrip issue resolved. For future reference, because I don't remember seeing anything on the fieldtrip FAQ about this and it may be useful to somebody else, the important thing is to turn the phi/theta from degrees into radians, and then applying a trigonometric function to get the X, Y, and Z coordinates. You can do all of these steps in 3 excel functions: X = COS(RADIANS(Phi))*SIN(RADIANS(Theta)) Y = SIN(RADIANS(Theta))*SIN(RADIANS(Phi)) Z = =COS(RADIANS(Theta)) This link on the easycap website ( http://www.easycap.de/easycap/e/downloads/how_to_read_3d.htm) explains the coordinate system. I then typed up the channel name, x, y, and z coordinates in a four column notepad document saved as a .sfp file, and used that as my cfg.elecfile. Thank you for the support, Max On Mon, Nov 18, 2013 at 5:15 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl> wrote: > Hi Max, > > check out Fieldtrip/template/electrode and see if you can use one of the > templates in there. Best would be to use electrode measurements that you > actually performed yourself (to get the distances between electrodes > right), but using a template might be good as well. Once you found a good > template-file, you can set cfg.elecfile = 'folder/filename' and FieldTrip > will handle the rest. > Otherwise, if some of your colleagues have electrode measurements, you can > also ask them for advice. > > Best, > Jörn > > > On 11/15/2013 5:40 PM, Max Cantor wrote: > > Hi all, > > I'm trying to perform channel repair on EEG data that has undergone > jump, muscle, and visual artifact rejection, and ICA to remove eog and ecg > components, unmixed back into the original channels. It's a 61 channel > system using a modified easycap layout and neighbours template. > > The layout has been shown to work on topographic displays, and the > template seems to work in that it creates a neighbours object when > ft_prepare_neighbours is run on it without any errors. > > However, I'm getting an error when I attempt to run ft_channelrepair: > > Error using ft_fetch_sens (line 179) > no electrodes or gradiometers specified. > > Error in ft_channelrepair (line 112) > sens = ft_fetch_sens(cfg, data); > > I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not > really sure what elec/sens file I should be reading or how to go about > creating it. I was hoping that the template, my data, and/or the layout > would contain the necessary information, but given the error on > ft_fetch_sens, that doesn't seem to be the case. > > Any help on this issue would be greatly appreciated. > > Thanks, > > Max > > > _______________________________________________ > fieldtrip mailing listfieldtrip at donders.ru.nlhttp://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From polomacnenad at gmail.com Thu Nov 21 12:29:32 2013 From: polomacnenad at gmail.com (Nenad Polomac) Date: Thu, 21 Nov 2013 12:29:32 +0100 Subject: [FieldTrip] ft_databrowser doesnt plot channel names Message-ID: Hi, I just realized that ft_databrowser in FT version 20131120 for some reason doesn't plot labels of the channels on y axis. Earlier version works fine. I have also read http://bugzilla.fcdonders.nl/show_bug.cgi?id=2065 cfg=[]; cfg.viewmode ='vertical'; cfg.plotlabels = 'yes'; cfg.eegscale=.5; cfg.trl = 'all'; cfg.continuous = 'no'; cfg.channel ='EEG'; ft_databrowser(cfg, data); My guess is something is wrong with the line 1696 of the ft_databrowser ft_plot_text(labelx(laysel), labely(laysel), opt.hdr.label(chanindx(i)), 'tag', 'chanlabel', 'HorizontalAlignment', 'right','interpreter','none','FontUnits','normalized','FontSize',8); It is not that I urgently need this, I just wanted to contribute a little. :) all the best! Nenad -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.brovelli at univ-amu.fr Thu Nov 21 15:41:25 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Thu, 21 Nov 2013 15:41:25 +0100 (CET) Subject: [FieldTrip] Conjunction analysis Message-ID: <1795812587.19187.1385044885611.JavaMail.root@bureau-frontal1> Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea From a.stolk8 at gmail.com Thu Nov 21 16:35:37 2013 From: a.stolk8 at gmail.com (A.stolk) Date: Thu, 21 Nov 2013 08:35:37 -0700 Subject: [FieldTrip] Conjunction analysis Message-ID: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjenandrea brovelli schreef:Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.brovelli at univ-amu.fr Thu Nov 21 16:58:54 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Thu, 21 Nov 2013 16:58:54 +0100 (CET) Subject: [FieldTrip] Conjunction analysis In-Reply-To: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> References: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> Message-ID: <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> Thanks a lot for your reply, Arjen. It's clearer now. In fact, I am using a parametric tests, so I think I would need to use the Nichols 2005 method for the conjunction analysis. Does anyone have the code to do this or does anyone know how to recover it within SPM ? Thanks a lot Andrea "A.stolk" wrote:Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjen andrea brovelli schreef: Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Thu Nov 21 17:36:38 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 21 Nov 2013 17:36:38 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? Message-ID: Fellow FieldTrippers, Currently I am looking at a contrast for left- versus right-hand index finger button presses. As expected, on sensor level (combined planar gradient, grand average) I see a clear lateralisation in beta band power starting at least 0.5s before the button press (see https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is clearly more beta power ipsilateral to the response hand. I would prefer to do further analyses on source level, so I attempt to reconstruct the sources for this effect using DICS beamformer (common filter, applied to both conditions separately; fixedori and realfilter = 'yes'). The grand average results for this (again contrast left vs right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the R/L-flip, this is radiological convention.) As you can see, the source level solution is much more blurry than on sensor level. This picture is without using any regularisation (lambda parameter), the results are even worse when I use lambda = '5%'. The negative blob (right hand higher power than left) becomes 'marginally significant' on source level (p ~ 0.06) where it was p < 0.001 on sensor level. The positive blob is nowhere near significant. Also, the individual results are much less topographically consistent on source than on sensor level (explaining the worse statistics). I have checked the segmentation of my MRIs, the 'gray' seems to be nicely within the head all the time. Also, I have manually verified the alignment of headmodel, sourcemodel, and gradiometer information for all subjects. As a final note, the above sensor-level plot was taken from a 'slice' out of a planar-gradient time-frequency analysis (mtmconvol). The ingredient for the beamformer was an mtmfft fourier spectrum on the axial gradiometer data, obtained for just the time-frequency range of interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). When I compute condition-averaged power based on these fourier spectra and look at the contrast, the results are again as expected: https://db.tt/n2P3UKcQ (of course less localised because of axial gradient vs planar). The freq structures underlying this contrast are exactly the same as those going into ft_sourceanalysis, so the problem must be in the source analysis step (and/or in the preparation of the geometric information, although these seem fine by visual inspection). Does anyone have any idea that might explain these seemingly contradictory results? I would have expected demixing to improve signal-to-noise ratio, rather than worsen it. Thanks! Best, Eelke From v.piai.research at gmail.com Thu Nov 21 17:51:00 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Thu, 21 Nov 2013 17:51:00 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: <528E39F4.9070105@gmail.com> Hi all, Eelke, Maybe adding to Eelke's remark, although I'm not working with motor beta activity and lateralised index. I'm also using DICS and my very clear, focal sensor-level effects all of a sudden become localised to the whole brain or a whole hemisphere! I happen to have heard from Jan-Mathijs that there may something going on at the moment, but at least for now, Eelke, I don't think this error is unique to our data (and I was actually going to post my incompatible sensor-source results here soon, so now it's less work for me :) Looking forward to hearing your updates, (I'm interrupting my source-level analyses for the time to get a better feeling for the sensor-level data first) Vitória On 21-11-2013 17:36, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Vitória Piai PhD Candidate Donders Institute for Brain, Cognition and Behaviour Centre for Cognition, Radboud University Nijmegen Montessorilaan 3, B.01.05 6525 HR Nijmegen The Netherlands Email : V.piai at donders.ru.nl Phone : +31 24 3612635 www.vitoriapiai.com From eelke.spaak at donders.ru.nl Thu Nov 21 18:27:43 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 21 Nov 2013 18:27:43 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <528E39F4.9070105@gmail.com> References: <528E39F4.9070105@gmail.com> Message-ID: Thanks for the input Vitória. Are you using Fourier input to sourceanalysis, or 'powandcsd'? I'm wondering whether the csd computation inside sourceanalysis might be to blame. Will investigate this tomorrow :) Eelke On Nov 21, 2013 6:01 PM, "Vitoria Piai" wrote: > Hi all, Eelke, > > Maybe adding to Eelke's remark, although I'm not working with motor beta > activity and lateralised index. > I'm also using DICS and my very clear, focal sensor-level effects all of a > sudden become localised to the whole brain or a whole hemisphere! > I happen to have heard from Jan-Mathijs that there may something going on > at the moment, but at least for now, Eelke, I don't think this error is > unique to our data (and I was actually going to post my incompatible > sensor-source results here soon, so now it's less work for me :) > > Looking forward to hearing your updates, > (I'm interrupting my source-level analyses for the time to get a better > feeling for the sensor-level data first) > Vitória > > On 21-11-2013 17:36, Eelke Spaak wrote: > >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus right-hand index >> finger button presses. As expected, on sensor level (combined planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer (common >> filter, applied to both conditions separately; fixedori and realfilter >> = 'yes'). The grand average results for this (again contrast left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry than on >> sensor level. This picture is without using any regularisation (lambda >> parameter), the results are even worse when I use lambda = '5%'. The >> negative blob (right hand higher power than left) becomes 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. Also, the >> individual results are much less topographically consistent on source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually verified >> the alignment of headmodel, sourcemodel, and gradiometer information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum on the >> axial gradiometer data, obtained for just the time-frequency range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this contrast are >> exactly the same as those going into ft_sourceanalysis, so the problem >> must be in the source analysis step (and/or in the preparation of the >> geometric information, although these seem fine by visual inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Vitória Piai > PhD Candidate > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognition, Radboud University Nijmegen > Montessorilaan 3, B.01.05 > 6525 HR Nijmegen > The Netherlands > > Email : V.piai at donders.ru.nl > Phone : +31 24 3612635 > www.vitoriapiai.com > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Thu Nov 21 19:39:30 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Thu, 21 Nov 2013 13:39:30 -0500 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Dear Eelke, very interesting topic. Please find my two cents below: On Thu, Nov 21, 2013 at 11:36 AM, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > There might be issues with: - head positions/distance of single subjects in the dewar - something happening in the transition axial -> planar gradiometers conversion - orientation of the brain motor sources - inverse problem reconstruction - magnitude of the power effects for the different subjects - forward model issues Let me comment briefly on point 4. If the sources in the motor cortex are bilateral (as expected to different extents from ipsi to contra) and are temporally correlated, this constitutes an issue for the beamformer algorithm (van Veen et al.1993) especially if the sources are near (and lead fields highly correlated). There are workarounds to localize the single contributions of primary/secondary motor sources, but this implies the use of regional suppression (a nulling beamformer) and it is a tedious procedure to apply. Might be worth to look into that though. Let me know if you have interest in this. > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > On this point: using regularization is useful to invert the real(csd) matrix if it is ill-conditioned, but might blur the source reconstruction. On the other hand not using it might also be detrimental on the source reconstruction. Therefore applying it depends on the condition number of your csd. Is the matrix full rank? If not you might consider regularizing. Did you previously use ICA/PCA to get rid of artifacts? If yes that will have a negative effect on the condition number. and you might consider cranking down the ICA components rejection to the big spiky components -if any- and let the beamformer filter reject the smaller ones (in magnitude). Are you using cluster statistics based on the maxval? Maybe another statistics might give different results, given that the maxval might be due to artifacts (muscular, heart, ...) > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > Do all subjects sit with the top of the head at the same distance from the dewar? This is easily visualized by plotting the headmodel together with the head coordinates' sensors. By experience with CTF systems not all subjects' heads are at the same distance from the top (because they slip down, or they reposition 'cause they can't see out of the dewar, they also move!). This might hinder the SNR of the raw data to start with. It seems the grand average is still significant, but might be due to the contribution of a few good subjects. You may also want to consider the movement correction GLM method at the source level. Maybe it gives you back some SNR. > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > Yes, but it can also depend on different extents from FFT-level analysis. Have you played around with spectral smoothing, by for example lowering the number of tapers, or changing to a single condition contrast like activation vs baseline in the beamformer? What is the grand average vs single subject lateralization effect/single condition effect/ planar or axial effect? Is it there for all single subjects? I hope the comments helped a bit. All the best! Cristiano > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stan.vanpelt at fcdonders.ru.nl Thu Nov 21 21:45:49 2013 From: stan.vanpelt at fcdonders.ru.nl (Stan van Pelt) Date: Thu, 21 Nov 2013 21:45:49 +0100 (CET) Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: Message-ID: <513733919.261511.1385066749005.JavaMail.root@indus.zimbra.ru.nl> Hi Eelke, Have you tried comparing the results with a time-domain beamformer? You could e.g. try LCMV on 15-25Hz-bandpassed data. This should give you in theory similar results. Best, Stan ----- Oorspronkelijk bericht ----- > Van: "Eelke Spaak" > Aan: "FieldTrip discussion list" > Verzonden: Donderdag 21 november 2013 18:27:43 > Onderwerp: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Thanks for the input Vitória. Are you using Fourier input to > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd > computation inside sourceanalysis might be to blame. Will investigate > this tomorrow :) > Eelke > On Nov 21, 2013 6:01 PM, "Vitoria Piai" < v.piai.research at gmail.com > > wrote: > > Hi all, Eelke, > > Maybe adding to Eelke's remark, although I'm not working with motor > > beta activity and lateralised index. > > I'm also using DICS and my very clear, focal sensor-level effects > > all > > of a sudden become localised to the whole brain or a whole > > hemisphere! > > I happen to have heard from Jan-Mathijs that there may something > > going > > on at the moment, but at least for now, Eelke, I don't think this > > error is unique to our data (and I was actually going to post my > > incompatible sensor-source results here soon, so now it's less work > > for me :) > > Looking forward to hearing your updates, > > (I'm interrupting my source-level analyses for the time to get a > > better feeling for the sensor-level data first) > > Vitória > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > Fellow FieldTrippers, > > > Currently I am looking at a contrast for left- versus right-hand > > > index > > > finger button presses. As expected, on sensor level (combined > > > planar > > > gradient, grand average) I see a clear lateralisation in beta band > > > power starting at least 0.5s before the button press (see > > > https://db.tt/Rtch3Qjy ). Both 'blobs' are significant; there is > > > clearly more beta power ipsilateral to the response hand. I would > > > prefer to do further analyses on source level, so I attempt to > > > reconstruct the sources for this effect using DICS beamformer > > > (common > > > filter, applied to both conditions separately; fixedori and > > > realfilter > > > = 'yes'). The grand average results for this (again contrast left > > > vs > > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore > > > the > > > R/L-flip, this is radiological convention.) > > > As you can see, the source level solution is much more blurry than > > > on > > > sensor level. This picture is without using any regularisation > > > (lambda > > > parameter), the results are even worse when I use lambda = '5%'. > > > The > > > negative blob (right hand higher power than left) becomes > > > 'marginally > > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > > sensor level. The positive blob is nowhere near significant. Also, > > > the > > > individual results are much less topographically consistent on > > > source > > > than on sensor level (explaining the worse statistics). > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > > nicely within the head all the time. Also, I have manually > > > verified > > > the alignment of headmodel, sourcemodel, and gradiometer > > > information > > > for all subjects. > > > As a final note, the above sensor-level plot was taken from a > > > 'slice' > > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > > ingredient for the beamformer was an mtmfft fourier spectrum on > > > the > > > axial gradiometer data, obtained for just the time-frequency range > > > of > > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = > > > 7). > > > When I compute condition-averaged power based on these fourier > > > spectra > > > and look at the contrast, the results are again as expected: > > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > > gradient vs planar). The freq structures underlying this contrast > > > are > > > exactly the same as those going into ft_sourceanalysis, so the > > > problem > > > must be in the source analysis step (and/or in the preparation of > > > the > > > geometric information, although these seem fine by visual > > > inspection). > > > Does anyone have any idea that might explain these seemingly > > > contradictory results? I would have expected demixing to improve > > > signal-to-noise ratio, rather than worsen it. > > > Thanks! > > > Best, > > > Eelke > > > ______________________________ _________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > -- > > Vitória Piai > > PhD Candidate > > Donders Institute for Brain, Cognition and Behaviour > > Centre for Cognition, Radboud University Nijmegen > > Montessorilaan 3, B.01.05 > > 6525 HR Nijmegen > > The Netherlands > > Email : V.piai at donders.ru.nl > > Phone : +31 24 3612635 > > www.vitoriapiai.com > > ______________________________ _________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour Centre for Cognition Montessorilaan 3, B.01.19 6525 HR Nijmegen tel: 024-3616288 -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiteng.jiang at gmail.com Thu Nov 21 22:49:50 2013 From: haiteng.jiang at gmail.com (Haiteng Jiang) Date: Thu, 21 Nov 2013 22:49:50 +0100 Subject: [FieldTrip] =?utf-8?q?Motor_beta_activity_-_DICS_solution_more_no?= =?utf-8?q?isy_than_=E3=80=80sensor_data=3F?= Message-ID: On 21 November 2013 21:46, wrote: > Send fieldtrip mailing list submissions to > fieldtrip at science.ru.nl > > To subscribe or unsubscribe via the World Wide Web, visit > http://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. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Eelke Spaak) > 2. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Cristiano Micheli) > 3. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Stan van Pelt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Nov 2013 18:27:43 +0100 > From: Eelke Spaak > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > zBvahNkAp9rO9LTRimRWR09GbeC3vfEv1sXHg at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thanks for the input Vit?ria. Are you using Fourier input to > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd computation > inside sourceanalysis might be to blame. Will investigate this tomorrow :) > > Eelke > On Nov 21, 2013 6:01 PM, "Vitoria Piai" wrote: > > > Hi all, Eelke, > > > > Maybe adding to Eelke's remark, although I'm not working with motor beta > > activity and lateralised index. > > I'm also using DICS and my very clear, focal sensor-level effects all of > a > > sudden become localised to the whole brain or a whole hemisphere! > > I happen to have heard from Jan-Mathijs that there may something going on > > at the moment, but at least for now, Eelke, I don't think this error is > > unique to our data (and I was actually going to post my incompatible > > sensor-source results here soon, so now it's less work for me :) > > > > Looking forward to hearing your updates, > > (I'm interrupting my source-level analyses for the time to get a better > > feeling for the sensor-level data first) > > Vit?ria > > > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > >> Fellow FieldTrippers, > >> > >> Currently I am looking at a contrast for left- versus right-hand index > >> finger button presses. As expected, on sensor level (combined planar > >> gradient, grand average) I see a clear lateralisation in beta band > >> power starting at least 0.5s before the button press (see > >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > >> clearly more beta power ipsilateral to the response hand. I would > >> prefer to do further analyses on source level, so I attempt to > >> reconstruct the sources for this effect using DICS beamformer (common > >> filter, applied to both conditions separately; fixedori and realfilter > >> = 'yes'). The grand average results for this (again contrast left vs > >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > >> R/L-flip, this is radiological convention.) > >> > >> As you can see, the source level solution is much more blurry than on > >> sensor level. This picture is without using any regularisation (lambda > >> parameter), the results are even worse when I use lambda = '5%'. The > >> negative blob (right hand higher power than left) becomes 'marginally > >> significant' on source level (p ~ 0.06) where it was p < 0.001 on > >> sensor level. The positive blob is nowhere near significant. Also, the > >> individual results are much less topographically consistent on source > >> than on sensor level (explaining the worse statistics). > >> > >> I have checked the segmentation of my MRIs, the 'gray' seems to be > >> nicely within the head all the time. Also, I have manually verified > >> the alignment of headmodel, sourcemodel, and gradiometer information > >> for all subjects. > >> > >> As a final note, the above sensor-level plot was taken from a 'slice' > >> out of a planar-gradient time-frequency analysis (mtmconvol). The > >> ingredient for the beamformer was an mtmfft fourier spectrum on the > >> axial gradiometer data, obtained for just the time-frequency range of > >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > >> When I compute condition-averaged power based on these fourier spectra > >> and look at the contrast, the results are again as expected: > >> https://db.tt/n2P3UKcQ (of course less localised because of axial > >> gradient vs planar). The freq structures underlying this contrast are > >> exactly the same as those going into ft_sourceanalysis, so the problem > >> must be in the source analysis step (and/or in the preparation of the > >> geometric information, although these seem fine by visual inspection). > >> > >> Does anyone have any idea that might explain these seemingly > >> contradictory results? I would have expected demixing to improve > >> signal-to-noise ratio, rather than worsen it. > >> > >> Thanks! > >> Best, > >> Eelke > >> _______________________________________________ > >> fieldtrip mailing list > >> fieldtrip at donders.ru.nl > >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > > > > > > -- > > Vit?ria Piai > > PhD Candidate > > Donders Institute for Brain, Cognition and Behaviour > > Centre for Cognition, Radboud University Nijmegen > > Montessorilaan 3, B.01.05 > > 6525 HR Nijmegen > > The Netherlands > > > > Email : V.piai at donders.ru.nl > > Phone : +31 24 3612635 > > www.vitoriapiai.com > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/00fab2a3/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 21 Nov 2013 13:39:30 -0500 > From: Cristiano Micheli > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > < > CADW7XCCf9aAPYFTF9iCuMnRgYHA6hhoPBbex0ihkJNB_b3ah5Q at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Dear Eelke, very interesting topic. Please find my two cents below: > > > On Thu, Nov 21, 2013 at 11:36 AM, Eelke Spaak >wrote: > > > Fellow FieldTrippers, > > > > Currently I am looking at a contrast for left- versus right-hand index > > finger button presses. As expected, on sensor level (combined planar > > gradient, grand average) I see a clear lateralisation in beta band > > power starting at least 0.5s before the button press (see > > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > > clearly more beta power ipsilateral to the response hand. I would > > prefer to do further analyses on source level, so I attempt to > > reconstruct the sources for this effect using DICS beamformer (common > > filter, applied to both conditions separately; fixedori and realfilter > > = 'yes'). The grand average results for this (again contrast left vs > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > > R/L-flip, this is radiological convention.) > > > > > There might be issues with: > - head positions/distance of single subjects in the dewar > - something happening in the transition axial -> planar gradiometers > conversion > - orientation of the brain motor sources > - inverse problem reconstruction > - magnitude of the power effects for the different subjects > - forward model issues > > Let me comment briefly on point 4. If the sources in the motor cortex are > bilateral (as expected to different extents from ipsi to contra) and are > temporally correlated, this constitutes an issue for the beamformer > algorithm (van Veen et al.1993) especially if the sources are near (and > lead fields highly correlated). > There are workarounds to localize the single contributions of > primary/secondary motor sources, but this implies the use of regional > suppression (a nulling beamformer) and it is a tedious procedure to apply. > Might be worth to look into that though. Let me know if you have interest > in this. > > > > > As you can see, the source level solution is much more blurry than on > > sensor level. This picture is without using any regularisation (lambda > > parameter), the results are even worse when I use lambda = '5%'. The > > negative blob (right hand higher power than left) becomes 'marginally > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > sensor level. The positive blob is nowhere near significant. Also, the > > individual results are much less topographically consistent on source > > than on sensor level (explaining the worse statistics). > > > > On this point: using regularization is useful to invert the real(csd) > matrix if it is ill-conditioned, but might blur the source reconstruction. > On the other hand not using it might also be detrimental on the source > reconstruction. Therefore applying it depends on the condition number of > your csd. Is the matrix full rank? If not you might consider regularizing. > Did you previously use ICA/PCA to get rid of artifacts? If yes that will > have a negative effect on the condition number. and you might consider > cranking down the ICA components rejection to the big spiky components -if > any- and let the beamformer filter reject the smaller ones (in magnitude). > Are you using cluster statistics based on the maxval? Maybe another > statistics might give different results, given that the maxval might be due > to artifacts (muscular, heart, ...) > > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > nicely within the head all the time. Also, I have manually verified > > the alignment of headmodel, sourcemodel, and gradiometer information > > for all subjects. > > > > Do all subjects sit with the top of the head at the same distance from the > dewar? This is easily visualized by plotting the headmodel together with > the head coordinates' sensors. > By experience with CTF systems not all subjects' heads are at the same > distance from the top (because they slip down, or they reposition 'cause > they can't see out of the dewar, they also move!). This might hinder the > SNR of the raw data to start with. > It seems the grand average is still significant, but might be due to the > contribution of a few good subjects. > You may also want to consider the movement correction GLM method at the > source level. Maybe it gives you back some SNR. > > > > As a final note, the above sensor-level plot was taken from a 'slice' > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > ingredient for the beamformer was an mtmfft fourier spectrum on the > > axial gradiometer data, obtained for just the time-frequency range of > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > > When I compute condition-averaged power based on these fourier spectra > > and look at the contrast, the results are again as expected: > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > gradient vs planar). The freq structures underlying this contrast are > > exactly the same as those going into ft_sourceanalysis, so the problem > > must be in the source analysis step (and/or in the preparation of the > > geometric information, although these seem fine by visual inspection). > > > > Does anyone have any idea that might explain these seemingly > > contradictory results? I would have expected demixing to improve > > signal-to-noise ratio, rather than worsen it. > > > > Yes, but it can also depend on different extents from FFT-level analysis. > Have you played around with spectral smoothing, by for example lowering the > number of tapers, or changing to a single condition contrast like > activation vs baseline in the beamformer? > What is the grand average vs single subject lateralization effect/single > condition effect/ planar or axial effect? Is it there for all single > subjects? > > I hope the comments helped a bit. > > All the best! > Cristiano > > > > > > Thanks! > > Best, > > Eelke > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/283a4f1b/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Nov 2013 21:45:49 +0100 (CET) > From: Stan van Pelt > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > <513733919.261511.1385066749005.JavaMail.root at indus.zimbra.ru.nl> > Content-Type: text/plain; charset="utf-8" > > Hi Eelke, Have you tried comparing the results with a time-domain > beamformer? You could e.g. try LCMV on 15-25Hz-bandpassed data. This should > give you in theory similar results. Best, Stan ----- Oorspronkelijk bericht > ----- > > Van: "Eelke Spaak" > > Aan: "FieldTrip discussion list" > > Verzonden: Donderdag 21 november 2013 18:27:43 > > Onderwerp: Re: [FieldTrip] Motor beta activity - DICS solution more > > noisy than sensor data? > > Thanks for the input Vit?ria. Are you using Fourier input to > > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd > > computation inside sourceanalysis might be to blame. Will investigate > > this tomorrow :) > > Eelke > > On Nov 21, 2013 6:01 PM, "Vitoria Piai" < v.piai.research at gmail.com > > > wrote: > > > Hi all, Eelke, > > > Maybe adding to Eelke's remark, although I'm not working with motor > > > beta activity and lateralised index. > > > I'm also using DICS and my very clear, focal sensor-level effects > > > all > > > of a sudden become localised to the whole brain or a whole > > > hemisphere! > > > I happen to have heard from Jan-Mathijs that there may something > > > going > > > on at the moment, but at least for now, Eelke, I don't think this > > > error is unique to our data (and I was actually going to post my > > > incompatible sensor-source results here soon, so now it's less work > > > for me :) > > > Looking forward to hearing your updates, > > > (I'm interrupting my source-level analyses for the time to get a > > > better feeling for the sensor-level data first) > > > Vit?ria > > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > > Fellow FieldTrippers, > > > > Currently I am looking at a contrast for left- versus right-hand > > > > index > > > > finger button presses. As expected, on sensor level (combined > > > > planar > > > > gradient, grand average) I see a clear lateralisation in beta band > > > > power starting at least 0.5s before the button press (see > > > > https://db.tt/Rtch3Qjy ). Both 'blobs' are significant; there is > > > > clearly more beta power ipsilateral to the response hand. I would > > > > prefer to do further analyses on source level, so I attempt to > > > > reconstruct the sources for this effect using DICS beamformer > > > > (common > > > > filter, applied to both conditions separately; fixedori and > > > > realfilter > > > > = 'yes'). The grand average results for this (again contrast left > > > > vs > > > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore > > > > the > > > > R/L-flip, this is radiological convention.) > > > > As you can see, the source level solution is much more blurry than > > > > on > > > > sensor level. This picture is without using any regularisation > > > > (lambda > > > > parameter), the results are even worse when I use lambda = '5%'. > > > > The > > > > negative blob (right hand higher power than left) becomes > > > > 'marginally > > > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > > > sensor level. The positive blob is nowhere near significant. Also, > > > > the > > > > individual results are much less topographically consistent on > > > > source > > > > than on sensor level (explaining the worse statistics). > > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > > > nicely within the head all the time. Also, I have manually > > > > verified > > > > the alignment of headmodel, sourcemodel, and gradiometer > > > > information > > > > for all subjects. > > > > As a final note, the above sensor-level plot was taken from a > > > > 'slice' > > > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > > > ingredient for the beamformer was an mtmfft fourier spectrum on > > > > the > > > > axial gradiometer data, obtained for just the time-frequency range > > > > of > > > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = > > > > 7). > > > > When I compute condition-averaged power based on these fourier > > > > spectra > > > > and look at the contrast, the results are again as expected: > > > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > > > gradient vs planar). The freq structures underlying this contrast > > > > are > > > > exactly the same as those going into ft_sourceanalysis, so the > > > > problem > > > > must be in the source analysis step (and/or in the preparation of > > > > the > > > > geometric information, although these seem fine by visual > > > > inspection). > > > > Does anyone have any idea that might explain these seemingly > > > > contradictory results? I would have expected demixing to improve > > > > signal-to-noise ratio, rather than worsen it. > > > > Thanks! > > > > Best, > > > > Eelke > > > > ______________________________ _________________ > > > > fieldtrip mailing list > > > > fieldtrip at donders.ru.nl > > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > > -- > > > Vit?ria Piai > > > PhD Candidate > > > Donders Institute for Brain, Cognition and Behaviour > > > Centre for Cognition, Radboud University Nijmegen > > > Montessorilaan 3, B.01.05 > > > 6525 HR Nijmegen > > > The Netherlands > > > Email : V.piai at donders.ru.nl > > > Phone : +31 24 3612635 > > > www.vitoriapiai.com > > > ______________________________ _________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour > Centre for Cognition Montessorilaan 3, B.01.19 6525 HR Nijmegen tel: > 024-3616288 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/60bb5dee/attachment.html > > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 36, Issue 34 > ***************************************** > -- Haiteng Jiang PhD candidate Neuronal Oscillations Group Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Visiting address Room 2.32 Donders Centre for Cognitive Neuroimaging Kapittelweg 29 6525 EN Nijmegen the Netherlands Tel.: +31 (0)243668291 Web: https://sites.google.com/site/haitengjiang/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From haristz at gmail.com Fri Nov 22 01:09:36 2013 From: haristz at gmail.com (Charidimos Tzagarakis) Date: Thu, 21 Nov 2013 18:09:36 -0600 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Hi Eelke, Provided there is no major recent revision of the DICS code, I would have expected motor desynchronisation to show up pretty well. Are the maps shown at source and channel level straight differences of L and Right hand conditions at the beta band (I hope I am correctly interpreting your paradigm) ? If so it might be helpful in pinpointing the problem/as a sanity check to see what happens when you use beta desynchonisation (ie change relative to the baseline) instead for each condition, and see source/channel maps of that separately for L and R and then when you take the difference. I suppose the main element this checks for is whether L and R conditions have the same baseline. This doesn't immediately explain why source and channel results are different but in the absence of any other clues it may be a way to 2ble check the whole process. Another point to consider is that, although beta changes should appear in all subjects, it is possibly true that there are individual differences in the actual beta range and frequency bin of maximum effect. If you are using the same settings for all subjects when you beamform with DICS you may be missing some of the effect (true, this is also the case for channel data but there may be subtle differences that add up - there are many voxels and few channels). I believe it may be useful to see what happens when you run the beamformer tailored to each subject's particular beta characteristics (ie change the "foi" for each subject, keep the tapsmofrq the same - possibly smaller) and then combine everything (you'll need of course to come up with a relative metric such as perc. change when you combine all subjects to account for the slightly different frequencies you used ) Best, Haris Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych University of Minnesota Dept of Neuroscience and Brain Sciences Center On 21 November 2013 10:36, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haristz at gmail.com Fri Nov 22 07:07:59 2013 From: haristz at gmail.com (Charidimos Tzagarakis) Date: Fri, 22 Nov 2013 00:07:59 -0600 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Eelke, Thinking again about my second suggestion (regarding individual variability) I actually can't think of a case where this could realistically produce what you get. On the other hand, looking at TF maps per subject and channel (on the "helmet" layout), normalised with a "rest" epoch, may help spot something unusual. Best, Haris Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych University of Minnesota Dept of Neuroscience and Brain Sciences Center On 21 November 2013 18:09, Charidimos Tzagarakis wrote: > Hi Eelke, > Provided there is no major recent revision of the DICS code, I would have > expected motor desynchronisation to show up pretty well. Are the maps shown > at source and channel level straight differences of L and Right hand > conditions at the beta band (I hope I am correctly interpreting your > paradigm) ? If so it might be helpful in pinpointing the problem/as a > sanity check to see what happens when you use beta desynchonisation (ie > change relative to the baseline) instead for each condition, and see > source/channel maps of that separately for L and R and then when you take > the difference. I suppose the main element this checks for is whether L and > R conditions have the same baseline. > This doesn't immediately explain why source and channel results are > different but in the absence of any other clues it may be a way to 2ble > check the whole process. > > > Another point to consider is that, although beta changes should appear in > all subjects, it is possibly true that there are individual differences in > the actual beta range and frequency bin of maximum effect. If you are using > the same settings for all subjects when you beamform with DICS you may be > missing some of the effect (true, this is also the case for channel data > but there may be subtle differences that add up - there are many voxels and > few channels). I believe it may be useful to see what happens when you run > the beamformer tailored to each subject's particular beta characteristics > (ie change the "foi" for each subject, keep the tapsmofrq the same - > possibly smaller) and then combine everything (you'll need of course to > come up with a relative metric such as perc. change when you combine all > subjects to account for the slightly different frequencies you used ) > > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak wrote: > >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus right-hand index >> finger button presses. As expected, on sensor level (combined planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer (common >> filter, applied to both conditions separately; fixedori and realfilter >> = 'yes'). The grand average results for this (again contrast left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry than on >> sensor level. This picture is without using any regularisation (lambda >> parameter), the results are even worse when I use lambda = '5%'. The >> negative blob (right hand higher power than left) becomes 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. Also, the >> individual results are much less topographically consistent on source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually verified >> the alignment of headmodel, sourcemodel, and gradiometer information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum on the >> axial gradiometer data, obtained for just the time-frequency range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this contrast are >> exactly the same as those going into ft_sourceanalysis, so the problem >> must be in the source analysis step (and/or in the preparation of the >> geometric information, although these seem fine by visual inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jm.horschig at donders.ru.nl Fri Nov 22 08:06:31 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Fri, 22 Nov 2013 08:06:31 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: <528F0277.5070200@donders.ru.nl> Hi Eelke, since everyone jumped on the train, here my 2 cents: To verify whether this is a newly introduced bug, maybe run a tutorial test script that includes beamforming. If they look alright, it gets more likely that it is you or your data and not fieldtrip :) It's not definite evidence of course though. SinceVitoria also experiences strange things, it might be something worthwhile to investigate. My initial guess from the plots is that there is something wrong with the forward model. All unit problems should have been resolved, but just to be sure you could check whether all objects are in the same unit (make it 'cm' as the grads are). Best, Jörn Charidimos Tzagarakis wrote: > Eelke, > Thinking again about my second suggestion (regarding individual > variability) I actually can't think of a case where this could > realistically produce what you get. On the other hand, looking at TF > maps per subject and channel (on the "helmet" layout), normalised with > a "rest" epoch, may help spot something unusual. > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > On 21 November 2013 18:09, Charidimos Tzagarakis > wrote: > > Hi Eelke, > Provided there is no major recent revision of the DICS code, I > would have expected motor desynchronisation to show up pretty > well. Are the maps shown at source and channel level straight > differences of L and Right hand conditions at the beta band (I > hope I am correctly interpreting your paradigm) ? If so it might > be helpful in pinpointing the problem/as a sanity check to see > what happens when you use beta desynchonisation (ie change > relative to the baseline) instead for each condition, and see > source/channel maps of that separately for L and R and then when > you take the difference. I suppose the main element this checks > for is whether L and R conditions have the same baseline. > This doesn't immediately explain why source and channel results > are different but in the absence of any other clues it may be a > way to 2ble check the whole process. > > > Another point to consider is that, although beta changes should > appear in all subjects, it is possibly true that there are > individual differences in the actual beta range and frequency bin > of maximum effect. If you are using the same settings for all > subjects when you beamform with DICS you may be missing some of > the effect (true, this is also the case for channel data but there > may be subtle differences that add up - there are many voxels and > few channels). I believe it may be useful to see what happens when > you run the beamformer tailored to each subject's particular beta > characteristics (ie change the "foi" for each subject, keep the > tapsmofrq the same - possibly smaller) and then combine everything > (you'll need of course to come up with a relative metric such as > perc. change when you combine all subjects to account for the > slightly different frequencies you used ) > > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak > wrote: > > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus > right-hand index > finger button presses. As expected, on sensor level (combined > planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer > (common > filter, applied to both conditions separately; fixedori and > realfilter > = 'yes'). The grand average results for this (again contrast > left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . > (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry > than on > sensor level. This picture is without using any regularisation > (lambda > parameter), the results are even worse when I use lambda = > '5%'. The > negative blob (right hand higher power than left) becomes > 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. > Also, the > individual results are much less topographically consistent on > source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually > verified > the alignment of headmodel, sourcemodel, and gradiometer > information > for all subjects. > > As a final note, the above sensor-level plot was taken from a > 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum > on the > axial gradiometer data, obtained for just the time-frequency > range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, > tapsmofrq = 7). > When I compute condition-averaged power based on these fourier > spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this > contrast are > exactly the same as those going into ft_sourceanalysis, so the > problem > must be in the source analysis step (and/or in the preparation > of the > geometric information, although these seem fine by visual > inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > ------------------------------------------------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Fri Nov 22 08:41:35 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 08:41:35 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <528F0277.5070200@donders.ru.nl> References: <528F0277.5070200@donders.ru.nl> Message-ID: Hi everyone, Thanks very much for your great input so far! Actually, as Jörn suggested, I did the very straightforward check (thanks for the tip :) ) of running one of our tutorial test scripts (test_beamforming_extended), and it turns out this one does not produce the same results as depicted here: http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most likely somewhere a bug has been introduced... Hopefully I can find out what it is today and fix it. Will keep you posted! Best, Eelke On 22 November 2013 08:06, "Jörn M. Horschig" wrote: > Hi Eelke, > > since everyone jumped on the train, here my 2 cents: > To verify whether this is a newly introduced bug, maybe run a tutorial test > script that includes beamforming. If they look alright, it gets more likely > that it is you or your data and not fieldtrip :) It's not definite evidence > of course though. SinceVitoria also experiences strange things, it might be > something worthwhile to investigate. > > My initial guess from the plots is that there is something wrong with the > forward model. All unit problems should have been resolved, but just to be > sure you could check whether all objects are in the same unit (make it 'cm' > as the grads are). > > Best, > Jörn > > Charidimos Tzagarakis wrote: >> >> Eelke, >> Thinking again about my second suggestion (regarding individual >> variability) I actually can't think of a case where this could realistically >> produce what you get. On the other hand, looking at TF maps per subject and >> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >> spot something unusual. >> Best, >> Haris >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> On 21 November 2013 18:09, Charidimos Tzagarakis > > wrote: >> >> Hi Eelke, >> Provided there is no major recent revision of the DICS code, I >> would have expected motor desynchronisation to show up pretty >> well. Are the maps shown at source and channel level straight >> differences of L and Right hand conditions at the beta band (I >> hope I am correctly interpreting your paradigm) ? If so it might >> be helpful in pinpointing the problem/as a sanity check to see >> what happens when you use beta desynchonisation (ie change >> relative to the baseline) instead for each condition, and see >> source/channel maps of that separately for L and R and then when >> you take the difference. I suppose the main element this checks >> for is whether L and R conditions have the same baseline. >> This doesn't immediately explain why source and channel results >> are different but in the absence of any other clues it may be a >> way to 2ble check the whole process. >> >> >> Another point to consider is that, although beta changes should >> appear in all subjects, it is possibly true that there are >> individual differences in the actual beta range and frequency bin >> of maximum effect. If you are using the same settings for all >> subjects when you beamform with DICS you may be missing some of >> the effect (true, this is also the case for channel data but there >> may be subtle differences that add up - there are many voxels and >> few channels). I believe it may be useful to see what happens when >> you run the beamformer tailored to each subject's particular beta >> characteristics (ie change the "foi" for each subject, keep the >> tapsmofrq the same - possibly smaller) and then combine everything >> (you'll need of course to come up with a relative metric such as >> perc. change when you combine all subjects to account for the >> slightly different frequencies you used ) >> >> Best, >> Haris >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> On 21 November 2013 10:36, Eelke Spaak > > wrote: >> >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus >> right-hand index >> finger button presses. As expected, on sensor level (combined >> planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer >> (common >> filter, applied to both conditions separately; fixedori and >> realfilter >> = 'yes'). The grand average results for this (again contrast >> left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . >> (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry >> than on >> sensor level. This picture is without using any regularisation >> (lambda >> parameter), the results are even worse when I use lambda = >> '5%'. The >> negative blob (right hand higher power than left) becomes >> 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. >> Also, the >> individual results are much less topographically consistent on >> source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually >> verified >> the alignment of headmodel, sourcemodel, and gradiometer >> information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a >> 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum >> on the >> axial gradiometer data, obtained for just the time-frequency >> range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >> tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier >> spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this >> contrast are >> exactly the same as those going into ft_sourceanalysis, so the >> problem >> must be in the source analysis step (and/or in the preparation >> of the >> geometric information, although these seem fine by visual >> inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Fri Nov 22 09:03:00 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 22 Nov 2013 09:03:00 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> Message-ID: Hoi Eelke, Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de forward module verwacht. Ik gok dat de high-level functies dit niet afdwingen, waardoor de leadfields er bekaaid van af komen. Gr, JM On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > Hi everyone, > > Thanks very much for your great input so far! Actually, as Jörn > suggested, I did the very straightforward check (thanks for the tip :) > ) of running one of our tutorial test scripts > (test_beamforming_extended), and it turns out this one does not > produce the same results as depicted here: > http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most > likely somewhere a bug has been introduced... > > Hopefully I can find out what it is today and fix it. Will keep you posted! > > Best, > Eelke > > On 22 November 2013 08:06, "Jörn M. Horschig" wrote: >> Hi Eelke, >> >> since everyone jumped on the train, here my 2 cents: >> To verify whether this is a newly introduced bug, maybe run a tutorial test >> script that includes beamforming. If they look alright, it gets more likely >> that it is you or your data and not fieldtrip :) It's not definite evidence >> of course though. SinceVitoria also experiences strange things, it might be >> something worthwhile to investigate. >> >> My initial guess from the plots is that there is something wrong with the >> forward model. All unit problems should have been resolved, but just to be >> sure you could check whether all objects are in the same unit (make it 'cm' >> as the grads are). >> >> Best, >> Jörn >> >> Charidimos Tzagarakis wrote: >>> >>> Eelke, >>> Thinking again about my second suggestion (regarding individual >>> variability) I actually can't think of a case where this could realistically >>> produce what you get. On the other hand, looking at TF maps per subject and >>> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >>> spot something unusual. >>> Best, >>> Haris >>> >>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>> >>> >>> >>> On 21 November 2013 18:09, Charidimos Tzagarakis >> > wrote: >>> >>> Hi Eelke, >>> Provided there is no major recent revision of the DICS code, I >>> would have expected motor desynchronisation to show up pretty >>> well. Are the maps shown at source and channel level straight >>> differences of L and Right hand conditions at the beta band (I >>> hope I am correctly interpreting your paradigm) ? If so it might >>> be helpful in pinpointing the problem/as a sanity check to see >>> what happens when you use beta desynchonisation (ie change >>> relative to the baseline) instead for each condition, and see >>> source/channel maps of that separately for L and R and then when >>> you take the difference. I suppose the main element this checks >>> for is whether L and R conditions have the same baseline. >>> This doesn't immediately explain why source and channel results >>> are different but in the absence of any other clues it may be a >>> way to 2ble check the whole process. >>> >>> >>> Another point to consider is that, although beta changes should >>> appear in all subjects, it is possibly true that there are >>> individual differences in the actual beta range and frequency bin >>> of maximum effect. If you are using the same settings for all >>> subjects when you beamform with DICS you may be missing some of >>> the effect (true, this is also the case for channel data but there >>> may be subtle differences that add up - there are many voxels and >>> few channels). I believe it may be useful to see what happens when >>> you run the beamformer tailored to each subject's particular beta >>> characteristics (ie change the "foi" for each subject, keep the >>> tapsmofrq the same - possibly smaller) and then combine everything >>> (you'll need of course to come up with a relative metric such as >>> perc. change when you combine all subjects to account for the >>> slightly different frequencies you used ) >>> >>> Best, >>> Haris >>> >>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>> >>> >>> >>> On 21 November 2013 10:36, Eelke Spaak >> > wrote: >>> >>> Fellow FieldTrippers, >>> >>> Currently I am looking at a contrast for left- versus >>> right-hand index >>> finger button presses. As expected, on sensor level (combined >>> planar >>> gradient, grand average) I see a clear lateralisation in beta band >>> power starting at least 0.5s before the button press (see >>> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >>> clearly more beta power ipsilateral to the response hand. I would >>> prefer to do further analyses on source level, so I attempt to >>> reconstruct the sources for this effect using DICS beamformer >>> (common >>> filter, applied to both conditions separately; fixedori and >>> realfilter >>> = 'yes'). The grand average results for this (again contrast >>> left vs >>> right response hand) are shown at https://db.tt/IBQZG0d8 . >>> (Ignore the >>> R/L-flip, this is radiological convention.) >>> >>> As you can see, the source level solution is much more blurry >>> than on >>> sensor level. This picture is without using any regularisation >>> (lambda >>> parameter), the results are even worse when I use lambda = >>> '5%'. The >>> negative blob (right hand higher power than left) becomes >>> 'marginally >>> significant' on source level (p ~ 0.06) where it was p < 0.001 on >>> sensor level. The positive blob is nowhere near significant. >>> Also, the >>> individual results are much less topographically consistent on >>> source >>> than on sensor level (explaining the worse statistics). >>> >>> I have checked the segmentation of my MRIs, the 'gray' seems to be >>> nicely within the head all the time. Also, I have manually >>> verified >>> the alignment of headmodel, sourcemodel, and gradiometer >>> information >>> for all subjects. >>> >>> As a final note, the above sensor-level plot was taken from a >>> 'slice' >>> out of a planar-gradient time-frequency analysis (mtmconvol). The >>> ingredient for the beamformer was an mtmfft fourier spectrum >>> on the >>> axial gradiometer data, obtained for just the time-frequency >>> range of >>> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >>> tapsmofrq = 7). >>> When I compute condition-averaged power based on these fourier >>> spectra >>> and look at the contrast, the results are again as expected: >>> https://db.tt/n2P3UKcQ (of course less localised because of axial >>> gradient vs planar). The freq structures underlying this >>> contrast are >>> exactly the same as those going into ft_sourceanalysis, so the >>> problem >>> must be in the source analysis step (and/or in the preparation >>> of the >>> geometric information, although these seem fine by visual >>> inspection). >>> >>> Does anyone have any idea that might explain these seemingly >>> contradictory results? I would have expected demixing to improve >>> signal-to-noise ratio, rather than worsen it. >>> >>> Thanks! >>> Best, >>> Eelke >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Fri Nov 22 09:11:25 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 22 Nov 2013 09:11:25 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> Message-ID: <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> To all, This reply should have gone to Eelke and not to the whole list. Apologies for that. For those who understand Dutch: doe er je voordeel mee. Groeten, Jan-Mathijs On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: > Hoi Eelke, > > Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de forward module verwacht. Ik gok dat de high-level functies dit niet afdwingen, waardoor de leadfields er bekaaid van af komen. > > Gr, > JM > > On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > >> Hi everyone, >> >> Thanks very much for your great input so far! Actually, as Jörn >> suggested, I did the very straightforward check (thanks for the tip :) >> ) of running one of our tutorial test scripts >> (test_beamforming_extended), and it turns out this one does not >> produce the same results as depicted here: >> http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most >> likely somewhere a bug has been introduced... >> >> Hopefully I can find out what it is today and fix it. Will keep you posted! >> >> Best, >> Eelke >> >> On 22 November 2013 08:06, "Jörn M. Horschig" wrote: >>> Hi Eelke, >>> >>> since everyone jumped on the train, here my 2 cents: >>> To verify whether this is a newly introduced bug, maybe run a tutorial test >>> script that includes beamforming. If they look alright, it gets more likely >>> that it is you or your data and not fieldtrip :) It's not definite evidence >>> of course though. SinceVitoria also experiences strange things, it might be >>> something worthwhile to investigate. >>> >>> My initial guess from the plots is that there is something wrong with the >>> forward model. All unit problems should have been resolved, but just to be >>> sure you could check whether all objects are in the same unit (make it 'cm' >>> as the grads are). >>> >>> Best, >>> Jörn >>> >>> Charidimos Tzagarakis wrote: >>>> >>>> Eelke, >>>> Thinking again about my second suggestion (regarding individual >>>> variability) I actually can't think of a case where this could realistically >>>> produce what you get. On the other hand, looking at TF maps per subject and >>>> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >>>> spot something unusual. >>>> Best, >>>> Haris >>>> >>>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>>> >>>> >>>> >>>> On 21 November 2013 18:09, Charidimos Tzagarakis >>> > wrote: >>>> >>>> Hi Eelke, >>>> Provided there is no major recent revision of the DICS code, I >>>> would have expected motor desynchronisation to show up pretty >>>> well. Are the maps shown at source and channel level straight >>>> differences of L and Right hand conditions at the beta band (I >>>> hope I am correctly interpreting your paradigm) ? If so it might >>>> be helpful in pinpointing the problem/as a sanity check to see >>>> what happens when you use beta desynchonisation (ie change >>>> relative to the baseline) instead for each condition, and see >>>> source/channel maps of that separately for L and R and then when >>>> you take the difference. I suppose the main element this checks >>>> for is whether L and R conditions have the same baseline. >>>> This doesn't immediately explain why source and channel results >>>> are different but in the absence of any other clues it may be a >>>> way to 2ble check the whole process. >>>> >>>> >>>> Another point to consider is that, although beta changes should >>>> appear in all subjects, it is possibly true that there are >>>> individual differences in the actual beta range and frequency bin >>>> of maximum effect. If you are using the same settings for all >>>> subjects when you beamform with DICS you may be missing some of >>>> the effect (true, this is also the case for channel data but there >>>> may be subtle differences that add up - there are many voxels and >>>> few channels). I believe it may be useful to see what happens when >>>> you run the beamformer tailored to each subject's particular beta >>>> characteristics (ie change the "foi" for each subject, keep the >>>> tapsmofrq the same - possibly smaller) and then combine everything >>>> (you'll need of course to come up with a relative metric such as >>>> perc. change when you combine all subjects to account for the >>>> slightly different frequencies you used ) >>>> >>>> Best, >>>> Haris >>>> >>>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>>> >>>> >>>> >>>> On 21 November 2013 10:36, Eelke Spaak >>> > wrote: >>>> >>>> Fellow FieldTrippers, >>>> >>>> Currently I am looking at a contrast for left- versus >>>> right-hand index >>>> finger button presses. As expected, on sensor level (combined >>>> planar >>>> gradient, grand average) I see a clear lateralisation in beta band >>>> power starting at least 0.5s before the button press (see >>>> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >>>> clearly more beta power ipsilateral to the response hand. I would >>>> prefer to do further analyses on source level, so I attempt to >>>> reconstruct the sources for this effect using DICS beamformer >>>> (common >>>> filter, applied to both conditions separately; fixedori and >>>> realfilter >>>> = 'yes'). The grand average results for this (again contrast >>>> left vs >>>> right response hand) are shown at https://db.tt/IBQZG0d8 . >>>> (Ignore the >>>> R/L-flip, this is radiological convention.) >>>> >>>> As you can see, the source level solution is much more blurry >>>> than on >>>> sensor level. This picture is without using any regularisation >>>> (lambda >>>> parameter), the results are even worse when I use lambda = >>>> '5%'. The >>>> negative blob (right hand higher power than left) becomes >>>> 'marginally >>>> significant' on source level (p ~ 0.06) where it was p < 0.001 on >>>> sensor level. The positive blob is nowhere near significant. >>>> Also, the >>>> individual results are much less topographically consistent on >>>> source >>>> than on sensor level (explaining the worse statistics). >>>> >>>> I have checked the segmentation of my MRIs, the 'gray' seems to be >>>> nicely within the head all the time. Also, I have manually >>>> verified >>>> the alignment of headmodel, sourcemodel, and gradiometer >>>> information >>>> for all subjects. >>>> >>>> As a final note, the above sensor-level plot was taken from a >>>> 'slice' >>>> out of a planar-gradient time-frequency analysis (mtmconvol). The >>>> ingredient for the beamformer was an mtmfft fourier spectrum >>>> on the >>>> axial gradiometer data, obtained for just the time-frequency >>>> range of >>>> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >>>> tapsmofrq = 7). >>>> When I compute condition-averaged power based on these fourier >>>> spectra >>>> and look at the contrast, the results are again as expected: >>>> https://db.tt/n2P3UKcQ (of course less localised because of axial >>>> gradient vs planar). The freq structures underlying this >>>> contrast are >>>> exactly the same as those going into ft_sourceanalysis, so the >>>> problem >>>> must be in the source analysis step (and/or in the preparation >>>> of the >>>> geometric information, although these seem fine by visual >>>> inspection). >>>> >>>> Does anyone have any idea that might explain these seemingly >>>> contradictory results? I would have expected demixing to improve >>>> signal-to-noise ratio, rather than worsen it. >>>> >>>> Thanks! >>>> Best, >>>> Eelke >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Fri Nov 22 11:51:08 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 11:51:08 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> References: <528F0277.5070200@donders.ru.nl> <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> Message-ID: Following this up: Jan-Mathijs' suggestion did the trick (as usual, thanks), at least for the tutorial code. It turns out that it is now required to explicitly convert the geometric objects to 'm' before doing source analysis. I am certain that this was not required in the past, as I taught workshops with the beamforming-extended tutorial where we did not do the unit conversion and results looked fine. So now we will investigate what exactly changed and make sure that either the conversion is done automatically or the user is informed of non-matching units. Best, Eelke On 22 November 2013 09:11, jan-mathijs schoffelen wrote: > To all, > > This reply should have gone to Eelke and not to the whole list. Apologies > for that. For those who understand Dutch: doe er je voordeel mee. > > Groeten, > Jan-Mathijs > > > > On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: > > Hoi Eelke, > > Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, > sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de > forward module verwacht. Ik gok dat de high-level functies dit niet > afdwingen, waardoor de leadfields er bekaaid van af komen. > > Gr, > JM > > On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > > Hi everyone, > > Thanks very much for your great input so far! Actually, as Jörn > suggested, I did the very straightforward check (thanks for the tip :) > ) of running one of our tutorial test scripts > (test_beamforming_extended), and it turns out this one does not > produce the same results as depicted here: > http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most > likely somewhere a bug has been introduced... > > Hopefully I can find out what it is today and fix it. Will keep you posted! > > Best, > Eelke > > On 22 November 2013 08:06, "Jörn M. Horschig" > wrote: > > Hi Eelke, > > > since everyone jumped on the train, here my 2 cents: > > To verify whether this is a newly introduced bug, maybe run a tutorial test > > script that includes beamforming. If they look alright, it gets more likely > > that it is you or your data and not fieldtrip :) It's not definite evidence > > of course though. SinceVitoria also experiences strange things, it might be > > something worthwhile to investigate. > > > My initial guess from the plots is that there is something wrong with the > > forward model. All unit problems should have been resolved, but just to be > > sure you could check whether all objects are in the same unit (make it 'cm' > > as the grads are). > > > Best, > > Jörn > > > Charidimos Tzagarakis wrote: > > > Eelke, > > Thinking again about my second suggestion (regarding individual > > variability) I actually can't think of a case where this could realistically > > produce what you get. On the other hand, looking at TF maps per subject and > > channel (on the "helmet" layout), normalised with a "rest" epoch, may help > > spot something unusual. > > Best, > > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 18:09, Charidimos Tzagarakis > > wrote: > > > Hi Eelke, > > Provided there is no major recent revision of the DICS code, I > > would have expected motor desynchronisation to show up pretty > > well. Are the maps shown at source and channel level straight > > differences of L and Right hand conditions at the beta band (I > > hope I am correctly interpreting your paradigm) ? If so it might > > be helpful in pinpointing the problem/as a sanity check to see > > what happens when you use beta desynchonisation (ie change > > relative to the baseline) instead for each condition, and see > > source/channel maps of that separately for L and R and then when > > you take the difference. I suppose the main element this checks > > for is whether L and R conditions have the same baseline. > > This doesn't immediately explain why source and channel results > > are different but in the absence of any other clues it may be a > > way to 2ble check the whole process. > > > > Another point to consider is that, although beta changes should > > appear in all subjects, it is possibly true that there are > > individual differences in the actual beta range and frequency bin > > of maximum effect. If you are using the same settings for all > > subjects when you beamform with DICS you may be missing some of > > the effect (true, this is also the case for channel data but there > > may be subtle differences that add up - there are many voxels and > > few channels). I believe it may be useful to see what happens when > > you run the beamformer tailored to each subject's particular beta > > characteristics (ie change the "foi" for each subject, keep the > > tapsmofrq the same - possibly smaller) and then combine everything > > (you'll need of course to come up with a relative metric such as > > perc. change when you combine all subjects to account for the > > slightly different frequencies you used ) > > > Best, > > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak > > wrote: > > > Fellow FieldTrippers, > > > Currently I am looking at a contrast for left- versus > > right-hand index > > finger button presses. As expected, on sensor level (combined > > planar > > gradient, grand average) I see a clear lateralisation in beta band > > power starting at least 0.5s before the button press (see > > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > > clearly more beta power ipsilateral to the response hand. I would > > prefer to do further analyses on source level, so I attempt to > > reconstruct the sources for this effect using DICS beamformer > > (common > > filter, applied to both conditions separately; fixedori and > > realfilter > > = 'yes'). The grand average results for this (again contrast > > left vs > > right response hand) are shown at https://db.tt/IBQZG0d8 . > > (Ignore the > > R/L-flip, this is radiological convention.) > > > As you can see, the source level solution is much more blurry > > than on > > sensor level. This picture is without using any regularisation > > (lambda > > parameter), the results are even worse when I use lambda = > > '5%'. The > > negative blob (right hand higher power than left) becomes > > 'marginally > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > sensor level. The positive blob is nowhere near significant. > > Also, the > > individual results are much less topographically consistent on > > source > > than on sensor level (explaining the worse statistics). > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > nicely within the head all the time. Also, I have manually > > verified > > the alignment of headmodel, sourcemodel, and gradiometer > > information > > for all subjects. > > > As a final note, the above sensor-level plot was taken from a > > 'slice' > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > ingredient for the beamformer was an mtmfft fourier spectrum > > on the > > axial gradiometer data, obtained for just the time-frequency > > range of > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, > > tapsmofrq = 7). > > When I compute condition-averaged power based on these fourier > > spectra > > and look at the contrast, the results are again as expected: > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > gradient vs planar). The freq structures underlying this > > contrast are > > exactly the same as those going into ft_sourceanalysis, so the > > problem > > must be in the source analysis step (and/or in the preparation > > of the > > geometric information, although these seem fine by visual > > inspection). > > > Does anyone have any idea that might explain these seemingly > > contradictory results? I would have expected demixing to improve > > signal-to-noise ratio, rather than worsen it. > > > Thanks! > > Best, > > Eelke > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Fri Nov 22 12:59:34 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 12:59:34 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> Message-ID: As confirmed by Robert, there is indeed a bug in the handling of distance units in ft_prepare_leadfield. This function will now (FTP release as of tonight) throw an error if units are not in agreement. Discussion of this bug will continue at http://bugzilla.fcdonders.nl/show_bug.cgi?id=2387 or at one of the related bugs. Cheers, Eelke On 22 November 2013 11:51, Eelke Spaak wrote: > Following this up: Jan-Mathijs' suggestion did the trick (as usual, > thanks), at least for the tutorial code. It turns out that it is now > required to explicitly convert the geometric objects to 'm' before > doing source analysis. > > I am certain that this was not required in the past, as I taught > workshops with the beamforming-extended tutorial where we did not do > the unit conversion and results looked fine. So now we will > investigate what exactly changed and make sure that either the > conversion is done automatically or the user is informed of > non-matching units. > > Best, > Eelke > > > On 22 November 2013 09:11, jan-mathijs schoffelen > wrote: >> To all, >> >> This reply should have gone to Eelke and not to the whole list. Apologies >> for that. For those who understand Dutch: doe er je voordeel mee. >> >> Groeten, >> Jan-Mathijs >> >> >> >> On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: >> >> Hoi Eelke, >> >> Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, >> sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de >> forward module verwacht. Ik gok dat de high-level functies dit niet >> afdwingen, waardoor de leadfields er bekaaid van af komen. >> >> Gr, >> JM >> >> On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: >> >> Hi everyone, >> >> Thanks very much for your great input so far! Actually, as Jörn >> suggested, I did the very straightforward check (thanks for the tip :) >> ) of running one of our tutorial test scripts >> (test_beamforming_extended), and it turns out this one does not >> produce the same results as depicted here: >> http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most >> likely somewhere a bug has been introduced... >> >> Hopefully I can find out what it is today and fix it. Will keep you posted! >> >> Best, >> Eelke >> >> On 22 November 2013 08:06, "Jörn M. Horschig" >> wrote: >> >> Hi Eelke, >> >> >> since everyone jumped on the train, here my 2 cents: >> >> To verify whether this is a newly introduced bug, maybe run a tutorial test >> >> script that includes beamforming. If they look alright, it gets more likely >> >> that it is you or your data and not fieldtrip :) It's not definite evidence >> >> of course though. SinceVitoria also experiences strange things, it might be >> >> something worthwhile to investigate. >> >> >> My initial guess from the plots is that there is something wrong with the >> >> forward model. All unit problems should have been resolved, but just to be >> >> sure you could check whether all objects are in the same unit (make it 'cm' >> >> as the grads are). >> >> >> Best, >> >> Jörn >> >> >> Charidimos Tzagarakis wrote: >> >> >> Eelke, >> >> Thinking again about my second suggestion (regarding individual >> >> variability) I actually can't think of a case where this could realistically >> >> produce what you get. On the other hand, looking at TF maps per subject and >> >> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >> >> spot something unusual. >> >> Best, >> >> Haris >> >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> >> On 21 November 2013 18:09, Charidimos Tzagarakis > >> > wrote: >> >> >> Hi Eelke, >> >> Provided there is no major recent revision of the DICS code, I >> >> would have expected motor desynchronisation to show up pretty >> >> well. Are the maps shown at source and channel level straight >> >> differences of L and Right hand conditions at the beta band (I >> >> hope I am correctly interpreting your paradigm) ? If so it might >> >> be helpful in pinpointing the problem/as a sanity check to see >> >> what happens when you use beta desynchonisation (ie change >> >> relative to the baseline) instead for each condition, and see >> >> source/channel maps of that separately for L and R and then when >> >> you take the difference. I suppose the main element this checks >> >> for is whether L and R conditions have the same baseline. >> >> This doesn't immediately explain why source and channel results >> >> are different but in the absence of any other clues it may be a >> >> way to 2ble check the whole process. >> >> >> >> Another point to consider is that, although beta changes should >> >> appear in all subjects, it is possibly true that there are >> >> individual differences in the actual beta range and frequency bin >> >> of maximum effect. If you are using the same settings for all >> >> subjects when you beamform with DICS you may be missing some of >> >> the effect (true, this is also the case for channel data but there >> >> may be subtle differences that add up - there are many voxels and >> >> few channels). I believe it may be useful to see what happens when >> >> you run the beamformer tailored to each subject's particular beta >> >> characteristics (ie change the "foi" for each subject, keep the >> >> tapsmofrq the same - possibly smaller) and then combine everything >> >> (you'll need of course to come up with a relative metric such as >> >> perc. change when you combine all subjects to account for the >> >> slightly different frequencies you used ) >> >> >> Best, >> >> Haris >> >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> >> On 21 November 2013 10:36, Eelke Spaak > >> > wrote: >> >> >> Fellow FieldTrippers, >> >> >> Currently I am looking at a contrast for left- versus >> >> right-hand index >> >> finger button presses. As expected, on sensor level (combined >> >> planar >> >> gradient, grand average) I see a clear lateralisation in beta band >> >> power starting at least 0.5s before the button press (see >> >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> >> clearly more beta power ipsilateral to the response hand. I would >> >> prefer to do further analyses on source level, so I attempt to >> >> reconstruct the sources for this effect using DICS beamformer >> >> (common >> >> filter, applied to both conditions separately; fixedori and >> >> realfilter >> >> = 'yes'). The grand average results for this (again contrast >> >> left vs >> >> right response hand) are shown at https://db.tt/IBQZG0d8 . >> >> (Ignore the >> >> R/L-flip, this is radiological convention.) >> >> >> As you can see, the source level solution is much more blurry >> >> than on >> >> sensor level. This picture is without using any regularisation >> >> (lambda >> >> parameter), the results are even worse when I use lambda = >> >> '5%'. The >> >> negative blob (right hand higher power than left) becomes >> >> 'marginally >> >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> >> sensor level. The positive blob is nowhere near significant. >> >> Also, the >> >> individual results are much less topographically consistent on >> >> source >> >> than on sensor level (explaining the worse statistics). >> >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> >> nicely within the head all the time. Also, I have manually >> >> verified >> >> the alignment of headmodel, sourcemodel, and gradiometer >> >> information >> >> for all subjects. >> >> >> As a final note, the above sensor-level plot was taken from a >> >> 'slice' >> >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> >> ingredient for the beamformer was an mtmfft fourier spectrum >> >> on the >> >> axial gradiometer data, obtained for just the time-frequency >> >> range of >> >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >> >> tapsmofrq = 7). >> >> When I compute condition-averaged power based on these fourier >> >> spectra >> >> and look at the contrast, the results are again as expected: >> >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> >> gradient vs planar). The freq structures underlying this >> >> contrast are >> >> exactly the same as those going into ft_sourceanalysis, so the >> >> problem >> >> must be in the source analysis step (and/or in the preparation >> >> of the >> >> geometric information, although these seem fine by visual >> >> inspection). >> >> >> Does anyone have any idea that might explain these seemingly >> >> contradictory results? I would have expected demixing to improve >> >> signal-to-noise ratio, rather than worsen it. >> >> >> Thanks! >> >> Best, >> >> Eelke >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From andrea.brovelli at univ-amu.fr Fri Nov 22 13:33:35 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Fri, 22 Nov 2013 13:33:35 +0100 (CET) Subject: [FieldTrip] Conjunction analysis In-Reply-To: <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> References: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> Message-ID: <85141893.13184.1385123615804.JavaMail.root@bureau-frontal2> Last comment on Conjunction analysis: I got an email from Thomas Nichols (2005, Neuroimage). In fact, things are much easier than expected, no special code is required. The conjunction is just the minimum of the two statistics (t-valeus, for example, or, equivalently, the maximum of the two p-values).  And this is independent of the type of statistical test used  (parametric or non-parametric). So, the implementation in ft_conjunctionanalysis should be safe. Bye Andrea andrea brovelli wrote:Thanks a lot for your reply, Arjen. It's clearer now. In fact, I am using a parametric tests, so I think I would need to use the Nichols 2005 method for the conjunction analysis. Does anyone have the code to do this or does anyone know how to recover it within SPM ? Thanks a lot Andrea "A.stolk" wrote:Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjen andrea brovelli schreef: Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip_______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From caspervanheck at gmail.com Fri Nov 22 13:36:22 2013 From: caspervanheck at gmail.com (Casper van Heck) Date: Fri, 22 Nov 2013 13:36:22 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Eelke, I was busy with some other stuff, and just now revisited the analysis. Even with a newer version of Fieldtrip, this is still happening, and I still do not know why... Have you had time to take a look at it? Sincerely, Casper On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck wrote: > Dear Eelke, > > I've put up an exerpt of my code, with the data from a single subject > (no.10, 9MB) in a separate folder here > . > It also includes a screenshot of what I see with when I run the code with > this exact dataset, and a small program 'filehandler', which I've been to > lazy to replace. > > Note that this specific subject only has about 60 seconds of data (and I'm > still waiting for the student to tell me why). > > I'm hoping you'll get the same result as the screenshot, and you'll be > able to tell me why... > > Best regards, > > Casper > > > On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak wrote: > >> Dear Casper, >> >> Could you maybe post a snippet online somewhere (e.g. dropbox) of data >> corresponding to this plot (i.e. the output of ft_freqanalysis that >> you input to ft_singleplotTFR, assuming that it's averaged over trials >> and therefore small)? Then we can see whether this is reproducable on >> our systems. >> >> Best, >> Eelke >> >> On 16 September 2013 17:12, Casper van Heck >> wrote: >> > Dear Fieldtrippers, >> > >> > I've been doing some exploratory plotting of a dataset where several >> > subjects were exposed to a continuous stimulus (CPM) over the course of >> > three minutes. One of the things that was asked was a time-frequency >> plot, >> > over those three minutes. While I'm not quite sure a TFR can be used on >> that >> > scale without problems, I went ahead with it just to see what Fieldtrip >> > would do. What I got, was this: >> > http://tinypic.com/r/zx2tqs/5| >> > And I have no idea what went wrong (note that this specific subject >> only got >> > a 60s stimulus). Quality of the picture and the validity of the analysis >> > aside, I have a severe problem with the axes, which seem to be all over >> the >> > place. >> > >> > I simply read the data using ft_preprocessing (no filters or anything, >> since >> > the student in charge already used a 10Hz high-pass and a 150Hz low-pass >> > filter). >> > The only field in 'cfg' is 'headerfile'. >> > >> > Next, I call ft_freqanalysis with: >> > cfg.output = 'pow'; >> > cfg.method = 'wavelet'; % default; Morlet wavelet >> > cfg.taper = 'hanning'; >> > cfg.tapsmofrq = 4; >> > cfg.channel = 'Cz'; >> > cfg.foi = [20:0.5:30]; >> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; >> > cfg.toi = 0:0.5:60; >> > >> > And finally, I end up with the monstrocity shown earlier. This problem >> only >> > presents itself with Fieldtrip-related functions, the normal >> Matlab-plots >> > work as well as they've ever done, so I'm thinking it's something in >> > Fieldtrip that's causing this. >> > >> > My hope is that someone has encountered this problem before, and knows >> how >> > to solve it... >> > >> > Sincerely, >> > >> > Casper >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Fri Nov 22 16:40:28 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 16:40:28 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Casper, See attached the plots I get when running your script (on Windows/Linux Matlab 2011b/2012a). They seem quite OK to me, so I suspect the issue is in your Matlab installation and/or system (e.g. video drivers). One thing that could possibly help (though I would not understand why exactly) is to change the renderer, by trying out all three options for cfg.renderer = 'painters'/'zbuffer'/'opengl'. Or maybe you could try running another Matlab version? Sorry this is not more helpful, good luck figuring it out! Best, Eelke On 22 November 2013 13:36, Casper van Heck wrote: > Dear Eelke, > > I was busy with some other stuff, and just now revisited the analysis. Even > with a newer version of Fieldtrip, this is still happening, and I still do > not know why... > Have you had time to take a look at it? > > Sincerely, > > Casper > > > On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck > wrote: >> >> Dear Eelke, >> >> I've put up an exerpt of my code, with the data from a single subject >> (no.10, 9MB) in a separate folder here. >> It also includes a screenshot of what I see with when I run the code with >> this exact dataset, and a small program 'filehandler', which I've been to >> lazy to replace. >> >> Note that this specific subject only has about 60 seconds of data (and I'm >> still waiting for the student to tell me why). >> >> I'm hoping you'll get the same result as the screenshot, and you'll be >> able to tell me why... >> >> Best regards, >> >> Casper >> >> >> On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak >> wrote: >>> >>> Dear Casper, >>> >>> Could you maybe post a snippet online somewhere (e.g. dropbox) of data >>> corresponding to this plot (i.e. the output of ft_freqanalysis that >>> you input to ft_singleplotTFR, assuming that it's averaged over trials >>> and therefore small)? Then we can see whether this is reproducable on >>> our systems. >>> >>> Best, >>> Eelke >>> >>> On 16 September 2013 17:12, Casper van Heck >>> wrote: >>> > Dear Fieldtrippers, >>> > >>> > I've been doing some exploratory plotting of a dataset where several >>> > subjects were exposed to a continuous stimulus (CPM) over the course of >>> > three minutes. One of the things that was asked was a time-frequency >>> > plot, >>> > over those three minutes. While I'm not quite sure a TFR can be used on >>> > that >>> > scale without problems, I went ahead with it just to see what Fieldtrip >>> > would do. What I got, was this: >>> > http://tinypic.com/r/zx2tqs/5| >>> > And I have no idea what went wrong (note that this specific subject >>> > only got >>> > a 60s stimulus). Quality of the picture and the validity of the >>> > analysis >>> > aside, I have a severe problem with the axes, which seem to be all over >>> > the >>> > place. >>> > >>> > I simply read the data using ft_preprocessing (no filters or anything, >>> > since >>> > the student in charge already used a 10Hz high-pass and a 150Hz >>> > low-pass >>> > filter). >>> > The only field in 'cfg' is 'headerfile'. >>> > >>> > Next, I call ft_freqanalysis with: >>> > cfg.output = 'pow'; >>> > cfg.method = 'wavelet'; % default; Morlet wavelet >>> > cfg.taper = 'hanning'; >>> > cfg.tapsmofrq = 4; >>> > cfg.channel = 'Cz'; >>> > cfg.foi = [20:0.5:30]; >>> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; >>> > cfg.toi = 0:0.5:60; >>> > >>> > And finally, I end up with the monstrocity shown earlier. This problem >>> > only >>> > presents itself with Fieldtrip-related functions, the normal >>> > Matlab-plots >>> > work as well as they've ever done, so I'm thinking it's something in >>> > Fieldtrip that's causing this. >>> > >>> > My hope is that someone has encountered this problem before, and knows >>> > how >>> > to solve it... >>> > >>> > Sincerely, >>> > >>> > Casper >>> > >>> > >>> > _______________________________________________ >>> > fieldtrip mailing list >>> > fieldtrip at donders.ru.nl >>> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- A non-text attachment was scrubbed... Name: mytfr-linux-matlab2012a-64bit.png Type: image/png Size: 25742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mytfr-windows-matlab2011b-64bit.png Type: image/png Size: 34916 bytes Desc: not available URL: From trdavenp at cogsci.ucsd.edu Fri Nov 22 20:35:31 2013 From: trdavenp at cogsci.ucsd.edu (Tristan Davenport) Date: Fri, 22 Nov 2013 11:35:31 -0800 Subject: [FieldTrip] ft_artifact_threshold and the return of the "unit circle" error Message-ID: I'm trying to import and analyze some Neuromag 306 data, and I keep running into the following error message whenever I try to detect blink artifacts with the threshold method: *??? Error using ==> filter_with_correction at 44 Calculated filter coefficients have poles on or outside the unit circle and will not be stable. Try a higher cutoff frequency or a different type/order of filter.Error in ==> filter_with_correction at 44 error('Calculated filter coefficients have poles on or outside the unit circle and will not be stable. Try a higher cutoff frequency or a different type/order of filter.');Error in ==> ft_preproc_bandpassfilter at 148 filt = filter_with_correction(B,A,dat,dir);Error in ==> preproc at 299if strcmp(cfg.bpfilter, 'yes'), dat = ft_preproc_bandpassfilter(dat, fsample, cfg.bpfreq, cfg.bpfiltord, cfg.bpfilttype, cfg.bpfiltdir, cfg.bpinstabilityfix); endError in ==> ft_artifact_threshold at 148 dat = preproc(dat, channel, offset2time(cfg.trl(trlop,3), hdr.Fs, size(dat,2)), artfctdef); * Based on previous advice in these threads, I have tried changing the cutoff frequency, order, direction, and type of filtering of my data using cfg fields like bpfreq, bpfilttype, bpfiltdir, and bpinstabilityfix. Long story short, I've tried every logically possible combination of filter settings (including no filtering at all), and I get the same error regardless. Does anyone have some insight into this? Take care, Tristan Davenport UC San Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Mon Nov 25 17:16:41 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Mon, 25 Nov 2013 17:16:41 +0100 Subject: [FieldTrip] Error in ft_fetch_data (line 99) Message-ID: Dear Field Trip user. I sometimes experience an error in ft_fetch_data (line 99) usually with the last trial after epoching continuous Neuromag 306 channel FIF data into trials. I suspect that there might be something wrong with my trial definitions or the data, but I don't understand the error messages. I had to concatenate the continuous data and the trial definitions, because the raw data was split into two files during recording, however all the concatenated continuous data can be seen clearly by using the ft_databrowser and the trial definition onset times and event values also looks reasonable. I wonder what could be the problem, and if there could be a solution to avoid this occasional error? (The simple solution would of course be just to remove the occasional trials with error, but then to loose some trials). Thank you if you have any comments or suggestions. Greetings Niels. This is the error messages that shows up if I try to show the "problematic" trial in ft_databrowser: Error in ft_fetch_data (line 99) count(trlbeg:trlend) = count(trlbeg:trlend) + 1; Error in ft_databrowser>redraw_cb (line 1458) dat = ft_fetch_data(opt.orgdata, 'header', opt.hdr, 'begsample', begsample, 'endsample', endsample, 'chanindx', chanindx, 'allowoverlap', true); % ALLOWING OVERLAPPING TRIALS Error in ft_databrowser>keyboard_cb (line 1232) redraw_cb(h, eventdata); Error while evaluating uicontrol Callback This is the error messages that is shown when I try to run ft_artifact_zvalue on the trials: Warning: -clear > In utilities/private/warning_once at 116 In utilities/private/ft_preamble_init at 26 In ft_preamble at 54 In ft_artifact_zvalue at 110 searching for artifacts in 102 channels searching trials.Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Index exceeds matrix dimensions. Error in ft_fetch_data (line 99) count(trlbeg:trlend) = count(trlbeg:trlend) + 1; Error in ft_artifact_zvalue (line 262) dat{trlop} = ft_fetch_data(data, 'header', hdr, 'begsample', trl(trlop,1)-fltpadding, 'endsample', trl(trlop,2)+fltpadding, 'chanindx', sgnind, 'checkboundary', strcmp(cfg.continuous,'no Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Mon Nov 25 17:26:17 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Mon, 25 Nov 2013 17:26:17 +0100 Subject: [FieldTrip] Error in ft_fetch_data (line 99) In-Reply-To: References: Message-ID: PS: Apparently, ft_rejectvisual can succesfully process show the occasional trials that causes errors with ft_databrowser and ft_artifact_zvalue. FieldTrip discussion list writes: >Dear Field Trip user. > >I sometimes experience an error in ft_fetch_data (line 99) usually with the last trial after epoching continuous Neuromag 306 channel FIF data into trials. I suspect that there might be something wrong with my trial definitions or the data, but I don't understand the error messages. I had to concatenate the continuous data and the trial definitions, because the raw data was split into two files during recording, however all the concatenated continuous data can be seen clearly by using the >ft_databrowser and the trial definition onset times and event values also looks reasonable. > >I wonder what could be the problem, and if there could be a solution to avoid this occasional error? > >(The simple solution would of course be just to remove the occasional trials with error, but then to loose some trials). > >Thank you if you have any comments or suggestions. > >Greetings >Niels. > >This is the error messages that shows up if I try to show the "problematic" trial in ft_databrowser: > >Error in ft_fetch_data (line 99) > � � � � � count(trlbeg:trlend) = count(trlbeg:trlend) + 1; > >Error in ft_databrowser>redraw_cb (line 1458) > � dat = ft_fetch_data(opt.orgdata, 'header', opt.hdr, 'begsample', begsample, 'endsample', endsample, > � 'chanindx', chanindx, 'allowoverlap', true); % ALLOWING OVERLAPPING TRIALS > >Error in ft_databrowser>keyboard_cb (line 1232) > � � � redraw_cb(h, eventdata); > >Error while evaluating uicontrol Callback > >This is the error messages that is shown when I try to run ft_artifact_zvalue on the trials: > >Warning: -clear >> In utilities/private/warning_once at 116 > � In utilities/private/ft_preamble_init at 26 > � In ft_preamble at 54 > � In ft_artifact_zvalue at 110 >searching for artifacts in 102 channels >searching trials.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Index exceeds matrix dimensions. > >Error in ft_fetch_data (line 99) > � � � � � count(trlbeg:trlend) = count(trlbeg:trlend) + 1; > >Error in ft_artifact_zvalue (line 262) > � � � � � dat{trlop} = ft_fetch_data(data, � � � � � � � 'header', hdr, 'begsample', trl(trlop,1)-fltpadding, > � � � � � 'endsample', trl(trlop,2)+fltpadding, 'chanindx', sgnind, 'checkboundary', > � � � � � strcmp(cfg.continuous,'no > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayobimpe2004 at hotmail.com Tue Nov 26 01:49:51 2013 From: ayobimpe2004 at hotmail.com (Azeez Adebimpe) Date: Tue, 26 Nov 2013 01:49:51 +0100 Subject: [FieldTrip] trial definition Message-ID: Hello everyone,I have a continuous cnt eeg file. There is no event and I want to divide it into several epochs. please it is normal to use this:?cfg.trialdef.triallength = duration in seconds (can also be 1 or Inf) cfg.trialdef.ntrials = number of trials (can also be 1 or Inf)Please if there is other way to define the trial, please kindly let me know. Best regards, Azeez Adebimpe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-baptiste.versini at etu.univ-lyon1.fr Tue Nov 26 11:12:36 2013 From: jean-baptiste.versini at etu.univ-lyon1.fr (VERSINI JEAN-BAPTISTE p1207642) Date: Tue, 26 Nov 2013 10:12:36 +0000 Subject: [FieldTrip] RE : trial definition In-Reply-To: References: Message-ID: <5271B6068CD8D94DB82254228237928801790560@mbx2010-02.univ-lyon1.fr> Hello, I have no idea if what you're currently doing works but maybe you should consider making your own trial function : http://fieldtrip.fcdonders.nl/example/making_your_own_trialfun_for_conditional_trial_definition regards, JB ________________________________ De : fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] de la part de Azeez Adebimpe [ayobimpe2004 at hotmail.com] Date d'envoi : mardi 26 novembre 2013 01:49 À : fieldtrip at science.ru.nl Objet : [FieldTrip] trial definition Hello everyone, I have a continuous cnt eeg file. There is no event and I want to divide it into several epochs. please it is normal to use this:? cfg.trialdef.triallength = duration in seconds (can also be 1 or Inf) cfg.trialdef.ntrials = number of trials (can also be 1 or Inf) Please if there is other way to define the trial, please kindly let me know. Best regards, Azeez Adebimpe -------------- next part -------------- An HTML attachment was scrubbed... URL: From caspervanheck at gmail.com Tue Nov 26 12:25:11 2013 From: caspervanheck at gmail.com (Casper van Heck) Date: Tue, 26 Nov 2013 12:25:11 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Eelke, I've tried it with the painters, zbuffer, and opengl, using Matlab 2011a and 2013a (giving me the 'not yet supported'-error), with the same results. I think I'll try it at home, later, and if that fails, I'll get the ICT-people to reinstall the whole thing. Thanks! Casper On Fri, Nov 22, 2013 at 4:40 PM, Eelke Spaak wrote: > Dear Casper, > > See attached the plots I get when running your script (on > Windows/Linux Matlab 2011b/2012a). They seem quite OK to me, so I > suspect the issue is in your Matlab installation and/or system (e.g. > video drivers). > > One thing that could possibly help (though I would not understand why > exactly) is to change the renderer, by trying out all three options > for cfg.renderer = 'painters'/'zbuffer'/'opengl'. Or maybe you could > try running another Matlab version? > > Sorry this is not more helpful, good luck figuring it out! > > Best, > Eelke > > On 22 November 2013 13:36, Casper van Heck > wrote: > > Dear Eelke, > > > > I was busy with some other stuff, and just now revisited the analysis. > Even > > with a newer version of Fieldtrip, this is still happening, and I still > do > > not know why... > > Have you had time to take a look at it? > > > > Sincerely, > > > > Casper > > > > > > On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck < > caspervanheck at gmail.com> > > wrote: > >> > >> Dear Eelke, > >> > >> I've put up an exerpt of my code, with the data from a single subject > >> (no.10, 9MB) in a separate folder here. > >> It also includes a screenshot of what I see with when I run the code > with > >> this exact dataset, and a small program 'filehandler', which I've been > to > >> lazy to replace. > >> > >> Note that this specific subject only has about 60 seconds of data (and > I'm > >> still waiting for the student to tell me why). > >> > >> I'm hoping you'll get the same result as the screenshot, and you'll be > >> able to tell me why... > >> > >> Best regards, > >> > >> Casper > >> > >> > >> On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak > > >> wrote: > >>> > >>> Dear Casper, > >>> > >>> Could you maybe post a snippet online somewhere (e.g. dropbox) of data > >>> corresponding to this plot (i.e. the output of ft_freqanalysis that > >>> you input to ft_singleplotTFR, assuming that it's averaged over trials > >>> and therefore small)? Then we can see whether this is reproducable on > >>> our systems. > >>> > >>> Best, > >>> Eelke > >>> > >>> On 16 September 2013 17:12, Casper van Heck > >>> wrote: > >>> > Dear Fieldtrippers, > >>> > > >>> > I've been doing some exploratory plotting of a dataset where several > >>> > subjects were exposed to a continuous stimulus (CPM) over the course > of > >>> > three minutes. One of the things that was asked was a time-frequency > >>> > plot, > >>> > over those three minutes. While I'm not quite sure a TFR can be used > on > >>> > that > >>> > scale without problems, I went ahead with it just to see what > Fieldtrip > >>> > would do. What I got, was this: > >>> > http://tinypic.com/r/zx2tqs/5| > >>> > And I have no idea what went wrong (note that this specific subject > >>> > only got > >>> > a 60s stimulus). Quality of the picture and the validity of the > >>> > analysis > >>> > aside, I have a severe problem with the axes, which seem to be all > over > >>> > the > >>> > place. > >>> > > >>> > I simply read the data using ft_preprocessing (no filters or > anything, > >>> > since > >>> > the student in charge already used a 10Hz high-pass and a 150Hz > >>> > low-pass > >>> > filter). > >>> > The only field in 'cfg' is 'headerfile'. > >>> > > >>> > Next, I call ft_freqanalysis with: > >>> > cfg.output = 'pow'; > >>> > cfg.method = 'wavelet'; % default; Morlet wavelet > >>> > cfg.taper = 'hanning'; > >>> > cfg.tapsmofrq = 4; > >>> > cfg.channel = 'Cz'; > >>> > cfg.foi = [20:0.5:30]; > >>> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; > >>> > cfg.toi = 0:0.5:60; > >>> > > >>> > And finally, I end up with the monstrocity shown earlier. This > problem > >>> > only > >>> > presents itself with Fieldtrip-related functions, the normal > >>> > Matlab-plots > >>> > work as well as they've ever done, so I'm thinking it's something in > >>> > Fieldtrip that's causing this. > >>> > > >>> > My hope is that someone has encountered this problem before, and > knows > >>> > how > >>> > to solve it... > >>> > > >>> > Sincerely, > >>> > > >>> > Casper > >>> > > >>> > > >>> > _______________________________________________ > >>> > fieldtrip mailing list > >>> > fieldtrip at donders.ru.nl > >>> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >>> _______________________________________________ > >>> fieldtrip mailing list > >>> fieldtrip at donders.ru.nl > >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > >> > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bingshuo.li at student.uni-tuebingen.de Tue Nov 26 18:26:26 2013 From: bingshuo.li at student.uni-tuebingen.de (Bingshuo Li) Date: Tue, 26 Nov 2013 18:26:26 +0100 Subject: [FieldTrip] ICA in TMS-EEG Message-ID: Dear FieldTrip Community, I recently started to analyze some TMS-EEG datasets and I encountered some questions regarding to using ICA to remove eye movement/muscle artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to inquire the FT community for some hints or suggestions. Below are the details of my questions: //Description of Data Processing// - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance less than 5 kOhm - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per subject) - TMS contaminated data points were cut out symmetrically -18ms to +18ms relative to TMS onset. Cubic spline interpolation is used to fill in the cut. - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line noise - Visual inspection and rejection of trials with obvious unstable signal or channels. //ICA// - ICA algorithm: runica - Demeaned data for ICA training (baseline is defined as the entire epoch -1 to +1s) - Unmixing matrix applied to non-demeaned data for component removal /////QUESTIONS///// Please see the image below for a typical result of ICA from a subject with TMS applied at M1 (32 epochs for ICA training): https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. However, what about component 5, 12, 20, 28? Topology-wise, they seem to have a very anterior origin, but data in the time domain does not seem to correlate with component 1 and 2 very well (judging visually..) Q2: What can you say about components 7, 9, 13 and 18? Are these cranial muscle artifacts? Q3: Also, for components 42 and 54, given their high focality, are these more or less a indication of bad/unstable electrodes? - I guess maybe I am asking too many questions. I think my main problem here is that I do not know what can be a good procedure / rules in manually selecting ICA components for rejection? (I tried to look in the literature but I couldn't find any that can answer my questions). And sometime I have the feeling that my ICA results look like a mess and maybe there were something wrong with my pre-processing or even data collection? Thank you guys in advance for any input! I look forward to hearing from you! Regards, Bingshuo Li MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 26 19:30:06 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 26 Nov 2013 13:30:06 -0500 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: Message-ID: Hi Bingshuo, I'm not sure what your code for the ICA is, but it may be beneficial to have the topoplots lined up with the signal, as I find it easier to recognize EOG and ECG artifacts in the signal. The following tutorials explain ICA: http://fieldtrip.fcdonders.nl/example/use_independent_component_analysis_ica_to_remove_ecg_artifacts http://fieldtrip.fcdonders.nl/example/use_independent_component_analysis_ica_to_remove_eog_artifacts In the ECG tutorial, they give a line of code: cfg = []; cfg.channel = {comp.label{2:5} comp.label{15:18}}; % components to be plotted cfg.layout = 'CTF275.lay'; % specify the layout file that should be used for plotting ft_databrowser(cfg, comp) Which outputs the topoplot and the time course of the signal together in a component browser. As far as criteria for correction, our policy is to err on the conservative side; only rejecting EOG and ECG artifacts, even if we find other components that are clearly artifactual (such as are picking up line noise). Without seeing your script, I can't really think of anything offhand that you are doing wrong, but I'm also not very familiar with TMS so there may be someone else who could answer that part of the question better. Good luck, Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Tue, Nov 26, 2013 at 12:26 PM, Bingshuo Li < bingshuo.li at student.uni-tuebingen.de> wrote: > Dear FieldTrip Community, > > I recently started to analyze some TMS-EEG datasets and I encountered some > questions regarding to using ICA to remove eye movement/muscle artifacts in > our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to > inquire the FT community for some hints or suggestions. Below are the > details of my questions: > > //Description of Data Processing// > - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance > less than 5 kOhm > - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per > subject) > - TMS contaminated data points were cut out symmetrically -18ms to +18ms > relative to TMS onset. Cubic spline interpolation is used to fill in the > cut. > - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. > - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line > noise > - Visual inspection and rejection of trials with obvious unstable signal > or channels. > > //ICA// > - ICA algorithm: runica > - Demeaned data for ICA training (baseline is defined as the entire epoch > -1 to +1s) > - Unmixing matrix applied to non-demeaned data for component removal > > /////QUESTIONS///// > Please see the image below for a typical result of ICA from a subject with > TMS applied at M1 (32 epochs for ICA training): > https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png > > Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. > However, what about component 5, 12, 20, 28? Topology-wise, they seem to > have a very anterior origin, but data in the time domain does not seem to > correlate with component 1 and 2 very well (judging visually..) > > Q2: What can you say about components 7, 9, 13 and 18? Are these cranial > muscle artifacts? > > Q3: Also, for components 42 and 54, given their high focality, are these > more or less a indication of bad/unstable electrodes? > > - I guess maybe I am asking too many questions. I think my main problem > here is that I do not know what can be a good procedure / rules in manually > selecting ICA components for rejection? (I tried to look in the literature > but I couldn't find any that can answer my questions). And sometime I have > the feeling that my ICA results look like a mess and maybe there were > something wrong with my pre-processing or even data collection? > > Thank you guys in advance for any input! I look forward to hearing from > you! > > Regards, > > Bingshuo Li > MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.herring at fcdonders.ru.nl Wed Nov 27 09:28:56 2013 From: j.herring at fcdonders.ru.nl (Herring, J.D. (Jim)) Date: Wed, 27 Nov 2013 09:28:56 +0100 (CET) Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: Message-ID: <012d01ceeb4a$b6ff3950$24fdabf0$@herring@fcdonders.ru.nl> Dear Bingshuo, I agree with Max that it would be beneficial to see the timecourses as well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock average the time courses of the ICA components to the onset of the TMS pulse. That helps in identifying components that are related to the TMS pulse. Just from looking at the topographies I would say that component 7 is too posterior for being a cranial muscle artifact given that you are stimulating M1. Also, cranial muscle artifacts related to the TMS pulse usually last up to about 15ms after stimulation onset (see for example: http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.p ng?id=tutorial%3Atms-eeg ) unless you are actually referring to a decay artifact (http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tu torial%3Atms-eeg) , which can last up to one second. You said that you cut and interpolated up to 18ms after stimulation so you should not see any cranial muscle artifacts related to TMS. Too me component 7 looks more like a topography related to posterior alpha oscillations, however, to be sure we need to see the time courses. Component 13 and 18 might be neck muscle artifacts, however, without performing a timelock analysis of the ICA components and inspecting the time courses it is hard to tell whether these are due to the TMS-pulse. Component 42 and 54 could indeed just reflect two bad channels, at least they seem to contain some variance that cannot be explained by a combination of the other channels. Best, Jim From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Bingshuo Li Sent: dinsdag 26 november 2013 18:26 To: fieldtrip at science.ru.nl Subject: [FieldTrip] ICA in TMS-EEG Dear FieldTrip Community, I recently started to analyze some TMS-EEG datasets and I encountered some questions regarding to using ICA to remove eye movement/muscle artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to inquire the FT community for some hints or suggestions. Below are the details of my questions: //Description of Data Processing// - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance less than 5 kOhm - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per subject) - TMS contaminated data points were cut out symmetrically -18ms to +18ms relative to TMS onset. Cubic spline interpolation is used to fill in the cut. - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line noise - Visual inspection and rejection of trials with obvious unstable signal or channels. //ICA// - ICA algorithm: runica - Demeaned data for ICA training (baseline is defined as the entire epoch -1 to +1s) - Unmixing matrix applied to non-demeaned data for component removal /////QUESTIONS///// Please see the image below for a typical result of ICA from a subject with TMS applied at M1 (32 epochs for ICA training): https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. However, what about component 5, 12, 20, 28? Topology-wise, they seem to have a very anterior origin, but data in the time domain does not seem to correlate with component 1 and 2 very well (judging visually..) Q2: What can you say about components 7, 9, 13 and 18? Are these cranial muscle artifacts? Q3: Also, for components 42 and 54, given their high focality, are these more or less a indication of bad/unstable electrodes? - I guess maybe I am asking too many questions. I think my main problem here is that I do not know what can be a good procedure / rules in manually selecting ICA components for rejection? (I tried to look in the literature but I couldn't find any that can answer my questions). And sometime I have the feeling that my ICA results look like a mess and maybe there were something wrong with my pre-processing or even data collection? Thank you guys in advance for any input! I look forward to hearing from you! Regards, Bingshuo Li MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Wed Nov 27 14:59:16 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Wed, 27 Nov 2013 08:59:16 -0500 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> References: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Dear J.D., Max and Bingshuo, A brief comment: to be more confident about the correlative nature of an artifact being an artifact (a.k.a. unwanted interference) I always consider three things: topographies, time courses and spectra. The last one too, since it might inform about spectral components not evident at the bare eye from the time courses. I'm not familiar with artifacts in TMS, but in all cases experience helps, especially if you see the same pattern in many subjects, in other published studies, from colleagues' data or from independent evidence (e.g. concomitant electromiography recorded from the facial muscles, for muscular artifacts identification). HTH Cristiano On Wed, Nov 27, 2013 at 3:28 AM, Herring, J.D. (Jim) < j.herring at fcdonders.ru.nl> wrote: > Dear Bingshuo, > > > > I agree with Max that it would be beneficial to see the timecourses as > well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock > average the time courses of the ICA components to the onset of the TMS > pulse. That helps in identifying components that are related to the TMS > pulse. > > > > Just from looking at the topographies I would say that component 7 is too > posterior for being a cranial muscle artifact given that you are > stimulating M1. Also, cranial muscle artifacts related to the TMS pulse > usually last up to about 15ms after stimulation onset (see for example: > http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.png?id=tutorial%3Atms-eeg) unless you are actually referring to a decay artifact ( > http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tutorial%3Atms-eeg) > , which can last up to one second. You said that you cut and interpolated > up to 18ms after stimulation so you should not see any cranial muscle > artifacts related to TMS. > > > > Too me component 7 looks more like a topography related to posterior alpha > oscillations, however, to be sure we need to see the time courses. > Component 13 and 18 might be neck muscle artifacts, however, without > performing a timelock analysis of the ICA components and inspecting the > time courses it is hard to tell whether these are due to the TMS-pulse. > > > > Component 42 and 54 could indeed just reflect two bad channels, at least > they seem to contain some variance that cannot be explained by a > combination of the other channels. > > > > Best, > > > > Jim > > > > *From:* fieldtrip-bounces at science.ru.nl [mailto: > fieldtrip-bounces at science.ru.nl] *On Behalf Of *Bingshuo Li > *Sent:* dinsdag 26 november 2013 18:26 > *To:* fieldtrip at science.ru.nl > *Subject:* [FieldTrip] ICA in TMS-EEG > > > > Dear FieldTrip Community, > > I recently started to analyze some TMS-EEG datasets and I encountered some > questions regarding to using ICA to remove eye movement/muscle artifacts in > our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to > inquire the FT community for some hints or suggestions. Below are the > details of my questions: > > //Description of Data Processing// > > - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance > less than 5 kOhm > > - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per > subject) > > - TMS contaminated data points were cut out symmetrically -18ms to +18ms > relative to TMS onset. Cubic spline interpolation is used to fill in the > cut. > > - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. > - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line > noise > > - Visual inspection and rejection of trials with obvious unstable signal > or channels. > > //ICA// > > - ICA algorithm: runica > > - Demeaned data for ICA training (baseline is defined as the entire epoch > -1 to +1s) > > - Unmixing matrix applied to non-demeaned data for component removal > > /////QUESTIONS///// > > Please see the image below for a typical result of ICA from a subject with > TMS applied at M1 (32 epochs for ICA training): > https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png > > Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. > However, what about component 5, 12, 20, 28? Topology-wise, they seem to > have a very anterior origin, but data in the time domain does not seem to > correlate with component 1 and 2 very well (judging visually..) > > Q2: What can you say about components 7, 9, 13 and 18? Are these cranial > muscle artifacts? > > Q3: Also, for components 42 and 54, given their high focality, are these > more or less a indication of bad/unstable electrodes? > > - I guess maybe I am asking too many questions. I think my main problem > here is that I do not know what can be a good procedure / rules in manually > selecting ICA components for rejection? (I tried to look in the literature > but I couldn't find any that can answer my questions). And sometime I have > the feeling that my ICA results look like a mess and maybe there were > something wrong with my pre-processing or even data collection? > > Thank you guys in advance for any input! I look forward to hearing from > you! > > Regards, > > Bingshuo Li > > MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgrande at cbs.mpg.de Wed Nov 27 16:28:46 2013 From: fgrande at cbs.mpg.de (Federico Grande) Date: Wed, 27 Nov 2013 16:28:46 +0100 (CET) Subject: [FieldTrip] Channel_selection Message-ID: <1142014025.14097.1385566126242.JavaMail.root@zimbra> Hello everyone, In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. Any suggestion? Thank you very much!! All the best, Federico Grande From jm.horschig at donders.ru.nl Wed Nov 27 16:46:56 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Wed, 27 Nov 2013 16:46:56 +0100 Subject: [FieldTrip] Channel_selection In-Reply-To: <1142014025.14097.1385566126242.JavaMail.root@zimbra> References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> Message-ID: <529613F0.7030801@donders.ru.nl> Hi Frederico, I think the best solution is to not use fieldtrip but plain matlab function. This is a small example that might help you: >> allchans = {'Fz', 'Cz', 'CPz'}; >> badchans = {'Fz', 'Cz'}; >> idx = ismember(allchans, badchans) idx = 1 1 0 You can then use the idx variable and logical indexing to get the good channels: >> allchans(~idx) ans = 'CPz' And then use cfg.channel = allchans(~idx). Be aware that ismember is a tricky function, because it returns the indices of the first vector as the first return variable and the respective same for the second vector as the second return variable, so order does matter. Just give it a try and play a bit around with it and you'll see. Best, Jörn Federico Grande wrote: > Hello everyone, > > In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. > > Any suggestion? > > Thank you very much!! > > All the best, > > Federico Grande > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands From mcantor at umich.edu Wed Nov 27 17:13:07 2013 From: mcantor at umich.edu (Max Cantor) Date: Wed, 27 Nov 2013 11:13:07 -0500 Subject: [FieldTrip] Channel_selection In-Reply-To: <529613F0.7030801@donders.ru.nl> References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> <529613F0.7030801@donders.ru.nl> Message-ID: Here is how I do it: allchan = ft_read_header(dataset); (preprocess) allchan.label = [allchan.label; implicitref]; (after artifact rejection/ICA/etc.) badchan = ft_channelselection('gui', allchan.label); This gives me the channel labels for all channels, with the implicitref added back in (normally this is removed), then a gui which lets me remove bad channels manually after preprocessing/artifact rejection/ICA/etc. Hope this helps. Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl> wrote: > Hi Frederico, > > I think the best solution is to not use fieldtrip but plain matlab > function. This is a small example that might help you: > > >> allchans = {'Fz', 'Cz', 'CPz'}; > >> badchans = {'Fz', 'Cz'}; > >> idx = ismember(allchans, badchans) > > idx = > > 1 1 0 > > You can then use the idx variable and logical indexing to get the good > channels: > > >> allchans(~idx) > > ans = > > 'CPz' > > And then use cfg.channel = allchans(~idx). > > Be aware that ismember is a tricky function, because it returns the > indices of the first vector as the first return variable and the respective > same for the second vector as the second return variable, so order does > matter. Just give it a try and play a bit around with it and you'll see. > > Best, > Jörn > > > > Federico Grande wrote: > >> Hello everyone, >> >> In order to clean a little bit more my measurements, I have developed a >> method which detects bad channels, and now, once I have the labels of the >> bad channels, I want to give it to ft_preprocessing, but I don't know how. >> I've been looking on ft_channelselection, and it seems that there is an >> option , by using some like channel={'all','-channel to exclude'}. I have >> an array with the labels of this channels that I want to exclude, but I >> don't know why, it seems that I am not using it in the proper way. I have >> tried with cfg.channel= {'all','-badSelections'} (badSelections is my >> array), and it doesn't work, since after processing, still appear all the >> channels in the dat.label. >> >> Any suggestion? >> >> Thank you very much!! >> >> All the best, >> >> Federico Grande >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.roux at bcbl.eu Wed Nov 27 19:14:26 2013 From: f.roux at bcbl.eu (=?utf-8?B?RnLDqWTDqXJpYw==?= Roux) Date: Wed, 27 Nov 2013 19:14:26 +0100 (CET) Subject: [FieldTrip] MEG-Ph.D. Studentship in Glasgow In-Reply-To: Message-ID: <1590326653.92591.1385576066623.JavaMail.root@bcbl.eu> On behalf of Peter Uhlhaas: Dear colleagues, I would like to alert you to a fully funded 3 ½ year Ph.D. studentship which is available at the Centre for Cognitive Neuroimaging , University of Glasgow. The project will use MEG to examine sensory predictions in patients with schizophrenia and will start in October 2014. The Ph.D. student will be supervised by Prof. Joachim Gross and Dr. Peter Uhlhaas. Details of the project are attached. Further infos on the studentship can be found here: http://www.gla.ac.uk/colleges/mvls/graduateschool/researchopportunities/studentshipopportunities/medicalresearchcouncil/ Inquiries can be forwarded to either one of the supervisors. Best wishes, Peter Uhlhaas Dr. Peter J. Uhlhaas Reader Institute for Neuroscience and Psychology University of Glasgow 58 Hillhead Street Glasgow G12 8QB Telephone +44 (0)141 330 8730 -- Frédéric Roux -------------- next part -------------- A non-text attachment was scrubbed... Name: MRC_Studentship_MEG in Schizophrenia.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 14535 bytes Desc: not available URL: From mcgoiv0 at wfu.edu Wed Nov 27 19:58:47 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Wed, 27 Nov 2013 13:58:47 -0500 Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hello, I am trying to apply head motion correction to a continuous MEG recording with Ft_regressconfound. Bcs the output of the Ft_regressconfound function is in the trial format , technically, I can proceed with the head motion regression method on the continuous data by dividing the data into smaller segments; which I did. I have 120 sec of MEG data (SR=600 Hz) that were divided into 10, or 20, or 30 sec trials. I run ft_regressconfound on these trials. No matter what the trial length or the total number of trials are, I get out of memory message in Matlab. Matlab error message: ??? Error using==>mldivide Out of memory. Error in ==> ft_regressconfound at 213 beta = regr\dat; % B= X\Y The error appears in the part of the code where the linear equation is solved directly. I tried to only work with a subset of all trials (half for example) with no luck. I rum MatlabR2010a on Windows XP 32-bit with the following memory allocation in Matlab: Max possible array: 851 Mb Memory available for all array: 1703 Mb Memory used by Matlab: 850 Mb RAM: 3317 Mb Were anybody else able to run this motion regression algorithm in Matlab without out of memory? Is there anything I can do to avoid the problem? I can share the code if needed. Thanks in advance, Inna Inna McGowin On Mon, Nov 18, 2013 at 10:42 AM, Arjen Stolk wrote: > Hi Inna, > Ft_regressconfound will remove trial by trial variability of signal > amplitude or frequency power that can be explained by variability in head > position over those trials. The input, whether sensor or source level, > should contain a trial field (keep trials in the previous step - eg at > timelockanalysis). Also variance due to head position can only be reliably > estimated when the neural signal is consistent over trials (as with an > event related modulation or potential). I would not know how to segment a > resting state into trials (for further analysis, given that those analyses > typically involve connectivity measures over the resting period) but if you > an idea on how to do this, you could give ft_regressconfound a try. Note > that the output will also be in the trials format. Hope this has made its > use a bit more clear. Yours, arjen > > Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het > volgende: > > > > > Hello everybody, > > > > I would like to use the ft_regressconfound function to remove/reduce > the head motion in a continuous MEG data. > > It's a resting state data and no averaging can be applied. Is there a > way to apply the correction without using the > > > > ft_timelockanalysis(cfg, data) function? > > > > I understand that the ft_regressconfound function has limits and caveats > but I still would like to see the results of its correction. > > > > > > Another way to ask this question is: > > what is the format/structure of the second input (timelock) in the > > ft_regressconfound(cfg, timelock) function and how it can be created > without ft_timelockanalysis? > > > > > > Thanks, > > > > Inna > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Thu Nov 28 03:11:12 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Wed, 27 Nov 2013 21:11:12 -0500 Subject: [FieldTrip] Channel_selection In-Reply-To: References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> <529613F0.7030801@donders.ru.nl> Message-ID: Dear Federico il Grande Allow 'badchstr' to be a cellarray of strings like this: badchstr = {'label2' 'labe8' ... 'label199'}; Try this: chstr = {'all'}; for i=1:numel(badchstr) chstr(i+1) = cellstr(sprintf('-%s ',badchstr{i})); end cfg = []; cfg.channel = chstr; dataclean = ft_preprocessing(cfg,data); Best, Cristiano On Wed, Nov 27, 2013 at 11:13 AM, Max Cantor wrote: > Here is how I do it: > > allchan = ft_read_header(dataset); > > (preprocess) > > allchan.label = [allchan.label; implicitref]; > > (after artifact rejection/ICA/etc.) > > badchan = ft_channelselection('gui', allchan.label); > > This gives me the channel labels for all channels, with the implicitref > added back in (normally this is removed), then a gui which lets me remove > bad channels manually after preprocessing/artifact rejection/ICA/etc. > > Hope this helps. > > Max Cantor > Research Assistant > Computational Neurolinguistics Lab > University of Michigan > > > On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < > jm.horschig at donders.ru.nl> wrote: > >> Hi Frederico, >> >> I think the best solution is to not use fieldtrip but plain matlab >> function. This is a small example that might help you: >> >> >> allchans = {'Fz', 'Cz', 'CPz'}; >> >> badchans = {'Fz', 'Cz'}; >> >> idx = ismember(allchans, badchans) >> >> idx = >> >> 1 1 0 >> >> You can then use the idx variable and logical indexing to get the good >> channels: >> >> >> allchans(~idx) >> >> ans = >> >> 'CPz' >> >> And then use cfg.channel = allchans(~idx). >> >> Be aware that ismember is a tricky function, because it returns the >> indices of the first vector as the first return variable and the respective >> same for the second vector as the second return variable, so order does >> matter. Just give it a try and play a bit around with it and you'll see. >> >> Best, >> Jörn >> >> >> >> Federico Grande wrote: >> >>> Hello everyone, >>> >>> In order to clean a little bit more my measurements, I have developed a >>> method which detects bad channels, and now, once I have the labels of the >>> bad channels, I want to give it to ft_preprocessing, but I don't know how. >>> I've been looking on ft_channelselection, and it seems that there is an >>> option , by using some like channel={'all','-channel to exclude'}. I have >>> an array with the labels of this channels that I want to exclude, but I >>> don't know why, it seems that I am not using it in the proper way. I have >>> tried with cfg.channel= {'all','-badSelections'} (badSelections is my >>> array), and it doesn't work, since after processing, still appear all the >>> channels in the dat.label. >>> >>> Any suggestion? >>> >>> Thank you very much!! >>> >>> All the best, >>> >>> Federico Grande >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> -- >> Jörn M. Horschig >> PhD Student >> Donders Institute for Brain, Cognition and Behaviour >> Centre for Cognitive Neuroimaging >> Radboud University Nijmegen >> Neuronal Oscillations Group >> FieldTrip Development Team >> >> P.O. Box 9101 >> NL-6500 HB Nijmegen >> The Netherlands >> >> Contact: >> E-Mail: jm.horschig at donders.ru.nl >> Tel: +31-(0)24-36-68493 >> Web: http://www.ru.nl/donders >> >> Visiting address: >> Trigon, room 2.30 >> Kapittelweg 29 >> NL-6525 EN Nijmegen >> The Netherlands >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bingshuo.li at student.uni-tuebingen.de Thu Nov 28 09:16:16 2013 From: bingshuo.li at student.uni-tuebingen.de (Bingshuo Li) Date: Thu, 28 Nov 2013 09:16:16 +0100 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Dear Max, Jim and Cristiano, Thank you so much for sharing your experiences! I found your comments very helpful. I will certain try the things you suggested and see how the ICA works this time. In addition, given that I have EOG and ECG recorded (but with different references), maybe it will also be beneficial if I calculate the coherence between the ICA components and EOG and ECG signals. Furthermore, I think it will be very beneficial to the field if someone with rich experiences in applying ICA in TMS-EEG can write a paper on manual artifactual components recognition! ;) Regards, ----- Bingshuo Li (MSc. candidate), Neuroprosthetic Group, CIN, Uni Tübingen On Wed, Nov 27, 2013 at 2:59 PM, Cristiano Micheli wrote: > Dear J.D., Max and Bingshuo, > > A brief comment: to be more confident about the correlative nature of an > artifact being an artifact (a.k.a. unwanted interference) I always consider > three things: topographies, time courses and spectra. The last one too, > since it might inform about spectral components not evident at the bare eye > from the time courses. > I'm not familiar with artifacts in TMS, but in all cases experience helps, > especially if you see the same pattern in many subjects, in other published > studies, from colleagues' data or from independent evidence (e.g. > concomitant electromiography recorded from the facial muscles, for muscular > artifacts identification). > > HTH > Cristiano > > > > > > On Wed, Nov 27, 2013 at 3:28 AM, Herring, J.D. (Jim) < > j.herring at fcdonders.ru.nl> wrote: > >> Dear Bingshuo, >> >> >> >> I agree with Max that it would be beneficial to see the timecourses as >> well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock >> average the time courses of the ICA components to the onset of the TMS >> pulse. That helps in identifying components that are related to the TMS >> pulse. >> >> >> >> Just from looking at the topographies I would say that component 7 is too >> posterior for being a cranial muscle artifact given that you are >> stimulating M1. Also, cranial muscle artifacts related to the TMS pulse >> usually last up to about 15ms after stimulation onset (see for example: >> http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.png?id=tutorial%3Atms-eeg) unless you are actually referring to a decay artifact ( >> http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tutorial%3Atms-eeg) >> , which can last up to one second. You said that you cut and interpolated >> up to 18ms after stimulation so you should not see any cranial muscle >> artifacts related to TMS. >> >> >> >> Too me component 7 looks more like a topography related to posterior >> alpha oscillations, however, to be sure we need to see the time courses. >> Component 13 and 18 might be neck muscle artifacts, however, without >> performing a timelock analysis of the ICA components and inspecting the >> time courses it is hard to tell whether these are due to the TMS-pulse. >> >> >> >> Component 42 and 54 could indeed just reflect two bad channels, at least >> they seem to contain some variance that cannot be explained by a >> combination of the other channels. >> >> >> >> Best, >> >> >> >> Jim >> >> >> >> *From:* fieldtrip-bounces at science.ru.nl [mailto: >> fieldtrip-bounces at science.ru.nl] *On Behalf Of *Bingshuo Li >> *Sent:* dinsdag 26 november 2013 18:26 >> *To:* fieldtrip at science.ru.nl >> *Subject:* [FieldTrip] ICA in TMS-EEG >> >> >> >> Dear FieldTrip Community, >> >> I recently started to analyze some TMS-EEG datasets and I encountered >> some questions regarding to using ICA to remove eye movement/muscle >> artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I >> would like to inquire the FT community for some hints or suggestions. Below >> are the details of my questions: >> >> //Description of Data Processing// >> >> - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance >> less than 5 kOhm >> >> - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials >> per subject) >> >> - TMS contaminated data points were cut out symmetrically -18ms to +18ms >> relative to TMS onset. Cubic spline interpolation is used to fill in the >> cut. >> >> - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. >> - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line >> noise >> >> - Visual inspection and rejection of trials with obvious unstable signal >> or channels. >> >> //ICA// >> >> - ICA algorithm: runica >> >> - Demeaned data for ICA training (baseline is defined as the entire epoch >> -1 to +1s) >> >> - Unmixing matrix applied to non-demeaned data for component removal >> >> /////QUESTIONS///// >> >> Please see the image below for a typical result of ICA from a subject >> with TMS applied at M1 (32 epochs for ICA training): >> https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png >> >> Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. >> However, what about component 5, 12, 20, 28? Topology-wise, they seem to >> have a very anterior origin, but data in the time domain does not seem to >> correlate with component 1 and 2 very well (judging visually..) >> >> Q2: What can you say about components 7, 9, 13 and 18? Are these cranial >> muscle artifacts? >> >> Q3: Also, for components 42 and 54, given their high focality, are these >> more or less a indication of bad/unstable electrodes? >> >> - I guess maybe I am asking too many questions. I think my main problem >> here is that I do not know what can be a good procedure / rules in manually >> selecting ICA components for rejection? (I tried to look in the literature >> but I couldn't find any that can answer my questions). And sometime I have >> the feeling that my ICA results look like a mess and maybe there were >> something wrong with my pre-processing or even data collection? >> >> Thank you guys in advance for any input! I look forward to hearing from >> you! >> >> Regards, >> >> Bingshuo Li >> >> MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgrande at cbs.mpg.de Thu Nov 28 09:49:21 2013 From: fgrande at cbs.mpg.de (Federico Grande) Date: Thu, 28 Nov 2013 09:49:21 +0100 (CET) Subject: [FieldTrip] Channel_selection In-Reply-To: Message-ID: <875544209.1015.1385628561634.JavaMail.root@zimbra> Thank you all! All the best, Federico ----- Original Message ----- From: "Cristiano Micheli" To: "FieldTrip discussion list" Sent: Thursday, November 28, 2013 3:11:12 AM Subject: Re: [FieldTrip] Channel_selection Dear Federico il Grande Allow 'badchstr' to be a cellarray of strings like this: badchstr = {'label2' 'labe8' ... 'label199'}; Try this: chstr = { 'all' }; for i=1:numel(badchstr) chstr(i+1) = cellstr(sprintf( '-%s ' ,badchstr{i})); end cfg = []; cfg.channel = chstr; dataclean = ft_preprocessing(cfg,data); Best, Cristiano On Wed, Nov 27, 2013 at 11:13 AM, Max Cantor < mcantor at umich.edu > wrote: Here is how I do it: allchan = ft_read_header(dataset); (preprocess) allchan.label = [allchan.label; implicitref]; (after artifact rejection/ICA/etc.) badchan = ft_channelselection('gui', allchan.label); This gives me the channel labels for all channels, with the implicitref added back in (normally this is removed), then a gui which lets me remove bad channels manually after preprocessing/artifact rejection/ICA/etc. Hope this helps. Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl > wrote: Hi Frederico, I think the best solution is to not use fieldtrip but plain matlab function. This is a small example that might help you: >> allchans = {'Fz', 'Cz', 'CPz'}; >> badchans = {'Fz', 'Cz'}; >> idx = ismember(allchans, badchans) idx = 1 1 0 You can then use the idx variable and logical indexing to get the good channels: >> allchans(~idx) ans = 'CPz' And then use cfg.channel = allchans(~idx). Be aware that ismember is a tricky function, because it returns the indices of the first vector as the first return variable and the respective same for the second vector as the second return variable, so order does matter. Just give it a try and play a bit around with it and you'll see. Best, Jörn Federico Grande wrote: Hello everyone, In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. Any suggestion? Thank you very much!! All the best, Federico Grande ______________________________ _________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands ______________________________ _________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Thu Nov 28 11:22:04 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 28 Nov 2013 11:22:04 +0100 Subject: [FieldTrip] LCMV giving conflicting results vs SAM and DICS In-Reply-To: References: <6D713918-6272-4E96-8CDF-0ECE2B95DE5A@ucdenver.edu> Message-ID: Hi Haris, Sorry for the slow reply, I had other stuff to do for a while. It seems that you have indeed stumbled on a bug, unfortunately. Let's move the discussion over to bugzilla: http://bugzilla.fcdonders.nl/show_bug.cgi?id=2395 Feel free to contribute anything there if you like (you can create an account if you don't have one yet). Hopefully we will be able to fix this soon. Best, Eelke On 29 October 2013 00:02, Charidimos Tzagarakis wrote: > Hi Eelke, > I have now run a test which I think does what you describe. > cfg.keeptrials='yes' for the calls to ft_timelockanalysis and > ft_sourcenalysis that generate the filter. > cfg.keeptrials='no' for all the other calls to these 2 functions (those that > generate the 2 conditions to be compared). > The result is still the same (ie not what I would call the 'correct' one, > but rather what seems to be based on an evoked response covariance matrix). > I should stress again that how I set keeptrials in ft_timelockanalysis is > also how I set it for the "matched" call to ft_sourceanalysis (It didn't > seem to me that this matters anyway as unless cfg.rawtrial='yes', > ft_sourceanalysis handles both cases so that what is used further down is > the same but I may be wrong in this) . > Best, > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 28 October 2013 05:26, Eelke Spaak wrote: >> >> Hi Charidimos, >> >> If I understand you correctly, you specified cfg.keeptrials = 'no' in >> the calls to ft_timelockanalysis prior to the *first* call of >> ft_sourceanalysis, right? Could you try what happens when you specify >> it in ft_timelockanalysis prior to the second call to >> ft_sourceanalysis (so the step where the precomputed filter is >> applied)? >> >> Thanks, >> Eelke >> >> On 25 October 2013 01:06, Charidimos Tzagarakis wrote: >> > Hi Eelke, >> > Thank you for looking into this! >> > The piece of code I commented out is indeed [790:836] (changing line 784 >> > accordingly or alternatively adding a copy of 785-789 after 790). >> > I did try running ft_timelockanalysis with keeptrials='no' for all 3 >> > calls >> > and that resulted in the same behaviour as before for LCMV (ie not the >> > "correct" one). I also tried it setting keeptrials='no' in >> > ft_sourceanalysis at the same time (ie keeptrials='no' for both >> > ft_timelockanalysis and ft_sourceanalysis) which had the same outcome (I >> > actually had run these tests before posting but wanted to 2ble check). >> > I may however be confused here because there are some other possible >> > combinations with keeptrials since for each subject there is a total of >> > 6 >> > calls to functions that accept it as an input and the filter is >> > estimated >> > with only 2 of them. >> > Do let me know if there is another combination I should run and I will >> > do >> > that. >> > Best, >> > Haris >> > >> > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> > University of Minnesota Dept of Neuroscience and Brain Sciences Center >> > >> > >> > On 24 October 2013 03:08, Eelke Spaak wrote: >> >> >> >> Hi Charidimos, >> >> >> >> Thanks for your elaborate e-mail. We discussed this issue in >> >> yesterday's FieldTrip meeting. It is very reasonable that you expect >> >> the three methods to produce the same results, and the code/interface >> >> indeed suggests that this would be the case. In other words, we need >> >> to clean up this part of the code to produce consistent results; >> >> however, this might take a while. >> >> >> >> We believe the discrepancy is caused by the fact that you compute the >> >> covariance while specifying cfg.keeptrials = 'yes', which is >> >> unnecessary while computing the filter. This results in a covariance >> >> matrix with dimensions trial X channel X channel, which then is >> >> subsequently averaged over trials during ft_sourceanalysis. Likely the >> >> filter is still in fact computed on the averaged covariance, as it >> >> should be. However, the subsequent projection of data through the >> >> filter will not first average the covariance, and will in essence only >> >> project the first trial through the filter. (This is because the dip{} >> >> fields will be struct arrays of dimension nTrial X 1, and in an >> >> assignment a(1).b = 2; a(2).b = 3; x = a; then x will be 2, so >> >> everything but the first element of a struct array is ignored in an >> >> assignment statement.) >> >> >> >> Could you try to compute the covariance with cfg.keeptrials = 'no' and >> >> then run LCMV again? This will still compute the covariance on the raw >> >> traces, not on the average. If our hunch is right, you should get the >> >> correct results then. >> >> >> >> As said, this is indeed messy and unclear, our apologies for that. >> >> >> >> Finally, could you tell us what part of the code you commented out to >> >> make the results consistent? We suspect it will be between lines 790 >> >> and 835, but it would be helpful to know for sure. >> >> >> >> Best, >> >> Eelke >> >> >> >> >> >> On 23 October 2013 21:43, Charidimos Tzagarakis >> >> wrote: >> >> > Hi Don, >> >> > Thanks for your reply. I do agree that some of these beamformers >> >> > are probably better suited than others to study beta >> >> > desynchronisation, >> >> > or >> >> > generally questions in the frequency domain. I in fact started from >> >> > DICS. >> >> > The reason I looked at LCMV and SAM is to be sure that I get >> >> > consistent >> >> > results (and also because my experiment can also address some >> >> > additional >> >> > time domain questions, so I wanted to see what happens when my data >> >> > goes >> >> > from one to the other). I therefore tried to set them up so I that >> >> > the >> >> > results from all 3 are similar. So you are correct in pointing out >> >> > that >> >> > my >> >> > question is why SAM and LCMV produce different results. Based on >> >> > their >> >> > description within the fieldtrip website and mailing list (if I have >> >> > interpreted these correctly) they should be treating the covariance >> >> > matrix >> >> > in the same way (to get a true evoked response covariance matrix you >> >> > would >> >> > normally need the extra call to ft_timelockanalysis that I show at >> >> > the >> >> > last >> >> > piece of code in my post). Also , if the covariance matrix is indeed >> >> > the >> >> > issue, it seems that the change in how it is treated in the >> >> > ft_sourceanalysis code (based on the "hack" I described) is unique to >> >> > LCMV >> >> > (none of the other beamformer options share that piece of code) and >> >> > is >> >> > active only when LCMV is given a precomputed filter which is (I >> >> > think) >> >> > unusual. >> >> > Hence my question! >> >> > Best, >> >> > Haris >> >> > >> >> > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> > University of Minnesota Dept of Neuroscience and Brain Sciences >> >> > Center >> >> > >> >> > >> >> > >> >> > On 23 October 2013 13:31, Rojas, Don wrote: >> >> >> >> >> >> Haris, >> >> >> >> >> >> Sorry - In my last post, I mistakenly put DICS and the Fieldtrip >> >> >> implementation of SAM into the same frequency domain category. In >> >> >> Fieldtrip, >> >> >> SAM is a time-domain technique and is not the same as the >> >> >> implementation of >> >> >> SAM that has been used in the published literature for beta ERD. So, >> >> >> are you >> >> >> then wondering why the two time-domain approaches produce differing >> >> >> results? >> >> >> That probably does depend on how the covariance matrix is >> >> >> calculated. >> >> >> Although I still think it is a bad idea to use a time-domain >> >> >> beamformer >> >> >> on >> >> >> motor beta ERD/ERS. >> >> >> >> >> >> Best, >> >> >> >> >> >> Don >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> fieldtrip mailing list >> >> >> fieldtrip at donders.ru.nl >> >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > fieldtrip mailing list >> >> > fieldtrip at donders.ru.nl >> >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From a.stolk at fcdonders.ru.nl Thu Nov 28 18:23:16 2013 From: a.stolk at fcdonders.ru.nl (Stolk, A. (Arjen)) Date: Thu, 28 Nov 2013 18:23:16 +0100 (CET) Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: Message-ID: <2046766750.4089031.1385659396420.JavaMail.root@sculptor.zimbra.ru.nl> Hi Inna, Are you using the same design matrix as on the wiki page? That one covers the primary head translations and rotations, but also their derivatives. You could try using the primary measures only (3 translastions, and 3 rotations of the circumcenter, totaling 6 + 1 constant regressors). It is also mentionworthy that there should be a balance between the number of regressors and the number of observations (i.e. trials). I believe on the respective wiki page on head movement regression it states that the ratio is recommended to be not larger than 1:10 (regressors:trials), accompanied with a reference. Accordingly, I'd suggest to use those 7 regressors, and your data (120s resting state) split in segments of 1 or 2 seconds, totaling 60 or 120 trials. These specifications might hopefully also allow working around your memory issue. Second, it may be worth mentioning what you would like to do with the data post-movement-regression. Namely, the movement compensation will remove contributions from head movement to the signal. But this requires that signal to behave consistently over trials, which does not seem the case with the signal in your resting study? That is, with an ERP study, the signal fluctuations appear consistent over trials, with amplitudes being modulated by head movement (i.e. sensor-source distance, see our neuroimage paper - 2013) in a predictable fashion. So if you're planning on doing frequency analysis, or maybe connectivity analysis, after head movement compensation, I'd recommend reversing that order. The rule of thumb is to use ft_regressconfound just prior to ft_xxxstatistics, removing otherwise unexplained variance (over trials) due to head movement, benefitting your statistical assessments. Hope these suggestions may help you with further analyses. I'm not familiar with anyone implementing this method to resting state analyses, but maybe someone else has some first-hand experience here. Furthermore, too late for your current dataset, but for a next one I'd recommend using the online head position monitoring/respositioning tool that we have developed for CTF systems (a neuromag version is approaching the final stage). This tool is routinely used in our lab to monitor and reduce head movment throughout recording (after which ft_regressconfound is being used to deal with the trial-by-trial crumbles). Yours, Arjen -------------- next part -------------- An HTML attachment was scrubbed... URL: From faranak.farzan at gmail.com Thu Nov 28 22:46:17 2013 From: faranak.farzan at gmail.com (Faranak Farzan) Date: Thu, 28 Nov 2013 16:46:17 -0500 Subject: [FieldTrip] Question regarding cluster-based permutation test Message-ID: Hi There, Hope this finds you well. We have a question in regards to 4 Dimensional cluster-based analysis meaning Data = Time X Freq X Channel X Subjects. Does fieldtrip allow us to produce clusters on a 3D matrix (TIME X FREQ X CHANNEL) while shuffling between/within subjects/groups? Or one should go about doing Time and Freq permutation separately (2D clusters at one specific frequency (or time))? Many thanks in advance, Regards, Faranak -------------- next part -------------- An HTML attachment was scrubbed... URL: From politzerahless at gmail.com Fri Nov 29 12:14:26 2013 From: politzerahless at gmail.com (Stephen Politzer-Ahles) Date: Fri, 29 Nov 2013 15:14:26 +0400 Subject: [FieldTrip] Question regarding cluster-based permutation test Message-ID: Hello Faranak, If you're doing a within-subjects design, then testing channels*time*freq on grand average data should be possible; see http://fieldtrip.fcdonders.nl/tutorial/cluster_permutation_freq#within_subjects_experiments . Best, Steve Stephen Politzer-Ahles New York University, Abu Dhabi Neuroscience of Language Lab http://www.nyu.edu/projects/politzer-ahles/ > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Nov 2013 16:46:17 -0500 > From: Faranak Farzan > To: fieldtrip at science.ru.nl > Subject: [FieldTrip] Question regarding cluster-based permutation test > Message-ID: > < CAEq_seaWYL87ZjXa0OX20xO1BqkGXHxODQrAVtbFsVg-6PuvHA at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi There, > > Hope this finds you well. We have a question in regards to 4 Dimensional > cluster-based analysis meaning Data = Time X Freq X Channel X Subjects. > Does fieldtrip allow us to produce clusters on a 3D matrix (TIME X FREQ X > CHANNEL) while shuffling between/within subjects/groups? Or one should go > about doing Time and Freq permutation separately (2D clusters at one > specific frequency (or time))? > > Many thanks in advance, > > Regards, > > Faranak > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131128/e67e370e/attachment-0001.html > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 36, Issue 52 > ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbirot at gmail.com Fri Nov 29 13:15:16 2013 From: gbirot at gmail.com (Gwenael Birot) Date: Fri, 29 Nov 2013 13:15:16 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables Message-ID: Dear all, I am trying to use the simbio package available in fieldtrip in order to compute the FEM headmodel. My OS is windows 7 64bits. When executing ft_headmodel_simbio I have got the following error: Error using sb_calc_stiff (line 89) Error executing mex-file. Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables are required. I installed these packages but I still have the error. It looks like there is several versions of these packages. Do I need one in particular or does any version is supposed to work? Thanks a lot, Gwenael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jm.horschig at donders.ru.nl Fri Nov 29 14:03:09 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Fri, 29 Nov 2013 14:03:09 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables In-Reply-To: References: Message-ID: <5298908D.2000005@donders.ru.nl> Hi Gwenael, I am not sure how much you know about mex-files, so this might go a bit over the top. The error you are describing probably stems from the fact that there are additional dependencies to other files on the mexed-version. We encountered similar things in the past with other FieldTrip functions, and found that the 2008 compiler actually should be compatible with any Windows version. Maybe the one who compiled the simbio toolbox did something other funky? Anyway, long story short, since the simbio toolbox is an external toolbox, we as the FieldTrip team do not maintain it. I don't know what you precisely need to install. You can use http://dependencywalker.com/ to find dependencies of the respective mexw64 file and try to find the respective packages containing these files. Just to assure you, when I try to execute the mex-file on Windows, I also get that error. On Linux it works fine though. I will bring this up in the next FieldTrip meeting and we will discuss this. We'll let you know about a solution. You could also go ahead and contact the Simbio guys directly (and share whatever the solution is with us, please) Best, Jörn Gwenael Birot wrote: > Dear all, > > I am trying to use the simbio package available in fieldtrip in order > to compute the FEM headmodel. My OS is windows 7 64bits. When > executing ft_headmodel_simbio I have got the following error: > > Error using sb_calc_stiff (line 89) > Error executing mex-file. Microsoft Visual C++ 2008 Redistributables > and Intel Visual Fortran Redistributables are required. > > I installed these packages but I still have the error. It looks like > there is several versions of these packages. Do I need one in > particular or does any version is supposed to work? > > Thanks a lot, > Gwenael > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands From jochem.rieger at uni-oldenburg.de Fri Nov 29 14:11:36 2013 From: jochem.rieger at uni-oldenburg.de (Jochem Rieger) Date: Fri, 29 Nov 2013 14:11:36 +0100 Subject: [FieldTrip] Post-doc with focus on statistical learning for analysis of speech coding in the human brain. Message-ID: <52989288.8090802@uni-oldenburg.de> The Department of Applied Neurocognitive Psychology at Oldenburg University, Germany, offers a Post-doctoral position (salary level E13 TVL, 3 years) with a focus on signal processing / statistical learning for analysis of speech coding in the human brain. The position is linked to the collaborative research center "The Active Auditory System" SFB-TR 31. The research center aims to characterize and model mechanism of auditory object formation and scene analysis by combining psychophysical, neurophysiological, and quantitative modelling. It complements the Excellence Cluster "Hearing 4 All" which was recently awarded to the University of Oldenburg. The combined effort of these centers will establish a strong link between neurophysiological models of auditory object representation and subjective perception. The post-doctoral position is situated in a project that applies statistical learning methods to human intracranial recordings (ECoG) and fMRI to derive and test quantitative statistical models of speech coding in the human brain. The experiments are performed in a highly interdisciplinary lab environment and in close collaboration with the University of California Berkeley and Stanford University. The quantitative nature of the research project will require highly motivated candidates with strong quantitative and experimental skills. Successful candidates will perform cutting edge research and should have a background in one or more of the following fields: signal processing, statistical learning, brain-machine-interfacing, non-invasive or invasive human neurophysiology of the auditory system. Applicants must have an academic university degree (Master or equivalent) and a PhD (or equivalent). Successful candidates will work in an interdisciplinary network with opportunities for international exchange. The post-doctoral position is initially limited to three years, with an option for extension, and can be split. Applications should include your CV, a list of most recent publications, two recommendation letters, and a research statement (max. 3 pages). The University of Oldenburg is an equal opportunity employer. The University of Oldenburg is dedicated to increasing the percentage of women in science. Therefore, equally qualified female candidates will be given preference. Applicants with disabilities will be preferentially considered in case of equal qualification. Please send inquiries and electronic applications per email (preferred) to Professor Dr. Jochem Rieger: Jochem.rieger(at)uni-oldenburg.de or paper applications per regular mail to: Margrit Jung Dept. of Applied Neurocognitive Psychology Institute of Psychology Oldenburg University 26111 Oldenburg Germany Application deadline is December 16th, 2013. -- Prof. Dr. rer. nat. Jochem Rieger Director, Institute of Psychology Head of Applied Neurocognitive | Knight Lab Psychology | Helen Wills Neuroscience Institute Faculty VI | University of California Carl-von-Ossietzky University | 132 Barker Hall 26111 Oldenburg | Berkeley, CA 94720-3192 Germany | USA Phone: +49(0)4417984533 Fax: +49(0)4417983865 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbirot at gmail.com Fri Nov 29 16:27:05 2013 From: gbirot at gmail.com (Gwenael Birot) Date: Fri, 29 Nov 2013 16:27:05 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables In-Reply-To: <5298908D.2000005@donders.ru.nl> References: <5298908D.2000005@donders.ru.nl> Message-ID: Dear Jörn, Thank you for your answer. Problem has been randomly solved by rebooting my computer. I should have know that Windows always needs to be restarted... Best, Gwenael 2013/11/29 "Jörn M. Horschig" > Hi Gwenael, > > I am not sure how much you know about mex-files, so this might go a bit > over the top. The error you are describing probably stems from the fact > that there are additional dependencies to other files on the mexed-version. > We encountered similar things in the past with other FieldTrip functions, > and found that the 2008 compiler actually should be compatible with any > Windows version. Maybe the one who compiled the simbio toolbox did > something other funky? Anyway, long story short, since the simbio toolbox > is an external toolbox, we as the FieldTrip team do not maintain it. I > don't know what you precisely need to install. You can use > http://dependencywalker.com/ to find dependencies of the respective > mexw64 file and try to find the respective packages containing these files. > Just to assure you, when I try to execute the mex-file on Windows, I also > get that error. On Linux it works fine though. I will bring this up in the > next FieldTrip meeting and we will discuss this. We'll let you know about a > solution. You could also go ahead and contact the Simbio guys directly (and > share whatever the solution is with us, please) > > Best, > Jörn > > > Gwenael Birot wrote: > >> Dear all, >> >> I am trying to use the simbio package available in fieldtrip in order to >> compute the FEM headmodel. My OS is windows 7 64bits. When executing >> ft_headmodel_simbio I have got the following error: >> >> Error using sb_calc_stiff (line 89) >> Error executing mex-file. Microsoft Visual C++ 2008 Redistributables and >> Intel Visual Fortran Redistributables are required. >> >> I installed these packages but I still have the error. It looks like >> there is several versions of these packages. Do I need one in particular or >> does any version is supposed to work? >> >> Thanks a lot, >> Gwenael >> >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Fri Nov 1 10:00:08 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 1 Nov 2013 10:00:08 +0100 Subject: [FieldTrip] new functionality for inverse modelling Message-ID: <444DEF5C-40D5-4143-9ED6-1B3DBCBD113A@donders.ru.nl> Dear FT-community, We are happy to announce that we just added some now functionality to the toolbox. Thanks to generous code contributions by Guido Nolte and Marlene Boenstrup from UKE Hamburg it is now possible to specify eloreta as a method in ft_sourceanalysis. It should work both on frequency and time domain data. Please feel free to try it out, and be generous with feedback/comments etc. Happy computing, also on behalf of Guido and Marlene, Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.vanlier at bsse.ethz.ch Fri Nov 1 12:33:02 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 1 Nov 2013 11:33:02 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: Hi Eric, Thanks for the answer. I really just dont see it... Where does the permutation distribution of the max cluster stat come from if you don't do a permutation test? But you don't actually need that distribution just the statistic?? how do you know then where your max stat (and the other clusterstats) is compared to the critical value at alpha? lets say your max clusterstat = 10 P(max(clusterstat) _> cv) = 0.05 so the probability that we see 10 or higher is 5% if h0 is in fact true. we actually are seeing 10 and thus (falsely) reject h0. so that always happens when h0 is true - you always reject the max cluster when h0 is true? doesn't make sense :( Thanks, Ben From e.maris at psych.ru.nl Fri Nov 1 22:40:10 2013 From: e.maris at psych.ru.nl (Eric Maris) Date: Fri, 1 Nov 2013 22:40:10 +0100 (CET) Subject: [FieldTrip] repeated measures ANOVA (statfun_depsamplesF): dfdenom problems In-Reply-To: <008D1219-3AC8-4011-985E-7396B0A9D64C@uos.de> References: <008D1219-3AC8-4011-985E-7396B0A9D64C@uos.de> Message-ID: <04ba01ced74a$efce27a0$cf6a76e0$@maris@psych.ru.nl> Dear Tim, > We have recently run into problems using the implementation of a > repeated measures ANOVA in statfun_depsamplesF.m. In our experiment, we > have recorded data of 16 subjects, and the factor of the repeated- > measures ANOVA has 37 levels (admittedly quite a few but that's just > how it is). > > Now if I am not mistaken, then for a repeated measures ANOVA, the > degrees of freedom in above case should be: df1 = 36 and df2 = 540 > (this is in line with the results of SPSS, too). However, the > statfun_depsamplesF.m function seems to compute dfdenom as nunits - > ncontrasts (nunits is the number of subjects, and ncontrasts is > nlevels-1). This of course leads to a different value as compared to > SPSS and what I found in the literature, in which dfdenom is computed > as (K-1)*(n-1), so in the current case as (nunits-1)*ncontrasts. > > For a one-factor repeated measures ANOVA, I could so far not find a > principled reason why the number of levels should not exceed the number > of subjects (which is the error message we get). In fact, SPSS works > just fine in above scenario. Could someone please explain the logic > behind the dfdenom computation in fieldtrip? Could it be that there is > an error in how the degrees of freedom are computed, or am I missing > something obvious here? For a MANOVA, the story would be different of > course. Here, you suggest the answer yourself: in Fieldtrip, we (I) have implemented the MANOVA dependent samples F-test, which requires more units than repeated measures. However, within the permutation framework, nothing prevents you from using the mixed F-statistic that you want to use (probably because it can deal with the situation of less units than repeated measures). You can write your own statfun, e.g. statfun_depsamplesFmixedmodel, and call this function in Fieldtrip's higher level statistics functions. Good to know, the false alarm rate control of your p-value-based inference does not depend on the sphericity assumption behind the use of the mixed model dependent samples F-test in a parametric context. Best, Eric Maris > > I should add that we are currently interfacing fieldtrip from eeglab > and get above error only if we choose the nonparametric fieldtrip > statistics (with cluster correction), but the parametric tests > implemented in eeglab work just fine. > > > Thank you very much for your help, I am looking forward to your > responses Tim > > > From pgoodin at swin.edu.au Sat Nov 2 07:15:27 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Sat, 2 Nov 2013 06:15:27 +0000 Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files In-Reply-To: References: Message-ID: Hi Neils, I use the ft_preprocessing function to load both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs. I haven't had a problem with dropped triggers / incorrect trial lengths etc. Please find the code I use below (and excuse any clunkiness): As for your second question re: cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. Hope the above (and below) helps and happy MEGing, Peter. %% %Read data into matlab cfg = []; cfg.dataset = megdata1; %first fif file cfg.channel = 'MEG'; d1 = ft_preprocessing(cfg); cfg = []; cfg.dataset = megdata2; %second fif file cfg.channel = 'MEG'; d2 = ft_preprocessing(cfg); %% %concatenate data dfull = d1; dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly. dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); dfull.sampleinfo = [1 length(dfull.trial{1,1})]; for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR. i = i + 1; end __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [aestnth at hum.au.dk] Sent: Friday, 1 November 2013 3:16 AM To: fieldtrip at science.ru.nl Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files Dear FieldTrip community. Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. ( http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? I'm looking forward to hear any comments, suggestions or solutions. Greetings Niels. Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital Denmark E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From russgport at gmail.com Sat Nov 2 23:19:41 2013 From: russgport at gmail.com (Russell G Port) Date: Sat, 2 Nov 2013 17:19:41 -0500 Subject: [FieldTrip] volume normalizing to mni template from ctf space mri Message-ID: Hi All, I just wanted to confirm this, because although I seen hints about this on the emails and websites that fieldtrip kindly archives; I worry. If I have a CTF coordinate system single subject MRI, and I want to normalize that onto the AVG152 brain in MNI space for example, ft_volumenormalization should handle this. What I mean by this is that I do not have to reslice/realign my image first to MNI space and then normalize... am I correct or misled? Best, Russ -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at psych.ru.nl Sun Nov 3 11:41:22 2013 From: e.maris at psych.ru.nl (Eric Maris) Date: Sun, 3 Nov 2013 11:41:22 +0100 (CET) Subject: [FieldTrip] maximum statistic in cluster correction In-Reply-To: References: Message-ID: <055001ced881$3baa4b40$b2fee1c0$@maris@psych.ru.nl> Hi Ben, (When you reply to a post, please also keep the post to which you reply. This is useful for others that want to follow the discussion.) > Thanks for the answer. I really just dont see it... Where does the > permutation distribution of the max cluster stat come from if you don't > do a permutation test? Without a permutation test, there is no permutation distribution. You construct the permutation distribution as a part of the test. > > But you don't actually need that distribution just the statistic?? You need both the distribution and the statistic, just like in parametric (Neyman-Pearson) statistics. However, unlike parametric statistics, in permutation statistics you construct your own reference distribution (i.c., the permutation distribution). how > do you know then where your max stat (and the other clusterstats) is > compared to the critical value at alpha? > > lets say your max clusterstat = 10 > > P(max(clusterstat) _> cv) = 0.05 > so the probability that we see 10 or higher is 5% if h0 is in fact > true. we actually are seeing 10 and thus (falsely) reject h0. so that > always happens when h0 is true - you always reject the max cluster when > h0 is true? doesn't make sense :( Your conceptual problem probably is due to the fact that you do not see how the maximum cluster statistic is generated under the permutation distribution. Under this distribution, this statistic really is a random variable. Maybe there is someone in your university to discuss this point. These conceptual issues are much faster clarified in a one-to-one discussion. Alternatively, attend one of our Fieldtrip courses. Best, Eric Maris > > Thanks, > Ben > From kgm at tf.uni-kiel.de Mon Nov 4 14:30:57 2013 From: kgm at tf.uni-kiel.de (kgm at tf.uni-kiel.de) Date: Mon, 4 Nov 2013 14:30:57 +0100 Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat Message-ID: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> Hi, I am working with the combined EEG and MEG recording and would like to do the forward model for the EEG. So I was trying to use the 'bemcp' and 'openmeeg' as am working on windows platform. I have the anatomy of my subject (DICOM file stacked and cleaned using SPM). When I try to use openmeeg, vol.mat is missing from the vol structure giving an error message om_minverser.exe doesn't function anymore. When I try to use 'bemcp', vol.mat contains all NaNs which resulted from the c12 and c21 matrices being not a square matrix which makes the inverse to be non-existent and also those matrices consists a large number of 'Inf' entries. Like it was mentioned on one of the forums, the error might come when the meshes are generated. I was able to find the index of the vertices from the Cij matrix, but I couldn't find the actual relation to the vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either brain, skull or scalp. Here are all the steps that I have followed. % reading MRI mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); % segment the brain cfg = []; cfg.output = {'brain', 'skull', 'scalp'}; cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- interauricular segmentedmri = ft_volumesegment(cfg, mri); segmentedmri.anatomy = mri.anatomy; % prepare mesh cfg = []; cfg.tissue = {'brain','skull', 'scalp'}; cfg.numvertices = [3000 2000 1000]; cfg.transform = segmentedmri.transform; bnd = ft_prepare_mesh(cfg, segmentedmri); % create head model cfg = []; cfg.method = 'openmeeg'; cfg.conductivity = [0.33 0.0041 0.33]; vol = ft_prepare_headmodel(cfg, bnd); figure; ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain figure; ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull figure; ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp Any help? Thanks. Kidist From s.rombetto at cib.na.cnr.it Mon Nov 4 17:16:33 2013 From: s.rombetto at cib.na.cnr.it (s.rombetto at cib.na.cnr.it) Date: Mon, 4 Nov 2013 17:16:33 +0100 Subject: [FieldTrip] question on SPIKE structure Message-ID: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> Dear Fieldtrip users I've just read the Tutorial concerning "Preprocessing and analysis of spike and local field potential data". Now I am wondering if it is possible to create a SPIKE structure, starting from recorded data, even without using any electrophysiology data acquisition system. Anybody can answer to this question? Maybe it is trivial, but I hhave never worked with these systems, but I am interested to this kind of analysis. Regards ------------------------- Dott.ssa Sara Rombetto Istituto di Cibernetica "E. Caianiello" Via Campi Flegrei, 34 80078 Pozzuoli (NA) Italy mob +39 3401689815 tel +39 0818675361 fax +39 0818675128 -------------------------- "I disapprove of what you say, but I will defend to the death your right to say it." [Evelyn Beatrice Hall, The Friends Of Voltaire] ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From r.oostenveld at donders.ru.nl Mon Nov 4 22:24:09 2013 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Mon, 4 Nov 2013 22:24:09 +0100 Subject: [FieldTrip] question on SPIKE structure In-Reply-To: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> References: <20131104171633.7c53po8erookw0s8@arco.cib.na.cnr.it> Message-ID: <252AD1B6-7925-4BCA-9541-15E28EB11741@donders.ru.nl> Dear Sara, Please have a look at ft_datatype_spike in the utilities directory (or do "help ft_datatype_spike"). It explains the various fields in the spike data structure. We have such ft_datatype_xxx functions for all FieldTrip data structures. Their help serves to define the data structure (also for the developers), and the code in the functions serves to do some sanity checks and to update older data structures (e.g. stored in a mat file on disk) to the standards of the fieldtrip version that has to process them. best regards, Robert On 4 Nov 2013, at 17:16, s.rombetto at cib.na.cnr.it wrote: > Dear Fieldtrip users > > I've just read the Tutorial concerning "Preprocessing and analysis of spike and local field potential data". > Now I am wondering if it is possible to create a SPIKE structure, starting from recorded data, even without using any electrophysiology data acquisition system. > Anybody can answer to this question? Maybe it is trivial, but I hhave never worked with these systems, but I am interested to this kind of analysis. > > Regards > ------------------------- > Dott.ssa Sara Rombetto > Istituto di Cibernetica > "E. Caianiello" > Via Campi Flegrei, 34 > 80078 Pozzuoli (NA) > Italy > mob +39 3401689815 > tel +39 0818675361 > fax +39 0818675128 > -------------------------- > "I disapprove of what you say, but I will defend to the death your right to say > it." [Evelyn Beatrice Hall, The Friends Of Voltaire] > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 5 09:43:18 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 5 Nov 2013 09:43:18 +0100 Subject: [FieldTrip] question about coregistration References: Message-ID: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Dear Nicola, I am forwarding your question to the list, "ter lering ende vermaak": Begin forwarded message: > From: Nicola Molinaro > Date: November 4, 2013 2:16:20 PM GMT+01:00 > To: jan-mathijs schoffelen > Subject: mm -> voxels ?? > > Hi Jan, > I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? > I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). > > Thanks > > Nicola Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). Best wishes, Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Tue Nov 5 16:56:59 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Tue, 05 Nov 2013 16:56:59 +0100 Subject: [FieldTrip] =?utf-8?q?Reading_data_and_trigger_events_from_Neurom?= =?utf-8?q?ag_=09fif=09dataset__spli?= In-Reply-To: References: Message-ID: Thanks Peter. The concatenation of the data by using horzcat works fine. However, I don't know how to define the trials by refering to the concatenated data. Is it possible to automatically define the trials based on trigger signals in the concatenated data by using ft_definetrial or ft_redefinetrial? I get the error message (see below) about the missing headerfile. I tried to define cfg.header = dfull.hdr and cfg.headerfile = dfull.hdr , but it didn't seem to work. Greetings Niels. >> cfg = []; cfg.data = dfull cfg.trialfun = 'ft_trialfun_general' % this is the default cfg.trialdef.eventtype = 'STI101'; % trigger channel cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds trl = ft_definetrial(cfg); cfg = data: [1x1 struct] cfg = data: [1x1 struct] trialfun: 'ft_trialfun_general' evaluating trialfunction 'ft_trialfun_general' Reference to non-existent field 'headerfile'. Error in ft_trialfun_general (line 71) hdr = ft_read_header(cfg.headerfile, 'headerformat', cfg.headerformat); Error in ft_definetrial (line 162) [trl, event] = feval(cfg.trialfun, cfg); FieldTrip discussion list writes: >Hi Neils,� > > >I use the ft_preprocessing function to load � both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs.� > > >I haven't had a problem with dropped triggers / incorrect trial lengths etc.� > > >Please find the code I use below (and excuse any clunkiness): > > >As for your second question re:� cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. � > > >Hope the above (and below) helps and happy MEGing,� > > >Peter. > > > > >%% >%Read data into matlab > > >cfg = []; >cfg.dataset = megdata1; %first fif file >cfg.channel = 'MEG'; >d1 = ft_preprocessing(cfg); > > >cfg = []; >cfg.dataset = megdata2;� %second fif file >cfg.channel = 'MEG'; >d2 = ft_preprocessing(cfg); > > >%% >%concatenate� data > > >dfull = d1; >dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly.� >dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); >dfull.sampleinfo = [1 length(dfull.trial{1,1})]; > > >for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. >dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR.� >i = i + 1; >end� � > > >__________________________ >Peter Goodin,� >BSc (Hons), Ph.D Candidate. > > >Brain and Psychological Sciences Research Centre (BPsych) >Swinburne University,� >Hawthorn, Vic, 3122 > > >Monash Alfred Psychiatry Research Centre (MAPrc) >Level 4, 607 St Kilda Road, >Melbourne 3004 > >--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >-From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [aestnth at hum.au.dk] >Sent: Friday, 1 November 2013 3:16 AM >To: fieldtrip at science.ru.nl >Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files > > >Dear FieldTrip community. > >Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? > >The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. >FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. >( [ http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ]http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) > >I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. >The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. > >When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. � > >I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? > >I'm looking forward to hear any comments, suggestions or solutions. > >Greetings >Niels. > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >Denmark >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From joramvandriel at gmail.com Wed Nov 6 10:06:39 2013 From: joramvandriel at gmail.com (Joram van Driel) Date: Wed, 6 Nov 2013 10:06:39 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: Hi Nicola, I also did coregistration in MRI-lab using isotrak data. Importing the fif files in fieldtrip worked fine, I don’t think you have to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial ingredient. This worked for me: mri = ft_read_mri(); %%% read the MRI; the fif file is in mm but FT changes it into meters mri = ft_convert_units(mri,'mm'); %%% make it mm as it originally was mri = ft_volumereslice([], mri); %%% after this function the ficual points in the MEG header match the coordinates in the MRI Then you should indeed check this with ft_sourceplot, where in the cfg you can fill in fiducial points to check if they make sense, e.g.: cfg = []; cfg.location = [0 90.5 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly cfg.locationcoordinates = 'head'; ft_sourceplot(cfg,mri); Hope this helps. Best, Joram On 05 Nov 2013, at 09:43, jan-mathijs schoffelen wrote: > Dear Nicola, > > I am forwarding your question to the list, "ter lering ende vermaak": > > Begin forwarded message: > >> From: Nicola Molinaro >> Date: November 4, 2013 2:16:20 PM GMT+01:00 >> To: jan-mathijs schoffelen >> Subject: mm -> voxels ?? >> >> Hi Jan, >> I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? >> I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). >> >> Thanks >> >> Nicola > > > Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? > To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. > Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. > I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). > > Best wishes, > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Wed Nov 6 11:52:19 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Wed, 6 Nov 2013 11:52:19 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: Thanks guys for any possible help. Really appreciate it! I will summarize my tests: 1. reading the COR-.fif produced by MRIlab with ft_read_mri Well, it seems that ft_read_mri reads the original (not coregistered) .fif file produced in earlier steps of the forward model calculation (COR.fif). For example, if I delete the COR.fif file, ft_read_mri gives an error. ft_read_mri applied to the COR-.fif should be able to read some header, and for this reason I tried the option suggested by Joram (including ft_volumereslice). However, when I plot the volume head model with *hs=ft_read_headshape(.fif. 'unit','mm'); %get headshape points* *ft_plot_vol(vol)* *ft_plot_headshape(hs)* There is an evident misalignment between isotrack points and the brain volume. I mean NO coregistration is done. you can also appreciate it when plotting a prearicular instead of the nasion with *cfg = [];* *cfg.location = [66.4 0 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly* *cfg.locationcoordinates = 'head';* *ft_sourceplot(cfg,mri);* Take home message: Fieldtrip does not read the coregistration done in MRIlab, and you have to coregister MEG and MRI again. 2. Using cfg.method = 'headshape' cfg.headshape = 'XXX.pos' for ft_volumerealign. I played with it, but in neuromag the polhemous data are within the header of the *.fif* file. You can export the isotrack point however from MRIlab. After importing then with File>Import>Isotrack data you can then export them with File>Export>Points and specifying the coordinate system in which you want your point (either Head, or MRI or Voxel). This file cannot be read by ft_volumerealign with the headshape method. However, the first three lines of the resulting .txt file will give you the nasion and the two pre-auricolar points positions. I tried importing the voxel positions of the three points in ft_volumerealign using the method cfg.coordsys = 'neuromag'; cfg.method = 'fiducial'; And it worked, the brain volume is aligned with the isotrack points. This is the only solution that is visually reliable to perform On Wed, Nov 6, 2013 at 10:06 AM, Joram van Driel wrote: > Hi Nicola, > > I also did coregistration in MRI-lab using isotrak data. > Importing the fif files in fieldtrip worked fine, I don’t think you have > to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial > ingredient. > This worked for me: > > mri = ft_read_mri(); %%% read the MRI; the fif > file is in mm but FT changes it into meters > mri = ft_convert_units(mri,'mm'); %%% make it mm as it > originally was > mri = ft_volumereslice([], mri); %%% after this function the > ficual points in the MEG header match the coordinates in the MRI > > Then you should indeed check this with ft_sourceplot, where in the cfg you > can fill in fiducial points to check if they make sense, e.g.: > > cfg = []; > cfg.location = [0 90.5 0]; %%% fill in a fiducial point from > the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > > ft_sourceplot(cfg,mri); > > Hope this helps. > Best, > Joram > > On 05 Nov 2013, at 09:43, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > > Dear Nicola, > > I am forwarding your question to the list, "ter lering ende vermaak": > > Begin forwarded message: > > *From: *Nicola Molinaro > *Date: *November 4, 2013 2:16:20 PM GMT+01:00 > *To: *jan-mathijs schoffelen > *Subject: **mm -> voxels ??* > > Hi Jan, > I am trying to align the T1 images with isotrak data using MRIlab and then > import the coregistrated image to fieldtrip. Comparing the headshape points > with the volume, we can see that Fieldtrip is not taking into account the > coregistration. Thus, we are trying to do the corregistration applying the > ft_volumerealign function with the method='fiducial' in Fieldtrip. I have > the information of the landmarks' position obtained with MRIlab in 'mm' and > the function ft_volumerealign need them in voxel index. How can you convert > that? > I don´t know if you ever used MRIlab to obtain this information or another > software (MNE?). > > > Thanks > > Nicola > > > > Indeed I have never used MRIlab for coregistration purposes, so I may not > be of much help here. However, I suspect that the coregistration procedure > in MRIlab allows you to export your MRI after coregistration, thus creating > an file with an anatomical image in register with what you want to achieve. > If this is the case, then I don't think that you need FieldTrip to > coregister again. I am therefore a bit confused with respect to your remark > that 'FieldTrip is not taking into account the coregistration'. If you read > in an MRI into FieldTrip, the resulting MRI-structure will contain a > transform field, that provides the mapping from voxel space into a more > meaningful coordinate system. FieldTrip will not 'guess' the nature of this > coordinate system: it just takes the values as they are in the file. Once > you have read in your MRI, you can use the ft_sourceplot function for > visualization. With cfg.method = 'ortho', the figure will also display the > coordinates that you click on (both in voxel indices and in real world > coordinates). Now, do you mean by 'FieldTrip does not take into account the > coregistration' that these real world coordinates are not as expected? > To answer your question regarding the conversion of landmark positions in > 'mm' back into voxel indices: this requires information from the > mri.transform matrix, but this implies that the mri is already in register, > so there would be no need anymore to call ft_volumerealign. > Either way, you could also do the coregistration entirely in FieldTrip. > This requires a two-step approach, calling ft_volumerealign twice (starting > from the raw DICOM files, i.e. prior to having used MRIlab). In the first > step you will use cfg.interactive = 'yes' and identify the fiducials that > define your corodinate system. Assuming that you are working with your MEG > data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). > The output to this funcion call is an MRI structure that is approximately > in register with the MEG-device. In the next step you can refine this > coregistration by calling ft_volumerealign (with the approximately > registered MRI in the input, and) with cfg.method = 'headshape', and > cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should > result (providing that the isotrak data can be read ;-) ) in an interactive > figure, that allows you to further align the MRI with the polhemus point > cloud that describes the headshape. Once you are happy enough, the figure > can be closed, and an iterative-closest-point algorithm is applied for > further refinement of the coregistration. > I hope this helps, and might inspire you to try out the coregistration in > FieldTrip (and give feedback to us about it, in order to make the procedure > more robust). > > Best wishes, > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -- ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Wed Nov 6 22:57:54 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Wed, 06 Nov 2013 22:57:54 +0100 Subject: [FieldTrip] =?utf-8?q?Reading_data_and_trigger_events_from_Neurom?= =?utf-8?q?ag_=09fif=09dataset___sp?= In-Reply-To: References: <, > <,> Message-ID: Sorry, the previously posted example was wrong. Below is a correction to the previous example. Does the error shown below mean that you can only define trials based on the raw data files, and you can not define trials based on the data, which has already been converted to FieldTrip data? If so, I assume that it's necessary to: 1. Apply ft_definetrial on each one of the splitted raw fif files. 2. In the first two rows in the trial definition matrix from the second splitted file (i.e. the trial begin sample and trial end sample) add the number of samples in the preceeding raw fif file + 1. 3. Use vertcat to concatenate the corrected trial definition matrices from both files into one trial definition. 4. Then use ft_redefinetrial to apply the concatenated trial definitions on the concatenated data. Have anyone tried succesfully to concatenate trial definitions and apply them on concatenated data (in cases with raw fif files splitted into 2 files due to 2 GB file limitation during raw data recording)? Greetings Niels. >> cfg = []; cfg.dataset = dfull cfg.trialfun = 'ft_trialfun_general' % this is the default cfg.trialdef.eventtype = 'STI101'; % trigger channel cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds trl = ft_definetrial(cfg); cfg = dataset: [1x1 struct] cfg = dataset: [1x1 struct] trialfun: 'ft_trialfun_general' Warning: -clear > In utilities/private/warning_once at 116 In utilities/private/ft_preamble_init at 26 In ft_preamble at 54 In ft_definetrial at 112 Error using fileparts (line 31) Input must be a row vector of characters. Error in ft_filetype (line 146) [p, f, x] = fileparts(filename); Error in dataset2files (line 14) format = ft_filetype(filename); Error in ft_checkconfig (line 503) [cfg.dataset, cfg.headerfile, cfg.datafile] = dataset2files(cfg.dataset, []); Error in ft_definetrial (line 116) cfg = ft_checkconfig(cfg, 'dataset2files', {'yes'}); FieldTrip discussion list writes: >Thanks Peter. > >The concatenation of the data by using horzcat works fine. > >However, I don't know how to define the trials by refering to the concatenated data. >Is it possible to automatically define the trials based on trigger signals in the concatenated data by using ft_definetrial or ft_redefinetrial? > >I get the error message (see below) about the missing headerfile. I tried to define cfg.header = dfull.hdr and cfg.headerfile = dfull.hdr , but it didn't seem to work. > >Greetings >Niels. > >>> cfg = []; >cfg.data = dfull >cfg.trialfun = 'ft_trialfun_general' % this is the default >cfg.trialdef.eventtype = 'STI101'; % trigger channel >cfg.trialdef.eventvalue = [1 2 3 4 5]; % the values of the stimulus triggers >cfg.trialdef.prestim = 0.250; % time window before stimulus in seconds >cfg.trialdef.poststim = 0.500; % time window after stimulus in seconds >trl � = ft_definetrial(cfg); > >cfg = > >� � � � data: [1x1 struct] > > >cfg = > >� � � � � � � � data: [1x1 struct] > � � � trialfun: 'ft_trialfun_general' > >evaluating trialfunction 'ft_trialfun_general' >Reference to non-existent field 'headerfile'. > >Error in ft_trialfun_general (line 71) >hdr = ft_read_header(cfg.headerfile, 'headerformat', cfg.headerformat); > >Error in ft_definetrial (line 162) > � � � [trl, event] = feval(cfg.trialfun, cfg); > > >FieldTrip discussion list <[ mailto:fieldtrip at science.ru.nl ]fieldtrip at science.ru.nl> writes: >Hi Neils,� > > >I use the ft_preprocessing function to load � both of my fif files into memory, then use the horzcat command to concatenate the matrices together. From there I create my trialdefs and use ft_redefinetrial to create the condition epochs.� > > >I haven't had a problem with dropped triggers / incorrect trial lengths etc.� > > >Please find the code I use below (and excuse any clunkiness): > > >As for your second question re:� cfg.detectflank = 'up', the ft_read_event function is the one you want to look at. If your system is anything like a typical neuromag, an event can be characterised by both the up and down edges of your digital trigger channel. By specifying cfg.detectflank = 'up' in the read_even function, it will search for jumps in the channel where samples change from 0 to > 0 and classify that as an event, ignoring the down edge. � > > >Hope the above (and below) helps and happy MEGing,� > > >Peter. > > > > >%% >%Read data into matlab > > >cfg = []; >cfg.dataset = megdata1; %first fif file >cfg.channel = 'MEG'; >d1 = ft_preprocessing(cfg); > > >cfg = []; >cfg.dataset = megdata2;� %second fif file >cfg.channel = 'MEG'; >d2 = ft_preprocessing(cfg); > > >%% >%concatenate� data > > >dfull = d1; >dfull.trial{1,1} = zeros(306,length(d1.trial{1,1}) + length(d2.trial{1,1})); NOTE: The 306 refers to channels (MEG only). If you have more channels (eg. EOG, ECG) change accordingly.� >dfull.trial{1,1} = horzcat(d1.trial{1,1}, d2.trial{1,1}); >dfull.sampleinfo = [1 length(dfull.trial{1,1})]; > > >for i = 2:length(dfull.time{1,1}); NOTE: Loop assumes data has yet to be downsampled and is at the base SR of 1000Hz. >dfull.time{1,1}(1,i) = (i - 1)*.001; %Change .001 to match SR.� >i = i + 1; >end� � > > >__________________________ >Peter Goodin,� � >BSc (Hons), Ph.D Candidate. > > >Brain and Psychological Sciences Research Centre (BPsych) >Swinburne University,� >Hawthorn, Vic, 3122 > > >Monash Alfred Psychiatry Research Centre (MAPrc) >Level 4, 607 St Kilda Road, >Melbourne 3004 > > >--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >- >From: [ mailto:fieldtrip-bounces at science.ru.nl ]fieldtrip-bounces at science.ru.nl� [[ mailto:fieldtrip-bounces at science.ru.nl ]fieldtrip-bounces at science.ru.nl] on behalf of Niels Trusbak Haumann [[ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk] >Sent: Friday, 1 November 2013 3:16 AM >To: [ mailto:fieldtrip at science.ru.nl ]fieldtrip at science.ru.nl >Subject: [FieldTrip] Reading data and trigger events from Neuromag fif dataset splitted into 2 files > > >Dear FieldTrip community. > >Is it possible to read the data and trial events from a single continuous Neuromag fif dataset, which was automatically split into two separate fif files during recording, because it exceeeded the standard 2 GB file size limitation? > >The second of the two splitted fif files contains relevant information showing that the second file continues at the time in seconds at which the first file ended. However, if the two fif files are read separately into Field Trip format this information seems to be lost. >FieldTrip seems to support reading in CTF datasets, which have been split into more files due to the 2 GB file size limitation, but I don't know whether there is a method for handling this problem with Neuromag fif data. >( [ http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ]http://fieldtrip.fcdonders.nl/getting_started/ctf?s[]=ctf ) > >I presume that it is a general problem that Neuromag fif datasets with 306 channel data sampled at 1 kHz 32 bit floats are splitted into more files, since only ca. 16-18 minutes raw data can be recorded before it is automatically splitted into two files. >The large file size is not a problem after applying MaxFilter procedures to remove high frequency cHPI signals..., etc., and thereafter downsampling e.g. to 16 bit integers sampled at 250 Hz. I see from a previous discussion in another forum that it is not possible to merge (or append) the splitted files with the MaxFilter software. > >When reading triggers from splitted fif files there is usually one trial, which starts in the end of the first file and ends in the start of the second file, which cannot be correctly recognized, if the files are treated separately. This is however just a minor problem of loosing a single trial. � > >I have a few wrong detections, probably because a few trials are both defined by up-going signals and down-going signals. Would ft_preprocessing (and the sub-routines that it calls) take this into consideration, if you e.g. specificy cfg.detectflank = 'up' ? > >I'm looking forward to hear any comments, suggestions or solutions. > >Greetings >Niels. > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >Denmark >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >[ mailto:fieldtrip at donders.ru.nl ]fieldtrip at donders.ru.nl >[ http://mailman.science.ru.nl/mailman/listinfo/fieldtrip ]http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.oostenveld at donders.ru.nl Thu Nov 7 09:28:30 2013 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Thu, 7 Nov 2013 09:28:30 +0100 Subject: [FieldTrip] Fwd: MEG postdoc vacancy - Aarhus Univ, DK References: <4494422563576817.WA.yury.shtyrovcfin.au.dk@www.jiscmail.ac.uk> Message-ID: <8D6628F1-BF71-4019-916D-1289BA520D0D@donders.ru.nl> Begin forwarded message: > From: Yury Shtyrov > Date: 6 November 2013 19:23:18 CET > To: NEUROMEG at JISCMAIL.AC.UK > Subject: MEG postdoc vacancy - Aarhus Univ, DK > Reply-To: Yury Shtyrov > > Dear all, > > Apologies for possible cross-postings - could you please circulate this MEG job to anyone who could be interested. > > Thanks, > /yury/ > > Yury Shtyrov, DPhil > Professor - Head of MEG Group > MINDLab - Center of Functionally Integrative Neuroscience (CFIN) > Institute for Clinical Medicine > Aarhus University, Denmark > > > ------------------ > > Post-doctoral Position in MEG/Neuroscience of Language > Center of Functionally Integrative Neuroscience, Aarhus University > > Applications are invited for a postdoctoral scientist to support research into neurobiological foundations of language at the Center of Functionally Integrative Neuroscience (CFIN), Aarhus University, Denmark. The postholder’s research will be centred on using MEG and on the spatio-temporal dynamics of the neural activity underlying speech and language processing in the human brain. Ideal candidates will therefore have experience in neuroimaging and in language research. Previous experience in using EEG or/and MEG is essential. Eligible candidates should hold a PhD or similar degree in a relevant discipline, including (but not limited to) psychology, neuroinformatics, psycholinguisitcs or neuroscience. The position is to be filled as soon as possible and is initially open for 1 year with a possibility of extension and/or permanent post for a good candidate. > > CFIN is an international multidisciplinary research centre based at Aarhus University’s Institute for Clinical Medicine, Denmark. Our research groups are supported by state-of-the-art cognitive neuroscience facilities including research-only 306-channel TRIUX MEG system (Elekta Neuromag), fMRI systems (Siemens TIM Trio 3T, Magnetom Skyra 3T), PET, navigated TMS, EEG and eye-tracking equipment, Two-Photon Microscopy, etc., and have well-established clinical and other collaborations. See cfin.au.dk for more inromation. Aarhus University provides an inspiring international research environment with top neuroscience facilties, and is consistently named among the world's best 100 universities. > > To apply, please go to http://www.au.dk/en/about/job/sun/academicpositions/ > > Additional information regarding this position can be obtained by contacting Professor Yury Shtyrov, head of MEG, CFIN: Yury.Shtyrov at cfin.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lilla.Magyari at mpi.nl Thu Nov 7 09:44:35 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 7 Nov 2013 09:44:35 +0100 (CET) Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> Message-ID: <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> hi Kidist, I am wondering if you have installed openmeeg properly. Here is a site to explain it: http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling Have you followed this? Lilla > Hi, > > I am working with the combined EEG and MEG recording and would like to do > the forward model for the EEG. > > So I was trying to use the 'bemcp' and 'openmeeg' as am working on windows > platform. I have the anatomy of my subject (DICOM file stacked and cleaned > using SPM). > > When I try to use openmeeg, vol.mat is missing from the vol structure > giving an error message om_minverser.exe doesn't function anymore. > > When I try to use 'bemcp', vol.mat contains all NaNs which resulted from > the c12 and c21 matrices being not a square matrix which makes the inverse > to be non-existent and also those matrices consists a large number of > 'Inf' entries. > > Like it was mentioned on one of the forums, the error might come when the > meshes are generated. I was able to find the index of the vertices from > the Cij matrix, but I couldn't find the actual relation to the > vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either brain, > skull or scalp. > > Here are all the steps that I have followed. > > % reading MRI > mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); > > % segment the brain > cfg = []; > cfg.output = {'brain', 'skull', 'scalp'}; > cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- > interauricular > segmentedmri = ft_volumesegment(cfg, mri); > segmentedmri.anatomy = mri.anatomy; > > % prepare mesh > cfg = []; > cfg.tissue = {'brain','skull', 'scalp'}; > cfg.numvertices = [3000 2000 1000]; > cfg.transform = segmentedmri.transform; > bnd = ft_prepare_mesh(cfg, segmentedmri); > > % create head model > cfg = []; > cfg.method = 'openmeeg'; > cfg.conductivity = [0.33 0.0041 0.33]; > vol = ft_prepare_headmodel(cfg, bnd); > > figure; > ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain > figure; > ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull > figure; > ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp > > Any help? > > Thanks. > Kidist > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From Lilla.Magyari at mpi.nl Thu Nov 7 10:35:54 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 7 Nov 2013 10:35:54 +0100 (CET) Subject: [FieldTrip] volume normalizing to mni template from ctf space mri In-Reply-To: References: Message-ID: <2065.84.86.187.191.1383816954.squirrel@84.86.187.191> hi Russ, you do not need to worry. Your original volume is converted to spm space from ctf during normalization and then the original volume and the template are matched to each other. Although the ctf to spm conversion is an approximation, it is sufficient to produce OK result. So, you do not need to realign or reslice your volume prior to normalization. And just a remark for others: The automatic conversion happens only if the original volume defined in ctf (or bti) or in itab (neuromag) coordinates. Otherwise, the original volume should be aligned to spm space. Lilla > Hi All, > > I just wanted to confirm this, because although I seen hints about this on > the emails and websites that fieldtrip kindly archives; I worry. If I have > a CTF coordinate system single subject MRI, and I want to normalize that > onto the AVG152 brain in MNI space for example, ft_volumenormalization > should handle this. What I mean by this is that I do not have to > reslice/realign my image first to MNI space and then normalize... am I > correct or misled? Best, Russ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From nuria.donamayor at neuro.uni-luebeck.de Thu Nov 7 15:54:31 2013 From: nuria.donamayor at neuro.uni-luebeck.de (=?iso-8859-1?Q?Nuria_Do=F1amayor_Alonso?=) Date: Thu, 7 Nov 2013 15:54:31 +0100 Subject: [FieldTrip] =?iso-8859-1?q?PhD_position_-_University_of_L=FCbeck?= =?iso-8859-1?q?=2C_Germany?= In-Reply-To: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF6@solaris.neuro.uni-luebeck.de> References: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF6@solaris.neuro.uni-luebeck.de> Message-ID: <810A8E06C75EB447A8CEB73DBFD7BB0E5EDACA2FF8@solaris.neuro.uni-luebeck.de> Dear fieldtrippers, could you please circulate this PhD opening to anyone who might be interested? Thanks, Nuria -------------- The Department of Neurology, University of Lübeck seeks to recruit a Ph.D. student from the 1st of January 2014 onwards. The candidate will be working on a project on the neural basis of primary food reward in humans using multimodal imaging (EEG-fMRI). An essential part of the project will be the development of methods of electrophysiological-hemodynamic coupling. Applicants must hold a Diplom, MSc or equivalent degree in Mathematics, Physics, Engineering or a relevant discipline. They should have a strong interest in cognitive neuroscience and excellent programming skills. Preference will be given to applicants experienced in functional imaging and/or cognitive electrophysiology. The position is initially for 2 years with the possibility of renewal. The salary will be according to an E13 (TV-L, 50%) position. The University of Lübeck is an equal opportunities employer. Applications from female candidates are strongly encouraged. In case of compatible qualifications, preference will be given to people with disabilities. Applications should include CV, copies of certificates and letters of recommendation. Please send initial enquiries and/or applications directly to Dr. Nuria Doñamayor Alonso (nuria.donamayor at neuro.uni-luebeck.de). -------------- next part -------------- A non-text attachment was scrubbed... Name: PhD_position.pdf Type: application/pdf Size: 53874 bytes Desc: PhD_position.pdf URL: From kgm at tf.uni-kiel.de Thu Nov 7 15:56:54 2013 From: kgm at tf.uni-kiel.de (kgm at tf.uni-kiel.de) Date: Thu, 7 Nov 2013 15:56:54 +0100 Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> Message-ID: <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> Hi Lilla, Thank you for your reply. The openmeeg works well for the mri (subject01.mri) that is used in the fieldtrip tutorial. But the error comes when I use my subject's mri whose anatomy is 256*256*192. I have also tried to use mri = ft_volumereslice(cfg,mri) thinking that the error might be due to the inequality of the size of the anatomical volume into each direction. Kidist > hi Kidist, > > I am wondering if you have installed openmeeg properly. Here is a site to > explain it: > http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling > > Have you followed this? > > Lilla > > > >> Hi, >> >> I am working with the combined EEG and MEG recording and would like to >> do >> the forward model for the EEG. >> >> So I was trying to use the 'bemcp' and 'openmeeg' as am working on >> windows >> platform. I have the anatomy of my subject (DICOM file stacked and >> cleaned >> using SPM). >> >> When I try to use openmeeg, vol.mat is missing from the vol structure >> giving an error message om_minverser.exe doesn't function anymore. >> >> When I try to use 'bemcp', vol.mat contains all NaNs which resulted from >> the c12 and c21 matrices being not a square matrix which makes the >> inverse >> to be non-existent and also those matrices consists a large number of >> 'Inf' entries. >> >> Like it was mentioned on one of the forums, the error might come when >> the >> meshes are generated. I was able to find the index of the vertices from >> the Cij matrix, but I couldn't find the actual relation to the >> vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either >> brain, >> skull or scalp. >> >> Here are all the steps that I have followed. >> >> % reading MRI >> mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); >> >> % segment the brain >> cfg = []; >> cfg.output = {'brain', 'skull', 'scalp'}; >> cfg.coordsys = ''; % here I use the RAS coordsys and for the origin 'i'- >> interauricular >> segmentedmri = ft_volumesegment(cfg, mri); >> segmentedmri.anatomy = mri.anatomy; >> >> % prepare mesh >> cfg = []; >> cfg.tissue = {'brain','skull', 'scalp'}; >> cfg.numvertices = [3000 2000 1000]; >> cfg.transform = segmentedmri.transform; >> bnd = ft_prepare_mesh(cfg, segmentedmri); >> >> % create head model >> cfg = []; >> cfg.method = 'openmeeg'; >> cfg.conductivity = [0.33 0.0041 0.33]; >> vol = ft_prepare_headmodel(cfg, bnd); >> >> figure; >> ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain >> figure; >> ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull >> figure; >> ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp >> >> Any help? >> >> Thanks. >> Kidist >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From mattmizumi at gmail.com Thu Nov 7 20:38:50 2013 From: mattmizumi at gmail.com (mattmizumi at gmail.com) Date: Thu, 07 Nov 2013 14:38:50 -0500 Subject: [FieldTrip] selecting which dimension to average over in ft_singleplotER Message-ID: <527BEC4A.5070401@gmail.com> A simple newbie question about ft_singleplotER: given a coherence spectrum, as follows, fd = labelcmb: {'vStr1' 'vStr2'} dimord: 'chan_freq_time' cohspctrm: [1x100x101 double] freq: [1x100 double] time: [1x101 double] dof: [1x100 double] cfg: [1x1 struct] how can I plot frequency against coherence? The default behavior of ft_singleplotER in this case is to average over frequency: cfg = []; cfg.parameter = 'cohspctrm'; cfg.refchannel = 'vStr2'; cfg.channel = 'vStr1'; ft_singleplotER(cfg, fd); selected 1 channels for cohspctrm selection cohspctrm along dimension 2 averaging cohspctrm over freq the call to "ft_singleplotER" took 0 seconds ..but I cannot find a way to get it to average over time instead. How can I do this? (Of course, I know I can plot this manually. But I would like to understand how to use the ft plotting functions. I can't find anything pertinent in the coherence and plotting tutorials, or the help for ft_singleplotER.) Thanks! -- Matt From s.caffarra at bcbl.eu Fri Nov 8 10:47:20 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Fri, 8 Nov 2013 10:47:20 +0100 (CET) Subject: [FieldTrip] help Message-ID: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu From jan.schoffelen at donders.ru.nl Fri Nov 8 11:08:56 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 8 Nov 2013 11:08:56 +0100 Subject: [FieldTrip] help In-Reply-To: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.whitmarsh at gmail.com Fri Nov 8 11:14:31 2013 From: stephen.whitmarsh at gmail.com (Stephen Whitmarsh) Date: Fri, 8 Nov 2013 11:14:31 +0100 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > > Hi Sendy, > > You may want to have a look at the following link: > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > I assume that your data has been passed through the MaxFilter, which > massively reduces the rank of your data, causing the ICA algorithm to spit > out complex valued numbers. > You need to reduce the rank of your data prior to running the component > decomposition, to be less that then true rank in your data. > > Best > Jan-Mathijs > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as > following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components > using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that > should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic > distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', > 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not > work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From polomacnenad at gmail.com Fri Nov 8 16:34:16 2013 From: polomacnenad at gmail.com (Nenad Polomac) Date: Fri, 8 Nov 2013 16:34:16 +0100 Subject: [FieldTrip] 'powandcsd' on short time window Message-ID: Dear Fieldtrip users, I have one problem and I hope that somebody has idea. For my source and connectivity analysis I need cross spectrum matrix at 40Hz and for time window of 50 ms(the effect is evoked gamma and it last less then 50 ms). The problem is that for this very narrow window the best I can get is the frequency resolution of 20Hz and that is far to low. I am trying now different padding options but it seems it doesn't help. If I band pass filter(35-45Hz) data before fft then result is as expected, but without filtering I pickup wide range of frequencies(probably from 20-60Hz) even if I specify cfg.foilim=[40 40]. Furthermore, all this stuff is included in my cross spectrum and brought into the further calculations. my code: cfg=[]; cfg.toilim = [0.03 0.08]; data_redef= ft_redefinetrial(cfg, data); cfg = []; cfg.trials = 'all'; cfg.keeptrials = 'no'; cfg.channel = 'MEG'; cfg.method = 'mtmfft'; cfg.output = 'powandcsd'; cfg.tapsmofrq = 1; cfg.foilim = [40 40]; cfg.taper = 'hanning'; cfg.pad =2; cfg.padtype='zero'; gamma = ft_freqanalysis(cfg, data_redef); Thank you in advance! Cheers, Nenad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.vanlier at bsse.ethz.ch Fri Nov 8 18:15:17 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 8 Nov 2013 17:15:17 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: I think I just had my aha-moment. Or actually more of a d'oh-moment. I was already wrong at step 0 which led to a whole cascade of thinking errors. I somehow thought that the t statistics were calculated per channel for a whole trial (so a single comparison) instead of every timepoint within a trial. every one of those t values that reaches a threshold is considered to be part of a cluster. then sum the t values within each cluster and get the maximum cluster stat. this is your observed statistic. now mix the trials and randomly assign them to subset1 and subset2. repeat the above to get another max cluster stat. do this many times (monte carlo) to create the permutation distribution of the max cluster stat. compare all the cluster stats you actually observed originally with your permutation distribution to find their p values. the FA rate is controlled because no other cluster will show a smaller p value than the max stat cluster and the chance on a type I error for the max cluster stat is alpha in "his own" distribution. not completely sure about that last sentence but i think its time for weekend now :) Thanks Eric Cheers, Ben From ben.vanlier at bsse.ethz.ch Fri Nov 8 18:23:09 2013 From: ben.vanlier at bsse.ethz.ch (van Lier Ben) Date: Fri, 8 Nov 2013 17:23:09 +0000 Subject: [FieldTrip] maximum statistic in cluster correction Message-ID: sorry, i am trying to reply to the previous posts but its not obvious. maybe "RE:" is capital sensitive? very irritating how there is no word wrap either, in my emails. From eelke.spaak at donders.ru.nl Sun Nov 10 01:11:04 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Sun, 10 Nov 2013 01:11:04 +0100 Subject: [FieldTrip] 'powandcsd' on short time window In-Reply-To: References: Message-ID: Dear Nenad, Unfortunately the limit to the frequency resolution is fundamental and not practical. It is impossible to get a better frequency resolution than 20 Hz with only 50ms of data. (It might help to think of this as analogous to Heisenberg's uncertainty principle in physics.) Why do you need a better frequency resolution? Perhaps there are alternatives to what you are trying. Best, Eelke On Nov 8, 2013 7:44 AM, "Nenad Polomac" wrote: > Dear Fieldtrip users, > > I have one problem and I hope that somebody has idea. For my source and > connectivity analysis I need cross spectrum matrix at 40Hz and for time > window of 50 ms(the effect is evoked gamma and it last less then 50 ms). > The problem is that for this very narrow window the best I can get is the > frequency resolution of 20Hz and that is far to low. I am trying now > different padding options but it seems it doesn't help. If I band pass > filter(35-45Hz) data before fft then result is as expected, but without > filtering I pickup wide range of frequencies(probably from 20-60Hz) even if > I specify cfg.foilim=[40 40]. Furthermore, all this stuff is included in my > cross spectrum and brought into the further calculations. > my code: > cfg=[]; > cfg.toilim = [0.03 0.08]; > data_redef= ft_redefinetrial(cfg, data); > > cfg = []; > cfg.trials = 'all'; > cfg.keeptrials = 'no'; > cfg.channel = 'MEG'; > cfg.method = 'mtmfft'; > cfg.output = 'powandcsd'; > cfg.tapsmofrq = 1; > cfg.foilim = [40 40]; > cfg.taper = 'hanning'; > cfg.pad =2; > cfg.padtype='zero'; > gamma = ft_freqanalysis(cfg, data_redef); > > Thank you in advance! > Cheers, > > Nenad > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Mon Nov 11 16:46:53 2013 From: mcantor at umich.edu (Max Cantor) Date: Mon, 11 Nov 2013 10:46:53 -0500 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com> wrote: > Hi Sendy, JM, > > In addition, that error also happens (or used to, at least) when you have > not selected MEG as channels, therefor applying ICA e.g. also on your EOG > channels etc. as well. > > Cheers, > Stephen > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> >> Hi Sendy, >> >> You may want to have a look at the following link: >> >> >> http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component >> >> I assume that your data has been passed through the MaxFilter, which >> massively reduces the rank of your data, causing the ICA algorithm to spit >> out complex valued numbers. >> You need to reduce the rank of your data prior to running the component >> decomposition, to be less that then true rank in your data. >> >> Best >> Jan-Mathijs >> >> On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: >> >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as >> following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components >> using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file >> that should be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic >> distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', >> 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not >> work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.caffarra at bcbl.eu Mon Nov 11 17:33:08 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Mon, 11 Nov 2013 17:33:08 +0100 (CET) Subject: [FieldTrip] help In-Reply-To: Message-ID: <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From pgoodin at swin.edu.au Tue Nov 12 04:41:57 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Tue, 12 Nov 2013 03:41:57 +0000 Subject: [FieldTrip] help In-Reply-To: <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Message-ID: Hi Sendy, TL;DR - Use fastica. Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). Hope this helps, Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] Sent: Tuesday, 12 November 2013 3:33 AM To: FieldTrip discussion list Cc: FieldTrip discussion list Subject: Re: [FieldTrip] help Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 12 09:06:01 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 09:06:01 +0100 Subject: [FieldTrip] help In-Reply-To: References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> Message-ID: <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> Dear all, As a comment to Peter's reply: the fastica code internally applies PCA to the data by removing all small signal components. In this respect runica does not behave differently if you specify cfg.runica.pca = 70 (provided that fastica estimates the number of components to retain is 70). Best, Jan-Mathijs On Nov 12, 2013, at 4:41 AM, Peter Goodin wrote: > Hi Sendy, > > TL;DR - Use fastica. > > Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). > > Hope this helps, > > Peter > > __________________________ > Peter Goodin, > BSc (Hons), Ph.D Candidate. > > Brain and Psychological Sciences Research Centre (BPsych) > Swinburne University, > Hawthorn, Vic, 3122 > > Monash Alfred Psychiatry Research Centre (MAPrc) > Level 4, 607 St Kilda Road, > Melbourne 3004 > > ________________________________________ > From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] > Sent: Tuesday, 12 November 2013 3:33 AM > To: FieldTrip discussion list > Cc: FieldTrip discussion list > Subject: Re: [FieldTrip] help > > Hi Fieldtrip users, > > I tried to select MEG as channels and I reduced the rank of my data, as following: > > cfg=[]; > cfg.runica.pca = 306; > cfg.channel = 'MEG'; > comp = ft_componentanalysis(cfg, data); > > ...but I still get the same error as before. > Are there any other reasons that could produce this error? > > Thanks in advance, > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > ----- Original Message ----- > From: "Max Cantor" > To: "FieldTrip discussion list" > Sent: Monday, November 11, 2013 4:46:53 PM > Subject: Re: [FieldTrip] help > > > > I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. > > > Thank you, > Max > > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: > > > > Hi Sendy, JM, > > > In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. > > > Cheers, > Stephen > > > > > > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: > > > > > > > Hi Sendy, > > > You may want to have a look at the following link: > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > > I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. > You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. > > > Best > Jan-Mathijs > > > > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgoodin at swin.edu.au Tue Nov 12 09:36:28 2013 From: pgoodin at swin.edu.au (Peter Goodin) Date: Tue, 12 Nov 2013 08:36:28 +0000 Subject: [FieldTrip] help In-Reply-To: <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> References: , <603834576.7426.1384187588821.JavaMail.javamailuser@localhost> , <262E34B2-0670-4652-9461-CD5FC2331B5D@donders.ru.nl> Message-ID: Hi Jan-Mathijs, Very good to know, thank you! Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of jan-mathijs schoffelen [jan.schoffelen at donders.ru.nl] Sent: Tuesday, 12 November 2013 7:06 PM To: FieldTrip discussion list Subject: Re: [FieldTrip] help Dear all, As a comment to Peter's reply: the fastica code internally applies PCA to the data by removing all small signal components. In this respect runica does not behave differently if you specify cfg.runica.pca = 70 (provided that fastica estimates the number of components to retain is 70). Best, Jan-Mathijs On Nov 12, 2013, at 4:41 AM, Peter Goodin wrote: Hi Sendy, TL;DR - Use fastica. Long version: The problem is due to Max filtering your data. You think you should have 305 components (n channels - 1) but due to the removal of some components during the Max filtering process it's more like 70 (tsss changes that figure again). There's been some discussion on this list previously about it where the suggestion was to use PCA to limit the components to ~70. On the EEGlab mailing list however there's talk that apparently using PCA can effect data quality. To get around this, instead of using an algorithm like runica, I use fastica. It automatically accounts for the reduced rank of the data using a co-variance matrix and produces comparable results (from my own tinkering). Hope this helps, Peter __________________________ Peter Goodin, BSc (Hons), Ph.D Candidate. Brain and Psychological Sciences Research Centre (BPsych) Swinburne University, Hawthorn, Vic, 3122 Monash Alfred Psychiatry Research Centre (MAPrc) Level 4, 607 St Kilda Road, Melbourne 3004 ________________________________________ From: fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] on behalf of Sendy Caffarra [s.caffarra at bcbl.eu] Sent: Tuesday, 12 November 2013 3:33 AM To: FieldTrip discussion list Cc: FieldTrip discussion list Subject: Re: [FieldTrip] help Hi Fieldtrip users, I tried to select MEG as channels and I reduced the rank of my data, as following: cfg=[]; cfg.runica.pca = 306; cfg.channel = 'MEG'; comp = ft_componentanalysis(cfg, data); ...but I still get the same error as before. Are there any other reasons that could produce this error? Thanks in advance, Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu ----- Original Message ----- From: "Max Cantor" To: "FieldTrip discussion list" Sent: Monday, November 11, 2013 4:46:53 PM Subject: Re: [FieldTrip] help I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 09:48:13 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 09:48:13 +0100 Subject: [FieldTrip] help In-Reply-To: References: <1154667156.5208.1383904040783.JavaMail.javamailuser@localhost> Message-ID: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> Hi Max, When you specify the channel to be left out, you have to name it according to how it's named in your data. I believe that the 'refchan' is only called like that for the purpose of the example. So, when you have a single reference channel, named 'thisisthenameofyourreferencechannel', you need to specify '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for exaggerating, but perhaps the silly name brings across the message more clearly. Note, that when you have applied a common average reference, you could at random remove a channel (not advisable). In that case I'd specify the dimensionality of your data space prior to calling ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG channels). Best, Jan-Mathijs On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: > I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. > > Thank you, > Max > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh wrote: > Hi Sendy, JM, > > In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. > > Cheers, > Stephen > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen wrote: > > Hi Sendy, > > You may want to have a look at the following link: > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. > You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. > > Best > Jan-Mathijs > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.caffarra at bcbl.eu Tue Nov 12 10:30:50 2013 From: s.caffarra at bcbl.eu (Sendy Caffarra) Date: Tue, 12 Nov 2013 10:30:50 +0100 (CET) Subject: [FieldTrip] help In-Reply-To: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> Message-ID: <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Thanks a lot. Now it works ;) Sendy ----- Original Message ----- From: "jan-mathijs schoffelen" To: "FieldTrip discussion list" Sent: Tuesday, November 12, 2013 9:48:13 AM Subject: Re: [FieldTrip] help Hi Max, When you specify the channel to be left out, you have to name it according to how it's named in your data. I believe that the 'refchan' is only called like that for the purpose of the example. So, when you have a single reference channel, named 'thisisthenameofyourreferencechannel', you need to specify '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for exaggerating, but perhaps the silly name brings across the message more clearly. Note, that when you have applied a common average reference, you could at random remove a channel (not advisable). In that case I'd specify the dimensionality of your data space prior to calling ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG channels). Best, Jan-Mathijs On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: I'm having this issue as well, only with EEG data, and at resamplefs = 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and also set path for EEGlab toolbox, but the issue persists. Any help would be greatly appreciated. Thank you, Max On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < stephen.whitmarsh at gmail.com > wrote: Hi Sendy, JM, In addition, that error also happens (or used to, at least) when you have not selected MEG as channels, therefor applying ICA e.g. also on your EOG channels etc. as well. Cheers, Stephen On 8 November 2013 11:08, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl > wrote: Hi Sendy, You may want to have a look at the following link: http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component I assume that your data has been passed through the MaxFilter, which massively reduces the rank of your data, causing the ICA algorithm to spit out complex valued numbers. You need to reduce the rank of your data prior to running the component decomposition, to be less that then true rank in your data. Best Jan-Mathijs On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: Hi, I'm using Fieldtrip to analyze my Meg data. Actually, I'm trying to reject ocular artifacts by using ICA. I decreased the sample rate to 300 and I performed the ICA analysis as following: cfg = []; cfg.resamplefs = 300; cfg.detrend = 'no'; data_1_rspl = ft_resampledata(cfg, data_1); %ICA cfg = []; cfg.method = 'runica'; comp = ft_componentanalysis(cfg, data_1_rspl); It worked, but now when I try to visualize the different ICA components using: cfg = []; cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should be used for plotting cfg.viewmode = 'component'; ft_databrowser(cfg, comp); I can see how the waves look like, but I cannot see the topographic distribution of them. And Matlab gives me this error: ??? Error using ==> surf at 78 X, Y, Z, and C cannot be complex. Error in ==> ft_plot_topo at 251 h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', 'FaceColor', shading); Error in ==> ft_databrowser>redraw_cb at 1850 ft_plot_topo(chanx, chany, chanz, 'mask', ... Error in ==> ft_databrowser at 671 redraw_cb(h); Could you help me in solving this problem? I also downloaded the latest version of fieldtrip but it still does not work. Thanks for your help. Sendy Sendy Caffarra Postdoctoral researcher BCBL www.bcbl.eu _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Tue Nov 12 10:53:17 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 10:53:17 +0100 Subject: [FieldTrip] selecting which dimension to average over in ft_singleplotER In-Reply-To: <527BEC4A.5070401@gmail.com> References: <527BEC4A.5070401@gmail.com> Message-ID: <03828B8D-5EBC-414F-9EAB-596C0C043EEF@donders.ru.nl> Hi Matt, In general, when dealing with time-frequency data, it is advisable to use ft_singleplotTFR, rather than ft_singleplotER. This will show the data both as a function of time and frequency. Interesting that ft_singleplotER works in the first place. If you want to visualize coherence as a function of frequency (i.e. collapsing across time) you can easily do this 'by hand': C = mean(fd.cohspctrm,3); figure;plot(fd.freq, C); Alternatively, you could use 'mtmfft' as a method for your spectral estimation, which yields frequency domain info without a time dimension. Once you have this, you can use ft_singleplotER (now it is ER confusingly) to visualize the data. Best, Jan-Mathijs On Nov 7, 2013, at 8:38 PM, mattmizumi at gmail.com wrote: > A simple newbie question about ft_singleplotER: given a coherence spectrum, as follows, > > fd = > > labelcmb: {'vStr1' 'vStr2'} > dimord: 'chan_freq_time' > cohspctrm: [1x100x101 double] > freq: [1x100 double] > time: [1x101 double] > dof: [1x100 double] > cfg: [1x1 struct] > > how can I plot frequency against coherence? The default behavior of ft_singleplotER in this case is to average over frequency: > > cfg = []; > cfg.parameter = 'cohspctrm'; > cfg.refchannel = 'vStr2'; > cfg.channel = 'vStr1'; > ft_singleplotER(cfg, fd); > > selected 1 channels for cohspctrm > selection cohspctrm along dimension 2 > averaging cohspctrm over freq > the call to "ft_singleplotER" took 0 seconds > > ..but I cannot find a way to get it to average over time instead. How can I do this? > > (Of course, I know I can plot this manually. But I would like to understand how to use the ft plotting functions. I can't find anything pertinent in the coherence and plotting tutorials, or the help for ft_singleplotER.) > > Thanks! > > -- Matt > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 10:58:42 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 10:58:42 +0100 Subject: [FieldTrip] question about coregistration In-Reply-To: References: <7AB2A52A-3B5A-4AAD-912F-24EA22EF8A93@donders.ru.nl> Message-ID: <6625F8BF-815B-40B6-8F2C-6D4C68CB8675@donders.ru.nl> Hi Nicola, Would it make sense to look into the possibility to improve support for using the polhemus info from the .fif file directly? It sounds a bit silly that you have to go through another piece of software to be able to read in the data. From ft_read_headshape it seems that *.fif files are supported, could it be that your data is not recognized as such? Best, JM On Nov 6, 2013, at 11:52 AM, Nicola Molinaro wrote: > Thanks guys for any possible help. Really appreciate it! > > I will summarize my tests: > > 1. reading the COR-.fif produced by MRIlab with ft_read_mri > > Well, it seems that ft_read_mri reads the original (not coregistered) .fif file produced in earlier steps of the forward model calculation (COR.fif). For example, if I delete the COR.fif file, ft_read_mri gives an error. ft_read_mri applied to the COR-.fif should be able to read some header, and for this reason I tried the option suggested by Joram (including ft_volumereslice). However, when I plot the volume head model with > > hs=ft_read_headshape(.fif. 'unit','mm'); %get headshape points > ft_plot_vol(vol) > ft_plot_headshape(hs) > > There is an evident misalignment between isotrack points and the brain volume. I mean NO coregistration is done. you can also appreciate it when plotting a prearicular instead of the nasion with > > cfg = []; > cfg.location = [66.4 0 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > ft_sourceplot(cfg,mri); > > Take home message: Fieldtrip does not read the coregistration done in MRIlab, and you have to coregister MEG and MRI again. > > 2. Using > > cfg.method = 'headshape' > cfg.headshape = 'XXX.pos' > > for ft_volumerealign. I played with it, but in neuromag the polhemous data are within the header of the .fif file. You can export the isotrack point however from MRIlab. After importing then with > > File>Import>Isotrack data > > you can then export them with > > File>Export>Points > > and specifying the coordinate system in which you want your point (either Head, or MRI or Voxel). This file cannot be read by ft_volumerealign with the headshape method. However, the first three lines of the resulting .txt file will give you the nasion and the two pre-auricolar points positions. I tried importing the voxel positions of the three points in ft_volumerealign using the method > > cfg.coordsys = 'neuromag'; > cfg.method = 'fiducial'; > > And it worked, the brain volume is aligned with the isotrack points. This is the only solution that is visually reliable to perform > > > On Wed, Nov 6, 2013 at 10:06 AM, Joram van Driel wrote: > Hi Nicola, > > I also did coregistration in MRI-lab using isotrak data. > Importing the fif files in fieldtrip worked fine, I don’t think you have to apply ft_volumerealign again. I suspect ft_volumereslice is a crucial ingredient. > This worked for me: > > mri = ft_read_mri(); %%% read the MRI; the fif file is in mm but FT changes it into meters > mri = ft_convert_units(mri,'mm'); %%% make it mm as it originally was > mri = ft_volumereslice([], mri); %%% after this function the ficual points in the MEG header match the coordinates in the MRI > > Then you should indeed check this with ft_sourceplot, where in the cfg you can fill in fiducial points to check if they make sense, e.g.: > > cfg = []; > cfg.location = [0 90.5 0]; %%% fill in a fiducial point from the current subject by hand, to check if coregistration went correctly > cfg.locationcoordinates = 'head'; > > ft_sourceplot(cfg,mri); > > Hope this helps. > Best, > Joram > > On 05 Nov 2013, at 09:43, jan-mathijs schoffelen wrote: > >> Dear Nicola, >> >> I am forwarding your question to the list, "ter lering ende vermaak": >> >> Begin forwarded message: >> >>> From: Nicola Molinaro >>> Date: November 4, 2013 2:16:20 PM GMT+01:00 >>> To: jan-mathijs schoffelen >>> Subject: mm -> voxels ?? >>> >>> Hi Jan, >>> I am trying to align the T1 images with isotrak data using MRIlab and then import the coregistrated image to fieldtrip. Comparing the headshape points with the volume, we can see that Fieldtrip is not taking into account the coregistration. Thus, we are trying to do the corregistration applying the ft_volumerealign function with the method='fiducial' in Fieldtrip. I have the information of the landmarks' position obtained with MRIlab in 'mm' and the function ft_volumerealign need them in voxel index. How can you convert that? >>> I don´t know if you ever used MRIlab to obtain this information or another software (MNE?). >>> >>> Thanks >>> >>> Nicola >> >> >> Indeed I have never used MRIlab for coregistration purposes, so I may not be of much help here. However, I suspect that the coregistration procedure in MRIlab allows you to export your MRI after coregistration, thus creating an file with an anatomical image in register with what you want to achieve. If this is the case, then I don't think that you need FieldTrip to coregister again. I am therefore a bit confused with respect to your remark that 'FieldTrip is not taking into account the coregistration'. If you read in an MRI into FieldTrip, the resulting MRI-structure will contain a transform field, that provides the mapping from voxel space into a more meaningful coordinate system. FieldTrip will not 'guess' the nature of this coordinate system: it just takes the values as they are in the file. Once you have read in your MRI, you can use the ft_sourceplot function for visualization. With cfg.method = 'ortho', the figure will also display the coordinates that you click on (both in voxel indices and in real world coordinates). Now, do you mean by 'FieldTrip does not take into account the coregistration' that these real world coordinates are not as expected? >> To answer your question regarding the conversion of landmark positions in 'mm' back into voxel indices: this requires information from the mri.transform matrix, but this implies that the mri is already in register, so there would be no need anymore to call ft_volumerealign. >> Either way, you could also do the coregistration entirely in FieldTrip. This requires a two-step approach, calling ft_volumerealign twice (starting from the raw DICOM files, i.e. prior to having used MRIlab). In the first step you will use cfg.interactive = 'yes' and identify the fiducials that define your corodinate system. Assuming that you are working with your MEG data acquired at BCBL, you should also specify cfg.coordsys = 'neuromag'). The output to this funcion call is an MRI structure that is approximately in register with the MEG-device. In the next step you can refine this coregistration by calling ft_volumerealign (with the approximately registered MRI in the input, and) with cfg.method = 'headshape', and cfg.headshape = 'XXX.pos' (the filename of your polhemus file). This should result (providing that the isotrak data can be read ;-) ) in an interactive figure, that allows you to further align the MRI with the polhemus point cloud that describes the headshape. Once you are happy enough, the figure can be closed, and an iterative-closest-point algorithm is applied for further refinement of the coregistration. >> I hope this helps, and might inspire you to try out the coregistration in FieldTrip (and give feedback to us about it, in order to make the procedure more robust). >> >> Best wishes, >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > -- > > ------------------------------ > Nicola Molinaro, Phd > Staff Scientist > www.bcbl.eu > > Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hanneke.vanDijk at med.uni-duesseldorf.de Tue Nov 12 11:28:33 2013 From: Hanneke.vanDijk at med.uni-duesseldorf.de (Hanneke.vanDijk at med.uni-duesseldorf.de) Date: Tue, 12 Nov 2013 10:28:33 +0000 Subject: [FieldTrip] [Fieldtrip] question about coregistration Message-ID: <495873C58A622E45A3ABF4813B9451EC6E3EF242@MAIL3-UKD.VMED.UKD> Hi Nicola and Jan-Mathijs, A simple solution can also be to save the points (the fiducials) that you have collected in MRIlab in 'voxel'. After we do the realignment with the polhemus data, we delete all points. We then create points at the final fiducial locations and export these. In this 'Export points' window you can select if you want to save them in head or voxel coordinates. The resulting .txt files can be read in matlab, and you can use them to realign the MRI in fieldtrip. Good luck! Thanks for the info as well, Jan-Mathijs! I didn't know about the two step solution in Fieldtrip, but will certainly give it a try! Groetjes Hanneke __________________________________________ Hanneke van Dijk, PhD http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html Institute for Clinical Neuroscience, Heinrich Heine Universität Düsseldorf, Germany Hanneke.vanDijk at med.uni-duesseldorf.de Tel. +49 (0) 211 81 13074 __________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 11:57:59 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 11:57:59 +0100 Subject: [FieldTrip] connectivity analysis In-Reply-To: References: Message-ID: <19A3518D-5E2A-452B-BA89-918B8FD18BC5@donders.ru.nl> Hi Bart, If you 7 frequency bins within each frequency bin are considered to belong to the same frequency band, I'd suggest to use the multitaper approach to estimate the spectral parameters per frequency band, using just a single frequency bin to represent the whole band of interest. So, rather than for example estimating from 15 until 21 Hz in steps of 1 Hz, you can also estimate only at 18, using cfg.tapsmofrq = 3 in ft_freqanalysis. I suggest to have a look at the documentation on the FT-wiki that is concerned with frequency analysis. I would certainly not average the spectral representation prior to computing the coherence, neither across the individual frequency bins, and even more certainly not across trials. Regarding statistics, I don't want to discourage you, but I don't think it makes sense to attempt doing statistics at the channel level to begin with, due to the effects of volume conduction. Also, in any group comparison (but also when doing a comparison across conditions), if there is any between groups in terms of SNR (e.g. more or less alpha power across groups) you are bound to find a statistically significant difference in estimated connectivity as well. It remains to be motivated in such a case, that the change in estimated connectivity actually reflects a change in true connectivity. If you want to do statistics irrespective of these caveats, you may want to look into FieldTrip's implementation of the non-parametric permutation testing framework. There is ample documentation about this on our wiki as well. Best wishes, Jan-Mathijs On Oct 30, 2013, at 1:22 PM, Bart Michiels wrote: > Hi, > > I have 30 patients and 30 controls and I'm investigating their coherence (EEG, 128 electrodes). Every patient has ~30 trials resting state eyes open consisting of 7 frequency bins with 7 frequencies in each bin. My goal is to show connectivity differences between different brain regions in the control and patient group (doing electrode-level analysis now, source-level analysis is next step). > > - Is it more appropriate to keep the averaging step as the latest step (ie. calculate all coherence for all the different subjects, for all trials, for all different frequencies in frequency bins) or is it better to do the averaging asap (ie. average all frequencies in 1 frequency bin at the time-frequency analysis step, average all trials at the ft_freqdescriptives step, ...) > > - Is there any better way to do some statistics on the 128x128x7x7 (128 electrodes, 7 frequency bins, 7 frequencies in each bin) besides using the ttest2() matlab function? > > Any tips & tricks are more then welcome! > > Bart > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 12:01:56 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 12:01:56 +0100 Subject: [FieldTrip] event related fields from source space In-Reply-To: References: Message-ID: <883F9839-5A9F-47C4-AC26-8B6C26C65060@donders.ru.nl> Dear Kaelasha, Yes indeed, the source.avg.mom contains per dipole location an estimate of the event-related field/potential in the x/y/z direction. You can reduce the dimensionality of these 3D time series by subsequently calling ft_sourcedescriptives with cfg.projectmom='yes'; Best, Jan-Mathijs On Oct 31, 2013, at 12:44 AM, Kaelasha Tyler wrote: > FieldTripers, > > I am wanting to reconstruct event related fields from source space and have been beamforming with ft_sourceanalysis using cfg.method='lcmv'. > > I have not been able to find any clear instructors on this, but can any one tell me, does ft_sourceanalysis output 'data.avg.mom' contain the averaged ERPs reconstructed in source space? > > data.avg.mom appears to be a column of cells, one cell for each point in my 3d grid, with each cell containing 3 time series (ERFs), one for each 3d orientation??, x, y, z? > > Can any one tell me if this is indeed what I am looking at in data.avg.mom? > > Regards, > Kaelasha Tyler > PhD candidate > Swinbunre University of Technology > Australia > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 12:05:52 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 12:05:52 +0100 Subject: [FieldTrip] visualize source localization data In-Reply-To: References: Message-ID: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> Hi Leo, Could you just do a simple plot to first get a feel of what the range of the data is, i.e. plot(source.time, source.avg.pow); This will inform you about sensible axis limits. Then, don't use a maskparameter for the time being (only a funparameter). Does this allow you to see the data in ft_sourcemovie? Best, Jan-Mathijs On Oct 29, 2013, at 10:30 AM, Leopold Zizlsperger wrote: > Dear all, > I have a question concerning source localization implementation. I need help in the very last step of visualizing a difference between 2 conditions over time: > > I get there by using the tutorial steps on single subject functional EEG data (fieldtrip-20130914; tried both WIN and MAC): > > clear all; > load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_rHFdemeanktkt.mat') > load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_lHFdemeanktkt.mat') > load leadfield; > load vol; > load elec_aligned; > > > cfg = []; > cfg.method = 'mne'; > cfg.elec = elec_aligned; > cfg.grid = leadfield; > cfg.vol = vol; > cfg.mne.prewhiten = 'yes'; > cfg.mne.lambda = 3; > cfg.mne.scalesourcecov = 'yes'; > cfg.mne.normalize = 'yes'; > sourcerHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_rHFdemeanktkt); > sourcelHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_lHFdemeanktkt); > > save source sourcerHF sourcelHF; > > clear all; > > load source; > load sourcespace; > > bnd.pnt = sourcespace.pnt; > bnd.tri = sourcespace.tri; > m=sourcerHF.avg.pow(:,1200); > ft_plot_mesh(bnd, 'vertexcolor', m); > > > > > In ft_defaults at 74 > In ft_sourceanalysis at 146 > the input is timelock data with 32 channels and 7000 timebins > using headmodel specified in the configuration > using electrodes specified in the configuration > determining source compartment (3) > projecting electrodes on skin surface > combining electrode transfer and system matrix > creating dipole grid based on user specified dipole positions > using headmodel specified in the configuration > using gradiometers specified in the configuration > 8196 dipoles inside, 0 dipoles outside brain > the call to "ft_prepare_sourcemodel" took 0 seconds > estimating current density distribution for repetition 1 > using pre-computed leadfields: some of the specified options will not have an effect > computing the solution where the noise covariance is used for regularisation > prewhitening the leadfields using the noise covariance > scaling the source covariance > the call to "ft_sourceanalysis" took 10 seconds > the input is timelock data with 32 channels and 7000 timebins > using headmodel specified in the configuration > using electrodes specified in the configuration > determining source compartment (3) > projecting electrodes on skin surface > combining electrode transfer and system matrix > creating dipole grid based on user specified dipole positions > using headmodel specified in the configuration > using gradiometers specified in the configuration > 8196 dipoles inside, 0 dipoles outside brain > the call to "ft_prepare_sourcemodel" took 0 seconds > estimating current density distribution for repetition 1 > using pre-computed leadfields: some of the specified options will not have an effect > computing the solution where the noise covariance is used for regularisation > prewhitening the leadfields using the noise covariance > scaling the source covariance > the call to "ft_sourceanalysis" took 87 seconds > >> > > cfg = []; > cfg.projectmom = 'yes'; > sdrHF = ft_sourcedescriptives(cfg,sourcerHF); > sdlHF = ft_sourcedescriptives(cfg, sourcelHF); > > sdDIFF = sdrHF; > sdDIFF.avg.pow = sdrHF.avg.pow - sdlHF.avg.pow; > sdDIFF.tri = sourcespace.tri; > > save sd sdrHF sdlHF sdDIFF; > > Then I tried different suggestions from the tutorial or the mailing list: > > cfg = []; > cfg.mask = 'avg.pow'; > ft_sourcemovie(cfg,sdDIFF); > > the input is source data with 8196 positions > baseline correcting dipole moments [--------------------------------------\] > projecting dipole moment [------------------------------------------------/] > computing power [---------------------------------------------------------|] > the call to "ft_sourcedescriptives" took 32 seconds > the input is source data with 8196 positions > baseline correcting dipole moments [---------------------------------------] > projecting dipole moment [------------------------------------------------\] > computing power [----------------------------------------------------------] > the call to "ft_sourcedescriptives" took 33 seconds > the input is source data with 8196 vertex positions and 16384 triangles > Warning: use cfg.maskparameter instead of cfg.mask > > In ft_checkconfig at 120 > In ft_sourcemovie at 48 > ??? Error using ==> set > Bad property value found. > Object Name : axes > Property Name : 'CLim' > Values must be increasing and non-NaN. > > Error in ==> caxis at 80 > set(ax,'CLim',arg); > > Error in ==> ft_sourcemovie at 263 > caxis(cfg.zlim); > > > > If I set a break before this point I can see that "arg" indeed contains two NaNs only. > > Do you have any suggestions why the script above fails to determine the axes properties? > > Alternatively I tried: > > figure > sdDIFF.tri = sourcespace.tri; > cfg = []; > cfg.alim = [0 0.5]; > cfg.zlim = [0 0.5]; > cfg.maskparameter = 'avg.pow'; > ft_sourcemovie(cfg,sdDIFF); > > > That results in a GUI that does seem to work but in the time course there is no activity displayed. > > Any advice how to visualize the difference properly? > Thanks in advance. > Best > Leo > RWTH Aachen Neurology > > > P.S. > structure of the difference sdDIFF: > > time: [1x7000 double] > pos: [8196x3 double] > inside: [8196x1 double] > outside: [1x0 double] > method: 'average' > avg: [1x1 struct] > cfg: [1x1 struct] > tri: [16384x3 int32] > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Tue Nov 12 14:51:49 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Tue, 12 Nov 2013 14:51:49 +0100 Subject: [FieldTrip] fieldtrip Digest, Vol 36, Issue 16 In-Reply-To: References: Message-ID: Dear Hanneke, this is exactly what I did, however, for better exploring the possibilities I also added an extra z point: lpa = [187.46 179.33 153.30]; nas = [127.59 147.10 244.07]; rpa = [ 69.76 185.61 147.85]; zpoint = [ 99.19 83.57 132.39]; and running ft_volumerealign with 'fiducials' everything calculated in voxel coordinates and since I was curiously biased by this webpage (outdated maybe but did not find anything updated): http://fieldtrip.fcdonders.nl/example/read_neuromag_mri_and_create_single-subject_grids_in_individual_head_space_that_are_all_aligned_in_mni_space I tried to switch a little bit the coordinates exchanging 'y' and 'x' (and it does not work) and exchanging lpa and rpa (I should have the zpoint that saves me anyway). When I plot all these points with the MEG channel's coordinates and the brain volume: vol = ft_convert_units(vol,'cm'); mri_real = ft_convert_units(mri_real,'cm'); hs=ft_read_headshape('.fif', 'unit','cm'); %get headshape points ft_plot_vol(vol) ft_plot_headshape(hs) hold plot3(hs.fid.pnt(:,1),hs.fid.pnt(:,2),hs.fid.pnt(:,3),'b+') plot3(DATA.grad.chanpos(:,1),DATA.grad.chanpos(:,2),DATA.grad.chanpos(:,3),'k*') everything seems perfect independently from switching lpa and rpa. However, after source reconstruction, when I interpolate cfg=[]; cfg.parameter='avg.pow'; inter_lcmv=ft_sourceinterpolate(cfg, lcmvdiff, mri_real); and plot my data cfg = []; cfg.method = 'slice'; cfg.coordsys = 'neuromag'; cfg.funparameter = 'avg.pow'; cfg.maskparameter = cfg.funparameter; cfg.funcolorlim = [4 10]; cfg.opacitylim = [4 10]; cfg.opacitymap = 'rampup'; ft_sourceplot(cfg,inter_lcmv); everything changes (unpredictably) depending on the coordinates of the lpa and rpa. I suspect there is something about ft_sourceinterpolate and ft_sourceplot I don't control. Actually, I tried also doing fine-grained realignment also with the headshape points as suggested by Jan (pretty slow ft_volumerealign with method headshape and isotrack points read form a .fif file). A part that realignment was not really nice (maybe because we took many isotrack points along the nose), ft_sourceplot gave new different results... Now I am kind of lost. Nicola > Message: 1 > Date: Tue, 12 Nov 2013 10:28:33 +0000 > From: > To: > Subject: Re: [FieldTrip] [Fieldtrip] question about coregistration > Message-ID: > <495873C58A622E45A3ABF4813B9451EC6E3EF242 at MAIL3-UKD.VMED.UKD> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nicola and Jan-Mathijs, > > > A simple solution can also be to save the points (the fiducials) that you > have collected in MRIlab in 'voxel'. After we do the realignment with the > polhemus data, we delete all points. We then create points at the final > fiducial locations and export these. In this 'Export points' window you can > select if you want to save them in head or voxel coordinates. The resulting > .txt files can be read in matlab, and you can use them to realign the MRI > in fieldtrip. > > Good luck! > > Thanks for the info as well, Jan-Mathijs! I didn't know about the two step > solution in Fieldtrip, but will certainly give it a try! > > Groetjes Hanneke > > > __________________________________________ > > Hanneke van Dijk, PhD > > http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html > Institute for Clinical Neuroscience, > Heinrich Heine Universit?t D?sseldorf, Germany > Hanneke.vanDijk at med.uni-duesseldorf.de Hanneke.vanDijk at med.uni-duesseldorf.de> > Tel. +49 (0) 211 81 13074 > __________________________________________ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131112/b96925a5/attachment-0001.html > > > ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 12 15:11:34 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 12 Nov 2013 09:11:34 -0500 Subject: [FieldTrip] help In-Reply-To: <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> References: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Message-ID: Hi Jan-Mathijs, I had assumed that 'refchan' was a built in fieldtrip thing, that makes more sense now! However, I'm unsure of whether I am supposed to be removing the implicit reference, or the (in my case) linked mastoid references. I ran the data using the cfg.runica.pca = N-1 parameters (I did it as N-2 actually, for the linked mastoid references) as described in the fieldtrip FAQ, Peter, and you, but the data did come out a bit weird, and I would prefer ICA over PCA, so I'll definitely try this as well and see if I get results that make more sense to me. On Tue, Nov 12, 2013 at 4:30 AM, Sendy Caffarra wrote: > Thanks a lot. > Now it works ;) > > > Sendy > > ----- Original Message ----- > From: "jan-mathijs schoffelen" > To: "FieldTrip discussion list" > Sent: Tuesday, November 12, 2013 9:48:13 AM > Subject: Re: [FieldTrip] help > > > Hi Max, > > > When you specify the channel to be left out, you have to name it according > to how it's named in your data. I believe that the 'refchan' is only called > like that for the purpose of the example. > So, when you have a single reference channel, named > 'thisisthenameofyourreferencechannel', you need to specify > '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for > exaggerating, but perhaps the silly name brings across the message more > clearly. Note, that when you have applied a common average reference, you > could at random remove a channel (not advisable). In that case I'd specify > the dimensionality of your data space prior to calling > ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG > channels). > > > Best, > Jan-Mathijs > > > > On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: > > > > I'm having this issue as well, only with EEG data, and at resamplefs = > 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and > also set path for EEGlab toolbox, but the issue persists. Any help would be > greatly appreciated. > > > Thank you, > Max > > > > On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < > stephen.whitmarsh at gmail.com > wrote: > > > > Hi Sendy, JM, > > > In addition, that error also happens (or used to, at least) when you have > not selected MEG as channels, therefor applying ICA e.g. also on your EOG > channels etc. as well. > > > Cheers, > Stephen > > > > > > > > > > On 8 November 2013 11:08, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl > wrote: > > > > > > > Hi Sendy, > > > You may want to have a look at the following link: > > > > http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component > > > I assume that your data has been passed through the MaxFilter, which > massively reduces the rank of your data, causing the ICA algorithm to spit > out complex valued numbers. > You need to reduce the rank of your data prior to running the component > decomposition, to be less that then true rank in your data. > > > Best > Jan-Mathijs > > > > > On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: > > > > Hi, > > > I'm using Fieldtrip to analyze my Meg data. > Actually, I'm trying to reject ocular artifacts by using ICA. > I decreased the sample rate to 300 and I performed the ICA analysis as > following: > > cfg = []; > cfg.resamplefs = 300; > cfg.detrend = 'no'; > data_1_rspl = ft_resampledata(cfg, data_1); > %ICA > cfg = []; > cfg.method = 'runica'; > comp = ft_componentanalysis(cfg, data_1_rspl); > > > It worked, but now when I try to visualize the different ICA components > using: > > cfg = []; > cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should > be used for plotting > cfg.viewmode = 'component'; > ft_databrowser(cfg, comp); > > I can see how the waves look like, but I cannot see the topographic > distribution of them. > > And Matlab gives me this error: > > ??? Error using ==> surf at 78 > X, Y, Z, and C cannot be complex. > > Error in ==> ft_plot_topo at 251 > h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', 'none', > 'FaceColor', > shading); > > Error in ==> ft_databrowser>redraw_cb at 1850 > ft_plot_topo(chanx, chany, chanz, 'mask', ... > > Error in ==> ft_databrowser at 671 > redraw_cb(h); > > > Could you help me in solving this problem? > I also downloaded the latest version of fieldtrip but it still does not > work. > > Thanks for your help. > > Sendy > > > Sendy Caffarra > Postdoctoral researcher BCBL > www.bcbl.eu > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > > > > > > > Jan-Mathijs Schoffelen, MD PhD > > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Tue Nov 12 15:59:54 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Tue, 12 Nov 2013 15:59:54 +0100 Subject: [FieldTrip] coregistration question In-Reply-To: References: Message-ID: Ciao Nicola, What do you mean with 'everything changes (unpredictably) depending on the coordinates of the lpa and rpa.'? The interpolation of the source-reconstructed results and the visualization of the interpolated results will be wrong if the initial coregistration is wrong to begin with. But this should already show up as a strange topography in the source reconstructed data. JM > > > > > > > > Message: 1 > Date: Tue, 12 Nov 2013 10:28:33 +0000 > From: > To: > Subject: Re: [FieldTrip] [Fieldtrip] question about coregistration > Message-ID: > <495873C58A622E45A3ABF4813B9451EC6E3EF242 at MAIL3-UKD.VMED.UKD> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Nicola and Jan-Mathijs, > > > A simple solution can also be to save the points (the fiducials) that you have collected in MRIlab in 'voxel'. After we do the realignment with the polhemus data, we delete all points. We then create points at the final fiducial locations and export these. In this 'Export points' window you can select if you want to save them in head or voxel coordinates. The resulting .txt files can be read in matlab, and you can use them to realign the MRI in fieldtrip. > > Good luck! > > Thanks for the info as well, Jan-Mathijs! I didn't know about the two step solution in Fieldtrip, but will certainly give it a try! > > Groetjes Hanneke > > > __________________________________________ > > Hanneke van Dijk, PhD > http://www.uniklinik-duesseldorf.de/deutsch/unternehmen/institute/KlinNeurowiss/Team/HannekevanDijk/page.html > Institute for Clinical Neuroscience, > Heinrich Heine Universit?t D?sseldorf, Germany > Hanneke.vanDijk at med.uni-duesseldorf.de > Tel. +49 (0) 211 81 13074 > __________________________________________ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > Nicola Molinaro, Phd > Staff Scientist > www.bcbl.eu > > Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.trautmann-lengsfeld at uke.de Tue Nov 12 17:26:18 2013 From: s.trautmann-lengsfeld at uke.de (Dr. Sina A. Trautmann-Lengsfeld) Date: Tue, 12 Nov 2013 17:26:18 +0100 Subject: [FieldTrip] Announcing Symposium 2014 in Hamburg: Synaesthesia in Perspective: Development, Networks, and Multisensory Processing Message-ID: <528256AA.1070508@uke.de> *Synaesthesia in Perspective: Development, Networks, and* *Multisensory Processing* ** *Organizers*: Tessa M. van Leeuwen, Sina A. Trautmann-Lengsfeld, Peter König, Jianwei Zhang, Andreas K. Engel *Location*: Universitätsklinikum Hamburg-Eppendorf, Hamburg, Germany *Date*: February 28th - March 1st 2014 *Website and registration*: http://www.multisense.org/index.php/symposium-2014 Dear Fieldtriplist! We are pleased to announce our symposium on synaesthesia and multisensory processing from February 28th to March 1st 2014 in Hamburg. Synaesthesia is a fascinating phenomenon in which different senses are mixed: for synaesthetes, specific sensory stimuli automatically trigger additional perceptual experiences that are not normally perceived by non-synaesthetes. Studying synaesthesia is interesting by itself, allowing for exploration of the nature of conscious experiences. The aim of the planned symposium, however, is to put synaesthesia in perspective by also emphasizing the relevance of synaesthesia for other fields of study, such as multisensory processing, sensory substitution, development of sensory processing, and connectivity in sensory systems. Participation is free of charge but registration via the website is required. Participants are welcome to present a poster during one of the two poster sessions. We are looking forward to seeing you in Hamburg! * Confirmed speakers* Amir Amedi, /Jerusalem, Israel / Andreas Engel, /Hamburg, Germany / Anil Seth, /Brighton, United Kingdom/ Brigitte Röder, /Hamburg, Germany / Charles Spence, /Oxford, United Kingdom/ Christoph Kayser, /Glasgow, United Kingdom / Christopher Sinke, /Hamburg, Germany/ Danko Nikolic, /Frankfurt am Main, Germany / David Brang, /Chicago, USA/ Devin Blair Terhune, /Oxford, United Kingdom/ Jamie Ward, /Brighton, United Kingdom/ Jianwei Zhang, /Hamburg, Germany/ Julia Simner, /Edinburgh, United Kingdom/ Ladan Shams, /Los Angeles, USA/ Micah Murray, /Lausanne, Switzerland / Nicolas Rothen, /Brighton, United Kingdom/ Olympia Colizoli/, Amsterdam, the Netherlands / Peter König, /Osnabru?ck, Germany / Petra Stoerig, /Du?sseldorf, Germany/ Roi Cohen Kadosh, /Oxford, United Kingdom / Romke Rouw, /Amsterdam, the Netherlands/ Sina A. Trautmann-Lengsfeld, /Hamburg, Germany/ Tessa van Leeuwen/, Frankfurt am Main, Germany/ Virginie van Wassenhove, /Paris, France/ -- Dr. Sina Alexa Trautmann-Lengsfeld Postdoc Dept. of Neurophysiology and Pathophysiology University Medical Center Hamburg-Eppendorf Martinistr. 52 20246 Hamburg Germany Phone: +49-40-7410-57238 Fax: +49-40-7410-57752 Email: s.trautmann-lengsfeld at uke.de -- Besuchen Sie uns auf: www.uke.de _____________________________________________________________________ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik _____________________________________________________________________ SAVE PAPER - THINK BEFORE PRINTING -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.molinaro at bcbl.eu Tue Nov 12 17:48:36 2013 From: n.molinaro at bcbl.eu (Nicola Molinaro) Date: Tue, 12 Nov 2013 17:48:36 +0100 Subject: [FieldTrip] coregistration question Message-ID: Hi Jan-Mathijs, everything started from the fact that I tried to source reconstruct a M1 ERF visual response as a test. The effect at the source level was clearly posterior in the MEG sensors. However, the source reconstruction gave me a solution with its maximum in the orbitofrontal regions of the brain. This result emerged when I employed the "correct fiducials" extracted from the Neuromag software. I thought that maybe I had to flip some landmarks to have the effect on the back of the brain. That's why I switched rpa and lpa, with however a more sparse solution. I suspect that grid, isotrack points and MEG channels are ok (when I plot them together in Matlab they are well aligned). Somehow, when I interpolate the power with the realigned brain something goes wrong, and the ft_sourceplot (the one of my previous e-mail) give me the results I described above. I also have to admit that ft_sourceplot in 'neuromag' coordinates shows the brain upside-down. N -- ------------------------------ Nicola Molinaro, Phd Staff Scientist www.bcbl.eu Legal disclaimer/Aviso legal/Lege-oharra: www.bcbl.eu/legal-disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 12 19:13:25 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 12 Nov 2013 13:13:25 -0500 Subject: [FieldTrip] help In-Reply-To: References: <03E610AF-38EB-422B-B6C2-53CB611F2BBA@donders.ru.nl> <1880873873.7899.1384248650488.JavaMail.javamailuser@localhost> Message-ID: So we decided to remove both linked mastoid references for the ICA, and it works just fine now. Thank you so much! On Tue, Nov 12, 2013 at 9:11 AM, Max Cantor wrote: > Hi Jan-Mathijs, > > I had assumed that 'refchan' was a built in fieldtrip thing, that makes > more sense now! However, I'm unsure of whether I am supposed to be removing > the implicit reference, or the (in my case) linked mastoid references. I > ran the data using the cfg.runica.pca = N-1 parameters (I did it as N-2 > actually, for the linked mastoid references) as described in the fieldtrip > FAQ, Peter, and you, but the data did come out a bit weird, and I would > prefer ICA over PCA, so I'll definitely try this as well and see if I get > results that make more sense to me. > > > On Tue, Nov 12, 2013 at 4:30 AM, Sendy Caffarra wrote: > >> Thanks a lot. >> Now it works ;) >> >> >> Sendy >> >> ----- Original Message ----- >> From: "jan-mathijs schoffelen" >> To: "FieldTrip discussion list" >> Sent: Tuesday, November 12, 2013 9:48:13 AM >> Subject: Re: [FieldTrip] help >> >> >> Hi Max, >> >> >> When you specify the channel to be left out, you have to name it >> according to how it's named in your data. I believe that the 'refchan' is >> only called like that for the purpose of the example. >> So, when you have a single reference channel, named >> 'thisisthenameofyourreferencechannel', you need to specify >> '-thisisthenameofmyreferencechannel', rather than '-refchan'. Sorry for >> exaggerating, but perhaps the silly name brings across the message more >> clearly. Note, that when you have applied a common average reference, you >> could at random remove a channel (not advisable). In that case I'd specify >> the dimensionality of your data space prior to calling >> ft_componentanalysis, as cfg.runica.pca = N-1 (N being the number of EEG >> channels). >> >> >> Best, >> Jan-Mathijs >> >> >> >> On Nov 11, 2013, at 4:46 PM, Max Cantor wrote: >> >> >> >> I'm having this issue as well, only with EEG data, and at resamplefs = >> 150. I've added '-refchan' to my cfg.channel for ft_componentanalysis, and >> also set path for EEGlab toolbox, but the issue persists. Any help would be >> greatly appreciated. >> >> >> Thank you, >> Max >> >> >> >> On Fri, Nov 8, 2013 at 5:14 AM, Stephen Whitmarsh < >> stephen.whitmarsh at gmail.com > wrote: >> >> >> >> Hi Sendy, JM, >> >> >> In addition, that error also happens (or used to, at least) when you have >> not selected MEG as channels, therefor applying ICA e.g. also on your EOG >> channels etc. as well. >> >> >> Cheers, >> Stephen >> >> >> >> >> >> >> >> >> >> On 8 November 2013 11:08, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl > wrote: >> >> >> >> >> >> >> Hi Sendy, >> >> >> You may want to have a look at the following link: >> >> >> >> http://fieldtrip.fcdonders.nl/faq/why_does_my_ica_output_contain_complex_numbers?s[]=component >> >> >> I assume that your data has been passed through the MaxFilter, which >> massively reduces the rank of your data, causing the ICA algorithm to spit >> out complex valued numbers. >> You need to reduce the rank of your data prior to running the component >> decomposition, to be less that then true rank in your data. >> >> >> Best >> Jan-Mathijs >> >> >> >> >> On Nov 8, 2013, at 10:47 AM, Sendy Caffarra wrote: >> >> >> >> Hi, >> >> >> I'm using Fieldtrip to analyze my Meg data. >> Actually, I'm trying to reject ocular artifacts by using ICA. >> I decreased the sample rate to 300 and I performed the ICA analysis as >> following: >> >> cfg = []; >> cfg.resamplefs = 300; >> cfg.detrend = 'no'; >> data_1_rspl = ft_resampledata(cfg, data_1); >> %ICA >> cfg = []; >> cfg.method = 'runica'; >> comp = ft_componentanalysis(cfg, data_1_rspl); >> >> >> It worked, but now when I try to visualize the different ICA components >> using: >> >> cfg = []; >> cfg.layout = 'neuromag306mag.lay'; % specify the layout file that should >> be used for plotting >> cfg.viewmode = 'component'; >> ft_databrowser(cfg, comp); >> >> I can see how the waves look like, but I cannot see the topographic >> distribution of them. >> >> And Matlab gives me this error: >> >> ??? Error using ==> surf at 78 >> X, Y, Z, and C cannot be complex. >> >> Error in ==> ft_plot_topo at 251 >> h = surf(Xi-deltax/2,Yi-deltay/2,zeros(size(Zi)), Zi, 'EdgeColor', >> 'none', 'FaceColor', >> shading); >> >> Error in ==> ft_databrowser>redraw_cb at 1850 >> ft_plot_topo(chanx, chany, chanz, 'mask', ... >> >> Error in ==> ft_databrowser at 671 >> redraw_cb(h); >> >> >> Could you help me in solving this problem? >> I also downloaded the latest version of fieldtrip but it still does not >> work. >> >> Thanks for your help. >> >> Sendy >> >> >> Sendy Caffarra >> Postdoctoral researcher BCBL >> www.bcbl.eu >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> >> >> >> >> >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> >> >> >> >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajatthomas at gmail.com Wed Nov 13 01:25:55 2013 From: rajatthomas at gmail.com (Rajat Thomas) Date: Wed, 13 Nov 2013 01:25:55 +0100 Subject: [FieldTrip] Plotting network arrows Message-ID: Dear all, Can FT do the following: I get a bunch of connected nodes (channels, sources whatever) and their connection strength. If there any way of plotting like curved arrows from node to the other (with varying thickness to reflect strength) ? Thanks. Rajat -- Rajat Mani Thomas Netherlands Institute for Neuroscience Amsterdam, The Netherlands http://www.cita.utoronto.ca/~thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.trautmann-lengsfeld at uke.de Wed Nov 13 13:03:10 2013 From: s.trautmann-lengsfeld at uke.de (Dr. Sina A. Trautmann-Lengsfeld) Date: Wed, 13 Nov 2013 13:03:10 +0100 Subject: [FieldTrip] Announcing Symposium 2014 in Hamburg: Synaesthesia in Perspective: Development, Networks, and Multisensory Processing In-Reply-To: <528256AA.1070508@uke.de> References: <528256AA.1070508@uke.de> Message-ID: <52836A7E.50409@uke.de> Dear Fieldtriplist, unfortunately, the link of our symposium website did not work in some cases. I apologize for that. Here is the corrected link and the announcement one more time. www.multisense.org/index.php/symposium-2014 > *Synaesthesia in Perspective: Development, Networks, and* > > *Multisensory Processing* > > ** > > *Organizers*: Tessa M. van Leeuwen, Sina A. Trautmann-Lengsfeld, > > Peter König, Jianwei Zhang, Andreas K. Engel > > *Location*: Universitätsklinikum Hamburg-Eppendorf, Hamburg, Germany > > *Date*: February 28th - March 1st 2014 > > *Website and registration*: > www.multisense.org/index.php/symposium-2014 > > > Dear Fieldtriplist! > > We are pleased to announce our symposium on synaesthesia and > multisensory processing from February 28th to March 1st 2014 in Hamburg. > > > Synaesthesia is a fascinating phenomenon in which different senses are > mixed: for synaesthetes, specific sensory stimuli automatically > trigger additional perceptual experiences that are not normally > perceived by non-synaesthetes. > > > Studying synaesthesia is interesting by itself, allowing for > exploration of the nature of conscious experiences. The aim of the > planned symposium, however, is to put synaesthesia in perspective by > also emphasizing the relevance of synaesthesia for other fields of > study, such as multisensory processing, sensory substitution, > development of sensory processing, and connectivity in sensory > systems. Participation is free of charge but registration via the > website is required. Participants are welcome to present a poster > during one of the two poster sessions. We are looking forward to > seeing you in Hamburg! > > * > Confirmed speakers* > > Amir Amedi, /Jerusalem, Israel / > > Andreas Engel, /Hamburg, Germany / > > Anil Seth, /Brighton, United Kingdom/ > > Brigitte Röder, /Hamburg, Germany / > > Charles Spence, /Oxford, United Kingdom/ > > Christoph Kayser, /Glasgow, United Kingdom / > > Christopher Sinke, /Hamburg, Germany/ > > Danko Nikolic, /Frankfurt am Main, Germany / > > David Brang, /Chicago, USA/ > > Devin Blair Terhune, /Oxford, United Kingdom/ > > Jamie Ward, /Brighton, United Kingdom/ > > Jianwei Zhang, /Hamburg, Germany/ > > Julia Simner, /Edinburgh, United Kingdom/ > > Ladan Shams, /Los Angeles, USA/ > > Micah Murray, /Lausanne, Switzerland / > > Nicolas Rothen, /Brighton, United Kingdom/ > > Olympia Colizoli/, Amsterdam, the Netherlands / > > Peter König, /Osnabru?ck, Germany / > > Petra Stoerig, /Du?sseldorf, Germany/ > > Roi Cohen Kadosh, /Oxford, United Kingdom / > > Romke Rouw, /Amsterdam, the Netherlands/ > > Sina A. Trautmann-Lengsfeld, /Hamburg, Germany/ > > Tessa van Leeuwen/, Frankfurt am Main, Germany/ > > Virginie van Wassenhove, /Paris, France/ > > -- > Dr. Sina Alexa Trautmann-Lengsfeld > Postdoc > Dept. of Neurophysiology and Pathophysiology > University Medical Center Hamburg-Eppendorf > Martinistr. 52 > 20246 Hamburg > Germany > Phone: +49-40-7410-57238 > Fax: +49-40-7410-57752 > Email:s.trautmann-lengsfeld at uke.de > > Besuchen Sie uns auf: www.uke.de > > ------------------------------------------------------------------------ > > Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen > Rechts; Gerichtsstand: Hamburg > Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. > Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik > > ------------------------------------------------------------------------ > > SAVE PAPER - THINK BEFORE PRINTING > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Dr. Sina Alexa Trautmann-Lengsfeld Postdoc Dept. of Neurophysiology and Pathophysiology University Medical Center Hamburg-Eppendorf Martinistr. 52 20246 Hamburg Germany Phone: +49-40-7410-57238 Fax: +49-40-7410-57752 Email: s.trautmann-lengsfeld at uke.de -- Besuchen Sie uns auf: www.uke.de _____________________________________________________________________ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg Vorstandsmitglieder: Prof. Dr. Martin Zeitz (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Rainer Schoppik _____________________________________________________________________ SAVE PAPER - THINK BEFORE PRINTING -------------- next part -------------- An HTML attachment was scrubbed... URL: From antony.passaro at gmail.com Wed Nov 13 17:40:20 2013 From: antony.passaro at gmail.com (Antony Passaro) Date: Wed, 13 Nov 2013 11:40:20 -0500 Subject: [FieldTrip] Plotting network arrows In-Reply-To: References: Message-ID: Hi Rajat, The intended Fieldtrip function for plotting connected nodes as you describe it is ft_topoplotCC: http://fieldtrip.fcdonders.nl/reference/ft_topoplotcc Best of luck, -Tony On Tue, Nov 12, 2013 at 7:25 PM, Rajat Thomas wrote: > Dear all, > > Can FT do the following: > > I get a bunch of connected nodes (channels, sources whatever) and their > connection strength. > > If there any way of plotting like curved arrows from node to the other > (with varying thickness to reflect strength) ? > > Thanks. > > Rajat > > -- > Rajat Mani Thomas > Netherlands Institute for Neuroscience > Amsterdam, The Netherlands > http://www.cita.utoronto.ca/~thomas > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Wed Nov 13 18:53:15 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Wed, 13 Nov 2013 18:53:15 +0100 Subject: [FieldTrip] Pre-processing on orthogonal planar gradiometers? Message-ID: Dear FieldTrip users. I want to detect and remove EOG and ECG by using ICA. My data is from a Neuromag 306 MEG scanner with magnetometers and two orthogonal planar gradiometers. I assume that it is recommendable to do the ICA separately on each sensor type separately, i.e. on 1. magnetomers, 2. horizontal planar gradiometers, and then 3. vertical planar gradiometers, because they measure magnetic field changes at different scales and in different directions. Would you recommend to do ICA and other pre-processing steps separately on the horizontal and vertical planar gradiometers, or would you just combine the planar gradiometers with ft_combineplanar immediately? I'm worried that combining the two different gradiometer sensor types would violate underlying assumptions of the pre-processing algorithms, i.e. ICA, filters and baseline correction, because the planar gradiometer values are only positive valued estimates from the combinations of the original gradiometer measures, which do not seem to have oscillatory deflections around a baseline zero valued point. Hope you can help. Greetings Niels. Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcgoiv0 at wfu.edu Wed Nov 13 19:49:34 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Wed, 13 Nov 2013 13:49:34 -0500 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data Message-ID: Hello everybody, I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the ft_timelockanalysis(cfg, data) function? I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. Another way to ask this question is: what is the format/structure of the second input (timelock) in the ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? Thanks, Inna -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Nov 14 09:02:17 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 14 Nov 2013 09:02:17 +0100 Subject: [FieldTrip] Pre-processing on orthogonal planar gradiometers? In-Reply-To: References: Message-ID: Hi Niels, It's perfectly fine to do the ICA etc on the horizontal and vertical planar gradients together. The reason being that the topographies of the artifacts cause (just like the neural sources) gradient fields with arbitrary orientation in 3D space, for which you need both the horizontal and vertical gradient channels to optimally capture this. For that matter it is even better to use them both in the same ICA step. It's absolutely forbidden to first do combineplanar and then try to do ICA on the combined data, because after the combination step (which is non-linear) the linear mixing assumption cannot be made anymore. Combining with the magnetometers would in principle be possible (differences in magnitude are addressed by the prewhitening step in most ICA algorithms), but I don't know how common this is in the field. Perhaps other people could comment on this. Best wishes, Jan-Mathijs On Nov 13, 2013, at 6:53 PM, Niels Trusbak Haumann wrote: > Dear FieldTrip users. > > I want to detect and remove EOG and ECG by using ICA. My data is from a Neuromag 306 MEG scanner with magnetometers and two orthogonal planar gradiometers. > > I assume that it is recommendable to do the ICA separately on each sensor type separately, i.e. on 1. magnetomers, 2. horizontal planar gradiometers, and then 3. vertical planar gradiometers, because they measure magnetic field changes at different scales and in different directions. > > Would you recommend to do ICA and other pre-processing steps separately on the horizontal and vertical planar gradiometers, or would you just combine the planar gradiometers with ft_combineplanarimmediately? > > I'm worried that combining the two different gradiometer sensor types would violate underlying assumptions of the pre-processing algorithms, i.e. ICA, filters and baseline correction, because the planar gradiometer values are only positive valued estimates from the combinations of the original gradiometer measures, which do not seem to have oscillatory deflections around a baseline zero valued point. > > Hope you can help. > > Greetings > Niels. > > Niels Trusbak Haumann > M.A. / PhD student > Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience > Aarhus University / Aarhus University Hospital > E-mail: aestnth at hum.au.dk > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From schuessler at cbs.mpg.de Thu Nov 14 09:41:42 2013 From: schuessler at cbs.mpg.de (Ellen Schuessler) Date: Thu, 14 Nov 2013 09:41:42 +0100 (CET) Subject: [FieldTrip] Append/Average same conditions over sessions In-Reply-To: <777653177.992.1384417995707.JavaMail.root@zimbra> Message-ID: <1301619942.1071.1384418502084.JavaMail.root@zimbra> Dear all, Here a short description of the issue: My data was conducted in 2 sessions (a week in between), both sessions contain all conditions (e.g. A B C D). For each session I will have a bit more than 400 trials to run ICA on. After ICA and after I redefine trials I will have separate files per condition (trials x time) for each session. Then, I want to concatenate conditions over sessions. That is, condition A session 2 should be appended to condition A of session 1 before I average. Now here is my question: I understand that ft_appenddata is mainly used to append different conditions. Additionally I read that files of different days might confuse in the sampleinfo (cf. http://fieldtrip.fcdonders.nl/faq/i_used_to_work_with_trl-matrices_that_have_more_than_3_columns._why_is_this_not_supported_anymore - middle part of the text). This might be true in may case as well? If not, can I just add the two matrices (sessions) horizontally (which sounds a bit too simple in my ears)? Anyway, what would be the best way to average my conditions over sessions and at which operational step? Thank you all very much in advance! If you have any further question please do not hesitate to contact me! Your help is very much appreciated. Ellen -- Ellen Schüßler, Dipl.-Psych. PhD Student Max Planck Institute for Human Cognitive and Brain Sciences Research Group "Subcortical Contributions to Comprehension" Department of Neuropsychology Stephanstraße 1a D-04103 Leipzig Germany Phone: +49 (0) 341 / 99 40 - 2474 Fax: +49 (0) 341 / 99 40 - 2260 Email: schuessler at cbs.mpg.de Web: www.cbs.mpg.de/~schuessler From Lilla.Magyari at mpi.nl Thu Nov 14 12:23:24 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Thu, 14 Nov 2013 12:23:24 +0100 (CET) Subject: [FieldTrip] Question on bemcp's and openmeeg's vol.mat In-Reply-To: <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> References: <1910c6a7c683869665ab79e84e63b00b.squirrel@webmail.tf.uni-kiel.de> <1796.84.86.187.191.1383813875.squirrel@84.86.187.191> <24e594af2b2a84fbad6eeb05b73f47c9.squirrel@webmail.tf.uni-kiel.de> Message-ID: <62505.131.174.46.51.1384428204.squirrel@131.174.46.51> Hi Kidist, Have you checked if the segmentation is OK? The segmentation for a BEM model should contain binary masks of the brain, skull and skin tissues. But these tissues should not overlap and they should form a closed shape without empty space between. One way to check this, if you plot the different tissue-types in the same image. For this, you can convert your binary segmentation to an indexed type segmentation. Here is a FAQ which explains how to do that: http://fieldtrip.fcdonders.nl/faq/how_is_the_segmentation_defined#conversion_between_probabilistic_and_indexed_representations Best, Lilla > Hi Lilla, > > Thank you for your reply. > > The openmeeg works well for the mri (subject01.mri) that is used in the > fieldtrip tutorial. > > But the error comes when I use my subject's mri whose anatomy is > 256*256*192. I have also tried to use mri = ft_volumereslice(cfg,mri) > thinking that the error might be due to the inequality of the size of the > anatomical volume into each direction. > > Kidist > > >> hi Kidist, >> >> I am wondering if you have installed openmeeg properly. Here is a site >> to >> explain it: >> http://fieldtrip.fcdonders.nl/faq/how_can_i_use_openmeeg_for_forward_modelling >> >> Have you followed this? >> >> Lilla >> >> >> >>> Hi, >>> >>> I am working with the combined EEG and MEG recording and would like to >>> do >>> the forward model for the EEG. >>> >>> So I was trying to use the 'bemcp' and 'openmeeg' as am working on >>> windows >>> platform. I have the anatomy of my subject (DICOM file stacked and >>> cleaned >>> using SPM). >>> >>> When I try to use openmeeg, vol.mat is missing from the vol structure >>> giving an error message om_minverser.exe doesn't function anymore. >>> >>> When I try to use 'bemcp', vol.mat contains all NaNs which resulted >>> from >>> the c12 and c21 matrices being not a square matrix which makes the >>> inverse >>> to be non-existent and also those matrices consists a large number of >>> 'Inf' entries. >>> >>> Like it was mentioned on one of the forums, the error might come when >>> the >>> meshes are generated. I was able to find the index of the vertices from >>> the Cij matrix, but I couldn't find the actual relation to the >>> vol.bnd(i).pnt and vol.bnd(i).tri matrices, 'i' representing either >>> brain, >>> skull or scalp. >>> >>> Here are all the steps that I have followed. >>> >>> % reading MRI >>> mri = ft_read_mri('msGAP724534-0002-00001-000192-01.img'); >>> >>> % segment the brain >>> cfg = []; >>> cfg.output = {'brain', 'skull', 'scalp'}; >>> cfg.coordsys = ''; % here I use the RAS coordsys and for the origin >>> 'i'- >>> interauricular >>> segmentedmri = ft_volumesegment(cfg, mri); >>> segmentedmri.anatomy = mri.anatomy; >>> >>> % prepare mesh >>> cfg = []; >>> cfg.tissue = {'brain','skull', 'scalp'}; >>> cfg.numvertices = [3000 2000 1000]; >>> cfg.transform = segmentedmri.transform; >>> bnd = ft_prepare_mesh(cfg, segmentedmri); >>> >>> % create head model >>> cfg = []; >>> cfg.method = 'openmeeg'; >>> cfg.conductivity = [0.33 0.0041 0.33]; >>> vol = ft_prepare_headmodel(cfg, bnd); >>> >>> figure; >>> ft_plot_mesh(vol.bnd(1),'facecolor','none'); %brain >>> figure; >>> ft_plot_mesh(vol.bnd(2),'facecolor','none'); %skull >>> figure; >>> ft_plot_mesh(vol.bnd(3),'facecolor','none'); %scalp >>> >>> Any help? >>> >>> Thanks. >>> Kidist >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From ggonesc at upo.es Fri Nov 15 11:26:52 2013 From: ggonesc at upo.es (Gabriel Gonzalez Escamilla) Date: Fri, 15 Nov 2013 11:26:52 +0100 Subject: [FieldTrip] problem with comparecorr Message-ID: <4ac7c1744427c47.528604fc@upo.es> Dear FildTrip experts, We have two groups and we are performing within group correlations with ft_sourcestatistics using cfg.method='montecarlo';cfg.statistic='corrcoef'; cfg.measure='stat'; cfg.correctm='cluster'; cfg.clusterstatistic='maxsum'; everything looks good on the analysis of every group. We've got negative correlation in GP1, and no correlation in GP2. Then we are performing between-group correlations to compare the regression lines by using cfg.method='montecarlo'; cfg.statistic='comparecorr'; cfg.measure='stat'; cfg.correctm='cluster'; cfg.clusterstatistic='maxsum' on ft_sourcestatistics. for which we are getting a difference between the correlations of the groups (GP1 Vs GP2, as input to ft_sourcestatistics a grandavg matrix containing firstly the subjects on GP1 followed by the subjects of the GP2). This seems to be ok when we perform the between correlation of GP1 Vs GP2, but then we invert the matrix to perform GP2 Vs GP1 (we have checked that the second matrix has the subjects in the correct order, all subjects of the GP2 now followed by subjects of GP1), which should result in the same results as GP1 Vs GP2 but with opposite direction; but instead of showing this, it shows no results. We have perform 1000 and 2000 montecarlo (MC)-permutations to ensure that this results are not biased by little MC-permutations, but every time we get, that in the first direction we get results, but in the inverse direction we never get any results. Is this somehow normal? Can anyone give us so guidence on this? Many thanks in advanced, Gabriel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Fri Nov 15 17:40:04 2013 From: mcantor at umich.edu (Max Cantor) Date: Fri, 15 Nov 2013 11:40:04 -0500 Subject: [FieldTrip] ft_channelrepair not finding electrodes Message-ID: Hi all, I'm trying to perform channel repair on EEG data that has undergone jump, muscle, and visual artifact rejection, and ICA to remove eog and ecg components, unmixed back into the original channels. It's a 61 channel system using a modified easycap layout and neighbours template. The layout has been shown to work on topographic displays, and the template seems to work in that it creates a neighbours object when ft_prepare_neighbours is run on it without any errors. However, I'm getting an error when I attempt to run ft_channelrepair: Error using ft_fetch_sens (line 179) no electrodes or gradiometers specified. Error in ft_channelrepair (line 112) sens = ft_fetch_sens(cfg, data); I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not really sure what elec/sens file I should be reading or how to go about creating it. I was hoping that the template, my data, and/or the layout would contain the necessary information, but given the error on ft_fetch_sens, that doesn't seem to be the case. Any help on this issue would be greatly appreciated. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Sat Nov 16 15:31:52 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Sat, 16 Nov 2013 15:31:52 +0100 Subject: [FieldTrip] failed segmentation Message-ID: <528781D8.1030107@gmail.com> Hi all, has anyone ever had a failed segmentation that looks like the one in the figure? My script works for all participants, I mean, for all other participants the brain is only inside the skull :) But it fails terribly for this one. I thought it could have to do with the placement of the fiducials, and I've played around a bit with that but it didn't solve the problem. If anyone recognises this type of error, I'd be help to hear if/how it can be fixed. Thanks a lot, Vitória -------------- next part -------------- A non-text attachment was scrubbed... Name: segmentation.png Type: image/png Size: 138624 bytes Desc: not available URL: From michelic72 at gmail.com Sat Nov 16 20:18:13 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Sat, 16 Nov 2013 14:18:13 -0500 Subject: [FieldTrip] failed segmentation In-Reply-To: <528781D8.1030107@gmail.com> References: <528781D8.1030107@gmail.com> Message-ID: Hi Vitoria, it looks like there is an artifact on the top of the head. It happened to me already and I had to preprocess the mri volume by using an appropriate cutoff and by thresholding (after plotting the histogram of the grey levels). mri.anatomy = (mri.anatomy>thr).*mri.anatomy; or mri.anatomy(:,:,230:256) = 0; If thresholding is still not effective you might consider applying morphological operators (erode, dilate, open, close), after taking care that you voxel dimensions are cubic (diagonal values of the canonic form of mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. I hope this helps, Cristiano On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai wrote: > Hi all, > > has anyone ever had a failed segmentation that looks like the one in the > figure? > My script works for all participants, I mean, for all other participants > the brain is only inside the skull :) > But it fails terribly for this one. I thought it could have to do with the > placement of the fiducials, and I've played around a bit with that but it > didn't solve the problem. > If anyone recognises this type of error, I'd be help to hear if/how it can > be fixed. > > Thanks a lot, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lilla.Magyari at mpi.nl Sun Nov 17 12:03:15 2013 From: Lilla.Magyari at mpi.nl (Lilla.Magyari at mpi.nl) Date: Sun, 17 Nov 2013 12:03:15 +0100 (CET) Subject: [FieldTrip] failed segmentation In-Reply-To: References: <528781D8.1030107@gmail.com> Message-ID: <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> hi Vitoria, is this a tpm (the default output of ft_volumesegment)? Have you also tried to segment this mri with an output for 'brain','skull','scalp'? because when you have a binary representation for these tissue-types, they do not overlap, and are closed. So, I am wondering if you end up with a brainmask which do not contain the artifact at the top of the head. Lilla > Hi Vitoria, > it looks like there is an artifact on the top of the head. It happened to > me already and I had to preprocess the mri volume by using an appropriate > cutoff and by thresholding (after plotting the histogram of the grey > levels). > > mri.anatomy = (mri.anatomy>thr).*mri.anatomy; > > or > > mri.anatomy(:,:,230:256) = 0; > > If thresholding is still not effective you might consider applying > morphological operators (erode, dilate, open, close), after taking care > that you voxel dimensions are cubic (diagonal values of the canonic form > of > mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. > > I hope this helps, > Cristiano > > > > On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai > wrote: > >> Hi all, >> >> has anyone ever had a failed segmentation that looks like the one in the >> figure? >> My script works for all participants, I mean, for all other participants >> the brain is only inside the skull :) >> But it fails terribly for this one. I thought it could have to do with >> the >> placement of the fiducials, and I've played around a bit with that but >> it >> didn't solve the problem. >> If anyone recognises this type of error, I'd be help to hear if/how it >> can >> be fixed. >> >> Thanks a lot, Vitória >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From zizlsperger at gmail.com Sun Nov 17 12:26:42 2013 From: zizlsperger at gmail.com (Zizlsperger Leopold) Date: Sun, 17 Nov 2013 12:26:42 +0100 Subject: [FieldTrip] visualize source localization data In-Reply-To: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> References: <26339DCE-BF08-4F94-B681-135EE9023254@donders.ru.nl> Message-ID: Hello Jan-Mathijs, thanks, you made my day ! Using funparameter instead of maskparameter and rescaling the plot worked fine, now I can see the data in ft_sourcemovie. All the best Leo On Nov 12, 2013, at 12:05 PM, jan-mathijs schoffelen wrote: > Hi Leo, > > Could you just do a simple plot to first get a feel of what the range of the data is, i.e. plot(source.time, source.avg.pow); > > This will inform you about sensible axis limits. Then, don't use a maskparameter for the time being (only a funparameter). > > Does this allow you to see the data in ft_sourcemovie? > > Best, > Jan-Mathijs > > > > > On Oct 29, 2013, at 10:30 AM, Leopold Zizlsperger wrote: > >> Dear all, >> I have a question concerning source localization implementation. I need help in the very last step of visualizing a difference between 2 conditions over time: >> >> I get there by using the tutorial steps on single subject functional EEG data (fieldtrip-20130914; tried both WIN and MAC): >> >> clear all; >> load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_rHFdemeanktkt.mat') >> load('F:\fieldtrip-20130914\EEG1_HC35_GA_XY_ICA_lHFdemeanktkt.mat') >> load leadfield; >> load vol; >> load elec_aligned; >> >> >> cfg = []; >> cfg.method = 'mne'; >> cfg.elec = elec_aligned; >> cfg.grid = leadfield; >> cfg.vol = vol; >> cfg.mne.prewhiten = 'yes'; >> cfg.mne.lambda = 3; >> cfg.mne.scalesourcecov = 'yes'; >> cfg.mne.normalize = 'yes'; >> sourcerHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_rHFdemeanktkt); >> sourcelHF = ft_sourceanalysis(cfg, EEG1_HC35_GA_XY_ICA_lHFdemeanktkt); >> >> save source sourcerHF sourcelHF; >> >> clear all; >> >> load source; >> load sourcespace; >> >> bnd.pnt = sourcespace.pnt; >> bnd.tri = sourcespace.tri; >> m=sourcerHF.avg.pow(:,1200); >> ft_plot_mesh(bnd, 'vertexcolor', m); >> >> >> >> > In ft_defaults at 74 >> In ft_sourceanalysis at 146 >> the input is timelock data with 32 channels and 7000 timebins >> using headmodel specified in the configuration >> using electrodes specified in the configuration >> determining source compartment (3) >> projecting electrodes on skin surface >> combining electrode transfer and system matrix >> creating dipole grid based on user specified dipole positions >> using headmodel specified in the configuration >> using gradiometers specified in the configuration >> 8196 dipoles inside, 0 dipoles outside brain >> the call to "ft_prepare_sourcemodel" took 0 seconds >> estimating current density distribution for repetition 1 >> using pre-computed leadfields: some of the specified options will not have an effect >> computing the solution where the noise covariance is used for regularisation >> prewhitening the leadfields using the noise covariance >> scaling the source covariance >> the call to "ft_sourceanalysis" took 10 seconds >> the input is timelock data with 32 channels and 7000 timebins >> using headmodel specified in the configuration >> using electrodes specified in the configuration >> determining source compartment (3) >> projecting electrodes on skin surface >> combining electrode transfer and system matrix >> creating dipole grid based on user specified dipole positions >> using headmodel specified in the configuration >> using gradiometers specified in the configuration >> 8196 dipoles inside, 0 dipoles outside brain >> the call to "ft_prepare_sourcemodel" took 0 seconds >> estimating current density distribution for repetition 1 >> using pre-computed leadfields: some of the specified options will not have an effect >> computing the solution where the noise covariance is used for regularisation >> prewhitening the leadfields using the noise covariance >> scaling the source covariance >> the call to "ft_sourceanalysis" took 87 seconds >> >> >> >> cfg = []; >> cfg.projectmom = 'yes'; >> sdrHF = ft_sourcedescriptives(cfg,sourcerHF); >> sdlHF = ft_sourcedescriptives(cfg, sourcelHF); >> >> sdDIFF = sdrHF; >> sdDIFF.avg.pow = sdrHF.avg.pow - sdlHF.avg.pow; >> sdDIFF.tri = sourcespace.tri; >> >> save sd sdrHF sdlHF sdDIFF; >> >> Then I tried different suggestions from the tutorial or the mailing list: >> >> cfg = []; >> cfg.mask = 'avg.pow'; >> ft_sourcemovie(cfg,sdDIFF); >> >> the input is source data with 8196 positions >> baseline correcting dipole moments [--------------------------------------\] >> projecting dipole moment [------------------------------------------------/] >> computing power [---------------------------------------------------------|] >> the call to "ft_sourcedescriptives" took 32 seconds >> the input is source data with 8196 positions >> baseline correcting dipole moments [---------------------------------------] >> projecting dipole moment [------------------------------------------------\] >> computing power [----------------------------------------------------------] >> the call to "ft_sourcedescriptives" took 33 seconds >> the input is source data with 8196 vertex positions and 16384 triangles >> Warning: use cfg.maskparameter instead of cfg.mask >> > In ft_checkconfig at 120 >> In ft_sourcemovie at 48 >> ??? Error using ==> set >> Bad property value found. >> Object Name : axes >> Property Name : 'CLim' >> Values must be increasing and non-NaN. >> >> Error in ==> caxis at 80 >> set(ax,'CLim',arg); >> >> Error in ==> ft_sourcemovie at 263 >> caxis(cfg.zlim); >> >> >> >> If I set a break before this point I can see that "arg" indeed contains two NaNs only. >> >> Do you have any suggestions why the script above fails to determine the axes properties? >> >> Alternatively I tried: >> >> figure >> sdDIFF.tri = sourcespace.tri; >> cfg = []; >> cfg.alim = [0 0.5]; >> cfg.zlim = [0 0.5]; >> cfg.maskparameter = 'avg.pow'; >> ft_sourcemovie(cfg,sdDIFF); >> >> >> That results in a GUI that does seem to work but in the time course there is no activity displayed. >> >> Any advice how to visualize the difference properly? >> Thanks in advance. >> Best >> Leo >> RWTH Aachen Neurology >> >> >> P.S. >> structure of the difference sdDIFF: >> >> time: [1x7000 double] >> pos: [8196x3 double] >> inside: [8196x1 double] >> outside: [1x0 double] >> method: 'average' >> avg: [1x1 struct] >> cfg: [1x1 struct] >> tri: [16384x3 int32] >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozancag at gmail.com Mon Nov 18 10:56:37 2013 From: ozancag at gmail.com (=?UTF-8?B?T3phbiDDh2HEn2xheWFu?=) Date: Mon, 18 Nov 2013 11:56:37 +0200 Subject: [FieldTrip] Some fixes to suppress gcc warnings in libbuffer Message-ID: Hi, Trying to build libbuffer, I got a lot of warnings. I'm sending a patch to fix those warnings. I didn't test if this breaks anything so it is up to you to take and/or ignore this. Thanks :) -- Ozan Çağlayan Research Assistant Galatasaray University - Computer Engineering Dept. http://www.ozancaglayan.com -------------- next part -------------- A non-text attachment was scrubbed... Name: fieldtrip-fixes.patch Type: text/x-patch Size: 6226 bytes Desc: not available URL: From jm.horschig at donders.ru.nl Mon Nov 18 11:15:32 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Mon, 18 Nov 2013 11:15:32 +0100 Subject: [FieldTrip] ft_channelrepair not finding electrodes In-Reply-To: References: Message-ID: <5289E8C4.9060605@donders.ru.nl> Hi Max, check out Fieldtrip/template/electrode and see if you can use one of the templates in there. Best would be to use electrode measurements that you actually performed yourself (to get the distances between electrodes right), but using a template might be good as well. Once you found a good template-file, you can set cfg.elecfile = 'folder/filename' and FieldTrip will handle the rest. Otherwise, if some of your colleagues have electrode measurements, you can also ask them for advice. Best, Jörn On 11/15/2013 5:40 PM, Max Cantor wrote: > Hi all, > > I'm trying to perform channel repair on EEG data that has undergone > jump, muscle, and visual artifact rejection, and ICA to remove eog and > ecg components, unmixed back into the original channels. It's a 61 > channel system using a modified easycap layout and neighbours template. > > The layout has been shown to work on topographic displays, and the > template seems to work in that it creates a neighbours object when > ft_prepare_neighbours is run on it without any errors. > > However, I'm getting an error when I attempt to run ft_channelrepair: > > Error using ft_fetch_sens (line 179) > no electrodes or gradiometers specified. > > Error in ft_channelrepair (line 112) > sens = ft_fetch_sens(cfg, data); > > I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not > really sure what elec/sens file I should be reading or how to go about > creating it. I was hoping that the template, my data, and/or the > layout would contain the necessary information, but given the error on > ft_fetch_sens, that doesn't seem to be the case. > > Any help on this issue would be greatly appreciated. > > Thanks, > > Max > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Mon Nov 18 15:33:12 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Mon, 18 Nov 2013 15:33:12 +0100 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline Message-ID: <528A2528.5020302@gmail.com> Hi everyone, In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? I'm looking forward to hearing any thoughts you may want to share! Cheers, Vitória From mcgoiv0 at wfu.edu Mon Nov 18 15:51:07 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Mon, 18 Nov 2013 09:51:07 -0500 Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hello everybody, I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the ft_timelockanalysis(cfg, data) function? I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. Another way to ask this question is: what is the format/structure of the second input (timelock) in the ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? Thanks, Inna -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.stolk8 at gmail.com Mon Nov 18 16:42:43 2013 From: a.stolk8 at gmail.com (Arjen Stolk) Date: Mon, 18 Nov 2013 16:42:43 +0100 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hi Inna, Ft_regressconfound will remove trial by trial variability of signal amplitude or frequency power that can be explained by variability in head position over those trials. The input, whether sensor or source level, should contain a trial field (keep trials in the previous step - eg at timelockanalysis). Also variance due to head position can only be reliably estimated when the neural signal is consistent over trials (as with an event related modulation or potential). I would not know how to segment a resting state into trials (for further analysis, given that those analyses typically involve connectivity measures over the resting period) but if you an idea on how to do this, you could give ft_regressconfound a try. Note that the output will also be in the trials format. Hope this has made its use a bit more clear. Yours, arjen Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het volgende: > > Hello everybody, > > I would like to use the ft_regressconfound function to remove/reduce the head motion in a continuous MEG data. > It's a resting state data and no averaging can be applied. Is there a way to apply the correction without using the > > ft_timelockanalysis(cfg, data) function? > > I understand that the ft_regressconfound function has limits and caveats but I still would like to see the results of its correction. > > > Another way to ask this question is: > what is the format/structure of the second input (timelock) in the > ft_regressconfound(cfg, timelock) function and how it can be created without ft_timelockanalysis? > > > Thanks, > > Inna > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From arno at cerco.ups-tlse.fr Mon Nov 18 17:27:40 2013 From: arno at cerco.ups-tlse.fr (Arnaud Delorme) Date: Mon, 18 Nov 2013 08:27:40 -0800 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline In-Reply-To: <528A2528.5020302@gmail.com> References: <528A2528.5020302@gmail.com> Message-ID: Dear Vitoria, there is no need to "export" data from Fieldtrip to EEGLAB to plot ERPimage figures. Simply call the "erpimage" function of EEGLAB and fill in the parameter using your fieldtrip data. The only thing you might have to do it is transform your data from a cell array to a regular 2-D array containing sample points in one dimension and trials in the other. Anything that is being shown on the EEGLAB ERPimage figure can be reproduced using this function on the command line. To sort single trials by alpha power or alpha phase (for example), you do not need a baseline period. You can compare ERPimage accross subjects and perform statistics on them using the STUDY structure of EEGLAB. Best, Arno -- Arnaud Delorme, PhD Centre de Recherche Cerveau et Cognition - UMR 5549 Pavillon Baudot, Hopital Purpan, BP 25202 31052 Toulouse Cedex, France On Nov 18, 2013, at 6:33 AM, Vitoria Piai wrote: > Hi everyone, > > In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: > http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif > Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? > I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) > I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. > > The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. > The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? > > I'm looking forward to hearing any thoughts you may want to share! > Cheers, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From arno at cerco.ups-tlse.fr Mon Nov 18 17:27:40 2013 From: arno at cerco.ups-tlse.fr (Arnaud Delorme) Date: Mon, 18 Nov 2013 08:27:40 -0800 Subject: [FieldTrip] ERP image from EEGlab in fieldtrip and power normalisation without baseline In-Reply-To: <528A2528.5020302@gmail.com> References: <528A2528.5020302@gmail.com> Message-ID: Dear Vitoria, there is no need to "export" data from Fieldtrip to EEGLAB to plot ERPimage figures. Simply call the "erpimage" function of EEGLAB and fill in the parameter using your fieldtrip data. The only thing you might have to do it is transform your data from a cell array to a regular 2-D array containing sample points in one dimension and trials in the other. Anything that is being shown on the EEGLAB ERPimage figure can be reproduced using this function on the command line. To sort single trials by alpha power or alpha phase (for example), you do not need a baseline period. You can compare ERPimage accross subjects and perform statistics on them using the STUDY structure of EEGLAB. Best, Arno -- Arnaud Delorme, PhD Centre de Recherche Cerveau et Cognition - UMR 5549 Pavillon Baudot, Hopital Purpan, BP 25202 31052 Toulouse Cedex, France On Nov 18, 2013, at 6:33 AM, Vitoria Piai wrote: > Hi everyone, > > In EEGlab, there is an interface to make the so-called ERP image: single-trial data is sorted, for example on the basis of RT, and plotted with a vertical line showing stimulus onset and another line showing the RTs. An example is shown here: > http://sccn.ucsd.edu/wiki/File:1ERPimageinf.gif > Has anyone ever implemented this in fieldtrip in a straightforward way? Or managed to interface with EEGlab and make these plots with FT structured data? > I scripted some code outside of FT to make this kind of figure but they didn't look as nice - neither the code nor the figure :) > I've never tried exporting from FT to EEGlab, maybe that's the only way to go about... but if anyone has thought about this as well, I'd be happy to hear. > > The other thing I was wondering about is whether it'd work to make the same kind of figure but instead of using single-trial phase-locked activity, I'd use single-trial alpha power over time (averaged over a frequency range) instead. > The problem I have in this case is that I don't have a valid baseline period to normalise against. I was reading some earlier threads about power normalisation (e.g., http://mailman.science.ru.nl/pipermail/fieldtrip/2012-March/004862.html) but many of the suggestions made still rely on pre- vs. post-stimulus normalisation. The usual (cond1 - cond2) / (cond1 + cond2) and its variations won't work here either since it's single-trial data. Should I give up or is there something I actually could do? > > I'm looking forward to hearing any thoughts you may want to share! > Cheers, Vitória > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From ww.peng0923 at gmail.com Tue Nov 19 13:50:18 2013 From: ww.peng0923 at gmail.com (PWW) Date: Tue, 19 Nov 2013 13:50:18 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source Message-ID: Dear Fieldtrippers, In the beamformer tutorial ( http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of (post-pre)/pre was calculated to circumvent the noise bias towards the center of the head. However, I wonder whether it is possible to only localize the pre-stimulus oscillation source, such as pre-stimulus alpha power for example, just like localizing the sources of spontaneous oscillatory activity. Actually, I tried to do it, and use neural activity index to remove the center of the head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't work so well. Does anyone have any suggestions about localizing the cortical sources of spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it any difference with the procedures described in the tutorial? Any pointers would be much appreciated. Thanks. Regards, Weiwei -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Tue Nov 19 14:05:37 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Tue, 19 Nov 2013 14:05:37 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source In-Reply-To: References: Message-ID: Dear Weiwei, After using cfg.dics.projectnoise = 'yes', did you also compute the "Neural Activity Index" by computing source.avg.pow = source.avg.pow ./ source.avg.noise? If not, the noise estimate remains unused. Best, Eelke On 19 November 2013 13:50, PWW wrote: > Dear Fieldtrippers, > > In the beamformer tutorial > (http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of > (post-pre)/pre was calculated to circumvent the noise bias towards the > center of the head. > > However, I wonder whether it is possible to only localize the pre-stimulus > oscillation source, such as pre-stimulus alpha power for example, just like > localizing the sources of spontaneous oscillatory activity. Actually, I > tried to do it, and use neural activity index to remove the center of the > head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't > work so well. > > Does anyone have any suggestions about localizing the cortical sources of > spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it > any difference with the procedures described in the tutorial? > > Any pointers would be much appreciated. > > Thanks. > > Regards, > > Weiwei > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jm.horschig at donders.ru.nl Tue Nov 19 14:12:09 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Tue, 19 Nov 2013 14:12:09 +0100 Subject: [FieldTrip] beamformer to localize spontaneous oscillation source In-Reply-To: References: Message-ID: <528B63A9.4050104@donders.ru.nl> Dear Weiwei, as an alternative to computing the NAI (as Eelke pointed to), you can normalize the leadfield by settings cfg.normalize = 'yes' prior to calling ft_compute_leadfield. I've heard from high places that this works pretty well, but haven't compared both methods myself. Best, Jörn Eelke Spaak wrote: > Dear Weiwei, > > After using cfg.dics.projectnoise = 'yes', did you also compute the > "Neural Activity Index" by computing source.avg.pow = source.avg.pow > ./ source.avg.noise? If not, the noise estimate remains unused. > > Best, > Eelke > > On 19 November 2013 13:50, PWW wrote: > >> Dear Fieldtrippers, >> >> In the beamformer tutorial >> (http://fieldtrip.fcdonders.nl/tutorial/beamformer), the contrast of >> (post-pre)/pre was calculated to circumvent the noise bias towards the >> center of the head. >> >> However, I wonder whether it is possible to only localize the pre-stimulus >> oscillation source, such as pre-stimulus alpha power for example, just like >> localizing the sources of spontaneous oscillatory activity. Actually, I >> tried to do it, and use neural activity index to remove the center of the >> head bias, by setting setting cfg.dics.projectnoise='yes'. But it doesn't >> work so well. >> >> Does anyone have any suggestions about localizing the cortical sources of >> spontaneous oscillatory activity (e.g. pre-stimulus interval only)? is it >> any difference with the procedures described in the tutorial? >> >> Any pointers would be much appreciated. >> >> Thanks. >> >> Regards, >> >> Weiwei >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From jean-baptiste.versini at etu.univ-lyon1.fr Tue Nov 19 14:36:10 2013 From: jean-baptiste.versini at etu.univ-lyon1.fr (VERSINI JEAN-BAPTISTE p1207642) Date: Tue, 19 Nov 2013 13:36:10 +0000 Subject: [FieldTrip] Is it safe to overlap trials ? In-Reply-To: <5271B6068CD8D94DB8225422823792880179014E@mbx2010-02.univ-lyon1.fr> References: <5271B6068CD8D94DB8225422823792880179014E@mbx2010-02.univ-lyon1.fr> Message-ID: <5271B6068CD8D94DB82254228237928801790161@mbx2010-02.univ-lyon1.fr> Dear all, I analyze EEG data and I would like to define trials in a way that they may overlap. I know it causes some problems with the databrowser because for a given time, the sample may have different values. Apart from that, are there other things I should worry about or is it totally okay for me to overlap my trials ? If it causes some troubles I will adjust sampleinfo to fake contiguous trials but I'd like to avoid that. Regards, JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.piai.research at gmail.com Tue Nov 19 18:29:03 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Tue, 19 Nov 2013 18:29:03 +0100 Subject: [FieldTrip] failed segmentation In-Reply-To: <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> References: <528781D8.1030107@gmail.com> <1736.84.86.187.191.1384686195.squirrel@84.86.187.191> Message-ID: <528B9FDF.1010404@gmail.com> Hi Lilla and Christiano, Thanks a lot for the suggestions. I think I've managed to fix it by applying Lilla's suggestion, i.e., instead of using the tpm default, I specified the output for 'brain','skull','scalp'. Cheers, Vitória On 11/17/2013 12:03 PM, Lilla.Magyari at mpi.nl wrote: > hi Vitoria, > > is this a tpm (the default output of ft_volumesegment)? Have you also > tried to segment this mri with an output for 'brain','skull','scalp'? > because when you have a binary representation for these tissue-types, they > do not overlap, and are closed. So, I am wondering if you end up with a > brainmask which do not contain the artifact at the top of the head. > > > Lilla > > >> Hi Vitoria, >> it looks like there is an artifact on the top of the head. It happened to >> me already and I had to preprocess the mri volume by using an appropriate >> cutoff and by thresholding (after plotting the histogram of the grey >> levels). >> >> mri.anatomy = (mri.anatomy>thr).*mri.anatomy; >> >> or >> >> mri.anatomy(:,:,230:256) = 0; >> >> If thresholding is still not effective you might consider applying >> morphological operators (erode, dilate, open, close), after taking care >> that you voxel dimensions are cubic (diagonal values of the canonic form >> of >> mri.transform(1:3,1:3) are all the same). I use ft_volumereslice for that. >> >> I hope this helps, >> Cristiano >> >> >> >> On Sat, Nov 16, 2013 at 9:31 AM, Vitoria Piai >> wrote: >> >>> Hi all, >>> >>> has anyone ever had a failed segmentation that looks like the one in the >>> figure? >>> My script works for all participants, I mean, for all other participants >>> the brain is only inside the skull :) >>> But it fails terribly for this one. I thought it could have to do with >>> the >>> placement of the fiducials, and I've played around a bit with that but >>> it >>> didn't solve the problem. >>> If anyone recognises this type of error, I'd be help to hear if/how it >>> can >>> be fixed. >>> >>> Thanks a lot, Vitória >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From mcgoiv0 at wfu.edu Tue Nov 19 20:01:17 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Tue, 19 Nov 2013 14:01:17 -0500 Subject: [FieldTrip] head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Thank you Arjen for clarifications, Bcs the output is in the trial format anyway, technically, I can proceed with the head motion regression method on the resting state by dividing the data into smaller segments; which I did. I have 120 sec of MEG data (SR=600 Hz) that I divided into 10, or 20, or 30 sec trials and run the ft_regressconfound. Every time I run into the out of memory problem. Matlab error message: ??? Error using==>mldivide Out of memory. Error in ==> ft_regressconfound at 213 beta = regr\dat; % B= X\Y The error appears in the part of the code where the linear equation is solved directly. I tried to only work with a subset of all trials (half for example) with no luck. I rum MatlabR2010a on Windows XP 32-bit with the following memory allocation in Matlab: Max possible array: 851 Mb Memory available for all array: 1703 Mb Memory used by Matlab: 850 Mb RAM: 3317 Mb Were anybody else able to run this motion regression algorithm in Matlab without out of memory? Is there anything I can do to avoid the problem? I can share the code if needed. Thanks in advance, Inna Inna McGowin On Mon, Nov 18, 2013 at 10:42 AM, Arjen Stolk wrote: > Hi Inna, > Ft_regressconfound will remove trial by trial variability of signal > amplitude or frequency power that can be explained by variability in head > position over those trials. The input, whether sensor or source level, > should contain a trial field (keep trials in the previous step - eg at > timelockanalysis). Also variance due to head position can only be reliably > estimated when the neural signal is consistent over trials (as with an > event related modulation or potential). I would not know how to segment a > resting state into trials (for further analysis, given that those analyses > typically involve connectivity measures over the resting period) but if you > an idea on how to do this, you could give ft_regressconfound a try. Note > that the output will also be in the trials format. Hope this has made its > use a bit more clear. Yours, arjen > > Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het > volgende: > > > > > Hello everybody, > > > > I would like to use the ft_regressconfound function to remove/reduce > the head motion in a continuous MEG data. > > It's a resting state data and no averaging can be applied. Is there a > way to apply the correction without using the > > > > ft_timelockanalysis(cfg, data) function? > > > > I understand that the ft_regressconfound function has limits and caveats > but I still would like to see the results of its correction. > > > > > > Another way to ask this question is: > > what is the format/structure of the second input (timelock) in the > > ft_regressconfound(cfg, timelock) function and how it can be created > without ft_timelockanalysis? > > > > > > Thanks, > > > > Inna > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Wed Nov 20 20:08:53 2013 From: mcantor at umich.edu (Max Cantor) Date: Wed, 20 Nov 2013 14:08:53 -0500 Subject: [FieldTrip] ft_channelrepair not finding electrodes In-Reply-To: <5289E8C4.9060605@donders.ru.nl> References: <5289E8C4.9060605@donders.ru.nl> Message-ID: Hi Jorn, Sorry for the late response. I had to create a template for our cap, which had it's own issues, but I think at this point I have it working. Even if there are still some trigonometric issues, at the very least I have the fieldtrip issue resolved. For future reference, because I don't remember seeing anything on the fieldtrip FAQ about this and it may be useful to somebody else, the important thing is to turn the phi/theta from degrees into radians, and then applying a trigonometric function to get the X, Y, and Z coordinates. You can do all of these steps in 3 excel functions: X = COS(RADIANS(Phi))*SIN(RADIANS(Theta)) Y = SIN(RADIANS(Theta))*SIN(RADIANS(Phi)) Z = =COS(RADIANS(Theta)) This link on the easycap website ( http://www.easycap.de/easycap/e/downloads/how_to_read_3d.htm) explains the coordinate system. I then typed up the channel name, x, y, and z coordinates in a four column notepad document saved as a .sfp file, and used that as my cfg.elecfile. Thank you for the support, Max On Mon, Nov 18, 2013 at 5:15 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl> wrote: > Hi Max, > > check out Fieldtrip/template/electrode and see if you can use one of the > templates in there. Best would be to use electrode measurements that you > actually performed yourself (to get the distances between electrodes > right), but using a template might be good as well. Once you found a good > template-file, you can set cfg.elecfile = 'folder/filename' and FieldTrip > will handle the rest. > Otherwise, if some of your colleagues have electrode measurements, you can > also ask them for advice. > > Best, > Jörn > > > On 11/15/2013 5:40 PM, Max Cantor wrote: > > Hi all, > > I'm trying to perform channel repair on EEG data that has undergone > jump, muscle, and visual artifact rejection, and ICA to remove eog and ecg > components, unmixed back into the original channels. It's a 61 channel > system using a modified easycap layout and neighbours template. > > The layout has been shown to work on topographic displays, and the > template seems to work in that it creates a neighbours object when > ft_prepare_neighbours is run on it without any errors. > > However, I'm getting an error when I attempt to run ft_channelrepair: > > Error using ft_fetch_sens (line 179) > no electrodes or gradiometers specified. > > Error in ft_channelrepair (line 112) > sens = ft_fetch_sens(cfg, data); > > I'm not currently using ft_datatype_sens or ft_read_sens, as I'm not > really sure what elec/sens file I should be reading or how to go about > creating it. I was hoping that the template, my data, and/or the layout > would contain the necessary information, but given the error on > ft_fetch_sens, that doesn't seem to be the case. > > Any help on this issue would be greatly appreciated. > > Thanks, > > Max > > > _______________________________________________ > fieldtrip mailing listfieldtrip at donders.ru.nlhttp://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From polomacnenad at gmail.com Thu Nov 21 12:29:32 2013 From: polomacnenad at gmail.com (Nenad Polomac) Date: Thu, 21 Nov 2013 12:29:32 +0100 Subject: [FieldTrip] ft_databrowser doesnt plot channel names Message-ID: Hi, I just realized that ft_databrowser in FT version 20131120 for some reason doesn't plot labels of the channels on y axis. Earlier version works fine. I have also read http://bugzilla.fcdonders.nl/show_bug.cgi?id=2065 cfg=[]; cfg.viewmode ='vertical'; cfg.plotlabels = 'yes'; cfg.eegscale=.5; cfg.trl = 'all'; cfg.continuous = 'no'; cfg.channel ='EEG'; ft_databrowser(cfg, data); My guess is something is wrong with the line 1696 of the ft_databrowser ft_plot_text(labelx(laysel), labely(laysel), opt.hdr.label(chanindx(i)), 'tag', 'chanlabel', 'HorizontalAlignment', 'right','interpreter','none','FontUnits','normalized','FontSize',8); It is not that I urgently need this, I just wanted to contribute a little. :) all the best! Nenad -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.brovelli at univ-amu.fr Thu Nov 21 15:41:25 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Thu, 21 Nov 2013 15:41:25 +0100 (CET) Subject: [FieldTrip] Conjunction analysis Message-ID: <1795812587.19187.1385044885611.JavaMail.root@bureau-frontal1> Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea From a.stolk8 at gmail.com Thu Nov 21 16:35:37 2013 From: a.stolk8 at gmail.com (A.stolk) Date: Thu, 21 Nov 2013 08:35:37 -0700 Subject: [FieldTrip] Conjunction analysis Message-ID: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjenandrea brovelli schreef:Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea.brovelli at univ-amu.fr Thu Nov 21 16:58:54 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Thu, 21 Nov 2013 16:58:54 +0100 (CET) Subject: [FieldTrip] Conjunction analysis In-Reply-To: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> References: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> Message-ID: <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> Thanks a lot for your reply, Arjen. It's clearer now. In fact, I am using a parametric tests, so I think I would need to use the Nichols 2005 method for the conjunction analysis. Does anyone have the code to do this or does anyone know how to recover it within SPM ? Thanks a lot Andrea "A.stolk" wrote:Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjen andrea brovelli schreef: Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Thu Nov 21 17:36:38 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 21 Nov 2013 17:36:38 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? Message-ID: Fellow FieldTrippers, Currently I am looking at a contrast for left- versus right-hand index finger button presses. As expected, on sensor level (combined planar gradient, grand average) I see a clear lateralisation in beta band power starting at least 0.5s before the button press (see https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is clearly more beta power ipsilateral to the response hand. I would prefer to do further analyses on source level, so I attempt to reconstruct the sources for this effect using DICS beamformer (common filter, applied to both conditions separately; fixedori and realfilter = 'yes'). The grand average results for this (again contrast left vs right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the R/L-flip, this is radiological convention.) As you can see, the source level solution is much more blurry than on sensor level. This picture is without using any regularisation (lambda parameter), the results are even worse when I use lambda = '5%'. The negative blob (right hand higher power than left) becomes 'marginally significant' on source level (p ~ 0.06) where it was p < 0.001 on sensor level. The positive blob is nowhere near significant. Also, the individual results are much less topographically consistent on source than on sensor level (explaining the worse statistics). I have checked the segmentation of my MRIs, the 'gray' seems to be nicely within the head all the time. Also, I have manually verified the alignment of headmodel, sourcemodel, and gradiometer information for all subjects. As a final note, the above sensor-level plot was taken from a 'slice' out of a planar-gradient time-frequency analysis (mtmconvol). The ingredient for the beamformer was an mtmfft fourier spectrum on the axial gradiometer data, obtained for just the time-frequency range of interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). When I compute condition-averaged power based on these fourier spectra and look at the contrast, the results are again as expected: https://db.tt/n2P3UKcQ (of course less localised because of axial gradient vs planar). The freq structures underlying this contrast are exactly the same as those going into ft_sourceanalysis, so the problem must be in the source analysis step (and/or in the preparation of the geometric information, although these seem fine by visual inspection). Does anyone have any idea that might explain these seemingly contradictory results? I would have expected demixing to improve signal-to-noise ratio, rather than worsen it. Thanks! Best, Eelke From v.piai.research at gmail.com Thu Nov 21 17:51:00 2013 From: v.piai.research at gmail.com (Vitoria Piai) Date: Thu, 21 Nov 2013 17:51:00 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: <528E39F4.9070105@gmail.com> Hi all, Eelke, Maybe adding to Eelke's remark, although I'm not working with motor beta activity and lateralised index. I'm also using DICS and my very clear, focal sensor-level effects all of a sudden become localised to the whole brain or a whole hemisphere! I happen to have heard from Jan-Mathijs that there may something going on at the moment, but at least for now, Eelke, I don't think this error is unique to our data (and I was actually going to post my incompatible sensor-source results here soon, so now it's less work for me :) Looking forward to hearing your updates, (I'm interrupting my source-level analyses for the time to get a better feeling for the sensor-level data first) Vitória On 21-11-2013 17:36, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Vitória Piai PhD Candidate Donders Institute for Brain, Cognition and Behaviour Centre for Cognition, Radboud University Nijmegen Montessorilaan 3, B.01.05 6525 HR Nijmegen The Netherlands Email : V.piai at donders.ru.nl Phone : +31 24 3612635 www.vitoriapiai.com From eelke.spaak at donders.ru.nl Thu Nov 21 18:27:43 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 21 Nov 2013 18:27:43 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <528E39F4.9070105@gmail.com> References: <528E39F4.9070105@gmail.com> Message-ID: Thanks for the input Vitória. Are you using Fourier input to sourceanalysis, or 'powandcsd'? I'm wondering whether the csd computation inside sourceanalysis might be to blame. Will investigate this tomorrow :) Eelke On Nov 21, 2013 6:01 PM, "Vitoria Piai" wrote: > Hi all, Eelke, > > Maybe adding to Eelke's remark, although I'm not working with motor beta > activity and lateralised index. > I'm also using DICS and my very clear, focal sensor-level effects all of a > sudden become localised to the whole brain or a whole hemisphere! > I happen to have heard from Jan-Mathijs that there may something going on > at the moment, but at least for now, Eelke, I don't think this error is > unique to our data (and I was actually going to post my incompatible > sensor-source results here soon, so now it's less work for me :) > > Looking forward to hearing your updates, > (I'm interrupting my source-level analyses for the time to get a better > feeling for the sensor-level data first) > Vitória > > On 21-11-2013 17:36, Eelke Spaak wrote: > >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus right-hand index >> finger button presses. As expected, on sensor level (combined planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer (common >> filter, applied to both conditions separately; fixedori and realfilter >> = 'yes'). The grand average results for this (again contrast left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry than on >> sensor level. This picture is without using any regularisation (lambda >> parameter), the results are even worse when I use lambda = '5%'. The >> negative blob (right hand higher power than left) becomes 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. Also, the >> individual results are much less topographically consistent on source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually verified >> the alignment of headmodel, sourcemodel, and gradiometer information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum on the >> axial gradiometer data, obtained for just the time-frequency range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this contrast are >> exactly the same as those going into ft_sourceanalysis, so the problem >> must be in the source analysis step (and/or in the preparation of the >> geometric information, although these seem fine by visual inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Vitória Piai > PhD Candidate > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognition, Radboud University Nijmegen > Montessorilaan 3, B.01.05 > 6525 HR Nijmegen > The Netherlands > > Email : V.piai at donders.ru.nl > Phone : +31 24 3612635 > www.vitoriapiai.com > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Thu Nov 21 19:39:30 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Thu, 21 Nov 2013 13:39:30 -0500 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Dear Eelke, very interesting topic. Please find my two cents below: On Thu, Nov 21, 2013 at 11:36 AM, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > There might be issues with: - head positions/distance of single subjects in the dewar - something happening in the transition axial -> planar gradiometers conversion - orientation of the brain motor sources - inverse problem reconstruction - magnitude of the power effects for the different subjects - forward model issues Let me comment briefly on point 4. If the sources in the motor cortex are bilateral (as expected to different extents from ipsi to contra) and are temporally correlated, this constitutes an issue for the beamformer algorithm (van Veen et al.1993) especially if the sources are near (and lead fields highly correlated). There are workarounds to localize the single contributions of primary/secondary motor sources, but this implies the use of regional suppression (a nulling beamformer) and it is a tedious procedure to apply. Might be worth to look into that though. Let me know if you have interest in this. > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > On this point: using regularization is useful to invert the real(csd) matrix if it is ill-conditioned, but might blur the source reconstruction. On the other hand not using it might also be detrimental on the source reconstruction. Therefore applying it depends on the condition number of your csd. Is the matrix full rank? If not you might consider regularizing. Did you previously use ICA/PCA to get rid of artifacts? If yes that will have a negative effect on the condition number. and you might consider cranking down the ICA components rejection to the big spiky components -if any- and let the beamformer filter reject the smaller ones (in magnitude). Are you using cluster statistics based on the maxval? Maybe another statistics might give different results, given that the maxval might be due to artifacts (muscular, heart, ...) > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > Do all subjects sit with the top of the head at the same distance from the dewar? This is easily visualized by plotting the headmodel together with the head coordinates' sensors. By experience with CTF systems not all subjects' heads are at the same distance from the top (because they slip down, or they reposition 'cause they can't see out of the dewar, they also move!). This might hinder the SNR of the raw data to start with. It seems the grand average is still significant, but might be due to the contribution of a few good subjects. You may also want to consider the movement correction GLM method at the source level. Maybe it gives you back some SNR. > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > Yes, but it can also depend on different extents from FFT-level analysis. Have you played around with spectral smoothing, by for example lowering the number of tapers, or changing to a single condition contrast like activation vs baseline in the beamformer? What is the grand average vs single subject lateralization effect/single condition effect/ planar or axial effect? Is it there for all single subjects? I hope the comments helped a bit. All the best! Cristiano > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stan.vanpelt at fcdonders.ru.nl Thu Nov 21 21:45:49 2013 From: stan.vanpelt at fcdonders.ru.nl (Stan van Pelt) Date: Thu, 21 Nov 2013 21:45:49 +0100 (CET) Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: Message-ID: <513733919.261511.1385066749005.JavaMail.root@indus.zimbra.ru.nl> Hi Eelke, Have you tried comparing the results with a time-domain beamformer? You could e.g. try LCMV on 15-25Hz-bandpassed data. This should give you in theory similar results. Best, Stan ----- Oorspronkelijk bericht ----- > Van: "Eelke Spaak" > Aan: "FieldTrip discussion list" > Verzonden: Donderdag 21 november 2013 18:27:43 > Onderwerp: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Thanks for the input Vitória. Are you using Fourier input to > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd > computation inside sourceanalysis might be to blame. Will investigate > this tomorrow :) > Eelke > On Nov 21, 2013 6:01 PM, "Vitoria Piai" < v.piai.research at gmail.com > > wrote: > > Hi all, Eelke, > > Maybe adding to Eelke's remark, although I'm not working with motor > > beta activity and lateralised index. > > I'm also using DICS and my very clear, focal sensor-level effects > > all > > of a sudden become localised to the whole brain or a whole > > hemisphere! > > I happen to have heard from Jan-Mathijs that there may something > > going > > on at the moment, but at least for now, Eelke, I don't think this > > error is unique to our data (and I was actually going to post my > > incompatible sensor-source results here soon, so now it's less work > > for me :) > > Looking forward to hearing your updates, > > (I'm interrupting my source-level analyses for the time to get a > > better feeling for the sensor-level data first) > > Vitória > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > Fellow FieldTrippers, > > > Currently I am looking at a contrast for left- versus right-hand > > > index > > > finger button presses. As expected, on sensor level (combined > > > planar > > > gradient, grand average) I see a clear lateralisation in beta band > > > power starting at least 0.5s before the button press (see > > > https://db.tt/Rtch3Qjy ). Both 'blobs' are significant; there is > > > clearly more beta power ipsilateral to the response hand. I would > > > prefer to do further analyses on source level, so I attempt to > > > reconstruct the sources for this effect using DICS beamformer > > > (common > > > filter, applied to both conditions separately; fixedori and > > > realfilter > > > = 'yes'). The grand average results for this (again contrast left > > > vs > > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore > > > the > > > R/L-flip, this is radiological convention.) > > > As you can see, the source level solution is much more blurry than > > > on > > > sensor level. This picture is without using any regularisation > > > (lambda > > > parameter), the results are even worse when I use lambda = '5%'. > > > The > > > negative blob (right hand higher power than left) becomes > > > 'marginally > > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > > sensor level. The positive blob is nowhere near significant. Also, > > > the > > > individual results are much less topographically consistent on > > > source > > > than on sensor level (explaining the worse statistics). > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > > nicely within the head all the time. Also, I have manually > > > verified > > > the alignment of headmodel, sourcemodel, and gradiometer > > > information > > > for all subjects. > > > As a final note, the above sensor-level plot was taken from a > > > 'slice' > > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > > ingredient for the beamformer was an mtmfft fourier spectrum on > > > the > > > axial gradiometer data, obtained for just the time-frequency range > > > of > > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = > > > 7). > > > When I compute condition-averaged power based on these fourier > > > spectra > > > and look at the contrast, the results are again as expected: > > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > > gradient vs planar). The freq structures underlying this contrast > > > are > > > exactly the same as those going into ft_sourceanalysis, so the > > > problem > > > must be in the source analysis step (and/or in the preparation of > > > the > > > geometric information, although these seem fine by visual > > > inspection). > > > Does anyone have any idea that might explain these seemingly > > > contradictory results? I would have expected demixing to improve > > > signal-to-noise ratio, rather than worsen it. > > > Thanks! > > > Best, > > > Eelke > > > ______________________________ _________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > -- > > Vitória Piai > > PhD Candidate > > Donders Institute for Brain, Cognition and Behaviour > > Centre for Cognition, Radboud University Nijmegen > > Montessorilaan 3, B.01.05 > > 6525 HR Nijmegen > > The Netherlands > > Email : V.piai at donders.ru.nl > > Phone : +31 24 3612635 > > www.vitoriapiai.com > > ______________________________ _________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour Centre for Cognition Montessorilaan 3, B.01.19 6525 HR Nijmegen tel: 024-3616288 -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiteng.jiang at gmail.com Thu Nov 21 22:49:50 2013 From: haiteng.jiang at gmail.com (Haiteng Jiang) Date: Thu, 21 Nov 2013 22:49:50 +0100 Subject: [FieldTrip] =?utf-8?q?Motor_beta_activity_-_DICS_solution_more_no?= =?utf-8?q?isy_than_=E3=80=80sensor_data=3F?= Message-ID: On 21 November 2013 21:46, wrote: > Send fieldtrip mailing list submissions to > fieldtrip at science.ru.nl > > To subscribe or unsubscribe via the World Wide Web, visit > http://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. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Eelke Spaak) > 2. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Cristiano Micheli) > 3. Re: Motor beta activity - DICS solution more noisy than > sensor data? (Stan van Pelt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Nov 2013 18:27:43 +0100 > From: Eelke Spaak > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > zBvahNkAp9rO9LTRimRWR09GbeC3vfEv1sXHg at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thanks for the input Vit?ria. Are you using Fourier input to > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd computation > inside sourceanalysis might be to blame. Will investigate this tomorrow :) > > Eelke > On Nov 21, 2013 6:01 PM, "Vitoria Piai" wrote: > > > Hi all, Eelke, > > > > Maybe adding to Eelke's remark, although I'm not working with motor beta > > activity and lateralised index. > > I'm also using DICS and my very clear, focal sensor-level effects all of > a > > sudden become localised to the whole brain or a whole hemisphere! > > I happen to have heard from Jan-Mathijs that there may something going on > > at the moment, but at least for now, Eelke, I don't think this error is > > unique to our data (and I was actually going to post my incompatible > > sensor-source results here soon, so now it's less work for me :) > > > > Looking forward to hearing your updates, > > (I'm interrupting my source-level analyses for the time to get a better > > feeling for the sensor-level data first) > > Vit?ria > > > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > >> Fellow FieldTrippers, > >> > >> Currently I am looking at a contrast for left- versus right-hand index > >> finger button presses. As expected, on sensor level (combined planar > >> gradient, grand average) I see a clear lateralisation in beta band > >> power starting at least 0.5s before the button press (see > >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > >> clearly more beta power ipsilateral to the response hand. I would > >> prefer to do further analyses on source level, so I attempt to > >> reconstruct the sources for this effect using DICS beamformer (common > >> filter, applied to both conditions separately; fixedori and realfilter > >> = 'yes'). The grand average results for this (again contrast left vs > >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > >> R/L-flip, this is radiological convention.) > >> > >> As you can see, the source level solution is much more blurry than on > >> sensor level. This picture is without using any regularisation (lambda > >> parameter), the results are even worse when I use lambda = '5%'. The > >> negative blob (right hand higher power than left) becomes 'marginally > >> significant' on source level (p ~ 0.06) where it was p < 0.001 on > >> sensor level. The positive blob is nowhere near significant. Also, the > >> individual results are much less topographically consistent on source > >> than on sensor level (explaining the worse statistics). > >> > >> I have checked the segmentation of my MRIs, the 'gray' seems to be > >> nicely within the head all the time. Also, I have manually verified > >> the alignment of headmodel, sourcemodel, and gradiometer information > >> for all subjects. > >> > >> As a final note, the above sensor-level plot was taken from a 'slice' > >> out of a planar-gradient time-frequency analysis (mtmconvol). The > >> ingredient for the beamformer was an mtmfft fourier spectrum on the > >> axial gradiometer data, obtained for just the time-frequency range of > >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > >> When I compute condition-averaged power based on these fourier spectra > >> and look at the contrast, the results are again as expected: > >> https://db.tt/n2P3UKcQ (of course less localised because of axial > >> gradient vs planar). The freq structures underlying this contrast are > >> exactly the same as those going into ft_sourceanalysis, so the problem > >> must be in the source analysis step (and/or in the preparation of the > >> geometric information, although these seem fine by visual inspection). > >> > >> Does anyone have any idea that might explain these seemingly > >> contradictory results? I would have expected demixing to improve > >> signal-to-noise ratio, rather than worsen it. > >> > >> Thanks! > >> Best, > >> Eelke > >> _______________________________________________ > >> fieldtrip mailing list > >> fieldtrip at donders.ru.nl > >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > > > > > > -- > > Vit?ria Piai > > PhD Candidate > > Donders Institute for Brain, Cognition and Behaviour > > Centre for Cognition, Radboud University Nijmegen > > Montessorilaan 3, B.01.05 > > 6525 HR Nijmegen > > The Netherlands > > > > Email : V.piai at donders.ru.nl > > Phone : +31 24 3612635 > > www.vitoriapiai.com > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/00fab2a3/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 21 Nov 2013 13:39:30 -0500 > From: Cristiano Micheli > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > < > CADW7XCCf9aAPYFTF9iCuMnRgYHA6hhoPBbex0ihkJNB_b3ah5Q at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Dear Eelke, very interesting topic. Please find my two cents below: > > > On Thu, Nov 21, 2013 at 11:36 AM, Eelke Spaak >wrote: > > > Fellow FieldTrippers, > > > > Currently I am looking at a contrast for left- versus right-hand index > > finger button presses. As expected, on sensor level (combined planar > > gradient, grand average) I see a clear lateralisation in beta band > > power starting at least 0.5s before the button press (see > > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > > clearly more beta power ipsilateral to the response hand. I would > > prefer to do further analyses on source level, so I attempt to > > reconstruct the sources for this effect using DICS beamformer (common > > filter, applied to both conditions separately; fixedori and realfilter > > = 'yes'). The grand average results for this (again contrast left vs > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > > R/L-flip, this is radiological convention.) > > > > > There might be issues with: > - head positions/distance of single subjects in the dewar > - something happening in the transition axial -> planar gradiometers > conversion > - orientation of the brain motor sources > - inverse problem reconstruction > - magnitude of the power effects for the different subjects > - forward model issues > > Let me comment briefly on point 4. If the sources in the motor cortex are > bilateral (as expected to different extents from ipsi to contra) and are > temporally correlated, this constitutes an issue for the beamformer > algorithm (van Veen et al.1993) especially if the sources are near (and > lead fields highly correlated). > There are workarounds to localize the single contributions of > primary/secondary motor sources, but this implies the use of regional > suppression (a nulling beamformer) and it is a tedious procedure to apply. > Might be worth to look into that though. Let me know if you have interest > in this. > > > > > As you can see, the source level solution is much more blurry than on > > sensor level. This picture is without using any regularisation (lambda > > parameter), the results are even worse when I use lambda = '5%'. The > > negative blob (right hand higher power than left) becomes 'marginally > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > sensor level. The positive blob is nowhere near significant. Also, the > > individual results are much less topographically consistent on source > > than on sensor level (explaining the worse statistics). > > > > On this point: using regularization is useful to invert the real(csd) > matrix if it is ill-conditioned, but might blur the source reconstruction. > On the other hand not using it might also be detrimental on the source > reconstruction. Therefore applying it depends on the condition number of > your csd. Is the matrix full rank? If not you might consider regularizing. > Did you previously use ICA/PCA to get rid of artifacts? If yes that will > have a negative effect on the condition number. and you might consider > cranking down the ICA components rejection to the big spiky components -if > any- and let the beamformer filter reject the smaller ones (in magnitude). > Are you using cluster statistics based on the maxval? Maybe another > statistics might give different results, given that the maxval might be due > to artifacts (muscular, heart, ...) > > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > nicely within the head all the time. Also, I have manually verified > > the alignment of headmodel, sourcemodel, and gradiometer information > > for all subjects. > > > > Do all subjects sit with the top of the head at the same distance from the > dewar? This is easily visualized by plotting the headmodel together with > the head coordinates' sensors. > By experience with CTF systems not all subjects' heads are at the same > distance from the top (because they slip down, or they reposition 'cause > they can't see out of the dewar, they also move!). This might hinder the > SNR of the raw data to start with. > It seems the grand average is still significant, but might be due to the > contribution of a few good subjects. > You may also want to consider the movement correction GLM method at the > source level. Maybe it gives you back some SNR. > > > > As a final note, the above sensor-level plot was taken from a 'slice' > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > ingredient for the beamformer was an mtmfft fourier spectrum on the > > axial gradiometer data, obtained for just the time-frequency range of > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > > When I compute condition-averaged power based on these fourier spectra > > and look at the contrast, the results are again as expected: > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > gradient vs planar). The freq structures underlying this contrast are > > exactly the same as those going into ft_sourceanalysis, so the problem > > must be in the source analysis step (and/or in the preparation of the > > geometric information, although these seem fine by visual inspection). > > > > Does anyone have any idea that might explain these seemingly > > contradictory results? I would have expected demixing to improve > > signal-to-noise ratio, rather than worsen it. > > > > Yes, but it can also depend on different extents from FFT-level analysis. > Have you played around with spectral smoothing, by for example lowering the > number of tapers, or changing to a single condition contrast like > activation vs baseline in the beamformer? > What is the grand average vs single subject lateralization effect/single > condition effect/ planar or axial effect? Is it there for all single > subjects? > > I hope the comments helped a bit. > > All the best! > Cristiano > > > > > > Thanks! > > Best, > > Eelke > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/283a4f1b/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Nov 2013 21:45:49 +0100 (CET) > From: Stan van Pelt > To: FieldTrip discussion list > Subject: Re: [FieldTrip] Motor beta activity - DICS solution more > noisy than sensor data? > Message-ID: > <513733919.261511.1385066749005.JavaMail.root at indus.zimbra.ru.nl> > Content-Type: text/plain; charset="utf-8" > > Hi Eelke, Have you tried comparing the results with a time-domain > beamformer? You could e.g. try LCMV on 15-25Hz-bandpassed data. This should > give you in theory similar results. Best, Stan ----- Oorspronkelijk bericht > ----- > > Van: "Eelke Spaak" > > Aan: "FieldTrip discussion list" > > Verzonden: Donderdag 21 november 2013 18:27:43 > > Onderwerp: Re: [FieldTrip] Motor beta activity - DICS solution more > > noisy than sensor data? > > Thanks for the input Vit?ria. Are you using Fourier input to > > sourceanalysis, or 'powandcsd'? I'm wondering whether the csd > > computation inside sourceanalysis might be to blame. Will investigate > > this tomorrow :) > > Eelke > > On Nov 21, 2013 6:01 PM, "Vitoria Piai" < v.piai.research at gmail.com > > > wrote: > > > Hi all, Eelke, > > > Maybe adding to Eelke's remark, although I'm not working with motor > > > beta activity and lateralised index. > > > I'm also using DICS and my very clear, focal sensor-level effects > > > all > > > of a sudden become localised to the whole brain or a whole > > > hemisphere! > > > I happen to have heard from Jan-Mathijs that there may something > > > going > > > on at the moment, but at least for now, Eelke, I don't think this > > > error is unique to our data (and I was actually going to post my > > > incompatible sensor-source results here soon, so now it's less work > > > for me :) > > > Looking forward to hearing your updates, > > > (I'm interrupting my source-level analyses for the time to get a > > > better feeling for the sensor-level data first) > > > Vit?ria > > > On 21-11-2013 17:36, Eelke Spaak wrote: > > > > Fellow FieldTrippers, > > > > Currently I am looking at a contrast for left- versus right-hand > > > > index > > > > finger button presses. As expected, on sensor level (combined > > > > planar > > > > gradient, grand average) I see a clear lateralisation in beta band > > > > power starting at least 0.5s before the button press (see > > > > https://db.tt/Rtch3Qjy ). Both 'blobs' are significant; there is > > > > clearly more beta power ipsilateral to the response hand. I would > > > > prefer to do further analyses on source level, so I attempt to > > > > reconstruct the sources for this effect using DICS beamformer > > > > (common > > > > filter, applied to both conditions separately; fixedori and > > > > realfilter > > > > = 'yes'). The grand average results for this (again contrast left > > > > vs > > > > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore > > > > the > > > > R/L-flip, this is radiological convention.) > > > > As you can see, the source level solution is much more blurry than > > > > on > > > > sensor level. This picture is without using any regularisation > > > > (lambda > > > > parameter), the results are even worse when I use lambda = '5%'. > > > > The > > > > negative blob (right hand higher power than left) becomes > > > > 'marginally > > > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > > > sensor level. The positive blob is nowhere near significant. Also, > > > > the > > > > individual results are much less topographically consistent on > > > > source > > > > than on sensor level (explaining the worse statistics). > > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > > > nicely within the head all the time. Also, I have manually > > > > verified > > > > the alignment of headmodel, sourcemodel, and gradiometer > > > > information > > > > for all subjects. > > > > As a final note, the above sensor-level plot was taken from a > > > > 'slice' > > > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > > > ingredient for the beamformer was an mtmfft fourier spectrum on > > > > the > > > > axial gradiometer data, obtained for just the time-frequency range > > > > of > > > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = > > > > 7). > > > > When I compute condition-averaged power based on these fourier > > > > spectra > > > > and look at the contrast, the results are again as expected: > > > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > > > gradient vs planar). The freq structures underlying this contrast > > > > are > > > > exactly the same as those going into ft_sourceanalysis, so the > > > > problem > > > > must be in the source analysis step (and/or in the preparation of > > > > the > > > > geometric information, although these seem fine by visual > > > > inspection). > > > > Does anyone have any idea that might explain these seemingly > > > > contradictory results? I would have expected demixing to improve > > > > signal-to-noise ratio, rather than worsen it. > > > > Thanks! > > > > Best, > > > > Eelke > > > > ______________________________ _________________ > > > > fieldtrip mailing list > > > > fieldtrip at donders.ru.nl > > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > > -- > > > Vit?ria Piai > > > PhD Candidate > > > Donders Institute for Brain, Cognition and Behaviour > > > Centre for Cognition, Radboud University Nijmegen > > > Montessorilaan 3, B.01.05 > > > 6525 HR Nijmegen > > > The Netherlands > > > Email : V.piai at donders.ru.nl > > > Phone : +31 24 3612635 > > > www.vitoriapiai.com > > > ______________________________ _________________ > > > fieldtrip mailing list > > > fieldtrip at donders.ru.nl > > > http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Stan van Pelt, PhD Donders Institute for Brain, Cognition and Behaviour > Centre for Cognition Montessorilaan 3, B.01.19 6525 HR Nijmegen tel: > 024-3616288 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131121/60bb5dee/attachment.html > > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 36, Issue 34 > ***************************************** > -- Haiteng Jiang PhD candidate Neuronal Oscillations Group Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Visiting address Room 2.32 Donders Centre for Cognitive Neuroimaging Kapittelweg 29 6525 EN Nijmegen the Netherlands Tel.: +31 (0)243668291 Web: https://sites.google.com/site/haitengjiang/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From haristz at gmail.com Fri Nov 22 01:09:36 2013 From: haristz at gmail.com (Charidimos Tzagarakis) Date: Thu, 21 Nov 2013 18:09:36 -0600 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Hi Eelke, Provided there is no major recent revision of the DICS code, I would have expected motor desynchronisation to show up pretty well. Are the maps shown at source and channel level straight differences of L and Right hand conditions at the beta band (I hope I am correctly interpreting your paradigm) ? If so it might be helpful in pinpointing the problem/as a sanity check to see what happens when you use beta desynchonisation (ie change relative to the baseline) instead for each condition, and see source/channel maps of that separately for L and R and then when you take the difference. I suppose the main element this checks for is whether L and R conditions have the same baseline. This doesn't immediately explain why source and channel results are different but in the absence of any other clues it may be a way to 2ble check the whole process. Another point to consider is that, although beta changes should appear in all subjects, it is possibly true that there are individual differences in the actual beta range and frequency bin of maximum effect. If you are using the same settings for all subjects when you beamform with DICS you may be missing some of the effect (true, this is also the case for channel data but there may be subtle differences that add up - there are many voxels and few channels). I believe it may be useful to see what happens when you run the beamformer tailored to each subject's particular beta characteristics (ie change the "foi" for each subject, keep the tapsmofrq the same - possibly smaller) and then combine everything (you'll need of course to come up with a relative metric such as perc. change when you combine all subjects to account for the slightly different frequencies you used ) Best, Haris Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych University of Minnesota Dept of Neuroscience and Brain Sciences Center On 21 November 2013 10:36, Eelke Spaak wrote: > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus right-hand index > finger button presses. As expected, on sensor level (combined planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer (common > filter, applied to both conditions separately; fixedori and realfilter > = 'yes'). The grand average results for this (again contrast left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry than on > sensor level. This picture is without using any regularisation (lambda > parameter), the results are even worse when I use lambda = '5%'. The > negative blob (right hand higher power than left) becomes 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. Also, the > individual results are much less topographically consistent on source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually verified > the alignment of headmodel, sourcemodel, and gradiometer information > for all subjects. > > As a final note, the above sensor-level plot was taken from a 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum on the > axial gradiometer data, obtained for just the time-frequency range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). > When I compute condition-averaged power based on these fourier spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this contrast are > exactly the same as those going into ft_sourceanalysis, so the problem > must be in the source analysis step (and/or in the preparation of the > geometric information, although these seem fine by visual inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haristz at gmail.com Fri Nov 22 07:07:59 2013 From: haristz at gmail.com (Charidimos Tzagarakis) Date: Fri, 22 Nov 2013 00:07:59 -0600 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: Eelke, Thinking again about my second suggestion (regarding individual variability) I actually can't think of a case where this could realistically produce what you get. On the other hand, looking at TF maps per subject and channel (on the "helmet" layout), normalised with a "rest" epoch, may help spot something unusual. Best, Haris Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych University of Minnesota Dept of Neuroscience and Brain Sciences Center On 21 November 2013 18:09, Charidimos Tzagarakis wrote: > Hi Eelke, > Provided there is no major recent revision of the DICS code, I would have > expected motor desynchronisation to show up pretty well. Are the maps shown > at source and channel level straight differences of L and Right hand > conditions at the beta band (I hope I am correctly interpreting your > paradigm) ? If so it might be helpful in pinpointing the problem/as a > sanity check to see what happens when you use beta desynchonisation (ie > change relative to the baseline) instead for each condition, and see > source/channel maps of that separately for L and R and then when you take > the difference. I suppose the main element this checks for is whether L and > R conditions have the same baseline. > This doesn't immediately explain why source and channel results are > different but in the absence of any other clues it may be a way to 2ble > check the whole process. > > > Another point to consider is that, although beta changes should appear in > all subjects, it is possibly true that there are individual differences in > the actual beta range and frequency bin of maximum effect. If you are using > the same settings for all subjects when you beamform with DICS you may be > missing some of the effect (true, this is also the case for channel data > but there may be subtle differences that add up - there are many voxels and > few channels). I believe it may be useful to see what happens when you run > the beamformer tailored to each subject's particular beta characteristics > (ie change the "foi" for each subject, keep the tapsmofrq the same - > possibly smaller) and then combine everything (you'll need of course to > come up with a relative metric such as perc. change when you combine all > subjects to account for the slightly different frequencies you used ) > > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak wrote: > >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus right-hand index >> finger button presses. As expected, on sensor level (combined planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer (common >> filter, applied to both conditions separately; fixedori and realfilter >> = 'yes'). The grand average results for this (again contrast left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry than on >> sensor level. This picture is without using any regularisation (lambda >> parameter), the results are even worse when I use lambda = '5%'. The >> negative blob (right hand higher power than left) becomes 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. Also, the >> individual results are much less topographically consistent on source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually verified >> the alignment of headmodel, sourcemodel, and gradiometer information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum on the >> axial gradiometer data, obtained for just the time-frequency range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this contrast are >> exactly the same as those going into ft_sourceanalysis, so the problem >> must be in the source analysis step (and/or in the preparation of the >> geometric information, although these seem fine by visual inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jm.horschig at donders.ru.nl Fri Nov 22 08:06:31 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Fri, 22 Nov 2013 08:06:31 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: Message-ID: <528F0277.5070200@donders.ru.nl> Hi Eelke, since everyone jumped on the train, here my 2 cents: To verify whether this is a newly introduced bug, maybe run a tutorial test script that includes beamforming. If they look alright, it gets more likely that it is you or your data and not fieldtrip :) It's not definite evidence of course though. SinceVitoria also experiences strange things, it might be something worthwhile to investigate. My initial guess from the plots is that there is something wrong with the forward model. All unit problems should have been resolved, but just to be sure you could check whether all objects are in the same unit (make it 'cm' as the grads are). Best, Jörn Charidimos Tzagarakis wrote: > Eelke, > Thinking again about my second suggestion (regarding individual > variability) I actually can't think of a case where this could > realistically produce what you get. On the other hand, looking at TF > maps per subject and channel (on the "helmet" layout), normalised with > a "rest" epoch, may help spot something unusual. > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > On 21 November 2013 18:09, Charidimos Tzagarakis > wrote: > > Hi Eelke, > Provided there is no major recent revision of the DICS code, I > would have expected motor desynchronisation to show up pretty > well. Are the maps shown at source and channel level straight > differences of L and Right hand conditions at the beta band (I > hope I am correctly interpreting your paradigm) ? If so it might > be helpful in pinpointing the problem/as a sanity check to see > what happens when you use beta desynchonisation (ie change > relative to the baseline) instead for each condition, and see > source/channel maps of that separately for L and R and then when > you take the difference. I suppose the main element this checks > for is whether L and R conditions have the same baseline. > This doesn't immediately explain why source and channel results > are different but in the absence of any other clues it may be a > way to 2ble check the whole process. > > > Another point to consider is that, although beta changes should > appear in all subjects, it is possibly true that there are > individual differences in the actual beta range and frequency bin > of maximum effect. If you are using the same settings for all > subjects when you beamform with DICS you may be missing some of > the effect (true, this is also the case for channel data but there > may be subtle differences that add up - there are many voxels and > few channels). I believe it may be useful to see what happens when > you run the beamformer tailored to each subject's particular beta > characteristics (ie change the "foi" for each subject, keep the > tapsmofrq the same - possibly smaller) and then combine everything > (you'll need of course to come up with a relative metric such as > perc. change when you combine all subjects to account for the > slightly different frequencies you used ) > > Best, > Haris > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak > wrote: > > Fellow FieldTrippers, > > Currently I am looking at a contrast for left- versus > right-hand index > finger button presses. As expected, on sensor level (combined > planar > gradient, grand average) I see a clear lateralisation in beta band > power starting at least 0.5s before the button press (see > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > clearly more beta power ipsilateral to the response hand. I would > prefer to do further analyses on source level, so I attempt to > reconstruct the sources for this effect using DICS beamformer > (common > filter, applied to both conditions separately; fixedori and > realfilter > = 'yes'). The grand average results for this (again contrast > left vs > right response hand) are shown at https://db.tt/IBQZG0d8 . > (Ignore the > R/L-flip, this is radiological convention.) > > As you can see, the source level solution is much more blurry > than on > sensor level. This picture is without using any regularisation > (lambda > parameter), the results are even worse when I use lambda = > '5%'. The > negative blob (right hand higher power than left) becomes > 'marginally > significant' on source level (p ~ 0.06) where it was p < 0.001 on > sensor level. The positive blob is nowhere near significant. > Also, the > individual results are much less topographically consistent on > source > than on sensor level (explaining the worse statistics). > > I have checked the segmentation of my MRIs, the 'gray' seems to be > nicely within the head all the time. Also, I have manually > verified > the alignment of headmodel, sourcemodel, and gradiometer > information > for all subjects. > > As a final note, the above sensor-level plot was taken from a > 'slice' > out of a planar-gradient time-frequency analysis (mtmconvol). The > ingredient for the beamformer was an mtmfft fourier spectrum > on the > axial gradiometer data, obtained for just the time-frequency > range of > interest (subselect toilim [-0.5 0], mtmfft foi = 23, > tapsmofrq = 7). > When I compute condition-averaged power based on these fourier > spectra > and look at the contrast, the results are again as expected: > https://db.tt/n2P3UKcQ (of course less localised because of axial > gradient vs planar). The freq structures underlying this > contrast are > exactly the same as those going into ft_sourceanalysis, so the > problem > must be in the source analysis step (and/or in the preparation > of the > geometric information, although these seem fine by visual > inspection). > > Does anyone have any idea that might explain these seemingly > contradictory results? I would have expected demixing to improve > signal-to-noise ratio, rather than worsen it. > > Thanks! > Best, > Eelke > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > ------------------------------------------------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Fri Nov 22 08:41:35 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 08:41:35 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <528F0277.5070200@donders.ru.nl> References: <528F0277.5070200@donders.ru.nl> Message-ID: Hi everyone, Thanks very much for your great input so far! Actually, as Jörn suggested, I did the very straightforward check (thanks for the tip :) ) of running one of our tutorial test scripts (test_beamforming_extended), and it turns out this one does not produce the same results as depicted here: http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most likely somewhere a bug has been introduced... Hopefully I can find out what it is today and fix it. Will keep you posted! Best, Eelke On 22 November 2013 08:06, "Jörn M. Horschig" wrote: > Hi Eelke, > > since everyone jumped on the train, here my 2 cents: > To verify whether this is a newly introduced bug, maybe run a tutorial test > script that includes beamforming. If they look alright, it gets more likely > that it is you or your data and not fieldtrip :) It's not definite evidence > of course though. SinceVitoria also experiences strange things, it might be > something worthwhile to investigate. > > My initial guess from the plots is that there is something wrong with the > forward model. All unit problems should have been resolved, but just to be > sure you could check whether all objects are in the same unit (make it 'cm' > as the grads are). > > Best, > Jörn > > Charidimos Tzagarakis wrote: >> >> Eelke, >> Thinking again about my second suggestion (regarding individual >> variability) I actually can't think of a case where this could realistically >> produce what you get. On the other hand, looking at TF maps per subject and >> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >> spot something unusual. >> Best, >> Haris >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> On 21 November 2013 18:09, Charidimos Tzagarakis > > wrote: >> >> Hi Eelke, >> Provided there is no major recent revision of the DICS code, I >> would have expected motor desynchronisation to show up pretty >> well. Are the maps shown at source and channel level straight >> differences of L and Right hand conditions at the beta band (I >> hope I am correctly interpreting your paradigm) ? If so it might >> be helpful in pinpointing the problem/as a sanity check to see >> what happens when you use beta desynchonisation (ie change >> relative to the baseline) instead for each condition, and see >> source/channel maps of that separately for L and R and then when >> you take the difference. I suppose the main element this checks >> for is whether L and R conditions have the same baseline. >> This doesn't immediately explain why source and channel results >> are different but in the absence of any other clues it may be a >> way to 2ble check the whole process. >> >> >> Another point to consider is that, although beta changes should >> appear in all subjects, it is possibly true that there are >> individual differences in the actual beta range and frequency bin >> of maximum effect. If you are using the same settings for all >> subjects when you beamform with DICS you may be missing some of >> the effect (true, this is also the case for channel data but there >> may be subtle differences that add up - there are many voxels and >> few channels). I believe it may be useful to see what happens when >> you run the beamformer tailored to each subject's particular beta >> characteristics (ie change the "foi" for each subject, keep the >> tapsmofrq the same - possibly smaller) and then combine everything >> (you'll need of course to come up with a relative metric such as >> perc. change when you combine all subjects to account for the >> slightly different frequencies you used ) >> >> Best, >> Haris >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> On 21 November 2013 10:36, Eelke Spaak > > wrote: >> >> Fellow FieldTrippers, >> >> Currently I am looking at a contrast for left- versus >> right-hand index >> finger button presses. As expected, on sensor level (combined >> planar >> gradient, grand average) I see a clear lateralisation in beta band >> power starting at least 0.5s before the button press (see >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> clearly more beta power ipsilateral to the response hand. I would >> prefer to do further analyses on source level, so I attempt to >> reconstruct the sources for this effect using DICS beamformer >> (common >> filter, applied to both conditions separately; fixedori and >> realfilter >> = 'yes'). The grand average results for this (again contrast >> left vs >> right response hand) are shown at https://db.tt/IBQZG0d8 . >> (Ignore the >> R/L-flip, this is radiological convention.) >> >> As you can see, the source level solution is much more blurry >> than on >> sensor level. This picture is without using any regularisation >> (lambda >> parameter), the results are even worse when I use lambda = >> '5%'. The >> negative blob (right hand higher power than left) becomes >> 'marginally >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> sensor level. The positive blob is nowhere near significant. >> Also, the >> individual results are much less topographically consistent on >> source >> than on sensor level (explaining the worse statistics). >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> nicely within the head all the time. Also, I have manually >> verified >> the alignment of headmodel, sourcemodel, and gradiometer >> information >> for all subjects. >> >> As a final note, the above sensor-level plot was taken from a >> 'slice' >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> ingredient for the beamformer was an mtmfft fourier spectrum >> on the >> axial gradiometer data, obtained for just the time-frequency >> range of >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >> tapsmofrq = 7). >> When I compute condition-averaged power based on these fourier >> spectra >> and look at the contrast, the results are again as expected: >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> gradient vs planar). The freq structures underlying this >> contrast are >> exactly the same as those going into ft_sourceanalysis, so the >> problem >> must be in the source analysis step (and/or in the preparation >> of the >> geometric information, although these seem fine by visual >> inspection). >> >> Does anyone have any idea that might explain these seemingly >> contradictory results? I would have expected demixing to improve >> signal-to-noise ratio, rather than worsen it. >> >> Thanks! >> Best, >> Eelke >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Fri Nov 22 09:03:00 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 22 Nov 2013 09:03:00 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> Message-ID: Hoi Eelke, Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de forward module verwacht. Ik gok dat de high-level functies dit niet afdwingen, waardoor de leadfields er bekaaid van af komen. Gr, JM On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > Hi everyone, > > Thanks very much for your great input so far! Actually, as Jörn > suggested, I did the very straightforward check (thanks for the tip :) > ) of running one of our tutorial test scripts > (test_beamforming_extended), and it turns out this one does not > produce the same results as depicted here: > http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most > likely somewhere a bug has been introduced... > > Hopefully I can find out what it is today and fix it. Will keep you posted! > > Best, > Eelke > > On 22 November 2013 08:06, "Jörn M. Horschig" wrote: >> Hi Eelke, >> >> since everyone jumped on the train, here my 2 cents: >> To verify whether this is a newly introduced bug, maybe run a tutorial test >> script that includes beamforming. If they look alright, it gets more likely >> that it is you or your data and not fieldtrip :) It's not definite evidence >> of course though. SinceVitoria also experiences strange things, it might be >> something worthwhile to investigate. >> >> My initial guess from the plots is that there is something wrong with the >> forward model. All unit problems should have been resolved, but just to be >> sure you could check whether all objects are in the same unit (make it 'cm' >> as the grads are). >> >> Best, >> Jörn >> >> Charidimos Tzagarakis wrote: >>> >>> Eelke, >>> Thinking again about my second suggestion (regarding individual >>> variability) I actually can't think of a case where this could realistically >>> produce what you get. On the other hand, looking at TF maps per subject and >>> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >>> spot something unusual. >>> Best, >>> Haris >>> >>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>> >>> >>> >>> On 21 November 2013 18:09, Charidimos Tzagarakis >> > wrote: >>> >>> Hi Eelke, >>> Provided there is no major recent revision of the DICS code, I >>> would have expected motor desynchronisation to show up pretty >>> well. Are the maps shown at source and channel level straight >>> differences of L and Right hand conditions at the beta band (I >>> hope I am correctly interpreting your paradigm) ? If so it might >>> be helpful in pinpointing the problem/as a sanity check to see >>> what happens when you use beta desynchonisation (ie change >>> relative to the baseline) instead for each condition, and see >>> source/channel maps of that separately for L and R and then when >>> you take the difference. I suppose the main element this checks >>> for is whether L and R conditions have the same baseline. >>> This doesn't immediately explain why source and channel results >>> are different but in the absence of any other clues it may be a >>> way to 2ble check the whole process. >>> >>> >>> Another point to consider is that, although beta changes should >>> appear in all subjects, it is possibly true that there are >>> individual differences in the actual beta range and frequency bin >>> of maximum effect. If you are using the same settings for all >>> subjects when you beamform with DICS you may be missing some of >>> the effect (true, this is also the case for channel data but there >>> may be subtle differences that add up - there are many voxels and >>> few channels). I believe it may be useful to see what happens when >>> you run the beamformer tailored to each subject's particular beta >>> characteristics (ie change the "foi" for each subject, keep the >>> tapsmofrq the same - possibly smaller) and then combine everything >>> (you'll need of course to come up with a relative metric such as >>> perc. change when you combine all subjects to account for the >>> slightly different frequencies you used ) >>> >>> Best, >>> Haris >>> >>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>> >>> >>> >>> On 21 November 2013 10:36, Eelke Spaak >> > wrote: >>> >>> Fellow FieldTrippers, >>> >>> Currently I am looking at a contrast for left- versus >>> right-hand index >>> finger button presses. As expected, on sensor level (combined >>> planar >>> gradient, grand average) I see a clear lateralisation in beta band >>> power starting at least 0.5s before the button press (see >>> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >>> clearly more beta power ipsilateral to the response hand. I would >>> prefer to do further analyses on source level, so I attempt to >>> reconstruct the sources for this effect using DICS beamformer >>> (common >>> filter, applied to both conditions separately; fixedori and >>> realfilter >>> = 'yes'). The grand average results for this (again contrast >>> left vs >>> right response hand) are shown at https://db.tt/IBQZG0d8 . >>> (Ignore the >>> R/L-flip, this is radiological convention.) >>> >>> As you can see, the source level solution is much more blurry >>> than on >>> sensor level. This picture is without using any regularisation >>> (lambda >>> parameter), the results are even worse when I use lambda = >>> '5%'. The >>> negative blob (right hand higher power than left) becomes >>> 'marginally >>> significant' on source level (p ~ 0.06) where it was p < 0.001 on >>> sensor level. The positive blob is nowhere near significant. >>> Also, the >>> individual results are much less topographically consistent on >>> source >>> than on sensor level (explaining the worse statistics). >>> >>> I have checked the segmentation of my MRIs, the 'gray' seems to be >>> nicely within the head all the time. Also, I have manually >>> verified >>> the alignment of headmodel, sourcemodel, and gradiometer >>> information >>> for all subjects. >>> >>> As a final note, the above sensor-level plot was taken from a >>> 'slice' >>> out of a planar-gradient time-frequency analysis (mtmconvol). The >>> ingredient for the beamformer was an mtmfft fourier spectrum >>> on the >>> axial gradiometer data, obtained for just the time-frequency >>> range of >>> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >>> tapsmofrq = 7). >>> When I compute condition-averaged power based on these fourier >>> spectra >>> and look at the contrast, the results are again as expected: >>> https://db.tt/n2P3UKcQ (of course less localised because of axial >>> gradient vs planar). The freq structures underlying this >>> contrast are >>> exactly the same as those going into ft_sourceanalysis, so the >>> problem >>> must be in the source analysis step (and/or in the preparation >>> of the >>> geometric information, although these seem fine by visual >>> inspection). >>> >>> Does anyone have any idea that might explain these seemingly >>> contradictory results? I would have expected demixing to improve >>> signal-to-noise ratio, rather than worsen it. >>> >>> Thanks! >>> Best, >>> Eelke >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Fri Nov 22 09:11:25 2013 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 22 Nov 2013 09:11:25 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> Message-ID: <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> To all, This reply should have gone to Eelke and not to the whole list. Apologies for that. For those who understand Dutch: doe er je voordeel mee. Groeten, Jan-Mathijs On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: > Hoi Eelke, > > Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de forward module verwacht. Ik gok dat de high-level functies dit niet afdwingen, waardoor de leadfields er bekaaid van af komen. > > Gr, > JM > > On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > >> Hi everyone, >> >> Thanks very much for your great input so far! Actually, as Jörn >> suggested, I did the very straightforward check (thanks for the tip :) >> ) of running one of our tutorial test scripts >> (test_beamforming_extended), and it turns out this one does not >> produce the same results as depicted here: >> http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most >> likely somewhere a bug has been introduced... >> >> Hopefully I can find out what it is today and fix it. Will keep you posted! >> >> Best, >> Eelke >> >> On 22 November 2013 08:06, "Jörn M. Horschig" wrote: >>> Hi Eelke, >>> >>> since everyone jumped on the train, here my 2 cents: >>> To verify whether this is a newly introduced bug, maybe run a tutorial test >>> script that includes beamforming. If they look alright, it gets more likely >>> that it is you or your data and not fieldtrip :) It's not definite evidence >>> of course though. SinceVitoria also experiences strange things, it might be >>> something worthwhile to investigate. >>> >>> My initial guess from the plots is that there is something wrong with the >>> forward model. All unit problems should have been resolved, but just to be >>> sure you could check whether all objects are in the same unit (make it 'cm' >>> as the grads are). >>> >>> Best, >>> Jörn >>> >>> Charidimos Tzagarakis wrote: >>>> >>>> Eelke, >>>> Thinking again about my second suggestion (regarding individual >>>> variability) I actually can't think of a case where this could realistically >>>> produce what you get. On the other hand, looking at TF maps per subject and >>>> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >>>> spot something unusual. >>>> Best, >>>> Haris >>>> >>>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>>> >>>> >>>> >>>> On 21 November 2013 18:09, Charidimos Tzagarakis >>> > wrote: >>>> >>>> Hi Eelke, >>>> Provided there is no major recent revision of the DICS code, I >>>> would have expected motor desynchronisation to show up pretty >>>> well. Are the maps shown at source and channel level straight >>>> differences of L and Right hand conditions at the beta band (I >>>> hope I am correctly interpreting your paradigm) ? If so it might >>>> be helpful in pinpointing the problem/as a sanity check to see >>>> what happens when you use beta desynchonisation (ie change >>>> relative to the baseline) instead for each condition, and see >>>> source/channel maps of that separately for L and R and then when >>>> you take the difference. I suppose the main element this checks >>>> for is whether L and R conditions have the same baseline. >>>> This doesn't immediately explain why source and channel results >>>> are different but in the absence of any other clues it may be a >>>> way to 2ble check the whole process. >>>> >>>> >>>> Another point to consider is that, although beta changes should >>>> appear in all subjects, it is possibly true that there are >>>> individual differences in the actual beta range and frequency bin >>>> of maximum effect. If you are using the same settings for all >>>> subjects when you beamform with DICS you may be missing some of >>>> the effect (true, this is also the case for channel data but there >>>> may be subtle differences that add up - there are many voxels and >>>> few channels). I believe it may be useful to see what happens when >>>> you run the beamformer tailored to each subject's particular beta >>>> characteristics (ie change the "foi" for each subject, keep the >>>> tapsmofrq the same - possibly smaller) and then combine everything >>>> (you'll need of course to come up with a relative metric such as >>>> perc. change when you combine all subjects to account for the >>>> slightly different frequencies you used ) >>>> >>>> Best, >>>> Haris >>>> >>>> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >>>> University of Minnesota Dept of Neuroscience and Brain Sciences Center >>>> >>>> >>>> >>>> On 21 November 2013 10:36, Eelke Spaak >>> > wrote: >>>> >>>> Fellow FieldTrippers, >>>> >>>> Currently I am looking at a contrast for left- versus >>>> right-hand index >>>> finger button presses. As expected, on sensor level (combined >>>> planar >>>> gradient, grand average) I see a clear lateralisation in beta band >>>> power starting at least 0.5s before the button press (see >>>> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >>>> clearly more beta power ipsilateral to the response hand. I would >>>> prefer to do further analyses on source level, so I attempt to >>>> reconstruct the sources for this effect using DICS beamformer >>>> (common >>>> filter, applied to both conditions separately; fixedori and >>>> realfilter >>>> = 'yes'). The grand average results for this (again contrast >>>> left vs >>>> right response hand) are shown at https://db.tt/IBQZG0d8 . >>>> (Ignore the >>>> R/L-flip, this is radiological convention.) >>>> >>>> As you can see, the source level solution is much more blurry >>>> than on >>>> sensor level. This picture is without using any regularisation >>>> (lambda >>>> parameter), the results are even worse when I use lambda = >>>> '5%'. The >>>> negative blob (right hand higher power than left) becomes >>>> 'marginally >>>> significant' on source level (p ~ 0.06) where it was p < 0.001 on >>>> sensor level. The positive blob is nowhere near significant. >>>> Also, the >>>> individual results are much less topographically consistent on >>>> source >>>> than on sensor level (explaining the worse statistics). >>>> >>>> I have checked the segmentation of my MRIs, the 'gray' seems to be >>>> nicely within the head all the time. Also, I have manually >>>> verified >>>> the alignment of headmodel, sourcemodel, and gradiometer >>>> information >>>> for all subjects. >>>> >>>> As a final note, the above sensor-level plot was taken from a >>>> 'slice' >>>> out of a planar-gradient time-frequency analysis (mtmconvol). The >>>> ingredient for the beamformer was an mtmfft fourier spectrum >>>> on the >>>> axial gradiometer data, obtained for just the time-frequency >>>> range of >>>> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >>>> tapsmofrq = 7). >>>> When I compute condition-averaged power based on these fourier >>>> spectra >>>> and look at the contrast, the results are again as expected: >>>> https://db.tt/n2P3UKcQ (of course less localised because of axial >>>> gradient vs planar). The freq structures underlying this >>>> contrast are >>>> exactly the same as those going into ft_sourceanalysis, so the >>>> problem >>>> must be in the source analysis step (and/or in the preparation >>>> of the >>>> geometric information, although these seem fine by visual >>>> inspection). >>>> >>>> Does anyone have any idea that might explain these seemingly >>>> contradictory results? I would have expected demixing to improve >>>> signal-to-noise ratio, rather than worsen it. >>>> >>>> Thanks! >>>> Best, >>>> Eelke >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Jan-Mathijs Schoffelen, MD PhD Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands Max Planck Institute for Psycholinguistics, Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: +31-24-3614793 http://www.hettaligebrein.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Fri Nov 22 11:51:08 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 11:51:08 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> References: <528F0277.5070200@donders.ru.nl> <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> Message-ID: Following this up: Jan-Mathijs' suggestion did the trick (as usual, thanks), at least for the tutorial code. It turns out that it is now required to explicitly convert the geometric objects to 'm' before doing source analysis. I am certain that this was not required in the past, as I taught workshops with the beamforming-extended tutorial where we did not do the unit conversion and results looked fine. So now we will investigate what exactly changed and make sure that either the conversion is done automatically or the user is informed of non-matching units. Best, Eelke On 22 November 2013 09:11, jan-mathijs schoffelen wrote: > To all, > > This reply should have gone to Eelke and not to the whole list. Apologies > for that. For those who understand Dutch: doe er je voordeel mee. > > Groeten, > Jan-Mathijs > > > > On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: > > Hoi Eelke, > > Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, > sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de > forward module verwacht. Ik gok dat de high-level functies dit niet > afdwingen, waardoor de leadfields er bekaaid van af komen. > > Gr, > JM > > On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: > > Hi everyone, > > Thanks very much for your great input so far! Actually, as Jörn > suggested, I did the very straightforward check (thanks for the tip :) > ) of running one of our tutorial test scripts > (test_beamforming_extended), and it turns out this one does not > produce the same results as depicted here: > http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most > likely somewhere a bug has been introduced... > > Hopefully I can find out what it is today and fix it. Will keep you posted! > > Best, > Eelke > > On 22 November 2013 08:06, "Jörn M. Horschig" > wrote: > > Hi Eelke, > > > since everyone jumped on the train, here my 2 cents: > > To verify whether this is a newly introduced bug, maybe run a tutorial test > > script that includes beamforming. If they look alright, it gets more likely > > that it is you or your data and not fieldtrip :) It's not definite evidence > > of course though. SinceVitoria also experiences strange things, it might be > > something worthwhile to investigate. > > > My initial guess from the plots is that there is something wrong with the > > forward model. All unit problems should have been resolved, but just to be > > sure you could check whether all objects are in the same unit (make it 'cm' > > as the grads are). > > > Best, > > Jörn > > > Charidimos Tzagarakis wrote: > > > Eelke, > > Thinking again about my second suggestion (regarding individual > > variability) I actually can't think of a case where this could realistically > > produce what you get. On the other hand, looking at TF maps per subject and > > channel (on the "helmet" layout), normalised with a "rest" epoch, may help > > spot something unusual. > > Best, > > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 18:09, Charidimos Tzagarakis > > wrote: > > > Hi Eelke, > > Provided there is no major recent revision of the DICS code, I > > would have expected motor desynchronisation to show up pretty > > well. Are the maps shown at source and channel level straight > > differences of L and Right hand conditions at the beta band (I > > hope I am correctly interpreting your paradigm) ? If so it might > > be helpful in pinpointing the problem/as a sanity check to see > > what happens when you use beta desynchonisation (ie change > > relative to the baseline) instead for each condition, and see > > source/channel maps of that separately for L and R and then when > > you take the difference. I suppose the main element this checks > > for is whether L and R conditions have the same baseline. > > This doesn't immediately explain why source and channel results > > are different but in the absence of any other clues it may be a > > way to 2ble check the whole process. > > > > Another point to consider is that, although beta changes should > > appear in all subjects, it is possibly true that there are > > individual differences in the actual beta range and frequency bin > > of maximum effect. If you are using the same settings for all > > subjects when you beamform with DICS you may be missing some of > > the effect (true, this is also the case for channel data but there > > may be subtle differences that add up - there are many voxels and > > few channels). I believe it may be useful to see what happens when > > you run the beamformer tailored to each subject's particular beta > > characteristics (ie change the "foi" for each subject, keep the > > tapsmofrq the same - possibly smaller) and then combine everything > > (you'll need of course to come up with a relative metric such as > > perc. change when you combine all subjects to account for the > > slightly different frequencies you used ) > > > Best, > > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 21 November 2013 10:36, Eelke Spaak > > wrote: > > > Fellow FieldTrippers, > > > Currently I am looking at a contrast for left- versus > > right-hand index > > finger button presses. As expected, on sensor level (combined > > planar > > gradient, grand average) I see a clear lateralisation in beta band > > power starting at least 0.5s before the button press (see > > https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is > > clearly more beta power ipsilateral to the response hand. I would > > prefer to do further analyses on source level, so I attempt to > > reconstruct the sources for this effect using DICS beamformer > > (common > > filter, applied to both conditions separately; fixedori and > > realfilter > > = 'yes'). The grand average results for this (again contrast > > left vs > > right response hand) are shown at https://db.tt/IBQZG0d8 . > > (Ignore the > > R/L-flip, this is radiological convention.) > > > As you can see, the source level solution is much more blurry > > than on > > sensor level. This picture is without using any regularisation > > (lambda > > parameter), the results are even worse when I use lambda = > > '5%'. The > > negative blob (right hand higher power than left) becomes > > 'marginally > > significant' on source level (p ~ 0.06) where it was p < 0.001 on > > sensor level. The positive blob is nowhere near significant. > > Also, the > > individual results are much less topographically consistent on > > source > > than on sensor level (explaining the worse statistics). > > > I have checked the segmentation of my MRIs, the 'gray' seems to be > > nicely within the head all the time. Also, I have manually > > verified > > the alignment of headmodel, sourcemodel, and gradiometer > > information > > for all subjects. > > > As a final note, the above sensor-level plot was taken from a > > 'slice' > > out of a planar-gradient time-frequency analysis (mtmconvol). The > > ingredient for the beamformer was an mtmfft fourier spectrum > > on the > > axial gradiometer data, obtained for just the time-frequency > > range of > > interest (subselect toilim [-0.5 0], mtmfft foi = 23, > > tapsmofrq = 7). > > When I compute condition-averaged power based on these fourier > > spectra > > and look at the contrast, the results are again as expected: > > https://db.tt/n2P3UKcQ (of course less localised because of axial > > gradient vs planar). The freq structures underlying this > > contrast are > > exactly the same as those going into ft_sourceanalysis, so the > > problem > > must be in the source analysis step (and/or in the preparation > > of the > > geometric information, although these seem fine by visual > > inspection). > > > Does anyone have any idea that might explain these seemingly > > contradictory results? I would have expected demixing to improve > > signal-to-noise ratio, rather than worsen it. > > > Thanks! > > Best, > > Eelke > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > Jan-Mathijs Schoffelen, MD PhD > > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > > Max Planck Institute for Psycholinguistics, > Nijmegen, The Netherlands > > J.Schoffelen at donders.ru.nl > Telephone: +31-24-3614793 > > http://www.hettaligebrein.nl > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Fri Nov 22 12:59:34 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 12:59:34 +0100 Subject: [FieldTrip] Motor beta activity - DICS solution more noisy than sensor data? In-Reply-To: References: <528F0277.5070200@donders.ru.nl> <8D873FC2-6FCC-4E5C-8D2E-ACA22175CF1F@donders.ru.nl> Message-ID: As confirmed by Robert, there is indeed a bug in the handling of distance units in ft_prepare_leadfield. This function will now (FTP release as of tonight) throw an error if units are not in agreement. Discussion of this bug will continue at http://bugzilla.fcdonders.nl/show_bug.cgi?id=2387 or at one of the related bugs. Cheers, Eelke On 22 November 2013 11:51, Eelke Spaak wrote: > Following this up: Jan-Mathijs' suggestion did the trick (as usual, > thanks), at least for the tutorial code. It turns out that it is now > required to explicitly convert the geometric objects to 'm' before > doing source analysis. > > I am certain that this was not required in the past, as I taught > workshops with the beamforming-extended tutorial where we did not do > the unit conversion and results looked fine. So now we will > investigate what exactly changed and make sure that either the > conversion is done automatically or the user is informed of > non-matching units. > > Best, > Eelke > > > On 22 November 2013 09:11, jan-mathijs schoffelen > wrote: >> To all, >> >> This reply should have gone to Eelke and not to the whole list. Apologies >> for that. For those who understand Dutch: doe er je voordeel mee. >> >> Groeten, >> Jan-Mathijs >> >> >> >> On Nov 22, 2013, at 9:03 AM, jan-mathijs schoffelen wrote: >> >> Hoi Eelke, >> >> Ik zou in eerste instantie handmatig alle geometrische objecten (headmodel, >> sourcemodel, grad) naar 'm' ft_convert_units'en. Dit is de conventie die de >> forward module verwacht. Ik gok dat de high-level functies dit niet >> afdwingen, waardoor de leadfields er bekaaid van af komen. >> >> Gr, >> JM >> >> On Nov 22, 2013, at 8:41 AM, Eelke Spaak wrote: >> >> Hi everyone, >> >> Thanks very much for your great input so far! Actually, as Jörn >> suggested, I did the very straightforward check (thanks for the tip :) >> ) of running one of our tutorial test scripts >> (test_beamforming_extended), and it turns out this one does not >> produce the same results as depicted here: >> http://fieldtrip.fcdonders.nl/tutorial/beamformingextended . So, most >> likely somewhere a bug has been introduced... >> >> Hopefully I can find out what it is today and fix it. Will keep you posted! >> >> Best, >> Eelke >> >> On 22 November 2013 08:06, "Jörn M. Horschig" >> wrote: >> >> Hi Eelke, >> >> >> since everyone jumped on the train, here my 2 cents: >> >> To verify whether this is a newly introduced bug, maybe run a tutorial test >> >> script that includes beamforming. If they look alright, it gets more likely >> >> that it is you or your data and not fieldtrip :) It's not definite evidence >> >> of course though. SinceVitoria also experiences strange things, it might be >> >> something worthwhile to investigate. >> >> >> My initial guess from the plots is that there is something wrong with the >> >> forward model. All unit problems should have been resolved, but just to be >> >> sure you could check whether all objects are in the same unit (make it 'cm' >> >> as the grads are). >> >> >> Best, >> >> Jörn >> >> >> Charidimos Tzagarakis wrote: >> >> >> Eelke, >> >> Thinking again about my second suggestion (regarding individual >> >> variability) I actually can't think of a case where this could realistically >> >> produce what you get. On the other hand, looking at TF maps per subject and >> >> channel (on the "helmet" layout), normalised with a "rest" epoch, may help >> >> spot something unusual. >> >> Best, >> >> Haris >> >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> >> On 21 November 2013 18:09, Charidimos Tzagarakis > >> > wrote: >> >> >> Hi Eelke, >> >> Provided there is no major recent revision of the DICS code, I >> >> would have expected motor desynchronisation to show up pretty >> >> well. Are the maps shown at source and channel level straight >> >> differences of L and Right hand conditions at the beta band (I >> >> hope I am correctly interpreting your paradigm) ? If so it might >> >> be helpful in pinpointing the problem/as a sanity check to see >> >> what happens when you use beta desynchonisation (ie change >> >> relative to the baseline) instead for each condition, and see >> >> source/channel maps of that separately for L and R and then when >> >> you take the difference. I suppose the main element this checks >> >> for is whether L and R conditions have the same baseline. >> >> This doesn't immediately explain why source and channel results >> >> are different but in the absence of any other clues it may be a >> >> way to 2ble check the whole process. >> >> >> >> Another point to consider is that, although beta changes should >> >> appear in all subjects, it is possibly true that there are >> >> individual differences in the actual beta range and frequency bin >> >> of maximum effect. If you are using the same settings for all >> >> subjects when you beamform with DICS you may be missing some of >> >> the effect (true, this is also the case for channel data but there >> >> may be subtle differences that add up - there are many voxels and >> >> few channels). I believe it may be useful to see what happens when >> >> you run the beamformer tailored to each subject's particular beta >> >> characteristics (ie change the "foi" for each subject, keep the >> >> tapsmofrq the same - possibly smaller) and then combine everything >> >> (you'll need of course to come up with a relative metric such as >> >> perc. change when you combine all subjects to account for the >> >> slightly different frequencies you used ) >> >> >> Best, >> >> Haris >> >> >> Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> University of Minnesota Dept of Neuroscience and Brain Sciences Center >> >> >> >> >> On 21 November 2013 10:36, Eelke Spaak > >> > wrote: >> >> >> Fellow FieldTrippers, >> >> >> Currently I am looking at a contrast for left- versus >> >> right-hand index >> >> finger button presses. As expected, on sensor level (combined >> >> planar >> >> gradient, grand average) I see a clear lateralisation in beta band >> >> power starting at least 0.5s before the button press (see >> >> https://db.tt/Rtch3Qjy). Both 'blobs' are significant; there is >> >> clearly more beta power ipsilateral to the response hand. I would >> >> prefer to do further analyses on source level, so I attempt to >> >> reconstruct the sources for this effect using DICS beamformer >> >> (common >> >> filter, applied to both conditions separately; fixedori and >> >> realfilter >> >> = 'yes'). The grand average results for this (again contrast >> >> left vs >> >> right response hand) are shown at https://db.tt/IBQZG0d8 . >> >> (Ignore the >> >> R/L-flip, this is radiological convention.) >> >> >> As you can see, the source level solution is much more blurry >> >> than on >> >> sensor level. This picture is without using any regularisation >> >> (lambda >> >> parameter), the results are even worse when I use lambda = >> >> '5%'. The >> >> negative blob (right hand higher power than left) becomes >> >> 'marginally >> >> significant' on source level (p ~ 0.06) where it was p < 0.001 on >> >> sensor level. The positive blob is nowhere near significant. >> >> Also, the >> >> individual results are much less topographically consistent on >> >> source >> >> than on sensor level (explaining the worse statistics). >> >> >> I have checked the segmentation of my MRIs, the 'gray' seems to be >> >> nicely within the head all the time. Also, I have manually >> >> verified >> >> the alignment of headmodel, sourcemodel, and gradiometer >> >> information >> >> for all subjects. >> >> >> As a final note, the above sensor-level plot was taken from a >> >> 'slice' >> >> out of a planar-gradient time-frequency analysis (mtmconvol). The >> >> ingredient for the beamformer was an mtmfft fourier spectrum >> >> on the >> >> axial gradiometer data, obtained for just the time-frequency >> >> range of >> >> interest (subselect toilim [-0.5 0], mtmfft foi = 23, >> >> tapsmofrq = 7). >> >> When I compute condition-averaged power based on these fourier >> >> spectra >> >> and look at the contrast, the results are again as expected: >> >> https://db.tt/n2P3UKcQ (of course less localised because of axial >> >> gradient vs planar). The freq structures underlying this >> >> contrast are >> >> exactly the same as those going into ft_sourceanalysis, so the >> >> problem >> >> must be in the source analysis step (and/or in the preparation >> >> of the >> >> geometric information, although these seem fine by visual >> >> inspection). >> >> >> Does anyone have any idea that might explain these seemingly >> >> contradictory results? I would have expected demixing to improve >> >> signal-to-noise ratio, rather than worsen it. >> >> >> Thanks! >> >> Best, >> >> Eelke >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Jan-Mathijs Schoffelen, MD PhD >> >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> >> Max Planck Institute for Psycholinguistics, >> Nijmegen, The Netherlands >> >> J.Schoffelen at donders.ru.nl >> Telephone: +31-24-3614793 >> >> http://www.hettaligebrein.nl >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From andrea.brovelli at univ-amu.fr Fri Nov 22 13:33:35 2013 From: andrea.brovelli at univ-amu.fr (andrea brovelli) Date: Fri, 22 Nov 2013 13:33:35 +0100 (CET) Subject: [FieldTrip] Conjunction analysis In-Reply-To: <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> References: <4n1mll4hhxynig3ee2fqxjfe.1385048137160@email.android.com> <151987884.22607.1385049534780.JavaMail.root@bureau-frontal1> Message-ID: <85141893.13184.1385123615804.JavaMail.root@bureau-frontal2> Last comment on Conjunction analysis: I got an email from Thomas Nichols (2005, Neuroimage). In fact, things are much easier than expected, no special code is required. The conjunction is just the minimum of the two statistics (t-valeus, for example, or, equivalently, the maximum of the two p-values).  And this is independent of the type of statistical test used  (parametric or non-parametric). So, the implementation in ft_conjunctionanalysis should be safe. Bye Andrea andrea brovelli wrote:Thanks a lot for your reply, Arjen. It's clearer now. In fact, I am using a parametric tests, so I think I would need to use the Nichols 2005 method for the conjunction analysis. Does anyone have the code to do this or does anyone know how to recover it within SPM ? Thanks a lot Andrea "A.stolk" wrote:Hi andrea, ft_conjunctionanalysis performs a logical AND on 2 or more contrasts, of which each contrast may be corrected for multiple comparisons. It thus shows the overlap between those nonparametric statistical maps where a voxel survives the conjunction if it survived two or more independent nonparametric tests. It differs from the spm version which is grounded in parametric testing (nichols 2005). In the latter one could find overlap between clusters that is not necessarily statistically significant at the clusterlevel. That is because the parametric method is geared toward the (fixed) intensity of the cluster (and overlaps). Those are the key differences. Hope this helps a bit. Yours; arjen andrea brovelli schreef: Dear all, I need to do a conjunction analysis between contrast maps (T-maps or thresholded p-maps). I have seen that there is a function called ft_conjunctionanalysis. Does anyone know what this function does ? I cannot find the reference for the method implemented. Or does anyone have the matlab code to perform a conjunction analysis as described in Nichols et al., 2005 Neuroimage ? http://psych.colorado.edu/~tor/Papers/Nichols_2005_conjunctions.pdf Thanks a lot Andrea _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip_______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- An HTML attachment was scrubbed... URL: From caspervanheck at gmail.com Fri Nov 22 13:36:22 2013 From: caspervanheck at gmail.com (Casper van Heck) Date: Fri, 22 Nov 2013 13:36:22 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Eelke, I was busy with some other stuff, and just now revisited the analysis. Even with a newer version of Fieldtrip, this is still happening, and I still do not know why... Have you had time to take a look at it? Sincerely, Casper On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck wrote: > Dear Eelke, > > I've put up an exerpt of my code, with the data from a single subject > (no.10, 9MB) in a separate folder here > . > It also includes a screenshot of what I see with when I run the code with > this exact dataset, and a small program 'filehandler', which I've been to > lazy to replace. > > Note that this specific subject only has about 60 seconds of data (and I'm > still waiting for the student to tell me why). > > I'm hoping you'll get the same result as the screenshot, and you'll be > able to tell me why... > > Best regards, > > Casper > > > On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak wrote: > >> Dear Casper, >> >> Could you maybe post a snippet online somewhere (e.g. dropbox) of data >> corresponding to this plot (i.e. the output of ft_freqanalysis that >> you input to ft_singleplotTFR, assuming that it's averaged over trials >> and therefore small)? Then we can see whether this is reproducable on >> our systems. >> >> Best, >> Eelke >> >> On 16 September 2013 17:12, Casper van Heck >> wrote: >> > Dear Fieldtrippers, >> > >> > I've been doing some exploratory plotting of a dataset where several >> > subjects were exposed to a continuous stimulus (CPM) over the course of >> > three minutes. One of the things that was asked was a time-frequency >> plot, >> > over those three minutes. While I'm not quite sure a TFR can be used on >> that >> > scale without problems, I went ahead with it just to see what Fieldtrip >> > would do. What I got, was this: >> > http://tinypic.com/r/zx2tqs/5| >> > And I have no idea what went wrong (note that this specific subject >> only got >> > a 60s stimulus). Quality of the picture and the validity of the analysis >> > aside, I have a severe problem with the axes, which seem to be all over >> the >> > place. >> > >> > I simply read the data using ft_preprocessing (no filters or anything, >> since >> > the student in charge already used a 10Hz high-pass and a 150Hz low-pass >> > filter). >> > The only field in 'cfg' is 'headerfile'. >> > >> > Next, I call ft_freqanalysis with: >> > cfg.output = 'pow'; >> > cfg.method = 'wavelet'; % default; Morlet wavelet >> > cfg.taper = 'hanning'; >> > cfg.tapsmofrq = 4; >> > cfg.channel = 'Cz'; >> > cfg.foi = [20:0.5:30]; >> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; >> > cfg.toi = 0:0.5:60; >> > >> > And finally, I end up with the monstrocity shown earlier. This problem >> only >> > presents itself with Fieldtrip-related functions, the normal >> Matlab-plots >> > work as well as they've ever done, so I'm thinking it's something in >> > Fieldtrip that's causing this. >> > >> > My hope is that someone has encountered this problem before, and knows >> how >> > to solve it... >> > >> > Sincerely, >> > >> > Casper >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eelke.spaak at donders.ru.nl Fri Nov 22 16:40:28 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Fri, 22 Nov 2013 16:40:28 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Casper, See attached the plots I get when running your script (on Windows/Linux Matlab 2011b/2012a). They seem quite OK to me, so I suspect the issue is in your Matlab installation and/or system (e.g. video drivers). One thing that could possibly help (though I would not understand why exactly) is to change the renderer, by trying out all three options for cfg.renderer = 'painters'/'zbuffer'/'opengl'. Or maybe you could try running another Matlab version? Sorry this is not more helpful, good luck figuring it out! Best, Eelke On 22 November 2013 13:36, Casper van Heck wrote: > Dear Eelke, > > I was busy with some other stuff, and just now revisited the analysis. Even > with a newer version of Fieldtrip, this is still happening, and I still do > not know why... > Have you had time to take a look at it? > > Sincerely, > > Casper > > > On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck > wrote: >> >> Dear Eelke, >> >> I've put up an exerpt of my code, with the data from a single subject >> (no.10, 9MB) in a separate folder here. >> It also includes a screenshot of what I see with when I run the code with >> this exact dataset, and a small program 'filehandler', which I've been to >> lazy to replace. >> >> Note that this specific subject only has about 60 seconds of data (and I'm >> still waiting for the student to tell me why). >> >> I'm hoping you'll get the same result as the screenshot, and you'll be >> able to tell me why... >> >> Best regards, >> >> Casper >> >> >> On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak >> wrote: >>> >>> Dear Casper, >>> >>> Could you maybe post a snippet online somewhere (e.g. dropbox) of data >>> corresponding to this plot (i.e. the output of ft_freqanalysis that >>> you input to ft_singleplotTFR, assuming that it's averaged over trials >>> and therefore small)? Then we can see whether this is reproducable on >>> our systems. >>> >>> Best, >>> Eelke >>> >>> On 16 September 2013 17:12, Casper van Heck >>> wrote: >>> > Dear Fieldtrippers, >>> > >>> > I've been doing some exploratory plotting of a dataset where several >>> > subjects were exposed to a continuous stimulus (CPM) over the course of >>> > three minutes. One of the things that was asked was a time-frequency >>> > plot, >>> > over those three minutes. While I'm not quite sure a TFR can be used on >>> > that >>> > scale without problems, I went ahead with it just to see what Fieldtrip >>> > would do. What I got, was this: >>> > http://tinypic.com/r/zx2tqs/5| >>> > And I have no idea what went wrong (note that this specific subject >>> > only got >>> > a 60s stimulus). Quality of the picture and the validity of the >>> > analysis >>> > aside, I have a severe problem with the axes, which seem to be all over >>> > the >>> > place. >>> > >>> > I simply read the data using ft_preprocessing (no filters or anything, >>> > since >>> > the student in charge already used a 10Hz high-pass and a 150Hz >>> > low-pass >>> > filter). >>> > The only field in 'cfg' is 'headerfile'. >>> > >>> > Next, I call ft_freqanalysis with: >>> > cfg.output = 'pow'; >>> > cfg.method = 'wavelet'; % default; Morlet wavelet >>> > cfg.taper = 'hanning'; >>> > cfg.tapsmofrq = 4; >>> > cfg.channel = 'Cz'; >>> > cfg.foi = [20:0.5:30]; >>> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; >>> > cfg.toi = 0:0.5:60; >>> > >>> > And finally, I end up with the monstrocity shown earlier. This problem >>> > only >>> > presents itself with Fieldtrip-related functions, the normal >>> > Matlab-plots >>> > work as well as they've ever done, so I'm thinking it's something in >>> > Fieldtrip that's causing this. >>> > >>> > My hope is that someone has encountered this problem before, and knows >>> > how >>> > to solve it... >>> > >>> > Sincerely, >>> > >>> > Casper >>> > >>> > >>> > _______________________________________________ >>> > fieldtrip mailing list >>> > fieldtrip at donders.ru.nl >>> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -------------- next part -------------- A non-text attachment was scrubbed... Name: mytfr-linux-matlab2012a-64bit.png Type: image/png Size: 25742 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mytfr-windows-matlab2011b-64bit.png Type: image/png Size: 34916 bytes Desc: not available URL: From trdavenp at cogsci.ucsd.edu Fri Nov 22 20:35:31 2013 From: trdavenp at cogsci.ucsd.edu (Tristan Davenport) Date: Fri, 22 Nov 2013 11:35:31 -0800 Subject: [FieldTrip] ft_artifact_threshold and the return of the "unit circle" error Message-ID: I'm trying to import and analyze some Neuromag 306 data, and I keep running into the following error message whenever I try to detect blink artifacts with the threshold method: *??? Error using ==> filter_with_correction at 44 Calculated filter coefficients have poles on or outside the unit circle and will not be stable. Try a higher cutoff frequency or a different type/order of filter.Error in ==> filter_with_correction at 44 error('Calculated filter coefficients have poles on or outside the unit circle and will not be stable. Try a higher cutoff frequency or a different type/order of filter.');Error in ==> ft_preproc_bandpassfilter at 148 filt = filter_with_correction(B,A,dat,dir);Error in ==> preproc at 299if strcmp(cfg.bpfilter, 'yes'), dat = ft_preproc_bandpassfilter(dat, fsample, cfg.bpfreq, cfg.bpfiltord, cfg.bpfilttype, cfg.bpfiltdir, cfg.bpinstabilityfix); endError in ==> ft_artifact_threshold at 148 dat = preproc(dat, channel, offset2time(cfg.trl(trlop,3), hdr.Fs, size(dat,2)), artfctdef); * Based on previous advice in these threads, I have tried changing the cutoff frequency, order, direction, and type of filtering of my data using cfg fields like bpfreq, bpfilttype, bpfiltdir, and bpinstabilityfix. Long story short, I've tried every logically possible combination of filter settings (including no filtering at all), and I get the same error regardless. Does anyone have some insight into this? Take care, Tristan Davenport UC San Diego -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Mon Nov 25 17:16:41 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Mon, 25 Nov 2013 17:16:41 +0100 Subject: [FieldTrip] Error in ft_fetch_data (line 99) Message-ID: Dear Field Trip user. I sometimes experience an error in ft_fetch_data (line 99) usually with the last trial after epoching continuous Neuromag 306 channel FIF data into trials. I suspect that there might be something wrong with my trial definitions or the data, but I don't understand the error messages. I had to concatenate the continuous data and the trial definitions, because the raw data was split into two files during recording, however all the concatenated continuous data can be seen clearly by using the ft_databrowser and the trial definition onset times and event values also looks reasonable. I wonder what could be the problem, and if there could be a solution to avoid this occasional error? (The simple solution would of course be just to remove the occasional trials with error, but then to loose some trials). Thank you if you have any comments or suggestions. Greetings Niels. This is the error messages that shows up if I try to show the "problematic" trial in ft_databrowser: Error in ft_fetch_data (line 99) count(trlbeg:trlend) = count(trlbeg:trlend) + 1; Error in ft_databrowser>redraw_cb (line 1458) dat = ft_fetch_data(opt.orgdata, 'header', opt.hdr, 'begsample', begsample, 'endsample', endsample, 'chanindx', chanindx, 'allowoverlap', true); % ALLOWING OVERLAPPING TRIALS Error in ft_databrowser>keyboard_cb (line 1232) redraw_cb(h, eventdata); Error while evaluating uicontrol Callback This is the error messages that is shown when I try to run ft_artifact_zvalue on the trials: Warning: -clear > In utilities/private/warning_once at 116 In utilities/private/ft_preamble_init at 26 In ft_preamble at 54 In ft_artifact_zvalue at 110 searching for artifacts in 102 channels searching trials.Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 .Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 87 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 88 In ft_artifact_zvalue at 262 Warning: Size vector should be a row vector with integer elements. > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Warning: Integer operands are required for colon operator when used as index > In ft_fetch_data at 89 In ft_artifact_zvalue at 262 Index exceeds matrix dimensions. Error in ft_fetch_data (line 99) count(trlbeg:trlend) = count(trlbeg:trlend) + 1; Error in ft_artifact_zvalue (line 262) dat{trlop} = ft_fetch_data(data, 'header', hdr, 'begsample', trl(trlop,1)-fltpadding, 'endsample', trl(trlop,2)+fltpadding, 'chanindx', sgnind, 'checkboundary', strcmp(cfg.continuous,'no Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From aestnth at hum.au.dk Mon Nov 25 17:26:17 2013 From: aestnth at hum.au.dk (Niels Trusbak Haumann) Date: Mon, 25 Nov 2013 17:26:17 +0100 Subject: [FieldTrip] Error in ft_fetch_data (line 99) In-Reply-To: References: Message-ID: PS: Apparently, ft_rejectvisual can succesfully process show the occasional trials that causes errors with ft_databrowser and ft_artifact_zvalue. FieldTrip discussion list writes: >Dear Field Trip user. > >I sometimes experience an error in ft_fetch_data (line 99) usually with the last trial after epoching continuous Neuromag 306 channel FIF data into trials. I suspect that there might be something wrong with my trial definitions or the data, but I don't understand the error messages. I had to concatenate the continuous data and the trial definitions, because the raw data was split into two files during recording, however all the concatenated continuous data can be seen clearly by using the >ft_databrowser and the trial definition onset times and event values also looks reasonable. > >I wonder what could be the problem, and if there could be a solution to avoid this occasional error? > >(The simple solution would of course be just to remove the occasional trials with error, but then to loose some trials). > >Thank you if you have any comments or suggestions. > >Greetings >Niels. > >This is the error messages that shows up if I try to show the "problematic" trial in ft_databrowser: > >Error in ft_fetch_data (line 99) > � � � � � count(trlbeg:trlend) = count(trlbeg:trlend) + 1; > >Error in ft_databrowser>redraw_cb (line 1458) > � dat = ft_fetch_data(opt.orgdata, 'header', opt.hdr, 'begsample', begsample, 'endsample', endsample, > � 'chanindx', chanindx, 'allowoverlap', true); % ALLOWING OVERLAPPING TRIALS > >Error in ft_databrowser>keyboard_cb (line 1232) > � � � redraw_cb(h, eventdata); > >Error while evaluating uicontrol Callback > >This is the error messages that is shown when I try to run ft_artifact_zvalue on the trials: > >Warning: -clear >> In utilities/private/warning_once at 116 > � In utilities/private/ft_preamble_init at 26 > � In ft_preamble at 54 > � In ft_artifact_zvalue at 110 >searching for artifacts in 102 channels >searching trials.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >.Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 87 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 88 > � In ft_artifact_zvalue at 262 >Warning: Size vector should be a row vector with integer elements. >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Warning: Integer operands are required for colon operator when used as index >> In ft_fetch_data at 89 > � In ft_artifact_zvalue at 262 >Index exceeds matrix dimensions. > >Error in ft_fetch_data (line 99) > � � � � � count(trlbeg:trlend) = count(trlbeg:trlend) + 1; > >Error in ft_artifact_zvalue (line 262) > � � � � � dat{trlop} = ft_fetch_data(data, � � � � � � � 'header', hdr, 'begsample', trl(trlop,1)-fltpadding, > � � � � � 'endsample', trl(trlop,2)+fltpadding, 'chanindx', sgnind, 'checkboundary', > � � � � � strcmp(cfg.continuous,'no > >Niels Trusbak Haumann >M.A. / PhD student >Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience >Aarhus University / Aarhus University Hospital >E-mail: [ mailto:aestnth at hum.au.dk ]aestnth at hum.au.dk >_______________________________________________ >fieldtrip mailing list >fieldtrip at donders.ru.nl >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Niels Trusbak Haumann M.A. / PhD student Department of Aesthetic Studies / Center of Functionally Integrative Neuroscience Aarhus University / Aarhus University Hospital E-mail: aestnth at hum.au.dk -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayobimpe2004 at hotmail.com Tue Nov 26 01:49:51 2013 From: ayobimpe2004 at hotmail.com (Azeez Adebimpe) Date: Tue, 26 Nov 2013 01:49:51 +0100 Subject: [FieldTrip] trial definition Message-ID: Hello everyone,I have a continuous cnt eeg file. There is no event and I want to divide it into several epochs. please it is normal to use this:?cfg.trialdef.triallength = duration in seconds (can also be 1 or Inf) cfg.trialdef.ntrials = number of trials (can also be 1 or Inf)Please if there is other way to define the trial, please kindly let me know. Best regards, Azeez Adebimpe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-baptiste.versini at etu.univ-lyon1.fr Tue Nov 26 11:12:36 2013 From: jean-baptiste.versini at etu.univ-lyon1.fr (VERSINI JEAN-BAPTISTE p1207642) Date: Tue, 26 Nov 2013 10:12:36 +0000 Subject: [FieldTrip] RE : trial definition In-Reply-To: References: Message-ID: <5271B6068CD8D94DB82254228237928801790560@mbx2010-02.univ-lyon1.fr> Hello, I have no idea if what you're currently doing works but maybe you should consider making your own trial function : http://fieldtrip.fcdonders.nl/example/making_your_own_trialfun_for_conditional_trial_definition regards, JB ________________________________ De : fieldtrip-bounces at science.ru.nl [fieldtrip-bounces at science.ru.nl] de la part de Azeez Adebimpe [ayobimpe2004 at hotmail.com] Date d'envoi : mardi 26 novembre 2013 01:49 À : fieldtrip at science.ru.nl Objet : [FieldTrip] trial definition Hello everyone, I have a continuous cnt eeg file. There is no event and I want to divide it into several epochs. please it is normal to use this:? cfg.trialdef.triallength = duration in seconds (can also be 1 or Inf) cfg.trialdef.ntrials = number of trials (can also be 1 or Inf) Please if there is other way to define the trial, please kindly let me know. Best regards, Azeez Adebimpe -------------- next part -------------- An HTML attachment was scrubbed... URL: From caspervanheck at gmail.com Tue Nov 26 12:25:11 2013 From: caspervanheck at gmail.com (Casper van Heck) Date: Tue, 26 Nov 2013 12:25:11 +0100 Subject: [FieldTrip] ft_singleplotTFR seems broken In-Reply-To: References: Message-ID: Dear Eelke, I've tried it with the painters, zbuffer, and opengl, using Matlab 2011a and 2013a (giving me the 'not yet supported'-error), with the same results. I think I'll try it at home, later, and if that fails, I'll get the ICT-people to reinstall the whole thing. Thanks! Casper On Fri, Nov 22, 2013 at 4:40 PM, Eelke Spaak wrote: > Dear Casper, > > See attached the plots I get when running your script (on > Windows/Linux Matlab 2011b/2012a). They seem quite OK to me, so I > suspect the issue is in your Matlab installation and/or system (e.g. > video drivers). > > One thing that could possibly help (though I would not understand why > exactly) is to change the renderer, by trying out all three options > for cfg.renderer = 'painters'/'zbuffer'/'opengl'. Or maybe you could > try running another Matlab version? > > Sorry this is not more helpful, good luck figuring it out! > > Best, > Eelke > > On 22 November 2013 13:36, Casper van Heck > wrote: > > Dear Eelke, > > > > I was busy with some other stuff, and just now revisited the analysis. > Even > > with a newer version of Fieldtrip, this is still happening, and I still > do > > not know why... > > Have you had time to take a look at it? > > > > Sincerely, > > > > Casper > > > > > > On Thu, Sep 26, 2013 at 12:43 PM, Casper van Heck < > caspervanheck at gmail.com> > > wrote: > >> > >> Dear Eelke, > >> > >> I've put up an exerpt of my code, with the data from a single subject > >> (no.10, 9MB) in a separate folder here. > >> It also includes a screenshot of what I see with when I run the code > with > >> this exact dataset, and a small program 'filehandler', which I've been > to > >> lazy to replace. > >> > >> Note that this specific subject only has about 60 seconds of data (and > I'm > >> still waiting for the student to tell me why). > >> > >> I'm hoping you'll get the same result as the screenshot, and you'll be > >> able to tell me why... > >> > >> Best regards, > >> > >> Casper > >> > >> > >> On Wed, Sep 18, 2013 at 1:25 PM, Eelke Spaak > > >> wrote: > >>> > >>> Dear Casper, > >>> > >>> Could you maybe post a snippet online somewhere (e.g. dropbox) of data > >>> corresponding to this plot (i.e. the output of ft_freqanalysis that > >>> you input to ft_singleplotTFR, assuming that it's averaged over trials > >>> and therefore small)? Then we can see whether this is reproducable on > >>> our systems. > >>> > >>> Best, > >>> Eelke > >>> > >>> On 16 September 2013 17:12, Casper van Heck > >>> wrote: > >>> > Dear Fieldtrippers, > >>> > > >>> > I've been doing some exploratory plotting of a dataset where several > >>> > subjects were exposed to a continuous stimulus (CPM) over the course > of > >>> > three minutes. One of the things that was asked was a time-frequency > >>> > plot, > >>> > over those three minutes. While I'm not quite sure a TFR can be used > on > >>> > that > >>> > scale without problems, I went ahead with it just to see what > Fieldtrip > >>> > would do. What I got, was this: > >>> > http://tinypic.com/r/zx2tqs/5| > >>> > And I have no idea what went wrong (note that this specific subject > >>> > only got > >>> > a 60s stimulus). Quality of the picture and the validity of the > >>> > analysis > >>> > aside, I have a severe problem with the axes, which seem to be all > over > >>> > the > >>> > place. > >>> > > >>> > I simply read the data using ft_preprocessing (no filters or > anything, > >>> > since > >>> > the student in charge already used a 10Hz high-pass and a 150Hz > >>> > low-pass > >>> > filter). > >>> > The only field in 'cfg' is 'headerfile'. > >>> > > >>> > Next, I call ft_freqanalysis with: > >>> > cfg.output = 'pow'; > >>> > cfg.method = 'wavelet'; % default; Morlet wavelet > >>> > cfg.taper = 'hanning'; > >>> > cfg.tapsmofrq = 4; > >>> > cfg.channel = 'Cz'; > >>> > cfg.foi = [20:0.5:30]; > >>> > cfg.t_ftimwin = ones(length(cfg.foi),1).*0.25; > >>> > cfg.toi = 0:0.5:60; > >>> > > >>> > And finally, I end up with the monstrocity shown earlier. This > problem > >>> > only > >>> > presents itself with Fieldtrip-related functions, the normal > >>> > Matlab-plots > >>> > work as well as they've ever done, so I'm thinking it's something in > >>> > Fieldtrip that's causing this. > >>> > > >>> > My hope is that someone has encountered this problem before, and > knows > >>> > how > >>> > to solve it... > >>> > > >>> > Sincerely, > >>> > > >>> > Casper > >>> > > >>> > > >>> > _______________________________________________ > >>> > fieldtrip mailing list > >>> > fieldtrip at donders.ru.nl > >>> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >>> _______________________________________________ > >>> fieldtrip mailing list > >>> fieldtrip at donders.ru.nl > >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > >> > > > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bingshuo.li at student.uni-tuebingen.de Tue Nov 26 18:26:26 2013 From: bingshuo.li at student.uni-tuebingen.de (Bingshuo Li) Date: Tue, 26 Nov 2013 18:26:26 +0100 Subject: [FieldTrip] ICA in TMS-EEG Message-ID: Dear FieldTrip Community, I recently started to analyze some TMS-EEG datasets and I encountered some questions regarding to using ICA to remove eye movement/muscle artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to inquire the FT community for some hints or suggestions. Below are the details of my questions: //Description of Data Processing// - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance less than 5 kOhm - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per subject) - TMS contaminated data points were cut out symmetrically -18ms to +18ms relative to TMS onset. Cubic spline interpolation is used to fill in the cut. - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line noise - Visual inspection and rejection of trials with obvious unstable signal or channels. //ICA// - ICA algorithm: runica - Demeaned data for ICA training (baseline is defined as the entire epoch -1 to +1s) - Unmixing matrix applied to non-demeaned data for component removal /////QUESTIONS///// Please see the image below for a typical result of ICA from a subject with TMS applied at M1 (32 epochs for ICA training): https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. However, what about component 5, 12, 20, 28? Topology-wise, they seem to have a very anterior origin, but data in the time domain does not seem to correlate with component 1 and 2 very well (judging visually..) Q2: What can you say about components 7, 9, 13 and 18? Are these cranial muscle artifacts? Q3: Also, for components 42 and 54, given their high focality, are these more or less a indication of bad/unstable electrodes? - I guess maybe I am asking too many questions. I think my main problem here is that I do not know what can be a good procedure / rules in manually selecting ICA components for rejection? (I tried to look in the literature but I couldn't find any that can answer my questions). And sometime I have the feeling that my ICA results look like a mess and maybe there were something wrong with my pre-processing or even data collection? Thank you guys in advance for any input! I look forward to hearing from you! Regards, Bingshuo Li MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcantor at umich.edu Tue Nov 26 19:30:06 2013 From: mcantor at umich.edu (Max Cantor) Date: Tue, 26 Nov 2013 13:30:06 -0500 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: Message-ID: Hi Bingshuo, I'm not sure what your code for the ICA is, but it may be beneficial to have the topoplots lined up with the signal, as I find it easier to recognize EOG and ECG artifacts in the signal. The following tutorials explain ICA: http://fieldtrip.fcdonders.nl/example/use_independent_component_analysis_ica_to_remove_ecg_artifacts http://fieldtrip.fcdonders.nl/example/use_independent_component_analysis_ica_to_remove_eog_artifacts In the ECG tutorial, they give a line of code: cfg = []; cfg.channel = {comp.label{2:5} comp.label{15:18}}; % components to be plotted cfg.layout = 'CTF275.lay'; % specify the layout file that should be used for plotting ft_databrowser(cfg, comp) Which outputs the topoplot and the time course of the signal together in a component browser. As far as criteria for correction, our policy is to err on the conservative side; only rejecting EOG and ECG artifacts, even if we find other components that are clearly artifactual (such as are picking up line noise). Without seeing your script, I can't really think of anything offhand that you are doing wrong, but I'm also not very familiar with TMS so there may be someone else who could answer that part of the question better. Good luck, Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Tue, Nov 26, 2013 at 12:26 PM, Bingshuo Li < bingshuo.li at student.uni-tuebingen.de> wrote: > Dear FieldTrip Community, > > I recently started to analyze some TMS-EEG datasets and I encountered some > questions regarding to using ICA to remove eye movement/muscle artifacts in > our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to > inquire the FT community for some hints or suggestions. Below are the > details of my questions: > > //Description of Data Processing// > - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance > less than 5 kOhm > - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per > subject) > - TMS contaminated data points were cut out symmetrically -18ms to +18ms > relative to TMS onset. Cubic spline interpolation is used to fill in the > cut. > - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. > - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line > noise > - Visual inspection and rejection of trials with obvious unstable signal > or channels. > > //ICA// > - ICA algorithm: runica > - Demeaned data for ICA training (baseline is defined as the entire epoch > -1 to +1s) > - Unmixing matrix applied to non-demeaned data for component removal > > /////QUESTIONS///// > Please see the image below for a typical result of ICA from a subject with > TMS applied at M1 (32 epochs for ICA training): > https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png > > Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. > However, what about component 5, 12, 20, 28? Topology-wise, they seem to > have a very anterior origin, but data in the time domain does not seem to > correlate with component 1 and 2 very well (judging visually..) > > Q2: What can you say about components 7, 9, 13 and 18? Are these cranial > muscle artifacts? > > Q3: Also, for components 42 and 54, given their high focality, are these > more or less a indication of bad/unstable electrodes? > > - I guess maybe I am asking too many questions. I think my main problem > here is that I do not know what can be a good procedure / rules in manually > selecting ICA components for rejection? (I tried to look in the literature > but I couldn't find any that can answer my questions). And sometime I have > the feeling that my ICA results look like a mess and maybe there were > something wrong with my pre-processing or even data collection? > > Thank you guys in advance for any input! I look forward to hearing from > you! > > Regards, > > Bingshuo Li > MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.herring at fcdonders.ru.nl Wed Nov 27 09:28:56 2013 From: j.herring at fcdonders.ru.nl (Herring, J.D. (Jim)) Date: Wed, 27 Nov 2013 09:28:56 +0100 (CET) Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: Message-ID: <012d01ceeb4a$b6ff3950$24fdabf0$@herring@fcdonders.ru.nl> Dear Bingshuo, I agree with Max that it would be beneficial to see the timecourses as well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock average the time courses of the ICA components to the onset of the TMS pulse. That helps in identifying components that are related to the TMS pulse. Just from looking at the topographies I would say that component 7 is too posterior for being a cranial muscle artifact given that you are stimulating M1. Also, cranial muscle artifacts related to the TMS pulse usually last up to about 15ms after stimulation onset (see for example: http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.p ng?id=tutorial%3Atms-eeg ) unless you are actually referring to a decay artifact (http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tu torial%3Atms-eeg) , which can last up to one second. You said that you cut and interpolated up to 18ms after stimulation so you should not see any cranial muscle artifacts related to TMS. Too me component 7 looks more like a topography related to posterior alpha oscillations, however, to be sure we need to see the time courses. Component 13 and 18 might be neck muscle artifacts, however, without performing a timelock analysis of the ICA components and inspecting the time courses it is hard to tell whether these are due to the TMS-pulse. Component 42 and 54 could indeed just reflect two bad channels, at least they seem to contain some variance that cannot be explained by a combination of the other channels. Best, Jim From: fieldtrip-bounces at science.ru.nl [mailto:fieldtrip-bounces at science.ru.nl] On Behalf Of Bingshuo Li Sent: dinsdag 26 november 2013 18:26 To: fieldtrip at science.ru.nl Subject: [FieldTrip] ICA in TMS-EEG Dear FieldTrip Community, I recently started to analyze some TMS-EEG datasets and I encountered some questions regarding to using ICA to remove eye movement/muscle artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to inquire the FT community for some hints or suggestions. Below are the details of my questions: //Description of Data Processing// - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance less than 5 kOhm - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per subject) - TMS contaminated data points were cut out symmetrically -18ms to +18ms relative to TMS onset. Cubic spline interpolation is used to fill in the cut. - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line noise - Visual inspection and rejection of trials with obvious unstable signal or channels. //ICA// - ICA algorithm: runica - Demeaned data for ICA training (baseline is defined as the entire epoch -1 to +1s) - Unmixing matrix applied to non-demeaned data for component removal /////QUESTIONS///// Please see the image below for a typical result of ICA from a subject with TMS applied at M1 (32 epochs for ICA training): https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. However, what about component 5, 12, 20, 28? Topology-wise, they seem to have a very anterior origin, but data in the time domain does not seem to correlate with component 1 and 2 very well (judging visually..) Q2: What can you say about components 7, 9, 13 and 18? Are these cranial muscle artifacts? Q3: Also, for components 42 and 54, given their high focality, are these more or less a indication of bad/unstable electrodes? - I guess maybe I am asking too many questions. I think my main problem here is that I do not know what can be a good procedure / rules in manually selecting ICA components for rejection? (I tried to look in the literature but I couldn't find any that can answer my questions). And sometime I have the feeling that my ICA results look like a mess and maybe there were something wrong with my pre-processing or even data collection? Thank you guys in advance for any input! I look forward to hearing from you! Regards, Bingshuo Li MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Wed Nov 27 14:59:16 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Wed, 27 Nov 2013 08:59:16 -0500 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> References: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Dear J.D., Max and Bingshuo, A brief comment: to be more confident about the correlative nature of an artifact being an artifact (a.k.a. unwanted interference) I always consider three things: topographies, time courses and spectra. The last one too, since it might inform about spectral components not evident at the bare eye from the time courses. I'm not familiar with artifacts in TMS, but in all cases experience helps, especially if you see the same pattern in many subjects, in other published studies, from colleagues' data or from independent evidence (e.g. concomitant electromiography recorded from the facial muscles, for muscular artifacts identification). HTH Cristiano On Wed, Nov 27, 2013 at 3:28 AM, Herring, J.D. (Jim) < j.herring at fcdonders.ru.nl> wrote: > Dear Bingshuo, > > > > I agree with Max that it would be beneficial to see the timecourses as > well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock > average the time courses of the ICA components to the onset of the TMS > pulse. That helps in identifying components that are related to the TMS > pulse. > > > > Just from looking at the topographies I would say that component 7 is too > posterior for being a cranial muscle artifact given that you are > stimulating M1. Also, cranial muscle artifacts related to the TMS pulse > usually last up to about 15ms after stimulation onset (see for example: > http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.png?id=tutorial%3Atms-eeg) unless you are actually referring to a decay artifact ( > http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tutorial%3Atms-eeg) > , which can last up to one second. You said that you cut and interpolated > up to 18ms after stimulation so you should not see any cranial muscle > artifacts related to TMS. > > > > Too me component 7 looks more like a topography related to posterior alpha > oscillations, however, to be sure we need to see the time courses. > Component 13 and 18 might be neck muscle artifacts, however, without > performing a timelock analysis of the ICA components and inspecting the > time courses it is hard to tell whether these are due to the TMS-pulse. > > > > Component 42 and 54 could indeed just reflect two bad channels, at least > they seem to contain some variance that cannot be explained by a > combination of the other channels. > > > > Best, > > > > Jim > > > > *From:* fieldtrip-bounces at science.ru.nl [mailto: > fieldtrip-bounces at science.ru.nl] *On Behalf Of *Bingshuo Li > *Sent:* dinsdag 26 november 2013 18:26 > *To:* fieldtrip at science.ru.nl > *Subject:* [FieldTrip] ICA in TMS-EEG > > > > Dear FieldTrip Community, > > I recently started to analyze some TMS-EEG datasets and I encountered some > questions regarding to using ICA to remove eye movement/muscle artifacts in > our EEG data. As I am quite new to the analysis of TMS-EEG, I would like to > inquire the FT community for some hints or suggestions. Below are the > details of my questions: > > //Description of Data Processing// > > - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance > less than 5 kOhm > > - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials per > subject) > > - TMS contaminated data points were cut out symmetrically -18ms to +18ms > relative to TMS onset. Cubic spline interpolation is used to fill in the > cut. > > - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. > - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line > noise > > - Visual inspection and rejection of trials with obvious unstable signal > or channels. > > //ICA// > > - ICA algorithm: runica > > - Demeaned data for ICA training (baseline is defined as the entire epoch > -1 to +1s) > > - Unmixing matrix applied to non-demeaned data for component removal > > /////QUESTIONS///// > > Please see the image below for a typical result of ICA from a subject with > TMS applied at M1 (32 epochs for ICA training): > https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png > > Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. > However, what about component 5, 12, 20, 28? Topology-wise, they seem to > have a very anterior origin, but data in the time domain does not seem to > correlate with component 1 and 2 very well (judging visually..) > > Q2: What can you say about components 7, 9, 13 and 18? Are these cranial > muscle artifacts? > > Q3: Also, for components 42 and 54, given their high focality, are these > more or less a indication of bad/unstable electrodes? > > - I guess maybe I am asking too many questions. I think my main problem > here is that I do not know what can be a good procedure / rules in manually > selecting ICA components for rejection? (I tried to look in the literature > but I couldn't find any that can answer my questions). And sometime I have > the feeling that my ICA results look like a mess and maybe there were > something wrong with my pre-processing or even data collection? > > Thank you guys in advance for any input! I look forward to hearing from > you! > > Regards, > > Bingshuo Li > > MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgrande at cbs.mpg.de Wed Nov 27 16:28:46 2013 From: fgrande at cbs.mpg.de (Federico Grande) Date: Wed, 27 Nov 2013 16:28:46 +0100 (CET) Subject: [FieldTrip] Channel_selection Message-ID: <1142014025.14097.1385566126242.JavaMail.root@zimbra> Hello everyone, In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. Any suggestion? Thank you very much!! All the best, Federico Grande From jm.horschig at donders.ru.nl Wed Nov 27 16:46:56 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Wed, 27 Nov 2013 16:46:56 +0100 Subject: [FieldTrip] Channel_selection In-Reply-To: <1142014025.14097.1385566126242.JavaMail.root@zimbra> References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> Message-ID: <529613F0.7030801@donders.ru.nl> Hi Frederico, I think the best solution is to not use fieldtrip but plain matlab function. This is a small example that might help you: >> allchans = {'Fz', 'Cz', 'CPz'}; >> badchans = {'Fz', 'Cz'}; >> idx = ismember(allchans, badchans) idx = 1 1 0 You can then use the idx variable and logical indexing to get the good channels: >> allchans(~idx) ans = 'CPz' And then use cfg.channel = allchans(~idx). Be aware that ismember is a tricky function, because it returns the indices of the first vector as the first return variable and the respective same for the second vector as the second return variable, so order does matter. Just give it a try and play a bit around with it and you'll see. Best, Jörn Federico Grande wrote: > Hello everyone, > > In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. > > Any suggestion? > > Thank you very much!! > > All the best, > > Federico Grande > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands From mcantor at umich.edu Wed Nov 27 17:13:07 2013 From: mcantor at umich.edu (Max Cantor) Date: Wed, 27 Nov 2013 11:13:07 -0500 Subject: [FieldTrip] Channel_selection In-Reply-To: <529613F0.7030801@donders.ru.nl> References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> <529613F0.7030801@donders.ru.nl> Message-ID: Here is how I do it: allchan = ft_read_header(dataset); (preprocess) allchan.label = [allchan.label; implicitref]; (after artifact rejection/ICA/etc.) badchan = ft_channelselection('gui', allchan.label); This gives me the channel labels for all channels, with the implicitref added back in (normally this is removed), then a gui which lets me remove bad channels manually after preprocessing/artifact rejection/ICA/etc. Hope this helps. Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl> wrote: > Hi Frederico, > > I think the best solution is to not use fieldtrip but plain matlab > function. This is a small example that might help you: > > >> allchans = {'Fz', 'Cz', 'CPz'}; > >> badchans = {'Fz', 'Cz'}; > >> idx = ismember(allchans, badchans) > > idx = > > 1 1 0 > > You can then use the idx variable and logical indexing to get the good > channels: > > >> allchans(~idx) > > ans = > > 'CPz' > > And then use cfg.channel = allchans(~idx). > > Be aware that ismember is a tricky function, because it returns the > indices of the first vector as the first return variable and the respective > same for the second vector as the second return variable, so order does > matter. Just give it a try and play a bit around with it and you'll see. > > Best, > Jörn > > > > Federico Grande wrote: > >> Hello everyone, >> >> In order to clean a little bit more my measurements, I have developed a >> method which detects bad channels, and now, once I have the labels of the >> bad channels, I want to give it to ft_preprocessing, but I don't know how. >> I've been looking on ft_channelselection, and it seems that there is an >> option , by using some like channel={'all','-channel to exclude'}. I have >> an array with the labels of this channels that I want to exclude, but I >> don't know why, it seems that I am not using it in the proper way. I have >> tried with cfg.channel= {'all','-badSelections'} (badSelections is my >> array), and it doesn't work, since after processing, still appear all the >> channels in the dat.label. >> >> Any suggestion? >> >> Thank you very much!! >> >> All the best, >> >> Federico Grande >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f.roux at bcbl.eu Wed Nov 27 19:14:26 2013 From: f.roux at bcbl.eu (=?utf-8?B?RnLDqWTDqXJpYw==?= Roux) Date: Wed, 27 Nov 2013 19:14:26 +0100 (CET) Subject: [FieldTrip] MEG-Ph.D. Studentship in Glasgow In-Reply-To: Message-ID: <1590326653.92591.1385576066623.JavaMail.root@bcbl.eu> On behalf of Peter Uhlhaas: Dear colleagues, I would like to alert you to a fully funded 3 ½ year Ph.D. studentship which is available at the Centre for Cognitive Neuroimaging , University of Glasgow. The project will use MEG to examine sensory predictions in patients with schizophrenia and will start in October 2014. The Ph.D. student will be supervised by Prof. Joachim Gross and Dr. Peter Uhlhaas. Details of the project are attached. Further infos on the studentship can be found here: http://www.gla.ac.uk/colleges/mvls/graduateschool/researchopportunities/studentshipopportunities/medicalresearchcouncil/ Inquiries can be forwarded to either one of the supervisors. Best wishes, Peter Uhlhaas Dr. Peter J. Uhlhaas Reader Institute for Neuroscience and Psychology University of Glasgow 58 Hillhead Street Glasgow G12 8QB Telephone +44 (0)141 330 8730 -- Frédéric Roux -------------- next part -------------- A non-text attachment was scrubbed... Name: MRC_Studentship_MEG in Schizophrenia.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 14535 bytes Desc: not available URL: From mcgoiv0 at wfu.edu Wed Nov 27 19:58:47 2013 From: mcgoiv0 at wfu.edu (McGowin, Inna) Date: Wed, 27 Nov 2013 13:58:47 -0500 Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: References: Message-ID: Hello, I am trying to apply head motion correction to a continuous MEG recording with Ft_regressconfound. Bcs the output of the Ft_regressconfound function is in the trial format , technically, I can proceed with the head motion regression method on the continuous data by dividing the data into smaller segments; which I did. I have 120 sec of MEG data (SR=600 Hz) that were divided into 10, or 20, or 30 sec trials. I run ft_regressconfound on these trials. No matter what the trial length or the total number of trials are, I get out of memory message in Matlab. Matlab error message: ??? Error using==>mldivide Out of memory. Error in ==> ft_regressconfound at 213 beta = regr\dat; % B= X\Y The error appears in the part of the code where the linear equation is solved directly. I tried to only work with a subset of all trials (half for example) with no luck. I rum MatlabR2010a on Windows XP 32-bit with the following memory allocation in Matlab: Max possible array: 851 Mb Memory available for all array: 1703 Mb Memory used by Matlab: 850 Mb RAM: 3317 Mb Were anybody else able to run this motion regression algorithm in Matlab without out of memory? Is there anything I can do to avoid the problem? I can share the code if needed. Thanks in advance, Inna Inna McGowin On Mon, Nov 18, 2013 at 10:42 AM, Arjen Stolk wrote: > Hi Inna, > Ft_regressconfound will remove trial by trial variability of signal > amplitude or frequency power that can be explained by variability in head > position over those trials. The input, whether sensor or source level, > should contain a trial field (keep trials in the previous step - eg at > timelockanalysis). Also variance due to head position can only be reliably > estimated when the neural signal is consistent over trials (as with an > event related modulation or potential). I would not know how to segment a > resting state into trials (for further analysis, given that those analyses > typically involve connectivity measures over the resting period) but if you > an idea on how to do this, you could give ft_regressconfound a try. Note > that the output will also be in the trials format. Hope this has made its > use a bit more clear. Yours, arjen > > Op 13 nov. 2013 11:50 schreef "McGowin, Inna" het > volgende: > > > > > Hello everybody, > > > > I would like to use the ft_regressconfound function to remove/reduce > the head motion in a continuous MEG data. > > It's a resting state data and no averaging can be applied. Is there a > way to apply the correction without using the > > > > ft_timelockanalysis(cfg, data) function? > > > > I understand that the ft_regressconfound function has limits and caveats > but I still would like to see the results of its correction. > > > > > > Another way to ask this question is: > > what is the format/structure of the second input (timelock) in the > > ft_regressconfound(cfg, timelock) function and how it can be created > without ft_timelockanalysis? > > > > > > Thanks, > > > > Inna > > > > _______________________________________________ > > fieldtrip mailing list > > fieldtrip at donders.ru.nl > > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelic72 at gmail.com Thu Nov 28 03:11:12 2013 From: michelic72 at gmail.com (Cristiano Micheli) Date: Wed, 27 Nov 2013 21:11:12 -0500 Subject: [FieldTrip] Channel_selection In-Reply-To: References: <1142014025.14097.1385566126242.JavaMail.root@zimbra> <529613F0.7030801@donders.ru.nl> Message-ID: Dear Federico il Grande Allow 'badchstr' to be a cellarray of strings like this: badchstr = {'label2' 'labe8' ... 'label199'}; Try this: chstr = {'all'}; for i=1:numel(badchstr) chstr(i+1) = cellstr(sprintf('-%s ',badchstr{i})); end cfg = []; cfg.channel = chstr; dataclean = ft_preprocessing(cfg,data); Best, Cristiano On Wed, Nov 27, 2013 at 11:13 AM, Max Cantor wrote: > Here is how I do it: > > allchan = ft_read_header(dataset); > > (preprocess) > > allchan.label = [allchan.label; implicitref]; > > (after artifact rejection/ICA/etc.) > > badchan = ft_channelselection('gui', allchan.label); > > This gives me the channel labels for all channels, with the implicitref > added back in (normally this is removed), then a gui which lets me remove > bad channels manually after preprocessing/artifact rejection/ICA/etc. > > Hope this helps. > > Max Cantor > Research Assistant > Computational Neurolinguistics Lab > University of Michigan > > > On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < > jm.horschig at donders.ru.nl> wrote: > >> Hi Frederico, >> >> I think the best solution is to not use fieldtrip but plain matlab >> function. This is a small example that might help you: >> >> >> allchans = {'Fz', 'Cz', 'CPz'}; >> >> badchans = {'Fz', 'Cz'}; >> >> idx = ismember(allchans, badchans) >> >> idx = >> >> 1 1 0 >> >> You can then use the idx variable and logical indexing to get the good >> channels: >> >> >> allchans(~idx) >> >> ans = >> >> 'CPz' >> >> And then use cfg.channel = allchans(~idx). >> >> Be aware that ismember is a tricky function, because it returns the >> indices of the first vector as the first return variable and the respective >> same for the second vector as the second return variable, so order does >> matter. Just give it a try and play a bit around with it and you'll see. >> >> Best, >> Jörn >> >> >> >> Federico Grande wrote: >> >>> Hello everyone, >>> >>> In order to clean a little bit more my measurements, I have developed a >>> method which detects bad channels, and now, once I have the labels of the >>> bad channels, I want to give it to ft_preprocessing, but I don't know how. >>> I've been looking on ft_channelselection, and it seems that there is an >>> option , by using some like channel={'all','-channel to exclude'}. I have >>> an array with the labels of this channels that I want to exclude, but I >>> don't know why, it seems that I am not using it in the proper way. I have >>> tried with cfg.channel= {'all','-badSelections'} (badSelections is my >>> array), and it doesn't work, since after processing, still appear all the >>> channels in the dat.label. >>> >>> Any suggestion? >>> >>> Thank you very much!! >>> >>> All the best, >>> >>> Federico Grande >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> -- >> Jörn M. Horschig >> PhD Student >> Donders Institute for Brain, Cognition and Behaviour >> Centre for Cognitive Neuroimaging >> Radboud University Nijmegen >> Neuronal Oscillations Group >> FieldTrip Development Team >> >> P.O. Box 9101 >> NL-6500 HB Nijmegen >> The Netherlands >> >> Contact: >> E-Mail: jm.horschig at donders.ru.nl >> Tel: +31-(0)24-36-68493 >> Web: http://www.ru.nl/donders >> >> Visiting address: >> Trigon, room 2.30 >> Kapittelweg 29 >> NL-6525 EN Nijmegen >> The Netherlands >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bingshuo.li at student.uni-tuebingen.de Thu Nov 28 09:16:16 2013 From: bingshuo.li at student.uni-tuebingen.de (Bingshuo Li) Date: Thu, 28 Nov 2013 09:16:16 +0100 Subject: [FieldTrip] ICA in TMS-EEG In-Reply-To: References: <5295ad61.81240f0a.584c.ffff9e62SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: Dear Max, Jim and Cristiano, Thank you so much for sharing your experiences! I found your comments very helpful. I will certain try the things you suggested and see how the ICA works this time. In addition, given that I have EOG and ECG recorded (but with different references), maybe it will also be beneficial if I calculate the coherence between the ICA components and EOG and ECG signals. Furthermore, I think it will be very beneficial to the field if someone with rich experiences in applying ICA in TMS-EEG can write a paper on manual artifactual components recognition! ;) Regards, ----- Bingshuo Li (MSc. candidate), Neuroprosthetic Group, CIN, Uni Tübingen On Wed, Nov 27, 2013 at 2:59 PM, Cristiano Micheli wrote: > Dear J.D., Max and Bingshuo, > > A brief comment: to be more confident about the correlative nature of an > artifact being an artifact (a.k.a. unwanted interference) I always consider > three things: topographies, time courses and spectra. The last one too, > since it might inform about spectral components not evident at the bare eye > from the time courses. > I'm not familiar with artifacts in TMS, but in all cases experience helps, > especially if you see the same pattern in many subjects, in other published > studies, from colleagues' data or from independent evidence (e.g. > concomitant electromiography recorded from the facial muscles, for muscular > artifacts identification). > > HTH > Cristiano > > > > > > On Wed, Nov 27, 2013 at 3:28 AM, Herring, J.D. (Jim) < > j.herring at fcdonders.ru.nl> wrote: > >> Dear Bingshuo, >> >> >> >> I agree with Max that it would be beneficial to see the timecourses as >> well. Also, in case of ICA on TMS-EEG data I find it usefull to timelock >> average the time courses of the ICA components to the onset of the TMS >> pulse. That helps in identifying components that are related to the TMS >> pulse. >> >> >> >> Just from looking at the topographies I would say that component 7 is too >> posterior for being a cranial muscle artifact given that you are >> stimulating M1. Also, cranial muscle artifacts related to the TMS pulse >> usually last up to about 15ms after stimulation onset (see for example: >> http://fieldtrip.fcdonders.nl/_detail/development/tms/art_cranial_muscle.png?id=tutorial%3Atms-eeg) unless you are actually referring to a decay artifact ( >> http://fieldtrip.fcdonders.nl/_detail/development/tms/art_decay.png?id=tutorial%3Atms-eeg) >> , which can last up to one second. You said that you cut and interpolated >> up to 18ms after stimulation so you should not see any cranial muscle >> artifacts related to TMS. >> >> >> >> Too me component 7 looks more like a topography related to posterior >> alpha oscillations, however, to be sure we need to see the time courses. >> Component 13 and 18 might be neck muscle artifacts, however, without >> performing a timelock analysis of the ICA components and inspecting the >> time courses it is hard to tell whether these are due to the TMS-pulse. >> >> >> >> Component 42 and 54 could indeed just reflect two bad channels, at least >> they seem to contain some variance that cannot be explained by a >> combination of the other channels. >> >> >> >> Best, >> >> >> >> Jim >> >> >> >> *From:* fieldtrip-bounces at science.ru.nl [mailto: >> fieldtrip-bounces at science.ru.nl] *On Behalf Of *Bingshuo Li >> *Sent:* dinsdag 26 november 2013 18:26 >> *To:* fieldtrip at science.ru.nl >> *Subject:* [FieldTrip] ICA in TMS-EEG >> >> >> >> Dear FieldTrip Community, >> >> I recently started to analyze some TMS-EEG datasets and I encountered >> some questions regarding to using ICA to remove eye movement/muscle >> artifacts in our EEG data. As I am quite new to the analysis of TMS-EEG, I >> would like to inquire the FT community for some hints or suggestions. Below >> are the details of my questions: >> >> //Description of Data Processing// >> >> - EEG with 64 channel, sampling frequency 2500 Hz, electrode impedance >> less than 5 kOhm >> >> - Every epoch consists of 1s prior to and 1s after TMS (130-150 trials >> per subject) >> >> - TMS contaminated data points were cut out symmetrically -18ms to +18ms >> relative to TMS onset. Cubic spline interpolation is used to fill in the >> cut. >> >> - Bandpass 0.5 - 80 Hz, with BUT and filter order 3. >> - Discrete Fourier transform filter (cfg.dftfilter) to remove 50 Hz line >> noise >> >> - Visual inspection and rejection of trials with obvious unstable signal >> or channels. >> >> //ICA// >> >> - ICA algorithm: runica >> >> - Demeaned data for ICA training (baseline is defined as the entire epoch >> -1 to +1s) >> >> - Unmixing matrix applied to non-demeaned data for component removal >> >> /////QUESTIONS///// >> >> Please see the image below for a typical result of ICA from a subject >> with TMS applied at M1 (32 epochs for ICA training): >> https://www.dropbox.com/s/chwo2jnwi72saba/ica1.png >> >> Q1: It seems obvious to me that component 1 and 2 are of eyeblink origin. >> However, what about component 5, 12, 20, 28? Topology-wise, they seem to >> have a very anterior origin, but data in the time domain does not seem to >> correlate with component 1 and 2 very well (judging visually..) >> >> Q2: What can you say about components 7, 9, 13 and 18? Are these cranial >> muscle artifacts? >> >> Q3: Also, for components 42 and 54, given their high focality, are these >> more or less a indication of bad/unstable electrodes? >> >> - I guess maybe I am asking too many questions. I think my main problem >> here is that I do not know what can be a good procedure / rules in manually >> selecting ICA components for rejection? (I tried to look in the literature >> but I couldn't find any that can answer my questions). And sometime I have >> the feeling that my ICA results look like a mess and maybe there were >> something wrong with my pre-processing or even data collection? >> >> Thank you guys in advance for any input! I look forward to hearing from >> you! >> >> Regards, >> >> Bingshuo Li >> >> MSc. Student, Neuroprosthetic Group, CIN, Uni Tübingen >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgrande at cbs.mpg.de Thu Nov 28 09:49:21 2013 From: fgrande at cbs.mpg.de (Federico Grande) Date: Thu, 28 Nov 2013 09:49:21 +0100 (CET) Subject: [FieldTrip] Channel_selection In-Reply-To: Message-ID: <875544209.1015.1385628561634.JavaMail.root@zimbra> Thank you all! All the best, Federico ----- Original Message ----- From: "Cristiano Micheli" To: "FieldTrip discussion list" Sent: Thursday, November 28, 2013 3:11:12 AM Subject: Re: [FieldTrip] Channel_selection Dear Federico il Grande Allow 'badchstr' to be a cellarray of strings like this: badchstr = {'label2' 'labe8' ... 'label199'}; Try this: chstr = { 'all' }; for i=1:numel(badchstr) chstr(i+1) = cellstr(sprintf( '-%s ' ,badchstr{i})); end cfg = []; cfg.channel = chstr; dataclean = ft_preprocessing(cfg,data); Best, Cristiano On Wed, Nov 27, 2013 at 11:13 AM, Max Cantor < mcantor at umich.edu > wrote: Here is how I do it: allchan = ft_read_header(dataset); (preprocess) allchan.label = [allchan.label; implicitref]; (after artifact rejection/ICA/etc.) badchan = ft_channelselection('gui', allchan.label); This gives me the channel labels for all channels, with the implicitref added back in (normally this is removed), then a gui which lets me remove bad channels manually after preprocessing/artifact rejection/ICA/etc. Hope this helps. Max Cantor Research Assistant Computational Neurolinguistics Lab University of Michigan On Wed, Nov 27, 2013 at 10:46 AM, "Jörn M. Horschig" < jm.horschig at donders.ru.nl > wrote: Hi Frederico, I think the best solution is to not use fieldtrip but plain matlab function. This is a small example that might help you: >> allchans = {'Fz', 'Cz', 'CPz'}; >> badchans = {'Fz', 'Cz'}; >> idx = ismember(allchans, badchans) idx = 1 1 0 You can then use the idx variable and logical indexing to get the good channels: >> allchans(~idx) ans = 'CPz' And then use cfg.channel = allchans(~idx). Be aware that ismember is a tricky function, because it returns the indices of the first vector as the first return variable and the respective same for the second vector as the second return variable, so order does matter. Just give it a try and play a bit around with it and you'll see. Best, Jörn Federico Grande wrote: Hello everyone, In order to clean a little bit more my measurements, I have developed a method which detects bad channels, and now, once I have the labels of the bad channels, I want to give it to ft_preprocessing, but I don't know how. I've been looking on ft_channelselection, and it seems that there is an option , by using some like channel={'all','-channel to exclude'}. I have an array with the labels of this channels that I want to exclude, but I don't know why, it seems that I am not using it in the proper way. I have tried with cfg.channel= {'all','-badSelections'} (badSelections is my array), and it doesn't work, since after processing, still appear all the channels in the dat.label. Any suggestion? Thank you very much!! All the best, Federico Grande ______________________________ _________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands ______________________________ _________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/ mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip _______________________________________________ fieldtrip mailing list fieldtrip at donders.ru.nl http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From eelke.spaak at donders.ru.nl Thu Nov 28 11:22:04 2013 From: eelke.spaak at donders.ru.nl (Eelke Spaak) Date: Thu, 28 Nov 2013 11:22:04 +0100 Subject: [FieldTrip] LCMV giving conflicting results vs SAM and DICS In-Reply-To: References: <6D713918-6272-4E96-8CDF-0ECE2B95DE5A@ucdenver.edu> Message-ID: Hi Haris, Sorry for the slow reply, I had other stuff to do for a while. It seems that you have indeed stumbled on a bug, unfortunately. Let's move the discussion over to bugzilla: http://bugzilla.fcdonders.nl/show_bug.cgi?id=2395 Feel free to contribute anything there if you like (you can create an account if you don't have one yet). Hopefully we will be able to fix this soon. Best, Eelke On 29 October 2013 00:02, Charidimos Tzagarakis wrote: > Hi Eelke, > I have now run a test which I think does what you describe. > cfg.keeptrials='yes' for the calls to ft_timelockanalysis and > ft_sourcenalysis that generate the filter. > cfg.keeptrials='no' for all the other calls to these 2 functions (those that > generate the 2 conditions to be compared). > The result is still the same (ie not what I would call the 'correct' one, > but rather what seems to be based on an evoked response covariance matrix). > I should stress again that how I set keeptrials in ft_timelockanalysis is > also how I set it for the "matched" call to ft_sourceanalysis (It didn't > seem to me that this matters anyway as unless cfg.rawtrial='yes', > ft_sourceanalysis handles both cases so that what is used further down is > the same but I may be wrong in this) . > Best, > Haris > > > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych > University of Minnesota Dept of Neuroscience and Brain Sciences Center > > > > > On 28 October 2013 05:26, Eelke Spaak wrote: >> >> Hi Charidimos, >> >> If I understand you correctly, you specified cfg.keeptrials = 'no' in >> the calls to ft_timelockanalysis prior to the *first* call of >> ft_sourceanalysis, right? Could you try what happens when you specify >> it in ft_timelockanalysis prior to the second call to >> ft_sourceanalysis (so the step where the precomputed filter is >> applied)? >> >> Thanks, >> Eelke >> >> On 25 October 2013 01:06, Charidimos Tzagarakis wrote: >> > Hi Eelke, >> > Thank you for looking into this! >> > The piece of code I commented out is indeed [790:836] (changing line 784 >> > accordingly or alternatively adding a copy of 785-789 after 790). >> > I did try running ft_timelockanalysis with keeptrials='no' for all 3 >> > calls >> > and that resulted in the same behaviour as before for LCMV (ie not the >> > "correct" one). I also tried it setting keeptrials='no' in >> > ft_sourceanalysis at the same time (ie keeptrials='no' for both >> > ft_timelockanalysis and ft_sourceanalysis) which had the same outcome (I >> > actually had run these tests before posting but wanted to 2ble check). >> > I may however be confused here because there are some other possible >> > combinations with keeptrials since for each subject there is a total of >> > 6 >> > calls to functions that accept it as an input and the filter is >> > estimated >> > with only 2 of them. >> > Do let me know if there is another combination I should run and I will >> > do >> > that. >> > Best, >> > Haris >> > >> > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> > University of Minnesota Dept of Neuroscience and Brain Sciences Center >> > >> > >> > On 24 October 2013 03:08, Eelke Spaak wrote: >> >> >> >> Hi Charidimos, >> >> >> >> Thanks for your elaborate e-mail. We discussed this issue in >> >> yesterday's FieldTrip meeting. It is very reasonable that you expect >> >> the three methods to produce the same results, and the code/interface >> >> indeed suggests that this would be the case. In other words, we need >> >> to clean up this part of the code to produce consistent results; >> >> however, this might take a while. >> >> >> >> We believe the discrepancy is caused by the fact that you compute the >> >> covariance while specifying cfg.keeptrials = 'yes', which is >> >> unnecessary while computing the filter. This results in a covariance >> >> matrix with dimensions trial X channel X channel, which then is >> >> subsequently averaged over trials during ft_sourceanalysis. Likely the >> >> filter is still in fact computed on the averaged covariance, as it >> >> should be. However, the subsequent projection of data through the >> >> filter will not first average the covariance, and will in essence only >> >> project the first trial through the filter. (This is because the dip{} >> >> fields will be struct arrays of dimension nTrial X 1, and in an >> >> assignment a(1).b = 2; a(2).b = 3; x = a; then x will be 2, so >> >> everything but the first element of a struct array is ignored in an >> >> assignment statement.) >> >> >> >> Could you try to compute the covariance with cfg.keeptrials = 'no' and >> >> then run LCMV again? This will still compute the covariance on the raw >> >> traces, not on the average. If our hunch is right, you should get the >> >> correct results then. >> >> >> >> As said, this is indeed messy and unclear, our apologies for that. >> >> >> >> Finally, could you tell us what part of the code you commented out to >> >> make the results consistent? We suspect it will be between lines 790 >> >> and 835, but it would be helpful to know for sure. >> >> >> >> Best, >> >> Eelke >> >> >> >> >> >> On 23 October 2013 21:43, Charidimos Tzagarakis >> >> wrote: >> >> > Hi Don, >> >> > Thanks for your reply. I do agree that some of these beamformers >> >> > are probably better suited than others to study beta >> >> > desynchronisation, >> >> > or >> >> > generally questions in the frequency domain. I in fact started from >> >> > DICS. >> >> > The reason I looked at LCMV and SAM is to be sure that I get >> >> > consistent >> >> > results (and also because my experiment can also address some >> >> > additional >> >> > time domain questions, so I wanted to see what happens when my data >> >> > goes >> >> > from one to the other). I therefore tried to set them up so I that >> >> > the >> >> > results from all 3 are similar. So you are correct in pointing out >> >> > that >> >> > my >> >> > question is why SAM and LCMV produce different results. Based on >> >> > their >> >> > description within the fieldtrip website and mailing list (if I have >> >> > interpreted these correctly) they should be treating the covariance >> >> > matrix >> >> > in the same way (to get a true evoked response covariance matrix you >> >> > would >> >> > normally need the extra call to ft_timelockanalysis that I show at >> >> > the >> >> > last >> >> > piece of code in my post). Also , if the covariance matrix is indeed >> >> > the >> >> > issue, it seems that the change in how it is treated in the >> >> > ft_sourceanalysis code (based on the "hack" I described) is unique to >> >> > LCMV >> >> > (none of the other beamformer options share that piece of code) and >> >> > is >> >> > active only when LCMV is given a precomputed filter which is (I >> >> > think) >> >> > unusual. >> >> > Hence my question! >> >> > Best, >> >> > Haris >> >> > >> >> > Charidimos [Haris] Tzagarakis MD, PhD, MRCPsych >> >> > University of Minnesota Dept of Neuroscience and Brain Sciences >> >> > Center >> >> > >> >> > >> >> > >> >> > On 23 October 2013 13:31, Rojas, Don wrote: >> >> >> >> >> >> Haris, >> >> >> >> >> >> Sorry - In my last post, I mistakenly put DICS and the Fieldtrip >> >> >> implementation of SAM into the same frequency domain category. In >> >> >> Fieldtrip, >> >> >> SAM is a time-domain technique and is not the same as the >> >> >> implementation of >> >> >> SAM that has been used in the published literature for beta ERD. So, >> >> >> are you >> >> >> then wondering why the two time-domain approaches produce differing >> >> >> results? >> >> >> That probably does depend on how the covariance matrix is >> >> >> calculated. >> >> >> Although I still think it is a bad idea to use a time-domain >> >> >> beamformer >> >> >> on >> >> >> motor beta ERD/ERS. >> >> >> >> >> >> Best, >> >> >> >> >> >> Don >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> fieldtrip mailing list >> >> >> fieldtrip at donders.ru.nl >> >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > fieldtrip mailing list >> >> > fieldtrip at donders.ru.nl >> >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > >> > >> > >> > _______________________________________________ >> > fieldtrip mailing list >> > fieldtrip at donders.ru.nl >> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From a.stolk at fcdonders.ru.nl Thu Nov 28 18:23:16 2013 From: a.stolk at fcdonders.ru.nl (Stolk, A. (Arjen)) Date: Thu, 28 Nov 2013 18:23:16 +0100 (CET) Subject: [FieldTrip] Fwd: head motion regression with ft_regressconfound on a continuous MEG data In-Reply-To: Message-ID: <2046766750.4089031.1385659396420.JavaMail.root@sculptor.zimbra.ru.nl> Hi Inna, Are you using the same design matrix as on the wiki page? That one covers the primary head translations and rotations, but also their derivatives. You could try using the primary measures only (3 translastions, and 3 rotations of the circumcenter, totaling 6 + 1 constant regressors). It is also mentionworthy that there should be a balance between the number of regressors and the number of observations (i.e. trials). I believe on the respective wiki page on head movement regression it states that the ratio is recommended to be not larger than 1:10 (regressors:trials), accompanied with a reference. Accordingly, I'd suggest to use those 7 regressors, and your data (120s resting state) split in segments of 1 or 2 seconds, totaling 60 or 120 trials. These specifications might hopefully also allow working around your memory issue. Second, it may be worth mentioning what you would like to do with the data post-movement-regression. Namely, the movement compensation will remove contributions from head movement to the signal. But this requires that signal to behave consistently over trials, which does not seem the case with the signal in your resting study? That is, with an ERP study, the signal fluctuations appear consistent over trials, with amplitudes being modulated by head movement (i.e. sensor-source distance, see our neuroimage paper - 2013) in a predictable fashion. So if you're planning on doing frequency analysis, or maybe connectivity analysis, after head movement compensation, I'd recommend reversing that order. The rule of thumb is to use ft_regressconfound just prior to ft_xxxstatistics, removing otherwise unexplained variance (over trials) due to head movement, benefitting your statistical assessments. Hope these suggestions may help you with further analyses. I'm not familiar with anyone implementing this method to resting state analyses, but maybe someone else has some first-hand experience here. Furthermore, too late for your current dataset, but for a next one I'd recommend using the online head position monitoring/respositioning tool that we have developed for CTF systems (a neuromag version is approaching the final stage). This tool is routinely used in our lab to monitor and reduce head movment throughout recording (after which ft_regressconfound is being used to deal with the trial-by-trial crumbles). Yours, Arjen -------------- next part -------------- An HTML attachment was scrubbed... URL: From faranak.farzan at gmail.com Thu Nov 28 22:46:17 2013 From: faranak.farzan at gmail.com (Faranak Farzan) Date: Thu, 28 Nov 2013 16:46:17 -0500 Subject: [FieldTrip] Question regarding cluster-based permutation test Message-ID: Hi There, Hope this finds you well. We have a question in regards to 4 Dimensional cluster-based analysis meaning Data = Time X Freq X Channel X Subjects. Does fieldtrip allow us to produce clusters on a 3D matrix (TIME X FREQ X CHANNEL) while shuffling between/within subjects/groups? Or one should go about doing Time and Freq permutation separately (2D clusters at one specific frequency (or time))? Many thanks in advance, Regards, Faranak -------------- next part -------------- An HTML attachment was scrubbed... URL: From politzerahless at gmail.com Fri Nov 29 12:14:26 2013 From: politzerahless at gmail.com (Stephen Politzer-Ahles) Date: Fri, 29 Nov 2013 15:14:26 +0400 Subject: [FieldTrip] Question regarding cluster-based permutation test Message-ID: Hello Faranak, If you're doing a within-subjects design, then testing channels*time*freq on grand average data should be possible; see http://fieldtrip.fcdonders.nl/tutorial/cluster_permutation_freq#within_subjects_experiments . Best, Steve Stephen Politzer-Ahles New York University, Abu Dhabi Neuroscience of Language Lab http://www.nyu.edu/projects/politzer-ahles/ > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Nov 2013 16:46:17 -0500 > From: Faranak Farzan > To: fieldtrip at science.ru.nl > Subject: [FieldTrip] Question regarding cluster-based permutation test > Message-ID: > < CAEq_seaWYL87ZjXa0OX20xO1BqkGXHxODQrAVtbFsVg-6PuvHA at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi There, > > Hope this finds you well. We have a question in regards to 4 Dimensional > cluster-based analysis meaning Data = Time X Freq X Channel X Subjects. > Does fieldtrip allow us to produce clusters on a 3D matrix (TIME X FREQ X > CHANNEL) while shuffling between/within subjects/groups? Or one should go > about doing Time and Freq permutation separately (2D clusters at one > specific frequency (or time))? > > Many thanks in advance, > > Regards, > > Faranak > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20131128/e67e370e/attachment-0001.html > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 36, Issue 52 > ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbirot at gmail.com Fri Nov 29 13:15:16 2013 From: gbirot at gmail.com (Gwenael Birot) Date: Fri, 29 Nov 2013 13:15:16 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables Message-ID: Dear all, I am trying to use the simbio package available in fieldtrip in order to compute the FEM headmodel. My OS is windows 7 64bits. When executing ft_headmodel_simbio I have got the following error: Error using sb_calc_stiff (line 89) Error executing mex-file. Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables are required. I installed these packages but I still have the error. It looks like there is several versions of these packages. Do I need one in particular or does any version is supposed to work? Thanks a lot, Gwenael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jm.horschig at donders.ru.nl Fri Nov 29 14:03:09 2013 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Fri, 29 Nov 2013 14:03:09 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables In-Reply-To: References: Message-ID: <5298908D.2000005@donders.ru.nl> Hi Gwenael, I am not sure how much you know about mex-files, so this might go a bit over the top. The error you are describing probably stems from the fact that there are additional dependencies to other files on the mexed-version. We encountered similar things in the past with other FieldTrip functions, and found that the 2008 compiler actually should be compatible with any Windows version. Maybe the one who compiled the simbio toolbox did something other funky? Anyway, long story short, since the simbio toolbox is an external toolbox, we as the FieldTrip team do not maintain it. I don't know what you precisely need to install. You can use http://dependencywalker.com/ to find dependencies of the respective mexw64 file and try to find the respective packages containing these files. Just to assure you, when I try to execute the mex-file on Windows, I also get that error. On Linux it works fine though. I will bring this up in the next FieldTrip meeting and we will discuss this. We'll let you know about a solution. You could also go ahead and contact the Simbio guys directly (and share whatever the solution is with us, please) Best, Jörn Gwenael Birot wrote: > Dear all, > > I am trying to use the simbio package available in fieldtrip in order > to compute the FEM headmodel. My OS is windows 7 64bits. When > executing ft_headmodel_simbio I have got the following error: > > Error using sb_calc_stiff (line 89) > Error executing mex-file. Microsoft Visual C++ 2008 Redistributables > and Intel Visual Fortran Redistributables are required. > > I installed these packages but I still have the error. It looks like > there is several versions of these packages. Do I need one in > particular or does any version is supposed to work? > > Thanks a lot, > Gwenael > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Neuronal Oscillations Group FieldTrip Development Team P.O. Box 9101 NL-6500 HB Nijmegen The Netherlands Contact: E-Mail: jm.horschig at donders.ru.nl Tel: +31-(0)24-36-68493 Web: http://www.ru.nl/donders Visiting address: Trigon, room 2.30 Kapittelweg 29 NL-6525 EN Nijmegen The Netherlands From jochem.rieger at uni-oldenburg.de Fri Nov 29 14:11:36 2013 From: jochem.rieger at uni-oldenburg.de (Jochem Rieger) Date: Fri, 29 Nov 2013 14:11:36 +0100 Subject: [FieldTrip] Post-doc with focus on statistical learning for analysis of speech coding in the human brain. Message-ID: <52989288.8090802@uni-oldenburg.de> The Department of Applied Neurocognitive Psychology at Oldenburg University, Germany, offers a Post-doctoral position (salary level E13 TVL, 3 years) with a focus on signal processing / statistical learning for analysis of speech coding in the human brain. The position is linked to the collaborative research center "The Active Auditory System" SFB-TR 31. The research center aims to characterize and model mechanism of auditory object formation and scene analysis by combining psychophysical, neurophysiological, and quantitative modelling. It complements the Excellence Cluster "Hearing 4 All" which was recently awarded to the University of Oldenburg. The combined effort of these centers will establish a strong link between neurophysiological models of auditory object representation and subjective perception. The post-doctoral position is situated in a project that applies statistical learning methods to human intracranial recordings (ECoG) and fMRI to derive and test quantitative statistical models of speech coding in the human brain. The experiments are performed in a highly interdisciplinary lab environment and in close collaboration with the University of California Berkeley and Stanford University. The quantitative nature of the research project will require highly motivated candidates with strong quantitative and experimental skills. Successful candidates will perform cutting edge research and should have a background in one or more of the following fields: signal processing, statistical learning, brain-machine-interfacing, non-invasive or invasive human neurophysiology of the auditory system. Applicants must have an academic university degree (Master or equivalent) and a PhD (or equivalent). Successful candidates will work in an interdisciplinary network with opportunities for international exchange. The post-doctoral position is initially limited to three years, with an option for extension, and can be split. Applications should include your CV, a list of most recent publications, two recommendation letters, and a research statement (max. 3 pages). The University of Oldenburg is an equal opportunity employer. The University of Oldenburg is dedicated to increasing the percentage of women in science. Therefore, equally qualified female candidates will be given preference. Applicants with disabilities will be preferentially considered in case of equal qualification. Please send inquiries and electronic applications per email (preferred) to Professor Dr. Jochem Rieger: Jochem.rieger(at)uni-oldenburg.de or paper applications per regular mail to: Margrit Jung Dept. of Applied Neurocognitive Psychology Institute of Psychology Oldenburg University 26111 Oldenburg Germany Application deadline is December 16th, 2013. -- Prof. Dr. rer. nat. Jochem Rieger Director, Institute of Psychology Head of Applied Neurocognitive | Knight Lab Psychology | Helen Wills Neuroscience Institute Faculty VI | University of California Carl-von-Ossietzky University | 132 Barker Hall 26111 Oldenburg | Berkeley, CA 94720-3192 Germany | USA Phone: +49(0)4417984533 Fax: +49(0)4417983865 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbirot at gmail.com Fri Nov 29 16:27:05 2013 From: gbirot at gmail.com (Gwenael Birot) Date: Fri, 29 Nov 2013 16:27:05 +0100 Subject: [FieldTrip] FEM headmodel: Microsoft Visual C++ 2008 Redistributables and Intel Visual Fortran Redistributables In-Reply-To: <5298908D.2000005@donders.ru.nl> References: <5298908D.2000005@donders.ru.nl> Message-ID: Dear Jörn, Thank you for your answer. Problem has been randomly solved by rebooting my computer. I should have know that Windows always needs to be restarted... Best, Gwenael 2013/11/29 "Jörn M. Horschig" > Hi Gwenael, > > I am not sure how much you know about mex-files, so this might go a bit > over the top. The error you are describing probably stems from the fact > that there are additional dependencies to other files on the mexed-version. > We encountered similar things in the past with other FieldTrip functions, > and found that the 2008 compiler actually should be compatible with any > Windows version. Maybe the one who compiled the simbio toolbox did > something other funky? Anyway, long story short, since the simbio toolbox > is an external toolbox, we as the FieldTrip team do not maintain it. I > don't know what you precisely need to install. You can use > http://dependencywalker.com/ to find dependencies of the respective > mexw64 file and try to find the respective packages containing these files. > Just to assure you, when I try to execute the mex-file on Windows, I also > get that error. On Linux it works fine though. I will bring this up in the > next FieldTrip meeting and we will discuss this. We'll let you know about a > solution. You could also go ahead and contact the Simbio guys directly (and > share whatever the solution is with us, please) > > Best, > Jörn > > > Gwenael Birot wrote: > >> Dear all, >> >> I am trying to use the simbio package available in fieldtrip in order to >> compute the FEM headmodel. My OS is windows 7 64bits. When executing >> ft_headmodel_simbio I have got the following error: >> >> Error using sb_calc_stiff (line 89) >> Error executing mex-file. Microsoft Visual C++ 2008 Redistributables and >> Intel Visual Fortran Redistributables are required. >> >> I installed these packages but I still have the error. It looks like >> there is several versions of these packages. Do I need one in particular or >> does any version is supposed to work? >> >> Thanks a lot, >> Gwenael >> >> >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > -- > Jörn M. Horschig > PhD Student > Donders Institute for Brain, Cognition and Behaviour > Centre for Cognitive Neuroimaging > Radboud University Nijmegen > Neuronal Oscillations Group > FieldTrip Development Team > > P.O. Box 9101 > NL-6500 HB Nijmegen > The Netherlands > > Contact: > E-Mail: jm.horschig at donders.ru.nl > Tel: +31-(0)24-36-68493 > Web: http://www.ru.nl/donders > > Visiting address: > Trigon, room 2.30 > Kapittelweg 29 > NL-6525 EN Nijmegen > The Netherlands > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: