Skip to content

Probe.copy() should preserve contact_ids #421

@h-mayorquin

Description

@h-mayorquin

I think Probe.copy() should preserve contact_ids

Currently, Probe.copy() currently copies only the contact geometry (positions, plane axes, shapes, shape params) and the planar contour. Everything else, including contact_ids, shank_ids, annotations, and contact_annotations, is dropped. The docstring states this explicitly for contact_ids, but the line was added as part of a general style sweep in PR #241 without any discussion of copy() semantics. Was this intentional? The only exclusion that has been there from the beginning is device_channel_indices, which is wiring and you can make a case it is not part of the identity. I could not find discussion about whether the other properties should be copied or not

contact_ids are identifiers set either by the manufacturer at probe init or by the user through set_contact_ids. They are the stable handle the library uses to refer to individual contacts: the Neuropixels reader slices a catalogue probe by contact_id to resolve an IMRO's active set, plotting labels contacts by them, and BIDS export requires them. Dropping contact_ids on copy() removes the information required for those operations. In addition, SpikeInterface clone preserves channel_ids and all recording properties through its Recording.clone(), and I think it would be good if Probe.copy() here had matching behavior.

I came to this while reviewing PR #4465 in SpikeInterface and PR #420 here in probeinterface. In #4465, ChannelsAggregationRecording calls p.copy() on each source probe to build a combined ProbeGroup, and because contact_ids are dropped by the copy, the mapping from channel ids to contact ids is lost in the aggregated recording. In #420, ProbeGroup.copy() is implemented with different semantics: it duplicates the underlying _contact_array wholesale, so contact_ids are preserved through a group-level copy. Probe.copy() and ProbeGroup.copy() therefore do not agree on what a copy preserves, which is undesirable.

I also think the same argument applies to a lot of other properties like shank_ids, annotations (name, model_name, manufacturer, serial_number), and contact_annotations.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions