5 ms·

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 s

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.
    - kevin_thibedeau 4y ago
      > there are gains beyond 8k. Sure if you had pinhole irises to look through instead of blobs of organic tissue.
    - giantrobot 4y ago
      It's not about the number of rods and cones, the question is the optical acuity of the eye. Someone with 20/20 vision has an acuity of about 1 minute of arc (1/60th of a degree). At living room distances a 4K 65" TV has pixels so small someone with perfect vision can't make them out. An 8K resolution is a waste. For 8K to be actually visible you're talking about TVs that take up the whole wall of a living room.
      - redox99 4y ago
        There are other types of acuity, such as vernier acuity, that are much more accurate. If you had a "human sized" display (let's say 2m x 2m), that you could stand next to, and it showed footage of a real size analog caliper that you had to read, I wouldn't be surprised if you needed something like 128K video or more. But I agree that for regular video content, 8K is good enough.
ttoinou 4y ago
How is 32 bits not enough ?
- pixelesque 4y ago
  It's more than enough per dimension (width and height), that's the point: the file format on disk is fine, there seem to be other limitations when trying to add the images to the format which error out currently with libavif.
  - Tempest1981 4y ago
    Maybe not enough memory? Although 8192 x 8192 x 4 (RGBA) is 256 MB, which is quite reasonable.
CodesInChaos 4y ago
Is that a limitation of the format itself, or just a limitation of libavif?
- pixelesque 4y ago
  The format stores both width and height as uint32_t (even in the structs within libavif!), so it's not the format itself, that's fine. I couldn't even get it to save 8192 x 5464 size files which is the native format of the R5 camera, that was too wide. It seems to be a limitation with the libavif API or maybe the codec.
  - CodesInChaos 4y ago
    Other parts of the format could have stricter limitations than the header, so the these fields being 32 bits doesn't necessarily mean it's not a format limitation Though I agree it's probably an implementation issue.
brigade 4y ago
It's still a perfectly valid bitstream and file if you don't conform to the defined profiles and encode resolutions up AV1's maximum 65536x65536 (or even larger with HEIF grids), as long as you don't falsely claim you're conforming to the defined profiles/levels. Then there's simply no guarantee that any specific decoder can decode it. (but technically that's the same with merely conforming to the advanced profile, or else there wouldn't be two profiles...) I don't know about the libavif API, but certainly libavif's avifenc will happily create large files that don't conform to the AVIF advanced profile.
- pixelesque 4y ago
  Yeah, the structs within libavif store width and height as uint32_t (which is better than libjpeg and libpng which use uint16_t, but both of those old format libs seem happy to save > 20,000 dimensions in my testing, as does libheif, and all the other libs produce nice helpful error strings when the size is too large), so the format itself is fine, libavif just currently seems incapable of encoding images larger than film "8k". I couldn't even get it to save at the size of 8192 x 5464, which is the R5's full resolution.
Tempest1981 4y ago
Is the 8k limit both horizontal and vertical? Most of my panoramas are horizontal (15k x 4k), but a few are vertical.
- pixelesque 4y ago
  I think so: I couldn't even save 8192 x 5464 full res examples from the R5 with it: it wouldn't even do 8000, seems to be limited to the "film" 8k resolution which is a bit less.

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.
  - kevin_thibedeau 4y ago
    > there are gains beyond 8k. Sure if you had pinhole irises to look through instead of blobs of organic tissue.
  - giantrobot 4y ago
    It's not about the number of rods and cones, the question is the optical acuity of the eye. Someone with 20/20 vision has an acuity of about 1 minute of arc (1/60th of a degree). At living room distances a 4K 65" TV has pixels so small someone with perfect vision can't make them out. An 8K resolution is a waste. For 8K to be actually visible you're talking about TVs that take up the whole wall of a living room.
    - redox99 4y ago
      There are other types of acuity, such as vernier acuity, that are much more accurate. If you had a "human sized" display (let's say 2m x 2m), that you could stand next to, and it showed footage of a real size analog caliper that you had to read, I wouldn't be surprised if you needed something like 128K video or more. But I agree that for regular video content, 8K is good enough.

ttoinou 4y ago

How is 32 bits not enough ?

pixelesque 4y ago
It's more than enough per dimension (width and height), that's the point: the file format on disk is fine, there seem to be other limitations when trying to add the images to the format which error out currently with libavif.
- Tempest1981 4y ago
  Maybe not enough memory? Although 8192 x 8192 x 4 (RGBA) is 256 MB, which is quite reasonable.

CodesInChaos 4y ago

Is that a limitation of the format itself, or just a limitation of libavif?

pixelesque 4y ago
The format stores both width and height as uint32_t (even in the structs within libavif!), so it's not the format itself, that's fine. I couldn't even get it to save 8192 x 5464 size files which is the native format of the R5 camera, that was too wide. It seems to be a limitation with the libavif API or maybe the codec.
- CodesInChaos 4y ago
  Other parts of the format could have stricter limitations than the header, so the these fields being 32 bits doesn't necessarily mean it's not a format limitation Though I agree it's probably an implementation issue.

brigade 4y ago

It's still a perfectly valid bitstream and file if you don't conform to the defined profiles and encode resolutions up AV1's maximum 65536x65536 (or even larger with HEIF grids), as long as you don't falsely claim you're conforming to the defined profiles/levels. Then there's simply no guarantee that any specific decoder can decode it. (but technically that's the same with merely conforming to the advanced profile, or else there wouldn't be two profiles...) I don't know about the libavif API, but certainly libavif's avifenc will happily create large files that don't conform to the AVIF advanced profile.

pixelesque 4y ago
Yeah, the structs within libavif store width and height as uint32_t (which is better than libjpeg and libpng which use uint16_t, but both of those old format libs seem happy to save > 20,000 dimensions in my testing, as does libheif, and all the other libs produce nice helpful error strings when the size is too large), so the format itself is fine, libavif just currently seems incapable of encoding images larger than film "8k". I couldn't even get it to save at the size of 8192 x 5464, which is the R5's full resolution.

Tempest1981 4y ago

Is the 8k limit both horizontal and vertical? Most of my panoramas are horizontal (15k x 4k), but a few are vertical.

pixelesque 4y ago
I think so: I couldn't even save 8192 x 5464 full res examples from the R5 with it: it wouldn't even do 8000, seems to be limited to the "film" 8k resolution which is a bit less.