Hacker Newsnew | past | comments | ask | show | jobs | submitlogin



From my own tests. JXL is better for photos and competitive with AVIF for images with flat areas of color (PNG-like). JXL is about the same speed as AVIF but WebP is quicker than both.


Is this your test, just in case? https://ache.one/articles/web-image-formats

I'm not very sure how you have compared the speed. `cjxl -e 9` for example is known to be very slow because it is AFAIK basically `-e 8` with a brute-force parameter search (and I think this level should be hidden in some way for this exact reason, it is very misleading). Also I assume that you have done an end-to-end command line test with relatively small inputs, which might be a major pitfall (because it doesn't only measure the PNG encoder/decoder but also all program invocation time and finalization time, which can be specficially optimized [1]).

Also only relying on a single objective metric might be misleading, and Jon Sneyers (one of JPEG XL devs) has a very good plot that illustrates this [2] and pointed out that actual images have to be also manually reviewed to reduce mistakes. Many comparisons are made against images with similar SSIM scores, but it is unclear if they indeed had similar qualities. And an ideal perceptual metric is not enough, specifics on "taking the AVIF format points as a basis and comparing them with the similarity and similar ratio points" would be necessary to evaluate the test.

[1] For example you can skip `free` on complicated structures because they will be reclaimed by the kernel anyway. Of course this is totally unacceptable for libraries.

[2] https://twitter.com/jonsneyers/status/1560924579719258113 (The ideal metric should strongly correlate to the human score and should not distort the relative score difference. Most metrics---except for SSIMULACRA 2 which specifically being developed with this dataset---are bad at both.)


JXL is same speed as AVIF ? but what everyone has been commenting is that AVIF is 100x slow


Encoding AVIF is very slow for large images.

Instead of using a breakpoint style approach with several predefined sizes some site generate images related to viewport size at very fine granularity and even changing the viewport by 1px will cause the AVIF to be regenerated

In these cases you can notice services like Cloudinary take several seconds to generate the new variant if it’s a large image


if I understood well, AVIF encoder is quite fast for ugly qualities and very slow for standard and higher quality. https://cloudinary.com/blog/contemplating-codec-comparisons#...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: