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

Limiting spikes to single shank & non-standard channel maps #826

Open
JazlynnXM-Tan opened this issue Dec 4, 2024 · 5 comments
Open

Limiting spikes to single shank & non-standard channel maps #826

JazlynnXM-Tan opened this issue Dec 4, 2024 · 5 comments
Assignees

Comments

@JazlynnXM-Tan
Copy link

Describe the issue:

Hi, I am using Neuropixel 2.0 with 4 shanks and a non-standard channel map - the channels were chosen in this manner via survey mode in spikeglx. The full recording was then acquired using openephys. When loading into the GUI, the probe layout looks correct. The probe layout information also has the kcoords details which also appear in the kilosort log file afterwards. However, the spikes and units do not seem to be limited to single shanks in the spike_positions plot (see the 'smearing' between shanks).

Screenshot from 2024-12-04 12-05-59
spike_positions

From the documentation, I understand that dmin and dminx parameters need to be changed according to the channel map. I tried increasing dminx to 250 (the distance between shanks) while leaving dmin as None since the channels are not spaced evenly in depth. This resulted in poor spike detection. I tried a range of other dminx values, but either the smearing persisted or the spike yield was badly affected.

With dminx=250:
spike_positions

With dminx=70:
spike_positions

I then used the same kilosort installation with spikeinterface run_sorter_by_property where the spikes were sorted shank by shank. This resolved the smearing issue and still retained high yield, leading me to wonder if the kcoords are not effectively limited the spike sorting to single shanks?

A section of the probe (0-1000um at the tip) with the units detected plotted:
image

My questions:

  1. For non-standard, unevenly spaced, multi-shank channel maps, how do I set dmin and dminx values?
  2. Is there a specific requirement for the kcoords information in the probe map so that kilosort can limit the sorting to single shanks?

Thank you!

Here are the channel map file and logfile:
ks4_channelmap_JT.json
kilosort4.log

Reproduce the bug:

No response

Error message:

No response

Version information:

Kilosort : 4.0.20
Spikeinterface: 0.101.2

@jacobpennington
Copy link
Collaborator

@JazlynnXM-Tan Can you please check the boxes for "universal templates" and "grouping centers" in the GUI, underneath the probe preview, and upload a screenshot of what that looks like? If the image looks too cluttered to see much, you can drag the handle to the right of the probe preview to expand that part of the GUI.

@JazlynnXM-Tan
Copy link
Author

JazlynnXM-Tan commented Dec 6, 2024

Ok sure. I'm also attaching the channel map I used if that is helpful:
ks4_channelmap_JT.json

Screenshot from 2024-12-06 13-41-52

@JazlynnXM-Tan
Copy link
Author

I played around with using probeinterface to generate the channel map and got a different set of universal templates/grouping centers, but the 'smearing' still persists:
mouse28_siprobe.json
Screenshot from 2024-12-06 14-04-04

spike_positions

@jacobpennington
Copy link
Collaborator

Thanks! Would you mind sharing your data to help me debug this for you? A google drive or drop box link to the binary file and probe would be easiest. You can post it here if you're comfortable with that, or e-mail it to me at [email protected]

@jacobpennington
Copy link
Collaborator

Sorry for the delay - I've pushed a fix for this now. The issue was that spike positions are estimated based on a weighted sum of nearest channels, but for your atypical probe layout there were cases where the next-nearest channels were on adjacent shanks. The latest changes (which will be available as v4.0.22 after tests finish) fix this by only using channels that are within some distance. By default this is set to 100um, but that can be configured using the new position_limit parameter. I confirmed that this eliminates the smearing issue for your dataset.

Note, however, that you will still see some of that effect between columns of contacts on the same shank. There's no way to get around that, that's just a result of the way we estimate spike positions in conjunction with the unevenly distributed contacts.

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

No branches or pull requests

3 participants