BUG: <Large number of contaminated clusters in kilosort v4>

[mikemanookin]

Describe the issue:

We are seeing a large number of contaminated clusters in kilosort v4 that are not present in v2.5. We would like to bias against merging and then we can merge with our own automated code after spike sorting; and it is much more difficult for us to deal with contaminated clusters than merging clusters. Is there a way to decrease the tendency to merge clusters as in previous versions of kilosort? Attached is an example electrical image from a kilosort4 cluster that clearly shows two distinct axons going across the array. The receptive field also shows two distinct regions arising from different cells.

Reproduce the bug:

No response

Error message:

No response

Version information:

Kilosort4, OS: Linux/Ubuntu 22.04; python v 3.9.

Context for the issue:

No response

Experiment information:

No response

[marius10p]

Is this a Neuropixels ultra or something like that? Given the high channel density, you likely will need to find a different parameter regime than the default. We don't have experience with this scenario yet, but if you send some data we can take a look and maybe give you some initial recommendations.

[mikemanookin]

Thank you, Marius! This is a rectangular MEA from UC Santa Cruz (60 um pitch). How would you like me to get the data to you? I really appreciate your help with this!

[mikemanookin]

If this helps, I calculated the projections of the PCA features and computed the bimodality score as in swarmsplitter.py. The bimodality score was 0.58, just low enough to pass the threshold, but the projections are clearly bimodal (see attached image).

I also found the very next cluster had a bimodality score of 0.69 and should have been kicked out or split, but made it through. Perhaps the t-statistic was what made that happen. Also, the projections look clearly bimodal...

[marius10p]

@mikemanookin I see, this is a larger spacing than I expected. Is this a common neuron in your recording or a special case?

I think this neuron is so different from our common assumptions that I have difficulty imagining how it was extracted at all. Our typical assumption is to divide the array into many non-overlapping patches, and cluster spikes from each patch separately. For this neuron, it probably would have meant that a lot of different portions were extracted in different blocks, and then a postprocessing step merged all of these back together. Have you been able to trace the origins of this neuron to those merging steps? How many parts were merged? The information you sent from the swarmsplitter step would all be happening inside a single block of channels, so I feel like there might be a disconnect between what happens inside that single block of channels, and all the other blocks where this neuron is likely detected.

Taking a step back, I think there would be multiple steps we would need to do to support the detection of neurons over so many channels. That work could be pooled together with work on Neuropixels Ultra, but it does not have high priority for us relative to other things we need to do. Perhaps it would be worth it for you to see what they did in the NP Ultra paper and see if you can use that approach?

[mikemanookin]

@marius10p Hi Marius. Yes, the issue for us is that many of the cells that we record will send their axons across the array in one or many directions (see attached electrical image from an example cell). I haven't followed this particular cell/cluster through the sorting process, but that is a good idea. I will do that when I get a chance.

Thank you for the tip to look at that paper. I am happy to share any insights/code that come out of this.