HEIF: Parse irot box to expose image orientation

[marcchehab]

Is your feature request related to a problem?

HEIF files from cameras like Sony A7 IV use the irot (image rotation) transformative property to indicate orientation. However, exiv2 does not parse this box, so Exif.Image.Orientation is not populated for these files.

This causes problems in applications like digiKam that rely on exiv2 for metadata: portrait photos display with incorrect orientation because no orientation information is available.

# Sony A7 IV HEIF file - exiv2 shows no orientation
$ exiv2 -g Orientation DSC02105.HIF
Exif.SonyMisc3c.CameraOrientation            Byte        1  Rotate 270° CW

# But exiftool shows the irot data exists
$ exiftool -G1 -Rotation -Orientation DSC02105.HIF
[QuickTime]     Rotation                        : 90

The irot box is already recognized by the boxHandler (visible in -pS output) but its value is not extracted.

Describe the solution you would like

Parse the irot box in bmffimage.cpp and synthesize Exif.Image.Orientation from it when EXIF orientation is not already present in the file. The mapping from irot angle (anti-clockwise, 0-3) to EXIF orientation would be:

irot	Rotation	EXIF Orientation
0	0°	1 (top, left)
1	90° CCW	8 (left, bottom)
2	180°	3 (bottom, right)
3	270° CCW	6 (right, top)

This follows the pattern already used for camera-specific rotation tags in easyaccess.cpp.

Describe alternatives you have considered

• ExifTool script: Currently using a shell script that copies CameraOrientation to Orientation using exiftool. Works but requires modifying files and running on import.
• Fix in digiKam: Would only help digiKam users, not other exiv2-based apps.
• Expose irot as separate property: More architecturally pure, but would require changes to all consuming applications.

Desktop

• OS and version: Linux (Ubuntu 24.04 / Pop!_OS)
• Exiv2 version and source: main branch (commit 872237d)
• Any software using exiv2 and source: digiKam 8.8.0 (Flatpak)

Additional context

This probably affects all HEIF-producing cameras that use irot without setting EXIF orientation, including:

• Sony A7 IV (.HIF files)
• Canon (CR3/HEIF)
• Likely others

The existing test files in tests/bugfixes/github/test_pr1475_HIF.py show irot boxes being detected but not parsed:

Exiv2::BmffImage::boxHandler: irot      577->9

I have a draft implementation that works well on my Sony files, if you'd like me to submit a PR. I created it using Claude Code.

main...marcchehab:exiv2:feature/irot-orientation

[clanmills]

Thank you @marcchehab for reporting this and for your investigation into a remedy.

Exiv2 reports the metadata in your file. Could you upload your file DSC02105.HIF for further investigation.

This sounds like a bug in the Sony Firmware as they have set Exif.SonyMisc3c.CameraOrientation to a different value fromExif.Image.Orientation. Are you sure about this? Could it be that the stored image is indeed with Orientation 0, although the camera is rotated?

Another thought about is to modify/update Exiv2 EasyAccess API to handle Orientation. The exiv2 command-line application can exercise more-or-less every feature of the library. Consider the following command:

$ exiv2 -g orient/i https://clanmills.com/Stonehenge.jpg
Exif.Image.Orientation                       Short       1  top, left

This command uses a grep library to filter the output of the command exiv2 -pa https://clanmills.com/Stonehenge.jpg to report metadata.

Now consider this command:

$ exiv2 https://clanmills.com/Stonehenge.jpg
File name       : https://clanmills.com/Stonehenge.jpg
MIME type       : image/jpeg
Image size      : 6000 x 4000
Thumbnail       : image/jpeg, 10837 Bytes
Camera make     : NIKON CORPORATION
Camera model    : NIKON D5300
Image timestamp : 2015:07:16 15:38:54
File number     : 
Exposure time   : 1/400 s
Aperture        : F10
Exposure bias   : 0 EV
Flash           : No, compulsory
Flash bias      : 
Focal length    : 44.0 mm
Subject distance: 31.62 m
ISO speed       : 200
Exposure mode   : Not defined
Metering mode   : Multi-segment
Macro mode      : 
Image quality   : NORMAL 
White balance   : AUTO        
Copyright       : 
Exif comment    : charset=Ascii Classic View
$ 

This command uses the EasyAccess API to "hunt down" the metadata by inspecting the MakerNote and other locations. EasyAccess is documented here: https://github.com/Exiv2/exiv2/wiki/EasyAccess-API

I appreciate the effort you have invested to "fix" this issue. However, I don't think we should "doctor" the value of Exif.Image.Orientation.

Another matter to consider is what should be done if the user edits Exif.Image.Orientation and/or Exif.SonyMisc3c.CameraOrientation.

My judgement is that the safe approach to this issue is to upgrade the EasyAccess API to support Orientation and ask DigiKam (and other library users) to use the EasyAccess to query Orientation.