FFmpeg Lands JPEG-XL Support

[brucethemoose]

Meh. With Google's sponsorship, it's highly unlikely this'll gain any momentum over WebP. Not to mention there's also HEIF that Apple's adopted 5 years ago. What's the niche for JPEG XL, really?

Funnily enough, apparently JPEG XL also borrowed stuff from Google's another project, Pik.

The niche is that it performs better than anything else, in almost every use case. Its dramatically faster to encode/decode than avif at the same quality, and generally achieves better maximum compression in all but very lossy presets. Hence it will also outperform heif and most other formats.

...but don't take my word for it, look up "butteraugli" benches that also include encoding time and filesize.

It also brings all those useful features to a single image format. Maybe there have been other formats with the same feature level, but I can't think of any that performed so well.

[Aeder]

The real problem to me feels like you need it to be better supported than classic jpeg which is probably not happening any time soon, because why bother when jpeg is good enough and works with both old and new software.

MS' patent might run out before that happens.

[Quackdoc]

What a bunch of weird assumptions here.
I too was wondering if Chrome would add support for it. Contrary to those here assuming chrome won't add it due to WebP... It's already in chrome!
It's in: "In developer trial (Behind a flag)". See here for more details: https://chromestatus.com/feature/5188299478007808
And see here for the bug tracking the JPEG XL status: https://bugs.chromium.org/p/chromium...ail?id=1178058

Also, just go to chrome://flags and filter on jxl. It's right there to enable is you feel adventurous.

People don't seem to realize google doesn't really care about "their standard" they just want whatever saves them the most money. if there are use cases where webp2 wins, they will use it, if their are cases where jxl wins, they will use it.

Any compression gains you get would be small or negligible, without modifying the content. Lossless conversion means you're not changing the block structure, base DCT transform, or quantization coefficients. That only leaves entropy & bitstream encoding, and there are no huge savings there.

This is plain wrong. you can losslessly compress jpegs to varying degrees, sometimes 5%, sometimes 50%, cjxl is open source, you can test it directly, or build ffmpeg if you wish to try it. I have a 23M jpeg compressed losslessly to 15M without even using a too slow preset. I would consider that "huge savings" to me.

It sort of does, because they have a large enough userbase to force their agenda. The last time iPhones changed their default image file format, software user forums and bug databases were flooded with requests to support it.

AV1 is still taking off in popularity.

...is technically superior, but only scientists with the best hardware in the world will be able to make use of its full features...ditto for AVIF. So the niche is the ability to take all the current photos and losslessly transcode them into a smaller format.

JXL for stills, AVIF for animations, JXL is highly flexible, and has great features like very good lossless, (can often beat PNG) multiple resolutions in a single photo (magnificent for web). and some more real nice goodies like progressive rendering.

Does Firefox use this library on Linux?
Or could use it to support this image format immediately?

yes but it's broken, last I checked only worked on nightly

[brad0]

Not to mention there's also HEIF that Apple's adopted 5 years ago.

and due to the patent minefield both HEIF and HEVC have seen little uptake.

[arun54321]

but only scientists with the best hardware in the world will be able to make use of its full features.

What do you mean? jxl is not computationally heavy to encode.

[Quackdoc]

What do you mean? jxl is not computationally heavy to encode.

exactly, i've been making videos with jxl for a little bit now, since V4 of the patch set. I can get about 2-8fps at 1080p video when encoding sequentially with ffmpeg using d 0 e 7. which is perfectly fine. and I get way more when using "parallel -j 4" a good mark form my ryzen 2600. I have zero issues lossless converting literally hundreds pngs, jpegs and bmps to jxl. the only reason I don't for apngs, gifs etc. is because i prefer using avif since you get the full muscle of av1 behind it, makes very small animations, smaller than jxl. (but ofc not lossless)

[Quackdoc]

What do you mean? jxl is not computationally heavy to encode.

my reply to this got nuked by anti-spam I guess, so instead of typing that all out, Ill make it brief, I get 2-8fps using ffmpeg sequentially when encoding 1080p video, I get about way more by using parallel jobs. not a problem losslessly converting hundreds of pictures, though webms, animated webps, apngs and gifs get the avif treatment instead

[arzeth]

https://github.com/archlinux/svntogi...s/imlib2/trunk Since yesterday, imlib2 in [testing] now supports JPEG-XL too! Now I am able to use feh (image viewer) to view .jxl!

I've just done lossless compression results comparison on a very-highly-detailed 1280x720 2D-image (non-overclocked Ryzen 5 2600, all these packages are recompiled with my CFLAGS):

optipng -o7 a.png # → 1 170 748 bytes ~2 minutes IIRC.
avifenc -j 12 -s 0 --lossless a.png losles.avif # → 1 072 339 bytes, 13 327 ms.
cwebp -mt -m 6 -q 100 -lossless on a.png -o losles.webp # → 937 850 bytes, 6432 ms.
cwp2 -q 100 -effort 9 a.png -o losles.wp2 # → 869 486 bytes. 10 minutes, only 1 thread was used. Just compiled from git.
cjxl a.png -q 100 -e 8 losles8.jxl # → 851 817 bytes, 5300 ms, only 2 threads?
cjxl a.png -q 100 -e 9 losles9.jxl # → 828 897 bytes, 50 748 ms (9.5x slower).

BTW, unlike all other formats, WebP 2 has a very interesting feature (probably useful only for lossy output?):

-neural ................ enable neural compression and specify directory
with enc/decoder graphdefs

[abu_shawarib]

Any compression gains you get would be small or negligible, without modifying the content. Lossless conversion means you're not changing the block structure, base DCT transform, or quantization coefficients. That only leaves entropy & bitstream encoding, and there are no huge savings there.

Seen claims of 20% savings with lossless conversion from jpeg to jpeg XL. I've converted some random photographs and it yielded %10-19 savings. IIRC jpeg XL uses a generalized transform for lossless conversion.

[pkese]

A big thing for web-dev folks is that with JXL you can export single image file for multiple screen resolutions and then serve just the first part of the file for low-res devices.

With almost all other current formats (WEBP, HEIF), you had to prepare (and distribute) different files for different screen resolutions.