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

Question about the error message "Bytes in binary file did not divide evenly, incorrect n_chan_bin" #672

Open
wilburshi opened this issue Apr 22, 2024 · 13 comments

Comments

@wilburshi
Copy link

Describe the issue:

Hello! I followed the steps on github to install kilosort4 and successfully ran the GUI. However, when I loaded our recording data and channel map file, it gave me this error message "Bytes in binary file did not divide evenly, incorrect n_chan_bin". I am not even sure where to start the debug. Could you please help me with it? Thanks!

image001

(In case you need it, we are recording using neuronexus probe, and whitematter wireless system.)

@jacobpennington
Copy link
Collaborator

Hello @wilburshi,

The first thing to double check is that the value you entered for "number of channels" is correct. This should reflect the actual number of rows in the data, including un-used channels, regardless of how many contacts are specified in your probe file. For example, for our Neuropixels 1 test data this is set to 385 even though only 383 channels are used for sorting.

If that is indeed the correct value, let me know. I added that error check because we kept seeing unreadable Pytorch errors when 'number of channels' was set incorrectly, but if it's causing problems for correct values then I'll remove it.

@andy20002000
Copy link

Hi @jacobpennington,

I am experiencing the same issue (altho i am using much less channels n_chan = 7). Would appreciate your advice on whether i am missing a setup for this probe i am testing with.

image

@jacobpennington
Copy link
Collaborator

@andy20002000 You need to check the same thing I mentioned above: are you certain the raw data file only has 7 channels in it, or are there other channels that are not being included for sorting? number of channels has to be the same as the number of rows in the data, regardless of how many are included in the probe file.

@andy20002000
Copy link

Hi @jacobpennington

Thank you for your response, but when i change the number of channels it would show 'Largest value of chanMap exceeds channel count of data, make sure chanMap is 0-indexed'. Do you have any advice on that? Thank you in advance

image

@jacobpennington
Copy link
Collaborator

That's because you reduced the number of channels. You clearly have at least 7, there are 7 channels specified in your probe. You probably need to increase it to account for channels that are not specified in the probe (for example, ground electrodes or non-ephys channels), but I have no way of knowing what that number should be. If none of that applies, let me know.

@andy20002000
Copy link

So the probe we use are have 7 channels but we were only able to record 4 channels out of 7 with ground automatically accounted for in the Intan. i understood it as i should have number of channels >= the number of channels in the probe map. Given my situation, i should redesign a probe map that has 4 or 3 channels for the GUI to accept my data?

@jacobpennington
Copy link
Collaborator

jacobpennington commented May 8, 2024

The probe map should only specify channels that you actually recorded from, i.e. the ones containing the data you are using for sorting. n_chan_bin should be the number of rows in the raw data file, regardless of anything else about the probe or other hardware. So it sounds like your probe should have 4 channels specified. As for n_chan_bin I don't know, that would depend on Intan, but I would try using n_chan_bin = 4 as a first guess (with the updated probe map).

@jacobpennington
Copy link
Collaborator

A side note: I notice the x- and y- values you specified are all single digits apart from each other, so I just want to point out that those should be specified in units of microns (maybe they already are, but most probes I've seen have contacts spaced farther apart than that). The raw values are important for Kilosort4, whereas I think in previous versions only the proportions mattered.

@DanEgert
Copy link

Sorry if this is already available, but maybe it could help to add a trace view to the GUI (and to the scripted pipeline). Is there a good place to plot the actual traces Kilosort will sort? A few users might be confused about where to specify the number of channels in the recording vs the connected channels on the probe to consider during sorting.

@jacobpennington
Copy link
Collaborator

Trace view is on the to-do list. There is currently nowhere to specify connected vs disconnected channels, if they're not connected they should not be included in the probe file.

@victornovakov
Copy link

Hi, I am getting this problem as well. I am using probe 3b1.mat and data from the mainen lab as linked in the basic example tutorial. I have tried using n = from 384 up to 390 and none seem to work. I continue to get this error. I do not know what is wrong or how to fix it. Any help would be greatly appreciated. At one point it would first say wrong n, and then continue to give a type error related to a summation of an int and a none type.

@jacobpennington
Copy link
Collaborator

jacobpennington commented May 15, 2024

@victornovakov I haven't used that full dataset link myself (I'm downloading it now to confirm), but it looks like it's supposed to be 385 just like the smaller sample dataset. What error are you seeing when you set number of channels = 385? And what version of Kilosort4 are you using? You can use conda list kilosort in a terminal to get version information.

@victornovakov
Copy link

@jacobpennington Sorry for the hassle. I am no longer getting any issues with the public data set or my own data. I am now getting automatic accurate estimations for channel number and the data is loading perfectly. Thank you. Not sure what was up yesterday, sorry again for the bother.

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

5 participants