@Joanna I have read the details about setting hierarchical keywords in Bridge. I have downloaded the latest version on my main machine but no matter what I set I cannot get Bridge to write anything but ‘dc’ fields!!
@platypus I did amend your fine work but also left it intact. I wanted to see the keywords without the added xmp “stuff” they were “confusing” an old man, i.e. I “could not see the wood for the trees”. So here is your version slightly altered;
Expressions in square brackets are like opening and closing brackets (the one with the /) and x stands for the content that is packed between the brackets. That’s not too complicated, is it.
Regarding IMatch specifically, your findings don’t match what I see. I have a NEF raw image for which I used IMatch to add the hierarchical keyword ‘animals|mammals|bear|black bear’ (to the attached XMP sidecar, not the NEF). _DSC0388.xmp (7.5 KB) Note that IMatch records the hierarchical keyword as ‘animals|mammals|bear|black bear’ and dc.subject as:
This is as I would expect. Note especially that dc.subject generated by IMatch doesn’t include a hierarchical keyword, again as I would expect, but your example for IMatch showed otherwise. This is why I would like to see how you generated your examples.
I then processed the NEF in PL5. In its Metadata section, PL5 shows only ‘black bear’ in the Keywords tag. In the Keywords section, it shows:
animals
mammals
bear
black bear
I then did an ExifTool dump of the output jpg metadata (ExifTool dump of PL5 output jpg.txt (22.0 KB)
). The only keyword it contains is ‘black bear’ in [XMP-dc] Description (i.e., in dc-subject) and no reference to hierarchical keywords. As has been discussed elsewhere here, the hierarchical nature of the keywords has been completely lost in the output image. PL5 may retain these in its database for the raw NEF, but it’s disconcerting for it to have lost them in the output image! To do so seriously interferes with any efforts to comprehensively manage keywords.
[In addition, PL5 has added an entire Legacy IPTC section to the output file that did not exist in the original NEF/XMP! That’s a problem, although outside this discussion.]
@BHAYT - To recap, given the number of program you’re testing for metadata handling, it’s important to know the processing sequence(s) that you used in your examples, particularly the program(s) used to originally generate the data. I do appreciate the effort you’ve been putting into this.
@jch2103 I will read the post properly later and check my results but most of the programs were run stand-alone, no simultaneous opening of programs and restricted to their own directory, I say most because it is possible that PL5 was open during one test but I will check the results and post any addendum when I can.
@jch2103 Sorry but I did the animal|mammals|bear|grizzly bear test on one of my raws and the xmp contained ‘dc’ subject of animal|mammals|bear|grizzly bear and ‘hr’ hierarchical subject of animal|mammals|bear|grizzly bear !
Mine on the left and yours on the right! We need to get our IMatch settings aligned!
@jch2103 looking at the preferences options the ‘Metadata’/‘Keyword Export’/‘Write path elements’ did the trick! So I now need to repeat the IMatch “tests” again and the Bridge “tests” when I finally find out how to make that product produce ‘hr’ fields! I still need your settings so that I don’t risk “offending” you again!
The original tests also included putting all the outputs into PL5 and exporting to a JPG and the IMatch tests (and Bridge) will need to be redone and then some way of publishing the results determined!
@platypus I was not genuinely confused by the notation but rather in the spreadsheet I wanted to concentrate on the keyword data without the ‘xmp’ packaging but thank you for your concern and in the light of @jch2103 response and my “discovering” the preferences option for IMatch I can repeat the IMatch tests.
@Joanna I need your help to sort out the “problem” with my configuration of Adobe Bridge so that I can get it to use ‘hr’ data.
@Stenis Can I drag you into this discussion and can you please do me a favour and verify the Photo Mechanic data when you have time. I am trying to represent the facts in each case not peddle “untruths”.
Then I can feed all the settings into PL5 and determine what it makes of them and what is to be found in the exported JPGs, which was my original intention!
The updated spreadsheet with the amended data for IMatch (animal|mammal|bear):
It finally clicked! You are working in the IPTC metadata palette, which you should not be touching with a barge pole, unless you explicitly want IPTC metadata for purposes other than keywording.
Keywords stored in dc:subject and lr:hierarchicalSubject are part of the XMP namespace, not IPTC.
This is a revelation to me. Although I have Capture 12, I only use it for remote control of my camera for demonstrations at our club and hadn’t looked at it for metadata editing.
What I see is confirmation that how my software writes the lr:hierarchicalSubject tag is valid.
… with one line per member of the hierarchy explicitly spelled out. To my mind, this gives the most comprehensive transmission of how the hierarchy is constructed.
The only thing I don’t agree with is that C1 writes the lr:hierarchicalSubject tag even when the keywords are not hierarchical. I wouldn’t say that this is wrong, just unnecessary. But then some have the same opinions about explicitly writing all levels if a keyword is the leaf node of a hierarchy. What matters is that there is neither missing nor wrong metadata.
@platypus , you have shown the two alternatives (in red), both of which are valid, which is useful to note
You see, it is possible to have either a standalone keyword or the same keyword in one or more hierarchical contexts. One should not preclude the other.
Finally, if I only add animal and bear…
… even though both keywords appear in a hierarchy, because a complete hierarchy is not mentioned, bear is no longer regarded as part of a hierarchy and the two keywords are recorded in the XMP as…
No keyword is necessarily, intrinsically, hierarchical. Hierarchies should be constructed from existing standalone keywords. That way, the same keyword can either be searched for as part of multiple contexts - something that PL5 doesn’t presently allow.
Search will provide 2 results (A, M, B) each.
All of the above seems logical within DPL’s scope…but the two search results come up as separate lines with the same (keyword) icon, which I find puzzling…but again, we’re way off the OP “Ghosting…” topic.
All these problems seem to stem from the confusion caused by the Keywords palette providing both dictionary creation and management, together with file assignment/editing.
Added to which, from what I can gather, PL5 uses the hierarchical tag for searching instead of the dc:subject tag. I believe this is the fundamental reason why the search is so inadequate and inflexible.
What that is needed is for the PL5 search to provide the ability to create both AND and OR predicates. Then you could do useful things like searching for a keyword, whatever its context. Then neither the excessive loading of the hierarchical tag would not be necessary, nor the restriction to only AND predicates.
@Joanna I am dreadfully sorry if I was using the wrong interface elements in Bridge, but it was very much easier to use than navigating that “ludicrous” tree structure, “ludicrous” because it is a “pain” to use when it is tiny, it must be a nightmare when it to a “real” size!!
Please remember that I have had to learn to use these programs from scratch and with limited knowledge of keywording/metadata etc. Who would have guessed that entering “animal;mammal;bear” would create a keyword of ‘animal;mammal;bear’ and that you need to enter "; " between the keywords to act as a delimiter (IMatch and Bridge) and in Bridge you appear to have to add “animal”, “bear” and “mammal” separately and then select them from the tree; it is useful once they have been entered and helps avoid issues of “animal” versus “animals”, i.e. the keyworder changes their minds (fails to remember in my case) about how they want to construct the keyword elements!
Sorry I am obviously not making myself clear, I am selecting the data from the correct ‘xmp’ elements and not touching any that are in the IPTC section (the “incorrect” settings in Bridge still populated the ‘dc’ elements), I simply wanted the spreadsheet to concentrate on the field values not the ‘xmp’ delimiters (and including all the ‘xmp’ delimiters makes for much wider columns in the spreadsheet). Hence, the Subject comes from ‘dc’ and Hierarchical Subject from ‘hr’, no IPTC fields were “harmed” or used in the making of the spreadsheet.
I have redone the tests with Bridge correctly (I hope) and now have the following;
All comments welcome (except about the format of MY spreadsheet).
I can fake the inputs from Capture 1 by switching to the RAWs and creating the sidecar files from one of the other sidecar files but with the C1 keywords or you can use the following photos, Copyright remains mine and not waived except for the purpose of this forum Uploading: 00 - Base pictures.zip…
Ideas for the best way of distributing the results from feeding the various photos into PL5 when I rerun the tests and export the photos from PL5.
It is actually not as difficult as all that because most of the data is a repetition of one or two themes in each test group, i.e. within Test 01 ‘dc’, Test 01 ‘hr’, Test 02 ‘dc’, Test 02 hr’, Test 04 ‘dc’ and Test 04 ‘hr’ but I will restrict test re-use to within each test group and then check the outputs for the same scenario across test groups (expecting the results to be the same!)
Joanna if you check the spreadsheet you will see that other packages do the same for this rather “bizarre” combination (I did that deliberately to contrast with the situation where only the hierarchical key is entered). Even C1 adds the “animal” keyword but in combination with “animal|mammal” and “animal|mammal|bear”. C1 is the only product tested so far that adds “animal|mammal”, this is the reason for the spreadsheet and then the tests to see what PL5 makes of the various combinations (see @jch2103 post above).
PS:-
During beta testing DxO could have sent out a request to all beta testers (covering all the DAMs etc) to put a test group of photos through a set of tests and report the findings. If the photos were RAWs the sidecar files could have been returned to DxO for input to PL5. The differences could have been raised by DxO and some sort of consensus (wishful thinking) arrived at!
This is not only a major issue in Bridge - PL5 suffers from exactly the same problem.
Choosing keywords doesn’t need any more space (see the screenshots of my app) but managing keywords and their hierarchies is far to big an issue to try and shoehorn into such a tiny palette.
A palette might be fine for managing a couple of dozen keywords but, what about using something like the standard Foundation List, which contains 1,782 keywords? And that is nowhere near as big as some of the more specialised hierarchies that are available. Which is why my app has two columns, so that keywords from the column containing the full list can be dragged to their rightful places in the hierarchical list.
There is also a desperate need to be able to search for keywords from a dictionary - something that neither Bridge nor PL5 allows - instead we are limited to scrolling.
This is exactly why you need a lookup search that uses a pre-defined dictionary of keywords and their hierarchies. In my app, I have defined the following delimiters as possible separators , | / \ : ; > <
Some of them are allowed when adding keywords to the dictionary but they will automatically tokenise words when entering them by just typing in the entry field and the next keystroke will start a new keyword.
The problem is, you should not have been using the IPTC tags at all as they can further confuse some (particularly older) software.
The most concise and easily interchangeable results come either from C1 or my app. It is only these two that properly comply with MWG guidelines, which is surprising since Adobe helped draw them up, but then went on to “do their own thing”.
During the beta, I spent weeks testing PL5’s compatibility with MWG standards, Adobe Bridge and several other non-Adobe apps for Mac. At the time, nobody else seemed to be doing much with the topic, possibly because, like you, they weren’t really concerned with keywording and metadata.
In the end, from my extensive testing, PL5 has come up with perfectly acceptable XMP, as long as keyword hierarchies were written in accordance with MWG guidelines. I do not believe that DxO has any duty to try and second guess what other software writers care to allow. After more than two years writing my own dedicated keywording app, I can assure you, it would take far too long to keep everybody happy.
The truth is, if an app can’t cope with the present XMP generated by PL5, it is not MWG compliant and users should pester those authors to get it right.
If PL5 can’t interpret the XMP output by other apps, then that metadata is non-compliant and not the responsibility of DxO to try and second guess.
