[Eeglablist] re-epoching; losing a trial

[Andreas Widmann]

Hi Yvonne,

> Thank you Andreas, the problem indeed seems to be that the epoch has to include t=0 (so it had nothing to do with the re-epoching I did). Epoching at [1 25] the first time around actually results in an empty event table, rather than the shifted one, so the shifting is something weird that happens on top of the other problem when epoching the second time. 
Indeed the issue is not related to re-epoching but epoching in general.

> Your workaround seems to solve my problem, but I find it hard to believe that excluding the first bit of an epoch is unintended usage of the function.
The point is actually a different one. It is not related that it is the first bit of an epoch but how events are processed and stored during epoching in EEGLAB.

Epochs are usually defined relative to the occurrence of an event. Events with latencies outside of any epoch are most commonly removed as they are not necessarily useful and ambiguities might arise to which epoch an event belongs to. Now it is not in general problematic, however unintuitive if the event defining an epoch is removed.

Furthermore, the way EEGLAB stores event latencies does not allow events outside of epochs without further complications: If epoch length is, for example, 500 samples, events within the first epoch have latencies (stored in samples) ranging from 1 to 500, in the second epoch from 501 to 1000, etc. Thus, the latency of an event 100 samples before the beginning of epoch 2 would incorrectly fall into the latency range of epoch 1. So, essentially this is a limitation of the file format which cannot be easily changed. The shifted event table is, however, indeed a bug. Result should be an empty event table.

Best,
Andreas

> I cannot be the only one who does this? Especially if one is looking at frequency information only, over a long duration. The alternative, of course, is to do this during analysis rather than at the preprocessing step.
> 
> I will report the problem to the bug tracker. Thanks again for your help!
> 
> Yvonne
> From: Andreas Widmann <widmann at uni-leipzig.de>
> Sent: 29 May 2017 10:31:15
> To: Yvonne Blokland
> Cc: eeglablist at sccn.ucsd.edu
> Subject: Re: [Eeglablist] re-epoching; losing a trial
>  
> Hi Yvonne,
> 
> I can replicate the problem. The issue occurs if the time range of the new epoch does not include the latency of the corresponding event. Not sure whether this is a bug or unintended usage of the function. I assume the latter as intuitively the time locking event would be expected to be included in the epoch. Various inconsistencies might be observed otherwise. However, this usage should rather result in an error or an empty file (as the problem actually applies to all epochs not only the first) but not a shifted and corrupted event table as observed.
> 
> I suggest you report this problem at the bugtracker:
> https://sccn.ucsd.edu/bugzilla/
> Part of the problem is that in line 141 of epoch() posend overlaps the next epoch (there is a -1 missing) resulting in the shifted event table (event 1 belongs to epoch 2 etc.). Adding the -1 does result in an empty event table as expected, but the data matrix is still not empty and eeg_checkset does not report any problem (even including eventconsistency check). As there might be other side effects I think this should be fixed by the author.
> 
> Anyway, a bug fix will presumably only give an error message or empty file in your use case. Thus, to work around the issue I would suggest you try to shift your events on the command line so that they are included by the new epoch limits. Replace the second pop_epoch command by:
> 
> tmp = num2cell( [ EEG_all.event.latency ] + 7 * EEG_all.srate );
> [ EEG_all.event.latency ] = deal( tmp{ : } )
> EEG_all = pop_epoch( EEG_all, labels, [ 0 18 ] );
> 
> Note that the epoch limits now refer to the event latencies *shifted by 7 secs*.
> 
> Hope this helps! Best,
> Andreas
> 
> > Am 24.05.2017 um 13:47 schrieb Yvonne Blokland <y.blokland at qmul.ac.uk>:
> > 
> > Hi all,
> > 
> > I am not sure if this is a bug or a stupid error on my end:
> > I have 25-s epochs, of which I want to use the first 2000ms as baseline, and then ignore the first 5 seconds for analysis.
> > As far as I understand this cannot be done in one line of code, so I've done it like this:
> > 
> > labels = { 'AAAA'  'AAAB'  'AAAC'}
> > EEG_all = pop_epoch(EEG, labels, [0  25], 'newname', 'all epochs', 'epochinfo','yes');
> > EEG_all = pop_rmbase(EEG_all, [0 2000]);
> > EEG_all = pop_epoch(EEG_all, labels, [7 25]);
> > 
> > 
> > Weirdly, when doing this I loose the first trial out of every data set at the last step (So: 80 epochs after removing the baseline, 79 epochs left after re-epoching. It's a different trial every time since randomized).
> > 
> > Some output:
> > 
> > EEG.event
> > 
> > ans = 
> > 
> > 1x79 struct array with fields:
> > 
> >     type
> >     latency
> >     urevent
> >     epoch
> > 
> > EEG.epoch
> > 
> > ans = 
> > 
> > 1x80 struct array with fields:
> > 
> >     event
> >     eventtype
> >     eventlatency
> >     eventurevent
> > 
> > EEG.epoch.event gives a list of n=1:79 plus an empty one:
> > 
> > ans =
> > 
> >    Empty matrix: 1-by-0
> > 
> > 
> > 
> > I verified that the same thing happens using the GUI rather than script.
> > 
> > Does anyone have an idea of what could be going on, and/or is there a better way of getting the epochs I want without epoching twice?
> > 
> > Many thanks,
> > Yvonne
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Eeglablist page: http://sccn.ucsd.edu/eeglab/eeglabmail.html
> > To unsubscribe, send an empty email to eeglablist-unsubscribe at sccn.ucsd.edu
> > For digest mode, send an email with the subject "set digest mime" to eeglablist-request at sccn.ucsd.edu