Version: unspecified (using KDE 4.5.4) OS: Linux So far, album properties are stored in the database, thus they are lost if the album is saved on a CD, or can't be read if the album is browsed using another image viewer. Reproducible: Didn't try Expected Results: Prividing a way to export albums' properties to a human readable file into the folder would prevent losing these data (a simple album.txt file for example).
Another possible solution is to write album metadata to *each* file inside the album. I'm not aware of standard metadata fields for such info, but digikam-specific metadata can be used for this. Of course, users which don't need this feature should be able to opt-out of metadata synchronization to files. Pros: - all album metadata is available as long as any file from it is available - when file is sent somewhere album metadata travels with it - low-level metadata handling is already implemented. Moreover, with a little effort all album metadata can be treated as a special tag, so most of the code can be reused. Cons: - metadata duplication takes an additional space. Anybody cares about this? Seems to be negligible. - synchronization issues between file's metadata and digikam's one. This is quite similar to current tags DB<->files synchronization - digikam supports album hierarchy, so A/B/C/file.jpg would need to handle information about A, B & C - conflict detection and resolution: What should be done when a file is moved between albums outside digikam? Detection is the same as for any new files. Conflict can be solved by asking a user whether he wants to rewrite file's metadata or to move file (back) to appropriate album, probably creating the album if it's absent. - time overhead: 1. File's metadata conflict detection is needed for files added/changed outside digikam. File hash and/or mtime/ctime stored in a DB can considerably speed things up. 2. File's metadata update can be lengthy, when a lot of files updated. This is the only real drawback of this scheme, as I see it. Some background updater can be implemented to compensate for it, but this doesn't seem to be as trivial as just letting the user wait...
*** Bug 217735 has been marked as a duplicate of this bug. ***
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
I am not aware of a method to export album properties, except storing albu properties into image metadata. So I confirm this bug is still there.
Hi, We have a student working on this topic through a new plugin. Code is under development located in a separated branch : https://invent.kde.org/graphics/digikam/-/tree/database_export/core/dplugins/db/dbexport Gilles Caulier
Nice :)