PL5 completely messes up my Hierarchical Keywords when exporting

I have a photo with the following tags:

exiftool -keywords -subject -HierarchicalSubject "E:\Test PMP\Source\AF.jpg"
Keywords                        : Anemonefish|Australian|Amphiprion rubrocinctus, 10 cm, Uncommon
Subject                         : Anemonefish|Australian|Amphiprion rubrocinctus, 10 cm, Uncommon
Hierarchical Subject            : Anemonefish|Australian|Amphiprion rubrocinctus

I export this file with PL5 and this is what I get:

exiftool -keywords -subject -HierarchicalSubject C:\Users\Keith\Desktop\AF_KRJ.jpg
Keywords                        : 10 cm, Amphiprion rubrocinctus, Anemonefish, Australian, Uncommon
Subject                         : 10 cm, Amphiprion rubrocinctus, Anemonefish, Australian, Uncommon
Hierarchical Subject            : 10 cm, Anemonefish|Australian|Amphiprion rubrocinctus, Uncommon

Note that my Hierachical Subject now has standalone keywords in it too! How is that a Hierarchy?

I used Photo Mechanic Plus to add my keywords and I believe this is correct and PL5 adds other keywords to this Hierarchical Subject tag which is obviously WRONG.

could you cite a source stating that “HierarchicalSubject” should differ from “Keywords” and “Subject” (to stay with ExifTool tag names)?

Did you read the MWG Guidance?

It is always potentially problematic to have software developed by multiple unrelated companies reading and updating the same data.


1 Like

Hi Keith

We have previously discussed the way Photo Mechanic Plus allows this combining of a hierarchy of keywords into a single keyword and that how this is non-standard according to MWG guidelines, causing confusion for other DAMs.

Because of this combining, Photo Mechanic Plus might be happy that Anemonefish|Australian|Amphiprion rubrocinctus represents a hierarchy but, in fact, it is just one single keyword that happens to contain a couple of pipe characters. This will definitely cause problems for some other DAMs.

PL5 has tried to parse this single keyword and has successfully separated it out into its constituent parts in the Subject tags as per the MWG guidelines. It is an MWG requirement that all pipe-separated hierarchical keywords in the HierarchicalSubject tag be explicitly and separately mentioned in the Subject tag and, in simply repeating the combined words, Photo Mechanic Plus is going against these guidelines, hence the confusion.

However, I would agree that both 10 cm and Uncommon are definitely not hierarchical in nature and should not be mentioned in the HierarchicalSubject tag.

@cdx can you comment on this?

1 Like

Hi Joanna, I guess I did not make clear what my real issue was. Ignoring how hierarchies are handled, my issue is that the keywords “10 cm” and “Uncommon” have been added to the HierarchicalSubject tag, as you rightly mentioned.

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