Visualization API
Every shading mode and colormap described elsewhere in this documentation - magnitude, sparsity-mask, quantization boundaries, the diverging cyan/red/dark diff convention - is an instance of the same underlying extension point: a TensorMetric, which computes a value per tile and a way to render it.
What a TensorMetric provides
- A statistic function - computed the same mergeable, monoid way as Tensormorph's built-in tile statistics, so a custom metric gets level-of-detail streaming for free rather than needing its own caching strategy.
- A color mapping - how a computed value becomes a color in the Matrix and Heatmap and Architecture shading-mode lists.
- A scale - linear, log, or diverging around a meaningful zero point, matching whichever is appropriate for what the metric measures.
Implementing the mergeable-statistic contract correctly is what makes a custom metric behave like a built-in one - available at every zoom level, computed once and reused, rather than recomputed per view or unavailable at coarse levels of detail.
A worked example
A plugin adding a domain-specific metric - say, a custom interpretability score computed per-weight - registers a TensorMetric that: computes the score per tile in a mergeable form, maps it to a color scale (likely diverging, if the score has a meaningful positive/negative/neutral structure), and from that point on appears as an ordinary shading-mode option everywhere shading modes are selectable, without any per-view integration work.
Custom colormaps without a new metric
A TensorMetric isn't required just to add a colormap for an existing statistic - see Settings for swapping the colormap used by a built-in shading mode, which doesn't require plugin code at all.
Related resources
- Tensor Statistics - the mergeable-statistic contract a custom metric must satisfy.
- Matrix and Heatmap Editor - the diverging-color convention a metric's scale should follow where applicable.
- Extension API - the plugin ABI a
TensorMetricis registered under.