From 722b8e3f4de5fe3f2c95e38a57dc3754fc9b8d39 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 17:20:41 +0000 Subject: [PATCH] re: the tone curve s single exponent is refuted above render 40 Raised by the port and independently reproduced here before being adopted, since adopting their claims unchecked has misfired twice this session. Binning matched pixels by render level rather than fitting a scalar, the implied exponent falls monotonically and crosses 1.0: render 16 23 31 39 47 64 port (all) 1.26 1.18 1.10 1.03 0.93 0.85 mine (flat) 1.303 1.347 1.128 0.912 0.935 1.003 Below the crossing the capture is darker than the render, which is what the page measured; above it the capture is brighter. A single exponent cannot express a curve that crosses unity, so the model is valid only in the darks -- which is exactly the reach the page already stated. The reach line was not a hedge, it was the finding. Where the two disagree is recorded and not resolved: the crossing is about 44 by their binning and 35 to 40 by mine, and the darks read 1.18-1.26 theirs, 1.30-1.35 mine, 1.49 for the page s original patch fit. Three estimators on three populations, all agreeing on direction and on gamma above 1 in the darks. A confound in my own reproduction is stated rather than left implicit: whole-image correlation is only 0.594 because the committed capture and the default render differ in focus state, which the port measured as 74.1 percent of differing pixels. My bins include that mismatch, so they are not a clean second opinion. And a 1280x720 render against a 1279x675 capture needs a resample, which is why the fit is restricted to flat-neighbourhood pixels. METHOD gains the general form: a stated reach is a boundary rather than a hedge, and the fix was printing the curve instead of a scalar, because a scalar hides its own domain. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/re/METHOD.md | 9 +++++ docs/re/structures/ui-render-tone-curve.md | 40 +++++++++++++++++++++- 2 files changed, 48 insertions(+), 1 deletion(-) diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index 335af219..a6c7a876 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -58,6 +58,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the * **My own last-turn result is a hypothesis too.** * **A global partition can understate a per-owner one.** * **A residual is measured against a population — name it.** +* ⚠️ **A stated reach is a boundary, not a hedge — do not extrapolate past it.** + `ui-render-tone-curve.md` fitted γ ≈ 1.34–1.49 on **dark flat patches** and + wrote "nothing constrains midtones or highlights". Used above that range the + model is simply wrong: binned by level, the exponent falls monotonically and + **crosses 1.0 near render ≈ 40**, so above it the capture is *brighter* than + the render and no single exponent can express the curve. The page had already + said where it stopped being true; the error was reading past the sentence. + ✅ **The fix was not a better fit — it was printing the curve instead of a + scalar**, so it can be argued with. A scalar hides its own domain. * ⚠️ **Normalising? Divide by how many inputs CARRY SIGNAL, not how many there are.** The port hit this three times in one pipeline, each invisible to every check except a level measurement, and each the same mistake: diff --git a/docs/re/structures/ui-render-tone-curve.md b/docs/re/structures/ui-render-tone-curve.md index a0b839fd..ec41a6fd 100644 --- a/docs/re/structures/ui-render-tone-curve.md +++ b/docs/re/structures/ui-render-tone-curve.md @@ -1,6 +1,7 @@ # 🟡 Our composite is brighter than the emulator's frame — measured, not decoded -**Status:** 🟡 **measured, with a narrow reach and a live confound.** Closes an +**Status:** 🟡 **measured, and REFUTED outside its stated reach** — the single +exponent holds only below render ≈ 40; see the refutation below. Closes an observation left dangling by [ui-8ax-fullres-background](ui-8ax-fullres-background.md) ("the capture is ~4× darker than the render"), and puts a number on the ❔ that @@ -48,6 +49,43 @@ patches, and the count runs 0 / 83 / 404 / 1055 / 1788 for `std <` So `capture ≈ 255·(render/255)^γ` with **γ ≈ 1.34 – 1.49**. +## 🔴 REFUTED above render ≈ 40 — one exponent cannot express this curve (2026-08-29) + +Raised by the port, and **independently reproduced here** before being adopted. +Binning matched pixels by render level instead of fitting a scalar: + +| | render 16 | 23 | 31 | 39 | 47 | 64 | +|---|---|---|---|---|---|---| +| **port**, all matched pixels | γ 1.26 | 1.18 | 1.10 | 1.03 | 0.93 | 0.85 | +| **mine**, flat-neighbourhood pixels | γ **1.303** | **1.347** | **1.128** | **0.912** | **0.935** | **1.003** | + +✅ **The finding holds: the exponent falls monotonically and crosses 1.0.** Below +that the capture is darker than the render (γ > 1, which is what this page +measured); **above it the capture is *brighter*.** A single exponent cannot +express a curve that crosses unity, so the model above is **valid only in the +darks** — which is exactly the reach this page already stated. ⚠️ **The reach +line was not a hedge; it was the finding.** + +🟡 **Where they disagree, and it is not resolved.** The crossing point is +**≈44** by the port's binning and **≈35–40** by mine; the darks read **1.18–1.26** +(theirs), **1.30–1.35** (mine) and **1.49** (this page's original patch fit). +Three estimators on three populations — selected flat patches, all matched +pixels, flat-neighbourhood pixels — and nothing here adjudicates between them. +**All three agree on the direction and on γ > 1 in the darks**; that is the part +to rely on. + +⚠️ **A confound in my reproduction, stated so it is not mistaken for +independence it does not have:** my whole-image correlation is only **0.594**, +because the committed `live-main-menu` capture and the default render differ in +**focus state** — the port measured that 74.1 % of differing pixels fall inside +the `live-main-menu` vs `live-main-menu-options-focused` signature. My bins +therefore include that mismatch. It did not change the direction of the trend, +but it is why my numbers are not a clean second opinion. + +⚠️ Also: render 1280×720 against a 1279×675 capture requires a resample +(LANCZOS here), which perturbs levels at edges — hence restricting to +flat-neighbourhood pixels. + ## ⚠️ The reach — and it is narrow * **The flat patches are almost all dark**: render values ~0–60. Over that range