Chrome Jpegxl Issue Reopened • Hacker News Board

Re: Chrome Jpegxl Issue Reopened

#141

Post by hirako2000 » Thu, Nov 27, 2025, 1:56 PM UTC

magicalist wrote: post #128

hirako2000 wrote: post #72

Earlier quoted context omitted.

You are correct it is possible to upload avif files into Google Photo. But you lose the view and of course the thumbnail. Defeating the whole purpose of putting them into Photo. Given it's an app, they didn't even need Google chrome to add support. Avif is supported on Android natively.

> You are correct it is possible to upload avif files into Google Photo. But you lose the view and of course the thumbnail. I'm not sure what you mean. They appear to act like any other photo in the interface. You can view them and they're visible in the thumbnail view, but maybe I'm misinterpreting what you mean?

Or perhaps I don't see what you see.

I take a photo, the format is jpeg. It backs up to Google photo, the Google photo app on Android renders the photo just fine.

I then convert that photo (via a local converter) to AVIF, Google backs it up, I can see the file in Google Photo on Android but it doesn't render the image. That being full size or thumbnail, all I get is a grayed square. So I concluded the app doesn't support avif rasterizing.

I then gave up on the automation that converted all my jpeg into avif, which in turn would have saved hundred of gigabytes given I have 10y worth of photos.

The experiment was done about 3 months ago, as of 2025 Google Photo on Android, latest version, would not render my AVIF photos.

Re: Chrome Jpegxl Issue Reopened

#142

Post by F3nd0 » Fri, Nov 28, 2025, 1:16 PM UTC

Dwedit wrote: post #137

F3nd0 wrote: post #63

Earlier quoted context omitted.

In context of the parent comment, 'only 20% improvement' is not super exciting, 'compared to the pain of dealing with yet another new image format'. You raise a good point, though; WebP certainly did (and continues to do) well in some areas, but at the cost of lacking in others. Moreover, when considering a format for adoption, one should compare it with other candidates for adoption, too. And years before WebP gaine…

FLIF got integrated in to JPEG-XL as the modular mode.

If I recall correctly, that's FUIF, originally created by the same author as FLIF's successor of sorts.

Re: Chrome Jpegxl Issue Reopened

#143

Post by JyrkiAlakuijala » Thu, Dec 04, 2025, 7:15 PM UTC

Dwedit wrote: post #24

F3nd0 wrote: post #21

Earlier quoted context omitted.

If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs. JPEG XL is the first image format in a long while that's been actually designed for images…

Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression. Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.

When I built WebP lossless format I kept testing design decisions against PNG. The average gain against my Internet PNG test corpus was 42 % and 26.5 % if I optimized the PNGs with pngcrush and pngout (kzip). I had not yet come up with ZopfliPNG ideas, those were backports from some WebP lossless ideas into gzip and PNG.

Re: Chrome Jpegxl Issue Reopened

#144

Post by JyrkiAlakuijala » Thu, Dec 04, 2025, 7:21 PM UTC

Dwedit wrote: post #137

F3nd0 wrote: post #63

Earlier quoted context omitted.

In context of the parent comment, 'only 20% improvement' is not super exciting, 'compared to the pain of dealing with yet another new image format'. You raise a good point, though; WebP certainly did (and continues to do) well in some areas, but at the cost of lacking in others. Moreover, when considering a format for adoption, one should compare it with other candidates for adoption, too. And years before WebP gaine…

FLIF got integrated in to JPEG-XL as the modular mode.

Not really. FLIF is too slow to decode, about 20x slower than WebP lossless. JPEG XL modular mode uses a similar static context modeling with WebP lossless and Brotli and likely LZHAM where all the entropy codes are generated at decoding time. Also JPEG XL forces tiled coding, making multi-threaded decoding a possibility.