Author Topic: PM metadata edits from two cameras won't all transfer to Lightroom  (Read 1653 times)

Offline mckeephoto

  • Newcomer
  • *
  • Posts: 1
    • View Profile
I'm running Mac OS Big Sur 11.5.2   PM Version 6  Build 6424  I've reproduced this issue on multiple versions of Lightroom.

I spoke with someone at CameraBits and they told me they believe the problem is with Lightroom, but so far Adobe has been no help.  I'm hoping someone here knows the solution.

I shoot sports and use multiple cameras.  I've used this same workflow without a problem for years.  I ingest multiple cards of jpegs with PM into one folder on my local SSD.  I go through the images in PM, add color class, cropping, and keywords/captions.  I then go to Lightroom and "Add" all of the photos into my catalog.  Lightroom has stopped reading my color class and cropping from images from my Nikon D3s camera.  The keywords and captions show up fine.  It works fine with all of the images from my Nikon D5, which are processed exactly the same way as the others.  I know PM is writing the info into the XMP because it works for the D5 files.  Also, after I've added the photos into Lr, if I go back to PM and change the color class or cropping to one of the D3s photos, a little arrow appears in Lr that indicates the metadata has changed.  If I click on "Read Metadata from file" or click on the little arrow and choose "Import settings from Disk," nothing happens...nothing changes.  It still can't see my color classes or crops.  If I make a change to a photo from the D5 and read metadata or import settings, it changes.

Any ideas?  How can images from a certain camera (I've even tried using different memory cards and it still happens) somehow make it so Lr can't see metadata changes made in PM?

Thanks,

Josh

Offline ahoward

  • Camera Bits Staff
  • Hero Member
  • *****
  • Posts: 973
    • View Profile
Re: PM metadata edits from two cameras won't all transfer to Lightroom
« Reply #1 on: April 28, 2022, 10:32:06 AM »
For anyone reading this in the future: This particular issue was due to a bug in build 6424. A workaround was to revert to build 6375, and a fix has been issued in build 6474