search

cortex-lab / KiloSort

GPU code for spike sorting
GNU General Public License v2.0
175 stars 100 forks source link

Choosing Parameters for Slower Spikes #186

Open corticodes opened 5 years ago

corticodes commented 5 years ago

Hello, I am trying to use KiloSort2 to sort data which came from recordings of a turtle brain. I think that the spikes are a little slower then the spikes that are usually being sorted by the algorithm. When I try using the GUI, it seems that in the filtered data the spikes are being highly attenuated, and looking in the prediction data it seems to miss them altogether (print-screens attached).

I have tried changing the ops.fshigh parameter in configFile384.m to 50 (instead of 150) and it seemed to help a little (I could only see that change in the GUI after doing the spike sorting), but still the predicted data misses spikes (and anyway they are still attenuated).

Is this the right way to go? And if so, what other parameters do you think I should try to play with?

Thanks for your help!

gui before sorting - filter gui before sorting - prediction gui before sorting - raw gui before sorting - raw+filter

nsteinme commented 5 years ago

Very cool data. Marius may have to advise about parameters, though it looks like you're oversampling so significantly in time that you could get away with downsampling to make it look more like a normal-speed recording to KS. Also, the 'filtering' step does both filtering and spatial whitening so that will also account for some of the shrinking of the waveforms.

Re: prediction, that will be flat until you run the algorithm (which you hadn't done yet at least in the screenshots you're showing).

On Mon, Apr 1, 2019 at 12:24 AM corticodes notifications@github.com wrote:

Hello, I am trying to use KiloSort2 to sort data which came from recordings of a turtle brain. I think that the spikes are a little slower then the spikes that are usually being sorted by the algorithm. When I try using the GUI, it seems that in the filtered data the spikes are being highly attenuated, and looking in the prediction data it seems to miss them altogether (print-screens attached).

I have tried changing the ops.fshigh parameter in configFile384.m to 50 (instead of 150) and it seemed to help a little (I could only see that change in the GUI after doing the spike sorting), but still the predicted data misses spikes (and anyway they are still attenuated).

Is this the right way to go? And if so, what other parameters do you think I should try to play with?

Thanks for your help!

[image: gui before sorting - filter] https://user-images.githubusercontent.com/46958640/55309897-c4b3e780-5467-11e9-9498-88fda7ce41c2.PNG [image: gui before sorting - prediction] https://user-images.githubusercontent.com/46958640/55309899-c4b3e780-5467-11e9-8f9d-85e6daebd68d.PNG [image: gui before sorting - raw] https://user-images.githubusercontent.com/46958640/55309901-c4b3e780-5467-11e9-9c6b-d871160cabae.PNG [image: gui before sorting - raw+filter] https://user-images.githubusercontent.com/46958640/55309902-c4b3e780-5467-11e9-8a52-da34ce566baf.PNG

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cortex-lab/KiloSort/issues/186, or mute the thread https://github.com/notifications/unsubscribe-auth/AHPUP8J_s4-V6xQpGRhm2t1Y5m7MMy1Aks5vcbQwgaJpZM4cVBsI .

corticodes commented 5 years ago

Thanks for your response! Are you suggesting that we're oversampling because of the sampling rate in the screenshots? Because actually the sampling frequency was 20kHz (I guess I was a bit hasty in taking these screenshots, but these results are what we get also after defining 20kHz. Sorry for the confusion!). So downsampling would be problematic, and I think playing with the parameters might be more suitable? As for the prediction - you're right, it does appear after I run the kilosort. Thanks!

marius10p commented 5 years ago

Nick meant that you're over sampling relative to the duration of the spike. The easiest thing might be to bin your data so that trough to peak is about 10 samples, like a cortical spike recorded at 30khz.

The filtered data is indeed supposed to look like that, but if you're missing spikes that could be because they're too long. Check out ops.wPCA after sorting and post them here to give us a sense of your spikes duration and how they fit in the sliding window size of Kilosort2.

WeissShahaf commented 5 years ago

i'm having similar problems with slow spikes being only partially detected is there a way to change the window size in kilosort2? ops.wPCA examples attached

wPCA.zip wPCA2.zip