Bug 386959

Summary: Properties view: wrong creation date [patch]
Product: [Applications] digikam Reporter: Jan Wolter <online>
Component: Albums-IconViewAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: b-misc, caulier.gilles, metzpinguin
Priority: NOR    
Version: 5.8.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 6.0.0
Sentry Crash Report:
Attachments: Wrong creation date with dk 5.6
Correct creation date with dk 4.14
xmp files of the image from the screenshot
xmpdatetime.patch
datetime.patch

Description Jan Wolter 2017-11-15 19:54:24 UTC
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".
Comment 1 Jan Wolter 2017-11-15 19:54:51 UTC
Created attachment 108885 [details]
Correct creation date with dk 4.14
Comment 2 Jan Wolter 2017-11-15 19:59:26 UTC
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 3 Jan Wolter 2017-11-15 20:00:30 UTC
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
Comment 4 Maik Qualmann 2017-11-15 20:34:27 UTC
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
Comment 5 Maik Qualmann 2017-11-16 07:01:16 UTC
Strange, I still see "Xmp.photoshop.DateCreated" is used here.

Maik
Comment 6 caulier.gilles 2017-11-16 10:34:02 UTC
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
Comment 7 Maik Qualmann 2017-11-16 11:16:59 UTC
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
Comment 8 Maik Qualmann 2017-11-16 11:32:35 UTC
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
Comment 9 Maik Qualmann 2017-11-16 12:48:35 UTC
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
Comment 10 caulier.gilles 2017-11-16 13:33:24 UTC
No, you cannot. XMP sidecar also include Exif tags as CC.

Gilles
Comment 11 Maik Qualmann 2017-11-16 19:10:08 UTC
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
Comment 12 caulier.gilles 2018-03-06 21:13:43 UTC
>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
Comment 13 Maik Qualmann 2018-03-06 21:40:42 UTC
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
Comment 14 caulier.gilles 2018-03-06 21:49:45 UTC
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
Comment 15 mau 2018-04-23 07:37:24 UTC
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
Comment 16 Maik Qualmann 2018-04-23 10:59:14 UTC
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
Comment 17 Maik Qualmann 2018-04-23 20:03:38 UTC
Created attachment 112203 [details]
datetime.patch

This patch fixes the date problem with a ranking of the date entries found in the metadata.

Maik
Comment 18 Maik Qualmann 2018-05-05 15:36:34 UTC
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