| Summary: | MAINTENANCE : Export album properties for compatibility with simple image viewers and archiving | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Romain Henriet <romain.pub> |
| Component: | Maintenance-Database | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | bogdan, caulier.gilles, mail4ilia |
| Priority: | NOR | ||
| Version: | 1.6.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Romain Henriet
2010-11-29 11:59:25 UTC
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 :) |