Multisegment sorting: combining sorting results

[JulienBrn]

Hi,

We are considering having huge recordings (maybe like 24h), but we would like to not save the whole 24h for space reasons. We can compute "relevant" portions of this 24h recordings (using animal behavior information) that may total to 2h. We would like to store each of these portions as different segments, but most current sorting algorithms do not handle multisegment sorting.

Of course, we could also first sort the full recording and keep the results of the sorting, and only then remove the useless segments. However:

• Sorting will take much longer than the individual sorting of the segments.
• Should we need to spikesort again for whatever reason, the current spikesorting is not reproducible.

It may be a hard task, but is there current work in progress an algorithm that given the spikesorting results of multiple segments and perhaps the segments themselves returns a common spikesorting for all the segments (matches the neurons from one segment with the neurons of the other segments) ? If such an algorithm would need features of what happens between the segments (multiunit activity as 1kz, ...) that could be possible for us, though it would diminish its generality.

Of course, this would be a hard task and maybe not entirely in the scope of spikeinterface, so my main question is whether there is current work in progress for such an algorithm. If so in an external library, could we consider wrapping it ?

[chrishalcrow]

Hello, in our lab the basic experiment contains several shorter recordings that are taken at different times in a day (although, all within 2 hours or so). So I imagine our recordings are similar to your “relevant” recording portions.

Our workflow is: concatenate the shorter recordings together (using concatenate_recordings) and sort the entire concatenated recording at once. This ensures that neurons are identified across recordings. I think you would slice out the shorter 2 hour recordings using recording.frame_slice and then re-concatenate the slices into a recording. Note: it's handy to save the lengths of the individual recordings as an annotation of the concatenated recording! The sorting works if the recording is stable (ours is chronic, which helps). We then give the SortingAnalyzer the full concatenated recording and the full sorting. If we want something like the spike trains for one of the portions, we split the sorting using sorting.frame_slice(). You can give the SortingAnalyzer a segmented recording and sorting, but we've not played with this yet.

We have experimented with sorting each portion separately then matching using UnitMatch (https://github.com/EnnyvanBeest/UnitMatch) or https://elifesciences.org/articles/92495 but so far we’re more confident with the results of sorting everything together.

[samuelgarcia]

@chrishalcrow
Give the segmented version to the SortingAnalyzer would be the recommandation because an analyzer segment aware is convinient for many operation : viewer, fecthing part only, ...

[JulienBrn]

The option of sorting the different segments as the single segment representing the concatenation of all those segments is interesting, though I'd assume the sorting results to not be as good : for example, if a neuron drifts during the the time in between segments, the sorting will probably consider it as two different neurons. Furthermore, this requires spikesorting the whole concatenated segments together which is much less scalable than sorting each individual segment and then matching neurons.

However, if this is the way to do it, as spikeinterface already creates a copy of the recording in run_from_folder, it could handle have an option to handle multisegments: in run_from_folder, simply concatenate the segments into a single recording, then run the sorter, finally parse the sorter output and split it according to each segment. This could be an option named multisegment_handling with possible values None (directly passed to sorter), "concatenate", "separate" (sort each segment separately) and some other possible values in the future.

This change could be added with the save_sorting option of issue #3901.

[samuelgarcia]

@JulienBrn : yes if you have a drift between segment you can apply a correct_motion() which is a heavy operation but this should take care of this.

About magic concatenation in the run_sorter() I think it is better to be explicit outside this fonction to handle segment and concatenation.

[JulienBrn]

@JulienBrn : yes if you have a drift between segment you can apply a correct_motion() which is a heavy operation but this should take care of this.

So if correct motion is applied, it is reasonable to assume that the sorting of the concatenation of segments (setting the time passed between segments to 0) would give good results?

About magic concatenation in the run_sorter() I think it is better to be explicit outside this fonction to handle segment and concatenation.

If the latter is true, adding a parameter like handle_multisegment with default value "forbid" that could take the value "concatenate" feels explicit enough while being easily usable.