search

scratcharchive / mountainsort_examples

Examples of using MountainSort spike sorting software.
27 stars 20 forks source link

Timestamps of some identified clusters do not align with peak of spikes. #6

Open linamnt opened 6 years ago

linamnt commented 6 years ago

In some of the identified clusters after running the whole pipeline, the timestamps for spikes do not represent the peak amplitude of the spikes, but seem shifted. This happens to all spikes within that cluster. See below where we plot a window 20 timepoints before and after the timestamp.

shifted-spikes

When we expanded the time window further back, we see that the timestamps do correspond to a real cell as shown below.

shifted-spike-resolved

Thanks in advance.

magland commented 6 years ago

I'm not exactly certain what you are asking. But let me ask you first, are the spikes expected to be positive or negative? and what are you using for detect_sign (or spike_sign) in the parameters?

linamnt commented 6 years ago

Hi @magland,

Thank you for your quick responses. I am wondering why the timestamp does not match with the actual peak of the spikes for some clusters? It seems to be consistent across a cluster I which this happens, as shown in the image, that the timestamp is actually delayed by a few milliseconds. The spike sign we use is 1 and mountainsort is able to correctly timestamp the peak of the spikes for other clusters identified in the same dataset. It is just one or two clusters that have this issue.

On Sat, Sep 15, 2018, 6:27 AM Jeremy Magland, notifications@github.com wrote:

I'm not exactly certain what you are asking. But let me ask you first, are the spikes expected to be positive or negative? and what are you using for detect_sign (or spike_sign) in the parameters?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/flatironinstitute/mountainsort_examples/issues/6#issuecomment-421550092, or mute the thread https://github.com/notifications/unsubscribe-auth/AKQ2vnYw8bIjaewBtX0V1TkWuNjaZF_0ks5ubNYWgaJpZM4Wp6FR .

magland commented 6 years ago

I am having trouble understanding the figures. Could you please describe in more detail. Why are there zeros?

linamnt commented 6 years ago

We use the Neuralynx set-up which returns a .ntt file with timestamps of potential spikes, and then stitched them together to make continuous file where the zeros are the padding around these spikes. In that case, should we be using the .ncs with just the channels x raw waveform information instead?

magland commented 6 years ago

Oh I see. I didn't realize you are using snippets, rather than continuous recording. In this case, you know the spike times... so ideally you should not need a detection stage for mountainsort. Somebody else was working on creating a simplified snippets version of mountainsort. How many channels do you have?

linamnt commented 6 years ago

We have 4 channels (it's a tetrode recording) Just to clarify, why do you think that the spike timestamps from the stitched .ntt are not accurate given the signal-to-noise in the stitched snippets should be much higher? Also, for now, can we use the .ncs (which is a single channel continuous file) and stitch the four channels together to use this pipeline?

Thanks!