Support for Neuropixels Ultra (NP1110) in SpikeInterface

[Serendipityzzz]

Title: Support for Neuropixels Ultra (NP1110) in SpikeInterface and DREDge

---

Description:

I am using Neuropixels Ultra (NP1110) probes for neural recordings and encountered issues when processing the data using SpikeInterface and DREDge. The current implementation appears to lack explicit support for NP Ultra probes. Below are the specific issues identified and proposed modifications:

---

Issues Identified:

1. IMRO Table Parsing (SpikeInterface)

   • The .meta file for NP1110 uses a different imroTbl format: (channel_id, bank, mux_group) compared to NP1/NP2.
   • Global parameters (AP/LF gains, reference, filter) are stored in the header rather than per-channel values.
   • The _read_imro_string() function currently expects per-channel gain/filter fields, leading to a failure when processing NP1110 data.

   Proposed Fix:

   • Modify _read_imro_string() to handle NP1110-specific parsing.
   • Extract global parameters directly from the IMRO header and adjust the data structure to use ("channel_ids", "banks", "mux_groups").

---

2. Channel Index Mismatch (SpikeInterface)

   • After slicing the probe to match snsSaveChanSubset, the device_channel_indices are reset using np.arange(), causing set_probe(inplace=True) to fail.
   • The original channel indices need to be preserved for accurate mapping.

   Proposed Fix:

   • Update the slicing procedure to retain original channel indices:

     probe.set_device_channel_indices(saved_chans)  # Preserve instead of using np.arange()  

---

3. Global Parameters Handling (SpikeInterface)

   • NP1110 AP/LF gains and filters are defined once in the IMRO header (e.g., (1110,2,0,500,250,1)), while the current code assumes per-channel values.

   Proposed Fix:

   • Modify the .meta file reader to annotate the global parameters directly, e.g., probe.annotate(global_ap_gain=500).

---

4. NP Ultra Compatibility in DREDge

   • The read_spikeglx() function in DREDge currently supports NP0.0, NP1.0, NP2.0, and NP1.0-NHP but not NP Ultra (1.0 HD).
   • Despite this, the demo code ap_registration.ipynb and the published paper demonstrate results using NP Ultra data.

   Proposed Questions/Clarifications:

   • How was NP Ultra compatibility enabled for DREDge in the published paper?

[alejoe91]

Hi @Serendipityzzz

Great timing for this issue! We have been collaborating with the SpikeGLX and Neuropixels developer teams to gather info about all NP probes in a centralized repo: https://github.com/billkarsh/ProbeTable

Our plan for the next couple of weeks is to update the probe parsing and the readers using that centralized resource (see SpikeInterface/probeinterface#341).

This said, NP1110 is the only probe within the neuropixels family that has different "rules" with respect to other probes. In the process of refactoring our parsing strategy, we'll make sure to support NP1110 correctly as well. We'll ping you here when we have a working PR for you to test.

(@jenniferColonell tagging you here if you have some additional comments!)

[jenniferColonell]

Just a couple notes for @Serendipityzzz

The NP1110 imro table is completely different than than other NP probes, due to the complicated rules for setting switches. If you need to extract any position information, please use the snsGeomMap, which records the position for each saved channel.

The data in the DREDge paper was mostly (maybe all) from a different probe (NP1100), which included only a single bank of 384 channels and no switching -- so compatibility with the NP1110 was not required.

[Serendipityzzz]

@jenniferColonell Hi Jennifer! Nice to hear from you after last sfn!
The NP1100 seems to be a NP 1.0 probe, not the 1.0 HD (ultra) one (based on https://billkarsh.github.io/SpikeGLX/Sgl_help/Metadata_30.html#imec)? And in DREDge paper fig5, they show one result with NP ultra.

[jenniferColonell]

Hi -- It's just a detail, but the NP1100 is an "NP1.0 like" probe, not an NP1.0 probe. The 1100 pattern is a single bank of 384 sites with the Ultra pattern. Essentially all of the data in the Ultra paper was taken with this probe type, and that's what was used in the DREDge paper as well. It is programmed just like a standard NP1.0 probe (except that there is only one bank), and the imro table is the same.

The NP1110 probe -- also called, 'Ultra', also called 'NP1.0HD' has 16 banks of 384 site each. The programming of this probe is very different, to handle that large number of sites. It therefore requires a different imro table.

[EthanKato]

Is there any update on support for NP1110 'Ultra' probes?

[h-mayorquin]

Hi, we are moving forward to support this probe but we would like to get sample data for this. Could anyone here share it with us?

[jenniferColonell]

Hi Heberto, I've uploaded a run to dropbox: https://www.dropbox.com/scl/fo/rkmzj9l8kz3fzbm2wswsk/AFRNQHaqAUkSPb3zUQsTYZg?rlkey=wragrttvdx2vrgxn6uj8l0vu3&st=u4nsumg7&dl=0
I've given Alessio permission for the folder (because I have an email for him) you might need to have dropbox send me an email for confirmation.
I've included a few very short recordings with a few different patterns. The imro table (which I assume you're not using at this point) is very different for these probes, but everything else in the metadata is very similar to NP1.0.

[alejoe91]

Hi Jennifer, we have an open PR that tried to reverse engineer the SpikeGLX C++ code here: SpikeInterface/probeinterface#410

I added the meta files you provided as test files and wanted to double check with you that the mappings that we get look correct.

NOTE: depths are with respect to the bottom row of the standard configuration (our 0).

NP1110_bank0_g0_t0.imec0.ap.meta

Standard config with 48x8 grid at the tip:

NP1110_2x192_bank4_g0_t0.imec0.ap.meta

2x192 spanning 1152/2298 um in depth, but in the middle the 2 columns "snap" to the right:

NP1110_botrow80_g0_t0.imec0.ap.meta

48x8 grid, but spanning 480/762 in depth:

NP1110_vstripe_g0_t0.imec0.ap.meta

Interleaved 1-column config, spanning 2304/4602 in depth.

[jenniferColonell]

Hi Alessio, These look correct -- however, because the channel arrangements are complicated, the best check is to match your coordinates to those in the snsGeomMap in the metadata.

[alejoe91]

Hi Alessio, These look correct -- however, because the channel arrangements are complicated, the best check is to match your coordinates to those in the snsGeomMap in the metadata.

Great idea :) I'll add it to the test!!!

[alejoe91]

Hi Alessio, These look correct -- however, because the channel arrangements are complicated, the best check is to match your coordinates to those in the snsGeomMap in the metadata.

Done! and giving the exact same results (with an x-offset of 15 um, due to the different "origin" - we use the left-most/bottom-most electrode)

[jenniferColonell]

Sounds good! btw, the x_offset is set the coordinates relative to the edge of the probe, and I think you should be seeing 15.5 um.