JPEG、PNG、WebP、AVIF：中身で選ぶ画像形式

顔、風景、階調やノイズを含むもの——いわゆる連続階調の画像は、非可逆コーデックとの相性が良好です。情報の多い部分では、目が小さな誤差を許してくれるからです。どこでも受け付けてもらえるという理由で、JPEGが安全な既定値になります。非可逆のWebPは同じ見た目の品質を明らかに少ないバイト数で実現するので、送り先が認めているならそちらが有利です。

ただしToolZoolでこれをする場合はひとつ注意があります。当サイトの圧縮ツールがWebPを書き出せるのは可逆モードだけで、写真ではJPEGの数倍の大きさになります。サイズ制限のある写真では、ここはJPEGを選んでください。その差が生まれる理由は圧縮ツールのページに書いてあります。ライセンスが両立しないか、WebAssemblyでビルドできないCのツールチェーンを必要とするかで、配布できる非可逆WebPエンコーダーが存在しないためです。

ロゴ、アイコン、図版、画面のスクリーンショットは、くっきりした輪郭と、同じ色が広がる面でできています。非可逆コーデックは輪郭の扱いが苦手で、文字のまわりに目に見えるにじみが出ます。しかも持ち込まれたノイズ自体を符号化するのに費用がかかるため、同じ画像を可逆のPNGにしたときより大きくなることも珍しくありません。

JPEGにはアルファチャンネルがありません。透過のあるPNGをJPEGに変換すると、透明だった部分は塗りつぶされます。たいていは黒、ときどき白、望んだ色になることはまずありません。PNGとWebPはどちらもアルファに対応しているので、透過がある画像ならこの2つが候補になります。

AVIFは、同じ品質で比べたときのファイルサイズでWebPを上回ります。とくに低ビットレートで差が出ますし、現行のブラウザはどれも表示できます。問題はエンコードです。JPEGやWebPと比べて劇的に遅く、はるかに重い。ビルドサーバーではなくスマートフォンの上で符号化するとなると、この差は効いてきます。

ToolZoolは現時点でAVIFを読むことも書くこともできません。どちらの方向にもAV1コーデックが必要で、保守されているものはどれもWebAssembly向けにビルドできないCのライブラリだからです。そのためAVIFのファイルは、いったん別のもので変換していただく必要があります。多くのiPhoneが既定で作るHEICについても事情は同じです。

そのフォームは何を受け付けるのか。弾かれる「より良い形式」は、良くありません。まず受付形式の一覧を読み、その枠の中で最適化してください。条件を満たしているはずのファイルがそれでも拒否されるなら、アップロードフォームにファイルを弾かれる理由で、フォームが実際に走らせている4つのチェックを順に見ていきます。形式のあいだを行き来したいときは、画像圧縮ツールがJPG、PNG、WebPを読み、JPEG、PNG、可逆WebPを書けるので、この範囲なら変換ツールとしても使えます。