Use of tags created with DigiKam in Synology Photo

Software
,
1

For years I have a workflow that satisfies my needs.
Loading raw files (Canon CR3) into DigiKam, culling and assigning keywords.
Raw images are processed in Darktable and exported as PNGs.
Final retouching and printing is done in GIMP using PNGs and JPGs.
Metadata for raw files are stored in XMP sidecar files and metadata for PNGs and JPGs are stored in the image files and in XMP sidecar files
So far so good.
All images are stored on a Synology NAS.
Unfortunately, the Synology Photo application does not recognise the tags.
I.e. searching based on tags it not possible.
When images are processed via other applications (e.g. ZereneStacker for makro stacking) the tags written by these applications are recognized by Synology Photo.

I assume this is a problem with DigiKam (version 8.3.0) or the ExifTool (version 12.84) used by DigiKam.
Has anybody similar experience and a solution for this problem with Synology Photos?

2

I think Digikam uses an alternate name convention for its XMP sidecar files. (filename.ext.xmp). The standard (?) naming convention is (filename.xmp) Some software cannot read the Digikam version or have to be set to read them. This could be your problem, or not :slight_smile:

I do not use a Synology NAS and I am not an expert so you might want to confirm what I am saying.

Cheers,
Gord

3

Hello Gord

Thank you. I’ll make a test and give feedback.

Gerd

4

Meanwhile I have found a solution.
I have changed the settings in DigiKam to ensure the metadata are always stored in the image files (CR3, PNG and JPG). Synology Photo is now able to build up an index and I can search for images with certain tags.
DigiKam gives a warning when writing metadata to raw files. However, so far I had no issues.

5

Please take good backups if you’re writing directly to the raw file, the warning is there for a reason!

6

Thank you for the warning. Besides my usual backups I’m just creating an offline backup before applying the setting to the +100k images I have collected over the last decades.
Is the warning given by DigiKam just a general concern or are there known issues?

7

Raw files are tricky, sometimes adding data to them can break them, sometimes there are software errors or hiccups that can corrupt them.

8

It’s a configurable option.

2024-05-15-202422_827x352_scrot
2024-05-15-202422_827x352_scrot827Ă—352 36.9 KB

Check “Sidecar file names are compatible with commercial programs”. XMP handling is unfortunately a mess with free software. Bad defaults can force you having to do “dangerous” things with hundreds of thousands of files if you take a lot of photos.

9

Thank you for your recommendation. I was already thinking about using this option.

Unfortunately, using this option DigiKam does not generate unique file names for the xmp files.
So either the xmp file name does not match the photo file name (img-123.cr3.xmp <> img-123.cr3) or using the option the xmp file name is not unique and can be associated with different files at the same time (img-123.xmp → img-123.jpg, img-123.cr3).
Both cases are messy.

10

Hopefully the photos app prefers embedded metadata over sidecar files. But you’ve discovered the hitch in the official xmp specification :wink:

11

I might be naive, but there seems to be a simple solution to the problem.
DigiKam should ensure that all file names are unique and the xmp file name and the image file name are identical. This could easily be achieved by adding the image file type not only to the xmp file name but also to the image file name itself:
Instead of
img-123.png.xmp and img-123.png
is should be
img-123.png.xmp and img-123.png.png

This could be part of the option: “Sidecar file names are compatible with commercial programs”.

I don’t see any disadvantages of this approach (besides confusing users by changing the name of the image file).

12

If you diverge from the standard .xmp convention you’ll end up in lots of trouble sooner or later as you’ve found out . RAWS and JPEGs should share the same xmp when in the same folder. JPEGs can have additional embedded metadata without issues.

Using darktable or setting up other Foss software to use the darktable convention will end up hurting unless you for all eternity stick to a closed darktable ecosystem. Messing this up with further extension gymnastics will only make things worse.

Paths/filenames should have meaning. Identical path + file name but diverging extension should only be used for the same content in different formats. If the content differs such that meaning is changed change the path or filename.

It’s imho a bad idea but you can of course automate putting sooc JPEGs in a separate subfolder if you for some reason want to treat them as separate content. I can’t see why you would double the workload managing tags etc but it’s easy to do.

None of this will help when darktable xmp and other Software xmp start to diverge and you can’t merge in any reasonably safe and labour efficient way.

13

Bah, this is true. If you need it both ways, just symlimk one xmp naming style to another.

The bigger problem will be other software just obliterating the xmp file with its own changes.

14

Obviously, I was too hasty when I replaced my tried and tested filing system with these new-fangled computers.

karteikasten_rdax_85
karteikasten_rdax_851156Ă—650 114 KB

Bad jokes aside…
It seems to me that a simple principle was violated when using XMP sidecar files. Keys (and filenames can be considered as such) must be unique and time-invariant. Deviations from these two points lead to problems (as I have painfully discovered).

1 Like