• Welcome to the Lightroom Queen Forums! We're a friendly bunch, so please feel free to register and join in the conversation. If you're not familiar with forums, you'll find step by step instructions on how to post your first thread under Help at the bottom of the page. You're also welcome to download our free Lightroom Quick Start eBooks and explore our other FAQ resources.
  • Stop struggling with Lightroom! There's no need to spend hours hunting for the answers to your Lightroom Classic questions. All the information you need is in Adobe Lightroom Classic - The Missing FAQ!

    To help you get started, there's a series of easy tutorials to guide you through a simple workflow. As you grow in confidence, the book switches to a conversational FAQ format, so you can quickly find answers to advanced questions. And better still, the eBooks are updated for every release, so it's always up to date.

Keywords - Characters < and > stripped on import

Status
Not open for further replies.

peterastle

New Member
Joined
Feb 4, 2020
Messages
2
Lightroom Version Number
Lightroom Classic version: 9.1 [ 201911291132-64cf80b4 ]
Operating System
  1. Windows 10
I have always keyworded my images using Adobe Bridge and have only recently started to use Lightroom Classic.
In Bridge I have made extensive use of the sybols < and > in certain keywords such as <Hew> for example.
Bridge is perfectly happy with these keywords but when I import such images into Lightroom the < and > characters are stripped from my keywords so <Hew> becomes simply Hew.
I do not know why this is happening.
I have created keywords in Lightroom containing < and > and Lightroom is quite happy with them , so <Hew> is a saved keyword in Lightroom.
Still when I import images containging these symbols they are immediately removed and I end up with two Lightroom keywords <Hew> and Hew.
 
Welcome to the forum.
In a hierarchal keyword listing it is possible that you can use the keyword with a different parent For example a list of color keyed might contain 'rose'. and a list of flowers might also contain "rose" For disambiguation these are displayed as rose<color, rose<flower.
I think the import process is seeing the "<" and expecting a parent But then that does not explain the missing ">". The creation process does allow this for some unexplained reason such that rose<color, rose<flower with "<" added becomes <rose><<color>, <rose><<flower>.
 
Thanks for your comments.
In Lightroom Preferences under File Handling - Reading Metadata, the only symbols mentioned to be interpretted as keyword separators are ' . ' and ' / ' (Dot and forward slash.) There is no mention of the use of ' < ' and ' > ' (They are mentioned as being illegal characters in File Name Generation but then I am not using them in File Names.)
 
Thanks for your comments.
In Lightroom Preferences under File Handling - Reading Metadata, the only symbols mentioned to be interpretted as keyword separators are ' . ' and ' / ' (Dot and forward slash.) There is no mention of the use of ' < ' and ' > ' (They are mentioned as being illegal characters in File Name Generation but then I am not using them in File Names.)
Those Preferences limits are to prevent legal Mac file names files from finding their way on tp the more restrictive Windows environment. I could find no limits in the Keyword naming and like you was able to create keywords containing "<" and ">". However, "<" is a separator character for disambiguation to distinguish keywords that may have different parents. It is a guess on my part that Import is reading keywords from the imputes file and finding the disambiguation character and stripping it off and placing everything in the (flat) keyword field The file metadata contains two keyword fields: Keyword and HierarchalKeyword. The IPTC Photo Metadata Standard 2019.1 has a field for Keyword but not HierarchalKeyword.
That said, I don't really have any other all encompassing explanation. Since "<" & ">" are permitted in the Keywords creation, this might be some sort of bug. Unless some comes up with a better explanation, you might want to submit this to Adobe as a bug report.
 
When LR imports a photo, it reads keyword metatadata from three fields: XMP:Subject, IPTC:Keywords, and XMP:HierarchicalSubject. The first two are defined by the XMP and IPTC standards, the third is defined by Adobe and not covered by any industry standard. XMP:Subject and IPTC:Keywords are, by convention, supposed to contain the same value, so I'll just refer here to XMP:Subject.

XMP:Subject can contain "flat" (top-level) keywords or hierarchical keywords. Preferences > File Handling says:
1580929024762.png


What this means is that if XMP:Subject contains "animal.dog", "animal/dog", or "animal|dog", that will be read as the hierarchical keyword Animal > Dog.

What's undocumented is that ">" and "<" are also treated as hierarchical separators, like "|". So "animal>dog" and "dog<animal" will be treated the same as "animal|dog". There's no way to turn that off, unfortunately. I filed a bug report about the incorrect documentation:
Lightroom: |, &lt, > not documented as hierarchical keyword separators | Photoshop Family Customer Community

XMP:HierarchicalSubject is an Adobe-defined field that contains hierarchical versions of the keywords in XMP:Subject, with just "|" recognized as the hierarchical separator. LR reads and writes that field, but I don't know about Bridge or other Adobe programs.
 
When LR imports a photo, it reads keyword metatadata from three fields: XMP:Subject, IPTC:Keywords, and XMP:HierarchicalSubject. The first two are defined by the XMP and IPTC standards, the third is defined by Adobe and not covered by any industry standard. XMP:Subject and IPTC:Keywords are, by convention, supposed to contain the same value, so I'll just refer here to XMP:Subject.
.

Thanks for the clarification. I knew that had to be some relationship to hierarchy separators But that was not to be found in the documentation.
Bridge keywords should be interpreted correctly when imported by Lightroom Classic


Sent from my iPad using Tapatalk
 
I've filed a bug to update the Preferences Dialog and sent in the changes for the Help doc. The help doc should be updated quickly. The Pref's dialog may take a bit.
 
Status
Not open for further replies.
Back
Top