Comment by F3nd0 | Hacker News Reader

Comment by F3nd0 | Hacker News Reader

Parent Full thread

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 and brings a substantial improvement to quality while also covering a wide range of uses and preserving features that video codecs don't have. It supports progressive decoding, seamless very large image sizes, potentially large amount of channels, is reasonably resilient against generation loss, and more. The fact that it has no major drawbacks alone gives it much more merit than WebP has ever had. Lossless recompression is in addition to all of that.

The difference is that this time around, Google has single-handedly held back the adoption of JPEG XL, while a number of other parties have expressed interest.

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.

Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.

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 gained widespread support in browsers, it had competition from other interesting formats like FLIF, which addressed some of its flaws, and I have to wonder how it compares to the even older JPEG 2000.

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.

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.

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.

You're not being fair. Webp has been the only choice for lossy image compression with alpha layer. Give it some credit.

Fair point, though not entirely true: you can run an image through lossy compression and store the result in a PNG, using tools like pngquant [1]. Likely not as efficient for many kinds of images, but totally doable.

[1] https://pngquant.org/

Reply on news.ycombinator.com