The GUI allows the user to save data in multiple formats, thanks to the use of RecordEngines. RecordEngines allow data formats to behave like plugins, with each format defined in its own file that's called on at the time of recording to determine how the data will be written to disk. You can only use one RecordEngine at a time, but you can switch to a different engine as soon as acquisition is stopped.
The available RecordEngines can be found in the drop-down menu at the far left of the recording options control panel.
The four RecordEngines currently supported by the GUI are:
The details can be found on the respective sub-pages for each format. Here's a quick overview of why you might choose one or another:
- Open Ephys format stores data in a binary file that contains both the data samples and markers that allow data to be recovered if any part of the file becomes corrupted. Each channel is stored in a separate file, which can be convenient or inconvenient for analysis, depending on what you need to do. It's the first format that was used by the GUI, so it's been the most extensively tested. However, it's specific to Open Ephys, and will likely need to be converted to be compatible with most analysis tools. If you're unsure about which format to use, or you're running the GUI on a potentially unstable system, we'd recommend using this.
- Flat binary format stores the data as an array of samples in the following order: ch1 sample1, ch2 sample 1, ch3 sample 1, ..., chN sample 1, ch1 sample 2, ch2 sample 2, etc. It's the most compact format, and therefore can be loaded very quickly. But because there's no extra information in the file, it requires that you keep track of the number of channels are saved in your dataset, as well as their ordering. It's also not robust to corruption. That said, it's likely that flat binary files will become increasingly common in the field, due to their simplicity and efficiency.
- NWB format stores data inside an HDF5 file, according to the specification defined by the Neurodata Without Borders project. It's based on a one-file-per-experiment philosophy, and aims to ensure that the data is self-documenting and easy to share. It comes with all the baggage of HDF5, including the need for a large library to access the data, and the inability to read any of the data if the file becomes corrupted.
- KWIK format was designed for use with the KlustaKwik spike sorting package, and is also based on HDF5. It has since been abandoned by the developers of KlustaKwik, for the reasons outlined here. We'll continue to support the KWIK format for Open Ephys data, but we'd recommend moving away from it if you can.
Please clone or download the analysis-tools repository to access tools for reading the data into Matlab and Python.