P: JPEG incorrectly treated as video sidecar

Report · Nov 02, 2019

[LR is treating a .jpg as a metadata sidecar of a .mov even when Treat JPEG Files Next To Raw Files As Separate Photos is checked. See here for a recipe to reproduce the bug: https://feedback.photoshop.com/photoshop_family/topics/lr-adding-metadata-from-jpg-into-mov-file-on-...]

Background
After a phone change, I ended up with files with the same filename (except file type) residing in the same image folder (JPG + HEIC/MOV)

On import of all files into LR, I saw that the order of the files was totally wrong (when sorting on capture time)
Some files were months off and with 500+ images in just one import

Spent a great deal of time debugging this and found that LR seem to add/overwrite metadata in .MOV files (which by default is lacking many fields usually present in images) IF on import, there exists a JPG with the same filename in the folder. If so, much of the metadata from the .JPG is copied to the .MOV file!? Doing an import w/o the JPG present, no fields are touched in the .MOV

Wrt to create time, which triggered the issue I saw, I can see no good reason for LR not to read the file system's FILE MODIFICATION DATE/TIME on the .MOVs, which in this case was correct.

Why should you take the metadata from some other file?

Problem is very easy to reproduce

Metadata on input files

RackMultipart201911036300bwdxe-7e64eeda-7864-4f49-9374-e2b5e4cd7b44-429703441.jpg

Importing JPG
RackMultipart20191103358311qjx-285bd150-4eb8-4f47-8a30-99652a8e0b15-1663372586.jpg

Importing MOV from folder with JPG
RackMultipart201911031120811vw-5288c513-1823-4cbc-927f-21168677f8d4-1858571390.jpg

Importing MOV from clean folder
RackMultipart2019110321171u7ok-3fab7dd5-5e66-44a0-a2a5-ab4ffacd3da9-1479208658.jpg

Running system
Mac OS Catalina 10.15.1
LR Classic 8.4.1
Done in a completely fresh and new catalog
And easy to replicate (happens every time)
JPEG next to RAW as sep. file = YES

Report · Nov 03, 2019

Concisely: When the option Preferences > Treat JPEG Files Next To Raw Files As Separate Photos is checked and A.MOV and A.JPG are imported, A.MOV gets important metadata (capture date and other fields) from A.JPG, even though "jpg" does not show up in the Sidecar Files field of the Metadata panel for A.MOV.

To reproduce this bug:

1. Start with two files in the same folder, A.MOV and A.JPG.

2. Use ExifTool to set EXIF:DateTimeOriginal of A.JPG to something much different than the capture date and file modified date of A.MOV. Also set EXIF:UserComment to "Hello world".

3. Uncheck the option Treat JPEG Files Next To Raw Files As Separate Photos.

4. Import A.MOV and A.JPG at the same time.

5. Note that the filename above the thumbnail in grid view shows A.MOV+JPEG, the Sidecar Files field in the Metadata panel contains "jpg", the capture date of the .MOV is the date set in step 2, and the User Comment field contains "Hello world". This is correct behavior.

6. Remove A.MOV and A.JPG from the catalog.

7. Check the option Treat JPEG Files Next To Raw Files As Separate Photos.

8. Import A.MOV and A.JPG.

9. Note that the two files are imported as separate files and that "jpg" does not appear in the Sidecar Files field for A.MOV -- this is correct. However, A.MOV still has the capture date set for A.JPG in step 2, and its User Comment field still says "Hello world". This is incorrect.

A workaround is to give the .jpg a different name before importing, e.g. rename A.JPG to A.X.JPG. Alternatively, move the .jpg into a different folder before importing.

Report · Nov 03, 2019

"Why should you take the metadata from some other file?"

This is by design. In past years, some cameras recorded .jpg files as metadata sidecars for videos, putting all the important metadata (and a convenient frame preview) in the .jpg. I don't know if any current cameras still create .jpg files as sidecars. But many cameras (including my Gopro 4 and Sony RX100 V) do create sidecars with the extension .thm, in which the .thm file is just a JPEG with a different extension.

As an aside, I think it's a bad design that the option Treat JPEG Files Next To Raw Files As Separate Photos is serving double duty, controlling two separate behaviors:

- Whether JPEGs next to raws are treated as a single entity. In this situation, the JPEGs are alternative renderings of the same image produced by cameras, which many users like to use in conjunction with the raw.

- Whether JPEGs next to videos are treated as metadata sidecars. In this situation, the JPEGs are most definitely not alternative renderings of the video, and their only purpose is to contain metadata.

These should be separate options.

Report · Nov 03, 2019

"Wrt to create time, which triggered the issue I saw, I can see no good reason for LR not to read the file system's FILE MODIFICATION DATE/TIME on the .MOVs"

When LR doesn't find a capture date stored in an industry-standard location in a video's metadata (in the video file itself or in a sidecar), LR does indeed use the file modification date as the video's capture date.

However, there are long-standing bugs with how LR does that, leaving the catalog inconsistent. Despite a couple attempts, Adobe has never managed to correctly fix those bugs. But there are workarounds for that too.

Report · Nov 03, 2019

Thanks a lot for the clarification and assistance. I'm completely new to LR so I'm eager to understand it better.

So you are saying that step 5 above would be the correct behaviour. You might be right about that but I'm not sure I understand why just yet 🙂

If that is correct, it feels like the JPG is the metadata source for the RAW and that metadata is read from JPEG "into" the RAW. Conceptually, I saw the RAW as master and the JPG as one (already produced output file from that master), not as a metadata sidecar similar to a pure XMP file. That an XMP affects the metadata (stored in LR after import) for RAWs is easy to grasp, it is its sole purpose, but it is harder to understand why a JPG should do so. My first understanding after reading about this online, was that "treat JPG as sidecar" only meant that it tags along (on file move done in LR etc) not that it actually affects anything in relation to the RAW file...

What then would be the default/correct behaviour for LR for a RAW/JPG pair from camera where the RAW is first modified in some external program that results in an XMP? Would the XMP have precedence over the JPG during the import?

As you write, the settings related to this need to be improved, or at least clarified so that one understand that unchecking the "separate photos" means JPGs are a source of metadata for RAW
Highlighting what counts as RAW files would also be beneficial. I saw MOVs more as JPGs than similar to RAWs.

Anyhow, if this is correct, its only for me to learn and adapt. More importantly though is that "treat as separate files", means exactly that, also for MOV+JPG and the metadata in those files.

BR

Report · Nov 03, 2019

The metadata storage in a JPG is more standard than the metadata storage in a RAW or MOV, so LR will use the JPG for the source of the metadata, sometimes.

Not sure which takes precedence if there is both a JPG and an XMP file.

Report · Nov 03, 2019

JPEGs are treated as metadata sidecars only for videos, never for raws. So when you import a raw + JPEG pair with Treat JPEG Files Next To Raw Files As Separate Photos unchecked, LR reads the metadata from the .xmp sidecar (if present) or the raw itself (it there's no .xmp), but never from the JPEG. Note that LR lists "jpg" in the Sidecar Files field of the Metadata panel, but it isn't using the .jpg as a source of metadata for the raw.

LR treats JPEGs as metadata sidecars for videos because that's how some cameras do it (or did it).

Report · Nov 16, 2019

Thanks for the clarification!

Report · Nov 16, 2019

On bullet 9 above, what can we expect from Adobe on this? How can we tell if they recognise this a bug and put it in the backlog?

Report · Nov 16, 2019

When (or if) an Adobe employee examines this topic, then if the bug is reproducible (or if not, sufficiently severe with many people reporting similar symptoms), they'll mark it as "Acknowledged", submit it to their internal tracking system, and tag this topic with the tracking number. It can take a while for an employee to examine a topic, and while they get to many or most, they don't appear to get to all of them. I think they prioritize partially based on the number of Me Toos.