Created attachment 108884 [details] Wrong creation date with dk 5.6 I mentioned that the creation date of nearly all my raw files are not displayed correctly in the photograph properties view: the date part is correct but the time part is fixed to "1:00 AM" or "2:00 AM" depending on winter or sommer time. For read-only files like raw files my digikam writes/reads all metadate to/from XMP sidecar files. Currently, I use digikam version 5.7.0 (AppImage). When I take a look in the *.xmp files, I see the following entries related to dates: exif:DateTimeDigitized="2014-07-29T11:22:08" exif:DateTimeOriginal="2014-07-29T11:22:08" tiff:DateTime="2014-07-29T11:22:08" xmp:CreateDate="2014-07-29T11:22:08" xmp:MetadataDate="2014-07-29T11:22:08" xmp:ModifyDate="2014-07-29T11:22:08" photoshop:DateCreated="2014-07-29" All date related attributes except "photoshop:DateCreated" saves the date including the time part. I noticed that this problem applies only to all raw files which XMP sidecar files was created by an older dk version (in my case dk 4.14.0). Sidecar files created by digikam 5.x writes "photoshop:DateCreated" including the time. But dk 5.x. is not able to show the creation date in the properties view correctly, when "photoshop:DateCreated" contains only the date. I would expect that dk use "xmp:CreateDate" instead of "photoshop:DateCreated".
Created attachment 108885 [details] Correct creation date with dk 4.14
Created attachment 108886 [details] xmp files of the image from the screenshot The xmp file was created 3 years ago with dk 4.x and the attribute "photoshop.DateCreated" does not contain the time part: $ exiv2 -pa --grep Date 2014-08-04T15-23-11_Australien.ORF.xmp Exif.Image.DateTime Ascii 20 2014:08:04 15:23:11 Exif.Photo.DateTimeOriginal Ascii 20 2014:08:04 02:00:00 Exif.Photo.DateTimeDigitized Ascii 20 2014:08:04 15:23:11 Iptc.Application2.DateCreated Date 8 2014-08-04 Iptc.Application2.DigitizationDate Date 8 2014-08-04 Xmp.exif.DateTimeDigitized XmpText 19 2014-08-04T15:23:11 Xmp.exif.DateTimeOriginal XmpText 19 2014:08:04 15:23:11 Xmp.photoshop.DateCreated XmpText 10 2014-08-04 Xmp.tiff.DateTime XmpText 19 2014-08-04T15:23:11 Xmp.xmp.CreateDate XmpText 19 2014-08-04T15:23:11 Xmp.xmp.MetadataDate XmpText 19 2014-08-04T15:23:11 Xmp.xmp.ModifyDate XmpText 19 2014-08-04T15:23:11
COMMENT FROM MAIL QUALMANN ON THE DIGIKAM-USERS LIST: Jan, here is the function. https://cgit.kde.org/digikam.git/tree/libs/dmetadata/metaengine_image.cpp#n534 Yes, if none of the many date/time sources are available, "Xmp.photoshop.DateCreated" will be queried before "Xmp.xmp.CreateDate". If "Xmp.photoshop.DateCreated" is so unreliable, I suggest giving it a lower priority. Maik
Git commit ff0fb215633010d563083c33e35d45b17d3484f0 by Maik Qualmann. Committed on 15/11/2017 at 20:32. Pushed by mqualmann into branch 'master'. use a low priority for Xmp.photoshop.DateCreated to get date/time from the image FIXED-IN: 5.8.0 M +2 -1 NEWS M +6 -6 libs/dmetadata/metaengine_image.cpp https://commits.kde.org/digikam/ff0fb215633010d563083c33e35d45b17d3484f0
Strange, I still see "Xmp.photoshop.DateCreated" is used here. Maik
Maik, The date metadata tags can be wrapped with settings from Setup/Metadata/Advanced control panel. The harcoded wrapping from MetaEngine is not used in this case... Gilles
Git commit 8604d96265828dad52de7c3706b2d168afb8deb7 by Maik Qualmann. Committed on 16/11/2017 at 11:16. Pushed by mqualmann into branch 'master'. Revert "use a low priority for Xmp.photoshop.DateCreated to get date/time from the image" M +1 -2 NEWS M +6 -6 libs/dmetadata/metaengine_image.cpp https://commits.kde.org/digikam/8604d96265828dad52de7c3706b2d168afb8deb7
If I understand this comment correctly, Exiv2 wrapped these tags. After my tests, this is exactly the case. https://cgit.kde.org/digikam.git/tree/libs/dmetadata/metaengine_p.cpp#n724 Exif.Photo.DateTimeOriginal == Xmp.photoshop.DateCreated Exif.Photo.DateTimeDigitized == Xmp.xmp.CreateDate If we try to read Exif.Photo.DateTimeOriginal, we get the value of Xmp.photoshop.DateCreated from the XMP sidcar file. Gilles, the date/time tags are not exist for wrapping in Setup/Metadata/Advanced. Maik
But I think the problem is easy to solve. If metadata was read from a sidecar, we ignore the Exif namespace for date/time. Maik
No, you cannot. XMP sidecar also include Exif tags as CC. Gilles
Created attachment 108902 [details] xmpdatetime.patch Here is the conversion table: http://www.exiv2.org/conversion.html Gilles, are you really sure that the Exif tags Exif.Photo.DateTimeOriginal or Exif.Photo.DateTimeDigitized exist in an XMP sidcar file? I think these are Xmp.exif.DateTimeOriginal and Xmp.exif.DateTimeDigitized. I once attached a patch to test and discuss. For me, the Exiv2 conversion is wrong, but maybe there is a standard for it? Maik
>Gilles, are you really sure that the Exif tags Exif.Photo.DateTimeOriginal or >Exif.Photo.DateTimeDigitized exist in an XMP sidcar file? Both tags exists in XMP definition of Exif namespace : https://github.com/Exiv2/exiv2/blob/master/src/properties.cpp#L813 https://github.com/Exiv2/exiv2/blob/master/src/properties.cpp#L816 There exists also for video namespace : https://github.com/Exiv2/exiv2/blob/master/src/properties.cpp#L1388 https://github.com/Exiv2/exiv2/blob/master/src/properties.cpp#L1389 Gilles
Yes, both entries exist: Xmp.exif.DateTimeOriginal Xmp.exif.DateTimeDigitized But I do not think that this entrys exists in a sidecar file: Exif.Photo.DateTimeOriginal Exif.Photo.DateTimeDigitized The problem is, we begins by looking for the date with the query from the EXIF name space. Through http://www.exiv2.org/conversion.html we get: Exif.Photo.DateTimeOriginal ==> Xmp.photoshop.DateCreated Exif.Photo.DateTimeDigitized ==> Xmp.xmp.CreateDate I think it would be correct: Exif.Photo.DateTimeOriginal ==> Xmp.exif.DateTimeOriginal Exif.Photo.DateTimeDigitized ==> Xmp.exif.DateTimeDigitized Or am I completely wrong? Maik
yes it sound logic. If the Exif to XMP conversion is suspect, i recommend to report this problem to Exiv2 team. At least they lust said if we have really a problem here ... Gilles
Hmm, for me it looks like we have two different problems here: First one is the mapping: The Metadata Working Group (MWG) [1] recommends for Tag Name "CreateDate" Composite:SubSecCreateDate EXIF:CreateDate IPTC:DigitalCreationDate IPTC:DigitalCreationTime XMP-xmp:CreateDate CurrentIPTCDigest IPTCDigest which is the "creation date of the digital representation" (MWG), and for Tag Name "DateTimeOriginal" Composite:SubSecDateTimeOriginal EXIF:DateTimeOriginal IPTC:DateCreated IPTC:TimeCreated XMP-photoshop:DateCreated CurrentIPTCDigest IPTCDigest which is the "creation date of the intellectual content being shown" (MWG). So apparently a photoshop-named tag should be used for DateTime information - at least as a fallback if no other field contains the DateTime information. Second problem is: Resolution (time information included or not). Since there seem to be cases when Xmp.photoshop.DateCreated does only contain the date and not the time (and that could at least theoretically be the case for all DateTime fields), I'd propose to prefer fields wich contain both date and time over fields which contain only the date part. So I'd use two priority rankings: First go through all DateTime fields in the defined order, if a valid value for Date and Time is found -> use that and exit. If no entry is found, go through all DateTime fields again, in the same order, and accept the first date value (withouth time) -> use that and exit. Another way of handling all the different fields would be to group them (just as MWG does) and check for and report any inconsistencies found (like different dates / times or different resolution (missing time)). That would allow to correct them, but the resulting question would be which cases of inconsistent information could be corrected silently and which cases would require human / user intervention. [1] https://sno.phy.queensu.ca/~phil/exiftool/TagNames/MWG.html
The idea is good to introduce a ranking and could solve the problem. We read all dates from the image, most of the same win before dates without time part. I will create a patch this evening. Maik
Created attachment 112203 [details] datetime.patch This patch fixes the date problem with a ranking of the date entries found in the metadata. Maik
Git commit 0e8da899d20a4549e41cffd83a488c85fa7ad85f by Maik Qualmann. Committed on 05/05/2018 at 15:35. Pushed by mqualmann into branch 'master'. check if a date exists more than once and use it FIXED-IN: 6.0.0 M +2 -1 NEWS M +113 -30 core/libs/dmetadata/metaengine_image.cpp https://commits.kde.org/digikam/0e8da899d20a4549e41cffd83a488c85fa7ad85f