AVIF を JXL に変換

JPEG XL を明確に必要とするときに使ってください。ほかの形式を一切読まないツール、それを前提に組まれたパイプライン、ISO 規格を名指しする保存方針、あるいは実際に測定するつもりの実験。これらは正当な理由で、この変換はそれにきちんと応えます。

理由が「新しそうだから」「良さそうだから」というだけなら、AVIF のまま残してください。2 つの形式は圧縮率が近く、どちらでも驚くような差は出ません。変換には非可逆な世代が 1 回増えるコストがかかり、AVIF は現行のすべてのブラウザーが読めるのに対し JPEG XL の対応はまだ部分的です。動いている Web 画像を JXL に変換してページが良くなる場面はありません。読んでみて変換をやめる、というのもこのページの正当な結末で、ここに来た人の多くにとってはそれが結末になります。

AVIF は 2019 年に Alliance for Open Media が AV1 動画コーデックを土台に発表しました。JPEG XL はその後 2022 年に JPEG 委員会自身が ISO/IEC 18181-1 として発表し、技術的な野心では、いくつかの点でむしろ洗練された設計です。

ですが採用は技術的な優劣どおりには進みませんでした。AVIF のブラウザー対応はいまや現行バージョン全体でおおむね一般的ですが、JPEG XL は依然として部分的です。この形式が「現行」ではなく「ニッチ」の分類に置かれ、需要が AVIF のごく一部にとどまっている理由です。この差こそが、この変換があなたのファイルにとって意味を持つかどうかを決める最大の要因であり、どちらのコーデックが優れているかとは無関係です。第一の形式がすでに広く普及している以上、第二の現代的な形式を求める理由は年々弱まっていくため、急に状況が変わる見込みも高くありません。

AVIF はいったん生の画素へデコードされ、その画素が JPEG XL のエンコーダーによってもう一度符号化されます。圧縮されたままの形で引き継がれるものは何もないので、AVIF のエンコーダーが捨てたものはそのまま失われたままで、その上に JXL のエンコーダーが自分自身の判断を重ねます。

既定の画質 82 では、この 2 回目の処理は写真ではほとんど目に見えませんが、無料というわけではありません。細かい質感やフィルムグレイン、非可逆な AVIF が硬い輪郭の周りに残すわずかなブロックノイズは、まさに 2 回目のエンコーダーが最も苦手とするものです。1 回目のエンコーダーの失敗を被写体の一部であるかのように符号化してしまうからです。2 つのうち片方だけを残すつもりなら、1 回しか符号化していないほうを残すのが素直な判断です。ライブラリ全体を変換するつもりなら、まず元のオリジナルを探すべき理由でもあります。

仕様上は、写真家や保存担当者にとって重要ないくつかの点で AVIF より先へ進んでいます。1 チャンネルあたり最大 32 ビットまで扱える（AVIF は 12 ビットまで）、広色域での作業向けに作られている、動画コーデックの副産物としてではなく、大規模な写真コレクションの長期保存を明確な目標として設計されている、といった点です。

ただし、この特定の変換を通ってはそのほとんどが届きません。エンコーダーに届く時点で、画像はすでにブラウザーの画像パイプラインを 1 チャンネル 8 ビットで通過済みなので、深度の余裕はここでは理論上のものにすぎず、どんな Web 配信元から来たとしても同じく理論上のものになります。8 ビットより多くを渡せる元データが最初からないからです。この能力を活かす場は、RAW や 16 ビットの元データから GIMP や ImageMagick のようなデスクトップアプリで変換する場面であって、配信用ファイルを再符号化する場面ではありません。形式ができることを知っているのと、それを実際に活かせる立場にあることは別の話です。

JPEG XL を支持するもっとも実用的な理由は、既存の JPEG を画像データに一切触れず、完全に復元可能なまま、およそ 2 割小さく再パッケージできることです。これは画像形式としては珍しい性質で、大規模な写真アーカイブがこの形式を真剣に検討する理由です。

これが可能なのは JPEG のデータを再符号化するのではなく並べ替えているからで、AVIF の中身は AV1 のデータです。写真の表現方法がまったく異なり、どちらも圧縮されているという以外に JPEG との共通点がありません。並べ替える対象がないので、この組み合わせではその恩恵は一切なく、ほかのどの組み合わせとも同じ、ただのデコードと再符号化になります。JPEG のオリジナルと AVIF の派生版の両方を持っているなら、JPEG XL にとって興味深いのはそちらのほうで、そちらを変換するほうがはるかに有意義な時間の使い方です。

GIMP と ImageMagick はどちらも JPEG XL を読め、どちらも AVIF を読めます。これはデスクトップの状況を公平に要約しています——片方に対応しているツールは、たいてい両方に対応しています。つまりこの変換が「開けない」という問題を解決することはあまりありません。

それ以外の場所ではすぐに心もとなくなります。OS のプレビュー、古い編集ソフト、アップロードフォーム、チャットアプリ、印刷サービスは、どちらの形式にも対応していないことが多く、片方だけ対応している場合は AVIF であることが多いです。ブラウザーのエンジンがブラウザー以外の多くのソフトに組み込まれているためです。会話なしに他人が開けるファイルが目的なら、どちらも正解ではなく、JPG や PNG、PDF を作るページのほうが目的に合います。

JXL を候補にし、AVIF か JPEG をフォールバックにした picture 要素は、正しい配信方法であり実際に機能します。しかしそれで何かが節約できるわけではありません。フォールバックはどのみち作らなければならないからです。

これが Web パフォーマンス目的でこの方向へ進む人にとっての厄介な算数です。すでに全員に届き、最良に近い容量を持つ 1 つの形式から出発したのに、最終的には 2 つのファイルと判定処理、両方を保存するキャッシュを抱えることになります。JXL が届いた訪問者で得られる節約が、それら全部の代償を払わなければならず、対応が部分的な形式ではたいてい割に合いません。配信用画像については、その議論はすでに AVIF のところで終わっています。

既定値の 82 は写真にとって妥当なバランスで、理由がない限りそのままにしておく値です。95 に近づけると 2 回目の符号化パスが控えめになり、あとで編集したり再符号化したりする予定のファイルにはこちらが向いています。

この組み合わせで 70 未満に下げる価値はほとんどありません。元がすでに圧縮済みなので、1 回目と 2 回目のエンコーダーの劣化が同じ輪郭に重なり、元データから始めたときより速く目に見えて悪化します。目標の容量が厳しいなら、リサイズのほうがよいレバーです。まずまずの画質で画素数を減らすほうが、同じ画素数のまま画質を落とすより優れており、事前に効果を予測できる唯一の変更です。

どちらの形式も EXIF、XMP、ICC プロファイルを持てますが、この経路ではどちらも生き残りません。ここでの画像変換はすべて生の画素へデコードしてから新しいファイルを書き出すので、撮影日時もカメラの機種も座標情報も、引き継がれるのではなく失われます。

誰かに渡すファイルとしてはこれはプライバシー面の改善で、覚えておくべき手順が 1 つ減るということでもあります。撮影場所の座標こそ、人々がもっとも消し忘れるものだからです。コレクションを再符号化する写真家にとっては、これは深刻な損失です。撮影時刻は写真集を並べる基準になるもので、すべて「今日作成」と表示される画像フォルダーはほとんど使い物になりません。素直な結論は、ブラウザーの変換ツールはライブラリの移行には向いておらず、タグを引き継ぐデスクトップアプリを使うべきだということです。

フォルダーを置けば、ファイルは手元のプロセッサーで 1 つずつ順番に変換され、アップロードも 1 日の上限もなく、1 つの ZIP として戻ってきます。JPEG XL の符号化は十分速いので、大きなバッチも根気の問題であって、午後をまるごと塞ぐようなことにはなりません。

AVIF のファイルは残しておいてください。それが古いほうの世代であり、5 年後もブラウザーで表示され続けるのはそちらで、あとから JXL のコピーが不要だったとわかっても、この変換をやり直すコストはかかりません。容量が近い 2 つの形式のために、容量を節約しようとして元データを消してしまうことが、ここで唯一取り返しのつかない失敗です。