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
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