AVIF を BMP に変換

AVIF は 2019 年、写真を携帯回線で送れる大きさにするために設計されました。BMP は 1987 年、Microsoft がプログラムにそのままメモリーへ読み込ませることだけを目的に設計した形式で、どちらの端にも圧縮がありません。この 2 つを組み合わせると、このサイトのどのペアよりも大きな倍率になります。

どちらの形式も誤用されているわけではありません。BMP が悪い形式なのではなく、目的が 1 つだけの形式なのです。デコーダーを実装したくないソフトが素直に読める形——ヘッダーに幅が書いてあり、あとは順番に画素が並んでいるだけ——というのがその目的で、その代償として容量が大きくなります。画面が 640 ピクセル幅で、ビットマップがフロッピー 1 枚に収まっていた時代には妥当な代償でした。3000 万画素のカメラがこの鎖の反対側に現れたことで、まっとうな設計がぎょっとするようなファイルになっただけです。

計算式は決まっていて、写真の中身とは関係ありません。幅 × 高さ × 3 バイトにヘッダーを足しただけです。1000×1000 のアイコンで 3 MB、3000×2000 の写真で 18 MB、6000×4000 なら 72 MB になります。

これを取り込んだ元のファイルと比べてみてください。Web で配信される 3000×2000 の AVIF は、たいてい 0.5 MB 未満です。何も特別なことをしなくても倍率は 50 倍を超えます。ロゴやチャート、インターフェース用の画像のような平坦な絵柄では AVIF はさらに強く圧縮するので、倍率は数百倍にまで跳ね上がります。写真の中身は何も変わっていません。変わったのはストレージとしての正直さだけです。フォルダーごと変換する前に、まず自分のファイルでこの数字を確かめておく価値があります。倍率次第でバッチがどこかに収まるかどうかが決まるからです。

容量が寸法だけで決まるため、この変換に画質設定はなく、そもそも存在しようがありません。BMP には調整するつまみがありません。グラデーションの一部でも白い余白の一部でも、1 画素は同じ 4 バイトを消費します。

したがって最大幅の設定だけが唯一のレバーで、画素を安くするのではなく、画素の数そのものを減らすことで効きます。幅を半分にすると容量は 4 分の 1 になります。両方の寸法が同時に縮むからです。18 MB の 3000×2000 は、1500×1000 にすると 4.5 MB になります。480 ピクセルしか求めていない組み込みディスプレイが行き先なら、これは知っておく価値があります。フル解像度のビットマップは無駄というだけでなく、機器が保持できる容量を超えてしまうことがあるからです。リサイズせずに小さな画面へビットマップを送ることが、この変換で誰も使えないファイルができる最大の原因です。

BMP は 1 つの形式というより小さなファミリーです。画素をフルカラーとして格納することも、最大 256 色のインデックスパレットとして格納することもでき、ビット深度もいくつかあります。「BMP」とだけ言われても、それだけでは文が終わっていません。この変換が書き出すのは 1 画素 4 バイトのフルカラービットマップです。

ほとんどのソフトが読むのはこの形式ですが、あらゆる場面で求められているわけではありません。よくある例外が小型ディスプレイのファームウェアです。メモリーが限られた組み込みパネルは、フレームバッファーの構造に合わせて 24 ビットや 8 ビットのインデックスパレットを名指しで要求することがあります。変換する前に仕様書を確認し、ここで作れない種類が指定されている場合は、IrfanView や GIMP を使って機器が求めるビット深度へ 1 手順で保存し直せます。

AVIF は 1 チャンネルあたり最大 12 ビットと広色域を格納できます。これが AVIF が Web で HDR 写真を運べる理由です。ここで書き出す BMP は 1 チャンネル 8 ビットの普通の RGB で、この形式を読むすべてのソフトが期待する形です。

普通の Web 画像なら何も失われません。もともと 8 ビットしか持っていなかったからです。HDR ソースの場合は余分な階調が捨てられ、見た目としては空が平板になったり、ハイライトがなだらかに落ちずに白く飛んだりする形で表れます。それが問題になるなら、階調のマッピングを自分で選べる編集ソフトで意図的に落とすべきで、1990 年生まれの形式にたどり着いた副作用として起きるべきではありません。

AVIF は完全なアルファチャンネルを持ちますが、BMP を読むどのソフトも期待しているとおり、BMP は持ちません。透けている画素は変換前に選んだ色で塗りつぶされ、その塗りつぶしは元に戻せません。透明度が隠されるのではなく、置き換えられるのです。

中立な色ではなく、画像が実際に置かれる背景の色を選んでください。アンチエイリアスの掛かった輪郭は部分的に透けているので、選んだ色と混ざり合います。想定どおりの背景の上では縁がなめらかに保たれますが、別の背景に置くと、絵柄の周りにうっすらとハローが見えます。これは、いったん白の上で平坦化した画像を暗い背景に置いたときに現れる典型的な症状で、AVIF からやり直さない限りあとから消せません。計器やパネル用なら、正しい色はたいてい渡された仕様書に書かれているので、判断ではなく確認で済みます。

これがこの変換をブラウザーで行う理由でもある非対称性です。BMP を待っている側のソフト——計器、パネル、レジ端末、20 年前の Windows ユーティリティ——には AVIF のデコーダーがなく、これからも実装される見込みがありません。動いている OS 自体に持っていないこともあります。

ブラウザーにはあります。AVIF は Web ページに描画するのと同じコードでデコードされるので、ファイルをダブルクリックしても何も起きない機械の上でもこの変換は動き、その機械がそのまま扱えるファイルを作り出せます。管理されたシステムにコーデックパックを入れるより確実で、何も新しく入れることが許されない機械では、これが唯一の答えになります。

境界のところだけ変換し、AVIF はそのまま残してください。容量はごくわずかで、透明度もフルカラーの階調もそのまま保っており、行き先が変わったり機器が更新されたりしたときにまた必要になるのはこちらです。

人に渡す相手が機械ではなく人間なら、BMP を送るのはほぼ確実に判断ミスです。受信箱を圧迫し、共有ドライブを詰まらせます。ここで壊さざるを得なかった透明度を保ったまま、PNG がはるかに小さい容量で可逆に運べる中身しか BMP には入っていません。BMP はそれを要求してきた機器のための伝送用の形式であって、保存用の形式として扱うと、本来なら 2 ギガバイトで済む画像群のために 100 ギガバイトを抱えることになります。

AVIF は複数のフレームを持てます。土台になっている動画コーデックから受け継いだ性質です。BMP は静止画 1 枚を持つだけで、2 枚目という概念そのものがありません。

短いアニメーションを持っているなら、この変換は望んだものの劣化版ではなく、そもそも行き先を間違えています。動きが目的なら MP4 が妥当な容量で動きを保ちますし、GIF なら古いソフトでも理解できます。どちらも、非常に大きなファイルに 1 コマだけ収めるより良い答えです。機器側が本当に一連のビットマップを求めているなら——一部の小型ディスプレイはそうです——先にフレームを取り出し、それぞれを変換する必要があり、それはドロップゾーンではなくスクリプトの仕事です。

最大 100 ファイルまでまとめて置けます。それぞれ順番に変換され、拡張子だけ変わった名前のまま、まとめて 1 つの ZIP として戻ってきます。無料枠のバッチはここで打ち切られ、それを超えるファイルはキューに積まれるのではなく除外されます。アップロードは発生しないので、待ち行列も、アカウントも、1 日あたりの上限もありません。

計画すべき制約はアップロードではなく出力のほうです。3000×2000 の写真 40 枚は、アーカイブを組み立てている間、ブラウザーのタブの中で 7 億バイト以上のビットマップとして保持されることになり、他の形式なら軽々こなせるバッチも、ここでは軽くありません。少しずつのグループに分けて変換し、こまめに保存し、行き先がフル解像度を必要としないなら最大幅を設定してください。