画像圧縮の徹底比較：フォーマット選定・品質設定と実ファイルサイズ
1. どのフォーマットと品質を選ぶべきか？（結論）
最適な画像フォーマットおよび品質係数の選定は、画像コンテンツの特性と配信要件によって決まります：
- 写真および連続階調の画像：WebP（品質75%〜80%）または JPEG（品質75%〜80%）。この設定範囲では、人間の視覚で劣化をほとんど識別できない状態を維持しながら、ファイルサイズを80%〜95%大幅に削減できます。
- 透過背景グラフィック・アイコン・ロゴ：WebP（アルファ透過チャネルを完全維持、品質75%〜80%）または PNG（完全可逆圧縮）。背景透過画像をJPEGで保存してはいけません。JPEGは透過チャネルに対応しておらず、透過領域が不透明な白色で塗りつぶされます。
- スクリーンショット・図表・文字主体の画像：PNG または 可逆圧縮WebP。JPEGの圧縮アルゴリズムは、文字の輪郭や高コントラストの境界にリンギング（モスキートノイズ／偽輪郭）アーティファクトを発生させます。
ピクセル解像度を変えずにファイルサイズが変わる理由：画像のピクセル寸法（幅 × 高さ）が一定であっても、非可逆コーデック（JPEG DCT、WebP VP8）は量子化行列を用いて人間の目には知覚できない高周波の空間色変化を間引き、エントロピー符号化によって大幅に少ないバイト数で保存します。一方、可逆フォーマット（PNG）はすべてのピクセルデータを保持したまま、数学的な繰り返し情報のみを圧縮します。ごく小さな画像の場合、固定のコンテナヘッダーや符号化テーブルのサイズが圧縮削減量を上回り、ファイルサイズが増加（+%X）することがあります。
2. フォーマット比較マトリクス
GoToolstack画像圧縮ツールでサポートされている出力フォーマットと基本仕様：
| フォーマット | 圧縮方式 | アルファ透過 | 品質スライダーの影響 | 推奨用途 |
|---|---|---|---|---|
| WebP (.webp) | 非可逆（VP8）および 可逆（VP8L） | 対応（透過を完全維持） | 非可逆モードでファイルサイズと量子化を直接制御 | 最新Webサイト、ブログ用画像、ECサイト |
| JPEG (.jpg) | 非可逆（離散コサイン変換 / DCT） | 非対応（透過部分は白色で塗りつぶし） | 0.10〜1.00の範囲で量子化と視覚的再現性を制御 | 写真、自然風景などの連続階調画像 |
| PNG (.png) | 可逆（DEFLATE / LZ77） | 対応（8ビットおよび24ビット透過） | Canvas API仕様により無視（常に完全可逆で出力） | ロゴ、UIスクリーンショット、図面 |
| AVIF (.avif) | 非可逆および 可逆（AV1） | 対応（透過を維持） | 対応環境において量子化係数を制御 | AVIFネイティブ対応の最新ブラウザ環境 |
3. 技術的に重要な4つの相違点
1. 写真画像と文字主体の画像の違い
JPEG規格（ITU-T T.81）は画像を8×8ピクセルのブロックに分割し、離散コサイン変換（DCT）を適用します。色の変化が緩やかな自然写真ではブロック境界は目立ちません。しかし、フォントの輪郭、バーコード、UI境界線などの高周波エッジでは、高周波成分を切り捨てることで輪郭の周囲にリンギング（ノイズ）や滲みが発生します。テキストを含む画像にはPNGまたは可逆WebPが不可欠です。
2. アルファ透明度とJPEGの落とし穴
JPEGコンテナ形式にはアルファチャネルの概念が存在しません。透過PNGをJPEGに変換すると、HTML5 Canvas 2Dコンテキストは透過領域を自動的に不透明な白色（#ffffff）で塗りつぶします。透明背景を保持する必要がある場合は、必ずWebPまたはPNGを選択してください。
3. リサイズ（解像度変更）と品質低下の違い
画像のリサイズはピクセル寸法そのものを変更します（例：4000×3000 px から 1200×900 px への縮小）。ピクセル数を減らすことが最も大幅なファイルサイズ削減をもたらします。一方、品質低下はピクセル解像度を一定に保ったまま、量子化行列の精度を緩和してデータ量を減らす手法です。GoToolstack画像圧縮ツール は元の解像度を維持し、選択されたフォーマットと品質係数で再エンコードを行います。
4. フォーマット別の圧縮効率（Google Developersの調査データ）
Google Developersが公表している実証研究および技術ドキュメントによると：
- 可逆WebP：高度な空間変換とエントロピー符号化により、同等のPNG画像と比較してファイルサイズが 26%小さく なります（出典：Google Developers, Comparative Study of WebP, JPEG and PNG）。
- 非可逆WebP：同等の構造的類似性指標（SSIM）において、標準的なJPEGよりも 25%〜34%少ないバイト数 で画像を表現できます。WebPのVP8イントラ予測は隣接するマクロブロックを解析して方向性のある色変化を予測し、冗長なペイロードを排除します。
4. HTML5 Canvasによるブラウザ合成データ実測値
数値的な根拠を明確にするため、本リポジトリの合成テストフィクスチャを用いてChromium 154（Chrome Headless）環境で標準HTML5 Canvas 2D toBlob() APIによる実測検証を実施しました。テストは外部ファイルや個人データを含まない合成テストグラフィックのみで実行されています。
検証手法と再現性：以下の測定値は、tests/fixtures/image-800x600-opaque.png および tests/fixtures/image-800x600-transparent.png を直接ツールに読み込んで得られたものです。測定バイト数は制御された幾何パターンおよび文字パターンの結果を反映しています。実写写真では空間エントロピーが異なり圧縮率も変動するため、これらの数値は絶対的な保証値ではなく、再現可能な客観的ベンチマーク値です。
シナリオA：不透明な合成グラフィック（800×600 px PNG、元サイズ：297,270 バイト / 290.3 KB）
| 変換フォーマット | 品質設定 | 出力サイズ | 実測サイズ変化率 | 視覚的品質評価 |
|---|---|---|---|---|
| WebP | 80%（推奨） | 8,300 バイト (8.1 KB) | -97.2% 削減 | シャープな輪郭、色の変化は知覚不能 |
| WebP | 60% | 6,716 バイト (6.6 KB) | -97.7% 削減 | コントラスト変化部に軽微な軟化 |
| JPEG | 80% | 13,871 バイト (13.5 KB) | -95.3% 削減 | 自然なトーン、わずかなブロック構造 |
| JPEG | 60% | 10,863 バイト (10.6 KB) | -96.3% 削減 | 細線部分にわずかなぼやけ |
| PNG（再エンコード） | 100% 可逆 | 297,270 バイト (290.3 KB) | 0.0% 変化 | ピクセル単位で完全一致 |
シナリオB：背景透過付き合成グラフィック（800×600 px PNG、元サイズ：28,766 バイト / 28.1 KB）
| 変換フォーマット | 品質設定 | 出力サイズ | 実測サイズ変化率 | 透過保持と視覚的忠実度 |
|---|---|---|---|---|
| WebP | 80%（推奨） | 8,474 バイト (8.3 KB) | -70.5% 削減 | アルファ透明度を完全保持、劣化なし |
| WebP | 60% | 7,664 バイト (7.5 KB) | -73.4% 削減 | アルファ透明度を完全保持、軽微な軟化 |
| JPEG | 80% | 14,343 バイト (14.0 KB) | -50.1% 削減 | 透過消失：背景が白色（#ffffff）で塗りつぶされる |
| PNG（再エンコード） | 100% 可逆 | 28,716 バイト (28.0 KB) | -0.2% 変化 | 透明度および色の忠実度を完全に維持 |
5. ファイルサイズが逆に増加する理由（+%X 警告の解説）
すでに極小化されているアイコン（1〜2 KB未満）や色数の極端に少ない画像を圧縮しようとすると、変換後のファイルサイズが元サイズより大きくなる（+10%〜+40%）場合があります。その技術的要因は以下の通りです：
- JPEGやWebPの仕様では、ファイルコンテナヘッダー、ハフマン符号表、カラーマップ、量子化行列が必須です。
- 元画像のペイロードが極小の場合、圧縮によって削減されたバイト数よりも、これらの固定メタデータオーバーヘッドの方が大きくなります。
- GoToolstack画像圧縮ツールはこの現象を自動検知し、赤色の
+%X警告を表示した上で、効率性を保護するためにデフォルトで元のファイルをダウンロードアクションを推奨します。
6. ツールの機能・処理アーキテクチャとブラウザの制約
GoToolstack画像圧縮ツール は完全にクライアントサイドで動作します。画像データが外部サーバーへ送信されることは一切なく、お使いの端末ハードウェア上で直接エンコード処理されます。
Canvas解像度の制限：画像処理はHTML5 Canvas 2Dエンジンを介して実行されます。モバイル環境（特にiOS Safari）では、16.7メガピクセル（約4096×4096 px）を超えるキャンバスでGPUメモリ制限が発生する場合があります。極端に高解像度な画像は、エンコード前に縮小が必要となることがあります。
- 対応機能：単一ファイルアップロード、JPEG・WebP・PNG・AVIF出力フォーマット選択、0.10〜1.00の品質スライダー、リアルタイム削減率計算、元ファイルと変換後ファイルの個別ダウンロードボタン。
- 非対応機能：一括ZIPアーカイブ化、分割比較スライダー、プログレッシブJPEGエンコード、SVGベクター化処理には対応していません。
- EXIFメタデータ：Canvasエンジンを介して出力することで、カメラのEXIFメタデータ（GPS座標、カメラ機種、シャッター設定等）が自動的に除去され、プライバシー保護と容量削減を両立します。
- 色深度：標準のブラウザCanvasはチャンネルあたり8ビットのsRGBで動作するため、10ビットや12ビットのHDR RAWプロファイルは標準の8ビットにクランプされます。
7. 参考文献および標準規格
- Google Developers (2025/2026): Comparative Study of WebP, JPEG and PNG & WebP Compression Techniques（VP8イントラ予測アーキテクチャおよび可逆WebPに関する技術解説）。
- ITU-T 勧告 T.81 / ISO/IEC 10918-1: Information Technology – Digital Compression and Coding of Continuous-tone Still Images（JPEG DCT規格およびアルファチャネル制約）。
- W3C 勧告: Portable Network Graphics (PNG) Specification (Second Edition) / ISO/IEC 15948（可逆DEFLATEアルゴリズムおよびアルファ透明度仕様）。
- WHATWG Living Standard: HTML Living Standard – HTMLCanvasElement toBlob()（ブラウザによるクライアントサイド画像シリアライズ仕様）。
