Unify template and quality metrics

[chrishalcrow]

Begin unifying template and quality metrics.

We recently discussed unifying the template and quality metric extensions. Here’s a proposal for starting that process. They’re already quite similar: the big difference is how they deal with parameters. Quality metrics have a parameter set for each metric, through the qm_params kwarg:

qm_params = {
    'sd_ratio’: {
         ‘censored_period_ms’: 4.0
    },
    ‘synchrony’: {
        ‘synchrony_sizes’: (2,4)
    }
}

while the template metrics have one set of parameters shared between all metrics, through the metrics_kwargs kwarg:

metrics_kwargs = {
    'recovery_window_ms’: 0.4,
    ‘spread_smooth_um’ : 20
}

This PR is a proposal to unify the parameter handling of the two metrics extensions, following the more flexible qm_params pattern, calling it metric_params in both cases. In the transition period, if we get the template metrics metrics_kwargs, we propogate these to all metrics. Hence, now the template metrics kwargs would look like:

metric_params = {
    'spread’: {
         ‘censored_period_ms’: 4.0
    },
    ‘exp_decay’: {
        ‘censored_period_ms’: 100,
        ‘peak_width_ms’: 0.11
    }
}

We also extend the load_params function for ComputeQualityMetric and ComputeTemplateMetric for backwards compatibility and add a get_default_tm_params function to match the existing get_default_qm_params.

This simplifies (and makes some neat refactoring (TODO) possible) for e.g. checking if metrics have already been computed. Would make the code in the curation metrics PR simpler.

Bigger picture, this standardisation is a necessary step if we want to make a more generic MetricExtension class/concept. @alejoe91 discussed a SpikeMetrics class, and it could be a good place for plugins and integration with other projects (e.g. could imagine UnitMatchMetrics class which computes the metrics used in UnitMatch).

Breaking change, so worth discussion. One less disruptive option: keep the metrics_kwargs and qm_params names, but just change the structure.

[alejoe91]

LGTM @chrishalcrow! Thanks!

[alejoe91]

@zm711 wanna take a look or ok to merge?

[zm711]

One fix and a couple questions.

[zm711]

a deep copy is expensive, but there's no way around it I guess right?

[chrishalcrow]

Yeah, this is the backwards compatibility case, where the individual metric_kwargs dict (which used to be forced to be the same for every template metric) gets copied repeatedly into metric_params. If there isn't a deepcopy, metric_params is just a dict of references to the metric_kwargs dict. So if one gets altered, they all do. Luckily, the dict is just a dict of kwargs (so is small) and this code only runs on instantiation if someone tries to use the old notation. So shouldn't be a performance issue.

[zm711]

So for templates we don't have the same structure as for quality metrics where we have a separate py file with all these names and a list of metrics?

[chrishalcrow]

Yeah, it's a bit different. Here we're copying the qm_compute_name_to_column_names dict, which is the important dict for getting the actual dataframe column names. The other stuff in quality_metric_list.py is mostly used for the pca/non-pca split. We could follow the quality_metrics structure and make a templatemetrics folder inside src/spikeinterface/postprocessing?? @alejoe91 thoughts?