Error: peak_channel of the clsuters is the reference channel

[OlyOlympic]

Hi, I have encountered an issue while working with the data in metrics.csv. Specifically, I noticed that there are clusters with peak_channel = 191. However, when using ecephys_spike_sorting/scripts/create_input_json.py, we set reference_channel to 191. Based on this, I would expect no clusters to have a peak_channel of 191.

Could you please advise if I might have made an error in my setup or processing? This situation is causing an additional problem because there is no position corresponding to 191 in channel_map or channel_position, which prevents me from determining the position of those neurons.

Additionally, I would like to ask: If reference_channel = [191], how should I configure the IMRO table or any other relevant parameters to ensure compatibility with Neuropixels during recording?

Thank you for your guidance, and I look forward to your response.

Best regards,
Oly

[jsiegle]

If you look at the waveforms for units with peak channel at 191, do they look like real action potentials, or are they noise? If they are noise, then they can be safely ignored – it's unlikely that real waveforms would have a peak on the reference channel, since there's no signal there.

[OlyOlympic]

Hi, jsiegle
Thank you for your reply. However, my question is: if the peak_channel of a certain cluster in metrics.csv falls on a channel that does not appear in the channel_map and channel_position, would this really not cause any issues? Specifically, even if I disregard clusters where the peak_channel appears on a reference_channel, can I trust the results of the other clusters? In other words, does this error affect the reliability of the results obtained for other clusters?

Initially, I used KS4, and I noticed that some clusters had their peak_channel appearing on a reference_channel. Then I tried KS2, and I found that there were still clusters whose peak_channel fell on channels not present in the channel_map or channel_position. However, those channels were no longer reference_channels.

I am genuinely puzzled as to what might be causing this issue. Could you please provide some guidance? I would greatly appreciate your help.

Best regards,
Oly

[OlyOlympic]

@jsiegle

Hi, jsiegle
Thank you for your reply. However, my question is: if the peak_channel of a certain cluster in metrics.csv falls on a channel that does not appear in the channel_map and channel_position, would this really not cause any issues? Specifically, even if I disregard clusters where the peak_channel appears on a reference_channel, can I trust the results of the other clusters? In other words, does this error affect the reliability of the results obtained for other clusters?

Initially, I used KS4, and I noticed that some clusters had their peak_channel appearing on a reference_channel. Then I tried KS2, and I found that there were still clusters whose peak_channel fell on channels not present in the channel_map or channel_position. However, those channels were no longer reference_channels.

I am genuinely puzzled as to what might be causing this issue. Could you please provide some guidance? I would greatly appreciate your help.

Best regards,
Oly

[jsiegle]

It's possible that the mean waveforms module is computing the waveform across all channels, regardless of whether they were included for spike sorting. To find the peak only across channels that were used by Kilosort, you'd have to apply the same channel mask to the waveform, then calculate which channel has the highest amplitude. It would help to see some plots of the affected waveforms to better understand what's happening.

[OlyOlympic]

@jsiegle
Based on your reply, I reviewed the mean_waveforms module. I wanted to confirm if the "find the peak channel that has the highest amplitude" you mentioned corresponds to the following part of the def metrics_from_file():

vpp_allchan = np.amax(mean_waveforms, 2) - np.amin(mean_waveforms, 2)
vpp_val = np.amax(vpp_allchan, 1)
meas_pkchan = np.argmax(vpp_allchan, 1)
vpp_nonzero = (vpp_val > 0)
peak_channels[vpp_nonzero] = meas_pkchan[vpp_nonzero]

In this part of the code, meas_pkchan can include channel 191, which then replaces the peak_channel from the original clus_Table. As a result, channel 191 appears as the peak_channel in both the waveform_metrics.csv and metrics.csv files.

So, if I restrict the computation of "vpp_allchan" to only include channels present in channel_map, this issue no longer occurs.

I also have a small question: is this second method of finding the peak_channel intended as a double-check for the first method?

Looking forward to your clarification.

Best regards,
Oly

[jsiegle]

I now realize you're using @jenniferColonell's fork of this repo -- maybe she has some insights about this?

[jenniferColonell]

Hi @OlyOlympic Sorry for the confusion. If you are using C_Waves to compute the mean waveforms, the output includes all channels in the original binary. The waveform metrics module then uses those channels in its calculations. It perhaps could be improved, but this difference between channels used in the sort and channels used in the waveform metrics is accounted for in the main function of the mean_waveforms module by loading in the correct channel positions for all channels in the original binary file.
So, the important points are: The inclusion of the reference channel does not indicate an error in your analysis. Although the sginal is lower there, it's actually not zero. The difference in the channels used for sorting and the waveform metrics is accounted for in the code. The recalculation of the pkchan is deliberate, to remove issues with estimating the peak channel from the KS templates.

[OlyOlympic]

@jsiegle
Hi, jsiegle,
Thank you for your previous response. Yes, I am indeed using jenniferColonell's fork, and your feedback was very helpful.

@jenniferColonell
Hi, jenniferColonell,
Thank you for your reply as well. I’m glad to know that there’s no error in my analysis. I’ve now decided to ignore clusters with peak_channel=191, excluding them from further analysis.

Best regards,
Oly