GIF を BMP に変換 — 機器が求める形に

この 2 つの形式はほぼ同時代——1987 年と 1990 年——に生まれ、同じ問題を逆方向から解決しています。GIF は最大 256 色のパレットへの索引を保存し、LZW 圧縮で圧縮する前で 1 ピクセルあたり 1 バイトです。ここで書くビットマットは、青・緑・赤の 3 値をすべてのピクセルに、無圧縮で保存します。

ですから膨張は 1 つの要因ではなく、2 つが掛け合わさります。GIF が 1 バイトで済ませていたところを 3 バイトにし、そもそも GIF を小さくしていた LZW の節約も一切残りません。40 KB の GIF がその 10 倍のビットマットになるのは珍しくなく、GIF が最も得意な平らな絵で同じ色が続く素材ほど、比率はさらに悪くなります。

計算は短く、見積もりの余地がありません。幅を 3 倍して 1 行あたりのバイト数を出し、4 の倍数に切り上げ、高さを掛けて、54 バイトのヘッダーを足します。480 かける 270 の GIF なら 1 行 1,440 バイト（端数なし）、ピクセル部分が 388,800 バイト、合計 388,854 バイトです。

元の絵の内容はこの数字を変えません。激しくディザリングされた写真も、真っ赤な四角形も、同じ 480 かける 270 なら同じ大きさのビットマットになります。すべてのピクセルを文字どおり保存するからです。この予測可能性こそ、機器がビットマップを求める理由です。ヘッダーだけを見ればファームウェアはバッファーを確保できます。

ここで書くビットマップの 2 つの慣習は、間違いに見えて間違いではありません。行は画像の下から上へ向かって保存され、各ピクセルのチャンネルの順序は赤緑青ではなく青緑赤です。どちらも元の仕様どおりで、BMP を読むソフトが期待するとおりです。

3 つ目はパディングです。すべての行は 4 バイトの倍数まで詰められるので、幅 101 ピクセルの画像は 303 バイトのピクセルデータのあとに 1 バイトの何もない部分が続き、1 行 304 バイトになります。幅かける 3 を 1 行のバイト数だと決めてかかるコードは、画像が斜めにずれた結果を作ります。これは自作の BMP リーダーでいちばんよくあるバグです。

BMP は 1 枚の絵しか持てません。連続、遅延、ループという概念がなく、ここへ届いたアニメーション GIF は開いたときのコマになり、残りは捨てられます。レジストリはこれを組み合わせの注意事項として明記しており、発見任せにはしていません。

ビットマットを求める行き先にとって、これはめったに問題になりません。BMP を求める機器は定義上、静止画を求めているからです。1 コマ目が欲しいコマかどうかは確認する価値があります。多くの GIF は中身が始まる前に空白やタイトルカードで開きます。

色が 256 色しかない画像なら小さいファイルになるだろうという予想は理にかなっていて、パレット形式なら実際そうなります。ビットマップの仕様自体、色テーブル付きの 8 ビット BMP をまさに許していて、GIF にほぼそのまま対応します。

この変換機はそれを書きません。作り出すすべてのビットマップは 24 ビットなので、6 色しか使わない GIF も同じ寸法の写真とまったく同じバイト数になります。相手の機器が単に BMP を受け付けるだけでなく 8 ビットパレット形式のビットマットを厳密に求めるなら、このファイルでは足りません。機器が拒否してから知るより、変換前に確かめておく価値があります。

GIF はパレットの 1 エントリを透明として指定できます。ここで書くビットマットには、24 ビット、3 チャンネル、余白なしで、アルファチャンネルがまったくありません。だから符号化の前に、それらのピクセルには何らかの値を与える必要があります。

背景色のオプションがその値を決め、既定は白です。機器の上ではこれを意図的に選ぶことが重要です。インターフェースが黒い表示先のアイコンは白ではなく黒に平坦化すべきで、あとで反転するのではありません。システムがクロマキーを期待するなら、後の工程が見つけてくれると期待せず、その色そのものを設定してください。

この変換に画質スライダーはなく、あり得ません。無圧縮は無圧縮で、取引する対象がないからです。唯一のレバーは最大幅で、ピクセルを書く前に絵を縮小するので、ファイルサイズは二乗で変わります。

幅を半分にすればビットマットは 4 分の 1 になります。行き先が小さな表示器ならこれはたいてい正しい選択です。128 ピクセル幅のパネルは 640 ピクセルの元データから何も得るものがなく、ここで縮小しておけば、機器がより大きなバッファーを持つ必要もなくなります。

このサイトのすべてのラスター変換は無条件にメタデータを取り除きますが、この組み合わせではその規則はほとんど何もしていません。GIF に EXIF ブロックはなく、カメラの機種も GPS 座標もありません。多くて、それを書いたソフトが残したコメント拡張とアプリケーション拡張くらいです。

ビットマップ形式にはそもそもそれを置く場所がありません。ヘッダーは寸法とビット深度をほぼ説明するだけです。出てくるのはピクセルと形状だけです。画面録画ソフトがコメントブロックに自分の名前を残していたとしても、その名前は渡りません。

GIF はブラウザー自身の画像対応で復号され、ビットマップのヘッダーとピクセル行は同じタブの中で JavaScript によって書かれます。この経路にサーバーはなく、アップロードも登録もなく、タブを閉じればファイルはなくなります。

これはこの組み合わせでは見た目以上に重要です。BMP に変換される対象はしばしば社内のもの——コントロールパネルの画像、商品ラベル、計測器の起動画面——だからです。ビットマットになるために誰か他人の基盤を通る必要はありません。