JPEG、PNG、WebPを品質指定または正確なサイズ上限まで圧縮

品質指定と上限指定は別の問題

画像を圧縮する理由のほとんどは2つのどちらかで、それぞれ必要とする操作が反対です。画像を適切な見た目にしながら可能な限り小さくしたい場合と、送信先に厳しい上限があり、その範囲に収めたい場合です。スライダーが1つだけのツールでは、後者は当て推量になります。

品質を目標にするのは、自分で管理できるものに適しています。作成中のページの画像、文書に入れる写真、ポートフォリオなどです。80から85を選べば、それ以上考える必要はありません。この範囲があるのは、JPEGまたはWebPのエンコーダーが、目が注目する画像の部分にビットを使うためです。85を超えると、残りのビットはほとんど誰も見ない細部に使われます。60未満では、コーデックが処理するブロック構造が、硬いエッジに沿って見え始めます。文字の輪郭や、明るい空を背景にした屋根の線などです。

上限を目標にするのは、フォームに「最大2 MB」と書かれている場合、メールサーバーがメッセージを拒否する場合、ビザ申請が写真を受け付けない場合です。そこでは、何が最もきれいに見えるかではなく、何が収まるかが問題になります。

上限に到達する仕組み

サイズ上限は分析的には解決できません。指定した品質での画像のエンコード後のサイズは内容によって変わります。同じ設定でも、森の写真と壁の写真では10倍違うことがあります。そのため、目標サイズに到達する正直な方法は、エンコードして測定することだけです。

このツールは、17段階の公開された品質を、95から20まで順に試し、それぞれでエンコードして結果を測定します。上限未満になった最初の段階が答えで、レシートにも記載されます。つまり結果を再現できます。同じファイルを同じ品質で処理すれば同じバイト列になり、他の人にも手順を伝えられます。

最低品質でも収まらない場合、ツールはピクセル寸法を12%小さくして、品質の段階をもう一度試します。これを最大9回行います。人が次に行う操作も同じですが、それを黙って行うのは不誠実です。そのためレシートには、上限に品質だけで到達したのか、品質とリサイズで到達したのかを記載します。どうしても到達できない場合は、目標を外れたファイルを渡すのではなく、達成できた最小サイズとともに失敗として報告します。

選択中に表示される推定値は、ピクセル数を使った算術であり、推定値として表示されます。レシートの数値はすべて、これからダウンロードするファイルの測定値です。

メールに実際に収まるサイズ

最も一般的な上限はメールの制限です。公開されている数値は、特定の理由で誤解を招きます。これはファイルではなく、エンコードされたメッセージの制限だからです。添付ファイルはbase64でエンコードされ、サイズが正確に3分の1増えます。さらにMIMEによって76文字ごとに改行が加わります。そのため「25 MBの上限」で実際に添付できるファイルは約18.3 MBで、この差が送信失敗の原因になります。

予算の列はどこかの数値を引用したものではなく、記載された上限から計算されています。そのため検算できます。上限からヘッダーと境界用の5 kBを引き、base64の4/3の比率と改行のオーバーヘッドで割った値です。1通に複数の写真を添付するなら、1枚あたり1-2 MBが無理のないサイズで、メッセージ自体の余地も残ります。

圧縮が適切でない場合

スマートフォンから直接取得した写真は、約1200万画素で4 MBほどあります。その4分の1に圧縮するのは簡単ですが、多くの場合は不要です。本当の問題は寸法であることが多いからです。Webページで幅800ピクセルで表示する画像を、幅4032ピクセルにしても利点はありません。品質設定ではこの問題を解決できません。

そのため、まず長い辺の上限を設定してみてください。このページにその項目があるのもそのためです。寸法を半分にするとピクセル数は4分の1になり、品質スライダーで得られる効果よりはるかに大きく節約できます。画像をそれ以上大きく表示しないなら、見た目のコストもありません。リサイズツールは、寸法の変更だけが目的の場合に使うツールです。

圧縮が適切でないケースは、ほかにも2つあります。スクリーンショットや図は、平坦な色、鋭いエッジ、文字で構成されています。PNGまたは可逆WebPが適しており、JPEGエンコーダーをかけるとすべての文字の周囲にリンギングが生じ、可逆圧縮された元画像より大きくなることもあります。もう1つは、すでに強く圧縮された画像です。再度圧縮しても改善できません。処理のたびに新たな非可逆劣化が前の劣化に重なります。このツールは、より小さくても見た目が悪くなったファイルをそのまま報告します。

JPEG、WebP、PNG

ブラウザーで表示する写真なら、WebPが標準的な選択です。同じ見た目の品質で、通常JPEGより25から35%小さく、現在のすべてのブラウザーで読み込めます。別のものでも開く必要がある場合はJPEGを選んでください。古いデスクトップアプリケーション、印刷工程、文書テンプレート、受け取った人がダブルクリックして開くファイルなどです。PNGは、平坦なグラフィックや文字、または透明度を維持する必要がある場合にだけ選んでください。

PNGには品質設定がまったくありません。これはよくある混乱の原因です。定義上、PNGは可逆です。交換できるものがありません。「PNGを圧縮する」とは、サイズを受け入れるか、寸法を小さくするか、変換することです。可逆WebPなら通常、ピクセルを同一に保ったまま25から30%小さくできます。追加費用のない選択肢です。

正直な制限が1つあります。ここで使うエンコーダーはブラウザーに組み込まれたもので、mozjpegやcwebpではありません。同じ見た目の品質なら、コマンドラインのエンコーダーのほうが通常10-20%小さいファイルを生成します。その代わり、タブの外に出ていないファイルを、アカウントも待ち行列もなく、1秒未満で処理できます。どこかに送る前の1枚の画像ならこちらのほうが適した選択ですが、4万枚のライブラリには適していません。

圧縮するとメタデータも削除される

このツールの出力はピクセルからエンコードされるため、EXIFブロック、GPS座標、XMPパケット、C2PAマニフェストは引き継がれません。通常は望ましい動作ですが、写真家の著作権表示も一緒に失われるため、そうでない場合もあります。

副作用ではなくメタデータの削除が本来の目的なら、メタデータツールを使えば、画像自体に触れずに処理できます。コンテナを再構築し、圧縮済みの画像データをバイト単位でそのままコピーするため、再エンコードされず、品質も失われません。EXIFを削除するために圧縮するのは、無料でできることに実際のコストを払うことになります。