SUMMARY I have scanned images in which Exif.Image.DateTime is set by the scanner to be the time of scanning. I use Exiv2 commands to manually copy that to Exif.Photo.DateTimeDigitized and also to set the original capture time in Exif.Photo.DateTimeOriginal. It looks like this: $ exiv2 -pt -g DateTime rj_20040709_063.jpg Exif.Image.DateTime Ascii 20 2015:10:11 13:40:12 Exif.Photo.DateTimeOriginal Ascii 20 2004:07:09 00:00:17 Exif.Photo.DateTimeDigitized Ascii 20 2015:10:11 13:40:12 When the image is loaded into DigiKam, all seems fine. The Exif tab of the metadata panel correctly shows both the Original and Digitized dates under the photograph information. However, if I choose Item->Write Metadata to File (I'm writing to sidecars only), then the photograph information shows the Original date for *both* DateTimeOriginal and DateTimeDigitized. If I configure Digikam metadata so that timestamps are not written to the metadata, this behavior does not happen. STEPS TO REPRODUCE 1. Configure DK metadata to write timestamps to metadata (I believe this is the default) 2. Add an image to DK that has different times for Exif.Photo.DateTimeOriginal and Exif.Photo.DateTimeDigitized 3. Perform the action Item->Write Metadata to File 4. See that the photograph information in the Exif tab of the metadata panel shows the original date for both "Date and Time (digitized)" and "Date and Time (original)" OBSERVED RESULT The digitized time is mistakenly overwritten by the original time. EXPECTED RESULT The digitized time should not be overwritten by the original time. SOFTWARE/OS VERSIONS Using the digikam-7.0.0-beta2-1-x86-64 AppImage on Pop OS! 19.10. ADDITIONAL INFORMATION This is annoying for those of us who obsess over metadata of scanned photos, but since it may not matter for digital photos where original and digitized is the same, and it seems that turning off timestamps in the metadata settings avoids the problem, this is probably a minor bug.
Hmm, in a first attempt here I can not reproduce the problem, the original date is preserved. It could be a problem with the AppImage because the locale is not working properly. Can you please provide a test image? Maik
Created attachment 125578 [details] sample image with different DateTimeOriginal and DateTimeDigitized dates Here is an image for testing.
(In reply to Maik Qualmann from comment #1) > Hmm, in a first attempt here I can not reproduce the problem, the original > date is preserved. It could be a problem with the AppImage because the > locale is not working properly. Can you please provide a test image? > > Maik Oh, and in case I wasn't clear, the problem isn't that the original date is preserved. It's that the digitized date is replaced.
The digitization date 2015-10-11 does not change here either. Maybe upload the sidecar file for testing so I can compare the content. Maik
Created attachment 125580 [details] Animated GIF of date-changing behavior Maybe it's easiest to show you the behavior in this animated gif.
Ok, I hadn't activated the writing of the time stamp. The problem only occurs with sidecars. Exiv2 performs a mapping to interpret from XMP to Exif. And this mapping uses Xmp.CreateDate for Exif.Photo.DateTimeDigitized. At the moment I don't see a solution to the problem. For me, the mapping in parts is faulty from Exiv2. The right candidate would be Xmp.exif.DateTimeDigitized. Maik
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Best Regards Gilles Caulier
@Raymond Johnson digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
@Raymond Johnson, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Thanks in advance Gilles Caulier