Mozilla Firefox Flips On AVIF Image Decoding By Default

[S.Pam]

Royalty-free?

Coming from a group which used to demand royalties for ages, I don't trust it...

Yea.

https://jpeg.org/jpegxl/

"Part 4, Reference software Provides a free and open source JPEG XL reference software, available at Gitlab under the Apache 2 license (which includes a royalty-free patent grant from the contributors)."

[Quackdoc]

Not enough attention gets focused on JPEG XL, the next-gen royalty-free image format standard that finally (hopefully) will replace JPEG across the industry. It's even backwards compatible in the sense that regular jpg files can be converted to jxl losslessly while reducing the file size by 22% on average due to the more efficient encoding. The format was frozen on Christmas eve and is now in the final stages of standardization.

Here's a few resources if anyone's interested:
Unofficial JPEG XL summary page
JPEG XL website
Source Code Repository
Nice summary video

While JpegXL is better than AVIF for larger images, tbh i dont think its really a big deal, Stills are already fairly small and webp is fine for that, Animations are where AVIF shine, and really the only thing that needs "short term" improvement as far as image sizes go, at least for general internet usage. WebP and Gif animations are still fairly large for any decent amount of detail. whereas AVIF animations are actually of acceptable sizes.

I dont see Jpeg-XL being a major improvement in that regard, as it doesn't support video features.

Im not saying that jpegxl shouldn't be implemented, but I can understand why it's not a high priority.

[bug77]

Use your imagination. Most images you see on the web do not come directly from a camera.

Actually, they do. Facebook? Check. Instagram? Check. Snapchat? Check.
(I actually don't have an account on any of these, but the average user does.)

[andreano]

> Most images you see on the web do not come directly from a camera.

Actually, they do. Facebook? Check. Instagram? Check. Snapchat? Check.
(I actually don't have an account on any of these, but the average user does.)

I mean without re-encoding. I would be very surprised if they weren't scaled down.

[andreano]

On the topic of AVIF vs JPEG XL:

In comparisons I've seen so far, JPEG XL wins on detail preservation and generation loss, but falls apart sooner if the bitrate is too low. But here is the grain of salt I feel missing from such discussions: AV1 has a lot of filters, which reduce detail. This is because in a video codec, a denoised reference image is a better reference image. But for still-image use, these make way less sense, and need to be tuned way down. The detail loss in AVIF is largely down to encoder tuning, and say very little about the format. AV1 encoders need to add easily accessible still-image presets.

One such comparison: https://eclipseo.github.io/image-comparison-web
Note that the AOM encoded images are either too dark or too light, which hint at a mistake along the way. PSNR would scream if every pixel was slightly off like this.

[lyamc]

Not enough attention gets focused on JPEG XL

I'm still more of a fan of FLIF because it addresses two issues simultaneously:

• Have an efficient progressive encode that also doesn't look like garbage when you decode it
• Eliminate generational loss
• Be a low-bitrate lossless compression codec

It is neat how JPEG XL contains a JPEG inside for anything legacy, but at the same time... "Let the past die. Kill it if you have to."

[pkese]

While JpegXL is better than AVIF for larger images, tbh i dont think its really a big deal, Stills are already fairly small and webp is fine for that, Animations are where AVIF shine, and really the only thing that needs "short term" improvement as far as image sizes go, at least for general internet usage. WebP and Gif animations are still fairly large for any decent amount of detail. whereas AVIF animations are actually of acceptable sizes.

I dont see Jpeg-XL being a major improvement in that regard, as it doesn't support video features.

Im not saying that jpegxl shouldn't be implemented, but I can understand why it's not a high priority.

I don't understand what you mean by "doesn't support video features"? It does support animated images just about as much as AVIF does.

Usual reasons why JpegXL would be better are:
- approximately same efficiency at high compression ratio compared to AVIF, but much better at lossless compression (see https://sourceful.us/doc/385/lossles...eg-xl-avif-web )
- approximately 30x faster encode, 3x faster decode (less CPU intensive) compared to other modern image codecs (not mentioning the case where AVIF required more than 32GB of memory to encode an image: https://www.reddit.com/r/jpegxl/comm..._webp_jpeg_xl/ ),
- progressive decoding: you can put a single large file on the server and then serve full file for 4k screens or just the first 1/3 of the file for normal screen (or even less for smaller resolutions or thumbnails)
- can losslessly store existing jpeg files while saving 20% on disk space - it does that without actually re-encoding pixel data but just doing more efficient prediction and quantization on existing DCTs, which means it can restore back original pixel-perfect Jpeg in real time without much CPU resources.

[pkese]

I'm still more of a fan of FLIF because it addresses two issues simultaneously:

• Have an efficient progressive encode that also doesn't look like garbage when you decode it
• Eliminate generational loss
• Be a low-bitrate lossless compression codec

It is neat how JPEG XL contains a JPEG inside for anything legacy, but at the same time... "Let the past die. Kill it if you have to."

The same person that had been working on FLIF is also working on JpegXL.
According to his own words:

Lossless jxl will be slightly better in density than FLIF, though at the moment the lossless jxl encoder is still very slow (you need to use the flags cjxl -q 100 -s 0 -E 3 to get the best lossless compression, but it will take a while). The decode should be fast, typically faster than FLIF since it can be done in parallel (unlike FLIF which is inherently sequential).
Basically we have put the best things from FLIF/FUIF and lossless WebP in a blender, added some nice new ingredients, and that's what became lossless jxl (or "modular mode" as we call it, since you can also use it for non-lossless encoding).

[Quackdoc]

I don't understand what you mean by "doesn't support video features"? It does support animated images just about as much as AVIF does.

Usual reasons why JpegXL would be better are:
- approximately same efficiency at high compression ratio compared to AVIF, but much better at lossless compression (see https://sourceful.us/doc/385/lossles...eg-xl-avif-web )
- approximately 30x faster encode, 3x faster decode (less CPU intensive) compared to other modern image codecs (not mentioning the case where AVIF required more than 32GB of memory to encode an image: https://www.reddit.com/r/jpegxl/comm..._webp_jpeg_xl/ ),
- progressive decoding: you can put a single large file on the server and then serve full file for 4k screens or just the first 1/3 of the file for normal screen (or even less for smaller resolutions or thumbnails)
- can losslessly store existing jpeg files while saving 20% on disk space - it does that without actually re-encoding pixel data but just doing more efficient prediction and quantization on existing DCTs, which means it can restore back original pixel-perfect Jpeg in real time without much CPU resources.

Animations are just looping videos, It's a lot more than just a series of stills, Jpeg-XL doesn't (to my knowledge) support features that video encoders use to make videos small while preserving an acceptable ammount of detail (IE. Motion estimation), Meaning while Jpeg-XL should result in smaller file sizes for stills, I highly doubt in animations Jpeg-XL will compete well, especially considering the longer the animation the more "unoptimized" Jpeg-XL will be.

For smaller animations with a low framerate Jpeg-XL may be superior, but it still is far from comparison to using a proper video encoder. Jpeg-XL may beat Animated WebP but VP8 isn't a real good encoder. HEVC/AV1 based picture formats will smoke Jpeg-XL for animation sizes

[pkese]

Animations are just looping videos, It's a lot more than just a series of stills, Jpeg-XL doesn't (to my knowledge) support features that video encoders use to make videos small while preserving an acceptable ammount of detail (IE. Motion estimation), Meaning while Jpeg-XL should result in smaller file sizes for stills, I highly doubt in animations Jpeg-XL will compete well, especially considering the longer the animation the more "unoptimized" Jpeg-XL will be.

For smaller animations with a low framerate Jpeg-XL may be superior, but it still is far from comparison to using a proper video encoder. Jpeg-XL may beat Animated WebP but VP8 isn't a real good encoder. HEVC/AV1 based picture formats will smoke Jpeg-XL for animation sizes

It seems you are assuming that AVIF is doing some sort of motion estimation when encoding animations, which is according to my knowledge incorrect.
AVIF is mostly just the still keyframe image compression part extracted from the AV1 standard (no particular video tricks are included).
They are also explicitely saying that AVIF is not particulary efficient at video encoding and suggest people use AV1 for that purpose.