jaffathecake

They didn't even have the halo back then!

There was a study done while I was at Google, and I fought for it to be done on high density screens, because that's what most users have. The response was "but people won't be able to see the artifacts" and my head nearly rotated 180 degrees.

But yes, you can see this with jixel, which I'm really impressed by, but it's so tuned to SSIMU2 that it looks really bad to human eyes in some cases compared to libjxl.

JPEG is fast as fuck, due to it being designed for decades old hardware.

When it comes to hardware encoders, the nicest thing you can say about them is they're fast. Software tends to do way better at quality. Hardware AV1 encoders will be tuned for video rather than stills.

OH WAIT. I KNOW WHAT'S HAPPENING HERE.

You're looking at it in a browser that doesn't support JPEG XL, so it's falling back to a WASM renderer, and I think it handles resizing differently.

This is totally my bad. I thought I was doing a good thing by adding that fallback renderer, but it isn't identical and it's giving people the wrong impression.

The lossless version is JPEG XL, hence the difference to AVIF.

What are you talking about? Video formats have a whole mad type parameter for this stuff https://jakearchibald.com/2022/html-codecs-parameter-for-av1...

I agree fwiw. The only one that looks bad to me is jixel at lower qualities.

Apologies if your comment was meant to be a parody as there's a bit of Poe's law around this stuff…

IE never supported AVIF. Edge even shipped AVIF later than Chrome. One of the leaders of JPEG XL worked at Google until relatively recently. A massive amount of JPEG XL development has been done by a team at Google.

Yep, Alpine, and yep, Goodwood! Nicely done!

I was at Google for 10 years, then went to Shopify for 2 years, but I missed the web. For most of the time I was at Google, it mostly did what was good for the web, rather than pushing Google's interests, but that started to change, which is one of things that led to me leaving. E.g. see what happened with the Prompt API.

Claims around JPEG XL have always been wild. E.g. this from one of the creators https://x.com/jyzg/status/1592811472073416704

This doesn't make sense to me. There's enough content negotiation out there that AV2 will need a new content-type parameter. Feature detection is important to browsers.

But the performance is so bad it isn't worth using. You're better off encoding a double height AV1 and mashing it together with WebGL https://jakearchibald.com/2024/video-with-transparency/. That's how bad the situation is.

It's not AVIF that's the issue, the blocker is supporting HDR in general.

No. I used to think this too, but it isn't limited to keyframes.You can convert an AV1 MP4 to AVIF and back losslessly - even if it has non-keyframes. It's just a different container. It has the full AV1 capability. Plus transparency.

You can suggest an "investigation area", which is essentially "how can we make the tests better".

Cheers! It's here https://github.com/mozilla/interop-stack-rank

Anyone could submit a proposal. Look out for that part of the process next year.

This seems like bad wording on GitHub's part https://docs.github.com/en/apps/using-github-apps/authorizin...

> When authorized, the GitHub App will be able to determine which resources you can access that the app can also access.

The 'app' is used for login only. It has no access to resources.

Personally, I like the concept, but not the execution. It only changes its size externally on DOMContentLoaded, and again on load. So, if the user e.g. expands a <details> element, that won't update the size of the iframe. If the width of the main window changes size, resulting in the iframe changing width, resulting in the content within becoming a different height, it won't update the size of the iframe.

In cases like this, the iframe has to manually call window.requestResize(). And… that just doesn't feel like a big step up from the hacks we do today.

It's shipped in Chromium only. It's one of the Interop 2027 proposals, so it's one of the choices in the list.

https://github.com/web-platform-tests/interop/. But… yeah, they should be on the site even before you log in. Let me fix that…

Fixed! Thanks for the suggestion. There was a whole read-only mode already there for when the process closes. I just didn't think of using it when the user is logged out.

As someone who speaks at tech conferences, even someone just saying 'nice talk' as I walk past makes my day.

Hi, I'm the author of the article you're quoting. AVIF was limited at the time of writing, but has since seen massive improvements, including progressive support.

I also called AV1 short-sighted for not including an alpha channel, and corrected someone who claimed jxl-rs was single-threaded. No agenda here - I'm just correcting misinformation and stating my opinions.

I'm not against progressive rendering - I fought for it to be part of the jxl-rs integration in browsers. I've written articles about it https://jakearchibald.com/2025/present-and-future-of-progres....

Just because someone has a different opinion to you doesn't make them part of some grand conspiracy.

jxl-rs is not single threaded.

I dismissed the bandwidth savings in another comment because the increased decode time undid the benefit.

I am not the author of the submission. I have experience in web performance, and my comments come from that experience.

That's fair, at really high resolution, the JXL decoders in browsers do better than JPEG decoders. I'm pretty sure this is a weakness in the JPEG decoder rather than the format, but it's still a meaningful result.

At smaller sizes (more typical on the web), the results are opposite, the JPEG decodes much faster.

I'm not sure where you're getting those numbers from. But, in the cached case, the download time is very fast, yes.

Cool. You're getting different results to everyone else. Do you see the same on https://random-stuff.jakearchibald.com/apps/img-decode-bench... (make sure you use a browser that supports JPEG XL)?

I disagree with this. If I'm in a poor connectivity situation, a preview can help me quickly decide if an image is worth waiting for.

I'm not talking about blurhash here - those are 'cute' at best. I'm talking about previews that let me determine the subject of an image.

I was on a train recently and an image preview X delivered to me was enough for me to tell that the image was a particular meme format, and thanks to context, I knew enough about the image, and didn't bother waiting for it to load.

If you're on a train, or a congested area, even 100 kB is a problem.