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.
I think
Probe.copy()should preservecontact_idsCurrently,
Probe.copy()currently copies only the contact geometry (positions, plane axes, shapes, shape params) and the planar contour. Everything else, includingcontact_ids,shank_ids,annotations, andcontact_annotations, is dropped. The docstring states this explicitly forcontact_ids, but the line was added as part of a general style sweep in PR #241 without any discussion ofcopy()semantics. Was this intentional? The only exclusion that has been there from the beginning isdevice_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 notcontact_idsare identifiers set either by the manufacturer at probe init or by the user throughset_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. Droppingcontact_idsoncopy()removes the information required for those operations. In addition, SpikeInterface clone preserves channel_ids and all recording properties through itsRecording.clone(), and I think it would be good ifProbe.copy()here had matching behavior.I came to this while reviewing PR #4465 in SpikeInterface and PR #420 here in probeinterface. In #4465,
ChannelsAggregationRecordingcallsp.copy()on each source probe to build a combinedProbeGroup, and becausecontact_idsare 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_arraywholesale, socontact_idsare preserved through a group-level copy.Probe.copy()andProbeGroup.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), andcontact_annotations.