Bug 141014

I am fine with this behavior, since most of my EXIF tags are totally wrong because of a broken camera, and I've manually corrected the file creation date, which seems to be used in digikam.

I understand that using the EXIF tag is technically more sane, but if you change this, please include a new tool like "Image->Correct Exif Date Tag" which sets the EXIF date/time tags to the file creation date/time. 

BTW, what triggers the "save image time stamp as tags" action? What I want to ask is at what time are the tags written, in response to what action?

I'm not quite sure I understand the bugreport, but I have a similar enough issue to reuse this one...

Obviously, some files have correct filedates and or exif date info. However it seems that digikam has another date stored for each image in the metadata. This date overrules the other two it seems, but I doubt that is desirable in all cases. Given that it exists, it was probably intended that way, but I would then suggest that the UI gets a way of removing this tag for the selected group of images, so the metadata used becomes the exif or file date.

It certainly isn't clear from the dates view that this date is the one used for the sorting. Perhaps an additional fix would be to indicate somewhere which date is used to determine the order that is shown...

Cheers

Simon

The relevant code is in QDateTime KExiv2::getImageDateTime(),
http://websvn.kde.org/branches/extragear/kde3/libs/libkexiv2/libkexiv2/kexiv2.cpp?view=markup
where 
  Exif.Photo.DateTimeOriginal 
is the first one which digiKam tries to get. If this
does not exist, Exif.Photo.DateTimeDigitized is used, etc.

Looking at http://www.exiv2.org/tags.html we have
Exif.Photo.DateTimeOriginal 
  The date and time when the original image data was generated. 
  For a digital still camera the date and time the picture was 
  taken are recorded.
Exif.Photo.DateTimeDigitized  
  The date and time when the image was stored as digital data.
Exif.Image.DateTime 	
  The date and time of image creation. 
  In Exif standard, it is the date and time the file was changed.


So as a test-case, consider an image `image_time.jpg`and set its times via:
exiv2 -M"set Exif.Image.DateTime Ascii 2008:03:03 03:00:00" image_time.jpg
exiv2 -M"set Exif.Photo.DateTimeOriginal Ascii 2008:02:02 02:00:00" \
image_time.jpg
exiv2 -M"set Exif.Photo.DateTimeDigitized Ascii 2008:01:01 01:00:00" \ 
image_time.jpg

which leads to:
  exiv2 -pt image_time.jpg | grep Date
  ls -l image_time.jpg
 
  Exif.Image.DateTime                Ascii      20  2008:03:03 03:00:00
  Exif.Photo.DateTimeOriginal        Ascii      20  2008:02:02 02:00:00
  Exif.Photo.DateTimeDigitized       Ascii      20  2008:01:01 01:00:00
  2008-03-17 22:25 image_time.jpg

This then shows inside of digikam
  created: 02/02/2008 02:00
  modified: 17/03/2008 22:25
and all displays are based on Exif.Photo.DateTimeOriginal.

So are there any remaining problems?

Unfortunately I don't have a specific test case, so I don't quite recall my specific issue (serves me right for not putting a test case in the comment ;-)

I think that my issue was that once a date is set in the Captions/Tags panel (based on file info or exif), this is then stored in the database and overrules the exif info in the file. If there's a conflict between these dates, it should be highlighted to the user!

Just to be clear, I am talking about the date shown in the Captions/Tags panel on the right, not the metadata panel.

Cheers

Simon

Changes to the file are only written, when 
- Update EXIF creation date
- Update IPTC creation date
are marked. 

Note that there was a bug in the time-adjust plugin, which was 
fixed two days ago,
http://bugs.kde.org/show_bug.cgi?id=149890
and at the same time a bug setting the time with the captions/Tags panel
was fixed.

So, should always a warning be shown, whenever one changes the date of an image, but the settings are such that the date is not written to the file?
Would this solve this issue?

I would say yes, a warning should always be shown, and more specifically when the date tag is not the same as the exif creation date. This would not always be wrong, but should be easier to notice for the user.

Cheers

Simon

Please, let's me hear if current implementation of digiKam from svn trunk (1.0.0-beta3) fix your original problem with date management.

Gilles Caulier

Moritz,

We need feedback using digiKam 2.x...

Gilles Caulier

Just a report on a very specific case as a long traveller. I had a few problem with time in digikam when crossing change date line between New Zealand and French Polynesia (-1d).
Maybe a tools option to force change date to a defined place (local, GMT, ...) else you finish with a mixing of images with time right but not in their real creation order.

for example, took images in place 1 in NZ, in place 2 (plane), in place 3 in PL, change time to local (-1d), in place 4 in PL
result: digikam mixed all images are all their local times mix themselves.
In this very specific case, it should be possible to align all of them to a unique reference (time GMT)

What's about this entry using digiKam 3.x serie ? It still valid ?

Gilles Caulier

A settings rule to route right date tags from file metadata to database is planed to do in bug #265880

Else, the original report ask to use EXIF "date and time original" as base date time stamp to register date info in database. It's already the case in current implementation from git/master :

https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2/repository/revisions/master/entry/libkexiv2/kexiv2image.cpp#L519

Gilles Caulier