Wrong image dimensions when irot is set

[mrjackbo]

Here is an image for which libheif 1.17 reports wrong dimensions for the primary image. It has width 722 and height 1024 after the correct rotation is applied, but libheif outputs 1024x722.

$ ./heif-info kimono.rotate90.avif
MIME type: image/avif
main brand: avif
compatible brands: avif, mif1, miaf, MA1B

image: 1024x722 (id=1), primary
  colorspace: YCbCr, 4:4:4
  bit depth: 8
  color profile: no
  alpha channel: no 
  depth channel: no
metadata:
  none
transformations:
  angle (ccw): 270
[...]

I believe the problem is here: For some reason the irot box appears before the ispe box, and thus line 626, which is supposed to flip the dimensions, is never called.

[bradh]

I believe that file is invalid. ISO/IEC 23008-12:2022 Section 6.5.3.1 requires that ispe occurs prior to the association of all other transformative properties. Do you know what software made it?

[emerygrotto]

The command is here: https://github.com/link-u/avif-sample-images/blob/c666a368b73006246694919b5dbcc078317af6cc/Makefile#L291

[bradh]

The cavif code is abandoned so probably not a priority to work around this bug in the producer.

[silverbacknet]

Those were generated years ago with an early pre-release of https://github.com/kornelski/cavif-rs . Sometimes early apps just aren't complete, even when someone uses them to purport to be authoritative. (Even samples from standards have suffered from this...)

A misplaced irot is pretty benign, since it can be fixed so easily by restreaming the boxes or just having an app set a new rotation.

[bradh]

Those were generated years ago with an early pre-release of https://github.com/kornelski/cavif-rs . Sometimes early apps just aren't complete, even when someone uses them to purport to be authoritative. (Even samples from standards have suffered from this...)

Interesting. I understood they came from https://github.com/link-u/cavif