スクリーンショット撮影の整数スケール設計 — ピクセルパーフェクトでにじみを消す
UIスクリーンショットのにじみ/ぼやけは、DPRと整数スケールの不一致、 clip座標の小数化、ブラウザズームの多用が主因です。本稿は「撮影→縮小→形式/品質→実装」の順で、 ピクセルパーフェクトを崩さずに最小容量へ寄せるテンプレートを示します。
1.5 落とし穴（ズーム/補間/clip）
- ブラウザのページズームはレンダリング後の拡大 → ぼやけの温床
- 非整数clip座標・幅高 → 1px 枠が 0.5px×2 に分割されてにじむ
- 等倍確認を怠り 150% だけでレビュー → 実寸で崩れる
要点（TL;DR）
- 整数スケール（1x/2x）で撮影。ページズーム依存は避ける。
- clip座標と幅/高さは整数pxに丸める。
- 縮小は整数比を優先（1/2, 2/3 など）。
- 文字/線主体はPNGパレット/ロスレスWebP、混在はWebP 85%±5%。
- 実装は
width/heightと srcset/sizes を徹底。
2.5 実例：整数縮小の二段処理
2/3 などの難しい比率は、先に3/1拡大→1/2縮小で滑らかさを調整。
magick in.png -filter box -resize 300% -filter lanczos -resize 50% out.png1. なぜ滲むのか（DPRとサブピクセルAA）
- 表示DPRと撮影倍率の不一致 → サブピクセルAAが発生。
- 小数座標/幅 → 1px罫線が0.5px×2に分散される。
- ページズームの拡大 → レンダリング結果を再サンプリングしてぼやける。
4.5 QA プロトコル（5分）
- 100%/150% の両方で 1px 枠と小文字の破綻がない
- 再ロード後も差分なし（無劣化保存）
- 最終用途の背景色上でもコントラスト十分
5. 計測メモ
文字/線の可読性は SSIM 等の画質指標だけでは評価しづらい。差分拡大や rater 2人以上の目視で最終判断。
2. 撮影テンプレ（整数スケール×整数座標）
- UI幅を測り、1x/2x等の整数倍撮影を決定。
- DPR/ビューポート/ズームのうち、DPR/レイアウト幅側で調整。
- clip座標・サイズを整数pxに揃える。
- 出力はPNG（必要に応じパレット減色）。
3. 書き出し→最小容量化
- 整数縮小（1/2, 2/3）で最終寸法へ。
- PNGパレット16–64色 → ディザ弱め。混在ならWebP 85%±5%を比較。
- 差分チェックは /compare、一括は /compressor。
3.5 目視プレビューの流れ（崩れ検知）
- 100%と150%表示で白縁/リンギングの有無を確認。
- 1/2縮小→2倍拡大で細部のAA再サンプル劣化を疑似チェック。
- 問題が見えたら、撮影スケール→座標整数→縮小比の順に是正。
最短で直す
まずは撮影を整数スケールに固定。それでも改善しない場合のみ縮小比や形式に触れます。
4. 実装チェック（LCP/CLSを壊さない）
width/heightを必ず指定（CLSゼロ）。- srcset/sizes で帯域最小化。
- ハッシュ付きファイル名でキャッシュ更新。
4.5 公開前チェック（5項目）
- 撮影は整数スケール（ページズーム依存なし）
- clip座標/幅高が整数（0.5pxなし）
- 縮小は整数比優先でリングが出ていない
- 形式は用途に最適（PNGパレット/ロスレス/有損WebP）
- width/height + srcset で配信最適化
FAQ
FAQ（よくある質問）
1ズームで2xにすれば整数スケール？
ブラウザのページズームはレンダリング後の拡大でぼやけます。DPRやレイアウト幅側で2x相当にするのが安全です。
21px線が滲む原因は？
小数座標で描かれてサブピクセルAAが効いている可能性。座標/幅を整数に揃えると解消します。
3書き出し形式は？
文字/線主体はPNGパレット/ロスレスWebP、写真混在はWebP85%起点。容量と可読性で決定します。
まとめ：整数で固めれば“クッキリ”は再現できる
撮影から縮小、形式/品質、実装まで整数を意識すれば、読めるスクショを最小容量で安定供給できます。
Version: 2025-09-09 – 初版（整数スケール撮影テンプレ）。