[digiKam-users] Keyword (metadata) consistency between programs

[Alan H]

Remco, and other viewers, apologies for not including the link to the files. Nothing that cannot be shared. Don’t know what I was thinking sending it just to Woenx. The more that can think about this the better. Here’s the link:
https://www.dropbox.com/sh/9x7heiuo6h492xb/AAB8tvDi6Or0_XLqcIK-ggCpa?dl=0

Thanks for the explanation. I can probably come up with some sort of kludgy solution to work around this since I really want to use digiKam as my DAM. There are times though that the processing tools of other apps suit my needs and familiarity better, such as the brush and masking tools in ON1. I’m about to go ahead with curating 30,000+ digitized slides and it would be very helpful to be able to search on ratings, color codes, keywords and other metadata added or changed (eg date taken) in digiKam reliably when in other apps and I want to find and process a particular photo.

As a curiosity, though, would it be a complex and/or a lengthy task for digiKam to create sidecars completely compatible with sidecars used by other apps? (possibly an industry first, aside from the snakepit of which apps to choose). I only ask because to my untrained eye the ON1 sidecar (“filename.on1”) created by digiKam appears to be very similar in format to the sidecar that ON1 creates, when “Use a compatible file name…” is checked. It is quite distinct from the (normal looking?) .xmp sidecar that digiKam (and most other apps) creates when that option is unchecked. From my view of the sidecars, the problem appears to be an inconsistency/confusion in whether the metadata tag belongs to a jpg or raw file and then writing it into the correct block. The blocks seem to be there, just not properly interpreted and applied. Could digiKam be programmed (and with what effort) to realize that the blocks legitimately hold different info?

Alan

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Remco Viëtor<mailto:remco.vietor at wanadoo.fr>
Sent: Wednesday, April 29, 2020 12:14 AM
To: digiKam - Home Manage your photographs as a professional with the power of open source<mailto:digikam-users at kde.org>
Subject: Re: [digiKam-users] Keyword (metadata) consistency between programs

On mardi 28 avril 2020 23:45:41 CEST Alan H wrote:
> I was thinking that given the configuration option “use a compatible file
> name for writing sidecar files”, and digiKam creating files using the
> extensions (.on1 & .xmp) that ON1 uses, that the sidecars would be
> interchangeable. The internal structure of the files even appears to be
> similar between what digiKam creates and ON1 creates (to an end-user,
> perhaps not a developer/programmer).

> Unfortunately it seems that contradictory metadata is written. As you may
> see in the Dropbox files jpeg metadata is overwritten by raw metadata in
> what are suppose to be jpeg blocks. Or, metadata is not updated without
> applying a very unintuitive process. Raw photo metadata can therefore be
> embedded in jpeg photos.
>
There's syntax (which XML fields are written) and semantics (what's the exact
meaning of the contents). The syntax is declared in the namespace definitions,
not the semantics. So if ON1 uses jpeg blocks and raw blocks in one file,
digikam may not realise those can legitimately hold different info.

> Perhaps there could be more detailed explanation by digiKam what was meant
> by “Use a compatible file name….” since the way I thought it worked does
> not appear to be correct, or I’m not using it correctly. Or maybe ON1 has
> advanced the structure of their sidecar files beyond what digiKam has
> programmed.

 "Compatible file name for sidecar files" means basically "use this extra
extension for XMP files". The internal structure will be the same for all
sidecars (it's derived from XML). Available tags may differ, and on reading
digikam should ignore tags it doesn't know about.

Remco

P.S. Referring here to files you apparently want to keep private isn't
particularly helpful


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200429/d895b57e/attachment.html>