SUMMARY Attempting to rotate an image by modifying the EXIF flags is unfortunately not the default. The default rotation seems to be possibly lossy unless I'm mistaken? (which is extremely bad, but a separate issue or I'm misremembering)... This bug though is that "rotation fails but pretends it's worked". See below. STEPS TO REPRODUCE To replicate: 1. set the following settings in Settings > Metadata left vertical tabbar > Rotation horizontal tabbar > "When rotating a file" section: (X) Rotate by only setting a flag ( ) Rotate by changing the content if possible [ ] Even allow lossy rotation if necessary <-- (this should be disabled by default if it isn't) 2. assign a shortcut of Ctrl-Shift-Left to keybind [rotate]"Left", and similar for Right, if not already set; this seems equivalent to context menu > Rotate > Left/Right 3. Find a .heic image file e.g. from your mobile phone, and note its EXIF Orientation metadata in the Metadata view. You can even have the metadata view open, or keep track of how it changes with exiftool. 4. Attempt to rotate the image with the shortcut. OBSERVED RESULT The image is rotated in digikam, semi-permanently, but behind-the-scenes the metadata has not changed. If the file is thus moved within digikam, or the folder or db is refreshed (e.g. right-click and refresh), or accessed from other apps, it will appear as originally. This is a sign of a lack of transactional semantics for similar operations, and is deceptive to the user (which I say without any insult since this bug description as text-over-the-internet can't convey tone very well... thank you for your work); I just say this because it can be a sign this design issue affects related related functions (not just Rotation). No error message is output via stdout. The metadata DOES change on other file formats, like jpg. EXPECTED RESULT The expected result is that Digikam attempts to set this flag or do its machinations, then reads it to assert if it was successfully set (either by waiting, or asynchronously). If successfully set, the change is propagated to visual feedback. If not successfully set, an error notification is raised. This way, the actual rotation state in Digikam is consistent with that on disk. In particular, exiftool (12.76) handles the rotation of .heic files just fine, so "shelling out" to exiftool should work just fine, but is a temporary and not permanent fix to the lack of try-except transactional semantics. Cheers.
For HEIF, exif metadata is not well supported in writting mode by Exiv2 backend. Switching to ExifToll backend in Setup/Metadata must solve. the problem. Other alternative : uses XMP sidecar
Thank you, the workaround works! P.S.: When applying this workaround (in Settings > Metadata > Behavior for others' reference, specifically [X] Use ExifTool backend to read... [X] Delegate to ExifTool backend all operations...), I noticed that "Rescan file when files are modified" might not seem to be respected, otherwise a rescan might have tipped off the user. Cheers. (Migration: For people with corrupted databases, if you keep track of orientation in TABLE ImageInformation .orientation :: int 0-8 (presumably mapping 1-8 to EXIF orientation), then you can 'fix' this for users with corrupt databases during migration by prompting them to apply digikam's orientation on example files if the orientation differs (or not apply it), depending on whether they use exiftool or Exiv2 grows support, etc.)