https://bugs.kde.org/show_bug.cgi?id=340211
--- Comment #6 from Andreas Schleth <schleth...@web.de> --- OK, I was too quick reading: Your intent is a modification of the exif-db and .NOT. the index.xml-db (?). So, most of my reservations are gone. I think, I intuitively understood the "cache" nature of this db, as the real exif info is always inside the image files, even if the exif db is corrupt (as after using the same index with two different revisions of KPA). So, I think the exif-db should keep it's status "disposable". * invalidate GPS ... -- "KPhotoAlbum has no way of changing the gps info..." - why not? There is a KIPI plugin to do just that. And - I just checked - the data gets written into the exif fields. -- "If the GPS information is changed outside KPA ... KPA should in my opinion always use the updated information." - Yes, eventually. It does not break things if the correction comes in e.g. when the image is viewed in the slide show (then it is opened in anyhow). And you could add "read geo tags" to the "Read Exif Info from Files" entry in the maintenance menu. Updating this when the checksum differs is ok too. * invalidate the Thumbnail ... "... this should IMO be reflected in the thumbnail." - Yes, eventually. When a different checksum is detected or when the image is viewed in the slide show would be good moments to rebuild this thumbnail. * the image date ... - "if it has not been changed internally" - Being able to change the image date in the DB *only* is IMHO only useful for images without any exif-info at all (bmp?). In all other cases, image date in the DB and in the exif-info of the image should be the same. (Always in my case). That is why we have "Read Exif Info from Files.." - As noted in the link above, there are already 3 dates in the exif-info (+ the file system date(s)). So, the situation is confusing enough even without a 5th date in the KPA index.xml. - I jumped through all the hoops as well: the KIPI plugin for adjusting the camera dates of different people, writing dates into images scans with exiftool (10000 slides). I even went so far to adjust the file creation date for these scans (which, unfortunately, only goes back until 1970). But then I read all the dates from exif into KPA. - I would go so far, as to say, the image date in KPA should be "display only", if exif info is available. Alternatively it could be displayed as "real date". - I guess, the feature of providing a date field that does not write back into exif originated from Jesper's mantra "KimDaBa leaves all image files untouched" and - in the early times of KimDaBa - the ability of dealing with read-only media (cd-rom). This approach has it's merits - until you want to change the date for real. - "Automatically updating the time *should* not be a problem for you when you modify images" - Yes. I never had a problem with that. Even stitched panoramas from hugin retain the original creation date of the first image. I do no know about Windoze-tools, though. - "falling back on the file modification time" - I do not like this one at all. File modification dates sometimes survive move/copy/rsync operations, sometimes not. If you need it, it has gone wrong and all files have the date/time from when you copied them back from backup. I would prefer to leave the date/time field empty (or at the manually entered value in the index.xml). The KIPI plugin should be able to write exif tags from the internal date/time values (I am going to try this now). * image dimensions: Yes. Summary: except for the tricky date/time issue - invalidate and rebuild the exif-DB/thumbnail as proposed. "Does this make sense to you now...?" - Yes it does. Thanks for your patience with the superficial reader. -- You are receiving this mail because: You are watching all bug changes.
