Project

General

Profile

Feature #10569

datetime_taken is not stored in the XMP file

Added by Torsten Bronger over 3 years ago. Updated over 3 years ago.

Status:
Triaged
Priority:
Low
Assignee:
-
Category:
General
Target version:
Start date:
07/06/2015
Due date:
% Done:

20%

Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

If I apply a timestamp offset to an image with the Geotagging module, the new timestamp (or the offset) is not written to the XMP file. So, if I remove the image from the database and re-import it again, the offset is lost.


Related issues

Related to darktable - Feature #11257: Geotagging menu won't let you revert changes New 10/24/2016

History

#1 Updated by Roman Lebedev over 3 years ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10
  • System changed from Ubuntu to all
  • Category changed from Lighttable to General

#2 Updated by Roman Lebedev over 3 years ago

  • Subject changed from Timestamp offsets are not stored in the XMP file to datetime_taken is not stored in the XMP file
Steps:
  • import image, time original
  • change image time using time offset in geotagging module, time original+00:12
  • remove image
  • import it back => time == original, while it was expected would have expected it to stay original+00:12

That results in different values of Exif.Photo.DateTimeOriginal, Exif.Photo.DateTimeDigitized and Exif.Image.DateTimeOriginal for exported images.

#3 Updated by Roman Lebedev over 3 years ago

From https://github.com/darktable-org/darktable/blob/285e70f1c76de1f55ef186c5ad08c7a85f3e55f3/src/common/exif.cc#L1111

// For us "keeping" it means to write out what we have in DB to support people adding a time offset in the geotagging module.

#4 Updated by Roman Lebedev over 3 years ago

  • Status changed from Confirmed to Patch attached
  • % Done changed from 10 to 70

With that comment in mind (which for me screams that this is just an oversight), i have prepared and tested a fix:
https://github.com/LebedevRI/darktable/tree/store-datetime_taken-in-xmp

#5 Updated by Roman Lebedev over 3 years ago

  • Tracker changed from Bug to Feature
  • Status changed from Patch attached to Triaged
  • Target version set to Future
  • % Done changed from 70 to 20

[23:35:03] <houz> yes, but not today. i can tell you that i didn't add timestamps to xmp on purpose (and it's part of the things i have to think about before i can rewrite metadata code) since that makes it basically impossible to use an xmp file as a stored processign for many images. loading that file would overwrite its timestamp, too
[23:35:27] <houz> getting it right is hard, and the current state is the best that was easily doable

TL DR: yes, the fix is right, but it would break usecase of single XMP for multiple different(not duplicated) images, so until next big metadata handling overhaul, it will have to stay as it is.

#6 Updated by Roman Lebedev about 2 years ago

  • Related to Feature #11257: Geotagging menu won't let you revert changes added

Also available in: Atom PDF