search

buzsakilab / buzcode

Code for internal lab sharing - polishing has started but is by no means complete
http://www.buzsakilab.com/
GNU General Public License v3.0
119 stars 128 forks source link

function bz_GetSpikes calling for shanks.npy #401

Closed eliezyer closed 3 years ago

eliezyer commented 3 years ago

I noticed that the function bz_GetSpikes in the dev branch requires shanks.npy (generated by Peter's plugin) for loading spikes from kilosort/phy files. In newer versions of kilosort and phy the shank information can be extracted by comparing channels in cluster_info.tsv with the xml. If no one is opposed / working on that, I can update the function to deal with the different versions of kilosort and the different files

brendonw1 commented 3 years ago

Good, we just saw this too actually So would you make it take both possible inputs? I think adding flexibility is always good and you don't have to ask. As long as you are adding options, but not breaking anything, then it's good

On Mon, Nov 16, 2020 at 8:03 AM Eliezyer notifications@github.com wrote:

I noticed that the function bz_GetSpikes in the dev branch requires shanks.npy (generated by Peter's plugin) for loading spikes from kilosort/phy files. In newer versions of kilosort and phy the shank information can be extracted by comparing channels in cluster_info.tsv with the xml. If no one is opposed / working on that, I can update the function to deal with the different versions of kilosort and the different files

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/401, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA26WTLFZSJUD3ST43EIQ2LSQEPL5ANCNFSM4TXENE4A .

eliezyer commented 3 years ago

Yes, I just changed so it first look for cluster_info.tsv file and if it doesn't exist it tries to load shanks.npy, so it should be compatible with both versions. I'll be submitting a pr soon. If I remember correctly, cluster_info.tsv was not available in kilosort 1, if someone has a session spike sorted with ks1 and can check that information that would be great. Also, it would be nice if we could get the updated bz_GetSpikes to be tested in a ks1 spike sorted session.

brendonw1 commented 3 years ago

Awesome

On Mon, Nov 16, 2020 at 10:15 AM Eliezyer notifications@github.com wrote:

Yes, I just changed so it first look for cluster_info.tsv file and if it doesn't exist it tries to load shanks.npy, so it should be compatible with both versions. I'll be submitting a pr soon. If I remember correctly, cluster_info.tsv was not available in kilosort 1, if someone has a session spike sorted with ks1 and can check that information that would be great. Also, it would be nice if we could get the updated bz_GetSpikes to be tested in a ks1 spike sorted session.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/401#issuecomment-728125769, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA26WTMUJPTVUPFAVQ54DLLSQE6Y5ANCNFSM4TXENE4A .

eliezyer commented 3 years ago

The part of the code that does the waveform extraction from the .dat file was using all the channels in order to find the max amplitude channel. This made the script return waveforms from dead channels since the noise was bigger than the unit amplitude. I updated the code to restrict the max amplitude channel finding only for the shank the unit belongs. It's on the same pull request (#402 ) as the fix to the previous issue