Comment by out_of_protocol
2 days ago
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Oldie goodie article with charts, comparing webp, jpegxl, avif, jpeg etc. avif is SLOW
2 days ago
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Oldie goodie article with charts, comparing webp, jpegxl, avif, jpeg etc. avif is SLOW
> This consolidates JPEG XL’s position as the best image codec currently available, for both lossless and lossy compression, across the quality range but in particular for high quality to visually lossless quality. It is Pareto-optimal across a wide range of speed settings.
Wow. Nice. Big improvement if JPEG and PNG can be replaced by one codec.
And even better if someone can implement the whole massive spec securely...
Disclaimer: As a manager I led the JPEG XL design, implementation and standardization effort at Google, and as an IC I was responsible for lossy format, encoding heuristics and image quality.
JPEG XL is not that massive.
JPEG XL spec is slightly less than 100 pages, about half the size of the JPEG1 spec.
A simple implementation in j40 was around 7000 lines of code last time I looked, not sure if it is 100 % complete however.
A simple encoder at libjxl-tiny is of similar size and very attractive to be used for expressing similar coding decisions in hardware intended for digital cameras.
A complex speed optimized C++ decoder implementation is ~35000 lines of code, but much of it is not due to the spec, but getting most out of SIMD-powered multi-core computers.
The binary size increase in Chromium on arm for adding (in the past) the C++ decoder was around 200 kB in APK size, possibly around 0.1 %.
This is probably impossible and also not needed. Choose security through compartmentalization (instead of security through correctness that never works), if you really care about security.
Works for me with Qubes OS.
14 replies →
The part I'm more excited for is all the image-like/bundle of image like data that until Jpeg-xl didn't have any good codecs (usually implemented as folders of images). One clear example of this is PBR in blender and friends. (e.g. a combo of normal map, roughness, color, metalness etc)
This is new to me. Can you elaborate please? Perhaps a link to somewhere showcasing this (and contrasting this to other solutions).
1 reply →
> Big improvement if JPEG and PNG can be replaced by one codec.
By one ? Ten maybe: webp, avif, ...
what exactly is this website trying to do? https://i.imgur.com/Q8JGYK3.png
I don't get any of that. Maybe you have a malicious extension installed?
Maybe some form of fingerprinting for ads?
JPEG at lowest quality looks much better here https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#wha...
That means that SSIMULACRA2 does not capture quality perfectly.
Note that in that figure the formats are compared at the same SSIMULACRA2 score, not at the same file size. In the "very low quality" category, JPEG uses ~0.4 bpp (bits per pixel), while JPEG-XL and AVIF use ~0.13 bpp and ~0.1 bpp, respectively, so JPEG is roughly given 4 times as much space to work with. In the "med-low quality" category, JPEG-XL and AVIF use around 0.4 bpp, so perhaps you should compare the "very low quality" JPEG with "med-low quality" JPEG-XL and AVIF.
After reading your comment, I assumed you had missed the bpp difference. Please excuse me if I assumed incorrectly.
Keep in mind that lowest JPEG is 3-4x the size of the lowest JXL and AVIF - similar to the size of their "med-low" (top row).
This doesn't use hardware accelerated decoders and encoders.
Chromium is not using libjxl, which is the decoder that is evaluated in this article. The SVT encoder is much faster than the AOM encoder for AVIF.