From lsbarbosa at gmail.com Tue Feb 1 03:05:59 2011 From: lsbarbosa at gmail.com (Leonardo Barbosa) Date: Tue, 1 Feb 2011 00:05:59 -0200 Subject: [FieldTrip] Forward model for dipoles with fixed position and orientation Message-ID: Dear Fieldtrip users, I'm trying to create a forward model for a fixed number of dipoles with fixed positions and orientations (extracted from a MRI image using freesurfer and a downsampling algorithm) so I can use it with my inverse algorithm. I read this tutorial , a few examplesand function headers , but I still didn't find exactly what I'm trying to do. Is it possible to have as a result of *ft_compute_leadfield*, (and*ft_prepare_leadfield *?,* ft_prepare_sourcemodel*?) a leadfield that depends only on the *intensity* of the dipole? Because it has a fixed orientation, and the idea is exactly reduce the number of unknowns. I noticed that SPM creates what I'm trying to do (as copied below), but I'm trying to stay within fieldtrip definitions so I can use it's inverse solutions to compare with mine, although I only found examples for beamformers inverse solutions, and not sparse methods. So this is the second question: is there any example of source-space based sparse methods inverse solutions? Thanks in advance for any help, Best Regards Leonardo Barbosa Here is the SPM code (inside *spm_eeg_lgainmat*) % Forward computation %-------------------------------------------------------------------------- [vol, sens] = forwinv_prepare_vol_sens(vol, sens, 'channel', forward(ind).channels); nvert = size(vert, 1); spm('Pointer', 'Watch');drawnow; spm_progress_bar('Init', nvert, ['Computing ' modality ' leadfields']); drawnow; if nvert > 100, Ibar = floor(linspace(1, nvert,100)); else Ibar = [1:nvert]; end Gxyz = zeros(length(forward(ind).channels), 3*nvert); for i = 1:nvert Gxyz(:, (3*i- 2):(3*i)) = forwinv_compute_leadfield(vert(i, :), sens, vol); if ismember(i, Ibar) spm_progress_bar('Set', i); drawnow; end end spm_progress_bar('Clear'); spm_progress_bar('Init', nvert, ['Orienting ' modality ' leadfields']); drawnow; G{ind} = zeros(size(Gxyz, 1), size(Gxyz, 2)/3); for i = 1:nvert G{ind}(:, i) = Gxyz(:, (3*i- 2):(3*i))*norm(i, :)'; if ismember(i, Ibar) spm_progress_bar('Set', i); drawnow; end end spm_progress_bar('Clear'); -------------- next part -------------- An HTML attachment was scrubbed... URL: From inbalots at gmail.com Tue Feb 1 14:09:08 2011 From: inbalots at gmail.com (Inbal Lots) Date: Tue, 1 Feb 2011 15:09:08 +0200 Subject: [FieldTrip] question about using ft_multiplot for my own needs Message-ID: Hello I have a data matrix (in Matlab, at size of [channel num X 30 X 8] ) that holds some values I calculated for *each channel*. Is it possible to use your ft_multiplot (or any other function) to display the plots of *all channels* in their original layout? similar to the ft_multiplotER ? My aim is to plot (for each channel) 8 plots on the same axes (similar to using hold on, or plot([x1,y1],[x2,y2] ,...[x8,y8]) where each xi and yi have 30 indexes and to display it all in the layout of all channels together (similar to the ft_multiplotER, with cfg.layout='4D248.lay';). Is it possible? how can I do that? can I "zoom in" or display a selected channels- similar to the cfg.interactive='yes'; option? thanks Inbal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Patricia.Wollstadt at gmx.de Tue Feb 1 16:34:04 2011 From: Patricia.Wollstadt at gmx.de (Patricia Wollstadt) Date: Tue, 01 Feb 2011 16:34:04 +0100 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net>, <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> Message-ID: <20110201153404.267000@gmx.net> Hi Michael, Hi Jan-Mathijs, thank you very much for the advice/clarification. Everything seems to run fine now (with the corrected design). Thank you very much, Best Patricia -------- Original-Nachricht -------- > Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > Von: "Michael Wibral" > An: "Email discussion list for the FieldTrip project" > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > Hi Patricia, > > I also would have thought your design to be correct. Maybe the > unneccessary specification of the uvar screws thinsg up?? > > However, you really do not have any repeated measures in your design - > here the output of FT is correct. I interpret it in the following way: You > specified cfg.uvar - indicating to FT the possibility that this might be a > repeated measures design. FT identified the units of observation as being 80 > (correct), and then checked how many repeated measures you ran in each UO > and found just 1 - which is also correct. I agree that naming the units of > observation (UO) as 'levels' of the UO variable is a bit odd, should rather > be 'units of observation'. > > The concept of repeated measures is also very often misunderstood: in > repated measures you do not actually repeat anything, rather you perform > different measurements (treatments) WITHIN a unit of observation - so a repated > measures design is a within UO design. Your subjects just have one age, so > there are no different treatments (levels of the indep variable) per > subjects and, hence, no 'repeated measures'. > > Hope this clarifies terminology for further discussion. > > Michael > > > -----Ursprüngliche Nachricht----- > Von: "jan-mathijs schoffelen" > Gesendet: Jan 25, 2011 8:57:03 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >Hi Patricia, > > > >I don't really understand what is going on, but could you try to > >specify your design only in a single row (design = design(2,:) in your > >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how > >it runs? As such the uvar row is not relevant in an independent > >samples design. > > > >Best, > > > >Jan-Mathijs > > > > > > > >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > > > >> Dear all, > >> > >> I'm still trying to identify the underlying reason for the issue > >> described below. I ran the analysis in debug mode (I'm using > >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) > >> and found that the matrix 'resample', that is generated in > >> 'statistics_montecarlo', line 187: > >> > >> resample = resampledesign(cfg, design); > >> > >> doesn't contain actual permutations of my initial design, but rather > >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is > >> no permutation of the units of observation) the 'randstat' that is > >> subsequently calculated for each row of the resample-matrix is > >> always the same. > >> Is this maybe due to my design and my units of observations > >> respectively? I am looking at age-dependent variations in resting- > >> state data, so my UO are 80 subjects, divided into four age groups. > >> The commandline-output of the 'resampledesign'-function is as follows: > >> > >> total number of measurements = 80 > >> total number of variables = 2 > >> number of independent variables = 1 > >> number of unit variables = 1 > >> number of within-cell variables = 0 > >> number of control variables = 0 > >> using a permutation resampling approach > >> repeated measurement in variable 1 over 80 levels > >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 > >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> 1 1 > >> > >> > >> Is this correct? Shouldn't this read 'repeated measurement in > >> variable 2 over 4 levels' with the number of subjects per group as > >> repeated measurements within a condition? Still I am pretty sure > >> about my design matrix, which contains the indices 1 to 80 (for all > >> subjects) in the first row (this is my cfg.uvar) with the > >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > >> my previous email below). I use an 'indepsamplesF'-statistic, since > >> I am comparing between four groups of different subjects (averaged > >> over trials). > >> > >> I hope, I got the settings and my design right. Any suggestions, > >> whether this is a problem due to wrong configurations in my script > >> are very welcome. > >> > >> Right now I work around this issue by replacing line 279 in > >> 'statistics_montecarlo': > >> > >> tmpdesign = design(:,resample(i,:)); > >> > >> with: > >> > >> tmpdesign = design(:,randperm(size(design,2))); > >> > >> creating permutations of my design 'by hand'. Is this acceptable or > >> is there anything I'm maybe missing. > >> > >> Thank you very much, kind regards, > >> > >> Patricia > >> > >> > >> > >> > >> -------- Original-Nachricht -------- > >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > >>> Von: "Patricia Wollstadt" > >>> An: fieldtrip at donders.ru.nl > >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > >> > >>> Dear Fieldtrip-users, > >>> > >>> I'm currently trying to calculate freqstatistics for four > >>> experimental > >>> groups, using the following options: > >>> > >>> groupSize=[length(subjects{1}) length(subjects{2}) > >>> length(subjects{3}) > >>> length(subjects{4})]; > >>> > >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > >>> % 1 to N subjects > >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > >>> group membership > >>> > >>> > >>> cfg=[]; > >>> cfg.design=design; > >>> cfg.uvar = 1; > >>> cfg.ivar = 2; > >>> cfg.method = 'montecarlo'; > >>> cfg.statistic = 'indepsamplesF'; > >>> cfg.correctm = 'fdr'; > >>> cfg.numrandomization = 180000; > >>> cfg.alpha = 0.01/7; > >>> cfg.tail = 1; > >>> cfg.design = design; > >>> cfg.channels = myChannels; > >>> cfg.avgovertime = 'yes'; > >>> cfg.avgoverfreq = 'yes'; > >>> cfg.frequency = [1 3]; > >>> > >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > >>> group4avg); > >>> > >>> With these settings, the coputation itself runs fine, but the > >>> resulting > >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > >>> consists of > >>> only ones). This would mean, that I found significant effects for all > >>> channels. Is this possible or rather due to an error somewhere in > >>> my script? Is > >>> it likely, that these are 'real' zeroes or rather very small > >>> values, close > >>> to zero? > >>> Any hints and suggestions are very welcome, thank you in advance, > >>> > >>> Kind regards > >>> > >>> Patricia Wollstadt > >>> > >>> > >>> -- > >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >>> _______________________________________________ > >>> fieldtrip mailing list > >>> fieldtrip at donders.ru.nl > >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > >> -- > >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > >> _______________________________________________ > >> fieldtrip mailing list > >> fieldtrip at donders.ru.nl > >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >Dr. J.M. (Jan-Mathijs) Schoffelen > >Donders Institute for Brain, Cognition and Behaviour, > >Centre for Cognitive Neuroimaging, > >Radboud University Nijmegen, The Netherlands > >J.Schoffelen at donders.ru.nl > >Telephone: 0031-24-3614793 > > > >_______________________________________________ > >fieldtrip mailing list > >fieldtrip at donders.ru.nl > >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl From michael.wibral at web.de Tue Feb 1 18:29:57 2011 From: michael.wibral at web.de (Michael Wibral) Date: Tue, 1 Feb 2011 18:29:57 +0100 (CET) Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <20110201153404.267000@gmx.net> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net>, <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056>, <20110201153404.267000@gmx.net> Message-ID: <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Hi Patricia, it seems that things are clarified now. I just do not know what was actually wrong with your code Was it the superfluous specification of cfg.uvar?? Could you let us know? Thanks. Michael -----Ursprüngliche Nachricht----- Von: "Patricia Wollstadt" Gesendet: Feb 1, 2011 4:34:04 PM An: "Email discussion list for the FieldTrip project" Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction >Hi Michael, Hi Jan-Mathijs, > >thank you very much for the advice/clarification. Everything seems to run fine now (with the corrected design). > >Thank you very much, > >Best > >Patricia > > >-------- Original-Nachricht -------- >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) >> Von: "Michael Wibral" >> An: "Email discussion list for the FieldTrip project" >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > >> Hi Patricia, >> >> I also would have thought your design to be correct. Maybe the >> unneccessary specification of the uvar screws thinsg up?? >> >> However, you really do not have any repeated measures in your design - >> here the output of FT is correct. I interpret it in the following way: You >> specified cfg.uvar - indicating to FT the possibility that this might be a >> repeated measures design. FT identified the units of observation as being 80 >> (correct), and then checked how many repeated measures you ran in each UO >> and found just 1 - which is also correct. I agree that naming the units of >> observation (UO) as 'levels' of the UO variable is a bit odd, should rather >> be 'units of observation'. >> >> The concept of repeated measures is also very often misunderstood: in >> repated measures you do not actually repeat anything, rather you perform >> different measurements (treatments) WITHIN a unit of observation - so a repated >> measures design is a within UO design. Your subjects just have one age, so >> there are no different treatments (levels of the indep variable) per >> subjects and, hence, no 'repeated measures'. >> >> Hope this clarifies terminology for further discussion. >> >> Michael >> >> >> -----Ursprüngliche Nachricht----- >> Von: "jan-mathijs schoffelen" >> Gesendet: Jan 25, 2011 8:57:03 PM >> An: "Email discussion list for the FieldTrip project" >> >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction >> >> >Hi Patricia, >> > >> >I don't really understand what is going on, but could you try to >> >specify your design only in a single row (design = design(2,:) in your >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how >> >it runs? As such the uvar row is not relevant in an independent >> >samples design. >> > >> >Best, >> > >> >Jan-Mathijs >> > >> > >> > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: >> > >> >> Dear all, >> >> >> >> I'm still trying to identify the underlying reason for the issue >> >> described below. I ran the analysis in debug mode (I'm using >> >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) >> >> and found that the matrix 'resample', that is generated in >> >> 'statistics_montecarlo', line 187: >> >> >> >> resample = resampledesign(cfg, design); >> >> >> >> doesn't contain actual permutations of my initial design, but rather >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is >> >> no permutation of the units of observation) the 'randstat' that is >> >> subsequently calculated for each row of the resample-matrix is >> >> always the same. >> >> Is this maybe due to my design and my units of observations >> >> respectively? I am looking at age-dependent variations in resting- >> >> state data, so my UO are 80 subjects, divided into four age groups. >> >> The commandline-output of the 'resampledesign'-function is as follows: >> >> >> >> total number of measurements = 80 >> >> total number of variables = 2 >> >> number of independent variables = 1 >> >> number of unit variables = 1 >> >> number of within-cell variables = 0 >> >> number of control variables = 0 >> >> using a permutation resampling approach >> >> repeated measurement in variable 1 over 80 levels >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 >> >> >> >> >> >> Is this correct? Shouldn't this read 'repeated measurement in >> >> variable 2 over 4 levels' with the number of subjects per group as >> >> repeated measurements within a condition? Still I am pretty sure >> >> about my design matrix, which contains the indices 1 to 80 (for all >> >> subjects) in the first row (this is my cfg.uvar) with the >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see >> >> my previous email below). I use an 'indepsamplesF'-statistic, since >> >> I am comparing between four groups of different subjects (averaged >> >> over trials). >> >> >> >> I hope, I got the settings and my design right. Any suggestions, >> >> whether this is a problem due to wrong configurations in my script >> >> are very welcome. >> >> >> >> Right now I work around this issue by replacing line 279 in >> >> 'statistics_montecarlo': >> >> >> >> tmpdesign = design(:,resample(i,:)); >> >> >> >> with: >> >> >> >> tmpdesign = design(:,randperm(size(design,2))); >> >> >> >> creating permutations of my design 'by hand'. Is this acceptable or >> >> is there anything I'm maybe missing. >> >> >> >> Thank you very much, kind regards, >> >> >> >> Patricia >> >> >> >> >> >> >> >> >> >> -------- Original-Nachricht -------- >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 >> >>> Von: "Patricia Wollstadt" >> >>> An: fieldtrip at donders.ru.nl >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction >> >> >> >>> Dear Fieldtrip-users, >> >>> >> >>> I'm currently trying to calculate freqstatistics for four >> >>> experimental >> >>> groups, using the following options: >> >>> >> >>> groupSize=[length(subjects{1}) length(subjects{2}) >> >>> length(subjects{3}) >> >>> length(subjects{4})]; >> >>> >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; >> >>> % 1 to N subjects >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> >> >>> group membership >> >>> >> >>> >> >>> cfg=[]; >> >>> cfg.design=design; >> >>> cfg.uvar = 1; >> >>> cfg.ivar = 2; >> >>> cfg.method = 'montecarlo'; >> >>> cfg.statistic = 'indepsamplesF'; >> >>> cfg.correctm = 'fdr'; >> >>> cfg.numrandomization = 180000; >> >>> cfg.alpha = 0.01/7; >> >>> cfg.tail = 1; >> >>> cfg.design = design; >> >>> cfg.channels = myChannels; >> >>> cfg.avgovertime = 'yes'; >> >>> cfg.avgoverfreq = 'yes'; >> >>> cfg.frequency = [1 3]; >> >>> >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, >> >>> group4avg); >> >>> >> >>> With these settings, the coputation itself runs fine, but the >> >>> resulting >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix >> >>> consists of >> >>> only ones). This would mean, that I found significant effects for all >> >>> channels. Is this possible or rather due to an error somewhere in >> >>> my script? Is >> >>> it likely, that these are 'real' zeroes or rather very small >> >>> values, close >> >>> to zero? >> >>> Any hints and suggestions are very welcome, thank you in advance, >> >>> >> >>> Kind regards >> >>> >> >>> Patricia Wollstadt >> >>> >> >>> >> >>> -- >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >> >>> _______________________________________________ >> >>> fieldtrip mailing list >> >>> fieldtrip at donders.ru.nl >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> -- >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > >> >Dr. J.M. (Jan-Mathijs) Schoffelen >> >Donders Institute for Brain, Cognition and Behaviour, >> >Centre for Cognitive Neuroimaging, >> >Radboud University Nijmegen, The Netherlands >> >J.Schoffelen at donders.ru.nl >> >Telephone: 0031-24-3614793 >> > >> >_______________________________________________ >> >fieldtrip mailing list >> >fieldtrip at donders.ru.nl >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >-- >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >_______________________________________________ >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From batrod at gmail.com Tue Feb 1 18:38:26 2011 From: batrod at gmail.com (Rodolphe Nenert) Date: Tue, 1 Feb 2011 11:38:26 -0600 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net> <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> <20110201153404.267000@gmx.net> <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Message-ID: Dear Patricia and others that participated to this discussion. I had recently the same problem, using ft_freqstatistics with Montecarlo to correlate Time-frequency power values and behavioral results. All my p-values were first found to be 0, resulting in a mask full of 1. By removing the useless cfg.uvar, the script made the correct analysis and reported good correlation values. Hope this helps, Rodolphe. On Tue, Feb 1, 2011 at 11:29 AM, Michael Wibral wrote: > Hi Patricia, > > it seems that things are clarified now. I just do not know what was > actually wrong with your code Was it the superfluous specification of > cfg.uvar?? > Could you let us know? Thanks. > > Michael > -----Ursprüngliche Nachricht----- > Von: "Patricia Wollstadt" > Gesendet: Feb 1, 2011 4:34:04 PM > An: "Email discussion list for the FieldTrip project" < > fieldtrip at donders.ru.nl> > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >Hi Michael, Hi Jan-Mathijs, > > > >thank you very much for the advice/clarification. Everything seems to run > fine now (with the corrected design). > > > >Thank you very much, > > > >Best > > > >Patricia > > > > > >-------- Original-Nachricht -------- > >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > >> Von: "Michael Wibral" > >> An: "Email discussion list for the FieldTrip project" < > fieldtrip at donders.ru.nl> > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > >> Hi Patricia, > >> > >> I also would have thought your design to be correct. Maybe the > >> unneccessary specification of the uvar screws thinsg up?? > >> > >> However, you really do not have any repeated measures in your design - > >> here the output of FT is correct. I interpret it in the following way: > You > >> specified cfg.uvar - indicating to FT the possibility that this might be > a > >> repeated measures design. FT identified the units of observation as > being 80 > >> (correct), and then checked how many repeated measures you ran in each > UO > >> and found just 1 - which is also correct. I agree that naming the units > of > >> observation (UO) as 'levels' of the UO variable is a bit odd, should > rather > >> be 'units of observation'. > >> > >> The concept of repeated measures is also very often misunderstood: in > >> repated measures you do not actually repeat anything, rather you perform > >> different measurements (treatments) WITHIN a unit of observation - so a > repated > >> measures design is a within UO design. Your subjects just have one age, > so > >> there are no different treatments (levels of the indep variable) per > >> subjects and, hence, no 'repeated measures'. > >> > >> Hope this clarifies terminology for further discussion. > >> > >> Michael > >> > >> > >> -----Ursprüngliche Nachricht----- > >> Von: "jan-mathijs schoffelen" > >> Gesendet: Jan 25, 2011 8:57:03 PM > >> An: "Email discussion list for the FieldTrip project" > >> > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > >> > >> >Hi Patricia, > >> > > >> >I don't really understand what is going on, but could you try to > >> >specify your design only in a single row (design = design(2,:) in your > >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how > >> >it runs? As such the uvar row is not relevant in an independent > >> >samples design. > >> > > >> >Best, > >> > > >> >Jan-Mathijs > >> > > >> > > >> > > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > >> > > >> >> Dear all, > >> >> > >> >> I'm still trying to identify the underlying reason for the issue > >> >> described below. I ran the analysis in debug mode (I'm using > >> >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) > >> >> and found that the matrix 'resample', that is generated in > >> >> 'statistics_montecarlo', line 187: > >> >> > >> >> resample = resampledesign(cfg, design); > >> >> > >> >> doesn't contain actual permutations of my initial design, but rather > >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is > >> >> no permutation of the units of observation) the 'randstat' that is > >> >> subsequently calculated for each row of the resample-matrix is > >> >> always the same. > >> >> Is this maybe due to my design and my units of observations > >> >> respectively? I am looking at age-dependent variations in resting- > >> >> state data, so my UO are 80 subjects, divided into four age groups. > >> >> The commandline-output of the 'resampledesign'-function is as > follows: > >> >> > >> >> total number of measurements = 80 > >> >> total number of variables = 2 > >> >> number of independent variables = 1 > >> >> number of unit variables = 1 > >> >> number of within-cell variables = 0 > >> >> number of control variables = 0 > >> >> using a permutation resampling approach > >> >> repeated measurement in variable 1 over 80 levels > >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 > >> >> > >> >> > >> >> Is this correct? Shouldn't this read 'repeated measurement in > >> >> variable 2 over 4 levels' with the number of subjects per group as > >> >> repeated measurements within a condition? Still I am pretty sure > >> >> about my design matrix, which contains the indices 1 to 80 (for all > >> >> subjects) in the first row (this is my cfg.uvar) with the > >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > >> >> my previous email below). I use an 'indepsamplesF'-statistic, since > >> >> I am comparing between four groups of different subjects (averaged > >> >> over trials). > >> >> > >> >> I hope, I got the settings and my design right. Any suggestions, > >> >> whether this is a problem due to wrong configurations in my script > >> >> are very welcome. > >> >> > >> >> Right now I work around this issue by replacing line 279 in > >> >> 'statistics_montecarlo': > >> >> > >> >> tmpdesign = design(:,resample(i,:)); > >> >> > >> >> with: > >> >> > >> >> tmpdesign = design(:,randperm(size(design,2))); > >> >> > >> >> creating permutations of my design 'by hand'. Is this acceptable or > >> >> is there anything I'm maybe missing. > >> >> > >> >> Thank you very much, kind regards, > >> >> > >> >> Patricia > >> >> > >> >> > >> >> > >> >> > >> >> -------- Original-Nachricht -------- > >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > >> >>> Von: "Patricia Wollstadt" > >> >>> An: fieldtrip at donders.ru.nl > >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > >> >> > >> >>> Dear Fieldtrip-users, > >> >>> > >> >>> I'm currently trying to calculate freqstatistics for four > >> >>> experimental > >> >>> groups, using the following options: > >> >>> > >> >>> groupSize=[length(subjects{1}) length(subjects{2}) > >> >>> length(subjects{3}) > >> >>> length(subjects{4})]; > >> >>> > >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > >> >>> % 1 to N subjects > >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > >> >>> group membership > >> >>> > >> >>> > >> >>> cfg=[]; > >> >>> cfg.design=design; > >> >>> cfg.uvar = 1; > >> >>> cfg.ivar = 2; > >> >>> cfg.method = 'montecarlo'; > >> >>> cfg.statistic = 'indepsamplesF'; > >> >>> cfg.correctm = 'fdr'; > >> >>> cfg.numrandomization = 180000; > >> >>> cfg.alpha = 0.01/7; > >> >>> cfg.tail = 1; > >> >>> cfg.design = design; > >> >>> cfg.channels = myChannels; > >> >>> cfg.avgovertime = 'yes'; > >> >>> cfg.avgoverfreq = 'yes'; > >> >>> cfg.frequency = [1 3]; > >> >>> > >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > >> >>> group4avg); > >> >>> > >> >>> With these settings, the coputation itself runs fine, but the > >> >>> resulting > >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > >> >>> consists of > >> >>> only ones). This would mean, that I found significant effects for > all > >> >>> channels. Is this possible or rather due to an error somewhere in > >> >>> my script? Is > >> >>> it likely, that these are 'real' zeroes or rather very small > >> >>> values, close > >> >>> to zero? > >> >>> Any hints and suggestions are very welcome, thank you in advance, > >> >>> > >> >>> Kind regards > >> >>> > >> >>> Patricia Wollstadt > >> >>> > >> >>> > >> >>> -- > >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >> >>> _______________________________________________ > >> >>> fieldtrip mailing list > >> >>> fieldtrip at donders.ru.nl > >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> >> > >> >> -- > >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > >> >> belohnen Sie mit bis zu 50,- Euro! > https://freundschaftswerbung.gmx.de > >> >> _______________________________________________ > >> >> fieldtrip mailing list > >> >> fieldtrip at donders.ru.nl > >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > > >> >Dr. J.M. (Jan-Mathijs) Schoffelen > >> >Donders Institute for Brain, Cognition and Behaviour, > >> >Centre for Cognitive Neuroimaging, > >> >Radboud University Nijmegen, The Netherlands > >> >J.Schoffelen at donders.ru.nl > >> >Telephone: 0031-24-3614793 > >> > > >> >_______________________________________________ > >> >fieldtrip mailing list > >> >fieldtrip at donders.ru.nl > >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >-- > >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >_______________________________________________ > >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 ekanal at cmu.edu Tue Feb 1 19:16:23 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Tue, 1 Feb 2011 13:16:23 -0500 Subject: [FieldTrip] using planar gradiometer data with ft_combineplanar Message-ID: <3F013D5F-0A1C-4A63-A365-FFD87F9233F9@cmu.edu> Hello folks - We have a Neuromag 306 system here, which has two planar gradiometers at each sensor location (x and y directions). Is there a way I can use ft_combineplanar with the data from these sensors? From what I can tell, I shouldn't need to use ft_megplanar, but I don't know how to format the data so that ft_combineplanar knows what to do. Thanks - Elli Kanal -------------------- Eliezer Kanal, Ph.D. Postdoctoral Fellow Center for the Neural Basis of Cognition Carnegie Mellon University 4400 Fifth Ave, Suite 115 Pittsburgh PA 15213 P: 412-268-4115 F: 412-268-5060 From Patricia.Wollstadt at gmx.de Tue Feb 1 22:26:51 2011 From: Patricia.Wollstadt at gmx.de (Patricia Wollstadt) Date: Tue, 01 Feb 2011 22:26:51 +0100 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net> <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> <20110201153404.267000@gmx.net> <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Message-ID: <20110201212651.47820@gmx.net> Dear all, the problem was caused by the wrong design matrix (and thus the superfluous cfg.uvar), sorry for not making this clear. So actually I just need a vector that specifies the group for each subject, Best Patricia -------- Original-Nachricht -------- > Datum: Tue, 1 Feb 2011 11:38:26 -0600 > Von: Rodolphe Nenert > An: Email discussion list for the FieldTrip project > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > Dear Patricia and others that participated to this discussion. > > I had recently the same problem, using ft_freqstatistics with Montecarlo > to > correlate Time-frequency power values and behavioral results. > All my p-values were first found to be 0, resulting in a mask full of 1. > By removing the useless cfg.uvar, the script made the correct analysis and > reported good correlation values. > > Hope this helps, > > Rodolphe. > > On Tue, Feb 1, 2011 at 11:29 AM, Michael Wibral > wrote: > > > Hi Patricia, > > > > it seems that things are clarified now. I just do not know what was > > actually wrong with your code Was it the superfluous specification of > > cfg.uvar?? > > Could you let us know? Thanks. > > > > Michael > > -----Ursprüngliche Nachricht----- > > Von: "Patricia Wollstadt" > > Gesendet: Feb 1, 2011 4:34:04 PM > > An: "Email discussion list for the FieldTrip project" < > > fieldtrip at donders.ru.nl> > > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > > >Hi Michael, Hi Jan-Mathijs, > > > > > >thank you very much for the advice/clarification. Everything seems to > run > > fine now (with the corrected design). > > > > > >Thank you very much, > > > > > >Best > > > > > >Patricia > > > > > > > > >-------- Original-Nachricht -------- > > >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > > >> Von: "Michael Wibral" > > >> An: "Email discussion list for the FieldTrip project" < > > fieldtrip at donders.ru.nl> > > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > > > >> Hi Patricia, > > >> > > >> I also would have thought your design to be correct. Maybe the > > >> unneccessary specification of the uvar screws thinsg up?? > > >> > > >> However, you really do not have any repeated measures in your design > - > > >> here the output of FT is correct. I interpret it in the following > way: > > You > > >> specified cfg.uvar - indicating to FT the possibility that this might > be > > a > > >> repeated measures design. FT identified the units of observation as > > being 80 > > >> (correct), and then checked how many repeated measures you ran in > each > > UO > > >> and found just 1 - which is also correct. I agree that naming the > units > > of > > >> observation (UO) as 'levels' of the UO variable is a bit odd, should > > rather > > >> be 'units of observation'. > > >> > > >> The concept of repeated measures is also very often misunderstood: in > > >> repated measures you do not actually repeat anything, rather you > perform > > >> different measurements (treatments) WITHIN a unit of observation - so > a > > repated > > >> measures design is a within UO design. Your subjects just have one > age, > > so > > >> there are no different treatments (levels of the indep variable) per > > >> subjects and, hence, no 'repeated measures'. > > >> > > >> Hope this clarifies terminology for further discussion. > > >> > > >> Michael > > >> > > >> > > >> -----Ursprüngliche Nachricht----- > > >> Von: "jan-mathijs schoffelen" > > >> Gesendet: Jan 25, 2011 8:57:03 PM > > >> An: "Email discussion list for the FieldTrip project" > > >> > > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >> > > >> >Hi Patricia, > > >> > > > >> >I don't really understand what is going on, but could you try to > > >> >specify your design only in a single row (design = design(2,:) in > your > > >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see > how > > >> >it runs? As such the uvar row is not relevant in an independent > > >> >samples design. > > >> > > > >> >Best, > > >> > > > >> >Jan-Mathijs > > >> > > > >> > > > >> > > > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > > >> > > > >> >> Dear all, > > >> >> > > >> >> I'm still trying to identify the underlying reason for the issue > > >> >> described below. I ran the analysis in debug mode (I'm using > > >> >> Matlab2008b and the Fieldtrip-release from the 16th of January > 2011) > > >> >> and found that the matrix 'resample', that is generated in > > >> >> 'statistics_montecarlo', line 187: > > >> >> > > >> >> resample = resampledesign(cfg, design); > > >> >> > > >> >> doesn't contain actual permutations of my initial design, but > rather > > >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there > is > > >> >> no permutation of the units of observation) the 'randstat' that is > > >> >> subsequently calculated for each row of the resample-matrix is > > >> >> always the same. > > >> >> Is this maybe due to my design and my units of observations > > >> >> respectively? I am looking at age-dependent variations in resting- > > >> >> state data, so my UO are 80 subjects, divided into four age > groups. > > >> >> The commandline-output of the 'resampledesign'-function is as > > follows: > > >> >> > > >> >> total number of measurements = 80 > > >> >> total number of variables = 2 > > >> >> number of independent variables = 1 > > >> >> number of unit variables = 1 > > >> >> number of within-cell variables = 0 > > >> >> number of control variables = 0 > > >> >> using a permutation resampling approach > > >> >> repeated measurement in variable 1 over 80 levels > > >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 > > >> >> > > >> >> > > >> >> Is this correct? Shouldn't this read 'repeated measurement in > > >> >> variable 2 over 4 levels' with the number of subjects per group as > > >> >> repeated measurements within a condition? Still I am pretty sure > > >> >> about my design matrix, which contains the indices 1 to 80 (for > all > > >> >> subjects) in the first row (this is my cfg.uvar) with the > > >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > > >> >> my previous email below). I use an 'indepsamplesF'-statistic, > since > > >> >> I am comparing between four groups of different subjects (averaged > > >> >> over trials). > > >> >> > > >> >> I hope, I got the settings and my design right. Any suggestions, > > >> >> whether this is a problem due to wrong configurations in my script > > >> >> are very welcome. > > >> >> > > >> >> Right now I work around this issue by replacing line 279 in > > >> >> 'statistics_montecarlo': > > >> >> > > >> >> tmpdesign = design(:,resample(i,:)); > > >> >> > > >> >> with: > > >> >> > > >> >> tmpdesign = design(:,randperm(size(design,2))); > > >> >> > > >> >> creating permutations of my design 'by hand'. Is this acceptable > or > > >> >> is there anything I'm maybe missing. > > >> >> > > >> >> Thank you very much, kind regards, > > >> >> > > >> >> Patricia > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> -------- Original-Nachricht -------- > > >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > > >> >>> Von: "Patricia Wollstadt" > > >> >>> An: fieldtrip at donders.ru.nl > > >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > > >> >> > > >> >>> Dear Fieldtrip-users, > > >> >>> > > >> >>> I'm currently trying to calculate freqstatistics for four > > >> >>> experimental > > >> >>> groups, using the following options: > > >> >>> > > >> >>> groupSize=[length(subjects{1}) length(subjects{2}) > > >> >>> length(subjects{3}) > > >> >>> length(subjects{4})]; > > >> >>> > > >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > > >> >>> % 1 to N subjects > > >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > > >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > > >> >>> group membership > > >> >>> > > >> >>> > > >> >>> cfg=[]; > > >> >>> cfg.design=design; > > >> >>> cfg.uvar = 1; > > >> >>> cfg.ivar = 2; > > >> >>> cfg.method = 'montecarlo'; > > >> >>> cfg.statistic = 'indepsamplesF'; > > >> >>> cfg.correctm = 'fdr'; > > >> >>> cfg.numrandomization = 180000; > > >> >>> cfg.alpha = 0.01/7; > > >> >>> cfg.tail = 1; > > >> >>> cfg.design = design; > > >> >>> cfg.channels = myChannels; > > >> >>> cfg.avgovertime = 'yes'; > > >> >>> cfg.avgoverfreq = 'yes'; > > >> >>> cfg.frequency = [1 3]; > > >> >>> > > >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > > >> >>> group4avg); > > >> >>> > > >> >>> With these settings, the coputation itself runs fine, but the > > >> >>> resulting > > >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > > >> >>> consists of > > >> >>> only ones). This would mean, that I found significant effects for > > all > > >> >>> channels. Is this possible or rather due to an error somewhere in > > >> >>> my script? Is > > >> >>> it likely, that these are 'real' zeroes or rather very small > > >> >>> values, close > > >> >>> to zero? > > >> >>> Any hints and suggestions are very welcome, thank you in advance, > > >> >>> > > >> >>> Kind regards > > >> >>> > > >> >>> Patricia Wollstadt > > >> >>> > > >> >>> > > >> >>> -- > > >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > > >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > >> >>> _______________________________________________ > > >> >>> fieldtrip mailing list > > >> >>> fieldtrip at donders.ru.nl > > >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > >> >> > > >> >> -- > > >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > > >> >> belohnen Sie mit bis zu 50,- Euro! > > https://freundschaftswerbung.gmx.de > > >> >> _______________________________________________ > > >> >> fieldtrip mailing list > > >> >> fieldtrip at donders.ru.nl > > >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > >> > > > >> >Dr. J.M. (Jan-Mathijs) Schoffelen > > >> >Donders Institute for Brain, Cognition and Behaviour, > > >> >Centre for Cognitive Neuroimaging, > > >> >Radboud University Nijmegen, The Netherlands > > >> >J.Schoffelen at donders.ru.nl > > >> >Telephone: 0031-24-3614793 > > >> > > > >> >_______________________________________________ > > >> >fieldtrip mailing list > > >> >fieldtrip at donders.ru.nl > > >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > >-- > > >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > > >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > >_______________________________________________ > > >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 > > -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail From r.oostenveld at donders.ru.nl Wed Feb 2 10:39:50 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 2 Feb 2011 10:39:50 +0100 Subject: [FieldTrip] toolkit course for MEG and EEG data analysis at the Donders Institute Message-ID: Dear MEG/EEG researchers, (appologies for multiple postings) I would like to announce the yearly toolkit course for MEG and EEG data analysis at the Donders Institute. This year's toolkit will take place from April 18 to April 21. Registration is now open. Have a look at http://www.ru.nl/donders/agenda-events/courses/toolkits-2011 for the preliminary programme and to register. Please note that the number of seats is limited and that participants will be selected based on the time of registration and on their research background and motivation. best regards, Robert ----------------------------------------------------------- Robert Oostenveld, PhD Senior Researcher & MEG Physicist Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Postal Address: PO Box 9101 6500 HB NIJMEGEN The Netherlands Visiting address: Kapittelweg 29 route: 210, room: 0.88 6525 EN NIJMEGEN tel.: +31 (0)24 3619695 e-mail: r.oostenveld at donders.ru.nl web: http://www.ru.nl/neuroimaging skype: r.oostenveld ----------------------------------------------------------- From michael.wibral at web.de Thu Feb 3 10:18:17 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 3 Feb 2011 10:18:17 +0100 (CET) Subject: [FieldTrip] Problem with permutation testing and FDR correction Message-ID: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> Dear Fieldtrip users, I think we detected an error with FDR correction and permutation testing. When increasing the number of permutations, the number of significant voxels goes DOWN, on the other hand when decreasing the number of permutations the number of significant voxels goes up. In my opinion the relationship should be the other way round. The theoretical background is as follows: With FDR correction, the best p-value should survive bonferroni correction (if I am not completely mistaken here), the threshold for the other p-values is then decreased successively. Hence, the p-value assigned to the best (most significant) statistical result plays a crucial role here. This best p-value in permutation tests can never be better than 1/numpermutations, i.e. when I do ten permutations, the best p I can possibly get is 0.1 EVEN IF ALL PERMUTED VALUES ARE LESS EXTREME. So to test with FDR at 275 sensors and 1 timepoint at a threshold of 0.05 we need for anything to get significant a p-value of 0.05/275 = 0.000181818.... to be able to reach this in the best case (remebering that p-values can never be better than 1/numpermutations) we need at least (0.000181818....)^-1 = 5500 permutations. In other words with anything less than this number of permutations we should not be able to get any significances. However, we do in fact get alot of significant values at least in the fieldtrip versions tested up to 16th of January, e.g. in a freqstatistics test on 275 sensors, 50 frequencies and 26 timepoints I get 20760 significant voxels using only 10 permutations (!!). I assume that in the stats module the p-value is simply taken as the fraction of permutations that was more extreme than the actual value. This is correct as long as this fraction is not 0. In the case of a 0 fraction, however, this "0" should be replaced by "1/numpermutations", otherwise you get everything signifcant by just using 10 permutations. An alternative would be to issue an ERROR that the number of permutations is insufficient to perform the desired test with fdr correction. Example: for 4300 source points at 0.05 the number of permutations should at least be (0.05/4300)^-1=86000. For now one should compute the p-value for a bonferroni correction manually, invert this value and take the resulting number as the number of permutations to be at least mathematically on the safe side (practically it seems to be advisable to multiply by another factor of 100 to have stable results, e.g 2000 permutations for uncorrceted testing at 0.05) Please disregard this mail if you are sure that this behaviour has been fixed in the latest fieldtrip (past 16th of January) versions. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From e.maris at donders.ru.nl Thu Feb 3 11:24:18 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Thu, 3 Feb 2011 11:24:18 +0100 Subject: [FieldTrip] Problem with permutation testing and FDR correction In-Reply-To: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> References: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> Message-ID: <018d01cbc38c$869a7ba0$93cf72e0$@maris@donders.ru.nl> Dear Michael, Thank you for pointing this out. The origin of the problem is that FT calculates Monte Carlo estimates of the p-values. In practice there is no other way, except for very small studies where enumeration is possible. However, Monte Carlo estimates are useless if the number of draws from the permutation distribution (numpermutations) is very small, because in that case their Monte Carlo confidence interval is very large. I propose that we add a Monte Carlo confidence interval for all Monte Carlo p-values that FT calculates. This is actually very easy, and I have described it in a paper together with Jan-Matthijs Schoffelen and Pascal Fries (JNeuroMeth, 2007). It just hasn't found its way into FT yet. I will discuss with Robert how to implement this. Best, Eric Maris dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > -----Original Message----- > From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > bounces at donders.ru.nl] On Behalf Of Michael Wibral > Sent: donderdag 3 februari 2011 10:18 > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] Problem with permutation testing and FDR > correction > > Dear Fieldtrip users, > > I think we detected an error with FDR correction and permutation > testing. When increasing the number of permutations, the number of > significant voxels goes DOWN, on the other hand when decreasing the > number of permutations the number of significant voxels goes up. In my > opinion the relationship should be the other way round. The theoretical > background is as follows: > > With FDR correction, the best p-value should survive bonferroni > correction (if I am not completely mistaken here), the threshold for > the other p-values is then decreased successively. > Hence, the p-value assigned to the best (most significant) statistical > result plays a crucial role here. This best p-value in permutation > tests can never be better than 1/numpermutations, i.e. when I do ten > permutations, the best p I can possibly get is 0.1 EVEN IF ALL PERMUTED > VALUES ARE LESS EXTREME. So to test with FDR at 275 sensors and 1 > timepoint at a threshold of 0.05 we need for anything to get > significant a p-value of 0.05/275 = 0.000181818.... to be able to reach > this in the best case (remebering that p-values can never be better > than 1/numpermutations) we need at least (0.000181818....)^-1 = 5500 > permutations. In other words with anything less than this number of > permutations we should not be able to get any significances. However, > we do in fact get alot of significant values at least in the fieldtrip > versions tested up to 16th of January, e.g. in a freqstatistics test on > 275 sensors, 50 frequencies and 26 timepoints I get 20760 significant > voxels using only 10 permutations (!!). I assume that in the stats > module the p-value is simply taken as the fraction of permutations that > was more extreme than the actual value. This is correct as long as this > fraction is not 0. In the case of a 0 fraction, however, this "0" > should be replaced by "1/numpermutations", otherwise you get everything > signifcant by just using 10 permutations. An alternative would be to > issue an ERROR that the number of permutations is insufficient to > perform the desired test with fdr correction. > > > Example: for 4300 source points at 0.05 the number of permutations > should at least be (0.05/4300)^-1=86000. > > For now one should compute the p-value for a bonferroni correction > manually, invert this value and take the resulting number as the number > of permutations to be at least mathematically on the safe side > (practically it seems to be advisable to multiply by another factor of > 100 to have stable results, e.g 2000 permutations for uncorrceted > testing at 0.05) > > Please disregard this mail if you are sure that this behaviour has been > fixed in the latest fieldtrip (past 16th of January) versions. > > Michael From H.Rossiter at ion.ucl.ac.uk Thu Feb 3 15:25:59 2011 From: H.Rossiter at ion.ucl.ac.uk (Holly Rossiter) Date: Thu, 3 Feb 2011 14:25:59 -0000 Subject: [FieldTrip] EMG data Message-ID: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> Dear Fieldtrip, I am new to fieldtrip and am using it to look at MEG-EMG coherence. I am trying to load in my EMG data which is in a separate data file to the MEG. It is made up of 3 files (.eeg, .vhdr and .vmrk). I am trying to follow the coherence tutorial I previously downloaded from your website but I'm not able to define trials despite there being triggers present. Here are my attempts to load in the data with the following error... cfg = []; cfg.trialfun = 'trialfun_general'; cfg.trialdef.eventtype = '1'; cfg.trialdef.eventvalue = [1 1]; cfg.trialdef.prestim = 1; cfg.trialdef.poststim = 2; cfg.dataset = 'sf_EMG.eeg'; cfg = ft_definetrial(cfg); evaluating trialfunction 'trialfun_general' reading the events from 'sf_EMG.vhdr' ??? Error using ==> ft_definetrial at 136 no trials were defined, see DEFINETRIAL for help What do you suggest is the problem? Is it not reading the triggers correctly? Thanks, Holly -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 3 16:09:16 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 3 Feb 2011 16:09:16 +0100 Subject: [FieldTrip] EMG data In-Reply-To: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> Message-ID: Dear Holly You may want to have a look at: http://fieldtrip.fcdonders.nl/example/getting_started_with_reading_raw_eeg_or_meg_data?s []=event To me it sounds as if you have an incorrect specification of your cfg. Good luck, Jan-Mathijs On Feb 3, 2011, at 3:25 PM, Holly Rossiter wrote: > Dear Fieldtrip, > > I am new to fieldtrip and am using it to look at MEG-EMG coherence. > I am trying to load in my EMG data which is in a separate data file > to the MEG. It is made up of 3 files (.eeg, .vhdr and .vmrk). I am > trying to follow the coherence tutorial I previously downloaded from > your website but I’m not able to define trials despite there being > triggers present. > > Here are my attempts to load in the data with the following error... > > cfg = []; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.eventtype = '1'; > cfg.trialdef.eventvalue = [1 1]; > cfg.trialdef.prestim = 1; > cfg.trialdef.poststim = 2; > cfg.dataset = 'sf_EMG.eeg'; > cfg = ft_definetrial(cfg); > evaluating trialfunction 'trialfun_general' > reading the events from 'sf_EMG.vhdr' > ??? Error using ==> ft_definetrial at 136 > no trials were defined, see DEFINETRIAL for help > > What do you suggest is the problem? Is it not reading the triggers > correctly? > > Thanks, > > Holly > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.frei at psy.gla.ac.uk Thu Feb 3 19:07:44 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Thu, 3 Feb 2011 18:07:44 +0000 Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> Message-ID: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Hi everybody, I have a problem that impacts several analysis steps and I'm hoping someone can point me to the right direction. I have 13 recording sessions, that I want to average, and then I want to compute the planar gradients of the average. I first average the sessions with ft_timelockanalysis for each session. Then I use ft_timelockgrandaverage to combine the sessions. Then, just to check the data, I plot the ERFs with ft_multiplotER. This is when the first problem arises. The x and y axes of the plots are shifted in space somehow (see picture 3.png). Next, I compute the planar gradients. When I plot the topographies for the planar gradient, I get a very strange activation pattern, that has nothing to do with the ERF topography (which, btw has no obvious flaws) and I also get several warnings when I make the plot (Picture4.png). I also know for a fact that the grand average planar gradient should look different, as I computed it once before by hand, and it looked much more sensible. If anyone has ever seen this before and can give me a hint as to where to look for the error, I would be very grateful. Luisa -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 4.png Type: application/applefile Size: 73 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 4.png Type: image/png Size: 8160 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 3.png Type: application/applefile Size: 73 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 3.png Type: image/png Size: 43112 bytes Desc: not available URL: -------------- next part -------------- From jan.schoffelen at donders.ru.nl Thu Feb 3 20:29:04 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 3 Feb 2011 20:29:04 +0100 Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Message-ID: Dear Luisa, Could you please specify whether this is a new problem that didn't occur before? If you didn't have problems before, approximately when did it stop working the way you expected it to work? As to the multiplot problem: To me, it seems as if the y-axis is plotted at time point 0, which is indeed far away from your latency of interest, which is (surprise) between 0.14 and 0.18 s. This is a property of multiplotER, which by default plots the x and y axes. Should be possible to switch it off. As to the topoplot problem: difficult to say without additional info / data to reproduce the problem. I assume you have used ft_combineplanar first before attempting to plot the planar gradient representation? Did everything go well in the previous steps, i.e. proper baseline correction etc, prior to timelockanalysis? Be sure also to not use the baseline-correction option for the plotting in ft_topoplotER. Best wishes, Jan-Mathijs On Feb 3, 2011, at 7:07 PM, Luisa Frei wrote: > Hi everybody, > I have a problem that impacts several analysis steps and I'm hoping > someone can point me to the right direction. > > I have 13 recording sessions, that I want to average, and then I > want to compute the planar gradients of the average. I first average > the sessions with ft_timelockanalysis for each session. Then I use > ft_timelockgrandaverage to combine the sessions. > Then, just to check the data, I plot the ERFs with ft_multiplotER. > This is when the first problem arises. The x and y axes of the plots > are shifted in space somehow (see picture 3.png). > Next, I compute the planar gradients. When I plot the topographies > for the planar gradient, I get a very strange activation pattern, > that has nothing to do with the ERF topography (which, btw has no > obvious flaws) and I also get several warnings when I make the plot > (Picture4.png). > > I also know for a fact that the grand average planar gradient should > look different, as I computed it once before by hand, and it looked > much more sensible. > > If anyone has ever seen this before and can give me a hint as to > where to look for the error, I would be very grateful. > > Luisa > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From michael.wibral at web.de Fri Feb 4 10:47:55 2011 From: michael.wibral at web.de (Michael Wibral) Date: Fri, 4 Feb 2011 10:47:55 +0100 (CET) Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk>, <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Message-ID: <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> Dear Luisa, I was also wondering whether you were aware of the fact that planar gradients of group data can look very different depending on when you do the averaging and the megplanar/combineplanar steps. This is because combineplanar is a nonlinear step that cannot be exchanged with the other steps without changing the results. So creating planar gradients in single trials and then using combineplanar and then averaging trials within subjects and then over subjects will look pretty different from doing all averaging first (trials, subjects) and then using megplanar/combineplanar to get an planar gradient representation of this average. Michael -----Ursprüngliche Nachricht----- Von: "Luisa Frei" Gesendet: Feb 3, 2011 7:07:44 PM An: "Email discussion list for the FieldTrip project" Betreff: [FieldTrip] problem with ft_multiplot and planar gradient ? >Hi everybody, >I have a problem that impacts several analysis steps and I'm hoping >someone can point me to the right direction. > >I have 13 recording sessions, that I want to average, and then I want >to compute the planar gradients of the average. I first average the >sessions with ft_timelockanalysis for each session. Then I use >ft_timelockgrandaverage to combine the sessions. >Then, just to check the data, I plot the ERFs with ft_multiplotER. >This is when the first problem arises. The x and y axes of the plots >are shifted in space somehow (see picture 3.png). >Next, I compute the planar gradients. When I plot the topographies >for the planar gradient, I get a very strange activation pattern, >that has nothing to do with the ERF topography (which, btw has no >obvious flaws) and I also get several warnings when I make the plot >(Picture4.png). > >I also know for a fact that the grand average planar gradient should >look different, as I computed it once before by hand, and it looked >much more sensible. > >If anyone has ever seen this before and can give me a hint as to >where to look for the error, I would be very grateful. > >Luisa > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From l.frei at psy.gla.ac.uk Fri Feb 4 11:43:59 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 4 Feb 2011 10:43:59 +0000 Subject: [FieldTrip] =?utf-8?q?=5BSPAM=3F=5D_Re=3A__problem_with_ft=5Fmult?= =?utf-8?q?iplot_and_planar_gradient__=EF=BF=BC?= In-Reply-To: <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk>, <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> Message-ID: <6E28D7B8-BFE7-44D9-93C4-5DDEF50D52A0@psy.gla.ac.uk> Thanks Michael and Jan-Mathijs, this is very useful information. I do all the averaging before computing the gradients. However, to resolve this I have to admit that I found a bug in my code last night and after fixing it, it looked fine. Thanks for your help! Luisa On 4 Feb 2011, at 09:47, Michael Wibral wrote: > Dear Luisa, > > I was also wondering whether you were aware of the fact that planar > gradients of group data can look very different depending on when > you do the averaging and the megplanar/combineplanar steps. This is > because combineplanar is a nonlinear step that cannot be exchanged > with the other steps without changing the results. > So creating planar gradients in single trials and then using > combineplanar and then averaging trials within subjects and then > over subjects will look pretty different from doing all averaging > first (trials, subjects) and then using megplanar/combineplanar to > get an planar gradient representation of this average. > > Michael > > > -----Ursprüngliche Nachricht----- > Von: "Luisa Frei" > Gesendet: Feb 3, 2011 7:07:44 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: [FieldTrip] problem with ft_multiplot and planar gradient ? > >> Hi everybody, >> I have a problem that impacts several analysis steps and I'm hoping >> someone can point me to the right direction. >> >> I have 13 recording sessions, that I want to average, and then I want >> to compute the planar gradients of the average. I first average the >> sessions with ft_timelockanalysis for each session. Then I use >> ft_timelockgrandaverage to combine the sessions. >> Then, just to check the data, I plot the ERFs with ft_multiplotER. >> This is when the first problem arises. The x and y axes of the plots >> are shifted in space somehow (see picture 3.png). >> Next, I compute the planar gradients. When I plot the topographies >> for the planar gradient, I get a very strange activation pattern, >> that has nothing to do with the ERF topography (which, btw has no >> obvious flaws) and I also get several warnings when I make the plot >> (Picture4.png). >> >> I also know for a fact that the grand average planar gradient should >> look different, as I computed it once before by hand, and it looked >> much more sensible. >> >> If anyone has ever seen this before and can give me a hint as to >> where to look for the error, I would be very grateful. >> >> Luisa >> >> >> >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From sburns at nmr.mgh.harvard.edu Fri Feb 4 17:12:46 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Fri, 4 Feb 2011 11:12:46 -0500 Subject: [FieldTrip] FT doesn't close .fif files Message-ID: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> FieldTrip Experts - I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgroppe at cogsci.ucsd.edu Mon Feb 7 16:48:40 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Mon, 7 Feb 2011 10:48:40 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? Message-ID: Hi fieldtrippers, I'm a little bit confused about the meaning of the cluster-based permutation test parameter 'minnbchan'. I understand the rationale for the parameter, but based on the tutorial description: "The value of cfg.minnbchan is a tuning parameter that determines the way the clusters are formed. More specifically, we use cfg.minnbchan to specify the minimum number of neighborhood channels that is required for a selected sample (i.e., a sample who's T-value exceeds the threshold) to be included in the clustering algorithm. With cfg.minnbchan = 0 (the default), it sometimes happens that two clusters are spatially connected via a narrow bridge of samples. Because they are connected, these two clusters are considered as a single cluster. If clusters are interpreted as reflecting spatially distinct sources, such a combined cluster does not make much sense. To suppress this type of combined clusters, one can choose to ignore all selected samples (on the basis of their T-values) if they have less than some minimum number of neighbors that were also selected. This minimum number is assigned to cfg.minnbchan. This number must be chosen independently of the data." I can't tell if "minimum number of neighbors" means just spatial neighbors (i.e., nearby sensors) or if includes temporal and frequency neighbors as well. Could someone clarify? Also, just to be clear, if I want to be able to detect an effect that I think is at only a single electrode, I should set minnbchan to 0, yes? If understand the parameter correctly, any greater value of minnbchan will ignore clusters that are restricted to a single electrode. thanks for your help, -David -- David Groppe, Ph.D. dgroppe at cogsci.ucsd.edu http://www.cogsci.ucsd.edu/~dgroppe/ From tom_campbell75 at hotmail.com Tue Feb 8 04:26:26 2011 From: tom_campbell75 at hotmail.com (Tom Campbell) Date: Tue, 8 Feb 2011 03:26:26 +0000 Subject: [FieldTrip] depsamplesF In-Reply-To: <001001cbbecf$dc470260$94d50720$@maris@donders.ru.nl> References: , <6FF942DE-E2EC-47D0-BC81-CEDCD9B12410@graphicmind.info> , <001001cbbecf$dc470260$94d50720$@maris@donders.ru.nl> Message-ID: Dear Eric, Thank you very much for these helpful suggestions. Plotting the suggested difference waves was rather enlightening. Best regards, Tom. From: e.maris at donders.ru.nl To: tom_campbell75 at hotmail.com; fieldtrip at donders.ru.nl Subject: RE: [FieldTrip] depsamplesF Date: Fri, 28 Jan 2011 10:43:42 +0100 Hi Tom, To test main and interaction effects in your 2x2 within subjects design, you have to perform 3 tests, each using the statfun desamplesT. Say you have the output of ft_timelockanalysis for all four conditions: tlout_Ia, tlout_Ib, tlout_IIa, tlout_IIb. Your then proceed as follows: 1. Main effect of I versus II: calculate the mean of tlout_Ia.avg and tlout_Ib.avg and put this is a a new struct variable tlout_I, which has the same fields as tlout_Ia and tlout_Ib. Do the same with tlout_IIa.avg and tlout_IIb.avg and make a new struct variable tlout_II. Then run ft_timelockstatistics with input arguments tlout_I and tlout_II. With this analysis you will test the main effect of I-versus-II. 2. In the same way, you now test the main effect of a versus b. In your calculations, the roles of (I,II) and (a,b) are now reversed. 3. Interaction of I-vs-II and a-vs-b. Calculate the differences (tlout_Ia.avg-tlout_Ib.avg) and (tlout_IIa.avg-tlout_IIb.avg), put them in output structures and statistically compare them using ft_timelockstatistics. With this analysis, you test the interaction of I-vs-II and a-vs-b. There is no need for Bonferroni correction or an adjustment of cfg.clusteralpha (which does not affect the false alarm rate anyhow) and cfg.alpha. Best, Eric Mari Thank you very much for this helpful advice Olga. That would have also been my impression until I found this discussion between Maya Zuckerman and Eric Maris: http://mailman.science.ru.nl/pipermail/fieldtrip/2010-December/003335.html http://mailman.science.ru.nl/pipermail/fieldtrip/2010-December/003338.html , which I may have misunderstood. I can see from the list that people are interested in using depsampleF to investigate interactions between two independent variables (e.g., background: I,II x stimulus: a,b) in experiments with multiple participants. I can also see a several people have had problems with this. Given for datasets I_a, I_b, II_a, II_b I'd like to do something like: cfg.design =????; ... cfg.statistic ='depsamplesF'; ... [stat] = ft_timelockstatistics(cfg, I_a, I_b, II_a, II_b); to find the tests of of main effect clusters for each factor and interaction clusters. How to specify up cfg.design could be one of the problems, as could be what other cfg parameters need to be specified. I may be barking up completely the wrong tree. Assuming the interaction is significant, there are 4 differences that would be of theoretical interest: I_a vs I_b, II_a vs II_b,I_a vs II_a,I_b vs II_b). For instance, a "classical" interaction might exhibit the abolition of significance of an effect ab seen at I at level II of that factor. So, if I understand the Zuckerman-Maris dialogue, if I used the permutation test to test such I_a vd II_b differences as in the tutorial: cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 500; ... [I_avsb_stat] = ft_timelockstatistics(cfg, I_a, I_b); [II_avsb_stat] = ft_timelockstatistics(cfg, II_a, II_b); [IvsII_a_stat] = ft_timelockstatistics(cfg, I_a, II_a); [IvsII_b_stat] = ft_timelockstatistics(cfg, I_a, II_b); ,I may have to either do some bonferonni correction: -at the cluster level (cluster.alpha) -or at the level at which each t-test can be included in a cluster (cfg.alpha). Please would you verify which, if at all? If I am testing 4 such differences with 4 permutation tests then if the bonferroni correction is to be at the cluster level, please should the correction depend upon the number of clusters as well as the number of such differences tested? Please, I look forward to any clarifications. With best regards, Tom Campbell. From: olga at graphicmind.info To: tom_campbell75 at hotmail.com; fieldtrip at donders.ru.nl Subject: Re: [FieldTrip] depsamplesF Date: Thu, 27 Jan 2011 06:16:51 +0300 Hi, Tom, I guess if you do cluster analysis, which is based on permutation tests you do not need any correction like. Cluster-based statistics just deal with multiple comparison problem differently (Monte-Carlo randomization, permutation tests and examine the probability of your cluster among the random ones). Clusters may be formed based on time, space/frequency adjacency. Best Regards, Olga. On 27.01.2011, at 2:26, Tom Campbell wrote: Dear Eric Maris, Robert Oostenveld and colleagues, I write with some queries with reference to your previous correspondence on the Fieldtrip listserv and would very much appreciate if you could please answer them. I am trying to use Fieldtrip to analyse timelocked ERP data from what is a 16(participant: [1:16]) X2(Background: congruent, incongruent)x2(Stimulus: Animal, Vehicle) design. The code seems to runing well treating this as a 16(participant: [1:16]) X4(Visual stimulus: animal-congruent background, animal-incongruent background, vehicle-congruent, vehicle-incongruent )design with 4 conditions, though I haven't looked at the results of the tests yet. If I then run cluster analyses of differences of theoretical interest via depsamplest, please how would I bonferroni correct? I am interested in what clusters exist in the background and stimulus main effects and their background X stimulus interaction. Please is this possible in fieldtrip to use depsamplesF to work with a Participant X "2-way" design? Best regards, Tom Campbell. _______________________________________________ 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 e.maris at donders.ru.nl Tue Feb 8 07:17:34 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 8 Feb 2011 07:17:34 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: Message-ID: <018101cbc757$e058f6c0$a10ae440$@maris@donders.ru.nl> Dear David, > I can't tell if "minimum number of neighbors" means just spatial > neighbors (i.e., nearby sensors) or if includes temporal and frequency > neighbors as well. Could someone clarify? It means ONLY spatial neighbors. > Also, just to be clear, if I want to be able to detect an effect that > I think is at only a single electrode, I should set minnbchan to 0, > yes? If understand the parameter correctly, any greater value of > minnbchan will ignore clusters that are restricted to a single > electrode. No, with minnbchan=0, there are no constraints on the clusters. If you want clusters to be local (as opposed to stretched over a large part of the scalp), minnbchan should be given a high value. Best, Eric dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > thanks for your help, > -David > > > -- > David Groppe, Ph.D. > dgroppe at cogsci.ucsd.edu > http://www.cogsci.ucsd.edu/~dgroppe/ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From dgroppe at cogsci.ucsd.edu Tue Feb 8 15:18:07 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Tue, 8 Feb 2011 09:18:07 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <-132249673793097681@unknownmsgid> References: <-132249673793097681@unknownmsgid> Message-ID: On Tue, Feb 8, 2011 at 1:17 AM, Eric Maris wrote: > Dear David, > > >> I can't tell if "minimum number of neighbors" means just spatial >> neighbors (i.e., nearby sensors) or if includes temporal and frequency >> neighbors as well.  Could someone clarify? > > It means ONLY spatial neighbors. > >> Also, just to be clear, if I want to be able to detect an effect that >> I think is at only a single electrode, I should set minnbchan to 0, >> yes?  If understand the parameter correctly, any greater value of >> minnbchan will ignore clusters that are restricted to a single >> electrode. > > No, with minnbchan=0, there are no constraints on the clusters. If you want > clusters to be local (as opposed to stretched over a large part of the > scalp), minnbchan should be given a high value. Thanks very much for the email Eric, but I'm confused as to why you answered "No" to my second comment. From what I understand, if you use a value of minnbchan that is greater than 0, then any significant clusters will necessarily spread across multiple electrodes. For example, if you set minnbchan to 1, then all significant clusters will have to include at least two electrodes so that each significant "voxel" has at least one neighbor at another electrode. Thus, if your effect is truly at only a single electrode, having a value of minnbchan greater than 0 will force you to miss the effect or to think it occurs at more electrodes than it really does. What part of my reasoning is incorrect? again, thanks very much for the help, -David > Best, > > Eric > > > dr. Eric Maris > Donders Institute for Brain, Cognition and Behavior > Radboud University > P.O. Box 9104 > 6500 HE Nijmegen > The Netherlands > T:+31 24 3612651 > Mobile: 06 39584581 > F:+31 24 3616066 > mailto:e.maris at donders.ru.nl > http://www.nphyscog.com/ > > > > > > > > >>     thanks for your help, >>         -David >> >> >> -- >> David Groppe, Ph.D. >> dgroppe at cogsci.ucsd.edu >> http://www.cogsci.ucsd.edu/~dgroppe/ >> _______________________________________________ >> 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 > -- David Groppe, Ph.D. Postdoctoral Researcher Kutaslab Dept. of Cognitive Science University of California, San Diego http://www.cogsci.ucsd.edu/~dgroppe/ From fredericroux at hotmail.de Tue Feb 8 16:16:56 2011 From: fredericroux at hotmail.de (Frederic Roux) Date: Tue, 8 Feb 2011 16:16:56 +0100 Subject: [FieldTrip] single trial beamforming Message-ID: Dear list-members, I would like to compute a common frequency specific DICS spatial filter for my baseline and post-stimulus time window as an average across trials, and then use this filter on a trial by trial basis to do the beam-forming for the baseline and post-stimulus time window separately. The reason is that I would like to localize the generators of sustained task-related beta-band activity (1.2 seconds). The code I am planning to use looks as follows: cfg = []; cfg.channel = {'MEG' '-MLP12' '-MLT41' '-MRC12' '-MRC14' '-MRC25' '-MRP56' '-MRT21' '-MLT57' '-MLT52' '-MRF22' '-MRF13' '-MRF24' '-MRF43' '-MLO22' '-MLF25' '-MRO31' '-MRO21'}; cfg.grid = warped_grid.grid; cfg.vol = warped_grid.hdm; cfg.frequency = 15; cfg.method = 'dics'; cfg.projectnoise = 'yes'; cfg.keepfilter = 'yes'; cfg.lambda = 0.05; cfg.dim = [Nx Ny Nz]; cfg.rawtrial = 'no'; cfg.keeptrials = 'no'; [common_filt] = sourceanalysis(cfg,common_TF); cfg.grid.filter = common_filt.avg.filter; cfg.rawtrial = 'yes'; cfg.keeptrials = 'yes'; [pre_source] = sourceanalysis(cfg,pre_TF) [post_source] =sourceanalysis(cfg,post_TF); Can anyone tell me if this code would be ok? I am not sure if is correct to specify the cfg.rawtrial = 'yes' option. Any help would be appreciated. Thanks, fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Tue Feb 8 16:33:25 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Tue, 8 Feb 2011 15:33:25 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> Message-ID: <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Hi Scott - Thanks for the e-mail - it's a good point. The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. Unless you can think of a better solution, my suggestion would be first to call hdr=ft_read_header(fname); in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with fclose(hdr.orig.raw.fid); Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. Cheers, Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 4 Feb 2011, at 16:12, Scott Burns wrote: > FieldTrip Experts - > > I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. > > I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. > > I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. > > FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). > > > Scott Burns > Kuperberg Lab > Martinos Center for Biomedical Imaging > sburns at nmr.mgh.harvard.edu > > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > _______________________________________________ > 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 e.maris at donders.ru.nl Tue Feb 8 17:01:46 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 8 Feb 2011 17:01:46 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: <-132249673793097681@unknownmsgid> Message-ID: <01d801cbc7a9$7ca7e710$75f7b530$@maris@donders.ru.nl> Dear David, > Thanks very much for the email Eric, but I'm confused as to why you > answered "No" to my second comment. From what I understand, if you > use a value of minnbchan that is greater than 0, then any significant > clusters will necessarily spread across multiple electrodes. For > example, if you set minnbchan to 1, then all significant clusters will > have to include at least two electrodes so that each significant > "voxel" has at least one neighbor at another electrode. Thus, if your > effect is truly at only a single electrode, having a value of > minnbchan greater than 0 will force you to miss the effect or to think > it occurs at more electrodes than it really does. What part of my > reasoning is incorrect? Your reasoning is correct and mine was incorrect. I should read better before I write. My apologies for this. I do have to qualify that with minnbchan=0 it may also happen that your significant cluster contains more than one electrode (the electrode with the true effect plus some surrounding ones that by accident exceed the threshold that is used to identify clusters). Best, Eric > again, thanks very much for the help, > -David > > > > Best, > > > > Eric > > > > > > dr. Eric Maris > > Donders Institute for Brain, Cognition and Behavior > > Radboud University > > P.O. Box 9104 > > 6500 HE Nijmegen > > The Netherlands > > T:+31 24 3612651 > > Mobile: 06 39584581 > > F:+31 24 3616066 > > mailto:e.maris at donders.ru.nl > > http://www.nphyscog.com/ > > > > > > > > > > > > > > > > > >>     thanks for your help, > >>         -David > >> > >> > >> -- > >> David Groppe, Ph.D. > >> dgroppe at cogsci.ucsd.edu > >> http://www.cogsci.ucsd.edu/~dgroppe/ > >> _______________________________________________ > >> 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 > > > > > > -- > David Groppe, Ph.D. > Postdoctoral Researcher > Kutaslab > Dept. of Cognitive Science > University of California, San Diego > http://www.cogsci.ucsd.edu/~dgroppe/ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From dgroppe at cogsci.ucsd.edu Tue Feb 8 19:18:59 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Tue, 8 Feb 2011 13:18:59 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <2657614842150526102@unknownmsgid> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid> Message-ID: On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris wrote: > Dear David, > > >> Thanks very much for the email Eric, but I'm confused as to why you >> answered "No" to my second comment.  From what I understand, if you >> use a value of minnbchan that is greater than 0, then any significant >> clusters will necessarily spread across multiple electrodes.  For >> example, if you set minnbchan to 1, then all significant clusters will >> have to include at least two electrodes so that each significant >> "voxel" has at least one neighbor at another electrode.  Thus, if your >> effect is truly at only a single electrode, having a value of >> minnbchan greater than 0 will force you to miss the effect or to think >> it occurs at more electrodes than it really does.  What part of my >> reasoning is incorrect? > > Your reasoning is correct and mine was incorrect. I should read better > before I write. My apologies for this. Got it. Thanks very much for clarifying Eric. > > I do have to qualify that with minnbchan=0 it may also happen that your > significant cluster contains more than one electrode (the electrode with the > true effect plus some surrounding ones that by accident exceed the threshold > that is used to identify clusters). That makes perfect sense. Since our lab uses only a limited number of electrodes (32), I wanted to make sure I understood the minimum number of electrodes an effect needs to span to be detected. once again, I very much appreciate your answers to my questions, -David > Best, > > Eric > > > > >>      again, thanks very much for the help, >>             -David >> >> >> > Best, >> > >> > Eric >> > >> > >> > dr. Eric Maris >> > Donders Institute for Brain, Cognition and Behavior >> > Radboud University >> > P.O. Box 9104 >> > 6500 HE Nijmegen >> > The Netherlands >> > T:+31 24 3612651 >> > Mobile: 06 39584581 >> > F:+31 24 3616066 >> > mailto:e.maris at donders.ru.nl >> > http://www.nphyscog.com/ >> > >> > >> > >> > >> > >> > >> > >> > >> >>     thanks for your help, >> >>         -David >> >> >> >> >> >> -- >> >> David Groppe, Ph.D. >> >> dgroppe at cogsci.ucsd.edu >> >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> David Groppe, Ph.D. >> Postdoctoral Researcher >> Kutaslab >> Dept. of Cognitive Science >> University of California, San Diego >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >> _______________________________________________ >> 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 > -- David Groppe, Ph.D. Postdoctoral Researcher Kutaslab Dept. of Cognitive Science University of California, San Diego http://www.cogsci.ucsd.edu/~dgroppe/ From r.oostenveld at donders.ru.nl Wed Feb 9 10:25:13 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 9 Feb 2011 10:25:13 +0100 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> Message-ID: <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Dear Scott, thanks for reporting this problem and for already tracking it down to files not being closed. ft_read_data does the following on every read-request (line 772), case {'neuromag_fif' 'neuromag_mne'} % check that the required low-level toolbox is available ft_hastoolbox('mne', 1); if (hdr.orig.iscontinuous) dat = fiff_read_raw_segment(hdr.orig.raw,begsample+hdr.orig.raw.first_samp-1,endsample+hdr.orig.raw.first_samp-1,chanindx); from this I understand that the file is already supposed to be open and represented in hdr.orig.raw (hdr.orig is in general where fieldtrip stores the original header details, i.e. including all system specific information). and prior to that it does (line 223) % read the header if it is not provided if isempty(hdr) hdr = ft_read_header(filename, 'headerformat', headerformat); end I would expect the part on ft_read_header not to be executed on every call to ft_read_data, because in general ft_read_header has already been called outside ft_read_data (e.g. to select the channels prior to start the reading). So ft_preprocessing calls ft_read_header once and ft_read_data many times. and in ft_read_header it does orig = fiff_read_meas_info(filename); and raw = fiff_setup_read_raw(filename); Diagnosis: ft_read_header opens the file, ft_read_data keeps it open. Then you move to the next file, and that one is also opened (and kept open). Hmm, indeed a problem. The design idea is that reading from files shoudl be stateless, i.e. prior and after each read operation the file should be closed. On modern file systems there is no penalty associated with that, and it keeps the code much cleaner. That is why fieldtrip does not have a ft_open_file and ft_close_file function, and why you cannot close the file (except with fclose('all')). Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw are supposed to keep the files open? I could not find a fiff_close function, do you know whether there is one? best Robert PS let's do the follow up discussion via the bug tracking system and not on the email list... you should have received a mail from that by now. On 4 Feb 2011, at 17:12, Scott Burns wrote: > FieldTrip Experts - > > I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. > > I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. > > I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. > > FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). > > > Scott Burns > Kuperberg Lab > Martinos Center for Biomedical Imaging > sburns at nmr.mgh.harvard.edu > > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > _______________________________________________ > 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 r.oostenveld at donders.ru.nl Wed Feb 9 10:43:55 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 9 Feb 2011 10:43:55 +0100 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Message-ID: Hi Laurence thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. best Robert On 8 Feb 2011, at 16:33, Laurence Hunt wrote: > Hi Scott - > > Thanks for the e-mail - it's a good point. > > The difficulty arises because fiff_setup_read_raw (called by > ft_read_header) leaves the .fif file open to be read (it stores the > fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for > fieldtrip). Unfortunately if we closed it at this stage (i.e. within > ft_read_header), fiff_read_raw_segment, which is called by > ft_read_data/ft_read_event, doesn't know where to look for the file > - it expects a structure to be returned by fiff_setup_read_raw with > an open file. Again, we could close the file after calling > fiff_read_raw_segment in ft_read_data, but this would assume that > ft_read_data/ft_read_event is only going to be called once, whereas > some users might want to use hdr=ft_read_header once and then keep > on using ft_read_data with same hdr structure, in which case we need > to keep the file open. > > Unless you can think of a better solution, my suggestion would be > first to call > > hdr=ft_read_header(fname); > > in your script, then supply this hdr to your calls to ft_read_event/ > ft_read_data (this should hopefully prevent the file being opened > multiple times), and then once you have done all the reading, close > that file with > > fclose(hdr.orig.raw.fid); > > Hopefully that will stop you clogging up matlab with open files. Let > me know if it works or not. > > Cheers, > Laurence > > =========================================== > Laurence Hunt, DPhil Student > Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > > On 4 Feb 2011, at 16:12, Scott Burns wrote: > >> FieldTrip Experts - >> >> I'm building a FieldTrip pipeline for use on M/EEG data collected >> on a Neuromag 306 system. Because I'm looping over subjects (13 >> currently), event type (5 unique events), and number of runs (4), >> there's lots of preprocessing to do. After processing a certain >> amount of files, MATLAB refuses to open more files. >> >> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only >> include the data files I'm using, not MATLAB's system files) and >> found that for every innermost loop, my script is opening the .fif >> file twice and not releasing it. I use a custom function for >> ft_definetrial and in that I use ft_read_event (that operates on >> the .fif file). After defining trials, I use ft_preprocessing. >> >> I would venture to guess that both ft_read_event and ft_read_data >> (ft_preprocessing:line 492) are either 1) not closing files they've >> opened (presumably through MNE functions), or 2) they're using >> shared code that doesn't close files. I use MNE and haven't run >> into this issue before. That being said, fclose('all') does close >> all these files but I think it's still worth looking into. >> >> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >> >> >> Scott Burns >> Kuperberg Lab >> Martinos Center for Biomedical Imaging >> sburns at nmr.mgh.harvard.edu >> >> The information in this e-mail is intended only for the person to >> whom it is addressed. If you believe this e-mail was sent to you in >> error and the e-mail contains patient information, please contact >> the Partners Compliance HelpLine at http://www.partners.org/complianceline >> . If the e-mail was sent to you in error but does not contain >> patient information, please contact the sender and properly dispose >> of the e-mail. >> >> >> >> >> _______________________________________________ >> 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 lhunt at fmrib.ox.ac.uk Wed Feb 9 13:21:07 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 12:21:07 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Message-ID: <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> Hi Robert, (i) Re-running fiff_setup_read_raw in ft_read_data might slow down operations with multiple calls to ft_read_data (e.g. reading multiple trials from a raw dataset), as it takes about half a second to execute fiff_setup_read_raw once. (ii) Just using fopen and fclose would be much faster, but fiff_setup_read_raw does indeed move the file cursor to a new position, so I think the best solution is to store this position after the file has been opened by fiff_setup_read_raw. So, within ft_read_header, add: raw.pos = ftell(raw.fid); fclose(raw.fid); and in ft_read_data, add hdr.orig.raw.fid = fopen(filename,'rb','ieee-be'); fseek(hdr.orig.raw.fid,hdr.orig.raw.pos,'bof'); before the call to fiff_read_raw_segment, and fclose it afterwards. This seems to work fine if I make these amendments to my version of the code. Hope this helps, Laurence On 9 Feb 2011, at 09:43, Robert Oostenveld wrote: > Hi Laurence > > thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. > > Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? > > If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). > > Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). > > What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. > > best > Robert > > > > On 8 Feb 2011, at 16:33, Laurence Hunt wrote: > >> Hi Scott - >> >> Thanks for the e-mail - it's a good point. >> >> The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. >> >> Unless you can think of a better solution, my suggestion would be first to call >> >> hdr=ft_read_header(fname); >> >> in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with >> >> fclose(hdr.orig.raw.fid); >> >> Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. >> >> Cheers, >> Laurence >> >> =========================================== >> Laurence Hunt, DPhil Student >> Centre for Functional MRI of the Brain (FMRIB), >> University of Oxford >> lhunt at fmrib.ox.ac.uk >> Phone: (+44)1865-(2)22738 >> =========================================== >> >> On 4 Feb 2011, at 16:12, Scott Burns wrote: >> >>> FieldTrip Experts - >>> >>> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >>> >>> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >>> >>> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >>> >>> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >>> >>> >>> Scott Burns >>> Kuperberg Lab >>> Martinos Center for Biomedical Imaging >>> sburns at nmr.mgh.harvard.edu >>> >>> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Wed Feb 9 13:22:18 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 12:22:18 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> Message-ID: p.s. I think this only applies to continuous data - evoked responses are closed in ft_read_header already, I think. L On 9 Feb 2011, at 12:21, Laurence Hunt wrote: > Hi Robert, > > (i) Re-running fiff_setup_read_raw in ft_read_data might slow down operations with multiple calls to ft_read_data (e.g. reading multiple trials from a raw dataset), as it takes about half a second to execute fiff_setup_read_raw once. > > (ii) Just using fopen and fclose would be much faster, but fiff_setup_read_raw does indeed move the file cursor to a new position, so I think the best solution is to store this position after the file has been opened by fiff_setup_read_raw. So, within ft_read_header, add: > > raw.pos = ftell(raw.fid); > fclose(raw.fid); > > and in ft_read_data, add > > hdr.orig.raw.fid = fopen(filename,'rb','ieee-be'); > fseek(hdr.orig.raw.fid,hdr.orig.raw.pos,'bof'); > > before the call to fiff_read_raw_segment, and fclose it afterwards. This seems to work fine if I make these amendments to my version of the code. > > Hope this helps, > Laurence > > On 9 Feb 2011, at 09:43, Robert Oostenveld wrote: > >> Hi Laurence >> >> thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. >> >> Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? >> >> If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). >> >> Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). >> >> What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. >> >> best >> Robert >> >> >> >> On 8 Feb 2011, at 16:33, Laurence Hunt wrote: >> >>> Hi Scott - >>> >>> Thanks for the e-mail - it's a good point. >>> >>> The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. >>> >>> Unless you can think of a better solution, my suggestion would be first to call >>> >>> hdr=ft_read_header(fname); >>> >>> in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with >>> >>> fclose(hdr.orig.raw.fid); >>> >>> Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. >>> >>> Cheers, >>> Laurence >>> >>> =========================================== >>> Laurence Hunt, DPhil Student >>> Centre for Functional MRI of the Brain (FMRIB), >>> University of Oxford >>> lhunt at fmrib.ox.ac.uk >>> Phone: (+44)1865-(2)22738 >>> =========================================== >>> >>> On 4 Feb 2011, at 16:12, Scott Burns wrote: >>> >>>> FieldTrip Experts - >>>> >>>> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >>>> >>>> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >>>> >>>> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >>>> >>>> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >>>> >>>> >>>> Scott Burns >>>> Kuperberg Lab >>>> Martinos Center for Biomedical Imaging >>>> sburns at nmr.mgh.harvard.edu >>>> >>>> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > =========================================== > Laurence Hunt, DPhil Student > Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From sburns at nmr.mgh.harvard.edu Wed Feb 9 16:27:14 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 10:27:14 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: <9F93CD03-78CC-4D03-BF55-239D5D12EFD0@nmr.mgh.harvard.edu> I tried replying to the latest email from the bug tracker but got back a Delivery Failure. What'd I do wrong? (the error was the bugzilla_daemon at fcdonders.ru.nl is an unknown or illegal alias) Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. On Feb 9, 2011, at 4:25 AM, Robert Oostenveld wrote: > Dear Scott, > > thanks for reporting this problem and for already tracking it down to files not being closed. > > ft_read_data does the following on every read-request (line 772), > case {'neuromag_fif' 'neuromag_mne'} > % check that the required low-level toolbox is available > ft_hastoolbox('mne', 1); > if (hdr.orig.iscontinuous) > dat = fiff_read_raw_segment(hdr.orig.raw,begsample+hdr.orig.raw.first_samp-1,endsample+hdr.orig.raw.first_samp-1,chanindx); > > from this I understand that the file is already supposed to be open and represented in hdr.orig.raw (hdr.orig is in general where fieldtrip stores the original header details, i.e. including all system specific information). > > and prior to that it does (line 223) > % read the header if it is not provided > if isempty(hdr) > hdr = ft_read_header(filename, 'headerformat', headerformat); > end > > I would expect the part on ft_read_header not to be executed on every call to ft_read_data, because in general ft_read_header has already been called outside ft_read_data (e.g. to select the channels prior to start the reading). So ft_preprocessing calls ft_read_header once and ft_read_data many times. > > and in ft_read_header it does > orig = fiff_read_meas_info(filename); > and > raw = fiff_setup_read_raw(filename); > > Diagnosis: ft_read_header opens the file, ft_read_data keeps it open. Then you move to the next file, and that one is also opened (and kept open). Hmm, indeed a problem. The design idea is that reading from files shoudl be stateless, i.e. prior and after each read operation the file should be closed. On modern file systems there is no penalty associated with that, and it keeps the code much cleaner. That is why fieldtrip does not have a ft_open_file and ft_close_file function, and why you cannot close the file (except with fclose('all')). > > Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw are supposed to keep the files open? I could not find a fiff_close function, do you know whether there is one? > > best > Robert > > PS let's do the follow up discussion via the bug tracking system and not on the email list... you should have received a mail from that by now. > > > On 4 Feb 2011, at 17:12, Scott Burns wrote: > >> FieldTrip Experts - >> >> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >> >> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >> >> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >> >> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >> >> >> Scott Burns >> Kuperberg Lab >> Martinos Center for Biomedical Imaging >> sburns at nmr.mgh.harvard.edu >> >> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >> >> >> >> >> _______________________________________________ >> 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 gramfort at nmr.mgh.harvard.edu Wed Feb 9 16:31:02 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 10:31:02 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi, > The design idea is that reading from files shoudl be > stateless, i.e. prior and after each read operation the file should be > closed. On modern file systems there is no penalty associated with that, and > it keeps the code much cleaner. That is why fieldtrip does not have a > ft_open_file and ft_close_file function, and why you cannot close the file > (except with fclose('all')). > Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw > are supposed to keep the files open? I could not find a fiff_close function, > do you know whether there is one? fiff_setup_read_raw keeps the files open for subsequent calls of fiff_read_raw_segment, fiff_read_raw_segment_times etc. when done the file can be closed with : fclose(raw.fid) assuming you used: raw = fiff_setup_read_raw(filename); FYI (I wanted to wait but it seems to be a good occasion) the mne-matlab code is now publicly hosted on line: https://github.com/mne-tools/mne-matlab latest commits: https://github.com/mne-tools/mne-matlab/commits/master the license of this code has been changed to BSD. If you have feature request, bug reports or willing to contribute some code that's a good place to do it. If you need help, just send me an email. If fieldtripers turn out to modify the mne matlab code it would be great to consider applying the modifications on the main repository. Alex -- Alexandre Gramfort, PhD gramfort at nmr.mgh.harvard.edu Dept. of Radiology MGH Martinos Center / Harvard Medical School http://www-sop.inria.fr/members/Alexandre.Gramfort/ From v.litvak at ion.ucl.ac.uk Wed Feb 9 16:54:29 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 15:54:29 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi Alexandre, So why does fiff_setup_read_raw take so long? Do you really need half a second to open a fif file or does it also read some header data not all of which is necessary? Could there perhaps be a faster version for repeated calls that would make it possible to keep fileio code stateless? Vladimir On Wed, Feb 9, 2011 at 3:31 PM, Alexandre Gramfort wrote: > Hi, > >> The design idea is that reading from files shoudl be >> stateless, i.e. prior and after each read operation the file should be >> closed. On modern file systems there is no penalty associated with that, and >> it keeps the code much cleaner. That is why fieldtrip does not have a >> ft_open_file and ft_close_file function, and why you cannot close the file >> (except with fclose('all')). >> Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw >> are supposed to keep the files open? I could not find a fiff_close function, >> do you know whether there is one? > > fiff_setup_read_raw keeps the files open for subsequent calls of > fiff_read_raw_segment, fiff_read_raw_segment_times etc. > > when done the file can be closed with : > > fclose(raw.fid) > > assuming you used: > raw = fiff_setup_read_raw(filename); > > FYI (I wanted to wait but it seems to be a good occasion) > the mne-matlab code is now publicly hosted on line: > > https://github.com/mne-tools/mne-matlab > > latest commits: > https://github.com/mne-tools/mne-matlab/commits/master > > the license of this code has been changed to BSD. > > If you have feature request, bug reports or willing to contribute some code > that's a good place to do it. If you need help, just send me an email. > > If fieldtripers turn out to modify the mne matlab code it would be great to > consider applying the modifications on the main repository. > > Alex > -- > Alexandre Gramfort, PhD > gramfort at nmr.mgh.harvard.edu > Dept. of Radiology MGH Martinos Center / Harvard Medical School > http://www-sop.inria.fr/members/Alexandre.Gramfort/ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 17:05:51 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 11:05:51 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi Vladimir, > So why does fiff_setup_read_raw take so long? Do you really need half > a second to open a fif file or does it also read some header data not > all of which is necessary? fiff_setup_read_raw reads many things from the fif file: - measurement info - sampling rate - first/last time sample to do this it locates in the file the location of all the info (the fif tags). So when you look for something in the file, you go down the tree (in matlab) and that points you to the location in the file where to read. > Could there perhaps be a faster version for > repeated calls that would make it possible to keep fileio code > stateless? we could write a single function that does both : fiff_setup_read_raw and fiff_read_raw_segment if it can help. Alex From v.litvak at ion.ucl.ac.uk Wed Feb 9 17:16:19 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 16:16:19 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: The question is if it would be possible to pre-read those fif tags and all the other info and store it in the header, then close the file and then given just the samples to read to open it again and navigate fast to the right place based on the info that has been stored before? Those tags don't change (do they?) so it should be sufficient to read them once. Vladimir On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort wrote: > Hi Vladimir, > >> So why does fiff_setup_read_raw take so long? Do you really need half >> a second to open a fif file or does it also read some header data not >> all of which is necessary? > > fiff_setup_read_raw reads many things from the fif file: > - measurement info > - sampling rate > - first/last time sample > > to do this it locates in the file the location of all the info (the fif tags). > So when you look for something in the file, you go down the tree > (in matlab) and that points you to the location in the file where to read. > >> Could there perhaps be a faster version for >> repeated calls that would make it possible to keep fileio code >> stateless? > > we could write a single function that does both : > fiff_setup_read_raw and fiff_read_raw_segment > if it can help. > > Alex > > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 17:41:05 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 11:41:05 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: the filename is stored raw.info we could close the file after the fiff_setup_read_raw and then do raw.fid = fopen(raw.info.filename) before reading from it later. see my attempt : https://github.com/agramfort/mne-matlab/commit/5a88ef764a5931c14015708d372942ed2f892b6c would this solve your pb? Alex On Wed, Feb 9, 2011 at 11:16 AM, Vladimir Litvak wrote: > The question is if it would be possible to pre-read those fif tags and > all the other info and store it in the header, then close the file and > then given just the samples to read to open it again and navigate fast > to the right place based on the info that has been stored before? > Those tags don't change (do they?) so it should be sufficient to read > them once. > > Vladimir > > On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort > wrote: >> Hi Vladimir, >> >>> So why does fiff_setup_read_raw take so long? Do you really need half >>> a second to open a fif file or does it also read some header data not >>> all of which is necessary? >> >> fiff_setup_read_raw reads many things from the fif file: >> - measurement info >> - sampling rate >> - first/last time sample >> >> to do this it locates in the file the location of all the info (the fif tags). >> So when you look for something in the file, you go down the tree >> (in matlab) and that points you to the location in the file where to read. >> >>> Could there perhaps be a faster version for >>> repeated calls that would make it possible to keep fileio code >>> stateless? >> >> we could write a single function that does both : >> fiff_setup_read_raw and fiff_read_raw_segment >> if it can help. >> >> Alex >> >> > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in error > but does not contain patient information, please contact the sender and properly > dispose of the e-mail. > > From lhunt at fmrib.ox.ac.uk Wed Feb 9 18:35:46 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 17:35:46 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Hi Alex, I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). So we need to store the cursor position too. See my earlier e-mail. Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 9 Feb 2011, at 16:41, Alexandre Gramfort wrote: > the filename is stored raw.info > > we could close the file after the fiff_setup_read_raw > and then do > raw.fid = fopen(raw.info.filename) > before reading from it later. > > see my attempt : > > https://github.com/agramfort/mne-matlab/commit/5a88ef764a5931c14015708d372942ed2f892b6c > > would this solve your pb? > > Alex > > On Wed, Feb 9, 2011 at 11:16 AM, Vladimir Litvak wrote: >> The question is if it would be possible to pre-read those fif tags and >> all the other info and store it in the header, then close the file and >> then given just the samples to read to open it again and navigate fast >> to the right place based on the info that has been stored before? >> Those tags don't change (do they?) so it should be sufficient to read >> them once. >> >> Vladimir >> >> On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort >> wrote: >>> Hi Vladimir, >>> >>>> So why does fiff_setup_read_raw take so long? Do you really need half >>>> a second to open a fif file or does it also read some header data not >>>> all of which is necessary? >>> >>> fiff_setup_read_raw reads many things from the fif file: >>> - measurement info >>> - sampling rate >>> - first/last time sample >>> >>> to do this it locates in the file the location of all the info (the fif tags). >>> So when you look for something in the file, you go down the tree >>> (in matlab) and that points you to the location in the file where to read. >>> >>>> Could there perhaps be a faster version for >>>> repeated calls that would make it possible to keep fileio code >>>> stateless? >>> >>> we could write a single function that does both : >>> fiff_setup_read_raw and fiff_read_raw_segment >>> if it can help. >>> >>> Alex >>> >>> >> >> >> The information in this e-mail is intended only for the person to whom it is >> addressed. If you believe this e-mail was sent to you in error and the e-mail >> contains patient information, please contact the Partners Compliance HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you in error >> but does not contain patient information, please contact the sender and properly >> dispose of the e-mail. >> >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 19:16:41 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 13:16:41 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Message-ID: hi, > I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). ok. That was a quick and dirty hack to give an idea. > So we need to store the cursor position too. See my earlier e-mail. maybe you or scott can propose a fix in the same vein? I can give you write access to the mne-matlab code if you want. Alex From sburns at nmr.mgh.harvard.edu Wed Feb 9 19:44:19 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 13:44:19 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Message-ID: <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> --I tried sending this on the bug report thread but got a delivery failure notice -- Robert, Laurence and Alexandre - Thanks for the feedback on this issue. Here are my thoughts on further investigation. Since ft_preprocessing calls its own ft_read_header (ft_preprocessing:327), ft_read_event isn't actually going for data, and that ft_definetrial and ft_preprocessing are separate high-level functions, then I think we can assume that no actual data will be read during ft_read_event and the file can be closed towards the end of the ft_read_event function. That closes one leak. Because ft_preprocessing is one of the high-level functions of FT and that the function is structured to operate on the data file once per event, it should clean up anything it opened. It'd be simple enough to check if hdr.orig.raw.fid is still open after all the data reading has been done (after ft_preprocessing:530) and close it. This way, you wouldn't have to fundamentally change how ft_read_data operates on neuromag files. I'm not sure how the architecture of FT deals with other file formats and whether this is sort of leak can occur in other situations, but this seems to be the easiest fix to this problem. Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. On Feb 9, 2011, at 1:16 PM, Alexandre Gramfort wrote: > hi, > >> I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). > > ok. That was a quick and dirty hack to give an idea. > >> So we need to store the cursor position too. See my earlier e-mail. > > maybe you or scott can propose a fix in the same vein? > > I can give you write access to the mne-matlab code if you want. > > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanweisz at mac.com Wed Feb 9 21:25:42 2011 From: nathanweisz at mac.com (Nathan Weisz) Date: Wed, 09 Feb 2011 21:25:42 +0100 Subject: [FieldTrip] dipolefitting issues Message-ID: <881B6122-2D39-4716-B1F6-6244DDE06703@mac.com> hi everyone, i'm trying to help out a colleague who is trying to analyse some auditory evoked potential (EEG) data and for the research question at hand it would be nice to separate left vs. right hemisphere. we want to keep things simple first by fitting symmetric dipoles to e.g. the N1 and then use the positions to estimate the dipole moments for the entire ERP. the ERP that we want to build the source montage on is calculated from ~600 trials, i.e. we see what we need to see very nicely. we are using a spherical headmodel (electrode positions also on sphere) as described on the FT homepage: vol = []; vol.r = [0.88 0.92 1.00]; % radii of spheres vol.c = [1 1/80 1]; % conductivity vol.o = [0 0 0]; using a precomputed leadfield i the turn to ft_dipolefitting: cfg = []; cfg.vol = vol; % see above cfg.elec = data.elec; % see above cfg.gridsearch = 'yes'; cfg.numdipoles=2; cfg.symmetry='y'; %nach den elec.pnt sieht es so aus als wäre y links / rechts cfg.grid=lf; cfg.latency=[.05 .1]; dip1 = ft_dipolefitting(cfg, avgbl); i get following message: ... > scanning grid location 279/280 > scanning grid location 280/280 > found minimum after scanning on grid point [-0.111111 0.111111 0.111111; -0.111111 -0.111111 0.111111] > First-order > Iteration Func-count f(x) Step-size optimality > 0 4 0.0406088 0.5 > > Local minimum possible. > > fminunc stopped because it cannot decrease the objective function > along the current search direction. > > > > found minimum after non-linear optimization on [-0.111111 0.111111 -0.111111; -0.111111 -0.111111 -0.111111] i then ran the tutorial example here: http://fieldtrip.fcdonders.nl/example/compute_forward_simulated_data_and_apply_a_dipole_fit just to check if there may be something fundamentally wrong with my code. however i get a similar message suggesting something went wrong: > scanning grid location 26/27 > scanning grid location 27/27 > found minimum after scanning on grid point [0 0.5 0.5] > First-order > Iteration Func-count f(x) Step-size optimality > 0 4 0.0293345 0.303 > 1 8 0.0079586 1 0.15 > 2 12 5.63895e-05 1 0.0138 > 3 16 5.75471e-06 1 0.00446 > 4 20 8.86701e-11 1 1.33e-05 > 5 24 1.45576e-14 1 1.3e-07 > 6 28 1.75862e-16 1 2.61e-08 > > Local minimum possible. > > fminunc stopped because the size of the current step is less than > the default value of the step size tolerance. > > > > found minimum after non-linear optimization on [-5.08281e-09 0.5 0.3] I am using Matlab 2010b. a fairly recent fieldtrip (~3 months old or so). there was a similar question on the archives, however i found no answer: http://mailman.science.ru.nl/pipermail/fieldtrip/2010-May/002874.html is this an issue related to the matlab version and the fminunc function? i would be grateful about any suggestion. cheers, nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.litvak at ion.ucl.ac.uk Wed Feb 9 21:48:35 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 20:48:35 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: Dear Scott, I think I know Robert's views quite well and he wouldn't like your solution because ft_preprocessing will have to deal with a format-specific low-level issue that should be handled by fileio. This will violate the software architecture which for FT is a big deal (and rightly so).  If, however, it is sufficient to store in the header a single number which can then be used to find the data onset and from there to find where to start reading (so perhaps not an fid but just the data offset in bytes to do fseek), that'd be a perfectly good solution and fast as well. But I don't know enough about  fif format to say if it's possible. Vladimir On Wednesday, February 9, 2011, Scott Burns wrote: > --I tried sending this on the bug report thread but got a delivery failure notice -- > > Robert, Laurence and Alexandre - > Thanks for the feedback on this issue. Here are my thoughts on further investigation. > Since ft_preprocessing calls its own ft_read_header (ft_preprocessing:327), ft_read_event isn't actually going for data, and that ft_definetrial and ft_preprocessing are separate high-level functions, then I think we can assume that no actual data will be read during ft_read_event and the file can be closed towards the end of the ft_read_event function. That closes one leak. > Because ft_preprocessing is one of the high-level functions of FT and that the function is structured to operate on the data file once per event, it should clean up anything it opened.  It'd be simple enough to check if hdr.orig.raw.fid is still open after all the data reading has been done (after ft_preprocessing:530) and close it.  This way, you wouldn't have to fundamentally change how ft_read_data operates on neuromag files. I'm not sure how the architecture of FT deals with other file formats and whether this is sort of leak can occur in other situations, but this seems to be the easiest fix to this problem. > > Scott BurnsKuperberg LabMartinos Center for Biomedical Imagingsburns at nmr.mgh.harvard.edu > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > On Feb 9, 2011, at 1:16 PM, Alexandre Gramfort wrote: > hi, > > I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). > > ok. That was a quick and dirty hack to give an idea. > > So we need to store the cursor position too. See my earlier e-mail. > > maybe you or scott can propose a fix in the same vein? > > I can give you write access to the mne-matlab code if you want. > > Alex > > > > From sburns at nmr.mgh.harvard.edu Wed Feb 9 22:06:09 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 16:06:09 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: <995D8606-7ED7-48BB-86FF-1CE529C97166@nmr.mgh.harvard.edu> On Feb 9, 2011, at 3:48 PM, Vladimir Litvak wrote: > think I know Robert's views quite well and he wouldn't like your > solution because ft_preprocessing will have to deal with a > format-specific low-level issue that should be handled by fileio. Makes sense, my solution is just a hack. Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Wed Feb 9 22:12:37 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 21:12:37 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> I think it should be possible to do it this way - when I tested it, it seemed to work OK. On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: > If, however, it is sufficient to store in the header a > single number which can then be used to find the data onset and from > there to find where to start reading (so perhaps not an fid but just > the data offset in bytes to do fseek), that'd be a perfectly good > solution and fast as well. But I don't know enough about fif format > to say if it's possible. =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== From gramfort at nmr.mgh.harvard.edu Wed Feb 9 22:17:54 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 16:17:54 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> Message-ID: again if something needs to be changed in the mne matlab code I'd be happy to help. Alex On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: > I think it should be possible to do it this way - when I tested it, it seemed to work OK. > > On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: > >> If, however, it is sufficient to store in the header a >> single number which can then be used to find the data onset and from >> there to find where to start reading (so perhaps not an fid but just >> the data offset in bytes to do fseek), that'd be a perfectly good >> solution and fast as well. But I don't know enough about  fif format >> to say if it's possible. > > =========================================== > Laurence Hunt, DPhil Student >  Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From lhunt at fmrib.ox.ac.uk Wed Feb 9 22:33:13 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 21:33:13 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> Message-ID: <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> Thanks Alex - I guess it might also be useful to add to the mne code instead, as long as it doesn't cause any problems elsewhere for other users...? Thinking about it, I reckon it would work if you used the same solution you suggested previously on your website, but just added data.pos = ftell(data.fid); %before running fclose in fiff_setup_read_raw and fseek(raw.fid,raw.pos); %after re-opening the file in fiff_read_raw_segment (...followed by an fclose of raw.fid at the end of fiff_read_raw_segment, of course). If you did this, it would save us making any changes in fieldtrip at all :) Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 9 Feb 2011, at 21:17, Alexandre Gramfort wrote: > again if something needs to be changed in the mne matlab code > I'd be happy to help. > > Alex > > On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: >> I think it should be possible to do it this way - when I tested it, it seemed to work OK. >> >> On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: >> >>> If, however, it is sufficient to store in the header a >>> single number which can then be used to find the data onset and from >>> there to find where to start reading (so perhaps not an fid but just >>> the data offset in bytes to do fseek), that'd be a perfectly good >>> solution and fast as well. But I don't know enough about fif format >>> to say if it's possible. >> >> =========================================== >> Laurence Hunt, DPhil Student >> Centre for Functional MRI of the Brain (FMRIB), >> University of Oxford >> lhunt at fmrib.ox.ac.uk >> Phone: (+44)1865-(2)22738 >> =========================================== >> _______________________________________________ >> 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 michael.wibral at web.de Thu Feb 10 09:58:57 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 10 Feb 2011 09:58:57 +0100 (CET) Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, Message-ID: <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> Dear David, dear Eric, there is one additional side effect of specifying a LARGE minnbchan that actually leads to SMALLEr clusters in a certain sense. If I understand correctly, at any point in time&frequency the cluster has to have a spatial extension of minnbchan+1. So when you specify a large value the cluster may more easily be cut up into several smaller ones along the space&time dimension - which may or may not be desirable. Michael -----Ursprüngliche Nachricht----- Von: "David Groppe" Gesendet: Feb 8, 2011 7:18:59 PM An: "Email discussion list for the FieldTrip project" Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris wrote: >> Dear David, >> >> >>> Thanks very much for the email Eric, but I'm confused as to why you >>> answered "No" to my second comment.  From what I understand, if you >>> use a value of minnbchan that is greater than 0, then any significant >>> clusters will necessarily spread across multiple electrodes.  For >>> example, if you set minnbchan to 1, then all significant clusters will >>> have to include at least two electrodes so that each significant >>> "voxel" has at least one neighbor at another electrode.  Thus, if your >>> effect is truly at only a single electrode, having a value of >>> minnbchan greater than 0 will force you to miss the effect or to think >>> it occurs at more electrodes than it really does.  What part of my >>> reasoning is incorrect? >> >> Your reasoning is correct and mine was incorrect. I should read better >> before I write. My apologies for this. > >Got it. Thanks very much for clarifying Eric. > >> >> I do have to qualify that with minnbchan=0 it may also happen that your >> significant cluster contains more than one electrode (the electrode with the >> true effect plus some surrounding ones that by accident exceed the threshold >> that is used to identify clusters). > >That makes perfect sense. Since our lab uses only a limited number of >electrodes (32), I wanted to make sure I understood the minimum number >of electrodes an effect needs to span to be detected. > once again, I very much appreciate your answers to my questions, > -David > >> Best, >> >> Eric >> >> >> >> >>>      again, thanks very much for the help, >>>             -David >>> >>> >>> > Best, >>> > >>> > Eric >>> > >>> > >>> > dr. Eric Maris >>> > Donders Institute for Brain, Cognition and Behavior >>> > Radboud University >>> > P.O. Box 9104 >>> > 6500 HE Nijmegen >>> > The Netherlands >>> > T:+31 24 3612651 >>> > Mobile: 06 39584581 >>> > F:+31 24 3616066 >>> > mailto:e.maris at donders.ru.nl >>> > http://www.nphyscog.com/ >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>     thanks for your help, >>> >>         -David >>> >> >>> >> >>> >> -- >>> >> David Groppe, Ph.D. >>> >> dgroppe at cogsci.ucsd.edu >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ >>> >> _______________________________________________ >>> >> 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 >>> > >>> >>> >>> >>> -- >>> David Groppe, Ph.D. >>> Postdoctoral Researcher >>> Kutaslab >>> Dept. of Cognitive Science >>> University of California, San Diego >>> http://www.cogsci.ucsd.edu/~dgroppe/ >>> >>> _______________________________________________ >>> 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 >> > > > >-- >David Groppe, Ph.D. >Postdoctoral Researcher >Kutaslab >Dept. of Cognitive Science >University of California, San Diego >http://www.cogsci.ucsd.edu/~dgroppe/ > >_______________________________________________ >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From e.maris at donders.ru.nl Thu Feb 10 11:16:05 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Thu, 10 Feb 2011 11:16:05 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> Message-ID: <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> Hi Michael, > there is one additional side effect of specifying a LARGE minnbchan > that actually leads to SMALLEr clusters in a certain sense. If I > understand correctly, at any point in time&frequency the cluster has to > have a spatial extension of minnbchan+1. So when you specify a large > value the cluster may more easily be cut up into several smaller ones > along the space&time dimension - which may or may not be desirable. Whether it is a side effect or not, depends on how you look at it. For me it is its intended effect. I implemented the minnbchan-parameter after discussions with PhD-students that applied the cluster-based permutation statistics on channel-time-frequency data and produced significant clusters with weird shapes. Often, these shapes contained narrow "bridges" connecting nearby blobs in channel-time-frequency space. By increasing minnbchan, these bridges were removed and only the blobs remained. Although I understand the requests of the PhD-students that I discussed with, I find the discussions about the minnbchan-parameter not very rewarding. In fact, it is looking for isolated blobs that one would like to interpret as separate physiological entities. This contrast with the nature of the EEG/MEG data, which has poor spatial resolution (due to volume conduction and common pick-up), often poor spectral resolution (due to the short time windows of our time-resolved spectral analysis), and often poor time resolution (due to latency jitter over trials). Best, Eric > > Michael > > -----Ursprüngliche Nachricht----- > Von: "David Groppe" > Gesendet: Feb 8, 2011 7:18:59 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to > spatial neighbors? > > >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris > wrote: > >> Dear David, > >> > >> > >>> Thanks very much for the email Eric, but I'm confused as to why you > >>> answered "No" to my second comment. From what I understand, if you > >>> use a value of minnbchan that is greater than 0, then any > >>> significant clusters will necessarily spread across multiple > >>> electrodes. For example, if you set minnbchan to 1, then all > >>> significant clusters will have to include at least two electrodes > so > >>> that each significant "voxel" has at least one neighbor at another > >>> electrode. Thus, if your effect is truly at only a single > >>> electrode, having a value of minnbchan greater than 0 will force > you > >>> to miss the effect or to think it occurs at more electrodes than it > >>> really does. What part of my reasoning is incorrect? > >> > >> Your reasoning is correct and mine was incorrect. I should read > >> better before I write. My apologies for this. > > > >Got it. Thanks very much for clarifying Eric. > > > >> > >> I do have to qualify that with minnbchan=0 it may also happen that > >> your significant cluster contains more than one electrode (the > >> electrode with the true effect plus some surrounding ones that by > >> accident exceed the threshold that is used to identify clusters). > > > >That makes perfect sense. Since our lab uses only a limited number of > >electrodes (32), I wanted to make sure I understood the minimum number > >of electrodes an effect needs to span to be detected. > > once again, I very much appreciate your answers to my questions, > > -David > > > >> Best, > >> > >> Eric > >> > >> > >> > >> > >>> again, thanks very much for the help, > >>> -David > >>> > >>> > >>> > Best, > >>> > > >>> > Eric > >>> > > >>> > > >>> > dr. Eric Maris > >>> > Donders Institute for Brain, Cognition and Behavior Radboud > >>> > University P.O. Box 9104 6500 HE Nijmegen The Netherlands > >>> > T:+31 24 3612651 > >>> > Mobile: 06 39584581 > >>> > F:+31 24 3616066 > >>> > mailto:e.maris at donders.ru.nl > >>> > http://www.nphyscog.com/ > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> >> thanks for your help, > >>> >> -David > >>> >> > >>> >> > >>> >> -- > >>> >> David Groppe, Ph.D. > >>> >> dgroppe at cogsci.ucsd.edu > >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ > >>> >> _______________________________________________ > >>> >> 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 > >>> > > >>> > >>> > >>> > >>> -- > >>> David Groppe, Ph.D. > >>> Postdoctoral Researcher > >>> Kutaslab > >>> Dept. of Cognitive Science > >>> University of California, San Diego > >>> http://www.cogsci.ucsd.edu/~dgroppe/ > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > > >-- > >David Groppe, Ph.D. > >Postdoctoral Researcher > >Kutaslab > >Dept. of Cognitive Science > >University of California, San Diego > >http://www.cogsci.ucsd.edu/~dgroppe/ > > > >_______________________________________________ > >fieldtrip mailing list > >fieldtrip at donders.ru.nl > >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From lucie.charles.ens at googlemail.com Thu Feb 10 11:58:43 2011 From: lucie.charles.ens at googlemail.com (Lucie Charles) Date: Thu, 10 Feb 2011 11:58:43 +0100 Subject: [FieldTrip] Modification of ft_timelockgrandaverage cfg.keepindividual Message-ID: Hello everyone, It seems that there has been a modification of ft_timelockgrandaverage : now if you specify cfg.keepindividual = 'yes', the grandaverage is computed but is not included in the output of the function (see above). Why is that ? Many of my scripts rely on this option and I wanted to know if there was a good reason for it. Thanks, Lucie New version of ft_timelockgrandaverage (downloaded yesterday), line 159-176 %-------------------------------------------- % % collect the results %-------------------------------------------- grandavg = []; grandavg.label = cfg.channel; % cell-array %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete grandavg.time = ResultsTime; % 1 x Nsamples %KEEP INDIVIDUAL MEANS? if strcmp(cfg.keepindividual, 'yes') * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples grandavg.dimord = 'subj_chan_time';* else * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* grandavg.var = ResultVar; % Nchan x Nsamples grandavg.dimord = 'chan_time'; end Older version of ft_timelockgrandaverage (april 2010) %-------------------------------------------- % % collect the results %-------------------------------------------- %SWITCH CHANNEL TO LABEL? grandavg.label = cfg.channel; % cell-array grandavg.fsample = varargin{1}.fsample; grandavg.avg = ResultGrandavg; % Nchan x Nsamples grandavg.var = ResultVar; % Nchan x Nsamples grandavg.time = ResultsTime; % 1 x Nsamples %KEEP INDIVIDUAL MEANS? if strcmp(cfg.keepindividual, 'yes') grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples grandavg.dimord = 'subj_chan_time'; else grandavg.dimord = 'chan_time'; end -- Lucie CHARLES INSERM-CEA Cognitive Neuroimaging unit CEA/SAC/DSV/DRM/NeuroSpin Bât 145, Point Courrier 156 F-91191 Gif/Yvette, FRANCE Tel : +33 1 69 08 99 74 Fax : +33 1 69 08 79 73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 10 12:17:21 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 10 Feb 2011 12:17:21 +0100 Subject: [FieldTrip] Modification of ft_timelockgrandaverage cfg.keepindividual In-Reply-To: References: Message-ID: <99137929-ED6C-41A8-A70C-2C3F94E8AF76@donders.ru.nl> Dear Lucie, Yes, indeed this has recently been changed. The logic behind it is the following: One either typically wants to keep the individuals, OR the average. If in your case you need the average, you have to specify cfg.keepindividual = 'no'; Keeping both the average and the individual leads to an inconsistent definition of the data structure. The field 'dimord' does not allow for an unequivocal interpretation of both indidual and avg are present. If you need both the individual, and the avg, you now need to run ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', and once with cfg.keepindividual = 'no'; Best wishes, Jan-Mathijs On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: > Hello everyone, > > It seems that there has been a modification of > ft_timelockgrandaverage : now if you specify cfg.keepindividual = > 'yes', the grandaverage is computed but is not included in the > output of the function (see above). > > Why is that ? Many of my scripts rely on this option and I wanted to > know if there was a good reason for it. > > Thanks, > > Lucie > > New version of ft_timelockgrandaverage (downloaded yesterday), line > 159-176 > > %-------------------------------------------- > % % collect the results > %-------------------------------------------- > > grandavg = []; > grandavg.label = cfg.channel; % cell-array > %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete > grandavg.time = ResultsTime; % 1 x Nsamples > > %KEEP INDIVIDUAL MEANS? > if strcmp(cfg.keepindividual, 'yes') > grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples > grandavg.dimord = 'subj_chan_time'; > else > grandavg.avg = ResultGrandavg; % Nchan x Nsamples > grandavg.var = ResultVar; % Nchan x Nsamples > grandavg.dimord = 'chan_time'; > end > > Older version of ft_timelockgrandaverage (april 2010) > > %-------------------------------------------- > % % collect the results > %-------------------------------------------- > > %SWITCH CHANNEL TO LABEL? > grandavg.label = cfg.channel; % cell-array > grandavg.fsample = varargin{1}.fsample; > grandavg.avg = ResultGrandavg; % Nchan x Nsamples > grandavg.var = ResultVar; % Nchan x Nsamples > grandavg.time = ResultsTime; % 1 x Nsamples > > %KEEP INDIVIDUAL MEANS? > if strcmp(cfg.keepindividual, 'yes') > grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples > grandavg.dimord = 'subj_chan_time'; > else > grandavg.dimord = 'chan_time'; > end > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.wibral at web.de Thu Feb 10 12:33:05 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 10 Feb 2011 12:33:05 +0100 (CET) Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053>, <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> Message-ID: <2052784146.469173.1297337585004.JavaMail.fmail@mwmweb054> Hi Eric, sorry that I called this a "side-effect", I indeed find it most practical myself. I just didn't know this was the intended purpose. Michael -----Ursprüngliche Nachricht----- Von: "Eric Maris" Gesendet: Feb 10, 2011 11:16:05 AM An: "'Email discussion list for the FieldTrip project'" Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? >Hi Michael, > >> there is one additional side effect of specifying a LARGE minnbchan >> that actually leads to SMALLEr clusters in a certain sense. If I >> understand correctly, at any point in time&frequency the cluster has to >> have a spatial extension of minnbchan+1. So when you specify a large >> value the cluster may more easily be cut up into several smaller ones >> along the space&time dimension - which may or may not be desirable. > >Whether it is a side effect or not, depends on how you look at it. For me it is its intended effect. I implemented the minnbchan-parameter after discussions with PhD-students that applied the cluster-based permutation statistics on channel-time-frequency data and produced significant clusters with weird shapes. Often, these shapes contained narrow "bridges" connecting nearby blobs in channel-time-frequency space. By increasing minnbchan, these bridges were removed and only the blobs remained. > >Although I understand the requests of the PhD-students that I discussed with, I find the discussions about the minnbchan-parameter not very rewarding. In fact, it is looking for isolated blobs that one would like to interpret as separate physiological entities. This contrast with the nature of the EEG/MEG data, which has poor spatial resolution (due to volume conduction and common pick-up), often poor spectral resolution (due to the short time windows of our time-resolved spectral analysis), and often poor time resolution (due to latency jitter over trials). > >Best, > >Eric > > > > > >> >> Michael >> >> -----Ursprüngliche Nachricht----- >> Von: "David Groppe" >> Gesendet: Feb 8, 2011 7:18:59 PM >> An: "Email discussion list for the FieldTrip project" >> >> Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to >> spatial neighbors? >> >> >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris >> wrote: >> >> Dear David, >> >> >> >> >> >>> Thanks very much for the email Eric, but I'm confused as to why you >> >>> answered "No" to my second comment. From what I understand, if you >> >>> use a value of minnbchan that is greater than 0, then any >> >>> significant clusters will necessarily spread across multiple >> >>> electrodes. For example, if you set minnbchan to 1, then all >> >>> significant clusters will have to include at least two electrodes >> so >> >>> that each significant "voxel" has at least one neighbor at another >> >>> electrode. Thus, if your effect is truly at only a single >> >>> electrode, having a value of minnbchan greater than 0 will force >> you >> >>> to miss the effect or to think it occurs at more electrodes than it >> >>> really does. What part of my reasoning is incorrect? >> >> >> >> Your reasoning is correct and mine was incorrect. I should read >> >> better before I write. My apologies for this. >> > >> >Got it. Thanks very much for clarifying Eric. >> > >> >> >> >> I do have to qualify that with minnbchan=0 it may also happen that >> >> your significant cluster contains more than one electrode (the >> >> electrode with the true effect plus some surrounding ones that by >> >> accident exceed the threshold that is used to identify clusters). >> > >> >That makes perfect sense. Since our lab uses only a limited number of >> >electrodes (32), I wanted to make sure I understood the minimum number >> >of electrodes an effect needs to span to be detected. >> > once again, I very much appreciate your answers to my questions, >> > -David >> > >> >> Best, >> >> >> >> Eric >> >> >> >> >> >> >> >> >> >>> again, thanks very much for the help, >> >>> -David >> >>> >> >>> >> >>> > Best, >> >>> > >> >>> > Eric >> >>> > >> >>> > >> >>> > dr. Eric Maris >> >>> > Donders Institute for Brain, Cognition and Behavior Radboud >> >>> > University P.O. Box 9104 6500 HE Nijmegen The Netherlands >> >>> > T:+31 24 3612651 >> >>> > Mobile: 06 39584581 >> >>> > F:+31 24 3616066 >> >>> > mailto:e.maris at donders.ru.nl >> >>> > http://www.nphyscog.com/ >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> >> thanks for your help, >> >>> >> -David >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> David Groppe, Ph.D. >> >>> >> dgroppe at cogsci.ucsd.edu >> >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >>> >> _______________________________________________ >> >>> >> 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 >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> David Groppe, Ph.D. >> >>> Postdoctoral Researcher >> >>> Kutaslab >> >>> Dept. of Cognitive Science >> >>> University of California, San Diego >> >>> http://www.cogsci.ucsd.edu/~dgroppe/ >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> > >> > >> >-- >> >David Groppe, Ph.D. >> >Postdoctoral Researcher >> >Kutaslab >> >Dept. of Cognitive Science >> >University of California, San Diego >> >http://www.cogsci.ucsd.edu/~dgroppe/ >> > >> >_______________________________________________ >> >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From jan.schoffelen at donders.ru.nl Thu Feb 10 13:15:57 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 10 Feb 2011 13:15:57 +0100 Subject: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage cfg.keepindividual References: Message-ID: Dear Lucie, Thank you very much for your feedback. I take the liberty to anyhow post this to the discussion list, so that other people may take notice / join in the discussion / etc. > Thanks a lot for this quick response : I understand the logic behind > this. It's true that I noticed some inconsistencies due to the > interpretation of the field dimord which can't be well defined if > you have both individual and average data in your structure. OK > However, I think many people were happy with this option as it was. > It's quite handy to keep both the average and individual data > because you can compute statistics and at the same time you don't > have to redo the average every time. I think a lot of scripts rely > on that at least in our lab. The historical purpose for supporting cfg.keepindividual = 'yes', was in order to get a representation of all single subjects' data in a single data matrix: data.individual. Nowadays, ft_timelockstatistics supports multiple data structures in the input, i.e. ft_timelockstatistics(cfg, subj1, subj2 subj3, etc) so I think the call to ft_timelockgrandaverage could even be bypassed. The FieldTrip development team is very keen on providing backward compatibility support. While in general this is feasible for the functions which are in FieldTrip, it is very difficult to realize for lab-specific scripts. In this particular example I think that clarity of the data representation should prevail over backward compatibility issues, particularly because in this case there's an easy workaround: just call ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data representation is a prerequisite for further developing the software, and keeping the historical 'oddity' will only hamper code development. > Furthermore, it's a bit strange to have a function called > ft_timelockgrandaverage which doesn't compute any grandaverage in > some cases ! I agree, yet see my point above. Some people may just like to have the data represented in a single matrix. > > I would suggest to keep the function as it is but add more options > (such as cfg.dimord = 'avg' or 'individual') to make the > experimenter aware of this issue and to solve further computation > problem. I hope I could convince you that our philosophy makes sense and that you and your lab-mates are willing to make the effort of adjusting the scripts a bit for future analyses. If very problematic, I would advice for the current analyses to rely on an old version of ft_timelockgrandaverage. Best wishes, Jan-Mathijs > Thank you again, > > Lucie > > PS : I've sent this email only to you as this is just a suggestion > which might not be relevant for all users. > > > 2011/2/10 jan-mathijs schoffelen > Dear Lucie, > > Yes, indeed this has recently been changed. The logic behind it is > the following: > > One either typically wants to keep the individuals, OR the average. > > If in your case you need the average, you have to specify > cfg.keepindividual = 'no'; > > Keeping both the average and the individual leads to an inconsistent > definition of the data structure. > The field 'dimord' does not allow for an unequivocal interpretation > of both indidual and avg are present. > > If you need both the individual, and the avg, you now need to run > ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', > and once with cfg.keepindividual = 'no'; > > Best wishes, > > Jan-Mathijs > > > On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: > >> Hello everyone, >> >> It seems that there has been a modification of >> ft_timelockgrandaverage : now if you specify cfg.keepindividual = >> 'yes', the grandaverage is computed but is not included in the >> output of the function (see above). >> >> Why is that ? Many of my scripts rely on this option and I wanted >> to know if there was a good reason for it. >> >> Thanks, >> >> Lucie >> >> New version of ft_timelockgrandaverage (downloaded yesterday), line >> 159-176 >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> grandavg = []; >> grandavg.label = cfg.channel; % cell-array >> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.dimord = 'chan_time'; >> end >> >> Older version of ft_timelockgrandaverage (april 2010) >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> %SWITCH CHANNEL TO LABEL? >> grandavg.label = cfg.channel; % cell-array >> grandavg.fsample = varargin{1}.fsample; >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.dimord = 'chan_time'; >> end >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> Bât 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucie.charles.ens at googlemail.com Thu Feb 10 14:03:30 2011 From: lucie.charles.ens at googlemail.com (Lucie Charles) Date: Thu, 10 Feb 2011 14:03:30 +0100 Subject: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage cfg.keepindividual In-Reply-To: References: Message-ID: Thank you very much for this very detailed response. I didn't know (or forgot) that ft_timelockstatistics could take several data sets as an input (I thought we always needed the big data matrix with all the subjects). That makes much more sense to remove the option in this context. Thanks again, Lucie 2011/2/10 jan-mathijs schoffelen > Dear Lucie, > > Thank you very much for your feedback. I take the liberty to anyhow post > this to the discussion list, so that other people may take notice / join in > the discussion / etc. > > Thanks a lot for this quick response : I understand the logic behind this. > It's true that I noticed some inconsistencies due to the interpretation of > the field dimord which can't be well defined if you have both individual and > average data in your structure. > > > OK > > However, I think many people were happy with this option as it was. It's > quite handy to keep both the average and individual data because you can > compute statistics and at the same time you don't have to redo the average > every time. I think a lot of scripts rely on that at least in our lab. > > > The historical purpose for supporting cfg.keepindividual = 'yes', was in > order to get a representation of all single subjects' data in a single data > matrix: data.individual. Nowadays, ft_timelockstatistics supports multiple > data structures in the input, i.e. ft_timelockstatistics(cfg, subj1, subj2 > subj3, etc) so I think the call to ft_timelockgrandaverage could even be > bypassed. > The FieldTrip development team is very keen on providing backward > compatibility support. While in general this is feasible for the functions > which are in FieldTrip, it is very difficult to realize for lab-specific > scripts. In this particular example I think that clarity of the data > representation should prevail over backward compatibility issues, > particularly because in this case there's an easy workaround: just call > ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data > representation is a prerequisite for further developing the software, and > keeping the historical 'oddity' will only hamper code development. > > Furthermore, it's a bit strange to have a function called > ft_timelockgrandaverage which doesn't compute any grandaverage in some cases > ! > > > I agree, yet see my point above. Some people may just like to have the data > represented in a single matrix. > > > I would suggest to keep the function as it is but add more options (such as > cfg.dimord = 'avg' or 'individual') to make the experimenter aware of this > issue and to solve further computation problem. > > > I hope I could convince you that our philosophy makes sense and that you > and your lab-mates are willing to make the effort of adjusting the scripts a > bit for future analyses. If very problematic, I would advice for the current > analyses to rely on an old version of ft_timelockgrandaverage. > > Best wishes, > > Jan-Mathijs > > > > Thank you again, > > Lucie > > PS : I've sent this email only to you as this is just a suggestion which > might not be relevant for all users. > > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Yes, indeed this has recently been changed. The logic behind it is the >> following: >> >> One either typically wants to keep the individuals, OR the average. >> >> If in your case you need the average, you have to specify >> cfg.keepindividual = 'no'; >> >> Keeping both the average and the individual leads to an inconsistent >> definition of the data structure. >> The field 'dimord' does not allow for an unequivocal interpretation of >> both indidual and avg are present. >> >> If you need both the individual, and the avg, you now need to run >> ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', and once >> with cfg.keepindividual = 'no'; >> >> Best wishes, >> >> Jan-Mathijs >> >> >> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >> >> Hello everyone, >> >> It seems that there has been a modification of ft_timelockgrandaverage : >> now if you specify cfg.keepindividual = 'yes', the grandaverage is computed >> but is not included in the output of the function (see above). >> >> Why is that ? Many of my scripts rely on this option and I wanted to know >> if there was a good reason for it. >> >> Thanks, >> >> Lucie >> >> New version of ft_timelockgrandaverage (downloaded yesterday), line >> 159-176 >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> grandavg = []; >> grandavg.label = cfg.channel; % cell-array >> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time';* >> else >> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.dimord = 'chan_time'; >> end >> >> Older version of ft_timelockgrandaverage (april 2010) >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> %SWITCH CHANNEL TO LABEL? >> grandavg.label = cfg.channel; % cell-array >> grandavg.fsample = varargin{1}.fsample; >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.dimord = 'chan_time'; >> end >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> Bât 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Lucie CHARLES INSERM-CEA Cognitive Neuroimaging unit CEA/SAC/DSV/DRM/NeuroSpin Bât 145, Point Courrier 156 F-91191 Gif/Yvette, FRANCE Tel : +33 1 69 08 99 74 Fax : +33 1 69 08 79 73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gregor.Volberg at psychologie.uni-regensburg.de Fri Feb 11 09:46:51 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Fri, 11 Feb 2011 09:46:51 +0100 Subject: [FieldTrip] WPLI weighted phase-locking index: available in fieldtrip? Message-ID: <4D55058B020000570000882D@gwsmtp1.uni-regensburg.de> Dear fieldtrip developers, I was just reading the pre-print of an upcoming article in Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved index of phase-synchronization...". As I understand, the proposed phase-locking index WPLI is not complicated by volume conduction, and an unbiased version of the WPLI can be computed that is not affected by trial number. This would be exactely what I need for the analysis of data from a spatial cueing paradigm. In the last paragraph, it is announced that the WPLI is made available in the fieldtrip toolbox. However, I did not yet find it (i was searching for it as an option in ft_connectivityanalysis, last Friday's fieldtrip version). May I ask whether it is planned to include WPLI / debiased WPLI into that function? Or was it perhaps intended to be computed by hand from the cross-spectrum. Thanks a lot, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From gauthierb.ens at gmail.com Fri Feb 11 10:46:13 2011 From: gauthierb.ens at gmail.com (Baptiste Gauthier) Date: Fri, 11 Feb 2011 10:46:13 +0100 Subject: [FieldTrip] bug in ft_componentanalysis Message-ID: Dear Fieldtrip users, I noticed a little error in ft_componentanalysis since your latest update (2011/02/09) : While using the function, I got this error message : "??? Error using ==> toc You must call TIC without an output argument before calling TOC without an input argument. Error in ==> ft_componentanalysis at 465 fprintf('total time in componentanalysis %.1f seconds\n', stopwatch(toc)); Error in ==> temprod_NEW_runicaonspectra at 37 comp = ft_componentanalysis(cfg,data);" It seems there's here a bad use of function toc.m It should be : "fprintf('total time in componentanalysis %.1f seconds\n', toc(stopwatch));" I tried it and it worked fine. Please let me know if I'm wrong. Cheers, Baptiste gauthier -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.micheli at fcdonders.ru.nl Fri Feb 11 11:43:39 2011 From: c.micheli at fcdonders.ru.nl (Micheli, C.) Date: Fri, 11 Feb 2011 11:43:39 +0100 (CET) Subject: [FieldTrip] bug in ft_componentanalysis In-Reply-To: Message-ID: <1133664698.83738.1297421019941.JavaMail.root@draco.zimbra.ru.nl> Hi Baptiste You are totally right. The bug has been corrected and you can find the new version by downloading the latest FieldTrip . Cheers, Cristiano ----- "Baptiste Gauthier" schreef: > Van: "Baptiste Gauthier" > Aan: fieldtrip at donders.ru.nl > Verzonden: Vrijdag 11 februari 2011 10:46:13 > Onderwerp: [FieldTrip] bug in ft_componentanalysis > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest update (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC without an input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch(toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds\n', toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > _______________________________________________ > 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 E.vandenBroeke at anes.umcn.nl Fri Feb 11 11:52:57 2011 From: E.vandenBroeke at anes.umcn.nl (E.vandenBroeke at anes.umcn.nl) Date: Fri, 11 Feb 2011 11:52:57 +0100 Subject: [FieldTrip] One or two sided testing? Message-ID: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> Dear dr. Maris, Bovenkant formulier Onderkant formulier I notice that there are many different views among scientists about the use of one or two sided tests. Most people say that you always have to test 2-sided. But is there a rationale for this? When is it appropriate and allowed to test one-sided? Perhaps you can shed light on this topic, by giving your point of view or perhaps you can recommend literature that provides insight on this debate? Thank you, Best Emanuel Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629. The Radboud University Nijmegen Medical Centre is listed in the Commercial Register of the Chamber of Commerce under file number 41055629. -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Fri Feb 11 15:01:01 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Fri, 11 Feb 2011 15:01:01 +0100 Subject: [FieldTrip] One or two sided testing? In-Reply-To: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> References: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> Message-ID: <006301cbc9f4$20d75fe0$62861fa0$@maris@donders.ru.nl> Dear Emanuel, I notice that there are many different views among scientists about the use of one or two sided tests. Most people say that you always have to test 2-sided. But is there a rationale for this? When is it appropriate and allowed to test one-sided? Perhaps you can shed light on this topic, by giving your point of view or perhaps you can recommend literature that provides insight on this debate? If you have prior information that an effect will occur only on one side, or if you are only interested in an effect at one side, then you should test one-sided. Otherwise, you should test two-sided. Best, Eric Thank you, Best Emanuel Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629. The Radboud University Nijmegen Medical Centre is listed in the Commercial Register of the Chamber of Commerce under file number 41055629. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gramfort at nmr.mgh.harvard.edu Fri Feb 11 17:27:50 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Fri, 11 Feb 2011 11:27:50 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> Message-ID: Hi, the pb should be fixed now on: https://github.com/mne-tools/mne-matlab scott confirmed it works for his needs. FYI the files are always closed now and reopened when necessary. Alex On Wed, Feb 9, 2011 at 4:33 PM, Laurence Hunt wrote: > Thanks Alex - I guess it might also be useful to add to the mne code instead, as long as it doesn't cause any problems elsewhere for other users...? Thinking about it, I reckon it would work if you used the same solution you suggested previously on your website, but just added > > data.pos = ftell(data.fid); %before running fclose in fiff_setup_read_raw > > and > > fseek(raw.fid,raw.pos); %after re-opening the file in fiff_read_raw_segment > > (...followed by an fclose of raw.fid at the end of fiff_read_raw_segment, of course). > > If you did this, it would save us making any changes in fieldtrip at all :) > > Laurence > > =========================================== > Laurence Hunt, DPhil Student >  Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > > On 9 Feb 2011, at 21:17, Alexandre Gramfort wrote: > >> again if something needs to be changed in the mne matlab code >> I'd be happy to help. >> >> Alex >> >> On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: >>> I think it should be possible to do it this way - when I tested it, it seemed to work OK. >>> >>> On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: >>> >>>> If, however, it is sufficient to store in the header a >>>> single number which can then be used to find the data onset and from >>>> there to find where to start reading (so perhaps not an fid but just >>>> the data offset in bytes to do fseek), that'd be a perfectly good >>>> solution and fast as well. But I don't know enough about  fif format >>>> to say if it's possible. >>> >>> =========================================== >>> Laurence Hunt, DPhil Student >>>  Centre for Functional MRI of the Brain (FMRIB), >>> University of Oxford >>> lhunt at fmrib.ox.ac.uk >>> Phone: (+44)1865-(2)22738 >>> =========================================== >>> _______________________________________________ >>> 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 > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in error > but does not contain patient information, please contact the sender and properly > dispose of the e-mail. > > From andreas.wilmer at uni-muenster.de Fri Feb 11 17:57:36 2011 From: andreas.wilmer at uni-muenster.de (Andreas Wilmer) Date: Fri, 11 Feb 2011 17:57:36 +0100 Subject: [FieldTrip] trial-based time-series via lcmv beamforming? Message-ID: dear fieldtrip-users, actually my first active post in the fieldtrip newsgroup. first i'd like to thank the community and especially the developers of fieldtrip for their great support&help! i am interested in a trial-based(!) time-domain data-set in the source space of MEG data for further connectivity analysis. i decided to use a beamformer (lcmv) to recover the neuronal activity by using snythetic data-sets (for testing and verification). the synthetic data- set consists of 3 correlated sources with up to 300 trials and a length of 720 datapoints (=1.2s at 600Hz) and many trials of uncorrelated noisy sources. i implemented the dipole simulation in the following way: 1) i used customized data with time dependent (time-delayed) phase correlations as source waveforms and added randomly located uncorrelated dipoles as disturbances and spontaneous brain processes. next, i simulated the data in sensor-space and did an lcmv beamforming -> works fine (a priori known connectivity can be recovered). 2) in the next step i repeated the simulation and added 10% rms as additive (delta-correlated) measurement noise to the data in the sensor-space to model thermal noise. -> in this case the beamformer reconstruction fails totally... 3) i averaged the data in sensor-space to get rid of the thermal noise and used the cov to recover every single trial, but in this case the beamformer cannot deal with brain-noise... -> this didn't work either.. MY QUESTION IS: is this a conceptual problem of beamforming, that one cannot recover a trial-based time-series or did i commit a crude error in reasoning/programming? do you think a bootstrapping for calculating the cov might make sense, i.e. i could calculate the cov for each trial by averaging over just a few trials (eg 10 randomly chosen trials) to reduce the uncorrelated noise in sensor space without loosing all the information to suppress the brain-noise? which other inverse methods can recover source activity in time-domain on trial level? eg MNE seems only to work on average over trials? so many questions.. thank you in advance for your help! with best wishes, andreas __________________________________ Dipl.-Phys. Andreas Wilmer Institut für Allgemeine Psychologie Westfälische Wilhelms-Universität Münster AE Prof. Dr. Markus Lappe Fliednerstraße 21 D 48149 Münster fon: +49 (251) 83 34175 email: andreas.wilmer at uni-muenster.de my code on beamforming two further remarks: a) i didn't apply a normalization of the virtual channels because i am interested in phase measures - normalizing the amplitudes won't have any effect on the results b) narrow band filtering didn't work with my (broad band) data %----------------------------------------------------------------- %estimating filter/cov cfg = []; cfg.channel = {'MEG'}; cfg.keeptrials = 'yes'; cfg.bpfrq = [1 150]; cfg.covariance = 'yes'; %trial/stimulus window cfg.covariancewindow = [0 1.2]; %complete data dataCov = ft_timelockanalysis(cfg,dataSensor); %----------------------------------------------------------------- %beamforming cfg = []; cfg.method = 'lcmv'; cfg.lcmv.fixedori = 'yes'; cfg.vol = dataHead; cfg.grid.pos = gridposition; cfg.lambda = '5%'; cfg.projectnoise = 'yes'; cfg.keepfilter = 'yes'; cfg.keeptrials = 'yes'; [dataVc] = ft_sourceanalysis(cfg,dataCov); %--------------------------------------------------------------- %reconstructing source data trialN = size(dataSensor.trial,2); [sensN tN] = size(dataSensor.trial{1}); srcN = length(dataVc.inside); for i=1:srcN, m = dataVc.inside(i); if ~isempty(dataVc.avg.filter{m}), fprintf('beamforming source %d/%d\n',i,srcN); %beamforming for j = 1:trialN, dataVc.trial(j).mom{m} =... dataVc.avg.filter{m}*dataSensor.trial{j}; end end end -------------- next part -------------- An HTML attachment was scrubbed... URL: From ting.ac at gmail.com Fri Feb 11 22:19:33 2011 From: ting.ac at gmail.com (Allison Connolly) Date: Fri, 11 Feb 2011 15:19:33 -0600 Subject: [FieldTrip] problem aligning MRI with gradiometer Message-ID: Hello, I am trying to perform beamforming on some MEG data (148 channels). I have the dicom files for the MRI, and I have converted them to .img and .hdr files using Curry. I am importing them into fieldtrip via mri=ft_read_mri('MRI.img'). Then I manually declaring the fiducials with cfg.method = 'interactive'; mrialign = ft_volumerealign(cfg, mri); Then segmenting with cfg = []; cfg.write = 'no'; [segment] = ft_volumesegment(cfg, mri); Then creating the head model with cfg = []; cfg.smooth = 'no'; vol = ft_prepare_singleshell(cfg, segment); Then creating the grid with cfg = []; cfg.grad = freq.grad; cfg.vol = vol; cfg.reducerank = 'no'; cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol [grid] = ft_prepare_leadfield(cfg); I am importing my MEG data with cfg = []; % empty configuration cfg.dataset = 'C:/MEG Study/Subjectd001/d001/Billy_180s/06@ -09 at -10@_19_41/4/c,rfhp0.1Hz'; cfg.trialfun = 'trialfun_general'; cfg.trialdef.triallength = 2; % duration in seconds cfg.trialdef.ntrials = inf; % number of trials, inf results in as many as possible cfg = ft_definetrial(cfg); % preprocess the data cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; %read all MEG channels except those with '-' cfg.lpfilter = 'yes'; cfg.lpfreq = 200; cfg.bsfilter = 'yes'; %60 Hz noise cfg.bsfreq = [58 62]; data = ft_preprocessing(cfg); In the end, when I go to plot them all on the same graph, the head model seems to be 100 times larger than the gradiometer sensors (they appear as a small ball in the middle of the head). I've tried adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't help the downstream frequency, leadfield, and source analysis. Can someone tell me how to ensure the gradiometer and mri/grid are on the same scale so I can be sure I have the right model for my beamforming? Thank you, -Allison -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.frei at psy.gla.ac.uk Fri Feb 11 23:02:18 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 11 Feb 2011 22:02:18 +0000 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: References: Message-ID: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Hi Alison, how do you change the units? I convert them using: data.grad=ft_convert_units(data.grad,'cm') Maybe this helps. Luisa On 11 Feb 2011, at 21:19, Allison Connolly wrote: > Hello, > > I am trying to perform beamforming on some MEG data (148 channels). > I have the dicom files for the MRI, and I have converted them > to .img and .hdr files using Curry. > I am importing them into fieldtrip via > mri=ft_read_mri('MRI.img'). > > Then I manually declaring the fiducials with > cfg.method = 'interactive'; > mrialign = ft_volumerealign(cfg, mri); > > Then segmenting with > cfg = []; > cfg.write = 'no'; > [segment] = ft_volumesegment(cfg, mri); > > Then creating the head model with > cfg = []; > cfg.smooth = 'no'; > vol = ft_prepare_singleshell(cfg, segment); > > Then creating the grid with > cfg = []; > cfg.grad = freq.grad; > cfg.vol = vol; > cfg.reducerank = 'no'; > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; > cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol > cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol > cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol > [grid] = ft_prepare_leadfield(cfg); > > I am importing my MEG data with > cfg = []; % empty configuration > cfg.dataset = 'C:/MEG Study/Subjectd001/d001/ > Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.triallength = 2; % duration in seconds > cfg.trialdef.ntrials = inf; % number of trials, inf results > in as many as possible > cfg = ft_definetrial(cfg); > > % preprocess the data > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','- > E4'}; %read all MEG channels except those with '-' > cfg.lpfilter = 'yes'; > cfg.lpfreq = 200; > cfg.bsfilter = 'yes'; %60 Hz noise > cfg.bsfreq = [58 62]; > > data = ft_preprocessing(cfg); > > In the end, when I go to plot them all on the same graph, the head > model seems to be 100 times larger than the gradiometer sensors > (they appear as a small ball in the middle of the head). I've tried > adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't > help the downstream frequency, leadfield, and source analysis. > > Can someone tell me how to ensure the gradiometer and mri/grid are > on the same scale so I can be sure I have the right model for my > beamforming? > > Thank you, > -Allison > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From ting.ac at gmail.com Fri Feb 11 23:25:24 2011 From: ting.ac at gmail.com (Allison Connolly) Date: Fri, 11 Feb 2011 16:25:24 -0600 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> References: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Message-ID: Thanks that seemed to help the scaling issue. However, my beamforming is still not producing results. There is a huge bias towards the center of the head, even though I accounted for the neural activity index. It seems like the beamforming is just projecting everything inwards. I'm not sure where to go from here. Do you have any suggestions on different configuration settings I could try for the beamforming? -Allison On Fri, Feb 11, 2011 at 4:02 PM, Luisa Frei wrote: > Hi Alison, > how do you change the units? I convert them using: > > data.grad=ft_convert_units(data.grad,'cm') > > Maybe this helps. > > Luisa > > > On 11 Feb 2011, at 21:19, Allison Connolly wrote: > > Hello, >> >> I am trying to perform beamforming on some MEG data (148 channels). I have >> the dicom files for the MRI, and I have converted them to .img and .hdr >> files using Curry. >> I am importing them into fieldtrip via >> mri=ft_read_mri('MRI.img'). >> >> Then I manually declaring the fiducials with >> cfg.method = 'interactive'; >> mrialign = ft_volumerealign(cfg, mri); >> >> Then segmenting with >> cfg = []; >> cfg.write = 'no'; >> [segment] = ft_volumesegment(cfg, mri); >> >> Then creating the head model with >> cfg = []; >> cfg.smooth = 'no'; >> vol = ft_prepare_singleshell(cfg, segment); >> >> Then creating the grid with >> cfg = []; >> cfg.grad = freq.grad; >> cfg.vol = vol; >> cfg.reducerank = 'no'; >> cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... >> '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... >> '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; >> cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol >> cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol >> cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol >> [grid] = ft_prepare_leadfield(cfg); >> >> I am importing my MEG data with >> cfg = []; % empty configuration >> cfg.dataset = 'C:/MEG >> Study/Subjectd001/d001/Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; >> cfg.trialfun = 'trialfun_general'; >> cfg.trialdef.triallength = 2; % duration in seconds >> cfg.trialdef.ntrials = inf; % number of trials, inf results in as >> many as possible >> cfg = ft_definetrial(cfg); >> >> % preprocess the data >> cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... >> '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... >> '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; %read >> all MEG channels except those with '-' >> cfg.lpfilter = 'yes'; >> cfg.lpfreq = 200; >> cfg.bsfilter = 'yes'; %60 Hz noise >> cfg.bsfreq = [58 62]; >> >> data = ft_preprocessing(cfg); >> >> In the end, when I go to plot them all on the same graph, the head model >> seems to be 100 times larger than the gradiometer sensors (they appear as a >> small ball in the middle of the head). I've tried adjusting the grad.unit >> parameter from 'm' to 'cm', but it doesn't help the downstream frequency, >> leadfield, and source analysis. >> >> Can someone tell me how to ensure the gradiometer and mri/grid are on the >> same scale so I can be sure I have the right model for my beamforming? >> >> Thank you, >> -Allison >> _______________________________________________ >> 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 l.frei at psy.gla.ac.uk Sat Feb 12 00:05:15 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 11 Feb 2011 23:05:15 +0000 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: References: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Message-ID: I'm not an expert on beamforming myself. But how clear your results are depends on the preprocessing as well. If your sources are very low in the head, you could have muscle or heartbeat artifacts. I did an ICA to remove the heartbeat component. Sorry I can't give you any more help, someone else can probably help you more. Luisa On 11 Feb 2011, at 22:25, Allison Connolly wrote: > Thanks that seemed to help the scaling issue. However, my > beamforming is still not producing results. There is a huge bias > towards the center of the head, even though I accounted for the > neural activity index. It seems like the beamforming is just > projecting everything inwards. I'm not sure where to go from here. > Do you have any suggestions on different configuration settings I > could try for the beamforming? > > -Allison > > On Fri, Feb 11, 2011 at 4:02 PM, Luisa Frei > wrote: > Hi Alison, > how do you change the units? I convert them using: > > data.grad=ft_convert_units(data.grad,'cm') > > Maybe this helps. > > Luisa > > > On 11 Feb 2011, at 21:19, Allison Connolly wrote: > > Hello, > > I am trying to perform beamforming on some MEG data (148 channels). > I have the dicom files for the MRI, and I have converted them > to .img and .hdr files using Curry. > I am importing them into fieldtrip via > mri=ft_read_mri('MRI.img'). > > Then I manually declaring the fiducials with > cfg.method = 'interactive'; > mrialign = ft_volumerealign(cfg, mri); > > Then segmenting with > cfg = []; > cfg.write = 'no'; > [segment] = ft_volumesegment(cfg, mri); > > Then creating the head model with > cfg = []; > cfg.smooth = 'no'; > vol = ft_prepare_singleshell(cfg, segment); > > Then creating the grid with > cfg = []; > cfg.grad = freq.grad; > cfg.vol = vol; > cfg.reducerank = 'no'; > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; > cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol > cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol > cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol > [grid] = ft_prepare_leadfield(cfg); > > I am importing my MEG data with > cfg = []; % empty configuration > cfg.dataset = 'C:/MEG Study/Subjectd001/d001/ > Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.triallength = 2; % duration in seconds > cfg.trialdef.ntrials = inf; % number of trials, inf results > in as many as possible > cfg = ft_definetrial(cfg); > > % preprocess the data > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','- > E4'}; %read all MEG channels except those with '-' > cfg.lpfilter = 'yes'; > cfg.lpfreq = 200; > cfg.bsfilter = 'yes'; %60 Hz noise > cfg.bsfreq = [58 62]; > > data = ft_preprocessing(cfg); > > In the end, when I go to plot them all on the same graph, the head > model seems to be 100 times larger than the gradiometer sensors > (they appear as a small ball in the middle of the head). I've tried > adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't > help the downstream frequency, leadfield, and source analysis. > > Can someone tell me how to ensure the gradiometer and mri/grid are > on the same scale so I can be sure I have the right model for my > beamforming? > > Thank you, > -Allison > _______________________________________________ > 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 jm.horschig at donders.ru.nl Mon Feb 14 16:18:36 2011 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Mon, 14 Feb 2011 16:18:36 +0100 Subject: [FieldTrip] Single Precision in FieldTrip (2011) Message-ID: <4D5947CC.3010608@donders.ru.nl> Dear all, This mail can be considered as a follow-up from an issue raised back in 2006 - just a little bit more recent (btw, there maybe should a more user-friendly interface to search in the FT mailing archive, it took some time to check if this question has been brought up before). Today, I was thinking about ways to reduce the memory use of FieldTrip/Matlab especially when handling large amount of data - other ways than using machines with huge memory capacities. In the old mailing list, I found a mail conversation started by Ali M. about single precision in 2006. Matlab, and FieldTrip, has advanced quite a lot since then, which resulted in removing at least that one particular Matlab-bug on my machine ;) However, in the past I have found that computations using single precision still yields problems such as wrong results or also incompatibilty of certain functions/operations. I wonder how severe these problems are with current Matlab/FieldTrip versions. Does anyone have experience with single precision computations using FieldTrip? Is it valid or even advisable to use single precision calculations? FYI, my machine runs Win7 64-bit and Matlab 7.9.0.529 (R2009b) Kind regards, Jörn -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen 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/fcdonders Visiting address: Trigon, room 2.30 Kapitelweg 29 NL-6525 EN Nijmegen The Netherlands From m.k.van.vugt at rug.nl Tue Feb 15 12:33:46 2011 From: m.k.van.vugt at rug.nl (Marieke van Vugt) Date: Tue, 15 Feb 2011 12:33:46 +0100 Subject: [FieldTrip] fully-funded PhD position in cognitive modeling group Rijksuniversiteit Groningen Message-ID: <05BDAE2A-1847-4DF4-8EE2-35155234794F@rug.nl> PhD position Cognitive Modeling group (1,0 fte) (211047) Organisation We invite applications for a four-year PhD student position available in the Cognitive Modeling group, in the laboratory of Marieke van Vugt (http://www.ai.rug.nl/~mkvanvugt/index_lab.html). The Cognitive Modeling group forms part of the ALICE research institute within the Department of Artificial Intelligence. It has a world-class reputation in cognitive modeling, largely based on the ACT-R architecture. The laboratory of Marieke van Vugt focuses on the neural correlates of decision making based on remembered information, combining modeling, behavioral experiments and EEG/fMRI. Job description The PhD project focuses on relating computational models of decision making based on remembered information to EEG and fMRI data. The drift diffusion model of memory and decision making makes explicit predictions of the dynamics of evidence accumulation, and these predictions will be examined in neural data. The project will bridge the domains of perceptual decision making and recognition memory. Specific focus will be placed on how different brain areas interact to implement this evidence accumulation process and adjust performance on a trial-to-trial basis. The participant will engage in advanced data analysis of existing EEG data sets, and collect new EEG and fMRI data. Qualifications A successful candidate has a Master's degree in Cognitive Neuroscience, Cognitive Science, Experimental Psychology, Artificial Intelligence or a related field, and has programming skills in Matlab, C, or Python. Experience in running EEG and/or fMRI experiments, or in modeling of cognition, is an advantage. Conditions of employment The University of Groningen offers a salary of 2,042 gross per month in the first year up to a maximum of 2,612 gross per month in the final year. The appointment is for a period of four years, which should be finished with a PhD examination. The full time appointment is temporary for 1.5 years with the perspective of prolongation for another 2.5 years. After the first year, there will be an evaluation of the feasibility of successful completion of the PhD thesis within the next three years. A training programme within the Graduate School of Science is part of the agreement. You and your supervisor will make up a plan for additional education and supervising that is specific to your needs. How to apply: Send a cover letter (with professional goals and a statement of interest), a curriculum vitae and two letters of recommendation (PDF format) to the job application portal (http://www.tangram-tis.nl/10378/Kandidaten/Inschrijven/00347-0000004562) before April 1st, 2011, although applications received after the deadline may be considered. Starting date: as soon as possible. Information For information you can contact: Dr Marieke van Vugt, m.k.van.vugt at rug.nl ALICE ---------------------------------------------------------------------------- Marieke van Vugt, PhD Assistant Professor, Cognitive Modeling Group Bernoulliborg, room 326 Nijenborgh 9 9747 AG Groningen The Netherlands phone: +31-6-51954984 (cell) +31-50-363-9487 (office) http://www.ai.rug.nl/~mkvanvugt m.k.van.vugt at rug.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.carmeli at gmail.com Tue Feb 15 16:32:39 2011 From: cristian.carmeli at gmail.com (Cristian Carmeli) Date: Tue, 15 Feb 2011 16:32:39 +0100 Subject: [FieldTrip] problem with ft_read_mri Message-ID: Dear FieldTrip users I would like to create a mesh from the MNI brain and when I start running the following command >> mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); I get this error message ??? Error using ==> spm_platform>init_platform at 173 MACI64 not supported architecture for SPM Do you know how to fix that? Or is there any mri structure already available to download somewhere? For complete information, I am using Matlab 7.11 on MacOs 10.6.6 thank you for your help best Cristian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanweisz at mac.com Tue Feb 15 16:42:56 2011 From: nathanweisz at mac.com (Nathan Weisz) Date: Tue, 15 Feb 2011 16:42:56 +0100 Subject: [FieldTrip] problem with ft_read_mri In-Reply-To: References: Message-ID: under template/ you'll find a single_subj_T1.mat. looks like what you are looking for (already segmented). good luck, n On 15.02.2011, at 16:32, Cristian Carmeli wrote: > Dear FieldTrip users > > I would like to create a mesh from the MNI brain and when I start running the following command > > >> mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); > > I get this error message > ??? Error using ==> spm_platform>init_platform at 173 > MACI64 not supported architecture for SPM > > Do you know how to fix that? Or is there any mri structure already available to download somewhere? > For complete information, I am using Matlab 7.11 on MacOs 10.6.6 > > thank you for your help > > best > Cristian > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From Gregor.Volberg at psychologie.uni-regensburg.de Tue Feb 15 17:16:57 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Tue, 15 Feb 2011 17:16:57 +0100 Subject: [FieldTrip] Artifacts on plotting grand-averaged BEMs: Normalization issue? Message-ID: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> Dear list members, I encountered a problem when plotting the results of a beamformer analysis with individual BEM headmodels. For each subject, I did an ft_sourceanalysis (DICS) and then interpolated the individual volume on the individual anatomy with ft_sourceinterpolate. The result was normalised onto the SPM8 template brain with ft_volumenormalise; then I computed the grand average with ft_sourcegrandaverage. When I plot the grand average (with cfg.funparameter = 'pow'), I see nice results at expected brain regions, but also artifacts around the outline of the volume - see my attached Figure "source_power.png". It appears as if normalization was imperfect so that a border remains, possibly showing idiosyncratic activations from single subjects. The border does not show up if, with the same data, I do ft_sourcestatistics and then plot the results with cfg.funparameter = 'stat' (see attached "source_stat.png"). One might expect this if the voxels showed activation of only one subject so that a t-test would return NANs. I then had a look into the "*.inside" fields of the normalized volumes and was surprised to see that number of voxels inside the brain was different for each subject (ranging between 23 and 27 % roughly). Should that not be the same number of voxels for each subject after normalization? I am now unsure whether the border is a known behavior when plottig the grand average over individual heads,or whether I made an error with normalization. I would be very happy if any someone had an advice for me. Many thanks and best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_power.png Type: image/png Size: 38081 bytes Desc: Portable Network Graphics Format URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_stat.png Type: image/png Size: 31701 bytes Desc: Portable Network Graphics Format URL: From datashare at sciencedb.net Tue Feb 15 23:01:48 2011 From: datashare at sciencedb.net (datashare at sciencedb.net) Date: Tue, 15 Feb 2011 23:01:48 +0100 (CET) Subject: [FieldTrip] Announcement : Neuroscience positions database In-Reply-To: References: Message-ID: Dear Fieldtrip users, * Apologies if you receive this multiple times * We would like to inform you about new forum for neuroscience job announcements: http://sciencedb.net/groups/neuroscience-positions-announcements/forum/ We hope you can use this forum to post announcements from post-doc positions and faculty positions to PhD. projects and internship projects. If you only want to follow the announcement; sign up for a free newswletter: http://feedburner.google.com/fb/a/mailverify?uri=ScienceDbNeurosciencePositions-Announcements&loc=en_US Kind regards, Sciencedb.net PS. Follow us on twitter http://twitter.com/sciencedb or sign-up for our newsletter: http://feedburner.google.com/fb/a/mailverify?uri=ScienceDb --- ScienceDB.net is a non-profit portal for the scientific community. Our service is sponsored by ads and donations. If you have any suggestions or comments, please mail us at sciencedb at sciencedb.net. From Gregor.Volberg at psychologie.uni-regensburg.de Wed Feb 16 11:52:43 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Wed, 16 Feb 2011 11:52:43 +0100 Subject: [FieldTrip] UPDATE: Artifacts on plotting grand-averaged BEMs: Normalization issue? In-Reply-To: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> References: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> Message-ID: <4D5BBA8B02000057000088F0@gwsmtp1.uni-regensburg.de> Dear list members, I think I fixed the problem described in my last mail. I manually averaged the avg.pow fields of the single subjects and put the average on the corresponding field of the grandaverage-structure. This worked fine, without artifactual borders at the outline of the brain compartement. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> "Gregor Volberg" 2/15/2011 5:16 PM >>> Dear list members, I encountered a problem when plotting the results of a beamformer analysis with individual BEM headmodels. For each subject, I did an ft_sourceanalysis (DICS) and then interpolated the individual volume on the individual anatomy with ft_sourceinterpolate. The result was normalised onto the SPM8 template brain with ft_volumenormalise; then I computed the grand average with ft_sourcegrandaverage. When I plot the grand average (with cfg.funparameter = 'pow'), I see nice results at expected brain regions, but also artifacts around the outline of the volume - see my attached Figure "source_power.png". It appears as if normalization was imperfect so that a border remains, possibly showing idiosyncratic activations from single subjects. The border does not show up if, with the same data, I do ft_sourcestatistics and then plot the results with cfg.funparameter = 'stat' (see attached "source_stat.png"). One might expect this if the voxels showed activation of only one subject so that a t-test would return NANs. I then had a look into the "*.inside" fields of the normalized volumes and was surprised to see that number of voxels inside the brain was different for each subject (ranging between 23 and 27 % roughly). Should that not be the same number of voxels for each subject after normalization? I am now unsure whether the border is a known behavior when plottig the grand average over individual heads,or whether I made an error with normalization. I would be very happy if any someone had an advice for me. Many thanks and best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinvinck at gmail.com Thu Feb 17 09:43:41 2011 From: martinvinck at gmail.com (Martin Vinck) Date: Thu, 17 Feb 2011 09:43:41 +0100 Subject: [FieldTrip] WPLI weighted phase-locking index: available in fieldtrip? (Gregor Volberg) In-Reply-To: References: Message-ID: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> Dear Gregor, Thank you for your interest. Please find, in the latest release, the WPLI functionality in ft_connectivityanalysis. Best regards, Martin Vinck. On Feb 11, 2011, at 10:46 AM, fieldtrip-request at donders.ru.nl wrote: > Send fieldtrip mailing list submissions to > fieldtrip at donders.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 donders.ru.nl > > You can reach the person managing the list at > fieldtrip-owner at donders.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: Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual (Lucie Charles) > 2. WPLI weighted phase-locking index: available in fieldtrip? > (Gregor Volberg) > 3. bug in ft_componentanalysis (Baptiste Gauthier) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Feb 2011 14:03:30 +0100 > From: Lucie Charles > To: Email discussion list for the FieldTrip project > > Subject: Re: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Thank you very much for this very detailed response. > > I didn't know (or forgot) that ft_timelockstatistics could take > several data > sets as an input (I thought we always needed the big data matrix > with all > the subjects). That makes much more sense to remove the option in this > context. > > Thanks again, > > Lucie > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Thank you very much for your feedback. I take the liberty to anyhow >> post >> this to the discussion list, so that other people may take notice / >> join in >> the discussion / etc. >> >> Thanks a lot for this quick response : I understand the logic >> behind this. >> It's true that I noticed some inconsistencies due to the >> interpretation of >> the field dimord which can't be well defined if you have both >> individual and >> average data in your structure. >> >> >> OK >> >> However, I think many people were happy with this option as it was. >> It's >> quite handy to keep both the average and individual data because >> you can >> compute statistics and at the same time you don't have to redo the >> average >> every time. I think a lot of scripts rely on that at least in our >> lab. >> >> >> The historical purpose for supporting cfg.keepindividual = 'yes', >> was in >> order to get a representation of all single subjects' data in a >> single data >> matrix: data.individual. Nowadays, ft_timelockstatistics supports >> multiple >> data structures in the input, i.e. ft_timelockstatistics(cfg, >> subj1, subj2 >> subj3, etc) so I think the call to ft_timelockgrandaverage could >> even be >> bypassed. >> The FieldTrip development team is very keen on providing backward >> compatibility support. While in general this is feasible for the >> functions >> which are in FieldTrip, it is very difficult to realize for lab- >> specific >> scripts. In this particular example I think that clarity of the data >> representation should prevail over backward compatibility issues, >> particularly because in this case there's an easy workaround: just >> call >> ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data >> representation is a prerequisite for further developing the >> software, and >> keeping the historical 'oddity' will only hamper code development. >> >> Furthermore, it's a bit strange to have a function called >> ft_timelockgrandaverage which doesn't compute any grandaverage in >> some cases >> ! >> >> >> I agree, yet see my point above. Some people may just like to have >> the data >> represented in a single matrix. >> >> >> I would suggest to keep the function as it is but add more options >> (such as >> cfg.dimord = 'avg' or 'individual') to make the experimenter aware >> of this >> issue and to solve further computation problem. >> >> >> I hope I could convince you that our philosophy makes sense and >> that you >> and your lab-mates are willing to make the effort of adjusting the >> scripts a >> bit for future analyses. If very problematic, I would advice for >> the current >> analyses to rely on an old version of ft_timelockgrandaverage. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> Thank you again, >> >> Lucie >> >> PS : I've sent this email only to you as this is just a suggestion >> which >> might not be relevant for all users. >> >> >> 2011/2/10 jan-mathijs schoffelen >> >>> Dear Lucie, >>> >>> Yes, indeed this has recently been changed. The logic behind it is >>> the >>> following: >>> >>> One either typically wants to keep the individuals, OR the average. >>> >>> If in your case you need the average, you have to specify >>> cfg.keepindividual = 'no'; >>> >>> Keeping both the average and the individual leads to an inconsistent >>> definition of the data structure. >>> The field 'dimord' does not allow for an unequivocal >>> interpretation of >>> both indidual and avg are present. >>> >>> If you need both the individual, and the avg, you now need to run >>> ft_timelockgrandaverage twice, once with cfg.keepinididual = >>> 'yes', and once >>> with cfg.keepindividual = 'no'; >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >>> >>> Hello everyone, >>> >>> It seems that there has been a modification of >>> ft_timelockgrandaverage : >>> now if you specify cfg.keepindividual = 'yes', the grandaverage is >>> computed >>> but is not included in the output of the function (see above). >>> >>> Why is that ? Many of my scripts rely on this option and I wanted >>> to know >>> if there was a good reason for it. >>> >>> Thanks, >>> >>> Lucie >>> >>> New version of ft_timelockgrandaverage (downloaded yesterday), line >>> 159-176 >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> grandavg = []; >>> grandavg.label = cfg.channel; % cell-array >>> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time';* >>> else >>> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> Older version of ft_timelockgrandaverage (april 2010) >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> %SWITCH CHANNEL TO LABEL? >>> grandavg.label = cfg.channel; % cell-array >>> grandavg.fsample = varargin{1}.fsample; >>> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time'; >>> else >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> >>> -- >>> Lucie CHARLES >>> >>> INSERM-CEA Cognitive Neuroimaging unit >>> >>> CEA/SAC/DSV/DRM/NeuroSpin >>> B?t 145, Point Courrier 156 >>> F-91191 Gif/Yvette, FRANCE >>> Tel : +33 1 69 08 99 74 >>> Fax : +33 1 69 08 79 73 >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> B?t 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > B?t 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 09:46:51 +0100 > From: "Gregor Volberg" > To: "FieldTrip List" > Subject: [FieldTrip] WPLI weighted phase-locking index: available in > fieldtrip? > Message-ID: <4D55058B020000570000882D at gwsmtp1.uni-regensburg.de> > Content-Type: text/plain; charset="us-ascii" > > > Dear fieldtrip developers, > > I was just reading the pre-print of an upcoming article in > Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved > index of phase-synchronization...". As I understand, the proposed > phase-locking index WPLI is not complicated by volume conduction, > and an unbiased version of the WPLI can be computed that is not > affected by trial number. This would be exactely what I need for the > analysis of data from a spatial cueing paradigm. > > In the last paragraph, it is announced that the WPLI is made > available in the fieldtrip toolbox. However, I did not yet find it > (i was searching for it as an option in ft_connectivityanalysis, > last Friday's fieldtrip version). May I ask whether it is planned to > include WPLI / debiased WPLI into that function? Or was it perhaps > intended to be computed by hand from the cross-spectrum. > > Thanks a lot, > Gregor > -- > Dr. rer. nat. Gregor Volberg > ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) > University of Regensburg > Institute for Experimental Psychology > 93040 Regensburg, Germany > Tel: +49 941 943 3862 > Fax: +49 941 943 3233 > http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Feb 2011 10:46:13 +0100 > From: Baptiste Gauthier > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] bug in ft_componentanalysis > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest > update > (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC > without an > input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch > (toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds > \n', > toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 3, Issue 17 > **************************************** From Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 10:57:37 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 10:57:37 +0100 Subject: [FieldTrip] Antw: Re: WPLI weighted phase-locking index: available in fieldtrip? (Gregor Volberg) In-Reply-To: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> References: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> Message-ID: <4D5CFF21020000570000893A@gwsmtp1.uni-regensburg.de> Dear Martin, thanks a lot for your help! I will try it within the next days. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> Martin Vinck 2/17/2011 9:43 AM >>> Dear Gregor, Thank you for your interest. Please find, in the latest release, the WPLI functionality in ft_connectivityanalysis. Best regards, Martin Vinck. On Feb 11, 2011, at 10:46 AM, fieldtrip-request at donders.ru.nl wrote: > Send fieldtrip mailing list submissions to > fieldtrip at donders.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 donders.ru.nl > > You can reach the person managing the list at > fieldtrip-owner at donders.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: Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual (Lucie Charles) > 2. WPLI weighted phase-locking index: available infieldtrip? > (Gregor Volberg) > 3. bug in ft_componentanalysis (Baptiste Gauthier) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Feb 2011 14:03:30 +0100 > From: Lucie Charles > To: Email discussion list for the FieldTrip project > > Subject: Re: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Thank you very much for this very detailed response. > > I didn't know (or forgot) that ft_timelockstatistics could take > several data > sets as an input (I thought we always needed the big data matrix > with all > the subjects). That makes much more sense to remove the option in this > context. > > Thanks again, > > Lucie > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Thank you very much for your feedback. I take the liberty to anyhow >> post >> this to the discussion list, so that other people may take notice / >> join in >> the discussion / etc. >> >> Thanks a lot for this quick response : I understand the logic >> behind this. >> It's true that I noticed some inconsistencies due to the >> interpretation of >> the field dimord which can't be well defined if you have both >> individual and >> average data in your structure. >> >> >> OK >> >> However, I think many people were happy with this option as it was. >> It's >> quite handy to keep both the average and individual data because >> you can >> compute statistics and at the same time you don't have to redo the >> average >> every time. I think a lot of scripts rely on that at least in our >> lab. >> >> >> The historical purpose for supporting cfg.keepindividual = 'yes', >> was in >> order to get a representation of all single subjects' data in a >> single data >> matrix: data.individual. Nowadays, ft_timelockstatistics supports >> multiple >> data structures in the input, i.e. ft_timelockstatistics(cfg, >> subj1, subj2 >> subj3, etc) so I think the call to ft_timelockgrandaverage could >> even be >> bypassed. >> The FieldTrip development team is very keen on providing backward >> compatibility support. While in general this is feasible for the >> functions >> which are in FieldTrip, it is very difficult to realize for lab- >> specific >> scripts. In this particular example I think that clarity of the data >> representation should prevail over backward compatibility issues, >> particularly because in this case there's an easy workaround: just >> call >> ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data >> representation is a prerequisite for further developing the >> software, and >> keeping the historical 'oddity' will only hamper code development. >> >> Furthermore, it's a bit strange to have a function called >> ft_timelockgrandaverage which doesn't compute any grandaverage in >> some cases >> ! >> >> >> I agree, yet see my point above. Some people may just like to have >> the data >> represented in a single matrix. >> >> >> I would suggest to keep the function as it is but add more options >> (such as >> cfg.dimord = 'avg' or 'individual') to make the experimenter aware >> of this >> issue and to solve further computation problem. >> >> >> I hope I could convince you that our philosophy makes sense and >> that you >> and your lab-mates are willing to make the effort of adjusting the >> scripts a >> bit for future analyses. If very problematic, I would advice for >> the current >> analyses to rely on an old version of ft_timelockgrandaverage. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> Thank you again, >> >> Lucie >> >> PS : I've sent this email only to you as this is just a suggestion >> which >> might not be relevant for all users. >> >> >> 2011/2/10 jan-mathijs schoffelen >> >>> Dear Lucie, >>> >>> Yes, indeed this has recently been changed. The logic behind it is >>> the >>> following: >>> >>> One either typically wants to keep the individuals, OR the average. >>> >>> If in your case you need the average, you have to specify >>> cfg.keepindividual = 'no'; >>> >>> Keeping both the average and the individual leads to an inconsistent >>> definition of the data structure. >>> The field 'dimord' does not allow for an unequivocal >>> interpretation of >>> both indidual and avg are present. >>> >>> If you need both the individual, and the avg, you now need to run >>> ft_timelockgrandaverage twice, once with cfg.keepinididual = >>> 'yes', and once >>> with cfg.keepindividual = 'no'; >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >>> >>> Hello everyone, >>> >>> It seems that there has been a modification of >>> ft_timelockgrandaverage : >>> now if you specify cfg.keepindividual = 'yes', the grandaverage is >>> computed >>> but is not included in the output of the function (see above). >>> >>> Why is that ? Many of my scripts rely on this option and I wanted >>> to know >>> if there was a good reason for it. >>> >>> Thanks, >>> >>> Lucie >>> >>> New version of ft_timelockgrandaverage (downloaded yesterday), line >>> 159-176 >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> grandavg = []; >>> grandavg.label = cfg.channel; % cell-array >>> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time';* >>> else >>> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> Older version of ft_timelockgrandaverage (april 2010) >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> %SWITCH CHANNEL TO LABEL? >>> grandavg.label = cfg.channel; % cell-array >>> grandavg.fsample = varargin{1}.fsample; >>> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time'; >>> else >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> >>> -- >>> Lucie CHARLES >>> >>> INSERM-CEA Cognitive Neuroimaging unit >>> >>> CEA/SAC/DSV/DRM/NeuroSpin >>> B?t 145, Point Courrier 156 >>> F-91191 Gif/Yvette, FRANCE >>> Tel : +33 1 69 08 99 74 >>> Fax : +33 1 69 08 79 73 >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> B?t 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > B?t 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 09:46:51 +0100 > From: "Gregor Volberg" > To: "FieldTrip List" > Subject: [FieldTrip] WPLI weighted phase-locking index: available in > fieldtrip? > Message-ID: <4D55058B020000570000882D at gwsmtp1.uni-regensburg.de> > Content-Type: text/plain; charset="us-ascii" > > > Dear fieldtrip developers, > > I was just reading the pre-print of an upcoming article in > Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved > index of phase-synchronization...". As I understand, the proposed > phase-locking index WPLI is not complicated by volume conduction, > and an unbiased version of the WPLI can be computed that is not > affected by trial number. This would be exactely what I need for the > analysis of data from a spatial cueing paradigm. > > In the last paragraph, it is announced that the WPLI is made > available in the fieldtrip toolbox. However, I did not yet find it > (i was searching for it as an option in ft_connectivityanalysis, > last Friday's fieldtrip version). May I ask whether it is planned to > include WPLI / debiased WPLI into that function? Or was it perhaps > intended to be computed by hand from the cross-spectrum. > > Thanks a lot, > Gregor > -- > Dr. rer. nat. Gregor Volberg > ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) > University of Regensburg > Institute for Experimental Psychology > 93040 Regensburg, Germany > Tel: +49 941 943 3862 > Fax: +49 941 943 3233 > http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Feb 2011 10:46:13 +0100 > From: Baptiste Gauthier > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] bug in ft_componentanalysis > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest > update > (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC > without an > input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch > (toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds > \n', > toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 3, Issue 17 > **************************************** _______________________________________________ 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 Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 15:50:05 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 15:50:05 +0100 Subject: [FieldTrip] reverse-normalising voxel locations to non-interpolated source volumes Message-ID: <4D5D43AD0200005700008956@gwsmtp1.uni-regensburg.de> Dear list members, sorry for asking a lot in recent days - i am entering a new stage of enlightment with respect to source analysis, and there are only one or two questions left until i am there. My current problem is the following: I am trying to find the voxel coordinates in an individual source volume that correspond to the voxel coordinates of a ROI, which i identified in the normalized brain. My original source volume is called SOURCE, the interpolated version is SOURCEi, and the normalized volume is NORM. Starting from NORM, I identified voxel coordinates belonging to a ROI, then determined the corresponding head (MNI) coordinates and transformed them into head coordinates of the interpolated individual source SOURCEi: [x,y,z] = ind2sub(NORM.dim, find(mask==1)); % voxel indices of a ROI as given in mask headcoords_NORM = warp_apply(NORM.transform, [x y z], 'homogeneous'); % head coordinates of ROI headcoords_SOURCEi = warp_apply(inv(NORM.cfg.final), headcoords_NORM, 'homogeneous'); % corresponding head coordinates in SOURCEi I checked this with several source plots and the results looked fine. Next, i did an LCMV beamformer with the option cfg.keepfilter = 'yes' in order to reconstruct source waveforms at the ROI. The resulting SOURCE has the filters that i need, but a lower resolution and therefore different voxel indices than SOURCEi. So i need to take the head coordinates i found for SOURCEi and identify the corresponding grid locations in SOURCE . For this i only found a crude solution where i, within the SOURCE.pos field, search for the triplet that produces the smallest squared difference to the MNI coordinates of my ROI in SOURCEi. The matrix subscripts for that triplet give the best fitting grid location for my desired ROI, and the corresponding index is pointing to my desired filter: indx = find((((SOURCE.pos(:,1)-headcoords_SOURCEi(1)).^2) + ((SOURCE.pos(:,2)-headcoords_SOURCEi(2)).^2) + ((SOURCE.pos(:,3)-headcoords_SOURCEi(3)).^2)) == min (((SOURCE.pos(:,1)-headcoords_SOURCEi(1)).^2) + ((SOURCE.pos(:,2)-headcoords_SOURCEi(2)).^2) + ((SOURCE.pos(:,3)-headcoords_SOURCEi(3)).^2))); % assume that ROI is a single source location, 1*3 vector [xvox, yvox, zvox] = ind2sub(SOURCE.dim, indx); ROI_filter = SOURCE.avg.filter{indx}; I am very unsure with these last lines of code. Is it true that SOURCE.pos holds MNI coordinates (for the code would be useless if not)? Or is there an easier solution that i am not aware of yet? Any comments would be greatly appreciated. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredericroux at hotmail.de Thu Feb 17 16:39:25 2011 From: fredericroux at hotmail.de (Frederic Roux) Date: Thu, 17 Feb 2011 16:39:25 +0100 Subject: [FieldTrip] =?windows-1256?q?indepsamplesF_vs_depsamplesF=FE=FE?= Message-ID: Dear fieldtrip users, in the fieldtrip-tutorial about how to compute cluster-based permutation tests for time frequency data I read that one should use the indepsamplesT statistic for between trials experiments at the single subject level and the depsamplesT statistic for within trial experiments at the single subject level. I would like to compute an F-test at the single subject level to test between trials effects between 3 conditions, and I was wondering if in analogy to the t-test, I could also use the indepsamplesF statistic? Any help on this question would be greatly appreciated. Frederic -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 20:48:02 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 20:48:02 +0100 Subject: [FieldTrip] =?windows-1256?q?Antw=3A__indepsamplesF_vs_depsamples?= =?windows-1256?b?Rv7+?= Message-ID: <4D5D89810200005700008976@gwsmtp1.uni-regensburg.de> Dear Frederic, technically, this should not be a problem. You find the available statistics functions in the /statfun directory of your fieldtrip folder (the functions have self-explaining names). The functioin you need can be specified with cfg.statistic = 'indepsamplesF'. Mind that you also need to modify the cfg.design accordingly, with three categories instead of two. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> Frederic Roux 17.02.11 17.08 Uhr >>> Dear fieldtrip users, in the fieldtrip-tutorial about how to compute cluster-based permutation tests for time frequency data I read that one should use the indepsamplesT statistic for between trials experiments at the single subject level and the depsamplesT statistic for within trial experiments at the single subject level. I would like to compute an F-test at the single subject level to test between trials effects between 3 conditions, and I was wondering if in analogy to the t-test, I could also use the indepsamplesF statistic? Any help on this question would be greatly appreciated. Frederic From matthew at psych.columbia.edu Fri Feb 18 02:32:08 2011 From: matthew at psych.columbia.edu (Matthew Davidson) Date: Thu, 17 Feb 2011 20:32:08 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? Message-ID: Hi everyone, I'm looking to see if there's an equivalent to the statfun_indepsamplesZcoh function, but for other connectivity measures, like PLV or WPLI. I need to do several single-subject, between-trials analyses of differences between two conditions. Since my data are intracranial EEG, there's no meaningful group test I could use, which I gather is how many people make inferences on connectivity measures. So, has anyone implemented this, or something like it? Am I missing something obvious in how to do this? If I implement it myself, I guess I should randomly partition the trials, compute the WPLIs of the two groups, take the difference, compute the max cluster size, and build a permutation distribution of the max cluster WPLI difference. Is that generally correct? Should I use jackknife variance to transform them into Z-scores for thresholding? Alternatively, if I wanted to do this parametrically, how should I do that? (I ask because Monte Carlo methods w/clustering haven't worked as well as analytic methods on intracranial data where the electrodes are more independent than in MEG or scalp EEG.) What's the proper reference distribution of differences in these bounded connectivity metrics? Do I just compute the jackknife variance, and then do a mass univariate t-test on the connectivity measures (for a single electrode pair and freq bin)? Thanks for any insight or advice you might have, Matthew Davidson From e.maris at donders.ru.nl Fri Feb 18 10:36:36 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Fri, 18 Feb 2011 10:36:36 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: References: Message-ID: <039201cbcf4f$594548f0$0bcfdad0$@maris@donders.ru.nl> Hi Matthew, Permutation inference is valid for comparing two experimental conditions using ANY statistic. If your channels are more or less independent (no common pick-up via volume conduction), then don't use the cluster-based statistics (at least not for the spatial dimension; clustering along the spectral dimension may still be wise). Best, Eric Maris > -----Original Message----- > From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > bounces at donders.ru.nl] On Behalf Of Matthew Davidson > Sent: vrijdag 18 februari 2011 2:32 > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? > > Hi everyone, I'm looking to see if there's an equivalent to the > statfun_indepsamplesZcoh function, but for other connectivity > measures, like PLV or WPLI. I need to do several single-subject, > between-trials analyses of differences between two conditions. Since > my data are intracranial EEG, there's no meaningful group test I could > use, which I gather is how many people make inferences on connectivity > measures. So, has anyone implemented this, or something like it? Am I > missing something obvious in how to do this? > > If I implement it myself, I guess I should randomly partition the > trials, compute the WPLIs of the two groups, take the difference, > compute the max cluster size, and build a permutation distribution of > the max cluster WPLI difference. Is that generally correct? Should I > use jackknife variance to transform them into Z-scores for > thresholding? > > Alternatively, if I wanted to do this parametrically, how should I do > that? (I ask because Monte Carlo methods w/clustering haven't worked > as well as analytic methods on intracranial data where the electrodes > are more independent than in MEG or scalp EEG.) What's the proper > reference distribution of differences in these bounded connectivity > metrics? Do I just compute the jackknife variance, and then do a mass > univariate t-test on the connectivity measures (for a single electrode > pair and freq bin)? > > Thanks for any insight or advice you might have, > Matthew Davidson > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From matthew at psych.columbia.edu Fri Feb 18 18:31:58 2011 From: matthew at psych.columbia.edu (Matthew Davidson) Date: Fri, 18 Feb 2011 12:31:58 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: <-5697139143563785936@unknownmsgid> References: <-5697139143563785936@unknownmsgid> Message-ID: Thanks for your reply, Dr. Maris. I'm sure you're very busy, so I really appreciate your taking time out to answer me. I'd already tried clustering across only time/frequency and not across channel, but what I found was that the strongest channels "set the bar" for all the others, so to speak. I would see 2-3 strong channels with long significant durations reaching significance, and everything else would be silenced. Whereas with parametric stats, I had enough strong signals to detect changes under FDR and Bonferroni correction across a wide range of times and channels. Would z-scoring to compensate for electrode sensitivity differences have helped? I considered doing Monte Carlo stats for each channel independently, and then adjusting critical p-vals via FDR or Bonferroni, but for 100 channels, I would need at least 20000 permutations just to have the Monte Carlo p-val resolution *approach* the adjusted Bonferroni p-vals, and would probably need more to be safe. Factor in several subjs and contrasts, and I computed my analysis would take a few weeks to run. This was why I asked about a parametric method; while I'd prefer permutation methods, I fear the same problem will occur with my connectivity analysis. I know your focus is on permutation stats, but do you have any insight into how to proceed? Think I could generate a permutation distribution of the WPLI differences from a random sampling of electrodes and contrasts, and then, if they look sufficiently close to normal (or transformable via something like a log transform), use that as an argument for using t-tests if I have to? Thanks again, Matthew On Fri, Feb 18, 2011 at 4:36 AM, Eric Maris wrote: > Hi Matthew, > > > Permutation inference is valid for comparing two experimental conditions > using ANY statistic. If your channels are more or less independent (no > common pick-up via volume conduction), then don't use the cluster-based > statistics (at least not for the spatial dimension; clustering along the > spectral dimension may still be wise). > > Best, > > Eric Maris > > > > >> -----Original Message----- >> From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- >> bounces at donders.ru.nl] On Behalf Of Matthew Davidson >> Sent: vrijdag 18 februari 2011 2:32 >> To: fieldtrip at donders.ru.nl >> Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? >> >> Hi everyone, I'm looking to see if there's an equivalent to the >> statfun_indepsamplesZcoh function, but for other connectivity >> measures, like PLV or WPLI. I need to do several single-subject, >> between-trials analyses of differences between two conditions. Since >> my data are intracranial EEG, there's no meaningful group test I could >> use, which I gather is how many people make inferences on connectivity >> measures. So, has anyone implemented this, or something like it? Am I >> missing something obvious in how to do this? >> >> If I implement it myself, I guess I should randomly partition the >> trials, compute the WPLIs of the two groups, take the difference, >> compute the max cluster size, and build a permutation distribution of >> the max cluster WPLI difference. Is that generally correct? Should I >> use jackknife variance to transform them into Z-scores for >> thresholding? >> >> Alternatively, if I wanted to do this parametrically, how should I do >> that? (I ask because Monte Carlo methods w/clustering haven't worked >> as well as analytic methods on intracranial data where the electrodes >> are more independent than in MEG or scalp EEG.) What's the proper >> reference distribution of differences in these bounded connectivity >> metrics? Do I just compute the jackknife variance, and then do a mass >> univariate t-test on the connectivity measures (for a single electrode >> pair and freq bin)? >> >> Thanks for any insight or advice you might have, >> Matthew Davidson >> _______________________________________________ >> 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 lifengmiao at gmail.com Fri Feb 18 20:07:16 2011 From: lifengmiao at gmail.com (Lifeng Miao) Date: Fri, 18 Feb 2011 12:07:16 -0700 Subject: [FieldTrip] question In-Reply-To: References: Message-ID: Dear Fieldtrip members, I have a question when using Fieldtrip tools. What are the locations of the 64 electrodes for EEG data set "subj2"? Thank you very much! Regards, Lifeng -------------- next part -------------- An HTML attachment was scrubbed... URL: From master_engineer07 at yahoo.com Fri Feb 18 22:42:09 2011 From: master_engineer07 at yahoo.com (yacob Jon Mohamady) Date: Fri, 18 Feb 2011 13:42:09 -0800 (PST) Subject: [FieldTrip] problem with ft_read_mri Message-ID: <250412.78294.qm@web38303.mail.mud.yahoo.com> Hi there, I want to calculate the BEM fo EEG. When I run this command line: mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); it gives the following error: Error using ==> spm_platform>init_platform at 173 PCWIN64 not supported architecture for SPM I have SPM8 and when I change my SPM8 to SPM5 it gives this erros: Error using ==> fread Invalid size. I have windows 7, 64-bit and MATLAB 2010a 64-bit. Do you know how I can fix the problem, please. Thank you Yaqub -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Sun Feb 20 17:34:40 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Sun, 20 Feb 2011 17:34:40 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: References: <-5697139143563785936@unknownmsgid> Message-ID: <003401cbd11c$124fcbe0$36ef63a0$@maris@donders.ru.nl> Dear Matthew, > I'd already tried clustering across only time/frequency and not across > channel, but what I found was that the strongest channels "set the > bar" for all the others, so to speak. I would see 2-3 strong channels > with long significant durations reaching significance, and everything > else would be silenced. Whereas with parametric stats, I had enough > strong signals to detect changes under FDR and Bonferroni correction > across a wide range of times and channels. Would z-scoring to > compensate for electrode sensitivity differences have helped? Are the channel-time-frequency-specific parametric p-values smaller than the corresponding permutation p-values (for the same test statistic, of course)? If that is the case, then I would be suspicious wrt to the validity of the parametric test (i.c., its false alarm rate control). (This does not mean, of course, that a smaller parametric p-value implies poor false alarm control.) It's not clear to me what you mean by z-scoring. Does this amount to a linear transform of the dependent variable (the same one for the conditions that are compared)? > > I considered doing Monte Carlo stats for each channel independently, > and then adjusting critical p-vals via FDR or Bonferroni, but for 100 > channels, I would need at least 20000 permutations just to have the > Monte Carlo p-val resolution *approach* the adjusted Bonferroni > p-vals, and would probably need more to be safe. Factor in several > subjs and contrasts, and I computed my analysis would take a few weeks > to run. > > This was why I asked about a parametric method; while I'd prefer > permutation methods, I fear the same problem will occur with my > connectivity analysis. I know your focus is on permutation stats, but > do you have any insight into how to proceed? Think I could generate a > permutation distribution of the WPLI differences from a random > sampling of electrodes and contrasts, and then, if they look > sufficiently close to normal (or transformable via something like a > log transform), use that as an argument for using t-tests if I have > to? If a parametric test solves my problem, then I will definitely use it. However, for statistical tests outside the normal theory parametric framework, it is typically a big challenge to come up with an appropriate parametric reference distribution. I expect this to hold for the WPLI too. Statistical testing of differences at the level of channel pairs (e.g., differences in coupling strength) is a big methodological challenge, for many reasons (a huge multiple comparison problem, lack of specificity of the coupling measure that is used for testing, difficulty of clustering in the space formed by channel pairs). A discussion of these issues is being the scope of the FT discussion list. It is not clear to me what you mean by "generate a permutation distribution of the WPLI differences from a random sampling of electrodes and contrasts". Constructing a permutation distribution in a single subject study (which I assume you are conducting, because you have ECoG data) involves random partitioning of trials (and not electrodes and contrasts). Best, Eric dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > > Thanks again, > Matthew > > > On Fri, Feb 18, 2011 at 4:36 AM, Eric Maris > wrote: > > Hi Matthew, > > > > > > Permutation inference is valid for comparing two experimental > conditions > > using ANY statistic. If your channels are more or less independent > (no > > common pick-up via volume conduction), then don't use the cluster- > based > > statistics (at least not for the spatial dimension; clustering along > the > > spectral dimension may still be wise). > > > > Best, > > > > Eric Maris > > > > > > > > > >> -----Original Message----- > >> From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > >> bounces at donders.ru.nl] On Behalf Of Matthew Davidson > >> Sent: vrijdag 18 februari 2011 2:32 > >> To: fieldtrip at donders.ru.nl > >> Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? > >> > >> Hi everyone, I'm looking to see if there's an equivalent to the > >> statfun_indepsamplesZcoh function, but for other connectivity > >> measures, like PLV or WPLI. I need to do several single-subject, > >> between-trials analyses of differences between two conditions. Since > >> my data are intracranial EEG, there's no meaningful group test I > could > >> use, which I gather is how many people make inferences on > connectivity > >> measures. So, has anyone implemented this, or something like it? Am > I > >> missing something obvious in how to do this? > >> > >> If I implement it myself, I guess I should randomly partition the > >> trials, compute the WPLIs of the two groups, take the difference, > >> compute the max cluster size, and build a permutation distribution > of > >> the max cluster WPLI difference. Is that generally correct? Should I > >> use jackknife variance to transform them into Z-scores for > >> thresholding? > >> > >> Alternatively, if I wanted to do this parametrically, how should I > do > >> that? (I ask because Monte Carlo methods w/clustering haven't worked > >> as well as analytic methods on intracranial data where the > electrodes > >> are more independent than in MEG or scalp EEG.) What's the proper > >> reference distribution of differences in these bounded connectivity > >> metrics? Do I just compute the jackknife variance, and then do a > mass > >> univariate t-test on the connectivity measures (for a single > electrode > >> pair and freq bin)? > >> > >> Thanks for any insight or advice you might have, > >> Matthew Davidson > >> _______________________________________________ > >> 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 r.oostenveld at donders.ru.nl Sun Feb 20 21:03:12 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Sun, 20 Feb 2011 21:03:12 +0100 Subject: [FieldTrip] problem with ft_read_mri In-Reply-To: <250412.78294.qm@web38303.mail.mud.yahoo.com> References: <250412.78294.qm@web38303.mail.mud.yahoo.com> Message-ID: Dear Yaqub (and Cristian, who recently had a similar question) FieldTrip uses SPM for some of the MRI reading and processing. For that purpose, fieldtrip/external/spm2 and fieldtrip/external/spm8 are included in the fieldtrip release version. These are automatically added to the path when needed, but will not be added to the path if you already have another version of spm on your path. Your problem (not having the mex file for the right problem) should be solved if you ensure that fieldtrip/external/spm8 is on your path. That version of SPM8 includes the mex files for 64 bit MS Windows and for 64 bit Mac OS X. The ft_read_mri will then call the correct compiled mex file. best regards, Robert On 18 Feb 2011, at 22:42, yacob Jon Mohamady wrote: > Hi there, > > I want to calculate the BEM fo EEG. > When I run this command line: > mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); > it gives the following error: > Error using ==> spm_platform>init_platform at 173 > PCWIN64 not supported architecture for SPM > > I have SPM8 and when I change my SPM8 to SPM5 it gives this erros: > Error using ==> fread > Invalid size. > > I have windows 7, 64-bit and MATLAB 2010a 64-bit. > Do you know how I can fix the problem, please. > > Thank you > Yaqub > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From r.oostenveld at donders.ru.nl Mon Feb 21 17:58:07 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Mon, 21 Feb 2011 17:58:07 +0100 Subject: [FieldTrip] question In-Reply-To: References: Message-ID: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> Dear Lifeng I would not know whether we have the 3D positions measured for that subject, but the 2D projected positions for plotting are the ones that correspond to fieldtrip/template/easycap64ch-avg.lay and to the section http://fieldtrip.fcdonders.nl/tutorial/layout#easycap_layouts on the tutorial page that explains how to work with 2D layouts for plotting. best regards, Robert On 18 Feb 2011, at 20:07, Lifeng Miao wrote: > > Dear Fieldtrip members, > I have a question when using Fieldtrip tools. What are the locations > of the 64 electrodes for EEG data set "subj2"? > > Thank you very much! > > Regards, > Lifeng > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From lifengmiao at gmail.com Mon Feb 21 18:22:15 2011 From: lifengmiao at gmail.com (Lifeng Miao) Date: Mon, 21 Feb 2011 10:22:15 -0700 Subject: [FieldTrip] question In-Reply-To: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> References: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> Message-ID: Thank you very much! On Mon, Feb 21, 2011 at 9:58 AM, Robert Oostenveld < r.oostenveld at donders.ru.nl> wrote: > Dear Lifeng > > I would not know whether we have the 3D positions measured for that > subject, but the 2D projected positions for plotting are the ones that > correspond to fieldtrip/template/easycap64ch-avg.lay > and to the section > http://fieldtrip.fcdonders.nl/tutorial/layout#easycap_layouts > on the tutorial page that explains how to work with 2D layouts for > plotting. > > best regards, > Robert > > > > On 18 Feb 2011, at 20:07, Lifeng Miao wrote: > > >> Dear Fieldtrip members, >> I have a question when using Fieldtrip tools. What are the locations of >> the 64 electrodes for EEG data set "subj2"? >> >> Thank you very much! >> >> Regards, >> Lifeng >> >> _______________________________________________ >> 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 Nina.Kahlbrock at uni-duesseldorf.de Mon Feb 21 18:54:27 2011 From: Nina.Kahlbrock at uni-duesseldorf.de (Nina Kahlbrock) Date: Mon, 21 Feb 2011 18:54:27 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics Message-ID: <003901cbd1f0$622291a0$cd136386@VMED.UKD> Dear all, I have a question concerning cluster based permutation statistics. It is more a basic question on the difference between one- and two-sided testings. I recall from simple t-tests that as an approach to your two-sided p-value you can multiply your one-sided p-value by 2. I hope this is correct? And I am assuming this to also hold in the other direction, thus, approximating your one-sided p-value by dividing your two-sided p-value by 2? That is why I am expecting something similar when calculating my statistics with a cluster based permutation approach. So what I am actually doing is comparing two conditions at one sensor, comparing time-frequency data. When I calculate a two-sided dependent samples t-test (cfg = []; cfg.channel = 'all'; cfg.latency = [0.5 1.5]; cfg.avgoverchan = 'no'; cfg.avgovertime = 'no'; cfg.parameter = 'powspctrm'; cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 1000; ) , I find one positive cluster with a p-value of 0.036, thus not significant (see fig 1). When I then change my settings to a one-sided test (cfg.tail = 1; cfg.clustertail = 1; cfg.alpha = 0.05;) , the positive cluster gets a p-value of 0.056, again not significant (see fig 2). With the assumption described above, however, I would expect this to become significant when using a one-sided test. Is my assumption correct? If not, could anybody comment on what is wrong about my assumption? I would be very grateful for any advice! Kind regards and thank you very much in advance! Nina - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nina Kahlbrock Institute of Clinical Neuroscience and Medical Psychology Heinrich Heine University Duesseldorf Universitaetsstr. 1 40225 Düsseldorf Tel.: +49 211 81 18075 Fax. .: +49 211 81 19916 Mail: Nina.Kahlbrock at med.uni-duesseldorf.de http://www.uniklinik-duesseldorf.de/medpsychologie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fig 1.pdf Type: application/pdf Size: 9504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fig 2.pdf Type: application/pdf Size: 9660 bytes Desc: not available URL: From sunyata at gmail.com Mon Feb 21 21:39:56 2011 From: sunyata at gmail.com (Matthew Davidson) Date: Mon, 21 Feb 2011 15:39:56 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: <-356542662290850285@unknownmsgid> References: <-5697139143563785936@unknownmsgid> <-356542662290850285@unknownmsgid> Message-ID: >> I'd already tried clustering across only time/frequency and not across >> channel, but what I found was that the strongest channels "set the >> bar" for all the others, so to speak. I would see 2-3 strong channels >> with long significant durations reaching significance, and everything >> else would be silenced. Whereas with parametric stats, I had enough >> strong signals to detect changes under FDR and Bonferroni correction >> across a wide range of times and channels. Would z-scoring to >> compensate for electrode sensitivity differences have helped? > > Are the channel-time-frequency-specific parametric p-values smaller than the > corresponding permutation p-values (for the same test statistic, of course)? > If that is the case, then I would be suspicious wrt to the validity of the > parametric test (i.c., its false alarm rate control). (This does not mean, > of course, that a smaller parametric p-value implies poor false alarm > control.) The parametric p-vals are much smaller, but wouldn't they have to be? To reach significance after Bonferroni correction, they'd have to be on the order of .0005. FWIW, when I ran the permutation tests, I did see p-vals at the minimum possible values. > It's not clear to me what you mean by z-scoring. Does this amount to a > linear transform of the dependent variable (the same one for the conditions > that are compared)? This would have involved z-scoring the log power. With intracranial data, some electrodes are simply less sensitive because they're not making good contact with the brain (because of the way they're embedded in plastic sheets, each electrode is not individually placed), and not because they're picking up a more distal/weaker signal. So, one way to compensate would be to normalize the power. I asked just in case, but I didn't really suspect this would work. Even if power were normalized, the cluster-max permutation distribution would still be dominated by the electrodes that were significant for the longest period of time. >> >> I considered doing Monte Carlo stats for each channel independently, >> and then adjusting critical p-vals via FDR or Bonferroni, but for 100 >> channels, I would need at least 20000 permutations just to have the >> Monte Carlo p-val resolution *approach* the adjusted Bonferroni >> p-vals, and would probably need more to be safe. Factor in several >> subjs and contrasts, and I computed my analysis would take a few weeks >> to run. >> >> This was why I asked about a parametric method; while I'd prefer >> permutation methods, I fear the same problem will occur with my >> connectivity analysis. I know your focus is on permutation stats, but >> do you have any insight into how to proceed? Think I could generate a >> permutation distribution of the WPLI differences from a random >> sampling of electrodes and contrasts, and then, if they look >> sufficiently close to normal (or transformable via something like a >> log transform), use that as an argument for using t-tests if I have >> to? > > If a parametric test solves my problem, then I will definitely use it. > However, for statistical tests outside the normal theory parametric > framework, it is typically a big challenge to come up with an appropriate > parametric reference distribution. I expect this to hold for the WPLI too. > > Statistical testing of differences at the level of channel pairs (e.g., > differences in coupling strength) is a big methodological challenge, for > many reasons (a huge multiple comparison problem, lack of specificity of the > coupling measure that is used for testing, difficulty of clustering in the > space formed by channel pairs). A discussion of these issues is being the > scope of the FT discussion list. > > It is not clear to me what you mean by "generate a permutation distribution > of the WPLI differences from a random sampling of electrodes and contrasts". > Constructing a permutation distribution in a single subject study (which I > assume you are conducting, because you have ECoG data) involves random > partitioning of trials (and not electrodes and contrasts). Ehh, this was a bit more ad hoc. I didn't have a formal method in mind, I was just thinking about the Kiebel, Tallon-Baudry and Friston HBM paper where they show that log-transforming power renders it approximately normal. It should, however, be legitimate for any given electrode pair to permute trials, compute the connectivity metrics and their difference, generate a permutation distribution of the difference, and make an inference from that, yes? (Although it doesn't address the MCP.) Thanks for all your help, btw. Matthew From e.maris at donders.ru.nl Mon Feb 21 21:58:52 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Mon, 21 Feb 2011 21:58:52 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics Message-ID: <00b501cbd20a$256bf890$7043e9b0$@maris@donders.ru.nl> Hi Nina, I have a question concerning cluster based permutation statistics. It is more a basic question on the difference between one- and two-sided testings. I recall from simple t-tests that as an approach to your two-sided p-value you can multiply your one-sided p-value by 2. I hope this is correct? And I am assuming this to also hold in the other direction, thus, approximating your one-sided p-value by dividing your two-sided p-value by 2? I propose that you calculate your p-values always one-sided. In fact, this is what the FT permutation statistics functions also do. The difference between a one- and a two-sided test is that you compare this one-sided p-value either with your desired type-I error level (for a one-sided test) or with half your desired type-I error level (for a two-sided test). That is why I am expecting something similar when calculating my statistics with a cluster based permutation approach. So what I am actually doing is comparing two conditions at one sensor, comparing time-frequency data. When I calculate a two-sided dependent samples t-test (cfg = []; cfg.channel = 'all'; cfg.latency = [0.5 1.5]; cfg.avgoverchan = 'no'; cfg.avgovertime = 'no'; cfg.parameter = 'powspctrm'; cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 1000; ) , I find one positive cluster with a p-value of 0.036, thus not significant (see fig 1). When I then change my settings to a one-sided test (cfg.tail = 1; cfg.clustertail = 1; cfg.alpha = 0.05;) , the positive cluster gets a p-value of 0.056, again not significant (see fig 2). I think that the difference between 0.036 and 0.056 is due to the fact that these are random quantities. If expect that, if you would increase cfg.numrandomization to 100,000, you would find two p-values that are much closer. In any case, the p-values are one-sided, and their calculation is independent of the value that you choose for cfg.alpha. Best, Eric Maris With the assumption described above, however, I would expect this to become significant when using a one-sided test. Is my assumption correct? If not, could anybody comment on what is wrong about my assumption? I would be very grateful for any advice! Kind regards and thank you very much in advance! Nina - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nina Kahlbrock Institute of Clinical Neuroscience and Medical Psychology Heinrich Heine University Duesseldorf Universitaetsstr. 1 40225 Düsseldorf Tel.: +49 211 81 18075 Fax. .: +49 211 81 19916 Mail: Nina.Kahlbrock at med.uni-duesseldorf.de http://www.uniklinik-duesseldorf.de/medpsychologie -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Tue Feb 22 07:26:10 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 22 Feb 2011 07:26:10 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? Message-ID: <00c101cbd259$7b5f3330$721d9990$@maris@donders.ru.nl> Hi Matthew, > The parametric p-vals are much smaller, but wouldn't they have to be? > To reach significance after Bonferroni correction, they'd have to be > on the order of .0005. FWIW, when I ran the permutation tests, I did > see p-vals at the minimum possible values. If the parametric p-values are around, say, 1e-10, then I would expect the permutation p-value to be 0, unless numrandomization is set a very high value (around 1e+10). It should, however, be legitimate for any given > electrode pair to permute trials, compute the connectivity metrics and > their difference, generate a permutation distribution of the > difference, and make an inference from that, yes? (Although it doesn't > address the MCP.) Agree. Best, Eric > > Thanks for all your help, btw. > Matthew From Nina.Kahlbrock at uni-duesseldorf.de Tue Feb 22 10:14:08 2011 From: Nina.Kahlbrock at uni-duesseldorf.de (Nina Kahlbrock) Date: Tue, 22 Feb 2011 10:14:08 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics In-Reply-To: <00b501cbd20a$256bf890$7043e9b0$%maris@donders.ru.nl> References: <00b501cbd20a$256bf890$7043e9b0$%maris@donders.ru.nl> Message-ID: <000901cbd270$dd991b80$cd136386@VMED.UKD> Hi Eric, thank you very much for your reply! I still have a question regarding your answer, though. I propose that you calculate your p-values always one-sided. In fact, this is what the FT permutation statistics functions also do. The difference between a one- and a two-sided test is that you compare this one-sided p-value either with your desired type-I error level (for a one-sided test) or with half your desired type-I error level (for a two-sided test). I think that the difference between 0.036 and 0.056 is due to the fact that these are random quantities. If expect that, if you would increase cfg.numrandomization to 100,000, you would find two p-values that are much closer. In any case, the p-values are one-sided, and their calculation is independent of the value that you choose for cfg.alpha. I understand that cfg.alpha only gives the threshold for which of my p-values is counted as being significant. However, I thought, changing cfg.tail would change whether I am looking for positive and negative clusters (cfg.tail = 0, two-sided test), or only positive or only negative clusters (cfg.tail = 1 or -1, one-sided test). The change in stat.prob from 0.036 to 0.056 described in my previous email seems to depend on whether I set cfg.tail to 0 or 1. I've computed it multiple times and witch cfg.tail = 0, stat.prob evolves around 0.03 and with cfg.tail = 1 around 0.05. Could you maybe explain this to me? >From your explanation above I would assume that I can use cfg.tail = 0 and cfg.alpha = 0.05 to end up with a mask including my significant clusters in a one-sided test? Thanks again for your help! Nina -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmeyer at cbs.mpg.de Tue Feb 22 13:01:16 2011 From: lmeyer at cbs.mpg.de (Lars Meyer) Date: Tue, 22 Feb 2011 13:01:16 +0100 Subject: [FieldTrip] =?iso-8859-1?q?correlation_=7C=A0statfun?= Message-ID: dear all, on the new fieldtrip homepage, i find a short suggestion on how to try and run a correlation analysis on timelock data using an external regressor (e.g. an fmri-effect) and a single-rowed cfg.design containing this regressor. my questions now are: how does the data have to look? should i just produce an effect (= difference .avg containing the difference between two erps) for each participant, i.e. my input data is a 1 x participants struct? is it correct that cfg.design is only the regressor (= one value per participant), and that cfg.uvar is empty? if the above are correct: what is the proper statfun to run this type of statistic, i.e. a correlation between the individual effects and an external regressor, if i want to use the cluster statistics monte carlo approach? thanks a lot, l. Lars Meyer Max Planck Institute for Human Cognitive & Brain Sciences Department of Neuropsychology Stephanstrafle 1a 04103 Leipzig | Germany Office | +49 341 99 40 22 66 Mail | lmeyer at cbs.mpg.de Web | www.cbs.mpg.de/~lmeyer From r.oostenveld at donders.ru.nl Tue Feb 22 21:48:35 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Tue, 22 Feb 2011 21:48:35 +0100 Subject: [FieldTrip] Washington University in St. Louis seeks postdoctoral scholar for MEG studies References: <4476B37DB8F5D248AE7C349966A22A04406D2359A8@nilex07.neuroimage.wustl.edu> Message-ID: Dear FieldTrip list members, Please see below or on http://humanconnectome.org for an interesting postdoc opportunity. The successful candidate will (among others) work together with the FieldTrip/Donders team. best regards Robert Oostenveld On 22 Feb 2011, at 19:04, Larson-Prior, Linda wrote: > Dear Colleague, > Washington University in St. Louis announces that a full-time Postdoctoral Research Associate position is available to develop creative methods of magnetoencephalography (MEG) analysis for the Human Connectome Project (HCP). The job announcement for this position is attached and we would appreciate your circulating this position announcement to you trainees. > > Best Regards, > Linda Larson-Prior > Abraham Snyder -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WU_MEG_postdoc_job_description_191113.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 15877 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Wed Feb 23 02:21:17 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Tue, 22 Feb 2011 17:21:17 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume Message-ID: Hello, While writing beamformed images to spm2 format in a previous version of fieldtrip (now lost due to a computer crash), I was able to get nice-looking results; networks of brain regions consistent with existing literature. When I try to write images from the same dataset and the same analysis to spm8 format, my results (t-images computed across subjects) end up being single clusters spanning large sections of the brain (e.g. a 'blob' spanning all of one hemisphere but not the other). Unfortunately, some aspects of my planned data analyses cannot be performed on spm2 images, so I have to find a way of writing to successfully to nifti format. I just noticed that in the comments in the ft_write_volume function, which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under the list of supported dataformats. Is there by any chance a patch out there for writing nifti images? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Wed Feb 23 16:50:16 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Wed, 23 Feb 2011 16:50:16 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: Message-ID: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Dear Jen, I notice that indeed in the documentation section of ft_write_volume there is a FIXME behind nifti. Yet, nifti format seems to be supported by ft_write_volume (at least in a recent version of fieldtrip). Did you try it at all (and ran into problems) or were you held back by the FIXME statement? Could you just try it out using a recent fieldtrip function? Thanks and best wishes Jan-Mathijs On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From jenwhitman at gmail.com Wed Feb 23 19:44:03 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Wed, 23 Feb 2011 10:44:03 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: Dear Jan, Thanks for the quick reply. Yes, I have tried it out quite a few times now, experimenting with different settings in the cfgs. Below I'll paste the code I've been using to write images - first the code that successfully created spm2 images that produced good results, then the code used for creating nifti format images from the same data. The comments in this second part are at this point a bit of a maze of cfg options I've been changing back & forth. Any insights/suggestions regarding how to set up my cfgs to make this work would be greatly appreciated. Jen %%%%%%%% this code generated spm2-compatible images which did work (producing results that made sense). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ sourcePre.avg.pow; cfg = []; cfg.downsample = 2; sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); % projecting the plot onto a surface... cfg = []; cfg.coordinates = 'ctf'; cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this template is in MNI coordinates sourcetempIntN = volumenormalise(cfg, sourcetempInt); filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) 'HzWin' int2str(win) 'width750ms']; cfg=[]; cfg.parameter = 'avg.pow'; % string, describing the functional data to be processed, e.g. 'pow', 'coh' or 'nai' cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % filename without the extension cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive (default = []) cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', 'int16', 'int32', 'float' or 'double' volumewrite(cfg, sourcetempIntN) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%% this code below hasn't worked yet... % I added cfg.spmversion = 'spm8'; % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, % and in the call to prepare_singleshell after calling volumesegment % I've also ensured that spm8 is the only spm version in my path, even in % the fieldtrip/external folder, and ensured that spm8 is installed properly % (files compiled correctly, etc..) sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ sourcePre.avg.pow; filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; cfg = []; % cfg.coordinates = 'spm'; % changed for version 5 % cfg.spmversion = 'spm8'; % changed for version 5 cfg.downsample = 4; sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); % projecting the plot onto a surface... cfg = []; %cfg.coordinates = 'spm'; % changed for version 5 %cfg.coordinates = 'ctf'; % changed for version 5 cfg.coordinates = 'spm'; % changed back to spm for version 9 cfg.downsample = 4; %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets specified in volumewrite) cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has the desired voxel size % cfg.name = [filename]; % changed for version 6 %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' there was no subsequent call to volumewrite) cfg.write= 'no'; % changed for version 6 sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); % this whole cfg and function call added for version 6 cfg=[]; % cfg.parameter = string, describing the functional data to be processed, e.g. 'pow', 'coh' or 'nai' % cfg.filename = filename without the extension % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = []) cfg.parameter='pow'; cfg.filename=filename; cfg.filetype = 'spm'; cfg.spmversion = 'SPM8'; % capitalized after first error message from vers 6 % cfg.dataformat='nifti'; % added after first error message from vers 6 % commented out after 2nd error message from vers 6 %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to specify unless cfg.filetyp='vmp' cfg.coordinates='spm'; ft_volumewrite(cfg,sourcetempIntN); On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume there > is a FIXME behind nifti. Yet, nifti format seems to be supported by > ft_write_volume (at least in a recent version of fieldtrip). Did you try it > at all (and ran into problems) or were you held back by the FIXME statement? > Could you just try it out using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, >> >> While writing beamformed images to spm2 format in a previous version of >> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >> results; networks of brain regions consistent with existing literature. When >> I try to write images from the same dataset and the same analysis to spm8 >> format, my results (t-images computed across subjects) end up being single >> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >> one hemisphere but not the other). Unfortunately, some aspects of my planned >> data analyses cannot be performed on spm2 images, so I have to find a way of >> writing to successfully to nifti format. >> >> I just noticed that in the comments in the ft_write_volume function, which >> I am calling via ft_volumewrite, it says 'FIXME' next to nifti under the >> list of supported dataformats. Is there by any chance a patch out there for >> writing nifti images? >> >> Thanks! >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Thu Feb 24 07:58:24 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 24 Feb 2011 07:58:24 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: Hi Jen, Thanks for sending the code. What is the actual error message you are getting? Best wishes, Jan-Mathijs On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few > times now, experimenting with different settings in the cfgs. Below > I'll paste the code I've been using to write images - first the code > that successfully created spm2 images that produced good results, > then the code used for creating nifti format images from the same > data. The comments in this second part are at this point a bit of a > maze of cfg options I've been changing back & forth. Any insights/ > suggestions regarding how to set up my cfgs to make this work would > be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; > %this template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the > functional data to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; > %'testimageoutput_alphafreq'; % filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and > ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, > even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this > gets specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to > using spm8/templates/EPI.nii, except that mask.nii (produced from > fmri data) has the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to > 'yes' there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format > to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive > (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message > from vers 6 > % cfg.dataformat='nifti'; % added after first error message from > vers 6 > % commented out after 2nd error > message from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need > to specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume > there is a FIXME behind nifti. Yet, nifti format seems to be > supported by ft_write_volume (at least in a recent version of > fieldtrip). Did you try it at all (and ran into problems) or were > you held back by the FIXME statement? Could you just try it out > using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 24 13:44:51 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 24 Feb 2011 13:44:51 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Dear Jen, I managed to reproduce your problem. The code was rather buggy and indeed ft_volumewrite did not behave as it should have. I now fixed it in the code and it should run fine now. Please find the updated file attached. It will be available on our ftp-server as of tonight. Please note that I updated the documentation, and changed the names of some of the options a bit. If you want to save your data in analyze-format, you should specify cfg.filetype = 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a volume to nifti-format, using SPM8. Best wishes, Jan-Mathijs On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few > times now, experimenting with different settings in the cfgs. Below > I'll paste the code I've been using to write images - first the code > that successfully created spm2 images that produced good results, > then the code used for creating nifti format images from the same > data. The comments in this second part are at this point a bit of a > maze of cfg options I've been changing back & forth. Any insights/ > suggestions regarding how to set up my cfgs to make this work would > be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; > %this template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the > functional data to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; > %'testimageoutput_alphafreq'; % filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and > ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, > even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this > gets specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to > using spm8/templates/EPI.nii, except that mask.nii (produced from > fmri data) has the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to > 'yes' there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format > to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive > (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message > from vers 6 > % cfg.dataformat='nifti'; % added after first error message from > vers 6 > % commented out after 2nd error > message from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need > to specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume > there is a FIXME behind nifti. Yet, nifti format seems to be > supported by ft_write_volume (at least in a recent version of > fieldtrip). Did you try it at all (and ran into problems) or were > you held back by the FIXME statement? Could you just try it out > using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ft_volumewrite.m Type: application/octet-stream Size: 16641 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.litvak at ion.ucl.ac.uk Thu Feb 24 17:06:06 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Thu, 24 Feb 2011 16:06:06 +0000 Subject: [FieldTrip] ICA In-Reply-To: <1625468855117010300@unknownmsgid> References: <1625468855117010300@unknownmsgid> Message-ID: Hi Holly, I'm not sure why the databrowser needs the trl struct or whether we can add something to our exported FT struct to make it happy. I'm CCing to the Fieldtrip list to perhaps get some answers. I got exactly the same complaint from someone else last week. Best, Vladimir On Thu, Feb 24, 2011 at 2:48 PM, Holly Rossiter wrote: > Hi Vladimir, > > > > I am trying out using ICA on my data to see what difference it makes to the > eye blinks and whether it is a step worth doing or not. I am using a > fieldtrip script... > > > > D= spm_eeg_load; > > data = D.ftraw(0); > > cfg = []; > > cfg.channel = 'MEG'; > > ic_data = ft_componentanalysis(cfg,data); > > cfg = []; > > cfg.viewmode = 'component'; > > cfg.continuous = 'yes'; > > cfg.layout = 'CTF275.lay'; > > cfg.blocksize = 30; > > cfg.channels = [1:10]; > > ft_databrowser(cfg,ic_data); > > > > But it comes up with an error saying > > > > Error using ==> ft_databrowser at 217 > > no trials to display > > > > I think this may be because I don’t have a trl matrix due to using > spm_eeg_load. Do you know how I can create one of these using spm format > data? Or how else to write the script so that ICA will work? > > > > Kind regards, > > > > Holly From jenwhitman at gmail.com Thu Feb 24 19:07:23 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Thu, 24 Feb 2011 10:07:23 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Great, thanks! I'll start the analysis with your new script today and will let you know how it works out. Jen On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I managed to reproduce your problem. The code was rather buggy and indeed > ft_volumewrite did not behave as it should have. I now fixed it in the code > and it should run fine now. Please find the updated file attached. It will > be available on our ftp-server as of tonight. Please note that I updated the > documentation, and changed the names of some of the options a bit. If you > want to save your data in analyze-format, you should specify cfg.filetype = > 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a > volume to nifti-format, using SPM8. > > Best wishes, > > Jan-Mathijs > > > > > > On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few times now, > experimenting with different settings in the cfgs. Below I'll paste the code > I've been using to write images - first the code that successfully created > spm2 images that produced good results, then the code used for creating > nifti format images from the same data. The comments in this second part are > at this point a bit of a maze of cfg options I've been changing back & > forth. Any insights/suggestions regarding how to set up my cfgs to make this > work would be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this > template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) > 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % > filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) > 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets > specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using > spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has > the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' > there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data to be > processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message from > vers 6 > % cfg.dataformat='nifti'; % added after first error message from vers 6 > % commented out after 2nd error message > from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to > specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I notice that indeed in the documentation section of ft_write_volume there >> is a FIXME behind nifti. Yet, nifti format seems to be supported by >> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >> at all (and ran into problems) or were you held back by the FIXME statement? >> Could you just try it out using a recent fieldtrip function? >> >> Thanks and best wishes >> >> Jan-Mathijs >> >> >> >> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >> >> Hello, >>> >>> While writing beamformed images to spm2 format in a previous version of >>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>> results; networks of brain regions consistent with existing literature. When >>> I try to write images from the same dataset and the same analysis to spm8 >>> format, my results (t-images computed across subjects) end up being single >>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>> data analyses cannot be performed on spm2 images, so I have to find a way of >>> writing to successfully to nifti format. >>> >>> I just noticed that in the comments in the ft_write_volume function, >>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>> the list of supported dataformats. Is there by any chance a patch out there >>> for writing nifti images? >>> >>> Thanks! >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 ekanal at cmu.edu Fri Feb 25 20:10:59 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 14:10:59 -0500 Subject: [FieldTrip] ft_componentbrowser problem Message-ID: Hello - I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: ~~~~ cfg = struct('method','fastica','channel','M*','numcomponent','10'); components = ft_componentanalysis(cfg, data_preprocessed); cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); ft_componentbrowser(cfg,components); ~~~~ I increase the The script fails at the final line with the following error: ~~~~ ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. Error in ==> ft_plot_topo at 92 inside = inside_contour([chanX chanY], mask{1}); Error in ==> ft_componentbrowser>plottopography at 172 ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... Error in ==> ft_componentbrowser at 116 plottopography([], cfg, comp) ~~~~ Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - Elli Kanal -------------------- Eliezer Kanal, Ph.D. Postdoctoral Fellow Center for the Neural Basis of Cognition Carnegie Mellon University 4400 Fifth Ave, Suite 115 Pittsburgh PA 15213 P: 412-268-4115 F: 412-268-5060 From jan.schoffelen at donders.ru.nl Fri Feb 25 20:33:43 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 25 Feb 2011 20:33:43 +0100 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: <9745F187-5622-4F8A-9939-0F4ED3D5B2F0@donders.ru.nl> Dear Elli, Apparently the ft_componentbrowser function cannot find inside_contour.m I know that ft_componentbrowser will soon be replaced by the more generic ft_databrowser, and it could be that in this process some changes have already been made, breaking the componentbrowser. Or perhaps something else is going on... Either way, inside_contour.m is located in fieldtrip/plotting/private, and it cannot be seen by ft_componentbrowser, because this function is located at fieldtrip/. If you copy inside_contour to the directory fieldtrip/private I expect that your problem is solved. Good luck, Jan-Mathijs On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > Hello - > > I have a simple script which seems to be failing on > ft_componentbrowser, and I can't figure out why. The script is as > follows: > > ~~~~ > cfg = struct('method','fastica','channel','M*','numcomponent','10'); > components = ft_componentanalysis(cfg, data_preprocessed); > > cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); > ft_componentbrowser(cfg,components); > ~~~~ > > I increase the The script fails at the final line with the following > error: > > ~~~~ > ??? Undefined function or method 'inside_contour' for input > arguments of type 'double'. > > Error in ==> ft_plot_topo at 92 > inside = inside_contour([chanX chanY], mask{1}); > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), > cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Any ideas as to why this isn't working? I'm pretty stuck at this > point. Thanks - > > Elli Kanal > > > -------------------- > Eliezer Kanal, Ph.D. > Postdoctoral Fellow > Center for the Neural Basis of Cognition > Carnegie Mellon University > 4400 Fifth Ave, Suite 115 > Pittsburgh PA 15213 > P: 412-268-4115 > F: 412-268-5060 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From jan.schoffelen at donders.ru.nl Fri Feb 25 20:38:40 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 25 Feb 2011 20:38:40 +0100 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: Hi Elli, Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? If not, I suggest you download a recent fieldtrip version, and try again. Best wishes, Jan-Mathijs On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > Hello - > > I have a simple script which seems to be failing on > ft_componentbrowser, and I can't figure out why. The script is as > follows: > > ~~~~ > cfg = struct('method','fastica','channel','M*','numcomponent','10'); > components = ft_componentanalysis(cfg, data_preprocessed); > > cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); > ft_componentbrowser(cfg,components); > ~~~~ > > I increase the The script fails at the final line with the following > error: > > ~~~~ > ??? Undefined function or method 'inside_contour' for input > arguments of type 'double'. > > Error in ==> ft_plot_topo at 92 > inside = inside_contour([chanX chanY], mask{1}); > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), > cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Any ideas as to why this isn't working? I'm pretty stuck at this > point. Thanks - > > Elli Kanal > > > -------------------- > Eliezer Kanal, Ph.D. > Postdoctoral Fellow > Center for the Neural Basis of Cognition > Carnegie Mellon University > 4400 Fifth Ave, Suite 115 > Pittsburgh PA 15213 > P: 412-268-4115 > F: 412-268-5060 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From ekanal at cmu.edu Fri Feb 25 20:52:02 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 14:52:02 -0500 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: <7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> Hello Dr Schoffelen - Thanks for the quick reply. I've been periodically updating from the SVN directory, but it appears my local working directory had become messed up. The file is now found. However, it seems to have uncovered another error: ~~~~ >> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay','channel','M*'); >> ft_componentbrowser(cfg,components); reading layout from file neuromag306all.lay ??? Error using ==> rdivide Matrix dimensions must agree. Error in ==> ft_componentbrowser>plottopography at 172 ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... Error in ==> ft_componentbrowser at 116 plottopography([], cfg, comp) ~~~~ Once again, any ideas? Thanks - Elli On Feb 25, 2011, at 2:38 PM, jan-mathijs schoffelen wrote: > Hi Elli, > > Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? > If not, I suggest you download a recent fieldtrip version, and try again. > > Best wishes, > > Jan-Mathijs > > On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > >> Hello - >> >> I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: >> >> ~~~~ >> cfg = struct('method','fastica','channel','M*','numcomponent','10'); >> components = ft_componentanalysis(cfg, data_preprocessed); >> >> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); >> ft_componentbrowser(cfg,components); >> ~~~~ >> >> I increase the The script fails at the final line with the following error: >> >> ~~~~ >> ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. >> >> Error in ==> ft_plot_topo at 92 >> inside = inside_contour([chanX chanY], mask{1}); >> >> Error in ==> ft_componentbrowser>plottopography at 172 >> ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... >> >> Error in ==> ft_componentbrowser at 116 >> plottopography([], cfg, comp) >> ~~~~ >> >> Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - >> >> Elli Kanal >> >> >> -------------------- >> Eliezer Kanal, Ph.D. >> Postdoctoral Fellow >> Center for the Neural Basis of Cognition >> Carnegie Mellon University >> 4400 Fifth Ave, Suite 115 >> Pittsburgh PA 15213 >> P: 412-268-4115 >> F: 412-268-5060 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jenwhitman at gmail.com Fri Feb 25 21:44:55 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Fri, 25 Feb 2011 12:44:55 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Hi Jan, I tried re-running the analysis with the new script you sent me, and the latest version of fieldtrip (since I needed ft_get_opt as well), but the spm8 images being written are still producing flawed results. It's the same problem as I mentioned briefly in my previous post. I am not getting any error messages when writing these images. Rather, my problem is that the spm8 and spm2 results from the same data ought to be identical when viewed in mricron, but they're far from it. When I use mricron to look at the results from the spm8-format images, combined across participants to create a t-image, I just get a single 'blob' spanning roughly half the brain. In contrast, when I used spm2-format previously on the same data, the t-image was much more meaningful; a posterior alpha power decrease in a set of regions corresponding to the 'task-positive network' (a network found in the results of an fMRI version of my experiment, and widely reported in the fMRI literature). This failure to replicate the spm2 results when using spm8 images from the same data leads me to suspect that something is wrong with the coordinates for spm8 format. However, after experimenting extensively with different cfg options I still haven't identified the problem. If I my structural MRIs have been saved to .mri files using CTF's MRIConverter program, which cfg options, particularly for coordinates, template images, and filetypes, should I specify before calling the ft_volumesegment, ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite functions? Or should I be calling a different set of functions now? Thanks again for your help, Jen On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: > Great, thanks! > > I'll start the analysis with your new script today and will let you know > how it works out. > > Jen > > On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I managed to reproduce your problem. The code was rather buggy and indeed >> ft_volumewrite did not behave as it should have. I now fixed it in the code >> and it should run fine now. Please find the updated file attached. It will >> be available on our ftp-server as of tonight. Please note that I updated the >> documentation, and changed the names of some of the options a bit. If you >> want to save your data in analyze-format, you should specify cfg.filetype = >> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a >> volume to nifti-format, using SPM8. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> >> >> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >> >> >> Dear Jan, >> >> Thanks for the quick reply. Yes, I have tried it out quite a few times >> now, experimenting with different settings in the cfgs. Below I'll paste the >> code I've been using to write images - first the code that successfully >> created spm2 images that produced good results, then the code used for >> creating nifti format images from the same data. The comments in this second >> part are at this point a bit of a maze of cfg options I've been changing >> back & forth. Any insights/suggestions regarding how to set up my cfgs to >> make this work would be greatly appreciated. >> >> Jen >> >> >> %%%%%%%% this code generated spm2-compatible images which did work >> (producing results that made sense). >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >> sourcePre.avg.pow; >> >> cfg = []; >> cfg.downsample = 2; >> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >> >> % projecting the plot onto a surface... >> cfg = []; >> cfg.coordinates = 'ctf'; >> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this >> template is in MNI coordinates >> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >> 'HzWin' int2str(win) 'width750ms']; >> cfg=[]; >> cfg.parameter = 'avg.pow'; % string, describing the functional >> data to be processed, e.g. 'pow', 'coh' or 'nai' >> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % >> filename without the extension >> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >> (default = []) >> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >> 'int16', 'int32', 'float' or 'double' >> >> volumewrite(cfg, sourcetempIntN) >> >> >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%% this code below hasn't worked yet... >> >> % I added cfg.spmversion = 'spm8'; >> % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, >> % and in the call to prepare_singleshell after calling volumesegment >> >> % I've also ensured that spm8 is the only spm version in my path, even in >> % the fieldtrip/external folder, and ensured that spm8 is installed >> properly >> % (files compiled correctly, etc..) >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >> sourcePre.avg.pow; >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >> >> cfg = []; >> % cfg.coordinates = 'spm'; % changed for version 5 >> % cfg.spmversion = 'spm8'; % changed for version 5 >> cfg.downsample = 4; >> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >> >> >> % projecting the plot onto a surface... >> cfg = []; >> %cfg.coordinates = 'spm'; % changed for version 5 >> %cfg.coordinates = 'ctf'; % changed for version 5 >> cfg.coordinates = 'spm'; % changed back to spm for version 9 >> cfg.downsample = 4; >> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >> specified in volumewrite) >> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using >> spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has >> the desired voxel size >> % cfg.name = [filename]; % changed for version 6 >> %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' >> there was no subsequent call to volumewrite) >> cfg.write= 'no'; % changed for version 6 >> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >> >> % this whole cfg and function call added for version 6 >> cfg=[]; >> % cfg.parameter = string, describing the functional data to be >> processed, e.g. 'pow', 'coh' or 'nai' >> % cfg.filename = filename without the extension >> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use >> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >> []) >> cfg.parameter='pow'; >> cfg.filename=filename; >> cfg.filetype = 'spm'; >> cfg.spmversion = 'SPM8'; % capitalized after first error message from >> vers 6 >> % cfg.dataformat='nifti'; % added after first error message from vers 6 >> % commented out after 2nd error message >> from vers 6 >> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >> specify unless cfg.filetyp='vmp' >> cfg.coordinates='spm'; >> ft_volumewrite(cfg,sourcetempIntN); >> >> >> >> >> >> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl> wrote: >> >>> Dear Jen, >>> >>> I notice that indeed in the documentation section of ft_write_volume >>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>> at all (and ran into problems) or were you held back by the FIXME statement? >>> Could you just try it out using a recent fieldtrip function? >>> >>> Thanks and best wishes >>> >>> Jan-Mathijs >>> >>> >>> >>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>> >>> Hello, >>>> >>>> While writing beamformed images to spm2 format in a previous version of >>>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>>> results; networks of brain regions consistent with existing literature. When >>>> I try to write images from the same dataset and the same analysis to spm8 >>>> format, my results (t-images computed across subjects) end up being single >>>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>>> data analyses cannot be performed on spm2 images, so I have to find a way of >>>> writing to successfully to nifti format. >>>> >>>> I just noticed that in the comments in the ft_write_volume function, >>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>> the list of supported dataformats. Is there by any chance a patch out there >>>> for writing nifti images? >>>> >>>> Thanks! >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> _______________________________________________ >>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 ekanal at cmu.edu Fri Feb 25 22:32:12 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 16:32:12 -0500 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: <7030_1298663591_p1PJr8OZ010844_7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> References: <7030_1298663591_p1PJr8OZ010844_7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> Message-ID: Never mind, the problem was my specifying the 'comp' item as a string (with single quotes'1:10') instead of a vector. Thanks for your help - Elli On Feb 25, 2011, at 2:52 PM, Kanal Eliezer wrote: > Hello Dr Schoffelen - > > Thanks for the quick reply. I've been periodically updating from the SVN directory, but it appears my local working directory had become messed up. The file is now found. > > However, it seems to have uncovered another error: > > ~~~~ >>> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay','channel','M*'); >>> ft_componentbrowser(cfg,components); > reading layout from file neuromag306all.lay > ??? Error using ==> rdivide > Matrix dimensions must agree. > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Once again, any ideas? Thanks - > > Elli > > > On Feb 25, 2011, at 2:38 PM, jan-mathijs schoffelen wrote: > >> Hi Elli, >> >> Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? >> If not, I suggest you download a recent fieldtrip version, and try again. >> >> Best wishes, >> >> Jan-Mathijs >> >> On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: >> >>> Hello - >>> >>> I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: >>> >>> ~~~~ >>> cfg = struct('method','fastica','channel','M*','numcomponent','10'); >>> components = ft_componentanalysis(cfg, data_preprocessed); >>> >>> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); >>> ft_componentbrowser(cfg,components); >>> ~~~~ >>> >>> I increase the The script fails at the final line with the following error: >>> >>> ~~~~ >>> ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. >>> >>> Error in ==> ft_plot_topo at 92 >>> inside = inside_contour([chanX chanY], mask{1}); >>> >>> Error in ==> ft_componentbrowser>plottopography at 172 >>> ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... >>> >>> Error in ==> ft_componentbrowser at 116 >>> plottopography([], cfg, comp) >>> ~~~~ >>> >>> Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - >>> >>> Elli Kanal >>> >>> >>> -------------------- >>> Eliezer Kanal, Ph.D. >>> Postdoctoral Fellow >>> Center for the Neural Basis of Cognition >>> Carnegie Mellon University >>> 4400 Fifth Ave, Suite 115 >>> Pittsburgh PA 15213 >>> P: 412-268-4115 >>> F: 412-268-5060 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 r.oostenveld at donders.ru.nl Sat Feb 26 10:15:35 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Sat, 26 Feb 2011 10:15:35 +0100 Subject: [FieldTrip] ICA In-Reply-To: References: <1625468855117010300@unknownmsgid> Message-ID: <2D910383-6EC3-4467-9946-C4321614591A@donders.ru.nl> Hi Holly The ft_databrowser function was initially written for identifying segments (artifacts, sleep spindles and spike-wave discharges) from continuous data. We wanted those segments to be marked relative to the original data file, i.e. the segments shoudl be marked by their begin- and end-sample. Over time, we started using the function for more and more stuff, but there are still some "relicts" in the code that rely on the sample indexing. We are working on improving the function. To keep you posted on the improvements, I have added you and Vladimir to the respective "bugs" in our bugzilla system. Through bugzilla you will receive an email when the issues are resolved so you know when to download an improved version that will work for you. best regards Robert On 24 Feb 2011, at 17:06, Vladimir Litvak wrote: > Hi Holly, > > I'm not sure why the databrowser needs the trl struct or whether we > can add something to our exported FT struct to make it happy. I'm > CCing to the Fieldtrip list to perhaps get some answers. I got exactly > the same complaint from someone else last week. > > > Best, > > Vladimir > > > On Thu, Feb 24, 2011 at 2:48 PM, Holly Rossiter > wrote: >> Hi Vladimir, >> >> >> >> I am trying out using ICA on my data to see what difference it makes to the >> eye blinks and whether it is a step worth doing or not. I am using a >> fieldtrip script... >> >> >> >> D= spm_eeg_load; >> >> data = D.ftraw(0); >> >> cfg = []; >> >> cfg.channel = 'MEG'; >> >> ic_data = ft_componentanalysis(cfg,data); >> >> cfg = []; >> >> cfg.viewmode = 'component'; >> >> cfg.continuous = 'yes'; >> >> cfg.layout = 'CTF275.lay'; >> >> cfg.blocksize = 30; >> >> cfg.channels = [1:10]; >> >> ft_databrowser(cfg,ic_data); >> >> >> >> But it comes up with an error saying >> >> >> >> Error using ==> ft_databrowser at 217 >> >> no trials to display >> >> >> >> I think this may be because I don’t have a trl matrix due to using >> spm_eeg_load. Do you know how I can create one of these using spm format >> data? Or how else to write the script so that ICA will work? >> >> >> >> Kind regards, >> >> >> >> Holly > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Sat Feb 26 14:26:40 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Sat, 26 Feb 2011 14:26:40 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Dear Jen, I do not manage to reproduce your issue, when only focussing on the ft_volumewrite and visualization part of your pipeline. See attached script, and yet an updated version of ft_volumewrite which you need to (hopefully) draw the same conclusion as I did. Yet, I only now realize that your question may pertain to the entire pipeline. It could be that something is going wrong there. I only see now that in the part of your script of which you reported that it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling ft_volumenormalise. I assume this is correct, because the coordinate system your source-reconstructed data lives in, is according to the CTF-convention, and not according to the SPM- convention. On the other hand, the template for the spatial normalization lives in the SPM-coordinate system. In order for the spatial normalization to work OK, Fieldtrip tries to convert from one coordinate system to the other (once again, this is appropriate behaviour), before doing the actual normalization. It seems that at least in the script you sent along, in the final (not working version), you specified cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is probably wrong. Another important point that should be mentioned, is that the coordinate systems in which the functional data and the anatomical data live should be the same for the ft_sourceinterpolate to make sense. In other words, if your source reconstructed images are defined on a 3D grid of positions in CTF-space, the mri.transform of your anatomy should describe a transformation from voxel to CTF-space. I think you may want to revisit step by step this part of the pipeline; I don't think the problem lies in the writing. A final possibility of course is that Mricron is misbehaving... Best, Jan-Mathijs On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > Hi Jan, > > I tried re-running the analysis with the new script you sent me, and > the latest version of fieldtrip (since I needed ft_get_opt as well), > but the spm8 images being written are still producing flawed > results. It's the same problem as I mentioned briefly in my previous > post. I am not getting any error messages when writing these images. > Rather, my problem is that the spm8 and spm2 results from the same > data ought to be identical when viewed in mricron, but they're far > from it. When I use mricron to look at the results from the spm8- > format images, combined across participants to create a t-image, I > just get a single 'blob' spanning roughly half the brain. In > contrast, when I used spm2-format previously on the same data, the t- > image was much more meaningful; a posterior alpha power decrease in > a set of regions corresponding to the 'task-positive network' (a > network found in the results of an fMRI version of my experiment, > and widely reported in the fMRI literature). > > This failure to replicate the spm2 results when using spm8 images > from the same data leads me to suspect that something is wrong with > the coordinates for spm8 format. However, after experimenting > extensively with different cfg options I still haven't identified > the problem. If I my structural MRIs have been saved to .mri files > using CTF's MRIConverter program, which cfg options, particularly > for coordinates, template images, and filetypes, should I specify > before calling the ft_volumesegment, ft_prepare_singleshell, > ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite > functions? Or should I be calling a different set of functions now? > > Thanks again for your help, > > Jen > > On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman > wrote: > Great, thanks! > > I'll start the analysis with your new script today and will let you > know how it works out. > > Jen > > On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I managed to reproduce your problem. The code was rather buggy and > indeed ft_volumewrite did not behave as it should have. I now fixed > it in the code and it should run fine now. Please find the updated > file attached. It will be available on our ftp-server as of tonight. > Please note that I updated the documentation, and changed the names > of some of the options a bit. If you want to save your data in > analyze-format, you should specify cfg.filetype = 'analyze_spm'. If > you specify cfg.filetype = 'nifti', it should write out a volume to > nifti-format, using SPM8. > > Best wishes, > > Jan-Mathijs > > > > > > On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > >> >> Dear Jan, >> >> Thanks for the quick reply. Yes, I have tried it out quite a few >> times now, experimenting with different settings in the cfgs. Below >> I'll paste the code I've been using to write images - first the >> code that successfully created spm2 images that produced good >> results, then the code used for creating nifti format images from >> the same data. The comments in this second part are at this point a >> bit of a maze of cfg options I've been changing back & forth. Any >> insights/suggestions regarding how to set up my cfgs to make this >> work would be greatly appreciated. >> >> Jen >> >> >> %%%%%%%% this code generated spm2-compatible images which did work >> (producing results that made sense). >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - >> sourcePre.avg.pow) ./ sourcePre.avg.pow; >> >> cfg = []; >> cfg.downsample = 2; >> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >> >> % projecting the plot onto a surface... >> cfg = []; >> cfg.coordinates = 'ctf'; >> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; >> %this template is in MNI coordinates >> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >> int2str(f) 'HzWin' int2str(win) 'width750ms']; >> cfg=[]; >> cfg.parameter = 'avg.pow'; % string, describing the >> functional data to be processed, e.g. 'pow', 'coh' or 'nai' >> cfg.filename = [filename '.img']; >> %'testimageoutput_alphafreq'; % filename without the extension >> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for >> interactive (default = []) >> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >> 'int16', 'int32', 'float' or 'double' >> >> volumewrite(cfg, sourcetempIntN) >> >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%% this code below hasn't worked yet... >> >> % I added cfg.spmversion = 'spm8'; >> % in the cfgs for the calls to ft_prepare_leadfield and >> ft_sourceanalysis, >> % and in the call to prepare_singleshell after calling volumesegment >> >> % I've also ensured that spm8 is the only spm version in my path, >> even in >> % the fieldtrip/external folder, and ensured that spm8 is installed >> properly >> % (files compiled correctly, etc..) >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - >> sourcePre.avg.pow) ./ sourcePre.avg.pow; >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >> int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >> >> cfg = []; >> % cfg.coordinates = 'spm'; % changed for version 5 >> % cfg.spmversion = 'spm8'; % changed for version 5 >> cfg.downsample = 4; >> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >> >> >> % projecting the plot onto a surface... >> cfg = []; >> %cfg.coordinates = 'spm'; % changed for version 5 >> %cfg.coordinates = 'ctf'; % changed for version 5 >> cfg.coordinates = 'spm'; % changed back to spm for version 9 >> cfg.downsample = 4; >> %cfg.spmversion = 'spm8'; % changed for version 6 (because this >> gets specified in volumewrite) >> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent >> to using spm8/templates/EPI.nii, except that mask.nii (produced >> from fmri data) has the desired voxel size >> % cfg.name = [filename]; % changed for version 6 >> %cfg.write= 'yes'; % changed for version 6 (when this was set >> to 'yes' there was no subsequent call to volumewrite) >> cfg.write= 'no'; % changed for version 6 >> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >> >> % this whole cfg and function call added for version 6 >> cfg=[]; >> % cfg.parameter = string, describing the functional data >> to be processed, e.g. 'pow', 'coh' or 'nai' >> % cfg.filename = filename without the extension >> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format >> to use >> % cfg.coordinates = 'spm, 'ctf' or empty for interactive >> (default = []) >> cfg.parameter='pow'; >> cfg.filename=filename; >> cfg.filetype = 'spm'; >> cfg.spmversion = 'SPM8'; % capitalized after first error >> message from vers 6 >> % cfg.dataformat='nifti'; % added after first error message from >> vers 6 >> % commented out after 2nd error >> message from vers 6 >> %cfg.vmpversion=2; % this is a filetype, like spm, so don't >> need to specify unless cfg.filetyp='vmp' >> cfg.coordinates='spm'; >> ft_volumewrite(cfg,sourcetempIntN); >> >> >> >> >> >> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > > wrote: >> Dear Jen, >> >> I notice that indeed in the documentation section of >> ft_write_volume there is a FIXME behind nifti. Yet, nifti format >> seems to be supported by ft_write_volume (at least in a recent >> version of fieldtrip). Did you try it at all (and ran into >> problems) or were you held back by the FIXME statement? Could you >> just try it out using a recent fieldtrip function? >> >> Thanks and best wishes >> >> Jan-Mathijs >> >> >> >> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >> >> Hello, >> >> While writing beamformed images to spm2 format in a previous >> version of fieldtrip (now lost due to a computer crash), I was able >> to get nice-looking results; networks of brain regions consistent >> with existing literature. When I try to write images from the same >> dataset and the same analysis to spm8 format, my results (t-images >> computed across subjects) end up being single clusters spanning >> large sections of the brain (e.g. a 'blob' spanning all of one >> hemisphere but not the other). Unfortunately, some aspects of my >> planned data analyses cannot be performed on spm2 images, so I have >> to find a way of writing to successfully to nifti format. >> >> I just noticed that in the comments in the ft_write_volume >> function, which I am calling via ft_volumewrite, it says 'FIXME' >> next to nifti under the list of supported dataformats. Is there by >> any chance a patch out there for writing nifti images? >> >> Thanks! >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_ft_write_volume.m Type: application/octet-stream Size: 1338 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ft_volumewrite.m Type: application/octet-stream Size: 17470 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Mon Feb 28 20:59:28 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Mon, 28 Feb 2011 11:59:28 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Hello Jan, When calling volumesegment, I specified 'ctf' as the coordinate system. The function I wrote to call volumesegment and prepare_singleshell for each subject and save the results is pasted below, with a couple of comments added for clarity. Over the weekend I tried specifying the coordinate system in the call to ft_volumenormalise as 'ctf' rather than 'spm', and commented out all the lines that said cfg.spmversion = 'spm8'; before calling a function. However, that created worse results, as each plot involved stripes of activation and empty voxels, suggesting that 'ctf' was not the correct coordinate system to specify. Thanks for the attached script. Looking in that the comments in that, I suspect that the solution to my problems will be to specify my filetype as nifti_img rather than nifti. I'll let you know how that goes. Jen ------------------------------------------------------------------------------------------------------------ % the variable subj is simply a string consisting of a subject number (e.g. 's05') which can be a folder name or part of a filename function [vol mri segmentedmri segmentedmriF]=call_volume_segment_function_spm8(subj) cfg.spmversion = 'spm8'; cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; cfg.name=[subj '_volseg']; cfg.write='yes'; cfg.smooth='no'; cfg.coordinates='ctf'; mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF mriConverter and mriViewer software, after fiducials were marked segmentedmri = volumesegment(cfg, mri); segmentedmriF = segmentedmri; segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3),2),1); segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3),2),1); segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3),2),1); segmentedmriF.transform = mri.transform; segmentedmriF.anatomy = mri.anatomy; cfg = []; cfg.spmversion = 'spm8'; vol = prepare_singleshell(cfg, segmentedmriF); eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri segmentedmriF vol']) On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I do not manage to reproduce your issue, when only focussing on the > ft_volumewrite and visualization part of your pipeline. See attached script, > and yet an updated version of ft_volumewrite which you need to (hopefully) > draw the same conclusion as I did. > Yet, I only now realize that your question may pertain to the entire > pipeline. It could be that something is going wrong there. > I only see now that in the part of your script of which you reported that > it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling > ft_volumenormalise. I assume this is correct, because the coordinate system > your source-reconstructed data lives in, is according to the CTF-convention, > and not according to the SPM-convention. On the other hand, the template for > the spatial normalization lives in the SPM-coordinate system. In order for > the spatial normalization to work OK, Fieldtrip tries to convert from one > coordinate system to the other (once again, this is appropriate behaviour), > before doing the actual normalization. It seems that at least in the script > you sent along, in the final (not working version), you specified > cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is > probably wrong. > Another important point that should be mentioned, is that the coordinate > systems in which the functional data and the anatomical data live should be > the same for the ft_sourceinterpolate to make sense. In other words, if your > source reconstructed images are defined on a 3D grid of positions in > CTF-space, the mri.transform of your anatomy should describe a > transformation from voxel to CTF-space. > I think you may want to revisit step by step this part of the pipeline; I > don't think the problem lies in the writing. > A final possibility of course is that Mricron is misbehaving... > > Best, > > Jan-Mathijs > > > > > > > On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > > Hi Jan, > > I tried re-running the analysis with the new script you sent me, and the > latest version of fieldtrip (since I needed ft_get_opt as well), but the > spm8 images being written are still producing flawed results. It's the same > problem as I mentioned briefly in my previous post. I am not getting any > error messages when writing these images. Rather, my problem is that the > spm8 and spm2 results from the same data ought to be identical when viewed > in mricron, but they're far from it. When I use mricron to look at the > results from the spm8-format images, combined across participants to create > a t-image, I just get a single 'blob' spanning roughly half the brain. In > contrast, when I used spm2-format previously on the same data, the t-image > was much more meaningful; a posterior alpha power decrease in a set of > regions corresponding to the 'task-positive network' (a network found in the > results of an fMRI version of my experiment, and widely reported in the fMRI > literature). > > This failure to replicate the spm2 results when using spm8 images from the > same data leads me to suspect that something is wrong with the coordinates > for spm8 format. However, after experimenting extensively with different cfg > options I still haven't identified the problem. If I my structural MRIs have > been saved to .mri files using CTF's MRIConverter program, which cfg > options, particularly for coordinates, template images, and filetypes, > should I specify before calling the ft_volumesegment, > ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and > ft_volumewrite functions? Or should I be calling a different set of > functions now? > > Thanks again for your help, > > Jen > > On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: > >> Great, thanks! >> >> I'll start the analysis with your new script today and will let you know >> how it works out. >> >> Jen >> >> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl> wrote: >> >>> Dear Jen, >>> >>> I managed to reproduce your problem. The code was rather buggy and indeed >>> ft_volumewrite did not behave as it should have. I now fixed it in the code >>> and it should run fine now. Please find the updated file attached. It will >>> be available on our ftp-server as of tonight. Please note that I updated the >>> documentation, and changed the names of some of the options a bit. If you >>> want to save your data in analyze-format, you should specify cfg.filetype = >>> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a >>> volume to nifti-format, using SPM8. >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> >>> >>> >>> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >>> >>> >>> Dear Jan, >>> >>> Thanks for the quick reply. Yes, I have tried it out quite a few times >>> now, experimenting with different settings in the cfgs. Below I'll paste the >>> code I've been using to write images - first the code that successfully >>> created spm2 images that produced good results, then the code used for >>> creating nifti format images from the same data. The comments in this second >>> part are at this point a bit of a maze of cfg options I've been changing >>> back & forth. Any insights/suggestions regarding how to set up my cfgs to >>> make this work would be greatly appreciated. >>> >>> Jen >>> >>> >>> %%%%%%%% this code generated spm2-compatible images which did work >>> (producing results that made sense). >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>> sourcePre.avg.pow; >>> >>> cfg = []; >>> cfg.downsample = 2; >>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> cfg.coordinates = 'ctf'; >>> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this >>> template is in MNI coordinates >>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>> 'HzWin' int2str(win) 'width750ms']; >>> cfg=[]; >>> cfg.parameter = 'avg.pow'; % string, describing the functional >>> data to be processed, e.g. 'pow', 'coh' or 'nai' >>> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; >>> % filename without the extension >>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >>> (default = []) >>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >>> 'int16', 'int32', 'float' or 'double' >>> >>> volumewrite(cfg, sourcetempIntN) >>> >>> >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%% this code below hasn't worked yet... >>> >>> % I added cfg.spmversion = 'spm8'; >>> % in the cfgs for the calls to ft_prepare_leadfield and >>> ft_sourceanalysis, >>> % and in the call to prepare_singleshell after calling volumesegment >>> >>> % I've also ensured that spm8 is the only spm version in my path, even in >>> % the fieldtrip/external folder, and ensured that spm8 is installed >>> properly >>> % (files compiled correctly, etc..) >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>> sourcePre.avg.pow; >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>> >>> cfg = []; >>> % cfg.coordinates = 'spm'; % changed for version 5 >>> % cfg.spmversion = 'spm8'; % changed for version 5 >>> cfg.downsample = 4; >>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>> >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> %cfg.coordinates = 'spm'; % changed for version 5 >>> %cfg.coordinates = 'ctf'; % changed for version 5 >>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>> cfg.downsample = 4; >>> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >>> specified in volumewrite) >>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to >>> using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) >>> has the desired voxel size >>> % cfg.name = [filename]; % changed for version 6 >>> %cfg.write= 'yes'; % changed for version 6 (when this was set to >>> 'yes' there was no subsequent call to volumewrite) >>> cfg.write= 'no'; % changed for version 6 >>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>> >>> % this whole cfg and function call added for version 6 >>> cfg=[]; >>> % cfg.parameter = string, describing the functional data to be >>> processed, e.g. 'pow', 'coh' or 'nai' >>> % cfg.filename = filename without the extension >>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use >>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >>> []) >>> cfg.parameter='pow'; >>> cfg.filename=filename; >>> cfg.filetype = 'spm'; >>> cfg.spmversion = 'SPM8'; % capitalized after first error message from >>> vers 6 >>> % cfg.dataformat='nifti'; % added after first error message from vers >>> 6 >>> % commented out after 2nd error message >>> from vers 6 >>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >>> specify unless cfg.filetyp='vmp' >>> cfg.coordinates='spm'; >>> ft_volumewrite(cfg,sourcetempIntN); >>> >>> >>> >>> >>> >>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >>> jan.schoffelen at donders.ru.nl> wrote: >>> >>>> Dear Jen, >>>> >>>> I notice that indeed in the documentation section of ft_write_volume >>>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>>> at all (and ran into problems) or were you held back by the FIXME statement? >>>> Could you just try it out using a recent fieldtrip function? >>>> >>>> Thanks and best wishes >>>> >>>> Jan-Mathijs >>>> >>>> >>>> >>>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>>> >>>> Hello, >>>>> >>>>> While writing beamformed images to spm2 format in a previous version of >>>>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>>>> results; networks of brain regions consistent with existing literature. When >>>>> I try to write images from the same dataset and the same analysis to spm8 >>>>> format, my results (t-images computed across subjects) end up being single >>>>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>>>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>>>> data analyses cannot be performed on spm2 images, so I have to find a way of >>>>> writing to successfully to nifti format. >>>>> >>>>> I just noticed that in the comments in the ft_write_volume function, >>>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>>> the list of supported dataformats. Is there by any chance a patch out there >>>>> for writing nifti images? >>>>> >>>>> Thanks! >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>> Donders Institute for Brain, Cognition and Behaviour, >>>> Centre for Cognitive Neuroimaging, >>>> Radboud University Nijmegen, The Netherlands >>>> J.Schoffelen at donders.ru.nl >>>> Telephone: 0031-24-3614793 >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Mon Feb 28 21:36:17 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Mon, 28 Feb 2011 21:36:17 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: <7F6275BA-C597-4E11-958C-9E944F27F6C4@donders.ru.nl> Hi Jen, At first glance I have a comment on your script. You may need to explicitly check the alignment of your segmented volume and the original anatomy. A while a go some changes were made to ft_volumesegment, taking away the need to do the flipdim(flipdim... operations. I have posted this on the discussion list last January, but you may not have noticed. Anyway, if you now have used a recent version of FieldTrip for your segmentation both the location of your dipole grid, and the volume conductor model will not be adequately coregistered with the data, which may lead to funky results to begin with. That's most likely not related to the filetype in which the volumes are saved for later use. Best wishes, Jan-Mathijs On Feb 28, 2011, at 8:59 PM, Jen Whitman wrote: > Hello Jan, > > When calling volumesegment, I specified 'ctf' as the coordinate > system. The function I wrote to call volumesegment and > prepare_singleshell for each subject and save the results is pasted > below, with a couple of comments added for clarity. > Over the weekend I tried specifying the coordinate system in the > call to ft_volumenormalise as 'ctf' rather than 'spm', and commented > out all the lines that said cfg.spmversion = 'spm8'; before calling > a function. However, that created worse results, as each plot > involved stripes of activation and empty voxels, suggesting that > 'ctf' was not the correct coordinate system to specify. > > Thanks for the attached script. Looking in that the comments in > that, I suspect that the solution to my problems will be to specify > my filetype as nifti_img rather than nifti. I'll let you know how > that goes. > > Jen > > ------------------------------------------------------------------------------------------------------------ > % the variable subj is simply a string consisting of a subject > number (e.g. 's05') which can be a folder name or part of a filename > function [vol mri segmentedmri > segmentedmriF]=call_volume_segment_function_spm8(subj) > cfg.spmversion = 'spm8'; > cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; > %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; > cfg.name=[subj '_volseg']; > cfg.write='yes'; > cfg.smooth='no'; > cfg.coordinates='ctf'; > mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF > mriConverter and mriViewer software, after fiducials were marked > segmentedmri = volumesegment(cfg, mri); > segmentedmriF = segmentedmri; > segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3), > 2),1); > segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3), > 2),1); > segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3), > 2),1); > segmentedmriF.transform = mri.transform; > segmentedmriF.anatomy = mri.anatomy; > cfg = []; > cfg.spmversion = 'spm8'; > vol = prepare_singleshell(cfg, segmentedmriF); > eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri > segmentedmriF vol']) > > > > On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I do not manage to reproduce your issue, when only focussing on the > ft_volumewrite and visualization part of your pipeline. See attached > script, and yet an updated version of ft_volumewrite which you need > to (hopefully) draw the same conclusion as I did. > Yet, I only now realize that your question may pertain to the entire > pipeline. It could be that something is going wrong there. > I only see now that in the part of your script of which you reported > that it gave 'good' results, you specify cfg.coordinates = 'ctf' > before calling ft_volumenormalise. I assume this is correct, because > the coordinate system your source-reconstructed data lives in, is > according to the CTF-convention, and not according to the SPM- > convention. On the other hand, the template for the spatial > normalization lives in the SPM-coordinate system. In order for the > spatial normalization to work OK, Fieldtrip tries to convert from > one coordinate system to the other (once again, this is appropriate > behaviour), before doing the actual normalization. It seems that at > least in the script you sent along, in the final (not working > version), you specified cfg.coordinates = 'spm' prior to calling > ft_volumenormalise. This is probably wrong. > Another important point that should be mentioned, is that the > coordinate systems in which the functional data and the anatomical > data live should be the same for the ft_sourceinterpolate to make > sense. In other words, if your source reconstructed images are > defined on a 3D grid of positions in CTF-space, the mri.transform of > your anatomy should describe a transformation from voxel to CTF-space. > I think you may want to revisit step by step this part of the > pipeline; I don't think the problem lies in the writing. > A final possibility of course is that Mricron is misbehaving... > > Best, > > Jan-Mathijs > > > > > > > On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > >> Hi Jan, >> >> I tried re-running the analysis with the new script you sent me, >> and the latest version of fieldtrip (since I needed ft_get_opt as >> well), but the spm8 images being written are still producing flawed >> results. It's the same problem as I mentioned briefly in my >> previous post. I am not getting any error messages when writing >> these images. Rather, my problem is that the spm8 and spm2 results >> from the same data ought to be identical when viewed in mricron, >> but they're far from it. When I use mricron to look at the results >> from the spm8-format images, combined across participants to create >> a t-image, I just get a single 'blob' spanning roughly half the >> brain. In contrast, when I used spm2-format previously on the same >> data, the t-image was much more meaningful; a posterior alpha power >> decrease in a set of regions corresponding to the 'task-positive >> network' (a network found in the results of an fMRI version of my >> experiment, and widely reported in the fMRI literature). >> >> This failure to replicate the spm2 results when using spm8 images >> from the same data leads me to suspect that something is wrong with >> the coordinates for spm8 format. However, after experimenting >> extensively with different cfg options I still haven't identified >> the problem. If I my structural MRIs have been saved to .mri files >> using CTF's MRIConverter program, which cfg options, particularly >> for coordinates, template images, and filetypes, should I specify >> before calling the ft_volumesegment, ft_prepare_singleshell, >> ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite >> functions? Or should I be calling a different set of functions now? >> >> Thanks again for your help, >> >> Jen >> >> On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman >> wrote: >> Great, thanks! >> >> I'll start the analysis with your new script today and will let you >> know how it works out. >> >> Jen >> >> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen > > wrote: >> Dear Jen, >> >> I managed to reproduce your problem. The code was rather buggy and >> indeed ft_volumewrite did not behave as it should have. I now fixed >> it in the code and it should run fine now. Please find the updated >> file attached. It will be available on our ftp-server as of >> tonight. Please note that I updated the documentation, and changed >> the names of some of the options a bit. If you want to save your >> data in analyze-format, you should specify cfg.filetype = >> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should >> write out a volume to nifti-format, using SPM8. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> >> >> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >> >>> >>> Dear Jan, >>> >>> Thanks for the quick reply. Yes, I have tried it out quite a few >>> times now, experimenting with different settings in the cfgs. >>> Below I'll paste the code I've been using to write images - first >>> the code that successfully created spm2 images that produced good >>> results, then the code used for creating nifti format images from >>> the same data. The comments in this second part are at this point >>> a bit of a maze of cfg options I've been changing back & forth. >>> Any insights/suggestions regarding how to set up my cfgs to make >>> this work would be greatly appreciated. >>> >>> Jen >>> >>> >>> %%%%%%%% this code generated spm2-compatible images which did work >>> (producing results that made sense). >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - >>> sourcePre.avg.pow) ./ sourcePre.avg.pow; >>> >>> cfg = []; >>> cfg.downsample = 2; >>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> cfg.coordinates = 'ctf'; >>> cfg.template = '/home/common/matlab/spm2/templates/ >>> T1.mnc'; %this template is in MNI coordinates >>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >>> int2str(f) 'HzWin' int2str(win) 'width750ms']; >>> cfg=[]; >>> cfg.parameter = 'avg.pow'; % string, describing the >>> functional data to be processed, e.g. 'pow', 'coh' or 'nai' >>> cfg.filename = [filename '.img']; >>> %'testimageoutput_alphafreq'; % filename without the extension >>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for >>> interactive (default = []) >>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', >>> 'uint8', 'int16', 'int32', 'float' or 'double' >>> >>> volumewrite(cfg, sourcetempIntN) >>> >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%% this code below hasn't worked yet... >>> >>> % I added cfg.spmversion = 'spm8'; >>> % in the cfgs for the calls to ft_prepare_leadfield and >>> ft_sourceanalysis, >>> % and in the call to prepare_singleshell after calling volumesegment >>> >>> % I've also ensured that spm8 is the only spm version in my path, >>> even in >>> % the fieldtrip/external folder, and ensured that spm8 is >>> installed properly >>> % (files compiled correctly, etc..) >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - >>> sourcePre.avg.pow) ./ sourcePre.avg.pow; >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >>> int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>> >>> cfg = []; >>> % cfg.coordinates = 'spm'; % changed for version 5 >>> % cfg.spmversion = 'spm8'; % changed for version 5 >>> cfg.downsample = 4; >>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>> >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> %cfg.coordinates = 'spm'; % changed for version 5 >>> %cfg.coordinates = 'ctf'; % changed for version 5 >>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>> cfg.downsample = 4; >>> %cfg.spmversion = 'spm8'; % changed for version 6 (because >>> this gets specified in volumewrite) >>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent >>> to using spm8/templates/EPI.nii, except that mask.nii (produced >>> from fmri data) has the desired voxel size >>> % cfg.name = [filename]; % changed for version 6 >>> %cfg.write= 'yes'; % changed for version 6 (when this was set >>> to 'yes' there was no subsequent call to volumewrite) >>> cfg.write= 'no'; % changed for version 6 >>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>> >>> % this whole cfg and function call added for version 6 >>> cfg=[]; >>> % cfg.parameter = string, describing the functional data >>> to be processed, e.g. 'pow', 'coh' or 'nai' >>> % cfg.filename = filename without the extension >>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format >>> to use >>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive >>> (default = []) >>> cfg.parameter='pow'; >>> cfg.filename=filename; >>> cfg.filetype = 'spm'; >>> cfg.spmversion = 'SPM8'; % capitalized after first error >>> message from vers 6 >>> % cfg.dataformat='nifti'; % added after first error message >>> from vers 6 >>> % commented out after 2nd error >>> message from vers 6 >>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't >>> need to specify unless cfg.filetyp='vmp' >>> cfg.coordinates='spm'; >>> ft_volumewrite(cfg,sourcetempIntN); >>> >>> >>> >>> >>> >>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen >> > wrote: >>> Dear Jen, >>> >>> I notice that indeed in the documentation section of >>> ft_write_volume there is a FIXME behind nifti. Yet, nifti format >>> seems to be supported by ft_write_volume (at least in a recent >>> version of fieldtrip). Did you try it at all (and ran into >>> problems) or were you held back by the FIXME statement? Could you >>> just try it out using a recent fieldtrip function? >>> >>> Thanks and best wishes >>> >>> Jan-Mathijs >>> >>> >>> >>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>> >>> Hello, >>> >>> While writing beamformed images to spm2 format in a previous >>> version of fieldtrip (now lost due to a computer crash), I was >>> able to get nice-looking results; networks of brain regions >>> consistent with existing literature. When I try to write images >>> from the same dataset and the same analysis to spm8 format, my >>> results (t-images computed across subjects) end up being single >>> clusters spanning large sections of the brain (e.g. a 'blob' >>> spanning all of one hemisphere but not the other). Unfortunately, >>> some aspects of my planned data analyses cannot be performed on >>> spm2 images, so I have to find a way of writing to successfully to >>> nifti format. >>> >>> I just noticed that in the comments in the ft_write_volume >>> function, which I am calling via ft_volumewrite, it says 'FIXME' >>> next to nifti under the list of supported dataformats. Is there by >>> any chance a patch out there for writing nifti images? >>> >>> Thanks! >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> _______________________________________________ >>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Mon Feb 28 22:32:16 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Mon, 28 Feb 2011 13:32:16 -0800 Subject: [FieldTrip] I think you solved the problem Message-ID: I just checked, and when I re-ran my segmentation script with the new Fieldtrip in order to use an spm8 template image, coordinates got reversed. When I take out the calls to flipdim, they look fine (see attached screenshots). That certainly explains the meaningless results I was getting! Thanks for figuring that out, Jen On Mon, Feb 28, 2011 at 12:36 PM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Hi Jen, > > At first glance I have a comment on your script. You may need to explicitly > check the alignment of your segmented volume and the original anatomy. A > while a go some changes were made to ft_volumesegment, taking away the need > to do the flipdim(flipdim... operations. I have posted this on the > discussion list last January, but you may not have noticed. > Anyway, if you now have used a recent version of FieldTrip for your > segmentation both the location of your dipole grid, and the volume conductor > model will not be adequately coregistered with the data, which may lead to > funky results to begin with. That's most likely not related to the filetype > in which the volumes are saved for later use. > > Best wishes, > > Jan-Mathijs > > > > On Feb 28, 2011, at 8:59 PM, Jen Whitman wrote: > > Hello Jan, > > When calling volumesegment, I specified 'ctf' as the coordinate system. The > function I wrote to call volumesegment and prepare_singleshell for each > subject and save the results is pasted below, with a couple of comments > added for clarity. > Over the weekend I tried specifying the coordinate system in the call to > ft_volumenormalise as 'ctf' rather than 'spm', and commented out all the > lines that said cfg.spmversion = 'spm8'; before calling a function. However, > that created worse results, as each plot involved stripes of activation and > empty voxels, suggesting that 'ctf' was not the correct coordinate system to > specify. > > Thanks for the attached script. Looking in that the comments in that, I > suspect that the solution to my problems will be to specify my filetype as > nifti_img rather than nifti. I'll let you know how that goes. > > Jen > > > ------------------------------------------------------------------------------------------------------------ > % the variable subj is simply a string consisting of a subject number (e.g. > 's05') which can be a folder name or part of a filename > function [vol mri segmentedmri > segmentedmriF]=call_volume_segment_function_spm8(subj) > cfg.spmversion = 'spm8'; > cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; > %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; > cfg.name=[subj '_volseg']; > cfg.write='yes'; > cfg.smooth='no'; > cfg.coordinates='ctf'; > mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF mriConverter > and mriViewer software, after fiducials were marked > segmentedmri = volumesegment(cfg, mri); > segmentedmriF = segmentedmri; > segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3),2),1); > segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3),2),1); > segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3),2),1); > segmentedmriF.transform = mri.transform; > segmentedmriF.anatomy = mri.anatomy; > cfg = []; > cfg.spmversion = 'spm8'; > vol = prepare_singleshell(cfg, segmentedmriF); > eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri segmentedmriF > vol']) > > > > On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I do not manage to reproduce your issue, when only focussing on the >> ft_volumewrite and visualization part of your pipeline. See attached script, >> and yet an updated version of ft_volumewrite which you need to (hopefully) >> draw the same conclusion as I did. >> Yet, I only now realize that your question may pertain to the entire >> pipeline. It could be that something is going wrong there. >> I only see now that in the part of your script of which you reported that >> it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling >> ft_volumenormalise. I assume this is correct, because the coordinate system >> your source-reconstructed data lives in, is according to the CTF-convention, >> and not according to the SPM-convention. On the other hand, the template for >> the spatial normalization lives in the SPM-coordinate system. In order for >> the spatial normalization to work OK, Fieldtrip tries to convert from one >> coordinate system to the other (once again, this is appropriate behaviour), >> before doing the actual normalization. It seems that at least in the script >> you sent along, in the final (not working version), you specified >> cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is >> probably wrong. >> Another important point that should be mentioned, is that the coordinate >> systems in which the functional data and the anatomical data live should be >> the same for the ft_sourceinterpolate to make sense. In other words, if your >> source reconstructed images are defined on a 3D grid of positions in >> CTF-space, the mri.transform of your anatomy should describe a >> transformation from voxel to CTF-space. >> I think you may want to revisit step by step this part of the pipeline; I >> don't think the problem lies in the writing. >> A final possibility of course is that Mricron is misbehaving... >> >> Best, >> >> Jan-Mathijs >> >> >> >> >> >> >> On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: >> >> Hi Jan, >> >> I tried re-running the analysis with the new script you sent me, and the >> latest version of fieldtrip (since I needed ft_get_opt as well), but the >> spm8 images being written are still producing flawed results. It's the same >> problem as I mentioned briefly in my previous post. I am not getting any >> error messages when writing these images. Rather, my problem is that the >> spm8 and spm2 results from the same data ought to be identical when viewed >> in mricron, but they're far from it. When I use mricron to look at the >> results from the spm8-format images, combined across participants to create >> a t-image, I just get a single 'blob' spanning roughly half the brain. In >> contrast, when I used spm2-format previously on the same data, the t-image >> was much more meaningful; a posterior alpha power decrease in a set of >> regions corresponding to the 'task-positive network' (a network found in the >> results of an fMRI version of my experiment, and widely reported in the fMRI >> literature). >> >> This failure to replicate the spm2 results when using spm8 images from the >> same data leads me to suspect that something is wrong with the coordinates >> for spm8 format. However, after experimenting extensively with different cfg >> options I still haven't identified the problem. If I my structural MRIs have >> been saved to .mri files using CTF's MRIConverter program, which cfg >> options, particularly for coordinates, template images, and filetypes, >> should I specify before calling the ft_volumesegment, >> ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and >> ft_volumewrite functions? Or should I be calling a different set of >> functions now? >> >> Thanks again for your help, >> >> Jen >> >> On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: >> >>> Great, thanks! >>> >>> I'll start the analysis with your new script today and will let you know >>> how it works out. >>> >>> Jen >>> >>> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < >>> jan.schoffelen at donders.ru.nl> wrote: >>> >>>> Dear Jen, >>>> >>>> I managed to reproduce your problem. The code was rather buggy and >>>> indeed ft_volumewrite did not behave as it should have. I now fixed it in >>>> the code and it should run fine now. Please find the updated file attached. >>>> It will be available on our ftp-server as of tonight. Please note that I >>>> updated the documentation, and changed the names of some of the options a >>>> bit. If you want to save your data in analyze-format, you should specify >>>> cfg.filetype = 'analyze_spm'. If you specify cfg.filetype = 'nifti', it >>>> should write out a volume to nifti-format, using SPM8. >>>> >>>> Best wishes, >>>> >>>> Jan-Mathijs >>>> >>>> >>>> >>>> >>>> >>>> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >>>> >>>> >>>> Dear Jan, >>>> >>>> Thanks for the quick reply. Yes, I have tried it out quite a few times >>>> now, experimenting with different settings in the cfgs. Below I'll paste the >>>> code I've been using to write images - first the code that successfully >>>> created spm2 images that produced good results, then the code used for >>>> creating nifti format images from the same data. The comments in this second >>>> part are at this point a bit of a maze of cfg options I've been changing >>>> back & forth. Any insights/suggestions regarding how to set up my cfgs to >>>> make this work would be greatly appreciated. >>>> >>>> Jen >>>> >>>> >>>> %%%%%%%% this code generated spm2-compatible images which did work >>>> (producing results that made sense). >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>>> sourcePre.avg.pow; >>>> >>>> cfg = []; >>>> cfg.downsample = 2; >>>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>>> >>>> % projecting the plot onto a surface... >>>> cfg = []; >>>> cfg.coordinates = 'ctf'; >>>> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; >>>> %this template is in MNI coordinates >>>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>>> >>>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>>> 'HzWin' int2str(win) 'width750ms']; >>>> cfg=[]; >>>> cfg.parameter = 'avg.pow'; % string, describing the functional >>>> data to be processed, e.g. 'pow', 'coh' or 'nai' >>>> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; >>>> % filename without the extension >>>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >>>> (default = []) >>>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >>>> 'int16', 'int32', 'float' or 'double' >>>> >>>> volumewrite(cfg, sourcetempIntN) >>>> >>>> >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> %%%%% this code below hasn't worked yet... >>>> >>>> % I added cfg.spmversion = 'spm8'; >>>> % in the cfgs for the calls to ft_prepare_leadfield and >>>> ft_sourceanalysis, >>>> % and in the call to prepare_singleshell after calling volumesegment >>>> >>>> % I've also ensured that spm8 is the only spm version in my path, even >>>> in >>>> % the fieldtrip/external folder, and ensured that spm8 is installed >>>> properly >>>> % (files compiled correctly, etc..) >>>> >>>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>>> sourcePre.avg.pow; >>>> >>>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>>> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>>> >>>> cfg = []; >>>> % cfg.coordinates = 'spm'; % changed for version 5 >>>> % cfg.spmversion = 'spm8'; % changed for version 5 >>>> cfg.downsample = 4; >>>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>>> >>>> >>>> % projecting the plot onto a surface... >>>> cfg = []; >>>> %cfg.coordinates = 'spm'; % changed for version 5 >>>> %cfg.coordinates = 'ctf'; % changed for version 5 >>>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>>> cfg.downsample = 4; >>>> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >>>> specified in volumewrite) >>>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to >>>> using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) >>>> has the desired voxel size >>>> % cfg.name = [filename]; % changed for version 6 >>>> %cfg.write= 'yes'; % changed for version 6 (when this was set to >>>> 'yes' there was no subsequent call to volumewrite) >>>> cfg.write= 'no'; % changed for version 6 >>>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>>> >>>> % this whole cfg and function call added for version 6 >>>> cfg=[]; >>>> % cfg.parameter = string, describing the functional data to be >>>> processed, e.g. 'pow', 'coh' or 'nai' >>>> % cfg.filename = filename without the extension >>>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to >>>> use >>>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >>>> []) >>>> cfg.parameter='pow'; >>>> cfg.filename=filename; >>>> cfg.filetype = 'spm'; >>>> cfg.spmversion = 'SPM8'; % capitalized after first error message >>>> from vers 6 >>>> % cfg.dataformat='nifti'; % added after first error message from vers >>>> 6 >>>> % commented out after 2nd error message >>>> from vers 6 >>>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >>>> specify unless cfg.filetyp='vmp' >>>> cfg.coordinates='spm'; >>>> ft_volumewrite(cfg,sourcetempIntN); >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >>>> jan.schoffelen at donders.ru.nl> wrote: >>>> >>>>> Dear Jen, >>>>> >>>>> I notice that indeed in the documentation section of ft_write_volume >>>>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>>>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>>>> at all (and ran into problems) or were you held back by the FIXME statement? >>>>> Could you just try it out using a recent fieldtrip function? >>>>> >>>>> Thanks and best wishes >>>>> >>>>> Jan-Mathijs >>>>> >>>>> >>>>> >>>>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>>>> >>>>> Hello, >>>>>> >>>>>> While writing beamformed images to spm2 format in a previous version >>>>>> of fieldtrip (now lost due to a computer crash), I was able to get >>>>>> nice-looking results; networks of brain regions consistent with existing >>>>>> literature. When I try to write images from the same dataset and the same >>>>>> analysis to spm8 format, my results (t-images computed across subjects) end >>>>>> up being single clusters spanning large sections of the brain (e.g. a 'blob' >>>>>> spanning all of one hemisphere but not the other). Unfortunately, some >>>>>> aspects of my planned data analyses cannot be performed on spm2 images, so I >>>>>> have to find a way of writing to successfully to nifti format. >>>>>> >>>>>> I just noticed that in the comments in the ft_write_volume function, >>>>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>>>> the list of supported dataformats. Is there by any chance a patch out there >>>>>> for writing nifti images? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>> >>>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>>> Donders Institute for Brain, Cognition and Behaviour, >>>>> Centre for Cognitive Neuroimaging, >>>>> Radboud University Nijmegen, The Netherlands >>>>> J.Schoffelen at donders.ru.nl >>>>> Telephone: 0031-24-3614793 >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>> Donders Institute for Brain, Cognition and Behaviour, >>>> Centre for Cognitive Neuroimaging, >>>> Radboud University Nijmegen, The Netherlands >>>> J.Schoffelen at donders.ru.nl >>>> Telephone: 0031-24-3614793 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: volumesegmentspm8.png Type: image/png Size: 141551 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fixedvolumesegmentspm8.png Type: image/png Size: 78944 bytes Desc: not available URL: From lsbarbosa at gmail.com Tue Feb 1 03:05:59 2011 From: lsbarbosa at gmail.com (Leonardo Barbosa) Date: Tue, 1 Feb 2011 00:05:59 -0200 Subject: [FieldTrip] Forward model for dipoles with fixed position and orientation Message-ID: Dear Fieldtrip users, I'm trying to create a forward model for a fixed number of dipoles with fixed positions and orientations (extracted from a MRI image using freesurfer and a downsampling algorithm) so I can use it with my inverse algorithm. I read this tutorial , a few examplesand function headers , but I still didn't find exactly what I'm trying to do. Is it possible to have as a result of *ft_compute_leadfield*, (and*ft_prepare_leadfield *?,* ft_prepare_sourcemodel*?) a leadfield that depends only on the *intensity* of the dipole? Because it has a fixed orientation, and the idea is exactly reduce the number of unknowns. I noticed that SPM creates what I'm trying to do (as copied below), but I'm trying to stay within fieldtrip definitions so I can use it's inverse solutions to compare with mine, although I only found examples for beamformers inverse solutions, and not sparse methods. So this is the second question: is there any example of source-space based sparse methods inverse solutions? Thanks in advance for any help, Best Regards Leonardo Barbosa Here is the SPM code (inside *spm_eeg_lgainmat*) % Forward computation %-------------------------------------------------------------------------- [vol, sens] = forwinv_prepare_vol_sens(vol, sens, 'channel', forward(ind).channels); nvert = size(vert, 1); spm('Pointer', 'Watch');drawnow; spm_progress_bar('Init', nvert, ['Computing ' modality ' leadfields']); drawnow; if nvert > 100, Ibar = floor(linspace(1, nvert,100)); else Ibar = [1:nvert]; end Gxyz = zeros(length(forward(ind).channels), 3*nvert); for i = 1:nvert Gxyz(:, (3*i- 2):(3*i)) = forwinv_compute_leadfield(vert(i, :), sens, vol); if ismember(i, Ibar) spm_progress_bar('Set', i); drawnow; end end spm_progress_bar('Clear'); spm_progress_bar('Init', nvert, ['Orienting ' modality ' leadfields']); drawnow; G{ind} = zeros(size(Gxyz, 1), size(Gxyz, 2)/3); for i = 1:nvert G{ind}(:, i) = Gxyz(:, (3*i- 2):(3*i))*norm(i, :)'; if ismember(i, Ibar) spm_progress_bar('Set', i); drawnow; end end spm_progress_bar('Clear'); -------------- next part -------------- An HTML attachment was scrubbed... URL: From inbalots at gmail.com Tue Feb 1 14:09:08 2011 From: inbalots at gmail.com (Inbal Lots) Date: Tue, 1 Feb 2011 15:09:08 +0200 Subject: [FieldTrip] question about using ft_multiplot for my own needs Message-ID: Hello I have a data matrix (in Matlab, at size of [channel num X 30 X 8] ) that holds some values I calculated for *each channel*. Is it possible to use your ft_multiplot (or any other function) to display the plots of *all channels* in their original layout? similar to the ft_multiplotER ? My aim is to plot (for each channel) 8 plots on the same axes (similar to using hold on, or plot([x1,y1],[x2,y2] ,...[x8,y8]) where each xi and yi have 30 indexes and to display it all in the layout of all channels together (similar to the ft_multiplotER, with cfg.layout='4D248.lay';). Is it possible? how can I do that? can I "zoom in" or display a selected channels- similar to the cfg.interactive='yes'; option? thanks Inbal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Patricia.Wollstadt at gmx.de Tue Feb 1 16:34:04 2011 From: Patricia.Wollstadt at gmx.de (Patricia Wollstadt) Date: Tue, 01 Feb 2011 16:34:04 +0100 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net>, <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> Message-ID: <20110201153404.267000@gmx.net> Hi Michael, Hi Jan-Mathijs, thank you very much for the advice/clarification. Everything seems to run fine now (with the corrected design). Thank you very much, Best Patricia -------- Original-Nachricht -------- > Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > Von: "Michael Wibral" > An: "Email discussion list for the FieldTrip project" > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > Hi Patricia, > > I also would have thought your design to be correct. Maybe the > unneccessary specification of the uvar screws thinsg up?? > > However, you really do not have any repeated measures in your design - > here the output of FT is correct. I interpret it in the following way: You > specified cfg.uvar - indicating to FT the possibility that this might be a > repeated measures design. FT identified the units of observation as being 80 > (correct), and then checked how many repeated measures you ran in each UO > and found just 1 - which is also correct. I agree that naming the units of > observation (UO) as 'levels' of the UO variable is a bit odd, should rather > be 'units of observation'. > > The concept of repeated measures is also very often misunderstood: in > repated measures you do not actually repeat anything, rather you perform > different measurements (treatments) WITHIN a unit of observation - so a repated > measures design is a within UO design. Your subjects just have one age, so > there are no different treatments (levels of the indep variable) per > subjects and, hence, no 'repeated measures'. > > Hope this clarifies terminology for further discussion. > > Michael > > > -----Ursprüngliche Nachricht----- > Von: "jan-mathijs schoffelen" > Gesendet: Jan 25, 2011 8:57:03 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >Hi Patricia, > > > >I don't really understand what is going on, but could you try to > >specify your design only in a single row (design = design(2,:) in your > >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how > >it runs? As such the uvar row is not relevant in an independent > >samples design. > > > >Best, > > > >Jan-Mathijs > > > > > > > >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > > > >> Dear all, > >> > >> I'm still trying to identify the underlying reason for the issue > >> described below. I ran the analysis in debug mode (I'm using > >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) > >> and found that the matrix 'resample', that is generated in > >> 'statistics_montecarlo', line 187: > >> > >> resample = resampledesign(cfg, design); > >> > >> doesn't contain actual permutations of my initial design, but rather > >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is > >> no permutation of the units of observation) the 'randstat' that is > >> subsequently calculated for each row of the resample-matrix is > >> always the same. > >> Is this maybe due to my design and my units of observations > >> respectively? I am looking at age-dependent variations in resting- > >> state data, so my UO are 80 subjects, divided into four age groups. > >> The commandline-output of the 'resampledesign'-function is as follows: > >> > >> total number of measurements = 80 > >> total number of variables = 2 > >> number of independent variables = 1 > >> number of unit variables = 1 > >> number of within-cell variables = 0 > >> number of control variables = 0 > >> using a permutation resampling approach > >> repeated measurement in variable 1 over 80 levels > >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 > >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> 1 1 > >> > >> > >> Is this correct? Shouldn't this read 'repeated measurement in > >> variable 2 over 4 levels' with the number of subjects per group as > >> repeated measurements within a condition? Still I am pretty sure > >> about my design matrix, which contains the indices 1 to 80 (for all > >> subjects) in the first row (this is my cfg.uvar) with the > >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > >> my previous email below). I use an 'indepsamplesF'-statistic, since > >> I am comparing between four groups of different subjects (averaged > >> over trials). > >> > >> I hope, I got the settings and my design right. Any suggestions, > >> whether this is a problem due to wrong configurations in my script > >> are very welcome. > >> > >> Right now I work around this issue by replacing line 279 in > >> 'statistics_montecarlo': > >> > >> tmpdesign = design(:,resample(i,:)); > >> > >> with: > >> > >> tmpdesign = design(:,randperm(size(design,2))); > >> > >> creating permutations of my design 'by hand'. Is this acceptable or > >> is there anything I'm maybe missing. > >> > >> Thank you very much, kind regards, > >> > >> Patricia > >> > >> > >> > >> > >> -------- Original-Nachricht -------- > >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > >>> Von: "Patricia Wollstadt" > >>> An: fieldtrip at donders.ru.nl > >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > >> > >>> Dear Fieldtrip-users, > >>> > >>> I'm currently trying to calculate freqstatistics for four > >>> experimental > >>> groups, using the following options: > >>> > >>> groupSize=[length(subjects{1}) length(subjects{2}) > >>> length(subjects{3}) > >>> length(subjects{4})]; > >>> > >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > >>> % 1 to N subjects > >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > >>> group membership > >>> > >>> > >>> cfg=[]; > >>> cfg.design=design; > >>> cfg.uvar = 1; > >>> cfg.ivar = 2; > >>> cfg.method = 'montecarlo'; > >>> cfg.statistic = 'indepsamplesF'; > >>> cfg.correctm = 'fdr'; > >>> cfg.numrandomization = 180000; > >>> cfg.alpha = 0.01/7; > >>> cfg.tail = 1; > >>> cfg.design = design; > >>> cfg.channels = myChannels; > >>> cfg.avgovertime = 'yes'; > >>> cfg.avgoverfreq = 'yes'; > >>> cfg.frequency = [1 3]; > >>> > >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > >>> group4avg); > >>> > >>> With these settings, the coputation itself runs fine, but the > >>> resulting > >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > >>> consists of > >>> only ones). This would mean, that I found significant effects for all > >>> channels. Is this possible or rather due to an error somewhere in > >>> my script? Is > >>> it likely, that these are 'real' zeroes or rather very small > >>> values, close > >>> to zero? > >>> Any hints and suggestions are very welcome, thank you in advance, > >>> > >>> Kind regards > >>> > >>> Patricia Wollstadt > >>> > >>> > >>> -- > >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >>> _______________________________________________ > >>> fieldtrip mailing list > >>> fieldtrip at donders.ru.nl > >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > >> -- > >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > >> _______________________________________________ > >> fieldtrip mailing list > >> fieldtrip at donders.ru.nl > >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >Dr. J.M. (Jan-Mathijs) Schoffelen > >Donders Institute for Brain, Cognition and Behaviour, > >Centre for Cognitive Neuroimaging, > >Radboud University Nijmegen, The Netherlands > >J.Schoffelen at donders.ru.nl > >Telephone: 0031-24-3614793 > > > >_______________________________________________ > >fieldtrip mailing list > >fieldtrip at donders.ru.nl > >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl From michael.wibral at web.de Tue Feb 1 18:29:57 2011 From: michael.wibral at web.de (Michael Wibral) Date: Tue, 1 Feb 2011 18:29:57 +0100 (CET) Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <20110201153404.267000@gmx.net> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net>, <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056>, <20110201153404.267000@gmx.net> Message-ID: <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Hi Patricia, it seems that things are clarified now. I just do not know what was actually wrong with your code Was it the superfluous specification of cfg.uvar?? Could you let us know? Thanks. Michael -----Ursprüngliche Nachricht----- Von: "Patricia Wollstadt" Gesendet: Feb 1, 2011 4:34:04 PM An: "Email discussion list for the FieldTrip project" Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction >Hi Michael, Hi Jan-Mathijs, > >thank you very much for the advice/clarification. Everything seems to run fine now (with the corrected design). > >Thank you very much, > >Best > >Patricia > > >-------- Original-Nachricht -------- >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) >> Von: "Michael Wibral" >> An: "Email discussion list for the FieldTrip project" >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > >> Hi Patricia, >> >> I also would have thought your design to be correct. Maybe the >> unneccessary specification of the uvar screws thinsg up?? >> >> However, you really do not have any repeated measures in your design - >> here the output of FT is correct. I interpret it in the following way: You >> specified cfg.uvar - indicating to FT the possibility that this might be a >> repeated measures design. FT identified the units of observation as being 80 >> (correct), and then checked how many repeated measures you ran in each UO >> and found just 1 - which is also correct. I agree that naming the units of >> observation (UO) as 'levels' of the UO variable is a bit odd, should rather >> be 'units of observation'. >> >> The concept of repeated measures is also very often misunderstood: in >> repated measures you do not actually repeat anything, rather you perform >> different measurements (treatments) WITHIN a unit of observation - so a repated >> measures design is a within UO design. Your subjects just have one age, so >> there are no different treatments (levels of the indep variable) per >> subjects and, hence, no 'repeated measures'. >> >> Hope this clarifies terminology for further discussion. >> >> Michael >> >> >> -----Ursprüngliche Nachricht----- >> Von: "jan-mathijs schoffelen" >> Gesendet: Jan 25, 2011 8:57:03 PM >> An: "Email discussion list for the FieldTrip project" >> >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction >> >> >Hi Patricia, >> > >> >I don't really understand what is going on, but could you try to >> >specify your design only in a single row (design = design(2,:) in your >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how >> >it runs? As such the uvar row is not relevant in an independent >> >samples design. >> > >> >Best, >> > >> >Jan-Mathijs >> > >> > >> > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: >> > >> >> Dear all, >> >> >> >> I'm still trying to identify the underlying reason for the issue >> >> described below. I ran the analysis in debug mode (I'm using >> >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) >> >> and found that the matrix 'resample', that is generated in >> >> 'statistics_montecarlo', line 187: >> >> >> >> resample = resampledesign(cfg, design); >> >> >> >> doesn't contain actual permutations of my initial design, but rather >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is >> >> no permutation of the units of observation) the 'randstat' that is >> >> subsequently calculated for each row of the resample-matrix is >> >> always the same. >> >> Is this maybe due to my design and my units of observations >> >> respectively? I am looking at age-dependent variations in resting- >> >> state data, so my UO are 80 subjects, divided into four age groups. >> >> The commandline-output of the 'resampledesign'-function is as follows: >> >> >> >> total number of measurements = 80 >> >> total number of variables = 2 >> >> number of independent variables = 1 >> >> number of unit variables = 1 >> >> number of within-cell variables = 0 >> >> number of control variables = 0 >> >> using a permutation resampling approach >> >> repeated measurement in variable 1 over 80 levels >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 >> >> >> >> >> >> Is this correct? Shouldn't this read 'repeated measurement in >> >> variable 2 over 4 levels' with the number of subjects per group as >> >> repeated measurements within a condition? Still I am pretty sure >> >> about my design matrix, which contains the indices 1 to 80 (for all >> >> subjects) in the first row (this is my cfg.uvar) with the >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see >> >> my previous email below). I use an 'indepsamplesF'-statistic, since >> >> I am comparing between four groups of different subjects (averaged >> >> over trials). >> >> >> >> I hope, I got the settings and my design right. Any suggestions, >> >> whether this is a problem due to wrong configurations in my script >> >> are very welcome. >> >> >> >> Right now I work around this issue by replacing line 279 in >> >> 'statistics_montecarlo': >> >> >> >> tmpdesign = design(:,resample(i,:)); >> >> >> >> with: >> >> >> >> tmpdesign = design(:,randperm(size(design,2))); >> >> >> >> creating permutations of my design 'by hand'. Is this acceptable or >> >> is there anything I'm maybe missing. >> >> >> >> Thank you very much, kind regards, >> >> >> >> Patricia >> >> >> >> >> >> >> >> >> >> -------- Original-Nachricht -------- >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 >> >>> Von: "Patricia Wollstadt" >> >>> An: fieldtrip at donders.ru.nl >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction >> >> >> >>> Dear Fieldtrip-users, >> >>> >> >>> I'm currently trying to calculate freqstatistics for four >> >>> experimental >> >>> groups, using the following options: >> >>> >> >>> groupSize=[length(subjects{1}) length(subjects{2}) >> >>> length(subjects{3}) >> >>> length(subjects{4})]; >> >>> >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; >> >>> % 1 to N subjects >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> >> >>> group membership >> >>> >> >>> >> >>> cfg=[]; >> >>> cfg.design=design; >> >>> cfg.uvar = 1; >> >>> cfg.ivar = 2; >> >>> cfg.method = 'montecarlo'; >> >>> cfg.statistic = 'indepsamplesF'; >> >>> cfg.correctm = 'fdr'; >> >>> cfg.numrandomization = 180000; >> >>> cfg.alpha = 0.01/7; >> >>> cfg.tail = 1; >> >>> cfg.design = design; >> >>> cfg.channels = myChannels; >> >>> cfg.avgovertime = 'yes'; >> >>> cfg.avgoverfreq = 'yes'; >> >>> cfg.frequency = [1 3]; >> >>> >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, >> >>> group4avg); >> >>> >> >>> With these settings, the coputation itself runs fine, but the >> >>> resulting >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix >> >>> consists of >> >>> only ones). This would mean, that I found significant effects for all >> >>> channels. Is this possible or rather due to an error somewhere in >> >>> my script? Is >> >>> it likely, that these are 'real' zeroes or rather very small >> >>> values, close >> >>> to zero? >> >>> Any hints and suggestions are very welcome, thank you in advance, >> >>> >> >>> Kind regards >> >>> >> >>> Patricia Wollstadt >> >>> >> >>> >> >>> -- >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >> >>> _______________________________________________ >> >>> fieldtrip mailing list >> >>> fieldtrip at donders.ru.nl >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> -- >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > >> >Dr. J.M. (Jan-Mathijs) Schoffelen >> >Donders Institute for Brain, Cognition and Behaviour, >> >Centre for Cognitive Neuroimaging, >> >Radboud University Nijmegen, The Netherlands >> >J.Schoffelen at donders.ru.nl >> >Telephone: 0031-24-3614793 >> > >> >_______________________________________________ >> >fieldtrip mailing list >> >fieldtrip at donders.ru.nl >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >-- >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >_______________________________________________ >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From batrod at gmail.com Tue Feb 1 18:38:26 2011 From: batrod at gmail.com (Rodolphe Nenert) Date: Tue, 1 Feb 2011 11:38:26 -0600 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net> <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> <20110201153404.267000@gmx.net> <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Message-ID: Dear Patricia and others that participated to this discussion. I had recently the same problem, using ft_freqstatistics with Montecarlo to correlate Time-frequency power values and behavioral results. All my p-values were first found to be 0, resulting in a mask full of 1. By removing the useless cfg.uvar, the script made the correct analysis and reported good correlation values. Hope this helps, Rodolphe. On Tue, Feb 1, 2011 at 11:29 AM, Michael Wibral wrote: > Hi Patricia, > > it seems that things are clarified now. I just do not know what was > actually wrong with your code Was it the superfluous specification of > cfg.uvar?? > Could you let us know? Thanks. > > Michael > -----Ursprüngliche Nachricht----- > Von: "Patricia Wollstadt" > Gesendet: Feb 1, 2011 4:34:04 PM > An: "Email discussion list for the FieldTrip project" < > fieldtrip at donders.ru.nl> > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >Hi Michael, Hi Jan-Mathijs, > > > >thank you very much for the advice/clarification. Everything seems to run > fine now (with the corrected design). > > > >Thank you very much, > > > >Best > > > >Patricia > > > > > >-------- Original-Nachricht -------- > >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > >> Von: "Michael Wibral" > >> An: "Email discussion list for the FieldTrip project" < > fieldtrip at donders.ru.nl> > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > >> Hi Patricia, > >> > >> I also would have thought your design to be correct. Maybe the > >> unneccessary specification of the uvar screws thinsg up?? > >> > >> However, you really do not have any repeated measures in your design - > >> here the output of FT is correct. I interpret it in the following way: > You > >> specified cfg.uvar - indicating to FT the possibility that this might be > a > >> repeated measures design. FT identified the units of observation as > being 80 > >> (correct), and then checked how many repeated measures you ran in each > UO > >> and found just 1 - which is also correct. I agree that naming the units > of > >> observation (UO) as 'levels' of the UO variable is a bit odd, should > rather > >> be 'units of observation'. > >> > >> The concept of repeated measures is also very often misunderstood: in > >> repated measures you do not actually repeat anything, rather you perform > >> different measurements (treatments) WITHIN a unit of observation - so a > repated > >> measures design is a within UO design. Your subjects just have one age, > so > >> there are no different treatments (levels of the indep variable) per > >> subjects and, hence, no 'repeated measures'. > >> > >> Hope this clarifies terminology for further discussion. > >> > >> Michael > >> > >> > >> -----Ursprüngliche Nachricht----- > >> Von: "jan-mathijs schoffelen" > >> Gesendet: Jan 25, 2011 8:57:03 PM > >> An: "Email discussion list for the FieldTrip project" > >> > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > >> > >> >Hi Patricia, > >> > > >> >I don't really understand what is going on, but could you try to > >> >specify your design only in a single row (design = design(2,:) in your > >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how > >> >it runs? As such the uvar row is not relevant in an independent > >> >samples design. > >> > > >> >Best, > >> > > >> >Jan-Mathijs > >> > > >> > > >> > > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > >> > > >> >> Dear all, > >> >> > >> >> I'm still trying to identify the underlying reason for the issue > >> >> described below. I ran the analysis in debug mode (I'm using > >> >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) > >> >> and found that the matrix 'resample', that is generated in > >> >> 'statistics_montecarlo', line 187: > >> >> > >> >> resample = resampledesign(cfg, design); > >> >> > >> >> doesn't contain actual permutations of my initial design, but rather > >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is > >> >> no permutation of the units of observation) the 'randstat' that is > >> >> subsequently calculated for each row of the resample-matrix is > >> >> always the same. > >> >> Is this maybe due to my design and my units of observations > >> >> respectively? I am looking at age-dependent variations in resting- > >> >> state data, so my UO are 80 subjects, divided into four age groups. > >> >> The commandline-output of the 'resampledesign'-function is as > follows: > >> >> > >> >> total number of measurements = 80 > >> >> total number of variables = 2 > >> >> number of independent variables = 1 > >> >> number of unit variables = 1 > >> >> number of within-cell variables = 0 > >> >> number of control variables = 0 > >> >> using a permutation resampling approach > >> >> repeated measurement in variable 1 over 80 levels > >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 > >> >> > >> >> > >> >> Is this correct? Shouldn't this read 'repeated measurement in > >> >> variable 2 over 4 levels' with the number of subjects per group as > >> >> repeated measurements within a condition? Still I am pretty sure > >> >> about my design matrix, which contains the indices 1 to 80 (for all > >> >> subjects) in the first row (this is my cfg.uvar) with the > >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > >> >> my previous email below). I use an 'indepsamplesF'-statistic, since > >> >> I am comparing between four groups of different subjects (averaged > >> >> over trials). > >> >> > >> >> I hope, I got the settings and my design right. Any suggestions, > >> >> whether this is a problem due to wrong configurations in my script > >> >> are very welcome. > >> >> > >> >> Right now I work around this issue by replacing line 279 in > >> >> 'statistics_montecarlo': > >> >> > >> >> tmpdesign = design(:,resample(i,:)); > >> >> > >> >> with: > >> >> > >> >> tmpdesign = design(:,randperm(size(design,2))); > >> >> > >> >> creating permutations of my design 'by hand'. Is this acceptable or > >> >> is there anything I'm maybe missing. > >> >> > >> >> Thank you very much, kind regards, > >> >> > >> >> Patricia > >> >> > >> >> > >> >> > >> >> > >> >> -------- Original-Nachricht -------- > >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > >> >>> Von: "Patricia Wollstadt" > >> >>> An: fieldtrip at donders.ru.nl > >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > >> >> > >> >>> Dear Fieldtrip-users, > >> >>> > >> >>> I'm currently trying to calculate freqstatistics for four > >> >>> experimental > >> >>> groups, using the following options: > >> >>> > >> >>> groupSize=[length(subjects{1}) length(subjects{2}) > >> >>> length(subjects{3}) > >> >>> length(subjects{4})]; > >> >>> > >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > >> >>> % 1 to N subjects > >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > >> >>> group membership > >> >>> > >> >>> > >> >>> cfg=[]; > >> >>> cfg.design=design; > >> >>> cfg.uvar = 1; > >> >>> cfg.ivar = 2; > >> >>> cfg.method = 'montecarlo'; > >> >>> cfg.statistic = 'indepsamplesF'; > >> >>> cfg.correctm = 'fdr'; > >> >>> cfg.numrandomization = 180000; > >> >>> cfg.alpha = 0.01/7; > >> >>> cfg.tail = 1; > >> >>> cfg.design = design; > >> >>> cfg.channels = myChannels; > >> >>> cfg.avgovertime = 'yes'; > >> >>> cfg.avgoverfreq = 'yes'; > >> >>> cfg.frequency = [1 3]; > >> >>> > >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > >> >>> group4avg); > >> >>> > >> >>> With these settings, the coputation itself runs fine, but the > >> >>> resulting > >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > >> >>> consists of > >> >>> only ones). This would mean, that I found significant effects for > all > >> >>> channels. Is this possible or rather due to an error somewhere in > >> >>> my script? Is > >> >>> it likely, that these are 'real' zeroes or rather very small > >> >>> values, close > >> >>> to zero? > >> >>> Any hints and suggestions are very welcome, thank you in advance, > >> >>> > >> >>> Kind regards > >> >>> > >> >>> Patricia Wollstadt > >> >>> > >> >>> > >> >>> -- > >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >> >>> _______________________________________________ > >> >>> fieldtrip mailing list > >> >>> fieldtrip at donders.ru.nl > >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> >> > >> >> -- > >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > >> >> belohnen Sie mit bis zu 50,- Euro! > https://freundschaftswerbung.gmx.de > >> >> _______________________________________________ > >> >> fieldtrip mailing list > >> >> fieldtrip at donders.ru.nl > >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > > >> >Dr. J.M. (Jan-Mathijs) Schoffelen > >> >Donders Institute for Brain, Cognition and Behaviour, > >> >Centre for Cognitive Neuroimaging, > >> >Radboud University Nijmegen, The Netherlands > >> >J.Schoffelen at donders.ru.nl > >> >Telephone: 0031-24-3614793 > >> > > >> >_______________________________________________ > >> >fieldtrip mailing list > >> >fieldtrip at donders.ru.nl > >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >-- > >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >_______________________________________________ > >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 ekanal at cmu.edu Tue Feb 1 19:16:23 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Tue, 1 Feb 2011 13:16:23 -0500 Subject: [FieldTrip] using planar gradiometer data with ft_combineplanar Message-ID: <3F013D5F-0A1C-4A63-A365-FFD87F9233F9@cmu.edu> Hello folks - We have a Neuromag 306 system here, which has two planar gradiometers at each sensor location (x and y directions). Is there a way I can use ft_combineplanar with the data from these sensors? From what I can tell, I shouldn't need to use ft_megplanar, but I don't know how to format the data so that ft_combineplanar knows what to do. Thanks - Elli Kanal -------------------- Eliezer Kanal, Ph.D. Postdoctoral Fellow Center for the Neural Basis of Cognition Carnegie Mellon University 4400 Fifth Ave, Suite 115 Pittsburgh PA 15213 P: 412-268-4115 F: 412-268-5060 From Patricia.Wollstadt at gmx.de Tue Feb 1 22:26:51 2011 From: Patricia.Wollstadt at gmx.de (Patricia Wollstadt) Date: Tue, 01 Feb 2011 22:26:51 +0100 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net> <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> <20110201153404.267000@gmx.net> <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Message-ID: <20110201212651.47820@gmx.net> Dear all, the problem was caused by the wrong design matrix (and thus the superfluous cfg.uvar), sorry for not making this clear. So actually I just need a vector that specifies the group for each subject, Best Patricia -------- Original-Nachricht -------- > Datum: Tue, 1 Feb 2011 11:38:26 -0600 > Von: Rodolphe Nenert > An: Email discussion list for the FieldTrip project > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > Dear Patricia and others that participated to this discussion. > > I had recently the same problem, using ft_freqstatistics with Montecarlo > to > correlate Time-frequency power values and behavioral results. > All my p-values were first found to be 0, resulting in a mask full of 1. > By removing the useless cfg.uvar, the script made the correct analysis and > reported good correlation values. > > Hope this helps, > > Rodolphe. > > On Tue, Feb 1, 2011 at 11:29 AM, Michael Wibral > wrote: > > > Hi Patricia, > > > > it seems that things are clarified now. I just do not know what was > > actually wrong with your code Was it the superfluous specification of > > cfg.uvar?? > > Could you let us know? Thanks. > > > > Michael > > -----Ursprüngliche Nachricht----- > > Von: "Patricia Wollstadt" > > Gesendet: Feb 1, 2011 4:34:04 PM > > An: "Email discussion list for the FieldTrip project" < > > fieldtrip at donders.ru.nl> > > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > > >Hi Michael, Hi Jan-Mathijs, > > > > > >thank you very much for the advice/clarification. Everything seems to > run > > fine now (with the corrected design). > > > > > >Thank you very much, > > > > > >Best > > > > > >Patricia > > > > > > > > >-------- Original-Nachricht -------- > > >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > > >> Von: "Michael Wibral" > > >> An: "Email discussion list for the FieldTrip project" < > > fieldtrip at donders.ru.nl> > > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > > > >> Hi Patricia, > > >> > > >> I also would have thought your design to be correct. Maybe the > > >> unneccessary specification of the uvar screws thinsg up?? > > >> > > >> However, you really do not have any repeated measures in your design > - > > >> here the output of FT is correct. I interpret it in the following > way: > > You > > >> specified cfg.uvar - indicating to FT the possibility that this might > be > > a > > >> repeated measures design. FT identified the units of observation as > > being 80 > > >> (correct), and then checked how many repeated measures you ran in > each > > UO > > >> and found just 1 - which is also correct. I agree that naming the > units > > of > > >> observation (UO) as 'levels' of the UO variable is a bit odd, should > > rather > > >> be 'units of observation'. > > >> > > >> The concept of repeated measures is also very often misunderstood: in > > >> repated measures you do not actually repeat anything, rather you > perform > > >> different measurements (treatments) WITHIN a unit of observation - so > a > > repated > > >> measures design is a within UO design. Your subjects just have one > age, > > so > > >> there are no different treatments (levels of the indep variable) per > > >> subjects and, hence, no 'repeated measures'. > > >> > > >> Hope this clarifies terminology for further discussion. > > >> > > >> Michael > > >> > > >> > > >> -----Ursprüngliche Nachricht----- > > >> Von: "jan-mathijs schoffelen" > > >> Gesendet: Jan 25, 2011 8:57:03 PM > > >> An: "Email discussion list for the FieldTrip project" > > >> > > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >> > > >> >Hi Patricia, > > >> > > > >> >I don't really understand what is going on, but could you try to > > >> >specify your design only in a single row (design = design(2,:) in > your > > >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see > how > > >> >it runs? As such the uvar row is not relevant in an independent > > >> >samples design. > > >> > > > >> >Best, > > >> > > > >> >Jan-Mathijs > > >> > > > >> > > > >> > > > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > > >> > > > >> >> Dear all, > > >> >> > > >> >> I'm still trying to identify the underlying reason for the issue > > >> >> described below. I ran the analysis in debug mode (I'm using > > >> >> Matlab2008b and the Fieldtrip-release from the 16th of January > 2011) > > >> >> and found that the matrix 'resample', that is generated in > > >> >> 'statistics_montecarlo', line 187: > > >> >> > > >> >> resample = resampledesign(cfg, design); > > >> >> > > >> >> doesn't contain actual permutations of my initial design, but > rather > > >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there > is > > >> >> no permutation of the units of observation) the 'randstat' that is > > >> >> subsequently calculated for each row of the resample-matrix is > > >> >> always the same. > > >> >> Is this maybe due to my design and my units of observations > > >> >> respectively? I am looking at age-dependent variations in resting- > > >> >> state data, so my UO are 80 subjects, divided into four age > groups. > > >> >> The commandline-output of the 'resampledesign'-function is as > > follows: > > >> >> > > >> >> total number of measurements = 80 > > >> >> total number of variables = 2 > > >> >> number of independent variables = 1 > > >> >> number of unit variables = 1 > > >> >> number of within-cell variables = 0 > > >> >> number of control variables = 0 > > >> >> using a permutation resampling approach > > >> >> repeated measurement in variable 1 over 80 levels > > >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 > > >> >> > > >> >> > > >> >> Is this correct? Shouldn't this read 'repeated measurement in > > >> >> variable 2 over 4 levels' with the number of subjects per group as > > >> >> repeated measurements within a condition? Still I am pretty sure > > >> >> about my design matrix, which contains the indices 1 to 80 (for > all > > >> >> subjects) in the first row (this is my cfg.uvar) with the > > >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > > >> >> my previous email below). I use an 'indepsamplesF'-statistic, > since > > >> >> I am comparing between four groups of different subjects (averaged > > >> >> over trials). > > >> >> > > >> >> I hope, I got the settings and my design right. Any suggestions, > > >> >> whether this is a problem due to wrong configurations in my script > > >> >> are very welcome. > > >> >> > > >> >> Right now I work around this issue by replacing line 279 in > > >> >> 'statistics_montecarlo': > > >> >> > > >> >> tmpdesign = design(:,resample(i,:)); > > >> >> > > >> >> with: > > >> >> > > >> >> tmpdesign = design(:,randperm(size(design,2))); > > >> >> > > >> >> creating permutations of my design 'by hand'. Is this acceptable > or > > >> >> is there anything I'm maybe missing. > > >> >> > > >> >> Thank you very much, kind regards, > > >> >> > > >> >> Patricia > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> -------- Original-Nachricht -------- > > >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > > >> >>> Von: "Patricia Wollstadt" > > >> >>> An: fieldtrip at donders.ru.nl > > >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > > >> >> > > >> >>> Dear Fieldtrip-users, > > >> >>> > > >> >>> I'm currently trying to calculate freqstatistics for four > > >> >>> experimental > > >> >>> groups, using the following options: > > >> >>> > > >> >>> groupSize=[length(subjects{1}) length(subjects{2}) > > >> >>> length(subjects{3}) > > >> >>> length(subjects{4})]; > > >> >>> > > >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > > >> >>> % 1 to N subjects > > >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > > >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > > >> >>> group membership > > >> >>> > > >> >>> > > >> >>> cfg=[]; > > >> >>> cfg.design=design; > > >> >>> cfg.uvar = 1; > > >> >>> cfg.ivar = 2; > > >> >>> cfg.method = 'montecarlo'; > > >> >>> cfg.statistic = 'indepsamplesF'; > > >> >>> cfg.correctm = 'fdr'; > > >> >>> cfg.numrandomization = 180000; > > >> >>> cfg.alpha = 0.01/7; > > >> >>> cfg.tail = 1; > > >> >>> cfg.design = design; > > >> >>> cfg.channels = myChannels; > > >> >>> cfg.avgovertime = 'yes'; > > >> >>> cfg.avgoverfreq = 'yes'; > > >> >>> cfg.frequency = [1 3]; > > >> >>> > > >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > > >> >>> group4avg); > > >> >>> > > >> >>> With these settings, the coputation itself runs fine, but the > > >> >>> resulting > > >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > > >> >>> consists of > > >> >>> only ones). This would mean, that I found significant effects for > > all > > >> >>> channels. Is this possible or rather due to an error somewhere in > > >> >>> my script? Is > > >> >>> it likely, that these are 'real' zeroes or rather very small > > >> >>> values, close > > >> >>> to zero? > > >> >>> Any hints and suggestions are very welcome, thank you in advance, > > >> >>> > > >> >>> Kind regards > > >> >>> > > >> >>> Patricia Wollstadt > > >> >>> > > >> >>> > > >> >>> -- > > >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > > >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > >> >>> _______________________________________________ > > >> >>> fieldtrip mailing list > > >> >>> fieldtrip at donders.ru.nl > > >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > >> >> > > >> >> -- > > >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > > >> >> belohnen Sie mit bis zu 50,- Euro! > > https://freundschaftswerbung.gmx.de > > >> >> _______________________________________________ > > >> >> fieldtrip mailing list > > >> >> fieldtrip at donders.ru.nl > > >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > >> > > > >> >Dr. J.M. (Jan-Mathijs) Schoffelen > > >> >Donders Institute for Brain, Cognition and Behaviour, > > >> >Centre for Cognitive Neuroimaging, > > >> >Radboud University Nijmegen, The Netherlands > > >> >J.Schoffelen at donders.ru.nl > > >> >Telephone: 0031-24-3614793 > > >> > > > >> >_______________________________________________ > > >> >fieldtrip mailing list > > >> >fieldtrip at donders.ru.nl > > >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > >-- > > >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > > >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > >_______________________________________________ > > >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 > > -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail From r.oostenveld at donders.ru.nl Wed Feb 2 10:39:50 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 2 Feb 2011 10:39:50 +0100 Subject: [FieldTrip] toolkit course for MEG and EEG data analysis at the Donders Institute Message-ID: Dear MEG/EEG researchers, (appologies for multiple postings) I would like to announce the yearly toolkit course for MEG and EEG data analysis at the Donders Institute. This year's toolkit will take place from April 18 to April 21. Registration is now open. Have a look at http://www.ru.nl/donders/agenda-events/courses/toolkits-2011 for the preliminary programme and to register. Please note that the number of seats is limited and that participants will be selected based on the time of registration and on their research background and motivation. best regards, Robert ----------------------------------------------------------- Robert Oostenveld, PhD Senior Researcher & MEG Physicist Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Postal Address: PO Box 9101 6500 HB NIJMEGEN The Netherlands Visiting address: Kapittelweg 29 route: 210, room: 0.88 6525 EN NIJMEGEN tel.: +31 (0)24 3619695 e-mail: r.oostenveld at donders.ru.nl web: http://www.ru.nl/neuroimaging skype: r.oostenveld ----------------------------------------------------------- From michael.wibral at web.de Thu Feb 3 10:18:17 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 3 Feb 2011 10:18:17 +0100 (CET) Subject: [FieldTrip] Problem with permutation testing and FDR correction Message-ID: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> Dear Fieldtrip users, I think we detected an error with FDR correction and permutation testing. When increasing the number of permutations, the number of significant voxels goes DOWN, on the other hand when decreasing the number of permutations the number of significant voxels goes up. In my opinion the relationship should be the other way round. The theoretical background is as follows: With FDR correction, the best p-value should survive bonferroni correction (if I am not completely mistaken here), the threshold for the other p-values is then decreased successively. Hence, the p-value assigned to the best (most significant) statistical result plays a crucial role here. This best p-value in permutation tests can never be better than 1/numpermutations, i.e. when I do ten permutations, the best p I can possibly get is 0.1 EVEN IF ALL PERMUTED VALUES ARE LESS EXTREME. So to test with FDR at 275 sensors and 1 timepoint at a threshold of 0.05 we need for anything to get significant a p-value of 0.05/275 = 0.000181818.... to be able to reach this in the best case (remebering that p-values can never be better than 1/numpermutations) we need at least (0.000181818....)^-1 = 5500 permutations. In other words with anything less than this number of permutations we should not be able to get any significances. However, we do in fact get alot of significant values at least in the fieldtrip versions tested up to 16th of January, e.g. in a freqstatistics test on 275 sensors, 50 frequencies and 26 timepoints I get 20760 significant voxels using only 10 permutations (!!). I assume that in the stats module the p-value is simply taken as the fraction of permutations that was more extreme than the actual value. This is correct as long as this fraction is not 0. In the case of a 0 fraction, however, this "0" should be replaced by "1/numpermutations", otherwise you get everything signifcant by just using 10 permutations. An alternative would be to issue an ERROR that the number of permutations is insufficient to perform the desired test with fdr correction. Example: for 4300 source points at 0.05 the number of permutations should at least be (0.05/4300)^-1=86000. For now one should compute the p-value for a bonferroni correction manually, invert this value and take the resulting number as the number of permutations to be at least mathematically on the safe side (practically it seems to be advisable to multiply by another factor of 100 to have stable results, e.g 2000 permutations for uncorrceted testing at 0.05) Please disregard this mail if you are sure that this behaviour has been fixed in the latest fieldtrip (past 16th of January) versions. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From e.maris at donders.ru.nl Thu Feb 3 11:24:18 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Thu, 3 Feb 2011 11:24:18 +0100 Subject: [FieldTrip] Problem with permutation testing and FDR correction In-Reply-To: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> References: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> Message-ID: <018d01cbc38c$869a7ba0$93cf72e0$@maris@donders.ru.nl> Dear Michael, Thank you for pointing this out. The origin of the problem is that FT calculates Monte Carlo estimates of the p-values. In practice there is no other way, except for very small studies where enumeration is possible. However, Monte Carlo estimates are useless if the number of draws from the permutation distribution (numpermutations) is very small, because in that case their Monte Carlo confidence interval is very large. I propose that we add a Monte Carlo confidence interval for all Monte Carlo p-values that FT calculates. This is actually very easy, and I have described it in a paper together with Jan-Matthijs Schoffelen and Pascal Fries (JNeuroMeth, 2007). It just hasn't found its way into FT yet. I will discuss with Robert how to implement this. Best, Eric Maris dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > -----Original Message----- > From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > bounces at donders.ru.nl] On Behalf Of Michael Wibral > Sent: donderdag 3 februari 2011 10:18 > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] Problem with permutation testing and FDR > correction > > Dear Fieldtrip users, > > I think we detected an error with FDR correction and permutation > testing. When increasing the number of permutations, the number of > significant voxels goes DOWN, on the other hand when decreasing the > number of permutations the number of significant voxels goes up. In my > opinion the relationship should be the other way round. The theoretical > background is as follows: > > With FDR correction, the best p-value should survive bonferroni > correction (if I am not completely mistaken here), the threshold for > the other p-values is then decreased successively. > Hence, the p-value assigned to the best (most significant) statistical > result plays a crucial role here. This best p-value in permutation > tests can never be better than 1/numpermutations, i.e. when I do ten > permutations, the best p I can possibly get is 0.1 EVEN IF ALL PERMUTED > VALUES ARE LESS EXTREME. So to test with FDR at 275 sensors and 1 > timepoint at a threshold of 0.05 we need for anything to get > significant a p-value of 0.05/275 = 0.000181818.... to be able to reach > this in the best case (remebering that p-values can never be better > than 1/numpermutations) we need at least (0.000181818....)^-1 = 5500 > permutations. In other words with anything less than this number of > permutations we should not be able to get any significances. However, > we do in fact get alot of significant values at least in the fieldtrip > versions tested up to 16th of January, e.g. in a freqstatistics test on > 275 sensors, 50 frequencies and 26 timepoints I get 20760 significant > voxels using only 10 permutations (!!). I assume that in the stats > module the p-value is simply taken as the fraction of permutations that > was more extreme than the actual value. This is correct as long as this > fraction is not 0. In the case of a 0 fraction, however, this "0" > should be replaced by "1/numpermutations", otherwise you get everything > signifcant by just using 10 permutations. An alternative would be to > issue an ERROR that the number of permutations is insufficient to > perform the desired test with fdr correction. > > > Example: for 4300 source points at 0.05 the number of permutations > should at least be (0.05/4300)^-1=86000. > > For now one should compute the p-value for a bonferroni correction > manually, invert this value and take the resulting number as the number > of permutations to be at least mathematically on the safe side > (practically it seems to be advisable to multiply by another factor of > 100 to have stable results, e.g 2000 permutations for uncorrceted > testing at 0.05) > > Please disregard this mail if you are sure that this behaviour has been > fixed in the latest fieldtrip (past 16th of January) versions. > > Michael From H.Rossiter at ion.ucl.ac.uk Thu Feb 3 15:25:59 2011 From: H.Rossiter at ion.ucl.ac.uk (Holly Rossiter) Date: Thu, 3 Feb 2011 14:25:59 -0000 Subject: [FieldTrip] EMG data Message-ID: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> Dear Fieldtrip, I am new to fieldtrip and am using it to look at MEG-EMG coherence. I am trying to load in my EMG data which is in a separate data file to the MEG. It is made up of 3 files (.eeg, .vhdr and .vmrk). I am trying to follow the coherence tutorial I previously downloaded from your website but I'm not able to define trials despite there being triggers present. Here are my attempts to load in the data with the following error... cfg = []; cfg.trialfun = 'trialfun_general'; cfg.trialdef.eventtype = '1'; cfg.trialdef.eventvalue = [1 1]; cfg.trialdef.prestim = 1; cfg.trialdef.poststim = 2; cfg.dataset = 'sf_EMG.eeg'; cfg = ft_definetrial(cfg); evaluating trialfunction 'trialfun_general' reading the events from 'sf_EMG.vhdr' ??? Error using ==> ft_definetrial at 136 no trials were defined, see DEFINETRIAL for help What do you suggest is the problem? Is it not reading the triggers correctly? Thanks, Holly -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 3 16:09:16 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 3 Feb 2011 16:09:16 +0100 Subject: [FieldTrip] EMG data In-Reply-To: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> Message-ID: Dear Holly You may want to have a look at: http://fieldtrip.fcdonders.nl/example/getting_started_with_reading_raw_eeg_or_meg_data?s []=event To me it sounds as if you have an incorrect specification of your cfg. Good luck, Jan-Mathijs On Feb 3, 2011, at 3:25 PM, Holly Rossiter wrote: > Dear Fieldtrip, > > I am new to fieldtrip and am using it to look at MEG-EMG coherence. > I am trying to load in my EMG data which is in a separate data file > to the MEG. It is made up of 3 files (.eeg, .vhdr and .vmrk). I am > trying to follow the coherence tutorial I previously downloaded from > your website but I’m not able to define trials despite there being > triggers present. > > Here are my attempts to load in the data with the following error... > > cfg = []; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.eventtype = '1'; > cfg.trialdef.eventvalue = [1 1]; > cfg.trialdef.prestim = 1; > cfg.trialdef.poststim = 2; > cfg.dataset = 'sf_EMG.eeg'; > cfg = ft_definetrial(cfg); > evaluating trialfunction 'trialfun_general' > reading the events from 'sf_EMG.vhdr' > ??? Error using ==> ft_definetrial at 136 > no trials were defined, see DEFINETRIAL for help > > What do you suggest is the problem? Is it not reading the triggers > correctly? > > Thanks, > > Holly > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.frei at psy.gla.ac.uk Thu Feb 3 19:07:44 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Thu, 3 Feb 2011 18:07:44 +0000 Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> Message-ID: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Hi everybody, I have a problem that impacts several analysis steps and I'm hoping someone can point me to the right direction. I have 13 recording sessions, that I want to average, and then I want to compute the planar gradients of the average. I first average the sessions with ft_timelockanalysis for each session. Then I use ft_timelockgrandaverage to combine the sessions. Then, just to check the data, I plot the ERFs with ft_multiplotER. This is when the first problem arises. The x and y axes of the plots are shifted in space somehow (see picture 3.png). Next, I compute the planar gradients. When I plot the topographies for the planar gradient, I get a very strange activation pattern, that has nothing to do with the ERF topography (which, btw has no obvious flaws) and I also get several warnings when I make the plot (Picture4.png). I also know for a fact that the grand average planar gradient should look different, as I computed it once before by hand, and it looked much more sensible. If anyone has ever seen this before and can give me a hint as to where to look for the error, I would be very grateful. Luisa -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 4.png Type: application/applefile Size: 73 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 4.png Type: image/png Size: 8160 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 3.png Type: application/applefile Size: 73 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 3.png Type: image/png Size: 43112 bytes Desc: not available URL: -------------- next part -------------- From jan.schoffelen at donders.ru.nl Thu Feb 3 20:29:04 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 3 Feb 2011 20:29:04 +0100 Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Message-ID: Dear Luisa, Could you please specify whether this is a new problem that didn't occur before? If you didn't have problems before, approximately when did it stop working the way you expected it to work? As to the multiplot problem: To me, it seems as if the y-axis is plotted at time point 0, which is indeed far away from your latency of interest, which is (surprise) between 0.14 and 0.18 s. This is a property of multiplotER, which by default plots the x and y axes. Should be possible to switch it off. As to the topoplot problem: difficult to say without additional info / data to reproduce the problem. I assume you have used ft_combineplanar first before attempting to plot the planar gradient representation? Did everything go well in the previous steps, i.e. proper baseline correction etc, prior to timelockanalysis? Be sure also to not use the baseline-correction option for the plotting in ft_topoplotER. Best wishes, Jan-Mathijs On Feb 3, 2011, at 7:07 PM, Luisa Frei wrote: > Hi everybody, > I have a problem that impacts several analysis steps and I'm hoping > someone can point me to the right direction. > > I have 13 recording sessions, that I want to average, and then I > want to compute the planar gradients of the average. I first average > the sessions with ft_timelockanalysis for each session. Then I use > ft_timelockgrandaverage to combine the sessions. > Then, just to check the data, I plot the ERFs with ft_multiplotER. > This is when the first problem arises. The x and y axes of the plots > are shifted in space somehow (see picture 3.png). > Next, I compute the planar gradients. When I plot the topographies > for the planar gradient, I get a very strange activation pattern, > that has nothing to do with the ERF topography (which, btw has no > obvious flaws) and I also get several warnings when I make the plot > (Picture4.png). > > I also know for a fact that the grand average planar gradient should > look different, as I computed it once before by hand, and it looked > much more sensible. > > If anyone has ever seen this before and can give me a hint as to > where to look for the error, I would be very grateful. > > Luisa > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From michael.wibral at web.de Fri Feb 4 10:47:55 2011 From: michael.wibral at web.de (Michael Wibral) Date: Fri, 4 Feb 2011 10:47:55 +0100 (CET) Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk>, <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Message-ID: <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> Dear Luisa, I was also wondering whether you were aware of the fact that planar gradients of group data can look very different depending on when you do the averaging and the megplanar/combineplanar steps. This is because combineplanar is a nonlinear step that cannot be exchanged with the other steps without changing the results. So creating planar gradients in single trials and then using combineplanar and then averaging trials within subjects and then over subjects will look pretty different from doing all averaging first (trials, subjects) and then using megplanar/combineplanar to get an planar gradient representation of this average. Michael -----Ursprüngliche Nachricht----- Von: "Luisa Frei" Gesendet: Feb 3, 2011 7:07:44 PM An: "Email discussion list for the FieldTrip project" Betreff: [FieldTrip] problem with ft_multiplot and planar gradient ? >Hi everybody, >I have a problem that impacts several analysis steps and I'm hoping >someone can point me to the right direction. > >I have 13 recording sessions, that I want to average, and then I want >to compute the planar gradients of the average. I first average the >sessions with ft_timelockanalysis for each session. Then I use >ft_timelockgrandaverage to combine the sessions. >Then, just to check the data, I plot the ERFs with ft_multiplotER. >This is when the first problem arises. The x and y axes of the plots >are shifted in space somehow (see picture 3.png). >Next, I compute the planar gradients. When I plot the topographies >for the planar gradient, I get a very strange activation pattern, >that has nothing to do with the ERF topography (which, btw has no >obvious flaws) and I also get several warnings when I make the plot >(Picture4.png). > >I also know for a fact that the grand average planar gradient should >look different, as I computed it once before by hand, and it looked >much more sensible. > >If anyone has ever seen this before and can give me a hint as to >where to look for the error, I would be very grateful. > >Luisa > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From l.frei at psy.gla.ac.uk Fri Feb 4 11:43:59 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 4 Feb 2011 10:43:59 +0000 Subject: [FieldTrip] =?utf-8?q?=5BSPAM=3F=5D_Re=3A__problem_with_ft=5Fmult?= =?utf-8?q?iplot_and_planar_gradient__=EF=BF=BC?= In-Reply-To: <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk>, <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> Message-ID: <6E28D7B8-BFE7-44D9-93C4-5DDEF50D52A0@psy.gla.ac.uk> Thanks Michael and Jan-Mathijs, this is very useful information. I do all the averaging before computing the gradients. However, to resolve this I have to admit that I found a bug in my code last night and after fixing it, it looked fine. Thanks for your help! Luisa On 4 Feb 2011, at 09:47, Michael Wibral wrote: > Dear Luisa, > > I was also wondering whether you were aware of the fact that planar > gradients of group data can look very different depending on when > you do the averaging and the megplanar/combineplanar steps. This is > because combineplanar is a nonlinear step that cannot be exchanged > with the other steps without changing the results. > So creating planar gradients in single trials and then using > combineplanar and then averaging trials within subjects and then > over subjects will look pretty different from doing all averaging > first (trials, subjects) and then using megplanar/combineplanar to > get an planar gradient representation of this average. > > Michael > > > -----Ursprüngliche Nachricht----- > Von: "Luisa Frei" > Gesendet: Feb 3, 2011 7:07:44 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: [FieldTrip] problem with ft_multiplot and planar gradient ? > >> Hi everybody, >> I have a problem that impacts several analysis steps and I'm hoping >> someone can point me to the right direction. >> >> I have 13 recording sessions, that I want to average, and then I want >> to compute the planar gradients of the average. I first average the >> sessions with ft_timelockanalysis for each session. Then I use >> ft_timelockgrandaverage to combine the sessions. >> Then, just to check the data, I plot the ERFs with ft_multiplotER. >> This is when the first problem arises. The x and y axes of the plots >> are shifted in space somehow (see picture 3.png). >> Next, I compute the planar gradients. When I plot the topographies >> for the planar gradient, I get a very strange activation pattern, >> that has nothing to do with the ERF topography (which, btw has no >> obvious flaws) and I also get several warnings when I make the plot >> (Picture4.png). >> >> I also know for a fact that the grand average planar gradient should >> look different, as I computed it once before by hand, and it looked >> much more sensible. >> >> If anyone has ever seen this before and can give me a hint as to >> where to look for the error, I would be very grateful. >> >> Luisa >> >> >> >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From sburns at nmr.mgh.harvard.edu Fri Feb 4 17:12:46 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Fri, 4 Feb 2011 11:12:46 -0500 Subject: [FieldTrip] FT doesn't close .fif files Message-ID: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> FieldTrip Experts - I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgroppe at cogsci.ucsd.edu Mon Feb 7 16:48:40 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Mon, 7 Feb 2011 10:48:40 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? Message-ID: Hi fieldtrippers, I'm a little bit confused about the meaning of the cluster-based permutation test parameter 'minnbchan'. I understand the rationale for the parameter, but based on the tutorial description: "The value of cfg.minnbchan is a tuning parameter that determines the way the clusters are formed. More specifically, we use cfg.minnbchan to specify the minimum number of neighborhood channels that is required for a selected sample (i.e., a sample who's T-value exceeds the threshold) to be included in the clustering algorithm. With cfg.minnbchan = 0 (the default), it sometimes happens that two clusters are spatially connected via a narrow bridge of samples. Because they are connected, these two clusters are considered as a single cluster. If clusters are interpreted as reflecting spatially distinct sources, such a combined cluster does not make much sense. To suppress this type of combined clusters, one can choose to ignore all selected samples (on the basis of their T-values) if they have less than some minimum number of neighbors that were also selected. This minimum number is assigned to cfg.minnbchan. This number must be chosen independently of the data." I can't tell if "minimum number of neighbors" means just spatial neighbors (i.e., nearby sensors) or if includes temporal and frequency neighbors as well. Could someone clarify? Also, just to be clear, if I want to be able to detect an effect that I think is at only a single electrode, I should set minnbchan to 0, yes? If understand the parameter correctly, any greater value of minnbchan will ignore clusters that are restricted to a single electrode. thanks for your help, -David -- David Groppe, Ph.D. dgroppe at cogsci.ucsd.edu http://www.cogsci.ucsd.edu/~dgroppe/ From tom_campbell75 at hotmail.com Tue Feb 8 04:26:26 2011 From: tom_campbell75 at hotmail.com (Tom Campbell) Date: Tue, 8 Feb 2011 03:26:26 +0000 Subject: [FieldTrip] depsamplesF In-Reply-To: <001001cbbecf$dc470260$94d50720$@maris@donders.ru.nl> References: , <6FF942DE-E2EC-47D0-BC81-CEDCD9B12410@graphicmind.info> , <001001cbbecf$dc470260$94d50720$@maris@donders.ru.nl> Message-ID: Dear Eric, Thank you very much for these helpful suggestions. Plotting the suggested difference waves was rather enlightening. Best regards, Tom. From: e.maris at donders.ru.nl To: tom_campbell75 at hotmail.com; fieldtrip at donders.ru.nl Subject: RE: [FieldTrip] depsamplesF Date: Fri, 28 Jan 2011 10:43:42 +0100 Hi Tom, To test main and interaction effects in your 2x2 within subjects design, you have to perform 3 tests, each using the statfun desamplesT. Say you have the output of ft_timelockanalysis for all four conditions: tlout_Ia, tlout_Ib, tlout_IIa, tlout_IIb. Your then proceed as follows: 1. Main effect of I versus II: calculate the mean of tlout_Ia.avg and tlout_Ib.avg and put this is a a new struct variable tlout_I, which has the same fields as tlout_Ia and tlout_Ib. Do the same with tlout_IIa.avg and tlout_IIb.avg and make a new struct variable tlout_II. Then run ft_timelockstatistics with input arguments tlout_I and tlout_II. With this analysis you will test the main effect of I-versus-II. 2. In the same way, you now test the main effect of a versus b. In your calculations, the roles of (I,II) and (a,b) are now reversed. 3. Interaction of I-vs-II and a-vs-b. Calculate the differences (tlout_Ia.avg-tlout_Ib.avg) and (tlout_IIa.avg-tlout_IIb.avg), put them in output structures and statistically compare them using ft_timelockstatistics. With this analysis, you test the interaction of I-vs-II and a-vs-b. There is no need for Bonferroni correction or an adjustment of cfg.clusteralpha (which does not affect the false alarm rate anyhow) and cfg.alpha. Best, Eric Mari Thank you very much for this helpful advice Olga. That would have also been my impression until I found this discussion between Maya Zuckerman and Eric Maris: http://mailman.science.ru.nl/pipermail/fieldtrip/2010-December/003335.html http://mailman.science.ru.nl/pipermail/fieldtrip/2010-December/003338.html , which I may have misunderstood. I can see from the list that people are interested in using depsampleF to investigate interactions between two independent variables (e.g., background: I,II x stimulus: a,b) in experiments with multiple participants. I can also see a several people have had problems with this. Given for datasets I_a, I_b, II_a, II_b I'd like to do something like: cfg.design =????; ... cfg.statistic ='depsamplesF'; ... [stat] = ft_timelockstatistics(cfg, I_a, I_b, II_a, II_b); to find the tests of of main effect clusters for each factor and interaction clusters. How to specify up cfg.design could be one of the problems, as could be what other cfg parameters need to be specified. I may be barking up completely the wrong tree. Assuming the interaction is significant, there are 4 differences that would be of theoretical interest: I_a vs I_b, II_a vs II_b,I_a vs II_a,I_b vs II_b). For instance, a "classical" interaction might exhibit the abolition of significance of an effect ab seen at I at level II of that factor. So, if I understand the Zuckerman-Maris dialogue, if I used the permutation test to test such I_a vd II_b differences as in the tutorial: cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 500; ... [I_avsb_stat] = ft_timelockstatistics(cfg, I_a, I_b); [II_avsb_stat] = ft_timelockstatistics(cfg, II_a, II_b); [IvsII_a_stat] = ft_timelockstatistics(cfg, I_a, II_a); [IvsII_b_stat] = ft_timelockstatistics(cfg, I_a, II_b); ,I may have to either do some bonferonni correction: -at the cluster level (cluster.alpha) -or at the level at which each t-test can be included in a cluster (cfg.alpha). Please would you verify which, if at all? If I am testing 4 such differences with 4 permutation tests then if the bonferroni correction is to be at the cluster level, please should the correction depend upon the number of clusters as well as the number of such differences tested? Please, I look forward to any clarifications. With best regards, Tom Campbell. From: olga at graphicmind.info To: tom_campbell75 at hotmail.com; fieldtrip at donders.ru.nl Subject: Re: [FieldTrip] depsamplesF Date: Thu, 27 Jan 2011 06:16:51 +0300 Hi, Tom, I guess if you do cluster analysis, which is based on permutation tests you do not need any correction like. Cluster-based statistics just deal with multiple comparison problem differently (Monte-Carlo randomization, permutation tests and examine the probability of your cluster among the random ones). Clusters may be formed based on time, space/frequency adjacency. Best Regards, Olga. On 27.01.2011, at 2:26, Tom Campbell wrote: Dear Eric Maris, Robert Oostenveld and colleagues, I write with some queries with reference to your previous correspondence on the Fieldtrip listserv and would very much appreciate if you could please answer them. I am trying to use Fieldtrip to analyse timelocked ERP data from what is a 16(participant: [1:16]) X2(Background: congruent, incongruent)x2(Stimulus: Animal, Vehicle) design. The code seems to runing well treating this as a 16(participant: [1:16]) X4(Visual stimulus: animal-congruent background, animal-incongruent background, vehicle-congruent, vehicle-incongruent )design with 4 conditions, though I haven't looked at the results of the tests yet. If I then run cluster analyses of differences of theoretical interest via depsamplest, please how would I bonferroni correct? I am interested in what clusters exist in the background and stimulus main effects and their background X stimulus interaction. Please is this possible in fieldtrip to use depsamplesF to work with a Participant X "2-way" design? Best regards, Tom Campbell. _______________________________________________ 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 e.maris at donders.ru.nl Tue Feb 8 07:17:34 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 8 Feb 2011 07:17:34 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: Message-ID: <018101cbc757$e058f6c0$a10ae440$@maris@donders.ru.nl> Dear David, > I can't tell if "minimum number of neighbors" means just spatial > neighbors (i.e., nearby sensors) or if includes temporal and frequency > neighbors as well. Could someone clarify? It means ONLY spatial neighbors. > Also, just to be clear, if I want to be able to detect an effect that > I think is at only a single electrode, I should set minnbchan to 0, > yes? If understand the parameter correctly, any greater value of > minnbchan will ignore clusters that are restricted to a single > electrode. No, with minnbchan=0, there are no constraints on the clusters. If you want clusters to be local (as opposed to stretched over a large part of the scalp), minnbchan should be given a high value. Best, Eric dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > thanks for your help, > -David > > > -- > David Groppe, Ph.D. > dgroppe at cogsci.ucsd.edu > http://www.cogsci.ucsd.edu/~dgroppe/ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From dgroppe at cogsci.ucsd.edu Tue Feb 8 15:18:07 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Tue, 8 Feb 2011 09:18:07 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <-132249673793097681@unknownmsgid> References: <-132249673793097681@unknownmsgid> Message-ID: On Tue, Feb 8, 2011 at 1:17 AM, Eric Maris wrote: > Dear David, > > >> I can't tell if "minimum number of neighbors" means just spatial >> neighbors (i.e., nearby sensors) or if includes temporal and frequency >> neighbors as well.  Could someone clarify? > > It means ONLY spatial neighbors. > >> Also, just to be clear, if I want to be able to detect an effect that >> I think is at only a single electrode, I should set minnbchan to 0, >> yes?  If understand the parameter correctly, any greater value of >> minnbchan will ignore clusters that are restricted to a single >> electrode. > > No, with minnbchan=0, there are no constraints on the clusters. If you want > clusters to be local (as opposed to stretched over a large part of the > scalp), minnbchan should be given a high value. Thanks very much for the email Eric, but I'm confused as to why you answered "No" to my second comment. From what I understand, if you use a value of minnbchan that is greater than 0, then any significant clusters will necessarily spread across multiple electrodes. For example, if you set minnbchan to 1, then all significant clusters will have to include at least two electrodes so that each significant "voxel" has at least one neighbor at another electrode. Thus, if your effect is truly at only a single electrode, having a value of minnbchan greater than 0 will force you to miss the effect or to think it occurs at more electrodes than it really does. What part of my reasoning is incorrect? again, thanks very much for the help, -David > Best, > > Eric > > > dr. Eric Maris > Donders Institute for Brain, Cognition and Behavior > Radboud University > P.O. Box 9104 > 6500 HE Nijmegen > The Netherlands > T:+31 24 3612651 > Mobile: 06 39584581 > F:+31 24 3616066 > mailto:e.maris at donders.ru.nl > http://www.nphyscog.com/ > > > > > > > > >>     thanks for your help, >>         -David >> >> >> -- >> David Groppe, Ph.D. >> dgroppe at cogsci.ucsd.edu >> http://www.cogsci.ucsd.edu/~dgroppe/ >> _______________________________________________ >> 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 > -- David Groppe, Ph.D. Postdoctoral Researcher Kutaslab Dept. of Cognitive Science University of California, San Diego http://www.cogsci.ucsd.edu/~dgroppe/ From fredericroux at hotmail.de Tue Feb 8 16:16:56 2011 From: fredericroux at hotmail.de (Frederic Roux) Date: Tue, 8 Feb 2011 16:16:56 +0100 Subject: [FieldTrip] single trial beamforming Message-ID: Dear list-members, I would like to compute a common frequency specific DICS spatial filter for my baseline and post-stimulus time window as an average across trials, and then use this filter on a trial by trial basis to do the beam-forming for the baseline and post-stimulus time window separately. The reason is that I would like to localize the generators of sustained task-related beta-band activity (1.2 seconds). The code I am planning to use looks as follows: cfg = []; cfg.channel = {'MEG' '-MLP12' '-MLT41' '-MRC12' '-MRC14' '-MRC25' '-MRP56' '-MRT21' '-MLT57' '-MLT52' '-MRF22' '-MRF13' '-MRF24' '-MRF43' '-MLO22' '-MLF25' '-MRO31' '-MRO21'}; cfg.grid = warped_grid.grid; cfg.vol = warped_grid.hdm; cfg.frequency = 15; cfg.method = 'dics'; cfg.projectnoise = 'yes'; cfg.keepfilter = 'yes'; cfg.lambda = 0.05; cfg.dim = [Nx Ny Nz]; cfg.rawtrial = 'no'; cfg.keeptrials = 'no'; [common_filt] = sourceanalysis(cfg,common_TF); cfg.grid.filter = common_filt.avg.filter; cfg.rawtrial = 'yes'; cfg.keeptrials = 'yes'; [pre_source] = sourceanalysis(cfg,pre_TF) [post_source] =sourceanalysis(cfg,post_TF); Can anyone tell me if this code would be ok? I am not sure if is correct to specify the cfg.rawtrial = 'yes' option. Any help would be appreciated. Thanks, fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Tue Feb 8 16:33:25 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Tue, 8 Feb 2011 15:33:25 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> Message-ID: <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Hi Scott - Thanks for the e-mail - it's a good point. The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. Unless you can think of a better solution, my suggestion would be first to call hdr=ft_read_header(fname); in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with fclose(hdr.orig.raw.fid); Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. Cheers, Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 4 Feb 2011, at 16:12, Scott Burns wrote: > FieldTrip Experts - > > I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. > > I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. > > I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. > > FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). > > > Scott Burns > Kuperberg Lab > Martinos Center for Biomedical Imaging > sburns at nmr.mgh.harvard.edu > > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > _______________________________________________ > 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 e.maris at donders.ru.nl Tue Feb 8 17:01:46 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 8 Feb 2011 17:01:46 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: <-132249673793097681@unknownmsgid> Message-ID: <01d801cbc7a9$7ca7e710$75f7b530$@maris@donders.ru.nl> Dear David, > Thanks very much for the email Eric, but I'm confused as to why you > answered "No" to my second comment. From what I understand, if you > use a value of minnbchan that is greater than 0, then any significant > clusters will necessarily spread across multiple electrodes. For > example, if you set minnbchan to 1, then all significant clusters will > have to include at least two electrodes so that each significant > "voxel" has at least one neighbor at another electrode. Thus, if your > effect is truly at only a single electrode, having a value of > minnbchan greater than 0 will force you to miss the effect or to think > it occurs at more electrodes than it really does. What part of my > reasoning is incorrect? Your reasoning is correct and mine was incorrect. I should read better before I write. My apologies for this. I do have to qualify that with minnbchan=0 it may also happen that your significant cluster contains more than one electrode (the electrode with the true effect plus some surrounding ones that by accident exceed the threshold that is used to identify clusters). Best, Eric > again, thanks very much for the help, > -David > > > > Best, > > > > Eric > > > > > > dr. Eric Maris > > Donders Institute for Brain, Cognition and Behavior > > Radboud University > > P.O. Box 9104 > > 6500 HE Nijmegen > > The Netherlands > > T:+31 24 3612651 > > Mobile: 06 39584581 > > F:+31 24 3616066 > > mailto:e.maris at donders.ru.nl > > http://www.nphyscog.com/ > > > > > > > > > > > > > > > > > >>     thanks for your help, > >>         -David > >> > >> > >> -- > >> David Groppe, Ph.D. > >> dgroppe at cogsci.ucsd.edu > >> http://www.cogsci.ucsd.edu/~dgroppe/ > >> _______________________________________________ > >> 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 > > > > > > -- > David Groppe, Ph.D. > Postdoctoral Researcher > Kutaslab > Dept. of Cognitive Science > University of California, San Diego > http://www.cogsci.ucsd.edu/~dgroppe/ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From dgroppe at cogsci.ucsd.edu Tue Feb 8 19:18:59 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Tue, 8 Feb 2011 13:18:59 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <2657614842150526102@unknownmsgid> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid> Message-ID: On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris wrote: > Dear David, > > >> Thanks very much for the email Eric, but I'm confused as to why you >> answered "No" to my second comment.  From what I understand, if you >> use a value of minnbchan that is greater than 0, then any significant >> clusters will necessarily spread across multiple electrodes.  For >> example, if you set minnbchan to 1, then all significant clusters will >> have to include at least two electrodes so that each significant >> "voxel" has at least one neighbor at another electrode.  Thus, if your >> effect is truly at only a single electrode, having a value of >> minnbchan greater than 0 will force you to miss the effect or to think >> it occurs at more electrodes than it really does.  What part of my >> reasoning is incorrect? > > Your reasoning is correct and mine was incorrect. I should read better > before I write. My apologies for this. Got it. Thanks very much for clarifying Eric. > > I do have to qualify that with minnbchan=0 it may also happen that your > significant cluster contains more than one electrode (the electrode with the > true effect plus some surrounding ones that by accident exceed the threshold > that is used to identify clusters). That makes perfect sense. Since our lab uses only a limited number of electrodes (32), I wanted to make sure I understood the minimum number of electrodes an effect needs to span to be detected. once again, I very much appreciate your answers to my questions, -David > Best, > > Eric > > > > >>      again, thanks very much for the help, >>             -David >> >> >> > Best, >> > >> > Eric >> > >> > >> > dr. Eric Maris >> > Donders Institute for Brain, Cognition and Behavior >> > Radboud University >> > P.O. Box 9104 >> > 6500 HE Nijmegen >> > The Netherlands >> > T:+31 24 3612651 >> > Mobile: 06 39584581 >> > F:+31 24 3616066 >> > mailto:e.maris at donders.ru.nl >> > http://www.nphyscog.com/ >> > >> > >> > >> > >> > >> > >> > >> > >> >>     thanks for your help, >> >>         -David >> >> >> >> >> >> -- >> >> David Groppe, Ph.D. >> >> dgroppe at cogsci.ucsd.edu >> >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> David Groppe, Ph.D. >> Postdoctoral Researcher >> Kutaslab >> Dept. of Cognitive Science >> University of California, San Diego >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >> _______________________________________________ >> 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 > -- David Groppe, Ph.D. Postdoctoral Researcher Kutaslab Dept. of Cognitive Science University of California, San Diego http://www.cogsci.ucsd.edu/~dgroppe/ From r.oostenveld at donders.ru.nl Wed Feb 9 10:25:13 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 9 Feb 2011 10:25:13 +0100 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> Message-ID: <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Dear Scott, thanks for reporting this problem and for already tracking it down to files not being closed. ft_read_data does the following on every read-request (line 772), case {'neuromag_fif' 'neuromag_mne'} % check that the required low-level toolbox is available ft_hastoolbox('mne', 1); if (hdr.orig.iscontinuous) dat = fiff_read_raw_segment(hdr.orig.raw,begsample+hdr.orig.raw.first_samp-1,endsample+hdr.orig.raw.first_samp-1,chanindx); from this I understand that the file is already supposed to be open and represented in hdr.orig.raw (hdr.orig is in general where fieldtrip stores the original header details, i.e. including all system specific information). and prior to that it does (line 223) % read the header if it is not provided if isempty(hdr) hdr = ft_read_header(filename, 'headerformat', headerformat); end I would expect the part on ft_read_header not to be executed on every call to ft_read_data, because in general ft_read_header has already been called outside ft_read_data (e.g. to select the channels prior to start the reading). So ft_preprocessing calls ft_read_header once and ft_read_data many times. and in ft_read_header it does orig = fiff_read_meas_info(filename); and raw = fiff_setup_read_raw(filename); Diagnosis: ft_read_header opens the file, ft_read_data keeps it open. Then you move to the next file, and that one is also opened (and kept open). Hmm, indeed a problem. The design idea is that reading from files shoudl be stateless, i.e. prior and after each read operation the file should be closed. On modern file systems there is no penalty associated with that, and it keeps the code much cleaner. That is why fieldtrip does not have a ft_open_file and ft_close_file function, and why you cannot close the file (except with fclose('all')). Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw are supposed to keep the files open? I could not find a fiff_close function, do you know whether there is one? best Robert PS let's do the follow up discussion via the bug tracking system and not on the email list... you should have received a mail from that by now. On 4 Feb 2011, at 17:12, Scott Burns wrote: > FieldTrip Experts - > > I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. > > I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. > > I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. > > FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). > > > Scott Burns > Kuperberg Lab > Martinos Center for Biomedical Imaging > sburns at nmr.mgh.harvard.edu > > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > _______________________________________________ > 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 r.oostenveld at donders.ru.nl Wed Feb 9 10:43:55 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 9 Feb 2011 10:43:55 +0100 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Message-ID: Hi Laurence thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. best Robert On 8 Feb 2011, at 16:33, Laurence Hunt wrote: > Hi Scott - > > Thanks for the e-mail - it's a good point. > > The difficulty arises because fiff_setup_read_raw (called by > ft_read_header) leaves the .fif file open to be read (it stores the > fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for > fieldtrip). Unfortunately if we closed it at this stage (i.e. within > ft_read_header), fiff_read_raw_segment, which is called by > ft_read_data/ft_read_event, doesn't know where to look for the file > - it expects a structure to be returned by fiff_setup_read_raw with > an open file. Again, we could close the file after calling > fiff_read_raw_segment in ft_read_data, but this would assume that > ft_read_data/ft_read_event is only going to be called once, whereas > some users might want to use hdr=ft_read_header once and then keep > on using ft_read_data with same hdr structure, in which case we need > to keep the file open. > > Unless you can think of a better solution, my suggestion would be > first to call > > hdr=ft_read_header(fname); > > in your script, then supply this hdr to your calls to ft_read_event/ > ft_read_data (this should hopefully prevent the file being opened > multiple times), and then once you have done all the reading, close > that file with > > fclose(hdr.orig.raw.fid); > > Hopefully that will stop you clogging up matlab with open files. Let > me know if it works or not. > > Cheers, > Laurence > > =========================================== > Laurence Hunt, DPhil Student > Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > > On 4 Feb 2011, at 16:12, Scott Burns wrote: > >> FieldTrip Experts - >> >> I'm building a FieldTrip pipeline for use on M/EEG data collected >> on a Neuromag 306 system. Because I'm looping over subjects (13 >> currently), event type (5 unique events), and number of runs (4), >> there's lots of preprocessing to do. After processing a certain >> amount of files, MATLAB refuses to open more files. >> >> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only >> include the data files I'm using, not MATLAB's system files) and >> found that for every innermost loop, my script is opening the .fif >> file twice and not releasing it. I use a custom function for >> ft_definetrial and in that I use ft_read_event (that operates on >> the .fif file). After defining trials, I use ft_preprocessing. >> >> I would venture to guess that both ft_read_event and ft_read_data >> (ft_preprocessing:line 492) are either 1) not closing files they've >> opened (presumably through MNE functions), or 2) they're using >> shared code that doesn't close files. I use MNE and haven't run >> into this issue before. That being said, fclose('all') does close >> all these files but I think it's still worth looking into. >> >> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >> >> >> Scott Burns >> Kuperberg Lab >> Martinos Center for Biomedical Imaging >> sburns at nmr.mgh.harvard.edu >> >> The information in this e-mail is intended only for the person to >> whom it is addressed. If you believe this e-mail was sent to you in >> error and the e-mail contains patient information, please contact >> the Partners Compliance HelpLine at http://www.partners.org/complianceline >> . If the e-mail was sent to you in error but does not contain >> patient information, please contact the sender and properly dispose >> of the e-mail. >> >> >> >> >> _______________________________________________ >> 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 lhunt at fmrib.ox.ac.uk Wed Feb 9 13:21:07 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 12:21:07 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Message-ID: <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> Hi Robert, (i) Re-running fiff_setup_read_raw in ft_read_data might slow down operations with multiple calls to ft_read_data (e.g. reading multiple trials from a raw dataset), as it takes about half a second to execute fiff_setup_read_raw once. (ii) Just using fopen and fclose would be much faster, but fiff_setup_read_raw does indeed move the file cursor to a new position, so I think the best solution is to store this position after the file has been opened by fiff_setup_read_raw. So, within ft_read_header, add: raw.pos = ftell(raw.fid); fclose(raw.fid); and in ft_read_data, add hdr.orig.raw.fid = fopen(filename,'rb','ieee-be'); fseek(hdr.orig.raw.fid,hdr.orig.raw.pos,'bof'); before the call to fiff_read_raw_segment, and fclose it afterwards. This seems to work fine if I make these amendments to my version of the code. Hope this helps, Laurence On 9 Feb 2011, at 09:43, Robert Oostenveld wrote: > Hi Laurence > > thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. > > Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? > > If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). > > Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). > > What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. > > best > Robert > > > > On 8 Feb 2011, at 16:33, Laurence Hunt wrote: > >> Hi Scott - >> >> Thanks for the e-mail - it's a good point. >> >> The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. >> >> Unless you can think of a better solution, my suggestion would be first to call >> >> hdr=ft_read_header(fname); >> >> in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with >> >> fclose(hdr.orig.raw.fid); >> >> Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. >> >> Cheers, >> Laurence >> >> =========================================== >> Laurence Hunt, DPhil Student >> Centre for Functional MRI of the Brain (FMRIB), >> University of Oxford >> lhunt at fmrib.ox.ac.uk >> Phone: (+44)1865-(2)22738 >> =========================================== >> >> On 4 Feb 2011, at 16:12, Scott Burns wrote: >> >>> FieldTrip Experts - >>> >>> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >>> >>> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >>> >>> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >>> >>> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >>> >>> >>> Scott Burns >>> Kuperberg Lab >>> Martinos Center for Biomedical Imaging >>> sburns at nmr.mgh.harvard.edu >>> >>> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Wed Feb 9 13:22:18 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 12:22:18 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> Message-ID: p.s. I think this only applies to continuous data - evoked responses are closed in ft_read_header already, I think. L On 9 Feb 2011, at 12:21, Laurence Hunt wrote: > Hi Robert, > > (i) Re-running fiff_setup_read_raw in ft_read_data might slow down operations with multiple calls to ft_read_data (e.g. reading multiple trials from a raw dataset), as it takes about half a second to execute fiff_setup_read_raw once. > > (ii) Just using fopen and fclose would be much faster, but fiff_setup_read_raw does indeed move the file cursor to a new position, so I think the best solution is to store this position after the file has been opened by fiff_setup_read_raw. So, within ft_read_header, add: > > raw.pos = ftell(raw.fid); > fclose(raw.fid); > > and in ft_read_data, add > > hdr.orig.raw.fid = fopen(filename,'rb','ieee-be'); > fseek(hdr.orig.raw.fid,hdr.orig.raw.pos,'bof'); > > before the call to fiff_read_raw_segment, and fclose it afterwards. This seems to work fine if I make these amendments to my version of the code. > > Hope this helps, > Laurence > > On 9 Feb 2011, at 09:43, Robert Oostenveld wrote: > >> Hi Laurence >> >> thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. >> >> Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? >> >> If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). >> >> Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). >> >> What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. >> >> best >> Robert >> >> >> >> On 8 Feb 2011, at 16:33, Laurence Hunt wrote: >> >>> Hi Scott - >>> >>> Thanks for the e-mail - it's a good point. >>> >>> The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. >>> >>> Unless you can think of a better solution, my suggestion would be first to call >>> >>> hdr=ft_read_header(fname); >>> >>> in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with >>> >>> fclose(hdr.orig.raw.fid); >>> >>> Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. >>> >>> Cheers, >>> Laurence >>> >>> =========================================== >>> Laurence Hunt, DPhil Student >>> Centre for Functional MRI of the Brain (FMRIB), >>> University of Oxford >>> lhunt at fmrib.ox.ac.uk >>> Phone: (+44)1865-(2)22738 >>> =========================================== >>> >>> On 4 Feb 2011, at 16:12, Scott Burns wrote: >>> >>>> FieldTrip Experts - >>>> >>>> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >>>> >>>> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >>>> >>>> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >>>> >>>> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >>>> >>>> >>>> Scott Burns >>>> Kuperberg Lab >>>> Martinos Center for Biomedical Imaging >>>> sburns at nmr.mgh.harvard.edu >>>> >>>> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > =========================================== > Laurence Hunt, DPhil Student > Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From sburns at nmr.mgh.harvard.edu Wed Feb 9 16:27:14 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 10:27:14 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: <9F93CD03-78CC-4D03-BF55-239D5D12EFD0@nmr.mgh.harvard.edu> I tried replying to the latest email from the bug tracker but got back a Delivery Failure. What'd I do wrong? (the error was the bugzilla_daemon at fcdonders.ru.nl is an unknown or illegal alias) Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. On Feb 9, 2011, at 4:25 AM, Robert Oostenveld wrote: > Dear Scott, > > thanks for reporting this problem and for already tracking it down to files not being closed. > > ft_read_data does the following on every read-request (line 772), > case {'neuromag_fif' 'neuromag_mne'} > % check that the required low-level toolbox is available > ft_hastoolbox('mne', 1); > if (hdr.orig.iscontinuous) > dat = fiff_read_raw_segment(hdr.orig.raw,begsample+hdr.orig.raw.first_samp-1,endsample+hdr.orig.raw.first_samp-1,chanindx); > > from this I understand that the file is already supposed to be open and represented in hdr.orig.raw (hdr.orig is in general where fieldtrip stores the original header details, i.e. including all system specific information). > > and prior to that it does (line 223) > % read the header if it is not provided > if isempty(hdr) > hdr = ft_read_header(filename, 'headerformat', headerformat); > end > > I would expect the part on ft_read_header not to be executed on every call to ft_read_data, because in general ft_read_header has already been called outside ft_read_data (e.g. to select the channels prior to start the reading). So ft_preprocessing calls ft_read_header once and ft_read_data many times. > > and in ft_read_header it does > orig = fiff_read_meas_info(filename); > and > raw = fiff_setup_read_raw(filename); > > Diagnosis: ft_read_header opens the file, ft_read_data keeps it open. Then you move to the next file, and that one is also opened (and kept open). Hmm, indeed a problem. The design idea is that reading from files shoudl be stateless, i.e. prior and after each read operation the file should be closed. On modern file systems there is no penalty associated with that, and it keeps the code much cleaner. That is why fieldtrip does not have a ft_open_file and ft_close_file function, and why you cannot close the file (except with fclose('all')). > > Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw are supposed to keep the files open? I could not find a fiff_close function, do you know whether there is one? > > best > Robert > > PS let's do the follow up discussion via the bug tracking system and not on the email list... you should have received a mail from that by now. > > > On 4 Feb 2011, at 17:12, Scott Burns wrote: > >> FieldTrip Experts - >> >> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >> >> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >> >> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >> >> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >> >> >> Scott Burns >> Kuperberg Lab >> Martinos Center for Biomedical Imaging >> sburns at nmr.mgh.harvard.edu >> >> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >> >> >> >> >> _______________________________________________ >> 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 gramfort at nmr.mgh.harvard.edu Wed Feb 9 16:31:02 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 10:31:02 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi, > The design idea is that reading from files shoudl be > stateless, i.e. prior and after each read operation the file should be > closed. On modern file systems there is no penalty associated with that, and > it keeps the code much cleaner. That is why fieldtrip does not have a > ft_open_file and ft_close_file function, and why you cannot close the file > (except with fclose('all')). > Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw > are supposed to keep the files open? I could not find a fiff_close function, > do you know whether there is one? fiff_setup_read_raw keeps the files open for subsequent calls of fiff_read_raw_segment, fiff_read_raw_segment_times etc. when done the file can be closed with : fclose(raw.fid) assuming you used: raw = fiff_setup_read_raw(filename); FYI (I wanted to wait but it seems to be a good occasion) the mne-matlab code is now publicly hosted on line: https://github.com/mne-tools/mne-matlab latest commits: https://github.com/mne-tools/mne-matlab/commits/master the license of this code has been changed to BSD. If you have feature request, bug reports or willing to contribute some code that's a good place to do it. If you need help, just send me an email. If fieldtripers turn out to modify the mne matlab code it would be great to consider applying the modifications on the main repository. Alex -- Alexandre Gramfort, PhD gramfort at nmr.mgh.harvard.edu Dept. of Radiology MGH Martinos Center / Harvard Medical School http://www-sop.inria.fr/members/Alexandre.Gramfort/ From v.litvak at ion.ucl.ac.uk Wed Feb 9 16:54:29 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 15:54:29 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi Alexandre, So why does fiff_setup_read_raw take so long? Do you really need half a second to open a fif file or does it also read some header data not all of which is necessary? Could there perhaps be a faster version for repeated calls that would make it possible to keep fileio code stateless? Vladimir On Wed, Feb 9, 2011 at 3:31 PM, Alexandre Gramfort wrote: > Hi, > >> The design idea is that reading from files shoudl be >> stateless, i.e. prior and after each read operation the file should be >> closed. On modern file systems there is no penalty associated with that, and >> it keeps the code much cleaner. That is why fieldtrip does not have a >> ft_open_file and ft_close_file function, and why you cannot close the file >> (except with fclose('all')). >> Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw >> are supposed to keep the files open? I could not find a fiff_close function, >> do you know whether there is one? > > fiff_setup_read_raw keeps the files open for subsequent calls of > fiff_read_raw_segment, fiff_read_raw_segment_times etc. > > when done the file can be closed with : > > fclose(raw.fid) > > assuming you used: > raw = fiff_setup_read_raw(filename); > > FYI (I wanted to wait but it seems to be a good occasion) > the mne-matlab code is now publicly hosted on line: > > https://github.com/mne-tools/mne-matlab > > latest commits: > https://github.com/mne-tools/mne-matlab/commits/master > > the license of this code has been changed to BSD. > > If you have feature request, bug reports or willing to contribute some code > that's a good place to do it. If you need help, just send me an email. > > If fieldtripers turn out to modify the mne matlab code it would be great to > consider applying the modifications on the main repository. > > Alex > -- > Alexandre Gramfort, PhD > gramfort at nmr.mgh.harvard.edu > Dept. of Radiology MGH Martinos Center / Harvard Medical School > http://www-sop.inria.fr/members/Alexandre.Gramfort/ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 17:05:51 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 11:05:51 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi Vladimir, > So why does fiff_setup_read_raw take so long? Do you really need half > a second to open a fif file or does it also read some header data not > all of which is necessary? fiff_setup_read_raw reads many things from the fif file: - measurement info - sampling rate - first/last time sample to do this it locates in the file the location of all the info (the fif tags). So when you look for something in the file, you go down the tree (in matlab) and that points you to the location in the file where to read. > Could there perhaps be a faster version for > repeated calls that would make it possible to keep fileio code > stateless? we could write a single function that does both : fiff_setup_read_raw and fiff_read_raw_segment if it can help. Alex From v.litvak at ion.ucl.ac.uk Wed Feb 9 17:16:19 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 16:16:19 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: The question is if it would be possible to pre-read those fif tags and all the other info and store it in the header, then close the file and then given just the samples to read to open it again and navigate fast to the right place based on the info that has been stored before? Those tags don't change (do they?) so it should be sufficient to read them once. Vladimir On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort wrote: > Hi Vladimir, > >> So why does fiff_setup_read_raw take so long? Do you really need half >> a second to open a fif file or does it also read some header data not >> all of which is necessary? > > fiff_setup_read_raw reads many things from the fif file: > - measurement info > - sampling rate > - first/last time sample > > to do this it locates in the file the location of all the info (the fif tags). > So when you look for something in the file, you go down the tree > (in matlab) and that points you to the location in the file where to read. > >> Could there perhaps be a faster version for >> repeated calls that would make it possible to keep fileio code >> stateless? > > we could write a single function that does both : > fiff_setup_read_raw and fiff_read_raw_segment > if it can help. > > Alex > > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 17:41:05 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 11:41:05 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: the filename is stored raw.info we could close the file after the fiff_setup_read_raw and then do raw.fid = fopen(raw.info.filename) before reading from it later. see my attempt : https://github.com/agramfort/mne-matlab/commit/5a88ef764a5931c14015708d372942ed2f892b6c would this solve your pb? Alex On Wed, Feb 9, 2011 at 11:16 AM, Vladimir Litvak wrote: > The question is if it would be possible to pre-read those fif tags and > all the other info and store it in the header, then close the file and > then given just the samples to read to open it again and navigate fast > to the right place based on the info that has been stored before? > Those tags don't change (do they?) so it should be sufficient to read > them once. > > Vladimir > > On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort > wrote: >> Hi Vladimir, >> >>> So why does fiff_setup_read_raw take so long? Do you really need half >>> a second to open a fif file or does it also read some header data not >>> all of which is necessary? >> >> fiff_setup_read_raw reads many things from the fif file: >> - measurement info >> - sampling rate >> - first/last time sample >> >> to do this it locates in the file the location of all the info (the fif tags). >> So when you look for something in the file, you go down the tree >> (in matlab) and that points you to the location in the file where to read. >> >>> Could there perhaps be a faster version for >>> repeated calls that would make it possible to keep fileio code >>> stateless? >> >> we could write a single function that does both : >> fiff_setup_read_raw and fiff_read_raw_segment >> if it can help. >> >> Alex >> >> > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in error > but does not contain patient information, please contact the sender and properly > dispose of the e-mail. > > From lhunt at fmrib.ox.ac.uk Wed Feb 9 18:35:46 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 17:35:46 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Hi Alex, I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). So we need to store the cursor position too. See my earlier e-mail. Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 9 Feb 2011, at 16:41, Alexandre Gramfort wrote: > the filename is stored raw.info > > we could close the file after the fiff_setup_read_raw > and then do > raw.fid = fopen(raw.info.filename) > before reading from it later. > > see my attempt : > > https://github.com/agramfort/mne-matlab/commit/5a88ef764a5931c14015708d372942ed2f892b6c > > would this solve your pb? > > Alex > > On Wed, Feb 9, 2011 at 11:16 AM, Vladimir Litvak wrote: >> The question is if it would be possible to pre-read those fif tags and >> all the other info and store it in the header, then close the file and >> then given just the samples to read to open it again and navigate fast >> to the right place based on the info that has been stored before? >> Those tags don't change (do they?) so it should be sufficient to read >> them once. >> >> Vladimir >> >> On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort >> wrote: >>> Hi Vladimir, >>> >>>> So why does fiff_setup_read_raw take so long? Do you really need half >>>> a second to open a fif file or does it also read some header data not >>>> all of which is necessary? >>> >>> fiff_setup_read_raw reads many things from the fif file: >>> - measurement info >>> - sampling rate >>> - first/last time sample >>> >>> to do this it locates in the file the location of all the info (the fif tags). >>> So when you look for something in the file, you go down the tree >>> (in matlab) and that points you to the location in the file where to read. >>> >>>> Could there perhaps be a faster version for >>>> repeated calls that would make it possible to keep fileio code >>>> stateless? >>> >>> we could write a single function that does both : >>> fiff_setup_read_raw and fiff_read_raw_segment >>> if it can help. >>> >>> Alex >>> >>> >> >> >> The information in this e-mail is intended only for the person to whom it is >> addressed. If you believe this e-mail was sent to you in error and the e-mail >> contains patient information, please contact the Partners Compliance HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you in error >> but does not contain patient information, please contact the sender and properly >> dispose of the e-mail. >> >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 19:16:41 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 13:16:41 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Message-ID: hi, > I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). ok. That was a quick and dirty hack to give an idea. > So we need to store the cursor position too. See my earlier e-mail. maybe you or scott can propose a fix in the same vein? I can give you write access to the mne-matlab code if you want. Alex From sburns at nmr.mgh.harvard.edu Wed Feb 9 19:44:19 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 13:44:19 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Message-ID: <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> --I tried sending this on the bug report thread but got a delivery failure notice -- Robert, Laurence and Alexandre - Thanks for the feedback on this issue. Here are my thoughts on further investigation. Since ft_preprocessing calls its own ft_read_header (ft_preprocessing:327), ft_read_event isn't actually going for data, and that ft_definetrial and ft_preprocessing are separate high-level functions, then I think we can assume that no actual data will be read during ft_read_event and the file can be closed towards the end of the ft_read_event function. That closes one leak. Because ft_preprocessing is one of the high-level functions of FT and that the function is structured to operate on the data file once per event, it should clean up anything it opened. It'd be simple enough to check if hdr.orig.raw.fid is still open after all the data reading has been done (after ft_preprocessing:530) and close it. This way, you wouldn't have to fundamentally change how ft_read_data operates on neuromag files. I'm not sure how the architecture of FT deals with other file formats and whether this is sort of leak can occur in other situations, but this seems to be the easiest fix to this problem. Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. On Feb 9, 2011, at 1:16 PM, Alexandre Gramfort wrote: > hi, > >> I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). > > ok. That was a quick and dirty hack to give an idea. > >> So we need to store the cursor position too. See my earlier e-mail. > > maybe you or scott can propose a fix in the same vein? > > I can give you write access to the mne-matlab code if you want. > > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanweisz at mac.com Wed Feb 9 21:25:42 2011 From: nathanweisz at mac.com (Nathan Weisz) Date: Wed, 09 Feb 2011 21:25:42 +0100 Subject: [FieldTrip] dipolefitting issues Message-ID: <881B6122-2D39-4716-B1F6-6244DDE06703@mac.com> hi everyone, i'm trying to help out a colleague who is trying to analyse some auditory evoked potential (EEG) data and for the research question at hand it would be nice to separate left vs. right hemisphere. we want to keep things simple first by fitting symmetric dipoles to e.g. the N1 and then use the positions to estimate the dipole moments for the entire ERP. the ERP that we want to build the source montage on is calculated from ~600 trials, i.e. we see what we need to see very nicely. we are using a spherical headmodel (electrode positions also on sphere) as described on the FT homepage: vol = []; vol.r = [0.88 0.92 1.00]; % radii of spheres vol.c = [1 1/80 1]; % conductivity vol.o = [0 0 0]; using a precomputed leadfield i the turn to ft_dipolefitting: cfg = []; cfg.vol = vol; % see above cfg.elec = data.elec; % see above cfg.gridsearch = 'yes'; cfg.numdipoles=2; cfg.symmetry='y'; %nach den elec.pnt sieht es so aus als wäre y links / rechts cfg.grid=lf; cfg.latency=[.05 .1]; dip1 = ft_dipolefitting(cfg, avgbl); i get following message: ... > scanning grid location 279/280 > scanning grid location 280/280 > found minimum after scanning on grid point [-0.111111 0.111111 0.111111; -0.111111 -0.111111 0.111111] > First-order > Iteration Func-count f(x) Step-size optimality > 0 4 0.0406088 0.5 > > Local minimum possible. > > fminunc stopped because it cannot decrease the objective function > along the current search direction. > > > > found minimum after non-linear optimization on [-0.111111 0.111111 -0.111111; -0.111111 -0.111111 -0.111111] i then ran the tutorial example here: http://fieldtrip.fcdonders.nl/example/compute_forward_simulated_data_and_apply_a_dipole_fit just to check if there may be something fundamentally wrong with my code. however i get a similar message suggesting something went wrong: > scanning grid location 26/27 > scanning grid location 27/27 > found minimum after scanning on grid point [0 0.5 0.5] > First-order > Iteration Func-count f(x) Step-size optimality > 0 4 0.0293345 0.303 > 1 8 0.0079586 1 0.15 > 2 12 5.63895e-05 1 0.0138 > 3 16 5.75471e-06 1 0.00446 > 4 20 8.86701e-11 1 1.33e-05 > 5 24 1.45576e-14 1 1.3e-07 > 6 28 1.75862e-16 1 2.61e-08 > > Local minimum possible. > > fminunc stopped because the size of the current step is less than > the default value of the step size tolerance. > > > > found minimum after non-linear optimization on [-5.08281e-09 0.5 0.3] I am using Matlab 2010b. a fairly recent fieldtrip (~3 months old or so). there was a similar question on the archives, however i found no answer: http://mailman.science.ru.nl/pipermail/fieldtrip/2010-May/002874.html is this an issue related to the matlab version and the fminunc function? i would be grateful about any suggestion. cheers, nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.litvak at ion.ucl.ac.uk Wed Feb 9 21:48:35 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 20:48:35 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: Dear Scott, I think I know Robert's views quite well and he wouldn't like your solution because ft_preprocessing will have to deal with a format-specific low-level issue that should be handled by fileio. This will violate the software architecture which for FT is a big deal (and rightly so).  If, however, it is sufficient to store in the header a single number which can then be used to find the data onset and from there to find where to start reading (so perhaps not an fid but just the data offset in bytes to do fseek), that'd be a perfectly good solution and fast as well. But I don't know enough about  fif format to say if it's possible. Vladimir On Wednesday, February 9, 2011, Scott Burns wrote: > --I tried sending this on the bug report thread but got a delivery failure notice -- > > Robert, Laurence and Alexandre - > Thanks for the feedback on this issue. Here are my thoughts on further investigation. > Since ft_preprocessing calls its own ft_read_header (ft_preprocessing:327), ft_read_event isn't actually going for data, and that ft_definetrial and ft_preprocessing are separate high-level functions, then I think we can assume that no actual data will be read during ft_read_event and the file can be closed towards the end of the ft_read_event function. That closes one leak. > Because ft_preprocessing is one of the high-level functions of FT and that the function is structured to operate on the data file once per event, it should clean up anything it opened.  It'd be simple enough to check if hdr.orig.raw.fid is still open after all the data reading has been done (after ft_preprocessing:530) and close it.  This way, you wouldn't have to fundamentally change how ft_read_data operates on neuromag files. I'm not sure how the architecture of FT deals with other file formats and whether this is sort of leak can occur in other situations, but this seems to be the easiest fix to this problem. > > Scott BurnsKuperberg LabMartinos Center for Biomedical Imagingsburns at nmr.mgh.harvard.edu > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > On Feb 9, 2011, at 1:16 PM, Alexandre Gramfort wrote: > hi, > > I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). > > ok. That was a quick and dirty hack to give an idea. > > So we need to store the cursor position too. See my earlier e-mail. > > maybe you or scott can propose a fix in the same vein? > > I can give you write access to the mne-matlab code if you want. > > Alex > > > > From sburns at nmr.mgh.harvard.edu Wed Feb 9 22:06:09 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 16:06:09 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: <995D8606-7ED7-48BB-86FF-1CE529C97166@nmr.mgh.harvard.edu> On Feb 9, 2011, at 3:48 PM, Vladimir Litvak wrote: > think I know Robert's views quite well and he wouldn't like your > solution because ft_preprocessing will have to deal with a > format-specific low-level issue that should be handled by fileio. Makes sense, my solution is just a hack. Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Wed Feb 9 22:12:37 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 21:12:37 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> I think it should be possible to do it this way - when I tested it, it seemed to work OK. On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: > If, however, it is sufficient to store in the header a > single number which can then be used to find the data onset and from > there to find where to start reading (so perhaps not an fid but just > the data offset in bytes to do fseek), that'd be a perfectly good > solution and fast as well. But I don't know enough about fif format > to say if it's possible. =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== From gramfort at nmr.mgh.harvard.edu Wed Feb 9 22:17:54 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 16:17:54 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> Message-ID: again if something needs to be changed in the mne matlab code I'd be happy to help. Alex On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: > I think it should be possible to do it this way - when I tested it, it seemed to work OK. > > On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: > >> If, however, it is sufficient to store in the header a >> single number which can then be used to find the data onset and from >> there to find where to start reading (so perhaps not an fid but just >> the data offset in bytes to do fseek), that'd be a perfectly good >> solution and fast as well. But I don't know enough about  fif format >> to say if it's possible. > > =========================================== > Laurence Hunt, DPhil Student >  Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From lhunt at fmrib.ox.ac.uk Wed Feb 9 22:33:13 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 21:33:13 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> Message-ID: <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> Thanks Alex - I guess it might also be useful to add to the mne code instead, as long as it doesn't cause any problems elsewhere for other users...? Thinking about it, I reckon it would work if you used the same solution you suggested previously on your website, but just added data.pos = ftell(data.fid); %before running fclose in fiff_setup_read_raw and fseek(raw.fid,raw.pos); %after re-opening the file in fiff_read_raw_segment (...followed by an fclose of raw.fid at the end of fiff_read_raw_segment, of course). If you did this, it would save us making any changes in fieldtrip at all :) Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 9 Feb 2011, at 21:17, Alexandre Gramfort wrote: > again if something needs to be changed in the mne matlab code > I'd be happy to help. > > Alex > > On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: >> I think it should be possible to do it this way - when I tested it, it seemed to work OK. >> >> On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: >> >>> If, however, it is sufficient to store in the header a >>> single number which can then be used to find the data onset and from >>> there to find where to start reading (so perhaps not an fid but just >>> the data offset in bytes to do fseek), that'd be a perfectly good >>> solution and fast as well. But I don't know enough about fif format >>> to say if it's possible. >> >> =========================================== >> Laurence Hunt, DPhil Student >> Centre for Functional MRI of the Brain (FMRIB), >> University of Oxford >> lhunt at fmrib.ox.ac.uk >> Phone: (+44)1865-(2)22738 >> =========================================== >> _______________________________________________ >> 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 michael.wibral at web.de Thu Feb 10 09:58:57 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 10 Feb 2011 09:58:57 +0100 (CET) Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, Message-ID: <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> Dear David, dear Eric, there is one additional side effect of specifying a LARGE minnbchan that actually leads to SMALLEr clusters in a certain sense. If I understand correctly, at any point in time&frequency the cluster has to have a spatial extension of minnbchan+1. So when you specify a large value the cluster may more easily be cut up into several smaller ones along the space&time dimension - which may or may not be desirable. Michael -----Ursprüngliche Nachricht----- Von: "David Groppe" Gesendet: Feb 8, 2011 7:18:59 PM An: "Email discussion list for the FieldTrip project" Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris wrote: >> Dear David, >> >> >>> Thanks very much for the email Eric, but I'm confused as to why you >>> answered "No" to my second comment.  From what I understand, if you >>> use a value of minnbchan that is greater than 0, then any significant >>> clusters will necessarily spread across multiple electrodes.  For >>> example, if you set minnbchan to 1, then all significant clusters will >>> have to include at least two electrodes so that each significant >>> "voxel" has at least one neighbor at another electrode.  Thus, if your >>> effect is truly at only a single electrode, having a value of >>> minnbchan greater than 0 will force you to miss the effect or to think >>> it occurs at more electrodes than it really does.  What part of my >>> reasoning is incorrect? >> >> Your reasoning is correct and mine was incorrect. I should read better >> before I write. My apologies for this. > >Got it. Thanks very much for clarifying Eric. > >> >> I do have to qualify that with minnbchan=0 it may also happen that your >> significant cluster contains more than one electrode (the electrode with the >> true effect plus some surrounding ones that by accident exceed the threshold >> that is used to identify clusters). > >That makes perfect sense. Since our lab uses only a limited number of >electrodes (32), I wanted to make sure I understood the minimum number >of electrodes an effect needs to span to be detected. > once again, I very much appreciate your answers to my questions, > -David > >> Best, >> >> Eric >> >> >> >> >>>      again, thanks very much for the help, >>>             -David >>> >>> >>> > Best, >>> > >>> > Eric >>> > >>> > >>> > dr. Eric Maris >>> > Donders Institute for Brain, Cognition and Behavior >>> > Radboud University >>> > P.O. Box 9104 >>> > 6500 HE Nijmegen >>> > The Netherlands >>> > T:+31 24 3612651 >>> > Mobile: 06 39584581 >>> > F:+31 24 3616066 >>> > mailto:e.maris at donders.ru.nl >>> > http://www.nphyscog.com/ >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>     thanks for your help, >>> >>         -David >>> >> >>> >> >>> >> -- >>> >> David Groppe, Ph.D. >>> >> dgroppe at cogsci.ucsd.edu >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ >>> >> _______________________________________________ >>> >> 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 >>> > >>> >>> >>> >>> -- >>> David Groppe, Ph.D. >>> Postdoctoral Researcher >>> Kutaslab >>> Dept. of Cognitive Science >>> University of California, San Diego >>> http://www.cogsci.ucsd.edu/~dgroppe/ >>> >>> _______________________________________________ >>> 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 >> > > > >-- >David Groppe, Ph.D. >Postdoctoral Researcher >Kutaslab >Dept. of Cognitive Science >University of California, San Diego >http://www.cogsci.ucsd.edu/~dgroppe/ > >_______________________________________________ >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From e.maris at donders.ru.nl Thu Feb 10 11:16:05 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Thu, 10 Feb 2011 11:16:05 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> Message-ID: <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> Hi Michael, > there is one additional side effect of specifying a LARGE minnbchan > that actually leads to SMALLEr clusters in a certain sense. If I > understand correctly, at any point in time&frequency the cluster has to > have a spatial extension of minnbchan+1. So when you specify a large > value the cluster may more easily be cut up into several smaller ones > along the space&time dimension - which may or may not be desirable. Whether it is a side effect or not, depends on how you look at it. For me it is its intended effect. I implemented the minnbchan-parameter after discussions with PhD-students that applied the cluster-based permutation statistics on channel-time-frequency data and produced significant clusters with weird shapes. Often, these shapes contained narrow "bridges" connecting nearby blobs in channel-time-frequency space. By increasing minnbchan, these bridges were removed and only the blobs remained. Although I understand the requests of the PhD-students that I discussed with, I find the discussions about the minnbchan-parameter not very rewarding. In fact, it is looking for isolated blobs that one would like to interpret as separate physiological entities. This contrast with the nature of the EEG/MEG data, which has poor spatial resolution (due to volume conduction and common pick-up), often poor spectral resolution (due to the short time windows of our time-resolved spectral analysis), and often poor time resolution (due to latency jitter over trials). Best, Eric > > Michael > > -----Ursprüngliche Nachricht----- > Von: "David Groppe" > Gesendet: Feb 8, 2011 7:18:59 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to > spatial neighbors? > > >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris > wrote: > >> Dear David, > >> > >> > >>> Thanks very much for the email Eric, but I'm confused as to why you > >>> answered "No" to my second comment. From what I understand, if you > >>> use a value of minnbchan that is greater than 0, then any > >>> significant clusters will necessarily spread across multiple > >>> electrodes. For example, if you set minnbchan to 1, then all > >>> significant clusters will have to include at least two electrodes > so > >>> that each significant "voxel" has at least one neighbor at another > >>> electrode. Thus, if your effect is truly at only a single > >>> electrode, having a value of minnbchan greater than 0 will force > you > >>> to miss the effect or to think it occurs at more electrodes than it > >>> really does. What part of my reasoning is incorrect? > >> > >> Your reasoning is correct and mine was incorrect. I should read > >> better before I write. My apologies for this. > > > >Got it. Thanks very much for clarifying Eric. > > > >> > >> I do have to qualify that with minnbchan=0 it may also happen that > >> your significant cluster contains more than one electrode (the > >> electrode with the true effect plus some surrounding ones that by > >> accident exceed the threshold that is used to identify clusters). > > > >That makes perfect sense. Since our lab uses only a limited number of > >electrodes (32), I wanted to make sure I understood the minimum number > >of electrodes an effect needs to span to be detected. > > once again, I very much appreciate your answers to my questions, > > -David > > > >> Best, > >> > >> Eric > >> > >> > >> > >> > >>> again, thanks very much for the help, > >>> -David > >>> > >>> > >>> > Best, > >>> > > >>> > Eric > >>> > > >>> > > >>> > dr. Eric Maris > >>> > Donders Institute for Brain, Cognition and Behavior Radboud > >>> > University P.O. Box 9104 6500 HE Nijmegen The Netherlands > >>> > T:+31 24 3612651 > >>> > Mobile: 06 39584581 > >>> > F:+31 24 3616066 > >>> > mailto:e.maris at donders.ru.nl > >>> > http://www.nphyscog.com/ > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> >> thanks for your help, > >>> >> -David > >>> >> > >>> >> > >>> >> -- > >>> >> David Groppe, Ph.D. > >>> >> dgroppe at cogsci.ucsd.edu > >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ > >>> >> _______________________________________________ > >>> >> 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 > >>> > > >>> > >>> > >>> > >>> -- > >>> David Groppe, Ph.D. > >>> Postdoctoral Researcher > >>> Kutaslab > >>> Dept. of Cognitive Science > >>> University of California, San Diego > >>> http://www.cogsci.ucsd.edu/~dgroppe/ > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > > >-- > >David Groppe, Ph.D. > >Postdoctoral Researcher > >Kutaslab > >Dept. of Cognitive Science > >University of California, San Diego > >http://www.cogsci.ucsd.edu/~dgroppe/ > > > >_______________________________________________ > >fieldtrip mailing list > >fieldtrip at donders.ru.nl > >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From lucie.charles.ens at googlemail.com Thu Feb 10 11:58:43 2011 From: lucie.charles.ens at googlemail.com (Lucie Charles) Date: Thu, 10 Feb 2011 11:58:43 +0100 Subject: [FieldTrip] Modification of ft_timelockgrandaverage cfg.keepindividual Message-ID: Hello everyone, It seems that there has been a modification of ft_timelockgrandaverage : now if you specify cfg.keepindividual = 'yes', the grandaverage is computed but is not included in the output of the function (see above). Why is that ? Many of my scripts rely on this option and I wanted to know if there was a good reason for it. Thanks, Lucie New version of ft_timelockgrandaverage (downloaded yesterday), line 159-176 %-------------------------------------------- % % collect the results %-------------------------------------------- grandavg = []; grandavg.label = cfg.channel; % cell-array %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete grandavg.time = ResultsTime; % 1 x Nsamples %KEEP INDIVIDUAL MEANS? if strcmp(cfg.keepindividual, 'yes') * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples grandavg.dimord = 'subj_chan_time';* else * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* grandavg.var = ResultVar; % Nchan x Nsamples grandavg.dimord = 'chan_time'; end Older version of ft_timelockgrandaverage (april 2010) %-------------------------------------------- % % collect the results %-------------------------------------------- %SWITCH CHANNEL TO LABEL? grandavg.label = cfg.channel; % cell-array grandavg.fsample = varargin{1}.fsample; grandavg.avg = ResultGrandavg; % Nchan x Nsamples grandavg.var = ResultVar; % Nchan x Nsamples grandavg.time = ResultsTime; % 1 x Nsamples %KEEP INDIVIDUAL MEANS? if strcmp(cfg.keepindividual, 'yes') grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples grandavg.dimord = 'subj_chan_time'; else grandavg.dimord = 'chan_time'; end -- Lucie CHARLES INSERM-CEA Cognitive Neuroimaging unit CEA/SAC/DSV/DRM/NeuroSpin Bât 145, Point Courrier 156 F-91191 Gif/Yvette, FRANCE Tel : +33 1 69 08 99 74 Fax : +33 1 69 08 79 73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 10 12:17:21 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 10 Feb 2011 12:17:21 +0100 Subject: [FieldTrip] Modification of ft_timelockgrandaverage cfg.keepindividual In-Reply-To: References: Message-ID: <99137929-ED6C-41A8-A70C-2C3F94E8AF76@donders.ru.nl> Dear Lucie, Yes, indeed this has recently been changed. The logic behind it is the following: One either typically wants to keep the individuals, OR the average. If in your case you need the average, you have to specify cfg.keepindividual = 'no'; Keeping both the average and the individual leads to an inconsistent definition of the data structure. The field 'dimord' does not allow for an unequivocal interpretation of both indidual and avg are present. If you need both the individual, and the avg, you now need to run ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', and once with cfg.keepindividual = 'no'; Best wishes, Jan-Mathijs On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: > Hello everyone, > > It seems that there has been a modification of > ft_timelockgrandaverage : now if you specify cfg.keepindividual = > 'yes', the grandaverage is computed but is not included in the > output of the function (see above). > > Why is that ? Many of my scripts rely on this option and I wanted to > know if there was a good reason for it. > > Thanks, > > Lucie > > New version of ft_timelockgrandaverage (downloaded yesterday), line > 159-176 > > %-------------------------------------------- > % % collect the results > %-------------------------------------------- > > grandavg = []; > grandavg.label = cfg.channel; % cell-array > %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete > grandavg.time = ResultsTime; % 1 x Nsamples > > %KEEP INDIVIDUAL MEANS? > if strcmp(cfg.keepindividual, 'yes') > grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples > grandavg.dimord = 'subj_chan_time'; > else > grandavg.avg = ResultGrandavg; % Nchan x Nsamples > grandavg.var = ResultVar; % Nchan x Nsamples > grandavg.dimord = 'chan_time'; > end > > Older version of ft_timelockgrandaverage (april 2010) > > %-------------------------------------------- > % % collect the results > %-------------------------------------------- > > %SWITCH CHANNEL TO LABEL? > grandavg.label = cfg.channel; % cell-array > grandavg.fsample = varargin{1}.fsample; > grandavg.avg = ResultGrandavg; % Nchan x Nsamples > grandavg.var = ResultVar; % Nchan x Nsamples > grandavg.time = ResultsTime; % 1 x Nsamples > > %KEEP INDIVIDUAL MEANS? > if strcmp(cfg.keepindividual, 'yes') > grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples > grandavg.dimord = 'subj_chan_time'; > else > grandavg.dimord = 'chan_time'; > end > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.wibral at web.de Thu Feb 10 12:33:05 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 10 Feb 2011 12:33:05 +0100 (CET) Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053>, <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> Message-ID: <2052784146.469173.1297337585004.JavaMail.fmail@mwmweb054> Hi Eric, sorry that I called this a "side-effect", I indeed find it most practical myself. I just didn't know this was the intended purpose. Michael -----Ursprüngliche Nachricht----- Von: "Eric Maris" Gesendet: Feb 10, 2011 11:16:05 AM An: "'Email discussion list for the FieldTrip project'" Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? >Hi Michael, > >> there is one additional side effect of specifying a LARGE minnbchan >> that actually leads to SMALLEr clusters in a certain sense. If I >> understand correctly, at any point in time&frequency the cluster has to >> have a spatial extension of minnbchan+1. So when you specify a large >> value the cluster may more easily be cut up into several smaller ones >> along the space&time dimension - which may or may not be desirable. > >Whether it is a side effect or not, depends on how you look at it. For me it is its intended effect. I implemented the minnbchan-parameter after discussions with PhD-students that applied the cluster-based permutation statistics on channel-time-frequency data and produced significant clusters with weird shapes. Often, these shapes contained narrow "bridges" connecting nearby blobs in channel-time-frequency space. By increasing minnbchan, these bridges were removed and only the blobs remained. > >Although I understand the requests of the PhD-students that I discussed with, I find the discussions about the minnbchan-parameter not very rewarding. In fact, it is looking for isolated blobs that one would like to interpret as separate physiological entities. This contrast with the nature of the EEG/MEG data, which has poor spatial resolution (due to volume conduction and common pick-up), often poor spectral resolution (due to the short time windows of our time-resolved spectral analysis), and often poor time resolution (due to latency jitter over trials). > >Best, > >Eric > > > > > >> >> Michael >> >> -----Ursprüngliche Nachricht----- >> Von: "David Groppe" >> Gesendet: Feb 8, 2011 7:18:59 PM >> An: "Email discussion list for the FieldTrip project" >> >> Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to >> spatial neighbors? >> >> >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris >> wrote: >> >> Dear David, >> >> >> >> >> >>> Thanks very much for the email Eric, but I'm confused as to why you >> >>> answered "No" to my second comment. From what I understand, if you >> >>> use a value of minnbchan that is greater than 0, then any >> >>> significant clusters will necessarily spread across multiple >> >>> electrodes. For example, if you set minnbchan to 1, then all >> >>> significant clusters will have to include at least two electrodes >> so >> >>> that each significant "voxel" has at least one neighbor at another >> >>> electrode. Thus, if your effect is truly at only a single >> >>> electrode, having a value of minnbchan greater than 0 will force >> you >> >>> to miss the effect or to think it occurs at more electrodes than it >> >>> really does. What part of my reasoning is incorrect? >> >> >> >> Your reasoning is correct and mine was incorrect. I should read >> >> better before I write. My apologies for this. >> > >> >Got it. Thanks very much for clarifying Eric. >> > >> >> >> >> I do have to qualify that with minnbchan=0 it may also happen that >> >> your significant cluster contains more than one electrode (the >> >> electrode with the true effect plus some surrounding ones that by >> >> accident exceed the threshold that is used to identify clusters). >> > >> >That makes perfect sense. Since our lab uses only a limited number of >> >electrodes (32), I wanted to make sure I understood the minimum number >> >of electrodes an effect needs to span to be detected. >> > once again, I very much appreciate your answers to my questions, >> > -David >> > >> >> Best, >> >> >> >> Eric >> >> >> >> >> >> >> >> >> >>> again, thanks very much for the help, >> >>> -David >> >>> >> >>> >> >>> > Best, >> >>> > >> >>> > Eric >> >>> > >> >>> > >> >>> > dr. Eric Maris >> >>> > Donders Institute for Brain, Cognition and Behavior Radboud >> >>> > University P.O. Box 9104 6500 HE Nijmegen The Netherlands >> >>> > T:+31 24 3612651 >> >>> > Mobile: 06 39584581 >> >>> > F:+31 24 3616066 >> >>> > mailto:e.maris at donders.ru.nl >> >>> > http://www.nphyscog.com/ >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> >> thanks for your help, >> >>> >> -David >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> David Groppe, Ph.D. >> >>> >> dgroppe at cogsci.ucsd.edu >> >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >>> >> _______________________________________________ >> >>> >> 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 >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> David Groppe, Ph.D. >> >>> Postdoctoral Researcher >> >>> Kutaslab >> >>> Dept. of Cognitive Science >> >>> University of California, San Diego >> >>> http://www.cogsci.ucsd.edu/~dgroppe/ >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> > >> > >> >-- >> >David Groppe, Ph.D. >> >Postdoctoral Researcher >> >Kutaslab >> >Dept. of Cognitive Science >> >University of California, San Diego >> >http://www.cogsci.ucsd.edu/~dgroppe/ >> > >> >_______________________________________________ >> >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From jan.schoffelen at donders.ru.nl Thu Feb 10 13:15:57 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 10 Feb 2011 13:15:57 +0100 Subject: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage cfg.keepindividual References: Message-ID: Dear Lucie, Thank you very much for your feedback. I take the liberty to anyhow post this to the discussion list, so that other people may take notice / join in the discussion / etc. > Thanks a lot for this quick response : I understand the logic behind > this. It's true that I noticed some inconsistencies due to the > interpretation of the field dimord which can't be well defined if > you have both individual and average data in your structure. OK > However, I think many people were happy with this option as it was. > It's quite handy to keep both the average and individual data > because you can compute statistics and at the same time you don't > have to redo the average every time. I think a lot of scripts rely > on that at least in our lab. The historical purpose for supporting cfg.keepindividual = 'yes', was in order to get a representation of all single subjects' data in a single data matrix: data.individual. Nowadays, ft_timelockstatistics supports multiple data structures in the input, i.e. ft_timelockstatistics(cfg, subj1, subj2 subj3, etc) so I think the call to ft_timelockgrandaverage could even be bypassed. The FieldTrip development team is very keen on providing backward compatibility support. While in general this is feasible for the functions which are in FieldTrip, it is very difficult to realize for lab-specific scripts. In this particular example I think that clarity of the data representation should prevail over backward compatibility issues, particularly because in this case there's an easy workaround: just call ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data representation is a prerequisite for further developing the software, and keeping the historical 'oddity' will only hamper code development. > Furthermore, it's a bit strange to have a function called > ft_timelockgrandaverage which doesn't compute any grandaverage in > some cases ! I agree, yet see my point above. Some people may just like to have the data represented in a single matrix. > > I would suggest to keep the function as it is but add more options > (such as cfg.dimord = 'avg' or 'individual') to make the > experimenter aware of this issue and to solve further computation > problem. I hope I could convince you that our philosophy makes sense and that you and your lab-mates are willing to make the effort of adjusting the scripts a bit for future analyses. If very problematic, I would advice for the current analyses to rely on an old version of ft_timelockgrandaverage. Best wishes, Jan-Mathijs > Thank you again, > > Lucie > > PS : I've sent this email only to you as this is just a suggestion > which might not be relevant for all users. > > > 2011/2/10 jan-mathijs schoffelen > Dear Lucie, > > Yes, indeed this has recently been changed. The logic behind it is > the following: > > One either typically wants to keep the individuals, OR the average. > > If in your case you need the average, you have to specify > cfg.keepindividual = 'no'; > > Keeping both the average and the individual leads to an inconsistent > definition of the data structure. > The field 'dimord' does not allow for an unequivocal interpretation > of both indidual and avg are present. > > If you need both the individual, and the avg, you now need to run > ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', > and once with cfg.keepindividual = 'no'; > > Best wishes, > > Jan-Mathijs > > > On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: > >> Hello everyone, >> >> It seems that there has been a modification of >> ft_timelockgrandaverage : now if you specify cfg.keepindividual = >> 'yes', the grandaverage is computed but is not included in the >> output of the function (see above). >> >> Why is that ? Many of my scripts rely on this option and I wanted >> to know if there was a good reason for it. >> >> Thanks, >> >> Lucie >> >> New version of ft_timelockgrandaverage (downloaded yesterday), line >> 159-176 >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> grandavg = []; >> grandavg.label = cfg.channel; % cell-array >> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.dimord = 'chan_time'; >> end >> >> Older version of ft_timelockgrandaverage (april 2010) >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> %SWITCH CHANNEL TO LABEL? >> grandavg.label = cfg.channel; % cell-array >> grandavg.fsample = varargin{1}.fsample; >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.dimord = 'chan_time'; >> end >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> Bât 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucie.charles.ens at googlemail.com Thu Feb 10 14:03:30 2011 From: lucie.charles.ens at googlemail.com (Lucie Charles) Date: Thu, 10 Feb 2011 14:03:30 +0100 Subject: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage cfg.keepindividual In-Reply-To: References: Message-ID: Thank you very much for this very detailed response. I didn't know (or forgot) that ft_timelockstatistics could take several data sets as an input (I thought we always needed the big data matrix with all the subjects). That makes much more sense to remove the option in this context. Thanks again, Lucie 2011/2/10 jan-mathijs schoffelen > Dear Lucie, > > Thank you very much for your feedback. I take the liberty to anyhow post > this to the discussion list, so that other people may take notice / join in > the discussion / etc. > > Thanks a lot for this quick response : I understand the logic behind this. > It's true that I noticed some inconsistencies due to the interpretation of > the field dimord which can't be well defined if you have both individual and > average data in your structure. > > > OK > > However, I think many people were happy with this option as it was. It's > quite handy to keep both the average and individual data because you can > compute statistics and at the same time you don't have to redo the average > every time. I think a lot of scripts rely on that at least in our lab. > > > The historical purpose for supporting cfg.keepindividual = 'yes', was in > order to get a representation of all single subjects' data in a single data > matrix: data.individual. Nowadays, ft_timelockstatistics supports multiple > data structures in the input, i.e. ft_timelockstatistics(cfg, subj1, subj2 > subj3, etc) so I think the call to ft_timelockgrandaverage could even be > bypassed. > The FieldTrip development team is very keen on providing backward > compatibility support. While in general this is feasible for the functions > which are in FieldTrip, it is very difficult to realize for lab-specific > scripts. In this particular example I think that clarity of the data > representation should prevail over backward compatibility issues, > particularly because in this case there's an easy workaround: just call > ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data > representation is a prerequisite for further developing the software, and > keeping the historical 'oddity' will only hamper code development. > > Furthermore, it's a bit strange to have a function called > ft_timelockgrandaverage which doesn't compute any grandaverage in some cases > ! > > > I agree, yet see my point above. Some people may just like to have the data > represented in a single matrix. > > > I would suggest to keep the function as it is but add more options (such as > cfg.dimord = 'avg' or 'individual') to make the experimenter aware of this > issue and to solve further computation problem. > > > I hope I could convince you that our philosophy makes sense and that you > and your lab-mates are willing to make the effort of adjusting the scripts a > bit for future analyses. If very problematic, I would advice for the current > analyses to rely on an old version of ft_timelockgrandaverage. > > Best wishes, > > Jan-Mathijs > > > > Thank you again, > > Lucie > > PS : I've sent this email only to you as this is just a suggestion which > might not be relevant for all users. > > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Yes, indeed this has recently been changed. The logic behind it is the >> following: >> >> One either typically wants to keep the individuals, OR the average. >> >> If in your case you need the average, you have to specify >> cfg.keepindividual = 'no'; >> >> Keeping both the average and the individual leads to an inconsistent >> definition of the data structure. >> The field 'dimord' does not allow for an unequivocal interpretation of >> both indidual and avg are present. >> >> If you need both the individual, and the avg, you now need to run >> ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', and once >> with cfg.keepindividual = 'no'; >> >> Best wishes, >> >> Jan-Mathijs >> >> >> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >> >> Hello everyone, >> >> It seems that there has been a modification of ft_timelockgrandaverage : >> now if you specify cfg.keepindividual = 'yes', the grandaverage is computed >> but is not included in the output of the function (see above). >> >> Why is that ? Many of my scripts rely on this option and I wanted to know >> if there was a good reason for it. >> >> Thanks, >> >> Lucie >> >> New version of ft_timelockgrandaverage (downloaded yesterday), line >> 159-176 >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> grandavg = []; >> grandavg.label = cfg.channel; % cell-array >> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time';* >> else >> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.dimord = 'chan_time'; >> end >> >> Older version of ft_timelockgrandaverage (april 2010) >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> %SWITCH CHANNEL TO LABEL? >> grandavg.label = cfg.channel; % cell-array >> grandavg.fsample = varargin{1}.fsample; >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.dimord = 'chan_time'; >> end >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> Bât 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Lucie CHARLES INSERM-CEA Cognitive Neuroimaging unit CEA/SAC/DSV/DRM/NeuroSpin Bât 145, Point Courrier 156 F-91191 Gif/Yvette, FRANCE Tel : +33 1 69 08 99 74 Fax : +33 1 69 08 79 73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gregor.Volberg at psychologie.uni-regensburg.de Fri Feb 11 09:46:51 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Fri, 11 Feb 2011 09:46:51 +0100 Subject: [FieldTrip] WPLI weighted phase-locking index: available in fieldtrip? Message-ID: <4D55058B020000570000882D@gwsmtp1.uni-regensburg.de> Dear fieldtrip developers, I was just reading the pre-print of an upcoming article in Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved index of phase-synchronization...". As I understand, the proposed phase-locking index WPLI is not complicated by volume conduction, and an unbiased version of the WPLI can be computed that is not affected by trial number. This would be exactely what I need for the analysis of data from a spatial cueing paradigm. In the last paragraph, it is announced that the WPLI is made available in the fieldtrip toolbox. However, I did not yet find it (i was searching for it as an option in ft_connectivityanalysis, last Friday's fieldtrip version). May I ask whether it is planned to include WPLI / debiased WPLI into that function? Or was it perhaps intended to be computed by hand from the cross-spectrum. Thanks a lot, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From gauthierb.ens at gmail.com Fri Feb 11 10:46:13 2011 From: gauthierb.ens at gmail.com (Baptiste Gauthier) Date: Fri, 11 Feb 2011 10:46:13 +0100 Subject: [FieldTrip] bug in ft_componentanalysis Message-ID: Dear Fieldtrip users, I noticed a little error in ft_componentanalysis since your latest update (2011/02/09) : While using the function, I got this error message : "??? Error using ==> toc You must call TIC without an output argument before calling TOC without an input argument. Error in ==> ft_componentanalysis at 465 fprintf('total time in componentanalysis %.1f seconds\n', stopwatch(toc)); Error in ==> temprod_NEW_runicaonspectra at 37 comp = ft_componentanalysis(cfg,data);" It seems there's here a bad use of function toc.m It should be : "fprintf('total time in componentanalysis %.1f seconds\n', toc(stopwatch));" I tried it and it worked fine. Please let me know if I'm wrong. Cheers, Baptiste gauthier -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.micheli at fcdonders.ru.nl Fri Feb 11 11:43:39 2011 From: c.micheli at fcdonders.ru.nl (Micheli, C.) Date: Fri, 11 Feb 2011 11:43:39 +0100 (CET) Subject: [FieldTrip] bug in ft_componentanalysis In-Reply-To: Message-ID: <1133664698.83738.1297421019941.JavaMail.root@draco.zimbra.ru.nl> Hi Baptiste You are totally right. The bug has been corrected and you can find the new version by downloading the latest FieldTrip . Cheers, Cristiano ----- "Baptiste Gauthier" schreef: > Van: "Baptiste Gauthier" > Aan: fieldtrip at donders.ru.nl > Verzonden: Vrijdag 11 februari 2011 10:46:13 > Onderwerp: [FieldTrip] bug in ft_componentanalysis > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest update (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC without an input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch(toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds\n', toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > _______________________________________________ > 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 E.vandenBroeke at anes.umcn.nl Fri Feb 11 11:52:57 2011 From: E.vandenBroeke at anes.umcn.nl (E.vandenBroeke at anes.umcn.nl) Date: Fri, 11 Feb 2011 11:52:57 +0100 Subject: [FieldTrip] One or two sided testing? Message-ID: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> Dear dr. Maris, Bovenkant formulier Onderkant formulier I notice that there are many different views among scientists about the use of one or two sided tests. Most people say that you always have to test 2-sided. But is there a rationale for this? When is it appropriate and allowed to test one-sided? Perhaps you can shed light on this topic, by giving your point of view or perhaps you can recommend literature that provides insight on this debate? Thank you, Best Emanuel Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629. The Radboud University Nijmegen Medical Centre is listed in the Commercial Register of the Chamber of Commerce under file number 41055629. -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Fri Feb 11 15:01:01 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Fri, 11 Feb 2011 15:01:01 +0100 Subject: [FieldTrip] One or two sided testing? In-Reply-To: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> References: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> Message-ID: <006301cbc9f4$20d75fe0$62861fa0$@maris@donders.ru.nl> Dear Emanuel, I notice that there are many different views among scientists about the use of one or two sided tests. Most people say that you always have to test 2-sided. But is there a rationale for this? When is it appropriate and allowed to test one-sided? Perhaps you can shed light on this topic, by giving your point of view or perhaps you can recommend literature that provides insight on this debate? If you have prior information that an effect will occur only on one side, or if you are only interested in an effect at one side, then you should test one-sided. Otherwise, you should test two-sided. Best, Eric Thank you, Best Emanuel Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629. The Radboud University Nijmegen Medical Centre is listed in the Commercial Register of the Chamber of Commerce under file number 41055629. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gramfort at nmr.mgh.harvard.edu Fri Feb 11 17:27:50 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Fri, 11 Feb 2011 11:27:50 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> Message-ID: Hi, the pb should be fixed now on: https://github.com/mne-tools/mne-matlab scott confirmed it works for his needs. FYI the files are always closed now and reopened when necessary. Alex On Wed, Feb 9, 2011 at 4:33 PM, Laurence Hunt wrote: > Thanks Alex - I guess it might also be useful to add to the mne code instead, as long as it doesn't cause any problems elsewhere for other users...? Thinking about it, I reckon it would work if you used the same solution you suggested previously on your website, but just added > > data.pos = ftell(data.fid); %before running fclose in fiff_setup_read_raw > > and > > fseek(raw.fid,raw.pos); %after re-opening the file in fiff_read_raw_segment > > (...followed by an fclose of raw.fid at the end of fiff_read_raw_segment, of course). > > If you did this, it would save us making any changes in fieldtrip at all :) > > Laurence > > =========================================== > Laurence Hunt, DPhil Student >  Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > > On 9 Feb 2011, at 21:17, Alexandre Gramfort wrote: > >> again if something needs to be changed in the mne matlab code >> I'd be happy to help. >> >> Alex >> >> On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: >>> I think it should be possible to do it this way - when I tested it, it seemed to work OK. >>> >>> On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: >>> >>>> If, however, it is sufficient to store in the header a >>>> single number which can then be used to find the data onset and from >>>> there to find where to start reading (so perhaps not an fid but just >>>> the data offset in bytes to do fseek), that'd be a perfectly good >>>> solution and fast as well. But I don't know enough about  fif format >>>> to say if it's possible. >>> >>> =========================================== >>> Laurence Hunt, DPhil Student >>>  Centre for Functional MRI of the Brain (FMRIB), >>> University of Oxford >>> lhunt at fmrib.ox.ac.uk >>> Phone: (+44)1865-(2)22738 >>> =========================================== >>> _______________________________________________ >>> 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 > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in error > but does not contain patient information, please contact the sender and properly > dispose of the e-mail. > > From andreas.wilmer at uni-muenster.de Fri Feb 11 17:57:36 2011 From: andreas.wilmer at uni-muenster.de (Andreas Wilmer) Date: Fri, 11 Feb 2011 17:57:36 +0100 Subject: [FieldTrip] trial-based time-series via lcmv beamforming? Message-ID: dear fieldtrip-users, actually my first active post in the fieldtrip newsgroup. first i'd like to thank the community and especially the developers of fieldtrip for their great support&help! i am interested in a trial-based(!) time-domain data-set in the source space of MEG data for further connectivity analysis. i decided to use a beamformer (lcmv) to recover the neuronal activity by using snythetic data-sets (for testing and verification). the synthetic data- set consists of 3 correlated sources with up to 300 trials and a length of 720 datapoints (=1.2s at 600Hz) and many trials of uncorrelated noisy sources. i implemented the dipole simulation in the following way: 1) i used customized data with time dependent (time-delayed) phase correlations as source waveforms and added randomly located uncorrelated dipoles as disturbances and spontaneous brain processes. next, i simulated the data in sensor-space and did an lcmv beamforming -> works fine (a priori known connectivity can be recovered). 2) in the next step i repeated the simulation and added 10% rms as additive (delta-correlated) measurement noise to the data in the sensor-space to model thermal noise. -> in this case the beamformer reconstruction fails totally... 3) i averaged the data in sensor-space to get rid of the thermal noise and used the cov to recover every single trial, but in this case the beamformer cannot deal with brain-noise... -> this didn't work either.. MY QUESTION IS: is this a conceptual problem of beamforming, that one cannot recover a trial-based time-series or did i commit a crude error in reasoning/programming? do you think a bootstrapping for calculating the cov might make sense, i.e. i could calculate the cov for each trial by averaging over just a few trials (eg 10 randomly chosen trials) to reduce the uncorrelated noise in sensor space without loosing all the information to suppress the brain-noise? which other inverse methods can recover source activity in time-domain on trial level? eg MNE seems only to work on average over trials? so many questions.. thank you in advance for your help! with best wishes, andreas __________________________________ Dipl.-Phys. Andreas Wilmer Institut für Allgemeine Psychologie Westfälische Wilhelms-Universität Münster AE Prof. Dr. Markus Lappe Fliednerstraße 21 D 48149 Münster fon: +49 (251) 83 34175 email: andreas.wilmer at uni-muenster.de my code on beamforming two further remarks: a) i didn't apply a normalization of the virtual channels because i am interested in phase measures - normalizing the amplitudes won't have any effect on the results b) narrow band filtering didn't work with my (broad band) data %----------------------------------------------------------------- %estimating filter/cov cfg = []; cfg.channel = {'MEG'}; cfg.keeptrials = 'yes'; cfg.bpfrq = [1 150]; cfg.covariance = 'yes'; %trial/stimulus window cfg.covariancewindow = [0 1.2]; %complete data dataCov = ft_timelockanalysis(cfg,dataSensor); %----------------------------------------------------------------- %beamforming cfg = []; cfg.method = 'lcmv'; cfg.lcmv.fixedori = 'yes'; cfg.vol = dataHead; cfg.grid.pos = gridposition; cfg.lambda = '5%'; cfg.projectnoise = 'yes'; cfg.keepfilter = 'yes'; cfg.keeptrials = 'yes'; [dataVc] = ft_sourceanalysis(cfg,dataCov); %--------------------------------------------------------------- %reconstructing source data trialN = size(dataSensor.trial,2); [sensN tN] = size(dataSensor.trial{1}); srcN = length(dataVc.inside); for i=1:srcN, m = dataVc.inside(i); if ~isempty(dataVc.avg.filter{m}), fprintf('beamforming source %d/%d\n',i,srcN); %beamforming for j = 1:trialN, dataVc.trial(j).mom{m} =... dataVc.avg.filter{m}*dataSensor.trial{j}; end end end -------------- next part -------------- An HTML attachment was scrubbed... URL: From ting.ac at gmail.com Fri Feb 11 22:19:33 2011 From: ting.ac at gmail.com (Allison Connolly) Date: Fri, 11 Feb 2011 15:19:33 -0600 Subject: [FieldTrip] problem aligning MRI with gradiometer Message-ID: Hello, I am trying to perform beamforming on some MEG data (148 channels). I have the dicom files for the MRI, and I have converted them to .img and .hdr files using Curry. I am importing them into fieldtrip via mri=ft_read_mri('MRI.img'). Then I manually declaring the fiducials with cfg.method = 'interactive'; mrialign = ft_volumerealign(cfg, mri); Then segmenting with cfg = []; cfg.write = 'no'; [segment] = ft_volumesegment(cfg, mri); Then creating the head model with cfg = []; cfg.smooth = 'no'; vol = ft_prepare_singleshell(cfg, segment); Then creating the grid with cfg = []; cfg.grad = freq.grad; cfg.vol = vol; cfg.reducerank = 'no'; cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol [grid] = ft_prepare_leadfield(cfg); I am importing my MEG data with cfg = []; % empty configuration cfg.dataset = 'C:/MEG Study/Subjectd001/d001/Billy_180s/06@ -09 at -10@_19_41/4/c,rfhp0.1Hz'; cfg.trialfun = 'trialfun_general'; cfg.trialdef.triallength = 2; % duration in seconds cfg.trialdef.ntrials = inf; % number of trials, inf results in as many as possible cfg = ft_definetrial(cfg); % preprocess the data cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; %read all MEG channels except those with '-' cfg.lpfilter = 'yes'; cfg.lpfreq = 200; cfg.bsfilter = 'yes'; %60 Hz noise cfg.bsfreq = [58 62]; data = ft_preprocessing(cfg); In the end, when I go to plot them all on the same graph, the head model seems to be 100 times larger than the gradiometer sensors (they appear as a small ball in the middle of the head). I've tried adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't help the downstream frequency, leadfield, and source analysis. Can someone tell me how to ensure the gradiometer and mri/grid are on the same scale so I can be sure I have the right model for my beamforming? Thank you, -Allison -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.frei at psy.gla.ac.uk Fri Feb 11 23:02:18 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 11 Feb 2011 22:02:18 +0000 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: References: Message-ID: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Hi Alison, how do you change the units? I convert them using: data.grad=ft_convert_units(data.grad,'cm') Maybe this helps. Luisa On 11 Feb 2011, at 21:19, Allison Connolly wrote: > Hello, > > I am trying to perform beamforming on some MEG data (148 channels). > I have the dicom files for the MRI, and I have converted them > to .img and .hdr files using Curry. > I am importing them into fieldtrip via > mri=ft_read_mri('MRI.img'). > > Then I manually declaring the fiducials with > cfg.method = 'interactive'; > mrialign = ft_volumerealign(cfg, mri); > > Then segmenting with > cfg = []; > cfg.write = 'no'; > [segment] = ft_volumesegment(cfg, mri); > > Then creating the head model with > cfg = []; > cfg.smooth = 'no'; > vol = ft_prepare_singleshell(cfg, segment); > > Then creating the grid with > cfg = []; > cfg.grad = freq.grad; > cfg.vol = vol; > cfg.reducerank = 'no'; > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; > cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol > cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol > cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol > [grid] = ft_prepare_leadfield(cfg); > > I am importing my MEG data with > cfg = []; % empty configuration > cfg.dataset = 'C:/MEG Study/Subjectd001/d001/ > Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.triallength = 2; % duration in seconds > cfg.trialdef.ntrials = inf; % number of trials, inf results > in as many as possible > cfg = ft_definetrial(cfg); > > % preprocess the data > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','- > E4'}; %read all MEG channels except those with '-' > cfg.lpfilter = 'yes'; > cfg.lpfreq = 200; > cfg.bsfilter = 'yes'; %60 Hz noise > cfg.bsfreq = [58 62]; > > data = ft_preprocessing(cfg); > > In the end, when I go to plot them all on the same graph, the head > model seems to be 100 times larger than the gradiometer sensors > (they appear as a small ball in the middle of the head). I've tried > adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't > help the downstream frequency, leadfield, and source analysis. > > Can someone tell me how to ensure the gradiometer and mri/grid are > on the same scale so I can be sure I have the right model for my > beamforming? > > Thank you, > -Allison > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From ting.ac at gmail.com Fri Feb 11 23:25:24 2011 From: ting.ac at gmail.com (Allison Connolly) Date: Fri, 11 Feb 2011 16:25:24 -0600 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> References: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Message-ID: Thanks that seemed to help the scaling issue. However, my beamforming is still not producing results. There is a huge bias towards the center of the head, even though I accounted for the neural activity index. It seems like the beamforming is just projecting everything inwards. I'm not sure where to go from here. Do you have any suggestions on different configuration settings I could try for the beamforming? -Allison On Fri, Feb 11, 2011 at 4:02 PM, Luisa Frei wrote: > Hi Alison, > how do you change the units? I convert them using: > > data.grad=ft_convert_units(data.grad,'cm') > > Maybe this helps. > > Luisa > > > On 11 Feb 2011, at 21:19, Allison Connolly wrote: > > Hello, >> >> I am trying to perform beamforming on some MEG data (148 channels). I have >> the dicom files for the MRI, and I have converted them to .img and .hdr >> files using Curry. >> I am importing them into fieldtrip via >> mri=ft_read_mri('MRI.img'). >> >> Then I manually declaring the fiducials with >> cfg.method = 'interactive'; >> mrialign = ft_volumerealign(cfg, mri); >> >> Then segmenting with >> cfg = []; >> cfg.write = 'no'; >> [segment] = ft_volumesegment(cfg, mri); >> >> Then creating the head model with >> cfg = []; >> cfg.smooth = 'no'; >> vol = ft_prepare_singleshell(cfg, segment); >> >> Then creating the grid with >> cfg = []; >> cfg.grad = freq.grad; >> cfg.vol = vol; >> cfg.reducerank = 'no'; >> cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... >> '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... >> '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; >> cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol >> cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol >> cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol >> [grid] = ft_prepare_leadfield(cfg); >> >> I am importing my MEG data with >> cfg = []; % empty configuration >> cfg.dataset = 'C:/MEG >> Study/Subjectd001/d001/Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; >> cfg.trialfun = 'trialfun_general'; >> cfg.trialdef.triallength = 2; % duration in seconds >> cfg.trialdef.ntrials = inf; % number of trials, inf results in as >> many as possible >> cfg = ft_definetrial(cfg); >> >> % preprocess the data >> cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... >> '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... >> '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; %read >> all MEG channels except those with '-' >> cfg.lpfilter = 'yes'; >> cfg.lpfreq = 200; >> cfg.bsfilter = 'yes'; %60 Hz noise >> cfg.bsfreq = [58 62]; >> >> data = ft_preprocessing(cfg); >> >> In the end, when I go to plot them all on the same graph, the head model >> seems to be 100 times larger than the gradiometer sensors (they appear as a >> small ball in the middle of the head). I've tried adjusting the grad.unit >> parameter from 'm' to 'cm', but it doesn't help the downstream frequency, >> leadfield, and source analysis. >> >> Can someone tell me how to ensure the gradiometer and mri/grid are on the >> same scale so I can be sure I have the right model for my beamforming? >> >> Thank you, >> -Allison >> _______________________________________________ >> 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 l.frei at psy.gla.ac.uk Sat Feb 12 00:05:15 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 11 Feb 2011 23:05:15 +0000 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: References: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Message-ID: I'm not an expert on beamforming myself. But how clear your results are depends on the preprocessing as well. If your sources are very low in the head, you could have muscle or heartbeat artifacts. I did an ICA to remove the heartbeat component. Sorry I can't give you any more help, someone else can probably help you more. Luisa On 11 Feb 2011, at 22:25, Allison Connolly wrote: > Thanks that seemed to help the scaling issue. However, my > beamforming is still not producing results. There is a huge bias > towards the center of the head, even though I accounted for the > neural activity index. It seems like the beamforming is just > projecting everything inwards. I'm not sure where to go from here. > Do you have any suggestions on different configuration settings I > could try for the beamforming? > > -Allison > > On Fri, Feb 11, 2011 at 4:02 PM, Luisa Frei > wrote: > Hi Alison, > how do you change the units? I convert them using: > > data.grad=ft_convert_units(data.grad,'cm') > > Maybe this helps. > > Luisa > > > On 11 Feb 2011, at 21:19, Allison Connolly wrote: > > Hello, > > I am trying to perform beamforming on some MEG data (148 channels). > I have the dicom files for the MRI, and I have converted them > to .img and .hdr files using Curry. > I am importing them into fieldtrip via > mri=ft_read_mri('MRI.img'). > > Then I manually declaring the fiducials with > cfg.method = 'interactive'; > mrialign = ft_volumerealign(cfg, mri); > > Then segmenting with > cfg = []; > cfg.write = 'no'; > [segment] = ft_volumesegment(cfg, mri); > > Then creating the head model with > cfg = []; > cfg.smooth = 'no'; > vol = ft_prepare_singleshell(cfg, segment); > > Then creating the grid with > cfg = []; > cfg.grad = freq.grad; > cfg.vol = vol; > cfg.reducerank = 'no'; > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; > cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol > cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol > cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol > [grid] = ft_prepare_leadfield(cfg); > > I am importing my MEG data with > cfg = []; % empty configuration > cfg.dataset = 'C:/MEG Study/Subjectd001/d001/ > Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.triallength = 2; % duration in seconds > cfg.trialdef.ntrials = inf; % number of trials, inf results > in as many as possible > cfg = ft_definetrial(cfg); > > % preprocess the data > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','- > E4'}; %read all MEG channels except those with '-' > cfg.lpfilter = 'yes'; > cfg.lpfreq = 200; > cfg.bsfilter = 'yes'; %60 Hz noise > cfg.bsfreq = [58 62]; > > data = ft_preprocessing(cfg); > > In the end, when I go to plot them all on the same graph, the head > model seems to be 100 times larger than the gradiometer sensors > (they appear as a small ball in the middle of the head). I've tried > adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't > help the downstream frequency, leadfield, and source analysis. > > Can someone tell me how to ensure the gradiometer and mri/grid are > on the same scale so I can be sure I have the right model for my > beamforming? > > Thank you, > -Allison > _______________________________________________ > 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 jm.horschig at donders.ru.nl Mon Feb 14 16:18:36 2011 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Mon, 14 Feb 2011 16:18:36 +0100 Subject: [FieldTrip] Single Precision in FieldTrip (2011) Message-ID: <4D5947CC.3010608@donders.ru.nl> Dear all, This mail can be considered as a follow-up from an issue raised back in 2006 - just a little bit more recent (btw, there maybe should a more user-friendly interface to search in the FT mailing archive, it took some time to check if this question has been brought up before). Today, I was thinking about ways to reduce the memory use of FieldTrip/Matlab especially when handling large amount of data - other ways than using machines with huge memory capacities. In the old mailing list, I found a mail conversation started by Ali M. about single precision in 2006. Matlab, and FieldTrip, has advanced quite a lot since then, which resulted in removing at least that one particular Matlab-bug on my machine ;) However, in the past I have found that computations using single precision still yields problems such as wrong results or also incompatibilty of certain functions/operations. I wonder how severe these problems are with current Matlab/FieldTrip versions. Does anyone have experience with single precision computations using FieldTrip? Is it valid or even advisable to use single precision calculations? FYI, my machine runs Win7 64-bit and Matlab 7.9.0.529 (R2009b) Kind regards, Jörn -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen 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/fcdonders Visiting address: Trigon, room 2.30 Kapitelweg 29 NL-6525 EN Nijmegen The Netherlands From m.k.van.vugt at rug.nl Tue Feb 15 12:33:46 2011 From: m.k.van.vugt at rug.nl (Marieke van Vugt) Date: Tue, 15 Feb 2011 12:33:46 +0100 Subject: [FieldTrip] fully-funded PhD position in cognitive modeling group Rijksuniversiteit Groningen Message-ID: <05BDAE2A-1847-4DF4-8EE2-35155234794F@rug.nl> PhD position Cognitive Modeling group (1,0 fte) (211047) Organisation We invite applications for a four-year PhD student position available in the Cognitive Modeling group, in the laboratory of Marieke van Vugt (http://www.ai.rug.nl/~mkvanvugt/index_lab.html). The Cognitive Modeling group forms part of the ALICE research institute within the Department of Artificial Intelligence. It has a world-class reputation in cognitive modeling, largely based on the ACT-R architecture. The laboratory of Marieke van Vugt focuses on the neural correlates of decision making based on remembered information, combining modeling, behavioral experiments and EEG/fMRI. Job description The PhD project focuses on relating computational models of decision making based on remembered information to EEG and fMRI data. The drift diffusion model of memory and decision making makes explicit predictions of the dynamics of evidence accumulation, and these predictions will be examined in neural data. The project will bridge the domains of perceptual decision making and recognition memory. Specific focus will be placed on how different brain areas interact to implement this evidence accumulation process and adjust performance on a trial-to-trial basis. The participant will engage in advanced data analysis of existing EEG data sets, and collect new EEG and fMRI data. Qualifications A successful candidate has a Master's degree in Cognitive Neuroscience, Cognitive Science, Experimental Psychology, Artificial Intelligence or a related field, and has programming skills in Matlab, C, or Python. Experience in running EEG and/or fMRI experiments, or in modeling of cognition, is an advantage. Conditions of employment The University of Groningen offers a salary of 2,042 gross per month in the first year up to a maximum of 2,612 gross per month in the final year. The appointment is for a period of four years, which should be finished with a PhD examination. The full time appointment is temporary for 1.5 years with the perspective of prolongation for another 2.5 years. After the first year, there will be an evaluation of the feasibility of successful completion of the PhD thesis within the next three years. A training programme within the Graduate School of Science is part of the agreement. You and your supervisor will make up a plan for additional education and supervising that is specific to your needs. How to apply: Send a cover letter (with professional goals and a statement of interest), a curriculum vitae and two letters of recommendation (PDF format) to the job application portal (http://www.tangram-tis.nl/10378/Kandidaten/Inschrijven/00347-0000004562) before April 1st, 2011, although applications received after the deadline may be considered. Starting date: as soon as possible. Information For information you can contact: Dr Marieke van Vugt, m.k.van.vugt at rug.nl ALICE ---------------------------------------------------------------------------- Marieke van Vugt, PhD Assistant Professor, Cognitive Modeling Group Bernoulliborg, room 326 Nijenborgh 9 9747 AG Groningen The Netherlands phone: +31-6-51954984 (cell) +31-50-363-9487 (office) http://www.ai.rug.nl/~mkvanvugt m.k.van.vugt at rug.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.carmeli at gmail.com Tue Feb 15 16:32:39 2011 From: cristian.carmeli at gmail.com (Cristian Carmeli) Date: Tue, 15 Feb 2011 16:32:39 +0100 Subject: [FieldTrip] problem with ft_read_mri Message-ID: Dear FieldTrip users I would like to create a mesh from the MNI brain and when I start running the following command >> mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); I get this error message ??? Error using ==> spm_platform>init_platform at 173 MACI64 not supported architecture for SPM Do you know how to fix that? Or is there any mri structure already available to download somewhere? For complete information, I am using Matlab 7.11 on MacOs 10.6.6 thank you for your help best Cristian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanweisz at mac.com Tue Feb 15 16:42:56 2011 From: nathanweisz at mac.com (Nathan Weisz) Date: Tue, 15 Feb 2011 16:42:56 +0100 Subject: [FieldTrip] problem with ft_read_mri In-Reply-To: References: Message-ID: under template/ you'll find a single_subj_T1.mat. looks like what you are looking for (already segmented). good luck, n On 15.02.2011, at 16:32, Cristian Carmeli wrote: > Dear FieldTrip users > > I would like to create a mesh from the MNI brain and when I start running the following command > > >> mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); > > I get this error message > ??? Error using ==> spm_platform>init_platform at 173 > MACI64 not supported architecture for SPM > > Do you know how to fix that? Or is there any mri structure already available to download somewhere? > For complete information, I am using Matlab 7.11 on MacOs 10.6.6 > > thank you for your help > > best > Cristian > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From Gregor.Volberg at psychologie.uni-regensburg.de Tue Feb 15 17:16:57 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Tue, 15 Feb 2011 17:16:57 +0100 Subject: [FieldTrip] Artifacts on plotting grand-averaged BEMs: Normalization issue? Message-ID: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> Dear list members, I encountered a problem when plotting the results of a beamformer analysis with individual BEM headmodels. For each subject, I did an ft_sourceanalysis (DICS) and then interpolated the individual volume on the individual anatomy with ft_sourceinterpolate. The result was normalised onto the SPM8 template brain with ft_volumenormalise; then I computed the grand average with ft_sourcegrandaverage. When I plot the grand average (with cfg.funparameter = 'pow'), I see nice results at expected brain regions, but also artifacts around the outline of the volume - see my attached Figure "source_power.png". It appears as if normalization was imperfect so that a border remains, possibly showing idiosyncratic activations from single subjects. The border does not show up if, with the same data, I do ft_sourcestatistics and then plot the results with cfg.funparameter = 'stat' (see attached "source_stat.png"). One might expect this if the voxels showed activation of only one subject so that a t-test would return NANs. I then had a look into the "*.inside" fields of the normalized volumes and was surprised to see that number of voxels inside the brain was different for each subject (ranging between 23 and 27 % roughly). Should that not be the same number of voxels for each subject after normalization? I am now unsure whether the border is a known behavior when plottig the grand average over individual heads,or whether I made an error with normalization. I would be very happy if any someone had an advice for me. Many thanks and best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_power.png Type: image/png Size: 38081 bytes Desc: Portable Network Graphics Format URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_stat.png Type: image/png Size: 31701 bytes Desc: Portable Network Graphics Format URL: From datashare at sciencedb.net Tue Feb 15 23:01:48 2011 From: datashare at sciencedb.net (datashare at sciencedb.net) Date: Tue, 15 Feb 2011 23:01:48 +0100 (CET) Subject: [FieldTrip] Announcement : Neuroscience positions database In-Reply-To: References: Message-ID: Dear Fieldtrip users, * Apologies if you receive this multiple times * We would like to inform you about new forum for neuroscience job announcements: http://sciencedb.net/groups/neuroscience-positions-announcements/forum/ We hope you can use this forum to post announcements from post-doc positions and faculty positions to PhD. projects and internship projects. If you only want to follow the announcement; sign up for a free newswletter: http://feedburner.google.com/fb/a/mailverify?uri=ScienceDbNeurosciencePositions-Announcements&loc=en_US Kind regards, Sciencedb.net PS. Follow us on twitter http://twitter.com/sciencedb or sign-up for our newsletter: http://feedburner.google.com/fb/a/mailverify?uri=ScienceDb --- ScienceDB.net is a non-profit portal for the scientific community. Our service is sponsored by ads and donations. If you have any suggestions or comments, please mail us at sciencedb at sciencedb.net. From Gregor.Volberg at psychologie.uni-regensburg.de Wed Feb 16 11:52:43 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Wed, 16 Feb 2011 11:52:43 +0100 Subject: [FieldTrip] UPDATE: Artifacts on plotting grand-averaged BEMs: Normalization issue? In-Reply-To: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> References: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> Message-ID: <4D5BBA8B02000057000088F0@gwsmtp1.uni-regensburg.de> Dear list members, I think I fixed the problem described in my last mail. I manually averaged the avg.pow fields of the single subjects and put the average on the corresponding field of the grandaverage-structure. This worked fine, without artifactual borders at the outline of the brain compartement. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> "Gregor Volberg" 2/15/2011 5:16 PM >>> Dear list members, I encountered a problem when plotting the results of a beamformer analysis with individual BEM headmodels. For each subject, I did an ft_sourceanalysis (DICS) and then interpolated the individual volume on the individual anatomy with ft_sourceinterpolate. The result was normalised onto the SPM8 template brain with ft_volumenormalise; then I computed the grand average with ft_sourcegrandaverage. When I plot the grand average (with cfg.funparameter = 'pow'), I see nice results at expected brain regions, but also artifacts around the outline of the volume - see my attached Figure "source_power.png". It appears as if normalization was imperfect so that a border remains, possibly showing idiosyncratic activations from single subjects. The border does not show up if, with the same data, I do ft_sourcestatistics and then plot the results with cfg.funparameter = 'stat' (see attached "source_stat.png"). One might expect this if the voxels showed activation of only one subject so that a t-test would return NANs. I then had a look into the "*.inside" fields of the normalized volumes and was surprised to see that number of voxels inside the brain was different for each subject (ranging between 23 and 27 % roughly). Should that not be the same number of voxels for each subject after normalization? I am now unsure whether the border is a known behavior when plottig the grand average over individual heads,or whether I made an error with normalization. I would be very happy if any someone had an advice for me. Many thanks and best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinvinck at gmail.com Thu Feb 17 09:43:41 2011 From: martinvinck at gmail.com (Martin Vinck) Date: Thu, 17 Feb 2011 09:43:41 +0100 Subject: [FieldTrip] WPLI weighted phase-locking index: available in fieldtrip? (Gregor Volberg) In-Reply-To: References: Message-ID: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> Dear Gregor, Thank you for your interest. Please find, in the latest release, the WPLI functionality in ft_connectivityanalysis. Best regards, Martin Vinck. On Feb 11, 2011, at 10:46 AM, fieldtrip-request at donders.ru.nl wrote: > Send fieldtrip mailing list submissions to > fieldtrip at donders.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 donders.ru.nl > > You can reach the person managing the list at > fieldtrip-owner at donders.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: Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual (Lucie Charles) > 2. WPLI weighted phase-locking index: available in fieldtrip? > (Gregor Volberg) > 3. bug in ft_componentanalysis (Baptiste Gauthier) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Feb 2011 14:03:30 +0100 > From: Lucie Charles > To: Email discussion list for the FieldTrip project > > Subject: Re: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Thank you very much for this very detailed response. > > I didn't know (or forgot) that ft_timelockstatistics could take > several data > sets as an input (I thought we always needed the big data matrix > with all > the subjects). That makes much more sense to remove the option in this > context. > > Thanks again, > > Lucie > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Thank you very much for your feedback. I take the liberty to anyhow >> post >> this to the discussion list, so that other people may take notice / >> join in >> the discussion / etc. >> >> Thanks a lot for this quick response : I understand the logic >> behind this. >> It's true that I noticed some inconsistencies due to the >> interpretation of >> the field dimord which can't be well defined if you have both >> individual and >> average data in your structure. >> >> >> OK >> >> However, I think many people were happy with this option as it was. >> It's >> quite handy to keep both the average and individual data because >> you can >> compute statistics and at the same time you don't have to redo the >> average >> every time. I think a lot of scripts rely on that at least in our >> lab. >> >> >> The historical purpose for supporting cfg.keepindividual = 'yes', >> was in >> order to get a representation of all single subjects' data in a >> single data >> matrix: data.individual. Nowadays, ft_timelockstatistics supports >> multiple >> data structures in the input, i.e. ft_timelockstatistics(cfg, >> subj1, subj2 >> subj3, etc) so I think the call to ft_timelockgrandaverage could >> even be >> bypassed. >> The FieldTrip development team is very keen on providing backward >> compatibility support. While in general this is feasible for the >> functions >> which are in FieldTrip, it is very difficult to realize for lab- >> specific >> scripts. In this particular example I think that clarity of the data >> representation should prevail over backward compatibility issues, >> particularly because in this case there's an easy workaround: just >> call >> ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data >> representation is a prerequisite for further developing the >> software, and >> keeping the historical 'oddity' will only hamper code development. >> >> Furthermore, it's a bit strange to have a function called >> ft_timelockgrandaverage which doesn't compute any grandaverage in >> some cases >> ! >> >> >> I agree, yet see my point above. Some people may just like to have >> the data >> represented in a single matrix. >> >> >> I would suggest to keep the function as it is but add more options >> (such as >> cfg.dimord = 'avg' or 'individual') to make the experimenter aware >> of this >> issue and to solve further computation problem. >> >> >> I hope I could convince you that our philosophy makes sense and >> that you >> and your lab-mates are willing to make the effort of adjusting the >> scripts a >> bit for future analyses. If very problematic, I would advice for >> the current >> analyses to rely on an old version of ft_timelockgrandaverage. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> Thank you again, >> >> Lucie >> >> PS : I've sent this email only to you as this is just a suggestion >> which >> might not be relevant for all users. >> >> >> 2011/2/10 jan-mathijs schoffelen >> >>> Dear Lucie, >>> >>> Yes, indeed this has recently been changed. The logic behind it is >>> the >>> following: >>> >>> One either typically wants to keep the individuals, OR the average. >>> >>> If in your case you need the average, you have to specify >>> cfg.keepindividual = 'no'; >>> >>> Keeping both the average and the individual leads to an inconsistent >>> definition of the data structure. >>> The field 'dimord' does not allow for an unequivocal >>> interpretation of >>> both indidual and avg are present. >>> >>> If you need both the individual, and the avg, you now need to run >>> ft_timelockgrandaverage twice, once with cfg.keepinididual = >>> 'yes', and once >>> with cfg.keepindividual = 'no'; >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >>> >>> Hello everyone, >>> >>> It seems that there has been a modification of >>> ft_timelockgrandaverage : >>> now if you specify cfg.keepindividual = 'yes', the grandaverage is >>> computed >>> but is not included in the output of the function (see above). >>> >>> Why is that ? Many of my scripts rely on this option and I wanted >>> to know >>> if there was a good reason for it. >>> >>> Thanks, >>> >>> Lucie >>> >>> New version of ft_timelockgrandaverage (downloaded yesterday), line >>> 159-176 >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> grandavg = []; >>> grandavg.label = cfg.channel; % cell-array >>> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time';* >>> else >>> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> Older version of ft_timelockgrandaverage (april 2010) >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> %SWITCH CHANNEL TO LABEL? >>> grandavg.label = cfg.channel; % cell-array >>> grandavg.fsample = varargin{1}.fsample; >>> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time'; >>> else >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> >>> -- >>> Lucie CHARLES >>> >>> INSERM-CEA Cognitive Neuroimaging unit >>> >>> CEA/SAC/DSV/DRM/NeuroSpin >>> B?t 145, Point Courrier 156 >>> F-91191 Gif/Yvette, FRANCE >>> Tel : +33 1 69 08 99 74 >>> Fax : +33 1 69 08 79 73 >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> B?t 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > B?t 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 09:46:51 +0100 > From: "Gregor Volberg" > To: "FieldTrip List" > Subject: [FieldTrip] WPLI weighted phase-locking index: available in > fieldtrip? > Message-ID: <4D55058B020000570000882D at gwsmtp1.uni-regensburg.de> > Content-Type: text/plain; charset="us-ascii" > > > Dear fieldtrip developers, > > I was just reading the pre-print of an upcoming article in > Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved > index of phase-synchronization...". As I understand, the proposed > phase-locking index WPLI is not complicated by volume conduction, > and an unbiased version of the WPLI can be computed that is not > affected by trial number. This would be exactely what I need for the > analysis of data from a spatial cueing paradigm. > > In the last paragraph, it is announced that the WPLI is made > available in the fieldtrip toolbox. However, I did not yet find it > (i was searching for it as an option in ft_connectivityanalysis, > last Friday's fieldtrip version). May I ask whether it is planned to > include WPLI / debiased WPLI into that function? Or was it perhaps > intended to be computed by hand from the cross-spectrum. > > Thanks a lot, > Gregor > -- > Dr. rer. nat. Gregor Volberg > ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) > University of Regensburg > Institute for Experimental Psychology > 93040 Regensburg, Germany > Tel: +49 941 943 3862 > Fax: +49 941 943 3233 > http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Feb 2011 10:46:13 +0100 > From: Baptiste Gauthier > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] bug in ft_componentanalysis > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest > update > (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC > without an > input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch > (toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds > \n', > toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 3, Issue 17 > **************************************** From Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 10:57:37 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 10:57:37 +0100 Subject: [FieldTrip] Antw: Re: WPLI weighted phase-locking index: available in fieldtrip? (Gregor Volberg) In-Reply-To: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> References: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> Message-ID: <4D5CFF21020000570000893A@gwsmtp1.uni-regensburg.de> Dear Martin, thanks a lot for your help! I will try it within the next days. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> Martin Vinck 2/17/2011 9:43 AM >>> Dear Gregor, Thank you for your interest. Please find, in the latest release, the WPLI functionality in ft_connectivityanalysis. Best regards, Martin Vinck. On Feb 11, 2011, at 10:46 AM, fieldtrip-request at donders.ru.nl wrote: > Send fieldtrip mailing list submissions to > fieldtrip at donders.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 donders.ru.nl > > You can reach the person managing the list at > fieldtrip-owner at donders.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: Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual (Lucie Charles) > 2. WPLI weighted phase-locking index: available infieldtrip? > (Gregor Volberg) > 3. bug in ft_componentanalysis (Baptiste Gauthier) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Feb 2011 14:03:30 +0100 > From: Lucie Charles > To: Email discussion list for the FieldTrip project > > Subject: Re: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Thank you very much for this very detailed response. > > I didn't know (or forgot) that ft_timelockstatistics could take > several data > sets as an input (I thought we always needed the big data matrix > with all > the subjects). That makes much more sense to remove the option in this > context. > > Thanks again, > > Lucie > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Thank you very much for your feedback. I take the liberty to anyhow >> post >> this to the discussion list, so that other people may take notice / >> join in >> the discussion / etc. >> >> Thanks a lot for this quick response : I understand the logic >> behind this. >> It's true that I noticed some inconsistencies due to the >> interpretation of >> the field dimord which can't be well defined if you have both >> individual and >> average data in your structure. >> >> >> OK >> >> However, I think many people were happy with this option as it was. >> It's >> quite handy to keep both the average and individual data because >> you can >> compute statistics and at the same time you don't have to redo the >> average >> every time. I think a lot of scripts rely on that at least in our >> lab. >> >> >> The historical purpose for supporting cfg.keepindividual = 'yes', >> was in >> order to get a representation of all single subjects' data in a >> single data >> matrix: data.individual. Nowadays, ft_timelockstatistics supports >> multiple >> data structures in the input, i.e. ft_timelockstatistics(cfg, >> subj1, subj2 >> subj3, etc) so I think the call to ft_timelockgrandaverage could >> even be >> bypassed. >> The FieldTrip development team is very keen on providing backward >> compatibility support. While in general this is feasible for the >> functions >> which are in FieldTrip, it is very difficult to realize for lab- >> specific >> scripts. In this particular example I think that clarity of the data >> representation should prevail over backward compatibility issues, >> particularly because in this case there's an easy workaround: just >> call >> ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data >> representation is a prerequisite for further developing the >> software, and >> keeping the historical 'oddity' will only hamper code development. >> >> Furthermore, it's a bit strange to have a function called >> ft_timelockgrandaverage which doesn't compute any grandaverage in >> some cases >> ! >> >> >> I agree, yet see my point above. Some people may just like to have >> the data >> represented in a single matrix. >> >> >> I would suggest to keep the function as it is but add more options >> (such as >> cfg.dimord = 'avg' or 'individual') to make the experimenter aware >> of this >> issue and to solve further computation problem. >> >> >> I hope I could convince you that our philosophy makes sense and >> that you >> and your lab-mates are willing to make the effort of adjusting the >> scripts a >> bit for future analyses. If very problematic, I would advice for >> the current >> analyses to rely on an old version of ft_timelockgrandaverage. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> Thank you again, >> >> Lucie >> >> PS : I've sent this email only to you as this is just a suggestion >> which >> might not be relevant for all users. >> >> >> 2011/2/10 jan-mathijs schoffelen >> >>> Dear Lucie, >>> >>> Yes, indeed this has recently been changed. The logic behind it is >>> the >>> following: >>> >>> One either typically wants to keep the individuals, OR the average. >>> >>> If in your case you need the average, you have to specify >>> cfg.keepindividual = 'no'; >>> >>> Keeping both the average and the individual leads to an inconsistent >>> definition of the data structure. >>> The field 'dimord' does not allow for an unequivocal >>> interpretation of >>> both indidual and avg are present. >>> >>> If you need both the individual, and the avg, you now need to run >>> ft_timelockgrandaverage twice, once with cfg.keepinididual = >>> 'yes', and once >>> with cfg.keepindividual = 'no'; >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >>> >>> Hello everyone, >>> >>> It seems that there has been a modification of >>> ft_timelockgrandaverage : >>> now if you specify cfg.keepindividual = 'yes', the grandaverage is >>> computed >>> but is not included in the output of the function (see above). >>> >>> Why is that ? Many of my scripts rely on this option and I wanted >>> to know >>> if there was a good reason for it. >>> >>> Thanks, >>> >>> Lucie >>> >>> New version of ft_timelockgrandaverage (downloaded yesterday), line >>> 159-176 >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> grandavg = []; >>> grandavg.label = cfg.channel; % cell-array >>> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time';* >>> else >>> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> Older version of ft_timelockgrandaverage (april 2010) >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> %SWITCH CHANNEL TO LABEL? >>> grandavg.label = cfg.channel; % cell-array >>> grandavg.fsample = varargin{1}.fsample; >>> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time'; >>> else >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> >>> -- >>> Lucie CHARLES >>> >>> INSERM-CEA Cognitive Neuroimaging unit >>> >>> CEA/SAC/DSV/DRM/NeuroSpin >>> B?t 145, Point Courrier 156 >>> F-91191 Gif/Yvette, FRANCE >>> Tel : +33 1 69 08 99 74 >>> Fax : +33 1 69 08 79 73 >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> B?t 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > B?t 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 09:46:51 +0100 > From: "Gregor Volberg" > To: "FieldTrip List" > Subject: [FieldTrip] WPLI weighted phase-locking index: available in > fieldtrip? > Message-ID: <4D55058B020000570000882D at gwsmtp1.uni-regensburg.de> > Content-Type: text/plain; charset="us-ascii" > > > Dear fieldtrip developers, > > I was just reading the pre-print of an upcoming article in > Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved > index of phase-synchronization...". As I understand, the proposed > phase-locking index WPLI is not complicated by volume conduction, > and an unbiased version of the WPLI can be computed that is not > affected by trial number. This would be exactely what I need for the > analysis of data from a spatial cueing paradigm. > > In the last paragraph, it is announced that the WPLI is made > available in the fieldtrip toolbox. However, I did not yet find it > (i was searching for it as an option in ft_connectivityanalysis, > last Friday's fieldtrip version). May I ask whether it is planned to > include WPLI / debiased WPLI into that function? Or was it perhaps > intended to be computed by hand from the cross-spectrum. > > Thanks a lot, > Gregor > -- > Dr. rer. nat. Gregor Volberg > ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) > University of Regensburg > Institute for Experimental Psychology > 93040 Regensburg, Germany > Tel: +49 941 943 3862 > Fax: +49 941 943 3233 > http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Feb 2011 10:46:13 +0100 > From: Baptiste Gauthier > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] bug in ft_componentanalysis > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest > update > (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC > without an > input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch > (toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds > \n', > toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 3, Issue 17 > **************************************** _______________________________________________ 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 Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 15:50:05 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 15:50:05 +0100 Subject: [FieldTrip] reverse-normalising voxel locations to non-interpolated source volumes Message-ID: <4D5D43AD0200005700008956@gwsmtp1.uni-regensburg.de> Dear list members, sorry for asking a lot in recent days - i am entering a new stage of enlightment with respect to source analysis, and there are only one or two questions left until i am there. My current problem is the following: I am trying to find the voxel coordinates in an individual source volume that correspond to the voxel coordinates of a ROI, which i identified in the normalized brain. My original source volume is called SOURCE, the interpolated version is SOURCEi, and the normalized volume is NORM. Starting from NORM, I identified voxel coordinates belonging to a ROI, then determined the corresponding head (MNI) coordinates and transformed them into head coordinates of the interpolated individual source SOURCEi: [x,y,z] = ind2sub(NORM.dim, find(mask==1)); % voxel indices of a ROI as given in mask headcoords_NORM = warp_apply(NORM.transform, [x y z], 'homogeneous'); % head coordinates of ROI headcoords_SOURCEi = warp_apply(inv(NORM.cfg.final), headcoords_NORM, 'homogeneous'); % corresponding head coordinates in SOURCEi I checked this with several source plots and the results looked fine. Next, i did an LCMV beamformer with the option cfg.keepfilter = 'yes' in order to reconstruct source waveforms at the ROI. The resulting SOURCE has the filters that i need, but a lower resolution and therefore different voxel indices than SOURCEi. So i need to take the head coordinates i found for SOURCEi and identify the corresponding grid locations in SOURCE . For this i only found a crude solution where i, within the SOURCE.pos field, search for the triplet that produces the smallest squared difference to the MNI coordinates of my ROI in SOURCEi. The matrix subscripts for that triplet give the best fitting grid location for my desired ROI, and the corresponding index is pointing to my desired filter: indx = find((((SOURCE.pos(:,1)-headcoords_SOURCEi(1)).^2) + ((SOURCE.pos(:,2)-headcoords_SOURCEi(2)).^2) + ((SOURCE.pos(:,3)-headcoords_SOURCEi(3)).^2)) == min (((SOURCE.pos(:,1)-headcoords_SOURCEi(1)).^2) + ((SOURCE.pos(:,2)-headcoords_SOURCEi(2)).^2) + ((SOURCE.pos(:,3)-headcoords_SOURCEi(3)).^2))); % assume that ROI is a single source location, 1*3 vector [xvox, yvox, zvox] = ind2sub(SOURCE.dim, indx); ROI_filter = SOURCE.avg.filter{indx}; I am very unsure with these last lines of code. Is it true that SOURCE.pos holds MNI coordinates (for the code would be useless if not)? Or is there an easier solution that i am not aware of yet? Any comments would be greatly appreciated. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredericroux at hotmail.de Thu Feb 17 16:39:25 2011 From: fredericroux at hotmail.de (Frederic Roux) Date: Thu, 17 Feb 2011 16:39:25 +0100 Subject: [FieldTrip] =?windows-1256?q?indepsamplesF_vs_depsamplesF=FE=FE?= Message-ID: Dear fieldtrip users, in the fieldtrip-tutorial about how to compute cluster-based permutation tests for time frequency data I read that one should use the indepsamplesT statistic for between trials experiments at the single subject level and the depsamplesT statistic for within trial experiments at the single subject level. I would like to compute an F-test at the single subject level to test between trials effects between 3 conditions, and I was wondering if in analogy to the t-test, I could also use the indepsamplesF statistic? Any help on this question would be greatly appreciated. Frederic -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 20:48:02 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 20:48:02 +0100 Subject: [FieldTrip] =?windows-1256?q?Antw=3A__indepsamplesF_vs_depsamples?= =?windows-1256?b?Rv7+?= Message-ID: <4D5D89810200005700008976@gwsmtp1.uni-regensburg.de> Dear Frederic, technically, this should not be a problem. You find the available statistics functions in the /statfun directory of your fieldtrip folder (the functions have self-explaining names). The functioin you need can be specified with cfg.statistic = 'indepsamplesF'. Mind that you also need to modify the cfg.design accordingly, with three categories instead of two. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> Frederic Roux 17.02.11 17.08 Uhr >>> Dear fieldtrip users, in the fieldtrip-tutorial about how to compute cluster-based permutation tests for time frequency data I read that one should use the indepsamplesT statistic for between trials experiments at the single subject level and the depsamplesT statistic for within trial experiments at the single subject level. I would like to compute an F-test at the single subject level to test between trials effects between 3 conditions, and I was wondering if in analogy to the t-test, I could also use the indepsamplesF statistic? Any help on this question would be greatly appreciated. Frederic From matthew at psych.columbia.edu Fri Feb 18 02:32:08 2011 From: matthew at psych.columbia.edu (Matthew Davidson) Date: Thu, 17 Feb 2011 20:32:08 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? Message-ID: Hi everyone, I'm looking to see if there's an equivalent to the statfun_indepsamplesZcoh function, but for other connectivity measures, like PLV or WPLI. I need to do several single-subject, between-trials analyses of differences between two conditions. Since my data are intracranial EEG, there's no meaningful group test I could use, which I gather is how many people make inferences on connectivity measures. So, has anyone implemented this, or something like it? Am I missing something obvious in how to do this? If I implement it myself, I guess I should randomly partition the trials, compute the WPLIs of the two groups, take the difference, compute the max cluster size, and build a permutation distribution of the max cluster WPLI difference. Is that generally correct? Should I use jackknife variance to transform them into Z-scores for thresholding? Alternatively, if I wanted to do this parametrically, how should I do that? (I ask because Monte Carlo methods w/clustering haven't worked as well as analytic methods on intracranial data where the electrodes are more independent than in MEG or scalp EEG.) What's the proper reference distribution of differences in these bounded connectivity metrics? Do I just compute the jackknife variance, and then do a mass univariate t-test on the connectivity measures (for a single electrode pair and freq bin)? Thanks for any insight or advice you might have, Matthew Davidson From e.maris at donders.ru.nl Fri Feb 18 10:36:36 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Fri, 18 Feb 2011 10:36:36 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: References: Message-ID: <039201cbcf4f$594548f0$0bcfdad0$@maris@donders.ru.nl> Hi Matthew, Permutation inference is valid for comparing two experimental conditions using ANY statistic. If your channels are more or less independent (no common pick-up via volume conduction), then don't use the cluster-based statistics (at least not for the spatial dimension; clustering along the spectral dimension may still be wise). Best, Eric Maris > -----Original Message----- > From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > bounces at donders.ru.nl] On Behalf Of Matthew Davidson > Sent: vrijdag 18 februari 2011 2:32 > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? > > Hi everyone, I'm looking to see if there's an equivalent to the > statfun_indepsamplesZcoh function, but for other connectivity > measures, like PLV or WPLI. I need to do several single-subject, > between-trials analyses of differences between two conditions. Since > my data are intracranial EEG, there's no meaningful group test I could > use, which I gather is how many people make inferences on connectivity > measures. So, has anyone implemented this, or something like it? Am I > missing something obvious in how to do this? > > If I implement it myself, I guess I should randomly partition the > trials, compute the WPLIs of the two groups, take the difference, > compute the max cluster size, and build a permutation distribution of > the max cluster WPLI difference. Is that generally correct? Should I > use jackknife variance to transform them into Z-scores for > thresholding? > > Alternatively, if I wanted to do this parametrically, how should I do > that? (I ask because Monte Carlo methods w/clustering haven't worked > as well as analytic methods on intracranial data where the electrodes > are more independent than in MEG or scalp EEG.) What's the proper > reference distribution of differences in these bounded connectivity > metrics? Do I just compute the jackknife variance, and then do a mass > univariate t-test on the connectivity measures (for a single electrode > pair and freq bin)? > > Thanks for any insight or advice you might have, > Matthew Davidson > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From matthew at psych.columbia.edu Fri Feb 18 18:31:58 2011 From: matthew at psych.columbia.edu (Matthew Davidson) Date: Fri, 18 Feb 2011 12:31:58 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: <-5697139143563785936@unknownmsgid> References: <-5697139143563785936@unknownmsgid> Message-ID: Thanks for your reply, Dr. Maris. I'm sure you're very busy, so I really appreciate your taking time out to answer me. I'd already tried clustering across only time/frequency and not across channel, but what I found was that the strongest channels "set the bar" for all the others, so to speak. I would see 2-3 strong channels with long significant durations reaching significance, and everything else would be silenced. Whereas with parametric stats, I had enough strong signals to detect changes under FDR and Bonferroni correction across a wide range of times and channels. Would z-scoring to compensate for electrode sensitivity differences have helped? I considered doing Monte Carlo stats for each channel independently, and then adjusting critical p-vals via FDR or Bonferroni, but for 100 channels, I would need at least 20000 permutations just to have the Monte Carlo p-val resolution *approach* the adjusted Bonferroni p-vals, and would probably need more to be safe. Factor in several subjs and contrasts, and I computed my analysis would take a few weeks to run. This was why I asked about a parametric method; while I'd prefer permutation methods, I fear the same problem will occur with my connectivity analysis. I know your focus is on permutation stats, but do you have any insight into how to proceed? Think I could generate a permutation distribution of the WPLI differences from a random sampling of electrodes and contrasts, and then, if they look sufficiently close to normal (or transformable via something like a log transform), use that as an argument for using t-tests if I have to? Thanks again, Matthew On Fri, Feb 18, 2011 at 4:36 AM, Eric Maris wrote: > Hi Matthew, > > > Permutation inference is valid for comparing two experimental conditions > using ANY statistic. If your channels are more or less independent (no > common pick-up via volume conduction), then don't use the cluster-based > statistics (at least not for the spatial dimension; clustering along the > spectral dimension may still be wise). > > Best, > > Eric Maris > > > > >> -----Original Message----- >> From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- >> bounces at donders.ru.nl] On Behalf Of Matthew Davidson >> Sent: vrijdag 18 februari 2011 2:32 >> To: fieldtrip at donders.ru.nl >> Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? >> >> Hi everyone, I'm looking to see if there's an equivalent to the >> statfun_indepsamplesZcoh function, but for other connectivity >> measures, like PLV or WPLI. I need to do several single-subject, >> between-trials analyses of differences between two conditions. Since >> my data are intracranial EEG, there's no meaningful group test I could >> use, which I gather is how many people make inferences on connectivity >> measures. So, has anyone implemented this, or something like it? Am I >> missing something obvious in how to do this? >> >> If I implement it myself, I guess I should randomly partition the >> trials, compute the WPLIs of the two groups, take the difference, >> compute the max cluster size, and build a permutation distribution of >> the max cluster WPLI difference. Is that generally correct? Should I >> use jackknife variance to transform them into Z-scores for >> thresholding? >> >> Alternatively, if I wanted to do this parametrically, how should I do >> that? (I ask because Monte Carlo methods w/clustering haven't worked >> as well as analytic methods on intracranial data where the electrodes >> are more independent than in MEG or scalp EEG.) What's the proper >> reference distribution of differences in these bounded connectivity >> metrics? Do I just compute the jackknife variance, and then do a mass >> univariate t-test on the connectivity measures (for a single electrode >> pair and freq bin)? >> >> Thanks for any insight or advice you might have, >> Matthew Davidson >> _______________________________________________ >> 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 lifengmiao at gmail.com Fri Feb 18 20:07:16 2011 From: lifengmiao at gmail.com (Lifeng Miao) Date: Fri, 18 Feb 2011 12:07:16 -0700 Subject: [FieldTrip] question In-Reply-To: References: Message-ID: Dear Fieldtrip members, I have a question when using Fieldtrip tools. What are the locations of the 64 electrodes for EEG data set "subj2"? Thank you very much! Regards, Lifeng -------------- next part -------------- An HTML attachment was scrubbed... URL: From master_engineer07 at yahoo.com Fri Feb 18 22:42:09 2011 From: master_engineer07 at yahoo.com (yacob Jon Mohamady) Date: Fri, 18 Feb 2011 13:42:09 -0800 (PST) Subject: [FieldTrip] problem with ft_read_mri Message-ID: <250412.78294.qm@web38303.mail.mud.yahoo.com> Hi there, I want to calculate the BEM fo EEG. When I run this command line: mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); it gives the following error: Error using ==> spm_platform>init_platform at 173 PCWIN64 not supported architecture for SPM I have SPM8 and when I change my SPM8 to SPM5 it gives this erros: Error using ==> fread Invalid size. I have windows 7, 64-bit and MATLAB 2010a 64-bit. Do you know how I can fix the problem, please. Thank you Yaqub -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Sun Feb 20 17:34:40 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Sun, 20 Feb 2011 17:34:40 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: References: <-5697139143563785936@unknownmsgid> Message-ID: <003401cbd11c$124fcbe0$36ef63a0$@maris@donders.ru.nl> Dear Matthew, > I'd already tried clustering across only time/frequency and not across > channel, but what I found was that the strongest channels "set the > bar" for all the others, so to speak. I would see 2-3 strong channels > with long significant durations reaching significance, and everything > else would be silenced. Whereas with parametric stats, I had enough > strong signals to detect changes under FDR and Bonferroni correction > across a wide range of times and channels. Would z-scoring to > compensate for electrode sensitivity differences have helped? Are the channel-time-frequency-specific parametric p-values smaller than the corresponding permutation p-values (for the same test statistic, of course)? If that is the case, then I would be suspicious wrt to the validity of the parametric test (i.c., its false alarm rate control). (This does not mean, of course, that a smaller parametric p-value implies poor false alarm control.) It's not clear to me what you mean by z-scoring. Does this amount to a linear transform of the dependent variable (the same one for the conditions that are compared)? > > I considered doing Monte Carlo stats for each channel independently, > and then adjusting critical p-vals via FDR or Bonferroni, but for 100 > channels, I would need at least 20000 permutations just to have the > Monte Carlo p-val resolution *approach* the adjusted Bonferroni > p-vals, and would probably need more to be safe. Factor in several > subjs and contrasts, and I computed my analysis would take a few weeks > to run. > > This was why I asked about a parametric method; while I'd prefer > permutation methods, I fear the same problem will occur with my > connectivity analysis. I know your focus is on permutation stats, but > do you have any insight into how to proceed? Think I could generate a > permutation distribution of the WPLI differences from a random > sampling of electrodes and contrasts, and then, if they look > sufficiently close to normal (or transformable via something like a > log transform), use that as an argument for using t-tests if I have > to? If a parametric test solves my problem, then I will definitely use it. However, for statistical tests outside the normal theory parametric framework, it is typically a big challenge to come up with an appropriate parametric reference distribution. I expect this to hold for the WPLI too. Statistical testing of differences at the level of channel pairs (e.g., differences in coupling strength) is a big methodological challenge, for many reasons (a huge multiple comparison problem, lack of specificity of the coupling measure that is used for testing, difficulty of clustering in the space formed by channel pairs). A discussion of these issues is being the scope of the FT discussion list. It is not clear to me what you mean by "generate a permutation distribution of the WPLI differences from a random sampling of electrodes and contrasts". Constructing a permutation distribution in a single subject study (which I assume you are conducting, because you have ECoG data) involves random partitioning of trials (and not electrodes and contrasts). Best, Eric dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > > Thanks again, > Matthew > > > On Fri, Feb 18, 2011 at 4:36 AM, Eric Maris > wrote: > > Hi Matthew, > > > > > > Permutation inference is valid for comparing two experimental > conditions > > using ANY statistic. If your channels are more or less independent > (no > > common pick-up via volume conduction), then don't use the cluster- > based > > statistics (at least not for the spatial dimension; clustering along > the > > spectral dimension may still be wise). > > > > Best, > > > > Eric Maris > > > > > > > > > >> -----Original Message----- > >> From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > >> bounces at donders.ru.nl] On Behalf Of Matthew Davidson > >> Sent: vrijdag 18 februari 2011 2:32 > >> To: fieldtrip at donders.ru.nl > >> Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? > >> > >> Hi everyone, I'm looking to see if there's an equivalent to the > >> statfun_indepsamplesZcoh function, but for other connectivity > >> measures, like PLV or WPLI. I need to do several single-subject, > >> between-trials analyses of differences between two conditions. Since > >> my data are intracranial EEG, there's no meaningful group test I > could > >> use, which I gather is how many people make inferences on > connectivity > >> measures. So, has anyone implemented this, or something like it? Am > I > >> missing something obvious in how to do this? > >> > >> If I implement it myself, I guess I should randomly partition the > >> trials, compute the WPLIs of the two groups, take the difference, > >> compute the max cluster size, and build a permutation distribution > of > >> the max cluster WPLI difference. Is that generally correct? Should I > >> use jackknife variance to transform them into Z-scores for > >> thresholding? > >> > >> Alternatively, if I wanted to do this parametrically, how should I > do > >> that? (I ask because Monte Carlo methods w/clustering haven't worked > >> as well as analytic methods on intracranial data where the > electrodes > >> are more independent than in MEG or scalp EEG.) What's the proper > >> reference distribution of differences in these bounded connectivity > >> metrics? Do I just compute the jackknife variance, and then do a > mass > >> univariate t-test on the connectivity measures (for a single > electrode > >> pair and freq bin)? > >> > >> Thanks for any insight or advice you might have, > >> Matthew Davidson > >> _______________________________________________ > >> 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 r.oostenveld at donders.ru.nl Sun Feb 20 21:03:12 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Sun, 20 Feb 2011 21:03:12 +0100 Subject: [FieldTrip] problem with ft_read_mri In-Reply-To: <250412.78294.qm@web38303.mail.mud.yahoo.com> References: <250412.78294.qm@web38303.mail.mud.yahoo.com> Message-ID: Dear Yaqub (and Cristian, who recently had a similar question) FieldTrip uses SPM for some of the MRI reading and processing. For that purpose, fieldtrip/external/spm2 and fieldtrip/external/spm8 are included in the fieldtrip release version. These are automatically added to the path when needed, but will not be added to the path if you already have another version of spm on your path. Your problem (not having the mex file for the right problem) should be solved if you ensure that fieldtrip/external/spm8 is on your path. That version of SPM8 includes the mex files for 64 bit MS Windows and for 64 bit Mac OS X. The ft_read_mri will then call the correct compiled mex file. best regards, Robert On 18 Feb 2011, at 22:42, yacob Jon Mohamady wrote: > Hi there, > > I want to calculate the BEM fo EEG. > When I run this command line: > mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); > it gives the following error: > Error using ==> spm_platform>init_platform at 173 > PCWIN64 not supported architecture for SPM > > I have SPM8 and when I change my SPM8 to SPM5 it gives this erros: > Error using ==> fread > Invalid size. > > I have windows 7, 64-bit and MATLAB 2010a 64-bit. > Do you know how I can fix the problem, please. > > Thank you > Yaqub > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From r.oostenveld at donders.ru.nl Mon Feb 21 17:58:07 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Mon, 21 Feb 2011 17:58:07 +0100 Subject: [FieldTrip] question In-Reply-To: References: Message-ID: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> Dear Lifeng I would not know whether we have the 3D positions measured for that subject, but the 2D projected positions for plotting are the ones that correspond to fieldtrip/template/easycap64ch-avg.lay and to the section http://fieldtrip.fcdonders.nl/tutorial/layout#easycap_layouts on the tutorial page that explains how to work with 2D layouts for plotting. best regards, Robert On 18 Feb 2011, at 20:07, Lifeng Miao wrote: > > Dear Fieldtrip members, > I have a question when using Fieldtrip tools. What are the locations > of the 64 electrodes for EEG data set "subj2"? > > Thank you very much! > > Regards, > Lifeng > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From lifengmiao at gmail.com Mon Feb 21 18:22:15 2011 From: lifengmiao at gmail.com (Lifeng Miao) Date: Mon, 21 Feb 2011 10:22:15 -0700 Subject: [FieldTrip] question In-Reply-To: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> References: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> Message-ID: Thank you very much! On Mon, Feb 21, 2011 at 9:58 AM, Robert Oostenveld < r.oostenveld at donders.ru.nl> wrote: > Dear Lifeng > > I would not know whether we have the 3D positions measured for that > subject, but the 2D projected positions for plotting are the ones that > correspond to fieldtrip/template/easycap64ch-avg.lay > and to the section > http://fieldtrip.fcdonders.nl/tutorial/layout#easycap_layouts > on the tutorial page that explains how to work with 2D layouts for > plotting. > > best regards, > Robert > > > > On 18 Feb 2011, at 20:07, Lifeng Miao wrote: > > >> Dear Fieldtrip members, >> I have a question when using Fieldtrip tools. What are the locations of >> the 64 electrodes for EEG data set "subj2"? >> >> Thank you very much! >> >> Regards, >> Lifeng >> >> _______________________________________________ >> 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 Nina.Kahlbrock at uni-duesseldorf.de Mon Feb 21 18:54:27 2011 From: Nina.Kahlbrock at uni-duesseldorf.de (Nina Kahlbrock) Date: Mon, 21 Feb 2011 18:54:27 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics Message-ID: <003901cbd1f0$622291a0$cd136386@VMED.UKD> Dear all, I have a question concerning cluster based permutation statistics. It is more a basic question on the difference between one- and two-sided testings. I recall from simple t-tests that as an approach to your two-sided p-value you can multiply your one-sided p-value by 2. I hope this is correct? And I am assuming this to also hold in the other direction, thus, approximating your one-sided p-value by dividing your two-sided p-value by 2? That is why I am expecting something similar when calculating my statistics with a cluster based permutation approach. So what I am actually doing is comparing two conditions at one sensor, comparing time-frequency data. When I calculate a two-sided dependent samples t-test (cfg = []; cfg.channel = 'all'; cfg.latency = [0.5 1.5]; cfg.avgoverchan = 'no'; cfg.avgovertime = 'no'; cfg.parameter = 'powspctrm'; cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 1000; ) , I find one positive cluster with a p-value of 0.036, thus not significant (see fig 1). When I then change my settings to a one-sided test (cfg.tail = 1; cfg.clustertail = 1; cfg.alpha = 0.05;) , the positive cluster gets a p-value of 0.056, again not significant (see fig 2). With the assumption described above, however, I would expect this to become significant when using a one-sided test. Is my assumption correct? If not, could anybody comment on what is wrong about my assumption? I would be very grateful for any advice! Kind regards and thank you very much in advance! Nina - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nina Kahlbrock Institute of Clinical Neuroscience and Medical Psychology Heinrich Heine University Duesseldorf Universitaetsstr. 1 40225 Düsseldorf Tel.: +49 211 81 18075 Fax. .: +49 211 81 19916 Mail: Nina.Kahlbrock at med.uni-duesseldorf.de http://www.uniklinik-duesseldorf.de/medpsychologie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fig 1.pdf Type: application/pdf Size: 9504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fig 2.pdf Type: application/pdf Size: 9660 bytes Desc: not available URL: From sunyata at gmail.com Mon Feb 21 21:39:56 2011 From: sunyata at gmail.com (Matthew Davidson) Date: Mon, 21 Feb 2011 15:39:56 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: <-356542662290850285@unknownmsgid> References: <-5697139143563785936@unknownmsgid> <-356542662290850285@unknownmsgid> Message-ID: >> I'd already tried clustering across only time/frequency and not across >> channel, but what I found was that the strongest channels "set the >> bar" for all the others, so to speak. I would see 2-3 strong channels >> with long significant durations reaching significance, and everything >> else would be silenced. Whereas with parametric stats, I had enough >> strong signals to detect changes under FDR and Bonferroni correction >> across a wide range of times and channels. Would z-scoring to >> compensate for electrode sensitivity differences have helped? > > Are the channel-time-frequency-specific parametric p-values smaller than the > corresponding permutation p-values (for the same test statistic, of course)? > If that is the case, then I would be suspicious wrt to the validity of the > parametric test (i.c., its false alarm rate control). (This does not mean, > of course, that a smaller parametric p-value implies poor false alarm > control.) The parametric p-vals are much smaller, but wouldn't they have to be? To reach significance after Bonferroni correction, they'd have to be on the order of .0005. FWIW, when I ran the permutation tests, I did see p-vals at the minimum possible values. > It's not clear to me what you mean by z-scoring. Does this amount to a > linear transform of the dependent variable (the same one for the conditions > that are compared)? This would have involved z-scoring the log power. With intracranial data, some electrodes are simply less sensitive because they're not making good contact with the brain (because of the way they're embedded in plastic sheets, each electrode is not individually placed), and not because they're picking up a more distal/weaker signal. So, one way to compensate would be to normalize the power. I asked just in case, but I didn't really suspect this would work. Even if power were normalized, the cluster-max permutation distribution would still be dominated by the electrodes that were significant for the longest period of time. >> >> I considered doing Monte Carlo stats for each channel independently, >> and then adjusting critical p-vals via FDR or Bonferroni, but for 100 >> channels, I would need at least 20000 permutations just to have the >> Monte Carlo p-val resolution *approach* the adjusted Bonferroni >> p-vals, and would probably need more to be safe. Factor in several >> subjs and contrasts, and I computed my analysis would take a few weeks >> to run. >> >> This was why I asked about a parametric method; while I'd prefer >> permutation methods, I fear the same problem will occur with my >> connectivity analysis. I know your focus is on permutation stats, but >> do you have any insight into how to proceed? Think I could generate a >> permutation distribution of the WPLI differences from a random >> sampling of electrodes and contrasts, and then, if they look >> sufficiently close to normal (or transformable via something like a >> log transform), use that as an argument for using t-tests if I have >> to? > > If a parametric test solves my problem, then I will definitely use it. > However, for statistical tests outside the normal theory parametric > framework, it is typically a big challenge to come up with an appropriate > parametric reference distribution. I expect this to hold for the WPLI too. > > Statistical testing of differences at the level of channel pairs (e.g., > differences in coupling strength) is a big methodological challenge, for > many reasons (a huge multiple comparison problem, lack of specificity of the > coupling measure that is used for testing, difficulty of clustering in the > space formed by channel pairs). A discussion of these issues is being the > scope of the FT discussion list. > > It is not clear to me what you mean by "generate a permutation distribution > of the WPLI differences from a random sampling of electrodes and contrasts". > Constructing a permutation distribution in a single subject study (which I > assume you are conducting, because you have ECoG data) involves random > partitioning of trials (and not electrodes and contrasts). Ehh, this was a bit more ad hoc. I didn't have a formal method in mind, I was just thinking about the Kiebel, Tallon-Baudry and Friston HBM paper where they show that log-transforming power renders it approximately normal. It should, however, be legitimate for any given electrode pair to permute trials, compute the connectivity metrics and their difference, generate a permutation distribution of the difference, and make an inference from that, yes? (Although it doesn't address the MCP.) Thanks for all your help, btw. Matthew From e.maris at donders.ru.nl Mon Feb 21 21:58:52 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Mon, 21 Feb 2011 21:58:52 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics Message-ID: <00b501cbd20a$256bf890$7043e9b0$@maris@donders.ru.nl> Hi Nina, I have a question concerning cluster based permutation statistics. It is more a basic question on the difference between one- and two-sided testings. I recall from simple t-tests that as an approach to your two-sided p-value you can multiply your one-sided p-value by 2. I hope this is correct? And I am assuming this to also hold in the other direction, thus, approximating your one-sided p-value by dividing your two-sided p-value by 2? I propose that you calculate your p-values always one-sided. In fact, this is what the FT permutation statistics functions also do. The difference between a one- and a two-sided test is that you compare this one-sided p-value either with your desired type-I error level (for a one-sided test) or with half your desired type-I error level (for a two-sided test). That is why I am expecting something similar when calculating my statistics with a cluster based permutation approach. So what I am actually doing is comparing two conditions at one sensor, comparing time-frequency data. When I calculate a two-sided dependent samples t-test (cfg = []; cfg.channel = 'all'; cfg.latency = [0.5 1.5]; cfg.avgoverchan = 'no'; cfg.avgovertime = 'no'; cfg.parameter = 'powspctrm'; cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 1000; ) , I find one positive cluster with a p-value of 0.036, thus not significant (see fig 1). When I then change my settings to a one-sided test (cfg.tail = 1; cfg.clustertail = 1; cfg.alpha = 0.05;) , the positive cluster gets a p-value of 0.056, again not significant (see fig 2). I think that the difference between 0.036 and 0.056 is due to the fact that these are random quantities. If expect that, if you would increase cfg.numrandomization to 100,000, you would find two p-values that are much closer. In any case, the p-values are one-sided, and their calculation is independent of the value that you choose for cfg.alpha. Best, Eric Maris With the assumption described above, however, I would expect this to become significant when using a one-sided test. Is my assumption correct? If not, could anybody comment on what is wrong about my assumption? I would be very grateful for any advice! Kind regards and thank you very much in advance! Nina - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nina Kahlbrock Institute of Clinical Neuroscience and Medical Psychology Heinrich Heine University Duesseldorf Universitaetsstr. 1 40225 Düsseldorf Tel.: +49 211 81 18075 Fax. .: +49 211 81 19916 Mail: Nina.Kahlbrock at med.uni-duesseldorf.de http://www.uniklinik-duesseldorf.de/medpsychologie -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Tue Feb 22 07:26:10 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 22 Feb 2011 07:26:10 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? Message-ID: <00c101cbd259$7b5f3330$721d9990$@maris@donders.ru.nl> Hi Matthew, > The parametric p-vals are much smaller, but wouldn't they have to be? > To reach significance after Bonferroni correction, they'd have to be > on the order of .0005. FWIW, when I ran the permutation tests, I did > see p-vals at the minimum possible values. If the parametric p-values are around, say, 1e-10, then I would expect the permutation p-value to be 0, unless numrandomization is set a very high value (around 1e+10). It should, however, be legitimate for any given > electrode pair to permute trials, compute the connectivity metrics and > their difference, generate a permutation distribution of the > difference, and make an inference from that, yes? (Although it doesn't > address the MCP.) Agree. Best, Eric > > Thanks for all your help, btw. > Matthew From Nina.Kahlbrock at uni-duesseldorf.de Tue Feb 22 10:14:08 2011 From: Nina.Kahlbrock at uni-duesseldorf.de (Nina Kahlbrock) Date: Tue, 22 Feb 2011 10:14:08 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics In-Reply-To: <00b501cbd20a$256bf890$7043e9b0$%maris@donders.ru.nl> References: <00b501cbd20a$256bf890$7043e9b0$%maris@donders.ru.nl> Message-ID: <000901cbd270$dd991b80$cd136386@VMED.UKD> Hi Eric, thank you very much for your reply! I still have a question regarding your answer, though. I propose that you calculate your p-values always one-sided. In fact, this is what the FT permutation statistics functions also do. The difference between a one- and a two-sided test is that you compare this one-sided p-value either with your desired type-I error level (for a one-sided test) or with half your desired type-I error level (for a two-sided test). I think that the difference between 0.036 and 0.056 is due to the fact that these are random quantities. If expect that, if you would increase cfg.numrandomization to 100,000, you would find two p-values that are much closer. In any case, the p-values are one-sided, and their calculation is independent of the value that you choose for cfg.alpha. I understand that cfg.alpha only gives the threshold for which of my p-values is counted as being significant. However, I thought, changing cfg.tail would change whether I am looking for positive and negative clusters (cfg.tail = 0, two-sided test), or only positive or only negative clusters (cfg.tail = 1 or -1, one-sided test). The change in stat.prob from 0.036 to 0.056 described in my previous email seems to depend on whether I set cfg.tail to 0 or 1. I've computed it multiple times and witch cfg.tail = 0, stat.prob evolves around 0.03 and with cfg.tail = 1 around 0.05. Could you maybe explain this to me? >From your explanation above I would assume that I can use cfg.tail = 0 and cfg.alpha = 0.05 to end up with a mask including my significant clusters in a one-sided test? Thanks again for your help! Nina -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmeyer at cbs.mpg.de Tue Feb 22 13:01:16 2011 From: lmeyer at cbs.mpg.de (Lars Meyer) Date: Tue, 22 Feb 2011 13:01:16 +0100 Subject: [FieldTrip] =?iso-8859-1?q?correlation_=7C=A0statfun?= Message-ID: dear all, on the new fieldtrip homepage, i find a short suggestion on how to try and run a correlation analysis on timelock data using an external regressor (e.g. an fmri-effect) and a single-rowed cfg.design containing this regressor. my questions now are: how does the data have to look? should i just produce an effect (= difference .avg containing the difference between two erps) for each participant, i.e. my input data is a 1 x participants struct? is it correct that cfg.design is only the regressor (= one value per participant), and that cfg.uvar is empty? if the above are correct: what is the proper statfun to run this type of statistic, i.e. a correlation between the individual effects and an external regressor, if i want to use the cluster statistics monte carlo approach? thanks a lot, l. Lars Meyer Max Planck Institute for Human Cognitive & Brain Sciences Department of Neuropsychology Stephanstrafle 1a 04103 Leipzig | Germany Office | +49 341 99 40 22 66 Mail | lmeyer at cbs.mpg.de Web | www.cbs.mpg.de/~lmeyer From r.oostenveld at donders.ru.nl Tue Feb 22 21:48:35 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Tue, 22 Feb 2011 21:48:35 +0100 Subject: [FieldTrip] Washington University in St. Louis seeks postdoctoral scholar for MEG studies References: <4476B37DB8F5D248AE7C349966A22A04406D2359A8@nilex07.neuroimage.wustl.edu> Message-ID: Dear FieldTrip list members, Please see below or on http://humanconnectome.org for an interesting postdoc opportunity. The successful candidate will (among others) work together with the FieldTrip/Donders team. best regards Robert Oostenveld On 22 Feb 2011, at 19:04, Larson-Prior, Linda wrote: > Dear Colleague, > Washington University in St. Louis announces that a full-time Postdoctoral Research Associate position is available to develop creative methods of magnetoencephalography (MEG) analysis for the Human Connectome Project (HCP). The job announcement for this position is attached and we would appreciate your circulating this position announcement to you trainees. > > Best Regards, > Linda Larson-Prior > Abraham Snyder -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WU_MEG_postdoc_job_description_191113.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 15877 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Wed Feb 23 02:21:17 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Tue, 22 Feb 2011 17:21:17 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume Message-ID: Hello, While writing beamformed images to spm2 format in a previous version of fieldtrip (now lost due to a computer crash), I was able to get nice-looking results; networks of brain regions consistent with existing literature. When I try to write images from the same dataset and the same analysis to spm8 format, my results (t-images computed across subjects) end up being single clusters spanning large sections of the brain (e.g. a 'blob' spanning all of one hemisphere but not the other). Unfortunately, some aspects of my planned data analyses cannot be performed on spm2 images, so I have to find a way of writing to successfully to nifti format. I just noticed that in the comments in the ft_write_volume function, which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under the list of supported dataformats. Is there by any chance a patch out there for writing nifti images? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Wed Feb 23 16:50:16 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Wed, 23 Feb 2011 16:50:16 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: Message-ID: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Dear Jen, I notice that indeed in the documentation section of ft_write_volume there is a FIXME behind nifti. Yet, nifti format seems to be supported by ft_write_volume (at least in a recent version of fieldtrip). Did you try it at all (and ran into problems) or were you held back by the FIXME statement? Could you just try it out using a recent fieldtrip function? Thanks and best wishes Jan-Mathijs On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From jenwhitman at gmail.com Wed Feb 23 19:44:03 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Wed, 23 Feb 2011 10:44:03 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: Dear Jan, Thanks for the quick reply. Yes, I have tried it out quite a few times now, experimenting with different settings in the cfgs. Below I'll paste the code I've been using to write images - first the code that successfully created spm2 images that produced good results, then the code used for creating nifti format images from the same data. The comments in this second part are at this point a bit of a maze of cfg options I've been changing back & forth. Any insights/suggestions regarding how to set up my cfgs to make this work would be greatly appreciated. Jen %%%%%%%% this code generated spm2-compatible images which did work (producing results that made sense). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ sourcePre.avg.pow; cfg = []; cfg.downsample = 2; sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); % projecting the plot onto a surface... cfg = []; cfg.coordinates = 'ctf'; cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this template is in MNI coordinates sourcetempIntN = volumenormalise(cfg, sourcetempInt); filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) 'HzWin' int2str(win) 'width750ms']; cfg=[]; cfg.parameter = 'avg.pow'; % string, describing the functional data to be processed, e.g. 'pow', 'coh' or 'nai' cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % filename without the extension cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive (default = []) cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', 'int16', 'int32', 'float' or 'double' volumewrite(cfg, sourcetempIntN) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%% this code below hasn't worked yet... % I added cfg.spmversion = 'spm8'; % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, % and in the call to prepare_singleshell after calling volumesegment % I've also ensured that spm8 is the only spm version in my path, even in % the fieldtrip/external folder, and ensured that spm8 is installed properly % (files compiled correctly, etc..) sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ sourcePre.avg.pow; filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; cfg = []; % cfg.coordinates = 'spm'; % changed for version 5 % cfg.spmversion = 'spm8'; % changed for version 5 cfg.downsample = 4; sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); % projecting the plot onto a surface... cfg = []; %cfg.coordinates = 'spm'; % changed for version 5 %cfg.coordinates = 'ctf'; % changed for version 5 cfg.coordinates = 'spm'; % changed back to spm for version 9 cfg.downsample = 4; %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets specified in volumewrite) cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has the desired voxel size % cfg.name = [filename]; % changed for version 6 %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' there was no subsequent call to volumewrite) cfg.write= 'no'; % changed for version 6 sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); % this whole cfg and function call added for version 6 cfg=[]; % cfg.parameter = string, describing the functional data to be processed, e.g. 'pow', 'coh' or 'nai' % cfg.filename = filename without the extension % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = []) cfg.parameter='pow'; cfg.filename=filename; cfg.filetype = 'spm'; cfg.spmversion = 'SPM8'; % capitalized after first error message from vers 6 % cfg.dataformat='nifti'; % added after first error message from vers 6 % commented out after 2nd error message from vers 6 %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to specify unless cfg.filetyp='vmp' cfg.coordinates='spm'; ft_volumewrite(cfg,sourcetempIntN); On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume there > is a FIXME behind nifti. Yet, nifti format seems to be supported by > ft_write_volume (at least in a recent version of fieldtrip). Did you try it > at all (and ran into problems) or were you held back by the FIXME statement? > Could you just try it out using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, >> >> While writing beamformed images to spm2 format in a previous version of >> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >> results; networks of brain regions consistent with existing literature. When >> I try to write images from the same dataset and the same analysis to spm8 >> format, my results (t-images computed across subjects) end up being single >> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >> one hemisphere but not the other). Unfortunately, some aspects of my planned >> data analyses cannot be performed on spm2 images, so I have to find a way of >> writing to successfully to nifti format. >> >> I just noticed that in the comments in the ft_write_volume function, which >> I am calling via ft_volumewrite, it says 'FIXME' next to nifti under the >> list of supported dataformats. Is there by any chance a patch out there for >> writing nifti images? >> >> Thanks! >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Thu Feb 24 07:58:24 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 24 Feb 2011 07:58:24 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: Hi Jen, Thanks for sending the code. What is the actual error message you are getting? Best wishes, Jan-Mathijs On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few > times now, experimenting with different settings in the cfgs. Below > I'll paste the code I've been using to write images - first the code > that successfully created spm2 images that produced good results, > then the code used for creating nifti format images from the same > data. The comments in this second part are at this point a bit of a > maze of cfg options I've been changing back & forth. Any insights/ > suggestions regarding how to set up my cfgs to make this work would > be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; > %this template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the > functional data to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; > %'testimageoutput_alphafreq'; % filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and > ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, > even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this > gets specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to > using spm8/templates/EPI.nii, except that mask.nii (produced from > fmri data) has the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to > 'yes' there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format > to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive > (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message > from vers 6 > % cfg.dataformat='nifti'; % added after first error message from > vers 6 > % commented out after 2nd error > message from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need > to specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume > there is a FIXME behind nifti. Yet, nifti format seems to be > supported by ft_write_volume (at least in a recent version of > fieldtrip). Did you try it at all (and ran into problems) or were > you held back by the FIXME statement? Could you just try it out > using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 24 13:44:51 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 24 Feb 2011 13:44:51 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Dear Jen, I managed to reproduce your problem. The code was rather buggy and indeed ft_volumewrite did not behave as it should have. I now fixed it in the code and it should run fine now. Please find the updated file attached. It will be available on our ftp-server as of tonight. Please note that I updated the documentation, and changed the names of some of the options a bit. If you want to save your data in analyze-format, you should specify cfg.filetype = 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a volume to nifti-format, using SPM8. Best wishes, Jan-Mathijs On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few > times now, experimenting with different settings in the cfgs. Below > I'll paste the code I've been using to write images - first the code > that successfully created spm2 images that produced good results, > then the code used for creating nifti format images from the same > data. The comments in this second part are at this point a bit of a > maze of cfg options I've been changing back & forth. Any insights/ > suggestions regarding how to set up my cfgs to make this work would > be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; > %this template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the > functional data to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; > %'testimageoutput_alphafreq'; % filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and > ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, > even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this > gets specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to > using spm8/templates/EPI.nii, except that mask.nii (produced from > fmri data) has the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to > 'yes' there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format > to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive > (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message > from vers 6 > % cfg.dataformat='nifti'; % added after first error message from > vers 6 > % commented out after 2nd error > message from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need > to specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume > there is a FIXME behind nifti. Yet, nifti format seems to be > supported by ft_write_volume (at least in a recent version of > fieldtrip). Did you try it at all (and ran into problems) or were > you held back by the FIXME statement? Could you just try it out > using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ft_volumewrite.m Type: application/octet-stream Size: 16641 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.litvak at ion.ucl.ac.uk Thu Feb 24 17:06:06 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Thu, 24 Feb 2011 16:06:06 +0000 Subject: [FieldTrip] ICA In-Reply-To: <1625468855117010300@unknownmsgid> References: <1625468855117010300@unknownmsgid> Message-ID: Hi Holly, I'm not sure why the databrowser needs the trl struct or whether we can add something to our exported FT struct to make it happy. I'm CCing to the Fieldtrip list to perhaps get some answers. I got exactly the same complaint from someone else last week. Best, Vladimir On Thu, Feb 24, 2011 at 2:48 PM, Holly Rossiter wrote: > Hi Vladimir, > > > > I am trying out using ICA on my data to see what difference it makes to the > eye blinks and whether it is a step worth doing or not. I am using a > fieldtrip script... > > > > D= spm_eeg_load; > > data = D.ftraw(0); > > cfg = []; > > cfg.channel = 'MEG'; > > ic_data = ft_componentanalysis(cfg,data); > > cfg = []; > > cfg.viewmode = 'component'; > > cfg.continuous = 'yes'; > > cfg.layout = 'CTF275.lay'; > > cfg.blocksize = 30; > > cfg.channels = [1:10]; > > ft_databrowser(cfg,ic_data); > > > > But it comes up with an error saying > > > > Error using ==> ft_databrowser at 217 > > no trials to display > > > > I think this may be because I don’t have a trl matrix due to using > spm_eeg_load. Do you know how I can create one of these using spm format > data? Or how else to write the script so that ICA will work? > > > > Kind regards, > > > > Holly From jenwhitman at gmail.com Thu Feb 24 19:07:23 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Thu, 24 Feb 2011 10:07:23 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Great, thanks! I'll start the analysis with your new script today and will let you know how it works out. Jen On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I managed to reproduce your problem. The code was rather buggy and indeed > ft_volumewrite did not behave as it should have. I now fixed it in the code > and it should run fine now. Please find the updated file attached. It will > be available on our ftp-server as of tonight. Please note that I updated the > documentation, and changed the names of some of the options a bit. If you > want to save your data in analyze-format, you should specify cfg.filetype = > 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a > volume to nifti-format, using SPM8. > > Best wishes, > > Jan-Mathijs > > > > > > On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few times now, > experimenting with different settings in the cfgs. Below I'll paste the code > I've been using to write images - first the code that successfully created > spm2 images that produced good results, then the code used for creating > nifti format images from the same data. The comments in this second part are > at this point a bit of a maze of cfg options I've been changing back & > forth. Any insights/suggestions regarding how to set up my cfgs to make this > work would be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this > template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) > 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % > filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) > 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets > specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using > spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has > the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' > there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data to be > processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message from > vers 6 > % cfg.dataformat='nifti'; % added after first error message from vers 6 > % commented out after 2nd error message > from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to > specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I notice that indeed in the documentation section of ft_write_volume there >> is a FIXME behind nifti. Yet, nifti format seems to be supported by >> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >> at all (and ran into problems) or were you held back by the FIXME statement? >> Could you just try it out using a recent fieldtrip function? >> >> Thanks and best wishes >> >> Jan-Mathijs >> >> >> >> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >> >> Hello, >>> >>> While writing beamformed images to spm2 format in a previous version of >>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>> results; networks of brain regions consistent with existing literature. When >>> I try to write images from the same dataset and the same analysis to spm8 >>> format, my results (t-images computed across subjects) end up being single >>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>> data analyses cannot be performed on spm2 images, so I have to find a way of >>> writing to successfully to nifti format. >>> >>> I just noticed that in the comments in the ft_write_volume function, >>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>> the list of supported dataformats. Is there by any chance a patch out there >>> for writing nifti images? >>> >>> Thanks! >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 ekanal at cmu.edu Fri Feb 25 20:10:59 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 14:10:59 -0500 Subject: [FieldTrip] ft_componentbrowser problem Message-ID: Hello - I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: ~~~~ cfg = struct('method','fastica','channel','M*','numcomponent','10'); components = ft_componentanalysis(cfg, data_preprocessed); cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); ft_componentbrowser(cfg,components); ~~~~ I increase the The script fails at the final line with the following error: ~~~~ ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. Error in ==> ft_plot_topo at 92 inside = inside_contour([chanX chanY], mask{1}); Error in ==> ft_componentbrowser>plottopography at 172 ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... Error in ==> ft_componentbrowser at 116 plottopography([], cfg, comp) ~~~~ Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - Elli Kanal -------------------- Eliezer Kanal, Ph.D. Postdoctoral Fellow Center for the Neural Basis of Cognition Carnegie Mellon University 4400 Fifth Ave, Suite 115 Pittsburgh PA 15213 P: 412-268-4115 F: 412-268-5060 From jan.schoffelen at donders.ru.nl Fri Feb 25 20:33:43 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 25 Feb 2011 20:33:43 +0100 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: <9745F187-5622-4F8A-9939-0F4ED3D5B2F0@donders.ru.nl> Dear Elli, Apparently the ft_componentbrowser function cannot find inside_contour.m I know that ft_componentbrowser will soon be replaced by the more generic ft_databrowser, and it could be that in this process some changes have already been made, breaking the componentbrowser. Or perhaps something else is going on... Either way, inside_contour.m is located in fieldtrip/plotting/private, and it cannot be seen by ft_componentbrowser, because this function is located at fieldtrip/. If you copy inside_contour to the directory fieldtrip/private I expect that your problem is solved. Good luck, Jan-Mathijs On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > Hello - > > I have a simple script which seems to be failing on > ft_componentbrowser, and I can't figure out why. The script is as > follows: > > ~~~~ > cfg = struct('method','fastica','channel','M*','numcomponent','10'); > components = ft_componentanalysis(cfg, data_preprocessed); > > cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); > ft_componentbrowser(cfg,components); > ~~~~ > > I increase the The script fails at the final line with the following > error: > > ~~~~ > ??? Undefined function or method 'inside_contour' for input > arguments of type 'double'. > > Error in ==> ft_plot_topo at 92 > inside = inside_contour([chanX chanY], mask{1}); > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), > cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Any ideas as to why this isn't working? I'm pretty stuck at this > point. Thanks - > > Elli Kanal > > > -------------------- > Eliezer Kanal, Ph.D. > Postdoctoral Fellow > Center for the Neural Basis of Cognition > Carnegie Mellon University > 4400 Fifth Ave, Suite 115 > Pittsburgh PA 15213 > P: 412-268-4115 > F: 412-268-5060 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From jan.schoffelen at donders.ru.nl Fri Feb 25 20:38:40 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 25 Feb 2011 20:38:40 +0100 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: Hi Elli, Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? If not, I suggest you download a recent fieldtrip version, and try again. Best wishes, Jan-Mathijs On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > Hello - > > I have a simple script which seems to be failing on > ft_componentbrowser, and I can't figure out why. The script is as > follows: > > ~~~~ > cfg = struct('method','fastica','channel','M*','numcomponent','10'); > components = ft_componentanalysis(cfg, data_preprocessed); > > cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); > ft_componentbrowser(cfg,components); > ~~~~ > > I increase the The script fails at the final line with the following > error: > > ~~~~ > ??? Undefined function or method 'inside_contour' for input > arguments of type 'double'. > > Error in ==> ft_plot_topo at 92 > inside = inside_contour([chanX chanY], mask{1}); > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), > cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Any ideas as to why this isn't working? I'm pretty stuck at this > point. Thanks - > > Elli Kanal > > > -------------------- > Eliezer Kanal, Ph.D. > Postdoctoral Fellow > Center for the Neural Basis of Cognition > Carnegie Mellon University > 4400 Fifth Ave, Suite 115 > Pittsburgh PA 15213 > P: 412-268-4115 > F: 412-268-5060 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From ekanal at cmu.edu Fri Feb 25 20:52:02 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 14:52:02 -0500 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: <7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> Hello Dr Schoffelen - Thanks for the quick reply. I've been periodically updating from the SVN directory, but it appears my local working directory had become messed up. The file is now found. However, it seems to have uncovered another error: ~~~~ >> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay','channel','M*'); >> ft_componentbrowser(cfg,components); reading layout from file neuromag306all.lay ??? Error using ==> rdivide Matrix dimensions must agree. Error in ==> ft_componentbrowser>plottopography at 172 ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... Error in ==> ft_componentbrowser at 116 plottopography([], cfg, comp) ~~~~ Once again, any ideas? Thanks - Elli On Feb 25, 2011, at 2:38 PM, jan-mathijs schoffelen wrote: > Hi Elli, > > Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? > If not, I suggest you download a recent fieldtrip version, and try again. > > Best wishes, > > Jan-Mathijs > > On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > >> Hello - >> >> I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: >> >> ~~~~ >> cfg = struct('method','fastica','channel','M*','numcomponent','10'); >> components = ft_componentanalysis(cfg, data_preprocessed); >> >> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); >> ft_componentbrowser(cfg,components); >> ~~~~ >> >> I increase the The script fails at the final line with the following error: >> >> ~~~~ >> ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. >> >> Error in ==> ft_plot_topo at 92 >> inside = inside_contour([chanX chanY], mask{1}); >> >> Error in ==> ft_componentbrowser>plottopography at 172 >> ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... >> >> Error in ==> ft_componentbrowser at 116 >> plottopography([], cfg, comp) >> ~~~~ >> >> Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - >> >> Elli Kanal >> >> >> -------------------- >> Eliezer Kanal, Ph.D. >> Postdoctoral Fellow >> Center for the Neural Basis of Cognition >> Carnegie Mellon University >> 4400 Fifth Ave, Suite 115 >> Pittsburgh PA 15213 >> P: 412-268-4115 >> F: 412-268-5060 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jenwhitman at gmail.com Fri Feb 25 21:44:55 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Fri, 25 Feb 2011 12:44:55 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Hi Jan, I tried re-running the analysis with the new script you sent me, and the latest version of fieldtrip (since I needed ft_get_opt as well), but the spm8 images being written are still producing flawed results. It's the same problem as I mentioned briefly in my previous post. I am not getting any error messages when writing these images. Rather, my problem is that the spm8 and spm2 results from the same data ought to be identical when viewed in mricron, but they're far from it. When I use mricron to look at the results from the spm8-format images, combined across participants to create a t-image, I just get a single 'blob' spanning roughly half the brain. In contrast, when I used spm2-format previously on the same data, the t-image was much more meaningful; a posterior alpha power decrease in a set of regions corresponding to the 'task-positive network' (a network found in the results of an fMRI version of my experiment, and widely reported in the fMRI literature). This failure to replicate the spm2 results when using spm8 images from the same data leads me to suspect that something is wrong with the coordinates for spm8 format. However, after experimenting extensively with different cfg options I still haven't identified the problem. If I my structural MRIs have been saved to .mri files using CTF's MRIConverter program, which cfg options, particularly for coordinates, template images, and filetypes, should I specify before calling the ft_volumesegment, ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite functions? Or should I be calling a different set of functions now? Thanks again for your help, Jen On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: > Great, thanks! > > I'll start the analysis with your new script today and will let you know > how it works out. > > Jen > > On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I managed to reproduce your problem. The code was rather buggy and indeed >> ft_volumewrite did not behave as it should have. I now fixed it in the code >> and it should run fine now. Please find the updated file attached. It will >> be available on our ftp-server as of tonight. Please note that I updated the >> documentation, and changed the names of some of the options a bit. If you >> want to save your data in analyze-format, you should specify cfg.filetype = >> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a >> volume to nifti-format, using SPM8. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> >> >> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >> >> >> Dear Jan, >> >> Thanks for the quick reply. Yes, I have tried it out quite a few times >> now, experimenting with different settings in the cfgs. Below I'll paste the >> code I've been using to write images - first the code that successfully >> created spm2 images that produced good results, then the code used for >> creating nifti format images from the same data. The comments in this second >> part are at this point a bit of a maze of cfg options I've been changing >> back & forth. Any insights/suggestions regarding how to set up my cfgs to >> make this work would be greatly appreciated. >> >> Jen >> >> >> %%%%%%%% this code generated spm2-compatible images which did work >> (producing results that made sense). >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >> sourcePre.avg.pow; >> >> cfg = []; >> cfg.downsample = 2; >> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >> >> % projecting the plot onto a surface... >> cfg = []; >> cfg.coordinates = 'ctf'; >> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this >> template is in MNI coordinates >> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >> 'HzWin' int2str(win) 'width750ms']; >> cfg=[]; >> cfg.parameter = 'avg.pow'; % string, describing the functional >> data to be processed, e.g. 'pow', 'coh' or 'nai' >> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % >> filename without the extension >> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >> (default = []) >> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >> 'int16', 'int32', 'float' or 'double' >> >> volumewrite(cfg, sourcetempIntN) >> >> >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%% this code below hasn't worked yet... >> >> % I added cfg.spmversion = 'spm8'; >> % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, >> % and in the call to prepare_singleshell after calling volumesegment >> >> % I've also ensured that spm8 is the only spm version in my path, even in >> % the fieldtrip/external folder, and ensured that spm8 is installed >> properly >> % (files compiled correctly, etc..) >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >> sourcePre.avg.pow; >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >> >> cfg = []; >> % cfg.coordinates = 'spm'; % changed for version 5 >> % cfg.spmversion = 'spm8'; % changed for version 5 >> cfg.downsample = 4; >> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >> >> >> % projecting the plot onto a surface... >> cfg = []; >> %cfg.coordinates = 'spm'; % changed for version 5 >> %cfg.coordinates = 'ctf'; % changed for version 5 >> cfg.coordinates = 'spm'; % changed back to spm for version 9 >> cfg.downsample = 4; >> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >> specified in volumewrite) >> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using >> spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has >> the desired voxel size >> % cfg.name = [filename]; % changed for version 6 >> %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' >> there was no subsequent call to volumewrite) >> cfg.write= 'no'; % changed for version 6 >> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >> >> % this whole cfg and function call added for version 6 >> cfg=[]; >> % cfg.parameter = string, describing the functional data to be >> processed, e.g. 'pow', 'coh' or 'nai' >> % cfg.filename = filename without the extension >> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use >> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >> []) >> cfg.parameter='pow'; >> cfg.filename=filename; >> cfg.filetype = 'spm'; >> cfg.spmversion = 'SPM8'; % capitalized after first error message from >> vers 6 >> % cfg.dataformat='nifti'; % added after first error message from vers 6 >> % commented out after 2nd error message >> from vers 6 >> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >> specify unless cfg.filetyp='vmp' >> cfg.coordinates='spm'; >> ft_volumewrite(cfg,sourcetempIntN); >> >> >> >> >> >> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl> wrote: >> >>> Dear Jen, >>> >>> I notice that indeed in the documentation section of ft_write_volume >>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>> at all (and ran into problems) or were you held back by the FIXME statement? >>> Could you just try it out using a recent fieldtrip function? >>> >>> Thanks and best wishes >>> >>> Jan-Mathijs >>> >>> >>> >>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>> >>> Hello, >>>> >>>> While writing beamformed images to spm2 format in a previous version of >>>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>>> results; networks of brain regions consistent with existing literature. When >>>> I try to write images from the same dataset and the same analysis to spm8 >>>> format, my results (t-images computed across subjects) end up being single >>>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>>> data analyses cannot be performed on spm2 images, so I have to find a way of >>>> writing to successfully to nifti format. >>>> >>>> I just noticed that in the comments in the ft_write_volume function, >>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>> the list of supported dataformats. Is there by any chance a patch out there >>>> for writing nifti images? >>>> >>>> Thanks! >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> _______________________________________________ >>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 ekanal at cmu.edu Fri Feb 25 22:32:12 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 16:32:12 -0500 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: <7030_1298663591_p1PJr8OZ010844_7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> References: <7030_1298663591_p1PJr8OZ010844_7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> Message-ID: Never mind, the problem was my specifying the 'comp' item as a string (with single quotes'1:10') instead of a vector. Thanks for your help - Elli On Feb 25, 2011, at 2:52 PM, Kanal Eliezer wrote: > Hello Dr Schoffelen - > > Thanks for the quick reply. I've been periodically updating from the SVN directory, but it appears my local working directory had become messed up. The file is now found. > > However, it seems to have uncovered another error: > > ~~~~ >>> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay','channel','M*'); >>> ft_componentbrowser(cfg,components); > reading layout from file neuromag306all.lay > ??? Error using ==> rdivide > Matrix dimensions must agree. > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Once again, any ideas? Thanks - > > Elli > > > On Feb 25, 2011, at 2:38 PM, jan-mathijs schoffelen wrote: > >> Hi Elli, >> >> Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? >> If not, I suggest you download a recent fieldtrip version, and try again. >> >> Best wishes, >> >> Jan-Mathijs >> >> On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: >> >>> Hello - >>> >>> I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: >>> >>> ~~~~ >>> cfg = struct('method','fastica','channel','M*','numcomponent','10'); >>> components = ft_componentanalysis(cfg, data_preprocessed); >>> >>> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); >>> ft_componentbrowser(cfg,components); >>> ~~~~ >>> >>> I increase the The script fails at the final line with the following error: >>> >>> ~~~~ >>> ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. >>> >>> Error in ==> ft_plot_topo at 92 >>> inside = inside_contour([chanX chanY], mask{1}); >>> >>> Error in ==> ft_componentbrowser>plottopography at 172 >>> ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... >>> >>> Error in ==> ft_componentbrowser at 116 >>> plottopography([], cfg, comp) >>> ~~~~ >>> >>> Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - >>> >>> Elli Kanal >>> >>> >>> -------------------- >>> Eliezer Kanal, Ph.D. >>> Postdoctoral Fellow >>> Center for the Neural Basis of Cognition >>> Carnegie Mellon University >>> 4400 Fifth Ave, Suite 115 >>> Pittsburgh PA 15213 >>> P: 412-268-4115 >>> F: 412-268-5060 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 r.oostenveld at donders.ru.nl Sat Feb 26 10:15:35 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Sat, 26 Feb 2011 10:15:35 +0100 Subject: [FieldTrip] ICA In-Reply-To: References: <1625468855117010300@unknownmsgid> Message-ID: <2D910383-6EC3-4467-9946-C4321614591A@donders.ru.nl> Hi Holly The ft_databrowser function was initially written for identifying segments (artifacts, sleep spindles and spike-wave discharges) from continuous data. We wanted those segments to be marked relative to the original data file, i.e. the segments shoudl be marked by their begin- and end-sample. Over time, we started using the function for more and more stuff, but there are still some "relicts" in the code that rely on the sample indexing. We are working on improving the function. To keep you posted on the improvements, I have added you and Vladimir to the respective "bugs" in our bugzilla system. Through bugzilla you will receive an email when the issues are resolved so you know when to download an improved version that will work for you. best regards Robert On 24 Feb 2011, at 17:06, Vladimir Litvak wrote: > Hi Holly, > > I'm not sure why the databrowser needs the trl struct or whether we > can add something to our exported FT struct to make it happy. I'm > CCing to the Fieldtrip list to perhaps get some answers. I got exactly > the same complaint from someone else last week. > > > Best, > > Vladimir > > > On Thu, Feb 24, 2011 at 2:48 PM, Holly Rossiter > wrote: >> Hi Vladimir, >> >> >> >> I am trying out using ICA on my data to see what difference it makes to the >> eye blinks and whether it is a step worth doing or not. I am using a >> fieldtrip script... >> >> >> >> D= spm_eeg_load; >> >> data = D.ftraw(0); >> >> cfg = []; >> >> cfg.channel = 'MEG'; >> >> ic_data = ft_componentanalysis(cfg,data); >> >> cfg = []; >> >> cfg.viewmode = 'component'; >> >> cfg.continuous = 'yes'; >> >> cfg.layout = 'CTF275.lay'; >> >> cfg.blocksize = 30; >> >> cfg.channels = [1:10]; >> >> ft_databrowser(cfg,ic_data); >> >> >> >> But it comes up with an error saying >> >> >> >> Error using ==> ft_databrowser at 217 >> >> no trials to display >> >> >> >> I think this may be because I don’t have a trl matrix due to using >> spm_eeg_load. Do you know how I can create one of these using spm format >> data? Or how else to write the script so that ICA will work? >> >> >> >> Kind regards, >> >> >> >> Holly > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Sat Feb 26 14:26:40 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Sat, 26 Feb 2011 14:26:40 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Dear Jen, I do not manage to reproduce your issue, when only focussing on the ft_volumewrite and visualization part of your pipeline. See attached script, and yet an updated version of ft_volumewrite which you need to (hopefully) draw the same conclusion as I did. Yet, I only now realize that your question may pertain to the entire pipeline. It could be that something is going wrong there. I only see now that in the part of your script of which you reported that it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling ft_volumenormalise. I assume this is correct, because the coordinate system your source-reconstructed data lives in, is according to the CTF-convention, and not according to the SPM- convention. On the other hand, the template for the spatial normalization lives in the SPM-coordinate system. In order for the spatial normalization to work OK, Fieldtrip tries to convert from one coordinate system to the other (once again, this is appropriate behaviour), before doing the actual normalization. It seems that at least in the script you sent along, in the final (not working version), you specified cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is probably wrong. Another important point that should be mentioned, is that the coordinate systems in which the functional data and the anatomical data live should be the same for the ft_sourceinterpolate to make sense. In other words, if your source reconstructed images are defined on a 3D grid of positions in CTF-space, the mri.transform of your anatomy should describe a transformation from voxel to CTF-space. I think you may want to revisit step by step this part of the pipeline; I don't think the problem lies in the writing. A final possibility of course is that Mricron is misbehaving... Best, Jan-Mathijs On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > Hi Jan, > > I tried re-running the analysis with the new script you sent me, and > the latest version of fieldtrip (since I needed ft_get_opt as well), > but the spm8 images being written are still producing flawed > results. It's the same problem as I mentioned briefly in my previous > post. I am not getting any error messages when writing these images. > Rather, my problem is that the spm8 and spm2 results from the same > data ought to be identical when viewed in mricron, but they're far > from it. When I use mricron to look at the results from the spm8- > format images, combined across participants to create a t-image, I > just get a single 'blob' spanning roughly half the brain. In > contrast, when I used spm2-format previously on the same data, the t- > image was much more meaningful; a posterior alpha power decrease in > a set of regions corresponding to the 'task-positive network' (a > network found in the results of an fMRI version of my experiment, > and widely reported in the fMRI literature). > > This failure to replicate the spm2 results when using spm8 images > from the same data leads me to suspect that something is wrong with > the coordinates for spm8 format. However, after experimenting > extensively with different cfg options I still haven't identified > the problem. If I my structural MRIs have been saved to .mri files > using CTF's MRIConverter program, which cfg options, particularly > for coordinates, template images, and filetypes, should I specify > before calling the ft_volumesegment, ft_prepare_singleshell, > ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite > functions? Or should I be calling a different set of functions now? > > Thanks again for your help, > > Jen > > On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman > wrote: > Great, thanks! > > I'll start the analysis with your new script today and will let you > know how it works out. > > Jen > > On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I managed to reproduce your problem. The code was rather buggy and > indeed ft_volumewrite did not behave as it should have. I now fixed > it in the code and it should run fine now. Please find the updated > file attached. It will be available on our ftp-server as of tonight. > Please note that I updated the documentation, and changed the names > of some of the options a bit. If you want to save your data in > analyze-format, you should specify cfg.filetype = 'analyze_spm'. If > you specify cfg.filetype = 'nifti', it should write out a volume to > nifti-format, using SPM8. > > Best wishes, > > Jan-Mathijs > > > > > > On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > >> >> Dear Jan, >> >> Thanks for the quick reply. Yes, I have tried it out quite a few >> times now, experimenting with different settings in the cfgs. Below >> I'll paste the code I've been using to write images - first the >> code that successfully created spm2 images that produced good >> results, then the code used for creating nifti format images from >> the same data. The comments in this second part are at this point a >> bit of a maze of cfg options I've been changing back & forth. Any >> insights/suggestions regarding how to set up my cfgs to make this >> work would be greatly appreciated. >> >> Jen >> >> >> %%%%%%%% this code generated spm2-compatible images which did work >> (producing results that made sense). >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - >> sourcePre.avg.pow) ./ sourcePre.avg.pow; >> >> cfg = []; >> cfg.downsample = 2; >> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >> >> % projecting the plot onto a surface... >> cfg = []; >> cfg.coordinates = 'ctf'; >> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; >> %this template is in MNI coordinates >> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >> int2str(f) 'HzWin' int2str(win) 'width750ms']; >> cfg=[]; >> cfg.parameter = 'avg.pow'; % string, describing the >> functional data to be processed, e.g. 'pow', 'coh' or 'nai' >> cfg.filename = [filename '.img']; >> %'testimageoutput_alphafreq'; % filename without the extension >> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for >> interactive (default = []) >> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >> 'int16', 'int32', 'float' or 'double' >> >> volumewrite(cfg, sourcetempIntN) >> >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%% this code below hasn't worked yet... >> >> % I added cfg.spmversion = 'spm8'; >> % in the cfgs for the calls to ft_prepare_leadfield and >> ft_sourceanalysis, >> % and in the call to prepare_singleshell after calling volumesegment >> >> % I've also ensured that spm8 is the only spm version in my path, >> even in >> % the fieldtrip/external folder, and ensured that spm8 is installed >> properly >> % (files compiled correctly, etc..) >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - >> sourcePre.avg.pow) ./ sourcePre.avg.pow; >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >> int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >> >> cfg = []; >> % cfg.coordinates = 'spm'; % changed for version 5 >> % cfg.spmversion = 'spm8'; % changed for version 5 >> cfg.downsample = 4; >> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >> >> >> % projecting the plot onto a surface... >> cfg = []; >> %cfg.coordinates = 'spm'; % changed for version 5 >> %cfg.coordinates = 'ctf'; % changed for version 5 >> cfg.coordinates = 'spm'; % changed back to spm for version 9 >> cfg.downsample = 4; >> %cfg.spmversion = 'spm8'; % changed for version 6 (because this >> gets specified in volumewrite) >> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent >> to using spm8/templates/EPI.nii, except that mask.nii (produced >> from fmri data) has the desired voxel size >> % cfg.name = [filename]; % changed for version 6 >> %cfg.write= 'yes'; % changed for version 6 (when this was set >> to 'yes' there was no subsequent call to volumewrite) >> cfg.write= 'no'; % changed for version 6 >> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >> >> % this whole cfg and function call added for version 6 >> cfg=[]; >> % cfg.parameter = string, describing the functional data >> to be processed, e.g. 'pow', 'coh' or 'nai' >> % cfg.filename = filename without the extension >> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format >> to use >> % cfg.coordinates = 'spm, 'ctf' or empty for interactive >> (default = []) >> cfg.parameter='pow'; >> cfg.filename=filename; >> cfg.filetype = 'spm'; >> cfg.spmversion = 'SPM8'; % capitalized after first error >> message from vers 6 >> % cfg.dataformat='nifti'; % added after first error message from >> vers 6 >> % commented out after 2nd error >> message from vers 6 >> %cfg.vmpversion=2; % this is a filetype, like spm, so don't >> need to specify unless cfg.filetyp='vmp' >> cfg.coordinates='spm'; >> ft_volumewrite(cfg,sourcetempIntN); >> >> >> >> >> >> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > > wrote: >> Dear Jen, >> >> I notice that indeed in the documentation section of >> ft_write_volume there is a FIXME behind nifti. Yet, nifti format >> seems to be supported by ft_write_volume (at least in a recent >> version of fieldtrip). Did you try it at all (and ran into >> problems) or were you held back by the FIXME statement? Could you >> just try it out using a recent fieldtrip function? >> >> Thanks and best wishes >> >> Jan-Mathijs >> >> >> >> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >> >> Hello, >> >> While writing beamformed images to spm2 format in a previous >> version of fieldtrip (now lost due to a computer crash), I was able >> to get nice-looking results; networks of brain regions consistent >> with existing literature. When I try to write images from the same >> dataset and the same analysis to spm8 format, my results (t-images >> computed across subjects) end up being single clusters spanning >> large sections of the brain (e.g. a 'blob' spanning all of one >> hemisphere but not the other). Unfortunately, some aspects of my >> planned data analyses cannot be performed on spm2 images, so I have >> to find a way of writing to successfully to nifti format. >> >> I just noticed that in the comments in the ft_write_volume >> function, which I am calling via ft_volumewrite, it says 'FIXME' >> next to nifti under the list of supported dataformats. Is there by >> any chance a patch out there for writing nifti images? >> >> Thanks! >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_ft_write_volume.m Type: application/octet-stream Size: 1338 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ft_volumewrite.m Type: application/octet-stream Size: 17470 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Mon Feb 28 20:59:28 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Mon, 28 Feb 2011 11:59:28 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Hello Jan, When calling volumesegment, I specified 'ctf' as the coordinate system. The function I wrote to call volumesegment and prepare_singleshell for each subject and save the results is pasted below, with a couple of comments added for clarity. Over the weekend I tried specifying the coordinate system in the call to ft_volumenormalise as 'ctf' rather than 'spm', and commented out all the lines that said cfg.spmversion = 'spm8'; before calling a function. However, that created worse results, as each plot involved stripes of activation and empty voxels, suggesting that 'ctf' was not the correct coordinate system to specify. Thanks for the attached script. Looking in that the comments in that, I suspect that the solution to my problems will be to specify my filetype as nifti_img rather than nifti. I'll let you know how that goes. Jen ------------------------------------------------------------------------------------------------------------ % the variable subj is simply a string consisting of a subject number (e.g. 's05') which can be a folder name or part of a filename function [vol mri segmentedmri segmentedmriF]=call_volume_segment_function_spm8(subj) cfg.spmversion = 'spm8'; cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; cfg.name=[subj '_volseg']; cfg.write='yes'; cfg.smooth='no'; cfg.coordinates='ctf'; mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF mriConverter and mriViewer software, after fiducials were marked segmentedmri = volumesegment(cfg, mri); segmentedmriF = segmentedmri; segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3),2),1); segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3),2),1); segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3),2),1); segmentedmriF.transform = mri.transform; segmentedmriF.anatomy = mri.anatomy; cfg = []; cfg.spmversion = 'spm8'; vol = prepare_singleshell(cfg, segmentedmriF); eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri segmentedmriF vol']) On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I do not manage to reproduce your issue, when only focussing on the > ft_volumewrite and visualization part of your pipeline. See attached script, > and yet an updated version of ft_volumewrite which you need to (hopefully) > draw the same conclusion as I did. > Yet, I only now realize that your question may pertain to the entire > pipeline. It could be that something is going wrong there. > I only see now that in the part of your script of which you reported that > it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling > ft_volumenormalise. I assume this is correct, because the coordinate system > your source-reconstructed data lives in, is according to the CTF-convention, > and not according to the SPM-convention. On the other hand, the template for > the spatial normalization lives in the SPM-coordinate system. In order for > the spatial normalization to work OK, Fieldtrip tries to convert from one > coordinate system to the other (once again, this is appropriate behaviour), > before doing the actual normalization. It seems that at least in the script > you sent along, in the final (not working version), you specified > cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is > probably wrong. > Another important point that should be mentioned, is that the coordinate > systems in which the functional data and the anatomical data live should be > the same for the ft_sourceinterpolate to make sense. In other words, if your > source reconstructed images are defined on a 3D grid of positions in > CTF-space, the mri.transform of your anatomy should describe a > transformation from voxel to CTF-space. > I think you may want to revisit step by step this part of the pipeline; I > don't think the problem lies in the writing. > A final possibility of course is that Mricron is misbehaving... > > Best, > > Jan-Mathijs > > > > > > > On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > > Hi Jan, > > I tried re-running the analysis with the new script you sent me, and the > latest version of fieldtrip (since I needed ft_get_opt as well), but the > spm8 images being written are still producing flawed results. It's the same > problem as I mentioned briefly in my previous post. I am not getting any > error messages when writing these images. Rather, my problem is that the > spm8 and spm2 results from the same data ought to be identical when viewed > in mricron, but they're far from it. When I use mricron to look at the > results from the spm8-format images, combined across participants to create > a t-image, I just get a single 'blob' spanning roughly half the brain. In > contrast, when I used spm2-format previously on the same data, the t-image > was much more meaningful; a posterior alpha power decrease in a set of > regions corresponding to the 'task-positive network' (a network found in the > results of an fMRI version of my experiment, and widely reported in the fMRI > literature). > > This failure to replicate the spm2 results when using spm8 images from the > same data leads me to suspect that something is wrong with the coordinates > for spm8 format. However, after experimenting extensively with different cfg > options I still haven't identified the problem. If I my structural MRIs have > been saved to .mri files using CTF's MRIConverter program, which cfg > options, particularly for coordinates, template images, and filetypes, > should I specify before calling the ft_volumesegment, > ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and > ft_volumewrite functions? Or should I be calling a different set of > functions now? > > Thanks again for your help, > > Jen > > On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: > >> Great, thanks! >> >> I'll start the analysis with your new script today and will let you know >> how it works out. >> >> Jen >> >> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl> wrote: >> >>> Dear Jen, >>> >>> I managed to reproduce your problem. The code was rather buggy and indeed >>> ft_volumewrite did not behave as it should have. I now fixed it in the code >>> and it should run fine now. Please find the updated file attached. It will >>> be available on our ftp-server as of tonight. Please note that I updated the >>> documentation, and changed the names of some of the options a bit. If you >>> want to save your data in analyze-format, you should specify cfg.filetype = >>> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a >>> volume to nifti-format, using SPM8. >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> >>> >>> >>> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >>> >>> >>> Dear Jan, >>> >>> Thanks for the quick reply. Yes, I have tried it out quite a few times >>> now, experimenting with different settings in the cfgs. Below I'll paste the >>> code I've been using to write images - first the code that successfully >>> created spm2 images that produced good results, then the code used for >>> creating nifti format images from the same data. The comments in this second >>> part are at this point a bit of a maze of cfg options I've been changing >>> back & forth. Any insights/suggestions regarding how to set up my cfgs to >>> make this work would be greatly appreciated. >>> >>> Jen >>> >>> >>> %%%%%%%% this code generated spm2-compatible images which did work >>> (producing results that made sense). >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>> sourcePre.avg.pow; >>> >>> cfg = []; >>> cfg.downsample = 2; >>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> cfg.coordinates = 'ctf'; >>> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this >>> template is in MNI coordinates >>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>> 'HzWin' int2str(win) 'width750ms']; >>> cfg=[]; >>> cfg.parameter = 'avg.pow'; % string, describing the functional >>> data to be processed, e.g. 'pow', 'coh' or 'nai' >>> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; >>> % filename without the extension >>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >>> (default = []) >>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >>> 'int16', 'int32', 'float' or 'double' >>> >>> volumewrite(cfg, sourcetempIntN) >>> >>> >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%% this code below hasn't worked yet... >>> >>> % I added cfg.spmversion = 'spm8'; >>> % in the cfgs for the calls to ft_prepare_leadfield and >>> ft_sourceanalysis, >>> % and in the call to prepare_singleshell after calling volumesegment >>> >>> % I've also ensured that spm8 is the only spm version in my path, even in >>> % the fieldtrip/external folder, and ensured that spm8 is installed >>> properly >>> % (files compiled correctly, etc..) >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>> sourcePre.avg.pow; >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>> >>> cfg = []; >>> % cfg.coordinates = 'spm'; % changed for version 5 >>> % cfg.spmversion = 'spm8'; % changed for version 5 >>> cfg.downsample = 4; >>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>> >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> %cfg.coordinates = 'spm'; % changed for version 5 >>> %cfg.coordinates = 'ctf'; % changed for version 5 >>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>> cfg.downsample = 4; >>> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >>> specified in volumewrite) >>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to >>> using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) >>> has the desired voxel size >>> % cfg.name = [filename]; % changed for version 6 >>> %cfg.write= 'yes'; % changed for version 6 (when this was set to >>> 'yes' there was no subsequent call to volumewrite) >>> cfg.write= 'no'; % changed for version 6 >>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>> >>> % this whole cfg and function call added for version 6 >>> cfg=[]; >>> % cfg.parameter = string, describing the functional data to be >>> processed, e.g. 'pow', 'coh' or 'nai' >>> % cfg.filename = filename without the extension >>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use >>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >>> []) >>> cfg.parameter='pow'; >>> cfg.filename=filename; >>> cfg.filetype = 'spm'; >>> cfg.spmversion = 'SPM8'; % capitalized after first error message from >>> vers 6 >>> % cfg.dataformat='nifti'; % added after first error message from vers >>> 6 >>> % commented out after 2nd error message >>> from vers 6 >>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >>> specify unless cfg.filetyp='vmp' >>> cfg.coordinates='spm'; >>> ft_volumewrite(cfg,sourcetempIntN); >>> >>> >>> >>> >>> >>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >>> jan.schoffelen at donders.ru.nl> wrote: >>> >>>> Dear Jen, >>>> >>>> I notice that indeed in the documentation section of ft_write_volume >>>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>>> at all (and ran into problems) or were you held back by the FIXME statement? >>>> Could you just try it out using a recent fieldtrip function? >>>> >>>> Thanks and best wishes >>>> >>>> Jan-Mathijs >>>> >>>> >>>> >>>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>>> >>>> Hello, >>>>> >>>>> While writing beamformed images to spm2 format in a previous version of >>>>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>>>> results; networks of brain regions consistent with existing literature. When >>>>> I try to write images from the same dataset and the same analysis to spm8 >>>>> format, my results (t-images computed across subjects) end up being single >>>>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>>>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>>>> data analyses cannot be performed on spm2 images, so I have to find a way of >>>>> writing to successfully to nifti format. >>>>> >>>>> I just noticed that in the comments in the ft_write_volume function, >>>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>>> the list of supported dataformats. Is there by any chance a patch out there >>>>> for writing nifti images? >>>>> >>>>> Thanks! >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>> Donders Institute for Brain, Cognition and Behaviour, >>>> Centre for Cognitive Neuroimaging, >>>> Radboud University Nijmegen, The Netherlands >>>> J.Schoffelen at donders.ru.nl >>>> Telephone: 0031-24-3614793 >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Mon Feb 28 21:36:17 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Mon, 28 Feb 2011 21:36:17 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: <7F6275BA-C597-4E11-958C-9E944F27F6C4@donders.ru.nl> Hi Jen, At first glance I have a comment on your script. You may need to explicitly check the alignment of your segmented volume and the original anatomy. A while a go some changes were made to ft_volumesegment, taking away the need to do the flipdim(flipdim... operations. I have posted this on the discussion list last January, but you may not have noticed. Anyway, if you now have used a recent version of FieldTrip for your segmentation both the location of your dipole grid, and the volume conductor model will not be adequately coregistered with the data, which may lead to funky results to begin with. That's most likely not related to the filetype in which the volumes are saved for later use. Best wishes, Jan-Mathijs On Feb 28, 2011, at 8:59 PM, Jen Whitman wrote: > Hello Jan, > > When calling volumesegment, I specified 'ctf' as the coordinate > system. The function I wrote to call volumesegment and > prepare_singleshell for each subject and save the results is pasted > below, with a couple of comments added for clarity. > Over the weekend I tried specifying the coordinate system in the > call to ft_volumenormalise as 'ctf' rather than 'spm', and commented > out all the lines that said cfg.spmversion = 'spm8'; before calling > a function. However, that created worse results, as each plot > involved stripes of activation and empty voxels, suggesting that > 'ctf' was not the correct coordinate system to specify. > > Thanks for the attached script. Looking in that the comments in > that, I suspect that the solution to my problems will be to specify > my filetype as nifti_img rather than nifti. I'll let you know how > that goes. > > Jen > > ------------------------------------------------------------------------------------------------------------ > % the variable subj is simply a string consisting of a subject > number (e.g. 's05') which can be a folder name or part of a filename > function [vol mri segmentedmri > segmentedmriF]=call_volume_segment_function_spm8(subj) > cfg.spmversion = 'spm8'; > cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; > %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; > cfg.name=[subj '_volseg']; > cfg.write='yes'; > cfg.smooth='no'; > cfg.coordinates='ctf'; > mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF > mriConverter and mriViewer software, after fiducials were marked > segmentedmri = volumesegment(cfg, mri); > segmentedmriF = segmentedmri; > segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3), > 2),1); > segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3), > 2),1); > segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3), > 2),1); > segmentedmriF.transform = mri.transform; > segmentedmriF.anatomy = mri.anatomy; > cfg = []; > cfg.spmversion = 'spm8'; > vol = prepare_singleshell(cfg, segmentedmriF); > eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri > segmentedmriF vol']) > > > > On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I do not manage to reproduce your issue, when only focussing on the > ft_volumewrite and visualization part of your pipeline. See attached > script, and yet an updated version of ft_volumewrite which you need > to (hopefully) draw the same conclusion as I did. > Yet, I only now realize that your question may pertain to the entire > pipeline. It could be that something is going wrong there. > I only see now that in the part of your script of which you reported > that it gave 'good' results, you specify cfg.coordinates = 'ctf' > before calling ft_volumenormalise. I assume this is correct, because > the coordinate system your source-reconstructed data lives in, is > according to the CTF-convention, and not according to the SPM- > convention. On the other hand, the template for the spatial > normalization lives in the SPM-coordinate system. In order for the > spatial normalization to work OK, Fieldtrip tries to convert from > one coordinate system to the other (once again, this is appropriate > behaviour), before doing the actual normalization. It seems that at > least in the script you sent along, in the final (not working > version), you specified cfg.coordinates = 'spm' prior to calling > ft_volumenormalise. This is probably wrong. > Another important point that should be mentioned, is that the > coordinate systems in which the functional data and the anatomical > data live should be the same for the ft_sourceinterpolate to make > sense. In other words, if your source reconstructed images are > defined on a 3D grid of positions in CTF-space, the mri.transform of > your anatomy should describe a transformation from voxel to CTF-space. > I think you may want to revisit step by step this part of the > pipeline; I don't think the problem lies in the writing. > A final possibility of course is that Mricron is misbehaving... > > Best, > > Jan-Mathijs > > > > > > > On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > >> Hi Jan, >> >> I tried re-running the analysis with the new script you sent me, >> and the latest version of fieldtrip (since I needed ft_get_opt as >> well), but the spm8 images being written are still producing flawed >> results. It's the same problem as I mentioned briefly in my >> previous post. I am not getting any error messages when writing >> these images. Rather, my problem is that the spm8 and spm2 results >> from the same data ought to be identical when viewed in mricron, >> but they're far from it. When I use mricron to look at the results >> from the spm8-format images, combined across participants to create >> a t-image, I just get a single 'blob' spanning roughly half the >> brain. In contrast, when I used spm2-format previously on the same >> data, the t-image was much more meaningful; a posterior alpha power >> decrease in a set of regions corresponding to the 'task-positive >> network' (a network found in the results of an fMRI version of my >> experiment, and widely reported in the fMRI literature). >> >> This failure to replicate the spm2 results when using spm8 images >> from the same data leads me to suspect that something is wrong with >> the coordinates for spm8 format. However, after experimenting >> extensively with different cfg options I still haven't identified >> the problem. If I my structural MRIs have been saved to .mri files >> using CTF's MRIConverter program, which cfg options, particularly >> for coordinates, template images, and filetypes, should I specify >> before calling the ft_volumesegment, ft_prepare_singleshell, >> ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite >> functions? Or should I be calling a different set of functions now? >> >> Thanks again for your help, >> >> Jen >> >> On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman >> wrote: >> Great, thanks! >> >> I'll start the analysis with your new script today and will let you >> know how it works out. >> >> Jen >> >> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen > > wrote: >> Dear Jen, >> >> I managed to reproduce your problem. The code was rather buggy and >> indeed ft_volumewrite did not behave as it should have. I now fixed >> it in the code and it should run fine now. Please find the updated >> file attached. It will be available on our ftp-server as of >> tonight. Please note that I updated the documentation, and changed >> the names of some of the options a bit. If you want to save your >> data in analyze-format, you should specify cfg.filetype = >> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should >> write out a volume to nifti-format, using SPM8. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> >> >> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >> >>> >>> Dear Jan, >>> >>> Thanks for the quick reply. Yes, I have tried it out quite a few >>> times now, experimenting with different settings in the cfgs. >>> Below I'll paste the code I've been using to write images - first >>> the code that successfully created spm2 images that produced good >>> results, then the code used for creating nifti format images from >>> the same data. The comments in this second part are at this point >>> a bit of a maze of cfg options I've been changing back & forth. >>> Any insights/suggestions regarding how to set up my cfgs to make >>> this work would be greatly appreciated. >>> >>> Jen >>> >>> >>> %%%%%%%% this code generated spm2-compatible images which did work >>> (producing results that made sense). >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - >>> sourcePre.avg.pow) ./ sourcePre.avg.pow; >>> >>> cfg = []; >>> cfg.downsample = 2; >>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> cfg.coordinates = 'ctf'; >>> cfg.template = '/home/common/matlab/spm2/templates/ >>> T1.mnc'; %this template is in MNI coordinates >>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >>> int2str(f) 'HzWin' int2str(win) 'width750ms']; >>> cfg=[]; >>> cfg.parameter = 'avg.pow'; % string, describing the >>> functional data to be processed, e.g. 'pow', 'coh' or 'nai' >>> cfg.filename = [filename '.img']; >>> %'testimageoutput_alphafreq'; % filename without the extension >>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for >>> interactive (default = []) >>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', >>> 'uint8', 'int16', 'int32', 'float' or 'double' >>> >>> volumewrite(cfg, sourcetempIntN) >>> >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%% this code below hasn't worked yet... >>> >>> % I added cfg.spmversion = 'spm8'; >>> % in the cfgs for the calls to ft_prepare_leadfield and >>> ft_sourceanalysis, >>> % and in the call to prepare_singleshell after calling volumesegment >>> >>> % I've also ensured that spm8 is the only spm version in my path, >>> even in >>> % the fieldtrip/external folder, and ensured that spm8 is >>> installed properly >>> % (files compiled correctly, etc..) >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - >>> sourcePre.avg.pow) ./ sourcePre.avg.pow; >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >>> int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>> >>> cfg = []; >>> % cfg.coordinates = 'spm'; % changed for version 5 >>> % cfg.spmversion = 'spm8'; % changed for version 5 >>> cfg.downsample = 4; >>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>> >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> %cfg.coordinates = 'spm'; % changed for version 5 >>> %cfg.coordinates = 'ctf'; % changed for version 5 >>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>> cfg.downsample = 4; >>> %cfg.spmversion = 'spm8'; % changed for version 6 (because >>> this gets specified in volumewrite) >>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent >>> to using spm8/templates/EPI.nii, except that mask.nii (produced >>> from fmri data) has the desired voxel size >>> % cfg.name = [filename]; % changed for version 6 >>> %cfg.write= 'yes'; % changed for version 6 (when this was set >>> to 'yes' there was no subsequent call to volumewrite) >>> cfg.write= 'no'; % changed for version 6 >>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>> >>> % this whole cfg and function call added for version 6 >>> cfg=[]; >>> % cfg.parameter = string, describing the functional data >>> to be processed, e.g. 'pow', 'coh' or 'nai' >>> % cfg.filename = filename without the extension >>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format >>> to use >>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive >>> (default = []) >>> cfg.parameter='pow'; >>> cfg.filename=filename; >>> cfg.filetype = 'spm'; >>> cfg.spmversion = 'SPM8'; % capitalized after first error >>> message from vers 6 >>> % cfg.dataformat='nifti'; % added after first error message >>> from vers 6 >>> % commented out after 2nd error >>> message from vers 6 >>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't >>> need to specify unless cfg.filetyp='vmp' >>> cfg.coordinates='spm'; >>> ft_volumewrite(cfg,sourcetempIntN); >>> >>> >>> >>> >>> >>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen >> > wrote: >>> Dear Jen, >>> >>> I notice that indeed in the documentation section of >>> ft_write_volume there is a FIXME behind nifti. Yet, nifti format >>> seems to be supported by ft_write_volume (at least in a recent >>> version of fieldtrip). Did you try it at all (and ran into >>> problems) or were you held back by the FIXME statement? Could you >>> just try it out using a recent fieldtrip function? >>> >>> Thanks and best wishes >>> >>> Jan-Mathijs >>> >>> >>> >>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>> >>> Hello, >>> >>> While writing beamformed images to spm2 format in a previous >>> version of fieldtrip (now lost due to a computer crash), I was >>> able to get nice-looking results; networks of brain regions >>> consistent with existing literature. When I try to write images >>> from the same dataset and the same analysis to spm8 format, my >>> results (t-images computed across subjects) end up being single >>> clusters spanning large sections of the brain (e.g. a 'blob' >>> spanning all of one hemisphere but not the other). Unfortunately, >>> some aspects of my planned data analyses cannot be performed on >>> spm2 images, so I have to find a way of writing to successfully to >>> nifti format. >>> >>> I just noticed that in the comments in the ft_write_volume >>> function, which I am calling via ft_volumewrite, it says 'FIXME' >>> next to nifti under the list of supported dataformats. Is there by >>> any chance a patch out there for writing nifti images? >>> >>> Thanks! >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> _______________________________________________ >>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Mon Feb 28 22:32:16 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Mon, 28 Feb 2011 13:32:16 -0800 Subject: [FieldTrip] I think you solved the problem Message-ID: I just checked, and when I re-ran my segmentation script with the new Fieldtrip in order to use an spm8 template image, coordinates got reversed. When I take out the calls to flipdim, they look fine (see attached screenshots). That certainly explains the meaningless results I was getting! Thanks for figuring that out, Jen On Mon, Feb 28, 2011 at 12:36 PM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Hi Jen, > > At first glance I have a comment on your script. You may need to explicitly > check the alignment of your segmented volume and the original anatomy. A > while a go some changes were made to ft_volumesegment, taking away the need > to do the flipdim(flipdim... operations. I have posted this on the > discussion list last January, but you may not have noticed. > Anyway, if you now have used a recent version of FieldTrip for your > segmentation both the location of your dipole grid, and the volume conductor > model will not be adequately coregistered with the data, which may lead to > funky results to begin with. That's most likely not related to the filetype > in which the volumes are saved for later use. > > Best wishes, > > Jan-Mathijs > > > > On Feb 28, 2011, at 8:59 PM, Jen Whitman wrote: > > Hello Jan, > > When calling volumesegment, I specified 'ctf' as the coordinate system. The > function I wrote to call volumesegment and prepare_singleshell for each > subject and save the results is pasted below, with a couple of comments > added for clarity. > Over the weekend I tried specifying the coordinate system in the call to > ft_volumenormalise as 'ctf' rather than 'spm', and commented out all the > lines that said cfg.spmversion = 'spm8'; before calling a function. However, > that created worse results, as each plot involved stripes of activation and > empty voxels, suggesting that 'ctf' was not the correct coordinate system to > specify. > > Thanks for the attached script. Looking in that the comments in that, I > suspect that the solution to my problems will be to specify my filetype as > nifti_img rather than nifti. I'll let you know how that goes. > > Jen > > > ------------------------------------------------------------------------------------------------------------ > % the variable subj is simply a string consisting of a subject number (e.g. > 's05') which can be a folder name or part of a filename > function [vol mri segmentedmri > segmentedmriF]=call_volume_segment_function_spm8(subj) > cfg.spmversion = 'spm8'; > cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; > %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; > cfg.name=[subj '_volseg']; > cfg.write='yes'; > cfg.smooth='no'; > cfg.coordinates='ctf'; > mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF mriConverter > and mriViewer software, after fiducials were marked > segmentedmri = volumesegment(cfg, mri); > segmentedmriF = segmentedmri; > segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3),2),1); > segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3),2),1); > segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3),2),1); > segmentedmriF.transform = mri.transform; > segmentedmriF.anatomy = mri.anatomy; > cfg = []; > cfg.spmversion = 'spm8'; > vol = prepare_singleshell(cfg, segmentedmriF); > eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri segmentedmriF > vol']) > > > > On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I do not manage to reproduce your issue, when only focussing on the >> ft_volumewrite and visualization part of your pipeline. See attached script, >> and yet an updated version of ft_volumewrite which you need to (hopefully) >> draw the same conclusion as I did. >> Yet, I only now realize that your question may pertain to the entire >> pipeline. It could be that something is going wrong there. >> I only see now that in the part of your script of which you reported that >> it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling >> ft_volumenormalise. I assume this is correct, because the coordinate system >> your source-reconstructed data lives in, is according to the CTF-convention, >> and not according to the SPM-convention. On the other hand, the template for >> the spatial normalization lives in the SPM-coordinate system. In order for >> the spatial normalization to work OK, Fieldtrip tries to convert from one >> coordinate system to the other (once again, this is appropriate behaviour), >> before doing the actual normalization. It seems that at least in the script >> you sent along, in the final (not working version), you specified >> cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is >> probably wrong. >> Another important point that should be mentioned, is that the coordinate >> systems in which the functional data and the anatomical data live should be >> the same for the ft_sourceinterpolate to make sense. In other words, if your >> source reconstructed images are defined on a 3D grid of positions in >> CTF-space, the mri.transform of your anatomy should describe a >> transformation from voxel to CTF-space. >> I think you may want to revisit step by step this part of the pipeline; I >> don't think the problem lies in the writing. >> A final possibility of course is that Mricron is misbehaving... >> >> Best, >> >> Jan-Mathijs >> >> >> >> >> >> >> On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: >> >> Hi Jan, >> >> I tried re-running the analysis with the new script you sent me, and the >> latest version of fieldtrip (since I needed ft_get_opt as well), but the >> spm8 images being written are still producing flawed results. It's the same >> problem as I mentioned briefly in my previous post. I am not getting any >> error messages when writing these images. Rather, my problem is that the >> spm8 and spm2 results from the same data ought to be identical when viewed >> in mricron, but they're far from it. When I use mricron to look at the >> results from the spm8-format images, combined across participants to create >> a t-image, I just get a single 'blob' spanning roughly half the brain. In >> contrast, when I used spm2-format previously on the same data, the t-image >> was much more meaningful; a posterior alpha power decrease in a set of >> regions corresponding to the 'task-positive network' (a network found in the >> results of an fMRI version of my experiment, and widely reported in the fMRI >> literature). >> >> This failure to replicate the spm2 results when using spm8 images from the >> same data leads me to suspect that something is wrong with the coordinates >> for spm8 format. However, after experimenting extensively with different cfg >> options I still haven't identified the problem. If I my structural MRIs have >> been saved to .mri files using CTF's MRIConverter program, which cfg >> options, particularly for coordinates, template images, and filetypes, >> should I specify before calling the ft_volumesegment, >> ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and >> ft_volumewrite functions? Or should I be calling a different set of >> functions now? >> >> Thanks again for your help, >> >> Jen >> >> On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: >> >>> Great, thanks! >>> >>> I'll start the analysis with your new script today and will let you know >>> how it works out. >>> >>> Jen >>> >>> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < >>> jan.schoffelen at donders.ru.nl> wrote: >>> >>>> Dear Jen, >>>> >>>> I managed to reproduce your problem. The code was rather buggy and >>>> indeed ft_volumewrite did not behave as it should have. I now fixed it in >>>> the code and it should run fine now. Please find the updated file attached. >>>> It will be available on our ftp-server as of tonight. Please note that I >>>> updated the documentation, and changed the names of some of the options a >>>> bit. If you want to save your data in analyze-format, you should specify >>>> cfg.filetype = 'analyze_spm'. If you specify cfg.filetype = 'nifti', it >>>> should write out a volume to nifti-format, using SPM8. >>>> >>>> Best wishes, >>>> >>>> Jan-Mathijs >>>> >>>> >>>> >>>> >>>> >>>> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >>>> >>>> >>>> Dear Jan, >>>> >>>> Thanks for the quick reply. Yes, I have tried it out quite a few times >>>> now, experimenting with different settings in the cfgs. Below I'll paste the >>>> code I've been using to write images - first the code that successfully >>>> created spm2 images that produced good results, then the code used for >>>> creating nifti format images from the same data. The comments in this second >>>> part are at this point a bit of a maze of cfg options I've been changing >>>> back & forth. Any insights/suggestions regarding how to set up my cfgs to >>>> make this work would be greatly appreciated. >>>> >>>> Jen >>>> >>>> >>>> %%%%%%%% this code generated spm2-compatible images which did work >>>> (producing results that made sense). >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>>> sourcePre.avg.pow; >>>> >>>> cfg = []; >>>> cfg.downsample = 2; >>>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>>> >>>> % projecting the plot onto a surface... >>>> cfg = []; >>>> cfg.coordinates = 'ctf'; >>>> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; >>>> %this template is in MNI coordinates >>>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>>> >>>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>>> 'HzWin' int2str(win) 'width750ms']; >>>> cfg=[]; >>>> cfg.parameter = 'avg.pow'; % string, describing the functional >>>> data to be processed, e.g. 'pow', 'coh' or 'nai' >>>> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; >>>> % filename without the extension >>>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >>>> (default = []) >>>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >>>> 'int16', 'int32', 'float' or 'double' >>>> >>>> volumewrite(cfg, sourcetempIntN) >>>> >>>> >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> %%%%% this code below hasn't worked yet... >>>> >>>> % I added cfg.spmversion = 'spm8'; >>>> % in the cfgs for the calls to ft_prepare_leadfield and >>>> ft_sourceanalysis, >>>> % and in the call to prepare_singleshell after calling volumesegment >>>> >>>> % I've also ensured that spm8 is the only spm version in my path, even >>>> in >>>> % the fieldtrip/external folder, and ensured that spm8 is installed >>>> properly >>>> % (files compiled correctly, etc..) >>>> >>>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>>> sourcePre.avg.pow; >>>> >>>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>>> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>>> >>>> cfg = []; >>>> % cfg.coordinates = 'spm'; % changed for version 5 >>>> % cfg.spmversion = 'spm8'; % changed for version 5 >>>> cfg.downsample = 4; >>>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>>> >>>> >>>> % projecting the plot onto a surface... >>>> cfg = []; >>>> %cfg.coordinates = 'spm'; % changed for version 5 >>>> %cfg.coordinates = 'ctf'; % changed for version 5 >>>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>>> cfg.downsample = 4; >>>> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >>>> specified in volumewrite) >>>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to >>>> using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) >>>> has the desired voxel size >>>> % cfg.name = [filename]; % changed for version 6 >>>> %cfg.write= 'yes'; % changed for version 6 (when this was set to >>>> 'yes' there was no subsequent call to volumewrite) >>>> cfg.write= 'no'; % changed for version 6 >>>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>>> >>>> % this whole cfg and function call added for version 6 >>>> cfg=[]; >>>> % cfg.parameter = string, describing the functional data to be >>>> processed, e.g. 'pow', 'coh' or 'nai' >>>> % cfg.filename = filename without the extension >>>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to >>>> use >>>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >>>> []) >>>> cfg.parameter='pow'; >>>> cfg.filename=filename; >>>> cfg.filetype = 'spm'; >>>> cfg.spmversion = 'SPM8'; % capitalized after first error message >>>> from vers 6 >>>> % cfg.dataformat='nifti'; % added after first error message from vers >>>> 6 >>>> % commented out after 2nd error message >>>> from vers 6 >>>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >>>> specify unless cfg.filetyp='vmp' >>>> cfg.coordinates='spm'; >>>> ft_volumewrite(cfg,sourcetempIntN); >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >>>> jan.schoffelen at donders.ru.nl> wrote: >>>> >>>>> Dear Jen, >>>>> >>>>> I notice that indeed in the documentation section of ft_write_volume >>>>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>>>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>>>> at all (and ran into problems) or were you held back by the FIXME statement? >>>>> Could you just try it out using a recent fieldtrip function? >>>>> >>>>> Thanks and best wishes >>>>> >>>>> Jan-Mathijs >>>>> >>>>> >>>>> >>>>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>>>> >>>>> Hello, >>>>>> >>>>>> While writing beamformed images to spm2 format in a previous version >>>>>> of fieldtrip (now lost due to a computer crash), I was able to get >>>>>> nice-looking results; networks of brain regions consistent with existing >>>>>> literature. When I try to write images from the same dataset and the same >>>>>> analysis to spm8 format, my results (t-images computed across subjects) end >>>>>> up being single clusters spanning large sections of the brain (e.g. a 'blob' >>>>>> spanning all of one hemisphere but not the other). Unfortunately, some >>>>>> aspects of my planned data analyses cannot be performed on spm2 images, so I >>>>>> have to find a way of writing to successfully to nifti format. >>>>>> >>>>>> I just noticed that in the comments in the ft_write_volume function, >>>>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>>>> the list of supported dataformats. Is there by any chance a patch out there >>>>>> for writing nifti images? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>> >>>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>>> Donders Institute for Brain, Cognition and Behaviour, >>>>> Centre for Cognitive Neuroimaging, >>>>> Radboud University Nijmegen, The Netherlands >>>>> J.Schoffelen at donders.ru.nl >>>>> Telephone: 0031-24-3614793 >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>> Donders Institute for Brain, Cognition and Behaviour, >>>> Centre for Cognitive Neuroimaging, >>>> Radboud University Nijmegen, The Netherlands >>>> J.Schoffelen at donders.ru.nl >>>> Telephone: 0031-24-3614793 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: volumesegmentspm8.png Type: image/png Size: 141551 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fixedvolumesegmentspm8.png Type: image/png Size: 78944 bytes Desc: not available URL: From lsbarbosa at gmail.com Tue Feb 1 03:05:59 2011 From: lsbarbosa at gmail.com (Leonardo Barbosa) Date: Tue, 1 Feb 2011 00:05:59 -0200 Subject: [FieldTrip] Forward model for dipoles with fixed position and orientation Message-ID: Dear Fieldtrip users, I'm trying to create a forward model for a fixed number of dipoles with fixed positions and orientations (extracted from a MRI image using freesurfer and a downsampling algorithm) so I can use it with my inverse algorithm. I read this tutorial , a few examplesand function headers , but I still didn't find exactly what I'm trying to do. Is it possible to have as a result of *ft_compute_leadfield*, (and*ft_prepare_leadfield *?,* ft_prepare_sourcemodel*?) a leadfield that depends only on the *intensity* of the dipole? Because it has a fixed orientation, and the idea is exactly reduce the number of unknowns. I noticed that SPM creates what I'm trying to do (as copied below), but I'm trying to stay within fieldtrip definitions so I can use it's inverse solutions to compare with mine, although I only found examples for beamformers inverse solutions, and not sparse methods. So this is the second question: is there any example of source-space based sparse methods inverse solutions? Thanks in advance for any help, Best Regards Leonardo Barbosa Here is the SPM code (inside *spm_eeg_lgainmat*) % Forward computation %-------------------------------------------------------------------------- [vol, sens] = forwinv_prepare_vol_sens(vol, sens, 'channel', forward(ind).channels); nvert = size(vert, 1); spm('Pointer', 'Watch');drawnow; spm_progress_bar('Init', nvert, ['Computing ' modality ' leadfields']); drawnow; if nvert > 100, Ibar = floor(linspace(1, nvert,100)); else Ibar = [1:nvert]; end Gxyz = zeros(length(forward(ind).channels), 3*nvert); for i = 1:nvert Gxyz(:, (3*i- 2):(3*i)) = forwinv_compute_leadfield(vert(i, :), sens, vol); if ismember(i, Ibar) spm_progress_bar('Set', i); drawnow; end end spm_progress_bar('Clear'); spm_progress_bar('Init', nvert, ['Orienting ' modality ' leadfields']); drawnow; G{ind} = zeros(size(Gxyz, 1), size(Gxyz, 2)/3); for i = 1:nvert G{ind}(:, i) = Gxyz(:, (3*i- 2):(3*i))*norm(i, :)'; if ismember(i, Ibar) spm_progress_bar('Set', i); drawnow; end end spm_progress_bar('Clear'); -------------- next part -------------- An HTML attachment was scrubbed... URL: From inbalots at gmail.com Tue Feb 1 14:09:08 2011 From: inbalots at gmail.com (Inbal Lots) Date: Tue, 1 Feb 2011 15:09:08 +0200 Subject: [FieldTrip] question about using ft_multiplot for my own needs Message-ID: Hello I have a data matrix (in Matlab, at size of [channel num X 30 X 8] ) that holds some values I calculated for *each channel*. Is it possible to use your ft_multiplot (or any other function) to display the plots of *all channels* in their original layout? similar to the ft_multiplotER ? My aim is to plot (for each channel) 8 plots on the same axes (similar to using hold on, or plot([x1,y1],[x2,y2] ,...[x8,y8]) where each xi and yi have 30 indexes and to display it all in the layout of all channels together (similar to the ft_multiplotER, with cfg.layout='4D248.lay';). Is it possible? how can I do that? can I "zoom in" or display a selected channels- similar to the cfg.interactive='yes'; option? thanks Inbal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Patricia.Wollstadt at gmx.de Tue Feb 1 16:34:04 2011 From: Patricia.Wollstadt at gmx.de (Patricia Wollstadt) Date: Tue, 01 Feb 2011 16:34:04 +0100 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net>, <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> Message-ID: <20110201153404.267000@gmx.net> Hi Michael, Hi Jan-Mathijs, thank you very much for the advice/clarification. Everything seems to run fine now (with the corrected design). Thank you very much, Best Patricia -------- Original-Nachricht -------- > Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > Von: "Michael Wibral" > An: "Email discussion list for the FieldTrip project" > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > Hi Patricia, > > I also would have thought your design to be correct. Maybe the > unneccessary specification of the uvar screws thinsg up?? > > However, you really do not have any repeated measures in your design - > here the output of FT is correct. I interpret it in the following way: You > specified cfg.uvar - indicating to FT the possibility that this might be a > repeated measures design. FT identified the units of observation as being 80 > (correct), and then checked how many repeated measures you ran in each UO > and found just 1 - which is also correct. I agree that naming the units of > observation (UO) as 'levels' of the UO variable is a bit odd, should rather > be 'units of observation'. > > The concept of repeated measures is also very often misunderstood: in > repated measures you do not actually repeat anything, rather you perform > different measurements (treatments) WITHIN a unit of observation - so a repated > measures design is a within UO design. Your subjects just have one age, so > there are no different treatments (levels of the indep variable) per > subjects and, hence, no 'repeated measures'. > > Hope this clarifies terminology for further discussion. > > Michael > > > -----Ursprüngliche Nachricht----- > Von: "jan-mathijs schoffelen" > Gesendet: Jan 25, 2011 8:57:03 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >Hi Patricia, > > > >I don't really understand what is going on, but could you try to > >specify your design only in a single row (design = design(2,:) in your > >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how > >it runs? As such the uvar row is not relevant in an independent > >samples design. > > > >Best, > > > >Jan-Mathijs > > > > > > > >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > > > >> Dear all, > >> > >> I'm still trying to identify the underlying reason for the issue > >> described below. I ran the analysis in debug mode (I'm using > >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) > >> and found that the matrix 'resample', that is generated in > >> 'statistics_montecarlo', line 187: > >> > >> resample = resampledesign(cfg, design); > >> > >> doesn't contain actual permutations of my initial design, but rather > >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is > >> no permutation of the units of observation) the 'randstat' that is > >> subsequently calculated for each row of the resample-matrix is > >> always the same. > >> Is this maybe due to my design and my units of observations > >> respectively? I am looking at age-dependent variations in resting- > >> state data, so my UO are 80 subjects, divided into four age groups. > >> The commandline-output of the 'resampledesign'-function is as follows: > >> > >> total number of measurements = 80 > >> total number of variables = 2 > >> number of independent variables = 1 > >> number of unit variables = 1 > >> number of within-cell variables = 0 > >> number of control variables = 0 > >> using a permutation resampling approach > >> repeated measurement in variable 1 over 80 levels > >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 > >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> 1 1 > >> > >> > >> Is this correct? Shouldn't this read 'repeated measurement in > >> variable 2 over 4 levels' with the number of subjects per group as > >> repeated measurements within a condition? Still I am pretty sure > >> about my design matrix, which contains the indices 1 to 80 (for all > >> subjects) in the first row (this is my cfg.uvar) with the > >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > >> my previous email below). I use an 'indepsamplesF'-statistic, since > >> I am comparing between four groups of different subjects (averaged > >> over trials). > >> > >> I hope, I got the settings and my design right. Any suggestions, > >> whether this is a problem due to wrong configurations in my script > >> are very welcome. > >> > >> Right now I work around this issue by replacing line 279 in > >> 'statistics_montecarlo': > >> > >> tmpdesign = design(:,resample(i,:)); > >> > >> with: > >> > >> tmpdesign = design(:,randperm(size(design,2))); > >> > >> creating permutations of my design 'by hand'. Is this acceptable or > >> is there anything I'm maybe missing. > >> > >> Thank you very much, kind regards, > >> > >> Patricia > >> > >> > >> > >> > >> -------- Original-Nachricht -------- > >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > >>> Von: "Patricia Wollstadt" > >>> An: fieldtrip at donders.ru.nl > >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > >> > >>> Dear Fieldtrip-users, > >>> > >>> I'm currently trying to calculate freqstatistics for four > >>> experimental > >>> groups, using the following options: > >>> > >>> groupSize=[length(subjects{1}) length(subjects{2}) > >>> length(subjects{3}) > >>> length(subjects{4})]; > >>> > >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > >>> % 1 to N subjects > >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > >>> group membership > >>> > >>> > >>> cfg=[]; > >>> cfg.design=design; > >>> cfg.uvar = 1; > >>> cfg.ivar = 2; > >>> cfg.method = 'montecarlo'; > >>> cfg.statistic = 'indepsamplesF'; > >>> cfg.correctm = 'fdr'; > >>> cfg.numrandomization = 180000; > >>> cfg.alpha = 0.01/7; > >>> cfg.tail = 1; > >>> cfg.design = design; > >>> cfg.channels = myChannels; > >>> cfg.avgovertime = 'yes'; > >>> cfg.avgoverfreq = 'yes'; > >>> cfg.frequency = [1 3]; > >>> > >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > >>> group4avg); > >>> > >>> With these settings, the coputation itself runs fine, but the > >>> resulting > >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > >>> consists of > >>> only ones). This would mean, that I found significant effects for all > >>> channels. Is this possible or rather due to an error somewhere in > >>> my script? Is > >>> it likely, that these are 'real' zeroes or rather very small > >>> values, close > >>> to zero? > >>> Any hints and suggestions are very welcome, thank you in advance, > >>> > >>> Kind regards > >>> > >>> Patricia Wollstadt > >>> > >>> > >>> -- > >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >>> _______________________________________________ > >>> fieldtrip mailing list > >>> fieldtrip at donders.ru.nl > >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > >> -- > >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > >> _______________________________________________ > >> fieldtrip mailing list > >> fieldtrip at donders.ru.nl > >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >Dr. J.M. (Jan-Mathijs) Schoffelen > >Donders Institute for Brain, Cognition and Behaviour, > >Centre for Cognitive Neuroimaging, > >Radboud University Nijmegen, The Netherlands > >J.Schoffelen at donders.ru.nl > >Telephone: 0031-24-3614793 > > > >_______________________________________________ > >fieldtrip mailing list > >fieldtrip at donders.ru.nl > >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl From michael.wibral at web.de Tue Feb 1 18:29:57 2011 From: michael.wibral at web.de (Michael Wibral) Date: Tue, 1 Feb 2011 18:29:57 +0100 (CET) Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <20110201153404.267000@gmx.net> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net>, <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056>, <20110201153404.267000@gmx.net> Message-ID: <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Hi Patricia, it seems that things are clarified now. I just do not know what was actually wrong with your code Was it the superfluous specification of cfg.uvar?? Could you let us know? Thanks. Michael -----Ursprüngliche Nachricht----- Von: "Patricia Wollstadt" Gesendet: Feb 1, 2011 4:34:04 PM An: "Email discussion list for the FieldTrip project" Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction >Hi Michael, Hi Jan-Mathijs, > >thank you very much for the advice/clarification. Everything seems to run fine now (with the corrected design). > >Thank you very much, > >Best > >Patricia > > >-------- Original-Nachricht -------- >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) >> Von: "Michael Wibral" >> An: "Email discussion list for the FieldTrip project" >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > >> Hi Patricia, >> >> I also would have thought your design to be correct. Maybe the >> unneccessary specification of the uvar screws thinsg up?? >> >> However, you really do not have any repeated measures in your design - >> here the output of FT is correct. I interpret it in the following way: You >> specified cfg.uvar - indicating to FT the possibility that this might be a >> repeated measures design. FT identified the units of observation as being 80 >> (correct), and then checked how many repeated measures you ran in each UO >> and found just 1 - which is also correct. I agree that naming the units of >> observation (UO) as 'levels' of the UO variable is a bit odd, should rather >> be 'units of observation'. >> >> The concept of repeated measures is also very often misunderstood: in >> repated measures you do not actually repeat anything, rather you perform >> different measurements (treatments) WITHIN a unit of observation - so a repated >> measures design is a within UO design. Your subjects just have one age, so >> there are no different treatments (levels of the indep variable) per >> subjects and, hence, no 'repeated measures'. >> >> Hope this clarifies terminology for further discussion. >> >> Michael >> >> >> -----Ursprüngliche Nachricht----- >> Von: "jan-mathijs schoffelen" >> Gesendet: Jan 25, 2011 8:57:03 PM >> An: "Email discussion list for the FieldTrip project" >> >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction >> >> >Hi Patricia, >> > >> >I don't really understand what is going on, but could you try to >> >specify your design only in a single row (design = design(2,:) in your >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how >> >it runs? As such the uvar row is not relevant in an independent >> >samples design. >> > >> >Best, >> > >> >Jan-Mathijs >> > >> > >> > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: >> > >> >> Dear all, >> >> >> >> I'm still trying to identify the underlying reason for the issue >> >> described below. I ran the analysis in debug mode (I'm using >> >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) >> >> and found that the matrix 'resample', that is generated in >> >> 'statistics_montecarlo', line 187: >> >> >> >> resample = resampledesign(cfg, design); >> >> >> >> doesn't contain actual permutations of my initial design, but rather >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is >> >> no permutation of the units of observation) the 'randstat' that is >> >> subsequently calculated for each row of the resample-matrix is >> >> always the same. >> >> Is this maybe due to my design and my units of observations >> >> respectively? I am looking at age-dependent variations in resting- >> >> state data, so my UO are 80 subjects, divided into four age groups. >> >> The commandline-output of the 'resampledesign'-function is as follows: >> >> >> >> total number of measurements = 80 >> >> total number of variables = 2 >> >> number of independent variables = 1 >> >> number of unit variables = 1 >> >> number of within-cell variables = 0 >> >> number of control variables = 0 >> >> using a permutation resampling approach >> >> repeated measurement in variable 1 over 80 levels >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 >> >> 1 1 >> >> >> >> >> >> Is this correct? Shouldn't this read 'repeated measurement in >> >> variable 2 over 4 levels' with the number of subjects per group as >> >> repeated measurements within a condition? Still I am pretty sure >> >> about my design matrix, which contains the indices 1 to 80 (for all >> >> subjects) in the first row (this is my cfg.uvar) with the >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see >> >> my previous email below). I use an 'indepsamplesF'-statistic, since >> >> I am comparing between four groups of different subjects (averaged >> >> over trials). >> >> >> >> I hope, I got the settings and my design right. Any suggestions, >> >> whether this is a problem due to wrong configurations in my script >> >> are very welcome. >> >> >> >> Right now I work around this issue by replacing line 279 in >> >> 'statistics_montecarlo': >> >> >> >> tmpdesign = design(:,resample(i,:)); >> >> >> >> with: >> >> >> >> tmpdesign = design(:,randperm(size(design,2))); >> >> >> >> creating permutations of my design 'by hand'. Is this acceptable or >> >> is there anything I'm maybe missing. >> >> >> >> Thank you very much, kind regards, >> >> >> >> Patricia >> >> >> >> >> >> >> >> >> >> -------- Original-Nachricht -------- >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 >> >>> Von: "Patricia Wollstadt" >> >>> An: fieldtrip at donders.ru.nl >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction >> >> >> >>> Dear Fieldtrip-users, >> >>> >> >>> I'm currently trying to calculate freqstatistics for four >> >>> experimental >> >>> groups, using the following options: >> >>> >> >>> groupSize=[length(subjects{1}) length(subjects{2}) >> >>> length(subjects{3}) >> >>> length(subjects{4})]; >> >>> >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; >> >>> % 1 to N subjects >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> >> >>> group membership >> >>> >> >>> >> >>> cfg=[]; >> >>> cfg.design=design; >> >>> cfg.uvar = 1; >> >>> cfg.ivar = 2; >> >>> cfg.method = 'montecarlo'; >> >>> cfg.statistic = 'indepsamplesF'; >> >>> cfg.correctm = 'fdr'; >> >>> cfg.numrandomization = 180000; >> >>> cfg.alpha = 0.01/7; >> >>> cfg.tail = 1; >> >>> cfg.design = design; >> >>> cfg.channels = myChannels; >> >>> cfg.avgovertime = 'yes'; >> >>> cfg.avgoverfreq = 'yes'; >> >>> cfg.frequency = [1 3]; >> >>> >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, >> >>> group4avg); >> >>> >> >>> With these settings, the coputation itself runs fine, but the >> >>> resulting >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix >> >>> consists of >> >>> only ones). This would mean, that I found significant effects for all >> >>> channels. Is this possible or rather due to an error somewhere in >> >>> my script? Is >> >>> it likely, that these are 'real' zeroes or rather very small >> >>> values, close >> >>> to zero? >> >>> Any hints and suggestions are very welcome, thank you in advance, >> >>> >> >>> Kind regards >> >>> >> >>> Patricia Wollstadt >> >>> >> >>> >> >>> -- >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >> >>> _______________________________________________ >> >>> fieldtrip mailing list >> >>> fieldtrip at donders.ru.nl >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> >> -- >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >> >> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >> >> _______________________________________________ >> >> fieldtrip mailing list >> >> fieldtrip at donders.ru.nl >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > >> >Dr. J.M. (Jan-Mathijs) Schoffelen >> >Donders Institute for Brain, Cognition and Behaviour, >> >Centre for Cognitive Neuroimaging, >> >Radboud University Nijmegen, The Netherlands >> >J.Schoffelen at donders.ru.nl >> >Telephone: 0031-24-3614793 >> > >> >_______________________________________________ >> >fieldtrip mailing list >> >fieldtrip at donders.ru.nl >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >-- >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >_______________________________________________ >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From batrod at gmail.com Tue Feb 1 18:38:26 2011 From: batrod at gmail.com (Rodolphe Nenert) Date: Tue, 1 Feb 2011 11:38:26 -0600 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net> <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> <20110201153404.267000@gmx.net> <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Message-ID: Dear Patricia and others that participated to this discussion. I had recently the same problem, using ft_freqstatistics with Montecarlo to correlate Time-frequency power values and behavioral results. All my p-values were first found to be 0, resulting in a mask full of 1. By removing the useless cfg.uvar, the script made the correct analysis and reported good correlation values. Hope this helps, Rodolphe. On Tue, Feb 1, 2011 at 11:29 AM, Michael Wibral wrote: > Hi Patricia, > > it seems that things are clarified now. I just do not know what was > actually wrong with your code Was it the superfluous specification of > cfg.uvar?? > Could you let us know? Thanks. > > Michael > -----Ursprüngliche Nachricht----- > Von: "Patricia Wollstadt" > Gesendet: Feb 1, 2011 4:34:04 PM > An: "Email discussion list for the FieldTrip project" < > fieldtrip at donders.ru.nl> > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >Hi Michael, Hi Jan-Mathijs, > > > >thank you very much for the advice/clarification. Everything seems to run > fine now (with the corrected design). > > > >Thank you very much, > > > >Best > > > >Patricia > > > > > >-------- Original-Nachricht -------- > >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > >> Von: "Michael Wibral" > >> An: "Email discussion list for the FieldTrip project" < > fieldtrip at donders.ru.nl> > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > >> Hi Patricia, > >> > >> I also would have thought your design to be correct. Maybe the > >> unneccessary specification of the uvar screws thinsg up?? > >> > >> However, you really do not have any repeated measures in your design - > >> here the output of FT is correct. I interpret it in the following way: > You > >> specified cfg.uvar - indicating to FT the possibility that this might be > a > >> repeated measures design. FT identified the units of observation as > being 80 > >> (correct), and then checked how many repeated measures you ran in each > UO > >> and found just 1 - which is also correct. I agree that naming the units > of > >> observation (UO) as 'levels' of the UO variable is a bit odd, should > rather > >> be 'units of observation'. > >> > >> The concept of repeated measures is also very often misunderstood: in > >> repated measures you do not actually repeat anything, rather you perform > >> different measurements (treatments) WITHIN a unit of observation - so a > repated > >> measures design is a within UO design. Your subjects just have one age, > so > >> there are no different treatments (levels of the indep variable) per > >> subjects and, hence, no 'repeated measures'. > >> > >> Hope this clarifies terminology for further discussion. > >> > >> Michael > >> > >> > >> -----Ursprüngliche Nachricht----- > >> Von: "jan-mathijs schoffelen" > >> Gesendet: Jan 25, 2011 8:57:03 PM > >> An: "Email discussion list for the FieldTrip project" > >> > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > >> > >> >Hi Patricia, > >> > > >> >I don't really understand what is going on, but could you try to > >> >specify your design only in a single row (design = design(2,:) in your > >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see how > >> >it runs? As such the uvar row is not relevant in an independent > >> >samples design. > >> > > >> >Best, > >> > > >> >Jan-Mathijs > >> > > >> > > >> > > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > >> > > >> >> Dear all, > >> >> > >> >> I'm still trying to identify the underlying reason for the issue > >> >> described below. I ran the analysis in debug mode (I'm using > >> >> Matlab2008b and the Fieldtrip-release from the 16th of January 2011) > >> >> and found that the matrix 'resample', that is generated in > >> >> 'statistics_montecarlo', line 187: > >> >> > >> >> resample = resampledesign(cfg, design); > >> >> > >> >> doesn't contain actual permutations of my initial design, but rather > >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there is > >> >> no permutation of the units of observation) the 'randstat' that is > >> >> subsequently calculated for each row of the resample-matrix is > >> >> always the same. > >> >> Is this maybe due to my design and my units of observations > >> >> respectively? I am looking at age-dependent variations in resting- > >> >> state data, so my UO are 80 subjects, divided into four age groups. > >> >> The commandline-output of the 'resampledesign'-function is as > follows: > >> >> > >> >> total number of measurements = 80 > >> >> total number of variables = 2 > >> >> number of independent variables = 1 > >> >> number of unit variables = 1 > >> >> number of within-cell variables = 0 > >> >> number of control variables = 0 > >> >> using a permutation resampling approach > >> >> repeated measurement in variable 1 over 80 levels > >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > >> >> 1 1 > >> >> > >> >> > >> >> Is this correct? Shouldn't this read 'repeated measurement in > >> >> variable 2 over 4 levels' with the number of subjects per group as > >> >> repeated measurements within a condition? Still I am pretty sure > >> >> about my design matrix, which contains the indices 1 to 80 (for all > >> >> subjects) in the first row (this is my cfg.uvar) with the > >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > >> >> my previous email below). I use an 'indepsamplesF'-statistic, since > >> >> I am comparing between four groups of different subjects (averaged > >> >> over trials). > >> >> > >> >> I hope, I got the settings and my design right. Any suggestions, > >> >> whether this is a problem due to wrong configurations in my script > >> >> are very welcome. > >> >> > >> >> Right now I work around this issue by replacing line 279 in > >> >> 'statistics_montecarlo': > >> >> > >> >> tmpdesign = design(:,resample(i,:)); > >> >> > >> >> with: > >> >> > >> >> tmpdesign = design(:,randperm(size(design,2))); > >> >> > >> >> creating permutations of my design 'by hand'. Is this acceptable or > >> >> is there anything I'm maybe missing. > >> >> > >> >> Thank you very much, kind regards, > >> >> > >> >> Patricia > >> >> > >> >> > >> >> > >> >> > >> >> -------- Original-Nachricht -------- > >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > >> >>> Von: "Patricia Wollstadt" > >> >>> An: fieldtrip at donders.ru.nl > >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > >> >> > >> >>> Dear Fieldtrip-users, > >> >>> > >> >>> I'm currently trying to calculate freqstatistics for four > >> >>> experimental > >> >>> groups, using the following options: > >> >>> > >> >>> groupSize=[length(subjects{1}) length(subjects{2}) > >> >>> length(subjects{3}) > >> >>> length(subjects{4})]; > >> >>> > >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > >> >>> % 1 to N subjects > >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > >> >>> group membership > >> >>> > >> >>> > >> >>> cfg=[]; > >> >>> cfg.design=design; > >> >>> cfg.uvar = 1; > >> >>> cfg.ivar = 2; > >> >>> cfg.method = 'montecarlo'; > >> >>> cfg.statistic = 'indepsamplesF'; > >> >>> cfg.correctm = 'fdr'; > >> >>> cfg.numrandomization = 180000; > >> >>> cfg.alpha = 0.01/7; > >> >>> cfg.tail = 1; > >> >>> cfg.design = design; > >> >>> cfg.channels = myChannels; > >> >>> cfg.avgovertime = 'yes'; > >> >>> cfg.avgoverfreq = 'yes'; > >> >>> cfg.frequency = [1 3]; > >> >>> > >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > >> >>> group4avg); > >> >>> > >> >>> With these settings, the coputation itself runs fine, but the > >> >>> resulting > >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > >> >>> consists of > >> >>> only ones). This would mean, that I found significant effects for > all > >> >>> channels. Is this possible or rather due to an error somewhere in > >> >>> my script? Is > >> >>> it likely, that these are 'real' zeroes or rather very small > >> >>> values, close > >> >>> to zero? > >> >>> Any hints and suggestions are very welcome, thank you in advance, > >> >>> > >> >>> Kind regards > >> >>> > >> >>> Patricia Wollstadt > >> >>> > >> >>> > >> >>> -- > >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >> >>> _______________________________________________ > >> >>> fieldtrip mailing list > >> >>> fieldtrip at donders.ru.nl > >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> >> > >> >> -- > >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > >> >> belohnen Sie mit bis zu 50,- Euro! > https://freundschaftswerbung.gmx.de > >> >> _______________________________________________ > >> >> fieldtrip mailing list > >> >> fieldtrip at donders.ru.nl > >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > >> > > >> >Dr. J.M. (Jan-Mathijs) Schoffelen > >> >Donders Institute for Brain, Cognition and Behaviour, > >> >Centre for Cognitive Neuroimaging, > >> >Radboud University Nijmegen, The Netherlands > >> >J.Schoffelen at donders.ru.nl > >> >Telephone: 0031-24-3614793 > >> > > >> >_______________________________________________ > >> >fieldtrip mailing list > >> >fieldtrip at donders.ru.nl > >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > >-- > >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > >_______________________________________________ > >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 ekanal at cmu.edu Tue Feb 1 19:16:23 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Tue, 1 Feb 2011 13:16:23 -0500 Subject: [FieldTrip] using planar gradiometer data with ft_combineplanar Message-ID: <3F013D5F-0A1C-4A63-A365-FFD87F9233F9@cmu.edu> Hello folks - We have a Neuromag 306 system here, which has two planar gradiometers at each sensor location (x and y directions). Is there a way I can use ft_combineplanar with the data from these sensors? From what I can tell, I shouldn't need to use ft_megplanar, but I don't know how to format the data so that ft_combineplanar knows what to do. Thanks - Elli Kanal -------------------- Eliezer Kanal, Ph.D. Postdoctoral Fellow Center for the Neural Basis of Cognition Carnegie Mellon University 4400 Fifth Ave, Suite 115 Pittsburgh PA 15213 P: 412-268-4115 F: 412-268-5060 From Patricia.Wollstadt at gmx.de Tue Feb 1 22:26:51 2011 From: Patricia.Wollstadt at gmx.de (Patricia Wollstadt) Date: Tue, 01 Feb 2011 22:26:51 +0100 Subject: [FieldTrip] ft_freqstatistics and FDR-correction In-Reply-To: References: <20110124164726.247880@gmx.net> <20110125170838.254600@gmx.net> <1C530F16-9067-4FDF-A526-20513EE05C79@donders.ru.nl> <1367146600.2032784.1296032931966.JavaMail.fmail@mwmweb056> <20110201153404.267000@gmx.net> <1161827061.5251946.1296581397869.JavaMail.fmail@mwmweb053> Message-ID: <20110201212651.47820@gmx.net> Dear all, the problem was caused by the wrong design matrix (and thus the superfluous cfg.uvar), sorry for not making this clear. So actually I just need a vector that specifies the group for each subject, Best Patricia -------- Original-Nachricht -------- > Datum: Tue, 1 Feb 2011 11:38:26 -0600 > Von: Rodolphe Nenert > An: Email discussion list for the FieldTrip project > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > Dear Patricia and others that participated to this discussion. > > I had recently the same problem, using ft_freqstatistics with Montecarlo > to > correlate Time-frequency power values and behavioral results. > All my p-values were first found to be 0, resulting in a mask full of 1. > By removing the useless cfg.uvar, the script made the correct analysis and > reported good correlation values. > > Hope this helps, > > Rodolphe. > > On Tue, Feb 1, 2011 at 11:29 AM, Michael Wibral > wrote: > > > Hi Patricia, > > > > it seems that things are clarified now. I just do not know what was > > actually wrong with your code Was it the superfluous specification of > > cfg.uvar?? > > Could you let us know? Thanks. > > > > Michael > > -----Ursprüngliche Nachricht----- > > Von: "Patricia Wollstadt" > > Gesendet: Feb 1, 2011 4:34:04 PM > > An: "Email discussion list for the FieldTrip project" < > > fieldtrip at donders.ru.nl> > > Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > > >Hi Michael, Hi Jan-Mathijs, > > > > > >thank you very much for the advice/clarification. Everything seems to > run > > fine now (with the corrected design). > > > > > >Thank you very much, > > > > > >Best > > > > > >Patricia > > > > > > > > >-------- Original-Nachricht -------- > > >> Datum: Wed, 26 Jan 2011 10:08:51 +0100 (CET) > > >> Von: "Michael Wibral" > > >> An: "Email discussion list for the FieldTrip project" < > > fieldtrip at donders.ru.nl> > > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > > > > >> Hi Patricia, > > >> > > >> I also would have thought your design to be correct. Maybe the > > >> unneccessary specification of the uvar screws thinsg up?? > > >> > > >> However, you really do not have any repeated measures in your design > - > > >> here the output of FT is correct. I interpret it in the following > way: > > You > > >> specified cfg.uvar - indicating to FT the possibility that this might > be > > a > > >> repeated measures design. FT identified the units of observation as > > being 80 > > >> (correct), and then checked how many repeated measures you ran in > each > > UO > > >> and found just 1 - which is also correct. I agree that naming the > units > > of > > >> observation (UO) as 'levels' of the UO variable is a bit odd, should > > rather > > >> be 'units of observation'. > > >> > > >> The concept of repeated measures is also very often misunderstood: in > > >> repated measures you do not actually repeat anything, rather you > perform > > >> different measurements (treatments) WITHIN a unit of observation - so > a > > repated > > >> measures design is a within UO design. Your subjects just have one > age, > > so > > >> there are no different treatments (levels of the indep variable) per > > >> subjects and, hence, no 'repeated measures'. > > >> > > >> Hope this clarifies terminology for further discussion. > > >> > > >> Michael > > >> > > >> > > >> -----Ursprüngliche Nachricht----- > > >> Von: "jan-mathijs schoffelen" > > >> Gesendet: Jan 25, 2011 8:57:03 PM > > >> An: "Email discussion list for the FieldTrip project" > > >> > > >> Betreff: Re: [FieldTrip] ft_freqstatistics and FDR-correction > > >> > > >> >Hi Patricia, > > >> > > > >> >I don't really understand what is going on, but could you try to > > >> >specify your design only in a single row (design = design(2,:) in > your > > >> >case), specify cfg.ivar = 1; and cfg=rmfield(cfg,'uvar'), and see > how > > >> >it runs? As such the uvar row is not relevant in an independent > > >> >samples design. > > >> > > > >> >Best, > > >> > > > >> >Jan-Mathijs > > >> > > > >> > > > >> > > > >> >On Jan 25, 2011, at 6:08 PM, Patricia Wollstadt wrote: > > >> > > > >> >> Dear all, > > >> >> > > >> >> I'm still trying to identify the underlying reason for the issue > > >> >> described below. I ran the analysis in debug mode (I'm using > > >> >> Matlab2008b and the Fieldtrip-release from the 16th of January > 2011) > > >> >> and found that the matrix 'resample', that is generated in > > >> >> 'statistics_montecarlo', line 187: > > >> >> > > >> >> resample = resampledesign(cfg, design); > > >> >> > > >> >> doesn't contain actual permutations of my initial design, but > rather > > >> >> sorted rowvectors from 1 to 80 (no of subjects). So (since there > is > > >> >> no permutation of the units of observation) the 'randstat' that is > > >> >> subsequently calculated for each row of the resample-matrix is > > >> >> always the same. > > >> >> Is this maybe due to my design and my units of observations > > >> >> respectively? I am looking at age-dependent variations in resting- > > >> >> state data, so my UO are 80 subjects, divided into four age > groups. > > >> >> The commandline-output of the 'resampledesign'-function is as > > follows: > > >> >> > > >> >> total number of measurements = 80 > > >> >> total number of variables = 2 > > >> >> number of independent variables = 1 > > >> >> number of unit variables = 1 > > >> >> number of within-cell variables = 0 > > >> >> number of control variables = 0 > > >> >> using a permutation resampling approach > > >> >> repeated measurement in variable 1 over 80 levels > > >> >> number of repeated measurements in each level is 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 > 1 > > >> >> 1 1 > > >> >> > > >> >> > > >> >> Is this correct? Shouldn't this read 'repeated measurement in > > >> >> variable 2 over 4 levels' with the number of subjects per group as > > >> >> repeated measurements within a condition? Still I am pretty sure > > >> >> about my design matrix, which contains the indices 1 to 80 (for > all > > >> >> subjects) in the first row (this is my cfg.uvar) with the > > >> >> corresponding age groups (1 to 4) in the second row (cfg.ivar, see > > >> >> my previous email below). I use an 'indepsamplesF'-statistic, > since > > >> >> I am comparing between four groups of different subjects (averaged > > >> >> over trials). > > >> >> > > >> >> I hope, I got the settings and my design right. Any suggestions, > > >> >> whether this is a problem due to wrong configurations in my script > > >> >> are very welcome. > > >> >> > > >> >> Right now I work around this issue by replacing line 279 in > > >> >> 'statistics_montecarlo': > > >> >> > > >> >> tmpdesign = design(:,resample(i,:)); > > >> >> > > >> >> with: > > >> >> > > >> >> tmpdesign = design(:,randperm(size(design,2))); > > >> >> > > >> >> creating permutations of my design 'by hand'. Is this acceptable > or > > >> >> is there anything I'm maybe missing. > > >> >> > > >> >> Thank you very much, kind regards, > > >> >> > > >> >> Patricia > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> -------- Original-Nachricht -------- > > >> >>> Datum: Mon, 24 Jan 2011 17:47:26 +0100 > > >> >>> Von: "Patricia Wollstadt" > > >> >>> An: fieldtrip at donders.ru.nl > > >> >>> Betreff: [FieldTrip] ft_freqstatistics and FDR-correction > > >> >> > > >> >>> Dear Fieldtrip-users, > > >> >>> > > >> >>> I'm currently trying to calculate freqstatistics for four > > >> >>> experimental > > >> >>> groups, using the following options: > > >> >>> > > >> >>> groupSize=[length(subjects{1}) length(subjects{2}) > > >> >>> length(subjects{3}) > > >> >>> length(subjects{4})]; > > >> >>> > > >> >>> design = [1:groupSize(1)+groupSize(2)+groupSize(3)+groupSize(4)]; > > >> >>> % 1 to N subjects > > >> >>> design(2,:) = [ones(1,groupSize(1)) 2*ones(1,groupSize(2)) > > >> >>> 3*ones(1,groupSize(3)) 4*ones(1,groupSize(4))]; % indep var -> > > >> >>> group membership > > >> >>> > > >> >>> > > >> >>> cfg=[]; > > >> >>> cfg.design=design; > > >> >>> cfg.uvar = 1; > > >> >>> cfg.ivar = 2; > > >> >>> cfg.method = 'montecarlo'; > > >> >>> cfg.statistic = 'indepsamplesF'; > > >> >>> cfg.correctm = 'fdr'; > > >> >>> cfg.numrandomization = 180000; > > >> >>> cfg.alpha = 0.01/7; > > >> >>> cfg.tail = 1; > > >> >>> cfg.design = design; > > >> >>> cfg.channels = myChannels; > > >> >>> cfg.avgovertime = 'yes'; > > >> >>> cfg.avgoverfreq = 'yes'; > > >> >>> cfg.frequency = [1 3]; > > >> >>> > > >> >>> stat = ft_freqstatistics(cfg, group1avg, group2avg, group3avg, > > >> >>> group4avg); > > >> >>> > > >> >>> With these settings, the coputation itself runs fine, but the > > >> >>> resulting > > >> >>> 'prob'-matrix contains only zeros (accordingly the 'mask'-matrix > > >> >>> consists of > > >> >>> only ones). This would mean, that I found significant effects for > > all > > >> >>> channels. Is this possible or rather due to an error somewhere in > > >> >>> my script? Is > > >> >>> it likely, that these are 'real' zeroes or rather very small > > >> >>> values, close > > >> >>> to zero? > > >> >>> Any hints and suggestions are very welcome, thank you in advance, > > >> >>> > > >> >>> Kind regards > > >> >>> > > >> >>> Patricia Wollstadt > > >> >>> > > >> >>> > > >> >>> -- > > >> >>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > > >> >>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > >> >>> _______________________________________________ > > >> >>> fieldtrip mailing list > > >> >>> fieldtrip at donders.ru.nl > > >> >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > >> >> > > >> >> -- > > >> >> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > > >> >> belohnen Sie mit bis zu 50,- Euro! > > https://freundschaftswerbung.gmx.de > > >> >> _______________________________________________ > > >> >> fieldtrip mailing list > > >> >> fieldtrip at donders.ru.nl > > >> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > >> > > > >> >Dr. J.M. (Jan-Mathijs) Schoffelen > > >> >Donders Institute for Brain, Cognition and Behaviour, > > >> >Centre for Cognitive Neuroimaging, > > >> >Radboud University Nijmegen, The Netherlands > > >> >J.Schoffelen at donders.ru.nl > > >> >Telephone: 0031-24-3614793 > > >> > > > >> >_______________________________________________ > > >> >fieldtrip mailing list > > >> >fieldtrip at donders.ru.nl > > >> >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > > >-- > > >GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > > >gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > >_______________________________________________ > > >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 > > -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail From r.oostenveld at donders.ru.nl Wed Feb 2 10:39:50 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 2 Feb 2011 10:39:50 +0100 Subject: [FieldTrip] toolkit course for MEG and EEG data analysis at the Donders Institute Message-ID: Dear MEG/EEG researchers, (appologies for multiple postings) I would like to announce the yearly toolkit course for MEG and EEG data analysis at the Donders Institute. This year's toolkit will take place from April 18 to April 21. Registration is now open. Have a look at http://www.ru.nl/donders/agenda-events/courses/toolkits-2011 for the preliminary programme and to register. Please note that the number of seats is limited and that participants will be selected based on the time of registration and on their research background and motivation. best regards, Robert ----------------------------------------------------------- Robert Oostenveld, PhD Senior Researcher & MEG Physicist Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen Postal Address: PO Box 9101 6500 HB NIJMEGEN The Netherlands Visiting address: Kapittelweg 29 route: 210, room: 0.88 6525 EN NIJMEGEN tel.: +31 (0)24 3619695 e-mail: r.oostenveld at donders.ru.nl web: http://www.ru.nl/neuroimaging skype: r.oostenveld ----------------------------------------------------------- From michael.wibral at web.de Thu Feb 3 10:18:17 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 3 Feb 2011 10:18:17 +0100 (CET) Subject: [FieldTrip] Problem with permutation testing and FDR correction Message-ID: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> Dear Fieldtrip users, I think we detected an error with FDR correction and permutation testing. When increasing the number of permutations, the number of significant voxels goes DOWN, on the other hand when decreasing the number of permutations the number of significant voxels goes up. In my opinion the relationship should be the other way round. The theoretical background is as follows: With FDR correction, the best p-value should survive bonferroni correction (if I am not completely mistaken here), the threshold for the other p-values is then decreased successively. Hence, the p-value assigned to the best (most significant) statistical result plays a crucial role here. This best p-value in permutation tests can never be better than 1/numpermutations, i.e. when I do ten permutations, the best p I can possibly get is 0.1 EVEN IF ALL PERMUTED VALUES ARE LESS EXTREME. So to test with FDR at 275 sensors and 1 timepoint at a threshold of 0.05 we need for anything to get significant a p-value of 0.05/275 = 0.000181818.... to be able to reach this in the best case (remebering that p-values can never be better than 1/numpermutations) we need at least (0.000181818....)^-1 = 5500 permutations. In other words with anything less than this number of permutations we should not be able to get any significances. However, we do in fact get alot of significant values at least in the fieldtrip versions tested up to 16th of January, e.g. in a freqstatistics test on 275 sensors, 50 frequencies and 26 timepoints I get 20760 significant voxels using only 10 permutations (!!). I assume that in the stats module the p-value is simply taken as the fraction of permutations that was more extreme than the actual value. This is correct as long as this fraction is not 0. In the case of a 0 fraction, however, this "0" should be replaced by "1/numpermutations", otherwise you get everything signifcant by just using 10 permutations. An alternative would be to issue an ERROR that the number of permutations is insufficient to perform the desired test with fdr correction. Example: for 4300 source points at 0.05 the number of permutations should at least be (0.05/4300)^-1=86000. For now one should compute the p-value for a bonferroni correction manually, invert this value and take the resulting number as the number of permutations to be at least mathematically on the safe side (practically it seems to be advisable to multiply by another factor of 100 to have stable results, e.g 2000 permutations for uncorrceted testing at 0.05) Please disregard this mail if you are sure that this behaviour has been fixed in the latest fieldtrip (past 16th of January) versions. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From e.maris at donders.ru.nl Thu Feb 3 11:24:18 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Thu, 3 Feb 2011 11:24:18 +0100 Subject: [FieldTrip] Problem with permutation testing and FDR correction In-Reply-To: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> References: <75316985.6251067.1296724697449.JavaMail.fmail@mwmweb054> Message-ID: <018d01cbc38c$869a7ba0$93cf72e0$@maris@donders.ru.nl> Dear Michael, Thank you for pointing this out. The origin of the problem is that FT calculates Monte Carlo estimates of the p-values. In practice there is no other way, except for very small studies where enumeration is possible. However, Monte Carlo estimates are useless if the number of draws from the permutation distribution (numpermutations) is very small, because in that case their Monte Carlo confidence interval is very large. I propose that we add a Monte Carlo confidence interval for all Monte Carlo p-values that FT calculates. This is actually very easy, and I have described it in a paper together with Jan-Matthijs Schoffelen and Pascal Fries (JNeuroMeth, 2007). It just hasn't found its way into FT yet. I will discuss with Robert how to implement this. Best, Eric Maris dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > -----Original Message----- > From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > bounces at donders.ru.nl] On Behalf Of Michael Wibral > Sent: donderdag 3 februari 2011 10:18 > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] Problem with permutation testing and FDR > correction > > Dear Fieldtrip users, > > I think we detected an error with FDR correction and permutation > testing. When increasing the number of permutations, the number of > significant voxels goes DOWN, on the other hand when decreasing the > number of permutations the number of significant voxels goes up. In my > opinion the relationship should be the other way round. The theoretical > background is as follows: > > With FDR correction, the best p-value should survive bonferroni > correction (if I am not completely mistaken here), the threshold for > the other p-values is then decreased successively. > Hence, the p-value assigned to the best (most significant) statistical > result plays a crucial role here. This best p-value in permutation > tests can never be better than 1/numpermutations, i.e. when I do ten > permutations, the best p I can possibly get is 0.1 EVEN IF ALL PERMUTED > VALUES ARE LESS EXTREME. So to test with FDR at 275 sensors and 1 > timepoint at a threshold of 0.05 we need for anything to get > significant a p-value of 0.05/275 = 0.000181818.... to be able to reach > this in the best case (remebering that p-values can never be better > than 1/numpermutations) we need at least (0.000181818....)^-1 = 5500 > permutations. In other words with anything less than this number of > permutations we should not be able to get any significances. However, > we do in fact get alot of significant values at least in the fieldtrip > versions tested up to 16th of January, e.g. in a freqstatistics test on > 275 sensors, 50 frequencies and 26 timepoints I get 20760 significant > voxels using only 10 permutations (!!). I assume that in the stats > module the p-value is simply taken as the fraction of permutations that > was more extreme than the actual value. This is correct as long as this > fraction is not 0. In the case of a 0 fraction, however, this "0" > should be replaced by "1/numpermutations", otherwise you get everything > signifcant by just using 10 permutations. An alternative would be to > issue an ERROR that the number of permutations is insufficient to > perform the desired test with fdr correction. > > > Example: for 4300 source points at 0.05 the number of permutations > should at least be (0.05/4300)^-1=86000. > > For now one should compute the p-value for a bonferroni correction > manually, invert this value and take the resulting number as the number > of permutations to be at least mathematically on the safe side > (practically it seems to be advisable to multiply by another factor of > 100 to have stable results, e.g 2000 permutations for uncorrceted > testing at 0.05) > > Please disregard this mail if you are sure that this behaviour has been > fixed in the latest fieldtrip (past 16th of January) versions. > > Michael From H.Rossiter at ion.ucl.ac.uk Thu Feb 3 15:25:59 2011 From: H.Rossiter at ion.ucl.ac.uk (Holly Rossiter) Date: Thu, 3 Feb 2011 14:25:59 -0000 Subject: [FieldTrip] EMG data Message-ID: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> Dear Fieldtrip, I am new to fieldtrip and am using it to look at MEG-EMG coherence. I am trying to load in my EMG data which is in a separate data file to the MEG. It is made up of 3 files (.eeg, .vhdr and .vmrk). I am trying to follow the coherence tutorial I previously downloaded from your website but I'm not able to define trials despite there being triggers present. Here are my attempts to load in the data with the following error... cfg = []; cfg.trialfun = 'trialfun_general'; cfg.trialdef.eventtype = '1'; cfg.trialdef.eventvalue = [1 1]; cfg.trialdef.prestim = 1; cfg.trialdef.poststim = 2; cfg.dataset = 'sf_EMG.eeg'; cfg = ft_definetrial(cfg); evaluating trialfunction 'trialfun_general' reading the events from 'sf_EMG.vhdr' ??? Error using ==> ft_definetrial at 136 no trials were defined, see DEFINETRIAL for help What do you suggest is the problem? Is it not reading the triggers correctly? Thanks, Holly -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 3 16:09:16 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 3 Feb 2011 16:09:16 +0100 Subject: [FieldTrip] EMG data In-Reply-To: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> Message-ID: Dear Holly You may want to have a look at: http://fieldtrip.fcdonders.nl/example/getting_started_with_reading_raw_eeg_or_meg_data?s []=event To me it sounds as if you have an incorrect specification of your cfg. Good luck, Jan-Mathijs On Feb 3, 2011, at 3:25 PM, Holly Rossiter wrote: > Dear Fieldtrip, > > I am new to fieldtrip and am using it to look at MEG-EMG coherence. > I am trying to load in my EMG data which is in a separate data file > to the MEG. It is made up of 3 files (.eeg, .vhdr and .vmrk). I am > trying to follow the coherence tutorial I previously downloaded from > your website but I’m not able to define trials despite there being > triggers present. > > Here are my attempts to load in the data with the following error... > > cfg = []; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.eventtype = '1'; > cfg.trialdef.eventvalue = [1 1]; > cfg.trialdef.prestim = 1; > cfg.trialdef.poststim = 2; > cfg.dataset = 'sf_EMG.eeg'; > cfg = ft_definetrial(cfg); > evaluating trialfunction 'trialfun_general' > reading the events from 'sf_EMG.vhdr' > ??? Error using ==> ft_definetrial at 136 > no trials were defined, see DEFINETRIAL for help > > What do you suggest is the problem? Is it not reading the triggers > correctly? > > Thanks, > > Holly > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.frei at psy.gla.ac.uk Thu Feb 3 19:07:44 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Thu, 3 Feb 2011 18:07:44 +0000 Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk> Message-ID: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Hi everybody, I have a problem that impacts several analysis steps and I'm hoping someone can point me to the right direction. I have 13 recording sessions, that I want to average, and then I want to compute the planar gradients of the average. I first average the sessions with ft_timelockanalysis for each session. Then I use ft_timelockgrandaverage to combine the sessions. Then, just to check the data, I plot the ERFs with ft_multiplotER. This is when the first problem arises. The x and y axes of the plots are shifted in space somehow (see picture 3.png). Next, I compute the planar gradients. When I plot the topographies for the planar gradient, I get a very strange activation pattern, that has nothing to do with the ERF topography (which, btw has no obvious flaws) and I also get several warnings when I make the plot (Picture4.png). I also know for a fact that the grand average planar gradient should look different, as I computed it once before by hand, and it looked much more sensible. If anyone has ever seen this before and can give me a hint as to where to look for the error, I would be very grateful. Luisa -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 4.png Type: application/applefile Size: 73 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 4.png Type: image/png Size: 8160 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 3.png Type: application/applefile Size: 73 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 3.png Type: image/png Size: 43112 bytes Desc: not available URL: -------------- next part -------------- From jan.schoffelen at donders.ru.nl Thu Feb 3 20:29:04 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 3 Feb 2011 20:29:04 +0100 Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$%Rossiter@ion.ucl.ac.uk> <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Message-ID: Dear Luisa, Could you please specify whether this is a new problem that didn't occur before? If you didn't have problems before, approximately when did it stop working the way you expected it to work? As to the multiplot problem: To me, it seems as if the y-axis is plotted at time point 0, which is indeed far away from your latency of interest, which is (surprise) between 0.14 and 0.18 s. This is a property of multiplotER, which by default plots the x and y axes. Should be possible to switch it off. As to the topoplot problem: difficult to say without additional info / data to reproduce the problem. I assume you have used ft_combineplanar first before attempting to plot the planar gradient representation? Did everything go well in the previous steps, i.e. proper baseline correction etc, prior to timelockanalysis? Be sure also to not use the baseline-correction option for the plotting in ft_topoplotER. Best wishes, Jan-Mathijs On Feb 3, 2011, at 7:07 PM, Luisa Frei wrote: > Hi everybody, > I have a problem that impacts several analysis steps and I'm hoping > someone can point me to the right direction. > > I have 13 recording sessions, that I want to average, and then I > want to compute the planar gradients of the average. I first average > the sessions with ft_timelockanalysis for each session. Then I use > ft_timelockgrandaverage to combine the sessions. > Then, just to check the data, I plot the ERFs with ft_multiplotER. > This is when the first problem arises. The x and y axes of the plots > are shifted in space somehow (see picture 3.png). > Next, I compute the planar gradients. When I plot the topographies > for the planar gradient, I get a very strange activation pattern, > that has nothing to do with the ERF topography (which, btw has no > obvious flaws) and I also get several warnings when I make the plot > (Picture4.png). > > I also know for a fact that the grand average planar gradient should > look different, as I computed it once before by hand, and it looked > much more sensible. > > If anyone has ever seen this before and can give me a hint as to > where to look for the error, I would be very grateful. > > Luisa > > > > > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From michael.wibral at web.de Fri Feb 4 10:47:55 2011 From: michael.wibral at web.de (Michael Wibral) Date: Fri, 4 Feb 2011 10:47:55 +0100 (CET) Subject: [FieldTrip] =?utf-8?q?problem_with_ft=5Fmultiplot_and_planar_grad?= =?utf-8?b?aWVudCAg77+8?= In-Reply-To: <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk>, <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> Message-ID: <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> Dear Luisa, I was also wondering whether you were aware of the fact that planar gradients of group data can look very different depending on when you do the averaging and the megplanar/combineplanar steps. This is because combineplanar is a nonlinear step that cannot be exchanged with the other steps without changing the results. So creating planar gradients in single trials and then using combineplanar and then averaging trials within subjects and then over subjects will look pretty different from doing all averaging first (trials, subjects) and then using megplanar/combineplanar to get an planar gradient representation of this average. Michael -----Ursprüngliche Nachricht----- Von: "Luisa Frei" Gesendet: Feb 3, 2011 7:07:44 PM An: "Email discussion list for the FieldTrip project" Betreff: [FieldTrip] problem with ft_multiplot and planar gradient ? >Hi everybody, >I have a problem that impacts several analysis steps and I'm hoping >someone can point me to the right direction. > >I have 13 recording sessions, that I want to average, and then I want >to compute the planar gradients of the average. I first average the >sessions with ft_timelockanalysis for each session. Then I use >ft_timelockgrandaverage to combine the sessions. >Then, just to check the data, I plot the ERFs with ft_multiplotER. >This is when the first problem arises. The x and y axes of the plots >are shifted in space somehow (see picture 3.png). >Next, I compute the planar gradients. When I plot the topographies >for the planar gradient, I get a very strange activation pattern, >that has nothing to do with the ERF topography (which, btw has no >obvious flaws) and I also get several warnings when I make the plot >(Picture4.png). > >I also know for a fact that the grand average planar gradient should >look different, as I computed it once before by hand, and it looked >much more sensible. > >If anyone has ever seen this before and can give me a hint as to >where to look for the error, I would be very grateful. > >Luisa > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From l.frei at psy.gla.ac.uk Fri Feb 4 11:43:59 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 4 Feb 2011 10:43:59 +0000 Subject: [FieldTrip] =?utf-8?q?=5BSPAM=3F=5D_Re=3A__problem_with_ft=5Fmult?= =?utf-8?q?iplot_and_planar_gradient__=EF=BF=BC?= In-Reply-To: <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> References: <002601cbc3ae$47118f10$d534ad30$@Rossiter@ion.ucl.ac.uk>, <9342E823-7571-408D-89AB-FF826DF77CF4@psy.gla.ac.uk> <897631264.6723975.1296812875674.JavaMail.fmail@mwmweb055> Message-ID: <6E28D7B8-BFE7-44D9-93C4-5DDEF50D52A0@psy.gla.ac.uk> Thanks Michael and Jan-Mathijs, this is very useful information. I do all the averaging before computing the gradients. However, to resolve this I have to admit that I found a bug in my code last night and after fixing it, it looked fine. Thanks for your help! Luisa On 4 Feb 2011, at 09:47, Michael Wibral wrote: > Dear Luisa, > > I was also wondering whether you were aware of the fact that planar > gradients of group data can look very different depending on when > you do the averaging and the megplanar/combineplanar steps. This is > because combineplanar is a nonlinear step that cannot be exchanged > with the other steps without changing the results. > So creating planar gradients in single trials and then using > combineplanar and then averaging trials within subjects and then > over subjects will look pretty different from doing all averaging > first (trials, subjects) and then using megplanar/combineplanar to > get an planar gradient representation of this average. > > Michael > > > -----Ursprüngliche Nachricht----- > Von: "Luisa Frei" > Gesendet: Feb 3, 2011 7:07:44 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: [FieldTrip] problem with ft_multiplot and planar gradient ? > >> Hi everybody, >> I have a problem that impacts several analysis steps and I'm hoping >> someone can point me to the right direction. >> >> I have 13 recording sessions, that I want to average, and then I want >> to compute the planar gradients of the average. I first average the >> sessions with ft_timelockanalysis for each session. Then I use >> ft_timelockgrandaverage to combine the sessions. >> Then, just to check the data, I plot the ERFs with ft_multiplotER. >> This is when the first problem arises. The x and y axes of the plots >> are shifted in space somehow (see picture 3.png). >> Next, I compute the planar gradients. When I plot the topographies >> for the planar gradient, I get a very strange activation pattern, >> that has nothing to do with the ERF topography (which, btw has no >> obvious flaws) and I also get several warnings when I make the plot >> (Picture4.png). >> >> I also know for a fact that the grand average planar gradient should >> look different, as I computed it once before by hand, and it looked >> much more sensible. >> >> If anyone has ever seen this before and can give me a hint as to >> where to look for the error, I would be very grateful. >> >> Luisa >> >> >> >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From sburns at nmr.mgh.harvard.edu Fri Feb 4 17:12:46 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Fri, 4 Feb 2011 11:12:46 -0500 Subject: [FieldTrip] FT doesn't close .fif files Message-ID: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> FieldTrip Experts - I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgroppe at cogsci.ucsd.edu Mon Feb 7 16:48:40 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Mon, 7 Feb 2011 10:48:40 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? Message-ID: Hi fieldtrippers, I'm a little bit confused about the meaning of the cluster-based permutation test parameter 'minnbchan'. I understand the rationale for the parameter, but based on the tutorial description: "The value of cfg.minnbchan is a tuning parameter that determines the way the clusters are formed. More specifically, we use cfg.minnbchan to specify the minimum number of neighborhood channels that is required for a selected sample (i.e., a sample who's T-value exceeds the threshold) to be included in the clustering algorithm. With cfg.minnbchan = 0 (the default), it sometimes happens that two clusters are spatially connected via a narrow bridge of samples. Because they are connected, these two clusters are considered as a single cluster. If clusters are interpreted as reflecting spatially distinct sources, such a combined cluster does not make much sense. To suppress this type of combined clusters, one can choose to ignore all selected samples (on the basis of their T-values) if they have less than some minimum number of neighbors that were also selected. This minimum number is assigned to cfg.minnbchan. This number must be chosen independently of the data." I can't tell if "minimum number of neighbors" means just spatial neighbors (i.e., nearby sensors) or if includes temporal and frequency neighbors as well. Could someone clarify? Also, just to be clear, if I want to be able to detect an effect that I think is at only a single electrode, I should set minnbchan to 0, yes? If understand the parameter correctly, any greater value of minnbchan will ignore clusters that are restricted to a single electrode. thanks for your help, -David -- David Groppe, Ph.D. dgroppe at cogsci.ucsd.edu http://www.cogsci.ucsd.edu/~dgroppe/ From tom_campbell75 at hotmail.com Tue Feb 8 04:26:26 2011 From: tom_campbell75 at hotmail.com (Tom Campbell) Date: Tue, 8 Feb 2011 03:26:26 +0000 Subject: [FieldTrip] depsamplesF In-Reply-To: <001001cbbecf$dc470260$94d50720$@maris@donders.ru.nl> References: , <6FF942DE-E2EC-47D0-BC81-CEDCD9B12410@graphicmind.info> , <001001cbbecf$dc470260$94d50720$@maris@donders.ru.nl> Message-ID: Dear Eric, Thank you very much for these helpful suggestions. Plotting the suggested difference waves was rather enlightening. Best regards, Tom. From: e.maris at donders.ru.nl To: tom_campbell75 at hotmail.com; fieldtrip at donders.ru.nl Subject: RE: [FieldTrip] depsamplesF Date: Fri, 28 Jan 2011 10:43:42 +0100 Hi Tom, To test main and interaction effects in your 2x2 within subjects design, you have to perform 3 tests, each using the statfun desamplesT. Say you have the output of ft_timelockanalysis for all four conditions: tlout_Ia, tlout_Ib, tlout_IIa, tlout_IIb. Your then proceed as follows: 1. Main effect of I versus II: calculate the mean of tlout_Ia.avg and tlout_Ib.avg and put this is a a new struct variable tlout_I, which has the same fields as tlout_Ia and tlout_Ib. Do the same with tlout_IIa.avg and tlout_IIb.avg and make a new struct variable tlout_II. Then run ft_timelockstatistics with input arguments tlout_I and tlout_II. With this analysis you will test the main effect of I-versus-II. 2. In the same way, you now test the main effect of a versus b. In your calculations, the roles of (I,II) and (a,b) are now reversed. 3. Interaction of I-vs-II and a-vs-b. Calculate the differences (tlout_Ia.avg-tlout_Ib.avg) and (tlout_IIa.avg-tlout_IIb.avg), put them in output structures and statistically compare them using ft_timelockstatistics. With this analysis, you test the interaction of I-vs-II and a-vs-b. There is no need for Bonferroni correction or an adjustment of cfg.clusteralpha (which does not affect the false alarm rate anyhow) and cfg.alpha. Best, Eric Mari Thank you very much for this helpful advice Olga. That would have also been my impression until I found this discussion between Maya Zuckerman and Eric Maris: http://mailman.science.ru.nl/pipermail/fieldtrip/2010-December/003335.html http://mailman.science.ru.nl/pipermail/fieldtrip/2010-December/003338.html , which I may have misunderstood. I can see from the list that people are interested in using depsampleF to investigate interactions between two independent variables (e.g., background: I,II x stimulus: a,b) in experiments with multiple participants. I can also see a several people have had problems with this. Given for datasets I_a, I_b, II_a, II_b I'd like to do something like: cfg.design =????; ... cfg.statistic ='depsamplesF'; ... [stat] = ft_timelockstatistics(cfg, I_a, I_b, II_a, II_b); to find the tests of of main effect clusters for each factor and interaction clusters. How to specify up cfg.design could be one of the problems, as could be what other cfg parameters need to be specified. I may be barking up completely the wrong tree. Assuming the interaction is significant, there are 4 differences that would be of theoretical interest: I_a vs I_b, II_a vs II_b,I_a vs II_a,I_b vs II_b). For instance, a "classical" interaction might exhibit the abolition of significance of an effect ab seen at I at level II of that factor. So, if I understand the Zuckerman-Maris dialogue, if I used the permutation test to test such I_a vd II_b differences as in the tutorial: cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.minnbchan = 2; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 500; ... [I_avsb_stat] = ft_timelockstatistics(cfg, I_a, I_b); [II_avsb_stat] = ft_timelockstatistics(cfg, II_a, II_b); [IvsII_a_stat] = ft_timelockstatistics(cfg, I_a, II_a); [IvsII_b_stat] = ft_timelockstatistics(cfg, I_a, II_b); ,I may have to either do some bonferonni correction: -at the cluster level (cluster.alpha) -or at the level at which each t-test can be included in a cluster (cfg.alpha). Please would you verify which, if at all? If I am testing 4 such differences with 4 permutation tests then if the bonferroni correction is to be at the cluster level, please should the correction depend upon the number of clusters as well as the number of such differences tested? Please, I look forward to any clarifications. With best regards, Tom Campbell. From: olga at graphicmind.info To: tom_campbell75 at hotmail.com; fieldtrip at donders.ru.nl Subject: Re: [FieldTrip] depsamplesF Date: Thu, 27 Jan 2011 06:16:51 +0300 Hi, Tom, I guess if you do cluster analysis, which is based on permutation tests you do not need any correction like. Cluster-based statistics just deal with multiple comparison problem differently (Monte-Carlo randomization, permutation tests and examine the probability of your cluster among the random ones). Clusters may be formed based on time, space/frequency adjacency. Best Regards, Olga. On 27.01.2011, at 2:26, Tom Campbell wrote: Dear Eric Maris, Robert Oostenveld and colleagues, I write with some queries with reference to your previous correspondence on the Fieldtrip listserv and would very much appreciate if you could please answer them. I am trying to use Fieldtrip to analyse timelocked ERP data from what is a 16(participant: [1:16]) X2(Background: congruent, incongruent)x2(Stimulus: Animal, Vehicle) design. The code seems to runing well treating this as a 16(participant: [1:16]) X4(Visual stimulus: animal-congruent background, animal-incongruent background, vehicle-congruent, vehicle-incongruent )design with 4 conditions, though I haven't looked at the results of the tests yet. If I then run cluster analyses of differences of theoretical interest via depsamplest, please how would I bonferroni correct? I am interested in what clusters exist in the background and stimulus main effects and their background X stimulus interaction. Please is this possible in fieldtrip to use depsamplesF to work with a Participant X "2-way" design? Best regards, Tom Campbell. _______________________________________________ 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 e.maris at donders.ru.nl Tue Feb 8 07:17:34 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 8 Feb 2011 07:17:34 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: Message-ID: <018101cbc757$e058f6c0$a10ae440$@maris@donders.ru.nl> Dear David, > I can't tell if "minimum number of neighbors" means just spatial > neighbors (i.e., nearby sensors) or if includes temporal and frequency > neighbors as well. Could someone clarify? It means ONLY spatial neighbors. > Also, just to be clear, if I want to be able to detect an effect that > I think is at only a single electrode, I should set minnbchan to 0, > yes? If understand the parameter correctly, any greater value of > minnbchan will ignore clusters that are restricted to a single > electrode. No, with minnbchan=0, there are no constraints on the clusters. If you want clusters to be local (as opposed to stretched over a large part of the scalp), minnbchan should be given a high value. Best, Eric dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > thanks for your help, > -David > > > -- > David Groppe, Ph.D. > dgroppe at cogsci.ucsd.edu > http://www.cogsci.ucsd.edu/~dgroppe/ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From dgroppe at cogsci.ucsd.edu Tue Feb 8 15:18:07 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Tue, 8 Feb 2011 09:18:07 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <-132249673793097681@unknownmsgid> References: <-132249673793097681@unknownmsgid> Message-ID: On Tue, Feb 8, 2011 at 1:17 AM, Eric Maris wrote: > Dear David, > > >> I can't tell if "minimum number of neighbors" means just spatial >> neighbors (i.e., nearby sensors) or if includes temporal and frequency >> neighbors as well.  Could someone clarify? > > It means ONLY spatial neighbors. > >> Also, just to be clear, if I want to be able to detect an effect that >> I think is at only a single electrode, I should set minnbchan to 0, >> yes?  If understand the parameter correctly, any greater value of >> minnbchan will ignore clusters that are restricted to a single >> electrode. > > No, with minnbchan=0, there are no constraints on the clusters. If you want > clusters to be local (as opposed to stretched over a large part of the > scalp), minnbchan should be given a high value. Thanks very much for the email Eric, but I'm confused as to why you answered "No" to my second comment. From what I understand, if you use a value of minnbchan that is greater than 0, then any significant clusters will necessarily spread across multiple electrodes. For example, if you set minnbchan to 1, then all significant clusters will have to include at least two electrodes so that each significant "voxel" has at least one neighbor at another electrode. Thus, if your effect is truly at only a single electrode, having a value of minnbchan greater than 0 will force you to miss the effect or to think it occurs at more electrodes than it really does. What part of my reasoning is incorrect? again, thanks very much for the help, -David > Best, > > Eric > > > dr. Eric Maris > Donders Institute for Brain, Cognition and Behavior > Radboud University > P.O. Box 9104 > 6500 HE Nijmegen > The Netherlands > T:+31 24 3612651 > Mobile: 06 39584581 > F:+31 24 3616066 > mailto:e.maris at donders.ru.nl > http://www.nphyscog.com/ > > > > > > > > >>     thanks for your help, >>         -David >> >> >> -- >> David Groppe, Ph.D. >> dgroppe at cogsci.ucsd.edu >> http://www.cogsci.ucsd.edu/~dgroppe/ >> _______________________________________________ >> 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 > -- David Groppe, Ph.D. Postdoctoral Researcher Kutaslab Dept. of Cognitive Science University of California, San Diego http://www.cogsci.ucsd.edu/~dgroppe/ From fredericroux at hotmail.de Tue Feb 8 16:16:56 2011 From: fredericroux at hotmail.de (Frederic Roux) Date: Tue, 8 Feb 2011 16:16:56 +0100 Subject: [FieldTrip] single trial beamforming Message-ID: Dear list-members, I would like to compute a common frequency specific DICS spatial filter for my baseline and post-stimulus time window as an average across trials, and then use this filter on a trial by trial basis to do the beam-forming for the baseline and post-stimulus time window separately. The reason is that I would like to localize the generators of sustained task-related beta-band activity (1.2 seconds). The code I am planning to use looks as follows: cfg = []; cfg.channel = {'MEG' '-MLP12' '-MLT41' '-MRC12' '-MRC14' '-MRC25' '-MRP56' '-MRT21' '-MLT57' '-MLT52' '-MRF22' '-MRF13' '-MRF24' '-MRF43' '-MLO22' '-MLF25' '-MRO31' '-MRO21'}; cfg.grid = warped_grid.grid; cfg.vol = warped_grid.hdm; cfg.frequency = 15; cfg.method = 'dics'; cfg.projectnoise = 'yes'; cfg.keepfilter = 'yes'; cfg.lambda = 0.05; cfg.dim = [Nx Ny Nz]; cfg.rawtrial = 'no'; cfg.keeptrials = 'no'; [common_filt] = sourceanalysis(cfg,common_TF); cfg.grid.filter = common_filt.avg.filter; cfg.rawtrial = 'yes'; cfg.keeptrials = 'yes'; [pre_source] = sourceanalysis(cfg,pre_TF) [post_source] =sourceanalysis(cfg,post_TF); Can anyone tell me if this code would be ok? I am not sure if is correct to specify the cfg.rawtrial = 'yes' option. Any help would be appreciated. Thanks, fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Tue Feb 8 16:33:25 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Tue, 8 Feb 2011 15:33:25 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> Message-ID: <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Hi Scott - Thanks for the e-mail - it's a good point. The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. Unless you can think of a better solution, my suggestion would be first to call hdr=ft_read_header(fname); in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with fclose(hdr.orig.raw.fid); Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. Cheers, Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 4 Feb 2011, at 16:12, Scott Burns wrote: > FieldTrip Experts - > > I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. > > I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. > > I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. > > FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). > > > Scott Burns > Kuperberg Lab > Martinos Center for Biomedical Imaging > sburns at nmr.mgh.harvard.edu > > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > _______________________________________________ > 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 e.maris at donders.ru.nl Tue Feb 8 17:01:46 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 8 Feb 2011 17:01:46 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: <-132249673793097681@unknownmsgid> Message-ID: <01d801cbc7a9$7ca7e710$75f7b530$@maris@donders.ru.nl> Dear David, > Thanks very much for the email Eric, but I'm confused as to why you > answered "No" to my second comment. From what I understand, if you > use a value of minnbchan that is greater than 0, then any significant > clusters will necessarily spread across multiple electrodes. For > example, if you set minnbchan to 1, then all significant clusters will > have to include at least two electrodes so that each significant > "voxel" has at least one neighbor at another electrode. Thus, if your > effect is truly at only a single electrode, having a value of > minnbchan greater than 0 will force you to miss the effect or to think > it occurs at more electrodes than it really does. What part of my > reasoning is incorrect? Your reasoning is correct and mine was incorrect. I should read better before I write. My apologies for this. I do have to qualify that with minnbchan=0 it may also happen that your significant cluster contains more than one electrode (the electrode with the true effect plus some surrounding ones that by accident exceed the threshold that is used to identify clusters). Best, Eric > again, thanks very much for the help, > -David > > > > Best, > > > > Eric > > > > > > dr. Eric Maris > > Donders Institute for Brain, Cognition and Behavior > > Radboud University > > P.O. Box 9104 > > 6500 HE Nijmegen > > The Netherlands > > T:+31 24 3612651 > > Mobile: 06 39584581 > > F:+31 24 3616066 > > mailto:e.maris at donders.ru.nl > > http://www.nphyscog.com/ > > > > > > > > > > > > > > > > > >>     thanks for your help, > >>         -David > >> > >> > >> -- > >> David Groppe, Ph.D. > >> dgroppe at cogsci.ucsd.edu > >> http://www.cogsci.ucsd.edu/~dgroppe/ > >> _______________________________________________ > >> 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 > > > > > > -- > David Groppe, Ph.D. > Postdoctoral Researcher > Kutaslab > Dept. of Cognitive Science > University of California, San Diego > http://www.cogsci.ucsd.edu/~dgroppe/ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From dgroppe at cogsci.ucsd.edu Tue Feb 8 19:18:59 2011 From: dgroppe at cogsci.ucsd.edu (David Groppe) Date: Tue, 8 Feb 2011 13:18:59 -0500 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <2657614842150526102@unknownmsgid> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid> Message-ID: On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris wrote: > Dear David, > > >> Thanks very much for the email Eric, but I'm confused as to why you >> answered "No" to my second comment.  From what I understand, if you >> use a value of minnbchan that is greater than 0, then any significant >> clusters will necessarily spread across multiple electrodes.  For >> example, if you set minnbchan to 1, then all significant clusters will >> have to include at least two electrodes so that each significant >> "voxel" has at least one neighbor at another electrode.  Thus, if your >> effect is truly at only a single electrode, having a value of >> minnbchan greater than 0 will force you to miss the effect or to think >> it occurs at more electrodes than it really does.  What part of my >> reasoning is incorrect? > > Your reasoning is correct and mine was incorrect. I should read better > before I write. My apologies for this. Got it. Thanks very much for clarifying Eric. > > I do have to qualify that with minnbchan=0 it may also happen that your > significant cluster contains more than one electrode (the electrode with the > true effect plus some surrounding ones that by accident exceed the threshold > that is used to identify clusters). That makes perfect sense. Since our lab uses only a limited number of electrodes (32), I wanted to make sure I understood the minimum number of electrodes an effect needs to span to be detected. once again, I very much appreciate your answers to my questions, -David > Best, > > Eric > > > > >>      again, thanks very much for the help, >>             -David >> >> >> > Best, >> > >> > Eric >> > >> > >> > dr. Eric Maris >> > Donders Institute for Brain, Cognition and Behavior >> > Radboud University >> > P.O. Box 9104 >> > 6500 HE Nijmegen >> > The Netherlands >> > T:+31 24 3612651 >> > Mobile: 06 39584581 >> > F:+31 24 3616066 >> > mailto:e.maris at donders.ru.nl >> > http://www.nphyscog.com/ >> > >> > >> > >> > >> > >> > >> > >> > >> >>     thanks for your help, >> >>         -David >> >> >> >> >> >> -- >> >> David Groppe, Ph.D. >> >> dgroppe at cogsci.ucsd.edu >> >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> David Groppe, Ph.D. >> Postdoctoral Researcher >> Kutaslab >> Dept. of Cognitive Science >> University of California, San Diego >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >> _______________________________________________ >> 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 > -- David Groppe, Ph.D. Postdoctoral Researcher Kutaslab Dept. of Cognitive Science University of California, San Diego http://www.cogsci.ucsd.edu/~dgroppe/ From r.oostenveld at donders.ru.nl Wed Feb 9 10:25:13 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 9 Feb 2011 10:25:13 +0100 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> Message-ID: <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Dear Scott, thanks for reporting this problem and for already tracking it down to files not being closed. ft_read_data does the following on every read-request (line 772), case {'neuromag_fif' 'neuromag_mne'} % check that the required low-level toolbox is available ft_hastoolbox('mne', 1); if (hdr.orig.iscontinuous) dat = fiff_read_raw_segment(hdr.orig.raw,begsample+hdr.orig.raw.first_samp-1,endsample+hdr.orig.raw.first_samp-1,chanindx); from this I understand that the file is already supposed to be open and represented in hdr.orig.raw (hdr.orig is in general where fieldtrip stores the original header details, i.e. including all system specific information). and prior to that it does (line 223) % read the header if it is not provided if isempty(hdr) hdr = ft_read_header(filename, 'headerformat', headerformat); end I would expect the part on ft_read_header not to be executed on every call to ft_read_data, because in general ft_read_header has already been called outside ft_read_data (e.g. to select the channels prior to start the reading). So ft_preprocessing calls ft_read_header once and ft_read_data many times. and in ft_read_header it does orig = fiff_read_meas_info(filename); and raw = fiff_setup_read_raw(filename); Diagnosis: ft_read_header opens the file, ft_read_data keeps it open. Then you move to the next file, and that one is also opened (and kept open). Hmm, indeed a problem. The design idea is that reading from files shoudl be stateless, i.e. prior and after each read operation the file should be closed. On modern file systems there is no penalty associated with that, and it keeps the code much cleaner. That is why fieldtrip does not have a ft_open_file and ft_close_file function, and why you cannot close the file (except with fclose('all')). Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw are supposed to keep the files open? I could not find a fiff_close function, do you know whether there is one? best Robert PS let's do the follow up discussion via the bug tracking system and not on the email list... you should have received a mail from that by now. On 4 Feb 2011, at 17:12, Scott Burns wrote: > FieldTrip Experts - > > I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. > > I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. > > I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. > > FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). > > > Scott Burns > Kuperberg Lab > Martinos Center for Biomedical Imaging > sburns at nmr.mgh.harvard.edu > > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > _______________________________________________ > 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 r.oostenveld at donders.ru.nl Wed Feb 9 10:43:55 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Wed, 9 Feb 2011 10:43:55 +0100 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Message-ID: Hi Laurence thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. best Robert On 8 Feb 2011, at 16:33, Laurence Hunt wrote: > Hi Scott - > > Thanks for the e-mail - it's a good point. > > The difficulty arises because fiff_setup_read_raw (called by > ft_read_header) leaves the .fif file open to be read (it stores the > fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for > fieldtrip). Unfortunately if we closed it at this stage (i.e. within > ft_read_header), fiff_read_raw_segment, which is called by > ft_read_data/ft_read_event, doesn't know where to look for the file > - it expects a structure to be returned by fiff_setup_read_raw with > an open file. Again, we could close the file after calling > fiff_read_raw_segment in ft_read_data, but this would assume that > ft_read_data/ft_read_event is only going to be called once, whereas > some users might want to use hdr=ft_read_header once and then keep > on using ft_read_data with same hdr structure, in which case we need > to keep the file open. > > Unless you can think of a better solution, my suggestion would be > first to call > > hdr=ft_read_header(fname); > > in your script, then supply this hdr to your calls to ft_read_event/ > ft_read_data (this should hopefully prevent the file being opened > multiple times), and then once you have done all the reading, close > that file with > > fclose(hdr.orig.raw.fid); > > Hopefully that will stop you clogging up matlab with open files. Let > me know if it works or not. > > Cheers, > Laurence > > =========================================== > Laurence Hunt, DPhil Student > Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > > On 4 Feb 2011, at 16:12, Scott Burns wrote: > >> FieldTrip Experts - >> >> I'm building a FieldTrip pipeline for use on M/EEG data collected >> on a Neuromag 306 system. Because I'm looping over subjects (13 >> currently), event type (5 unique events), and number of runs (4), >> there's lots of preprocessing to do. After processing a certain >> amount of files, MATLAB refuses to open more files. >> >> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only >> include the data files I'm using, not MATLAB's system files) and >> found that for every innermost loop, my script is opening the .fif >> file twice and not releasing it. I use a custom function for >> ft_definetrial and in that I use ft_read_event (that operates on >> the .fif file). After defining trials, I use ft_preprocessing. >> >> I would venture to guess that both ft_read_event and ft_read_data >> (ft_preprocessing:line 492) are either 1) not closing files they've >> opened (presumably through MNE functions), or 2) they're using >> shared code that doesn't close files. I use MNE and haven't run >> into this issue before. That being said, fclose('all') does close >> all these files but I think it's still worth looking into. >> >> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >> >> >> Scott Burns >> Kuperberg Lab >> Martinos Center for Biomedical Imaging >> sburns at nmr.mgh.harvard.edu >> >> The information in this e-mail is intended only for the person to >> whom it is addressed. If you believe this e-mail was sent to you in >> error and the e-mail contains patient information, please contact >> the Partners Compliance HelpLine at http://www.partners.org/complianceline >> . If the e-mail was sent to you in error but does not contain >> patient information, please contact the sender and properly dispose >> of the e-mail. >> >> >> >> >> _______________________________________________ >> 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 lhunt at fmrib.ox.ac.uk Wed Feb 9 13:21:07 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 12:21:07 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> Message-ID: <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> Hi Robert, (i) Re-running fiff_setup_read_raw in ft_read_data might slow down operations with multiple calls to ft_read_data (e.g. reading multiple trials from a raw dataset), as it takes about half a second to execute fiff_setup_read_raw once. (ii) Just using fopen and fclose would be much faster, but fiff_setup_read_raw does indeed move the file cursor to a new position, so I think the best solution is to store this position after the file has been opened by fiff_setup_read_raw. So, within ft_read_header, add: raw.pos = ftell(raw.fid); fclose(raw.fid); and in ft_read_data, add hdr.orig.raw.fid = fopen(filename,'rb','ieee-be'); fseek(hdr.orig.raw.fid,hdr.orig.raw.pos,'bof'); before the call to fiff_read_raw_segment, and fclose it afterwards. This seems to work fine if I make these amendments to my version of the code. Hope this helps, Laurence On 9 Feb 2011, at 09:43, Robert Oostenveld wrote: > Hi Laurence > > thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. > > Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? > > If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). > > Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). > > What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. > > best > Robert > > > > On 8 Feb 2011, at 16:33, Laurence Hunt wrote: > >> Hi Scott - >> >> Thanks for the e-mail - it's a good point. >> >> The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. >> >> Unless you can think of a better solution, my suggestion would be first to call >> >> hdr=ft_read_header(fname); >> >> in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with >> >> fclose(hdr.orig.raw.fid); >> >> Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. >> >> Cheers, >> Laurence >> >> =========================================== >> Laurence Hunt, DPhil Student >> Centre for Functional MRI of the Brain (FMRIB), >> University of Oxford >> lhunt at fmrib.ox.ac.uk >> Phone: (+44)1865-(2)22738 >> =========================================== >> >> On 4 Feb 2011, at 16:12, Scott Burns wrote: >> >>> FieldTrip Experts - >>> >>> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >>> >>> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >>> >>> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >>> >>> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >>> >>> >>> Scott Burns >>> Kuperberg Lab >>> Martinos Center for Biomedical Imaging >>> sburns at nmr.mgh.harvard.edu >>> >>> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Wed Feb 9 13:22:18 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 12:22:18 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <908475EE-E8CC-4904-9283-9B6BFD499603@fmrib.ox.ac.uk> <83DF9CAE-4726-4F3A-BC25-E3FA20B34ED7@fmrib.ox.ac.uk> Message-ID: p.s. I think this only applies to continuous data - evoked responses are closed in ft_read_header already, I think. L On 9 Feb 2011, at 12:21, Laurence Hunt wrote: > Hi Robert, > > (i) Re-running fiff_setup_read_raw in ft_read_data might slow down operations with multiple calls to ft_read_data (e.g. reading multiple trials from a raw dataset), as it takes about half a second to execute fiff_setup_read_raw once. > > (ii) Just using fopen and fclose would be much faster, but fiff_setup_read_raw does indeed move the file cursor to a new position, so I think the best solution is to store this position after the file has been opened by fiff_setup_read_raw. So, within ft_read_header, add: > > raw.pos = ftell(raw.fid); > fclose(raw.fid); > > and in ft_read_data, add > > hdr.orig.raw.fid = fopen(filename,'rb','ieee-be'); > fseek(hdr.orig.raw.fid,hdr.orig.raw.pos,'bof'); > > before the call to fiff_read_raw_segment, and fclose it afterwards. This seems to work fine if I make these amendments to my version of the code. > > Hope this helps, > Laurence > > On 9 Feb 2011, at 09:43, Robert Oostenveld wrote: > >> Hi Laurence >> >> thanks for the reply to Scott. I had typed my email on the train yesterday evening (while offline) and sent it out this morning, without checking whether there was any news. >> >> Does fiff_setup_read_raw take a significant amount of time? I.e. is there a severe performance impact if we would call it on each ft_read_data and fclose also on each call? >> >> If Scott follows standard FieldTrip practise, he could very well call ft_read_header in his script but he cannot pass the hdr into the subsequent ft_read_data calls (because those are done by ft_preprocessing, which will read it's own copy of the header info anyway). >> >> Is the position of the file pointer relevant in the subsequent calls to ft_read_data? If not, then we could also do a plain fopen instead of fiff_setup_read_raw on subsequent calls to ft_read_data and also fclose on each call. A fopen/fseek/fclose does not take any measurable time on a modern operating system and file system (because the file is read-cached in memory anyway) and the advantage of the stateless implementation is worth more than lossing a milisecond on an operation that takes a second or more anyway (which is reading the actual data data and pumping it to memory). >> >> What we could also do (alternative to the two options above) is to have a persistent variable for the filename and for the fid in ft_read_header. Using those, it could close the previous file it it detects that a new file is opened. >> >> best >> Robert >> >> >> >> On 8 Feb 2011, at 16:33, Laurence Hunt wrote: >> >>> Hi Scott - >>> >>> Thanks for the e-mail - it's a good point. >>> >>> The difficulty arises because fiff_setup_read_raw (called by ft_read_header) leaves the .fif file open to be read (it stores the fid in its output structure raw.fid, i.e. hdr.orig.raw.fid for fieldtrip). Unfortunately if we closed it at this stage (i.e. within ft_read_header), fiff_read_raw_segment, which is called by ft_read_data/ft_read_event, doesn't know where to look for the file - it expects a structure to be returned by fiff_setup_read_raw with an open file. Again, we could close the file after calling fiff_read_raw_segment in ft_read_data, but this would assume that ft_read_data/ft_read_event is only going to be called once, whereas some users might want to use hdr=ft_read_header once and then keep on using ft_read_data with same hdr structure, in which case we need to keep the file open. >>> >>> Unless you can think of a better solution, my suggestion would be first to call >>> >>> hdr=ft_read_header(fname); >>> >>> in your script, then supply this hdr to your calls to ft_read_event/ft_read_data (this should hopefully prevent the file being opened multiple times), and then once you have done all the reading, close that file with >>> >>> fclose(hdr.orig.raw.fid); >>> >>> Hopefully that will stop you clogging up matlab with open files. Let me know if it works or not. >>> >>> Cheers, >>> Laurence >>> >>> =========================================== >>> Laurence Hunt, DPhil Student >>> Centre for Functional MRI of the Brain (FMRIB), >>> University of Oxford >>> lhunt at fmrib.ox.ac.uk >>> Phone: (+44)1865-(2)22738 >>> =========================================== >>> >>> On 4 Feb 2011, at 16:12, Scott Burns wrote: >>> >>>> FieldTrip Experts - >>>> >>>> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >>>> >>>> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >>>> >>>> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >>>> >>>> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >>>> >>>> >>>> Scott Burns >>>> Kuperberg Lab >>>> Martinos Center for Biomedical Imaging >>>> sburns at nmr.mgh.harvard.edu >>>> >>>> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > =========================================== > Laurence Hunt, DPhil Student > Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From sburns at nmr.mgh.harvard.edu Wed Feb 9 16:27:14 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 10:27:14 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: <9F93CD03-78CC-4D03-BF55-239D5D12EFD0@nmr.mgh.harvard.edu> I tried replying to the latest email from the bug tracker but got back a Delivery Failure. What'd I do wrong? (the error was the bugzilla_daemon at fcdonders.ru.nl is an unknown or illegal alias) Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. On Feb 9, 2011, at 4:25 AM, Robert Oostenveld wrote: > Dear Scott, > > thanks for reporting this problem and for already tracking it down to files not being closed. > > ft_read_data does the following on every read-request (line 772), > case {'neuromag_fif' 'neuromag_mne'} > % check that the required low-level toolbox is available > ft_hastoolbox('mne', 1); > if (hdr.orig.iscontinuous) > dat = fiff_read_raw_segment(hdr.orig.raw,begsample+hdr.orig.raw.first_samp-1,endsample+hdr.orig.raw.first_samp-1,chanindx); > > from this I understand that the file is already supposed to be open and represented in hdr.orig.raw (hdr.orig is in general where fieldtrip stores the original header details, i.e. including all system specific information). > > and prior to that it does (line 223) > % read the header if it is not provided > if isempty(hdr) > hdr = ft_read_header(filename, 'headerformat', headerformat); > end > > I would expect the part on ft_read_header not to be executed on every call to ft_read_data, because in general ft_read_header has already been called outside ft_read_data (e.g. to select the channels prior to start the reading). So ft_preprocessing calls ft_read_header once and ft_read_data many times. > > and in ft_read_header it does > orig = fiff_read_meas_info(filename); > and > raw = fiff_setup_read_raw(filename); > > Diagnosis: ft_read_header opens the file, ft_read_data keeps it open. Then you move to the next file, and that one is also opened (and kept open). Hmm, indeed a problem. The design idea is that reading from files shoudl be stateless, i.e. prior and after each read operation the file should be closed. On modern file systems there is no penalty associated with that, and it keeps the code much cleaner. That is why fieldtrip does not have a ft_open_file and ft_close_file function, and why you cannot close the file (except with fclose('all')). > > Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw are supposed to keep the files open? I could not find a fiff_close function, do you know whether there is one? > > best > Robert > > PS let's do the follow up discussion via the bug tracking system and not on the email list... you should have received a mail from that by now. > > > On 4 Feb 2011, at 17:12, Scott Burns wrote: > >> FieldTrip Experts - >> >> I'm building a FieldTrip pipeline for use on M/EEG data collected on a Neuromag 306 system. Because I'm looping over subjects (13 currently), event type (5 unique events), and number of runs (4), there's lots of preprocessing to do. After processing a certain amount of files, MATLAB refuses to open more files. >> >> I ran 'lsof MATLAB | grep "/autofs/cluster/kuperberg/" (to only include the data files I'm using, not MATLAB's system files) and found that for every innermost loop, my script is opening the .fif file twice and not releasing it. I use a custom function for ft_definetrial and in that I use ft_read_event (that operates on the .fif file). After defining trials, I use ft_preprocessing. >> >> I would venture to guess that both ft_read_event and ft_read_data (ft_preprocessing:line 492) are either 1) not closing files they've opened (presumably through MNE functions), or 2) they're using shared code that doesn't close files. I use MNE and haven't run into this issue before. That being said, fclose('all') does close all these files but I think it's still worth looking into. >> >> FWIW I'm using CentOS 5 and MATLAB R2010B (glnxa64). >> >> >> Scott Burns >> Kuperberg Lab >> Martinos Center for Biomedical Imaging >> sburns at nmr.mgh.harvard.edu >> >> The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. >> >> >> >> >> _______________________________________________ >> 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 gramfort at nmr.mgh.harvard.edu Wed Feb 9 16:31:02 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 10:31:02 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi, > The design idea is that reading from files shoudl be > stateless, i.e. prior and after each read operation the file should be > closed. On modern file systems there is no penalty associated with that, and > it keeps the code much cleaner. That is why fieldtrip does not have a > ft_open_file and ft_close_file function, and why you cannot close the file > (except with fclose('all')). > Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw > are supposed to keep the files open? I could not find a fiff_close function, > do you know whether there is one? fiff_setup_read_raw keeps the files open for subsequent calls of fiff_read_raw_segment, fiff_read_raw_segment_times etc. when done the file can be closed with : fclose(raw.fid) assuming you used: raw = fiff_setup_read_raw(filename); FYI (I wanted to wait but it seems to be a good occasion) the mne-matlab code is now publicly hosted on line: https://github.com/mne-tools/mne-matlab latest commits: https://github.com/mne-tools/mne-matlab/commits/master the license of this code has been changed to BSD. If you have feature request, bug reports or willing to contribute some code that's a good place to do it. If you need help, just send me an email. If fieldtripers turn out to modify the mne matlab code it would be great to consider applying the modifications on the main repository. Alex -- Alexandre Gramfort, PhD gramfort at nmr.mgh.harvard.edu Dept. of Radiology MGH Martinos Center / Harvard Medical School http://www-sop.inria.fr/members/Alexandre.Gramfort/ From v.litvak at ion.ucl.ac.uk Wed Feb 9 16:54:29 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 15:54:29 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi Alexandre, So why does fiff_setup_read_raw take so long? Do you really need half a second to open a fif file or does it also read some header data not all of which is necessary? Could there perhaps be a faster version for repeated calls that would make it possible to keep fileio code stateless? Vladimir On Wed, Feb 9, 2011 at 3:31 PM, Alexandre Gramfort wrote: > Hi, > >> The design idea is that reading from files shoudl be >> stateless, i.e. prior and after each read operation the file should be >> closed. On modern file systems there is no penalty associated with that, and >> it keeps the code much cleaner. That is why fieldtrip does not have a >> ft_open_file and ft_close_file function, and why you cannot close the file >> (except with fclose('all')). >> Do you happen to know whether fiff_read_meas_info and fiff_setup_read_raw >> are supposed to keep the files open? I could not find a fiff_close function, >> do you know whether there is one? > > fiff_setup_read_raw keeps the files open for subsequent calls of > fiff_read_raw_segment, fiff_read_raw_segment_times etc. > > when done the file can be closed with : > > fclose(raw.fid) > > assuming you used: > raw = fiff_setup_read_raw(filename); > > FYI (I wanted to wait but it seems to be a good occasion) > the mne-matlab code is now publicly hosted on line: > > https://github.com/mne-tools/mne-matlab > > latest commits: > https://github.com/mne-tools/mne-matlab/commits/master > > the license of this code has been changed to BSD. > > If you have feature request, bug reports or willing to contribute some code > that's a good place to do it. If you need help, just send me an email. > > If fieldtripers turn out to modify the mne matlab code it would be great to > consider applying the modifications on the main repository. > > Alex > -- > Alexandre Gramfort, PhD > gramfort at nmr.mgh.harvard.edu > Dept. of Radiology MGH Martinos Center / Harvard Medical School > http://www-sop.inria.fr/members/Alexandre.Gramfort/ > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 17:05:51 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 11:05:51 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: Hi Vladimir, > So why does fiff_setup_read_raw take so long? Do you really need half > a second to open a fif file or does it also read some header data not > all of which is necessary? fiff_setup_read_raw reads many things from the fif file: - measurement info - sampling rate - first/last time sample to do this it locates in the file the location of all the info (the fif tags). So when you look for something in the file, you go down the tree (in matlab) and that points you to the location in the file where to read. > Could there perhaps be a faster version for > repeated calls that would make it possible to keep fileio code > stateless? we could write a single function that does both : fiff_setup_read_raw and fiff_read_raw_segment if it can help. Alex From v.litvak at ion.ucl.ac.uk Wed Feb 9 17:16:19 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 16:16:19 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: The question is if it would be possible to pre-read those fif tags and all the other info and store it in the header, then close the file and then given just the samples to read to open it again and navigate fast to the right place based on the info that has been stored before? Those tags don't change (do they?) so it should be sufficient to read them once. Vladimir On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort wrote: > Hi Vladimir, > >> So why does fiff_setup_read_raw take so long? Do you really need half >> a second to open a fif file or does it also read some header data not >> all of which is necessary? > > fiff_setup_read_raw reads many things from the fif file: > - measurement info > - sampling rate > - first/last time sample > > to do this it locates in the file the location of all the info (the fif tags). > So when you look for something in the file, you go down the tree > (in matlab) and that points you to the location in the file where to read. > >> Could there perhaps be a faster version for >> repeated calls that would make it possible to keep fileio code >> stateless? > > we could write a single function that does both : > fiff_setup_read_raw and fiff_read_raw_segment > if it can help. > > Alex > > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 17:41:05 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 11:41:05 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: the filename is stored raw.info we could close the file after the fiff_setup_read_raw and then do raw.fid = fopen(raw.info.filename) before reading from it later. see my attempt : https://github.com/agramfort/mne-matlab/commit/5a88ef764a5931c14015708d372942ed2f892b6c would this solve your pb? Alex On Wed, Feb 9, 2011 at 11:16 AM, Vladimir Litvak wrote: > The question is if it would be possible to pre-read those fif tags and > all the other info and store it in the header, then close the file and > then given just the samples to read to open it again and navigate fast > to the right place based on the info that has been stored before? > Those tags don't change (do they?) so it should be sufficient to read > them once. > > Vladimir > > On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort > wrote: >> Hi Vladimir, >> >>> So why does fiff_setup_read_raw take so long? Do you really need half >>> a second to open a fif file or does it also read some header data not >>> all of which is necessary? >> >> fiff_setup_read_raw reads many things from the fif file: >> - measurement info >> - sampling rate >> - first/last time sample >> >> to do this it locates in the file the location of all the info (the fif tags). >> So when you look for something in the file, you go down the tree >> (in matlab) and that points you to the location in the file where to read. >> >>> Could there perhaps be a faster version for >>> repeated calls that would make it possible to keep fileio code >>> stateless? >> >> we could write a single function that does both : >> fiff_setup_read_raw and fiff_read_raw_segment >> if it can help. >> >> Alex >> >> > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in error > but does not contain patient information, please contact the sender and properly > dispose of the e-mail. > > From lhunt at fmrib.ox.ac.uk Wed Feb 9 18:35:46 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 17:35:46 +0000 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> Message-ID: <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Hi Alex, I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). So we need to store the cursor position too. See my earlier e-mail. Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 9 Feb 2011, at 16:41, Alexandre Gramfort wrote: > the filename is stored raw.info > > we could close the file after the fiff_setup_read_raw > and then do > raw.fid = fopen(raw.info.filename) > before reading from it later. > > see my attempt : > > https://github.com/agramfort/mne-matlab/commit/5a88ef764a5931c14015708d372942ed2f892b6c > > would this solve your pb? > > Alex > > On Wed, Feb 9, 2011 at 11:16 AM, Vladimir Litvak wrote: >> The question is if it would be possible to pre-read those fif tags and >> all the other info and store it in the header, then close the file and >> then given just the samples to read to open it again and navigate fast >> to the right place based on the info that has been stored before? >> Those tags don't change (do they?) so it should be sufficient to read >> them once. >> >> Vladimir >> >> On Wed, Feb 9, 2011 at 4:05 PM, Alexandre Gramfort >> wrote: >>> Hi Vladimir, >>> >>>> So why does fiff_setup_read_raw take so long? Do you really need half >>>> a second to open a fif file or does it also read some header data not >>>> all of which is necessary? >>> >>> fiff_setup_read_raw reads many things from the fif file: >>> - measurement info >>> - sampling rate >>> - first/last time sample >>> >>> to do this it locates in the file the location of all the info (the fif tags). >>> So when you look for something in the file, you go down the tree >>> (in matlab) and that points you to the location in the file where to read. >>> >>>> Could there perhaps be a faster version for >>>> repeated calls that would make it possible to keep fileio code >>>> stateless? >>> >>> we could write a single function that does both : >>> fiff_setup_read_raw and fiff_read_raw_segment >>> if it can help. >>> >>> Alex >>> >>> >> >> >> The information in this e-mail is intended only for the person to whom it is >> addressed. If you believe this e-mail was sent to you in error and the e-mail >> contains patient information, please contact the Partners Compliance HelpLine at >> http://www.partners.org/complianceline . If the e-mail was sent to you in error >> but does not contain patient information, please contact the sender and properly >> dispose of the e-mail. >> >> > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From gramfort at nmr.mgh.harvard.edu Wed Feb 9 19:16:41 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 13:16:41 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Message-ID: hi, > I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). ok. That was a quick and dirty hack to give an idea. > So we need to store the cursor position too. See my earlier e-mail. maybe you or scott can propose a fix in the same vein? I can give you write access to the mne-matlab code if you want. Alex From sburns at nmr.mgh.harvard.edu Wed Feb 9 19:44:19 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 13:44:19 -0500 Subject: [FieldTrip] FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> Message-ID: <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> --I tried sending this on the bug report thread but got a delivery failure notice -- Robert, Laurence and Alexandre - Thanks for the feedback on this issue. Here are my thoughts on further investigation. Since ft_preprocessing calls its own ft_read_header (ft_preprocessing:327), ft_read_event isn't actually going for data, and that ft_definetrial and ft_preprocessing are separate high-level functions, then I think we can assume that no actual data will be read during ft_read_event and the file can be closed towards the end of the ft_read_event function. That closes one leak. Because ft_preprocessing is one of the high-level functions of FT and that the function is structured to operate on the data file once per event, it should clean up anything it opened. It'd be simple enough to check if hdr.orig.raw.fid is still open after all the data reading has been done (after ft_preprocessing:530) and close it. This way, you wouldn't have to fundamentally change how ft_read_data operates on neuromag files. I'm not sure how the architecture of FT deals with other file formats and whether this is sort of leak can occur in other situations, but this seems to be the easiest fix to this problem. Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. On Feb 9, 2011, at 1:16 PM, Alexandre Gramfort wrote: > hi, > >> I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). > > ok. That was a quick and dirty hack to give an idea. > >> So we need to store the cursor position too. See my earlier e-mail. > > maybe you or scott can propose a fix in the same vein? > > I can give you write access to the mne-matlab code if you want. > > Alex > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanweisz at mac.com Wed Feb 9 21:25:42 2011 From: nathanweisz at mac.com (Nathan Weisz) Date: Wed, 09 Feb 2011 21:25:42 +0100 Subject: [FieldTrip] dipolefitting issues Message-ID: <881B6122-2D39-4716-B1F6-6244DDE06703@mac.com> hi everyone, i'm trying to help out a colleague who is trying to analyse some auditory evoked potential (EEG) data and for the research question at hand it would be nice to separate left vs. right hemisphere. we want to keep things simple first by fitting symmetric dipoles to e.g. the N1 and then use the positions to estimate the dipole moments for the entire ERP. the ERP that we want to build the source montage on is calculated from ~600 trials, i.e. we see what we need to see very nicely. we are using a spherical headmodel (electrode positions also on sphere) as described on the FT homepage: vol = []; vol.r = [0.88 0.92 1.00]; % radii of spheres vol.c = [1 1/80 1]; % conductivity vol.o = [0 0 0]; using a precomputed leadfield i the turn to ft_dipolefitting: cfg = []; cfg.vol = vol; % see above cfg.elec = data.elec; % see above cfg.gridsearch = 'yes'; cfg.numdipoles=2; cfg.symmetry='y'; %nach den elec.pnt sieht es so aus als wäre y links / rechts cfg.grid=lf; cfg.latency=[.05 .1]; dip1 = ft_dipolefitting(cfg, avgbl); i get following message: ... > scanning grid location 279/280 > scanning grid location 280/280 > found minimum after scanning on grid point [-0.111111 0.111111 0.111111; -0.111111 -0.111111 0.111111] > First-order > Iteration Func-count f(x) Step-size optimality > 0 4 0.0406088 0.5 > > Local minimum possible. > > fminunc stopped because it cannot decrease the objective function > along the current search direction. > > > > found minimum after non-linear optimization on [-0.111111 0.111111 -0.111111; -0.111111 -0.111111 -0.111111] i then ran the tutorial example here: http://fieldtrip.fcdonders.nl/example/compute_forward_simulated_data_and_apply_a_dipole_fit just to check if there may be something fundamentally wrong with my code. however i get a similar message suggesting something went wrong: > scanning grid location 26/27 > scanning grid location 27/27 > found minimum after scanning on grid point [0 0.5 0.5] > First-order > Iteration Func-count f(x) Step-size optimality > 0 4 0.0293345 0.303 > 1 8 0.0079586 1 0.15 > 2 12 5.63895e-05 1 0.0138 > 3 16 5.75471e-06 1 0.00446 > 4 20 8.86701e-11 1 1.33e-05 > 5 24 1.45576e-14 1 1.3e-07 > 6 28 1.75862e-16 1 2.61e-08 > > Local minimum possible. > > fminunc stopped because the size of the current step is less than > the default value of the step size tolerance. > > > > found minimum after non-linear optimization on [-5.08281e-09 0.5 0.3] I am using Matlab 2010b. a fairly recent fieldtrip (~3 months old or so). there was a similar question on the archives, however i found no answer: http://mailman.science.ru.nl/pipermail/fieldtrip/2010-May/002874.html is this an issue related to the matlab version and the fminunc function? i would be grateful about any suggestion. cheers, nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.litvak at ion.ucl.ac.uk Wed Feb 9 21:48:35 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Wed, 9 Feb 2011 20:48:35 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: Dear Scott, I think I know Robert's views quite well and he wouldn't like your solution because ft_preprocessing will have to deal with a format-specific low-level issue that should be handled by fileio. This will violate the software architecture which for FT is a big deal (and rightly so).  If, however, it is sufficient to store in the header a single number which can then be used to find the data onset and from there to find where to start reading (so perhaps not an fid but just the data offset in bytes to do fseek), that'd be a perfectly good solution and fast as well. But I don't know enough about  fif format to say if it's possible. Vladimir On Wednesday, February 9, 2011, Scott Burns wrote: > --I tried sending this on the bug report thread but got a delivery failure notice -- > > Robert, Laurence and Alexandre - > Thanks for the feedback on this issue. Here are my thoughts on further investigation. > Since ft_preprocessing calls its own ft_read_header (ft_preprocessing:327), ft_read_event isn't actually going for data, and that ft_definetrial and ft_preprocessing are separate high-level functions, then I think we can assume that no actual data will be read during ft_read_event and the file can be closed towards the end of the ft_read_event function. That closes one leak. > Because ft_preprocessing is one of the high-level functions of FT and that the function is structured to operate on the data file once per event, it should clean up anything it opened.  It'd be simple enough to check if hdr.orig.raw.fid is still open after all the data reading has been done (after ft_preprocessing:530) and close it.  This way, you wouldn't have to fundamentally change how ft_read_data operates on neuromag files. I'm not sure how the architecture of FT deals with other file formats and whether this is sort of leak can occur in other situations, but this seems to be the easiest fix to this problem. > > Scott BurnsKuperberg LabMartinos Center for Biomedical Imagingsburns at nmr.mgh.harvard.edu > The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. > > > > > On Feb 9, 2011, at 1:16 PM, Alexandre Gramfort wrote: > hi, > > I don't think this works because fopen will place the file cursor at the beginning of the file, whereas fiff_setup_read_raw places the cursor at the beginning of the data (after all the header tags in the .fif file). > > ok. That was a quick and dirty hack to give an idea. > > So we need to store the cursor position too. See my earlier e-mail. > > maybe you or scott can propose a fix in the same vein? > > I can give you write access to the mne-matlab code if you want. > > Alex > > > > From sburns at nmr.mgh.harvard.edu Wed Feb 9 22:06:09 2011 From: sburns at nmr.mgh.harvard.edu (Scott Burns) Date: Wed, 9 Feb 2011 16:06:09 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: <995D8606-7ED7-48BB-86FF-1CE529C97166@nmr.mgh.harvard.edu> On Feb 9, 2011, at 3:48 PM, Vladimir Litvak wrote: > think I know Robert's views quite well and he wouldn't like your > solution because ft_preprocessing will have to deal with a > format-specific low-level issue that should be handled by fileio. Makes sense, my solution is just a hack. Scott Burns Kuperberg Lab Martinos Center for Biomedical Imaging sburns at nmr.mgh.harvard.edu The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhunt at fmrib.ox.ac.uk Wed Feb 9 22:12:37 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 21:12:37 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> Message-ID: <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> I think it should be possible to do it this way - when I tested it, it seemed to work OK. On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: > If, however, it is sufficient to store in the header a > single number which can then be used to find the data onset and from > there to find where to start reading (so perhaps not an fid but just > the data offset in bytes to do fseek), that'd be a perfectly good > solution and fast as well. But I don't know enough about fif format > to say if it's possible. =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== From gramfort at nmr.mgh.harvard.edu Wed Feb 9 22:17:54 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Wed, 9 Feb 2011 16:17:54 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> Message-ID: again if something needs to be changed in the mne matlab code I'd be happy to help. Alex On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: > I think it should be possible to do it this way - when I tested it, it seemed to work OK. > > On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: > >> If, however, it is sufficient to store in the header a >> single number which can then be used to find the data onset and from >> there to find where to start reading (so perhaps not an fid but just >> the data offset in bytes to do fseek), that'd be a perfectly good >> solution and fast as well. But I don't know enough about  fif format >> to say if it's possible. > > =========================================== > Laurence Hunt, DPhil Student >  Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > From lhunt at fmrib.ox.ac.uk Wed Feb 9 22:33:13 2011 From: lhunt at fmrib.ox.ac.uk (Laurence Hunt) Date: Wed, 9 Feb 2011 21:33:13 +0000 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> Message-ID: <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> Thanks Alex - I guess it might also be useful to add to the mne code instead, as long as it doesn't cause any problems elsewhere for other users...? Thinking about it, I reckon it would work if you used the same solution you suggested previously on your website, but just added data.pos = ftell(data.fid); %before running fclose in fiff_setup_read_raw and fseek(raw.fid,raw.pos); %after re-opening the file in fiff_read_raw_segment (...followed by an fclose of raw.fid at the end of fiff_read_raw_segment, of course). If you did this, it would save us making any changes in fieldtrip at all :) Laurence =========================================== Laurence Hunt, DPhil Student Centre for Functional MRI of the Brain (FMRIB), University of Oxford lhunt at fmrib.ox.ac.uk Phone: (+44)1865-(2)22738 =========================================== On 9 Feb 2011, at 21:17, Alexandre Gramfort wrote: > again if something needs to be changed in the mne matlab code > I'd be happy to help. > > Alex > > On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: >> I think it should be possible to do it this way - when I tested it, it seemed to work OK. >> >> On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: >> >>> If, however, it is sufficient to store in the header a >>> single number which can then be used to find the data onset and from >>> there to find where to start reading (so perhaps not an fid but just >>> the data offset in bytes to do fseek), that'd be a perfectly good >>> solution and fast as well. But I don't know enough about fif format >>> to say if it's possible. >> >> =========================================== >> Laurence Hunt, DPhil Student >> Centre for Functional MRI of the Brain (FMRIB), >> University of Oxford >> lhunt at fmrib.ox.ac.uk >> Phone: (+44)1865-(2)22738 >> =========================================== >> _______________________________________________ >> 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 michael.wibral at web.de Thu Feb 10 09:58:57 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 10 Feb 2011 09:58:57 +0100 (CET) Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, Message-ID: <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> Dear David, dear Eric, there is one additional side effect of specifying a LARGE minnbchan that actually leads to SMALLEr clusters in a certain sense. If I understand correctly, at any point in time&frequency the cluster has to have a spatial extension of minnbchan+1. So when you specify a large value the cluster may more easily be cut up into several smaller ones along the space&time dimension - which may or may not be desirable. Michael -----Ursprüngliche Nachricht----- Von: "David Groppe" Gesendet: Feb 8, 2011 7:18:59 PM An: "Email discussion list for the FieldTrip project" Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris wrote: >> Dear David, >> >> >>> Thanks very much for the email Eric, but I'm confused as to why you >>> answered "No" to my second comment.  From what I understand, if you >>> use a value of minnbchan that is greater than 0, then any significant >>> clusters will necessarily spread across multiple electrodes.  For >>> example, if you set minnbchan to 1, then all significant clusters will >>> have to include at least two electrodes so that each significant >>> "voxel" has at least one neighbor at another electrode.  Thus, if your >>> effect is truly at only a single electrode, having a value of >>> minnbchan greater than 0 will force you to miss the effect or to think >>> it occurs at more electrodes than it really does.  What part of my >>> reasoning is incorrect? >> >> Your reasoning is correct and mine was incorrect. I should read better >> before I write. My apologies for this. > >Got it. Thanks very much for clarifying Eric. > >> >> I do have to qualify that with minnbchan=0 it may also happen that your >> significant cluster contains more than one electrode (the electrode with the >> true effect plus some surrounding ones that by accident exceed the threshold >> that is used to identify clusters). > >That makes perfect sense. Since our lab uses only a limited number of >electrodes (32), I wanted to make sure I understood the minimum number >of electrodes an effect needs to span to be detected. > once again, I very much appreciate your answers to my questions, > -David > >> Best, >> >> Eric >> >> >> >> >>>      again, thanks very much for the help, >>>             -David >>> >>> >>> > Best, >>> > >>> > Eric >>> > >>> > >>> > dr. Eric Maris >>> > Donders Institute for Brain, Cognition and Behavior >>> > Radboud University >>> > P.O. Box 9104 >>> > 6500 HE Nijmegen >>> > The Netherlands >>> > T:+31 24 3612651 >>> > Mobile: 06 39584581 >>> > F:+31 24 3616066 >>> > mailto:e.maris at donders.ru.nl >>> > http://www.nphyscog.com/ >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>     thanks for your help, >>> >>         -David >>> >> >>> >> >>> >> -- >>> >> David Groppe, Ph.D. >>> >> dgroppe at cogsci.ucsd.edu >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ >>> >> _______________________________________________ >>> >> 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 >>> > >>> >>> >>> >>> -- >>> David Groppe, Ph.D. >>> Postdoctoral Researcher >>> Kutaslab >>> Dept. of Cognitive Science >>> University of California, San Diego >>> http://www.cogsci.ucsd.edu/~dgroppe/ >>> >>> _______________________________________________ >>> 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 >> > > > >-- >David Groppe, Ph.D. >Postdoctoral Researcher >Kutaslab >Dept. of Cognitive Science >University of California, San Diego >http://www.cogsci.ucsd.edu/~dgroppe/ > >_______________________________________________ >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From e.maris at donders.ru.nl Thu Feb 10 11:16:05 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Thu, 10 Feb 2011 11:16:05 +0100 Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053> Message-ID: <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> Hi Michael, > there is one additional side effect of specifying a LARGE minnbchan > that actually leads to SMALLEr clusters in a certain sense. If I > understand correctly, at any point in time&frequency the cluster has to > have a spatial extension of minnbchan+1. So when you specify a large > value the cluster may more easily be cut up into several smaller ones > along the space&time dimension - which may or may not be desirable. Whether it is a side effect or not, depends on how you look at it. For me it is its intended effect. I implemented the minnbchan-parameter after discussions with PhD-students that applied the cluster-based permutation statistics on channel-time-frequency data and produced significant clusters with weird shapes. Often, these shapes contained narrow "bridges" connecting nearby blobs in channel-time-frequency space. By increasing minnbchan, these bridges were removed and only the blobs remained. Although I understand the requests of the PhD-students that I discussed with, I find the discussions about the minnbchan-parameter not very rewarding. In fact, it is looking for isolated blobs that one would like to interpret as separate physiological entities. This contrast with the nature of the EEG/MEG data, which has poor spatial resolution (due to volume conduction and common pick-up), often poor spectral resolution (due to the short time windows of our time-resolved spectral analysis), and often poor time resolution (due to latency jitter over trials). Best, Eric > > Michael > > -----Ursprüngliche Nachricht----- > Von: "David Groppe" > Gesendet: Feb 8, 2011 7:18:59 PM > An: "Email discussion list for the FieldTrip project" > > Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to > spatial neighbors? > > >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris > wrote: > >> Dear David, > >> > >> > >>> Thanks very much for the email Eric, but I'm confused as to why you > >>> answered "No" to my second comment. From what I understand, if you > >>> use a value of minnbchan that is greater than 0, then any > >>> significant clusters will necessarily spread across multiple > >>> electrodes. For example, if you set minnbchan to 1, then all > >>> significant clusters will have to include at least two electrodes > so > >>> that each significant "voxel" has at least one neighbor at another > >>> electrode. Thus, if your effect is truly at only a single > >>> electrode, having a value of minnbchan greater than 0 will force > you > >>> to miss the effect or to think it occurs at more electrodes than it > >>> really does. What part of my reasoning is incorrect? > >> > >> Your reasoning is correct and mine was incorrect. I should read > >> better before I write. My apologies for this. > > > >Got it. Thanks very much for clarifying Eric. > > > >> > >> I do have to qualify that with minnbchan=0 it may also happen that > >> your significant cluster contains more than one electrode (the > >> electrode with the true effect plus some surrounding ones that by > >> accident exceed the threshold that is used to identify clusters). > > > >That makes perfect sense. Since our lab uses only a limited number of > >electrodes (32), I wanted to make sure I understood the minimum number > >of electrodes an effect needs to span to be detected. > > once again, I very much appreciate your answers to my questions, > > -David > > > >> Best, > >> > >> Eric > >> > >> > >> > >> > >>> again, thanks very much for the help, > >>> -David > >>> > >>> > >>> > Best, > >>> > > >>> > Eric > >>> > > >>> > > >>> > dr. Eric Maris > >>> > Donders Institute for Brain, Cognition and Behavior Radboud > >>> > University P.O. Box 9104 6500 HE Nijmegen The Netherlands > >>> > T:+31 24 3612651 > >>> > Mobile: 06 39584581 > >>> > F:+31 24 3616066 > >>> > mailto:e.maris at donders.ru.nl > >>> > http://www.nphyscog.com/ > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> >> thanks for your help, > >>> >> -David > >>> >> > >>> >> > >>> >> -- > >>> >> David Groppe, Ph.D. > >>> >> dgroppe at cogsci.ucsd.edu > >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ > >>> >> _______________________________________________ > >>> >> 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 > >>> > > >>> > >>> > >>> > >>> -- > >>> David Groppe, Ph.D. > >>> Postdoctoral Researcher > >>> Kutaslab > >>> Dept. of Cognitive Science > >>> University of California, San Diego > >>> http://www.cogsci.ucsd.edu/~dgroppe/ > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > > > > >-- > >David Groppe, Ph.D. > >Postdoctoral Researcher > >Kutaslab > >Dept. of Cognitive Science > >University of California, San Diego > >http://www.cogsci.ucsd.edu/~dgroppe/ > > > >_______________________________________________ > >fieldtrip mailing list > >fieldtrip at donders.ru.nl > >http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From lucie.charles.ens at googlemail.com Thu Feb 10 11:58:43 2011 From: lucie.charles.ens at googlemail.com (Lucie Charles) Date: Thu, 10 Feb 2011 11:58:43 +0100 Subject: [FieldTrip] Modification of ft_timelockgrandaverage cfg.keepindividual Message-ID: Hello everyone, It seems that there has been a modification of ft_timelockgrandaverage : now if you specify cfg.keepindividual = 'yes', the grandaverage is computed but is not included in the output of the function (see above). Why is that ? Many of my scripts rely on this option and I wanted to know if there was a good reason for it. Thanks, Lucie New version of ft_timelockgrandaverage (downloaded yesterday), line 159-176 %-------------------------------------------- % % collect the results %-------------------------------------------- grandavg = []; grandavg.label = cfg.channel; % cell-array %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete grandavg.time = ResultsTime; % 1 x Nsamples %KEEP INDIVIDUAL MEANS? if strcmp(cfg.keepindividual, 'yes') * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples grandavg.dimord = 'subj_chan_time';* else * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* grandavg.var = ResultVar; % Nchan x Nsamples grandavg.dimord = 'chan_time'; end Older version of ft_timelockgrandaverage (april 2010) %-------------------------------------------- % % collect the results %-------------------------------------------- %SWITCH CHANNEL TO LABEL? grandavg.label = cfg.channel; % cell-array grandavg.fsample = varargin{1}.fsample; grandavg.avg = ResultGrandavg; % Nchan x Nsamples grandavg.var = ResultVar; % Nchan x Nsamples grandavg.time = ResultsTime; % 1 x Nsamples %KEEP INDIVIDUAL MEANS? if strcmp(cfg.keepindividual, 'yes') grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples grandavg.dimord = 'subj_chan_time'; else grandavg.dimord = 'chan_time'; end -- Lucie CHARLES INSERM-CEA Cognitive Neuroimaging unit CEA/SAC/DSV/DRM/NeuroSpin Bât 145, Point Courrier 156 F-91191 Gif/Yvette, FRANCE Tel : +33 1 69 08 99 74 Fax : +33 1 69 08 79 73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 10 12:17:21 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 10 Feb 2011 12:17:21 +0100 Subject: [FieldTrip] Modification of ft_timelockgrandaverage cfg.keepindividual In-Reply-To: References: Message-ID: <99137929-ED6C-41A8-A70C-2C3F94E8AF76@donders.ru.nl> Dear Lucie, Yes, indeed this has recently been changed. The logic behind it is the following: One either typically wants to keep the individuals, OR the average. If in your case you need the average, you have to specify cfg.keepindividual = 'no'; Keeping both the average and the individual leads to an inconsistent definition of the data structure. The field 'dimord' does not allow for an unequivocal interpretation of both indidual and avg are present. If you need both the individual, and the avg, you now need to run ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', and once with cfg.keepindividual = 'no'; Best wishes, Jan-Mathijs On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: > Hello everyone, > > It seems that there has been a modification of > ft_timelockgrandaverage : now if you specify cfg.keepindividual = > 'yes', the grandaverage is computed but is not included in the > output of the function (see above). > > Why is that ? Many of my scripts rely on this option and I wanted to > know if there was a good reason for it. > > Thanks, > > Lucie > > New version of ft_timelockgrandaverage (downloaded yesterday), line > 159-176 > > %-------------------------------------------- > % % collect the results > %-------------------------------------------- > > grandavg = []; > grandavg.label = cfg.channel; % cell-array > %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete > grandavg.time = ResultsTime; % 1 x Nsamples > > %KEEP INDIVIDUAL MEANS? > if strcmp(cfg.keepindividual, 'yes') > grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples > grandavg.dimord = 'subj_chan_time'; > else > grandavg.avg = ResultGrandavg; % Nchan x Nsamples > grandavg.var = ResultVar; % Nchan x Nsamples > grandavg.dimord = 'chan_time'; > end > > Older version of ft_timelockgrandaverage (april 2010) > > %-------------------------------------------- > % % collect the results > %-------------------------------------------- > > %SWITCH CHANNEL TO LABEL? > grandavg.label = cfg.channel; % cell-array > grandavg.fsample = varargin{1}.fsample; > grandavg.avg = ResultGrandavg; % Nchan x Nsamples > grandavg.var = ResultVar; % Nchan x Nsamples > grandavg.time = ResultsTime; % 1 x Nsamples > > %KEEP INDIVIDUAL MEANS? > if strcmp(cfg.keepindividual, 'yes') > grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples > grandavg.dimord = 'subj_chan_time'; > else > grandavg.dimord = 'chan_time'; > end > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.wibral at web.de Thu Feb 10 12:33:05 2011 From: michael.wibral at web.de (Michael Wibral) Date: Thu, 10 Feb 2011 12:33:05 +0100 (CET) Subject: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? In-Reply-To: <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> References: <-132249673793097681@unknownmsgid> <2657614842150526102@unknownmsgid>, <751966812.9112450.1297328337180.JavaMail.fmail@mwmweb053>, <02dc01cbc90b$89cbf720$9d63e560$@maris@donders.ru.nl> Message-ID: <2052784146.469173.1297337585004.JavaMail.fmail@mwmweb054> Hi Eric, sorry that I called this a "side-effect", I indeed find it most practical myself. I just didn't know this was the intended purpose. Michael -----Ursprüngliche Nachricht----- Von: "Eric Maris" Gesendet: Feb 10, 2011 11:16:05 AM An: "'Email discussion list for the FieldTrip project'" Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to spatial neighbors? >Hi Michael, > >> there is one additional side effect of specifying a LARGE minnbchan >> that actually leads to SMALLEr clusters in a certain sense. If I >> understand correctly, at any point in time&frequency the cluster has to >> have a spatial extension of minnbchan+1. So when you specify a large >> value the cluster may more easily be cut up into several smaller ones >> along the space&time dimension - which may or may not be desirable. > >Whether it is a side effect or not, depends on how you look at it. For me it is its intended effect. I implemented the minnbchan-parameter after discussions with PhD-students that applied the cluster-based permutation statistics on channel-time-frequency data and produced significant clusters with weird shapes. Often, these shapes contained narrow "bridges" connecting nearby blobs in channel-time-frequency space. By increasing minnbchan, these bridges were removed and only the blobs remained. > >Although I understand the requests of the PhD-students that I discussed with, I find the discussions about the minnbchan-parameter not very rewarding. In fact, it is looking for isolated blobs that one would like to interpret as separate physiological entities. This contrast with the nature of the EEG/MEG data, which has poor spatial resolution (due to volume conduction and common pick-up), often poor spectral resolution (due to the short time windows of our time-resolved spectral analysis), and often poor time resolution (due to latency jitter over trials). > >Best, > >Eric > > > > > >> >> Michael >> >> -----Ursprüngliche Nachricht----- >> Von: "David Groppe" >> Gesendet: Feb 8, 2011 7:18:59 PM >> An: "Email discussion list for the FieldTrip project" >> >> Betreff: Re: [FieldTrip] What exactly does 'minnbchan' refer just to >> spatial neighbors? >> >> >On Tue, Feb 8, 2011 at 11:01 AM, Eric Maris >> wrote: >> >> Dear David, >> >> >> >> >> >>> Thanks very much for the email Eric, but I'm confused as to why you >> >>> answered "No" to my second comment. From what I understand, if you >> >>> use a value of minnbchan that is greater than 0, then any >> >>> significant clusters will necessarily spread across multiple >> >>> electrodes. For example, if you set minnbchan to 1, then all >> >>> significant clusters will have to include at least two electrodes >> so >> >>> that each significant "voxel" has at least one neighbor at another >> >>> electrode. Thus, if your effect is truly at only a single >> >>> electrode, having a value of minnbchan greater than 0 will force >> you >> >>> to miss the effect or to think it occurs at more electrodes than it >> >>> really does. What part of my reasoning is incorrect? >> >> >> >> Your reasoning is correct and mine was incorrect. I should read >> >> better before I write. My apologies for this. >> > >> >Got it. Thanks very much for clarifying Eric. >> > >> >> >> >> I do have to qualify that with minnbchan=0 it may also happen that >> >> your significant cluster contains more than one electrode (the >> >> electrode with the true effect plus some surrounding ones that by >> >> accident exceed the threshold that is used to identify clusters). >> > >> >That makes perfect sense. Since our lab uses only a limited number of >> >electrodes (32), I wanted to make sure I understood the minimum number >> >of electrodes an effect needs to span to be detected. >> > once again, I very much appreciate your answers to my questions, >> > -David >> > >> >> Best, >> >> >> >> Eric >> >> >> >> >> >> >> >> >> >>> again, thanks very much for the help, >> >>> -David >> >>> >> >>> >> >>> > Best, >> >>> > >> >>> > Eric >> >>> > >> >>> > >> >>> > dr. Eric Maris >> >>> > Donders Institute for Brain, Cognition and Behavior Radboud >> >>> > University P.O. Box 9104 6500 HE Nijmegen The Netherlands >> >>> > T:+31 24 3612651 >> >>> > Mobile: 06 39584581 >> >>> > F:+31 24 3616066 >> >>> > mailto:e.maris at donders.ru.nl >> >>> > http://www.nphyscog.com/ >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> >> thanks for your help, >> >>> >> -David >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> David Groppe, Ph.D. >> >>> >> dgroppe at cogsci.ucsd.edu >> >>> >> http://www.cogsci.ucsd.edu/~dgroppe/ >> >>> >> _______________________________________________ >> >>> >> 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 >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> David Groppe, Ph.D. >> >>> Postdoctoral Researcher >> >>> Kutaslab >> >>> Dept. of Cognitive Science >> >>> University of California, San Diego >> >>> http://www.cogsci.ucsd.edu/~dgroppe/ >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> >> > >> > >> > >> >-- >> >David Groppe, Ph.D. >> >Postdoctoral Researcher >> >Kutaslab >> >Dept. of Cognitive Science >> >University of California, San Diego >> >http://www.cogsci.ucsd.edu/~dgroppe/ >> > >> >_______________________________________________ >> >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: Michael Wibral.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: From jan.schoffelen at donders.ru.nl Thu Feb 10 13:15:57 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 10 Feb 2011 13:15:57 +0100 Subject: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage cfg.keepindividual References: Message-ID: Dear Lucie, Thank you very much for your feedback. I take the liberty to anyhow post this to the discussion list, so that other people may take notice / join in the discussion / etc. > Thanks a lot for this quick response : I understand the logic behind > this. It's true that I noticed some inconsistencies due to the > interpretation of the field dimord which can't be well defined if > you have both individual and average data in your structure. OK > However, I think many people were happy with this option as it was. > It's quite handy to keep both the average and individual data > because you can compute statistics and at the same time you don't > have to redo the average every time. I think a lot of scripts rely > on that at least in our lab. The historical purpose for supporting cfg.keepindividual = 'yes', was in order to get a representation of all single subjects' data in a single data matrix: data.individual. Nowadays, ft_timelockstatistics supports multiple data structures in the input, i.e. ft_timelockstatistics(cfg, subj1, subj2 subj3, etc) so I think the call to ft_timelockgrandaverage could even be bypassed. The FieldTrip development team is very keen on providing backward compatibility support. While in general this is feasible for the functions which are in FieldTrip, it is very difficult to realize for lab-specific scripts. In this particular example I think that clarity of the data representation should prevail over backward compatibility issues, particularly because in this case there's an easy workaround: just call ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data representation is a prerequisite for further developing the software, and keeping the historical 'oddity' will only hamper code development. > Furthermore, it's a bit strange to have a function called > ft_timelockgrandaverage which doesn't compute any grandaverage in > some cases ! I agree, yet see my point above. Some people may just like to have the data represented in a single matrix. > > I would suggest to keep the function as it is but add more options > (such as cfg.dimord = 'avg' or 'individual') to make the > experimenter aware of this issue and to solve further computation > problem. I hope I could convince you that our philosophy makes sense and that you and your lab-mates are willing to make the effort of adjusting the scripts a bit for future analyses. If very problematic, I would advice for the current analyses to rely on an old version of ft_timelockgrandaverage. Best wishes, Jan-Mathijs > Thank you again, > > Lucie > > PS : I've sent this email only to you as this is just a suggestion > which might not be relevant for all users. > > > 2011/2/10 jan-mathijs schoffelen > Dear Lucie, > > Yes, indeed this has recently been changed. The logic behind it is > the following: > > One either typically wants to keep the individuals, OR the average. > > If in your case you need the average, you have to specify > cfg.keepindividual = 'no'; > > Keeping both the average and the individual leads to an inconsistent > definition of the data structure. > The field 'dimord' does not allow for an unequivocal interpretation > of both indidual and avg are present. > > If you need both the individual, and the avg, you now need to run > ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', > and once with cfg.keepindividual = 'no'; > > Best wishes, > > Jan-Mathijs > > > On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: > >> Hello everyone, >> >> It seems that there has been a modification of >> ft_timelockgrandaverage : now if you specify cfg.keepindividual = >> 'yes', the grandaverage is computed but is not included in the >> output of the function (see above). >> >> Why is that ? Many of my scripts rely on this option and I wanted >> to know if there was a good reason for it. >> >> Thanks, >> >> Lucie >> >> New version of ft_timelockgrandaverage (downloaded yesterday), line >> 159-176 >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> grandavg = []; >> grandavg.label = cfg.channel; % cell-array >> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.dimord = 'chan_time'; >> end >> >> Older version of ft_timelockgrandaverage (april 2010) >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> %SWITCH CHANNEL TO LABEL? >> grandavg.label = cfg.channel; % cell-array >> grandavg.fsample = varargin{1}.fsample; >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.dimord = 'chan_time'; >> end >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> Bât 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucie.charles.ens at googlemail.com Thu Feb 10 14:03:30 2011 From: lucie.charles.ens at googlemail.com (Lucie Charles) Date: Thu, 10 Feb 2011 14:03:30 +0100 Subject: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage cfg.keepindividual In-Reply-To: References: Message-ID: Thank you very much for this very detailed response. I didn't know (or forgot) that ft_timelockstatistics could take several data sets as an input (I thought we always needed the big data matrix with all the subjects). That makes much more sense to remove the option in this context. Thanks again, Lucie 2011/2/10 jan-mathijs schoffelen > Dear Lucie, > > Thank you very much for your feedback. I take the liberty to anyhow post > this to the discussion list, so that other people may take notice / join in > the discussion / etc. > > Thanks a lot for this quick response : I understand the logic behind this. > It's true that I noticed some inconsistencies due to the interpretation of > the field dimord which can't be well defined if you have both individual and > average data in your structure. > > > OK > > However, I think many people were happy with this option as it was. It's > quite handy to keep both the average and individual data because you can > compute statistics and at the same time you don't have to redo the average > every time. I think a lot of scripts rely on that at least in our lab. > > > The historical purpose for supporting cfg.keepindividual = 'yes', was in > order to get a representation of all single subjects' data in a single data > matrix: data.individual. Nowadays, ft_timelockstatistics supports multiple > data structures in the input, i.e. ft_timelockstatistics(cfg, subj1, subj2 > subj3, etc) so I think the call to ft_timelockgrandaverage could even be > bypassed. > The FieldTrip development team is very keen on providing backward > compatibility support. While in general this is feasible for the functions > which are in FieldTrip, it is very difficult to realize for lab-specific > scripts. In this particular example I think that clarity of the data > representation should prevail over backward compatibility issues, > particularly because in this case there's an easy workaround: just call > ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data > representation is a prerequisite for further developing the software, and > keeping the historical 'oddity' will only hamper code development. > > Furthermore, it's a bit strange to have a function called > ft_timelockgrandaverage which doesn't compute any grandaverage in some cases > ! > > > I agree, yet see my point above. Some people may just like to have the data > represented in a single matrix. > > > I would suggest to keep the function as it is but add more options (such as > cfg.dimord = 'avg' or 'individual') to make the experimenter aware of this > issue and to solve further computation problem. > > > I hope I could convince you that our philosophy makes sense and that you > and your lab-mates are willing to make the effort of adjusting the scripts a > bit for future analyses. If very problematic, I would advice for the current > analyses to rely on an old version of ft_timelockgrandaverage. > > Best wishes, > > Jan-Mathijs > > > > Thank you again, > > Lucie > > PS : I've sent this email only to you as this is just a suggestion which > might not be relevant for all users. > > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Yes, indeed this has recently been changed. The logic behind it is the >> following: >> >> One either typically wants to keep the individuals, OR the average. >> >> If in your case you need the average, you have to specify >> cfg.keepindividual = 'no'; >> >> Keeping both the average and the individual leads to an inconsistent >> definition of the data structure. >> The field 'dimord' does not allow for an unequivocal interpretation of >> both indidual and avg are present. >> >> If you need both the individual, and the avg, you now need to run >> ft_timelockgrandaverage twice, once with cfg.keepinididual = 'yes', and once >> with cfg.keepindividual = 'no'; >> >> Best wishes, >> >> Jan-Mathijs >> >> >> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >> >> Hello everyone, >> >> It seems that there has been a modification of ft_timelockgrandaverage : >> now if you specify cfg.keepindividual = 'yes', the grandaverage is computed >> but is not included in the output of the function (see above). >> >> Why is that ? Many of my scripts rely on this option and I wanted to know >> if there was a good reason for it. >> >> Thanks, >> >> Lucie >> >> New version of ft_timelockgrandaverage (downloaded yesterday), line >> 159-176 >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> grandavg = []; >> grandavg.label = cfg.channel; % cell-array >> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time';* >> else >> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.dimord = 'chan_time'; >> end >> >> Older version of ft_timelockgrandaverage (april 2010) >> >> %-------------------------------------------- >> % % collect the results >> %-------------------------------------------- >> >> %SWITCH CHANNEL TO LABEL? >> grandavg.label = cfg.channel; % cell-array >> grandavg.fsample = varargin{1}.fsample; >> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >> grandavg.var = ResultVar; % Nchan x Nsamples >> grandavg.time = ResultsTime; % 1 x Nsamples >> >> %KEEP INDIVIDUAL MEANS? >> if strcmp(cfg.keepindividual, 'yes') >> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >> grandavg.dimord = 'subj_chan_time'; >> else >> grandavg.dimord = 'chan_time'; >> end >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> Bât 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > Bât 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -- Lucie CHARLES INSERM-CEA Cognitive Neuroimaging unit CEA/SAC/DSV/DRM/NeuroSpin Bât 145, Point Courrier 156 F-91191 Gif/Yvette, FRANCE Tel : +33 1 69 08 99 74 Fax : +33 1 69 08 79 73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gregor.Volberg at psychologie.uni-regensburg.de Fri Feb 11 09:46:51 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Fri, 11 Feb 2011 09:46:51 +0100 Subject: [FieldTrip] WPLI weighted phase-locking index: available in fieldtrip? Message-ID: <4D55058B020000570000882D@gwsmtp1.uni-regensburg.de> Dear fieldtrip developers, I was just reading the pre-print of an upcoming article in Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved index of phase-synchronization...". As I understand, the proposed phase-locking index WPLI is not complicated by volume conduction, and an unbiased version of the WPLI can be computed that is not affected by trial number. This would be exactely what I need for the analysis of data from a spatial cueing paradigm. In the last paragraph, it is announced that the WPLI is made available in the fieldtrip toolbox. However, I did not yet find it (i was searching for it as an option in ft_connectivityanalysis, last Friday's fieldtrip version). May I ask whether it is planned to include WPLI / debiased WPLI into that function? Or was it perhaps intended to be computed by hand from the cross-spectrum. Thanks a lot, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From gauthierb.ens at gmail.com Fri Feb 11 10:46:13 2011 From: gauthierb.ens at gmail.com (Baptiste Gauthier) Date: Fri, 11 Feb 2011 10:46:13 +0100 Subject: [FieldTrip] bug in ft_componentanalysis Message-ID: Dear Fieldtrip users, I noticed a little error in ft_componentanalysis since your latest update (2011/02/09) : While using the function, I got this error message : "??? Error using ==> toc You must call TIC without an output argument before calling TOC without an input argument. Error in ==> ft_componentanalysis at 465 fprintf('total time in componentanalysis %.1f seconds\n', stopwatch(toc)); Error in ==> temprod_NEW_runicaonspectra at 37 comp = ft_componentanalysis(cfg,data);" It seems there's here a bad use of function toc.m It should be : "fprintf('total time in componentanalysis %.1f seconds\n', toc(stopwatch));" I tried it and it worked fine. Please let me know if I'm wrong. Cheers, Baptiste gauthier -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.micheli at fcdonders.ru.nl Fri Feb 11 11:43:39 2011 From: c.micheli at fcdonders.ru.nl (Micheli, C.) Date: Fri, 11 Feb 2011 11:43:39 +0100 (CET) Subject: [FieldTrip] bug in ft_componentanalysis In-Reply-To: Message-ID: <1133664698.83738.1297421019941.JavaMail.root@draco.zimbra.ru.nl> Hi Baptiste You are totally right. The bug has been corrected and you can find the new version by downloading the latest FieldTrip . Cheers, Cristiano ----- "Baptiste Gauthier" schreef: > Van: "Baptiste Gauthier" > Aan: fieldtrip at donders.ru.nl > Verzonden: Vrijdag 11 februari 2011 10:46:13 > Onderwerp: [FieldTrip] bug in ft_componentanalysis > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest update (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC without an input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch(toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds\n', toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > _______________________________________________ > 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 E.vandenBroeke at anes.umcn.nl Fri Feb 11 11:52:57 2011 From: E.vandenBroeke at anes.umcn.nl (E.vandenBroeke at anes.umcn.nl) Date: Fri, 11 Feb 2011 11:52:57 +0100 Subject: [FieldTrip] One or two sided testing? Message-ID: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> Dear dr. Maris, Bovenkant formulier Onderkant formulier I notice that there are many different views among scientists about the use of one or two sided tests. Most people say that you always have to test 2-sided. But is there a rationale for this? When is it appropriate and allowed to test one-sided? Perhaps you can shed light on this topic, by giving your point of view or perhaps you can recommend literature that provides insight on this debate? Thank you, Best Emanuel Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629. The Radboud University Nijmegen Medical Centre is listed in the Commercial Register of the Chamber of Commerce under file number 41055629. -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Fri Feb 11 15:01:01 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Fri, 11 Feb 2011 15:01:01 +0100 Subject: [FieldTrip] One or two sided testing? In-Reply-To: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> References: <1DB2AC40A2EE4B4180B817DEEACBF9210C2E32@UMCEXBE12.umcn.nl> Message-ID: <006301cbc9f4$20d75fe0$62861fa0$@maris@donders.ru.nl> Dear Emanuel, I notice that there are many different views among scientists about the use of one or two sided tests. Most people say that you always have to test 2-sided. But is there a rationale for this? When is it appropriate and allowed to test one-sided? Perhaps you can shed light on this topic, by giving your point of view or perhaps you can recommend literature that provides insight on this debate? If you have prior information that an effect will occur only on one side, or if you are only interested in an effect at one side, then you should test one-sided. Otherwise, you should test two-sided. Best, Eric Thank you, Best Emanuel Het UMC St Radboud staat geregistreerd bij de Kamer van Koophandel in het handelsregister onder nummer 41055629. The Radboud University Nijmegen Medical Centre is listed in the Commercial Register of the Chamber of Commerce under file number 41055629. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gramfort at nmr.mgh.harvard.edu Fri Feb 11 17:27:50 2011 From: gramfort at nmr.mgh.harvard.edu (Alexandre Gramfort) Date: Fri, 11 Feb 2011 11:27:50 -0500 Subject: [FieldTrip] Fwd: FT doesn't close .fif files In-Reply-To: <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> References: <1B11E324-D672-442B-AB17-5FF7D01C4D12@nmr.mgh.harvard.edu> <6AB5FC50-00E4-4972-A886-34F221E86EEB@donders.ru.nl> <4E9B0876-DFBB-4A2C-8AF2-B9C9756C0AFC@fmrib.ox.ac.uk> <531F8596-0800-41EC-A2F6-BF6F8F44D02E@nmr.mgh.harvard.edu> <8285689F-5431-42F9-B022-33300097243F@fmrib.ox.ac.uk> <179A5067-5EC9-4A20-AB1F-FB5E67FBF4A4@fmrib.ox.ac.uk> Message-ID: Hi, the pb should be fixed now on: https://github.com/mne-tools/mne-matlab scott confirmed it works for his needs. FYI the files are always closed now and reopened when necessary. Alex On Wed, Feb 9, 2011 at 4:33 PM, Laurence Hunt wrote: > Thanks Alex - I guess it might also be useful to add to the mne code instead, as long as it doesn't cause any problems elsewhere for other users...? Thinking about it, I reckon it would work if you used the same solution you suggested previously on your website, but just added > > data.pos = ftell(data.fid); %before running fclose in fiff_setup_read_raw > > and > > fseek(raw.fid,raw.pos); %after re-opening the file in fiff_read_raw_segment > > (...followed by an fclose of raw.fid at the end of fiff_read_raw_segment, of course). > > If you did this, it would save us making any changes in fieldtrip at all :) > > Laurence > > =========================================== > Laurence Hunt, DPhil Student >  Centre for Functional MRI of the Brain (FMRIB), > University of Oxford > lhunt at fmrib.ox.ac.uk > Phone: (+44)1865-(2)22738 > =========================================== > > On 9 Feb 2011, at 21:17, Alexandre Gramfort wrote: > >> again if something needs to be changed in the mne matlab code >> I'd be happy to help. >> >> Alex >> >> On Wed, Feb 9, 2011 at 4:12 PM, Laurence Hunt wrote: >>> I think it should be possible to do it this way - when I tested it, it seemed to work OK. >>> >>> On 9 Feb 2011, at 20:48, Vladimir Litvak wrote: >>> >>>> If, however, it is sufficient to store in the header a >>>> single number which can then be used to find the data onset and from >>>> there to find where to start reading (so perhaps not an fid but just >>>> the data offset in bytes to do fseek), that'd be a perfectly good >>>> solution and fast as well. But I don't know enough about  fif format >>>> to say if it's possible. >>> >>> =========================================== >>> Laurence Hunt, DPhil Student >>>  Centre for Functional MRI of the Brain (FMRIB), >>> University of Oxford >>> lhunt at fmrib.ox.ac.uk >>> Phone: (+44)1865-(2)22738 >>> =========================================== >>> _______________________________________________ >>> 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 > > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in error > but does not contain patient information, please contact the sender and properly > dispose of the e-mail. > > From andreas.wilmer at uni-muenster.de Fri Feb 11 17:57:36 2011 From: andreas.wilmer at uni-muenster.de (Andreas Wilmer) Date: Fri, 11 Feb 2011 17:57:36 +0100 Subject: [FieldTrip] trial-based time-series via lcmv beamforming? Message-ID: dear fieldtrip-users, actually my first active post in the fieldtrip newsgroup. first i'd like to thank the community and especially the developers of fieldtrip for their great support&help! i am interested in a trial-based(!) time-domain data-set in the source space of MEG data for further connectivity analysis. i decided to use a beamformer (lcmv) to recover the neuronal activity by using snythetic data-sets (for testing and verification). the synthetic data- set consists of 3 correlated sources with up to 300 trials and a length of 720 datapoints (=1.2s at 600Hz) and many trials of uncorrelated noisy sources. i implemented the dipole simulation in the following way: 1) i used customized data with time dependent (time-delayed) phase correlations as source waveforms and added randomly located uncorrelated dipoles as disturbances and spontaneous brain processes. next, i simulated the data in sensor-space and did an lcmv beamforming -> works fine (a priori known connectivity can be recovered). 2) in the next step i repeated the simulation and added 10% rms as additive (delta-correlated) measurement noise to the data in the sensor-space to model thermal noise. -> in this case the beamformer reconstruction fails totally... 3) i averaged the data in sensor-space to get rid of the thermal noise and used the cov to recover every single trial, but in this case the beamformer cannot deal with brain-noise... -> this didn't work either.. MY QUESTION IS: is this a conceptual problem of beamforming, that one cannot recover a trial-based time-series or did i commit a crude error in reasoning/programming? do you think a bootstrapping for calculating the cov might make sense, i.e. i could calculate the cov for each trial by averaging over just a few trials (eg 10 randomly chosen trials) to reduce the uncorrelated noise in sensor space without loosing all the information to suppress the brain-noise? which other inverse methods can recover source activity in time-domain on trial level? eg MNE seems only to work on average over trials? so many questions.. thank you in advance for your help! with best wishes, andreas __________________________________ Dipl.-Phys. Andreas Wilmer Institut für Allgemeine Psychologie Westfälische Wilhelms-Universität Münster AE Prof. Dr. Markus Lappe Fliednerstraße 21 D 48149 Münster fon: +49 (251) 83 34175 email: andreas.wilmer at uni-muenster.de my code on beamforming two further remarks: a) i didn't apply a normalization of the virtual channels because i am interested in phase measures - normalizing the amplitudes won't have any effect on the results b) narrow band filtering didn't work with my (broad band) data %----------------------------------------------------------------- %estimating filter/cov cfg = []; cfg.channel = {'MEG'}; cfg.keeptrials = 'yes'; cfg.bpfrq = [1 150]; cfg.covariance = 'yes'; %trial/stimulus window cfg.covariancewindow = [0 1.2]; %complete data dataCov = ft_timelockanalysis(cfg,dataSensor); %----------------------------------------------------------------- %beamforming cfg = []; cfg.method = 'lcmv'; cfg.lcmv.fixedori = 'yes'; cfg.vol = dataHead; cfg.grid.pos = gridposition; cfg.lambda = '5%'; cfg.projectnoise = 'yes'; cfg.keepfilter = 'yes'; cfg.keeptrials = 'yes'; [dataVc] = ft_sourceanalysis(cfg,dataCov); %--------------------------------------------------------------- %reconstructing source data trialN = size(dataSensor.trial,2); [sensN tN] = size(dataSensor.trial{1}); srcN = length(dataVc.inside); for i=1:srcN, m = dataVc.inside(i); if ~isempty(dataVc.avg.filter{m}), fprintf('beamforming source %d/%d\n',i,srcN); %beamforming for j = 1:trialN, dataVc.trial(j).mom{m} =... dataVc.avg.filter{m}*dataSensor.trial{j}; end end end -------------- next part -------------- An HTML attachment was scrubbed... URL: From ting.ac at gmail.com Fri Feb 11 22:19:33 2011 From: ting.ac at gmail.com (Allison Connolly) Date: Fri, 11 Feb 2011 15:19:33 -0600 Subject: [FieldTrip] problem aligning MRI with gradiometer Message-ID: Hello, I am trying to perform beamforming on some MEG data (148 channels). I have the dicom files for the MRI, and I have converted them to .img and .hdr files using Curry. I am importing them into fieldtrip via mri=ft_read_mri('MRI.img'). Then I manually declaring the fiducials with cfg.method = 'interactive'; mrialign = ft_volumerealign(cfg, mri); Then segmenting with cfg = []; cfg.write = 'no'; [segment] = ft_volumesegment(cfg, mri); Then creating the head model with cfg = []; cfg.smooth = 'no'; vol = ft_prepare_singleshell(cfg, segment); Then creating the grid with cfg = []; cfg.grad = freq.grad; cfg.vol = vol; cfg.reducerank = 'no'; cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol [grid] = ft_prepare_leadfield(cfg); I am importing my MEG data with cfg = []; % empty configuration cfg.dataset = 'C:/MEG Study/Subjectd001/d001/Billy_180s/06@ -09 at -10@_19_41/4/c,rfhp0.1Hz'; cfg.trialfun = 'trialfun_general'; cfg.trialdef.triallength = 2; % duration in seconds cfg.trialdef.ntrials = inf; % number of trials, inf results in as many as possible cfg = ft_definetrial(cfg); % preprocess the data cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; %read all MEG channels except those with '-' cfg.lpfilter = 'yes'; cfg.lpfreq = 200; cfg.bsfilter = 'yes'; %60 Hz noise cfg.bsfreq = [58 62]; data = ft_preprocessing(cfg); In the end, when I go to plot them all on the same graph, the head model seems to be 100 times larger than the gradiometer sensors (they appear as a small ball in the middle of the head). I've tried adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't help the downstream frequency, leadfield, and source analysis. Can someone tell me how to ensure the gradiometer and mri/grid are on the same scale so I can be sure I have the right model for my beamforming? Thank you, -Allison -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.frei at psy.gla.ac.uk Fri Feb 11 23:02:18 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 11 Feb 2011 22:02:18 +0000 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: References: Message-ID: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Hi Alison, how do you change the units? I convert them using: data.grad=ft_convert_units(data.grad,'cm') Maybe this helps. Luisa On 11 Feb 2011, at 21:19, Allison Connolly wrote: > Hello, > > I am trying to perform beamforming on some MEG data (148 channels). > I have the dicom files for the MRI, and I have converted them > to .img and .hdr files using Curry. > I am importing them into fieldtrip via > mri=ft_read_mri('MRI.img'). > > Then I manually declaring the fiducials with > cfg.method = 'interactive'; > mrialign = ft_volumerealign(cfg, mri); > > Then segmenting with > cfg = []; > cfg.write = 'no'; > [segment] = ft_volumesegment(cfg, mri); > > Then creating the head model with > cfg = []; > cfg.smooth = 'no'; > vol = ft_prepare_singleshell(cfg, segment); > > Then creating the grid with > cfg = []; > cfg.grad = freq.grad; > cfg.vol = vol; > cfg.reducerank = 'no'; > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; > cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol > cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol > cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol > [grid] = ft_prepare_leadfield(cfg); > > I am importing my MEG data with > cfg = []; % empty configuration > cfg.dataset = 'C:/MEG Study/Subjectd001/d001/ > Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.triallength = 2; % duration in seconds > cfg.trialdef.ntrials = inf; % number of trials, inf results > in as many as possible > cfg = ft_definetrial(cfg); > > % preprocess the data > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','- > E4'}; %read all MEG channels except those with '-' > cfg.lpfilter = 'yes'; > cfg.lpfreq = 200; > cfg.bsfilter = 'yes'; %60 Hz noise > cfg.bsfreq = [58 62]; > > data = ft_preprocessing(cfg); > > In the end, when I go to plot them all on the same graph, the head > model seems to be 100 times larger than the gradiometer sensors > (they appear as a small ball in the middle of the head). I've tried > adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't > help the downstream frequency, leadfield, and source analysis. > > Can someone tell me how to ensure the gradiometer and mri/grid are > on the same scale so I can be sure I have the right model for my > beamforming? > > Thank you, > -Allison > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From ting.ac at gmail.com Fri Feb 11 23:25:24 2011 From: ting.ac at gmail.com (Allison Connolly) Date: Fri, 11 Feb 2011 16:25:24 -0600 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> References: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Message-ID: Thanks that seemed to help the scaling issue. However, my beamforming is still not producing results. There is a huge bias towards the center of the head, even though I accounted for the neural activity index. It seems like the beamforming is just projecting everything inwards. I'm not sure where to go from here. Do you have any suggestions on different configuration settings I could try for the beamforming? -Allison On Fri, Feb 11, 2011 at 4:02 PM, Luisa Frei wrote: > Hi Alison, > how do you change the units? I convert them using: > > data.grad=ft_convert_units(data.grad,'cm') > > Maybe this helps. > > Luisa > > > On 11 Feb 2011, at 21:19, Allison Connolly wrote: > > Hello, >> >> I am trying to perform beamforming on some MEG data (148 channels). I have >> the dicom files for the MRI, and I have converted them to .img and .hdr >> files using Curry. >> I am importing them into fieldtrip via >> mri=ft_read_mri('MRI.img'). >> >> Then I manually declaring the fiducials with >> cfg.method = 'interactive'; >> mrialign = ft_volumerealign(cfg, mri); >> >> Then segmenting with >> cfg = []; >> cfg.write = 'no'; >> [segment] = ft_volumesegment(cfg, mri); >> >> Then creating the head model with >> cfg = []; >> cfg.smooth = 'no'; >> vol = ft_prepare_singleshell(cfg, segment); >> >> Then creating the grid with >> cfg = []; >> cfg.grad = freq.grad; >> cfg.vol = vol; >> cfg.reducerank = 'no'; >> cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... >> '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... >> '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; >> cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol >> cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol >> cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol >> [grid] = ft_prepare_leadfield(cfg); >> >> I am importing my MEG data with >> cfg = []; % empty configuration >> cfg.dataset = 'C:/MEG >> Study/Subjectd001/d001/Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; >> cfg.trialfun = 'trialfun_general'; >> cfg.trialdef.triallength = 2; % duration in seconds >> cfg.trialdef.ntrials = inf; % number of trials, inf results in as >> many as possible >> cfg = ft_definetrial(cfg); >> >> % preprocess the data >> cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... >> '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... >> '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; %read >> all MEG channels except those with '-' >> cfg.lpfilter = 'yes'; >> cfg.lpfreq = 200; >> cfg.bsfilter = 'yes'; %60 Hz noise >> cfg.bsfreq = [58 62]; >> >> data = ft_preprocessing(cfg); >> >> In the end, when I go to plot them all on the same graph, the head model >> seems to be 100 times larger than the gradiometer sensors (they appear as a >> small ball in the middle of the head). I've tried adjusting the grad.unit >> parameter from 'm' to 'cm', but it doesn't help the downstream frequency, >> leadfield, and source analysis. >> >> Can someone tell me how to ensure the gradiometer and mri/grid are on the >> same scale so I can be sure I have the right model for my beamforming? >> >> Thank you, >> -Allison >> _______________________________________________ >> 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 l.frei at psy.gla.ac.uk Sat Feb 12 00:05:15 2011 From: l.frei at psy.gla.ac.uk (Luisa Frei) Date: Fri, 11 Feb 2011 23:05:15 +0000 Subject: [FieldTrip] problem aligning MRI with gradiometer In-Reply-To: References: <471A587C-A451-4213-B987-219B98BF63E3@psy.gla.ac.uk> Message-ID: I'm not an expert on beamforming myself. But how clear your results are depends on the preprocessing as well. If your sources are very low in the head, you could have muscle or heartbeat artifacts. I did an ICA to remove the heartbeat component. Sorry I can't give you any more help, someone else can probably help you more. Luisa On 11 Feb 2011, at 22:25, Allison Connolly wrote: > Thanks that seemed to help the scaling issue. However, my > beamforming is still not producing results. There is a huge bias > towards the center of the head, even though I accounted for the > neural activity index. It seems like the beamforming is just > projecting everything inwards. I'm not sure where to go from here. > Do you have any suggestions on different configuration settings I > could try for the beamforming? > > -Allison > > On Fri, Feb 11, 2011 at 4:02 PM, Luisa Frei > wrote: > Hi Alison, > how do you change the units? I convert them using: > > data.grad=ft_convert_units(data.grad,'cm') > > Maybe this helps. > > Luisa > > > On 11 Feb 2011, at 21:19, Allison Connolly wrote: > > Hello, > > I am trying to perform beamforming on some MEG data (148 channels). > I have the dicom files for the MRI, and I have converted them > to .img and .hdr files using Curry. > I am importing them into fieldtrip via > mri=ft_read_mri('MRI.img'). > > Then I manually declaring the fiducials with > cfg.method = 'interactive'; > mrialign = ft_volumerealign(cfg, mri); > > Then segmenting with > cfg = []; > cfg.write = 'no'; > [segment] = ft_volumesegment(cfg, mri); > > Then creating the head model with > cfg = []; > cfg.smooth = 'no'; > vol = ft_prepare_singleshell(cfg, segment); > > Then creating the grid with > cfg = []; > cfg.grad = freq.grad; > cfg.vol = vol; > cfg.reducerank = 'no'; > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','-E4'}; > cfg.grid.xgrid = [-10:0.5:15]; % adjust according to vol > cfg.grid.ygrid = [-15:0.5:15]; % adjust according to vol > cfg.grid.zgrid = [-10:0.5:15]; % adjust according to vol > [grid] = ft_prepare_leadfield(cfg); > > I am importing my MEG data with > cfg = []; % empty configuration > cfg.dataset = 'C:/MEG Study/Subjectd001/d001/ > Billy_180s/06 at -09@-10 at _19_41/4/c,rfhp0.1Hz'; > cfg.trialfun = 'trialfun_general'; > cfg.trialdef.triallength = 2; % duration in seconds > cfg.trialdef.ntrials = inf; % number of trials, inf results > in as many as possible > cfg = ft_definetrial(cfg); > > % preprocess the data > cfg.channel = {'MEG','-TRIGGER','-RESPONSE',... > '-UACurrent','-MxA','-MyA','-MzA','-GxxA','-GyxA','-GyyA',... > '-GzyA','-GzxA','-MxaA','-MyaA','-MzaA','-E1','-E2','-E3','- > E4'}; %read all MEG channels except those with '-' > cfg.lpfilter = 'yes'; > cfg.lpfreq = 200; > cfg.bsfilter = 'yes'; %60 Hz noise > cfg.bsfreq = [58 62]; > > data = ft_preprocessing(cfg); > > In the end, when I go to plot them all on the same graph, the head > model seems to be 100 times larger than the gradiometer sensors > (they appear as a small ball in the middle of the head). I've tried > adjusting the grad.unit parameter from 'm' to 'cm', but it doesn't > help the downstream frequency, leadfield, and source analysis. > > Can someone tell me how to ensure the gradiometer and mri/grid are > on the same scale so I can be sure I have the right model for my > beamforming? > > Thank you, > -Allison > _______________________________________________ > 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 jm.horschig at donders.ru.nl Mon Feb 14 16:18:36 2011 From: jm.horschig at donders.ru.nl (=?ISO-8859-1?Q?=22J=F6rn_M=2E_Horschig=22?=) Date: Mon, 14 Feb 2011 16:18:36 +0100 Subject: [FieldTrip] Single Precision in FieldTrip (2011) Message-ID: <4D5947CC.3010608@donders.ru.nl> Dear all, This mail can be considered as a follow-up from an issue raised back in 2006 - just a little bit more recent (btw, there maybe should a more user-friendly interface to search in the FT mailing archive, it took some time to check if this question has been brought up before). Today, I was thinking about ways to reduce the memory use of FieldTrip/Matlab especially when handling large amount of data - other ways than using machines with huge memory capacities. In the old mailing list, I found a mail conversation started by Ali M. about single precision in 2006. Matlab, and FieldTrip, has advanced quite a lot since then, which resulted in removing at least that one particular Matlab-bug on my machine ;) However, in the past I have found that computations using single precision still yields problems such as wrong results or also incompatibilty of certain functions/operations. I wonder how severe these problems are with current Matlab/FieldTrip versions. Does anyone have experience with single precision computations using FieldTrip? Is it valid or even advisable to use single precision calculations? FYI, my machine runs Win7 64-bit and Matlab 7.9.0.529 (R2009b) Kind regards, Jörn -- Jörn M. Horschig PhD Student Donders Institute for Brain, Cognition and Behaviour Centre for Cognitive Neuroimaging Radboud University Nijmegen 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/fcdonders Visiting address: Trigon, room 2.30 Kapitelweg 29 NL-6525 EN Nijmegen The Netherlands From m.k.van.vugt at rug.nl Tue Feb 15 12:33:46 2011 From: m.k.van.vugt at rug.nl (Marieke van Vugt) Date: Tue, 15 Feb 2011 12:33:46 +0100 Subject: [FieldTrip] fully-funded PhD position in cognitive modeling group Rijksuniversiteit Groningen Message-ID: <05BDAE2A-1847-4DF4-8EE2-35155234794F@rug.nl> PhD position Cognitive Modeling group (1,0 fte) (211047) Organisation We invite applications for a four-year PhD student position available in the Cognitive Modeling group, in the laboratory of Marieke van Vugt (http://www.ai.rug.nl/~mkvanvugt/index_lab.html). The Cognitive Modeling group forms part of the ALICE research institute within the Department of Artificial Intelligence. It has a world-class reputation in cognitive modeling, largely based on the ACT-R architecture. The laboratory of Marieke van Vugt focuses on the neural correlates of decision making based on remembered information, combining modeling, behavioral experiments and EEG/fMRI. Job description The PhD project focuses on relating computational models of decision making based on remembered information to EEG and fMRI data. The drift diffusion model of memory and decision making makes explicit predictions of the dynamics of evidence accumulation, and these predictions will be examined in neural data. The project will bridge the domains of perceptual decision making and recognition memory. Specific focus will be placed on how different brain areas interact to implement this evidence accumulation process and adjust performance on a trial-to-trial basis. The participant will engage in advanced data analysis of existing EEG data sets, and collect new EEG and fMRI data. Qualifications A successful candidate has a Master's degree in Cognitive Neuroscience, Cognitive Science, Experimental Psychology, Artificial Intelligence or a related field, and has programming skills in Matlab, C, or Python. Experience in running EEG and/or fMRI experiments, or in modeling of cognition, is an advantage. Conditions of employment The University of Groningen offers a salary of 2,042 gross per month in the first year up to a maximum of 2,612 gross per month in the final year. The appointment is for a period of four years, which should be finished with a PhD examination. The full time appointment is temporary for 1.5 years with the perspective of prolongation for another 2.5 years. After the first year, there will be an evaluation of the feasibility of successful completion of the PhD thesis within the next three years. A training programme within the Graduate School of Science is part of the agreement. You and your supervisor will make up a plan for additional education and supervising that is specific to your needs. How to apply: Send a cover letter (with professional goals and a statement of interest), a curriculum vitae and two letters of recommendation (PDF format) to the job application portal (http://www.tangram-tis.nl/10378/Kandidaten/Inschrijven/00347-0000004562) before April 1st, 2011, although applications received after the deadline may be considered. Starting date: as soon as possible. Information For information you can contact: Dr Marieke van Vugt, m.k.van.vugt at rug.nl ALICE ---------------------------------------------------------------------------- Marieke van Vugt, PhD Assistant Professor, Cognitive Modeling Group Bernoulliborg, room 326 Nijenborgh 9 9747 AG Groningen The Netherlands phone: +31-6-51954984 (cell) +31-50-363-9487 (office) http://www.ai.rug.nl/~mkvanvugt m.k.van.vugt at rug.nl -------------- next part -------------- An HTML attachment was scrubbed... URL: From cristian.carmeli at gmail.com Tue Feb 15 16:32:39 2011 From: cristian.carmeli at gmail.com (Cristian Carmeli) Date: Tue, 15 Feb 2011 16:32:39 +0100 Subject: [FieldTrip] problem with ft_read_mri Message-ID: Dear FieldTrip users I would like to create a mesh from the MNI brain and when I start running the following command >> mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); I get this error message ??? Error using ==> spm_platform>init_platform at 173 MACI64 not supported architecture for SPM Do you know how to fix that? Or is there any mri structure already available to download somewhere? For complete information, I am using Matlab 7.11 on MacOs 10.6.6 thank you for your help best Cristian -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathanweisz at mac.com Tue Feb 15 16:42:56 2011 From: nathanweisz at mac.com (Nathan Weisz) Date: Tue, 15 Feb 2011 16:42:56 +0100 Subject: [FieldTrip] problem with ft_read_mri In-Reply-To: References: Message-ID: under template/ you'll find a single_subj_T1.mat. looks like what you are looking for (already segmented). good luck, n On 15.02.2011, at 16:32, Cristian Carmeli wrote: > Dear FieldTrip users > > I would like to create a mesh from the MNI brain and when I start running the following command > > >> mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); > > I get this error message > ??? Error using ==> spm_platform>init_platform at 173 > MACI64 not supported architecture for SPM > > Do you know how to fix that? Or is there any mri structure already available to download somewhere? > For complete information, I am using Matlab 7.11 on MacOs 10.6.6 > > thank you for your help > > best > Cristian > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From Gregor.Volberg at psychologie.uni-regensburg.de Tue Feb 15 17:16:57 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Tue, 15 Feb 2011 17:16:57 +0100 Subject: [FieldTrip] Artifacts on plotting grand-averaged BEMs: Normalization issue? Message-ID: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> Dear list members, I encountered a problem when plotting the results of a beamformer analysis with individual BEM headmodels. For each subject, I did an ft_sourceanalysis (DICS) and then interpolated the individual volume on the individual anatomy with ft_sourceinterpolate. The result was normalised onto the SPM8 template brain with ft_volumenormalise; then I computed the grand average with ft_sourcegrandaverage. When I plot the grand average (with cfg.funparameter = 'pow'), I see nice results at expected brain regions, but also artifacts around the outline of the volume - see my attached Figure "source_power.png". It appears as if normalization was imperfect so that a border remains, possibly showing idiosyncratic activations from single subjects. The border does not show up if, with the same data, I do ft_sourcestatistics and then plot the results with cfg.funparameter = 'stat' (see attached "source_stat.png"). One might expect this if the voxels showed activation of only one subject so that a t-test would return NANs. I then had a look into the "*.inside" fields of the normalized volumes and was surprised to see that number of voxels inside the brain was different for each subject (ranging between 23 and 27 % roughly). Should that not be the same number of voxels for each subject after normalization? I am now unsure whether the border is a known behavior when plottig the grand average over individual heads,or whether I made an error with normalization. I would be very happy if any someone had an advice for me. Many thanks and best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_power.png Type: image/png Size: 38081 bytes Desc: Portable Network Graphics Format URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: source_stat.png Type: image/png Size: 31701 bytes Desc: Portable Network Graphics Format URL: From datashare at sciencedb.net Tue Feb 15 23:01:48 2011 From: datashare at sciencedb.net (datashare at sciencedb.net) Date: Tue, 15 Feb 2011 23:01:48 +0100 (CET) Subject: [FieldTrip] Announcement : Neuroscience positions database In-Reply-To: References: Message-ID: Dear Fieldtrip users, * Apologies if you receive this multiple times * We would like to inform you about new forum for neuroscience job announcements: http://sciencedb.net/groups/neuroscience-positions-announcements/forum/ We hope you can use this forum to post announcements from post-doc positions and faculty positions to PhD. projects and internship projects. If you only want to follow the announcement; sign up for a free newswletter: http://feedburner.google.com/fb/a/mailverify?uri=ScienceDbNeurosciencePositions-Announcements&loc=en_US Kind regards, Sciencedb.net PS. Follow us on twitter http://twitter.com/sciencedb or sign-up for our newsletter: http://feedburner.google.com/fb/a/mailverify?uri=ScienceDb --- ScienceDB.net is a non-profit portal for the scientific community. Our service is sponsored by ads and donations. If you have any suggestions or comments, please mail us at sciencedb at sciencedb.net. From Gregor.Volberg at psychologie.uni-regensburg.de Wed Feb 16 11:52:43 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Wed, 16 Feb 2011 11:52:43 +0100 Subject: [FieldTrip] UPDATE: Artifacts on plotting grand-averaged BEMs: Normalization issue? In-Reply-To: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> References: <4D5AB50902000057000088E2@gwsmtp1.uni-regensburg.de> Message-ID: <4D5BBA8B02000057000088F0@gwsmtp1.uni-regensburg.de> Dear list members, I think I fixed the problem described in my last mail. I manually averaged the avg.pow fields of the single subjects and put the average on the corresponding field of the grandaverage-structure. This worked fine, without artifactual borders at the outline of the brain compartement. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> "Gregor Volberg" 2/15/2011 5:16 PM >>> Dear list members, I encountered a problem when plotting the results of a beamformer analysis with individual BEM headmodels. For each subject, I did an ft_sourceanalysis (DICS) and then interpolated the individual volume on the individual anatomy with ft_sourceinterpolate. The result was normalised onto the SPM8 template brain with ft_volumenormalise; then I computed the grand average with ft_sourcegrandaverage. When I plot the grand average (with cfg.funparameter = 'pow'), I see nice results at expected brain regions, but also artifacts around the outline of the volume - see my attached Figure "source_power.png". It appears as if normalization was imperfect so that a border remains, possibly showing idiosyncratic activations from single subjects. The border does not show up if, with the same data, I do ft_sourcestatistics and then plot the results with cfg.funparameter = 'stat' (see attached "source_stat.png"). One might expect this if the voxels showed activation of only one subject so that a t-test would return NANs. I then had a look into the "*.inside" fields of the normalized volumes and was surprised to see that number of voxels inside the brain was different for each subject (ranging between 23 and 27 % roughly). Should that not be the same number of voxels for each subject after normalization? I am now unsure whether the border is a known behavior when plottig the grand average over individual heads,or whether I made an error with normalization. I would be very happy if any someone had an advice for me. Many thanks and best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinvinck at gmail.com Thu Feb 17 09:43:41 2011 From: martinvinck at gmail.com (Martin Vinck) Date: Thu, 17 Feb 2011 09:43:41 +0100 Subject: [FieldTrip] WPLI weighted phase-locking index: available in fieldtrip? (Gregor Volberg) In-Reply-To: References: Message-ID: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> Dear Gregor, Thank you for your interest. Please find, in the latest release, the WPLI functionality in ft_connectivityanalysis. Best regards, Martin Vinck. On Feb 11, 2011, at 10:46 AM, fieldtrip-request at donders.ru.nl wrote: > Send fieldtrip mailing list submissions to > fieldtrip at donders.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 donders.ru.nl > > You can reach the person managing the list at > fieldtrip-owner at donders.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: Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual (Lucie Charles) > 2. WPLI weighted phase-locking index: available in fieldtrip? > (Gregor Volberg) > 3. bug in ft_componentanalysis (Baptiste Gauthier) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Feb 2011 14:03:30 +0100 > From: Lucie Charles > To: Email discussion list for the FieldTrip project > > Subject: Re: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Thank you very much for this very detailed response. > > I didn't know (or forgot) that ft_timelockstatistics could take > several data > sets as an input (I thought we always needed the big data matrix > with all > the subjects). That makes much more sense to remove the option in this > context. > > Thanks again, > > Lucie > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Thank you very much for your feedback. I take the liberty to anyhow >> post >> this to the discussion list, so that other people may take notice / >> join in >> the discussion / etc. >> >> Thanks a lot for this quick response : I understand the logic >> behind this. >> It's true that I noticed some inconsistencies due to the >> interpretation of >> the field dimord which can't be well defined if you have both >> individual and >> average data in your structure. >> >> >> OK >> >> However, I think many people were happy with this option as it was. >> It's >> quite handy to keep both the average and individual data because >> you can >> compute statistics and at the same time you don't have to redo the >> average >> every time. I think a lot of scripts rely on that at least in our >> lab. >> >> >> The historical purpose for supporting cfg.keepindividual = 'yes', >> was in >> order to get a representation of all single subjects' data in a >> single data >> matrix: data.individual. Nowadays, ft_timelockstatistics supports >> multiple >> data structures in the input, i.e. ft_timelockstatistics(cfg, >> subj1, subj2 >> subj3, etc) so I think the call to ft_timelockgrandaverage could >> even be >> bypassed. >> The FieldTrip development team is very keen on providing backward >> compatibility support. While in general this is feasible for the >> functions >> which are in FieldTrip, it is very difficult to realize for lab- >> specific >> scripts. In this particular example I think that clarity of the data >> representation should prevail over backward compatibility issues, >> particularly because in this case there's an easy workaround: just >> call >> ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data >> representation is a prerequisite for further developing the >> software, and >> keeping the historical 'oddity' will only hamper code development. >> >> Furthermore, it's a bit strange to have a function called >> ft_timelockgrandaverage which doesn't compute any grandaverage in >> some cases >> ! >> >> >> I agree, yet see my point above. Some people may just like to have >> the data >> represented in a single matrix. >> >> >> I would suggest to keep the function as it is but add more options >> (such as >> cfg.dimord = 'avg' or 'individual') to make the experimenter aware >> of this >> issue and to solve further computation problem. >> >> >> I hope I could convince you that our philosophy makes sense and >> that you >> and your lab-mates are willing to make the effort of adjusting the >> scripts a >> bit for future analyses. If very problematic, I would advice for >> the current >> analyses to rely on an old version of ft_timelockgrandaverage. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> Thank you again, >> >> Lucie >> >> PS : I've sent this email only to you as this is just a suggestion >> which >> might not be relevant for all users. >> >> >> 2011/2/10 jan-mathijs schoffelen >> >>> Dear Lucie, >>> >>> Yes, indeed this has recently been changed. The logic behind it is >>> the >>> following: >>> >>> One either typically wants to keep the individuals, OR the average. >>> >>> If in your case you need the average, you have to specify >>> cfg.keepindividual = 'no'; >>> >>> Keeping both the average and the individual leads to an inconsistent >>> definition of the data structure. >>> The field 'dimord' does not allow for an unequivocal >>> interpretation of >>> both indidual and avg are present. >>> >>> If you need both the individual, and the avg, you now need to run >>> ft_timelockgrandaverage twice, once with cfg.keepinididual = >>> 'yes', and once >>> with cfg.keepindividual = 'no'; >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >>> >>> Hello everyone, >>> >>> It seems that there has been a modification of >>> ft_timelockgrandaverage : >>> now if you specify cfg.keepindividual = 'yes', the grandaverage is >>> computed >>> but is not included in the output of the function (see above). >>> >>> Why is that ? Many of my scripts rely on this option and I wanted >>> to know >>> if there was a good reason for it. >>> >>> Thanks, >>> >>> Lucie >>> >>> New version of ft_timelockgrandaverage (downloaded yesterday), line >>> 159-176 >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> grandavg = []; >>> grandavg.label = cfg.channel; % cell-array >>> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time';* >>> else >>> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> Older version of ft_timelockgrandaverage (april 2010) >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> %SWITCH CHANNEL TO LABEL? >>> grandavg.label = cfg.channel; % cell-array >>> grandavg.fsample = varargin{1}.fsample; >>> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time'; >>> else >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> >>> -- >>> Lucie CHARLES >>> >>> INSERM-CEA Cognitive Neuroimaging unit >>> >>> CEA/SAC/DSV/DRM/NeuroSpin >>> B?t 145, Point Courrier 156 >>> F-91191 Gif/Yvette, FRANCE >>> Tel : +33 1 69 08 99 74 >>> Fax : +33 1 69 08 79 73 >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> B?t 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > B?t 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 09:46:51 +0100 > From: "Gregor Volberg" > To: "FieldTrip List" > Subject: [FieldTrip] WPLI weighted phase-locking index: available in > fieldtrip? > Message-ID: <4D55058B020000570000882D at gwsmtp1.uni-regensburg.de> > Content-Type: text/plain; charset="us-ascii" > > > Dear fieldtrip developers, > > I was just reading the pre-print of an upcoming article in > Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved > index of phase-synchronization...". As I understand, the proposed > phase-locking index WPLI is not complicated by volume conduction, > and an unbiased version of the WPLI can be computed that is not > affected by trial number. This would be exactely what I need for the > analysis of data from a spatial cueing paradigm. > > In the last paragraph, it is announced that the WPLI is made > available in the fieldtrip toolbox. However, I did not yet find it > (i was searching for it as an option in ft_connectivityanalysis, > last Friday's fieldtrip version). May I ask whether it is planned to > include WPLI / debiased WPLI into that function? Or was it perhaps > intended to be computed by hand from the cross-spectrum. > > Thanks a lot, > Gregor > -- > Dr. rer. nat. Gregor Volberg > ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) > University of Regensburg > Institute for Experimental Psychology > 93040 Regensburg, Germany > Tel: +49 941 943 3862 > Fax: +49 941 943 3233 > http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Feb 2011 10:46:13 +0100 > From: Baptiste Gauthier > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] bug in ft_componentanalysis > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest > update > (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC > without an > input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch > (toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds > \n', > toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 3, Issue 17 > **************************************** From Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 10:57:37 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 10:57:37 +0100 Subject: [FieldTrip] Antw: Re: WPLI weighted phase-locking index: available in fieldtrip? (Gregor Volberg) In-Reply-To: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> References: <09A15B3F-32B6-4E03-8803-52A6DF6D5A04@gmail.com> Message-ID: <4D5CFF21020000570000893A@gwsmtp1.uni-regensburg.de> Dear Martin, thanks a lot for your help! I will try it within the next days. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> Martin Vinck 2/17/2011 9:43 AM >>> Dear Gregor, Thank you for your interest. Please find, in the latest release, the WPLI functionality in ft_connectivityanalysis. Best regards, Martin Vinck. On Feb 11, 2011, at 10:46 AM, fieldtrip-request at donders.ru.nl wrote: > Send fieldtrip mailing list submissions to > fieldtrip at donders.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 donders.ru.nl > > You can reach the person managing the list at > fieldtrip-owner at donders.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: Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual (Lucie Charles) > 2. WPLI weighted phase-locking index: available infieldtrip? > (Gregor Volberg) > 3. bug in ft_componentanalysis (Baptiste Gauthier) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 10 Feb 2011 14:03:30 +0100 > From: Lucie Charles > To: Email discussion list for the FieldTrip project > > Subject: Re: [FieldTrip] Fwd: Modification of ft_timelockgrandaverage > cfg.keepindividual > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Thank you very much for this very detailed response. > > I didn't know (or forgot) that ft_timelockstatistics could take > several data > sets as an input (I thought we always needed the big data matrix > with all > the subjects). That makes much more sense to remove the option in this > context. > > Thanks again, > > Lucie > > 2011/2/10 jan-mathijs schoffelen > >> Dear Lucie, >> >> Thank you very much for your feedback. I take the liberty to anyhow >> post >> this to the discussion list, so that other people may take notice / >> join in >> the discussion / etc. >> >> Thanks a lot for this quick response : I understand the logic >> behind this. >> It's true that I noticed some inconsistencies due to the >> interpretation of >> the field dimord which can't be well defined if you have both >> individual and >> average data in your structure. >> >> >> OK >> >> However, I think many people were happy with this option as it was. >> It's >> quite handy to keep both the average and individual data because >> you can >> compute statistics and at the same time you don't have to redo the >> average >> every time. I think a lot of scripts rely on that at least in our >> lab. >> >> >> The historical purpose for supporting cfg.keepindividual = 'yes', >> was in >> order to get a representation of all single subjects' data in a >> single data >> matrix: data.individual. Nowadays, ft_timelockstatistics supports >> multiple >> data structures in the input, i.e. ft_timelockstatistics(cfg, >> subj1, subj2 >> subj3, etc) so I think the call to ft_timelockgrandaverage could >> even be >> bypassed. >> The FieldTrip development team is very keen on providing backward >> compatibility support. While in general this is feasible for the >> functions >> which are in FieldTrip, it is very difficult to realize for lab- >> specific >> scripts. In this particular example I think that clarity of the data >> representation should prevail over backward compatibility issues, >> particularly because in this case there's an easy workaround: just >> call >> ft_timelockgrandaverage twice. Moreover, a clean and unambiguous data >> representation is a prerequisite for further developing the >> software, and >> keeping the historical 'oddity' will only hamper code development. >> >> Furthermore, it's a bit strange to have a function called >> ft_timelockgrandaverage which doesn't compute any grandaverage in >> some cases >> ! >> >> >> I agree, yet see my point above. Some people may just like to have >> the data >> represented in a single matrix. >> >> >> I would suggest to keep the function as it is but add more options >> (such as >> cfg.dimord = 'avg' or 'individual') to make the experimenter aware >> of this >> issue and to solve further computation problem. >> >> >> I hope I could convince you that our philosophy makes sense and >> that you >> and your lab-mates are willing to make the effort of adjusting the >> scripts a >> bit for future analyses. If very problematic, I would advice for >> the current >> analyses to rely on an old version of ft_timelockgrandaverage. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> Thank you again, >> >> Lucie >> >> PS : I've sent this email only to you as this is just a suggestion >> which >> might not be relevant for all users. >> >> >> 2011/2/10 jan-mathijs schoffelen >> >>> Dear Lucie, >>> >>> Yes, indeed this has recently been changed. The logic behind it is >>> the >>> following: >>> >>> One either typically wants to keep the individuals, OR the average. >>> >>> If in your case you need the average, you have to specify >>> cfg.keepindividual = 'no'; >>> >>> Keeping both the average and the individual leads to an inconsistent >>> definition of the data structure. >>> The field 'dimord' does not allow for an unequivocal >>> interpretation of >>> both indidual and avg are present. >>> >>> If you need both the individual, and the avg, you now need to run >>> ft_timelockgrandaverage twice, once with cfg.keepinididual = >>> 'yes', and once >>> with cfg.keepindividual = 'no'; >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> On Feb 10, 2011, at 11:58 AM, Lucie Charles wrote: >>> >>> Hello everyone, >>> >>> It seems that there has been a modification of >>> ft_timelockgrandaverage : >>> now if you specify cfg.keepindividual = 'yes', the grandaverage is >>> computed >>> but is not included in the output of the function (see above). >>> >>> Why is that ? Many of my scripts rely on this option and I wanted >>> to know >>> if there was a good reason for it. >>> >>> Thanks, >>> >>> Lucie >>> >>> New version of ft_timelockgrandaverage (downloaded yesterday), line >>> 159-176 >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> grandavg = []; >>> grandavg.label = cfg.channel; % cell-array >>> %grandavg.fsample = varargin{1}.fsample; % fsample is obsolete >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> * grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time';* >>> else >>> * grandavg.avg = ResultGrandavg; % Nchan x Nsamples* >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> Older version of ft_timelockgrandaverage (april 2010) >>> >>> %-------------------------------------------- >>> % % collect the results >>> %-------------------------------------------- >>> >>> %SWITCH CHANNEL TO LABEL? >>> grandavg.label = cfg.channel; % cell-array >>> grandavg.fsample = varargin{1}.fsample; >>> grandavg.avg = ResultGrandavg; % Nchan x Nsamples >>> grandavg.var = ResultVar; % Nchan x Nsamples >>> grandavg.time = ResultsTime; % 1 x Nsamples >>> >>> %KEEP INDIVIDUAL MEANS? >>> if strcmp(cfg.keepindividual, 'yes') >>> grandavg.individual = avgmat; % Nsubj x Nchan x Nsamples >>> grandavg.dimord = 'subj_chan_time'; >>> else >>> grandavg.dimord = 'chan_time'; >>> end >>> >>> >>> -- >>> Lucie CHARLES >>> >>> INSERM-CEA Cognitive Neuroimaging unit >>> >>> CEA/SAC/DSV/DRM/NeuroSpin >>> B?t 145, Point Courrier 156 >>> F-91191 Gif/Yvette, FRANCE >>> Tel : +33 1 69 08 99 74 >>> Fax : +33 1 69 08 79 73 >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> >> >> -- >> Lucie CHARLES >> >> INSERM-CEA Cognitive Neuroimaging unit >> >> CEA/SAC/DSV/DRM/NeuroSpin >> B?t 145, Point Courrier 156 >> F-91191 Gif/Yvette, FRANCE >> Tel : +33 1 69 08 99 74 >> Fax : +33 1 69 08 79 73 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > > > -- > Lucie CHARLES > > INSERM-CEA Cognitive Neuroimaging unit > > CEA/SAC/DSV/DRM/NeuroSpin > B?t 145, Point Courrier 156 > F-91191 Gif/Yvette, FRANCE > Tel : +33 1 69 08 99 74 > Fax : +33 1 69 08 79 73 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 2 > Date: Fri, 11 Feb 2011 09:46:51 +0100 > From: "Gregor Volberg" > To: "FieldTrip List" > Subject: [FieldTrip] WPLI weighted phase-locking index: available in > fieldtrip? > Message-ID: <4D55058B020000570000882D at gwsmtp1.uni-regensburg.de> > Content-Type: text/plain; charset="us-ascii" > > > Dear fieldtrip developers, > > I was just reading the pre-print of an upcoming article in > Neuroimage by Martin Vinck, Robert Oostenveld et al., "An improved > index of phase-synchronization...". As I understand, the proposed > phase-locking index WPLI is not complicated by volume conduction, > and an unbiased version of the WPLI can be computed that is not > affected by trial number. This would be exactely what I need for the > analysis of data from a spatial cueing paradigm. > > In the last paragraph, it is announced that the WPLI is made > available in the fieldtrip toolbox. However, I did not yet find it > (i was searching for it as an option in ft_connectivityanalysis, > last Friday's fieldtrip version). May I ask whether it is planned to > include WPLI / debiased WPLI into that function? Or was it perhaps > intended to be computed by hand from the cross-spectrum. > > Thanks a lot, > Gregor > -- > Dr. rer. nat. Gregor Volberg > ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) > University of Regensburg > Institute for Experimental Psychology > 93040 Regensburg, Germany > Tel: +49 941 943 3862 > Fax: +49 941 943 3233 > http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Fri, 11 Feb 2011 10:46:13 +0100 > From: Baptiste Gauthier > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] bug in ft_componentanalysis > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Dear Fieldtrip users, > > I noticed a little error in ft_componentanalysis since your latest > update > (2011/02/09) : > While using the function, I got this error message : > > "??? Error using ==> toc > You must call TIC without an output argument before calling TOC > without an > input argument. > > Error in ==> ft_componentanalysis at 465 > fprintf('total time in componentanalysis %.1f seconds\n', stopwatch > (toc)); > > Error in ==> temprod_NEW_runicaonspectra at 37 > comp = ft_componentanalysis(cfg,data);" > > It seems there's here a bad use of function toc.m > > It should be : "fprintf('total time in componentanalysis %.1f seconds > \n', > toc(stopwatch));" > I tried it and it worked fine. > > Please let me know if I'm wrong. > > Cheers, > > Baptiste gauthier > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > End of fieldtrip Digest, Vol 3, Issue 17 > **************************************** _______________________________________________ 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 Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 15:50:05 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 15:50:05 +0100 Subject: [FieldTrip] reverse-normalising voxel locations to non-interpolated source volumes Message-ID: <4D5D43AD0200005700008956@gwsmtp1.uni-regensburg.de> Dear list members, sorry for asking a lot in recent days - i am entering a new stage of enlightment with respect to source analysis, and there are only one or two questions left until i am there. My current problem is the following: I am trying to find the voxel coordinates in an individual source volume that correspond to the voxel coordinates of a ROI, which i identified in the normalized brain. My original source volume is called SOURCE, the interpolated version is SOURCEi, and the normalized volume is NORM. Starting from NORM, I identified voxel coordinates belonging to a ROI, then determined the corresponding head (MNI) coordinates and transformed them into head coordinates of the interpolated individual source SOURCEi: [x,y,z] = ind2sub(NORM.dim, find(mask==1)); % voxel indices of a ROI as given in mask headcoords_NORM = warp_apply(NORM.transform, [x y z], 'homogeneous'); % head coordinates of ROI headcoords_SOURCEi = warp_apply(inv(NORM.cfg.final), headcoords_NORM, 'homogeneous'); % corresponding head coordinates in SOURCEi I checked this with several source plots and the results looked fine. Next, i did an LCMV beamformer with the option cfg.keepfilter = 'yes' in order to reconstruct source waveforms at the ROI. The resulting SOURCE has the filters that i need, but a lower resolution and therefore different voxel indices than SOURCEi. So i need to take the head coordinates i found for SOURCEi and identify the corresponding grid locations in SOURCE . For this i only found a crude solution where i, within the SOURCE.pos field, search for the triplet that produces the smallest squared difference to the MNI coordinates of my ROI in SOURCEi. The matrix subscripts for that triplet give the best fitting grid location for my desired ROI, and the corresponding index is pointing to my desired filter: indx = find((((SOURCE.pos(:,1)-headcoords_SOURCEi(1)).^2) + ((SOURCE.pos(:,2)-headcoords_SOURCEi(2)).^2) + ((SOURCE.pos(:,3)-headcoords_SOURCEi(3)).^2)) == min (((SOURCE.pos(:,1)-headcoords_SOURCEi(1)).^2) + ((SOURCE.pos(:,2)-headcoords_SOURCEi(2)).^2) + ((SOURCE.pos(:,3)-headcoords_SOURCEi(3)).^2))); % assume that ROI is a single source location, 1*3 vector [xvox, yvox, zvox] = ind2sub(SOURCE.dim, indx); ROI_filter = SOURCE.avg.filter{indx}; I am very unsure with these last lines of code. Is it true that SOURCE.pos holds MNI coordinates (for the code would be useless if not)? Or is there an easier solution that i am not aware of yet? Any comments would be greatly appreciated. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredericroux at hotmail.de Thu Feb 17 16:39:25 2011 From: fredericroux at hotmail.de (Frederic Roux) Date: Thu, 17 Feb 2011 16:39:25 +0100 Subject: [FieldTrip] =?windows-1256?q?indepsamplesF_vs_depsamplesF=FE=FE?= Message-ID: Dear fieldtrip users, in the fieldtrip-tutorial about how to compute cluster-based permutation tests for time frequency data I read that one should use the indepsamplesT statistic for between trials experiments at the single subject level and the depsamplesT statistic for within trial experiments at the single subject level. I would like to compute an F-test at the single subject level to test between trials effects between 3 conditions, and I was wondering if in analogy to the t-test, I could also use the indepsamplesF statistic? Any help on this question would be greatly appreciated. Frederic -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gregor.Volberg at psychologie.uni-regensburg.de Thu Feb 17 20:48:02 2011 From: Gregor.Volberg at psychologie.uni-regensburg.de (Gregor Volberg) Date: Thu, 17 Feb 2011 20:48:02 +0100 Subject: [FieldTrip] =?windows-1256?q?Antw=3A__indepsamplesF_vs_depsamples?= =?windows-1256?b?Rv7+?= Message-ID: <4D5D89810200005700008976@gwsmtp1.uni-regensburg.de> Dear Frederic, technically, this should not be a problem. You find the available statistics functions in the /statfun directory of your fieldtrip folder (the functions have self-explaining names). The functioin you need can be specified with cfg.statistic = 'indepsamplesF'. Mind that you also need to modify the cfg.design accordingly, with three categories instead of two. Best regards, Gregor -- Dr. rer. nat. Gregor Volberg ( mailto:gregor.volberg at psychologie.uni-regensburg.de ) University of Regensburg Institute for Experimental Psychology 93040 Regensburg, Germany Tel: +49 941 943 3862 Fax: +49 941 943 3233 http://www.psychologie.uni-regensburg.de/Greenlee/team/volberg/volberg.html >>> Frederic Roux 17.02.11 17.08 Uhr >>> Dear fieldtrip users, in the fieldtrip-tutorial about how to compute cluster-based permutation tests for time frequency data I read that one should use the indepsamplesT statistic for between trials experiments at the single subject level and the depsamplesT statistic for within trial experiments at the single subject level. I would like to compute an F-test at the single subject level to test between trials effects between 3 conditions, and I was wondering if in analogy to the t-test, I could also use the indepsamplesF statistic? Any help on this question would be greatly appreciated. Frederic From matthew at psych.columbia.edu Fri Feb 18 02:32:08 2011 From: matthew at psych.columbia.edu (Matthew Davidson) Date: Thu, 17 Feb 2011 20:32:08 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? Message-ID: Hi everyone, I'm looking to see if there's an equivalent to the statfun_indepsamplesZcoh function, but for other connectivity measures, like PLV or WPLI. I need to do several single-subject, between-trials analyses of differences between two conditions. Since my data are intracranial EEG, there's no meaningful group test I could use, which I gather is how many people make inferences on connectivity measures. So, has anyone implemented this, or something like it? Am I missing something obvious in how to do this? If I implement it myself, I guess I should randomly partition the trials, compute the WPLIs of the two groups, take the difference, compute the max cluster size, and build a permutation distribution of the max cluster WPLI difference. Is that generally correct? Should I use jackknife variance to transform them into Z-scores for thresholding? Alternatively, if I wanted to do this parametrically, how should I do that? (I ask because Monte Carlo methods w/clustering haven't worked as well as analytic methods on intracranial data where the electrodes are more independent than in MEG or scalp EEG.) What's the proper reference distribution of differences in these bounded connectivity metrics? Do I just compute the jackknife variance, and then do a mass univariate t-test on the connectivity measures (for a single electrode pair and freq bin)? Thanks for any insight or advice you might have, Matthew Davidson From e.maris at donders.ru.nl Fri Feb 18 10:36:36 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Fri, 18 Feb 2011 10:36:36 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: References: Message-ID: <039201cbcf4f$594548f0$0bcfdad0$@maris@donders.ru.nl> Hi Matthew, Permutation inference is valid for comparing two experimental conditions using ANY statistic. If your channels are more or less independent (no common pick-up via volume conduction), then don't use the cluster-based statistics (at least not for the spatial dimension; clustering along the spectral dimension may still be wise). Best, Eric Maris > -----Original Message----- > From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > bounces at donders.ru.nl] On Behalf Of Matthew Davidson > Sent: vrijdag 18 februari 2011 2:32 > To: fieldtrip at donders.ru.nl > Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? > > Hi everyone, I'm looking to see if there's an equivalent to the > statfun_indepsamplesZcoh function, but for other connectivity > measures, like PLV or WPLI. I need to do several single-subject, > between-trials analyses of differences between two conditions. Since > my data are intracranial EEG, there's no meaningful group test I could > use, which I gather is how many people make inferences on connectivity > measures. So, has anyone implemented this, or something like it? Am I > missing something obvious in how to do this? > > If I implement it myself, I guess I should randomly partition the > trials, compute the WPLIs of the two groups, take the difference, > compute the max cluster size, and build a permutation distribution of > the max cluster WPLI difference. Is that generally correct? Should I > use jackknife variance to transform them into Z-scores for > thresholding? > > Alternatively, if I wanted to do this parametrically, how should I do > that? (I ask because Monte Carlo methods w/clustering haven't worked > as well as analytic methods on intracranial data where the electrodes > are more independent than in MEG or scalp EEG.) What's the proper > reference distribution of differences in these bounded connectivity > metrics? Do I just compute the jackknife variance, and then do a mass > univariate t-test on the connectivity measures (for a single electrode > pair and freq bin)? > > Thanks for any insight or advice you might have, > Matthew Davidson > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From matthew at psych.columbia.edu Fri Feb 18 18:31:58 2011 From: matthew at psych.columbia.edu (Matthew Davidson) Date: Fri, 18 Feb 2011 12:31:58 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: <-5697139143563785936@unknownmsgid> References: <-5697139143563785936@unknownmsgid> Message-ID: Thanks for your reply, Dr. Maris. I'm sure you're very busy, so I really appreciate your taking time out to answer me. I'd already tried clustering across only time/frequency and not across channel, but what I found was that the strongest channels "set the bar" for all the others, so to speak. I would see 2-3 strong channels with long significant durations reaching significance, and everything else would be silenced. Whereas with parametric stats, I had enough strong signals to detect changes under FDR and Bonferroni correction across a wide range of times and channels. Would z-scoring to compensate for electrode sensitivity differences have helped? I considered doing Monte Carlo stats for each channel independently, and then adjusting critical p-vals via FDR or Bonferroni, but for 100 channels, I would need at least 20000 permutations just to have the Monte Carlo p-val resolution *approach* the adjusted Bonferroni p-vals, and would probably need more to be safe. Factor in several subjs and contrasts, and I computed my analysis would take a few weeks to run. This was why I asked about a parametric method; while I'd prefer permutation methods, I fear the same problem will occur with my connectivity analysis. I know your focus is on permutation stats, but do you have any insight into how to proceed? Think I could generate a permutation distribution of the WPLI differences from a random sampling of electrodes and contrasts, and then, if they look sufficiently close to normal (or transformable via something like a log transform), use that as an argument for using t-tests if I have to? Thanks again, Matthew On Fri, Feb 18, 2011 at 4:36 AM, Eric Maris wrote: > Hi Matthew, > > > Permutation inference is valid for comparing two experimental conditions > using ANY statistic. If your channels are more or less independent (no > common pick-up via volume conduction), then don't use the cluster-based > statistics (at least not for the spatial dimension; clustering along the > spectral dimension may still be wise). > > Best, > > Eric Maris > > > > >> -----Original Message----- >> From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- >> bounces at donders.ru.nl] On Behalf Of Matthew Davidson >> Sent: vrijdag 18 februari 2011 2:32 >> To: fieldtrip at donders.ru.nl >> Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? >> >> Hi everyone, I'm looking to see if there's an equivalent to the >> statfun_indepsamplesZcoh function, but for other connectivity >> measures, like PLV or WPLI. I need to do several single-subject, >> between-trials analyses of differences between two conditions. Since >> my data are intracranial EEG, there's no meaningful group test I could >> use, which I gather is how many people make inferences on connectivity >> measures. So, has anyone implemented this, or something like it? Am I >> missing something obvious in how to do this? >> >> If I implement it myself, I guess I should randomly partition the >> trials, compute the WPLIs of the two groups, take the difference, >> compute the max cluster size, and build a permutation distribution of >> the max cluster WPLI difference. Is that generally correct? Should I >> use jackknife variance to transform them into Z-scores for >> thresholding? >> >> Alternatively, if I wanted to do this parametrically, how should I do >> that? (I ask because Monte Carlo methods w/clustering haven't worked >> as well as analytic methods on intracranial data where the electrodes >> are more independent than in MEG or scalp EEG.) What's the proper >> reference distribution of differences in these bounded connectivity >> metrics? Do I just compute the jackknife variance, and then do a mass >> univariate t-test on the connectivity measures (for a single electrode >> pair and freq bin)? >> >> Thanks for any insight or advice you might have, >> Matthew Davidson >> _______________________________________________ >> 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 lifengmiao at gmail.com Fri Feb 18 20:07:16 2011 From: lifengmiao at gmail.com (Lifeng Miao) Date: Fri, 18 Feb 2011 12:07:16 -0700 Subject: [FieldTrip] question In-Reply-To: References: Message-ID: Dear Fieldtrip members, I have a question when using Fieldtrip tools. What are the locations of the 64 electrodes for EEG data set "subj2"? Thank you very much! Regards, Lifeng -------------- next part -------------- An HTML attachment was scrubbed... URL: From master_engineer07 at yahoo.com Fri Feb 18 22:42:09 2011 From: master_engineer07 at yahoo.com (yacob Jon Mohamady) Date: Fri, 18 Feb 2011 13:42:09 -0800 (PST) Subject: [FieldTrip] problem with ft_read_mri Message-ID: <250412.78294.qm@web38303.mail.mud.yahoo.com> Hi there, I want to calculate the BEM fo EEG. When I run this command line: mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); it gives the following error: Error using ==> spm_platform>init_platform at 173 PCWIN64 not supported architecture for SPM I have SPM8 and when I change my SPM8 to SPM5 it gives this erros: Error using ==> fread Invalid size. I have windows 7, 64-bit and MATLAB 2010a 64-bit. Do you know how I can fix the problem, please. Thank you Yaqub -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Sun Feb 20 17:34:40 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Sun, 20 Feb 2011 17:34:40 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: References: <-5697139143563785936@unknownmsgid> Message-ID: <003401cbd11c$124fcbe0$36ef63a0$@maris@donders.ru.nl> Dear Matthew, > I'd already tried clustering across only time/frequency and not across > channel, but what I found was that the strongest channels "set the > bar" for all the others, so to speak. I would see 2-3 strong channels > with long significant durations reaching significance, and everything > else would be silenced. Whereas with parametric stats, I had enough > strong signals to detect changes under FDR and Bonferroni correction > across a wide range of times and channels. Would z-scoring to > compensate for electrode sensitivity differences have helped? Are the channel-time-frequency-specific parametric p-values smaller than the corresponding permutation p-values (for the same test statistic, of course)? If that is the case, then I would be suspicious wrt to the validity of the parametric test (i.c., its false alarm rate control). (This does not mean, of course, that a smaller parametric p-value implies poor false alarm control.) It's not clear to me what you mean by z-scoring. Does this amount to a linear transform of the dependent variable (the same one for the conditions that are compared)? > > I considered doing Monte Carlo stats for each channel independently, > and then adjusting critical p-vals via FDR or Bonferroni, but for 100 > channels, I would need at least 20000 permutations just to have the > Monte Carlo p-val resolution *approach* the adjusted Bonferroni > p-vals, and would probably need more to be safe. Factor in several > subjs and contrasts, and I computed my analysis would take a few weeks > to run. > > This was why I asked about a parametric method; while I'd prefer > permutation methods, I fear the same problem will occur with my > connectivity analysis. I know your focus is on permutation stats, but > do you have any insight into how to proceed? Think I could generate a > permutation distribution of the WPLI differences from a random > sampling of electrodes and contrasts, and then, if they look > sufficiently close to normal (or transformable via something like a > log transform), use that as an argument for using t-tests if I have > to? If a parametric test solves my problem, then I will definitely use it. However, for statistical tests outside the normal theory parametric framework, it is typically a big challenge to come up with an appropriate parametric reference distribution. I expect this to hold for the WPLI too. Statistical testing of differences at the level of channel pairs (e.g., differences in coupling strength) is a big methodological challenge, for many reasons (a huge multiple comparison problem, lack of specificity of the coupling measure that is used for testing, difficulty of clustering in the space formed by channel pairs). A discussion of these issues is being the scope of the FT discussion list. It is not clear to me what you mean by "generate a permutation distribution of the WPLI differences from a random sampling of electrodes and contrasts". Constructing a permutation distribution in a single subject study (which I assume you are conducting, because you have ECoG data) involves random partitioning of trials (and not electrodes and contrasts). Best, Eric dr. Eric Maris Donders Institute for Brain, Cognition and Behavior Radboud University P.O. Box 9104 6500 HE Nijmegen The Netherlands T:+31 24 3612651 Mobile: 06 39584581 F:+31 24 3616066 mailto:e.maris at donders.ru.nl http://www.nphyscog.com/ > > Thanks again, > Matthew > > > On Fri, Feb 18, 2011 at 4:36 AM, Eric Maris > wrote: > > Hi Matthew, > > > > > > Permutation inference is valid for comparing two experimental > conditions > > using ANY statistic. If your channels are more or less independent > (no > > common pick-up via volume conduction), then don't use the cluster- > based > > statistics (at least not for the spatial dimension; clustering along > the > > spectral dimension may still be wise). > > > > Best, > > > > Eric Maris > > > > > > > > > >> -----Original Message----- > >> From: fieldtrip-bounces at donders.ru.nl [mailto:fieldtrip- > >> bounces at donders.ru.nl] On Behalf Of Matthew Davidson > >> Sent: vrijdag 18 februari 2011 2:32 > >> To: fieldtrip at donders.ru.nl > >> Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? > >> > >> Hi everyone, I'm looking to see if there's an equivalent to the > >> statfun_indepsamplesZcoh function, but for other connectivity > >> measures, like PLV or WPLI. I need to do several single-subject, > >> between-trials analyses of differences between two conditions. Since > >> my data are intracranial EEG, there's no meaningful group test I > could > >> use, which I gather is how many people make inferences on > connectivity > >> measures. So, has anyone implemented this, or something like it? Am > I > >> missing something obvious in how to do this? > >> > >> If I implement it myself, I guess I should randomly partition the > >> trials, compute the WPLIs of the two groups, take the difference, > >> compute the max cluster size, and build a permutation distribution > of > >> the max cluster WPLI difference. Is that generally correct? Should I > >> use jackknife variance to transform them into Z-scores for > >> thresholding? > >> > >> Alternatively, if I wanted to do this parametrically, how should I > do > >> that? (I ask because Monte Carlo methods w/clustering haven't worked > >> as well as analytic methods on intracranial data where the > electrodes > >> are more independent than in MEG or scalp EEG.) What's the proper > >> reference distribution of differences in these bounded connectivity > >> metrics? Do I just compute the jackknife variance, and then do a > mass > >> univariate t-test on the connectivity measures (for a single > electrode > >> pair and freq bin)? > >> > >> Thanks for any insight or advice you might have, > >> Matthew Davidson > >> _______________________________________________ > >> 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 r.oostenveld at donders.ru.nl Sun Feb 20 21:03:12 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Sun, 20 Feb 2011 21:03:12 +0100 Subject: [FieldTrip] problem with ft_read_mri In-Reply-To: <250412.78294.qm@web38303.mail.mud.yahoo.com> References: <250412.78294.qm@web38303.mail.mud.yahoo.com> Message-ID: Dear Yaqub (and Cristian, who recently had a similar question) FieldTrip uses SPM for some of the MRI reading and processing. For that purpose, fieldtrip/external/spm2 and fieldtrip/external/spm8 are included in the fieldtrip release version. These are automatically added to the path when needed, but will not be added to the path if you already have another version of spm on your path. Your problem (not having the mex file for the right problem) should be solved if you ensure that fieldtrip/external/spm8 is on your path. That version of SPM8 includes the mex files for 64 bit MS Windows and for 64 bit Mac OS X. The ft_read_mri will then call the correct compiled mex file. best regards, Robert On 18 Feb 2011, at 22:42, yacob Jon Mohamady wrote: > Hi there, > > I want to calculate the BEM fo EEG. > When I run this command line: > mri = ft_read_mri('t1_icbm_normal_1mm_pn0_rf0.mnc'); > it gives the following error: > Error using ==> spm_platform>init_platform at 173 > PCWIN64 not supported architecture for SPM > > I have SPM8 and when I change my SPM8 to SPM5 it gives this erros: > Error using ==> fread > Invalid size. > > I have windows 7, 64-bit and MATLAB 2010a 64-bit. > Do you know how I can fix the problem, please. > > Thank you > Yaqub > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From r.oostenveld at donders.ru.nl Mon Feb 21 17:58:07 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Mon, 21 Feb 2011 17:58:07 +0100 Subject: [FieldTrip] question In-Reply-To: References: Message-ID: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> Dear Lifeng I would not know whether we have the 3D positions measured for that subject, but the 2D projected positions for plotting are the ones that correspond to fieldtrip/template/easycap64ch-avg.lay and to the section http://fieldtrip.fcdonders.nl/tutorial/layout#easycap_layouts on the tutorial page that explains how to work with 2D layouts for plotting. best regards, Robert On 18 Feb 2011, at 20:07, Lifeng Miao wrote: > > Dear Fieldtrip members, > I have a question when using Fieldtrip tools. What are the locations > of the 64 electrodes for EEG data set "subj2"? > > Thank you very much! > > Regards, > Lifeng > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From lifengmiao at gmail.com Mon Feb 21 18:22:15 2011 From: lifengmiao at gmail.com (Lifeng Miao) Date: Mon, 21 Feb 2011 10:22:15 -0700 Subject: [FieldTrip] question In-Reply-To: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> References: <269196CC-168E-4C37-81DC-A31E1321FD28@donders.ru.nl> Message-ID: Thank you very much! On Mon, Feb 21, 2011 at 9:58 AM, Robert Oostenveld < r.oostenveld at donders.ru.nl> wrote: > Dear Lifeng > > I would not know whether we have the 3D positions measured for that > subject, but the 2D projected positions for plotting are the ones that > correspond to fieldtrip/template/easycap64ch-avg.lay > and to the section > http://fieldtrip.fcdonders.nl/tutorial/layout#easycap_layouts > on the tutorial page that explains how to work with 2D layouts for > plotting. > > best regards, > Robert > > > > On 18 Feb 2011, at 20:07, Lifeng Miao wrote: > > >> Dear Fieldtrip members, >> I have a question when using Fieldtrip tools. What are the locations of >> the 64 electrodes for EEG data set "subj2"? >> >> Thank you very much! >> >> Regards, >> Lifeng >> >> _______________________________________________ >> 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 Nina.Kahlbrock at uni-duesseldorf.de Mon Feb 21 18:54:27 2011 From: Nina.Kahlbrock at uni-duesseldorf.de (Nina Kahlbrock) Date: Mon, 21 Feb 2011 18:54:27 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics Message-ID: <003901cbd1f0$622291a0$cd136386@VMED.UKD> Dear all, I have a question concerning cluster based permutation statistics. It is more a basic question on the difference between one- and two-sided testings. I recall from simple t-tests that as an approach to your two-sided p-value you can multiply your one-sided p-value by 2. I hope this is correct? And I am assuming this to also hold in the other direction, thus, approximating your one-sided p-value by dividing your two-sided p-value by 2? That is why I am expecting something similar when calculating my statistics with a cluster based permutation approach. So what I am actually doing is comparing two conditions at one sensor, comparing time-frequency data. When I calculate a two-sided dependent samples t-test (cfg = []; cfg.channel = 'all'; cfg.latency = [0.5 1.5]; cfg.avgoverchan = 'no'; cfg.avgovertime = 'no'; cfg.parameter = 'powspctrm'; cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 1000; ) , I find one positive cluster with a p-value of 0.036, thus not significant (see fig 1). When I then change my settings to a one-sided test (cfg.tail = 1; cfg.clustertail = 1; cfg.alpha = 0.05;) , the positive cluster gets a p-value of 0.056, again not significant (see fig 2). With the assumption described above, however, I would expect this to become significant when using a one-sided test. Is my assumption correct? If not, could anybody comment on what is wrong about my assumption? I would be very grateful for any advice! Kind regards and thank you very much in advance! Nina - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nina Kahlbrock Institute of Clinical Neuroscience and Medical Psychology Heinrich Heine University Duesseldorf Universitaetsstr. 1 40225 Düsseldorf Tel.: +49 211 81 18075 Fax. .: +49 211 81 19916 Mail: Nina.Kahlbrock at med.uni-duesseldorf.de http://www.uniklinik-duesseldorf.de/medpsychologie -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fig 1.pdf Type: application/pdf Size: 9504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fig 2.pdf Type: application/pdf Size: 9660 bytes Desc: not available URL: From sunyata at gmail.com Mon Feb 21 21:39:56 2011 From: sunyata at gmail.com (Matthew Davidson) Date: Mon, 21 Feb 2011 15:39:56 -0500 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? In-Reply-To: <-356542662290850285@unknownmsgid> References: <-5697139143563785936@unknownmsgid> <-356542662290850285@unknownmsgid> Message-ID: >> I'd already tried clustering across only time/frequency and not across >> channel, but what I found was that the strongest channels "set the >> bar" for all the others, so to speak. I would see 2-3 strong channels >> with long significant durations reaching significance, and everything >> else would be silenced. Whereas with parametric stats, I had enough >> strong signals to detect changes under FDR and Bonferroni correction >> across a wide range of times and channels. Would z-scoring to >> compensate for electrode sensitivity differences have helped? > > Are the channel-time-frequency-specific parametric p-values smaller than the > corresponding permutation p-values (for the same test statistic, of course)? > If that is the case, then I would be suspicious wrt to the validity of the > parametric test (i.c., its false alarm rate control). (This does not mean, > of course, that a smaller parametric p-value implies poor false alarm > control.) The parametric p-vals are much smaller, but wouldn't they have to be? To reach significance after Bonferroni correction, they'd have to be on the order of .0005. FWIW, when I ran the permutation tests, I did see p-vals at the minimum possible values. > It's not clear to me what you mean by z-scoring. Does this amount to a > linear transform of the dependent variable (the same one for the conditions > that are compared)? This would have involved z-scoring the log power. With intracranial data, some electrodes are simply less sensitive because they're not making good contact with the brain (because of the way they're embedded in plastic sheets, each electrode is not individually placed), and not because they're picking up a more distal/weaker signal. So, one way to compensate would be to normalize the power. I asked just in case, but I didn't really suspect this would work. Even if power were normalized, the cluster-max permutation distribution would still be dominated by the electrodes that were significant for the longest period of time. >> >> I considered doing Monte Carlo stats for each channel independently, >> and then adjusting critical p-vals via FDR or Bonferroni, but for 100 >> channels, I would need at least 20000 permutations just to have the >> Monte Carlo p-val resolution *approach* the adjusted Bonferroni >> p-vals, and would probably need more to be safe. Factor in several >> subjs and contrasts, and I computed my analysis would take a few weeks >> to run. >> >> This was why I asked about a parametric method; while I'd prefer >> permutation methods, I fear the same problem will occur with my >> connectivity analysis. I know your focus is on permutation stats, but >> do you have any insight into how to proceed? Think I could generate a >> permutation distribution of the WPLI differences from a random >> sampling of electrodes and contrasts, and then, if they look >> sufficiently close to normal (or transformable via something like a >> log transform), use that as an argument for using t-tests if I have >> to? > > If a parametric test solves my problem, then I will definitely use it. > However, for statistical tests outside the normal theory parametric > framework, it is typically a big challenge to come up with an appropriate > parametric reference distribution. I expect this to hold for the WPLI too. > > Statistical testing of differences at the level of channel pairs (e.g., > differences in coupling strength) is a big methodological challenge, for > many reasons (a huge multiple comparison problem, lack of specificity of the > coupling measure that is used for testing, difficulty of clustering in the > space formed by channel pairs). A discussion of these issues is being the > scope of the FT discussion list. > > It is not clear to me what you mean by "generate a permutation distribution > of the WPLI differences from a random sampling of electrodes and contrasts". > Constructing a permutation distribution in a single subject study (which I > assume you are conducting, because you have ECoG data) involves random > partitioning of trials (and not electrodes and contrasts). Ehh, this was a bit more ad hoc. I didn't have a formal method in mind, I was just thinking about the Kiebel, Tallon-Baudry and Friston HBM paper where they show that log-transforming power renders it approximately normal. It should, however, be legitimate for any given electrode pair to permute trials, compute the connectivity metrics and their difference, generate a permutation distribution of the difference, and make an inference from that, yes? (Although it doesn't address the MCP.) Thanks for all your help, btw. Matthew From e.maris at donders.ru.nl Mon Feb 21 21:58:52 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Mon, 21 Feb 2011 21:58:52 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics Message-ID: <00b501cbd20a$256bf890$7043e9b0$@maris@donders.ru.nl> Hi Nina, I have a question concerning cluster based permutation statistics. It is more a basic question on the difference between one- and two-sided testings. I recall from simple t-tests that as an approach to your two-sided p-value you can multiply your one-sided p-value by 2. I hope this is correct? And I am assuming this to also hold in the other direction, thus, approximating your one-sided p-value by dividing your two-sided p-value by 2? I propose that you calculate your p-values always one-sided. In fact, this is what the FT permutation statistics functions also do. The difference between a one- and a two-sided test is that you compare this one-sided p-value either with your desired type-I error level (for a one-sided test) or with half your desired type-I error level (for a two-sided test). That is why I am expecting something similar when calculating my statistics with a cluster based permutation approach. So what I am actually doing is comparing two conditions at one sensor, comparing time-frequency data. When I calculate a two-sided dependent samples t-test (cfg = []; cfg.channel = 'all'; cfg.latency = [0.5 1.5]; cfg.avgoverchan = 'no'; cfg.avgovertime = 'no'; cfg.parameter = 'powspctrm'; cfg.method = 'montecarlo'; cfg.statistic = 'depsamplesT'; cfg.correctm = 'cluster'; cfg.clusteralpha = 0.05; cfg.clusterstatistic = 'maxsum'; cfg.tail = 0; cfg.clustertail = 0; cfg.alpha = 0.025; cfg.numrandomization = 1000; ) , I find one positive cluster with a p-value of 0.036, thus not significant (see fig 1). When I then change my settings to a one-sided test (cfg.tail = 1; cfg.clustertail = 1; cfg.alpha = 0.05;) , the positive cluster gets a p-value of 0.056, again not significant (see fig 2). I think that the difference between 0.036 and 0.056 is due to the fact that these are random quantities. If expect that, if you would increase cfg.numrandomization to 100,000, you would find two p-values that are much closer. In any case, the p-values are one-sided, and their calculation is independent of the value that you choose for cfg.alpha. Best, Eric Maris With the assumption described above, however, I would expect this to become significant when using a one-sided test. Is my assumption correct? If not, could anybody comment on what is wrong about my assumption? I would be very grateful for any advice! Kind regards and thank you very much in advance! Nina - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nina Kahlbrock Institute of Clinical Neuroscience and Medical Psychology Heinrich Heine University Duesseldorf Universitaetsstr. 1 40225 Düsseldorf Tel.: +49 211 81 18075 Fax. .: +49 211 81 19916 Mail: Nina.Kahlbrock at med.uni-duesseldorf.de http://www.uniklinik-duesseldorf.de/medpsychologie -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.maris at donders.ru.nl Tue Feb 22 07:26:10 2011 From: e.maris at donders.ru.nl (Eric Maris) Date: Tue, 22 Feb 2011 07:26:10 +0100 Subject: [FieldTrip] Single-subject Monte Carlo PLV or WPLI test? Message-ID: <00c101cbd259$7b5f3330$721d9990$@maris@donders.ru.nl> Hi Matthew, > The parametric p-vals are much smaller, but wouldn't they have to be? > To reach significance after Bonferroni correction, they'd have to be > on the order of .0005. FWIW, when I ran the permutation tests, I did > see p-vals at the minimum possible values. If the parametric p-values are around, say, 1e-10, then I would expect the permutation p-value to be 0, unless numrandomization is set a very high value (around 1e+10). It should, however, be legitimate for any given > electrode pair to permute trials, compute the connectivity metrics and > their difference, generate a permutation distribution of the > difference, and make an inference from that, yes? (Although it doesn't > address the MCP.) Agree. Best, Eric > > Thanks for all your help, btw. > Matthew From Nina.Kahlbrock at uni-duesseldorf.de Tue Feb 22 10:14:08 2011 From: Nina.Kahlbrock at uni-duesseldorf.de (Nina Kahlbrock) Date: Tue, 22 Feb 2011 10:14:08 +0100 Subject: [FieldTrip] One-sided versus two-sided cluster statistics In-Reply-To: <00b501cbd20a$256bf890$7043e9b0$%maris@donders.ru.nl> References: <00b501cbd20a$256bf890$7043e9b0$%maris@donders.ru.nl> Message-ID: <000901cbd270$dd991b80$cd136386@VMED.UKD> Hi Eric, thank you very much for your reply! I still have a question regarding your answer, though. I propose that you calculate your p-values always one-sided. In fact, this is what the FT permutation statistics functions also do. The difference between a one- and a two-sided test is that you compare this one-sided p-value either with your desired type-I error level (for a one-sided test) or with half your desired type-I error level (for a two-sided test). I think that the difference between 0.036 and 0.056 is due to the fact that these are random quantities. If expect that, if you would increase cfg.numrandomization to 100,000, you would find two p-values that are much closer. In any case, the p-values are one-sided, and their calculation is independent of the value that you choose for cfg.alpha. I understand that cfg.alpha only gives the threshold for which of my p-values is counted as being significant. However, I thought, changing cfg.tail would change whether I am looking for positive and negative clusters (cfg.tail = 0, two-sided test), or only positive or only negative clusters (cfg.tail = 1 or -1, one-sided test). The change in stat.prob from 0.036 to 0.056 described in my previous email seems to depend on whether I set cfg.tail to 0 or 1. I've computed it multiple times and witch cfg.tail = 0, stat.prob evolves around 0.03 and with cfg.tail = 1 around 0.05. Could you maybe explain this to me? >From your explanation above I would assume that I can use cfg.tail = 0 and cfg.alpha = 0.05 to end up with a mask including my significant clusters in a one-sided test? Thanks again for your help! Nina -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmeyer at cbs.mpg.de Tue Feb 22 13:01:16 2011 From: lmeyer at cbs.mpg.de (Lars Meyer) Date: Tue, 22 Feb 2011 13:01:16 +0100 Subject: [FieldTrip] =?iso-8859-1?q?correlation_=7C=A0statfun?= Message-ID: dear all, on the new fieldtrip homepage, i find a short suggestion on how to try and run a correlation analysis on timelock data using an external regressor (e.g. an fmri-effect) and a single-rowed cfg.design containing this regressor. my questions now are: how does the data have to look? should i just produce an effect (= difference .avg containing the difference between two erps) for each participant, i.e. my input data is a 1 x participants struct? is it correct that cfg.design is only the regressor (= one value per participant), and that cfg.uvar is empty? if the above are correct: what is the proper statfun to run this type of statistic, i.e. a correlation between the individual effects and an external regressor, if i want to use the cluster statistics monte carlo approach? thanks a lot, l. Lars Meyer Max Planck Institute for Human Cognitive & Brain Sciences Department of Neuropsychology Stephanstrafle 1a 04103 Leipzig | Germany Office | +49 341 99 40 22 66 Mail | lmeyer at cbs.mpg.de Web | www.cbs.mpg.de/~lmeyer From r.oostenveld at donders.ru.nl Tue Feb 22 21:48:35 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Tue, 22 Feb 2011 21:48:35 +0100 Subject: [FieldTrip] Washington University in St. Louis seeks postdoctoral scholar for MEG studies References: <4476B37DB8F5D248AE7C349966A22A04406D2359A8@nilex07.neuroimage.wustl.edu> Message-ID: Dear FieldTrip list members, Please see below or on http://humanconnectome.org for an interesting postdoc opportunity. The successful candidate will (among others) work together with the FieldTrip/Donders team. best regards Robert Oostenveld On 22 Feb 2011, at 19:04, Larson-Prior, Linda wrote: > Dear Colleague, > Washington University in St. Louis announces that a full-time Postdoctoral Research Associate position is available to develop creative methods of magnetoencephalography (MEG) analysis for the Human Connectome Project (HCP). The job announcement for this position is attached and we would appreciate your circulating this position announcement to you trainees. > > Best Regards, > Linda Larson-Prior > Abraham Snyder -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WU_MEG_postdoc_job_description_191113.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 15877 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Wed Feb 23 02:21:17 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Tue, 22 Feb 2011 17:21:17 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume Message-ID: Hello, While writing beamformed images to spm2 format in a previous version of fieldtrip (now lost due to a computer crash), I was able to get nice-looking results; networks of brain regions consistent with existing literature. When I try to write images from the same dataset and the same analysis to spm8 format, my results (t-images computed across subjects) end up being single clusters spanning large sections of the brain (e.g. a 'blob' spanning all of one hemisphere but not the other). Unfortunately, some aspects of my planned data analyses cannot be performed on spm2 images, so I have to find a way of writing to successfully to nifti format. I just noticed that in the comments in the ft_write_volume function, which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under the list of supported dataformats. Is there by any chance a patch out there for writing nifti images? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Wed Feb 23 16:50:16 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Wed, 23 Feb 2011 16:50:16 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: Message-ID: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Dear Jen, I notice that indeed in the documentation section of ft_write_volume there is a FIXME behind nifti. Yet, nifti format seems to be supported by ft_write_volume (at least in a recent version of fieldtrip). Did you try it at all (and ran into problems) or were you held back by the FIXME statement? Could you just try it out using a recent fieldtrip function? Thanks and best wishes Jan-Mathijs On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From jenwhitman at gmail.com Wed Feb 23 19:44:03 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Wed, 23 Feb 2011 10:44:03 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: Dear Jan, Thanks for the quick reply. Yes, I have tried it out quite a few times now, experimenting with different settings in the cfgs. Below I'll paste the code I've been using to write images - first the code that successfully created spm2 images that produced good results, then the code used for creating nifti format images from the same data. The comments in this second part are at this point a bit of a maze of cfg options I've been changing back & forth. Any insights/suggestions regarding how to set up my cfgs to make this work would be greatly appreciated. Jen %%%%%%%% this code generated spm2-compatible images which did work (producing results that made sense). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ sourcePre.avg.pow; cfg = []; cfg.downsample = 2; sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); % projecting the plot onto a surface... cfg = []; cfg.coordinates = 'ctf'; cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this template is in MNI coordinates sourcetempIntN = volumenormalise(cfg, sourcetempInt); filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) 'HzWin' int2str(win) 'width750ms']; cfg=[]; cfg.parameter = 'avg.pow'; % string, describing the functional data to be processed, e.g. 'pow', 'coh' or 'nai' cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % filename without the extension cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive (default = []) cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', 'int16', 'int32', 'float' or 'double' volumewrite(cfg, sourcetempIntN) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%% this code below hasn't worked yet... % I added cfg.spmversion = 'spm8'; % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, % and in the call to prepare_singleshell after calling volumesegment % I've also ensured that spm8 is the only spm version in my path, even in % the fieldtrip/external folder, and ensured that spm8 is installed properly % (files compiled correctly, etc..) sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ sourcePre.avg.pow; filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; cfg = []; % cfg.coordinates = 'spm'; % changed for version 5 % cfg.spmversion = 'spm8'; % changed for version 5 cfg.downsample = 4; sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); % projecting the plot onto a surface... cfg = []; %cfg.coordinates = 'spm'; % changed for version 5 %cfg.coordinates = 'ctf'; % changed for version 5 cfg.coordinates = 'spm'; % changed back to spm for version 9 cfg.downsample = 4; %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets specified in volumewrite) cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has the desired voxel size % cfg.name = [filename]; % changed for version 6 %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' there was no subsequent call to volumewrite) cfg.write= 'no'; % changed for version 6 sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); % this whole cfg and function call added for version 6 cfg=[]; % cfg.parameter = string, describing the functional data to be processed, e.g. 'pow', 'coh' or 'nai' % cfg.filename = filename without the extension % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = []) cfg.parameter='pow'; cfg.filename=filename; cfg.filetype = 'spm'; cfg.spmversion = 'SPM8'; % capitalized after first error message from vers 6 % cfg.dataformat='nifti'; % added after first error message from vers 6 % commented out after 2nd error message from vers 6 %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to specify unless cfg.filetyp='vmp' cfg.coordinates='spm'; ft_volumewrite(cfg,sourcetempIntN); On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume there > is a FIXME behind nifti. Yet, nifti format seems to be supported by > ft_write_volume (at least in a recent version of fieldtrip). Did you try it > at all (and ran into problems) or were you held back by the FIXME statement? > Could you just try it out using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, >> >> While writing beamformed images to spm2 format in a previous version of >> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >> results; networks of brain regions consistent with existing literature. When >> I try to write images from the same dataset and the same analysis to spm8 >> format, my results (t-images computed across subjects) end up being single >> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >> one hemisphere but not the other). Unfortunately, some aspects of my planned >> data analyses cannot be performed on spm2 images, so I have to find a way of >> writing to successfully to nifti format. >> >> I just noticed that in the comments in the ft_write_volume function, which >> I am calling via ft_volumewrite, it says 'FIXME' next to nifti under the >> list of supported dataformats. Is there by any chance a patch out there for >> writing nifti images? >> >> Thanks! >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Thu Feb 24 07:58:24 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 24 Feb 2011 07:58:24 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: Hi Jen, Thanks for sending the code. What is the actual error message you are getting? Best wishes, Jan-Mathijs On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few > times now, experimenting with different settings in the cfgs. Below > I'll paste the code I've been using to write images - first the code > that successfully created spm2 images that produced good results, > then the code used for creating nifti format images from the same > data. The comments in this second part are at this point a bit of a > maze of cfg options I've been changing back & forth. Any insights/ > suggestions regarding how to set up my cfgs to make this work would > be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; > %this template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the > functional data to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; > %'testimageoutput_alphafreq'; % filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and > ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, > even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this > gets specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to > using spm8/templates/EPI.nii, except that mask.nii (produced from > fmri data) has the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to > 'yes' there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format > to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive > (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message > from vers 6 > % cfg.dataformat='nifti'; % added after first error message from > vers 6 > % commented out after 2nd error > message from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need > to specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume > there is a FIXME behind nifti. Yet, nifti format seems to be > supported by ft_write_volume (at least in a recent version of > fieldtrip). Did you try it at all (and ran into problems) or were > you held back by the FIXME statement? Could you just try it out > using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.schoffelen at donders.ru.nl Thu Feb 24 13:44:51 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Thu, 24 Feb 2011 13:44:51 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> Message-ID: <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Dear Jen, I managed to reproduce your problem. The code was rather buggy and indeed ft_volumewrite did not behave as it should have. I now fixed it in the code and it should run fine now. Please find the updated file attached. It will be available on our ftp-server as of tonight. Please note that I updated the documentation, and changed the names of some of the options a bit. If you want to save your data in analyze-format, you should specify cfg.filetype = 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a volume to nifti-format, using SPM8. Best wishes, Jan-Mathijs On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few > times now, experimenting with different settings in the cfgs. Below > I'll paste the code I've been using to write images - first the code > that successfully created spm2 images that produced good results, > then the code used for creating nifti format images from the same > data. The comments in this second part are at this point a bit of a > maze of cfg options I've been changing back & forth. Any insights/ > suggestions regarding how to set up my cfgs to make this work would > be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; > %this template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the > functional data to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; > %'testimageoutput_alphafreq'; % filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and > ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, > even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' > int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this > gets specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to > using spm8/templates/EPI.nii, except that mask.nii (produced from > fmri data) has the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to > 'yes' there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format > to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive > (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message > from vers 6 > % cfg.dataformat='nifti'; % added after first error message from > vers 6 > % commented out after 2nd error > message from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need > to specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I notice that indeed in the documentation section of ft_write_volume > there is a FIXME behind nifti. Yet, nifti format seems to be > supported by ft_write_volume (at least in a recent version of > fieldtrip). Did you try it at all (and ran into problems) or were > you held back by the FIXME statement? Could you just try it out > using a recent fieldtrip function? > > Thanks and best wishes > > Jan-Mathijs > > > > On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: > > Hello, > > While writing beamformed images to spm2 format in a previous version > of fieldtrip (now lost due to a computer crash), I was able to get > nice-looking results; networks of brain regions consistent with > existing literature. When I try to write images from the same > dataset and the same analysis to spm8 format, my results (t-images > computed across subjects) end up being single clusters spanning > large sections of the brain (e.g. a 'blob' spanning all of one > hemisphere but not the other). Unfortunately, some aspects of my > planned data analyses cannot be performed on spm2 images, so I have > to find a way of writing to successfully to nifti format. > > I just noticed that in the comments in the ft_write_volume function, > which I am calling via ft_volumewrite, it says 'FIXME' next to nifti > under the list of supported dataformats. Is there by any chance a > patch out there for writing nifti images? > > Thanks! > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ft_volumewrite.m Type: application/octet-stream Size: 16641 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.litvak at ion.ucl.ac.uk Thu Feb 24 17:06:06 2011 From: v.litvak at ion.ucl.ac.uk (Vladimir Litvak) Date: Thu, 24 Feb 2011 16:06:06 +0000 Subject: [FieldTrip] ICA In-Reply-To: <1625468855117010300@unknownmsgid> References: <1625468855117010300@unknownmsgid> Message-ID: Hi Holly, I'm not sure why the databrowser needs the trl struct or whether we can add something to our exported FT struct to make it happy. I'm CCing to the Fieldtrip list to perhaps get some answers. I got exactly the same complaint from someone else last week. Best, Vladimir On Thu, Feb 24, 2011 at 2:48 PM, Holly Rossiter wrote: > Hi Vladimir, > > > > I am trying out using ICA on my data to see what difference it makes to the > eye blinks and whether it is a step worth doing or not. I am using a > fieldtrip script... > > > > D= spm_eeg_load; > > data = D.ftraw(0); > > cfg = []; > > cfg.channel = 'MEG'; > > ic_data = ft_componentanalysis(cfg,data); > > cfg = []; > > cfg.viewmode = 'component'; > > cfg.continuous = 'yes'; > > cfg.layout = 'CTF275.lay'; > > cfg.blocksize = 30; > > cfg.channels = [1:10]; > > ft_databrowser(cfg,ic_data); > > > > But it comes up with an error saying > > > > Error using ==> ft_databrowser at 217 > > no trials to display > > > > I think this may be because I don’t have a trl matrix due to using > spm_eeg_load. Do you know how I can create one of these using spm format > data? Or how else to write the script so that ICA will work? > > > > Kind regards, > > > > Holly From jenwhitman at gmail.com Thu Feb 24 19:07:23 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Thu, 24 Feb 2011 10:07:23 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Great, thanks! I'll start the analysis with your new script today and will let you know how it works out. Jen On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I managed to reproduce your problem. The code was rather buggy and indeed > ft_volumewrite did not behave as it should have. I now fixed it in the code > and it should run fine now. Please find the updated file attached. It will > be available on our ftp-server as of tonight. Please note that I updated the > documentation, and changed the names of some of the options a bit. If you > want to save your data in analyze-format, you should specify cfg.filetype = > 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a > volume to nifti-format, using SPM8. > > Best wishes, > > Jan-Mathijs > > > > > > On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > > > Dear Jan, > > Thanks for the quick reply. Yes, I have tried it out quite a few times now, > experimenting with different settings in the cfgs. Below I'll paste the code > I've been using to write images - first the code that successfully created > spm2 images that produced good results, then the code used for creating > nifti format images from the same data. The comments in this second part are > at this point a bit of a maze of cfg options I've been changing back & > forth. Any insights/suggestions regarding how to set up my cfgs to make this > work would be greatly appreciated. > > Jen > > > %%%%%%%% this code generated spm2-compatible images which did work > (producing results that made sense). > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > cfg = []; > cfg.downsample = 2; > sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); > > % projecting the plot onto a surface... > cfg = []; > cfg.coordinates = 'ctf'; > cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this > template is in MNI coordinates > sourcetempIntN = volumenormalise(cfg, sourcetempInt); > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) > 'HzWin' int2str(win) 'width750ms']; > cfg=[]; > cfg.parameter = 'avg.pow'; % string, describing the functional data > to be processed, e.g. 'pow', 'coh' or 'nai' > cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % > filename without the extension > cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' > cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive > (default = []) > cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', > 'int16', 'int32', 'float' or 'double' > > volumewrite(cfg, sourcetempIntN) > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > %%%%% this code below hasn't worked yet... > > % I added cfg.spmversion = 'spm8'; > % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, > % and in the call to prepare_singleshell after calling volumesegment > > % I've also ensured that spm8 is the only spm version in my path, even in > % the fieldtrip/external folder, and ensured that spm8 is installed > properly > % (files compiled correctly, etc..) > > sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ > sourcePre.avg.pow; > > filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) > 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; > > cfg = []; > % cfg.coordinates = 'spm'; % changed for version 5 > % cfg.spmversion = 'spm8'; % changed for version 5 > cfg.downsample = 4; > sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); > > > % projecting the plot onto a surface... > cfg = []; > %cfg.coordinates = 'spm'; % changed for version 5 > %cfg.coordinates = 'ctf'; % changed for version 5 > cfg.coordinates = 'spm'; % changed back to spm for version 9 > cfg.downsample = 4; > %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets > specified in volumewrite) > cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using > spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has > the desired voxel size > % cfg.name = [filename]; % changed for version 6 > %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' > there was no subsequent call to volumewrite) > cfg.write= 'no'; % changed for version 6 > sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); > > % this whole cfg and function call added for version 6 > cfg=[]; > % cfg.parameter = string, describing the functional data to be > processed, e.g. 'pow', 'coh' or 'nai' > % cfg.filename = filename without the extension > % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' > % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use > % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = []) > cfg.parameter='pow'; > cfg.filename=filename; > cfg.filetype = 'spm'; > cfg.spmversion = 'SPM8'; % capitalized after first error message from > vers 6 > % cfg.dataformat='nifti'; % added after first error message from vers 6 > % commented out after 2nd error message > from vers 6 > %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to > specify unless cfg.filetyp='vmp' > cfg.coordinates='spm'; > ft_volumewrite(cfg,sourcetempIntN); > > > > > > On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I notice that indeed in the documentation section of ft_write_volume there >> is a FIXME behind nifti. Yet, nifti format seems to be supported by >> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >> at all (and ran into problems) or were you held back by the FIXME statement? >> Could you just try it out using a recent fieldtrip function? >> >> Thanks and best wishes >> >> Jan-Mathijs >> >> >> >> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >> >> Hello, >>> >>> While writing beamformed images to spm2 format in a previous version of >>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>> results; networks of brain regions consistent with existing literature. When >>> I try to write images from the same dataset and the same analysis to spm8 >>> format, my results (t-images computed across subjects) end up being single >>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>> data analyses cannot be performed on spm2 images, so I have to find a way of >>> writing to successfully to nifti format. >>> >>> I just noticed that in the comments in the ft_write_volume function, >>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>> the list of supported dataformats. Is there by any chance a patch out there >>> for writing nifti images? >>> >>> Thanks! >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 ekanal at cmu.edu Fri Feb 25 20:10:59 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 14:10:59 -0500 Subject: [FieldTrip] ft_componentbrowser problem Message-ID: Hello - I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: ~~~~ cfg = struct('method','fastica','channel','M*','numcomponent','10'); components = ft_componentanalysis(cfg, data_preprocessed); cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); ft_componentbrowser(cfg,components); ~~~~ I increase the The script fails at the final line with the following error: ~~~~ ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. Error in ==> ft_plot_topo at 92 inside = inside_contour([chanX chanY], mask{1}); Error in ==> ft_componentbrowser>plottopography at 172 ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... Error in ==> ft_componentbrowser at 116 plottopography([], cfg, comp) ~~~~ Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - Elli Kanal -------------------- Eliezer Kanal, Ph.D. Postdoctoral Fellow Center for the Neural Basis of Cognition Carnegie Mellon University 4400 Fifth Ave, Suite 115 Pittsburgh PA 15213 P: 412-268-4115 F: 412-268-5060 From jan.schoffelen at donders.ru.nl Fri Feb 25 20:33:43 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 25 Feb 2011 20:33:43 +0100 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: <9745F187-5622-4F8A-9939-0F4ED3D5B2F0@donders.ru.nl> Dear Elli, Apparently the ft_componentbrowser function cannot find inside_contour.m I know that ft_componentbrowser will soon be replaced by the more generic ft_databrowser, and it could be that in this process some changes have already been made, breaking the componentbrowser. Or perhaps something else is going on... Either way, inside_contour.m is located in fieldtrip/plotting/private, and it cannot be seen by ft_componentbrowser, because this function is located at fieldtrip/. If you copy inside_contour to the directory fieldtrip/private I expect that your problem is solved. Good luck, Jan-Mathijs On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > Hello - > > I have a simple script which seems to be failing on > ft_componentbrowser, and I can't figure out why. The script is as > follows: > > ~~~~ > cfg = struct('method','fastica','channel','M*','numcomponent','10'); > components = ft_componentanalysis(cfg, data_preprocessed); > > cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); > ft_componentbrowser(cfg,components); > ~~~~ > > I increase the The script fails at the final line with the following > error: > > ~~~~ > ??? Undefined function or method 'inside_contour' for input > arguments of type 'double'. > > Error in ==> ft_plot_topo at 92 > inside = inside_contour([chanX chanY], mask{1}); > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), > cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Any ideas as to why this isn't working? I'm pretty stuck at this > point. Thanks - > > Elli Kanal > > > -------------------- > Eliezer Kanal, Ph.D. > Postdoctoral Fellow > Center for the Neural Basis of Cognition > Carnegie Mellon University > 4400 Fifth Ave, Suite 115 > Pittsburgh PA 15213 > P: 412-268-4115 > F: 412-268-5060 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From jan.schoffelen at donders.ru.nl Fri Feb 25 20:38:40 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Fri, 25 Feb 2011 20:38:40 +0100 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: Hi Elli, Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? If not, I suggest you download a recent fieldtrip version, and try again. Best wishes, Jan-Mathijs On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > Hello - > > I have a simple script which seems to be failing on > ft_componentbrowser, and I can't figure out why. The script is as > follows: > > ~~~~ > cfg = struct('method','fastica','channel','M*','numcomponent','10'); > components = ft_componentanalysis(cfg, data_preprocessed); > > cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); > ft_componentbrowser(cfg,components); > ~~~~ > > I increase the The script fails at the final line with the following > error: > > ~~~~ > ??? Undefined function or method 'inside_contour' for input > arguments of type 'double'. > > Error in ==> ft_plot_topo at 92 > inside = inside_contour([chanX chanY], mask{1}); > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), > cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Any ideas as to why this isn't working? I'm pretty stuck at this > point. Thanks - > > Elli Kanal > > > -------------------- > Eliezer Kanal, Ph.D. > Postdoctoral Fellow > Center for the Neural Basis of Cognition > Carnegie Mellon University > 4400 Fifth Ave, Suite 115 > Pittsburgh PA 15213 > P: 412-268-4115 > F: 412-268-5060 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 From ekanal at cmu.edu Fri Feb 25 20:52:02 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 14:52:02 -0500 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: References: Message-ID: <7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> Hello Dr Schoffelen - Thanks for the quick reply. I've been periodically updating from the SVN directory, but it appears my local working directory had become messed up. The file is now found. However, it seems to have uncovered another error: ~~~~ >> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay','channel','M*'); >> ft_componentbrowser(cfg,components); reading layout from file neuromag306all.lay ??? Error using ==> rdivide Matrix dimensions must agree. Error in ==> ft_componentbrowser>plottopography at 172 ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... Error in ==> ft_componentbrowser at 116 plottopography([], cfg, comp) ~~~~ Once again, any ideas? Thanks - Elli On Feb 25, 2011, at 2:38 PM, jan-mathijs schoffelen wrote: > Hi Elli, > > Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? > If not, I suggest you download a recent fieldtrip version, and try again. > > Best wishes, > > Jan-Mathijs > > On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: > >> Hello - >> >> I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: >> >> ~~~~ >> cfg = struct('method','fastica','channel','M*','numcomponent','10'); >> components = ft_componentanalysis(cfg, data_preprocessed); >> >> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); >> ft_componentbrowser(cfg,components); >> ~~~~ >> >> I increase the The script fails at the final line with the following error: >> >> ~~~~ >> ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. >> >> Error in ==> ft_plot_topo at 92 >> inside = inside_contour([chanX chanY], mask{1}); >> >> Error in ==> ft_componentbrowser>plottopography at 172 >> ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... >> >> Error in ==> ft_componentbrowser at 116 >> plottopography([], cfg, comp) >> ~~~~ >> >> Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - >> >> Elli Kanal >> >> >> -------------------- >> Eliezer Kanal, Ph.D. >> Postdoctoral Fellow >> Center for the Neural Basis of Cognition >> Carnegie Mellon University >> 4400 Fifth Ave, Suite 115 >> Pittsburgh PA 15213 >> P: 412-268-4115 >> F: 412-268-5060 >> >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jenwhitman at gmail.com Fri Feb 25 21:44:55 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Fri, 25 Feb 2011 12:44:55 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Hi Jan, I tried re-running the analysis with the new script you sent me, and the latest version of fieldtrip (since I needed ft_get_opt as well), but the spm8 images being written are still producing flawed results. It's the same problem as I mentioned briefly in my previous post. I am not getting any error messages when writing these images. Rather, my problem is that the spm8 and spm2 results from the same data ought to be identical when viewed in mricron, but they're far from it. When I use mricron to look at the results from the spm8-format images, combined across participants to create a t-image, I just get a single 'blob' spanning roughly half the brain. In contrast, when I used spm2-format previously on the same data, the t-image was much more meaningful; a posterior alpha power decrease in a set of regions corresponding to the 'task-positive network' (a network found in the results of an fMRI version of my experiment, and widely reported in the fMRI literature). This failure to replicate the spm2 results when using spm8 images from the same data leads me to suspect that something is wrong with the coordinates for spm8 format. However, after experimenting extensively with different cfg options I still haven't identified the problem. If I my structural MRIs have been saved to .mri files using CTF's MRIConverter program, which cfg options, particularly for coordinates, template images, and filetypes, should I specify before calling the ft_volumesegment, ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite functions? Or should I be calling a different set of functions now? Thanks again for your help, Jen On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: > Great, thanks! > > I'll start the analysis with your new script today and will let you know > how it works out. > > Jen > > On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I managed to reproduce your problem. The code was rather buggy and indeed >> ft_volumewrite did not behave as it should have. I now fixed it in the code >> and it should run fine now. Please find the updated file attached. It will >> be available on our ftp-server as of tonight. Please note that I updated the >> documentation, and changed the names of some of the options a bit. If you >> want to save your data in analyze-format, you should specify cfg.filetype = >> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a >> volume to nifti-format, using SPM8. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> >> >> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >> >> >> Dear Jan, >> >> Thanks for the quick reply. Yes, I have tried it out quite a few times >> now, experimenting with different settings in the cfgs. Below I'll paste the >> code I've been using to write images - first the code that successfully >> created spm2 images that produced good results, then the code used for >> creating nifti format images from the same data. The comments in this second >> part are at this point a bit of a maze of cfg options I've been changing >> back & forth. Any insights/suggestions regarding how to set up my cfgs to >> make this work would be greatly appreciated. >> >> Jen >> >> >> %%%%%%%% this code generated spm2-compatible images which did work >> (producing results that made sense). >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >> sourcePre.avg.pow; >> >> cfg = []; >> cfg.downsample = 2; >> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >> >> % projecting the plot onto a surface... >> cfg = []; >> cfg.coordinates = 'ctf'; >> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this >> template is in MNI coordinates >> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >> 'HzWin' int2str(win) 'width750ms']; >> cfg=[]; >> cfg.parameter = 'avg.pow'; % string, describing the functional >> data to be processed, e.g. 'pow', 'coh' or 'nai' >> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; % >> filename without the extension >> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >> (default = []) >> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >> 'int16', 'int32', 'float' or 'double' >> >> volumewrite(cfg, sourcetempIntN) >> >> >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%% this code below hasn't worked yet... >> >> % I added cfg.spmversion = 'spm8'; >> % in the cfgs for the calls to ft_prepare_leadfield and ft_sourceanalysis, >> % and in the call to prepare_singleshell after calling volumesegment >> >> % I've also ensured that spm8 is the only spm version in my path, even in >> % the fieldtrip/external folder, and ensured that spm8 is installed >> properly >> % (files compiled correctly, etc..) >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >> sourcePre.avg.pow; >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >> >> cfg = []; >> % cfg.coordinates = 'spm'; % changed for version 5 >> % cfg.spmversion = 'spm8'; % changed for version 5 >> cfg.downsample = 4; >> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >> >> >> % projecting the plot onto a surface... >> cfg = []; >> %cfg.coordinates = 'spm'; % changed for version 5 >> %cfg.coordinates = 'ctf'; % changed for version 5 >> cfg.coordinates = 'spm'; % changed back to spm for version 9 >> cfg.downsample = 4; >> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >> specified in volumewrite) >> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to using >> spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) has >> the desired voxel size >> % cfg.name = [filename]; % changed for version 6 >> %cfg.write= 'yes'; % changed for version 6 (when this was set to 'yes' >> there was no subsequent call to volumewrite) >> cfg.write= 'no'; % changed for version 6 >> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >> >> % this whole cfg and function call added for version 6 >> cfg=[]; >> % cfg.parameter = string, describing the functional data to be >> processed, e.g. 'pow', 'coh' or 'nai' >> % cfg.filename = filename without the extension >> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use >> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >> []) >> cfg.parameter='pow'; >> cfg.filename=filename; >> cfg.filetype = 'spm'; >> cfg.spmversion = 'SPM8'; % capitalized after first error message from >> vers 6 >> % cfg.dataformat='nifti'; % added after first error message from vers 6 >> % commented out after 2nd error message >> from vers 6 >> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >> specify unless cfg.filetyp='vmp' >> cfg.coordinates='spm'; >> ft_volumewrite(cfg,sourcetempIntN); >> >> >> >> >> >> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl> wrote: >> >>> Dear Jen, >>> >>> I notice that indeed in the documentation section of ft_write_volume >>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>> at all (and ran into problems) or were you held back by the FIXME statement? >>> Could you just try it out using a recent fieldtrip function? >>> >>> Thanks and best wishes >>> >>> Jan-Mathijs >>> >>> >>> >>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>> >>> Hello, >>>> >>>> While writing beamformed images to spm2 format in a previous version of >>>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>>> results; networks of brain regions consistent with existing literature. When >>>> I try to write images from the same dataset and the same analysis to spm8 >>>> format, my results (t-images computed across subjects) end up being single >>>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>>> data analyses cannot be performed on spm2 images, so I have to find a way of >>>> writing to successfully to nifti format. >>>> >>>> I just noticed that in the comments in the ft_write_volume function, >>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>> the list of supported dataformats. Is there by any chance a patch out there >>>> for writing nifti images? >>>> >>>> Thanks! >>>> >>>> _______________________________________________ >>>> fieldtrip mailing list >>>> fieldtrip at donders.ru.nl >>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> _______________________________________________ >>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 ekanal at cmu.edu Fri Feb 25 22:32:12 2011 From: ekanal at cmu.edu (Kanal Eliezer) Date: Fri, 25 Feb 2011 16:32:12 -0500 Subject: [FieldTrip] ft_componentbrowser problem In-Reply-To: <7030_1298663591_p1PJr8OZ010844_7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> References: <7030_1298663591_p1PJr8OZ010844_7375230D-A397-4CD3-BBE2-1E8A9AE929BB@cmu.edu> Message-ID: Never mind, the problem was my specifying the 'comp' item as a string (with single quotes'1:10') instead of a vector. Thanks for your help - Elli On Feb 25, 2011, at 2:52 PM, Kanal Eliezer wrote: > Hello Dr Schoffelen - > > Thanks for the quick reply. I've been periodically updating from the SVN directory, but it appears my local working directory had become messed up. The file is now found. > > However, it seems to have uncovered another error: > > ~~~~ >>> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay','channel','M*'); >>> ft_componentbrowser(cfg,components); > reading layout from file neuromag306all.lay > ??? Error using ==> rdivide > Matrix dimensions must agree. > > Error in ==> ft_componentbrowser>plottopography at 172 > ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... > > Error in ==> ft_componentbrowser at 116 > plottopography([], cfg, comp) > ~~~~ > > Once again, any ideas? Thanks - > > Elli > > > On Feb 25, 2011, at 2:38 PM, jan-mathijs schoffelen wrote: > >> Hi Elli, >> >> Forget about my previous e-mail. I did not read thoroughly your error log. The problem does not happen in ft_componentbrowser, but it occurs in ft_plot_topo. This function is in fieldtrip/plotting, and it should be able to see the functions in fieldtrip/plotting/private, i.e. it should be able to locate the inside_contour.m, provided it can be found at this location. Could you check whether your fieldtrip version has inside_contour in fieldtrip/plotting/private? >> If not, I suggest you download a recent fieldtrip version, and try again. >> >> Best wishes, >> >> Jan-Mathijs >> >> On Feb 25, 2011, at 8:10 PM, Kanal Eliezer wrote: >> >>> Hello - >>> >>> I have a simple script which seems to be failing on ft_componentbrowser, and I can't figure out why. The script is as follows: >>> >>> ~~~~ >>> cfg = struct('method','fastica','channel','M*','numcomponent','10'); >>> components = ft_componentanalysis(cfg, data_preprocessed); >>> >>> cfg = struct('comp','1:10','trial','1','layout','neuromag306all.lay'); >>> ft_componentbrowser(cfg,components); >>> ~~~~ >>> >>> I increase the The script fails at the final line with the following error: >>> >>> ~~~~ >>> ??? Undefined function or method 'inside_contour' for input arguments of type 'double'. >>> >>> Error in ==> ft_plot_topo at 92 >>> inside = inside_contour([chanX chanY], mask{1}); >>> >>> Error in ==> ft_componentbrowser>plottopography at 172 >>> ft_plot_topo(cfg.layout.pos(cfg.chanidx.lay,1), cfg.layout.pos(cfg.chanidx.lay,2), ... >>> >>> Error in ==> ft_componentbrowser at 116 >>> plottopography([], cfg, comp) >>> ~~~~ >>> >>> Any ideas as to why this isn't working? I'm pretty stuck at this point. Thanks - >>> >>> Elli Kanal >>> >>> >>> -------------------- >>> Eliezer Kanal, Ph.D. >>> Postdoctoral Fellow >>> Center for the Neural Basis of Cognition >>> Carnegie Mellon University >>> 4400 Fifth Ave, Suite 115 >>> Pittsburgh PA 15213 >>> P: 412-268-4115 >>> F: 412-268-5060 >>> >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 r.oostenveld at donders.ru.nl Sat Feb 26 10:15:35 2011 From: r.oostenveld at donders.ru.nl (Robert Oostenveld) Date: Sat, 26 Feb 2011 10:15:35 +0100 Subject: [FieldTrip] ICA In-Reply-To: References: <1625468855117010300@unknownmsgid> Message-ID: <2D910383-6EC3-4467-9946-C4321614591A@donders.ru.nl> Hi Holly The ft_databrowser function was initially written for identifying segments (artifacts, sleep spindles and spike-wave discharges) from continuous data. We wanted those segments to be marked relative to the original data file, i.e. the segments shoudl be marked by their begin- and end-sample. Over time, we started using the function for more and more stuff, but there are still some "relicts" in the code that rely on the sample indexing. We are working on improving the function. To keep you posted on the improvements, I have added you and Vladimir to the respective "bugs" in our bugzilla system. Through bugzilla you will receive an email when the issues are resolved so you know when to download an improved version that will work for you. best regards Robert On 24 Feb 2011, at 17:06, Vladimir Litvak wrote: > Hi Holly, > > I'm not sure why the databrowser needs the trl struct or whether we > can add something to our exported FT struct to make it happy. I'm > CCing to the Fieldtrip list to perhaps get some answers. I got exactly > the same complaint from someone else last week. > > > Best, > > Vladimir > > > On Thu, Feb 24, 2011 at 2:48 PM, Holly Rossiter > wrote: >> Hi Vladimir, >> >> >> >> I am trying out using ICA on my data to see what difference it makes to the >> eye blinks and whether it is a step worth doing or not. I am using a >> fieldtrip script... >> >> >> >> D= spm_eeg_load; >> >> data = D.ftraw(0); >> >> cfg = []; >> >> cfg.channel = 'MEG'; >> >> ic_data = ft_componentanalysis(cfg,data); >> >> cfg = []; >> >> cfg.viewmode = 'component'; >> >> cfg.continuous = 'yes'; >> >> cfg.layout = 'CTF275.lay'; >> >> cfg.blocksize = 30; >> >> cfg.channels = [1:10]; >> >> ft_databrowser(cfg,ic_data); >> >> >> >> But it comes up with an error saying >> >> >> >> Error using ==> ft_databrowser at 217 >> >> no trials to display >> >> >> >> I think this may be because I don’t have a trl matrix due to using >> spm_eeg_load. Do you know how I can create one of these using spm format >> data? Or how else to write the script so that ICA will work? >> >> >> >> Kind regards, >> >> >> >> Holly > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip From jan.schoffelen at donders.ru.nl Sat Feb 26 14:26:40 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Sat, 26 Feb 2011 14:26:40 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Dear Jen, I do not manage to reproduce your issue, when only focussing on the ft_volumewrite and visualization part of your pipeline. See attached script, and yet an updated version of ft_volumewrite which you need to (hopefully) draw the same conclusion as I did. Yet, I only now realize that your question may pertain to the entire pipeline. It could be that something is going wrong there. I only see now that in the part of your script of which you reported that it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling ft_volumenormalise. I assume this is correct, because the coordinate system your source-reconstructed data lives in, is according to the CTF-convention, and not according to the SPM- convention. On the other hand, the template for the spatial normalization lives in the SPM-coordinate system. In order for the spatial normalization to work OK, Fieldtrip tries to convert from one coordinate system to the other (once again, this is appropriate behaviour), before doing the actual normalization. It seems that at least in the script you sent along, in the final (not working version), you specified cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is probably wrong. Another important point that should be mentioned, is that the coordinate systems in which the functional data and the anatomical data live should be the same for the ft_sourceinterpolate to make sense. In other words, if your source reconstructed images are defined on a 3D grid of positions in CTF-space, the mri.transform of your anatomy should describe a transformation from voxel to CTF-space. I think you may want to revisit step by step this part of the pipeline; I don't think the problem lies in the writing. A final possibility of course is that Mricron is misbehaving... Best, Jan-Mathijs On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > Hi Jan, > > I tried re-running the analysis with the new script you sent me, and > the latest version of fieldtrip (since I needed ft_get_opt as well), > but the spm8 images being written are still producing flawed > results. It's the same problem as I mentioned briefly in my previous > post. I am not getting any error messages when writing these images. > Rather, my problem is that the spm8 and spm2 results from the same > data ought to be identical when viewed in mricron, but they're far > from it. When I use mricron to look at the results from the spm8- > format images, combined across participants to create a t-image, I > just get a single 'blob' spanning roughly half the brain. In > contrast, when I used spm2-format previously on the same data, the t- > image was much more meaningful; a posterior alpha power decrease in > a set of regions corresponding to the 'task-positive network' (a > network found in the results of an fMRI version of my experiment, > and widely reported in the fMRI literature). > > This failure to replicate the spm2 results when using spm8 images > from the same data leads me to suspect that something is wrong with > the coordinates for spm8 format. However, after experimenting > extensively with different cfg options I still haven't identified > the problem. If I my structural MRIs have been saved to .mri files > using CTF's MRIConverter program, which cfg options, particularly > for coordinates, template images, and filetypes, should I specify > before calling the ft_volumesegment, ft_prepare_singleshell, > ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite > functions? Or should I be calling a different set of functions now? > > Thanks again for your help, > > Jen > > On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman > wrote: > Great, thanks! > > I'll start the analysis with your new script today and will let you > know how it works out. > > Jen > > On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I managed to reproduce your problem. The code was rather buggy and > indeed ft_volumewrite did not behave as it should have. I now fixed > it in the code and it should run fine now. Please find the updated > file attached. It will be available on our ftp-server as of tonight. > Please note that I updated the documentation, and changed the names > of some of the options a bit. If you want to save your data in > analyze-format, you should specify cfg.filetype = 'analyze_spm'. If > you specify cfg.filetype = 'nifti', it should write out a volume to > nifti-format, using SPM8. > > Best wishes, > > Jan-Mathijs > > > > > > On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: > >> >> Dear Jan, >> >> Thanks for the quick reply. Yes, I have tried it out quite a few >> times now, experimenting with different settings in the cfgs. Below >> I'll paste the code I've been using to write images - first the >> code that successfully created spm2 images that produced good >> results, then the code used for creating nifti format images from >> the same data. The comments in this second part are at this point a >> bit of a maze of cfg options I've been changing back & forth. Any >> insights/suggestions regarding how to set up my cfgs to make this >> work would be greatly appreciated. >> >> Jen >> >> >> %%%%%%%% this code generated spm2-compatible images which did work >> (producing results that made sense). >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - >> sourcePre.avg.pow) ./ sourcePre.avg.pow; >> >> cfg = []; >> cfg.downsample = 2; >> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >> >> % projecting the plot onto a surface... >> cfg = []; >> cfg.coordinates = 'ctf'; >> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; >> %this template is in MNI coordinates >> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >> int2str(f) 'HzWin' int2str(win) 'width750ms']; >> cfg=[]; >> cfg.parameter = 'avg.pow'; % string, describing the >> functional data to be processed, e.g. 'pow', 'coh' or 'nai' >> cfg.filename = [filename '.img']; >> %'testimageoutput_alphafreq'; % filename without the extension >> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for >> interactive (default = []) >> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >> 'int16', 'int32', 'float' or 'double' >> >> volumewrite(cfg, sourcetempIntN) >> >> >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> %%%%% this code below hasn't worked yet... >> >> % I added cfg.spmversion = 'spm8'; >> % in the cfgs for the calls to ft_prepare_leadfield and >> ft_sourceanalysis, >> % and in the call to prepare_singleshell after calling volumesegment >> >> % I've also ensured that spm8 is the only spm version in my path, >> even in >> % the fieldtrip/external folder, and ensured that spm8 is installed >> properly >> % (files compiled correctly, etc..) >> >> sourcetemp.avg.pow = (sourcetemp.avg.pow - >> sourcePre.avg.pow) ./ sourcePre.avg.pow; >> >> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >> int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >> >> cfg = []; >> % cfg.coordinates = 'spm'; % changed for version 5 >> % cfg.spmversion = 'spm8'; % changed for version 5 >> cfg.downsample = 4; >> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >> >> >> % projecting the plot onto a surface... >> cfg = []; >> %cfg.coordinates = 'spm'; % changed for version 5 >> %cfg.coordinates = 'ctf'; % changed for version 5 >> cfg.coordinates = 'spm'; % changed back to spm for version 9 >> cfg.downsample = 4; >> %cfg.spmversion = 'spm8'; % changed for version 6 (because this >> gets specified in volumewrite) >> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent >> to using spm8/templates/EPI.nii, except that mask.nii (produced >> from fmri data) has the desired voxel size >> % cfg.name = [filename]; % changed for version 6 >> %cfg.write= 'yes'; % changed for version 6 (when this was set >> to 'yes' there was no subsequent call to volumewrite) >> cfg.write= 'no'; % changed for version 6 >> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >> >> % this whole cfg and function call added for version 6 >> cfg=[]; >> % cfg.parameter = string, describing the functional data >> to be processed, e.g. 'pow', 'coh' or 'nai' >> % cfg.filename = filename without the extension >> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format >> to use >> % cfg.coordinates = 'spm, 'ctf' or empty for interactive >> (default = []) >> cfg.parameter='pow'; >> cfg.filename=filename; >> cfg.filetype = 'spm'; >> cfg.spmversion = 'SPM8'; % capitalized after first error >> message from vers 6 >> % cfg.dataformat='nifti'; % added after first error message from >> vers 6 >> % commented out after 2nd error >> message from vers 6 >> %cfg.vmpversion=2; % this is a filetype, like spm, so don't >> need to specify unless cfg.filetyp='vmp' >> cfg.coordinates='spm'; >> ft_volumewrite(cfg,sourcetempIntN); >> >> >> >> >> >> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen > > wrote: >> Dear Jen, >> >> I notice that indeed in the documentation section of >> ft_write_volume there is a FIXME behind nifti. Yet, nifti format >> seems to be supported by ft_write_volume (at least in a recent >> version of fieldtrip). Did you try it at all (and ran into >> problems) or were you held back by the FIXME statement? Could you >> just try it out using a recent fieldtrip function? >> >> Thanks and best wishes >> >> Jan-Mathijs >> >> >> >> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >> >> Hello, >> >> While writing beamformed images to spm2 format in a previous >> version of fieldtrip (now lost due to a computer crash), I was able >> to get nice-looking results; networks of brain regions consistent >> with existing literature. When I try to write images from the same >> dataset and the same analysis to spm8 format, my results (t-images >> computed across subjects) end up being single clusters spanning >> large sections of the brain (e.g. a 'blob' spanning all of one >> hemisphere but not the other). Unfortunately, some aspects of my >> planned data analyses cannot be performed on spm2 images, so I have >> to find a way of writing to successfully to nifti format. >> >> I just noticed that in the comments in the ft_write_volume >> function, which I am calling via ft_volumewrite, it says 'FIXME' >> next to nifti under the list of supported dataformats. Is there by >> any chance a patch out there for writing nifti images? >> >> Thanks! >> >> _______________________________________________ >> fieldtrip mailing list >> fieldtrip at donders.ru.nl >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_ft_write_volume.m Type: application/octet-stream Size: 1338 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ft_volumewrite.m Type: application/octet-stream Size: 17470 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Mon Feb 28 20:59:28 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Mon, 28 Feb 2011 11:59:28 -0800 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: Hello Jan, When calling volumesegment, I specified 'ctf' as the coordinate system. The function I wrote to call volumesegment and prepare_singleshell for each subject and save the results is pasted below, with a couple of comments added for clarity. Over the weekend I tried specifying the coordinate system in the call to ft_volumenormalise as 'ctf' rather than 'spm', and commented out all the lines that said cfg.spmversion = 'spm8'; before calling a function. However, that created worse results, as each plot involved stripes of activation and empty voxels, suggesting that 'ctf' was not the correct coordinate system to specify. Thanks for the attached script. Looking in that the comments in that, I suspect that the solution to my problems will be to specify my filetype as nifti_img rather than nifti. I'll let you know how that goes. Jen ------------------------------------------------------------------------------------------------------------ % the variable subj is simply a string consisting of a subject number (e.g. 's05') which can be a folder name or part of a filename function [vol mri segmentedmri segmentedmriF]=call_volume_segment_function_spm8(subj) cfg.spmversion = 'spm8'; cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; cfg.name=[subj '_volseg']; cfg.write='yes'; cfg.smooth='no'; cfg.coordinates='ctf'; mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF mriConverter and mriViewer software, after fiducials were marked segmentedmri = volumesegment(cfg, mri); segmentedmriF = segmentedmri; segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3),2),1); segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3),2),1); segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3),2),1); segmentedmriF.transform = mri.transform; segmentedmriF.anatomy = mri.anatomy; cfg = []; cfg.spmversion = 'spm8'; vol = prepare_singleshell(cfg, segmentedmriF); eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri segmentedmriF vol']) On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Dear Jen, > > I do not manage to reproduce your issue, when only focussing on the > ft_volumewrite and visualization part of your pipeline. See attached script, > and yet an updated version of ft_volumewrite which you need to (hopefully) > draw the same conclusion as I did. > Yet, I only now realize that your question may pertain to the entire > pipeline. It could be that something is going wrong there. > I only see now that in the part of your script of which you reported that > it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling > ft_volumenormalise. I assume this is correct, because the coordinate system > your source-reconstructed data lives in, is according to the CTF-convention, > and not according to the SPM-convention. On the other hand, the template for > the spatial normalization lives in the SPM-coordinate system. In order for > the spatial normalization to work OK, Fieldtrip tries to convert from one > coordinate system to the other (once again, this is appropriate behaviour), > before doing the actual normalization. It seems that at least in the script > you sent along, in the final (not working version), you specified > cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is > probably wrong. > Another important point that should be mentioned, is that the coordinate > systems in which the functional data and the anatomical data live should be > the same for the ft_sourceinterpolate to make sense. In other words, if your > source reconstructed images are defined on a 3D grid of positions in > CTF-space, the mri.transform of your anatomy should describe a > transformation from voxel to CTF-space. > I think you may want to revisit step by step this part of the pipeline; I > don't think the problem lies in the writing. > A final possibility of course is that Mricron is misbehaving... > > Best, > > Jan-Mathijs > > > > > > > On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > > Hi Jan, > > I tried re-running the analysis with the new script you sent me, and the > latest version of fieldtrip (since I needed ft_get_opt as well), but the > spm8 images being written are still producing flawed results. It's the same > problem as I mentioned briefly in my previous post. I am not getting any > error messages when writing these images. Rather, my problem is that the > spm8 and spm2 results from the same data ought to be identical when viewed > in mricron, but they're far from it. When I use mricron to look at the > results from the spm8-format images, combined across participants to create > a t-image, I just get a single 'blob' spanning roughly half the brain. In > contrast, when I used spm2-format previously on the same data, the t-image > was much more meaningful; a posterior alpha power decrease in a set of > regions corresponding to the 'task-positive network' (a network found in the > results of an fMRI version of my experiment, and widely reported in the fMRI > literature). > > This failure to replicate the spm2 results when using spm8 images from the > same data leads me to suspect that something is wrong with the coordinates > for spm8 format. However, after experimenting extensively with different cfg > options I still haven't identified the problem. If I my structural MRIs have > been saved to .mri files using CTF's MRIConverter program, which cfg > options, particularly for coordinates, template images, and filetypes, > should I specify before calling the ft_volumesegment, > ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and > ft_volumewrite functions? Or should I be calling a different set of > functions now? > > Thanks again for your help, > > Jen > > On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: > >> Great, thanks! >> >> I'll start the analysis with your new script today and will let you know >> how it works out. >> >> Jen >> >> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < >> jan.schoffelen at donders.ru.nl> wrote: >> >>> Dear Jen, >>> >>> I managed to reproduce your problem. The code was rather buggy and indeed >>> ft_volumewrite did not behave as it should have. I now fixed it in the code >>> and it should run fine now. Please find the updated file attached. It will >>> be available on our ftp-server as of tonight. Please note that I updated the >>> documentation, and changed the names of some of the options a bit. If you >>> want to save your data in analyze-format, you should specify cfg.filetype = >>> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should write out a >>> volume to nifti-format, using SPM8. >>> >>> Best wishes, >>> >>> Jan-Mathijs >>> >>> >>> >>> >>> >>> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >>> >>> >>> Dear Jan, >>> >>> Thanks for the quick reply. Yes, I have tried it out quite a few times >>> now, experimenting with different settings in the cfgs. Below I'll paste the >>> code I've been using to write images - first the code that successfully >>> created spm2 images that produced good results, then the code used for >>> creating nifti format images from the same data. The comments in this second >>> part are at this point a bit of a maze of cfg options I've been changing >>> back & forth. Any insights/suggestions regarding how to set up my cfgs to >>> make this work would be greatly appreciated. >>> >>> Jen >>> >>> >>> %%%%%%%% this code generated spm2-compatible images which did work >>> (producing results that made sense). >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>> sourcePre.avg.pow; >>> >>> cfg = []; >>> cfg.downsample = 2; >>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> cfg.coordinates = 'ctf'; >>> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; %this >>> template is in MNI coordinates >>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>> 'HzWin' int2str(win) 'width750ms']; >>> cfg=[]; >>> cfg.parameter = 'avg.pow'; % string, describing the functional >>> data to be processed, e.g. 'pow', 'coh' or 'nai' >>> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; >>> % filename without the extension >>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >>> (default = []) >>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >>> 'int16', 'int32', 'float' or 'double' >>> >>> volumewrite(cfg, sourcetempIntN) >>> >>> >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%% this code below hasn't worked yet... >>> >>> % I added cfg.spmversion = 'spm8'; >>> % in the cfgs for the calls to ft_prepare_leadfield and >>> ft_sourceanalysis, >>> % and in the call to prepare_singleshell after calling volumesegment >>> >>> % I've also ensured that spm8 is the only spm version in my path, even in >>> % the fieldtrip/external folder, and ensured that spm8 is installed >>> properly >>> % (files compiled correctly, etc..) >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>> sourcePre.avg.pow; >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>> >>> cfg = []; >>> % cfg.coordinates = 'spm'; % changed for version 5 >>> % cfg.spmversion = 'spm8'; % changed for version 5 >>> cfg.downsample = 4; >>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>> >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> %cfg.coordinates = 'spm'; % changed for version 5 >>> %cfg.coordinates = 'ctf'; % changed for version 5 >>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>> cfg.downsample = 4; >>> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >>> specified in volumewrite) >>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to >>> using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) >>> has the desired voxel size >>> % cfg.name = [filename]; % changed for version 6 >>> %cfg.write= 'yes'; % changed for version 6 (when this was set to >>> 'yes' there was no subsequent call to volumewrite) >>> cfg.write= 'no'; % changed for version 6 >>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>> >>> % this whole cfg and function call added for version 6 >>> cfg=[]; >>> % cfg.parameter = string, describing the functional data to be >>> processed, e.g. 'pow', 'coh' or 'nai' >>> % cfg.filename = filename without the extension >>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to use >>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >>> []) >>> cfg.parameter='pow'; >>> cfg.filename=filename; >>> cfg.filetype = 'spm'; >>> cfg.spmversion = 'SPM8'; % capitalized after first error message from >>> vers 6 >>> % cfg.dataformat='nifti'; % added after first error message from vers >>> 6 >>> % commented out after 2nd error message >>> from vers 6 >>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >>> specify unless cfg.filetyp='vmp' >>> cfg.coordinates='spm'; >>> ft_volumewrite(cfg,sourcetempIntN); >>> >>> >>> >>> >>> >>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >>> jan.schoffelen at donders.ru.nl> wrote: >>> >>>> Dear Jen, >>>> >>>> I notice that indeed in the documentation section of ft_write_volume >>>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>>> at all (and ran into problems) or were you held back by the FIXME statement? >>>> Could you just try it out using a recent fieldtrip function? >>>> >>>> Thanks and best wishes >>>> >>>> Jan-Mathijs >>>> >>>> >>>> >>>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>>> >>>> Hello, >>>>> >>>>> While writing beamformed images to spm2 format in a previous version of >>>>> fieldtrip (now lost due to a computer crash), I was able to get nice-looking >>>>> results; networks of brain regions consistent with existing literature. When >>>>> I try to write images from the same dataset and the same analysis to spm8 >>>>> format, my results (t-images computed across subjects) end up being single >>>>> clusters spanning large sections of the brain (e.g. a 'blob' spanning all of >>>>> one hemisphere but not the other). Unfortunately, some aspects of my planned >>>>> data analyses cannot be performed on spm2 images, so I have to find a way of >>>>> writing to successfully to nifti format. >>>>> >>>>> I just noticed that in the comments in the ft_write_volume function, >>>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>>> the list of supported dataformats. Is there by any chance a patch out there >>>>> for writing nifti images? >>>>> >>>>> Thanks! >>>>> >>>>> _______________________________________________ >>>>> fieldtrip mailing list >>>>> fieldtrip at donders.ru.nl >>>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>> >>>> >>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>> Donders Institute for Brain, Cognition and Behaviour, >>>> Centre for Cognitive Neuroimaging, >>>> Radboud University Nijmegen, The Netherlands >>>> J.Schoffelen at donders.ru.nl >>>> Telephone: 0031-24-3614793 >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> >>> _______________________________________________ >>> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Mon Feb 28 21:36:17 2011 From: jan.schoffelen at donders.ru.nl (jan-mathijs schoffelen) Date: Mon, 28 Feb 2011 21:36:17 +0100 Subject: [FieldTrip] difficulty with nifti format and ft_write_volume In-Reply-To: References: <1F0F0930-4606-4EE0-B2D6-3D379B2DC9B4@donders.ru.nl> <676C9A29-2C90-4E02-9B3E-865BCDC5E28F@donders.ru.nl> Message-ID: <7F6275BA-C597-4E11-958C-9E944F27F6C4@donders.ru.nl> Hi Jen, At first glance I have a comment on your script. You may need to explicitly check the alignment of your segmented volume and the original anatomy. A while a go some changes were made to ft_volumesegment, taking away the need to do the flipdim(flipdim... operations. I have posted this on the discussion list last January, but you may not have noticed. Anyway, if you now have used a recent version of FieldTrip for your segmentation both the location of your dipole grid, and the volume conductor model will not be adequately coregistered with the data, which may lead to funky results to begin with. That's most likely not related to the filetype in which the volumes are saved for later use. Best wishes, Jan-Mathijs On Feb 28, 2011, at 8:59 PM, Jen Whitman wrote: > Hello Jan, > > When calling volumesegment, I specified 'ctf' as the coordinate > system. The function I wrote to call volumesegment and > prepare_singleshell for each subject and save the results is pasted > below, with a couple of comments added for clarity. > Over the weekend I tried specifying the coordinate system in the > call to ft_volumenormalise as 'ctf' rather than 'spm', and commented > out all the lines that said cfg.spmversion = 'spm8'; before calling > a function. However, that created worse results, as each plot > involved stripes of activation and empty voxels, suggesting that > 'ctf' was not the correct coordinate system to specify. > > Thanks for the attached script. Looking in that the comments in > that, I suspect that the solution to my problems will be to specify > my filetype as nifti_img rather than nifti. I'll let you know how > that goes. > > Jen > > ------------------------------------------------------------------------------------------------------------ > % the variable subj is simply a string consisting of a subject > number (e.g. 's05') which can be a folder name or part of a filename > function [vol mri segmentedmri > segmentedmriF]=call_volume_segment_function_spm8(subj) > cfg.spmversion = 'spm8'; > cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; > %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; > cfg.name=[subj '_volseg']; > cfg.write='yes'; > cfg.smooth='no'; > cfg.coordinates='ctf'; > mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF > mriConverter and mriViewer software, after fiducials were marked > segmentedmri = volumesegment(cfg, mri); > segmentedmriF = segmentedmri; > segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3), > 2),1); > segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3), > 2),1); > segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3), > 2),1); > segmentedmriF.transform = mri.transform; > segmentedmriF.anatomy = mri.anatomy; > cfg = []; > cfg.spmversion = 'spm8'; > vol = prepare_singleshell(cfg, segmentedmriF); > eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri > segmentedmriF vol']) > > > > On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen > wrote: > Dear Jen, > > I do not manage to reproduce your issue, when only focussing on the > ft_volumewrite and visualization part of your pipeline. See attached > script, and yet an updated version of ft_volumewrite which you need > to (hopefully) draw the same conclusion as I did. > Yet, I only now realize that your question may pertain to the entire > pipeline. It could be that something is going wrong there. > I only see now that in the part of your script of which you reported > that it gave 'good' results, you specify cfg.coordinates = 'ctf' > before calling ft_volumenormalise. I assume this is correct, because > the coordinate system your source-reconstructed data lives in, is > according to the CTF-convention, and not according to the SPM- > convention. On the other hand, the template for the spatial > normalization lives in the SPM-coordinate system. In order for the > spatial normalization to work OK, Fieldtrip tries to convert from > one coordinate system to the other (once again, this is appropriate > behaviour), before doing the actual normalization. It seems that at > least in the script you sent along, in the final (not working > version), you specified cfg.coordinates = 'spm' prior to calling > ft_volumenormalise. This is probably wrong. > Another important point that should be mentioned, is that the > coordinate systems in which the functional data and the anatomical > data live should be the same for the ft_sourceinterpolate to make > sense. In other words, if your source reconstructed images are > defined on a 3D grid of positions in CTF-space, the mri.transform of > your anatomy should describe a transformation from voxel to CTF-space. > I think you may want to revisit step by step this part of the > pipeline; I don't think the problem lies in the writing. > A final possibility of course is that Mricron is misbehaving... > > Best, > > Jan-Mathijs > > > > > > > On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: > >> Hi Jan, >> >> I tried re-running the analysis with the new script you sent me, >> and the latest version of fieldtrip (since I needed ft_get_opt as >> well), but the spm8 images being written are still producing flawed >> results. It's the same problem as I mentioned briefly in my >> previous post. I am not getting any error messages when writing >> these images. Rather, my problem is that the spm8 and spm2 results >> from the same data ought to be identical when viewed in mricron, >> but they're far from it. When I use mricron to look at the results >> from the spm8-format images, combined across participants to create >> a t-image, I just get a single 'blob' spanning roughly half the >> brain. In contrast, when I used spm2-format previously on the same >> data, the t-image was much more meaningful; a posterior alpha power >> decrease in a set of regions corresponding to the 'task-positive >> network' (a network found in the results of an fMRI version of my >> experiment, and widely reported in the fMRI literature). >> >> This failure to replicate the spm2 results when using spm8 images >> from the same data leads me to suspect that something is wrong with >> the coordinates for spm8 format. However, after experimenting >> extensively with different cfg options I still haven't identified >> the problem. If I my structural MRIs have been saved to .mri files >> using CTF's MRIConverter program, which cfg options, particularly >> for coordinates, template images, and filetypes, should I specify >> before calling the ft_volumesegment, ft_prepare_singleshell, >> ft_sourceinterpolate, ft_volumenormalise, and ft_volumewrite >> functions? Or should I be calling a different set of functions now? >> >> Thanks again for your help, >> >> Jen >> >> On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman >> wrote: >> Great, thanks! >> >> I'll start the analysis with your new script today and will let you >> know how it works out. >> >> Jen >> >> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen > > wrote: >> Dear Jen, >> >> I managed to reproduce your problem. The code was rather buggy and >> indeed ft_volumewrite did not behave as it should have. I now fixed >> it in the code and it should run fine now. Please find the updated >> file attached. It will be available on our ftp-server as of >> tonight. Please note that I updated the documentation, and changed >> the names of some of the options a bit. If you want to save your >> data in analyze-format, you should specify cfg.filetype = >> 'analyze_spm'. If you specify cfg.filetype = 'nifti', it should >> write out a volume to nifti-format, using SPM8. >> >> Best wishes, >> >> Jan-Mathijs >> >> >> >> >> >> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >> >>> >>> Dear Jan, >>> >>> Thanks for the quick reply. Yes, I have tried it out quite a few >>> times now, experimenting with different settings in the cfgs. >>> Below I'll paste the code I've been using to write images - first >>> the code that successfully created spm2 images that produced good >>> results, then the code used for creating nifti format images from >>> the same data. The comments in this second part are at this point >>> a bit of a maze of cfg options I've been changing back & forth. >>> Any insights/suggestions regarding how to set up my cfgs to make >>> this work would be greatly appreciated. >>> >>> Jen >>> >>> >>> %%%%%%%% this code generated spm2-compatible images which did work >>> (producing results that made sense). >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - >>> sourcePre.avg.pow) ./ sourcePre.avg.pow; >>> >>> cfg = []; >>> cfg.downsample = 2; >>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> cfg.coordinates = 'ctf'; >>> cfg.template = '/home/common/matlab/spm2/templates/ >>> T1.mnc'; %this template is in MNI coordinates >>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >>> int2str(f) 'HzWin' int2str(win) 'width750ms']; >>> cfg=[]; >>> cfg.parameter = 'avg.pow'; % string, describing the >>> functional data to be processed, e.g. 'pow', 'coh' or 'nai' >>> cfg.filename = [filename '.img']; >>> %'testimageoutput_alphafreq'; % filename without the extension >>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for >>> interactive (default = []) >>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', >>> 'uint8', 'int16', 'int32', 'float' or 'double' >>> >>> volumewrite(cfg, sourcetempIntN) >>> >>> >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> %%%%% this code below hasn't worked yet... >>> >>> % I added cfg.spmversion = 'spm8'; >>> % in the cfgs for the calls to ft_prepare_leadfield and >>> ft_sourceanalysis, >>> % and in the call to prepare_singleshell after calling volumesegment >>> >>> % I've also ensured that spm8 is the only spm version in my path, >>> even in >>> % the fieldtrip/external folder, and ensured that spm8 is >>> installed properly >>> % (files compiled correctly, etc..) >>> >>> sourcetemp.avg.pow = (sourcetemp.avg.pow - >>> sourcePre.avg.pow) ./ sourcePre.avg.pow; >>> >>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' >>> int2str(f) 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>> >>> cfg = []; >>> % cfg.coordinates = 'spm'; % changed for version 5 >>> % cfg.spmversion = 'spm8'; % changed for version 5 >>> cfg.downsample = 4; >>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>> >>> >>> % projecting the plot onto a surface... >>> cfg = []; >>> %cfg.coordinates = 'spm'; % changed for version 5 >>> %cfg.coordinates = 'ctf'; % changed for version 5 >>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>> cfg.downsample = 4; >>> %cfg.spmversion = 'spm8'; % changed for version 6 (because >>> this gets specified in volumewrite) >>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent >>> to using spm8/templates/EPI.nii, except that mask.nii (produced >>> from fmri data) has the desired voxel size >>> % cfg.name = [filename]; % changed for version 6 >>> %cfg.write= 'yes'; % changed for version 6 (when this was set >>> to 'yes' there was no subsequent call to volumewrite) >>> cfg.write= 'no'; % changed for version 6 >>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>> >>> % this whole cfg and function call added for version 6 >>> cfg=[]; >>> % cfg.parameter = string, describing the functional data >>> to be processed, e.g. 'pow', 'coh' or 'nai' >>> % cfg.filename = filename without the extension >>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format >>> to use >>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive >>> (default = []) >>> cfg.parameter='pow'; >>> cfg.filename=filename; >>> cfg.filetype = 'spm'; >>> cfg.spmversion = 'SPM8'; % capitalized after first error >>> message from vers 6 >>> % cfg.dataformat='nifti'; % added after first error message >>> from vers 6 >>> % commented out after 2nd error >>> message from vers 6 >>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't >>> need to specify unless cfg.filetyp='vmp' >>> cfg.coordinates='spm'; >>> ft_volumewrite(cfg,sourcetempIntN); >>> >>> >>> >>> >>> >>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen >> > wrote: >>> Dear Jen, >>> >>> I notice that indeed in the documentation section of >>> ft_write_volume there is a FIXME behind nifti. Yet, nifti format >>> seems to be supported by ft_write_volume (at least in a recent >>> version of fieldtrip). Did you try it at all (and ran into >>> problems) or were you held back by the FIXME statement? Could you >>> just try it out using a recent fieldtrip function? >>> >>> Thanks and best wishes >>> >>> Jan-Mathijs >>> >>> >>> >>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>> >>> Hello, >>> >>> While writing beamformed images to spm2 format in a previous >>> version of fieldtrip (now lost due to a computer crash), I was >>> able to get nice-looking results; networks of brain regions >>> consistent with existing literature. When I try to write images >>> from the same dataset and the same analysis to spm8 format, my >>> results (t-images computed across subjects) end up being single >>> clusters spanning large sections of the brain (e.g. a 'blob' >>> spanning all of one hemisphere but not the other). Unfortunately, >>> some aspects of my planned data analyses cannot be performed on >>> spm2 images, so I have to find a way of writing to successfully to >>> nifti format. >>> >>> I just noticed that in the comments in the ft_write_volume >>> function, which I am calling via ft_volumewrite, it says 'FIXME' >>> next to nifti under the list of supported dataformats. Is there by >>> any chance a patch out there for writing nifti images? >>> >>> Thanks! >>> >>> _______________________________________________ >>> fieldtrip mailing list >>> fieldtrip at donders.ru.nl >>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>> >>> Dr. J.M. (Jan-Mathijs) Schoffelen >>> Donders Institute for Brain, Cognition and Behaviour, >>> Centre for Cognitive Neuroimaging, >>> Radboud University Nijmegen, The Netherlands >>> J.Schoffelen at donders.ru.nl >>> Telephone: 0031-24-3614793 >>> >>> _______________________________________________ >>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > 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 Dr. J.M. (Jan-Mathijs) Schoffelen Donders Institute for Brain, Cognition and Behaviour, Centre for Cognitive Neuroimaging, Radboud University Nijmegen, The Netherlands J.Schoffelen at donders.ru.nl Telephone: 0031-24-3614793 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenwhitman at gmail.com Mon Feb 28 22:32:16 2011 From: jenwhitman at gmail.com (Jen Whitman) Date: Mon, 28 Feb 2011 13:32:16 -0800 Subject: [FieldTrip] I think you solved the problem Message-ID: I just checked, and when I re-ran my segmentation script with the new Fieldtrip in order to use an spm8 template image, coordinates got reversed. When I take out the calls to flipdim, they look fine (see attached screenshots). That certainly explains the meaningless results I was getting! Thanks for figuring that out, Jen On Mon, Feb 28, 2011 at 12:36 PM, jan-mathijs schoffelen < jan.schoffelen at donders.ru.nl> wrote: > Hi Jen, > > At first glance I have a comment on your script. You may need to explicitly > check the alignment of your segmented volume and the original anatomy. A > while a go some changes were made to ft_volumesegment, taking away the need > to do the flipdim(flipdim... operations. I have posted this on the > discussion list last January, but you may not have noticed. > Anyway, if you now have used a recent version of FieldTrip for your > segmentation both the location of your dipole grid, and the volume conductor > model will not be adequately coregistered with the data, which may lead to > funky results to begin with. That's most likely not related to the filetype > in which the volumes are saved for later use. > > Best wishes, > > Jan-Mathijs > > > > On Feb 28, 2011, at 8:59 PM, Jen Whitman wrote: > > Hello Jan, > > When calling volumesegment, I specified 'ctf' as the coordinate system. The > function I wrote to call volumesegment and prepare_singleshell for each > subject and save the results is pasted below, with a couple of comments > added for clarity. > Over the weekend I tried specifying the coordinate system in the call to > ft_volumenormalise as 'ctf' rather than 'spm', and commented out all the > lines that said cfg.spmversion = 'spm8'; before calling a function. However, > that created worse results, as each plot involved stripes of activation and > empty voxels, suggesting that 'ctf' was not the correct coordinate system to > specify. > > Thanks for the attached script. Looking in that the comments in that, I > suspect that the solution to my problems will be to specify my filetype as > nifti_img rather than nifti. I'll let you know how that goes. > > Jen > > > ------------------------------------------------------------------------------------------------------------ > % the variable subj is simply a string consisting of a subject number (e.g. > 's05') which can be a folder name or part of a filename > function [vol mri segmentedmri > segmentedmriF]=call_volume_segment_function_spm8(subj) > cfg.spmversion = 'spm8'; > cfg.template = '/home/woodwardlab/spm8/templates/EPI.nii'; > %cfg.template='/home/common/matlab/spm2/templates/T1.mnc'; > cfg.name=[subj '_volseg']; > cfg.write='yes'; > cfg.smooth='no'; > cfg.coordinates='ctf'; > mri=read_mri([subj '/mri/' subj 'head.mri']); % made with CTF mriConverter > and mriViewer software, after fiducials were marked > segmentedmri = volumesegment(cfg, mri); > segmentedmriF = segmentedmri; > segmentedmriF.gray = flipdim(flipdim(flipdim(segmentedmriF.gray,3),2),1); > segmentedmriF.white = flipdim(flipdim(flipdim(segmentedmriF.white,3),2),1); > segmentedmriF.csf = flipdim(flipdim(flipdim(segmentedmriF.csf,3),2),1); > segmentedmriF.transform = mri.transform; > segmentedmriF.anatomy = mri.anatomy; > cfg = []; > cfg.spmversion = 'spm8'; > vol = prepare_singleshell(cfg, segmentedmriF); > eval(['save ' subj '/meg/mrisegmented.mat mri segmentedmri segmentedmriF > vol']) > > > > On Sat, Feb 26, 2011 at 5:26 AM, jan-mathijs schoffelen < > jan.schoffelen at donders.ru.nl> wrote: > >> Dear Jen, >> >> I do not manage to reproduce your issue, when only focussing on the >> ft_volumewrite and visualization part of your pipeline. See attached script, >> and yet an updated version of ft_volumewrite which you need to (hopefully) >> draw the same conclusion as I did. >> Yet, I only now realize that your question may pertain to the entire >> pipeline. It could be that something is going wrong there. >> I only see now that in the part of your script of which you reported that >> it gave 'good' results, you specify cfg.coordinates = 'ctf' before calling >> ft_volumenormalise. I assume this is correct, because the coordinate system >> your source-reconstructed data lives in, is according to the CTF-convention, >> and not according to the SPM-convention. On the other hand, the template for >> the spatial normalization lives in the SPM-coordinate system. In order for >> the spatial normalization to work OK, Fieldtrip tries to convert from one >> coordinate system to the other (once again, this is appropriate behaviour), >> before doing the actual normalization. It seems that at least in the script >> you sent along, in the final (not working version), you specified >> cfg.coordinates = 'spm' prior to calling ft_volumenormalise. This is >> probably wrong. >> Another important point that should be mentioned, is that the coordinate >> systems in which the functional data and the anatomical data live should be >> the same for the ft_sourceinterpolate to make sense. In other words, if your >> source reconstructed images are defined on a 3D grid of positions in >> CTF-space, the mri.transform of your anatomy should describe a >> transformation from voxel to CTF-space. >> I think you may want to revisit step by step this part of the pipeline; I >> don't think the problem lies in the writing. >> A final possibility of course is that Mricron is misbehaving... >> >> Best, >> >> Jan-Mathijs >> >> >> >> >> >> >> On Feb 25, 2011, at 9:44 PM, Jen Whitman wrote: >> >> Hi Jan, >> >> I tried re-running the analysis with the new script you sent me, and the >> latest version of fieldtrip (since I needed ft_get_opt as well), but the >> spm8 images being written are still producing flawed results. It's the same >> problem as I mentioned briefly in my previous post. I am not getting any >> error messages when writing these images. Rather, my problem is that the >> spm8 and spm2 results from the same data ought to be identical when viewed >> in mricron, but they're far from it. When I use mricron to look at the >> results from the spm8-format images, combined across participants to create >> a t-image, I just get a single 'blob' spanning roughly half the brain. In >> contrast, when I used spm2-format previously on the same data, the t-image >> was much more meaningful; a posterior alpha power decrease in a set of >> regions corresponding to the 'task-positive network' (a network found in the >> results of an fMRI version of my experiment, and widely reported in the fMRI >> literature). >> >> This failure to replicate the spm2 results when using spm8 images from the >> same data leads me to suspect that something is wrong with the coordinates >> for spm8 format. However, after experimenting extensively with different cfg >> options I still haven't identified the problem. If I my structural MRIs have >> been saved to .mri files using CTF's MRIConverter program, which cfg >> options, particularly for coordinates, template images, and filetypes, >> should I specify before calling the ft_volumesegment, >> ft_prepare_singleshell, ft_sourceinterpolate, ft_volumenormalise, and >> ft_volumewrite functions? Or should I be calling a different set of >> functions now? >> >> Thanks again for your help, >> >> Jen >> >> On Thu, Feb 24, 2011 at 10:07 AM, Jen Whitman wrote: >> >>> Great, thanks! >>> >>> I'll start the analysis with your new script today and will let you know >>> how it works out. >>> >>> Jen >>> >>> On Thu, Feb 24, 2011 at 4:44 AM, jan-mathijs schoffelen < >>> jan.schoffelen at donders.ru.nl> wrote: >>> >>>> Dear Jen, >>>> >>>> I managed to reproduce your problem. The code was rather buggy and >>>> indeed ft_volumewrite did not behave as it should have. I now fixed it in >>>> the code and it should run fine now. Please find the updated file attached. >>>> It will be available on our ftp-server as of tonight. Please note that I >>>> updated the documentation, and changed the names of some of the options a >>>> bit. If you want to save your data in analyze-format, you should specify >>>> cfg.filetype = 'analyze_spm'. If you specify cfg.filetype = 'nifti', it >>>> should write out a volume to nifti-format, using SPM8. >>>> >>>> Best wishes, >>>> >>>> Jan-Mathijs >>>> >>>> >>>> >>>> >>>> >>>> On Feb 23, 2011, at 7:44 PM, Jen Whitman wrote: >>>> >>>> >>>> Dear Jan, >>>> >>>> Thanks for the quick reply. Yes, I have tried it out quite a few times >>>> now, experimenting with different settings in the cfgs. Below I'll paste the >>>> code I've been using to write images - first the code that successfully >>>> created spm2 images that produced good results, then the code used for >>>> creating nifti format images from the same data. The comments in this second >>>> part are at this point a bit of a maze of cfg options I've been changing >>>> back & forth. Any insights/suggestions regarding how to set up my cfgs to >>>> make this work would be greatly appreciated. >>>> >>>> Jen >>>> >>>> >>>> %%%%%%%% this code generated spm2-compatible images which did work >>>> (producing results that made sense). >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>>> sourcePre.avg.pow; >>>> >>>> cfg = []; >>>> cfg.downsample = 2; >>>> sourcetempInt = sourceinterpolate(cfg, sourcetemp , mri); >>>> >>>> % projecting the plot onto a surface... >>>> cfg = []; >>>> cfg.coordinates = 'ctf'; >>>> cfg.template = '/home/common/matlab/spm2/templates/T1.mnc'; >>>> %this template is in MNI coordinates >>>> sourcetempIntN = volumenormalise(cfg, sourcetempInt); >>>> >>>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>>> 'HzWin' int2str(win) 'width750ms']; >>>> cfg=[]; >>>> cfg.parameter = 'avg.pow'; % string, describing the functional >>>> data to be processed, e.g. 'pow', 'coh' or 'nai' >>>> cfg.filename = [filename '.img']; %'testimageoutput_alphafreq'; >>>> % filename without the extension >>>> cfg.filetype = 'spm'; %'analyze', 'spm', 'vmp' or 'vmr' >>>> cfg.coordinates = 'spm'; %'spm, 'ctf' or empty for interactive >>>> (default = []) >>>> cfg.datatype = 'double'; %'float'; %'double'; %'bit1', 'uint8', >>>> 'int16', 'int32', 'float' or 'double' >>>> >>>> volumewrite(cfg, sourcetempIntN) >>>> >>>> >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> >>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>>> %%%%% this code below hasn't worked yet... >>>> >>>> % I added cfg.spmversion = 'spm8'; >>>> % in the cfgs for the calls to ft_prepare_leadfield and >>>> ft_sourceanalysis, >>>> % and in the call to prepare_singleshell after calling volumesegment >>>> >>>> % I've also ensured that spm8 is the only spm version in my path, even >>>> in >>>> % the fieldtrip/external folder, and ensured that spm8 is installed >>>> properly >>>> % (files compiled correctly, etc..) >>>> >>>> sourcetemp.avg.pow = (sourcetemp.avg.pow - sourcePre.avg.pow) ./ >>>> sourcePre.avg.pow; >>>> >>>> filename=[subj 'run' int2str(r) 'cond' int2str(cond) '_' int2str(f) >>>> 'Hzspm8_FIXv9_Win' int2str(win) 'width750ms.img']; >>>> >>>> cfg = []; >>>> % cfg.coordinates = 'spm'; % changed for version 5 >>>> % cfg.spmversion = 'spm8'; % changed for version 5 >>>> cfg.downsample = 4; >>>> sourcetempInt = ft_sourceinterpolate(cfg, sourcetemp , mri); >>>> >>>> >>>> % projecting the plot onto a surface... >>>> cfg = []; >>>> %cfg.coordinates = 'spm'; % changed for version 5 >>>> %cfg.coordinates = 'ctf'; % changed for version 5 >>>> cfg.coordinates = 'spm'; % changed back to spm for version 9 >>>> cfg.downsample = 4; >>>> %cfg.spmversion = 'spm8'; % changed for version 6 (because this gets >>>> specified in volumewrite) >>>> cfg.template = 'Hmatrix/mask.nii.nii'; % basically equivalent to >>>> using spm8/templates/EPI.nii, except that mask.nii (produced from fmri data) >>>> has the desired voxel size >>>> % cfg.name = [filename]; % changed for version 6 >>>> %cfg.write= 'yes'; % changed for version 6 (when this was set to >>>> 'yes' there was no subsequent call to volumewrite) >>>> cfg.write= 'no'; % changed for version 6 >>>> sourcetempIntN = ft_volumenormalise(cfg, sourcetempInt); >>>> >>>> % this whole cfg and function call added for version 6 >>>> cfg=[]; >>>> % cfg.parameter = string, describing the functional data to be >>>> processed, e.g. 'pow', 'coh' or 'nai' >>>> % cfg.filename = filename without the extension >>>> % cfg.filetype = 'analyze', 'spm', 'vmp' or 'vmr' >>>> % cfg.vmpversion = 1 or 2 (default) version of the vmp-format to >>>> use >>>> % cfg.coordinates = 'spm, 'ctf' or empty for interactive (default = >>>> []) >>>> cfg.parameter='pow'; >>>> cfg.filename=filename; >>>> cfg.filetype = 'spm'; >>>> cfg.spmversion = 'SPM8'; % capitalized after first error message >>>> from vers 6 >>>> % cfg.dataformat='nifti'; % added after first error message from vers >>>> 6 >>>> % commented out after 2nd error message >>>> from vers 6 >>>> %cfg.vmpversion=2; % this is a filetype, like spm, so don't need to >>>> specify unless cfg.filetyp='vmp' >>>> cfg.coordinates='spm'; >>>> ft_volumewrite(cfg,sourcetempIntN); >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Feb 23, 2011 at 7:50 AM, jan-mathijs schoffelen < >>>> jan.schoffelen at donders.ru.nl> wrote: >>>> >>>>> Dear Jen, >>>>> >>>>> I notice that indeed in the documentation section of ft_write_volume >>>>> there is a FIXME behind nifti. Yet, nifti format seems to be supported by >>>>> ft_write_volume (at least in a recent version of fieldtrip). Did you try it >>>>> at all (and ran into problems) or were you held back by the FIXME statement? >>>>> Could you just try it out using a recent fieldtrip function? >>>>> >>>>> Thanks and best wishes >>>>> >>>>> Jan-Mathijs >>>>> >>>>> >>>>> >>>>> On Feb 23, 2011, at 2:21 AM, Jen Whitman wrote: >>>>> >>>>> Hello, >>>>>> >>>>>> While writing beamformed images to spm2 format in a previous version >>>>>> of fieldtrip (now lost due to a computer crash), I was able to get >>>>>> nice-looking results; networks of brain regions consistent with existing >>>>>> literature. When I try to write images from the same dataset and the same >>>>>> analysis to spm8 format, my results (t-images computed across subjects) end >>>>>> up being single clusters spanning large sections of the brain (e.g. a 'blob' >>>>>> spanning all of one hemisphere but not the other). Unfortunately, some >>>>>> aspects of my planned data analyses cannot be performed on spm2 images, so I >>>>>> have to find a way of writing to successfully to nifti format. >>>>>> >>>>>> I just noticed that in the comments in the ft_write_volume function, >>>>>> which I am calling via ft_volumewrite, it says 'FIXME' next to nifti under >>>>>> the list of supported dataformats. Is there by any chance a patch out there >>>>>> for writing nifti images? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> _______________________________________________ >>>>>> fieldtrip mailing list >>>>>> fieldtrip at donders.ru.nl >>>>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip >>>>>> >>>>> >>>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>>> Donders Institute for Brain, Cognition and Behaviour, >>>>> Centre for Cognitive Neuroimaging, >>>>> Radboud University Nijmegen, The Netherlands >>>>> J.Schoffelen at donders.ru.nl >>>>> Telephone: 0031-24-3614793 >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>>> Dr. J.M. (Jan-Mathijs) Schoffelen >>>> Donders Institute for Brain, Cognition and Behaviour, >>>> Centre for Cognitive Neuroimaging, >>>> Radboud University Nijmegen, The Netherlands >>>> J.Schoffelen at donders.ru.nl >>>> Telephone: 0031-24-3614793 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> Dr. J.M. (Jan-Mathijs) Schoffelen >> Donders Institute for Brain, Cognition and Behaviour, >> Centre for Cognitive Neuroimaging, >> Radboud University Nijmegen, The Netherlands >> J.Schoffelen at donders.ru.nl >> Telephone: 0031-24-3614793 >> >> >> _______________________________________________ >> 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 > > > Dr. J.M. (Jan-Mathijs) Schoffelen > Donders Institute for Brain, Cognition and Behaviour, > Centre for Cognitive Neuroimaging, > Radboud University Nijmegen, The Netherlands > J.Schoffelen at donders.ru.nl > Telephone: 0031-24-3614793 > > > _______________________________________________ > fieldtrip mailing list > fieldtrip at donders.ru.nl > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: volumesegmentspm8.png Type: image/png Size: 141551 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fixedvolumesegmentspm8.png Type: image/png Size: 78944 bytes Desc: not available URL: