Bug 141014 - Time and dates in digikam
Summary: Time and dates in digikam
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Date (show other bugs)
Version: 0.9.0
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-01 18:13 UTC by Moritz
Modified: 2017-08-12 06:40 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.3.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz 2007-02-01 18:13:47 UTC
Version:           0.9 (using KDE KDE 3.5.5)
Installed from:    Unlisted Binary Package
OS:                Linux

I've noticed, that digikam uses (in the dates tab) the creation time and date of the image file. IMHO, the EXIF "date and time original" should be used as the only time and date in a program like digikam.

I've found "save image time stamp as tags", but I guess that's the other way around (saving file info to exiv)

Is there a reason why digikam prefers file info instead of exiv info? Images without a exiv date should be listed in an extra list entry.
i.e.
My Dates
- unknown
- 1998
-- January
- 1999
-- March
...

And the metadata setting "Save image time stamp as tags" should also say, that the original exiv date may be lost...

Regards,
Moritz
Comment 1 Thomas McGuire 2007-02-14 20:57:38 UTC
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?
Comment 2 Simon Oosthoek 2008-01-13 16:52:46 UTC
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
Comment 3 Arnd Baecker 2008-03-17 22:34:13 UTC
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?
Comment 4 Simon Oosthoek 2008-03-18 09:22:47 UTC
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
Comment 5 Arnd Baecker 2008-03-18 09:51:19 UTC
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?
Comment 6 Simon Oosthoek 2008-03-18 10:16:33 UTC
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
Comment 7 caulier.gilles 2009-07-20 11:06:20 UTC
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
Comment 8 caulier.gilles 2011-12-17 09:54:51 UTC
Moritz,

We need feedback using digiKam 2.x...

Gilles Caulier
Comment 9 julien.t43+kde 2012-06-17 17:12:51 UTC
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)
Comment 10 caulier.gilles 2013-11-21 22:41:57 UTC
What's about this entry using digiKam 3.x serie ? It still valid ?

Gilles Caulier
Comment 11 caulier.gilles 2014-08-28 15:40:40 UTC
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