Skip to main content
Inspiring
August 25, 2024

P: "Save Metadata to File" overwrites EXIF tag SubSecTimeOriginal

  • August 25, 2024
  • 22 replies
  • 1643 views

Issue: When I save metadata from Lightroom Classic via "Save Metadata to File", I lose subsecond EXIF metadata that was originally there in the file. This is new behavior, did not happen in previous versions (though I'm not sure exactly when it started).

 

Lightroom Classic version: 13.5 [ 202408062022-6258095b ]

System version: macOS 13.6.9

 

To reproduce:

 

1) Import a photo that has a subsecond creation date—for my test, I used an iPhone photo imported via mobile sync.

 

2) Check SubSecTimeOriginal from the command line:

$ -> exiftool -G -s -SubSecTimeOriginal /Volumes/Media/Photos/Import/Mobile\ Import/IMG_6067.HEIC 

[EXIF]          SubSecTimeOriginal              : 389

 

3) In LrC, run the "Save Metdata to File" command

 

4) Check SubSecTimeOriginal from the command line:

$ -> exiftool -G -s -SubSecTimeOriginal /Volumes/Media/Photos/Import/Mobile\ Import/IMG_6067.HEIC 

Warning: [minor] Bad format (16) for MakerNotes entry 14 - /Volumes/Media/Photos/Import/Mobile Import/IMG_6067.HEIC

 

(That warning does not seem directly connected to the issue, but may be a sign of something unexpected happening...)

 

22 replies

johnrellis
Genius
August 27, 2024

@Rikk Flohr: Photography, more testing by @dansmith21 and myself indicate the bug is in the sync between LR clients (Mobile and Desktop) and LR Cloud.  Thus this bug should be refiled accordingly, thanks.

johnrellis
Genius
August 27, 2024

Good detective work. I did some more testing, and EXIF:SubSecTimeOriginal is getting dropped by the sync protocol uploading from the clients (LR Mobile and LR Desktop) to LR Cloud. 

 

This path demonstrates that the IOS Camera App sets both SubSecTimeOriginal and SubSecTimeDigitized:

 

Camera App > Share Airdrop to Mac: ...Original and ...Digitized preserved

 

This path demonstrates that the LR Mobile app preserves both fields when it imports from the camera roll:

 

Camera App > LR Mobile > Export As DNG > Share Airdrop to Mac: ...Original and ...Digitized preserved

 

This path demonstrates that the LR Desktop app preserves both fields when it first imports from a file on the Mac:

 

file > LR Desktop > Share Export Original: ...Original and ...Digitized preserved

 

This path demonstrates that LR Cloud itself preserves both fields (LR Web doesn't use the sync protocol -- it uses an HTTP REST protocol to access the LR Cloud):

 

file > LR Web upload > LR Web download: ..Original and ...Digitized preserved

 

These paths demonstrate it's the sync protocol uploading from the clients to the cloud that's dropping SubSecTimeOriginal:

 

Camera App > LR Mobile > Sync > LR Web > Download: ...Original not preserved, ...Digitized preserved

file > LR Desktop > Sync > LR Web > Download: ...Original not preserved, ...Digitized preserved

 

* * * 

 

Tested with Iphone 11 Pro / IOS 17.3, Lightroom IOS 9.5.0, Lightroom Desktop 7.5 / Mac OS 14.6.1, Lightroom Classic 13.5.

Inspiring
August 27, 2024

Ok, looking at the same identical photo side-by-side, imported two ways: (1) directly (as in subseconds-test3), and (2) via mobile sync (as in subseconds-test2):

- The exiftool output is identical (other than directories and file modify/access times)

 

- The LrC "Date Created" field is different—the first says "2024-08-27T10:05:36.130-07:00", the second says "2024-08-27T10:05:36-07:00"

Inspiring
August 27, 2024

And here's a third test library:

 

https://www.icloud.com/iclouddrive/00cGMltBWAWrhkR6nCopUw2Ow#subseconds-test3

 

These images came directly from the iPhone without going through mobile sync. (Specifically: took the photo, hit the "Share" button in the Photos app and exported to my iCloud storage, then manually imported to my LrC library.) They show subseconds in the "Date Created" LrC field, and do not overwrite the SubSecTimeOriginal tag on "Save Metadata to File".

 

So it seems there's something about the metadata that is being corrupted by the mobile sync process? When these last shots show up via mobile sync (it's a painfully slow process), I'll try to compare their exiftool tags and see if I notice any anomalies.

Inspiring
August 27, 2024

Here's a second library, this one with some images that came directly through mobile sync from my iPhone (so, untouched by exiftool). Follow the steps, get the same behavior:

 

https://www.icloud.com/iclouddrive/0c4PlWAGhrVAY-JWaL7NP148Q#subseconds-test2

Inspiring
August 26, 2024

I noticed that the files had been modified with Exiftool 12.70, probably with the  plugin dansmith.customizations

 

Yep, that's my workflow to manage date/time metadata.

 

> Does the problem occur with virgin unmodified files straight from your Iphone?

 

I'll have to experiment more with the entire workflow to figure out at exactly what point the issue comes up, but it's not just one corrupt file or something—I've got whole batches of photos that came in from iPhone and ended up in this same state. (Good news, then, is that I should hopefully be able to reproduce the entire workflow again...)

johnrellis
Genius
August 26, 2024

Also, be sure to preserve the uploaded catalog at that Icloud link until Adobe fixes the issue. They generally download sample files until they start working on a problem.

johnrellis
Genius
August 26, 2024

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

 

@dansmith21, LR normally preserves EXIF:SubSecTimeOriginal in the catalog and uses it internally for sorting images in Grid view, though the only place it displays it is in the Date Created field of the Metadata panel.  In your test catalog (before doing Save Metadata To File), the fractional time isn't displayed for the two problem images, though it is for the third:

 

 

 

 

This indicates the problem is likely in reading the metadata from the file on import, rather than writing it back with Save Metadata To File.

 

Also, I noticed that the files had been modified with Exiftool 12.70, probably with the  plugin dansmith.customizations.

 

- Does the problem occur with virgin unmodified files straight from your Iphone?  I don't see any anomalies or standards nonconformance with the photos in the test catalog, but I recall in years past a few times some bugs where LR choked on files whose metadata was modified by other apps in ways LR wasn't expecting.

 

- The latest version of Exiftool is 12.93. Does the problem occur with that version?

 

Rikk Flohr_Photography
Community Manager
Community Manager
August 26, 2024

Updating Status - adding bug number

 

Rikk Flohr: Adobe Photography Org
Inspiring
August 26, 2024

Here's a test library:

 

https://www.icloud.com/iclouddrive/0b3ffGjOxRmVDHtdo6YhcvalA#subsecond-test

 

I did notice some intermittency while testing. But it seems I can pretty reliably reproduce by:

 

1) Download & unzip the library

 

2) Inspect the files

 

$ -> cd ~/Downloads/subsecond-test/Photos/Import/Test/

$ -> exiftool -G -s -SubSecTimeOriginal IMG_6067.HEIC IMG_6097.HEIC IMG_6175.HEIC 

======== IMG_6067.HEIC

[EXIF]          SubSecTimeOriginal              : 389

======== IMG_6097.HEIC

[EXIF]          SubSecTimeOriginal              : 747

======== IMG_6175.HEIC

[EXIF]          SubSecTimeOriginal              : 366

    3 image files read

 

3) Open the library, select all 3 files, edit metadata (I remove the "Review Place" keyword), do "Save Metadata to Files"

 

4) Inspect the files again

 

$ -> exiftool -G -s -SubSecTimeOriginal IMG_6067.HEIC IMG_6097.HEIC IMG_6175.HEIC 

======== IMG_6067.HEIC

Warning: [minor] Bad format (16) for MakerNotes entry 14 - IMG_6067.HEIC

======== IMG_6097.HEIC

Warning: [minor] Bad format (16) for MakerNotes entry 13 - IMG_6097.HEIC

======== IMG_6175.HEIC

[EXIF]          SubSecTimeOriginal              : 366

    3 image files read

 

johnrellis
Genius
August 26, 2024

@Rikk Flohr: Photography, please consider moving to Bugs -- I get the same misbehavior following the bug recipe with the sample catalog.