BMP を AVIF に変換

AVIF ファイルは構造としては、Alliance for Open Media が 2019 年に策定したコンテナーに収めた AV1 動画の 1 コマです。動画コーデックの圧縮技術をそのまま受け継いでいるので、同じ見た目の画質なら写真では WebP や JPEG を上回ります。

コストのほうも受け継いでいます。この形式の弱点として遅い符号化が挙げられ、このサイトの処理系もそれに沿っています。大きな写真の場合、ほかの変換ではデコードのほうが時間のかかる工程ですが、AVIF ではエンコードのほうが時間のかかる工程になります。1200 万画素のビットマップ——4000×3000、BMP として 36 MB——は、進捗バーが気休めではなく実際に仕事をしていると感じられるくらいの時間がかかります。この非対称は普段の直感を裏返すので覚えておく価値があります。ビットマップは巨大で読むのは軽く、AVIF は小さいのに書くのは重いのです。

AVIF は 1 チャンネルあたり 12 ビットを持て、広色域を記述できます。この 2 つの能力こそがこの形式の存在理由の大半で、HDR 写真の配信形式として使われる理由でもあります。

BMP は 1 チャンネルあたり 8 ビットの普通の RGB しか持ちません。元データに広い色域はなく、余分なダイナミックレンジもなく、色プロファイルもありません——レジストリには BMP 用のメタデータの入れ物自体が記録されていません。AVIF に用意された余裕は空のままで、この変換で得られる利点は圧縮だけです。それは確かな利点ですが、それだけだと知っておく価値があります。AVIF について書かれるものの多くは、BMP には届かない能力についての話だからです。形式は情報を足すことができず、届いたものを記述できるだけです。ここに届いたのは、Microsoft が 1987 年に発表した形式が持つ 8 ビットの sRGB です。

処理は WebAssembly としてブラウザーのタブの中で、手元の機械のプロセッサーで動きます。サーバーが代わりに作業してくれるわけではなく、それが何もアップロードされない理由であり、大きなビットマップの束を変換するのが「始めて、あとで戻ってくる」種類の作業になる理由でもあります。

実際の感覚としては、そこそこの画像 1 枚なら少し待つ程度、40 枚のスキャナー出力ならコーヒーを 1 杯淹れる程度です。それが許容できず、相手が幅広い層なら、WebP がすぐ隣のページにあり、符号化時間はごくわずかで済み、容量も AVIF とわずかな差に収まることが多いです。これはこの変換の欠陥ではありません。同じ符号化をサーバーで行っても同程度の作業量が必要で、単に誰かのプロセッサーを借り、そのためにファイルを送る必要が生じるだけです。この時間は、写真が機械から一度も出ていかないことへの正直な対価です。

レジストリは AVIF を「現代的なブラウザーが対応」と分類しており、この言葉は WebP や JPEG に与えられる「すべて」という言葉の隣で、実質的な意味を持っています。現在のデスクトップとモバイルのブラウザーは AVIF を読めますが、古い機器や一部のアプリ内ブラウザー、多くのメールソフトは読めません。

つまりこれは送るための形式ではなく配信するための形式です。添付ファイルとして、あるいは他人に渡すファイルとしては貧弱な選択で、自分の機械で開けることは相手の機械について何も語りません。デザインや編集ツールでも同じ注意が必要です。対応状況にはばらつきがあり、ブラウザーで完璧に表示される AVIF が、同僚が文書に貼り付けられないファイルであることもあります。

対応の隙間を乗り切る仕組みが picture 要素です。複数の候補を順番に並べ、それぞれに種類を指定しておくと、ブラウザーは自分が理解できる最初のものを選びます。AVIF を先頭に、その次に WebP、最後に JPEG を置けば、判定用のコードを走らせなくても、訪問者ごとにブラウザーが実際にデコードできる最小のファイルが届きます。

つまり同じビットマップを 2 回変換することになり、このページのバッチ変換が WebP のバッチ変換とセットで行われることが多いのはそのためです。WebP から AVIF を作るのではなく、この順番で行う価値があります。それぞれの非可逆エンコーダーは何を捨てるかを独自に判断するので、2 つを重ねると両方の損失を抱えたファイルになり、節約にもなりません。配信用の各形式は、常にビットマップ自体から作ってください。

AVIF はアルファチャンネルを持ち、この経路では画像を平坦化したり背景色を尋ねたりしないので、32 ビットのビットマップは透けている部分をそのまま保ちます。ここに来るファイルの大半を占める 24 ビットのファイルには、そもそも保つべき透明度がありません。

画質の既定値は 82 で、このサイトの非可逆な変換先すべてに共通する数字です。この尺度は画像ではなく符号化器に属していることを覚えておく価値があります。AVIF の 82 と JPEG の 82 は、同じ量の損失でも同じ容量でもないので、2 つの形式を比べるなら設定ではなく出力そのものを比べてください。壊れ方も違います。JPEG はブロック状の乱れや輪郭のリンギングとして表れますが、AVIF は細かい質感をなだらかにぼかす形で表れ、元画像と並べるまで気づきにくいという性質があります。

相手に古い機器が含まれるとき。画像が小さく、差がわずか数キロバイトしかないとき。硬い輪郭を持つ平坦な絵柄で、AVIF の優位が縮まり、逆転すらするとき。そして何百ファイルも変換していて、符号化にかかる時間そのものが制約になっているとき。

AVIF がコストに見合うのは、picture 要素を通じて現代的な相手に配信される大きな写真の場合です。それは既定の選択ではなく特定の場面で、これに反する説明をするページがあれば、それは新しい形式を客観的に説明しているのではなく売り込んでいるだけです。判断は 1 分で済みます。代表的なビットマップ 1 枚を両方の形式に変換し、2 つの容量を並べて、ファイルごとに 2 回符号化しマークアップにフォールバックを書く手間に見合うかどうかを決めてください。明らかに見合うこともあれば、明らかに見合わないこともあります。

これは容量と符号化時間を同時に改善する唯一の調整です。効果は幅ではなく画素数に比例するので、ビットマップの幅を半分にすると、符号化器が処理する画素はその 4 分の 1 になります。

最大幅は、画像が表示される最大の幅に、高精細画面向けに 2 倍した値を設定してください。4000×3000 のスキャンを 2000×1500 に縮小しても、ほとんどの表示場所より依然として大きく、AVIF の符号化はおよそ 4 分の 1 の時間で終わります。

フォルダーごと置けば、それぞれ手元の機械で順番に変換され、拡張子だけ変わった名前のまま、まとめて 1 つの ZIP として戻ってきます。上限は 1 ファイルあたり 100 MB で、無圧縮のビットマップにするとおよそ 3300 万画素分に相当します。

バッチはダウンロードではなく符号化を中心に計画してください。ファイルは 1 つずつ順番に処理されるので、かかる時間はおおむね個々の符号化時間の合計になり、いちばん大きな画像が全体を左右します。3300 万画素のビットマップ 1 枚が、小さな画像 30 枚より時間がかかることもあります。明らかに大きすぎるファイルを先によけて縮小しておくことが、このバッチに対してできるどんな工夫よりも効果があり、待ち時間だけでなく出力自体の質も改善する唯一の変更です。