Google Chrome Is Already Preparing to Deprecate JPEG-XL | Hacker News Reader

Google Chrome Is Already Preparing to Deprecate JPEG-XL

phoronix.com

62 pointssmitop20 comments

I wouldn't be surprised if this is more a legal issue since Microsoft was granted a patent on rANS encoding, which is used in JPEG-XL: https://www.theregister.com/2022/02/17/microsoft_ans_patent/

I doubt it's related to that. That patent is too recent to affect JPEG XL.

didn't read it, but someone told on a forum that Microsoft's patent is about dynamically updated rANS probabilities during decoding -- JPEG XL is about static rANS codes, the codes are never changed/updated during decoding, they are context modeled and already clustered at encoding time, which makes it faster to decode than dynamically updated codes

As funny as this is, I don't think this is true.

I _think_ for policy reasons all of Chromes experimental flags have deprecation deadlines to ensure they it doesn't accumulate endless flags that eventually break. These deadlines can be moved.

Just search the jxl issue for "expiry", they've bumped it a few times already: https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

All past bumps however were only done by updating flag-metadata.json (this includes the most recent bump to M115 as well). Changing the user-facing message is new, and it doesn't help that the commit author is Vignesh Venkatasubramanian, who developed AVIF muxer for FFmpeg in the past. M115 therefore might be the final deadline this time.

With AV1 video and AVIF browsers got buy-1-get-1-free deal. The video codec was a necessity, and decoding one frame from a slightly different flavor of MP4 container is a relatively minor addition.

AVIF is not as good as JPEG XL, but it's good enough to the point JXL is a nice to have rather than a burning need. For the same reason I don't expect WebP2 to go anywhere unless Google is willing to make it a compatibility headache for other vendors.

I might be incorrect here, but I thought that AVIF is using same/similar container format as MP4/HEIF. Is there clarity on patent situation for container formats?

Wikipedia article briefly mentions patents for HEIF and it does not inspire much confidence there.

[0] https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_F...

HEIF has a ton of issues when you use it with H.256 (HEIC).

But basic usage of it is almost identical to any MP4 video file, it just has a few bits of metadata saying "I'm an image". That's too trivial to be patentable.

In terms of burning needs you could argue that AVIF and WebP also don't really fill those, since they are not _that_ much better than JPEG with a good encoder while they lack progressive decode.

There was no good format for wide gamut and HDR. JPEG XT didn't catch on. If only WebP had been based on VP9 instead of VP8, it may have been good enough to stop AVIF too.

You should propose JXL as intra frames in AV2. Seriously. Browsers got a video-derived image format twice in a row now, and without video there may never be a strong-enough motivation ever again.

Full JXL is not hardware-friendly enough to be used as-is in a video codec. A trimmed down subset of JXL could work, but I doubt they would accept it in AV2.

Video-derived image formats like WebP, HEIC and AVIF all have issues in the high quality range — they are simply not designed for that, and either cannot reach the very high qualities, or they can do it but not with good compression. Also they don't support fast lossless modes and the precision (bit depth) needed in authoring workflows, so they are delivery formats only, not across-the-workflow formats. Features like progressive decode, region of interest decode, CMYK/spot colors, other additional channels (even just alpha), etc are just not relevant for video codecs, and while some of those shortcomings can be resolved at the file format level (e.g. by implementing extra channels as additional grayscale codestreams, or 'progressive' as a separately coded embedded preview image), it will come at a cost compared to what is possible if the codestream is designed for these features in the first place.

So I think they should stop making these video-derived image formats, and browsers should just accept video formats in img tags (or anywhere where they would currently accept GIF) so if you want you can just use a single-frame video.

I think the motivation for JXL is not just improving the state of image delivery on the web, but also image interchange in general. Currently the only interchange format that can do layers is TIFF. The only interchange formats that can do CMYK are JPEG and TIFF. There is currently no standardized interchange format for images with spot colors (only PSD can do that atm). The only widely supported format that can do lossless 16-bit with some compression is PNG (and J2K, I guess, depending on your definition of "widely supported"). For camera-quality HDR images (with enough precision for further editing), there are currently only the raw formats and OpenEXR. I think these all correspond to important use cases, and it is unlikely that any image format derived from a video codec will support these use cased in a satisfactory way.

JPEG XL is the first image format that has the potential to cover the whole workflow from capture and authoring to delivery. I think that's where its real value lies.

While JPEG XL is awesome if measured with DSSIM, SSIMULACRA 2, Butteraugli or human viewers, JPEG XL is an average or bad codec if measured with AOM's current image quality metrics (MS-)SSIM, PSNR and VMAF(neg).

AOM's image quality group is not receptive to adding new image quality metrics. I proposed it, they told that they want to rather reduce the number of metrics, not increase.

To accept JPEG XL as an intraframe they would need to have political will for it -- to deviate from they usual image quality procedures.

JPEG XL seems to give an extra 10-15 % of density on average, but it cannot be measured using the current AOM processes. If it had been possible, they would have already based AV2 on JPEG XL keyframes instead of AV1 keyframes. They are hunting a lot of small improvements, even 1 % improvements, with substantial effort.

Like I said before,

For Video, H.266 / VVC is just technically superior in every single way. For Images, JPEG XL is the best for 95%+ of use cases. For audio, we have a AAC-LC, literally as ubiquitous as MP3, truly patent free, and at 128 or 160+kbps, it is within 10% Bitrate difference compared to state of the art codec.

And yet we end up in a world where the only accepted choice is AV1 for video, AVIF for images and Opus for Audio.

The only open-source AAC-LC encoder I'm aware of is ffmpeg's, which is pretty awful for quality and featureset. LAME beats the quality of ffmpeg's AAC-LLC encoder at similar bitrates, from what I've tried. That's a condemnation of ffmpeg and not AAC-LC, of course, but why care when libopus is right there and beats AAC-LC in a good percentage of cases.

H.265/HEVC has barely gotten off the ground in adoption due to the double patent pool situation, and VVC seems unlikely to continue. VVC is a fine spec but it's too expensive to ship products with right now.

JPEG-XL was never a good spec, tbh, having looked at the drafts. I don't have a copy of the ISO spec, but the draft I looked at lacked the rigor I would expect out of a modern compression system & file format -- some parts had Pi and trigonometric functions in the equations without precision bounds. It felt academic to me.

> H.265/HEVC has barely gotten off the ground in adoption due to the double patent pool situation…

H.265/HEVC is ubiquitous on video-focused devices. It's used in every streaming service's encoding ladder. It's used for OTA DTV. It's used for Blu-ray. It's very popular for torrents. Apple devices capture to H.265. AV1 will be (deservedly) considered wildly successful when it reaches current H.265 adoption levels, several years from now.

> The only open-source AAC-LC encoder I'm aware of is ffmpeg's, which is pretty awful for quality and featureset

FDK is open source and decent.

https://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_A...

FDK-AAC's license is regarded in the FOSS community as open-source, but patent encumbered. So it's up to the party shipping to the codec to determine where they fall on the spectrum of shipping patent encumbered software. In Fedora, for example, a modified version of fdk-aac is shipped, stripping out the features and functionality restricted by patents, in the fdk-aac-free package, with the more complete package shipped in RPM Fusion.

Precision bounds are in 18181-3.

JPEG XL ISO Spec -- it is a good idea to take a look at a more recent version than the committee draft in 2019 -- it evolved quite a bit

You said this on the HEVC for Chrome thread, and even now I still don't fully agree with it. While some of these solutions may be technically superior in certain aspects, that doesn't mean everyone will drop what they're doing and implement support in hardware and software today because the folks managing these codecs (aka the patent pools) make life miserable for anyone trying to do so. Why bother with vague terms, definitions, royalties, and risk of lawsuit when you can have a solution that works nearly or just as well without all those problems?

AV1 is a great video codec and when paired with a modern software toolset (like SVT-AV1) or, for today, latest gen hardware it's not really an issue. The age of the ecosystem is really the only practical drawback, with a lack of generally efficient software and widespread hardware support that other codecs like HEVC have had for several years. Opus is also a great audio codec that has seen successful adoption across streaming platforms and the vast majority of people wouldn't be able to tell the difference between Opus, AAC-LC, and MP3 without blatant artifacting.

I have no problems with the technologies you mentioned themselves, they are all amazingly advanced and can open a lot of doors for high quality, efficient data transfer and media consumption. But the tech is only half the story; if you have people acting as ridiculous gatekeepers then there's no use complaining about the lack of adoption as it's falling on the ears of people who only care about one thing: money. The patent pools are looking to make money, the implementers are looking to save money. Take a guess which one end-user consumers are going to end up with most of the time?

Reply on news.ycombinator.com