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

Electrode proximity and linear indexing #194

Closed
dimokaramanlis opened this issue Mar 4, 2020 · 1 comment · Fixed by #595
Closed

Electrode proximity and linear indexing #194

dimokaramanlis opened this issue Mar 4, 2020 · 1 comment · Fixed by #595

Comments

@dimokaramanlis
Copy link
Contributor

Hi Marius,

in my understanding, although Neuropixels probes are not fully linear, channel indices correlate with electrode depth. Hence, if a spike has a large peak/trough in channel ic, one can expect to find peaks in nearby channels by indexing around ic (e.g. in the interval [ic-6, ic + 6]). This assumption is used in some pre-processing functions, like my_min or my_sum.

Is this assumption also implicitly used during the optimization (in CUDA functions), and could it affect sorting results for different array geometries? Or is the proximity problem completely handled by finding the closest channels for each electrode through the channel map? The relevant function name is getClosestChannels, and its main output is actually passed to the CUDA functions.

In our ex-vivo retina experiments, we use square arrays (16x16) with relatively large inter-electrode distances (~100 um). Thus, the signals from single units are usually seen in 1-2 electrodes around the main electrode. However, indexing does not correlate that well with proximity. In the example below, 129 is the main electrode, but there is signal also in 113 and 145, which are quite apart in terms of "linear" indices:

3 - Copy

Although KS2 tends to work well, sometimes units get unreasonably split in many parts during the optimization, and I am trying to find potential reasons.

Thanks!

@marius10p
Copy link
Contributor

Some functions in the preprocessing may still be using that kind of linear indexing, but the main algorithm doesn't. If it looks like something goes wrong in the preprocessing (i.e. up to and including the re-sorting of batches in time), then it could be due to this.

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.

2 participants