combine_probes lose 'device_channel_indices' #431

Activity

1. chiyu1203

   changed the title [-]combine_probes[/-] [+]combine_probes lose 'device_channel_indices'[/+] on Apr 25, 2026
2. h-mayorquin commented on May 22, 2026

   

   h-mayorquin

   on May 22, 2026

   Collaborator

   More actions

   Sorry for the long wait for an answer. We are in the middle of a discussion on how to handle this. See SpikeInterface #4553, SpikeInterface #4397, and probeinterface #420.

   The direct solution to your problem is to set the device channels at the ProbeGroup level.

   multi = combine_probes([shank0, shank1])
   combined = np.concatenate([shank0.device_channel_indices, shank1.device_channel_indices])
   multi.set_device_channel_indices(combined)

   The main problem is that device_channel_indices at the probe level are meant to be a local reference. They attempt to match an internal index of the probe data with the internal index of the would-be trace of a recording. They are meant to be properties of probes attached recordings, so the semantics for stand-alone probes are not clear and are riddled with ambiguities such as:

   • A standalone probe has no recording attached, so device_channel_indices = [0..N-1] could mean "channels 0..N-1 of the recording it will be attached to" or "channels 0..N-1 of the recording it was loaded from." Nothing on the probe distinguishes them.
   • Two probes each carrying [0..N-1] can be two shanks of one recording (need offsetting before combining) or two probes from two separate recordings (should not be combined at the probeinterface level at all). The arrays look identical.
   • Probe.copy() drops device_channel_indices, combine_probes() drops them, but readers like read_spikeglx() set them. The field is treated as half probe-state, half recording-state across the API.

   Setting them at the ProbeGroup level then is clean intent as you are stating that you know the index of the traces that would be assigned.

   Be aware that if you are using SpikeInterface at recording time it will modify the information that you set (see SpikeInterface #4565), so there is no surprise. This still keeps the right mapping but does an internal reorder.

   Tagging the other developers as they might have a different opinion than mine, and that is important: @alejoe91 @samuelgarcia @chrishalcrow