Files
Sylpheed/docs
Sylpheed port agent 0a054d681b port: discriminate the blend -- additive halves alpha-over's error on both frames
Last iteration could say the shortfall scales with the background but not which
curve. That is decidable with no RE: an element rendered over two different
backgrounds gives two equations in a and aC, and the mod tree supplies the second
background by suppressing pteff10/pteff12, which moves it by a mean of 26 levels.
No placement, no coordinate transform, no texture decode assumed.

The control is exact. Alpha-over rebuilt from the solved per-pixel a and aC
reproduces the port's own render at RMSE 0.0000 on both screens, so the recovered
values are right rather than a fit that lands nearby.

RMSE against the capture, ptframe1 / ptframe3:
  additive     34.305 / 28.948
  screen       50.052 / 50.368
  alpha-over   65.046 / 71.299   <- what the port does
  not drawn    90.916 / 109.801

Same ordering on both. The frame is certainly drawn in the capture, and additive
roughly halves the error of what the port currently does.

What it is not: additive still leaves 28.9-34.3, so none of the three reproduces
the capture. This ranks candidates, it does not identify the equation, and the
absolutes are inflated by mapping the capture through the fitted LUT inverse --
the ranking is fair because all four go through the same mapping.

Nothing adopted. The Decoder established no blend is on the disc for .t32, so any
choice is authored, and the mission says propose rather than take. The renderer is
unchanged.

Refutation attempt, recorded as surviving: their kind-0 claim checked against my
own exporter's independently decoded kind_raw. Every sprite decoration on both
screens is 0x0, frames included, every button 0x3002. Two independent decodes
agree, which is also what makes the blend question sharp -- the frames are declared
identically to ptbase and pteff05, which the port draws at 1.31x and 0.92x.
2026-08-31 05:45:21 +00:00
..