Bug 409038 - erroneous extraction of date metadata for videos
Summary: erroneous extraction of date metadata for videos
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Date (show other bugs)
Version: 6.1.0
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-22 14:02 UTC by Kusi
Modified: 2019-06-22 19:08 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.2.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kusi 2019-06-22 14:02:02 UTC
Extracting the video date does not work correctly for an iPhone. The problem is the interpretation of the timezone: 

            exif tag:| "Create Date"   | "Creation Date"                   
---------------------|-----------------|---------
Panasonic Lumix GH4: | local timezone  | N/A
iPhone5 SE           | UTC             | local timezone

Apparently, Digikam interpretes the exif "Create Date", which is correct for Panasonic, but not for my iPhone, see image digikam-rename.png. My local timezone is UTC+2.

Images are available here: https://drive.google.com/drive/folders/1yHVOhvZMNWn2hGXgVPwoU0_841izpkPu

Unfortunately, there is no good solution to the problem since often the timezone is not reflected in the metadata. With DK 6.1, it is still not possible to use the correct video timestamp from within DK, but only via exiftool.

Maybe a user-configurable database which maps the correct exif field to the date used in DK based on the used video hardware? How do other tools handle the problem?

Literature: https://sno.phy.queensu.ca/~phil/exiftool/TagNames/QuickTime.html

PS: for photos taken with iPhone, the "Create Date" or "Date/Time Original" seems to be the local time zone. This issue only appears with videos
Comment 1 caulier.gilles 2019-06-22 14:19:25 UTC
if Iphone photo and video do not use the same date zone on the same device, it's clearly an Apple bug (:=)))...

And of course, you cannot report this problem to the big Apple.


Gilles Caulier
Comment 2 Maik Qualmann 2019-06-22 14:31:57 UTC
Exiftool also finds 09:09:41 as the creation date. There is an additional entry in the video called "com.apple.quicktime.creationdate", which has the timezone addition. We can add this as a special case.

Maik
Comment 3 Kusi 2019-06-22 14:58:01 UTC
(In reply to Maik Qualmann from comment #2)
> Exiftool also finds 09:09:41 as the creation date. There is an additional
> entry in the video called "com.apple.quicktime.creationdate", which has the
> timezone addition. We can add this as a special case.
> 
> Maik

That would be great! How did you check the special tag "com....creationdate"?

For reference:

Create Date in UTC, Creation Date in local time zone
$ exiftool IMG_9360-iPhone.MOV | grep Creat
Create Date                     : 2019:06:22 09:09:41
Creation Date                   : 2019:06:22 11:09:41+02:00

Create Date and Creation Date in local time zone
$ exiftool -api QuickTimeUTC IMG_9360-iPhone.MOV | grep Creat
Create Date                     : 2019:06:22 11:09:41+02:00
Creation Date                   : 2019:06:22 11:09:41+02:00

Source: https://askubuntu.com/questions/989646/exif-tool-and-video-files-which-are-saved-with-utc-timestamps
Comment 4 Kusi 2019-06-22 14:59:03 UTC
(In reply to caulier.gilles from comment #1)
> if Iphone photo and video do not use the same date zone on the same device,
> it's clearly an Apple bug (:=)))...
> 
> And of course, you cannot report this problem to the big Apple.
> 
> 
> Gilles Caulier

yeah, thanks Apple! :/
Comment 5 Maik Qualmann 2019-06-22 15:44:34 UTC
Git commit f172937814e3524bfcde25d19c4e1350c0c1ba4d by Maik Qualmann.
Committed on 22/06/2019 at 15:42.
Pushed by mqualmann into branch 'master'.

prefer "com.apple.quicktime.creationdate" for video date
Related: bug 405589
FIXED-IN: 6.2.0

M  +2    -1    NEWS
M  +26   -17   core/libs/metadataengine/dmetadata/dmetadata_video.cpp

https://invent.kde.org/kde/digikam/commit/f172937814e3524bfcde25d19c4e1350c0c1ba4d
Comment 6 Kusi 2019-06-22 19:08:05 UTC
Fixing the issue 1h42 after reporting, that's a fantastic job! Thanks alot Maik!