undefined | Better HN

0 pointscjawdb2y ago0 comments

They did. It's called JXL. JXL is clearly technically superior to WebP and AVIF and the decisions from the Chromium team (not even Google as a whole, since they have a Google Research team working on JXL encoders/decoders) have faced a ton of criticism because they're vague and mostly false and seem to be based on internal politics and Chromium being able to dictate web standards due to having de facto control over the browser engine market.

0 comments

google2341232y ago

Looks like it maybe gives 10% better quality? Meh... that's the reason why nothing will come of this in the end. Come back when you have something 50% better

cjawdbOP2y ago

I mean, you realize that there are mathematical limits to how much you can compress information, right? And WebP/AVIF didn't achieve anywhere near 50% and were adopted by the Chromium team without issue because a few of them actually MADE those codecs/formats.

JXL has better compression than AVIF (by 10-15% on average) and WebP (by 20-25% on average and the latest JPEG encoders like MozJPG (by 30-35%). It also encodes well (even the AVIF devs admitted that JXL was "faster across the board with single-core encode and decode speeds and is more parallelizable than AVIF" in a since-deleted official blog post), which is extremely important.

You can convert existing JPEGs for ~20% savings and the process is lossless and reversible. You can also lossily convert existing JPEGs for even more while still targeting a visually-lossless quality.

It also has progressive decode, which is extremely valuable to anyone hosting web images since JXL can deliver a full-image preview thumbnail from the sole, full-quality JXL file by only sending 15-20% of the total size. This can be tuned to target things like faces or foreground objects. WebP and AVIF do not support progressive decode and thus a separate, additional, low-quality thumbnail copy must be encoded + stored + delivered.

It has 4099 additional channels (vs. WebP's 4 and AVIF's 5) which can be used for things like selection masks, spot colors, etc. There have been posts from researchers in other interesting fields such as bio/medical tech for storing additional imagining data in these channels.

The max resolution limits are over a billion pixels on each side, whereas WebP is 16k and AVIF has either a) surprisingly low limits if being used in lossless mode or b) lower limits than JXL but at least more reasonable if you're willing to suffer visual artifacting on the boundaries of some tiling technique it uses.

JXL has a max bit depth of 32 vs. WebP's 8 (no HDR support) or AVIF's 12.

Support for overlays/layers, depth maps, 4:4:4 lossy (AVIF can do these but WebP cannot).

Much better generation loss resistance than JPEG/WebP/AVIF.

The tiniest header (12 bytes, smaller than AVIF/WebP/JPEG/PNG/GIF with AVIF being easily the worst of them all at 298 bytes).

> That's why nothing will come of this in the end.

I highly doubt that, considering the incredible level of support and interest it's received from large corporations even though it only finished standardization a bit over a year ago. Codec adoption doesn't happen overnight, but JXL has progressed WAY faster than WebP or AVIF did in my experience. It already has support in macOS/iOS/Safari, Adobe products, Serif Affinity products, GIMP, Krita, Paint.NET, Darktable, ffmpeg, ImageMagick, libvips, the entire Qt/KDE ecosystem, basically every Linux distro. Samsung added partial support like a week or two ago for the S24 line (you can save using its RAW format and compression and the Samsung Gallery app can obviously decode and view those) and Windows is apparently adding support to WIC based on leaks from like a week ago, which means native support in Windows (including Explorer and the default Image Viewer, although basically every third party viewer of note has also had JXL support for over a year now).

There are forks of Chromium (Thorium) and Firefox (Waterfox and Pale Moon) with support that seems very solid from my basic testing on it months ago. And senior engineers from big web-oriented companies like Facebook, Shopify, and Cloudinary and other tech companies like Intel and nVidia expressed their support for JXL and disappointment with the Chromium team's poorly-justified decision to abandon JXL support.

All that and Google Research has people actively working on JXL encoders/decoders. It really is just the Chromium team blocking things (and Firefox saying they're neutral and just sitting there on the sidelines because no serious website is going to deliver JXL content without Chromium's dominant userbase having support and Mozilla doesn't necessarily have the resources to spend on what would solely be a political statement).

(sorry for ranting, but I actually feel like JXL is actually the next "universal image format" for years to come in a way that I never did about shit like JPG2000, WebP, or HEIF/HEIC or AVIF, once the rest of the tech industry gets around to removing the Chromium teams' head from their ass)

j / k navigate · click thread line to collapse