5 ms·

I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it. From a quick look at various "benchmarks" JpegXL seems

by jakkos 8mo ago

I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it. From a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing? My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it.

speps 8mo ago
It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser.
- a-french-anon 8mo ago
  Unmaintained? You must be mistaken, libjxl was getting a healthy stream of commits. The issue was the use of C++ instead of Rust or WUFFS (that Chromium uses for a lot of formats).
- spider-mario 8mo ago
  It’s largely the same people.
jacobp100 8mo ago
JpegXL and AVIF are comparable formats. Google argued you only needed one, and each additional format is a security vulnerability.
- londons_explore 8mo ago
  And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser. I can completely see why the default answer to "should we add x" should be no unless there is a really good reason.
out_of_protocol 8mo ago
- avif is better at low bpp (low-quality images), terrible in lossless - jxl is better at high bpp, best in lossless mode
jmillikin 8mo ago
Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox. The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires.
- latexr 8mo ago
  > The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. I agree with the second part (useless hero images at the top of every post demonstrate it), but not necessarily the first. JPEG is supported pretty much everywhere images are, and it’s the de facto default format for pictures. Most people won’t even know what format they’re using, let alone that they could compress it or use another one. In the words of Hank Hill: > Do I look like I know what a JPEG is? I just want a picture of a god dang hot dog. https://www.youtube.com/watch?v=EvKTOHVGNbg https://www.youtube.com/watch?v=EvKTOHVGNbg
  - jmillikin 8mo ago
    I'm not (only) talking about the general population, but major sites. As a quick sanity check, the following sites are serving images with the `image/jpeg` content type: * CNN (cnn.com): News-related photos on their front page * Reddit (www.reddit.com): User-provided images uploaded to their internal image hosting * Amazon (amazon.com): Product categories on the front page (product images are in WebP) I wouldn't expect to see a lot of WebP on personal homepages or old-style forums, but if bandwidth costs were a meaningful budget line item then I would expect to see ~100% adoption of WebP or AVIF for any image that gets recompressed by a publishing pipeline.
coppsilgold 8mo ago
JPEG XL has progressive decoding https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U
archerx 8mo ago
Google created webp and that is why they are giving it unjustified preferential treatment and has been trying to unreasonably force it down the throat of the internet.
- breppp 8mo ago
  unjustified preferential treatment over jpegxl a format google also had created
  - archerx 8mo ago
    They helped create jpegXL but they are not the sole owner like they are with webp. There is a difference.
    - breppp 8mo ago
      a better argument might be that chrome protects their own vs a research group in google switzerland, however as other mentioned the security implications of another unsafe binary parser in a browser is hardly worth it
      - archerx 8mo ago
        Webp has had major vulnerabilities. https://blog.cloudflare.com/uncovering-the-hidden-webp-vulnerability-cve-2023-4863/ https://blog.cloudflare.com/uncovering-the-hidden-webp-vulne...
        breppp 8mo ago
        which only strengthens my argument, webp seemed like some ad-hoc pet project in chrome, and that ended like most unsafe binary parsers, with critical vulnerabilities
        magicalist 8mo ago
        > webp seemed like some ad-hoc pet project in chrome FWIW webp came from the same "research group in google switzerland" that later developed jpegxl.
rdsubhas 8mo ago
> various "benchmarks" JpegXL seems just be flat out better than WebP The decode speed benchmarks are misleading. WebP has been hardware accelerated since 2013 in Android and 2020 in Apple devices. Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp. JXL is more about future-proofing. Bit depth, Wide gamut HDR, Progressive decoding, Animation, Transparency, etc. JXL does flat out beats AVIF (the image codec, not videos) today. AVIF also pretty much doesn't have hardware decoding in modern phones yet. It makes sense to invest NOW in JXL than on AVIF. For what people use today - unfortunately there is no significant case to beat WebP with the existing momentum. The size vs perceptive quality tradeoffs are not significantly different. For users, things will get worse (worser decode speeds & battery life due to lack of hardware decode) before it gets better. That can take many years – because hey, more features in JXL also means translating that to hardware die space will take more time. Just the software side of things is only now picking up. But for what we all need – it's really necessary to start the JXL journey now.
- Dylan16807 8mo ago
  > Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp. Extra data transfer costs performance and battery life too.
- chocolatkey 8mo ago
  Where can I learn more about hardware acceleration of WebP on mobile OSes? I haven’t yet come across a resource that confirms this is actually the case. I know it should theoretically be possible using the VP8 hardware decoders but I thought those were expensive to warm up just for images
3OCSzk 8mo ago
1 black pixel of .webp is smaller than 1 black pixel of .jpegxl that is also smaller than 1 black pixel of .png so webp > jpegxl > png

by jakkos 8mo ago

speps 8mo ago

It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser.

a-french-anon 8mo ago
Unmaintained? You must be mistaken, libjxl was getting a healthy stream of commits. The issue was the use of C++ instead of Rust or WUFFS (that Chromium uses for a lot of formats).
spider-mario 8mo ago
It’s largely the same people.

jacobp100 8mo ago

JpegXL and AVIF are comparable formats. Google argued you only needed one, and each additional format is a security vulnerability.

londons_explore 8mo ago
And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser. I can completely see why the default answer to "should we add x" should be no unless there is a really good reason.

out_of_protocol 8mo ago

- avif is better at low bpp (low-quality images), terrible in lossless - jxl is better at high bpp, best in lossless mode

jmillikin 8mo ago

Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox. The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires.

latexr 8mo ago
> The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes. I agree with the second part (useless hero images at the top of every post demonstrate it), but not necessarily the first. JPEG is supported pretty much everywhere images are, and it’s the de facto default format for pictures. Most people won’t even know what format they’re using, let alone that they could compress it or use another one. In the words of Hank Hill: > Do I look like I know what a JPEG is? I just want a picture of a god dang hot dog. https://www.youtube.com/watch?v=EvKTOHVGNbg https://www.youtube.com/watch?v=EvKTOHVGNbg
- jmillikin 8mo ago
  I'm not (only) talking about the general population, but major sites. As a quick sanity check, the following sites are serving images with the `image/jpeg` content type: * CNN (cnn.com): News-related photos on their front page * Reddit (www.reddit.com): User-provided images uploaded to their internal image hosting * Amazon (amazon.com): Product categories on the front page (product images are in WebP) I wouldn't expect to see a lot of WebP on personal homepages or old-style forums, but if bandwidth costs were a meaningful budget line item then I would expect to see ~100% adoption of WebP or AVIF for any image that gets recompressed by a publishing pipeline.

coppsilgold 8mo ago

JPEG XL has progressive decoding https://www.youtube.com/watch?v=UphN1_7nP8U https://www.youtube.com/watch?v=UphN1_7nP8U

archerx 8mo ago

Google created webp and that is why they are giving it unjustified preferential treatment and has been trying to unreasonably force it down the throat of the internet.

breppp 8mo ago
unjustified preferential treatment over jpegxl a format google also had created
- archerx 8mo ago
  They helped create jpegXL but they are not the sole owner like they are with webp. There is a difference.
  - breppp 8mo ago
    a better argument might be that chrome protects their own vs a research group in google switzerland, however as other mentioned the security implications of another unsafe binary parser in a browser is hardly worth it
    - archerx 8mo ago
      Webp has had major vulnerabilities. https://blog.cloudflare.com/uncovering-the-hidden-webp-vulnerability-cve-2023-4863/ https://blog.cloudflare.com/uncovering-the-hidden-webp-vulne...
      - breppp 8mo ago
        which only strengthens my argument, webp seemed like some ad-hoc pet project in chrome, and that ended like most unsafe binary parsers, with critical vulnerabilities
        magicalist 8mo ago
        > webp seemed like some ad-hoc pet project in chrome FWIW webp came from the same "research group in google switzerland" that later developed jpegxl.

rdsubhas 8mo ago

> various "benchmarks" JpegXL seems just be flat out better than WebP The decode speed benchmarks are misleading. WebP has been hardware accelerated since 2013 in Android and 2020 in Apple devices. Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp. JXL is more about future-proofing. Bit depth, Wide gamut HDR, Progressive decoding, Animation, Transparency, etc. JXL does flat out beats AVIF (the image codec, not videos) today. AVIF also pretty much doesn't have hardware decoding in modern phones yet. It makes sense to invest NOW in JXL than on AVIF. For what people use today - unfortunately there is no significant case to beat WebP with the existing momentum. The size vs perceptive quality tradeoffs are not significantly different. For users, things will get worse (worser decode speeds & battery life due to lack of hardware decode) before it gets better. That can take many years – because hey, more features in JXL also means translating that to hardware die space will take more time. Just the software side of things is only now picking up. But for what we all need – it's really necessary to start the JXL journey now.

Dylan16807 8mo ago
> Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp. Extra data transfer costs performance and battery life too.
chocolatkey 8mo ago
Where can I learn more about hardware acceleration of WebP on mobile OSes? I haven’t yet come across a resource that confirms this is actually the case. I know it should theoretically be possible using the VP8 hardware decoders but I thought those were expensive to warm up just for images

3OCSzk 8mo ago

1 black pixel of .webp is smaller than 1 black pixel of .jpegxl that is also smaller than 1 black pixel of .png so webp > jpegxl > png