SUMMARY: see $SUBJECT I use Digikam on a small notebook when abroad or on holiday to tag, describe and rate my photos taken on the road. I then rsync these folders to my home PC with the "main" installation of Digikam. Both installations use XMP sidecars only to store image metadata so this works quite well. However, the way I see it neither album settings (which I can live with) nor image groups survive this transfer because they are *only* stored in the database. The latter is a pain because I use this feature hevaily. Can we add a (possibly digikam specific) tag in the XMP sidecar files which, when set, defines the "parent item" (e.g. by filename) which the current item is grouped into? An XMP "derivedFrom" tag exists and could also be used for this purpose but I'm not sure this is exactly the same thing. I actually asked this back in 2016 for a completely different use case (Digikam importer) but it seems nothing has happened since then.
No, such things do not belong in sidecars, they are not file metadata, but program-specific settings. In digKam-8.0.0 it will be better possible to "take along" a database. Paths can be "attached" to the network collection for easy use on another OS or machine with a different mount point. Maik
I can agree with you for folder settings. But I disagree for file groups. A relationship of a file to another file - like versioning, series shots, edits or "parent/child" relations - should be portable between apps and is actually metadata of the file. So Digikam should (and could) save a kind of "belongs-to" relation in each image's sidecar files. Of course, it should also take care there are no loops or endless recursions when loading sidecars, but that's rather obvious.
No, the Metadata Standard does not consider such a use case. Maik
Thanks for making this clear. So what alternatives exist? I think that being able to transfer albums / folders / files between Digikam installations including *all* file metadata is a valid use case. But currently, at least the grouping status is not saved anywhere but the database. Can we use a Digikam specific tag to accomplish this?
Grouping is not file metadata. This is a feature within an image management. How should the link to another image be created in the metadata? Via the filename/path - is ambiguous. Via the internal image ID - is different for each database. Via a hash - even a slight change to the file would make the hash invalid. Maik
Maik, I think the grouping item information can be stored in the digiKam XMP namespace. Group can be identified as a list of properties as files list grouped. Adobe do something similar with XMP MM tags about versioning. Sure versioning is not exactly the Grouping feature, but not so far in fact. https://exiftool.org/TagNames/XMP.html#xmpMM Of course grouped files must be identified from the database with something more than file path + name, perhaps with the checksum of first bytes already used to identified already downloaded files from camera. Gilles
Technically it is quite uncertain. When a collection is rescanned, you cannot ensure the order of the images. How do you want to match an item to the parent item if the parent item hasn't even been scanned yet? It would then have to be something like tag paths. For example, I'm looking for a better solution than device + date + file size + name for recognizing images during import. Unfortunately, I haven't come up with a better solution that also works with GPhoto2. Maik
>It would then have to be something like tag paths? Right using an internal tags to identify a group of image is the most universal way, why i don't found this idea myself... Gilles
> When a collection is rescanned, you cannot ensure the order of the images. How do you want to match an item to the parent item if the parent item hasn't even been scanned yet? The easy solution would be to scan twice. In the first round skip all images which have a parent_id. Then scan again, and skip all images already scanned (where parent_id != NULL). This guarantees that you'll get all parents before you scan the first child. The performance hit would probably be small because every image is still only touched once and sorting needs to be done anyway depending on user choice.
No need to scan twice. If grouped image is associated to an internal tag, this will be easy to restore as all the relevant code already exist an work well
All the better! :-)
*** Bug 474373 has been marked as a duplicate of this bug. ***