PL5 completely messes up my Hierarchical Keywords when exporting

Would you mind to point me to the specification stating that lr:HierarchicalSubject shall not contain keywords without “hierarchy”, let’s call them “level 0 hierarchical”?

I have a related feature request:

This would be of benefit to Photo Mechanic Plus users, IMatch users and likely others as well.

1 Like

@jch2103, it was your thread that got me testing and found this issue!


we looked into that issue andhere is result of investigation for PhotoMechanic.
All programs write lr:HierarchicalSubject in the same way except C1 (C1 do not support unselected keyword items).
As for dc:subject , all programs write flatten keywords except PhotoMechanic.
PhotoMechanic lost a tag somewhere and it writes hierarchical subject to dc:subject, that is probably wrong because hierarchical structure is not expected in dc:subject.
So we write tags as they should be and bug is on PhotoMechanic side. I’ll see if we can push it to them.

We will now look into iMatch behavior, I’ll keep you up to date.


1 Like

PhotoMechanic is in the space a lot longer and has a great deal more experience working around the vagaries of hierarchical keywords. As the new entry into the metadata sweepstakes, it would behoove the DxO engineers to better understand Camerabits choices and work around them.

Someone at DxO is deluded that DxO is Apple or Microsoft or Adobe and should be able to dictate what computers or OS version their paying users are allowed to use (or in this case how metadata should function). What a pity. Great software hamstrung by arrogance. This kind of user-hostile behaviour makes it much harder to root for the little guy or feel any desire to advocate for him.

Adobe’s market domination was not built by abusing users. It was built by accomodating users and only later when the dominance was established were the MBA types given free rein to treat users like cattle to be herded and milked. Adobe’s long time mission was to help digital creators work better.

And even then, C1 adhere to MWG guidelines, only varying by including full hierarchical contexts instead of a simpler single context - something which does not break compatibility, even with PM.

Indeed. The inclusion of pipe delimiters is not a MWG standard syntax and would be expected to be interpreted as a single word that just happens to contain pipe characters.

Absolutely correct.

That’s exceedingly generous of you :wink:

This is arrogance par excellence. Any app that considers input like Fruit|Orange|Satsuma to be valid as a “hierarchy” in the dc:subject tag is simply breaking MWG guidelines.

The dc:subject tag is meant to contain words or phrases delimited by commas. No other delimiters are allowed as it is a list tag and the commas separate the items in the list. Any characters found between commas are deemed to be part of a single keyword and have no hierarchical relevance at all.

Nobody at DxO is “deluded”, they are following MWG guidelines. If Camerabits choose to implement non-standard metadata formatting, it is they that are trying to tie people in to only being able to use their software to “correctly” (according to their standards) interpret the metadata they allow to be written.

And yet, having participated in the creation of the MWG guidelines, Adobe then went off and decided that the whole world should adopt their “modifications” to the MWG and XMP standards - hence lr-hierarchicalSubject instead of using the mwg-kw:Keywords and mwg-kw:Hierarchy tags.

Adobe’s mission is to make money for Adobe and if that involves them tying people in to their products and “standards”, so much the better. However, Camerabits are not even following Adobe’s standards.

1 Like

Camerabits as their entire business is metadata and file management at an industrial scale (think thirty photographers shooting the same event simultaneously, sending properly tagged files out in real time) have some very good reasons for making the decisions they did.

DxO would do better to ask Camerabits why they handle hierarchical tags the way they do and what DxO could do to best retain compatibility with both PhotoMechanic and Adobe. I loathe Adobe but insisting on a non-Adobe compatible file handling would be another own goal.

Why should DxO have to write conditional code to accommodate Camerabits’ non-standard format?

That is the start of a coding nightmare as others could also insist that DxO also cater for their non-standard “standard”.

DxO have decided to follow MWG guidelines, which now include some of Adobe’s tags. This means that, in following MWG, Adobe are automatically compatible.

Camerabits may be a big player in metadata but that doesn’t mean they have the right to state that what they do is correct and that others should bend to their ideas.

I will say it again, text that includes pipe characters does not constitute anything other than a single keyword in the comma separated list that is the dc:subject tag.

The fact that lr:hierarchicalSubject was deliberately introduced to separate out hierarchical context from the keywords themselves, makes it plain that the two tags exist for two entirely separate purposes.

What is the purpose of repeating concatenated hierarchical keywords, already stored in lr:hierarchicalSubject in dc:subject? This leads to multiple sources of truth, with all the synchronisation issues that can bring.

I have said this many times before…

  • dc:subject is for searching
  • lr:hierarchicalSubject is for transmission of context

Adding pipe-delimited text to dc:subject means that it has to be parsed before it can be searched for a single matching keyword. This then creating combined search predicates much more complex and slower to run.

What DxO are doing is both MWG compatible and Adobe compatible.

It is not just DxO that doesn’t play nicely with Camerabits’ idea, it causes problems for most other software.

Your persistent propaganda efforts on behalf of DxO and your own software project show far too much bias.

I’m sure there’s a way to solve these hierarchical keyword compatibility issues. Sending peremptory directives to Camerabits from a metadata neophyte company like DxO is surely not the way to do it.

For those who are genuinely interested in dealing with the hierarchical keyword problems, my best suggestion is to sidestep it. Unless you are compelled by participation in a large commercial project to use hierarchical, don’t use them. Most metadata grief is due to the conflicting standards on hierarchical keywords. Sooner or later all of the carefully constructed hierarchy is going to come tumbling down on your head when you change software or even try new software.

Oh, go away. I really haven’t got the time or inclination to discuss with Camerabits’ chief propagandist.

1 Like

I am a Photo Mechanic Plus user and have had extensive communication with them on metadata and hierarchical keywords in particular. Metadata is Camerabits’ core business and I do trust that what they do is very well researched and correct. Standards in metadata are not really standards because there are so many and a lot is open to interpretation.

As far as hierarchical keywords in the subject field goes, my memory seems to indicate that Camerabits puts the full hierarchically keyword as a SINGLE keyword into the subject field to indicate that there is a hierarchy present and it can be used as a single keyword if required. There is nothing wrong with this because the separator is not the comma which is a normal keyword.

Using Joanna’s example, the hierarchy Fruit|Orange|Satsuma is added to the subject field as “Fruit|Orange|Satsuma” which is just a keyword which does NOT violate any standards!

Kirk Baker from Camerabits is very knowledgeable and very easy to chat to so if you want some clarification from him then get onto their forum at

1 Like

I have no affiliation with Camera Bits, other than as a relatively recent user. I thought PhotoMechanic was too expensive until I started to use it.

I have a lot of respect for software companies who spend decades working persistently on a single program and supporting their users properly. It’s also good to see a vendor in the photography arena who is focused on maintaining compatibility with a wide range of applications and not trying to blanket the market with features and become an inferior all-in-one tool.

Camera Bits manages to provide a single metadata product which helps the solo shooter, the wedding studio and NFL/UEFA/Olympics style multi-camera live events. Yes, it impresses me.

Oh and Photo Mechanic will never require a photographer to update to the latest Apple OS to run their software, as Camera Bits works for their photographer customers and not for their programmers’ egos, or vicariously for free for Apple.


PhotoLab 5.2 has been released today and should improve the export of hierachical keywords.


What changed ?
In the releases notes, it only mentions synchronization/update.

Edit: There is a modification to the Parent|Child hierarchical keywords in the Xmp file that there wasn’t before.

1 Like

Using an external DAM I don’t know what I do with it as its not at all clear what it does.

I’m testing with XnViewMP but it doesn’t recognize PL5 keywords, but the reverse works.
I don’t know who is at fault yet.

Edit: I added Bridge to my tests and there it seems to work, the problem will probably come from XnViewMP

What we fixed is preservation of hierarchy in keywords.
Behavior in LightRoom is unchanged as it was fine but now C1 and PhotoMechanic get the correct hierarchy in keywords in exported images from PhotoLab.

@Franky , can you provide us files and description of issue on ?



The problem actually came from XnViewMP, and it was solved after talking with the developer about it.

Unfortunately, PL5.2 still adds non-hierarchical keywords to the lr:hierarchicalSubject tag, thus leading to other software not interpreting the metadata correctly.