Question on computing spike location across kilosort versions

[JoeZiminski]

Hi Kilosort team, hope you are doing well. I am currently working to load kilosort spike outputs into SpikeInterface format, work in progress here. This includes computing the spike locations. I have a couple of questions to check my understanding and confirm the best way to approach this across kilosort versions, any help would be much appreciated.

Initially I based the approach on the spikes method, which calculates the center-of-mass using pc_features. Now I realise this is most relevant for KS1. To check my understanding: this is the 'private PCA' in which for each spike, PCA is performed directly on the spike waveform ($t \ \text{x} \ c$ matrix) is giving scores for projection onto $c$ principal components. The scores for the top 3 components are retained.

In all other kilosort versions, a template matching approach is used. Now template_features gives the projection of the spike waveform onto the most similar template (out of 6 possible in KS4). These are not from a PCA but computed as the magnitude of the projection of the spike onto the templates during the template matching step. template_features is (num spikes, num features) where features is a set of n channels (I think 32 in KS2/2.5, 10 in KS4). This array holds the magnitudes for each channel, when the waveform is projected onto the closet-matching template). For these versions, I guess it it makes more sense to use the centre of mass over the template_features, rather than pc_features?

A main reason I am clarifying is because for some spikes, all scores onto the first principal component are negative. If I understand correctly, depending on the method, the interpretation of this case changes. In the 'private PCA' context, this sign is arbitrary and the sign of the scores can be reversed for these spikes. However, in the template_features content, this means the waveform is in the opposite direction to the template, and should probably be excluded.

It would be great to check that I have understood the above correctly and can handle the estimation of spike location accordingly. Thanks!

[jacobpennington]

@marius10p can give a better explanation for the other versions, but just for reference you can look at kilosort.postprocessing.compute_spike_positions to see how KS4 handles this.

[jacobpennington]

Updating my previous comment with feedback from Marius: there is not going to be a consistent way to compute spike positions across versions since the algorithms are fundamentally different in many cases and have switched from matlab to python. We are no longer providing support for older versions of Kilosort, so our recommendation would be to look at how spike positions are computed for Kilosort4 (see my comment above) and try to recreate that with other sorting results if that's your goal. If you have questions about Kilosort4's spike position calculation, please let us know.

[JoeZiminski]

Hi @jacobpennington, thanks a lot for this that's much appreciated.

That sounds good, for KS1 I can use the approach from the spikes repository. For KS4 I can use this approach you linked, and for KS2-3 I'l try the approach used in standalone_detector.m here (checking for potential differences across versions). I'll dig in a little more, but if I understand correctly it seems all approaches >KS1 are using the average template position weighted by magnitude of spike projection onto templates.

I also see across versions negative PC scores are set to zero, so I'll stick with this approach across all versions, essentially excluding all-negative score case. Thanks for your help!