Channel ids of concatenated recordings

[LeMuellerGuy]

Hey there,

I found your repository while looking though some issues in the spikeinterface repo and have found it to be very nice and understandable. Since I am working on a similar problem I was wondering if you have considered what happens to the channel ids/ electrodes when concatenating multiple recording segments. As far as I understand you record multiple configurations on the Maxwell systems and then concatenate them based on the common electrodes. This is so far the same that I have done, however I came to realize today that this may not be ideal since the routing of the electrodes may change to a different channel in between configurations (see attached image) and I have not yet found a good way of dealing with this issue through spikeinterface. Is this not an issue for you because you configured the Maxwell System to have constant routing for the common electrodes? I tried to sort of map the renamed channel ids to reflect the changing associations but spikeinterface doesn't seem to like that so currently I'm thinking that I'm either missing something completely or that I have to manually get the traces and write to a sort of binary file in the right order.

[hornauerp]

Hi! Thanks for your interest, I didn't really expect anyone to stumble across this repo.

I feel like what you are describing is what I am doing in the spike_sorting.get_common_electrodes and spike_sorting.concatenate_recording_slices functions. In short, I iterate over all recording slices/segments, call the spikeinterface function rec.get_property("contact_vector")["electrode"], and look for intersections across all recordings. Then, I iterate over all recording slices again, identify the channel IDs that correspond to the common electrode IDs through rec.get_property("contact_vector")['device_channel_indices'], extract the signal from those IDs and concatenate the channel_slice_recordings.

Let me know if that helps or if you have any further questions.

[LeMuellerGuy]

Yeah I saw that and while my function works a little bit different, I confirmed that they are equal in result. However, I think this doesn't really solve the problem that I was referring to.

Consider this example I grabbed from my project, where I queried all recorded configurations for the recording channel used for the common electrodes (in this case electrode 224). The table shows that for the most part, this electrode was recorded using output channel 400 (and some electrodes even use the same channel all the time) but there are apparently also a few instances where this is not the case. The channel position refers to index in the list of channel ids. I then sliced the recordings to only contain the common electrodes, renamed the channel to just 1 to 200. As you can see the sliced channels are a mess but at least the position and the channel ids are now the same.

But the real problem, is that the concatenate_recording function, concatenates the recordings by their channel ID and not by their electrode ID. So this means that for this specific electrode you will most likely end up with recordings from a bunch of different channels that are likely not from the same electrode. I checked this by going through the call stack when retrieving the traces and in the case of electrode 224, the retrieved traces for the first 3 segments were at position 382, 383, and 373, meaning that it got channel 400 on the first one, then channel 395 instead of 400 and when it should have retrieved channel 504, it retrieved channel 389 because of the channel id distortion.

And while I am strictly speaking not working with the contact vector but rather the channel ids/ electrode mapping that I pulled from the h5 file, I also confirmed that these results are consistent when you use the indices provided by the contact_vector.

[LeMuellerGuy]

I'm realizing that this really isn't a problem that you can solve, I am just wondering if you happen to have a solution in mind or know if I am totally missing something here Edit: I wonder if it is actually the same problem as https://github.com/SpikeInterface/spikeinterface/issues/1691 that you opened a while back that I just found

[LeMuellerGuy]

Okay Update 3: I went back and rechecked all of my code and it turns out that I had a massive bug in the electrode to channel conversion. I fixed it and it seems to be working now. Your code provided very helpful inspirations. Thanks a lot.