https://bugs.kde.org/show_bug.cgi?id=340211
--- Comment #8 from Johannes Zarl-Zierl <johan...@zarl.at> --- On Monday 18 January 2016 20:46:02 you wrote: > * invalidate GPS ... > -- "KPhotoAlbum has no way of changing the gps info..." - why not? Mostly because someone would have to write it. Apart from that, there are already good tools to change the gps info. One is the KIPI plugin that you mentioned. > There is > a KIPI plugin to do just that. And - I just checked - the data gets > written into the exif fields. ...which is why KPA does update the GPS data from the exif data. > -- "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. I guess I should not have written the GPS information as its own point. GPS data (in its current implementation) is stored in the exif DB just like other exif fields there. > Updating this when the checksum differs is ok too. So we are in accordance here. > * 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?). There's still the matter of digitized images - many film and flatbed scanners do embed Exif information in the image. > 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.." In that case, reading the creation date again won't hurt. > - 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. We already have a 5th date (actually, a date range) in the index.xml (not in the exif db). Whether we update the date information or not does not increase the complexity. The bigger issue here (from my implementor's point of view) is whether the "if it has not been changed internally" increases complexity in the matter. > - 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". Making the date readonly for images with exif info is a nice idea. > - 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. The other big advantage of KPA dates is that they can be date ranges. A feature that plainly cannot be mapped into existing exif/xmp/iptc fields. > - "falling back on the file modification time" - I do not like this one at > all. For the record, I *did* write "*prevent* falling back on the file modification time". > The KIPI plugin should be able to write exif tags from the internal > date/time values (I am going to try this now). Yes, it can do that (with date ranges being "flattened" to a single date). > 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. Great;-) Cheers, Johannes -- You are receiving this mail because: You are watching all bug changes.
