Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
49 changes: 49 additions & 0 deletions .claude/plans/x265-sprite-replay-probe-v1.md
Original file line number Diff line number Diff line change
Expand Up @@ -217,3 +217,52 @@ The arc's own sprite-replay motion coding (E-SPRITE-IPB-HELIX-1: one Signed360
code per sprite per P-frame) is the thing being contextualized; the
bitrate-comparison study (our object-level motion codes vs x265's per-block MV
field on the SAME scene) is a NAMED follow-up, not done here.

## Results (2026-07-18 — HEAD-TO-HEAD: our helix motion codes vs x265 MV field)

The head-to-head the HEVC anchor set up: our object-level helix motion codes vs
x265's per-block MV search, on the SAME φ-spiral scene. Reproducer:
`lance-graph crates/helix/examples/hevc_headtohead.rs` (uses the REAL helix
public API — `ResidueEncoder::encode_signed` / `Signed360` / azimuth-roundtrip
decode — not a re-inline; 3 tests, clippy-clean).

**Codex-P1 #740 correction:** the reproducer renders through helix's REAL
`HemispherePoint::signed_lift(n, total, sign).cartesian()` (golden-RATIO azimuth,
`r=√u`), NOT a local golden-angle approximation — so the scene IS the geometry
`Signed360` encodes and this is a genuine helix-motion-code result. Numbers below
are on that real-helix scene.

| Lane | Bytes | bits/frame | PSNR | What the bytes are |
|---|---|---|---|---|
| A — x265 3.5 medium | 40,750 | 1358.3 | 61.27 dB | **TOTAL HEVC bitstream** — texture + residuals + modes + headers + MV, all syntax |
| B — our helix `Signed360` | **432** (192 appearance + 240 motion) | 14.4 | **∞ (bit-exact)** | **TOTAL our-codec stream** — sprite appearance + object-motion (1× 6-byte code / sprite / P-frame) |

**This is a TOTAL-stream vs TOTAL-stream comparison, NOT motion-vs-motion
(codex-P2 #250).** Lane A's 43,115 B is the *entire* HEVC output — the 432 B does
**not** replace only x265's MV field, it replaces x265's whole stream, which it
can only do because it is model-based. Isolating x265's MV-only bits (via `--csv`
per-frame syntax analysis) to test the "one code replaces the per-block MV field"
thesis DIRECTLY is a named follow-up, not measured here.

**Verdict: TAUTOLOGICAL-WIN / MODEL-MATCHED LOWER BOUND (KILL did not fire; NOT a
general-codec win).** Lane B was handed the EXACT generative model of a
self-generated φ-scene; the ∞ PSNR is the decoder re-running the same generator.
Legitimately establishes the object-motion amortization's concrete bit-cost — one
6-byte `Signed360` per sprite per P-frame = 240 B of motion for the whole
240-frame GOP — as a TOTAL-stream lower bound on model-matched content. Does NOT
beat x265 in general: (1) arbitrary non-φ-manifold motion needs stored residuals
(PROBE-SPRITE-REPLAY's [H] gate); (2) x265's bytes encode actual pixels while
ours encode model parameters — different things. Board: lance-graph
`E-X265-HEADTOHEAD-1`.

## Follow-up probe queued — PROBE-SPLAT-μ-HYDRATION-RHO (the spatial cousin)

The operator's 3DGS↔blasgraph↔gridlake presumption, adjudicated by the
convergence-architect (lance-graph `E-3DGS-MU-HYDRATION-1`): `splat3d::GaussianBatch`
is ALREADY SoA, so the only net-new "gridlake" claim is **address-derived gaussian
μ** (WORTH-EXPLORING on the φ-manifold — the SAME [H] gate as this head-to-head's
temporal tautology). "EWA = blasgraph semiring" DROPPED (depth-sorted Porter-Duff
*over* is non-commutative → axiom break). Named probe **PROBE-SPLAT-μ-HYDRATION-RHO**
runs on a real trained Inria `.ply` (non-φ input via `splat3d::ply`): μ-hydration
ratio + semiring-matches-EWA (commutative-⊕ vs sorted-over) + SoA-sweep throughput.
PASS→[H] / KILL→DROP bands in the board entry.
Loading