4 ms·

This is simply false, even if you mean using AVIF. Here's a test case, using a moderate sized (3000x2000) image. Nothing ridiculously huge or anything, and it'

This is simply false, even if you mean using AVIF. Here's a test case, using a moderate sized (3000x2000) image. Nothing ridiculously huge or anything, and it's not an especially complex image. I'm linking the best I can do for both JPEG (at 200 KB) and AVIF (at 100 KB). If you can create a passable versions of these images at 100 KB with either codec (or WEBP for that matter), please do show us how. Original image: https://0x0.st/o9x5.png https://0x0.st/o9x5.png JPEG (200 KB): https://0x0.st/o93i.jpg https://0x0.st/o93i.jpg AVIF (100 KB): https://0x0.st/o9xC.avif https://0x0.st/o9xC.avif Maybe JPEG XL will get us closer, but not all the way there, that's for sure: https://0x0.st/o9xd.jxl https://0x0.st/o9xd.jxl - JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage.

worldofmatthew 4y ago
I normally deal with 720P images for internet distribution. For 3000x2000 that would be around 230KB to 250KB.
- bscphil 4y ago
  You replied to a thread about a photography website. I don't think 720p images are the norm for that use case. In any event, I don't think the AVIF result at 250 KB is acceptable for photography either: https://0x0.st/o93a.avif https://0x0.st/o93a.avif - There's a ton of smearing and blurring that's very obvious when you're viewing the image at full size.
- IMTDb 4y ago
  3000x2000 basically means "fullscreen on a retina display @ full resolution". You can only reasonably show one picture like that at a time. So it's completely OK to have the currently displayed picture at that resolution/size. But all photo should be loaded at a much lower size, initially, and only downloaded at full size the the user puts them in full screen.
  - Wowfunhappy 4y ago
    I know lazy loading is in vogue, but as a user it only ever seems to create problems for me. I’d much rather the website download all the images ahead of time on page load, so I don’t have to wait for full quality versions each time I full screen a different image.
    - IMTDb 4y ago
      This is the restaurant equivalent of : "We are at an all you can eat buffet, let me take 10 plates even if I only realistically will eat 4, so that if I want any more I don't have to stand up again".
      - docmars 4y ago
        While the other way (loading each image as you view them, or lazy) is functionally equivalent to waiting in line for each separate dish, which isn't quite so fun. Maybe gallery sites could consider offering a preference to load all images upfront if you intend to view them all. A good example would be housing sites, where viewing higher quality photos of each listing is a primary use case.
cuu508 4y ago
Downsize the 3000x2000 to the dimensions it will be displayed at and you will be able to go below 100KB.
- bscphil 4y ago
  What if it will be displayed at 3000x2000? I mean that's the whole conversation here, we're talking about images that are the focus point of the page.
  - cuu508 4y ago
    Yes, then 100KB is usually not enough.
theandrewbailey 4y ago
> JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage. It's better than AVIF at low bitrates. I did a comparison of the latest builds 3 months ago, and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p). It's a bit subtle, but I could see it. Once browsers ship full support (at least Firefox + Chrome), I'll be on board.
- bscphil 4y ago
  > and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p) bpp = bits per pixel, not bytes. At 1080p, "0.05-0.1 bpp" is 13-26 KB. Much smaller than what you were testing. Might want to recheck your sizes, if you are actually looking at 0.5 bpp it would not surprise me at all that you found JPEG XL superior. At very small sizes like 0.1 bpp the results are debatable, but I think AVIF is a pretty clear winner if you aren't too bothered by blurring. Samples at 0.15 bpp: https://afontenot.github.io/image-formats-comparison/#air-force-academy-chapel&jxl=t&avif=t https://afontenot.github.io/image-formats-comparison/#air-fo... https://afontenot.github.io/image-formats-comparison/#citroen&jxl=t&avif=t https://afontenot.github.io/image-formats-comparison/#citroe... https://afontenot.github.io/image-formats-comparison/#festa-major-del-clot&jxl=t&avif=t https://afontenot.github.io/image-formats-comparison/#festa-...
  - Seirdy 4y ago
    In the experimental Document-Policy HTTP header, "bpp" does seem to signify bytes per pixel. Document-Policy explainer: https://github.com/wicg/document-policy/blob/main/document-policy-explainer.md https://github.com/wicg/document-policy/blob/main/document-p... I tried it out on my own site, and through trial-and-error I found that Chromium does in fact treat the "max-bpp" Document-Policy directives as bytes-per-pixel. I could be wrong; my memory has faded. Please correct me if this is the case.
    - bscphil 4y ago
      I'm not sure what HTTP headers have to do with anything. Using "bpp" to mean bits per pixel is extremely common in image encoding. See e.g. https://en.wikipedia.org/wiki/Color_depth https://en.wikipedia.org/wiki/Color_depth where an uncompressed image is often 24 bpp (8 bits per channel). It's also common to use bitrate (rather than byterate) in audio encoding, see e.g. https://wiki.hydrogenaud.io/index.php?title=Bitrate https://wiki.hydrogenaud.io/index.php?title=Bitrate

worldofmatthew 4y ago

I normally deal with 720P images for internet distribution. For 3000x2000 that would be around 230KB to 250KB.

bscphil 4y ago
You replied to a thread about a photography website. I don't think 720p images are the norm for that use case. In any event, I don't think the AVIF result at 250 KB is acceptable for photography either: https://0x0.st/o93a.avif https://0x0.st/o93a.avif - There's a ton of smearing and blurring that's very obvious when you're viewing the image at full size.
IMTDb 4y ago
3000x2000 basically means "fullscreen on a retina display @ full resolution". You can only reasonably show one picture like that at a time. So it's completely OK to have the currently displayed picture at that resolution/size. But all photo should be loaded at a much lower size, initially, and only downloaded at full size the the user puts them in full screen.
- Wowfunhappy 4y ago
  I know lazy loading is in vogue, but as a user it only ever seems to create problems for me. I’d much rather the website download all the images ahead of time on page load, so I don’t have to wait for full quality versions each time I full screen a different image.
  - IMTDb 4y ago
    This is the restaurant equivalent of : "We are at an all you can eat buffet, let me take 10 plates even if I only realistically will eat 4, so that if I want any more I don't have to stand up again".
    - docmars 4y ago
      While the other way (loading each image as you view them, or lazy) is functionally equivalent to waiting in line for each separate dish, which isn't quite so fun. Maybe gallery sites could consider offering a preference to load all images upfront if you intend to view them all. A good example would be housing sites, where viewing higher quality photos of each listing is a primary use case.

cuu508 4y ago

Downsize the 3000x2000 to the dimensions it will be displayed at and you will be able to go below 100KB.

bscphil 4y ago
What if it will be displayed at 3000x2000? I mean that's the whole conversation here, we're talking about images that are the focus point of the page.
- cuu508 4y ago
  Yes, then 100KB is usually not enough.

theandrewbailey 4y ago

> JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage. It's better than AVIF at low bitrates. I did a comparison of the latest builds 3 months ago, and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p). It's a bit subtle, but I could see it. Once browsers ship full support (at least Firefox + Chrome), I'll be on board.

bscphil 4y ago
> and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p) bpp = bits per pixel, not bytes. At 1080p, "0.05-0.1 bpp" is 13-26 KB. Much smaller than what you were testing. Might want to recheck your sizes, if you are actually looking at 0.5 bpp it would not surprise me at all that you found JPEG XL superior. At very small sizes like 0.1 bpp the results are debatable, but I think AVIF is a pretty clear winner if you aren't too bothered by blurring. Samples at 0.15 bpp: https://afontenot.github.io/image-formats-comparison/#air-force-academy-chapel&jxl=t&avif=t https://afontenot.github.io/image-formats-comparison/#air-fo... https://afontenot.github.io/image-formats-comparison/#citroen&jxl=t&avif=t https://afontenot.github.io/image-formats-comparison/#citroe... https://afontenot.github.io/image-formats-comparison/#festa-major-del-clot&jxl=t&avif=t https://afontenot.github.io/image-formats-comparison/#festa-...
- Seirdy 4y ago
  In the experimental Document-Policy HTTP header, "bpp" does seem to signify bytes per pixel. Document-Policy explainer: https://github.com/wicg/document-policy/blob/main/document-policy-explainer.md https://github.com/wicg/document-policy/blob/main/document-p... I tried it out on my own site, and through trial-and-error I found that Chromium does in fact treat the "max-bpp" Document-Policy directives as bytes-per-pixel. I could be wrong; my memory has faded. Please correct me if this is the case.
  - bscphil 4y ago
    I'm not sure what HTTP headers have to do with anything. Using "bpp" to mean bits per pixel is extremely common in image encoding. See e.g. https://en.wikipedia.org/wiki/Color_depth https://en.wikipedia.org/wiki/Color_depth where an uncompressed image is often 24 bpp (8 bits per channel). It's also common to use bitrate (rather than byterate) in audio encoding, see e.g. https://wiki.hydrogenaud.io/index.php?title=Bitrate https://wiki.hydrogenaud.io/index.php?title=Bitrate