P: Automatically Write Changes To XMP can't be used with Denoise on large numbers of photos

[johnrellis]

The new implementation of Denoise in LR 14.4 has several bugs with Automatically Write Changes To XMP. As a result, it is not practical to use that option with large numbers of denoised photos.

- The Denoise data gets copied into the main .lrcat database file, making it two orders of magnitude larger and defeating the purpose of separating out computed AI data into the .lrcat-data file. Surely not intended by the original architects of the .lrcat-data file.

- Whenever LR is saving XMP for a large batch of denoised photos, e.g. after the initial application of Denoise or after applying a batch change to other Develop sliders, it isn't possible to switch photos in Develop until the saving completes, which can be minutes for large batches.

- After saving XMP has completed, spurious "Saving XMP for n photos" messages appear in the upper-left corner, even though the .xmp sidecars aren't actually being modified. The incorrect message itself is innocuous, but it likely is a symptom of more serious internal bugs.

To reproduce on LR 14.4 / Mac OS 15.5:

1. Download and open this LR catalog containing 100 raws to which Denoise has already been applied (beware, it's 2.8 GB):

https://www.dropbox.com/scl/fi/61bsi0xh7xdgpewnjt20u/denoise-xmp.2025-06-28.zip?rlkey=ipwzy7azjnhzoj...

Observe the sizes of the various files/subfolders:

denoise-xmp.lrcat: 4.1 MB

denoise-xmp.lrcat-data: 728 MB

pics (containing the raws): 2.1 GB

2. Open the first photo in Develop and make the filmstrip visible.

3. Set the option Catalog Settings > Metadata > Automatically Write Changes To XMP. Observe in the upper-left corner the message "Saving XMP for n photos".

4. Click on random photos in the filmstrip and observe that they won't appear Develop Loupe view until the saving of XMP finishes (incorrect). (See the attached screen recording "saving.mp4".)

5. After the metadata is fully saved to all the photos, observe these sizes:

denoise-xmp.lrcat: 744 MB (incorrect)

denoise-xmp.lrcat-data: 728 MB (correct)

pics (containing the raws): 3.0 GB (correct)

Saving metadata has copied the Denoise data into the .xmp sidecars in the "pics" folder (correct), but it has also copied into the main .lrcat catalog database (incorrect).

6. Open Finder on the "pics" subfolder and observe there are 100 .xmp sidecars, all larger than 6 MB, indicating that the metadata has been saved for all the photos (correct).

7. Sort the Finder window by Date Modified.

8. In LR Develop, select the first photo. Then use the right-arrow key to move to the next photo, about once per second.  Observe that "Saving XMP for n photos" appears in the upper-left, and n is increasing as you proceed through the filmstrip.   

9. Stop using the arrow key and wait until "Saving XMP" disappears. Observe in the Finder window that no .xmp sidecars have been modified. (See the attached screen recording "navigating.mp4".)

10. Select the first photo in the film strip and set Exposure = -3.  With all the photos selected, do Sync Settings and sync just Exposure.

11. Click random photos in the filmstrip and observe the same symptoms as in step 4 -- after the saving of XMP gets started, the photos won't appear in Develop Loupe until the saving finishes. (See the attached screen recording "exposure.mp4".)

[DClark064]

John, thanks for your very thorough testing and explanation.  Two questions I have:

1.  It seems to me the type of problem you describe should have been caught by any reasonable product testing program.  Do you have any idea why Adobe misses stuff like this?

2. I do not use automatic writing to XMP, but I see lots of reports (most seem ill informed) of major issues with the new denoise method.  I have used the DNG based denose a lot, and have done a few with the new process.  Do you have any suggestions on how the new process should be used and integrated into our work flow?  Should we revert to prior version to avoid issues?

Thanks again for your work on LrC.  

[Jao vdL]

Are you sure the xmp files don't get actually updated when you are stepping through? Finder can be extraordinarily sluggish with updating the metadata columns. It certainly seems like Lightroom is saving something seeing how long it takes to count down the number of saves left. Often you have to close and reopen a folder to see any updates. 

Anyway, these are clearly bugs with the automatic xmp writing system. That has always been very buggy unfortunately.  

[johnrellis]

@Jao vdL: "Are you sure the xmp files don't get actually updated when you are stepping through? Finder can be extraordinarily sluggish with updating the metadata columns. It certainly seems like Lightroom is saving something seeing how long it takes to count down the number of saves left. Often you have to close and reopen a folder to see any updates."

During my testing I originally thought LR was actually writing the .xmp sidecars, so I quintuple-checked:

1. I waited for several minutes to see if Finder would update.

2. I switched the Finder window to another folder, waited, then back.

3. I quit Finder and restarted it.

4. When I selected a single photo and did Metadata > Save Metadata To File, Finder sorted the changed .xmp to the top of the list immediately.

5. I captured copies of the initial .xmp files and then diffed them with the current .xmp files, and there were no differences.

[johnrellis]

"Do you have any suggestions on how the new process should be used and integrated into our work flow?"

Turn off Automatically Write Changes Into XMP. (I've done that, thought I've always had the option on.)

If you're working with large batches of noisy photos (e.g. a photo shoot of a stage production or a sporting event, with high ISOs), rearrange your schedule to the degree possible to apply Denoise in batch immediately after import and find something else to do while it's running.   That's a minor inconvenience for me (e.g. when I shoot our scout troop's court of honor), but for high-volume professional photographers, that could still be costly in terms of their time, especially if they're on deadline.

"It seems to me the type of problem you describe should have been caught by any reasonable product testing program.  Do you have any idea why Adobe misses stuff like this?"

Adobe has long had a reputation for reducing their development costs to the absolute minimum needed to maintain their market dominance. For products like LR Classic that don't have serious competition (at least for the asset-management features), users don't have anywhere else to go, which means Adobe can further reduce development costs. Wall Street has long loved Adobe for its quarterly performance.

On the demand side, with many software categories, users show a preference for buying the cheaper product, even if it's lower quality. I'd be willing to pay twice as much for a higher-quality LR, but many users wouldn't.

[C.Cella]

As I reported in another thread the best workflow is to use VC and not save into XMP till the last moment.

e.g

.lrcat = 1,9 MB

Super Resolution applied to a VC of the ONLY image in the catalog (a GFX 100 RAW)

lrcat = 1,9 MB

Save the VC as a named "Super Res" Snapshots...Enhance now is to be saved into XMP

Save into XMP (this can take many many seconds,)

.lrcat = 203.4 MB

Now get rid of the Snapshots
Save into XMP

lrcat = 203.4MB

Optimise Catalog
lrcat = 1.9 MB

So use VC and save XMP only when you desperately need the edits in the sidecar.