diff options
| author | Luke Hoersten <[email protected]> | 2026-06-20 11:32:54 -0500 |
|---|---|---|
| committer | Luke Hoersten <[email protected]> | 2026-06-20 11:32:54 -0500 |
| commit | cdd18277a8dfae8227864a3fb4e4e3a62e4dc315 (patch) | |
| tree | dc1daddabb8ddbc6639ec468fbf88444a84ca40c /main/touch.h | |
| parent | c4f6b1586d1ee904ba5bd8091bc72060c9b7249e (diff) | |
phase 5: fix snapshot looking lower-quality than stream
User reported "snapshot is still lower qual than the stream" even at
jpegQuality=1. Two compounding causes in the sharp transform path:
1. Quality mapping topped out at 97. Previous formula was
Math.max(50, 100 - v.jpegQuality * 3); at jpegQuality=1 that
produced quality=97 — versus the stream's ffmpeg mjpeg -q:v 1
which lands at sharp-equivalent ~99-100. Visible compression
artifacts on flat regions accounted for ~half the perceived
quality gap. New formula Math.min(100, 102 - v.jpegQuality * 2)
yields:
jpegQuality=1 → 100 (was 97)
jpegQuality=2 → 98 (was 94)
jpegQuality=5 → 92 (was 85)
jpegQuality=10 → 82 (was 70)
jpegQuality=31 → 40 (was 50, clamped)
2. Chroma subsampling was sharp's default 4:2:0 — half-rate chroma
in U+V planes. On colored edges (UI overlays, sharp camera
subjects against backgrounds, text) this smears and is the
dominant visible artifact at panel-native 800x480. ffmpeg
mjpeg's default behavior at -q:v 1 is closer to 4:2:2 or no
subsampling. Force 4:4:4 when jpegQuality <= 2 (the "I want max
quality" regime); keep 4:2:0 for jpegQuality >= 3 since the
point at that quality is smaller files.
Plus mozjpeg: true on the encoder. Same quality value, slightly
tighter file size — modest but free.
The Lanczos kernel was already lanczos3 — confirmed, no change.
Expected outcome: snapshot at jpegQuality=1 is visually
indistinguishable from a stream frame at the same scene.
Diffstat (limited to 'main/touch.h')
0 files changed, 0 insertions, 0 deletions
