Closed michaelaloft closed 6 years ago
Hi, I think everything should work fine. Usually the default parameters work fine regardless of the number of channels. Other things are more important, like SNR or channel density, but within a reasonable range the default parameters should work.
I would recommend processing both shanks together anyway, particularly if the raw data file contains all channels. This way noise clusters can be shared between probes, and it is also easier to deal with the results in the Phy GUI, since you only have one file with all the clusters to load and manipulate. To do this, make sure you make your own customized channel map file, and give the shanks different labels ("kcoords"). That ensures that no clusters will be shared between them.
For 32 channels, try 128 clusters first. If it looks overclustered, try 64. For too many clusters, Kilosort will keep finding smaller spikes, unclusterable etc. but it will also start oversplitting clusters, particularly if a recording has drift.
To do this, make sure you make your own customized channel map file, and give the shanks different labels ("kcoords"). That ensures that no clusters will be shared between them.
There is a one thing that I don't understand with the kcoords. We use 4 x 8 probes and I have grouped each shank (shanks are 200µm apart), but I still get spikes from neighbouring shanks (seen in Phys WaveformView) for most of the clusters. Is this how it should work, or should kcoords totally isolate shanks from each other? Not sure if I understood all correctly.
Here is my current config for the channel map:
function make_buzsakiProbe4x8ChannelMap(fpath) % Makes channel map for Buzsaki probe 4x8 ( ATLAS Neuroengineering E32B-20-S4-L10-200). % Mapping is made for ordered channels.
chanMap = [1 2 3 4 5 6 7 8 ... 9 10 11 12 13 14 15 16 ... 17 18 19 20 21 22 23 24 ... 25 26 27 28 29 30 31 32 ];
connected = true(32, 1);
xcoords = [0 -13 13 -20 20 -27 27 -34 ... 200 187 213 180 220 173 227 166 ... 400 387 413 380 420 373 427 366 ... 600 587 613 580 620 573 627 566];
ycoords = [0 20 40 60 80 100 120 140 ... 0 20 40 60 80 100 120 140 ... 0 20 40 60 80 100 120 140 ... 0 20 40 60 80 100 120 140];
ycoords = -ycoords;
kcoords = [1 1 1 1 1 1 1 1 ... 2 2 2 2 2 2 2 2 ... 3 3 3 3 3 3 3 3 ... 4 4 4 4 4 4 4 4];
% Saving save(fullfile(fpath, 'chanMap.mat'), 'chanMap', 'connected', 'xcoords', 'ycoords', 'kcoords')
can we get a response? how does kcoords exactly work?
That's just a display effect in Phy, where it has to plot blue at least N nearest channels. You can change that parameter N in the nearest channel PCs in the configuration, but it's purely a visual change, and has no effect on the actual sorting.
kcoords is just a visual effect? so it does not make sure that kilosort treats tetrode groups separately as stated in the createChanMap? or is the fact that channels are coloured together a visual effect? shouldnt this be labeled a bug?
No, the other way around: kcoords is real, and in your screenshot it successfully restricted the sorting to channels 24-31. But channels 16-23 got colored blue in phy anyway, since phy will color 16 channels blue by default. The blue is the visual effect but kcoords is real and should have worked - if you have other evidence that the sorting itself didn't work, please let us know (try viewing the template with 'w' and see whether it is not flat on channels from the other shanks). You could also post an issue on phy's github asking for easier control of the blue coloration if you like. Closing this issue for now but feel free to re-open if we didn't get it.
Hi, I have set up Kilosort 2 with a 4*8 silicon probe. How can I change the default in Phy from 16 to 8 coloured channels? I understand its just a visual effect but it is sometimes making it confusing to understand what spike belongs to which cluster in trace view. Thanks! Zoe
Hi Zoe, not sure whether this is still relevant for you, but it is possible to change the default by installing this plugin: https://phy.readthedocs.io/en/latest/plugins/#changing-the-number-of-spikes-in-views The value of controller.model.n_closest_channels corresponds to the number of highlighted channels (in TraceView, ProbeView and WaveformView).
Hello, I solved the issue already, but thank-you for providing an alternative solution!
On Fri, Mar 6, 2020 at 1:41 PM hana777 notifications@github.com wrote:
Hi Zoe, not sure whether this is still relevant for you, but it is possible to change the default by installing this plugin:
https://phy.readthedocs.io/en/latest/plugins/#changing-the-number-of-spikes-in-views The value of controller.model.n_closest_channels corresponds to the number of highlighted channels (in TraceView, ProbeView and WaveformView).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cortex-lab/KiloSort/issues/60?email_source=notifications&email_token=AMB6AJ675XMACRDWWPB4GOLRGD4QJA5CNFSM4DFS6LI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOBMITY#issuecomment-595772495, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMB6AJYFCXY4JUB6SBQ7ZJLRGD4QJANCNFSM4DFS6LIQ .
I'm using a 32 (2 x16) channel probe with parallel sites (~25um apart). The two shanks are 250um apart so I want to sort them separately. Can anyone recommend the best parameters for the standard config file? In particular I'm curious about ops.Nfilt - in the version of the code that I have there's a comment next to it which says:
% number of clusters to use (2-4 times more than Nchan, should be a multiple of 32). Is the fact that I've only got 16 channels going to be a problem here?
Are there any other parameters I should particularly careful about given my relatively low number of recording sites?