av1-avif

as discussion around this and clarifying that the profiles decided on in 2018/2019 were more about giving targets for hardware acceleration of the time, but software decoders by 2021 supported essentially the whole spec (and it appears to me that another 2 years later now final lingering stuff has been dealt with) [1,2]: >Cyril has proposed a pull request (#130) to better clarify what is and is not supported in AVIF. In short, AVIF supports everything that AV1 supports, which includes 12-bit encoding. The current software decoder implementations also support more or less all of AV1, which can be seen if you try to decode a 12-bit AVIF file in a web browser. And for still images, hardware acceleration isn't important, so as a practical matter unlike AV1 video pure software for max features is fine. So 65k x 65k and 36-bit color appear to be the limit, which definitely isn't as much as JPEG XL, but is pretty respectable for majority of end user usage? Edit to add: the comments there also mention complaints that the JPEG XL author has a history of spreading misinformation about AVIF, "See the article and infographic recently posted by the JPEG-XL author that claims (among other things) that AVIF does not support 12-bit images". So apparently there has been some good old dev drama going on during the last few years which means one may need to be a little suspicious about any "Good summaries" :(. ---- 0: https://aomediacodec.github.io/av1-avif/#profiles-overview 1: https://github.com/AOMediaCodec/av1-avif/issues/128 2: https://github.com/AOMediaCodec/av1-avif/pull/130

m" and "one or more entities" that together "form a group", and "indicating, in the file, a grouping type for the group". The patent appears to be written in a way to allow this definition to encompass, say, a thumbnail and a bunch of frames thereafter, or, say a master image and a set of pictures derived from it, or alternate camera angles of the same thing. Some of these techniques sound like stuff we've seen before, but as is common in patents, the precise wording of claims is often key, and this is where patent lawyers come in. A thorough look of the AVIF specification [3] and the patents registered with the MPEG LA about this format [1] is likely wise before any widespread deployment that makes use of advanced features of the HEIF container; using it to hold exactly 1 'one-layer' still-image is probably fine. Additionally, in my reading [5], the HEIF reference software released by Nokia [4] includes a patent grant for non-commercial evaluation, testing and academic research only. [1] https://news.ycombinator.com/item?id=19874321 [2] https://patents.google.com/patent/US20160232939A1/ [3] https://aomediacodec.github.io/av1-avif/ [4] https://github.com/nokiatech/heif/blob/master/LICENSE.TXT [5] https://news.ycombinator.com/item?id=19874368 [6] https://en.wikipedia.org/w/index.php?title=AV1&oldid=9976507... [7] https://github.com/AOMediaCodec/av1-avif/issues/2

acking and went through IP review that may help it avoid being mired in a patent mess like previous proposals to replace JPEG. (Apple is using .heic, based on HEVC intra coding. Android'll support .heic in the next major version, but the HEVC patent situation will likely constrain how many external tools, platforms, etc. pick it up.) There's work on defining an AVIF format (https://github.com/AOMediaCodec/av1-avif) and tech demos look great (https://people.xiph.org/~tdaede/av1stilldemo/). So, maybe fewer ugly JPEG artifacts in our future, partly thanks to that deringing filter mentioned at the end of Monty's post. (I said more or less the stuff about stills above, with a couple more details and links, at https://news.ycombinator.com/item?id=16699000)