olafdimigen / eye-eeg

EYE-EEG toolbox for combining eye-tracking & EEG
https://www.eyetracking-eeg.org
37 stars 12 forks source link

Issue with epoching after flagging bad data using pop_rej_eyecontin() #28

Open Dyschezia opened 3 weeks ago

Dyschezia commented 3 weeks ago

Hi. There seems to be an issue with epoching data after marking (but not removing) bad ET on the continuous data. The duration of the bad_ET event seems to not be changed in the epoching process, leading to a situation where a long bad_ET event that started in one epoch will spill on the next ones according to the new time axis, not taking into account whether originally it was part of these events. In the attached images, the first shows the bad_ET event in the continuous EEG: it starts at the end of the trial and continues into a break between trials. The second image shows the epoched data: the same bad_ET event now lasts for the same duration (as confirmed by checking its duration in EEG.event), but this time including the trials following the one it started in (and not the break, which was removed while epoching).

bad_ET1 bad_ET2

This could also be a bug in EEGLAB and not the eye-eeg plugin, I did not check whether it happens with other events.

Thank you!

olafdimigen commented 3 weeks ago

Thanks for submitting this issue. The "duration" property of events in EEG.event is indeed not tracked by EEGLAB when epochs are cut, in the sense that a long/ongoing event is not "copied" to multiple epochs.

For clarificaiton: If you detect your saccades in continuous data, the possibility to add bad_ET events is mainly intended to avoid that bad eye-tracking samples affect the detection of saccades in the continuous data, because bad samples (like zeros and outlier values during blinks) can distort saccade detection algorithms, like the Engbert & Kliegl (2003) algorithm.

In contrast, when we do the saccade detection on epoched data (this depends on the experiment), we prefer and suggest to generally exclude the entire epoch if it contains missing/bad eye-tracking data. So in our workflow, the issue you raise is usually not a practical problem.

I agree however, that it would be more elegant if the original bad_ET events were correctly tracked including their duration. Some serious hacking would be needed to maintain the event duration information if it spans multiple epochs. I am very open for pull request in case you want to try to improve this (which needs to be an indirect solution since the pop_epoch function belongs to EEGLAB).

Dyschezia commented 3 weeks ago

I think this could be a practical problem, as detecteyemovements.m is written in a way that assumes epoched data could have bad_ET events masked and not rejected already (looking at lines 238-254), and generates badvector according to them for continuous and epoched data. This is how I found this in the first place - the generated badvector was longer than the actual EEG data because of long bad_ET instances (during breaks etc.). I started working on a modified version of rej_eyecontin.m that could work on continuous or epoched data and that, while not fixing the issue of event durations not being edited during epoching, will create events with the right duration when run on epoched data. If you think this is a good enough solution, I would be happy to upload it when I'm done.