JPEG XLはWebに不要だ

この記事は良い点を指摘している。JPEG XLは素晴らしいが、AVIFと比較して典型的なWebのユースケースに特化しているわけではない。しかし、結論はそこから導かれない。優れた汎用性の高いフォーマットがブラウザでサポートされることは非常に有用だ！

私のウェブサイトのJPEGをロスレス再エンコードして20%のサイズ削減を得るために33%長いデコード時間を費やす価値はないかもしれないし、ウェブサイトが非常に高解像度の画像やチャンネルあたり12ビット以上を必要としないかもしれない。しかし、私の個人アーカイブには間違いなく役立つし、そのようなファイルが専門的なツールなしでどこでも閲覧できるのは素晴らしい。イントラネットや実際にWebで提供されることも含めて。

要するに、JPEG XLはそれほど長くないテールのユースケースでAVIFを容易に打ち負かし、どこでも互換ビューアがあることは非常に有用だ。そしてJPEG XLがPDFの一部になるにつれて、すぐに一般的なユースケースにもなるだろう。

記事の残りについては、ベンチマークセクションには興味深い点があるが、JPEG XLの採用サイクルとしては結論を出すには早すぎると思う。ただ一つ気になるのは、単一の画像比較（「結果がすべてを物語る」というキャッチコピー付き）があり、これはかなり誤解を招くと思う。それは「受信バイト数」の線上の、AVIFにとってJPEG XLと比較して最も良く見える一点を選んでいるだけだ。自分で試してみればわかるが、JPEG XLは2KBですでに何かを表示するのに対し、AVIFは8KBまで何も表示せず、100KB以降はJPEG XLの方がAVIFよりも良く見える。

AVIFに対する私の潜在的な大きな問題は、それがビデオフォーマットに基づいているため、AVIFが得るハードウェアデコードサポートは一般的なビデオシナリオに限定される可能性が高いことだ。これにより、例えばハードウェアデコーダが4:2:0 YUVのみをサポートする結果になるかもしれない。それはAV1 Main Profileの上限（ひいてはAVIF Baseline Profileの限界）だからだ。そして4:2:0は特定のカテゴリの画像（例えば様々な種類のイラスト、スクリーンショットなど）にはまったく不向きだ。モダンなフォーマットで非可逆4:4:4画像圧縮が強く推奨されないWebにはあまり満足できない。

また、優れたロスレス圧縮はWebにとっても絶対に重要だ。非可逆画像はすべての状況で使えるわけではない。例えば圧縮品質を比較するとき（特にビデオの）などだ！

編集：追加の例を挙げると、ピクセルアートは芸術の一分野全体であり（今日でも非常に活発だ）、ロスレス圧縮が必須であり、4:2:0は品質にとって絶対に壊滅的だ。

「非写真画像については、『ベクター画像であるべきだ』という議論は成り立たない。なぜなら多くの画像はベクター画像になり得るがそうなっておらず、完璧にベクター化することはできないからだ。『世界は違うべきだ』というのは、世界の実際のあり方に最適化することに対する正当な防御にはならない。」

この段落は良い。人々が最後の文を適用するのを忘れているのをよく見かける。

このブログ記事は二つの相容れない主張をしている：

1) AVIFは今や根本的に改善され、以前はそうではなかった方法で実際にかなり良くなっている。

2) JXLは改善されないだろう。他のすべてのコーデックの性能が常に根本的に改善されてきたという事実にもかかわらず。

他のすべてはさておき、将来の実装努力が何かを達成するだろうと想像することを厭うのは、非歴史的で見苦しい。

あのJPEG XL素数計算はかなり醜いDoSだ。Finderで選択するだけで、プレビューペインを開いた状態で、MacのすべてのコアがQuickLookSatellite内で最大になり、その間4GBのRAMも消費した。15秒間も。2KBの画像にしては悪くない。AppleはJXLプレビューアにまともな制限を設定していないようだ。

しかし、これはフォーマットが何をなし得るかの信じられないほどクールなデモだ。画像フォーマットがそこまで柔軟であるべきかどうかは完全には確信できないが、それでも感銘を受けた。

> Webコーデックは専用に構築され、効率的で、Webのニーズに狭くスコープされるべきだと信じている。

この記事は汎用性の有用性を軽視している。私は反対だ。「この画像とこのユースケースにはどの画像フォーマットが最適か」というゲームをしたり、それらの間でトランスコードしたりするのは避けたい。例えば、ハードディスクに保存しているままのファイルの写真を表示するHTMLギャラリーがあれば素晴らしいだろう。今日ではこれらはJPEGだ。なぜならそれが最小公分母だからだ。WEBP、AVIFは写真ツールでサポートされていない（例：https://support.captureone.com/hc/en-us/articles/36000262921...）し、写真向けのフォーマットではないためサポートが追加されるとは思えない。

AV1（AVIFで使用されるコーデック）は、ビデオで広く採用されているおかげで、近年はるかに多くの開発が見られたように思う。JPEG XLは同様の大規模な採用は見られていない。おそらく大部分はChromeが疑わしい根拠で拒否したためだ（以前はWebPとAVIFの採用を熱心に強制したにもかかわらず）。リファレンス実装の開発ペースは非常に遅くなり、それが得ているささやかな注目のほとんどは、ブラウザが最終的に開発者に求めるものを決めた後、新しいRustデコーダに最近移ったようだ。

それを考慮すると、コーデック間の公平な比較とは思えない。JPEG XLはかつてAVIFよりもはるかに印象的だった。人々（著者を含む）がAVIFを前進させたのは素晴らしいが、JPEG XLに対しても同様の努力が本気でなされるまでは、彼らのエンコーダ間の比較がコーデック自体について多くを語るとは思えない。著者はJXLエンコーダがどれだけ改善され得るかについて推測しているが、それはただの推測だ。試されるまでわからない。そして特にこの不幸な歴史全体を考えると、JPEG XLは本当に、本当に試される価値があると思う。

まだ誰も言及していないが、JPEG XLはOpenEXRに近い潜在能力と柔軟性を持っているようだ。JPEG、WEBP、PNGのようなものというよりは、画像処理やデジタルアートのパイプラインで使うための、そうしたものの競合のように思える。

とはいえ、私は個人的なJPEGをJPEG XLに変換した。なぜなら、JPEG XLではより小さなファイルサイズで品質劣化なしに双方向にロスレス変換でき、無料でストレージを節約でき、必要ならバイト単位で元のJPEGを取り戻せるからだ。

注意：JPEG XLはDNGファイル（Digital Negative - カメラの生センサーデータを保存するraw画像）の可能な圧縮方法として追加された。

そのため、過去数年間、すべての新しいiPhoneとほぼすべてのAndroidスマートフォン（主にSamsung）は、すでにJPEG XLエンコーダ/デコーダを搭載している（これらのDNGを生成するため）。