To me (As an outside observer) the reason for the status change seemed pretty clear. There was no activity on the issue for a month and a half, and then someone made a new comment that personally attacked a google employee by name as a bad faith actor. Of course google is going to shut that down real quick.
They closed the ticket 12 minutes after that comment. It seems unlikely a coincidence. If someone wanted a reason to shut this down that comment gave them all the ammunition they needed. Don't forget, Google is not a singular entity and is made up of individuals with differing opinions, some of which are pro and some against jpegxl, but like any human social group, if you cause them to feel that one of their own is being attacked they are almost certain to close ranks.
There is an annoying guy on our team (Apple fanboy), he insists on using Jpeg XL even though I have begged him to use png or av1 or literally anything that is reliably supported across all modern browsers. I ended up using https://github.com/zamfofex/jxl-crx
JPEGXL makes a lot of sense though. You can encode as JPEG XL and then reencode to older formats or lower qualities with minimal effort. That's part of the reason JPEG XL is set up the way it is.
Even just re-encoding a JPEG XL image into old-school JPEG using the modern JPEG XL techniques (or just directly encoding into JPEG XL style JPEG) will result in a higher visual quality and better compression ratio than just creating a normal old-school JPEG.
If you look into the architecture and design rationale of JPEG XL you'll notice that even if you don't use it as a downstream image format, just keeping it as your "source format" can give you a lot of benefits for your image encoding and delivery pipeline.
It's all about convenience for him, Apple's tools generate Jpeg XL so he can't be bothered to resave it for anyone else. He's like "I use Safari and it works fine"
No Apple tools generate JPEG XL by default. You can, of course, export as jxl on newer OSes, since it's built in, but it's not a default. iOS devices still use HEIC as the default "new" image format, but convert to regular JPEG when shared with services which don't support it.
Google, (the Google Chrome team), have stated before that "[JPEG XL] doesn't provide significant benefits over existing image formats" [1] and have been vocal in there disinterest in shipping support for it (they deprecated experimental support) [1]
My guess is that the newest/latest JPEG encoder developed by Google researchers, Jpegli[2], has a lot to do with this. Jpegli has been described in a Reddit comment as "a JPEG encoder that was developed by the JXL [JPEG XL] folks and the libjxl psychovisual model" and described to have superior performance to WebP (lossy WebP) [3]. that whole reddit thread has comments relevant to this discussion, specifically about the tradeoffs of supporting extra formats in browsers.
But that's kind of the thing with JPEG XL. It's designed specifically so you can store everything as JXL and "downcast" to older formats for little to no cost.
JXL downscaling is practically a free operation that allows you to very effectively deliver multiple image sizes from a single copy.
JXL -> JPEG re-encode is very cheap and results in nicer looking, better compressed JPEGs than using traditional JPEG encoders.
And for formats like PNG, JXL should be able to hold that same data in roughly the same size (or less) without any visible data loss (or none at all for a slightly larger filesize). So converting down to PNGs at different sizes just becomes it's own pipeline if you still need that (over JPEGs or JXLs).
It's the first thing close to a universal image format which is part of the reason some people push so heavily for it.
The PNG file format is essentially ZIP(BMP), trying to compress the raw pixels in a pretty naive way. It works extremely well for diagrams and large blocks of identical colours. But for real-world photos, AAA game screenshots, or even just linear gradients, it doesn't offer any size compression at all.
The raster/vector dichotomy is a bit orthogonal to this and perhaps not quite the right choice of words. PNG is still a raster format as it stores the final pixels. Only that it's better suited for images that originated from a vector source, rather than images that have been rasterized out of a camera CCD or a video game engine.
>But for real-world photos, AAA game screenshots, or even just linear gradients, it doesn't offer any size compression at all.
PNG will normally get at least 2:1 compression on photos, I think worst case with a image of each pixel being a different color of 16 million pixels it still had around 35% compression.
2:1 is much less than jpeg which would probably be around 10:1 for photo, its definitely better than nothing, and the big thing here is its lossless unlike jpeg.
It's not naive, it's just not lossy like jpeg. Jpeg XL also supports lossless with around 35% better compression than PNG so that means may 3:1 vs 2:1.
I just did the same in preview on my Mac (export TIFF uncompressed - 12mb -> export PNG) and got 5.4mb so 2.2:1 and on https://cloudconvert.com 4.6mb with default settings.
PNG does have some tuning parameters that can effect the final size usually just speed vs size.
Using plain gzip -9 on the 12MB uncompressed image, i get 6953 KiB, smaller than your PNG. Using a stronger gzip compressor (zopfli) i get as little as 6294 KiB.