Hi Marie
I have just updated and found that NO keywords are now copied over when you process from RAW to JPEG. I have added keywords in IMatch to all my RAW files and after processing nothing gets copied over even if you mark all metadata to be copied. Not sure what is happening now.
Andre
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.
About iMatch, @akirstein , can you provide me examples of issues you have (with description of the issue) ? You can use https://upload.dxo.com/
Regards,
Marie
Hi,
My workflowcase is:
Fast RawViewer v2 (creates xmp if i hit a star or colorflag.) Lightroom based.
Then Adobebridge for adding iptcdata and keywords to new images. Xmp (raw only)
Then load into DxOPL v5 and adding GPS data and maybe some forgotten data(which caused the earlier problem).
(now i am keep Bridge open for after metadata edits on the fly and let dxo only read to burn in exported jpegs.This let me still use autosync without the change of corrupting my xmp’s.)
Does the fix you talk about repaired connection between bridge and DxO?
So a change in dxo doesn’t cause writing a editted line on a different location in the xmp as the original place which was written by Bridge?
And honor the way bridge write the hierachical keywords?
(i am just fixed all xmp’s so i am very carefull. 
)
My workflow is as follows:
Upload using Fast View, cull as required, save to my drive
Open IMatch, add keywords and other metadata as required, batch rename YYYYMMDD-####
Open PL and edit RAW, export processed JPEG to same file location, noting keywords are to be copied.
In IMatch I can now filter all JPEGS for view or share as required.
In PL5.1 the keywords were copied with no issues.
In PL5.2 no keywords are copied over from RAW to JPEG.
OR
Open PL and edit RAW, export processed TIFF to NIK Collection, complete editing and then export final JPEG to same file location, noting keywords are to be copied.
In IMatch I can now filter all JPEGS for view or share as required.
In PL5.1 all hierarchy keywords copied as well as having the words duplicated into flat keywords.
I have not tried to do this in PL5.2 yet.
I have also seen that PL5.2 now asks you to either write or read metadata to the file as it has detected metadata was added using other software. (Small “S” icon appears on top right of photo.) All I want PL to do is read the metadata, not write anything as I spent months cleaning up the problem created by PL5.1. If this means it will write the data to PL5 then copy that same data back to the JPEG that would be great.
As OXiDant notes I too am treading carefully because it took a long time to fix my keywording up and I don’t want it to happen again. I would be interested to know what will happen if I “wrote” the metadata to the file so will try later t see what happens. As noted, treading carefully.
It works for me with PL5.2
I add keywords in RAW with Bridge and after open PL export JPEG
The keywords are copied on JPEG with all hierarchy
@akirstein I am concerned about your post because although there are changes a simple export test with old test data shows a difference in the exported JPG but the data is still there! The test was using data created by IMatch that was then input to PL5, according to the file naming this was for PL5.1.2 and exported. I re-exported the data to check what might be happening.
At the same time @Marie had posted in another related post and the final (so far) post from @Marie was PL 5 Keywords Handling: Output Files - #16 by Marie indicating that there have been changes made in the format of the output for hierarchical keys.
The following is a screenshot from PIE that indicates the changes are a reduction in the ‘dc’ fields generated within PL5.2, which I presume is what is being described by @Marie . The dataset is a mixture of JPG and RAW (RW2) images and the _DxPL5 JPGs are from the original tests and the _DxPL5.2 images are what was produced a few minutes ago!
This does not repeat your workflow but the original data was from IMatch into an earlier version of PL5 and then exported in that version and then again just now in PL5.2.0 and shows what has changed.
I will try to repeat your workflow when I have time, to see if I can reproduce any data loss!
Having read a number of posts now I decided to remove and reload PL5.2 as a number of other users seem to have had an issue corrected when they did this. After reloading I found all my keywords are seen and correctly listed so I am not sure what happened the first time I loaded PL. It has also read and loaded the old keywords and did not ask about needing to read keywords again so I am very happy with the outcome. I did a lot more testing last night and am very pleased to see the keywords stay as I set them up with no issues when I export.
So thank you team at DXO, really appreciate the work you do and for all the posts. They are really helpful to a non-geeky old timer like me 
If auto sync isn’t active you need to use "file-> metadata-> read metadata. to update xmp iptc data.
By removing and re installing you actualy remove the database and refresh this by installing.
so it sees all new entry’s because there “new”
If I can just chip in here.
I just ran a test with a NEF file with hierarchical keywords embedded in it (as opposed to in an XMP sidecar file)
I used my own keywording app that is fully MWG compliant to prepare the file.
Embedded in RAW
Here is the ExifTool output for that file…
[XMP] Subject : Couleur, Orange, Entreprise, Télécommunications
[XMP] Hierarchical Subject : Couleur, Entreprise, Couleur|Orange, Entreprise|Télécommunications, Entreprise|Télécommunications|Orange
… and here is the ExifTool output for an exported JPEG…
[XMP] Subject : Couleur, Entreprise, Orange, Télécommunications
[XMP] Hierarchical Subject : Couleur, Couleur|Orange, Entreprise, Entreprise|Télécommunications, Entreprise|Télécommunications|Orange
Written to XMP sidecar
Now, I use my app to clear out the keywords from the NEF file and rewrite the same keywords to an XMP sidecar file…
<dc:subject>
<rdf:Bag>
<rdf:li>Couleur</rdf:li>
<rdf:li>Orange</rdf:li>
<rdf:li>Entreprise</rdf:li>
<rdf:li>Télécommunications</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Couleur</rdf:li>
<rdf:li>Entreprise</rdf:li>
<rdf:li>Couleur|Orange</rdf:li>
<rdf:li>Entreprise|Télécommunications</rdf:li>
<rdf:li>Entreprise|Télécommunications|Orange</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
Closing PL5, deleting the database and any DOP file, reopening PL5 and exporting to JPEG gives the following ExifTool output from the JPEG…
[XMP] Subject : Couleur, Entreprise, Orange, Télécommunications
[XMP] Hierarchical Subject : Couleur, Couleur|Orange, Entreprise, Entreprise|Télécommunications, Entreprise|Télécommunications|Orange
This is totally correct, as expected and MWG compliant.
@OXiDant @akirstein what are you using to write the original keywords and hierarchies and could you please post
- the
dc:subjectandlr:hierarchicalSubjecttags that you have before PL5 gets to touch them - the
dc:subjectandlr:hierarchicalSubjecttags that you have after PL5 has done its thing
first Fast raw viewer then Adobe Bridge 2022 and finaly DxOPL.
Adobe Bridge is my main DAM.
I only use IMatch as my DAM software. Fast Raw Viewer is only for culling and selecting photos off the camera card which is then added to IMatch for keywording and the odd marking (one star, two stars etc.).
I tried again to load more photos today and PL showed metadata was written by another software when I first opened the new folder in PL. When I clicked that it should read the data it worked well by adding the information to the PL database and then correctly copied the information from the RAW file to the JPEG when processed. Before I reloaded PL again the original process did not copy the information so hence the reason no keywords were written to the exported file. Not sure what the reason was but it seems to have sorted itself out with the reload. So far I have not seen any issues with the hierarchal structure and there is no errors when reading back to IMatch.
Would you be so kind as to show me the keywords and their hierarchies as you entered them in Bridge? A screenshot should suffice.
@joanna Long time no speak! As a result of @akirstein concerns over what PL5.2.0 had done with keywords I did some more tests and was going to put them in my topic PL5.2.0.4730 Conflict Resolution only detects externally generated conflicts (getting very parochial all of a sudden) but will place them here instead!
Way back in a post far far away and certainly far away from the topic itself (a “bug” reported by me) I asked Joanna and @jch2103 to enlighten me on the “correct” representation of metadata and that started a lot of discussions and tests, amongst which I produced a spreadsheet that looked at what PL5 (PL5.1.2 to be exact) did with the keyword data that other software had “lovingly” placed in the image (in the RAW xmp sidecar file) when that image was then exported from PL5 as a JPG.
The original post that contains the spreadsheet I produced with input from others was contained in PL4.3.6.32 Ghosting Ratings for Same image in different directories (Win10) - #114 by BHAYT, i.e.
Always good to quote yourself!?
So I took the original test data and copied it to a new location and repeated the tests on PL5.2.0 on my Main machine and on PL5.1.4 on my Test machine and produced the following, where the first rows are from the original file, the second from the original PL5.1.2 tests (designated just DxPL5), the third from PL5.1.4 and finally from PL5.2.0 so that we can see exactly what DxO has changed!
-
Personally I would have retained the original as an option and allowed the users to choose between the two!
-
I don’t think that this answers the many posts that complained that the metadata so lovingly inserted by their DAM systems has been altered by PL5!!
It is good to see that DxO monitor the posts and take note of the various complaints. it is sad that they then make an arbitrary change and seem to not really have consulted with their users, “You can lead a horse to water but you can’t make it drink and you can’t stop it … in the pond!”.
After that remark and the frosty look I got from my wife, when she kindly brought me a cup of coffee and saw this post etc. on my screen, this might well be my last post!!
ACDSEE:-
Bridge:-
Photo Mechanics:-
IMatch:-
PL5.1.2:-
Lightroom:-
Capture 1:-
Zoner:-
Very difficult to read these spreadsheets but the only one I can see that adheres fully to MWG guidelines (as I understand them) and records the same results as my app, is Capture One.
Given a hierarchy of Animal > Mammal > Bear > Black Bear the guidelines state that the metadata written to an XMP file should be…
<dc:subject>
<rdf:Bag>
<rdf:li>Animal</rdf:li>
<rdf:li>Mammal</rdf:li>
<rdf:li>Bear</rdf:li>
<rdf:li>Black Bear</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>Animal</rdf:li>
<rdf:li>Animal|Mammal</rdf:li>
<rdf:li>Animal|Mammal|Bear</rdf:li>
<rdf:li>Animal|Mammal|Bear|Black Bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
That way, all the keywords in the hierarchy are available for searching, via the dc:subject tag and the full hierarchical structure of all keywords is transmitted in the lr:hierarchicalSubject tag.
a exported txt file sufficient?
keyword list.txt (1,1 KB)
right:
step one
FRV: create xmp. bij star and colorlabel.
_1080786.xmp (560 Bytes)
_1080791.xmp (560 Bytes)
Then step 2:
Bridge 2022:
meta iptc preset. and keywords: one as main and sub visible in checkbox:
and one as hide main show sub:
_1080786 step 2.xmp (4,6 KB)
_1080791 step 2.xmp (4,7 KB)
Then open in Plv5.2
fill in some fields and add keyword “planten” from list. (always synchronize is active)
_1080786 step 3.xmp (8,3 KB)
_1080791 step 3.xmp (8,4 KB)
Sins i have always sync active i don’t add new keywords in database of dxopl because i polute then this database.
(if it’s necessary for you to have that also then i
switch off allways sync.
add something to this two files (786/791) and manual export to metadata(xmp) and then delete database and modified xmp’s and re- index my archive to ingest all metadata again. (i don’t add keywords in dxo for now unless i know its safe to do so. )
if you need a bigger test i will.
Peter
@joanna Sorry about the legibility they are actually not spreadsheets they are “windows” into 4 simultaneous windows from PIE put together in real-time by 'Sneaky Previews" doing it this way saves me trouble and time trying to copy to the spreadsheet and I have found the colour combinations available in PIE not particularly good when using screen grabs - sorry!
Are any of the following easier to read?
The keywords in this file are not being written according to MWG guidelines. For the given hierarchy, they should be…
<dc:subject>
<rdf:Bag>
<rdf:li>woning</rdf:li>
<rdf:li>Dahliastraat</rdf:li>
<rdf:li>Type</rdf:li>
<rdf:li>Kunst en beelden</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>woning</rdf:li>
<rdf:li>woning|Dahliastraat</rdf:li>
<rdf:li>Type</rdf:li>
<rdf:li>Type|Kunst en beelden</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
After adding the extra keyword, the XMP should read…
<dc:subject>
<rdf:Bag>
<rdf:li>woning</rdf:li>
<rdf:li>Dahliastraat</rdf:li>
<rdf:li>Type</rdf:li>
<rdf:li>Kunst en beelden</rdf:li>
<rdf:li>Overige</rdf:li>
<rdf:li>Planten</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>woning</rdf:li>
<rdf:li>woning|Dahliastraat</rdf:li>
<rdf:li>Type</rdf:li>
<rdf:li>Type|Kunst en beelden</rdf:li>
<rdf:li>Overige</rdf:li>
<rdf:li>Overige|Planten</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
Now, what are you getting from PL when you export?
Unfortunately, nowhere can I see the hierarchical structure written explicitly. Am I to assume it is indeed Animal > Mammal > Bear > Black Bear ?
If a “DAM” doesn’t write the full structure, as I have outlined, then it is not MWG compliant and it is no wonder that PL is having problems. My app is fully compliant, as I gather is Capture One, and the resulting exports from such files are fine.
What would be useful is to see screenshots of the input dialogs for each app, to see how the hierarchies are determined and chosen from.
@joanna The keywords entered were
Photo 1 - animal, mammal, bear
Photo 2 - animal|mammal|bear
Photo 3 - animal|mammal|bear|Black Bear (but missing on some)
Photo 4 - animal, mammal, bear, animal|mammal|bear
into all packages but one of the things I did discover were that was output could (would) be influenced by certain options generally stored in the ‘Preferences’ section for each package. As a consequence it would be possible for two users of the same package to have a different keyword structure output depending on the choices they made!
My tests originally included JPG but I abandoned that in favour of RAWs because most if not all packages can be configured to use xmp sidecar files or simply do not provide an option to update the embedded xmp in the RAW file itself!
With the xmp sidecar files there is a greater and more easily accessed transparency!
However, I can access JPG using Beyond Compare which uses various add-ons to access the internals of images (including ExifTool) and it threw up this when comparing a PL5.1.2 output JPG with a PL5.1.4 (and PL5.2.0) output JPG with respect to IPTC data?
This indicates three standalone keywords with no hierarchical relationship and should produce…
<dc:subject>
<rdf:Bag>
<rdf:li>animal</rdf:li>
<rdf:li>mammal</rdf:li>
<rdf:li>bear</rdf:li>
</rdf:Bag>
</dc:subject>
This either indicates one keyword animal|mammal|bear or it can indicate an implicit hierarchy, depending on the software. I have seen it wrongly interpreted as…
<dc:subject>
<rdf:Bag>
<rdf:li>animal|mammal|bear</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>animal|mammal|bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… which is horrendously wrong in so many ways. Or this…
<dc:subject>
<rdf:Bag>
<rdf:li>animal</rdf:li>
<rdf:li>mammal</rdf:li>
<rdf:li>bear</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>animal|mammal|bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… which can be acceptable but doesn’t fully transmit the nature of the hierarchy for the upper nodes.
… suffers from the same problem of possible differing interpretations as found in Photo 2, just with another level.
This is simply a mess and a disaster waiting to happen. Essentially, the “natural” way to interpret this would be…
<dc:subject>
<rdf:Bag>
<rdf:li>animal</rdf:li>
<rdf:li>mammal</rdf:li>
<rdf:li>bear</rdf:li>
<rdf:li>animal|mammal|bear</rdf:li>
</rdf:Bag>
</dc:subject>
…
<lr:hierarchicalSubject>
<rdf:Bag>
<rdf:li>animal</rdf:li>
<rdf:li>animal|mammal</rdf:li>
<rdf:li>animal|mammal|bear</rdf:li>
</rdf:Bag>
</lr:hierarchicalSubject>
… that assumes that animal|mammal|bear is a standalone keyword that just happens to contain pipe symbols. I presume the inclusion of the “combined” keyword is an attempt to convey hierarchical structure within the confines of the dc:subject tag - something which should be a definite no-no.
The big problem with allowing all these non-standard variations to be entered in an app is that it is then up to each app to decide how to write them to the file’s metadata. Which subsequently means that every other app has to know about all possible variants and take an “educated” guess as to which one was intended.
On the other hand, if all DAM writers not only properly adhered to MWG standards but enforced them at the point of entry, we wouldn’t be in the par-less mess we find ourselves in today.
At which point I am going to blow my own trumpet again in stating that my app (unfortunately Mac only) does adhere to those standards and I haven’t yet found another app that misinterprets the metadata I write.
The key to the integrity that my app ensures is that the management of keywords and the construction of hierarchies is taken care of in a separate “Keyword Manager” popup window, which provides the only means of constructing hierarchies, it being impossible to imply a hierarchy just by entering a delimited list of words in the keywords entry field. The keywords entry field provides a chooser, populated from the dictionary that is managed by the Keyword Manager, so that it is more difficult to mis-spell a word or choose one from the wrong hierarchy. This dictionary is then used in the construction of the metadata that gets written into the XMP.
What DxO have done is to try and emulate other software in putting both keyword assignment and organisation in an impossibly small tool palette - something which can actively dissuade folks from properly organising a “dictionary” or “thesaurus” in the first place. Have you tried dragging a keyword to be a child of another?
Then you have the problem of being forced to see multiple versions of the same keyword in the entry field if you happen to need the same keyword from more than one hierarchy, with the only way of determining which is which being to hover over the tokens in anticipation of a tooltip to elucidate.
And, in closing this overly long post, we still haven’t got to the limitations the current DxO hierarchical structures place on any chance of a search that can do more than simple AND conditions - but I’ll leave that for another rant 