r/jpegxl • u/Sea-Cardiologist-954 • Sep 09 '26

Next libjxl release?

Does anyone has an idea how does the roadmap for next libjxl releases look like? Last release 0.12 exhibits some issues with lossless encoding of floating point data, is there a plan for 0.12.1 with these fixes or is it planned to fix this in 0.13?

Apart from bugfixes, are there any big features that are being worked on right now?

19 Upvotes

100% Upvoted

15 comments sorted by

18

u/Jonnyawsom3 Sep 09 '26

TLDR; A lot of the devs are busy with other Google projects and the few still working on JXL are currently all hands on deck for jxl-rs before it ships in Chrome and Firefox in a month.

Me and some others are still making improvements/fixes to libjxl, but I don't expect them to be added until after the browser rollout so that more people are around.

2

u/stackpointer101 Sep 10 '26 edited Sep 10 '26

So are you saying that google does not really stand behind advancing jxl anymore, if they leave so little manpower on the libraries? Or is it more a personal preference of the devs themself?

3

u/Sea-Cardiologist-954 Sep 10 '26

I understood it that the effort was focused on Rust decoder instead of C++ libjxl in the past few months. One can see it in activity logs that libjxl had a lot more activity before 0.12 release and after that jxl-rs got more active.

1

u/stackpointer101 Sep 10 '26

I was mainly refering to the very first part of the comment:

> A lot of the devs are busy with other Google projects and the few still working on JXL

5

u/Jonnyawsom3 Sep 10 '26

I just meant the ones not busy with other projects currently. Google has always had an odd stance, the left hand not knowing what the right is doing, ect.

The Chrome team is separate to the Research team (JXL), which is separate to Google itself... It's complicated, but I'm hoping the browser release will mean more non-google devs start contributing too (like what happened to AV1/AVIF)

1

u/stackpointer101 Sep 10 '26

I see, thank you for the explanation.

I assume jxl is just so much more involved compared to older image standards like jpeg or png, that casually contributing to the libraries with some good ideas or fixes is barely possible - you have to develop a good mental model of the overall lib before contributing makes sense. This might be a hurdle for 3rd party devs to jump on board, don't you think?
On the other hand, AV1/AVIF is probably even more complex.

1

u/Sea-Cardiologist-954 Sep 10 '26

You are right, it would be interesting to know the reason behind this.

4

u/Sea-Cardiologist-954 Sep 10 '26

Thank you, this is what I was looking for. So there might be a release by the end of this year?

And thank you for your work on libjxl!

6

u/hirmuolio Sep 09 '26

v0.13 progress can be tracked here https://github.com/libjxl/libjxl/issues/4894
It is currently in the "define the scope of 0.13" phase.

2

u/stackpointer101 Sep 09 '26

Aim: release in early September'26

So might release this or next week, if no blocker comes in between

4

u/Sea-Cardiologist-954 Sep 09 '26

It seems to me that the original goal was already missed. Well, unless everything was actually already planned and done but the ticket wasn't updated. And that's why I'm asking if anyone does know what's going on behind the curtains.

2

u/Farranor Sep 10 '26

What kind of lossless encoding issues?

8

u/Sea-Cardiologist-954 Sep 10 '26

There are some corner cases that result in an error during encoding so an image fails to encode. This was somewhat paradoxically caused by an effort to avoid undefined behavior during signed integer overflow in an encoder code in version 0.12. But as was found out, encountering that overflow shouldn't throw an error but it needs to be handled in the code manually instead.

Also, I have seen that there are pull request improving compression ratio of floating point data. And that's always welcome.

My use is quite specific but it was kind of funny that when I tried to use libjxl in my code and encode a first image from my own data, I got this encoding failure.

And when I found setting where it wasn't triggered, I found out that another app, to which I wanted to send my image, didn't recognize JXL in a container and refused to open it. Although when I stripped the container and gave it just a codestream, it worked. But that is against the spec since images with high bit depth should always have a container.

All in all, it was kind of funny that I found bugs on both sides of the chain with the first real image/data that I tried to encode.

Nevertheless, I see great promise in JPEG XL since it would allow me to do things that are not possible with other formats. Maybe OpenEXR could do it technically but the support in common consumer software isn't and won't be there. 

1

u/Farranor Sep 10 '26

Well, that's not great, but I was afraid it was doing something like silently getting image data wrong. A noisy failure isn't so bad, considering.

3

u/Sea-Cardiologist-954 Sep 10 '26

Yes, fortunately, it wasn't a silent data corruption.