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
    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