Bug 136060 - Doesn't save existing comments when "save image comments as embedded text" has been activated
Summary: Doesn't save existing comments when "save image comments as embedded text" ha...
Alias: None
Product: digikam
Classification: Unclassified
Component: ImageEditor-Core (show other bugs)
Version: 0.9.0
Platform: Gentoo Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2006-10-20 23:31 UTC by Valerio Fuoglio
Modified: 2022-01-08 11:39 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0


Note You need to log in before you can comment on or make changes to this bug.
Description Valerio Fuoglio 2006-10-20 23:31:21 UTC
Version:           0.9.0-beta2 (using KDE KDE 3.5.5)
Installed from:    Gentoo Packages
Compiler:          gcc version 4.1.1 (Gentoo 4.1.1-r1) 
OS:                Linux

When I activate "save image comments as embedded text" (in digikam's configuration dialog), previous inserted comments should be saved into JPEG files. It isn't.

To save previous comments, you have to modify them, change image, then modify them again (coming back); repeat for each image.

To reproduce:
- Start digikam with "save image comments as ebedded text" not activated
- Insert new image
- Activate "save image comments as embedded text"
Comment 1 Marcel Wiesweg 2006-10-21 16:10:04 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.
Comment 2 Valerio Fuoglio 2006-10-21 16:34:58 UTC
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)
Comment 3 caulier.gilles 2006-10-21 20:59:35 UTC

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
Comment 4 caulier.gilles 2006-10-22 22:06:11 UTC

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 ***
Comment 5 Marcel Wiesweg 2006-10-26 22:16:22 UTC
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.
Comment 6 caulier.gilles 2022-01-08 11:39:28 UTC
Fixed with https://bugs.kde.org/show_bug.cgi?id=130017