Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Template metrics seems to assume negative polarity, causing incorrect "peak_to_trough_duration" and "halfwidth" for positive units

Open
#4,634 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
data

Research direction

No source file or test is named. Start by locating the template metric implementations for peak_to_trough_duration and halfwidth, then compare their behavior on positive and negative templates; done means the metrics handle both polarities correctly or the supported limitation is explicitly documented, with regression coverage added where the existing tests belong.

Written by the indexing model from the issue text.

Description

metrics question

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

Dominant language
Python
Stars
858
Forks
281
Avg merge
2d 18h
Merged PRs (30d)
38

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SpikeInterface/spikeinterface

All issues in SpikeInterface/spikeinterface

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.