| Summary: | erroneous extraction of date metadata for videos | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Kusi <kusi> |
| Component: | Metadata-Date | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 6.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/kde/digikam/commit/f172937814e3524bfcde25d19c4e1350c0c1ba4d | Version Fixed In: | 6.2.0 |
| Sentry Crash Report: | |||
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 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 (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 (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! :/ 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 Fixing the issue 1h42 after reporting, that's a fantastic job! Thanks alot Maik! |
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