fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: fit a gamma on the clean rows, and repeat a mistake my own tool documents

Browse Source 
The splashes carry no free-running element, so they are the only place to measure
the capture's tone relationship without a phase term. Gamma sweep gives a clean
minimum at 0.85 on publisher_logo, developer_logos and title -- gamma ~1.18 in the
corpus convention, against HANDOFF's 1.34-1.49. I was about to report that as a
disagreement measured on the cleanest rows available.

verify-capture's own header answers it: the tone relationship is a curve, not a
best exponent, and two earlier versions of the tool reported an exponent and were
wrong. The binned table below it shows implied gamma falling with render level --
1.20 at 8, 1.18 at 24, 1.03 at 40, 0.93 at 48 -- with 511026 pixels in the dark
bins against 258823 above. My whole-frame fit recovered the pixel-count-weighted
average of a varying curve and would have published it as the gamma. Third time
this tool has been fitted an exponent, third time wrong.

The residual at best gamma is 1.92-2.06 on the clean rows, ~30x the 0.06
rasterisation floor, so a single exponent cannot close it.

What the clean rows do establish: the splash residual bottoms at 1.92 with no
phase term, so it is a real floor for those screens and still 30x the noise --
the port and the capture differ by something the tone curve does not explain.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 16:13:47 +00:00
parent 998af195e0
commit a890b66b35
1 changed files with 53 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
docs/port/DECISIONS.md
View File

@@ -9,7 +9,7 @@ dies, which is what this file is for.
<!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
180 sections. Search this before re-deriving anything.
181 sections. Search this before re-deriving anything.
* [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
* [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -191,6 +191,7 @@ dies, which is what this file is for.
* [Replicating the phase result on the title — it fails, and the failure is the finding](#replicating-the-phase-result-on-the-title--it-fails-and-the-failure-is-the-finding)
* [Their masking rule, implemented — and it does not transfer to my screens](#their-masking-rule-implemented--and-it-does-not-transfer-to-my-screens)
* [Their "the game may not draw these leaves" hypothesis — my curves say *sometimes*](#their-the-game-may-not-draw-these-leaves-hypothesis--my-curves-say-sometimes)
* [Using the clean splash rows to measure the tone curve — and repeating a documented mistake](#using-the-clean-splash-rows-to-measure-the-tone-curve--and-repeating-a-documented-mistake)
<!-- /INDEX -->
## P0 — the exporter, 2026-08-28
@@ -10281,3 +10282,54 @@ for `pteff03`/`pteff03a` on a settled title. **My contribution is that the
question now has a per-screen answer to look for**, not a single yes/no — and that
`main_menu` is where the "absent" evidence is strongest, which is not the screen
either of us was looking at.
## Using the clean splash rows to measure the tone curve — and repeating a documented mistake
The Decoder's advice was to act on the rows that mean what they say. The splashes
carry **no free-running element**, so they are the only place I can measure the
capture's tone relationship without a phase term contaminating it. I swept gamma
on them:
| γ (ImageMagick) | 0.70 | 0.80 | **0.85** | 0.90 | 1.00 |
|---|---|---|---|---|---|
| `publisher_logo` | 2.25 | 2.09 | **2.06** | 2.07 | 2.17 |
| `developer_logos` | 3.44 | 2.14 | **1.92** | 2.08 | 3.05 |
| `title` | 12.95 | 8.52 | **8.22** | 9.40 | 14.16 |
A clean minimum at 0.85 on all three — **γ ≈ 1.18** in the corpus's convention,
against HANDOFF's **1.34–1.49**. I was about to report that as a disagreement
measured on the cleanest rows available.
### 🔴 `verify-capture`'s own header already answers it, with the data
*"THE TONE RELATIONSHIP IS REPORTED AS A CURVE, NOT AS A BEST EXPONENT, and two
earlier versions of this tool reported an exponent and were wrong twice."* And
below it, the binned table:
| render level | 8 | 16 | 24 | 32 | 40 | 48 |
|---|---|---|---|---|---|---|
| implied γ | 1.20 | 1.26 | 1.18 | 1.10 | 1.03 | **0.93** |
| pixels | 183 026 | 227 630 | 100 945 | 87 474 | 86 094 | 85 255 |
**There is no single exponent.** γ falls with level and crosses 1.0 by render 48.
My whole-frame fit recovered **1.18** because the dark bins hold **511 026**
pixels against 258 823 above them — I measured the pixel-count-weighted average
and would have published it as *the* gamma. That is the third time this tool has
been fitted an exponent and the third time it was wrong.
✅ The residual at the best gamma is **1.92–2.06** on the clean rows — ~30× the
0.06 rasterisation floor. A single exponent cannot close it, exactly as the header
says.
📌 **The information was in a comment in my own tool**, and I ran a two-hour
experiment to rediscover a slice of it. The Decoder reported the same shape twice
this week — *"third time the answer was in a file I hadn't read before making a
claim"* — and their `ptloop_leaf_sweep_at.rs` window is the same thing one level
out. **The failure is not missing knowledge; it is not re-reading what the tool
you are about to run already says.**
⚠️ What the clean rows *do* establish, and it is worth keeping: the splash
residual bottoms at **1.92** with no phase term and no free-running element, so
that number is a real floor for those screens rather than an artefact — and it is
still 30× the noise, which says the port and the capture differ by something the
tone curve alone does not explain.