Chromium jpegxl issue closed as won't fix | Hacker News Reader

Chromium jpegxl issue closed as won't fix

issues.chromium.org

68 pointsthayne35 comments

No reason was given for the status change.

The reason is clear. "We're not interested in this." Have you not been following this saga for years now?

> No reason was given for the status change

My boss said no.

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.

No activity for a month isn't that unusual the chromium bug tracker from what I've seen (or firefox for that matter).

And closing an issue because of a personal attack from one person on the Internet seems like an overreaction.

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.

Chrome is the new IE 6.

It's a bit better... maybe IE 8.

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

porque no los dos? use <source>

Why would you prefer to have duplicates in different formats when other formats supported by all are available.

This is a common storage vs bandwidth trade-off.

The bandwidth saving is miniscule by any metric though.

and using one image format (or fewer number of them) increases the CDN's cache hit rate, so it decreases latencies and makes your site load faster.

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.

Isn't JPEG XL superior to both of those? PNG was not made to store raster graphics, and AV1 doesn't do progressive loading.

Yeah, it is superior in everything except for support.

> PNG was not made to store raster graphics

I did some searching, found nothing. What do you mean by this statement?

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.

>PNG will normally get at least 2:1 compression on photos

"At least"? I tried with the first photo on the wikipedia home page: https://en.wikipedia.org/wiki/File:City_Building_Champaign_I...

Saving it as a 24-bit bmp (ie. uncompressed) gets me 12,180KB. Saving it as a PNG gets me 7,157KB, which is 1.7: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.

Maintaining a full third image pipeline and bug support it quite a big ask for a few % of superiority.

For huge majority of (even picture heavy) websites you won't get more than 10% of loading time reduction even in the cases where JXL most superior.

You forgot about versatility. If anything, WebP and AVIF formats should never have been added to Chrome due to their glaring limitations.

Sure, but that's an argument for Chrome, not our websites.

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.

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.

[1] https://www.techspot.com/news/101764-google-once-again-accus...

[2] https://opensource.googleblog.com/2024/04/introducing-jpegli...

[3] https://www.reddit.com/r/programming/comments/1ajq7bj/commen...

> literally anything that is reliably supported across all modern browsers

I mean that's the problem, isn't it.

Chrome just gets to decide and they'll cite your non-use to support their decision.

Certainly some issues are chrome vs. the world, but here it is apple vs. the world: https://caniuse.com/jpegxl

Mozilla has it ready to go, and other companies were ready to use it before apple.

Chrome is the blocker.

I use Firefox and Safari and 90% of bugs get responded to with “use chrome”

Than they should respond with "use a modern browser, not chrome". Chrome is just behind

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.

Said JPEG XL style JPEG encoder (fully backwards compatible with existing JPEG decoding): https://github.com/libjxl/libjxl/tree/main/lib/jpegli

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.

Reply on news.ycombinator.com