Indeed? It looks like that particular file has been manhandled by several apps, one of which is digiKam, with its own particular tags.
XMP digiKam Tags
DigiKam namespace tags.
These tags belong to the ExifTool XMP-digiKam family 1 group.
Tag Name
Writable
Values / Notes
CaptionsAuthorNames
lang-alt
CaptionsDateTimeStamps
lang-alt
ColorLabel
string
ImageHistory
string/
(different format from EXIF:ImageHistory)
ImageUnique I D
string/
LensCorrectionSettings
string
PicasawebGPhotoId
string
PickLabel
string
TagsList
string+
Something that is obvious is that you have no hierarchy, despite the presence of the lr:hierarchicalSubject tag.
There is a hint, in the screenshot of your XMP file, that you might created a hierarchy of - National Trust | Nymans Gardens but, if that were the case, I would expect to see…
Otherwise, with only those two keywords as standalone, there is no need at all for the lr:hierarchicalSubject tag.
However, even if there is no hierarchical link, DxO has the peculiarity of writing every standalone keyword as a single level hierarchy. This is not standard behaviour and can cause confusion with other software.
For completion (and a case I never want to use but some people do), If I remove the A keyword from the image but leave the A|B keyword selected, what should lr:hierarchicalSubject now include?
As long as you’re looking at this and have written your own keyword software, I understand that RGB files should have keyword changes written directly to them, not to XMP files–correct? If you happen to use exiftool, would you know the command line versions to correctly write keywords and hierarchies to the RGB file in all the cases listed above (only A, A and A|B, only A|B)?
If you look at the ACDSee line in the xmp sidecar you will see the problem I got into with digiKam, I added the list of keywords incorrectly and now need to work out how to remove them but somehow digiKam included them in my assignment so I removed them before discovering the image in DxPL!
@freixas I am not sure if it was you or another poster that asked if DxPL uses ExifTool and given that I crippled ExifTool by accident on my test machine but nothing happened with DxPL I can safely assume that it doesn’t.
It might use Exiv 2 or ??
I will let @Joanna answer the ExifTool question which is way out of my knowledge but the “rules” state that RGB files should have the xmp data embedded and not placed in sidecar files.
In DxPL you will have A & B in the Dc fields as shown in the table I provided in an earlier post in the topic but the ‘hr’ fields will have the following in the first images (P1111331.RW2) with the option shown below selected and the second image (P1111333.RW2) is with the alternative option selected.
Wasn’t me. I doubt that PL would depend on an external PERL script.
You left out some context:
To clarify, I wasn’t asking @Joanna what PL does since I can check that myself, I was asking what the “standard behavior” she cited would do. In any case, shouldn’t you be in bed?
Thanks to all who have added to this post. A very interesting read. My two cents worth having trialled numerous DAM packages, including Bridge which I really liked, is that Bridge had the occasion to not write information to the file but only hold it in its data folder. I eventually landed on IMatch as my DAM softawre and to date there has been no issues between the two software as far as I can tell. IMatch also uses the latest version of ExifTool and suggest those who are able to have a look at how it works in the background.
What a good question to start and what a complex discussion. I can’t claim to have understood all of it (I’m a naïve user who doesn’t look at code, rather like a car driver who doesn’t open the bonnet / hood) but it does reassure me that I’m not the only one unclear i this area. It strikes me Dxo ought to be either improving / rationalising their tech design so that there isn’t duplication of information and different options about whether to store it in either or both paces (sidecars, database), or - if some kind of rationalisation isn’t for some reason possible, improving their documentation so customers don’t have to do experiments and tests to find out what it actually does.
