`read_spikegadgets_neuropixels` applies a display offset to multi-probe geometry; should it?

Open
#442 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
data

Research direction

Start at read_spikegadgets_neuropixels and trace how multi-probe contact_positions are populated, then review the display offset introduced in #260 and generalized in #441. Check the plotting path to determine where overlap spreading belongs. Done means absolute contact_positions remain unmodified, while multi-probe plots can still separate overlapping probes during rendering.

Written by the indexing model from the issue text.

Description

Today read_spikegadgets_neuropixels shifts each probe in a multi-probe .rec by multi_probe_plot_offset_um * (probe_index - 1) on the x axis (250 um for NP1.0 and NP2.0 single-shank, 1000 um for NP2.0 4-shank). The shift was introduced in #260 to keep multi-probe ProbeGroup plots visually distinguishable: the catalogue probe sits at origin, so without it two or three NP1.0 probes would stack on top of each other. In #418 I kept the line, and in #441 I generalised the magnitude per format, but the display-only transform is still baked into contact_positions.

As far as I am aware read_spikegadgets_neuropixels is the only multi-probe Neuropixels reader that does this. Downstream consumers that read absolute coordinates (stereotactic registration, custom multi-probe layouts) see invented values for probes 2 and 3, with no annotation and no opt-out. I think the better fix lives in the plot function: detect overlap and spread probes only when rendering. That keeps contact_positions honest and would help any multi-probe reader, not just SpikeGadgets. What do you think?

Dominant language
Python
Stars
85
Forks
49
Avg merge
13h 47m
Merged PRs (30d)
3

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SpikeInterface/probeinterface

All issues in SpikeInterface/probeinterface

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.