Skip to content

Add DeAutozero preprocessing step#4423

Draft
chrishalcrow wants to merge 1 commit intoSpikeInterface:mainfrom
chrishalcrow:add-dezero-pp
Draft

Add DeAutozero preprocessing step#4423
chrishalcrow wants to merge 1 commit intoSpikeInterface:mainfrom
chrishalcrow:add-dezero-pp

Conversation

@chrishalcrow
Copy link
Member

@chrishalcrow chrishalcrow commented Mar 4, 2026

This PR adds a de-zeroing preprocessing step, designed for SiNAPS probes.

There are several levels of complexity in how you can do this. Currently, the PR implements the simplest possible algorithm on the simplest data, so that we have a reasonable starting point to make further progress.

Background: SINAPs probes "auto zero" their signal every now and again, to ensure the raw data remains in some reasonable range of values. These "auto zero" events shift the raw voltage reading on each channel by some amount, over a (very small) number of samples. Here's an example:

Screenshot 2026-03-03 at 12 50 52

The strategy to "deautozero" the signal (any have a better name??):

  1. find all samples where zeroing occurs, and the window around the sample which is affected by the zeroing. [For now, use the samples provided by the probe and use a $\pm 4$ sample window around that]
  2. find the size of the jump at each event, and the cumulative sum of the jumps. Note: these are different at each zeroing event and on each channel.
  3. De-zero the jumps. In practice: when you get_traces, compute a recording_shift array equal to the cumulative jumps in each interval between jumps.

This deals with the overall signal, but there are artifacts left behind by the jumps. This is because the jump does not occur at a single sample value. Instead, it is smeared across a few samples. An example of dezeroed data is shown below:

Screenshot 2026-03-03 at 12 58 12

The jump has been taken care of, but either it's zeroed at the wrong place or there's an artifact on the few samples near the jump. I suggest that a good way of dealing with this, using existing tools, is

  1. Use silence_periods on the samples affected by the zeroing (found in 1.)

The lab I'm in touch with do a linear interpolation on these samples, which also sounds like a good idea. We don't have an implementation of this yet, right?

You now (hopefully) have an artifact-free, de-zeroed recording.

In practice, you compute the autozero information first (this requires scanning through the recording once):

autozero_samples, autozero_periods, voltage_cumsum = get_sinaps_autozero_information(raw_recording, az_channel)

Then use this information to make your dezeroed recording:

dezeroed_recording = dezero_sinaps(raw_recording, autozero_samples, autozero_periods, voltage_cumsum)

Many issues:
A. Finding all samples where zeroing is not straightforward and, depending on hardware, can be channel-specific. But there might only be 4 groups of channels, so maybe we could split the recording into these 4 groups with split_by...
B. The de-zeroed signal trends in one direction, and will saturate. Hence we'll need to upcast to int64(?) at some point. You could then apply other preprocessing and downcast again, but all a bit awkward.

EDIT: I'm also curious if all this might be overkill. You might just be able to silence the auto-zero periods and apply a bandpass filter...

@chrishalcrow chrishalcrow added the preprocessing Related to preprocessing module label Mar 4, 2026
@chrishalcrow chrishalcrow added this to the 0.105.0 milestone Mar 4, 2026
@chrishalcrow chrishalcrow marked this pull request as draft March 4, 2026 14:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

preprocessing Related to preprocessing module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant