https://bugs.kde.org/show_bug.cgi?id=518334
Bug ID: 518334
Summary: Use QuickTime CreationDate if Present Rather Than
CreateDate in MOV files
Classification: Applications
Product: digikam
Version First 9.0.0
Reported In:
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Metadata-Video
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
SUMMARY
I request that the QuickTime metadata field CreationDate be used if present
rather than QuickTime CreateDate in the digiKam the database for display and
sorting of MOV files.
BACKGROUND
I believe based on observation and a search of other bugzilla reports that
digiKam uses the QuickTime metadata field CreateDate when MOV files are
scanned. This field is UTC and contains no time zone info. I believe that
digiKam therefore applies a correction to the UTC time based on the current
time zone of the computer when the file is added to the database.
I believe that newer Apple devices including iPhones now prioritize the field
CreationDate over CreateDate. CreationDate includes time zone information. If
CreationDate is present, this would allow digiKam to treat MOV files the same
way as other image files that contain time zone information. If CreationDate
is not present, digiKam could default back to the way dates are currently being
handled using CreateDate.
This issue became apparent when downloading iPhone Live Photos to a PC and
scanning them in with digiKam. Live Photos consist of a still HEIC image and a
short 3-sec MOV video that are created at the same time. If the Live Photo was
taken in a different time zone than the digiKam computer is set to, the
creation times for the HEIC and MOV files are different and therefore will sort
out of order. Use of CreationDate would fix this I believe.
I am attaching the HEIC and MOV files from a sample Live Photo. The photo was
taken with the iPhone set to the Paris time zone, and was downloaded to a
computer set to New York. (The time displayed on the clock in the image is
Paris time - 4:26 pm or 16:26.) I also am attaching a screenshot of digiKam
after the file was scanned in. Currently, a correction must be applied to the
MOV date to allow them to be sorted together. If my suggestion is implemented,
digiKam would display Paris time for both files, since that was the local time
of the phone when the photo was taken.
Finally, I am attaching a screenshot of some info from an AI search regarding
this subject.
SOFTWARE/OS VERSIONS
digiKam 9.0.0 - Windows version
Windows 11
--
You are receiving this mail because:
You are watching all bug changes.
