-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: <Large number of contaminated clusters in kilosort v4> #703
Comments
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. |
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 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? |
@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. |
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
The text was updated successfully, but these errors were encountered: