JPEG XL file format

Lounge
41

It’s logical to assume this, even more so from their perspective. However (I don’t want to drag this discussion but I think it deserves a bit more nuance) I think the biggest point to add would be patent-encumberence. Many of those formats have failed because patent hogs made it clear that they want a piece of that pie. Apple had some leverage to get HEIF licensed at reasonable prices I think because even MPEG realized that they can’t be too greedy. Would love to hear some details on that.
With Apple in the game of HEIF, camera manufacturers saw an opportunity for something in between jpeg and their homebrew RAW format jungle. The fact that HEIF is so similar to hevc came as a bonus and HEVC was implemented much earlier because hdr-4k just eats memory cards if nobody can license RedRAW (the next patent hogs and boy what a laughably broad patent that RED patent is!)

I agree and yet I think that JXL could just be both at the same time. If there were a good compressed version of EXR who is to say that this would not also be adopted to something benign like a browser? x264 and x265 are capture, intermediate and delivery formats too. Not because they are good at that, but because they can be used like that.

I’m not disagreeing with you but just question if that argument “it exists, we have decoders for it, its reasonably better and free of problematic patents” should be the sole argument…that is disguised by that:

because that statement needs the above qualification or else is demonstrably false.

Just have a play with the codecs and different pics here:
Codec comparison

1 Like
42

A nice writeup of all the benefits of JXL that are hard to neglect:
https://cloudinary.com/blog/the-case-for-jpeg-xl

2 Likes
43

Chrome is dropping jpeg xl support :frowning:

44

was already a discussion topic here :slight_smile:

45

HDPhoto / JPEG XR also failed, while the maths and processes used were ‘just jpeg, just more’ in simpls terms. It was done to make it easy to create / extend current hardware decoders and other fixed-function chips to use it in embedded devices (specially made to be used in photo cameras…). YEARS old by now. Better compression, extremely quick and easy to encode and decode, HDR support, floating point support, lossless mode, more than just 10/12 bit support.
Patents donated to jpeg consortium by Microsoft IIRC. Yet still, nothing… still sad about that one.

1 Like
46

It does not help that many operating systems simply don’t have the content delivery pipeline to support anything but 8-bit sRGB. Thus for content delivery, anything that offers “more” is waiting for the pipeline to improve.

HDR/high bit depth support appears to be a wildly inconsistent mess on Windows, MacOS seems to be a bit ahead in this regard, and sadly Linux support for higher bit depth display output is currently nearly nonexistent. There’s some progress in Wayland but it’s not really there/usable yet. (See the other discussion threads about Wayland color management…) The only “common” way I’ve found to display high dynamic range/wide gamut content on a display that supports it is to encode to HLG or PQ H.265 video and feed it to a smart TV or dedicated streaming device. Encoding a still image to video is pretty inefficient even if the P/B frames are extremely small.

1 Like
47

Heif/avif are of course the video formats used as image format. Encoding it with a huge iframe and just making a single frame movie should work right ?

Anyway , for me high bitdepth is not displaying it in the end. I understand that its needed and different for HDR.

But it’s not like you are ever going to ‘see’ the difference between 12bit and 16bit for instance.

For me it’s being able to store a lot of range , and being able to edit it. Just like the raw files from a camera for instance.

And that’s fine in any modern OS these days . And formats like webp , heif and avif fall short on only offering 8, 10 or maybe 12bit.

While jpeg2000 , jpeg xr, jpeg xl, exr and others do 16bit without issue.

For instance , storing ‘raw’ film scans of negatives . These are quite huge files if stored as 16bit lossless png or something.

So, I’ve been toying with taking a scan , inverting it with my own software, then doing a quite heavy edit on it. My lossless 16bit scan as input is ground truth.
Then see how low i can encode it with jpeg xl while keeping the final output file as a butteraugli distance lower than around 1.2.

Any 10bit input i take , even if compressed lossless , falls short . The huge curve and gamma and contrast changes fall apart on lower ranges. 12bit is hit or miss.
But also any format without proper full chroma (4:4:4) is basically a no go.

So, storing the scans with a touch of lossy compression from jpeg xl , but keeping them full res 16bit creates files waaay smaller than any other formats i tried , without any kind of bitdepth or chroma subsampling issues while editing . ND also not having to wait a couple of minutes to compress a single 40mpixel scan :).

Jpeg xl is absolutely king here , and can store 400mb tiff files as <20mb files while keeping the final edited output visually indistinguishable .
Also, the included distance encoding means j don’t have to think about if a file is difficult to compress or not (kinda like x264 CRF mode ). It will basically guarantee a certain quality level , no matter the input complexity. This is very nice for batch work.

This format deserves it soooo badly to get traction and widespread use IMHO.

1 Like
48

i have 10bit display support in vkdt. it requires support from your GPU, cable (display port?), and monitor. it’s not hard to get if you avoid using all the old/bloated/focus-on-something-else libraries. this is plain xorg/vulkan (or opengl would work too). need to set some Depth 30 in a Display section in xorg.conf.

the thing is that with a bit of dithering it’s really hard to tell the difference on a 4k display.

agreed.

49

The bit depth w/ JPEG XL is a bit of moot point for the lossy mode:

If you start with high quality input (16b or float), you’ll notice that for a given non-zero distance, you’ll end up with the same file size no matter what bit depth you choose, because the internal representation is actually always float. The bit depth matters when you decode - if you don’t request a specific format out of the JPEG XL decoder, it’ll convert to the bit depth that was recorded at encoding time (this makes sense for delivering e.g. 8b sRGB images for the web as the lowest common denominator).

It is only in the lossless mode where bit depth is kept verbatim, but that is not so interesting compared to other lossless codecs (apart from the fact there is more choice in depths).

1 Like
50

You can set 10-bit mode, but can you set the system to use a transfer function other than sRGB, and send the appropriate metadata?

10-bit is honestly not that useful without the PQ or HLG transfer functions, along with appropriate metadata output over DP or HDMI to indicate Rec.2020 instead of sRGB/Rec709. At least two years ago, Intel’s patches to support the metadata output over HDMI was still unmerged in the upstream kernel, but that might finally have changed.

10 bit PQ or HLG + Rec2020 vs. any Rec709 setup regardless of bit depth is night and day on a capable display. So far, triggering such a display to enter the proper mode is extremely difficult unless you feed an H.265 video with appropriate metadata to the TV itself, or to a streaming device like a Chromecast.

So far the only way I’ve ever successfully output an HDMI signal with appropriate metadata to trigger my Vizio’s HDR modes is with a Blackmagic Ultrastudio Monitor

Sadly, most HDR-capable smart TVs and/or streaming devices are designed assuming video. In many cases, what happens is that in the best case, they see a single frame movie, and as soon as it ends they cancel playback and exit out… I’ve generally found myself having to encode 30 seconds worth (fortunately the P/B frames are quite small) to give myself enough time to hit the “pause playback” button. I’m not even sure if HEIC supports SEI metadata. ICC profiles aren’t a thing for H.265 video, so any ICC metadata is going to get ignored. https://www.loc.gov/preservation/digital/formats/fdd/fdd000526.shtml does mention SEI, although again, I’m not sure what happens if you embed, for example, an ATC SEI into an HEIC file’s bitstream.

51

Here is the Hacker News discussion, with some of the developers participating: The case for JPEG XL | Hacker News

4 Likes
52

FYI, darktable master as of now provides JPEG XL support, for both export and import (credits to cyruscook and victoryforce), so please feel free to test (libjxl 0.7.0 is a minimum requirement).

5 Likes
53

Oh wow! That thread has Jon Sneyers and Jyrki Alakuijala, the lead devs if I remeber correctly, answer stuff. It is so rich in information. Thanks for that link!
IMHO this is a must read.

1 Like
54

I’ve been playing about with JPEG XL for a while, now - fantastic format. I use an Arch-based distro with KDE Plasma, and there’s a plugin available that provides JXL support to all of my KDE apps - as well as GIMP and FEH!

I can’t believe Google have dropped support for it in Chromium!

2 Likes
55

Someone is trying to revert the Chromium commit that added the JPEG XL deprecation note... 👀https://t.co/AqK2NTOPJw pic.twitter.com/WKcDDfwNLF

— Jon Sneyers (@jonsneyers) November 30, 2022

JPEG XL support has entered the top 10 of most requested Chromium features: https://t.co/AOmNj4jS4V

Specifically in the Blink component (the actual browser engine itself), it's currently in the top 4 and could enter the top 3 soon:https://t.co/23Dawf86fW

— Jon Sneyers (@jonsneyers) November 30, 2022
56

I must have something wrong… I noticed for some time that libjxl was listed as not found when I was building. I never used it so I wasn’t worried but after reading this thread I went and added it to my system from msys2 packages. DT finds it during the build and I have no errors. I have the option in export… I tried a few settings but it seems to just hang while trying to export. I can cancel the exports without any crashing or issues so I must be still missing something??

EDIT

Ah seems to be working now…took a restart and second try… now I just have to see how to manage them in windows XNviewMP seems to read them fine

57

From here:

Found

Does this seem safe any thoughs??

Or any other ways to add this support to Win11 anyone knows of??

58

I always disable thumbnails in windows so i didn’t go looking for a thumbnail handler.

I use irfanview as a viewer , which handles jpeg xl (you do have to enable it somewhere because it’s still an experimental feature ).

59

Well it enables WIC so that you can use it in many apps and the os…so it initially was a thumbnail provider but it adds support beyond that…

I usually use Faststone but this one was mentioned… https://photoqt.org/

60

I tried it. Meh… Looks like a phone app running on the desktop. HUGE widgets, strange clumsy UI, IMO. Uninstalled. Nowhere near the level of FastStone nor XnView MP.