Hacker News

I had the same problem with AVIF. My platform allows users to “scrub” through a video file they’ve uploaded by hovering over the thumbnail. To achieve this it creates a grid of 100 representative frames, up to 480px in width per frame. So the images are pretty large and take up a lot of space in JPEG format. File size is important because it reduces lag time before the thumbnail is scrubbable.

We tried AVIF and file sizes were much better but it would take multiple minutes just to generate. We also got feedback from our self-hosted customers that it was using way too many of their system resources.

So we’re now using WebP which generates in about 10 secs using much less CPU. I’m open to JPEG XL if it can improve on those metrics.

To make sure I understand, your concern specifically applies to images that your application server is rendering custom for each visitor?

I'm assuming that for more persistent, cachable types of images, there wouldn't likely be that type of problem, right?

The article brings attention to advancements in AVIF encoders over the past few years (to which its author has greatly contributed), but does not provide a definitive comparison between the two formats, even when it comes to the web. Parts of it are entirely based on personal opinions and educated guesses.

There are some unanswered questions about the methodology used, the resources spent on development of the respective encoders is not taken into consideration, the future developments of JPEG XL encoding are written off as too costly and the author’s opinion on what kind of content is appropriate for the web is quite subjective. See also the recent discussion:

https://news.ycombinator.com/item?id=49690554

Obviously, once the Google overlords decided it.

Unless you're targeting really old browsers, lossless WebP is absolutely worth it over PNG.

As a test, I have a set of 36 old MS paint Drawings, originally drawn on Windows 98SE, originally saved in bitmap format with a total size of 53.4 MB.

Transcoded to PNG format using FFmpeg and the highest -compression_level of 100, this same set of images takes up 403.8 kB.

Transcoded to -lossless WebP format using FFmpeg and libwebp with the maximum -quality value of 100 and maximum -compression_level of 6, the set of images takes up 174.8 kB.

Transcoded to lossless JPEG XL format using cjxl in the highest compression settings, the 36 images only takes up 126.6 kB.

Given the computing power required to decode JPEG XL images and their limited support, it may not make sense to use JPEG XL for non-archival purposes, but lossless WebP is an excellent middle-ground, achieving over 2x the compression level of PNG.

Lossless WebP has also been supported by all major web browsers since September 2022, when Apple finally added full support for lossless and animated WebP images. It really doesn't make sense to still be using PNG, unless you're targeting really out-of-date Mac or iOS devices. Having drawings and illustrations be 50% smaller (versus PNG) is huge!

I used to think this and then I saw how well webp reduced my website's bandwidth costs compared to optimized jpg or png. I felt a bit left behind at that moment, like I should have been paying attention to these great improvements over the years.

JPEGXL literally is able to display images and colors that jpeg and png cannot (32-but floating point, layers, emission independent transparency, spot colors, built im depth maps). It’s not just about compression optimization. So for those use cases standard JPEG and PNG alone will never work. There are “updated” versions of JPEG that support some of these like HDR but those won’t work with any old browser either so back to the same issue.

JXL has clear advantages and saying you don't see them means you either didn't attempt to see them or willfully ignore them

I just switched over some machine vision code to use it for the lossless format, saving around 30% file size (~5 gigabytes per dataset) over optimized lossless PNG. I'll gladly take any storage donations you may be passing out though, so I can continue to use the good old and proven formats! ;)

James Brown recorded his music to sound good over an AM radio. It still sounds good on good equipment.

Meanwhile, there's a lot of modern music that takes full advantage of quality gear, but is basically unlistenable on bad speakers.

There's nothing wrong with either approach, but if you're not trying to raise the bar why not just stick with the lowest common denominator?

biggest advantage for me is file size and lossless conversion of existing jpg images. In a network scenario that can meaningfully impact load times. Others will care about e.g. bit depth

For one, it allowed me to fit several years of photos in a few gigabytes so I can easily back them up without going broke.

JXL supports extra channels for multispectral images.

You should add that line to your resume.

> the average domestic connection being gigabit

This strongly depends on where your domicile is, even in Europe and the US. And lot of the users live outside these areas.

> JPEG was fine in the days we had much slower connections

Except that waiting for a large picture to load was very much thing, and in many cases still is.

> What are the benefit for the final user?

A number of users are still on metered mobile plans, and have little storage on their phones. With the current situation in electronics production, new phones are not going to offer more space, cheaper; to the contrary.

Also, publishing larger / better quality images becomes easier and cheaper.

> What are the benefit for the final user?

Many that you can search the web for, but to address the specific points you mentioned off the top of my head:

- Lower cell data usage for users

- Not everyone has gigabit fiber

The issue for me is that RAW sucks, and Jpeg also sucks. Jpegs are standardized and display anywhere, but are also super lossy. RAW, like fish, is not actually a thing beyond a sorta "I know it when I see it" deal. It's non-standard even between camera models from the same manufacturer, and there are like 10 pieces of software that bother with this bullshit and afaik none of them are OSes or browsers.

First, try explaining to a non-tech person the difference between jpeg and png and they commonly scratch their head. It's nice to have a single format covering lossy and lossless, just meaning "picture". Whether it's a photo where lossless is ok or some icon where it isn't should be insubstantial.

Second, the "all connections are fast, what's the point" is one reason why the web is so slow. Connections are often slower than the dev with his 1gbps connect feels every day. The average website loads slower (in wall clock time) than it did 15 years ago. Smaller files and fewer network round trips would do everybody a favor.

The original libjxl was written in C and has been riddled with security issues. It’s been rewritten in Rust which is what has been shipped by Chrome and soon Firefox.

I have to think this is a substantial reason for the backflip here as adding a new huge C library to browsers is a huge concern.

Hurrah!

> Big companies have big egos

More likely the Google eng. director who tried to get rid of it because of not-invented-here syndrome (it was built in a different org) got a new job or changed company.

No, that was not part of the reason the Google Chrome team gave: https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...

that's what firefox said, not chrome

Probably why Google implemented their own decoder in Rust

https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...

> nobody benifits from supporting it

Do you mean the users of the browsers not benefitting, or specific Google employees/stakeholders?

Removed because having yet another giant C codec was a huge risk, re-added because the PDF Association chose JXL as their next image format so anyone rendering PDFs (including browsers) is now required to have it.

> Why can't it be shipped as a shared library for the whole system to use?

Flashbacks to DataTypes on the Amiga: https://wiki.amigaos.net/wiki/Datatypes_Library

This way browser vendors control what their app supports, and won't have something break because a user doesn't have a library.

> Why can't it be shipped as a shared library for the whole system to use?

That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.

Google seems to prefer reimplementing every portion of an OS possible in Chrome.

Given that there are more operating systems than browser engines these days, I'm not sure this would be an unequivocal win.

Because browsers want to provide a consistent platform and can’t rely on OS vendors to do it in the way they need and prioritize their interests.

But it is a shared library? It's used in both Chrome and Firefox.

> Why can't it be shipped as a shared library

Shared libraries are a bad idea that is simply taking way too long to just die the horrible death it deserves.

Such an important piece of software does not want to subject itself to the packaging and support woes of shared libraries. There are security issues, maintainability issues, and much more headache by going with that approach.

Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.

There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.

Still can't upload it to every site that takes images, my file browser doesn't preview them nicely for whatever reason, that kind of stuff.

It's frankly pointless. Pretty much nothing produces them natively, so it's usually a generation loss from JPEG, not enough compression gains without annoyingly visible loss of quality, still has format many format and functional limits so it solved nobody's problem at any time, pretty much.

And much (though not all) of its improved compression (before it damages the image too badly) was anyway matched by the better JPEG encoders which were released and improved over time. It sure benched very well against a 30+ year old JPEG encoder implementation though.

JXL has a pixel-accurate JPEG-input mode with no generation loss which already beats WebP, a native mode which is way way better even, it addresses many more use cases and is not Google's pet project (saying this while thanking them for all the foundational work from which modern image/video codecs benefit - JXL itself first and foremost!) so it DOES have better than a snowball's chance in hell of becoming the defacto standard of the next 10-30 years and we'll soon see it in silicon.

Poor support in some instances. Apple lagged for a long time for iPhone support. Discord mobile still does not support animated webp's.

webp = VP8 image

Nothing wrong with that per se, it's just old and limited, especially compared to avif/AV1 which would be like a theoretical VP10 at this point.

Poor support makes it feel like a form of DRM.

I think the bigger driver is that, due to it being the next PDF image format, most platforms will already be forced to add some form of support to it.

When literally every OS already comes with a form of libjxl pre-installed there is no good reason not to add support for it.

> you just truncate the output stream at the right proportion of pixel data

Does the format have explicit support for this? As in, is there any easy way to do, say, an exact Range request after reading the file header?

>JPEG-XL is not particularly patent-laden and its license is correct for the use-case.

The same could be said for .webm, but Apple refused to support it because they wanted to patent-laden alternative to thrive.

Can progressive loading be made less fine-grained? With too many levels you don't know, if image is still loading or is just low-res.

Loading vs loaded difference needs to be clear.

> you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)

It's an attack vector for images to have different thumbnail/first bytes than the final image so software still have to decode the whole image.

The problem with progressive rendering is that the user never knows when downloading is complete unless you add loaders to each image.

Yeah. Here is a surprisingly readable article on all the supported features and design decisions of JPEG XL: https://arxiv.org/abs/2506.05987

The format is designed to be as general as possible, potentially replacing many common (JPEG, GIF, PNG) and professional image formats.

For example, JPEG XL supports pages (e.g. for comic books), layers (with variable frame sizes, positions and blend modes) and timed animations.

How about AVIF?

I have not read that many direct comparisons here.

When Apple adopts jxl-rs? Any source for them doing that? I can’t think of any Rust code that Apple is shipping.

Windows has, for a while, had Windows Imaging Component for images (https://learn.microsoft.com/en-us/windows/win32/wic/-wic-lh) and Microsoft Media Foundation for video (https://learn.microsoft.com/en-us/windows/win32/medfound/mic...). Not sure how widespread actual use is though.

Codecs have been a thing on both major OSes, Windows Media Player could open DivX and QuickTime could open MKV. I think they were only limited to videos however.

The user's OS or the LMS should offer to convert it on the spot. Worst case to .bmp

> Why would Google executives want to stop it?

Google and Mozilla executives. The 'why' is not public knowledge. Maybe someone has a personal vendetta against some people involved in jxl.

> Reality is a lot simpler - it wasn't deemed worth the cost of addressing the security problems in the existing library so someone chose to abandon the format.

As evidenced by what? When first rejecting JPEG XL, Google did share their reasoning, but security problems hardly figured in it.

You made me check. iOS only supports JXL in ProRAW mode, which (I hope) most people don't use.

WebP is 15 years old, and Google cares about it less than anybody else. Pretty much everybody else supports WebP but Google can’t even be bothered adding support for it to Google Docs.

Google is one of the main developers of Jpeg XL.

And a nominally “lossless” image may have been reencoded from a lossy source.

Independent preprocessing doesn't make PNG itself lossy.

It's a big deal :(

JPEG artifacts are literally a meme, normal people are aware of this stuff.

I hold the extremist view that had we decided to use .png for lossless webps, it would have been an overall net gain - in people's minds "png" maps roughly to "whoever last touched this image didn't do anything evil to it" - very few people care how the data is actually encoded.

I mean we are already dealing with that nowadays. Many PNGs are either JPEG in a different package or straight up lossy compressed. Unfotunately extensions have never been safe for judge

I've been wishing for years that all of these codecs with hybrid lossless/lossy modes would just add a single l to their file extensions, purely for the annoyance of it.

Like, you can do this individually, but it's not the same thing as actually having it in the standard.

When writing GPU shaders it's not uncommon to use extensions like ".vert.glsl" = "vertex shader written in GLSL", ".frag.hlsl" = "fragment shader written in HLSL", etc.

Multiple extensions typically denote nested filetypes.

Like files.tar.xz may be decompressed with xz and then extracted with tar to get the directory "files".

I think in your case .md.fm would be a greater fit, as the front matter is read first. Or just .fmd

Yeah, the conservative loaders took over.

I’ll see myself out.

Not really.. caniuse is quite literal to its name, as a web dev that's what orients what tech i pick up to deploy today.

Anything below ~90ish% is no go, unless i have a fallback strategy of some sort.

Firefox 158 will ship with it on by default: https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YM...

iPhones have supported it for 3 years.

looks great - jxl-rs is faster since June 2026 (using just a bit more RAM)

"open" in the sense that you have to pay $200 to read it, anyway.

That's good to hear. Let's hope there's hardware adoption on the camera end soon. As an image lib maintainer the codec wars were driving me nuts.

7zip meaning what, LZMA (xz)?

and zstandard outdoes 7zip (LZMA)

I think that’s why they were advocating for gzip or bzip2 instead of just relying on PNG’s built-in compression.

> Does it satisfy the rule of two?

One to embody power, the other one to crave it?

I'm confused about the connection.

Yep.

this does not help me against malicious or incompetent website authors. Mobile browsers usually do not have support for user stylesheets.

Nah iOS really cranks up the screen brightness to display HDR content.

Everytime someone in the world tells the truth about Rust, a lot of "crustracians" went bad...

Folks, it's just a tool