radiens_qc.preprocess
Configure the stage-2 DSP chain and detection threshold every measurement runs on.
One pair of settings governs the whole package, because the server has only one
of each per datasource. Stage 2 is the chain the KPI engine measures through, the
chain get_signals(apply_dsp=True) reads back, and the chain the spike sorter
runs on -- the sorter has no filter chain of its own. The threshold is written
into the datasource's own detection parameters, the single object the KPI scraper
detects with, the UI displays, and any sorter launched afterwards shares.
Both are shared server-side state: other clients viewing the same datasource see the change.
Kept in the package rather than left to callers because the report's correctness
depends on the ordering: configure, then kpi_calculate, then read metrics.
The server clears its KPI cache asynchronously when either setting changes, so a
caller who reads metrics without re-triggering computation silently gets stale
values that do not reflect the filters the report says were applied.
Classes
DetectionSettings
dataclass
What to configure on a datasource before measuring it.
The two travel together because they are never independently meaningful: a
threshold is in multiples of a noise floor measured through the filters, and
an event_rate states nothing without both. Passing one object is also
what keeps a report and the raw-signal figures drawn beside it describing the
same signal, which two loose arguments left to a caller to keep in sync.
Attributes:
| Name | Type | Description |
|---|---|---|
dsp_params |
Sequence[DSPParam] | None
|
Filters applied at stage 2, in order. Any param that does not
name a |
threshold_sd |
float
|
Symmetric event-detection threshold in noise-SD multiples,
applied as |
ResolvedDetection
dataclass
What was applied to a particular recording, recorded as provenance.
Distinct from :class:DetectionSettings so that a report describes the
filters that ran rather than the request that produced them: ports are
expanded, stage is injected, and the mapping form is gone. An
empty dsp_params means no DSP was configured, so the measurement rode on
whatever the server already held -- which is why
:meth:~radiens_qc.report.QualityReport.ap_band_rms_uv declines to answer.
Functions:
amp_ports
Distinct hardware ports the recording's amplifier channels occupy, in channel order.
A DSP filter targets one port, so filters must be replicated across every port present. Falls back to port A when no channel reports one.
apply_detection_settings
Configure dataset's stage-2 filters and detection threshold, and report what was applied.
No data files are rewritten -- stage 2 is read-time filtering.
The server auto-clears and recomputes the KPI cache when either changes, but
that recompute is asynchronous. Callers must therefore trigger and await KPI
computation (:meth:VidereClient.kpi_calculate) after this returns, before
reading metrics, or get_kpi_metrics_series may return stale/partial values.
:func:~radiens_qc.compute.compute_report handles that ordering for you.
Returns:
| Type | Description |
|---|---|
ResolvedDetection
|
The settings as applied, for recording as provenance. |
canonical_dsp_params
Reduce a chain to one JSON shape, so equal chains compare and hash alike.
Coerces the mapping form and injects STAGE2 as :func:resolve_dsp_params
does, so the two spellings of one request agree. Stops short of port
expansion, which needs the dataset, so a port-less entry stays port-less.
Two fields are dropped because they name nothing the filter acts on:
user_label, free text the server stamps its own value into; and
aux_chan_idx on a param that is not is_aux, which reads back as 0
rather than the unset it went out as.