Hi all,
I’m wondering if anyone has experience with Natus EEG monitoring system and their proprietary file format *.stc. We are starting a study that involves collecting iEEG data from multiple centers. We are deciding on what format to save the iEEG data in. I want to ensure we are BIDs compliant, which would mean saving the data in EDF format. The clinicians on the study would have to examine the iEEG recordings so we would like to be able to import that data back into the Natus software. A few questions:
- Is there any critical clinical information we would lose if we used EDF instead of Natus .stc?
- How easy is it to import EDF data into the Natus software?
One difference I have noticed is that the EDF file format is much larger than the Natus .stc format. If we g-zipped the EDF files would we still be BIDs compliant?
Thank you for your time,
Greydon
1 Like
paging @sappelhoff who may know more
Unfortunately I have no experience with the Natus EEG system and the .stc
file format. It seems to me like there are currently also no reading functions implemented in common analysis software suites like MNE-Python or FieldTrip. Would you be analyzing the data using proprietary software?
To answer your questions:
- I would advise that you
- do the conversion from
.stc
to .edf
- store BOTH file formats: the
.edf
in the main raw data BIDS directory, and the .stc
files in a /sourcedata
directory nested there)
- take a look at the
eeg_matchingpennies
example: The data was originally recorded in .xdf
format, but then converted to BrainVision format (.eeg
, .vhdr
, .vmr
) … the original .xdf
files are still shipped with the data in the /sourcedata
directory
- Going back to my introductory paragraph: I am not sure how well the proprietary Natus Software will be able to deal with EDF data. However, EDF data is handled well by all major open source data analysis software suites
- Finally, g-zipped EDF files are currently not supported in BIDS. If I remember correctly, an argument against this was that the gain in space was not enough to justify the added workload to unzip again (…???)
Thank you for such an informative response! Really helped in determining my next steps.
The issue with the Natus .stc
format is it uses a proprietary compression algorithm. In order to convert the .stc
into another format, we would need to sign an NDA with Natus to obtain their C++ SDK. We would be doing the analysis in MNE-python.
Unfortunately, the Natus system is a widely used clinical data recording system for epilepsy monitoring units so we need to continue to use the system. Looking into it further, it seems the system will import and export EDF files without issue.
One problem we will face is that these are 24-hour iEEG recordings sampled at 1Khz, so they are very large in size. Saving the .stc
and .edf
might be a challenge. We may have to export .edf
from Natus and not save the .stc
.
I see … perhaps you could try a conversion from stc
to edf
early on and do extensive checking on which data gets “lost in translation” (if any data gets lost at all)
Glad I could help!
PS: Very sorry to hear that Natus seems to be locking their customers in with a proprietary compression algorithm