Project

General

Profile

Bug #9899

timestamp being ignored when importing new directory with pictures and XMPs

Added by P B over 5 years ago. Updated over 5 years ago.

Status:
Triaged
Priority:
Low
Assignee:
-
Category:
General
Target version:
-
Start date:
04/12/2014
Due date:
% Done:

20%

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

Description

How to reproduce:
  • Have some pictures in a directory
  • fix their timestamp using darktable
  • make changes to the images like you are used to do (contrast, basecurve etc.)
    now
  • create a new directory
  • move/copy the images from above and their sidecars to the new directory
  • import the new directory to DT
    Result:
    all changes made in the first directory show up - except the corrected timestamp of the image

Tested with version 1.5+707~g7a63851

History

#1 Updated by Tobias Ellinghaus over 5 years ago

  • System changed from other GNU/Linux to all
  • % Done changed from 0 to 50
  • Target version set to Candidate for next minor release
  • Priority changed from Medium to Low
  • Assignee set to Tobias Ellinghaus
  • Status changed from New to In Progress

We have to write the exif_datetime_taken field into the XMP files (XMP.xmp.CreateDate sounds like a good place) and read it back when loading.

#2 Updated by Tobias Ellinghaus over 5 years ago

  • % Done changed from 50 to 20
  • Target version deleted (Candidate for next minor release)
  • Assignee deleted (Tobias Ellinghaus)
  • Status changed from In Progress to Triaged

Thinking about it a little more reveals a serious issue with writing the timestamp to the XMP file: applying the sidecar of another image will set the timestamp to that image's. Which is bad™.

Does anyone have an idea how to handle this situation?

#3 Updated by P B over 5 years ago

Tobias Ellinghaus wrote:

Does anyone have an idea how to handle this situation?

Could it work only to re-apply the exif_datetime_taken field if the image to apply it to would have an identical checksum like the picture where the xmp origins from?

#4 Updated by Tobias Ellinghaus over 5 years ago

We don't compute checksums (it's slow). Any more ideas? Anyone?

Also available in: Atom PDF

Go to top