Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • 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 efficiencyExtra data, like timestamps or events are stored in NumPy format, which can be easily read and converted to raw binary by stripping the header. Metadata about the recording, such as sample rates or channel counts are stored in a easy to parse JSON file.

  • 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.