Adobe Bridge - can I tell it to always use sidecar XMP files for RAW formats only?

[eric_brb]

Due to how much larger DNG files have gotten with higher megapixel smartphones and with DNGs being created with AI denoising of other camera RAW formats, I recently modified my Camera Raw Preferences so that DNG files "Always use sidecar XMP files".  What I didn't expect is to see Bridge create xmp sidecar files from JPG format images.  Is there a setting so that it never creates a sidecar for a JPG?

Sometimes I'm just updating the caption or copyright URL on the JPEGs before uploading to my photo hosting site, so I really don't want it placing that info in a separate sidecar file (which don't get read by the site's uploader).

Also, once you have the sidecar files, is there a quick / bulk way to embed the xmp sidecar data into their respective JPG files from within Adobe Bridge?

[gary_sc]

DNG,  JPG, and TNG files (not PSD) are all container files. That is, they act like folders to "contain" the various metadata files. 

But I think you may be chasing a false premise here. A 20 MG DNG and a 25 kb file will have the same storage size as the 20,000025 file with the xmp data. Separating the two will not make a difference. 

The JPG with xmp support has always been a bit of a tricky issue for many people: if you make adjustments to a JPG image and send that to someone who doesn't have Adobe Camera Raw themselves, they will see the JPG image without any of your adjustments. So, if you adjust a JPG file, you must do a Save as… before sending it out or sharing it on Facebook or other social media. 

Also, as you observed, captions, copyrights, keywords, etc., are all stored in the metadata as well. 

Similarly, if you move a JPG, TIF, or DNG file of its folder without the XMP file, it will appear as it did before adjustments. 

So, always saving XMP files outside of the files themselves really doesn't save you anything and potentially increases your frustration. And, I suggest you get two large external hard drives if your file size concerns you. You might consider doing what I do:

Keep in mind that any hard drive can fail. "There are two kinds of hard drive users. Those who've had a hard drive crash and those who've not had a hard drive crash YET.

Over the years, I've had several hard drives crash, and yes, I've lost stuff. Here's what I now do:

I have a 4 TB drive that holds all of my images and many documents. I have a 2nd 4TB drive that I use to back up my first drive. I manually do this at least once a week or more often if I've done a lot of work.

I have a 3rd 4TB drive I use for Apple's Time Machine.

I also use a cloud service in case the house burns down. Am I paranoid? No, just a realist. In a worst-case scenario, I would not lose much, at worse, sometimes. 

[Note: the 4TB is entirely based on what I need. Your needs may demand more or less hard drive space. Whatever you think you need, double it. Oh, the backup drives do not need to be SSDs or anything fancy or fast, just reliable. Also, look for backup software that can update your data as opposed to replacing your data. If you're on a Mac, I strongly recommend ChronoSync. If you're on a PC, I'm sure someone can make recommendations.]

Good luck!

[eric_brb]

The issue with file sizes is more of a workflow issue than one of increasing an individual file's size.  I auto-synchronize files that get touched in my work folders via cloud services (like CloudStation to sync my PC with my NAS which then syncs with Dropbox online...I think I'm more paranoid than you about data loss in this regard).  If I touch data embedded within a DNG everytime I make a small adjustment to RAW processing settings or to simply edit a caption, my cloud applications re-upload the whole DNG (in some cases, files that are over 100MB).  If I am doing a quick adjustment that affects more than a thousand such files within a folder, I start to choke my upstream Internet bandwidth and make a significant dent in my data cap for the month (I'm switching to fiber soon to get around some of these issues).  If that data is in an xmp file, I'm just touching tiny text files when I make such adjustments...a non-factor.  I never share DNG files in the same way that I never share CR3 files from my mirrorless camera....they're my digital negatives and I think of them as read-only data for the most part...so I really don't need the metadata to be embedded within them (even though that used to be my preferred method of working with DNG files).

I usually think of JPEGs as the final output from my RAW processing.  I don't usually touch them for RAW processing unless the source file was a JPG (i.e. from a smartphone) in which case I do tend to treat those files more like RAW files.  But caption in the description, copyright / URL, capture date, etc....those edits I need to stay embedded within the JPG files.  I often don't even write my captions until I have the final JPGs since I often only write them based on the context of other JPG images I share (i.e. in an album on a photo hosting site...a site that reads the captions and copyright info from the JPG files themselves).

[gary_sc]

Hi, @eric_brb, (sorry I was gone all day yesterday, so I could not respond).

Looking at this extra bit of information on your workflow, I now have a better understanding of your issue. Yes, you are correct, for your purposes separating the xmp data from the image is more efficient.

One of the things photography teaches you is that everything is a compromise. This is yet another example.

And, as such, the xmp files can either be stored within the image file or not. I know of no way to have both on a file-type basis nor do I know if there's any way to attach or remove them on an image-by-image basis.

I do have one thought for you: a variation on your workflow: Is it possible to have one folder for your "final" images and, from that, a second folder for your posting images? That is, as you work, have your processed DNG/JPG files go to folder "A," and once you're happy with them, have a second folder, "B," that takes the final image for posting on your website.

I use LRC for any images I'm posting to a Collection, and internally, things are blazing fast. I can make a change to a file and then see the results on the web's presentation on that file within half a minute—far less time than it would take for the whole file to upload. But then, my files presented on Lightroom Web are not a formal photographer's website. (Again, choices.)

Oh, one other item for you to consider: if you download Lightroom Mobile to your phone, you can have DNG images from your phone. Take them on your phone, and they will appear in Lightroom Desktop. And, if you want, these can directly be transferred to Lightroom Classic—just a thought.

Oh, wait a minute: this brings up one more thought for you: If you move from Bridge to Lightroom Classic, you can have all of the xmp data stored in LRC's database and not in the file itself. Plus, you have a full-strength DAM for your images—just (another) thought. I know many people do not like changing ships in the middle of what they are used to.

[eric_brb]

I think what's being missed here is that I had a workflow I liked very much and something changed that is starting to break it.  And I'm still thinking that the xmp sidecar with jpeg file issue is an abberation as I've been able to modify some jpeg captions without them generating a sidecar file.

I actually start in Lightroom Mobile, sync to Lightroom Classic, and then move my files OUT of Lightroom managed folders (I've never liked working with Lightroom libraries and don't want to risk it getting corrupted...again I consider the sidecars far more ideal) to my preferred work folders (which are the ones that auto sync with my NAS and then Dropbox) .  My organization does involve separate folders for the "source" whether they are RAWs or JPGs files and the final JPGs are renamed in a way that allows me to use names to sort them for how I plan to upload the photos to my photo hosting site (which actually takes them directly from Dropbox).  And then I archive these folders to Amazon Photos (to archive the RAW files), move everything out of the Dropbox synchronized folders.  At one point I archived the RAWs to optical disks, but that became not realistic ages ago.

Lightroom is great for quickly getting things started, but I have long preferred finishing my processing via Adobe Camera RAW and Photoshop, especially with how I integrate use of AI enhancing tools from both Adobe and Topaz.

This afternoon I got setup with fiber with 10x faster upstream and no data usage caps, so keeping the data embedded within DNG files might not be so bad moving forward.

[eric_brb]

I'm actually starting to think the xmp jpg sidecar issue is a bug related to the latest version of Adobe Camera RAW.  Even if I set the preference to embed the info in DNG, it still creates sidecar files for jpg files...and I'm pretty sure I hadn't seen this happen before the 16.3 update of Adobe Camera RAW.  I tried using Bridge 2023 to see if certain issues persist...and I see that it is still using Adobe Camera RAW 16.3. 

I also noticed the "Constrain crop" checkbox no longer has any affect...which is really going to make processing photos rough until it is fixed.

Unlike the applications, I don't see an option for installing an older version of Adobe Camera RAW other than 14.5 (which is ancient).  Ugh. 

[Elise_Claire · Accepted solution]

Good call on it being Camera RAW instead of Bridge - I was rolling back Bridge over and over with no effect. I was able to download and install Camera Raw 16.0 (went back a couple versions to be sure) by modifying the download URLs on the 14.5 links here. After restarting my computer I went back into Bridge (14.1.0) and was able to apply/edit metadata on JPGs that were creating the XMP sidecar files before, and no XMP files were created.

For Mac I used https://download.adobe.com/pub/adobe/photoshop/cameraraw/mac/16.x/CameraRaw_6_0.dmg

If it works the same for Windows, it should hopefully be https://download.adobe.com/pub/adobe/photoshop/cameraraw/win/16x/AdobeCameraRaw_x64_16_0.exe 

Hope that helps!

[gary_sc]

@Elise_Claire, Brilliant! 

I hope this is it! And it's a great deduction that this might be the issue.

[Elise_Claire]

I didn't realize you were on both threads, oops! I posted on the other too, hopefully it'll help those folks too!

[gary_sc]

Hi, @Elise_Claire. No problem. This was such a weird issue that it's good to have it in multiple locations for people to find. I always update to the latest ACR, which is probably why I did not encounter this issue.

[Elise_Claire · Accepted solution]

For anyone else who comes across this, sorry I made a typo in the Mac url - it should have "16_0" not "6_0" near the end, but can't figure out how to edit my other post. It should be like this: https://download.adobe.com/pub/adobe/photoshop/cameraraw/mac/16.x/CameraRaw_16_0.dmg

[eric_brb · Accepted solution]

Thanks for figuring this out!  I just had it start happening again with a few (but not all) jpg files so I'm glad I revisited this thread...rolling back to 16.0 definitely worked on those files.

The windows version of the link is actually: https://download.adobe.com/pub/adobe/photoshop/cameraraw/win/16.x/AdobeCameraRaw_x64_16_0.exe

16.1 and 16.2 work as well.
https://download.adobe.com/pub/adobe/photoshop/cameraraw/win/16.x/AdobeCameraRaw_x64_16_1.exe

https://download.adobe.com/pub/adobe/photoshop/cameraraw/win/16.x/AdobeCameraRaw_x64_16_2.exe