11 ms·

JPEG-XL vs. AVIF and Others: 27 Images Compared

156 points by computerbuster 4y ago

Dwedit 4y ago
Note that AVIF is badly broken in Gimp. Save an image as AVIF, then load it again. Decompose the Luma and Chroma. You will see that the chroma is on a perfect 2x2 pixel grid, as if it was upscaled using nearest neighbor upscaling. This does not happen for JPEG.
brucethemoose2 4y ago
The Chromium dev who rejected JXL works on AOM code. The manager who commented on it also participated in some articles about the benefits of AV1. JPEG XL could be twice as efficient as AVIF everywhere, and every blog on the internet could benchmark it, and I suspect it still wouldn't make a difference.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- CharlesW 4y ago
  > JPEG XL could be twice as efficient as AVIF everywhere… This isn't true if you're talking about encoding size efficiency. See the "Quality" chart at https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html Even JPEG XL cheerleader Cloudinary says, "JPEG XL can obtain 10 to 15% better compression than AVIF" overall, which isn't a sufficient incremental benefit. https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
  - mdasen 4y ago
    I think they were trying to say that even if it were twice as efficient and everyone benchmarked it as twice as efficient, it still wouldn't make a difference because the Google devs are biased towards AVIF. It wasn't arguing that JXL is twice as efficient. It was just arguing that even if it were twice as efficient, it wouldn't matter.
  - tagrun 4y ago
    If you look at the plots in the 2nd link you are referring to, they show the gains of AVIF over WebP are also similar, so the case of AVIF "isn't a sufficient incremental benefit" as well by your criteria. Not to mention JPEG XL can do lossless and progressive on top, and that avifenc is much slower than cjxl.
- brigade 4y ago
  If it was actually 2x more efficient then that would be a very strong argument that I believe would prevail. But I'm kinda surprised so many people are so thirsty for a 10% improvement for natural images at qualities above what most websites serve. Which might even be reduced if AV1 encoder folks ever start caring about that quality range, given that it's way above what's relevant for video... Give it another couple years and maybe we'll have another format 5-10% better than JXL, at which point I hope everyone starts getting angry that format isn't included in browsers... (actually VVC intra should be at that performance level today, not that it has any chance of becoming the basis of a web image format...)
  - worrycue 4y ago
    > people are so thirsty for a 10% improvement for natural images at qualities above what most websites serve Because it won’t be just the web that uses JPEG. However whoever wins the support of the web will become THE universal image format for the foreseeable future. > Give it another couple years and maybe we'll have another format 5-10% better than JXL, at which point I hope everyone starts getting angry that format isn't included in browsers... That’s the thing. Once a format has become THE standard it won’t be replaced for a very long time. Might as well get the best bang for buck and pick the best standard that’s availability now.
  - brucethemoose2 4y ago
    Its not just about bitrate, as avif has some issues: - slow power hungry encoding - slow decoding (though this has gotten better very quickly) - terrible lossless performance - no lossless path from jpeg like jxl. - no support for "exotic" formats like > 12 bpc or many extra channels. Saying avif should be the only format is like saying everyone should depreciate png and just use jpeg. It doesn't cover all use cases, though frankly I am getting sick of slow pngs.
  - ksec 4y ago
    >actually VVC intra should be at that performance level today, Yes. Considering HEIC surpassingly did outperform AV1 and JPEG-XL in most of the benchmarks. You can expect VVC intra to be even better. >Give it another couple years and maybe we'll have another format 5-10% better than JXL Well yes. That is on the assumption everyone will settle on AVIF because that 10% is comparing to AV1. That wasn't true until Apple made the move. And AVIF, or AV1 the codec in general likes to remove details. So I would argue it isn't even a great image codec in the first place until it is fixed ( which the AOM has no intention of improving ). The good thing ( or bad thing ) about JPEG XL is that they have now port some of the improvement to existing JPEG via JPEGLI, which gives ~10-15% improvement depending on image type without breaking compatibilities. This improvement on JPEG alone means the next generation replacement codec needs to be much better for it to be meaningful.
tetrisgm 4y ago
Unclear why Google would straight up reject an open standard. Considering their browser market share, jt feels like they can just kill a standard.
- zamadatix 4y ago
  Mozilla's statement gives a good summary of takes form both ends and why they decided their position was neutral https://github.com/mozilla/standards-positions/issues/522#issuecomment-1409539985 https://github.com/mozilla/standards-positions/issues/522#is...
  - edflsafoiewq 4y ago
    Unfortunately this basically means JPEG-XL is dead.
    - recuter 4y ago
      X-JPEG-XL, bereft of pixels.
    - wongarsu 4y ago
      dead for the web. I still store various images in JPEG-XL, have support for it in my image-viewer of choice, can use it in Python's pillow (with a decoder plugin) and lots of other things I use to modify images. I still have to occasionally convert some images back to jpeg, but the savings from storing all of them in jpeg-xl instead is worth it to me (and avif support is spotty in the same areas, it is only really ahead in browsers and photoshop)
  - pmarreck 4y ago
    > Overall, we don't see JPEG-XL performing enough better than its closest competitors (like AVIF) to justify addition on that basis alone The progressive enhancement feature alone could be quite amazing, and its competitors don’t offer that- No more thumbnail generation! Its competitors can’t offer that! Do they realize how many security holes everyone’s use of “ImageTragick” generates, and how much caching infrastructure is devoted to images? also, how does he fail to see this as a potential competitive advantage over browser competitors?
Slix 4y ago
Is there a patent, copyright, or royalty reason why JPEG-XL isn't championed for the web? It would be awful to have another format that can't be used in certain Linux distros or browsers.
- jbverschoor 4y ago
  Nope. It’s the best thing out there atm. It’s just big tech wanting to control the IP
  - mort96 4y ago
    Or is it their desire to be slightly careful about which image formats they have to support in perpetuity? With AVIF you get to re-use a bunch of your AV1 decoding code too. And the reference JPEG-XL decoder is still on version 0.x, with no sign that they'll make a stable release any time soon. Why everyone is all up in arms about the fact that the industry is finally standardizing on a good royalty-free image format is beyond me.
    - Dylan16807 4y ago
      AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec. It especially has trouble with lossless. If we were picking a single royalty-free image codec for the 2018-2026 range, it should be JXL.
      - CharlesW 4y ago
        > AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec. Image encoding is a subset of video encoding, so any limits are mostly arbitrary, and in AV1's case image-only encoding was a consideration from the start. AVIF in particular supports color depths up to 12 bits, wide color gamuts, many color spaces and standards for color space signaling, etc., so I'm curious what aspect you consider limited.
deleted 4y ago
[deleted]
sroussey 4y ago
“And others” in the title does not include HEIC: “HEIC is being excluded because it sucks”.
- MBCook 4y ago
  That really annoyed me. The blog post tries to do a lot to appear scientific and objective, then just tosses something out without testing due to personal opinion. They also mention it’s not free. That would be ok. Just say your test is image quality of free image formats. But that statement just undermined the trust I had in the author up to that point.
  - ianlevesque 4y ago
    Given how widely deployed HEIC is I would be curious to know objectively how it fares even if there are practical reasons to not choose it.
  - computerbuster 4y ago
    You're probably right that I shouldn't have been so rash, I'm sorry for the omission & my despondent attitude toward HEIC. My enthusiasm is sullied by the presence of royalties & a non-existent web presence because of these royalties which I consider reasonable (where JXL's lack of web presence is questionable). In the future, I may do a similar test and include HEIC, but currently I believe it fares worse than AVIF almost across the board. I'd be willing to see whether or not I'm correct in saying this, though. I should include that under "Takeaway," I do say that " ... this is a non-scientific test," & it shouldn't be considered objective despite the use of metrics. While I find SSIMULACRA2 correlates very well with what my eyes see with these images & most other images, 27 landscape/architecture images aren't enough to draw any objective conclusions here & I'd need to do more testing in the future to produce research-quality work.
    - MBCook 4y ago
      If you said something like that and provided a link right there at explained why it was already known to be worse, that would’ve been understandable. I appreciate what you did. Your article is far above a simple “I looked at five pictures and decided this one was the best“ kind of comparison that you sometimes see. You clearly tried to do a good and fair job with your contenders. The results were interesting to see. This isn’t an area I spent time in so I really didn’t know what to expect going in other than thinking there must be something better than the venerable JPEG.
zagrebian 4y ago
> The Chromium team shouldn't have the absolute authority to shoot down would-be standards like this I’m not sure that “the Chromium team” is a real thing. Chromium is a cross-company project. People from different companies and different teams work on it together. Google has a Chrome team. edit: I’m not familiar with the Google JPEG-XL situation, but generally speaking, it should be possible to ship a feature in Chromium without Google’s involvement because there are three non-Google Blink API owners (last time I checked).
- fabrice_d 4y ago
  Even if you manage to land features in Chromium without approval from Google employees, that will not help much. If Google doesn't want the feature they will disable it in Chrome, which is what matters for adoption.
- computerbuster 4y ago
  As I mentioned in the article, Thorium is a Chromium-based browser that fully supports JPEG-XL. Here's the libjxl patch that can be ported to other Chromium-based browsers: https://github.com/Alex313031/thorium-libjxl https://github.com/Alex313031/thorium-libjxl
pixelesque 4y ago
I recently tried out HIEF and AVIF to try and save high resolution panorama images to, and discovered that AVIF currently doesn't support images > 8K, despite saving the resolution in 32-bit ints, which is a bit disappointing in 2023. (Limits inherited from the fact it's basically a video codec). Also annoying was the fact I actually had to debug libavif to work out what the problem was, as `avifEncoderAddImage()` would just return a generic error that wasn't helpful when the dimensions were too big, but `avifRGBImageAllocatePixels()` and `avifImageRGBToYUV()` didn't complain about the dimensions beforehand.
- wongarsu 4y ago
  >Limits inherited from the fact it's basically a video codec It's also disappointing for a video codec released in 2018. For context, in 2019 Sony released an 16k screen. Granted, that was a home cinema screen, and 16k displays will be a niche product for the forseeable future, but it's also not something unimaginably large.
  - adgjlsfhk1 4y ago
    I doubt this will ever make sense. An 8k screen that is full field of view is already big enough that the pixels aren't visible.
    - wongarsu 4y ago
      An 8k screen has about 33 million pixels. The first google result claims that the human eye contains about 91 million rods (and 4.5 million cones). So just from a sensor-pixel vs image-pixel standpoint, there are gains beyond 8k. From the top of my head, going up to about 32k is meaningful if you account for the fact that what you're really catering to is central vision: the 2-5° of visual field where most of your cones are packed together, giving you much higher resolution for the point you're looking at. And of course that's assuming that the viewer is static. If you assume that viewers can move to a point where the screen is bigger than their field of view (say a large display in a museum) or that the viewer can zoom the video (just as we routinely zoom images today) there are even fewer limits to reasonable resolutions.
redox99 4y ago
Mozilla and Google dropping JPEG-XL support because "too much complexity". Software engineers using "too much complexity" as an excuse for something they don't want to do is such a classic move. Browsers are already absurdly complex, and are constantly receiving HTML, CSS and JS features that significantly increase complexity. Are we really to believe that adding support for a certain image format, which is basically as modular as it gets (decode the file into a buffer), is too much complexity? Obviously, this is a case of them showing favoritism toward codecs based on the IP owners of those codecs.
- deleted 4y ago
  [deleted]
- pedrovhb 4y ago
  Not to mention the complexity is mostly offloaded to the maintainers of the library itself, not the browser that calls it. I wish Mozilla had gone ahead and enabled it by default in Firefox, as I'd hoped it would. Still salty it didn't happen (yet, at least). It seems like such a clear choice to developers that there's actually people being vocal about it (as evidenced by the sparse but constant stream of e.g. posts on HN about browser image codecs, which is a topic _no one_ finds sexy otherwise), but browser vendors still won't budge. It's weird to see them say "sure it's better, but it's not better enough than the alternatives". There's a large enough discrepancy in my own perception of the merits of jxl and that of the people making choices for browsers that I genuinely wish I understood them, because it feels like I'm missing something. I still convert my pictures to jxl locally and, and the space savings are enough of a reason to go through the trouble of converting - it just seems like a no-brainer that it'd be even more valuable on the web, as bandwidth savings are generally even more important than disk storage, and then there's still the plethora of other features on top of that.
  - izacus 4y ago
    The browser developers defacto become the library maintainers since they're now on the hook for any security issue within that library forever. Even if the "real" maintainers go play with something else.
peppermint_gum 4y ago
Some will blame Google for the demise of JPEG XL, but I think that's a red herring. JPEG XL includes Google technologies such as Pik and Guetzli/Brunsli. Some of the JXL developers are Google employees. Google doesn't have a profit motive to promote one format over another. Their upper management most likely isn't even aware that JPEG XL exists. It also doesn't explain why Mozilla and Apple are favoring AVIF too. Nonetheless, there's no question that JPEG XL was sabotaged. AVIF was enabled by default in Chrome the day it was implemented, JXL had to go through an experimental period. At some point, Mozilla developers were told to stop working on improving their JXL implementation and they couldn't even merge already developed patches.[1] Google's justifications for the removal were baffling. They said there's "not enough interest" despite all the hype, all the major companies requesting JXL support.[2] They claimed JXL doesn't bring "sufficient benefits", despite the numerous advantages, such as lossless JPEG recompression. They published their flawed[3] benchmarks weeks after they made the decision to remove JPEG XL. BTW, the removal happened immediately after Adobe announced they are supporting JPEG XL in one of their products. Almost as if they realized that JXL may be gaining too much support and it's time to pull the plug. So who's behind this if not Google? To me, the most likely suspect is AOM, the Alliance for Open Media. The people who are involved in AOM also the ones who make the decisions in the browsers. What are their motives? I don't know, pettiness? Maybe they just want their format to win. [1] - https://phabricator.services.mozilla.com/D119700#3977128 https://phabricator.services.mozilla.com/D119700#3977128 [2] - https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... [3] - https://cloudinary.com/blog/contemplating-codec-comparisons https://cloudinary.com/blog/contemplating-codec-comparisons
- tpolzer 4y ago
  Some people try to spin this as a Google vs open standards, while it's mostly a Google devs vs. some other Google devs situation: If you look at https://github.com/libjxl/libjxl/graphs/contributors https://github.com/libjxl/libjxl/graphs/contributors, ~everybody except Jon Sneyers is a Google employee (I think the AVIF ratio is similar, but I didn't check). So the question isn't about which format is better, but who won internal politics and it's clearly the AVIF folks - for reasons which aren't really possible to tell from the outside.
PaulHoule 4y ago
I did a small amount of eval work and was not impressed with AVIF when it came to compressing photos I took with my DSLR that I wanted to present as a "photo I took with my DSLR" that is the core of the content. That's a different scenario that a splash image for a landing page, but I was really quite disappointed.
timbit42 4y ago
If image types were implemented the way they are on the Amiga OS, we wouldn't be having this conversation about whether jpeg-xl will be supported in a web browser. When you add a jpeg-xl.library, every app on the system instantly supports loading and saving that image format.
- Asooka 4y ago
  Windows already has a codec system. Chrome just doesn't use it. No matter how perfect a system service you have, if the premier web browser doesn't use it, it doesn't matter.
  - pornel 4y ago
    This is on purpose, because otherwise it would lead to proliferation of redundant, potentially crappy and insecure formats on the Web. You could end up with sites using some Windows-only formats (e.g. some internal MS Office format), iPhone-centric sites would serve patented HEIC, and then browsers on other platforms would be forced to adopt these formats. Not every plugin dumped in the local OS is as hardened as web-facing codecs. People would likely get pwned through some legacy fax codec from their scanner software. Users seeing broken images is not a good UX, and users installing random code-running plugins, because websites tell them to, is even more annoying and dangerous. We've got decades of experience, and scars in the User-Agent header, showing that developers can't be trusted to make sensible technical choices.
    - snvzz 4y ago
      >This is on purpose, because otherwise it would lead to proliferation of redundant, potentially crappy and insecure formats on the Web. In a well-designed datatype system, an image datatype would, for decoding take a compressed image and return a decompressed image. Possibly with streaming support. It would not be able to do anything else, not having capabilities to anything else than necessary.
  - Avamander 4y ago
    Windows's system is terrible though. It's buggy, it requires to use of MS Store, the user experience is terrible. The HEVC extension for example causes incorrect HDR playback on certain AMD cards for years now, with no fix in sight. It's surprising that you've forgotten the shit web was with all the "You must install Adobe Flash Player to view this content" banners or shudder, Java and ActiveX applets.
computerbuster 4y ago
I think the most interesting takeaway here is that while JXL continues to face unfair treatment from web browser vendors, jpegli is a really fascinating development that performs very closely to AVIF at high quality in the dataset. I'd like to test jpegli with the XYB colorspace in the future to see how much better it is compared to RGB, but even with the RGB handicap it still looks very promising.
shmerl 4y ago
Does gimp have some issue with avif? I tried setting the print size and after re-opening, it wasn't kept.
ksec 4y ago
Worth Pointing out again. According to Chrome Stats from Google ~80 to 85% of images served are above BPP 1.0 ( Bit per Pixel ). [1] Figure 1 >The number of transferred bytes is important because it affects the latency and hence the user experience. Using this estimate, we calculated that between June 1st and 28th, 2019, the average BPP (weighted by the number of bytes transmitted with that BPP) was 2.97, 2.24 and 2.03 for small, medium and large images, respectively. We confirmed that there was no considerable difference between mobile and desktop platforms. This data indicates that image compression algorithms should target rich images with a relatively high BPP values, aiming to produce 1 BPP images almost free of artefacts instead of 0.5 BPP images with artefacts that are not too intrusive. It has been quite well know by now, at least to those who are familiar with JPEG XL that is doesn't do as well in Non-photographic photos. But it is still much better than WebP or JPEG. I dont know if we could potentially further improve Non-photographic photos, but if you are look at the chart JPEG-XL has a perfect score at below BPP 1.0 already. Compared to AV1 encoder having many years of head start. [1] https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1 https://www.spiedigitallibrary.org/conference-proceedings-of...

Note that AVIF is badly broken in Gimp. Save an image as AVIF, then load it again. Decompose the Luma and Chroma. You will see that the chroma is on a perfect 2x2 pixel grid, as if it was upscaled using nearest neighbor upscaling. This does not happen for JPEG.

brucethemoose2 4y ago

The Chromium dev who rejected JXL works on AOM code. The manager who commented on it also participated in some articles about the benefits of AV1. JPEG XL could be twice as efficient as AVIF everywhere, and every blog on the internet could benchmark it, and I suspect it still wouldn't make a difference.

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
CharlesW 4y ago
> JPEG XL could be twice as efficient as AVIF everywhere… This isn't true if you're talking about encoding size efficiency. See the "Quality" chart at https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html Even JPEG XL cheerleader Cloudinary says, "JPEG XL can obtain 10 to 15% better compression than AVIF" overall, which isn't a sufficient incremental benefit. https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
- mdasen 4y ago
  I think they were trying to say that even if it were twice as efficient and everyone benchmarked it as twice as efficient, it still wouldn't make a difference because the Google devs are biased towards AVIF. It wasn't arguing that JXL is twice as efficient. It was just arguing that even if it were twice as efficient, it wouldn't matter.
- tagrun 4y ago
  If you look at the plots in the 2nd link you are referring to, they show the gains of AVIF over WebP are also similar, so the case of AVIF "isn't a sufficient incremental benefit" as well by your criteria. Not to mention JPEG XL can do lossless and progressive on top, and that avifenc is much slower than cjxl.
brigade 4y ago
If it was actually 2x more efficient then that would be a very strong argument that I believe would prevail. But I'm kinda surprised so many people are so thirsty for a 10% improvement for natural images at qualities above what most websites serve. Which might even be reduced if AV1 encoder folks ever start caring about that quality range, given that it's way above what's relevant for video... Give it another couple years and maybe we'll have another format 5-10% better than JXL, at which point I hope everyone starts getting angry that format isn't included in browsers... (actually VVC intra should be at that performance level today, not that it has any chance of becoming the basis of a web image format...)
- worrycue 4y ago
  > people are so thirsty for a 10% improvement for natural images at qualities above what most websites serve Because it won’t be just the web that uses JPEG. However whoever wins the support of the web will become THE universal image format for the foreseeable future. > Give it another couple years and maybe we'll have another format 5-10% better than JXL, at which point I hope everyone starts getting angry that format isn't included in browsers... That’s the thing. Once a format has become THE standard it won’t be replaced for a very long time. Might as well get the best bang for buck and pick the best standard that’s availability now.
- brucethemoose2 4y ago
  Its not just about bitrate, as avif has some issues: - slow power hungry encoding - slow decoding (though this has gotten better very quickly) - terrible lossless performance - no lossless path from jpeg like jxl. - no support for "exotic" formats like > 12 bpc or many extra channels. Saying avif should be the only format is like saying everyone should depreciate png and just use jpeg. It doesn't cover all use cases, though frankly I am getting sick of slow pngs.
- ksec 4y ago
  >actually VVC intra should be at that performance level today, Yes. Considering HEIC surpassingly did outperform AV1 and JPEG-XL in most of the benchmarks. You can expect VVC intra to be even better. >Give it another couple years and maybe we'll have another format 5-10% better than JXL Well yes. That is on the assumption everyone will settle on AVIF because that 10% is comparing to AV1. That wasn't true until Apple made the move. And AVIF, or AV1 the codec in general likes to remove details. So I would argue it isn't even a great image codec in the first place until it is fixed ( which the AOM has no intention of improving ). The good thing ( or bad thing ) about JPEG XL is that they have now port some of the improvement to existing JPEG via JPEGLI, which gives ~10-15% improvement depending on image type without breaking compatibilities. This improvement on JPEG alone means the next generation replacement codec needs to be much better for it to be meaningful.

tetrisgm 4y ago

Unclear why Google would straight up reject an open standard. Considering their browser market share, jt feels like they can just kill a standard.

zamadatix 4y ago
Mozilla's statement gives a good summary of takes form both ends and why they decided their position was neutral https://github.com/mozilla/standards-positions/issues/522#issuecomment-1409539985 https://github.com/mozilla/standards-positions/issues/522#is...
- edflsafoiewq 4y ago
  Unfortunately this basically means JPEG-XL is dead.
  - recuter 4y ago
    X-JPEG-XL, bereft of pixels.
  - wongarsu 4y ago
    dead for the web. I still store various images in JPEG-XL, have support for it in my image-viewer of choice, can use it in Python's pillow (with a decoder plugin) and lots of other things I use to modify images. I still have to occasionally convert some images back to jpeg, but the savings from storing all of them in jpeg-xl instead is worth it to me (and avif support is spotty in the same areas, it is only really ahead in browsers and photoshop)
- pmarreck 4y ago
  > Overall, we don't see JPEG-XL performing enough better than its closest competitors (like AVIF) to justify addition on that basis alone The progressive enhancement feature alone could be quite amazing, and its competitors don’t offer that- No more thumbnail generation! Its competitors can’t offer that! Do they realize how many security holes everyone’s use of “ImageTragick” generates, and how much caching infrastructure is devoted to images? also, how does he fail to see this as a potential competitive advantage over browser competitors?

Slix 4y ago

Is there a patent, copyright, or royalty reason why JPEG-XL isn't championed for the web? It would be awful to have another format that can't be used in certain Linux distros or browsers.

jbverschoor 4y ago
Nope. It’s the best thing out there atm. It’s just big tech wanting to control the IP
- mort96 4y ago
  Or is it their desire to be slightly careful about which image formats they have to support in perpetuity? With AVIF you get to re-use a bunch of your AV1 decoding code too. And the reference JPEG-XL decoder is still on version 0.x, with no sign that they'll make a stable release any time soon. Why everyone is all up in arms about the fact that the industry is finally standardizing on a good royalty-free image format is beyond me.
  - Dylan16807 4y ago
    AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec. It especially has trouble with lossless. If we were picking a single royalty-free image codec for the 2018-2026 range, it should be JXL.
    - CharlesW 4y ago
      > AVIF doesn't do everything, and a codec that's designed to encode video frames will always be limited compared to a pure image codec. Image encoding is a subset of video encoding, so any limits are mostly arbitrary, and in AV1's case image-only encoding was a consideration from the start. AVIF in particular supports color depths up to 12 bits, wide color gamuts, many color spaces and standards for color space signaling, etc., so I'm curious what aspect you consider limited.

deleted 4y ago

[deleted]

sroussey 4y ago

“And others” in the title does not include HEIC: “HEIC is being excluded because it sucks”.

MBCook 4y ago
That really annoyed me. The blog post tries to do a lot to appear scientific and objective, then just tosses something out without testing due to personal opinion. They also mention it’s not free. That would be ok. Just say your test is image quality of free image formats. But that statement just undermined the trust I had in the author up to that point.
- ianlevesque 4y ago
  Given how widely deployed HEIC is I would be curious to know objectively how it fares even if there are practical reasons to not choose it.
- computerbuster 4y ago
  You're probably right that I shouldn't have been so rash, I'm sorry for the omission & my despondent attitude toward HEIC. My enthusiasm is sullied by the presence of royalties & a non-existent web presence because of these royalties which I consider reasonable (where JXL's lack of web presence is questionable). In the future, I may do a similar test and include HEIC, but currently I believe it fares worse than AVIF almost across the board. I'd be willing to see whether or not I'm correct in saying this, though. I should include that under "Takeaway," I do say that " ... this is a non-scientific test," & it shouldn't be considered objective despite the use of metrics. While I find SSIMULACRA2 correlates very well with what my eyes see with these images & most other images, 27 landscape/architecture images aren't enough to draw any objective conclusions here & I'd need to do more testing in the future to produce research-quality work.
  - MBCook 4y ago
    If you said something like that and provided a link right there at explained why it was already known to be worse, that would’ve been understandable. I appreciate what you did. Your article is far above a simple “I looked at five pictures and decided this one was the best“ kind of comparison that you sometimes see. You clearly tried to do a good and fair job with your contenders. The results were interesting to see. This isn’t an area I spent time in so I really didn’t know what to expect going in other than thinking there must be something better than the venerable JPEG.

zagrebian 4y ago

> The Chromium team shouldn't have the absolute authority to shoot down would-be standards like this I’m not sure that “the Chromium team” is a real thing. Chromium is a cross-company project. People from different companies and different teams work on it together. Google has a Chrome team. edit: I’m not familiar with the Google JPEG-XL situation, but generally speaking, it should be possible to ship a feature in Chromium without Google’s involvement because there are three non-Google Blink API owners (last time I checked).

fabrice_d 4y ago
Even if you manage to land features in Chromium without approval from Google employees, that will not help much. If Google doesn't want the feature they will disable it in Chrome, which is what matters for adoption.
computerbuster 4y ago
As I mentioned in the article, Thorium is a Chromium-based browser that fully supports JPEG-XL. Here's the libjxl patch that can be ported to other Chromium-based browsers: https://github.com/Alex313031/thorium-libjxl https://github.com/Alex313031/thorium-libjxl

pixelesque 4y ago

I recently tried out HIEF and AVIF to try and save high resolution panorama images to, and discovered that AVIF currently doesn't support images > 8K, despite saving the resolution in 32-bit ints, which is a bit disappointing in 2023. (Limits inherited from the fact it's basically a video codec). Also annoying was the fact I actually had to debug libavif to work out what the problem was, as `avifEncoderAddImage()` would just return a generic error that wasn't helpful when the dimensions were too big, but `avifRGBImageAllocatePixels()` and `avifImageRGBToYUV()` didn't complain about the dimensions beforehand.

wongarsu 4y ago
>Limits inherited from the fact it's basically a video codec It's also disappointing for a video codec released in 2018. For context, in 2019 Sony released an 16k screen. Granted, that was a home cinema screen, and 16k displays will be a niche product for the forseeable future, but it's also not something unimaginably large.
- adgjlsfhk1 4y ago
  I doubt this will ever make sense. An 8k screen that is full field of view is already big enough that the pixels aren't visible.
  - wongarsu 4y ago
    An 8k screen has about 33 million pixels. The first google result claims that the human eye contains about 91 million rods (and 4.5 million cones). So just from a sensor-pixel vs image-pixel standpoint, there are gains beyond 8k. From the top of my head, going up to about 32k is meaningful if you account for the fact that what you're really catering to is central vision: the 2-5° of visual field where most of your cones are packed together, giving you much higher resolution for the point you're looking at. And of course that's assuming that the viewer is static. If you assume that viewers can move to a point where the screen is bigger than their field of view (say a large display in a museum) or that the viewer can zoom the video (just as we routinely zoom images today) there are even fewer limits to reasonable resolutions.

redox99 4y ago

Mozilla and Google dropping JPEG-XL support because "too much complexity". Software engineers using "too much complexity" as an excuse for something they don't want to do is such a classic move. Browsers are already absurdly complex, and are constantly receiving HTML, CSS and JS features that significantly increase complexity. Are we really to believe that adding support for a certain image format, which is basically as modular as it gets (decode the file into a buffer), is too much complexity? Obviously, this is a case of them showing favoritism toward codecs based on the IP owners of those codecs.

deleted 4y ago
[deleted]
pedrovhb 4y ago
Not to mention the complexity is mostly offloaded to the maintainers of the library itself, not the browser that calls it. I wish Mozilla had gone ahead and enabled it by default in Firefox, as I'd hoped it would. Still salty it didn't happen (yet, at least). It seems like such a clear choice to developers that there's actually people being vocal about it (as evidenced by the sparse but constant stream of e.g. posts on HN about browser image codecs, which is a topic _no one_ finds sexy otherwise), but browser vendors still won't budge. It's weird to see them say "sure it's better, but it's not better enough than the alternatives". There's a large enough discrepancy in my own perception of the merits of jxl and that of the people making choices for browsers that I genuinely wish I understood them, because it feels like I'm missing something. I still convert my pictures to jxl locally and, and the space savings are enough of a reason to go through the trouble of converting - it just seems like a no-brainer that it'd be even more valuable on the web, as bandwidth savings are generally even more important than disk storage, and then there's still the plethora of other features on top of that.
- izacus 4y ago
  The browser developers defacto become the library maintainers since they're now on the hook for any security issue within that library forever. Even if the "real" maintainers go play with something else.

peppermint_gum 4y ago

Some will blame Google for the demise of JPEG XL, but I think that's a red herring. JPEG XL includes Google technologies such as Pik and Guetzli/Brunsli. Some of the JXL developers are Google employees. Google doesn't have a profit motive to promote one format over another. Their upper management most likely isn't even aware that JPEG XL exists. It also doesn't explain why Mozilla and Apple are favoring AVIF too. Nonetheless, there's no question that JPEG XL was sabotaged. AVIF was enabled by default in Chrome the day it was implemented, JXL had to go through an experimental period. At some point, Mozilla developers were told to stop working on improving their JXL implementation and they couldn't even merge already developed patches.[1] Google's justifications for the removal were baffling. They said there's "not enough interest" despite all the hype, all the major companies requesting JXL support.[2] They claimed JXL doesn't bring "sufficient benefits", despite the numerous advantages, such as lossless JPEG recompression. They published their flawed[3] benchmarks weeks after they made the decision to remove JPEG XL. BTW, the removal happened immediately after Adobe announced they are supporting JPEG XL in one of their products. Almost as if they realized that JXL may be gaining too much support and it's time to pull the plug. So who's behind this if not Google? To me, the most likely suspect is AOM, the Alliance for Open Media. The people who are involved in AOM also the ones who make the decisions in the browsers. What are their motives? I don't know, pettiness? Maybe they just want their format to win. [1] - https://phabricator.services.mozilla.com/D119700#3977128 https://phabricator.services.mozilla.com/D119700#3977128 [2] - https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... [3] - https://cloudinary.com/blog/contemplating-codec-comparisons https://cloudinary.com/blog/contemplating-codec-comparisons

tpolzer 4y ago
Some people try to spin this as a Google vs open standards, while it's mostly a Google devs vs. some other Google devs situation: If you look at https://github.com/libjxl/libjxl/graphs/contributors https://github.com/libjxl/libjxl/graphs/contributors, ~everybody except Jon Sneyers is a Google employee (I think the AVIF ratio is similar, but I didn't check). So the question isn't about which format is better, but who won internal politics and it's clearly the AVIF folks - for reasons which aren't really possible to tell from the outside.

PaulHoule 4y ago

I did a small amount of eval work and was not impressed with AVIF when it came to compressing photos I took with my DSLR that I wanted to present as a "photo I took with my DSLR" that is the core of the content. That's a different scenario that a splash image for a landing page, but I was really quite disappointed.

timbit42 4y ago

If image types were implemented the way they are on the Amiga OS, we wouldn't be having this conversation about whether jpeg-xl will be supported in a web browser. When you add a jpeg-xl.library, every app on the system instantly supports loading and saving that image format.

Asooka 4y ago
Windows already has a codec system. Chrome just doesn't use it. No matter how perfect a system service you have, if the premier web browser doesn't use it, it doesn't matter.
- pornel 4y ago
  This is on purpose, because otherwise it would lead to proliferation of redundant, potentially crappy and insecure formats on the Web. You could end up with sites using some Windows-only formats (e.g. some internal MS Office format), iPhone-centric sites would serve patented HEIC, and then browsers on other platforms would be forced to adopt these formats. Not every plugin dumped in the local OS is as hardened as web-facing codecs. People would likely get pwned through some legacy fax codec from their scanner software. Users seeing broken images is not a good UX, and users installing random code-running plugins, because websites tell them to, is even more annoying and dangerous. We've got decades of experience, and scars in the User-Agent header, showing that developers can't be trusted to make sensible technical choices.
  - snvzz 4y ago
    >This is on purpose, because otherwise it would lead to proliferation of redundant, potentially crappy and insecure formats on the Web. In a well-designed datatype system, an image datatype would, for decoding take a compressed image and return a decompressed image. Possibly with streaming support. It would not be able to do anything else, not having capabilities to anything else than necessary.
- Avamander 4y ago
  Windows's system is terrible though. It's buggy, it requires to use of MS Store, the user experience is terrible. The HEVC extension for example causes incorrect HDR playback on certain AMD cards for years now, with no fix in sight. It's surprising that you've forgotten the shit web was with all the "You must install Adobe Flash Player to view this content" banners or shudder, Java and ActiveX applets.

computerbuster 4y ago

I think the most interesting takeaway here is that while JXL continues to face unfair treatment from web browser vendors, jpegli is a really fascinating development that performs very closely to AVIF at high quality in the dataset. I'd like to test jpegli with the XYB colorspace in the future to see how much better it is compared to RGB, but even with the RGB handicap it still looks very promising.

shmerl 4y ago

Does gimp have some issue with avif? I tried setting the print size and after re-opening, it wasn't kept.

ksec 4y ago

Worth Pointing out again. According to Chrome Stats from Google ~80 to 85% of images served are above BPP 1.0 ( Bit per Pixel ). [1] Figure 1 >The number of transferred bytes is important because it affects the latency and hence the user experience. Using this estimate, we calculated that between June 1st and 28th, 2019, the average BPP (weighted by the number of bytes transmitted with that BPP) was 2.97, 2.24 and 2.03 for small, medium and large images, respectively. We confirmed that there was no considerable difference between mobile and desktop platforms. This data indicates that image compression algorithms should target rich images with a relatively high BPP values, aiming to produce 1 BPP images almost free of artefacts instead of 0.5 BPP images with artefacts that are not too intrusive. It has been quite well know by now, at least to those who are familiar with JPEG XL that is doesn't do as well in Non-photographic photos. But it is still much better than WebP or JPEG. I dont know if we could potentially further improve Non-photographic photos, but if you are look at the chart JPEG-XL has a perfect score at below BPP 1.0 already. Compared to AV1 encoder having many years of head start. [1] https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1 https://www.spiedigitallibrary.org/conference-proceedings-of...