[FieldTrip] ft_selectdata, ft_freqstatistics problems
"Jörn M. Horschig"
jm.horschig at donders.ru.nl
Tue Mar 26 08:50:47 CET 2013
Dear Harsimrat,
Actually, both cumtapcnt and powspctrm should be subselected. The
problem most likely comes from the fact that your data has 32 labels but
in powspctrm only one channel left (dimord is rpt_chan_freq_time,
dimension of powspctrm is 73 x 1 x 2 x 3, but you have 32 labels).
Whatever you did to your data, you made it inconsistent. A way to solve
this is to make the label fields have the sime size as powspctrm. A
better way would be to find out what made them inconsistent. Not sure
about freq and time here, because you mention that these dimension are
alright for your tf matrix.
That should solve it. ft_selectdata works with all our test data. If
not, let us know or send me a snippet of your data together with some
code to reproduce this error and I can have a more thorough look.
Best,
Jörn
On 3/25/2013 6:35 PM, Harsimrat Singh wrote:
> Hi All
>
> I think I have a problem with ft_selectdata.
>
> Data Background: I have 4 class data but i am just doing
> classification (multivariate analysis) between the first two classes
> with 13 and 20 trials each.
> After the ft_freqanalysis - all the trials are contained in tf - and
> tf.powsctrm is 4D (73*1*3*4) - [trials, channel, freq, time] - Here, I
> have one channel as I removed others.
> When I use
> tf1 = ft_selectdata(tf, 'rpt', data1.trlvec(1:end));
> to get trials for only the first class
> I get
> label: {32x1 cell}
> dimord: 'rpt_chan_freq_time'
> freq: [10.5000 12.5000 14.5000]
> time: [0.3000 0.4000 0.5000 0.6000]
> powspctrm: [4-D double]
> cumtapcnt: [13x3 double]
> cfg: [1x1 struct]
> Now, the size of tf1.powspctrm is (73, 1, 2, 3) which is same as
> tf.powspctrm
> Similarly, for trials of class 2
> tf2 = ft_selectdata(tf, 'rpt', data2.trlvec(1:end));
> Again, the size of tf2 is same as tf1 which is same as tf
> The only difference in the structure is
> tf2.cumtapcnt which is 20 for tf2, 13 for tf1 and 73 for tf.
>
> The first question is-
> How does ft_freqstatistics handle tf1.cumtapcnt, when I use
> stat = ft_freqstatistics(cfg,tf1,tf2)
> Is tf1. cumtapcnt telling the ft_freqstatistics which trials to use of
> tf1?
> This only works if I design the label as
> cfg. design =
> [ones(size(tf1.powspctrm,1),1);2*ones(size(tf2.powspctrm,1),1)]'
> its size is 73*2 =146
>
> Problem:
> My total relevant trials are just 13 (class 1) + 20(class2) = 33 for
> both classes and not 146.
> I suspect I making a mistake somewhere as in ideal case, I should be
> designing cgf.design = [ones(size(tf1.cumtapcnt,1),1);
> 2*ones(size(tf2.cumtapcnt,1),1)]'
> size(cg.design) should be 33
> and tf1.powspctrm should have size [13 1 3 4] and tf2 should have size
> [20 1 3 4]
>
> So after doing ft_selectdata, ft_freqstatistics should be handling 33
> trials - with 13 from first class, 20 from other class.
> But now it has full 146 trials even after doing ft_selectdata.
> I will be very grateful for any help.
>
> Best regards
> Harsimrat
>
> On 21 March 2013 08:34, Eelke Spaak <eelke.spaak at donders.ru.nl
> <mailto:eelke.spaak at donders.ru.nl>> wrote:
>
> Hi Ingrid,
>
> Thanks for your question; it made me realize that my e-mail was not
> clear enough. In your case, when you repaired channels that were still
> present in the data, the output channel order of ft_channelrepair will
> be the same as the input channel order.
>
> The problem only occurs if you use ft_channelrepair to repair
> *missing* channels, so e.g. channels switched off during acquisition
> or that were discarded during preprocessing.
>
> Groeten,
> Eelke
>
> On 20 March 2013 20:55, Ingrid Nieuwenhuis
> <inieuwenhuis at berkeley.edu <mailto:inieuwenhuis at berkeley.edu>> wrote:
> > Hi Eelke,
> >
> > Thanks for reporting. I did do ft_channelrepair on my EEG data
> for some
> > subjects and subsequently used ft_freqstatistics. However, the
> channel order
> > is indentical in all my subjects in the freq.
> >
> > I repaired bad channels using the default setting
> (method='nearest'). The
> > bad channels were included in the input data to ft_channelrepair
> (so they
> > were not missing). I just checked, and in data_out after
> ft_channelrepair,
> > the order of the labels of the data is identical to the data_in,
> thus the
> > repaired channels were NOT appended to the end of the data. So
> apparently
> > ft_channelrepair not always appends the repaired channels at the
> end. I
> > suppose this is good news for me, meaning that the bug did not
> affect me,
> > since the channels were ordered identically when calling
> ft_freqstatistics.
> > Do you agree, or am I missing something? And for others that used
> > ft_channelrepair, might be worth checking if the ordering is
> indeed changed
> > after calling it, because it appears not always to be the case.
> >
> > Thanks,
> > Ingrid
> >
> >
> > On 3/20/2013 2:01 AM, Eelke Spaak wrote:
> >>
> >> Dear FieldTrip community,
> >>
> >> Short version: if you did ft_freqstatistics across subjects with a
> >> different channel ordering across data sets (which is the case
> if you
> >> use ft_channelrepair), your results might have been erroneous. Read
> >> the following carefully.
> >>
> >> Yesterday, we discovered a possibly severe bug in a utility
> function
> >> (ft_selectdata_old) which was used by ft_freqstatistics. The bug
> >> entails that ft_selectdata_old assumes that the channels in all
> data
> >> input arguments are ordered identically, and does not take into
> >> account the order of the data.label field. This means that when
> >> several data input arguments with different channel orderings are
> >> passed to ft_selectdata_old, the resulting output structure (with a
> >> newly added 'rpt' dimension) will contain wrong data (i.e. data for
> >> channel X might end up in another channel Y). Importantly, the same
> >> thus holds for ft_freqstatistics: when doing statistics across
> >> subjects, if the different subjects' data sets have different
> channel
> >> orderings, the resulting statistics will be wrong.
> >>
> >> We expect that in many cases, the channel ordering across different
> >> data sets will be identical, and in those cases this bug will
> not have
> >> had any effect. However, one important case in which channel
> ordering
> >> *will* be different is when one does ft_channelrepair on a data
> set,
> >> since this function appends the repaired channels to the end of the
> >> data. So, if you have done ft_channelrepair on only a subset of
> your
> >> subjects' data, and/or used ft_channelrepair to repair different
> >> channels in different subjects, and subsequently passed the
> repaired
> >> data sets to ft_freqstatistics, there is a good chance the
> results you
> >> got were wrong.
> >>
> >> Most likely, this bug was introduced with revision 4101, in
> september
> >> 2011, so it has been in the code for quite a while. Note that
> >> ft_channelrepair only supports repairing missing channels since
> >> revision 5216 (february 2012), and that this was advised
> against until
> >> revision 6100 (june 2012), when the algorithm for doing so sensibly
> >> was implemented.
> >>
> >> The fix has been implemented and is now available from the FTP
> server
> >> as of fieldtrip-20130319 (Donders users: the fix is automatically
> >> available on the /home/common/ version of FieldTrip). Note that
> >> ft_selectdata_old still does not work correctly, this is
> something we
> >> will fix in the near future (ft_selectdata_old is deprecated). We
> >> fixed the behaviour of ft_appendfreq (the preferred replacement
> >> function for ft_selectdata_old when appending freq structures) and
> >> changed ft_freqstatistics to use this function instead.
> >>
> >> The other statistics functions, ft_timelockstatistics and
> >> ft_sourcestatistics, were not affected by this bug. We strongly
> advise
> >> you to upgrade to the latest version of FieldTrip. If the situation
> >> described above applies to you, you will need to redo your
> >> channel-level (time-)frequency statistics analyses.
> >>
> >> Details on the bug (and a test script) can be found here:
> >> http://bugzilla.fcdonders.nl/show_bug.cgi?id=2069 If you find any
> >> problems related to the bug, please post them there.
> >>
> >> We sincerely apologise for this bug and any trouble it might
> have caused.
> >>
> >> Best,
> >> On behalf of the FT core development team,
> >>
> >> Eelke
> >> _______________________________________________
> >> fieldtrip mailing list
> >> fieldtrip at donders.ru.nl <mailto:fieldtrip at donders.ru.nl>
> >> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> >
> >
> > --
> > Ingrid Nieuwenhuis PhD
> > Postdoctoral Fellow
> > Sleep and Neuroimaging Laboratory
> > Department of Psychology
> > University of California, Berkeley
> > California 94720-1650
> > Tolman Hall, room 5305
> >
> >
> > _______________________________________________
> > fieldtrip mailing list
> > fieldtrip at donders.ru.nl <mailto:fieldtrip at donders.ru.nl>
> > http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
> _______________________________________________
> fieldtrip mailing list
> fieldtrip at donders.ru.nl <mailto:fieldtrip at donders.ru.nl>
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>
>
>
>
>
> _______________________________________________
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
--
Jörn M. Horschig
PhD Student
Donders Institute for Brain, Cognition and Behaviour
Centre for Cognitive Neuroimaging
Radboud University Nijmegen
Neuronal Oscillations Group
FieldTrip Development Team
P.O. Box 9101
NL-6500 HB Nijmegen
The Netherlands
Contact:
E-Mail: jm.horschig at donders.ru.nl
Tel: +31-(0)24-36-68493
Web: http://www.ru.nl/donders
Visiting address:
Trigon, room 2.30
Kapittelweg 29
NL-6525 EN Nijmegen
The Netherlands
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20130326/daf84c12/attachment-0001.html>
More information about the fieldtrip
mailing list