From 8be984c47f0de02e90fe29d273ee89411e1aaf06 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Mon, 31 Aug 2026 04:53:33 +0000 Subject: [PATCH] re: the tone-vs-geometry positive control rested on a number that cannot carry it sylpheed-port found that my control's premise misreads their figure. The 0.06 % counts pixels surviving -threshold 25%, differing by more than ~64 levels -- a gross-displacement detector, blind to sub-pixel offsets and antialiasing, which are exactly what a per-level LUT also cannot close. It says no gross displacement, not geometry is right, and I read one as the other. Their direct measurement, attributed and not reproduced here: after the LUT the menu's residual is 6.94 on edge pixels against 2.20 on flat, with a known negative leaving 0.00. So the menu carries spatial error and is not a geometry-free control. The 32/68 result does not rest on it -- 'whatever a fitted per-level LUT cannot close is not a per-level effect' is the method's own basis and is self-standing. What the control shows is narrower than claimed. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- .../title-residual-tone-vs-geometry.md | 25 +++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/docs/re/structures/title-residual-tone-vs-geometry.md b/docs/re/structures/title-residual-tone-vs-geometry.md index 7c54b6b5..02fde31b 100644 --- a/docs/re/structures/title-residual-tone-vs-geometry.md +++ b/docs/re/structures/title-residual-tone-vs-geometry.md @@ -36,8 +36,29 @@ So fitting a LUT *on the screen itself* and measuring what remains gives an ## The positive control The method must be able to close a residual that really is tone. On the **main -menu** — where the port measures only 0.06 % of pixels differing, so geometry is -essentially right — it does: +menu** it does: + +> 🔴 **THE PREMISE OF THIS CONTROL WAS WRONG, corrected 2026-08-31.** It read +> *"where the port measures only 0.06 % of pixels differing, so geometry is +> essentially right"*. That 0.06 % is `verify-capture`'s, and it counts pixels +> surviving `-threshold 25%` — differing by more than ~64 levels. **It is a +> gross-displacement detector by design**, blind to sub-pixel offsets and +> antialiasing, which are exactly what a per-level LUT also cannot close. It says +> *no gross displacement*, not *geometry is right*, and I read one as the other. +> +> `sylpheed-port` measured the screen directly (`DECISIONS.md` at `5738b83`): after +> this LUT, the menu's residual is **6.94 on edge pixels against 2.20 on flat — +> 3.2×**, with a known negative (a render against itself under a pure gamma) +> leaving exactly **0.00**, since a per-level LUT inverts a per-level effect +> perfectly. **So the menu carries spatial error and is not a geometry-free +> control.** ⚠️ I have **not** reproduced that split — it needs their render beside +> the capture — and it is recorded as their measurement, not mine. +> +> ✅ **The result below does not rest on this control.** *"Whatever a fitted +> per-level LUT cannot close is, by construction, not a per-pixel-level effect"* is +> stated as the method's basis above and stands on its own. What the control +> actually shows is narrower than claimed: the LUT closes 70 % of the menu's +> residual — evidence it works on tone, not evidence the menu is tone-only. | | mean abs difference | closed | |---|---|---|