BMPをPNGに変換

同じピクセルを、ごく一部のサイズで

BMPは通常、まったく圧縮されていません。すべてのピクセルが1つあたり3〜4バイトでそのまま書き込まれ、各行は4バイト単位に揃えるための詰め物が入ります。そのため1920×1080のスクリーンショットは約8 MB、1200万画素の写真は36 MB近くになります。PNGはまったく同じピクセルをロスレスで圧縮して保存するので、画像は何も変わらず、ファイルは一般的に5〜20分の1になります。平坦な部分が多いスクリーンショットや図なら、その比率は上限に近くなります。トレードオフがまったくない、珍しい変換です。

結果について確認しておきたい点が1つあります。32ビットBMPの透過は当てになりません。これはここでの処理のせいではありません。 もともとのWindowsビットマップのヘッダーにはアルファチャンネルという概念がなく、各ピクセルの4バイト目は単に使われていませんでした。後のヘッダーで正式に定義されましたが、今でも古い形式で書き出すソフトは多く、新しい形式を無視するデコーダーも多くあります。そのため、作成したソフトでは透明に見えるBMPが、アルファのバイトを詰め物として読まれて不透明にデコードされることがあります。透過が重要なら、PNGを使う前に確認してください。

もう1つの癖は行の順番です。BMPは慣例として行を下から上の順に保存します。これは初期のグラフィックハードウェアのメモリの扱い方を受け継いだもので、上から下の順のファイルは高さを負の値にして示します。デコーダーはどちらも扱えるので、実際には気づくことはありません。書きかけのBMPや途中で切れたBMPが、途中で切れるのではなく上下逆に表示されるのは、これが理由です。

一般的なWindowsのBMPはすべて変換できます。この形式の特殊な部分、つまりRLE圧縮の4ビット・8ビットのビットマップ、90年代初頭のOS/2ヘッダー、まれなJPEG埋め込み形式は、デコーダー次第です。そのどれかが受け付けられない場合は、崩れた画像を出力するのではなく、その旨が表示されます。

ほかの目的には

PNGをさらに小さくするなら、oxipng -o 4 out.png や optipng で、ピクセルを1つも変えずにさらに10〜30%小さくなることがよくあります。pngquantはパレットに減色することでさらに大幅に小さくします。これは非可逆ですが、スクリーンショットや図ならたいてい見た目に違いは出ません。

フォルダー単位で変換するなら、ImageMagickの magick mogrify -format png *.bmp で1行ですべて変換でき、libvipsなら非常に大きな画像でも、わずかなメモリで同じ処理ができます。BMPが図ではなく写真なら、そもそもPNGは適した変換先ではありません。JPGなら、誰にも見分けられない画質の差で、サイズは10分の1になります。