JPG を JXL に変換

JPEG XL には、このファミリーの他のどれも持たない能力があります。既存の JPEG を、画素へデコードせずに係数のまま再パッケージし、もとの JPEG をバイト単位で復元できる状態を保ちながら、およそ 2 割小さくできます。何も失われず、何も足されず、操作は可逆です。写真アーカイブをこの形式へ移す理由として、これまでで最も強力な主張です。

この変換ツールはそれを行いません。このサイトのすべての画像変換は、元データを生の画素へデコードしてから結果を新たに符号化します。パイプライン全体がその形をしており、この組み合わせにも例外はありません。したがって戻ってくるのは写真の新しい非可逆な符号化で、容量は小さくなりますが見た目はわずかに変わり、最初のファイルへ戻すこともできません。このことをはっきり書くために、このページは自動生成ではなく手書きされています。

JPEG は mozjpeg によって 8 ビット RGB のバッファーへデコードされ、そのバッファーを libjxl が選んだ画質——既定は 82——で符号化します。このサイト自身のサンプル写真では、8,924 バイトの JPG が 7,240 バイトの JXL になり、およそ 19 パーセントの削減です。これは可逆な再圧縮で語られる数字に近く紛らわしいものですが、まったく別の経路でたどり着いた結果です。

この違いは数字そのものより重要です。再符号化による 19 パーセントは画質の 1 世代分を代償にし、元に戻せません。再圧縮による 19 パーセントは何も代償を払わず、いつでも元に戻せます。欲しいのが容量の節約だけで正確さは気にしないなら、このページで十分です。両方を約束されたと思っているなら、探していたのは cjxl についての話です。

libjxl は cjxl と djxl という 2 つのコマンドラインプログラムを提供しており、どちらも無料でオープンソース、Windows、macOS、Linux で使えます。JPEG を渡された cjxl は既定で可逆なトランスコードを行い、djxl はそれを元に戻して元の JPEG を返します。大きなライブラリでもスクリプトを 1 本書いて午後の時間があれば済み、結果は本当の意味で可逆です。

ここで使えないのは思想的な理由ではなく設計上の理由です。このパイプラインは画素へデコードして再び符号化する仕組みを中心に組まれており、それによって百組もの形式の組み合わせが 1 本の経路で動いています。JPEG の係数レベルでのトランスコードはその全体を迂回する特殊な処理です。これは回避策を探すより、そういうものだと知っておく価値があります。ブラウザーの変換ツールはこの作業には向いておらず、正しい道具はダウンロード 1 つ先にあります。

JPEG はすでに情報を捨てており、残っているものにはそれ自体の癖が含まれます。平坦な領域にある 8×8 のブロック境界、硬い輪郭に沿ったリンギング、明るさの半分の解像度で保存された色。いまやそれらは写真そのものの一部で、JXL のエンコーダーはそれを忠実に再現しつつ、その上にさらに新しい量子化を重ねます。

どれだけ響くかは元データ次第です。カメラから出たばかりの高画質 JPEG は、画質 82 での再符号化に見た目上ほとんど耐えます。メッセージアプリを経由し、スクリーンショットを取られ、画質 60 で保存されたことのある JPEG にはすでに目に見える劣化があり、2 回目の処理はそれをなめらかにするどころかわずかに悪化させます。RAW や可逆な書き出しがまだ残っているなら、そちらから符号化するほうが明確によく、残っていないなら、節約が小さな劣化に見合うときだけ妥当な取引になります。

設定は 1 から 100 まで、既定は 82 です。元データがすでに非可逆なので、オリジナルから符号化するときより少し高めに設定する理由があります。エンコーダーは自分が生み出していない構造を再現しようとしているので、余裕を与えるほど、その構造がさらににじむ量が減ります。

上限付近は挙動が違い、知っておく価値があります。このサイト自身のエンコーダーで測定したところ、画質 100 では 256×256 のグラデーションで 262,144 サンプル中 334 サンプルだけが 1 段階ずれ、平坦な絵柄はビット単位で完全に一致しました。デコードされた画素に対してはほぼ可逆ですが、元の JPEG ファイルに対してはそうではありません。その設定では JXL は JPEG よりかなり大きくなるので、画質 100 は保存戦略としてではなく、あとでさらに再符号化するワークフローに渡す場合にのみ意味があります。

JPEG は EXIF、XMP、IPTC、ICC プロファイル、しばしば GPS 座標を持ち、写真集にとってはそれが画素と同じくらい価値を持つことがあります。日付、カメラ、レンズ、位置、キャプション、著作権表記です。この変換は生の画素へデコードしてから再符号化するので、それらは無条件で失われます。ページの設定で選べるものではありません。

1 枚をどこかへ送る場面では歓迎されることも多いです。撮影場所の家の座標も一緒に消えるからです。ライブラリの移行としては深刻な問題で、可逆性に次いで cjxl がその作業に正しい道具である 2 番目の理由でもあります。cjxl は係数と一緒にメタデータブロック全体を保ちます。ICC プロファイルを失うことは、彩度の高い色をわずかに平板にすることにもつながります。プロファイルのないファイルは、次に開くソフトによって sRGB として読まれるからです。

このサイト自身のサンプル写真で既定の画質を使うと、同じ写真は JPG で 8,924 バイト、WebP で 14,700 バイト、AVIF で 17,599 バイト、JXL で 7,240 バイトになります。JPEG XL がこの 4 つの中で最小で、これがこの形式を技術的に支持する主張を一言で表しています。次に小さいのが mozjpeg の JPEG で、よく符号化された JPEG は世間で言われるほど弱くないことを思い出させてくれます。

対応状況はちょうど逆の順序になります。JPG はどこでも開けます。WebP は現行のすべてのブラウザーで、AVIF は現代的なブラウザーで、JXL は一部で開けます。写真を送ったり公開したり手渡したりするなら、この順序が優先され、JPG か WebP が正しい答えです。JPEG XL が勝つのは、ファイルが自分の管理下にあるシステムの中に留まる場合だけです。

移すべき理由は本物です。数百ギガバイトになりがちなコレクションで、ディスクの 2 割ほどが戻ってきます。可逆なトランスコードならさらに戻ってきます。反対の理由は、JPEG がこれまでで最も普遍的に読める画像形式だということです。使っているソフトで開けなくなったライブラリは、節約できたストレージよりずっと価値があります。

守りやすい中間案は、JPEG を残したまま JXL を実験として扱うか、cjxl を使って移行を可逆にし何も本当のリスクにさらさないことです。守りにくいのは、20 年分のアーカイブをブラウザーで画質 82 のまま変換し、元データを消してしまうことです。「JPEG XL は可逆に 2 割節約できる」という言葉をそう読み違えることを防ぐために、このページは存在しています。

mozjpeg がデコードし libjxl がエンコードします。どちらも WebAssembly にコンパイルされ、必要になったときだけ取得され、すべてブラウザーの中で完結します。写真についての何もネットワークを越えないので、このページにたどり着くような素材——個人のアーカイブ、クライアントの撮影、未公開の作品——にとって重要な点です。

無料枠の上限は 1 ファイルあたり 100 MB で、どんな JPEG よりもずっと大きい値です。バッチも扱えます。フォルダーを置けば各ファイルが自分の進捗行を持って変換され、結果は ZIP として戻ってきます。JPEG XL の符号化は WebP より遅く AVIF より速いので、数百枚の写真も少し時間を置けば終わります。まず数枚だけ変換して原寸でオリジナルと見比べ、その 19 パーセントが 1 世代分の劣化に見合うかどうかを、大きなバッチにかける前に判断してください。