What the level column measures

Linear light, over the lit set (ADR-0150). Two halves, and both matter:

• Linear, because the stored pixels are sRGB-encoded and that curve is concave: a mean over the bytes under-reports a brightness change by roughly half. That factor of two is the property, and it is what the statistic is for. The move you see is not the trim you made, and expecting it to be will make a working column look broken. Trimming star_rosewindow’s brightness by 30 % moves this column from 0.0532 to 0.0408 — 23 %, measured 2026-09-01 on the DX12 software adapter. Two things eat the rest, and both are the pipeline rather than the statistic: the tonemap is the identity only below its knee and compressive above it, so bright content moves less than its source; and the lit set itself shrinks as dimmed pixels fall under cover’s threshold, which lifts the mean of what stays.
• Over the lit set, the same pixels cover counts, so an authored background does not dilute the reading. The two columns read one picture from two directions: cover is how much of the frame is lit, level is how bright that lit part is. In the sample above Shatter lights more than half the frame at a low level and Stipple lights a third of it, brightly.

It is a comparison number and never a threshold. There is no level a preset ought to hit, and one row’s cell says nothing on its own. What it is for is a before/after on the same preset — did this change make it brighter, and by how much — or an ordering across a family. The lit predicate is a threshold on the stored bytes, so the statistic is linear light over a set chosen in code space; ADR-0150 records why that seam is accepted rather than solved.

The blind spot, by construction: a preset that goes wrong by changing its background is invisible here. That is the price of not being a background detector, and cover is the column that sees it.

The name column is fourteen characters wide, and a longer name is elided in the middle, not at the tail: Tiled Rosette Mono prints as Tiled R~e Mono. The tail is what distinguishes a name in this library — Mono, Gallery, Bordered, Walk — and a tail truncation threw it away, which is how two presets came to print as one row label in every table (design-backlog 0131). A ~ in a label means characters were dropped there.

A family whose scenes draw through the line renderer first gets a one-column geom block, under the prose that follows the table: the in-frame geometry fraction, the share of drawn line length inside the frame at the fully-driven capture, read while tuning scale and never as a threshold (ADR-0083). It is a block rather than a column because the table has no width left for it under 100 characters. A preset in such a family that drew no line prints -, and --json carries the value as in_frame_geometry.

  preset           geom
  Gyre           0.9685
  Loom           0.9962
  Curve Mono     0.9602

Three more labeled blocks print under the table (new readings go beside the table rather than into it, so every historical number keeps its place): the frame cost described above, the realistic-levels reading (reactivity_low — the same bands at the levels real music reaches, ADR-0042) and, since Plan 0077, the footprint reading (reactivity_footprint) — the same differentials divided by the union of lit pixels instead of the whole frame (metrics::footprint_diff, ADR-0091). Read the footprint block when a mean band column shows ~0.000: reactivity concentrated in a small footprint — a bloom_amount halo, a sparse figure — is diluted by the whole-frame mean, and before this reading existed the house workaround was binding a flash lever just so the report had something to see. On a backdrop-heavy preset the union mask approaches the whole frame and the reading degrades toward the mean column — it never sits meaningfully below it, so it fails toward the old behaviour rather than inventing reactivity.

Every one of those but count and the last two is a settled measurement: the capture holds one stimulus for every frame it renders, so each smoother has converged long before the pixels are read. That is the right question for “does it respond”, and it is exactly why those columns are identical for any [smoothing] constant.