Comment by pixelesque
2 days ago
Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.
And it really was the right move at the time, imo. JXL however now has better implementations and better momentum in the wider ecosystem and not just yet another image format that gets put into chrome and de facto becomes a standard.
I can confirm. I found multiple problems in the "official" cjxl encoder back in 2023 contrary to the webp2 (cwp2) implementation where I could not find any bug or error.
If the encoder have obvious problems it is not a big deal, but it doesn't bode well for the decoder.
CVE-2023-0645 in libjxl that year too, and several since
1 reply →
https://www.google.com/search?q=what+the+old+man+does+is+alw...
http://hca.gilead.org.il/old_man.html
Aviso: http
Hahaha perfect! Can't believe I never heard this story before.
Forcing other companies to override them is a way to prove momentum but it's not a good way to prove momentum.
> duplicating largely what AVIF provided
That's not a great bar since both of them showed up around the same time. And importantly JXL hits many use cases that AVIF doesn't.
> while being written in an unsafe language
They put little emphasis on that part when they were rejecting JXL. If they wanted to call for a safer implementation they could have done that.