5 ms·
So a few dozen comments, but so far it doesn't look like any mention the immediate thing that jumped out at me which was the claims vs AVIF: >"In turn, what us
by xoa 4y ago
So a few dozen comments, but so far it doesn't look like any mention the immediate thing that jumped out at me which was the claims vs AVIF:
>"In turn, what users will be given is yet another facet of the web that Google itself controls: the AVIF format."
Huh? I'll admit I haven't been following codecs as super ultra closely as I used to, but I thought AOM was a pretty broad coalition of varying interests and AV1 an open, royalty free codec that was plenty open source friendly? I've heard plenty of reasonable arguments that JPEG XL has some real technical advantages over AVIF and as well as superior performance is much more feature rich and scalable. So I could see people being bummed for that. But this is the first time I've heard the assertion that it's somehow a Google project? I mean, AOM's libavif reference is BSD too [0]? I'd love some more details on that from anyone who has been following this more closely. I can even understand if AOM isn't as community friendly and an accusation that it's dominated by big corps, but in that case why single out Google alone? From wiki:
>The governing members of the Alliance for Open Media are Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent.
Like, Google is certainly significant, but that's a lot of equally heavy hitters. And interesting that Mozilla is there too.
----
0: https://github.com/AOMediaCodec/libavif https://github.com/AOMediaCodec/libavif
- pessimizer 4y ago> Like, Google is certainly significant, but that's a lot of equally heavy hitters. And interesting that Mozilla is there too. Mozilla is a dependent of Google's. The thing that stands out about that list is that aside from Google and Facebook (who completely control their markets), the New Microsoft and the aforementioned Mozilla, most of these companies are notoriously openly hostile to anything open.
- jerryX 4y agoIn practice AVIF is made practically only by Google team. Good summary from https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1383056-fsf-slams-google-over-dropping-jpeg-xl-in-chrome https://www.phoronix.com/forums/forum/phoronix/latest-phoron... : Max image size is limited to 4K (3840x2160) in AVIF, which is a deal breaker to me. You can tile images, but seams are visible at the edges, which makes this unusable. JPEG XL supports image sizes of up to 1,073,741,823x1,073,741,824. You won’t run out of image space anytime soon. JXL offers lossless recompression of JPEG images. This is important for compatibility, as you can re-encode JPEG images into JXL for a 30% reduction in file size for free. AVIF has no such feature. JXL has a maximum of 32 bits per channel. AVIF supports up to 10. JXL is more resilient to generation loss.5 JXL supports progressive decoding, which is essential in web delivery, IMO. AVIF has no such feature. AVIF is notoriously based on the AV1 video encoder. That makes it far superior for animated image sequences, outperforming JXL in this department by a wide margin. However, JXL also supports this feature. AVIF is supported in most major browsers. This includes Chrome (and derivatives) and Firefox (and forks). JXL is supported by almost nobody right now. Only Thorium, Pale Moon, LibreWolf, Waterfox, Basilisk and Firefox Nightly incorporate it. Most of these are community-maintained forks of Firefox. That is a big downside for adoption, as I already ranted about in this post. Both formats support transparency and wide gamut (HDR).
- Wowfunhappy 4y ago> Max image size is limited to 4K (3840x2160) in AVIF What?! That is terrible for a next-generation image format, and should be an immediate and obvious dealbreaker for introducing any type of support. It would be one thing if AVIF was a legacy format already in widespread, but anything new should be several orders of magnitude more future-proof.
- izacus 4y agoMaximum image size for AVIF is 65535x65535, no idea where you're all picking up this crock.
- formerly_proven 4y agoSeems to be not so simple. > AVIF has different limitations when it comes to the highest megapixel count / largest dimensions. Several decoders may not support larger images, so single-coded photos do not exceed 4k resolution. According to AV1, AVIF Baseline profile coded image items must not have more pixels than 8912896 or wider widths or higher heights than 8192 or 4352. The Baseline profile can still be used to create larger images using grid derivation. You might encounter discontinuities along the grid boundaries, depending on how the image is decomposed. For this particular case, however, the maximum size of a coded picture is 65536x65536. https://avif.io/blog/faq/avif-megapixel/ https://avif.io/blog/faq/avif-megapixel/ So as I understand this, anything with more than ~9 MP would be encoded in some kind of tiled way, possibly introducing artifacts where tiles meet. However, another blog post claims different limits > The default limit of AVIF is 8K. Video professionals will recognize this as the size of an 8K video frame. It is possible to break this limit for both formats by independently encoded tiles of 8K frames. But this method introduces artifacts at the tile boundaries, affecting the overall appearance of images. https://avif.io/blog/comparisons/avif-vs-heif/ https://avif.io/blog/comparisons/avif-vs-heif/
- brigade 4y agoThe profiles only matter if you want to be decodable by hardware decoders. If you only care about software decoders, which must be true if JPEG-XL is your comparison, then you don't have to use the HEIF grid for large dimensions, and the better question is how much memory your application will allow to be allocated. Because chances are JPEG's maximum 65535x65535 exceeds it that too. AV1 itself allows a maximum of 65536x65536 for a single picture, whereas the HEIF grid hypothetically allows even more than that regardless of how large each individual picture is (HEIF grid dimensions are 32-bits). As a practical example, libavif will not use the grid for large dimensions unless explicitly told to do so, by default producing files that aren't compliant to either baseline or advanced profiles. (to further my pedantry against your source: AVIF is a subset of HEIF; what people usually mean by "HEIF" is the HEIC subset)
- deleted 4y ago[deleted]
- jcranmer 4y ago>> The governing members of the Alliance for Open Media are Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent. > Like, Google is certainly significant, but that's a lot of equally heavy hitters. And interesting that Mozilla is there too. The Alliance for Open Media basically arose from the fact that MPEG decided to use the success of H.264 to charge a king's ransom in licensing fees for H.265, whereupon most of the consumer industry took one look at those fees and said "we need a free alternative."
- kmeisthax 4y agoTo be fair to MPEG, they don't actually run the patent pools, they just make everyone promise to join one. MPEG-LA is the patent pool that everyone was using and it was assumed that would be the case for H.265. HEVC Advance and Velos Media realized they could break this business structure by giving a few net-implementer companies (e.g. Samsung) a sweetheart deal on patent licensing if they moved their patents over to their pool. They paid for this by double-charging people who were already licensed through MPEG-LA for those patents. Leonardo Chiariglione, co-founder of MPEG, tried to get ISO to change their patent policy to allow more scrutiny of patent ownership in standards. ISO responded by... denying Leonardo's petitions, cutting MPEG up into pieces, and pushing him out of the working group he built. Funny thing is, MPEG actually knows royalty-free video encoding is a thing people want. They've tried building an ISO standard for that. Problem is, ISO's patent policy only allows removing patented technology from a standard if the technology is not licensable - not if the technology is too expensive. So their standardized royalty-free codecs[0] are not actually royalty-free and nobody uses them. The underlying problem was pointed out by Leonardo on his blog: patent owners want to go back to the days of charging an arm and a leg for MPEG-2, and they are willing to suck the brains out of MPEG in order to do it, under the assumption that people were paying royalty fees for the ISO branding rather than for the technical superiority of the standard. MPEG is not the cause of this problem, they are a victim of it. [0] Fun fact: Google outright just submitted VP8 to MPEG as a candidate for MPEG IVC, but they decided against using it in favor of building their own royalty-free standard.