I've been getting the "Please restart Bridge to use Photoshop options" frequently since one of the recent updates, but I had never seen it before.  I have both Bridge and Photoshop open most of the time and things will be working fine for awhile...and then suddenly I start getting the message, usually when I try to use the Image Processor.  Note that I'll still be able to open an image in ACR and it will open into Photoshop even after getting the popup, but I will not be able to use Image Processor until I restart Bridge. Perhaps related, after closing Bridge, if I select to Browse Bridge from Photoshop, it fails to open on the first attempt, but will open on the second. Windows 11 Home 24H2, Bridge version 15.0.2.432, ACR version 17.2, Photoshop version 26.4.1 Release ... View more

I'm still seeing the issue intermittently with the latest version 17.2.  I'm not sure why it *sometimes* gives me the icon to manually reposition the source...because, when it works, it seems to stay working.   When I don't get the option, I can't find any *trick* to get it to work.  I've tried disabling hardware acceleration, but that doesn't make a difference.  Note that I can always reposition the target and us the option to refresh the source, but I usually want to pick a source area when I use the heal tool. ... View more

Thanks Adobe, looks like 14.1.1 fixed the issue I was having too! ... View more

It appears every edit I made since Lightroom udpated (from 14.0.1 to 14.1 on Windows 11) earlier this morning has automatically bumped the capture time in my photos.  Fortunately I can simply "Revert Capture Time to Original" to fix, but the auto-capture-time-change behavior was driving me mad (especially when I was filtering photos to be from a specific day...and they'd disappear as soon as I made any adjustments).  I think the time stamps were being adjusted ahead by 8 hours...which sorta makes sense since I took the photos in Morocco with my camera properly set to that timezone, but I'm editing them back home (on Pacific Standard Time).  Technically, I think the offset should have been 9 hours...8 hours would be the difference from UTC to PST, but regardless I did NOT want the capture time to be adjusted at all!  I can't find any setting that would enable or disable such behavior.   I've rolled back to 14.0.1 and the problem is no longer present, so I am assuming this is just a bug in the latest update. ... View more

I first encountered this on an image with no heal or clone adjustments. ... View more

I just started getting this issue after updating to ACR 17.  Never had it happen before, probably because I had stuck with ACR 16.2 (due to unrelated issues that started appearing with 16.3 and more recent updates). ... View more

What's annoying is that Adobe auto-updates ACR without me knowing...and, just when I think I'm ready to archive a batch of JPEGs, I find a bunch of xmp files amongst them.  I'm just glad I kept the 16.2 installer on my machine so I don't have to hunt for the link each time it gets updated. ... View more

I too upgraded to 16.5 hoping it addressed the issue I saw starting from 16.3 and initially thought the jpg xmp sidecar issue was fixed, but I think you found the piece of the puzzle I hadn't.  Using Adobe's generative AI before saving the JPG seems to be what causes the JPG to produce xmp files.  Even if you remove the generative AI layer from the layered file (without merging it down) and save a JPG, the resulting JPG will produce xmp files on further metadata edits.  I'm rolling back as well, but to 16.2. ... View more

The bug is that the Bridge/ACR combo has started generating xmp files for some JPEGs. Here is my default usage of Bridge:  I use Bridge to open RAW format files (from my DSLR/mirrorless cameras and Android phones), any Photoshop edited tifs, and the occasional original jpg from a camera/phone within the Adobe Camera RAW dialog to make non-destructive edits before bringing these "source" files into Photoshop (most of the time, I'm just using the image processor to bake out the adjustments with some final automated actions) before saving the "final" jpegs that I'll upload to my photo sharing site.  In this workflow, I absolutely want ACR to open the original jpeg files...and I actually do not usually re-open the "final" ones because I don't want to have them go through an additional round of lossy compression.  I've been using this technique for two decades without any problems.  Image processor support is one of the reasons I still favor a Bridge based workflow to Lightroom (I also use Lightroom Mobile and Classic, but I prefer to remove my files from my Lightroom libraries and finish my edits from Bridge)...plus I prefer to manage my own libraries because I'm constantly shifting where I store my files based on where I am in my editing/finishing/archiving process.   Most of the time, I'll touch the "final" jpegs to make last minute edits to metadata...things like the captions I had set in the description field, modify my copyright info URL, change the label color, etc.  This is what I tend to do once I have a whole collection of images I plan to share in my online gallery...because I tend to work out the final sequencing once I have all of the "final" jpegs altogether in one place (and I'll want the captions to flow from one image to the next).  Most of the time, Bridge works as expected...where metadata edits, whether made within the ACR dialog or within the metadata fields in Bridge, stay with the JPEG file.  The bug that appears to have been introduced when Adobe Camera RAW 16.3 or 16.4 is installed is that, for whatever reason, Bridge starts generating .xmp files for those jpegs when I make those final edits.  If I delete those .xmp files, my last minute changes to the jpegs go away.  Please understand that the problem completely goes away if I reinstall Adobe Camera RAW versions 16.0, 16.1, or 16.2...and the problem comes back immediately when I update past that.  This is why I am nearly 100% sure the bug has to be within Adobe Camera RAW.  Rolling back only ACR is all that it took to make the problem go away...I'm still using the latest version of every other Adobe product. ... View more

As far as I know, by default, Bridge uses Adobe Camera Raw to modify JPG metadata.  I haven't directly opened a jpg file from Bridge in Photoshop without it first going to the camera raw dialog in ages, so I just assume that's the usual workflow for most.   Either way, all of these JPGs were generated first by processing RAW photos (CR2 / CR3 files from my Canon cameras, DNG and an occasional JPG from my smartphone). ... View more

As I mentioned, it's specific to 16.3 or 16.4 versions of Adobe Camera RAW (which Bridge uses to open / edit RAW files).  It is not present in 16.0, 16.1, or 16.2.    I was previously discussing this issue in another thread, but I wanted to post it as a bug.  In the other thread, someone posted how to download previous versions of Adobe Camera RAW for Mac (and I figured out where to find the Windows equivalents). ... View more

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. ... View more

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.  ... View more

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

I rolled back to the previous version of Bridge becuase of this very reason.  RAW files not opening in Photoshop (after ACR) consistently wasn't nearly as annoying as this...but both issues completley messed up my usual workflow. ... View more

I've been having similar issues with Canon RAW (CR3) files since the latest update.   I sometimes can't open them in Photoshop from Bridge's Adobe Camera RAW module (v15), but it doesn't always give me the "Could not open (file name) because the file-format module cannot parse the file" dialog...sometimes it doesn't do anything at all.  However, I have been able to open every single one of the files if I first drag the file's thumbnail from Bridge into Photoshop (which still opens the same version of Adobe Camera RAW)...which makes me think something weird is happening with the hand off between Adobe Camera RAW and Photoshop. Either way, try dragging from Bridge to PS and see if that wokraround works for you. ... View more

I just realized that I'm encountering this very issue with Bridge (12.0.2.252) and now I can't use it at all, not even for doing something as simple as editing descriptions in 12MP DNG photos I captured with my Galaxy S21.  Bridge suddenly becomes a CPU and memory hog whenever I deal with my smartphone pics.  I thought MAYBE I could get around this by enabling the option that always uses xmp sidecar files with the DNGs, but it didn't make a  difference. I got the idea to try the latter because I noticed I don't have ANY issues with performance when handling my Canon EOS R5's 45 megapixel CR3 files.  How is it that Bridge is a much more usable piece of software with file sizes two to three times larger? ... View more

Ok...it turns out that this particular photo was from my mirrorless camera...which I may have uploaded from my phone (because I did copy some from my camera to my phone for more immediate work) or could have trasferred directly from image.canon (where I initially upload photos from my camera when connected to WiFi).  The latter automatically sends the RAWs to Adobe Lightroom over the cloud (which is a great convenience).   This is actually the first instance of one of my mirrorless camera's CR3 photos disappeared from Lightroom Mobile's "All Photos" after an edit.  Up until now, it had only witnessed the DNG and JPG that were added to an album disappearing from the "Album" and "All Photos" sections of the app.  As mentioned in a previous comment, I found it in the "no keywords" smart collection of Lightroom Classic on my PC.   AFAIK, there is no way to see smart collections from the mobile app... So, as far as the original CR3 file as copied to the phone the goes, in this particular case it's not like it actually vanished from the phone after all. I was just looking for the wrong kind of file of photo.  And it isn't as bad as the phone photos since I still have the originals on their memory card (they only stay on image.canon for 30 days). ... View more

Okay...I found the latest missing photo in the "Without Keywords" Smart Collection using Lightroom Classic on my PC.  But why did it drop out of my album and off my phone? ... View more

I can now confirm at least one (possibly more) photos that I had added from my Android phone to Lightroom Mobile have completely disappeared after making edits.  There was one I thought I had exported and planned to share today, but it was nowhere to be found in the AdobeLightroom folder on my phone.  The original no longer exists in Lightroom Mobile's library, it is not synchronized with my PC's Lightroom Classic, can't find it in the web version of Lightroom.  The original dng (which I had added to Lightroom) and the jpg that got concurrently created when I snapped the photo with my phone both do not appear within DCIM\Camera folder on my phone (where all of the other originals exist), nor do they appear in the Gallery.  I cannot find the file in the trash.  It's like it never existed.   I have a ballpark idea of the filename (which is based on the capture date).  It does NOT come up in searches.  It's like the file never existed! And since I made those edits when my computer was not on, I don't see it apper within the "Most Recent" smart collection (which was my way of fixing the previous photos I mentioned that stopped appearing in synchronized albums). How can this be?  Is there ANY way to search the history of syncrhonized folders within a Lightroom album on Adobe Creative Cloud to find files that may have been in the cloud but are no longer associated with any Lightroom album? ... View more

So it looks like the color space missing issue is isolated to hardware encoded h264 files. Fortunately, software encoding in Media Encoder is a valid workaround. Even Premiere Rush on my Galaxy S21 handles this properly.   Is this an issue with the implementation of hardware encoding in Adobe Media Encoder?  Is this a hardware issue with my specific nVidia GPU (RTX 2070)?  Is it possibly a driver issue?  Who can I reach out to for help? ... View more