SUMMARY On a series of images the dates read out are wrong, or even fictitious. Many images of that series (Xiaomi MI3, ran through Wechat, seems common denominator) are shown in thumbnail view as having identical date/time, which is that 2002 date. Looking with exiv2 gives limited results, exiftool does better. The probable date of the hamburger picture is 2014:08:25 19:28:17 EXPECTED RESULT Don't show dates that are not in the file. And give preference to "Date/Time Original" or GPS dates. Or make the user aware of discrepancies. SOFTWARE/OS VERSIONS Qt 5.9.5 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.4.0) on "xcb" OS: Ubuntu 18.04.4 LTS [linux version 4.15.0-91-generic] ADDITIONAL INFORMATION https://my.mail.de/dl/61cb9e7c7c079b4803cdf8efe4a1de46 https://my.mail.de/dl/7ce6c711fe8a9554f38ce4e29321f2d4 One example (hamburger picture): digikam-properties: created 06.08.15 14:40 where does that come from? digikam-metadata: shows same GPS date/time as exiftool Date and time (digitized) 2002:12:08 12:00:00 fictitious, but apparently in the file Date and time (original) 2014:08:25 19:28:17 (likely correct date) In the Batch Queue Manager, [date:yyyy-MM-ddThh.mm.ss] pulls out the 2015-08-06T14.40.01 fictitious timestamp Item/Adjust Date&Time shows DigiKam timestamp:06.08.2015 14:40:02 EXIF/IPTC/XMP shows: 2002:12:08 12:00:00 wrong date, batch setting dates would cause a mess. EXIF: original actually gets the correct 2014 date EXIF: digitized gets the 2002 date $ exiv2 mmicroMsg.1409-hamburger.jpg File name : microMsg.1409009293506-bad-date.jpg File size : 1886048 Bytes MIME type : image/jpeg Image size : 4208 x 3120 Camera make : XIAOMI Camera model : MI3 Image timestamp : 2014:08:25 19:28:17 (likely correct date) not output: create date exiftool: Create Date : 2002:12:08 12:00:00 Date/Time Original : 2014:08:25 19:28:17 (likely correct date) GPS Date/Time : 2014:08:25 18:33:36Z digikam version 7.0.0-beta3 CPU cores: 4 Eigen: 3.3.4 Exiv2: 0.27.2 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes HEIF encoding support: Yes ImageMagick codecs support: No KF5: 5.44.0 LensFun: 0.3.2-0 LibCImg: 130 LibJPEG: 80 LibJasper support: No LibLCMS: 2090 LibLqr support: Yes LibPGF: 7.19.03 LibPNG: 1.6.36 LibRaw: 0.20.0 LibTIFF: 4.0.9 Marble: 0.27.20 Parallelized demosaicing: Yes Qt: 5.9.5 Qt WebEngine support: Yes VKontakte support: No AkonadiContact support: No Baloo support: Yes Calendar support: Yes DBus support: Yes Database backend: QSQLITE HTML Gallery support: Yes LibGphoto2: 2.5.16 LibOpenCV: 4.3.0-pre Media player support: No Panorama support: No
Ok, since the original does not appear again in the image except for the GPS date (which we are not testing), it fails in the final test because we do not consider the priority in the final test. I will fix it. Yes, determining the correct date is not easy. In principle, your camera has already made a mistake, since digitization and original date are so different. Maik
Git commit 5d8b8cf2f862ebd52259dc2355fac6f7c24a3083 by Maik Qualmann. Committed on 30/03/2020 at 17:11. Pushed by mqualmann into branch 'master'. use the date with the highest priority in the end result FIXED-IN: 7.0.0 M +2 -1 NEWS M +6 -12 core/libs/metadataengine/engine/metaengine_item.cpp https://invent.kde.org/kde/digikam/commit/5d8b8cf2f862ebd52259dc2355fac6f7c24a3083
Maik, Thanks for that fix. You are right, the camera (or further handling) has introduced two unmatching dates. If date conflicts arise which are difficult to resolve, I wonder if it helps to give the user a choice about dates. As you said, making decision on the "correct" date is challenging, let the user do so. I have no idea why in my files a 2002 date appears, it was taken 2016. This is a challenge of dealing with images that come from hardware that is long gone. Thanks again and keep healthy, Martin On Mon, 2020-03-30 at 11:19 +0000, Maik Qualmann wrote: > https://bugs.kde.org/show_bug.cgi?id=419409 > > Maik Qualmann <metzpinguin@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |metzpinguin@gmail.com > > --- Comment #1 from Maik Qualmann <metzpinguin@gmail.com> --- > Ok, since the original does not appear again in the image except for the GPS > date (which we are not testing), it fails in the final test because we do not > consider the priority in the final test. I will fix it. Yes, determining the > correct date is not easy. In principle, your camera has already made a mistake, > since digitization and original date are so different. > > Maik >
Since we have had this topic for a long time, I now have a lot of test images with date information. There are images where the users have already corrected the dates in the XMP field with other programs, but Exif is still wrong, etc. With a manual selection, it would only fit for a part of the images. No, digiKam must solve this itself as intelligently as possible. Maik
Got you :) makes sense At the risk of being annoying (sorry), how about looking possibly existing gps dates for judgement? Martin