Missing spike events from large amplitude clusters

[jcbyts]

I'm finding that KiloSort is missing many of the largest spikes in my recordings. KiloSort will identify a cluster for the unit, but almost half of the spikes are missing and are not grouped as any cluster. This only seems to be happening with very large spikes.

Example cluster waveform:

Missed spikes that are unclassified:

More example unclassified large spikes

I've tried a number of different parameters and initialization 'fromData' none of it seems to make a difference. Any suggestions? Thanks in advance!

[nsteinme]

I think this likely happens for one of several reasons: 1) the spikes actually are highlighted, but in a color that's indistinguishable from grey (kwikteam/phy-contrib#125), and/or 2) they are having their color "overwritten" by a distant neuron (since the determination of which color appears on top is essentially random currently, kwikteam/phy-contrib#126), or 3) they are part of a cluster that has been labeled "noise", which then gets colored in nearly-grey.

To distinguish this, try "toggle highlighted spikes" in the traceview to make it only show you blue highlighting for the selected cluster. Then try selecting the cluster of the spikes in question by ctrl+right-click on the traceview near the spikes. You can test that this works to select clusters with some of the other highlighted spikes, then see whether you can select those spikes. Please follow the [very easy] instructions to upgrade to the "development version" of phy here, so we know we're working from the same code.

Another thing to look for - if you zoom in on individual spikes in traceview you will see two traces: the raw data and, behind it, the raw data after subtracting the template, i.e. the residual. If there is no residual trace behind those spikes (but you can indeed find it behind others) then we know there's a problem.

If you still think the spikes are just missed, could you clarify what you mean that different parameters didn't "make a difference" - was it the exact same spikes that are missed every time, or always spikes of that unit, or just that you can always find some spikes somewhere that appear missed?

[jcbyts]

Thanks for the quick response! Unfortunately, it doesn't seem to be a visualization problem. Here is a zoomed in plot showing that the gray spikes only have one trace. They do not seem to be assigned to any cluster (including noise clusters). I've also confirmed in matlab that these times are not assigned to any cluster.

If you still think the spikes are just missed, could you clarify what you mean that different parameters didn't "make a difference" - was it the exact same spikes that are missed every time, or always spikes of that unit, or just that you can always find some spikes somewhere that appear

Yes, that was vague. I mean this unit consistently produces this problem where a large fraction of spikes are missing. I can't say that it's the same spike times that are missed because I've pretty naively modified parameters, re-run, then re-visualized, and haven't compared the outcome quantitatively.

When I say "consistently" I mean across parameters and sessions. The recordings are chronic from a 32 channel silicone probe and this unit is present on every session (we've been recording for about three weeks now). Whether I sort the individual sessions or concatenate, this unit is missing spikes. There are other spikes that appear missed, but that happens infrequently. The striking thing about this unit is that a large portion of spike times are missed, even though it has a very clear spike template.

Below are the parameters I have been changing. I've started with the default config file from the KiloSort repo. I haven't explored the parameters very intelligently and was hoping you might have some suggestions.

I've tried lowering ops.Th and I've tried a range of ops.lam
I've tried initializing 'fromData' , with a range of ops.spkTh and I've tried increasing ops.maxFR
KiloSort seems incredibly robust to any of those.

Thanks again. Hopefully, there's something dumb I'm missing!

[nsteinme]

Is it possible to send a dataset, along with the config file and results of kilosort?

…

On Mon, Aug 14, 2017 at 2:35 PM, Jacob ***@***.***> wrote: Thanks for the quick response! Unfortunately, it doesn't seem to be a visualization problem. Here is a zoomed in plot showing that the gray spikes only have one trace. They do not seem to be assigned to any cluster (including noise clusters). I've also confirmed in matlab that these times are not assigned to any cluster. [image: image] <https://user-images.githubusercontent.com/1760049/29272344-98da361a-80cd-11e7-9380-06399b6c225b.png> If you still think the spikes are just missed, could you clarify what you mean that different parameters didn't "make a difference" - was it the exact same spikes that are missed every time, or always spikes of that unit, or just that you can always find some spikes somewhere that appear Yes, that was vague. I mean this unit consistently produces this problem where a large fraction of spikes are missing. I can't say that it's the same spike times that are missed because I've pretty naively modified parameters, re-run, then re-visualized, and haven't compared the outcome quantitatively. When I say "consistently" I mean across parameters and sessions. The recordings are chronic from a 32 channel silicone probe and this unit is present on every session (we've been recording for about three weeks now). Whether I sort the individual sessions or concatenate, this unit is missing spikes. There are other spikes that appear missed, but that happens infrequently. The striking thing about this unit is that a large portion of spike times are missed, even though it has a very clear spike template. Below are the parameters I have been changing. I've started with the default config file from the KiloSort repo. I haven't explored the parameters very intelligently and was hoping you might have some suggestions. I've tried lowering ops.Th and I've tried a range of ops.lam I've tried initializing 'fromData' , with a range of ops.spkTh and I've tried increasing ops.maxFR KiloSort seems incredibly robust to any of those. Thanks again. Hopefully, there's something dumb I'm missing! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#84 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHPUPxTrpCUX6LT79UxXJH3cbNhv4wvbks5sYE0qgaJpZM4O1ybG> .

[jcbyts]

Yes. I'll package up a dataset and email you a link to download it later today. Thanks!

[jcbyts]

Okay. I got to the bottom of it and it is indeed something dumb! The spike from this unit is big enough that when it co-occurs with other events on the probe, it triggers my artifact detection thresholds that were tuned to earlier recordings. Thanks for your help, and sorry for wasting time!

[cindyhfls]

@jcbyts
Hi! I think I have had the same issue. Can you tell me how you solved it? What was the final parameters you used?