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.
Re:Chrome Jpegxl Issue Reopened
by JyrkiAlakuijala on Thursday December 04, 2025 @02:21PM
(#46151624)
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.
Re:Chrome Jpegxl Issue Reopened
by JyrkiAlakuijala on Thursday December 04, 2025 @02:15PM
(#46151573)
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.
Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.