Whenever I (auto-)rotate images, e.g. by the menu action or during import where it seems to be done automatically, it looks like the image contents are rotated but the metadata is not updated (or maybe only in the sidecar file but not in the image itself). Manually setting the exif Orientation tag to "normal" via the menu seems to fix the view inside digikam but not for external programs, e.g. gimp. Reproducible: Always Steps to Reproduce: 1. find a jpeg which is rotated by its exif flag 2. rotate in digikam (with the settings above) 3. open the image in e.g. gimp to see the messed-up result Actual Results: rotated image (contents) with the original exif orientation flag inside the jpg file Expected Results: rotated image (contents) including the exif orientation flag set to "normal" inside the jpg file related application settings: * Metadata -> Rotation -> Rotate by changing the content if possible * Metadata -> Rotation -> Write flag to metadata if possible * Metadata -> Behaviour -> Read from sidecar files * Metadata -> Behaviour -> Write to sidecar files + Write to XMP sidecar only (* Metadata -> Behaviour -> Use lazy synchronisation OFF)
Git commit c4368decf81052e45dcec84833e8697d748dfe7d by Maik Qualmann. Committed on 04/08/2016 at 17:22. Pushed by mqualmann into branch 'master'. move temp sidecar file to image if rotate image M +20 -3 libs/jpegutils/jpegutils.cpp http://commits.kde.org/digikam/c4368decf81052e45dcec84833e8697d748dfe7d
This commit fix the not updated exif orientation if using sidecar files. With you metadata settings you write metadatas only to sidecar files. Gimp not read sidecar files. You must write metadatas for Gimp in the image files. I close this bug now. Maik
Thank you and yes, I usually do not want digikam to modify the file contents (so I do not need to backup the jpg over and over again) and hence my settings. Looks like the temporary (and left-over) jpegrotator...xml files are a thing of the past, too, after your commit :) However, the option "Rotate by changing the content if possible" allows the jpg file to change and implies that the image's metadata in the jpg file is consistent with the image content itself. Therefore, the metadata in the jpg file should be changed as well and that was the behaviour in digikam < 5.0. I know that these two settings somehow contradict each other but I also believe that the previous behaviour is the most sensible one under these circumstances.
I do not think that the behavior of digiKam < 5.0.0 was different. I test it tomorrow with digiKam-4.14. Maik
With digiKam-4.14 the same behavior. Orientation flag is not written in this case. The bug (now is fixed) with temporary XMP files is also available. Gilles, what do you think? Should the orientation flag be changed in the metadata, if the option is enabled that all changes only write to sidecar files? Maik
>Gilles, what do you think? Should the orientation flag be changed in the metadata, if the option is enabled that all changes only write to sidecar files? Typically, no. If only sidecar must be touched (through metadata settings), well only sidecar must be changed. Some users want to not touch the image file and delegate to sidecar all metadata changes. Gilles
(In reply to caulier.gilles from comment #6) > >Gilles, what do you think? Should the orientation flag be changed in the metadata, if the option is enabled that all changes only write to sidecar files? > > Typically, no. If only sidecar must be touched (through metadata settings), > well only sidecar must be changed. Some users want to not touch the image > file and delegate to sidecar all metadata changes. this bug is not about whether the orientation flag should be changed in the image when metadata should only be written to sidecar files but whether the orientation flag should be changed in the image when the user selects to "Rotate by changing the content if possible" AND decided to write metadata to sidecar files only (which kind of contradict)
(In reply to Maik Qualmann from comment #5) > With digiKam-4.14 the same behavior. Orientation flag is not written in this > case. I guess you are right - although I remembered differently, I verified the same behaviour with digikam (and kipi) 4.14, 4.6 and 4.3 on my side. I can't test any older version here but think that my setup was once working. Note that with these three versions, after auto-rotating the file and re-reading their metadata (with the "Read from sidecar files" option set), all are rotated wrongly in the UI but I guess this is due to the left-over "JpegRotator-XM****.digikamtempfile.jpg.xmp" file which is the only file that has the new orientation flag set and is now (hopefully) correctly integrated into the right xmp file :)
Problem still reproducible using current DK 5.4.0 bundle ? https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier
Can you reproduce the problem using digiKam Linux AppImage bundle ? The last bundle is available at this url: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier
with the 5.4.0 package from 22/12/2016: * using auto-rotate does not touch the jpg file at all but only seems to set the orientation flag in digikam's DB and thus the file is shown in the wrong orientation in digikam itself. (this is some other bug, I guess) * using rotate left/right the file's content is rotated but the exif data in the jpg is not changed (only in the sidecar file). It is shown correctly in Digikam but is wrong in programs only using the exif data from the jpg. Please let me sum up my desired change: the content of the file needs to be consistent with the exif data in the file, so if the content is changed, e.g. by allowing rotation, there is no point in not changing the metadata along with it, despite the setting of where to save metadata.
Git commit 3c33610858367196ee6c73745f0d8a1d8d242634 by Maik Qualmann. Committed on 28/04/2018 at 20:15. Pushed by mqualmann into branch 'master'. reset exif orientation tag to normal if rotate pixels and the option is enabled M +2 -1 core/libs/fileactionmanager/fileworkeriface.cpp https://commits.kde.org/digikam/3c33610858367196ee6c73745f0d8a1d8d242634
*** Bug 393539 has been marked as a duplicate of this bug. ***
I am still of the opinion that in the attitude that metadata should be written only in the sidecar, this must be respected. If we start adding exceptions now, this will unnecessarily complicate the whole story. Anyone who wants the orientation flag to be written in the metadata of the image has the option to do so, either with writing to the image and sidecar or sidecar just for read-only files (RAW). Maik
I'm agree with Maik. The puzzle is already enough complex to not increase it to introduce this feature. Gilles Caulier
The main problem of the non-reset orientation flag is fixed. I close the bug now.