Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

channel numbers are not corrected after removal of bad channels #26

Closed
Sepidak opened this issue Mar 12, 2019 · 13 comments · Fixed by #595
Closed

channel numbers are not corrected after removal of bad channels #26

Sepidak opened this issue Mar 12, 2019 · 13 comments · Fixed by #595

Comments

@Sepidak
Copy link

Sepidak commented Mar 12, 2019

Once kilosort2 removes bad channels, the channel ID (number) of consecutive channels changes. For instance, if there is a cluster which has its max spike amplitude on channel 100, and kilosort2 has removed channels 10-20 as bad channels, now it appears as if this cluster is closest to channel 90. I can force kilosort2 to use all channels as suggested before but would be nice to use this option and still be able to get the correct channel number at the end.

@marius10p
Copy link
Contributor

I think the channel number is decided by Phy, which takes them consecutively from the channel map of connected channels. When KS2 sets a channel as bad, it just sets connected to 0.

@rossant, do you think Phy could show the original channel number?

@Sepidak
Copy link
Author

Sepidak commented Mar 12, 2019

Thank you for your quick reply Marius. Yes, that makes sense. Channel depths are shown correctly though, so should be possible to include the correct channel numbers in Phy too.

@rossant
Copy link
Contributor

rossant commented Mar 13, 2019

I think phy already shows the channel numbers that appear in channel_map.npy

@marius10p
Copy link
Contributor

I don't think so, I just looked.

@nsteinme
Copy link
Collaborator

channel_map refers to the rows of the data file, and this doesn't necessarily correspond to anything the user cares about. Perhaps we should make this more clear by introducing a "channel_numbers.npy" or "channel_names.npy"? The labels in phy would be taken from this new file, though the channel_map would still be used as it currently is to read the file.

@rossant
Copy link
Contributor

rossant commented Mar 13, 2019

are you saying that the requested information is currently not saved anywhere?

@marius10p
Copy link
Contributor

but the GUI doesn't actually show the channel map numbers from channel_map.npy.

@rossant
Copy link
Contributor

rossant commented Mar 13, 2019

Right, the raw data file is swapped according to channel_map, and the displayed channels are just 0..nchannels-1. If you want different channel labels you need another channel_names.tsv (could be names also, I guess?)

@marius10p
Copy link
Contributor

Ok, I can output that from Kilosort2. How is the tsv file formatted? I tried a few things that gave an error:

phy template-gui params.py
14:43:38 [E] cli:36 An error has occurred (ValueError): axes don't match array

@rossant
Copy link
Contributor

rossant commented Mar 13, 2019

I think this should work (where \t is a tab character)

cluster_id\tchannel_name
0\tmychannelname
...

but the logic to display this is not yet implemented in phy

@marius10p
Copy link
Contributor

Thanks Cyrille. I think the defaults for channel number should be the ones from the channel map file, because those are the actual, original channels in the data file.

If you don't think it should be that way, I can open an issue in Phy to add arbitrary user-defined labels, and then output the correct channel numbers from Kilosort itself.

@rossant
Copy link
Contributor

rossant commented Mar 13, 2019

Thanks Cyrille. I think the defaults for channel number should be the ones from the channel map file, because those are the actual, original channels in the data file.

sounds good!

@xy103
Copy link

xy103 commented Feb 15, 2022

Hi I was seeing this exact issue on my data, where the best channel based on template and raw waveforms don't match up. For context, I'm running kilosort 2.5 wrapped through ecephys pipeline, and visualizing results in phy2. This error occurs especially obviously in sessions some noisy channels were extracted before running kilosort.

I've tracked down the issue to channel_map.npy too. Currently this channel map saves chanMap0ind = int32([1:rez.ops.Nchan]-1); regardless of channel connectivity situation in rezToPhy.m. And immediately before this line chanMap0ind = int32(chanMap0ind); was commented out. I saw that if I rewrite channel_map.npy with results from chanMap0ind = int32(chanMap0ind); I get the correct channel mappings displayed in phy. @marius10p Was there any particular reason that chanMap0ind = int32(chanMap0ind); was commented out in the first place?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants