I was trying to review and import the ECoG/EEG data in the format of EDF (generated by Nihon Koden's machine). I received error messages, which occur in the step of loading annotation from EDF files.
** Error: Line 445: Unrecognized function or variable 't0_file'.
**
** Call stack:
** >in_fopen_edf.m at 445
** >in_fopen.m at 103
** >import_raw.m at 126
** >bst_call.m at 28
** >tree_callbacks.m>@(h,ev)bst_call(@import_raw,[],[],iSubject) at 658
**
I checked the values during the processing of EDF annotation channel.
There is only one annotation channel in my dataset.
The program cannot obtain the t0 information probably because the information in strAnnot cannot pass
"if (iAnnot == 1) && (length(splitAnnot) == 1) && ~any(splitAnnot{1} == 21)".
The strAnnots obtained from the first channel in my dataset is
"+0.000000\u0014\u0014+0.000000\u0014Segment: REC START 1-128 EEG"
So the splitAnnot is {'+0.000000'} {'+0.000000'} {'Segment: REC START 1-128 …'}
The starting time of my dataset is 0 and I am not sure about the reason of using iAnnot == 1, length(splitAnnot) == 1, and ~any(splitAnnot{1} == 21). I just replaced "if (iAnnot == 1) && (length(splitAnnot) == 1) && ~any(splitAnnot{1} == 21)" with "if (iAnnot == 1) " and ran "Reviewing raw file" again. Then the error message was not shown. Will this modification cause any potential problem in the data processing?
The fix you propose would prevent from reading any other event ("TAL") from the file. The following else block is actually more important than this first if (iAnnot == 1) ... test.
One option is that your file is simply missing the t0 definition, ie. a TAL with no annotation in the first record of the file (irec=1, iAnnot=1, TAL=+0.000000\u0014). Note that Unicode character \u0014 is the equivalent to the ASCII [20] character that separates the blocks.
Another possible problem could be coming from the confusion with Unicode encoding or reading... In that case, I would an example dataset to investigate this further (as small as possible, so that I don't have to download several Gb)
Let me know how it goes.
PS: Why don't you work directly with the NK files?
After running the updated program, I got the following error message:
** Error: Line 397: Unrecognized function or variable 'prev_rec'.
**
** Call stack:
** >in_fopen_edf.m at 397
** >in_fopen.m at 103
** >import_raw.m at 126
** >bst_call.m at 28
** >tree_callbacks.m>@(h,ev)bst_call(@import_raw,[],[],iSubject) at 658
**
If I am going to load event information from other files, does that mean it's ok to skip downloading the information in the annotation channel?
Please find the example NK EDF data through the following google drive link: EEG_5minresting
We were thinking that EDF format might be more common and thus most of software may support this format. That's why we saved those EEG and ECoG in the format and EDF. I checked the tutorial that Brainstorm supports .eeg format. Does the NK files you mentioned equal .eeg files?
The file you sent me has incorrectly formed event information in the annotation channels, it is not compliant with the EDF+ specification: https://www.edfplus.info/specs/edfplus.html
In the first record (=block of recordings), which causes the bugs you observed: +0.000000[20][20]+0.000000[20]Segment: REC START MEG EEG
there is a missing null (\0) character after the first block. It should be: +0.000000[20][0][20]+0.000000[20]Segment: REC START MEG EEG
and it should be read as two separate TALs instead of one.
I recommend you discard any timing and event information coming from this file, as it is unreliable.
We were thinking that EDF format might be more common and thus most of software may support this format. That's why we saved those EEG and ECoG in the format and EDF.
Using intermediate conversions to EDF+ is never recommended unless absolutely necessary, due to many limitations of this file format (impossible to store anything but int16 data for instance).
And now you found out that on top of this, the NK EDF+ export has bugs....
Does the NK files you mentioned equal .eeg files?
The Nihon Kohden files have .eeg extensions indeed.
You can process them natively with Brainstorm.
Thank you very much for quickly updating the program. I successfully import the NK EDF file into Brainstorm using the updated version!
We didn't know that EDF file format has many limitations. Next time we will save the data in the format of .eeg extension. We will also contact NK to ask about the incorrect format of exported EDF file.
Thank you for the example file.
Unfortunately, it is in a format that is not handled by the Brainstorm reader yet.
The list of supported file formats, from the function get_header_version:
function ver = get_header_version(str)
% Older NK systems
if ismember(str, {...
'EEG-1100A V01.00', ...
'EEG-1100B V01.00', ...
'EEG-1100C V01.00', ...
'QI-403A V01.00', ...
'QI-403A V02.00', ...
'EEG-2100 V01.00', ...
'EEG-2100 V02.00', ...
'DAE-2100D V01.30', ...
'DAE-2100D V02.00', ...
'EEG-1100A V02.00', ...
'EEG-1100B V02.00', ...
'EEG-1100C V02.00'})
ver = 1;
% Newer NK systems (>= 2015)
elseif ismember(str, {...
'EEG-1200A V01.00'})
ver = 2;
else
ver = 0;
end
end
Your file contains a block labelled BFA NKC04/01/16, which I have no idea how to handle. I tried the two readers existing in Brainstorm (version 1 and version 2) and it doesn't work.
It is complicated to update the readers because the NK file formats are not publicly documented, and most of if comes from reverse engineering... I'll try asking around among the expert NK users, if anybody has ever tried to read similar files with open-source software.
In the meantime, I'm sorry, I don't have any other solution than sending you back to the NK to EDF+ converter...
Please tell us all the information you know about the device that recorded this file: model of the EEG system, name of the cap and amplifiers, version of the acquisition software, purchase date, recording date...
That's very likely because it looks strange to use the string "+0.000000" as an annotation description.
However, it is correctly formatted EDF+ and technically, there's nothing wrong with it.
If one would want to store two annotations, one with description "+0.000000" and one with description
"Segment: REC START MEG EEG", both with an onsettime at 0.0, this is one valid way to do that.
This is invalid EDF+. The first annotation in the first annotationsignal, must be empty and is used for time keeping of the datarecord.
The following is correct:
+0.000000[20][20][0]+0.000000[20]Segment: REC START MEG EEG[20][0]
Notice the empty annotation used for timekeeping.
It could also be written as:
+0.000000[20][20]Segment: REC START MEG EEG[20][0]
In this case, the first empty annotation (used for timekeeping) and the second annotation share the same onsettime.
@Teuniz Thanks for checking for the EDF file! I will double-check this.
The last posts were about the original Nihon Kohden file, which EDFBrowser can't convert either.
Would you have any info related with this NK file format?
Unfortunately not. Presently, I'm not working with NK equipment anymore and I don't have access to these machines anymore.
In my past experience, NK is notorious for providing info about their fileformats.
The only way to get your hands on it is to make it part of the purchase deal (in written) when buying NK equipment.
It's a problem that should be handled by big organizations like universities when buying equipment to require also full specs of the fileformats. They have that power when negotiating for the best deal.
Thanks for your valuable input! I didn't consider that possibility, indeed.
I fixed the Brainstorm EDF reader in order to handle this case correctly:
I still think, however, that this might be related to an unexpected behavior of the NK export software.
It would make more sense with an extra [0] to split this TAL into a record timestamp plus an annotation Segment: REC START MEG EEG:
+0.000000[20][20][0]+0.000000[20]Segment: REC START MEG EEG[20][0]
@lyngen Can you see any event named "+0.000000", "+3.000000" or "+4.000000" in the NK viewer?
Model of EEG system: EEG-1260
Amplifier name: JE-921A for 10-20 scalp EEG and JE-120A for ECoG
Software version: Ver. 06-02
Purchase date: March 2020 and Dec 2020
For the data I uploaded before, I don't have their NK raw data and thus cannot check the event in NKviewer. I uploaded another dataset that I have NK raw data. Please download the eeg file, edf file, and snapshots of events shown in NK viewer from the following link. In the NK viewer, I didn't see event named "+0.000000", "+3.000000" or "+4.000000" in this file.
This is indeed a new system, for which we don't have any information yet, I won't be able to update the Brainstorm reader to support this file format.
If anybody gets any information about the NK EEG1260 file format, please let us know.
I didn't see event named "+0.000000", "+3.000000" or "+4.000000" in this file.
This confirms our guess that there is a bug in the NK EDF+ export function.
Not critical, since it only defines extra useless events, but to keep in mind if you observe anything else strange in the list of events obtained from the EDF+ files, there might be other issues.
You could suggest that the people who own this NK EEG system report this to the company customer service.
About the version of format, NK company said that EEG-1260 uses the same format as EEG-1200. So we should be able to read .eeg data from EEG-1260 if the program can import .eeg data from EEG-1200.
I tried reading the data from this file using the same function as for the blocks EEG-1200A V01.00 but unfortunately it doesn't work. Our functions probably don't handle all the possibilities of the EEG1200 file format.
Since we have both the .EEG file and the EDF+ export, there is the possibility to do some reverse engineering in order to understand how the pointers system works in this file, but it would take days, with no guarantee of success. I currently don't have enough time to work on this.
Unless someone has other interesting options, I suggest you go back to your initial objective of working the EDF+ files. I'm sorry my initial recommendation to work with the NK files was not a good one...
Francois. It's OK! I understand that. Thanks for your time and efforts in checking our problems and also making Brainstorm being able to import our EDF files. We are now using EDF format to do analysis. One day when you want to work on any NK file issue, please don't hesitate to let me know if you need any info. Thanks again.