| Summary: | rotating an image seems to forget to reset the orientation flag | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Nico Kruber <nico.kruber> |
| Component: | Import-PostProcessing | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, k, metzpinguin |
| Priority: | NOR | ||
| Version: | 5.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/digikam/3c33610858367196ee6c73745f0d8a1d8d242634 | Version Fixed In: | 6.0.0 |
| Sentry Crash Report: | |||
|
Description
Nico Kruber
2016-08-03 22:10:58 UTC
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. *** Bug 393539 has been marked as a duplicate of this bug. *** |