The previous entry scored verify-screen's title_jp frame against the oracle and
concluded the port had moved away from the game. That frame is posed --pose=rest,
which the port does not ship. Posed as it runs, the disputed block scores +0.9994
against the reference's +0.8727, and the whole surface +0.9652 against +0.9200 --
holding under gamma compensation and on the English control (+0.9946 vs +0.9560).
The port is closer to the game than the reference on both title screens.
Mechanism: ptlogo_back2eff1 is (0,0)(98,0)(100,255)(102,255)(104,0) -- a 4-unit
sparkle whose rest.t is the peak of its own flash. Six of them stagger across the
logo, so --pose=rest fires every sparkle at once. The 25.6% excess light was real
and was in a frame nobody sees.
verify-screen is not at fault: it poses rest deliberately, so that both renderers
read one decoder and the run is a consistency check. I used a consistency-check
frame for a correctness question. Its header now says its frames must never be
scored against a capture.
A second claim in that entry was also wrong -- both screens draw those layers
under pose=rest; I had compared a --menu timeline log against a verify-screen
rest log and read a mode difference as a screen difference.
verify-capture takes a fifth per-row field, a capture crop, because this capture
is a full display frame with the surface at +0+45 while the others are
pre-cropped. With it title_jp reads RMSE 20.91 / 1.04%, beside title's 14.16 /
0.21%. The row prints 'no capture' until their branch merges.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
aa51e5af67