coincident spikes in the same cluster

[christonifter]

Hello, I'm using Kilosort2 on recordings sampled at 24414 Hz, and I've been finding interspike intervals going down to 0 samples within each cluster. As a verification, I've been finding clusters containing multiple spikes with identical spike times. This is a problem because I'd like to isolate the activity of single neurons, and seeing ISIs below 1 ms (24 samples) makes it hard to believe the clusters are individual neurons. After lowering the AUCsplit parameter from 0.9 down to 0.2, I'm still seeing coincident spikes. I'm also interested in understanding how the spike extraction process might be finding the same cluster template twice at the same sample- would that happen if a spike waveform with twice the expected amplitude were found at that time?

To describe our data in better detail: we are recording spontaneous and sound-driven spikes in the inferior colliculus using 32channel iridium probes from Neuronexus (impedance: 0.2-1.5 MOhm). Single neuron spike rates can reach hundreds of Hz during responses to preferred stimuli. However, even when sorting spontaneous spikes, which should have low firing rates,, the sorting is returning clusters with coincident spikes.

[marius10p]

This is a known problem that should only happen very rarely. The ISI contamination measure ignore anything within a few samples of a spike. Some users get rid of near-simultaneous detections in post-processing.

This is an indirect consequence of the template matching step, that we have reduced over time, but may still happen occasionally. Whenever a single template is insufficient to account for a spike because the amplitude is too high, a second template is used to account for the residual.

[petersenpeter]

This is actually a very big problem with KiloSort when processing freely moving recordings, where you can have large noise artifacts coming from various sources (.e.g. animal scratches its head or head banging). As far as I can see, they directly decrease the performance of the sorting algorithm because templates are created to capture this variance and the same time, regular spike templates are contaminated by these events. Do you have any plans for implementing a penalty system for adding smaller templates onto very large templates?

[marius10p]

@petersenpeter I think what you are mentioning is different from the issue that @christonifter and others have more generally. It is true that artifacts will degrade the quality of the sorting, and if you can pre-process your data to minimize artifacts, you could probably get better results. There are already multiple penalty systems implicitly and explicitly for controlling the size of the templates, but they can still be insufficient when the artifacts dominate your data.

[petersenpeter]

OK. btw, this is also an issue with artifacts caused by optogenetical stimulation.

The only way I know to preprocess, that is compatible with the pipeline of Kilosort, is altering the dat file and I don't consider this an ideal solution. Because KiloSort is sensitive to this issue, I do feel that there is missing a way for the user to provide time intervals that can be excluded from the spike extraction. Is there a processing point to feed this information into the pipeline? And is there any chance this could become a built-in solution? I am saying this because we are very happy with KiloSort otherwise, but this issue is the biggest caveat with the algorithm from my perspective.

[marius10p]

In this case though, can't you just remove any spikes within the period of the artifact?

You can just make a copy of the dat file with your preprocessing.

Excluding time periods from sorting is not trivial, because I have to alter batch boundaries and batch overlaps, but I will see if I can fold that into the next round of updates.

[petersenpeter]

I see the issue with the batch boundaries.

We do remove the spikes post hoc, but the artifacts still deteriorate the quality of the sorting.

It is true that one could create a temporary copy of the dat file, but this is what we try to avoid as our data files are very large. Could this instead be achieved by altering the whitened dat file that already is being created by kiloSort? This way the batch script would not need to be altered.

[etrautmann]

Perhaps try applying ERAASR for more effective artifact removal first? https://www.ncbi.nlm.nih.gov/m/pubmed/29265009/

…

On Thu, Nov 7, 2019 at 5:29 PM Peter Petersen ***@***.***> wrote: I see the issue with the batch boundaries. We do remove the spikes post hoc, but the artifacts still deteriorate the quality of the sorting. It is true that one could create a temporary copy of the dat file, but this is what we try to avoid as our data files are very large. Could this instead be achieved by altering the whitened dat file that already is being created by kiloSort? This way the batch script would not need to be altered. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#126>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAF3QOAYUXAUDGZRQBP2M73QSSJDJANCNFSM4JBPNEQA> .

[marius10p]

Generally speaking, we let users preprocess their own artifacts, since they can vary a lot from prep to prep. You probably don't want to mess with the preprocessed kilosort file, since that contains batches, not a continuous sequence of time samples.