Kilosort
Kilosort copied to clipboard
MouseLand
Question about the error message "Bytes in binary file did not divide evenly, incorrect n_chan_bin"
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!
(In case you need it, we are recording using neuronexus probe, and whitematter wireless system.)
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.
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.
@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.
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
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.
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?
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).
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.
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.
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.
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.
@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.
@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.
It sounds like everyone encountering this error has been able to fix the problem by identifying the correct number of channels, so I'm going to close this issue. To reiterate for anyone searching this in the future: if you see this error, it means the number you entered for "number of channels" (GUI) or "n_chan_bin" (API) did not line up with the shape of the data. That number needs to be the exact number of rows/channels in the data, regardless of how many of those channels are actually used for sorting.