P: JPEG incorrectly treated as video sidecar

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.

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?

Thanks for the clarification!

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).

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.

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 
  

"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.

"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.

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.