Project 6

[samuelgarcia]

Hi Andre,
we met in Edimburgh meeting in June.

I plan this autum (if I have time) to make a sorter comparison (your project 6) with our spikeinterface package.

Are you aware of any initiative on this task ?

Cheers,

Samuel Garcia

[andrefmsmith]

Hi Samuel! Very nice meeting you in Edinburgh this summer, and great hearing from you. Apart from SpikeForest I know of no other initiative. Kampff lab has 2 datasets used on SpikeForest (https://spikeforest.flatironinstitute.org/studyresults/paired_kampff), the recordings that start with ‘c’ (‘c14’, ‘c16’ etc) are from my dataset (the one referred to in sc.io). Let me know if you have any questions and many thanks for your interest! andre

…

On 10 Sep 2019, 10:00 +0100, Garcia Samuel ***@***.***>, wrote: Hi Andre, we met in Edimburgh meeting in June. I plan this autum (if I have time) to make a sorter comparison (your project 6) with our spikeinterface package. Are you aware of any initiative on this task ? Cheers, Samuel Garcia — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[samuelgarcia]

Thank for your answer.
I did not realised that theses dataset was from this neuropixel.
The channel count is only 32ch in spikeforest.
I think that they selected only some channels.
I will try to do the same with all channels.

[samuelgarcia]

Hi Andre.
I am back here.
The acquisition sampling rate (30kHz) is not mention on the README.
I found it the some code in sub folders. You should mention it.

Another quick question to be sure:
to get the ground truth spike indexes I need:

• to take the spike index from 'c16_wc_spike_samples.npy' there are at 50khz
• and then align them to the 30kHz signal. with the m factor m = len(patch_recording)/float( len(npx_recording[0]))

[samuelgarcia]

I have discoverd that the spike index you give can be have a bias.
Theses are in file "c16_wc_spike_samples.npy" for instance.

I can obser some double peak detection in some case.
This can impact accuracy measurement in spikeforest I think.
Look at this for instance:

I propose to make a script for a better peak detection on patch trace and send you theses corected index.

[samuelgarcia]

I wrote this small peak detection for the patch signal. I believe it is a bit more clearner.

def detect_peak_on_patch_sig(patch_sig, sample_rate):
    # filter because some traces have drift
    sos = scipy.signal.iirfilter(5, 200./sample_rate*2, analog=False, btype = 'highpass', ftype = 'butter', output = 'sos')
    patch_sig_f = scipy.signal.sosfiltfilt(sos, patch_sig, axis=0)
    
    med = np.median(patch_sig_f)
    mad = np.median(np.abs(patch_sig_f-med))*1.4826
    thresh = med - 12 * mad
    
    # 1 ms aounrd peak
    d = int(sample_rate * 0.001)
    spike_indexes, prop = scipy.signal.find_peaks(-patch_sig_f, height=-thresh, distance=d)

    #~ fig, ax = plt.subplots()
    #~ ax.plot(patch_sig_f)
    #~ ax.axhline(thresh)
    #~ ax.plot(spike_indexes, patch_sig_f[spike_indexes], ls='None', marker='o')
    #~ plt.show()
    
    return spike_indexes

I can compare the indexe you give in the repo vs ones freshly dected by this functions:
I get this

c14
gt_spike_indexes_patch recomputed 5583
gt_spike_indexes_patch_from_repo 5428
c26
gt_spike_indexes_patch recomputed 7045
gt_spike_indexes_patch_from_repo 6942
c28
gt_spike_indexes_patch recomputed 2332
gt_spike_indexes_patch_from_repo 2333
c37
gt_spike_indexes_patch recomputed 597
gt_spike_indexes_patch_from_repo 601
c45
gt_spike_indexes_patch recomputed 6754
gt_spike_indexes_patch_from_repo 6743
c46
gt_spike_indexes_patch recomputed 6823
gt_spike_indexes_patch_from_repo 6803

As you can see, the differences is marginal except for c14 and c26 where there is a 2% of diference. In spikeforest, this 2% diferences can be moe than the accuracy differences between some sorters. I think it should be corrected.

[andrefmsmith]

Hi Samuel, many thanks for your input and for defining the new function. I have updated the readme to add the neuropixel sampling rate and clarify the patch rate was 50.023 kHz. I have also clarified an issue which may have gone under the radar. If you look at the data summary (https://github.com/kampff-lab/sc.io/blob/master/Paired%20Recordings/Preprint%20Code/Data%20Summary.xlsx), particularly the last column on that spreadsheet, you can see there was a very small variation in sampling rate from cell to cell. For that reason the conversion factor between the two signals is specific for each patch clamp recording.

I wonder if this was the reason for the discrepancy in the cells you mentioned.

[andrefmsmith]

Thanks again Samuel - just adding a note that I took down the npy arrays detailing extracellular spike times to be safe. I added a readme in their folder linking to your post here with the function, to prevent people running into the issue of inaccurate spike times in the cells you mentioned.