why is there a limit on number of pixels (8912896) in the spec?

[sheecegardezi]

Coded image items compliant to the AVIF Baseline profile may not have a number of pixels greater than 8912896, a width greater than 8192 or a height greater than 4352.

[leo-barnes]

It's a profile. Profiles exist to provide an anchoring point for implementations since basically no implementation will fully implement everything that is supported by the AV1 spec. Vendors creating HW or someone adding a SW implementation can then easily look at the various profiles and select a subset of features that make sense to add and that hopefully matches what other implementations have added.

4:2:0 4k 8-bit video is something that most implementations will support, hence why that kind of corresponds to the AVIF Baseline profile. 8k or 10-bit is more rare. But implementations that support 8k tend to also support 10-bit and/or 4:4:4.

[sheecegardezi]

Maybe I’m misunderstanding but it sounds like it’s an arbitrary number. I don’t think your point about anchoring point or just a reference profile is valid … Problem I’m facing is I can’t seem find a straight forward way to create avif image from rgb arrays and I have to rely on libavif for conversion. Libavif throw errors if image exceeds 8912896. I havnt tested this but my guess is browser will also throw an error if an avif image is greater then this size. And this is because of an arbitrary number set in spec.
There are whole other worlds outside of 8k videos like geospatial datasets, game environments etc that can benefit form this image format … this brings me back to my question why is there a limit on number of pixels (8912896) in the spec? if it has nothing to do with compression algorithm or ability to decode the binary data then it should be removed.

[leo-barnes]

Maybe I’m misunderstanding but it sounds like it’s an arbitrary number.

It is not. There are corresponding profiles and levels built into all video codecs, including AV1. Those numbers are typically chosen to map to specific use-cases.

I don’t think your point about anchoring point or just a reference profile is valid …

Sorry, but that is the reason that the profiles were added to AVIF, MIAF and HEIF.

Problem I’m facing is I can’t seem find a straight forward way to create avif image from rgb arrays and I have to rely on libavif for conversion. Libavif throw errors if image exceeds 8912896. I havnt tested this but my guess is browser will also throw an error if an avif image is greater then this size. And this is because of an arbitrary number set in spec.

No, it's not because it's an arbitrary number set in AVIF. It's because it's a limitation of the underlying codec. All codecs have limitations like this.

There are whole other worlds outside of 8k videos like geospatial datasets, game environments etc that can benefit form this image format … this brings me back to my question why is there a limit on number of pixels (8912896) in the spec? if it has nothing to do with compression algorithm or ability to decode the binary data then it should be removed.

Absolutely. And AVIF/HEIF does explicitly support those use cases. As an example, you can watch one of the first WWDC demos from when Apple announced the switch to HEIF. It involved showing a gigapixel pano being displayed in Photos on an iPhone. One of the reasons for switching to the HEIF container format (on which AVIF is based) was specifically to be able to support more complex and large image files.

But encoding something like a gigapixel image as a single coded image item is a really bad idea. No HW implementations will support it, and even SW implementations may not support it since there may simply not be enough memory on the device to decode the full image.

The way you're supposed to be creating large files is by using a grid item, where you split the image into reasonably sized tiles. This allows:

• Many more implementations (including dedicated HW) to support them
• Multiple tiles to be decoded in parallel if there are multiple SW/HW cores
• Only the tiles of interest to be decoded
• Processing to be done incrementally without ever having to hold the full image in memory at any time

[wantehchang]

@sheecegardezi Hi Sheece,

What is the size (in width x height) of the image that you could not encode with libavif? If you use libavif's avifenc program, what is the command line?

libavif should be able to encode an AVIF image larger than 8912896 pixels (but smaller than, say, 2^28, see the Note below) without using a grid item, but it should not insert the 'MA1B' brand into the AVIF file in this case. (Unfortunately libavif adds the 'MA1B' brand incorrectly. I filed AOMediaCodec/libavif#2514.) Photos taken by most smart phones are larger than 8912896 pixels.

For example, attached is an AVIF image of size 4624x3472 (zip-compressed so that it can be attached) that I just encoded with libavif's avifenc program. (I used libaom as the AV1 encoder.) I can view the image in the Chrome browser.

Note: Chrome and the libavif decoder imposes a maximum image size of 2^28 to avoid integer overflow bugs. As far as I know, the libavif encoder itself does not impose such a image size limit, but the underlying AV1 encoder such as libaom may impose an image size limit for the same reason. To encode a very large AVIF image, you need to use a grid item as Leo Barnes suggested.

trees.avif.zip

[gitoss]

It is not. There are corresponding profiles and levels built into all video codecs, including AV1. Those numbers are typically chosen to map to specific use-cases.

Sorry, but that is the reason that the profiles were added to AVIF, MIAF and HEIF.

Talking about how great profiles are, it's probably worth mentioning that avif (image) even with the latest draft spec I can find doesn't support more than 10 bpp even in the "advanced" avif profile - while AV1 (video) has a "professional" av1 profile for this use case.

Afaik the devs thought about adding a 12 bpp "professional" avif profile at some point in time, but it didn't happen. So unless the image hasm't "number of pixels greater than 35651584, a width greater than 16384 or a height greater than 8704" you're inside a profile, as long as you stick to 8 or 10 bpp.

https://en.wikipedia.org/wiki/AV1#Profiles
https://aomediacodec.github.io/av1-avif/#advanced-profile

[leo-barnes]

@gitoss

Afaik the devs thought about adding a 12 bpp "professional" avif profile at some point in time, but it didn't happen. So unless the image hasm't "number of pixels greater than 35651584, a width greater than 16384 or a height greater than 8704" you're inside a profile, as long as you stick to 8 or 10 bpp.

One thing to note is that you don't have to use any AVIF profiles. You can create a profiles-less AVIF file that only uses the AVIF brand, at which point you can basically add whatever AV1 supports into the file.

We debated whether we should add a 12-bit profile or not, but the conclusion was that profiles are there to add a restriction. Adding a 12-bit profile would basically not add any restriction, so it's kind of pointless to have it since you could then simply just create a profile-less AVIF instead.