Bug 258272 - MAINTENANCE : Export album properties for compatibility with simple image viewers and archiving
Summary: MAINTENANCE : Export album properties for compatibility with simple image vie...
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Maintenance-Database (show other bugs)
Version: 1.6.0
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
: 217735 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-11-29 11:59 UTC by Romain Henriet
Modified: 2021-03-09 08:20 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Romain Henriet 2010-11-29 11:59:25 UTC
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).
Comment 1 Ilia K. 2011-05-02 01:09:48 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...
Comment 2 caulier.gilles 2014-08-07 07:09:41 UTC
*** Bug 217735 has been marked as a duplicate of this bug. ***
Comment 3 Justin Zobel 2021-03-09 05:51:45 UTC
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.
Comment 4 Romain Henriet 2021-03-09 07:48:00 UTC
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.
Comment 5 caulier.gilles 2021-03-09 08:19:12 UTC
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
Comment 6 Romain Henriet 2021-03-09 08:20:33 UTC
Nice :)