Hi,
Brainstorn newbie here. I have gone through the tutorials.
Now I want to import some EEGLAB .set files. The dataset is epoched and has 6 events per epoch. The first epoch is labelled 768 and is located at the first sample of each epoch. The event defining the epoch type is located midway while others are scattered along the epochs.
Ideally I would like to import the epochs with all the events but this does not seem to be possible. Irrespective of the parameter I select from the ‘Condition Selection’ window, I always have all the epochs imported and all labelled type768 which seems to refer to the event (768) at the beginning of each epoch.
Reading the forum, it looks like I cannot import all event? So if I extract the event onset times for each epoch from EEGLAB, can I map them to their corresponding trials somehow?
Hello,
I’m not sure I follow what you describe here. I’m not very familiar with the way the EEGLAB files are structured.
If you want me to have a look at it, please send me your file (upload it somewhere and send me the link in a separate message on this forum) and describe the final structure you would like to have in the database after importing everything.
Thanks
Francois
I am using Brainstorm 29th/Sept/2017.
I have just traced the 'Import MEG/EEG' down to lines 186-200 of function 'in_fopen_eeglab.m'.
These lines of code decides the event type of each epoch. The code makes this decision based on the first event type on the list of an epoch's events. This should work perfectly if there is only one event type per epoch. The code also tries to define epochs using event duration and I think latency but I am not sure that this is necessary.
I have two issues when the data is imported into Brainstorm.
Trials are not separated/correctly separated into different folders based on particular event types.This can be solved by asking user to select event types with which the trials will be labelled. I have temporarily messily patched this by messing around with : in_fopen_eeglab.m (17.1 KB) in line 176-163 and 212-219. I was just using this to learn more about BrainStorm. I believe also that it will be much easier for your to understand the issue I was having when you have look at those lines.
There is no event present on the loaded files (see the Record tab below). I don't think I need this one at the moment but it will be good to have it working. I need to know Brainstorm a bit more in order to make a suggestion. From line 367, it seems like you are reading the events markers but no event markers appears on the loaded file.
When you load the file I sent you please enter the events: 769,770 in the new dialogue I have added. Here event 7702 is read as 770 successfully. This will demonstrate that it is better to allow users to adjust the automatically extracted events types.
The above image shows that using the modification I have added to 'in_fopen_eeglab.m', I can load the separate trials of dataset hs1 (https://www.transfernow.net/01joy1o0050a) in differents folders but all event markers are missing as shown on the Record tab.
Looking at ‘in_fopen_eeglab.m’ line 367, I can see that you are only interested in imported the events only if the data is not epoched. You may not need to worry any longer, I will try to write my own import.
Thanks
Regarding event 768, it is a subevent which is often in BCI studies. Basically each trial has about 5 events but only one of the events defines the trial and others are subevents. E.g. Imagine epoch types labelled 769 which represent left hand task and 770 for right, then 768 which could represent subject response time will appear in both epoch types. The epochs can only be separated with event 769 and 770. After separation they can be re-epoched to extract their respective 768.
As for the unusual issue with 7702; it special to my processing pipeline and this is the reason I am using the input dialogue to choose the event type.
Thanks a lot for your help and putting together this beautiful software.
Bethel
Hi Francois,
Am sorry but I have updated BrainStorm and tried loading the file I sent you and I am not understanding the loaded data at all. For example, if I choose event 769 as in the image below,
no subevent is loaded and the number of repeated folder created depends on my answer to the popup dialogue below.
If I however I specifically select event 769 from the 'Event selection' fieldset as shown in the image below, the subevents are loaded but two things happens, the epoch time length is not loaded correctly as specified(it loads [-3000 to 293]ms instead of the specified [-3000 to 3000]). Secondly the subevent times are loaded wrongly.
As a guide, when epoching with event 769, event 768 should be located at -3000ms as this event actually means start of trial.
By the way under event selection, is it possible to ask for the entire epoch to be loaded perhaps by using a checkbox or by entering +-Inf in the Epoch time fields.
You shouldn’t be using the option “Use events” here.
This is not a selection of sub-events, but an option to “re-epoch” the existing epochs. If you select “Use events” and event 769 in the list, it would try to extract a time window of [-3s,+3s] around each event “769” within each epoch, which is not possible because there is not enough data available in your epochs. Therefore the files that are imported are much shortrer than 6s, and may have quite random time definitions.
If you decide to import a file that is already epoched in Brainstorm, you should stick with the existing epochs (do not select the option “Use events”).
Alternatively, link the native continuous files in Brainstorm and do the epoching there, as illustrated in all the online tutorials (in this case, you would need this option “Use events”). This could make your import process easier…
Actually Francois each epoch is just over 6s long and event 769 is positioned ~ midway at 0s or if you are using only positive timing then it is located at 3s. So extracting epoch of length [-3s,+3s] around event 769 located midway in an over 6s epoch should work?
Perhaps I can go back to EEGLAB and prepare the epochs how Brianstorm likes it; so not a big issue.
