ブラウザが画像を圧縮するとき、何が起きているのか

圧縮されたファイルを、ピクセルの格子に戻します。ブラウザはこれをネイティブコードで、プラットフォームが用意していればハードウェア支援も使って行い、JPEG、PNG、WebP、AVIFを扱います。AppleのプラットフォームではHEICも扱えます。OSがそのデコーダーをすでに載せているからです。

デコードは、ファイルに対しては可逆です。ファイルが記述しているとおりのピクセルが、そのまま得られます。損失はもっと前、そのファイルを作った何かが符号化した時点で、すでに起きています。

スマートフォンのカメラは、センサーの生の向きと、それをどう回すかを示す別のEXIFタグを保存します。このタグを無視するソフトウェアは、横倒しの写真を吐き出します。タグを適用するとは、他の処理が触れる前にピクセルの格子そのものを回すということです。回してしまえばタグはもう要らなくなります。再エンコードでメタデータが落ちるのは、ひとつにはこれが理由です。

目標のサイズに元の解像度のままでは届かないとき、画像を縮小します。体感的な画質が、静かに稼がれたり失われたりするのはここです。安価なボックスフィルターは隣り合うピクセルを平均して全体を眠くしますし、Lanczosフィルターはより広い近傍に重みを付けて輪郭を保ちます。

リサンプリングは正真正銘の破壊的処理で、捨てたピクセルは戻ってきません。それでも、小さな目標に届くための手段としてはいちばん破壊が少ないことがよくあります。エンコーダーが予算を丸ごと使っても描き切れないようなディテールを、先に取り除いてくれるからです。

非可逆なのはここです。JPEGは明るさと色の表現に変換し、色の解像度を一部捨て（目はほとんど気づきません）、画像を8×8のブロックに分け、それぞれを周波数成分に変換し、そして量子化します。高い周波数のディテールを丸めて捨てる処理です。品質パラメーターとは、この丸めの粗さのことです。その後はすべて可逆のエントロピー符号化で、だからこそ最適化したハフマンテーブルやプログレッシブスキャンは、画質を犠牲にせずバイト数を減らせます。

ブラウザ内蔵のエンコーダーは中身の見えない箱です。品質の数値を頼むことしかできません。エントロピーテーブルの最適化も、ベースラインかプログレッシブかの選択も、リサンプリングフィルターの指定もできず、ある設定で何バイトになるかを試さずに知る方法もありません。

WebAssemblyにコンパイルしたコーデックは、そのすべてを取り戻してくれます。代わりに払うのは、ダウンロードするバイト数です。ToolZoolはデコードをブラウザに任せず、パイプライン全体をこの方式で動かしています。デコード、向きの補正、リサンプリング、エンコードのすべてがRustで書かれてWebAssemblyになり、バックグラウンドのワーカーで動きます。理由は3つ、どれも実務的なものです。

• 探索には何度もエンコードが要ります。 サイズをぴったり合わせるには、同じ画像を5回か6回符号化することになります。エンコーダーを自前で持っているからこそ、それが安く、何度でも同じようにできます。
• デコーダーは「ノー」と言えなければなりません。 60,000 × 60,000ピクセルだと宣言するファイルは、メモリを確保する前に拒否しなければなりませんし、途中で切れたファイルは半分の画像を返すのではなく失敗しなければなりません。そこはブラウザのデコーダーが独自に判断するところです。こちらのものは、限界を明示して守らせます。
• 同じ入力からは同じ出力が出なければなりません。 ブラウザのデコーダーは、色の扱いや壊れたファイルへの対応が実装ごとに違います。両端を自前で持つパイプラインなら、どの端末でも同じバイト列が出ます。結果を検証できるのは、それがあるからです。

代償は正直に書いておきます。そのエンジンはダウンロードです。ファイルを選んだときにだけ取得されるので、このページのような読みものを読むかぎり、その分を払うことはありません。

目標のファイルサイズが決まっているとき、良いエンコーダーと素晴らしいエンコーダーの差は数パーセントです。品質スライダーを勘で決めるのと、正しい値を探索するのとの差は、それよりずっと大きい。許容量の60%のところに着地した勘は、本来受け取れたはずの画質を3分の1捨てたということだからです。サイズを指定して圧縮するという考え方はまるごとこれですし、50 KBの制限に収めるでは、いちばん厳しい側で探索が何を買ってくれるのかを見ていきます。