| Summary: | Doesn't save existing comments when "save image comments as embedded text" has been activated | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Valerio Fuoglio <valerio.fuoglio> |
| Component: | ImageEditor-Core | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version: | 0.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 7.5.0 | |
|
Description
Valerio Fuoglio
2006-10-20 23:31:21 UTC
Not sure if you describe a bug or the currently expected behavior. The comment is written to the image metadata when it was changed and only if the option is activated. So the option only describes what is done in the future. If the option is not activated, the comment is only stored in the database. Storing previous comments would require to go through all images in the collection and change the metadata - for various reasons we cannot do this automatically after each option change! I am not sure if Gilles' MetadataEdit plugin is capable to do this. If the option should describes what is done in the future, does its job very well. If previous comments can't be copied from database to JPEG files (too much overhead?), this bug doesn't exist. Thanks for the explanation, slideshow plugin will inherit this behavior (https://bugs.kde.org/show_bug.cgi?id=106133) Valerio, The digiKam option from setup work only with image when you enter a new comment from the sidebar tab. old pictures previously annoted will not be scanned to insert comments in JPEG section, Exif UserCOmments tag, and IPTC Caption. This job is dedicaced to a future batch tool to sync pictures metadata with digiKam database. Marcel, this job is not completed by the new MetadataEdit kipi plugin... In fact my vision to later digiKam 0.9.0 release is to add a new batch tool (ruuning like the current "Rebuild all Thumbnails" tool). Not only Exif/IPTC comments will be sync with digiKam comments from database, but digiKam rating with IPTC urgency tag, digiKam date with Exif/Iptc dates tags, and digiKam tags with IPTC keywords. Let's me hear your constructive remarks about this solution. Gilles Caulier Valerio, Your report is similar than B.K.O file #130017. I set as duplicate. Gilles Caulier *** This bug has been marked as a duplicate of 130017 *** Some thoughts from me: We will need tools for both ways: digikam db -> image metadata, and image metadata -> digikam db. It's relatively easy to add a manual option for both. There can be a dialog to provide fine grained control which data shall be sync'ed. In the backend, we can put the code to libs/ and share it for all places where it's used (imagedescedittab, albumiconview etc.) to address bug 127583. In the UI, it can be accessible from the menu as a batch job, and from the imagedescedittab for the current selection. I am not sure if we can call it "metadata synchronization" and offer to set the syncing direction in a dialog, or if we should only offer the db->metadata direction in the UI and do the metadata->db direction only under the hood. But doing this automatically, based on modification dates in Scanlib, is much more difficult. The same applies to the problem to sync with kipi changes: Can we assume that the user always wants to sync everything from image metadata? Or only if he set in the option to _write_ it to the image? In either case it would be easy to trigger the sync from the refreshImage method, but more difficult from Scanlib - for this we'd need to store modification dates. Fixed with https://bugs.kde.org/show_bug.cgi?id=130017 |