Bug 460064

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. ***