In case of a photo, adding for example 1 sec from Exif:created to Exif:original, Exif:created, Exif:digitized, Exif:Thumbnail, XMP, XMP:Video and IPTC:created (all these fields set into the Timestamp updated sub-panel) updates actually all these fields. But in case of a video, the same operation misses 2 date fields into Basic Schema (one of three is updated), the date field into Adobe photoshop, the date field into Exif-specific properties and the date field into XMP Extended Video. On the other hand, the date field into Dynamic media and Tiff properties are actually updated.
Metadata in video files is generally very special. Windows Explorer, for example, writes metadata to a QuickTime container, which we cannot change at the moment. We already have a bug report for this. Our metadata display in XMP is more "virtual", it contains metadata that may not even be present in the video. We do this to display audio/video stream information, for example. Please provide a video that contains date metadata that you think digiKam is not updating. Maik
Created attachment 167918 [details] video untouched from a moto g6
Created attachment 167919 [details] video adjusted by digikam (adding 1 sec from Exif:created to all dates fields)
Created attachment 167920 [details] output of exiftool about the untouched video
Created attachment 167921 [details] output of exiftool about the adjusted video Please note that some fields have been added by Digikam such as xmp fields, which it is normal, but some "native" fields have been removed, which it does seem normal (check with a diff tool).
Anyway, this report was about the difference of behavior about the updated (or not) date fields between photo and video, NO MATTER these fields are written to the file or not.
Git commit a8ec0c7e9285cab9d520cdc28bde6c6596c7d2de by Maik Qualmann. Committed on 29/03/2024 at 18:05. Pushed by mqualmann into branch 'master'. add missing "Xmp.exif.DateTimeDigitized" to date time adjust M +1 -0 core/libs/timeadjust/timeadjustcontainer.cpp https://invent.kde.org/graphics/digikam/-/commit/a8ec0c7e9285cab9d520cdc28bde6c6596c7d2de
> Please note that some fields have been added by Digikam such as xmp fields, which it is normal, but some "native" fields have been removed, which it does seem normal (check with a diff tool). In fact, none fields are removed from the adjusted file. This (false) problem seems to come from exiftool. I made the same command for both files : exiftool -G1 -api QuickTimeUTC <file> but these "missing" fields are not displayed on the adjusted file except if i add the exiftool -a option (which is not needed for the untouched file). It is a little bit strange but it is not a digikam problem.
I am now closing this bug, with the new option to update all existing timestamps with ExifTool, all timestamps can be synchronized in the video uploaded here as a sample. Maik
Git commit d5d2f8639ff3d906f1af212546ca8c78a100755a by Maik Qualmann. Committed on 02/04/2024 at 17:08. Pushed by mqualmann into branch 'master'. fix updating file timestamp with ExifTool enabled M +2 -1 core/dplugins/bqm/metadata/timeadjust/timeadjust.cpp M +84 -90 core/dplugins/generic/metadata/timeadjust/timeadjusttask.cpp https://invent.kde.org/graphics/digikam/-/commit/d5d2f8639ff3d906f1af212546ca8c78a100755a
1) With Exiftool enabled, Digikam:CaptionDateTimestamp is also adjusted, it should not. 2) With the fix, Digikam don't display any more a source selecting EXIF/IPTC/XMP (it displays "not valid"). In fact, that seems logical since the only available date comes from another schema (i.e. QuickTime). But the new way to get a source is selecting DigikamTimestamp which is not very intuitive. DigikamTimestamp seems created with a fuzzy logic from EXIF/IPTC/XMP and QuickTime (and may be others fields in the file), so why notl to remove either DigikamTimestamp choice or EXIF/IPTC/XMP choice ? They are partially redondant, it is confusing.
3) There a third point impacted by the fix. let say a video file with QuickTimeCreateDate : 2024:04:04T10:00:00. As we know it is presumed to be an UTC time (except for some devices according an internal Digikam list). Today my PC is UTC+2 (CET + DST). Renaming the file with [date:yyyy-MM-dd_hh'h'mm-ss] give me the filename 2024-04-04_12h00-00.mp4. If I do an adjustment of +00:00:01 (1 sec) with exiftool enabled, all dates are modified, including QuickTimeCreateDate which become 2024:04:04T10:00:01. Then I try to renaming the file and I expect to get a filename 2024-04-04_12h00-01.mp4. But I get 2024:04:04T10:00:01. It seems that QuickTimeCreateDate is no more considerate as an UTC time.
Git commit 242b062fe2bc6fd6aa704d792ec823d3e74a6321 by Maik Qualmann. Committed on 04/04/2024 at 16:41. Pushed by mqualmann into branch 'master'. read all video metadata to get time adjust source timestamps M +1 -1 core/dplugins/generic/metadata/timeadjust/timeadjustthread.cpp https://invent.kde.org/graphics/digikam/-/commit/242b062fe2bc6fd6aa704d792ec823d3e74a6321
Git commit 240db23403a6ba44d8be6b74e927e98425ac1e5b by Maik Qualmann. Committed on 04/04/2024 at 17:51. Pushed by mqualmann into branch 'master'. restore an existing caption timestamp M +4 -0 core/libs/metadataengine/exiftool/exiftoolparser_command.cpp https://invent.kde.org/graphics/digikam/-/commit/240db23403a6ba44d8be6b74e927e98425ac1e5b
Git commit c05646ba479f934e6fb9d09f273324e3c73d979e by Maik Qualmann. Committed on 04/04/2024 at 19:05. Pushed by mqualmann into branch 'master'. fix time shifting with QuickTime UTC M +5 -2 core/libs/metadataengine/dmetadata/dmetadata_exiftool.cpp M +9 -3 core/libs/metadataengine/dmetadata/dmetadata_video.cpp M +2 -0 core/libs/metadataengine/exiftool/exiftoolparser_command.cpp https://invent.kde.org/graphics/digikam/-/commit/c05646ba479f934e6fb9d09f273324e3c73d979e
I need to know if your Ricoh camera actually writes a QuickTime timestamp in local time because it sets the "Z" flag (even if ExifTool doesn't show it). Please film a clock and send me the video without further editing. Maik
Created attachment 168156 [details] a clock (local time : UTC+2) with Ricoh GR II
Thanks, really local time with UTC identifier. Currently it works fine when QuickTime is actually UTC. I have to think about how we can switch UTC on/off when writing in ExifTool, depending on the camera device. Maik
After to decide that a QuickTime date of a given video is UTC (which is not easy, I agree), Digikam uses the local time of the PC to calculate the "local" time of the video. This "local" time is incorrect if the video was been taken in a foreign country (with a time zone different from that of the PC). This incorrect "local" time impacts 1) the sorting by date 2) the renaming with format such as [date:yyyy-MM-dd_hh'h'mm-ss]. The more logical way for the user to manage this "travel" use case is the following : When he come back to his country, he adjusts the dates of his travel videos he know they have a true UTC QuickTime date (i.e. from smartphones) in order to set them to the right local time (offset = QTdate - timezone&dst of the foreign country). But this way, he cannot rename these videos with a format such as [date:yyyy-MM-dd_hh'h'mm-ss] because Digikam is not aware the date are local time now. So I workaround the problem adjusting the date of these videos with an offset = TZ of the foreign country – TZ of my PC. This way I can then to rename the videos with a format [date:yyyy-MM-dd_hh'h'mm-ss]. Sorting by name (not by date !) allow me to displays the photos and videos of a travel with the right chronology. I think the best solution is the first one (adjust to local time) and add an option to the rename function to notify Digikam not to adjust Timestamp Updated with the local time of the PC. This way I can also sort/search by date consistently within a travel sequence.
Git commit 9f313750fe03c2b5e7f6b575d4497a919f1a843b by Maik Qualmann. Committed on 05/04/2024 at 05:59. Pushed by mqualmann into branch 'master'. add detection for QuickTime UTC timestamp M +12 -0 core/dplugins/generic/metadata/timeadjust/timeadjusttask.cpp M +1 -0 core/libs/metadataengine/dmetadata/dmetadata_video.cpp M +7 -2 core/libs/metadataengine/exiftool/exiftoolparser_command.cpp https://invent.kde.org/graphics/digikam/-/commit/9f313750fe03c2b5e7f6b575d4497a919f1a843b
I confirm that points 1, 2 and 3 (see comment 11) are fixed. Thanks. I think I will create a wish report related to my comment 19 but I have to think a little bit more about this use case.