Ubuntu 24.04 LTS Won't Support JPEG-XL Out-Of-The-Box

[sobrus]

I have more faith in AVIF or VVC based image codec than JXL. AV1 (so far only in Google Pixel 8) and VVC already have IP cores and so far we've had nothing for JXL.

No smartphone will ever support JXL officially out of the box unless it's hardware accelerated both ways, encode and decode.

AVIF, just like AV1, is not a high fidelity format. It may outperform JXL with higher compression ratio, but the quality is subpar.
Also, it has some limitations - for example higher resolution images need to be divided into subimages, and it can introduce artifacts on stitching area. And it's slooooooooow, makes 5950x feel like a 486. SX.

On paper, JXL is a real winner, it has everything, including lossless JPEG recompression.

But in reality, it's not ready yet.

I've already switched to JXL, but only to lossless JPEG recompression. If something goes wrong, I can go back.
These files are different from vardct mode (which is "true" jxl), and have better software support, including full AdobeRGB and ICC profile support. But having two distinct modes in single image format is akward for me. I don't like this idea. Seems too complex.

[Quackdoc]

This is fairly disappointing. Not sure why they couldn't include it, and frankly don't really care enough to really look into it, but not having it default is annoying.

But in reality, it's not ready yet.

I've already switched to JXL, but only to lossless JPEG recompression. If something goes wrong, I can go back.
These files are different from vardct mode (which is "true" jxl), and have better software support, including full AdobeRGB and ICC profile support. But having two distinct modes in single image format is akward for me. I don't like this idea. Seems too complex.

Is there any specific issues you are having with it? JXL for me with lossless encoding and no reconstruction is still typically better then PNG, even when comparing ECT pngs, and lossy is quite good, with high fidelity lossy images beating out mozjpeg, webp, and avif. All ofc while maintaining features like progressive image decoding that AVIF and webp don't.

[Quackdoc]

I don't think we'll see JPEG-XL enabled camera in foreseeable future. Cameras use H264/H265 and HEIF. I haven't seen anything using AV1 or VP9. Hardware VP9 encoders are not very popular and AV1 is not very good for live high quality high bitrate footage. It would be good on cheap smartphone but not on full frame camera.

It's already been confirmed that someone is working on an hwaccelerator for jxl.

As for JPEG-XL it's still in infancy. AdobeRGB (very popular in photography and supported by all higher quality cameras) support was vastly improved in recent 0.10 release (it was plain broken before), but I don't know whether it's as good as P3 or Rec2020 (in previous releases, these were favored for reasons unknown to me, as they are more appropriate for video ).
If reference encoder is still not 100% finished, how can we get one in hardware?

what even is a 100% finished encoder? JXL as a spec defines how to decode images, There is a LOT of optimization encoders can do with JXL and libjxl barely scratches the surface

[skeevy420]

Is there any specific issues you are having with it? JXL for me with lossless encoding and no reconstruction is still typically better then PNG, even when comparing ECT pngs, and lossy is quite good, with high fidelity lossy images beating out mozjpeg, webp, and avif. All ofc while maintaining features like progressive image decoding that AVIF and webp don't.

It's programs supporting everything it does or even supporting it period. Firefox or Chrome on Windows or Linux need addons to view them. HDR images don't even render properly on Windows with HDR enabled. You have to download them and open them up in GIMP because the native Windows photo viewer doesn't even support opening JPEG-XL images, but at least they're in HDR with GIMP. JXL animations don't work in browsers, either.

Then there's operating systems. Windows itself doesn't even support it out of the box. Like I said, it's default Photos program doesn't load JXL images. For personal use when limited to viewing only on Linux, it's a great CODEC, but even then it's not the greatest due to the slow adoption rate since you have to convert images back to JPEG when you want to share them with friends and family.

[szymon_g]

In Windows it forced me something paid, but I found how to do it and have free support. In Linux, it open the image file instantly. (Ubuntu, Mint, ...)

Not on my system

[sobrus]

Is there any specific issues you are having with it? JXL for me with lossless encoding and no reconstruction is still typically better then PNG, even when comparing ECT pngs, and lossy is quite good, with high fidelity lossy images beating out mozjpeg, webp, and avif. All ofc while maintaining features like progressive image decoding that AVIF and webp don't.

I don't have issues with losslessly recompressed JPGs. In fact, I have almost 200GiB of them. Maybe except gThumb not able to read exif, but this is obviously gThumb issue, exiv2 works OK.
But 8x8DCT is not what JXL is all about. The vardct mode is still not usable beyond sRGB and maybe P3/Rec2020.

edit: this seems to be software issue as well. gThumb and GIMP doesn't seem to enable color management on vardct images. but darktable does! And AdobeRGB looks finally as it should too!

It's already been confirmed that someone is working on an hwaccelerator for jxl.
what even is a 100% finished encoder? JXL as a spec defines how to decode images, There is a LOT of optimization encoders can do with JXL and libjxl barely scratches the surface

Got it, so hopefully we'll see all these problems resolved at some point.

But it doesn't change the fact, that all camera manufacturers already adopted HEIF, and large percentage of "content creators"/artists use Apple. It all revolves around proven proprietary codecs there. It's almost funny when you send vp9 video to iphone users and they're not able to play it.

[Rovano]

Not on my system

Is it difficult to write more? Have you tried Uncle Google yet?

sudo apt install heif-thumbnailer heif-gdk-pixbuf

[geerge]

Thank you for the benchmark link. Love me some benchmarks.

I take only minor issue with this:
First off qoi isn't multithreaded and they're comparing it to libjxl running 8 threads. Second the default qoi encoding isn't an optimal use of the code space, it didn't take much pissing about for me to create a qoi-like that's more space efficient some time ago at no time cost (quicker even when I/O is involved IIRC). If I can be arsed I'll try some benchmarks later.

Turns out I could be arsed to optimise my qoi-like a bit, but only rgb encode for this test: https://github.com/chocolate42/qoi/tree/roi

• qoi 145.1 MP/s 17.1 bpp
• roi 234.8 MP/s 15.0 bpp
• jxl 284.2 MP/s 11.5 bpp

Some of the speed optimisations added to roi could apply to qoi but not all. Single threaded. jxl has AVX2 enabled the other 2 don't use SIMD. roi doesn't use index ops unlike qoi, so SIMD could be applied relatively easily (run ops don't make it fully trivial). Also qoi and roi read the entire file to memory before encoding anything instead of encoding on the fly, this may be a hefty slowdown. I reckon I could make roi faster than jxl if I put enough effort into it, but life's short. Anyway the main thing to note is how much more space efficient roi is over qoi on average, there are examples where qoi produces a slightly smaller file but roi tends to win case by case and by a larger margin. Also something not considered is that qoi and roi are compressible, roi+LZ4 might narrow the gap to jxl considerably (roi would be considered a preprocessor). Might test further, probably won't.

[Quackdoc]

I don't have issues with losslessly recompressed JPGs. In fact, I have almost 200GiB of them. Maybe except gThumb not able to read exif, but this is obviously gThumb issue, exiv2 works OK.
But 8x8DCT is not what JXL is all about. The vardct mode is still not usable beyond sRGB and maybe P3/Rec2020.

edit: this seems to be software issue as well. gThumb and GIMP doesn't seem to enable color management on vardct images. but darktable does! And AdobeRGB looks finally as it should too!

This is an interesting issue. by vardct mode do you mean lossy vs lossless? (vardct mode is default but not mandatory in lossy mode), If so that could be fairly interesting but I might have an idea as to what is going on, libjxl in lossymode converts the image to XYB internally (an entirely different method of representing pixels compared to rgb or yuv, while technically it's a lossy conversion, it's only at the "acktually" level in practice.) so the ICC actually gets made differently (but still accurately) and i'm wondering if gimp/gthumb can't properly work with this, can you possibly send a sample problematic image?

[sobrus]

This is an interesting issue. by vardct mode do you mean lossy vs lossless?

If you compress AdobeRGB JPEG image (even with embedded AdobeRGB ICC profile, usually profile is not attached by a camera, but can be added with exif tools) using:

cjxl orig.jpg --lossless_jpeg=0 -d 1 test.jxl

You will end up with file that has no color management in gimp and gThumb, and looks flat (exactly like AdobeRGB image showed as plain sRGB in non color managed apps). But in Darktable it's OK.

When decoded using djxl, the embedded AdobeRGB ICC color profile will be back in decoded image, although recreated as "D65 blahblabh", but technically probably equivalent to AdobeRGB (didn't checked the rest of params, white point is correct and image displays correctly, including colors outside sRGB space). It would be nicer to have "AdobeRGB (compatible)" shown there, though.