[Eeglablist] re-epoching; losing a trial

Yvonne Blokland y.blokland at qmul.ac.uk
Wed May 31 09:07:05 PDT 2017


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.


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. 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sccn.ucsd.edu/pipermail/eeglablist/attachments/20170531/7e8ef3b2/attachment.html>


More information about the eeglablist mailing list