[JoeZiminski]

This PR implements some (but not all) of the IBL's raw data quality metrics. According to the IBL's white paper (version two) their quality metrics are:

1. Over 1s chunks every 300 seconds, compute:

• Power spectral density (Welch) (num_channel x num_freqs(
• RMS (num_channel x 1)

then take the median RMS across all of the chunks (giving noise estimate per-channel) and the 10-90 quantile across channels (giving spread of noise across channels). They also average all of the Welch PSDs into a single representattive. They do this across AP and LFP, before and after preprocessing.

Further, they compute a rolling RMS over consecutive 3s chunks, I believe only for AP preprocessed and LFP.

They also do a quick spike detection using a threshold method. Here I skipped this, as it is not simple AFAICT to have a static threshold across different recordings (rather than the threshold being a multiple of the noise) and it is not easy to find such a threshold across recordings. Instead i would be better for a general-purpose DataQualityMetrics module to compute various metrics after the pipeline has run, using spikes from the sorter.

Their metrics are summarized in:

This is a draft implementation still up for discussion so I've not implemented tests or documentation yet as it might change. @oliche here I have demeaned the RMS for better comparison between raw and preprocessed, and for the PSD taken chunks, computed periodogram (Hann window) and averaged over these PSDs, so a kind of non-overlapping Welch. Am curios as to your opinion on these design choices.

The runtime is fast for the metrics computed over chunks (RMS, PSD), by default the number of chunks is set to 30 so this is constant with recording size and only takes a few seconds. The rolling RMS is much slower. By default, this only computes rolling RMS on the preprocessed data (and LFP if passed). I think in most cases people will only be passing the AP band. It took around 1m30 on raw data, 7m16 on HP filtered data and 9m26 on LFP data. For this reason there is also a quick_metrics_only: bool = False flag that turns off the rolling RMS computation.

[alejoe91]

@JoeZiminski let me drop here also our AIND QC module: https://github.com/AllenNeuralDynamics/aind-ephys-processing-qc

[JoeZiminski]

Hey @alejoe91 thanks for this! This PR should be ready for review / feedback on the implementation (no tests or docs yet), I think test failures are unrelated.

For the raw data QC we cover the PSD and noise, but am missing "raw data: snippets of AP and LFP traces at multiple points over the session" - could make sense to also write this to the output folder in this PR?

I wonder if a general DataQC module can somehow combine the outputs from raw data quality metrics, artefact detection (if run), and sorting to cover all bases (drift raster map, saturation, unit yield, firing rate)

[alejoe91]

Hey @alejoe91 thanks for this! This PR should be ready for review / feedback on the implementation (no tests or docs yet), I think test failures are unrelated.

For the raw data QC we cover the PSD and noise, but am missing "raw data: snippets of AP and LFP traces at multiple points over the session" - could make sense to also write this to the output folder in this PR?

I wonder if a general DataQC module can somehow combine the outputs from raw data quality metrics, artefact detection (if run), and sorting to cover all bases (drift raster map, saturation, unit yield, firing rate)

Yes I think that a separate "qc" or spelled out "qualitycontrol" module with full metric plots and potentially also some automatic assessment is the way to go. Let's move things there! I think it can have both compute and plotting, since the application is very specific