Proposal: Add `ProbeInterface` Support for ONIX Source Plugin

[bparks13]

Hi there! I'm currently helping develop a new Open Ephys GUI plugin, ONIX Source, which streams Neuropixels data from an ONIX acquisition system. We already have a beta release and are aiming to maintain compatibility with the existing Neuropixels-PXI and OneBox plugins wherever possible.

Current Behavior

Using SpikeInterface, we're able to load neural data from ONIX recordings via si.read_openephys, since the stream structure is consistent. However, generating probe geometry using pi.read_openephys does not currently work for ONIX Source, as that function is tailored for PXI and OneBox plugins.

The main limitation stems from the lack of embedded probe metadata in the ONIX plugin's settings.xml file — unlike PXI/OneBox, which include additional details like part number and probe version in XML, allowing the function to infer the inter_sample_shift and probe contours.

Proposed Solution

Rather than modifying the XML structure for the plugin (and requiring changes to pi.read_openephys parsing logic), we propose the following:

• Create an ONIX Source folder alongside each Record Node folder
• Save a fully formatted ProbeInterface JSON file to this folder for each stream
• Modify pi.read_openephys to:
  • Detect if the source is ONIX Source
  • Search for a corresponding JSON file in the ONIX folder (e.g., ../ONIX Source XXX/<stream_name>.json)
  • Stream names would have '-AP'/'-LFP' suffixes stripped to align with how ProbeInterface handles these as a single device
• Load and return the probe group directly using:

from probeinterface import read_probeinterface
probegroup = read_probeinterface('/path/to/<stream_name>.json')
return probegroup

This avoids the need to embed detailed metadata in the XML file and ensures we preserve compatibility with existing workflows.

Benefits

• No changes needed to ONIX's minimal XML structure
• Cleaner separation of concerns (streaming vs. probe config)
• Allows seamless use of pi.read_openephys for ONIX users

Let me know if this approach seems viable, or if there are edge cases we might be missing. I’d be happy to help implement or test the changes!

[zm711]

At least in my opinion this sounds fine. The read_openephy and read_spikeglx both follow complicated logic so if there is a simple case of just loading a json file that seems great. We can see what @alejoe91 thinks too.

[alejoe91]

Hi @bparks13

I agree that having extra files/folders is a better strategy instead of messing around with the XML file!

A couple of suggestions/thoughts:

• do we need the ONIX Source folder alongside Recording Nodes? This could mess up with how we explore the Open Ephys folder structure in NEO
• why not just adding a probe_{stream_name}.json in each experiment* folder? The reason is that Probes (and streams) could change across experiments (in fact you have different settings files). Then we would only need to change the spikeinterface read functions and primarily check if a probe_{stream_name}.json is available!
• we recently (#349, #355, #356) refactored our neuropixels tools here and in spikeinterface to use ProbeTable, a centralized resource for NP metadata. This means that we are not estimating the inter-sample shifts in spikeinterface anymore, but getting them from the mux_channels contact annotations. You can either generate JSON files with such annotation, or we could make a probeinterface function get_mux_channels_from_probe_type() that retrieves the correct info and attaches it to a probe.

[bparks13]

Hey @zm711 @alejoe91 — thanks for the feedback and suggestions.

The Open Ephys dev team confirmed the ONIX Source plugin can’t write directly into the Record Node experiment* folders, so placing JSON files there isn’t possible. I’m not familiar with NEO’s limitations — could you clarify why adding an ONIX Source folder alongside the Record Node might be problematic? If it’s workable, I can mirror the experiment* structure inside the ONIX Source folder so the corresponding <stream_name>.json is easy to locate while keeping the hierarchy consistent.

On the ProbeTable updates — would including the probe type in the ProbeInterface JSON be enough to attach the correct mux channel/contact annotations, or is additional context needed? I can adapt the JSON to integrate cleanly with the new ProbeTable workflow.

Thanks again for your help — I really appreciate your insights and look forward to collaborating more on this.

[bparks13]

Hi @alejoe91, just following up here — I wanted to check if you had any thoughts on the folder structure and ProbeTable integration questions I mentioned above. I’d like to make sure I have all the details clear before starting work on this, so any guidance you can share would be really helpful. Thanks!

[alejoe91]

Hi @bparks13

If you cannot write directly to th experiment folders then what you suggested is perfect!

The probe type should be enough to fetch mux channels and attached them to the probe object, which will need some updates on our end.

I suggest you get started with a PR and we can discuss details there :)

[bparks13]

Hi @alejoe91

I have opened up a draft PR on the plugin repo, and I have attached a zipped folder there for testing that contains the folder structure with the settings.xml files and the JSON files for a Neuropixels 1.0 probe.

Let me know if this makes sense on your end!

Also, to confirm, are you referring to a PR for the plugin, or a PR for SpikeInterface/ProbeInterface? I would be happy to take a stab at it from the SpikeInterface side, just let me know if there are any considerations I should keep in mind if I were to get started.

[chrishalcrow]

Hello, I've been snooping a bit and looked at the sample data from the PR you mentioned. I'm curious: how do you figure out the electrode positions for each channel?

[bparks13]

@chrishalcrow The original electrode positions were taken from the Neuropixels PXI plugin from the OE GUI. I copied over the code based on their original setup to the ONIX Source plugin.

I am not sure where these numbers originally came from though.

[chrishalcrow]

Great, thanks. I have a feeling we'll be able to use the settings.xml files to generate the probes without having to make the intermediate json file. I'll have some time to have a proper go at this late next week.

[bparks13]

Sounds good! Let me know if there is anything I can do to help, or anything that needs to be changed on my end.

[chrishalcrow]

Hello, I made a draft PR #360 with some comments/questions.