BMP を JXL に変換

JPEG XL は JPEG 委員会から生まれ、2022 年に ISO/IEC 18181-1 として標準化されました。可逆にも非可逆にも圧縮でき、1 チャンネルあたり最大 32 ビットを扱え、アルファチャンネルとアニメーションを持てます。配信用ではなく保管用の形式として明確に狙って作られています。

これは、大きな無圧縮ビットマップを持っている人が求めているものそのものに見えます。BMP はいわば偶然のマスターです。無圧縮なのは、この形式が定義しているランレングス圧縮モードを誰も使わないからで、忠実さを選んだ結果ではありません。画素を保ったまま 1 画素 3 バイトの負担をなくす形式へ移すのは自然な発想です。レジストリでも JPEG XL の用途としてアーカイブと写真が挙がり、BMP の弱点として大容量が挙がっています。紙の上ではこの 2 つは互いのために作られたようなものです。このページの残りは、その読みと、実際にこの変換ツールが渡せるものとの間にある距離についての話です。

この変換の符号化器は画質 82 の非可逆 JPEG XL を書き出します。このサイトの非可逆な変換先すべてに共通する既定値です。可逆モードは書き出さず、切り替える設定もこのページにはありません。

つまり先ほどの発想はこのページでは実現しません。手に入るのは、小さくて現代的でよく圧縮された画像であって、最初に持っていたビットマップそのものではなく、しかも多くのソフトがまだ開けない入れ物に入っています。この組み合わせは、どちらか片方の問題より厄介です。この節を脚注ではなく前のほうに置いているのはそのためです。アーカイブのつもりで非可逆な処理を黙って行ってしまえば、アーカイブが本来防ぐべき結果そのものが起き、それに気づくのは何年も先になります。

PNG は可逆で、1996 年から標準化されており、あらゆるブラウザーとあらゆる編集ソフトが読め、BMP に多い平坦な素材ではよく圧縮されます。960×640 の写真で測定したところ、PNG では 468 KB、BMP では 1.84 MB になり、平坦な絵柄ではさらに差が開きます。

可逆な JPEG XL ほど効率的ではありませんが、いつでも使え、正確で、30 年経っても開けます。アーカイブ形式に求められているのはまさにこの性質だけです。ここで変換されているビットマップ自体がその証拠です。生き残っているのは形式が単純で誰もが読めるからであって、優れていたからではありません。マスターには PNG を選び、画像の行き先が決まってから非可逆な形式に戻ってきてください。

BMP ファイルの多くは写真ではなくページです。他に選択肢のなかった画像処理ソフトが書き出したスキャンや FAX です。JPEG XL はそれらに提供できるものがありません。文字が並んだページを非可逆に符号化するのはまさに間違った操作で、記録管理システムも同僚も規制当局も受け付けない入れ物です。

そうしたファイルには PDF が納品用の形式で、アーカイブの仕様がよく指定するのは TIFF です。このサイトはどちらもビットマップから直接変換できます。画像そのものより文字が重要なら、BMP から TXT への変換が光学文字認識でページを読み取ります。この 3 つのうちどれが本当に欲しいかを決めるほうが、フォルダーを 2 回変換するより早く済みます。

レジストリは JXL のブラウザー対応を「部分的」と記録しています。PNG、JPEG、GIF、WebP に与えられている「すべて」という言葉の隣にです。これは新しい形式にありがちな一時的な状態ではなく、標準化されて以来ずっと不揃いな受け入れられ方をしてきたもので、何ヶ月ではなく何年も落ち着いていません。

実務上の結果として、JXL は誰かに送るファイルでも、代替なしでページに置くファイルでもありません。自分だけが使う、ソフトを管理できる機械のためのファイルです。それは正当な用途ですが、この形式の技術的な長所が示唆するよりずっと狭い用途です。レジストリはこの形式の位置づけを「ニッチ」とし、対応のばらつきを既知の問題として記録していますが、どちらも普及についての編集上の判断であって、技術についての判断ではありません。技術面では、JPEG XL はこのレジストリの中でもっとも強力な静止画形式です。

レジストリが挙げているのは GIMP と ImageMagick です。どちらもきちんと読め、どちらも無料なので、この形式は封じ込められているわけではありません。ただ、ファイルをダブルクリックするときに大半の人が手元に持っているソフトではありません。

OS のプレビュー機能、ストックフォトの管理ソフト、主要な編集ソフトの多くは、いまだに何も表示しません。フォルダーごと変換する前に自分の機械で試しておく価値があります。プレビューできないファイルの束は、1 ヶ月後に発見するにはかなり厄介なものだからです。

BMP は加工されていないきれいな画素を与えます。非可逆エンコーダーを一度も通っていないので、以前の圧縮の痕跡が何もなく、どの符号化器にとってもこれ以上ない入力です。もとの場面になかったノイズを符号化するために無駄なビットを使う必要がないからです。

それ以外は何も与えません。形式が持てる 32 ビットに対して 8 ビットしかなく、広色域の情報のない普通の RGB、色プロファイルも EXIF も撮影データもありません——レジストリには BMP 用のメタデータの入れ物自体が記録されていません。JPEG XL の余裕は空のままです。元データに入れるものが何もないからで、開くソフトはどれも sRGB として読み込みます。ビットマップが校正済みの機器やカラーマネジメントされたスキャナーから来たものなら、この前提を引き継ぐのではなく確認しておく価値があります。

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

JPEG XL はアニメーションにも対応していますが、BMP は対応していないので、この能力は受け取るものがありません。あえて書いておくのは、これも仕様の中で、この形式より古いところから来た元データが活かせない項目の 1 つだからです。

かなり軽くなります。1 画素 3 バイトより軽いものはほとんど何でも軽いからです。1920×1080 のビットマップは、画像について何も判断していない時点ですでに 6.2 MB あり、それを非可逆な JPEG XL にすると、その一部の容量に収まります。

WebP や AVIF との比較はずっと近く、画像次第です。容量を最適化したいなら、同じビットマップを 2 つか 3 つの形式に変換して実際のバイト数を比べてください。ここなら 1 分で済み、どんな一般則も確実には答えられない問いを解決できます。3 つが数パーセントの差に収まることもよくあり、その場合は容量ではなく対応状況で決めるべきです。その軸では JPEG XL は 3 つの中で最下位で、しかも僅差ではありません。

ビットマップはブラウザーがデコードし、同じタブの中で WebAssembly 版の JPEG XL エンコーダーが符号化します。どこにも送られず、アカウントも不要で、上限は 1 ファイルあたり 100 MB——無圧縮ビットマップでおよそ 3300 万画素分です。

フォルダーを置けばファイルは順番に変換され、拡張子だけ変わった名前のまま 1 つの ZIP として戻ってきます。ここまで書いてきたことを踏まえると、まず 2、3 ファイルだけ変換して自分のソフトで開けるか確認するほうが、フォルダーを 2 回変換するより時間の節約になります。その確認が済むまでビットマップは残しておいてください。この変換は非可逆で、JXL から BMP が持っていた画素へ戻る道はありません。元ファイルを消すことだけが、この作業の中で唯一取り返しのつかない一歩です。