Skip to content
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

Fail to get some seemingly good quality units #190

Closed
RynzzZ opened this issue Feb 10, 2020 · 3 comments · Fixed by #595
Closed

Fail to get some seemingly good quality units #190

RynzzZ opened this issue Feb 10, 2020 · 3 comments · Fixed by #595

Comments

@RynzzZ
Copy link

RynzzZ commented Feb 10, 2020

Hi,

I've been using KS2 for spike soring with recordings in cerebellar nuclei for a while. Recently, we changed to a new probe (not sure if this is the cause) and ran into a new problem that I have never experienced before - missing/oversplit units that seem to have pretty good quality (at least by eye).

The probe we are using now is a neuronexus A4X16-poly2 probe, and for our recording purposes, we deliberately broke one shank, so now it's a A3X16-poly2 probe. The broken shank has been marked disconnected in the channel map and has been verified in KS2 GUI. We are doing acute recording in head-fixed mice locomoting on a wheel, so there is certain amount of short-term and long-term drifting.

As you can see in the figure below, there is a very good unit at channel 38. It was at channel 36 in the beginning, but drifted to channel 38 (22 is the OpenEphys channel num for the same channel) and remained relatively stable at channel 38 at least for the later half of the recording. But the spike sorting was never able to sort the majority of the spike into a single unit. After the sorting, there were always several units associated with this channel, and every sorted unit picked only a fraction of the spike, and the waveform looked wierd to me.

channels_200130_000

sortingResult_defaultSetting

After enlarging the trace view, using my own eyes, I cannot see obvious differences between the spikes that KS2 picked and not picked.

image

image

Based on what I saw, I tried to manipulate some parameters, thinking maybe that would help. I tried these things separately: (1) make KS2 biases on big amplitude units by increase the threshold to [20 8]. (2) since there was drifting, decrease the amplitude penalty lam to 3. (3) restrict the time range to only the later half of the recording. (4) increase the waveform variability within one template - momentum - to [50 400].

Basically, none of these parameter twicking improved the sorting effectively...The sorting results got even worse in most of the cases...

I was wondering what makes this unit so difficult to sort. One possible reason is that there is actually two neurons on that channel, with different waveforms, so that's why the template waveform looks so wierd. Another thought is that since the amplitude is very high, indicating the neuron was very close to the recording site, so maybe it was subjected to a higher variability in its waveform due to the brain movement/drifting, a tiny bit of drifts can shift the waveform a lot???...

BTW I've had KS2 working well with my other sessions, and it can effectively pick good units even with drifting. Here is another example, and use just default settings for all the parameters:

200131_000allUnits

All KS2 sorted spikes were marked with color. You can see that KS2 was able to pick channel 27 (even considered drifting!) but failed to catch channel 40.

It would be deeply appreciated if you can offer any advice! Big thanks in advance!!

Qianyun

@marius10p
Copy link
Contributor

hi Qianyun, can you please post a screenshot of the data in the GUI, where you can clearly see the same spikes on nearby channels? That is usually the best way to verify the configuration.

Also, please post the batch-to-batch similarity matrix. If there is an abrupt transition, that could explain some of the missing spikes you are seeing. For the neuron with the double waveform template, it's possible this is not the "main" template. Have you looked around for other templates on that channel?

@RynzzZ
Copy link
Author

RynzzZ commented Mar 1, 2020

hi Qianyun, can you please post a screenshot of the data in the GUI, where you can clearly see the same spikes on nearby channels? That is usually the best way to verify the configuration.

Also, please post the batch-to-batch similarity matrix. If there is an abrupt transition, that could explain some of the missing spikes you are seeing. For the neuron with the double waveform template, it's possible this is not the "main" template. Have you looked around for other templates on that channel?

Hi. Thanks a lot for getting back to me.
I didn't keep the figure when I ran the data and got the results I posted earlier, so I ran the data again, with default settings. I got a slightly different result, but the same problem persisted - KS only sorted a portion of the spikes into one unit, and missing other seemling also clean and big spikes.

KS_1
[waveform_highpass]

KS_2
[mean_waveform_highpass]

KS_Fig1
[batch-to-batch similarity matrix]

Here's what I got. As you requested, I include the probe view from the GUI to verify the probe configuration and the batch-to-batch similarity matrix. Does the batch-to-batch similarity view look bad from your perspective? I see missing spikes started to happen somewhere between 570s and 580s and persisted till the end of the recording. But I didn't see a very obvious abrupt transition around that time point (~batch 290 I assume).

The channel number order in the phy GUI is actually corresponding to the channel number associated with the .continuous file from OpenEphys, which is not very meaningful and intuitive, so here I attached another channel map for reference. The location of sites in this plot faithfully reflect the probe configuration and the channel number in the bracket is the channel number you saw in the phy GUI. The unit I had problems was on the third channel, so corresponding to the third column in the plot below. The shank number (in the bracket) and the layout in the phy GUI was the same as in the plot below.

BDFD2_ProbeMap

One sentence to conclude: I think there is no problem with probe maps and probe configuration.

Another issue with phy GUI is that recording sites are sorted by depth in the trace view, regardless of shankNum, so sites with similar depth (especially the same location but on a different shank) will get criss-crossed in the trace view. That's why in my previous post, the channels highlighted with blue color in the trace view are not located next to each other. To fix this problem, and for a better visualization in phy GUI. The channel map I used when I ran KS2 is actually the one I attached below:

BDFD2_ProbeMap_KS

This channel map keeps the recording site configuration within each shank, but falsely assign different depth to each shank, so nearby sites on the same shank will be clustered in the trace view by their unique depth and won't be interfered by sites on other shanks with similar depth. Also, I manually assign a larger shank separation distance to make sure that KS2 won't take sites from another shank into consideration. I assume this modification won't cause any problems since the site configuration within one shank isn't changed .

As for other templates on that channel, so far all I posted are the best(highest firing rate, most n_spikes) unit on that channel. Other units have dramaticly decreased firing rate and n_spikes compared to the best unit, so I think the unit I posted should be the "main" template on that channel.

However, I found that units on that channel have relatively higher ContamPct (6.3 and 7.1 for blue and red unit I showed below, other good units are usually below 5, best sorted units are below 1). Does this mean anything particularly or indicating bad quality of the sorting results for that unit in general?

KS_4

Big thanks in advance for helping me figuring this out! Looking forward to hearing from you!

Qianyun

@marius10p
Copy link
Contributor

Sorry for the long delay. I meant I wanted to see the whitened data in the Kilosort GUI (not the Phy GUI).

Based on what I see, your neurons are either small, or the channels are spaced relatively far apart. Each unit only shows up on one channel, which means that during drift, units may "fall" in-between channels, and then you cannot track them anymore.

However, this wouldn't explain why some seemingly good spikes are not picked. Have you checked whether they are picked by a different unit on those channels? It would be a very different problem if a unit got "over split" into multiple pieces vs some spikes just never got picked at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants