When MD5 sums are recalculated, KPA currently does not invalidate any metadata except the image Thumbnail. DB::ImageInfo::setMD5Sum() is probably a good place to trigger the following things: - invalidate GPS information on the image - invalidate the Thumbnail (instead of doing this in the new image finder) - the image date, if it has not been changed internally - exif info in general (as well as the exifDB) - image dimensions
Has this one probably already been fixed via the GPS stuff implementation?
No. This has not yet been implemented.
I do not think, this is a completely good idea. I often do some minor repairs to images after tagging. I even have a tag: "Nacharbeit" = "repair something". So, I would not want my image data to change because of this. Updating the thumbnail would be very OK. Changing tags, time and such much less. I do not understand: why should the GPS-Info be changed? I guess it is a rare case that an image would be replaced by a completely different image from another location. In this case you could easily import the image as new and delete the old one.
Here's my rationale for each item on the above list: - invalidate GPS information on the image Many cameras don't have geotagging built in. Therefore people geotag their images on their pc, using external gps log files. KPhotoAlbum has no way of changing the gps info, and the exif search db where the information is stored is considered a cache only. If the GPS information is changed outside KPA (e.g. because someone geotags their images after import to KPA), KPA should in my opinion always use the updated information. - invalidate the Thumbnail (instead of doing this in the new image finder) If you do minor adjustments to your images (white-balance, cropping, etc.) this should IMO be reflected in the thumbnail. - the image date, if it has not been changed internally This is the one thing that I'm not entirely sure about, yet. Notice the 'if' part, though. I've added it to the list because I alter the image date/time sometimes after the import into KPA. That can happen either through the "Adjust time and date" KIPI plugin, or sometimes directly using the exiv2 or exiftool commandline utilities. The reason for doing this is when I'm merging images from multiple cameras, the internal clocks are not that accurate and therefore the images need adjusting. Automatically updating the time *should* not be a problem for you when you modify images - at least no tool that I know of alters the EXIF creation timestamp that is used by KPA when reading the file date. I guess it would make sense to prevent falling back on the file modification time when EXIF is not available, though. - exif info in general (as well as the exifDB) - image dimensions This is IMO a no-brainer: if the image was changed, the exif search database (which is intended as a cache only) should be updated to reflect the reality. Also, the image dimensions should always be kept up to date. Does this make sense to you now that I've explained myself? On the "changing tags" part: I don't think I understood you correctly, there. I have not written anything about changing tags - rest assured that I did not intend to go about changing any tags on the images. Regarding the date/time adjustment: I would very much appreciate your thoughts on my proposed changes.
Regarding Date/Time, it is always useful to refer to the MWG Guidelines on which date/time fields are used and when and if they should be updated. http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf#page=37
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.
The KIPI plugin can change all exif date/time values except "Date/Time Original". "Create Date" is among the values that are updated. Thus, "Create Date" should be the tag to read from the exif-info into the KPA index.xml - if needed.
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
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
AFAICS the report is still valid. Setting importance to minor...