🚀 Release v0.12.0 📦

[eustas]

This is a tracker issue to make sure things do not fall off our radars.

• [x] investigate timeout in djxl fuzzer (@eustas) -- #4384
• [x] ~check if we need to mention #3648 in changelog, or it was introduced in the same version~
• [x] land #4380
• [x] land #4305
• [x] land #4448 / #4449
• [ ] investigate why some malware detectors are unhappy (#4373)
• [ ] finish and land #4313
• [ ] resolve #3887
• [ ] look into other PRs ready for landing (and safe for release)

[jonnyawsom3]

I have a rolling changelog in #4313, I can update it with #3648 if required.

#4368 may be worth looking into before the release too. Most other issues (#4328) have mitigations or workarounds, so can be done later.

#3887 is also a major blocker for mobile support currently, so could be considered high priority.

Quite a few JPEGLI PRs are also pending and would be worth merging for the release. Improving quality, density and some major bugfixes since last.

[jonnyawsom3]

I think #3648 was caused by #3561, both of which were in the v0.11 release, so the changelog doesn't need updating.

On Discord Quackdoc said that Highway is the cause of #3887.

[eustas]

Thanks for investigation.

[Galaxy4594]

It would be nice if #4305 got merged for 0.12. I got it working recently and it passes all tests.

[eustas]

Sure!

[jonnyawsom3]

https://github.com/google/jpegli/pull/135, https://github.com/google/jpegli/pull/136 and https://github.com/google/jpegli/pull/138 are ready for merging.

https://github.com/google/jpegli/pull/137 may need more work, as we're unable to test the API due to issues building the DLL.

Afterwards, libjxl needs to be synced with the jpegli repo, due to missing commits in libjxl. This should close numerous issues and improve both quality and density, also allowing for XYB JPEG transcoding to JXL.

[jonnyawsom3]

Hopefully shouldn't take long to fix, but #4447 is a major regression to track.

[mertalev]

I’m not sure if this is the right place to ask, but I’m waiting on https://github.com/google/jpegli/pull/48 and https://github.com/google/jpegli/pull/138 as I currently have to patch the source code with these commits. In general there are user complaints that jpegli is rejecting their JPEG images that look normal in other software, so I have to make such changes for it to be usable. It’s still rejecting some JPEGs and causing friction, but I’m not sure where to make future PRs to accommodate them.

[wwinniww]

Good point. I asked myself. Now that jpegli is in a seperate repository, is it doable for the developers to bring jpegli forward?

There is already software (e.g. XnView) that have jpegli implemented, with remaining bugs. I doubt that's a good thing.

[tocotronaut]

I'm eagerly awaiting the new version. The last release was ages ago.

I think several small development steps would help the format spread.