Copy link to clipboard
Copied
I ingest and tag photos with Photo Mechanic before processing them in LRCC. I recently noticed that after processing in LRCC, there are extra keywords added to the metadata. I have confirmed that the extra keywords are not there after the photos have been ingested, nor are they visible in the metadata when viewed in LR. The exported file has the extra keywords. I have used these keywords before when I was using LR to tag photos and found them in the keyword list. I deleted the keywords and the one image I tested on export, exported as expected. I then went to export the rest of the images and the export has pretty much stopped working - it takes forever to get started. I cancelled it as it seemed stuck in the "preparing" stage. I have already done the 'shut-it-down-and-restart' thing and no change.
I am in the middle of shooting a tournament and can't have this happening to me right now!
Any ideas what's going on here?
The topic selection below is not helpful.
After a very long conversation with Adobe support, the mystery has been solved.
The TL/DR version: LRCC Keyword hierarchies write all levels of the structure on export.
The longer explanation:
When I started tagging photos, I used LR and created keyword structures. LRCC will always export the upper level keyword with the lower level keyword. Although I stopped using LRCC to tag my photos, I am using some of the same keywords. So what happened, in LRCC I had created a structure that had an upper
...Copy link to clipboard
Copied
What is your OS? Mac or PC?
I tested that on my MacBook Pro M1 Max with Photo Mechanic and LrC 12.1 and didn't see any keywords on the imported .jpgs previously exported. However, I have never used keywords in that machine since it is just my travel laptop.so that might make a difference.
Copy link to clipboard
Copied
MacBook M1 Max, Ventura but this also happened before I upgraded to Ventura (checked older exports). I can't really say when it started but when checking prior exports the first time I see it is in files that I exported on February 2, 2022. I don't normally back up my exports since I can re-create them but sometimes they sit on my device long enough for time maching to pick them up.
Copy link to clipboard
Copied
Is it possible these 'extras' are synonym keywords, or parent keywords? The Keywording panel when set to "Enter keywords" will only show the directly assigned keywords. Changing this to "Keywords and Containing Keywords" will also show those that the image indirectly acquires because of nesting. Changing this to "Will export" displays any keyword synonyms too, but OTOH, will now suppress the display of any keywords which are set not to export.
Copy link to clipboard
Copied
These files weren't tagged in LR, they were tagged in Photo Mechanic so I wouldn't expect any LR tagging to be involved. And it's a completely random tag. It hadn't been used anywhere in a few years, at least since I started using Photo Mechanic to tag. And it appears to have started happening somewhere around February 2022 based on checking old exports that found in my backups. Just a really random thing.
Copy link to clipboard
Copied
I don't know Photo Mechanic but is it possible these may be synonym keywords coming from there? An image inside LrC may or may not evidently show a synonym keyword depending on how you inspect it. The different modes of the Keywording panel that I described in previous post, may help as a troubleshooting tool to understand what is going on - at least, within the Catalog.
A synonym would not be expected to show up in the Catalog's keywords list.
Copy link to clipboard
Copied
I don't think so. I checked the images after they were digested and before they were imported into LR and there were no rogue keywords. I checked my metadata templates and replacement code files very carefully to see if these words showed up anywhere and they didn't. Also, I have never used these keywords in Photo Mechanic - only in LR when I was using LR to tag photos. This addition has to have happened somewhere in LR. Since having deleted the keywords out of the keyword list, this is not happening anymore but it's still a huge mystery as to why it happened in the first place and has me worried that it might crop up again.
Also, having shut everything down for the night, LR is now behaving as expected so that worry is off my mind. Nothing like the panic of a critical piece of your workflow going bonkers in the middle of a busy shooting schedule.
Copy link to clipboard
Copied
If this happens again, load the files into Photoshop or Bridge and post the File Info->Raw data for us.
There are multiple keyword namespaces and sometimes they get out of sync.
Copy link to clipboard
Copied
Thanks - I will keep a copy of this on my desktop juuuuust in case it happens again.
Copy link to clipboard
Copied
Just happened again. sigh. Here is the raw data. The rogue keyword this time is CEBL
.x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 9.0-c000 79.171c27fab, 2022/08/16-22:35:41 "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/" xmlns:xmpRights="http://ns.adobe.com/xap/1.0/rights/" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:photomechanic="http://ns.camerabits.com/photomechanic/1.0/" xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#" xmlns:Iptc4xmpExt="http://iptc.org/std/Iptc4xmpExt/2008-02-29/" xmlns:lr="http://ns.adobe.com/lightroom/1.0/" xmlns:tiff="http://ns.adobe.com/tiff/1.0/" xmlns:exif="http://ns.adobe.com/exif/1.0/"> <photoshop:City>Ottawa </photoshop:City> <photoshop:State>Ontario</photoshop:State> <photoshop:Country>Canada</photoshop:Country> <photoshop:AuthorsPosition>Founder</photoshop:AuthorsPosition> <photoshop:Credit>Valerie Wutti/OSEG</photoshop:Credit> <photoshop:Source>Valerie Wutti/OSEG</photoshop:Source> <photoshop:CaptionWriter>Valerie Wutti</photoshop:CaptionWriter> <photoshop:Instructions>anthem</photoshop:Instructions> <photoshop:Urgency>2</photoshop:Urgency> <photoshop:DateCreated>2022-12-16T19:03:06.035+09:00</photoshop:DateCreated> <photoshop:SupplementalCategories> <rdf:Bag> <rdf:li>Hockey</rdf:li> <rdf:li>Oshawa Generals</rdf:li> <rdf:li>Ottawa 67's</rdf:li> </rdf:Bag> </photoshop:SupplementalCategories> <photoshop:LegacyIPTCDigest>27876E2C070F9FDA886FA9D746447788</photoshop:LegacyIPTCDigest> <photoshop:ColorMode>3</photoshop:ColorMode> <photoshop:ICCProfile>sRGB IEC61966-2.1</photoshop:ICCProfile> <xmpRights:Marked>True</xmpRights:Marked> <xmpRights:WebStatement>www.blitzenphotography.com</xmpRights:WebStatement> <xmpRights:UsageTerms> <rdf:Alt> <rdf:li xml:lang="x-default">No usage granted without prior permission. Use of this photo is governed by contract and intellectual property laws of Canada. This image remains the exclusive property of Valerie Wutti. No rights are granted unless written contracts are in place</rdf:li> </rdf:Alt> </xmpRights:UsageTerms> <xmp:CreateDate>2022-12-16T19:03:06</xmp:CreateDate> <xmp:Label>1st</xmp:Label> <xmp:Rating>4</xmp:Rating> <xmp:ModifyDate>2022-12-17T06:45:49-05:00</xmp:ModifyDate> <xmp:CreatorTool>Adobe Photoshop Lightroom Classic 12.1 (Macintosh)</xmp:CreatorTool> <xmp:MetadataDate>2022-12-17T06:45:49-05:00</xmp:MetadataDate> <photomechanic:EditStatus>Regular Season</photomechanic:EditStatus> <photomechanic:ColorClass>2</photomechanic:ColorClass> <photomechanic:Tagged>False</photomechanic:Tagged> <photomechanic:Prefs>0:2:4:000018</photomechanic:Prefs> <photomechanic:PMVersion>PM6</photomechanic:PMVersion> <Iptc4xmpCore:CountryCode>CAN</Iptc4xmpCore:CountryCode> <Iptc4xmpCore:Location>Arena at TD Place</Iptc4xmpCore:Location> <Iptc4xmpCore:CreatorContactInfo rdf:parseType="Resource"> <Iptc4xmpCore:CiAdrExtadr>1972 Summerfields Cres.</Iptc4xmpCore:CiAdrExtadr> <Iptc4xmpCore:CiAdrCity>Ottawa</Iptc4xmpCore:CiAdrCity> <Iptc4xmpCore:CiAdrRegion>Ontario</Iptc4xmpCore:CiAdrRegion> <Iptc4xmpCore:CiAdrPcode>K1C 7B4</Iptc4xmpCore:CiAdrPcode> <Iptc4xmpCore:CiAdrCtry>Canada</Iptc4xmpCore:CiAdrCtry> <Iptc4xmpCore:CiTelWork>613-355-8804</Iptc4xmpCore:CiTelWork> <Iptc4xmpCore:CiEmailWork>v_wutti@hotmail.com</Iptc4xmpCore:CiEmailWork> <Iptc4xmpCore:CiUrlWork>www.blitzenphotography.com</Iptc4xmpCore:CiUrlWork> </Iptc4xmpCore:CreatorContactInfo> <dc:format>image/jpeg</dc:format> <dc:creator> <rdf:Seq> <rdf:li>Valerie Wutti</rdf:li> </rdf:Seq> </dc:creator> <dc:rights> <rdf:Alt> <rdf:li xml:lang="x-default">© 2022 Valerie Wutti. All rights reserved</rdf:li> </rdf:Alt> </dc:rights> <dc:subject> <rdf:Bag> <rdf:li>Arena at TD Place</rdf:li> <rdf:li>CEBL</rdf:li> <rdf:li>Hockey</rdf:li> <rdf:li>OHL Regular Season</rdf:li> <rdf:li>Oshawa Generals</rdf:li> <rdf:li>Ottawa</rdf:li> <rdf:li>Ottawa 67's</rdf:li> <rdf:li>anthem</rdf:li> </rdf:Bag> </dc:subject> <xmpMM:DocumentID>xmp.did:9ec3f989-17fe-45ed-9711-4be2b7deb179</xmpMM:DocumentID> <xmpMM:PreservedFileName>VWX30018.JPG</xmpMM:PreservedFileName> <xmpMM:OriginalDocumentID>E9134032B146ED10C2AF833F851D523E</xmpMM:OriginalDocumentID> <xmpMM:InstanceID>xmp.iid:9ec3f989-17fe-45ed-9711-4be2b7deb179</xmpMM:InstanceID> <xmpMM:DerivedFrom rdf:parseType="Resource"> <stRef:documentID>E9134032B146ED10C2AF833F851D523E</stRef:documentID> <stRef:originalDocumentID>E9134032B146ED10C2AF833F851D523E</stRef:originalDocumentID> </xmpMM:DerivedFrom> <Iptc4xmpExt:PersonInImage> <rdf:Bag> <rdf:li>anthem</rdf:li> </rdf:Bag> </Iptc4xmpExt:PersonInImage> <Iptc4xmpExt:LocationCreated> <rdf:Bag> <rdf:li rdf:parseType="Resource"> <Iptc4xmpExt:Sublocation>Arena at TD Place</Iptc4xmpExt:Sublocation> <Iptc4xmpExt:City>Ottawa</Iptc4xmpExt:City> <Iptc4xmpExt:ProvinceState>Ontario</Iptc4xmpExt:ProvinceState> <Iptc4xmpExt:CountryName>Canada</Iptc4xmpExt:CountryName> <Iptc4xmpExt:CountryCode>CAN</Iptc4xmpExt:CountryCode> <Iptc4xmpExt:WorldRegion>North America</Iptc4xmpExt:WorldRegion> </rdf:li> </rdf:Bag> </Iptc4xmpExt:LocationCreated> <lr:weightedFlatSubject> <rdf:Bag> <rdf:li>Oshawa Generals</rdf:li> <rdf:li>Ottawa 67's</rdf:li> <rdf:li>anthem</rdf:li> <rdf:li>CEBL</rdf:li> <rdf:li>Arena at TD Place</rdf:li> <rdf:li>Ottawa</rdf:li> <rdf:li>OHL Regular Season</rdf:li> <rdf:li>Hockey</rdf:li> </rdf:Bag> </lr:weightedFlatSubject> <tiff:ImageWidth>5472</tiff:ImageWidth> <tiff:ImageLength>3648</tiff:ImageLength> <tiff:BitsPerSample> <rdf:Seq> <rdf:li>8</rdf:li> <rdf:li>8</rdf:li> <rdf:li>8</rdf:li> </rdf:Seq> </tiff:BitsPerSample> <tiff:PhotometricInterpretation>2</tiff:PhotometricInterpretation> <tiff:SamplesPerPixel>3</tiff:SamplesPerPixel> <tiff:XResolution>300/1</tiff:XResolution> <tiff:YResolution>300/1</tiff:YResolution> <tiff:ResolutionUnit>2</tiff:ResolutionUnit> <exif:ExifVersion>0231</exif:ExifVersion> <exif:ColorSpace>1</exif:ColorSpace> <exif:PixelXDimension>5472</exif:PixelXDimension> <exif:PixelYDimension>3648</exif:PixelYDimension> <exif:DateTimeOriginal>2022-12-16T19:03:06</exif:DateTimeOriginal> <exif:SubSecTimeOriginal>35</exif:SubSecTimeOriginal> <exif:SubSecTimeDigitized>35</exif:SubSecTimeDigitized> </rdf:Description> </rdf:RDF> </x:xmpmeta>
Copy link to clipboard
Copied
An update, it didn' happen with today's images. Rogue and random. Hope this can be resolved soon as I will be filing photos where the metadata REALLY matters.
Copy link to clipboard
Copied
Have you tried resetting LrC preferences per my post below?
Copy link to clipboard
Copied
I should have mentioned it in my first reply, whenever LrC does something funny, try a Reset of the Preferences.
What you did to restart the computer and the app is also a great idea for clearing up abnormal things.
Copy link to clipboard
Copied
After a very long conversation with Adobe support, the mystery has been solved.
The TL/DR version: LRCC Keyword hierarchies write all levels of the structure on export.
The longer explanation:
When I started tagging photos, I used LR and created keyword structures. LRCC will always export the upper level keyword with the lower level keyword. Although I stopped using LRCC to tag my photos, I am using some of the same keywords. So what happened, in LRCC I had created a structure that had an upper level keyword (CEBL in this case) with a "subordinate" keyword, "anthem". When I used the keyword "anthem" in Photo Mechanic, LR automatically appends the upper level keyword from the LR structure. It has no way of knowing that the keyword came from Photo Mechanic. Once I moved the "subordinate" keyword out of the structure, all is good. The takeaway - don't structure your keywords in LRCC because somewhere down the line it will bite you.
And know we all know.
Copy link to clipboard
Copied
Well, that's not completely correct either.
First of all, keywords are plain text. There is no inherent structure to them.
Second, there are no less than five namespaces (part of the file header) where keywords can be stored. Windows and macOS do it differently, Bridge and Lightroom do things differently, and there is a bug in Photoshop and Bridge where keywords can become out of sync in different namespaces.
Third, its COMPLETELY up to the reading/writing app to decide how to handle keywords. So an app may or may not write both parent and child tags, and can read either or both. The delimiter(s) can optionally be specified per app.
Now, is this a hot mess? Absolutely. I'd love to see standards unified so all the namespaces are used the same and so hierarchical keywords are handled the same in different apps. We see a LOT of posts on here about keywords not behaving the way that users expect.
I will say you are correct in the conclusion that if you are always going to want flat keywords, to leave them flat from the beginning.
Copy link to clipboard
Copied
Just to add: if there's a keyword you want to use within the Catalog (perhaps for workflow reasons, or for grouping your other keywords in some organised way) but you don't want that to show up in exports, you can change the properties of this keyword accordingly.
Regardless whether that is directly assigned to images, or indirectly happening by "parentage".
Also in a given keyword's properties you can disable the exporting of "containing" (parent) keywords - although those keywords would still export when explicitly assigned to an image in their own right.