I’m preprocessing human Neuropixels data using SpikeInterface with both positive and negative spike detection enabled when creating the SortingAnalyzer after external KS2.0 and Phy curation.
In my dataset, some units (sometimes the majority) are clearly positive, but I just found out that template metrics such as peak_to_trough_duration and halfwidth are incorrect for those positive units.
The documentation for peak_to_trough_duration describes it as “Duration in seconds between the trough (minimum) and the next peak (maximum) of the template”, which appears to assume a negative-going spike by definition (at least here in the documentation text).
After checking the repository and code, it looks like some metric functions do not receive spike polarity information, so the calculation path appears to be hard-coded for negative spikes, at least in my opinion. That would explain why positive units produce strange values for peak_to_trough_duration and half_width metrics.
I also noticed the halfwidth-style description is similarly phrased around the largest trough/minimum, which again seems aligned with negative spikes rather than with handling both polarities symmetrically.
In contrast, SpikeInterface documentation and discussion threads indicate that positive spikes are a real use case and can be detected, so these metrics could ideally account for spike polarity or document the limitation explicitly.
Thanks in advance for any input or suggestions you may have on this!
Best,
Domi
I’m preprocessing human Neuropixels data using SpikeInterface with both positive and negative spike detection enabled when creating the SortingAnalyzer after external KS2.0 and Phy curation.
In my dataset, some units (sometimes the majority) are clearly positive, but I just found out that template metrics such as peak_to_trough_duration and halfwidth are incorrect for those positive units.
The documentation for peak_to_trough_duration describes it as “Duration in seconds between the trough (minimum) and the next peak (maximum) of the template”, which appears to assume a negative-going spike by definition (at least here in the documentation text).
After checking the repository and code, it looks like some metric functions do not receive spike polarity information, so the calculation path appears to be hard-coded for negative spikes, at least in my opinion. That would explain why positive units produce strange values for peak_to_trough_duration and half_width metrics.
I also noticed the halfwidth-style description is similarly phrased around the largest trough/minimum, which again seems aligned with negative spikes rather than with handling both polarities symmetrically.
In contrast, SpikeInterface documentation and discussion threads indicate that positive spikes are a real use case and can be detected, so these metrics could ideally account for spike polarity or document the limitation explicitly.
Thanks in advance for any input or suggestions you may have on this!
Best,
Domi