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
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.
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 ??
Still valid using last digiKam 4.2.0 ? Gilles Caulier
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.
*** This bug has been marked as a duplicate of bug 329976 ***
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
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 ;-) )
Thanks for the feedback