Skip to main content
Known Participant
November 21, 2023
Question

Sidecar Files (JPEG) to TIFF files are no longer recognized as such

  • November 21, 2023
  • 2 replies
  • 653 views

When exporting TIFF files as JPEG in the same directory and synchronizing that folder, the JPEG files are no longer recognized as sidecar files to the TIFF files.

 

Version: 13.0.1

Last working: 12.5.1

System: Windows 10 22H2

 

Steps to reproduce and behaviour:

  1. Create a folder and put some TIFF files in it (e.g. img1.tif, img2.tif, img3.tif).
  2. Create a new catalog and import that folder.
  3. Export the TIFF files as JPEG files in the same directory.
  4. Run "Synchronize Folder..." from the context menu: The Synchronize Dialog will show "Import new photos (3)" instead of "Import new photos (0)" as expected.
  5. The following Import Dialog will show no new photos to be imported as expected. Click "Done."
  6. Back in the Grid View the filename is shown as img1.tif (expected: img1.tif+JPEG) and the Sidecar Files list in the Metadata Panel [EXIF and IPTC] is empty (expected: "Sidecar Files jpg").

 

Remarks

  • A similar (broken) behavour applies to PSD and PNG files. However, the Import Dialog shows the sidecar JPEG files as new/separate files to be imported. For those files, this behaviour exists since I consciously use it (~ Version 11).
  • When importing TIFF files with the associated JPEG files present during import, the JPEG files are correctly recognized as sidecar files and as such are not imported separately. Also, the JPEG files are listed as sidecar files in the Grid View/Metadata panel
  • Impact: When moving images to a different directory, the exported JPEG files are left behind in the original directory.

 

This topic has been closed for replies.

2 replies

Community Expert
November 23, 2023

Why are you trying to use jpegs as sidecars to tiff and psd, png files? Those file types store sidecar info in their metadata sections. I wish Lightroom supported actual sidecars to those filetypes but it uses the internal metadata sections in the actual metadata of the files and has done so since lightroom's inception. It only uses sidecar files (whether xmp or jpeg) for proprietary raw files. For dng, it also stores the sidecar info in the file itself. I know there was a bug some time ago where for tiff it recognized jpegs with the same name as sidecars but this happened because there are a few cameras that use the .TIF extension as their raw format and they fixed that bug finally (some people complained their jpegs disappeared) and now it only does that if the tif is actually a raw file from those cameras. 

GoldingD
Legend
November 22, 2023

Why would the be sidecar files? they are different files.

And JPEF are never sidecar to raster images like TIFF files, they can be to RAW files, but only if they were the embedded JPEG within the RAW data (upon creation in camera)

 

Camera69Author
Known Participant
November 23, 2023
@GoldingD

Sidecar files are – by definition – files with the same base name but
different extensions as the root file.

So, when you rename/move/delete the root file, you want to
rename/move/delete the logically associated sidecar file(s) as well –
independent of the file format of the root file.

Currently, LrC recognized only raw files as root files. So, when you
rename/move/delete your PSD, PNG, TIFF (, etc) root file, any associated
sidecar file (like .xmp, .xmp_original, .jpg, .bak, etc) is left behind,
screwing your file organization: You have to rename/move/delete the
associated sidecar files manually from outside LrC, risking to forget or
miss some files and making mistakes. This can be particularly painful,
when you batch rename several hundreds of your files: You have you
rename each and every sidecar file (whose root file is not a raw file)
manually, with the risk of typos etc.
Community Expert
November 23, 2023

I can see this conception of the job of sidecar files, as a bit problematic. A camera Raw+JPG pairing, I think we can all agree, is two files with the same origin and of the same nature. It makes sense both are affected by the same operations done from within the Catalog. But in normal LrC usage a TIFF would be a derived file with a different creation history.  It's not so clear that you'd always want that and say a JPG with the same base name, to receive the same operation.

 

Furthermore, an export and a working file from which an export is made, are inherently of different natures from each other. This method of exporting to the same folder as the original and then syncing the folder is unnecessary: you can export selecting the option to "import to this catalog". Personally I see no reason or benefit to doing that re-import in any case: like many others, I regard exports as disposable ephemera. Not least, practically, to reimport an exported file will impair your ability to later repeat the same export, to reflect updated editing.

 

Also an export may require to remain on disk even after the same-name imported file has been removed from a Catalog, whether or not that removal involves file deletion. Personally I distinguish exports under a different file naming - I prefix the capture date - thus allowing a camera JPG to be exported as JPG and tell the difference. and even, to coexist within the same folder. I do recommend having exports not in the same folder though: LrC imported files and derived exports may demand different management. Of course I accept attitudes do vary on all of this.

 

Also: multiple Catalogs may refer in common to the same body of files, and the consequences of file 'set' operations of the sort discussed, may only become apparent in these other Catalogs much later on, or else simply get missed altogether.

 

Effectively, this functional locking-together of multiple files of differing natures, seems to me to offer more downsides than upsides. That's coming from the perspective of someone who regards all subsequent moving around and renaming within the file sytem, as an avoidable inefficiency. LrC permits those who think along those same lines, to simply forego file operations altogether - aside from the necessary initial ingesting from camera card.