Bug 329390

Summary: Auto-rotate Using Exif information: rotates wrong picture
Product: [Applications] digikam Reporter: Nicofo <nicofo>
Component: Metadata-OrientationAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 3.5.0   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In: 8.2.0
Sentry Crash Report:

Description Nicofo 2013-12-29 22:39:17 UTC
Now that the bug #317943 seems resolved, I have auto-rotated several albums.
It has worked well except once:

On an album, digikam has rotated all my pictures, but it has made a mistake between 2 pictures (2 consecutive pictures): it has rotated the first one while it shouldn't and has not rotated the second one while it should ! It's as though digikam had mixed up these 2 pictures ...

More accurately:
- my picture 102.jpg is a landscape picture (Orientation=top-left) -> no need to rotate it
- my picture 103.jpg is a portrait picture (Orientation=right-top) -> need to rotate it
After digikam Auto-rotation:
- picture 102 has been rotated (picture itself+thumbnail in digikam view) (Orientation still top-left). Moreover, the tag "Software = digiKam-3.5.0" (among others) has been added. This tag is normally added by digikam during an image manipulation: it is not present for my other pictures that digikam has not rotated.
- picture 103: its thumbnail in digikam has been rotated (but I think the image itself has not been rotated) (Orientation still right-top)

Additional Information: To resolve this situation:
- apply a new Auto-rotation -> no effect
- I have had to "Reread Metadata from Image" (that had an effect on the picture 103) and apply "Auto-rotation using Exif info" again to have finally picture 103 correctly rotated.
- For picture 102 -> I have had to rotate it manually.

Conclusion:
=========
I try to interpret what digikam had to do and what it did actually (this is my interpretation -> may be you have to correct it):
- what digikam had to:
0) leave untouched picture 102
1) rotate physically picture 103
2) update metadata (right-top -> top-left) of picture 103
2bis) update digikam database for picture 103
3) update thumbnail (in digikam view and database) for picture 103

- what digikam did:
1) rotate physically picture 102 instead of 103 :-(
2) probably update metadata of picture 102 (i.e 'Orientation' tag set to top-left [because it is the metadata that should have been applied to 103, but is already the one of 102 -> 'Orientation' metadata actually unchanged] + 'Software' tag added)
2bis) update digikam database of picture 103 (?) Actually I don't know what digikam did, but for picture 103, there were a difference between its metadata and the database (that was corrected after a "Reread Metadata from Image")
3) update thumbnails (in digikam view and database) for pictures 102 and 103 (both appear not correctly rotated)

=> digikam has applied a part of the treatment rotation to a wrong picture ?!

Reproducible: Couldn't Reproduce
Comment 1 Nicofo 2014-01-14 21:20:42 UTC
Additional info: I'm wondering if this bug could be related to bug 329976 .
It would be surprising since in this bug, only 2 pictures were wrongly rotated while I have a lot of pictures in portrait/landscape mode in the concerned directory, but the result seems identical.
Comment 2 Nicofo 2014-01-14 21:51:30 UTC
New info: I remark now that the digikam timestamp of my pictures is not correct from picture 94 (reminder: I had a rotation problem for pictures 102 and 103).
As in bug 329976, timestamp of picture 94 equals exif of picture 93, etc for the following pictures...
I remind me that I had deleted one picture (say number 80) and renamed my pictures consequently so 81 became 80 ; .... ; 94 became 93 ; 95 became 94 ; etc...

So, finally, I think this is well an undesired effect of bug 329976.

However, strangely, although I deleted picture 80, timestamp of pictures 80 to 93 are correct ?? It's only from picture 94 that it becomes to be wrong (for the majority but not all ?). And no rotation problem for these pictures ??
Comment 3 caulier.gilles 2014-08-22 15:05:04 UTC
Still valid using last digiKam 4.2.0 ?

Gilles Caulier
Comment 4 Nicofo 2014-08-22 16:28:50 UTC
Gilles,
for me, this is another confusion caused by bug 329976. If you agree, you can set this bug as a duplicate of bug 329976.
Comment 5 caulier.gilles 2014-08-22 18:58:36 UTC

*** This bug has been marked as a duplicate of bug 329976 ***
Comment 6 caulier.gilles 2023-10-24 05:38:01 UTC
Nicofo,

The digiKam 8.2.0 pre-release for Windows is available for testing :

https://files.kde.org/digikam/

Problem still reproducible on your computer ?

Thanks in advance

Gilles Caulier
Comment 7 Nicofo 2023-10-24 20:01:11 UTC
No such problem since a long time.
Note: probably because bug 329976 does not affect the orientation anymore since a long time (because orientation is reread from the metadata of the file after a renaming - if option 'Rescan file when files modified' activated)

So this bug can be closed (it was already in the state "resolved" (duplicate) btw ;-) )
Comment 8 caulier.gilles 2023-10-25 02:01:53 UTC
Thanks for the feedback