Skip to content

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

@h-mayorquin

Description

@h-mayorquin

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions