Supported Formats#

To manage project analysis, spikewrap must make some assumptions on how the data is organised.

Currently, only data from Neuropixels probes acquired in SpikeGLX or OpenEphys are supported.

Contact Us

If you would like to see more formats supported, please don’t hesitate to get in contact.

Key data organisation levels#

We briefly define the three folder levels that spikewrap expects to find:

subject:

The experimental subject from which the data is recorded.

session:

The experimental session in which the data was collected.

run:

Multiple runs within an experimental session are supported.
Runs are inferred based on the acquisition software (see below).

Supported data organisation schemes#

NeuroBlueprint is the recommended way to organise the project folder for spikewrap.

Briefly, a NeuroBlueprint project is organised like:

└── rawdata/
    └── sub-001_.../
        └── ses-001_.../
            └── ephys  /
                └── <spikeglx or openephys output>

See the full NeuroBlueprint specification for details.

Otherwise, it is expected that the folder format of the data will have the levels:

subject -> session -> recording

For example:

└── my_subject_name/
    └── my_session_name/
        └── <spikeglx or openephys output>

NeuroBlueprint

All examples below are in NeuroBlueprint format.

Acquisition-software specific organisation#

We are keen to extend support to more SpikeGLX and OpenEphys use cases. Please get in contact with unsupported datasets.

SpikeGLX recordings (in this example output to ses-001/ephys) are typically formatted like:

└── ses-001/
    └── ephys/
        └── run-name_g0_imec0/
            ├── run-name_g0_t0.imec0.ap.bin
            └── run-name_g0_t0.imec0.ap.meta

Experiments that do no use multiple gates, triggers or imec probes are immediately supported.

An experimental folder with SpikeGLX-acquired data might look like:

└── rawdata/
    └── sub-001  /
        └── ses-001/
            └── ephys/
                ├── run-001_g0_imec0/
                │   ├── run-001_g0_t0.imec0.ap.bin
                │   └── run-001_g0_t0.imec0.ap.meta
                └── run-002_g0_imec0/
                    ├── run-002_g0_t0.imec0.ap.bin
                    └── run-002_g0_t0.imec0.ap.meta
Recordings with multiple gates, trigers or imec probes

spikewrap assumes that all folders within the session level are separate runs. Multi-gate recordings will be treated as separate runs.

Therefore, you can distinguish runs either with the run-name, or keep the same run-name and acquire separate gates. However, if multiple run names and multiple gates are mixed, all will be treated as separate runs.

Currently multiple imec probes are not supported.

For each run, only one recording is expected. Therefore, multi-trigger recordings are not supported.

Note runs are simply concatenated in spikewrap / SpikeInterface by direct concatenation of the data. Use catGT for proper concatenation of multi-gate and trigger recordings.

Currently, the flat binary format (the OpenEphys default) is supported.

OpenEphys flat binary recordings (in this example output to ses-001/ephys) are organised like:

└── ses-001/
    └── ephys/
        └── Recording Node 304/
            └── experiment1/
                ├── recording1
                └── recording2
                └── recording3

At this level, OpenEphys has three concepts (Recording Node, experiment and recording) but spikewrap expects only a single a set of runs.

Therefore, spikewrap will treat the recording folders as separate runs. This means that datasets with multiple Recording Node and experiment folders are not currently supported.

In the above, example, the ses-001 will be associated with three runs (recording1, recording2 and recording3).