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

If your catalog's .lrcat file (the SQL database) ballooned in size due to this LR 14.5 bug, here's how to reduce it back to its pre-14.5 size:

1. Do Catalog Settings > General > Show to open File Explorer / Finder on the catalog folder.  Write down the size in bytes of the <catalog>.lrcat file.

2. Using the Has Denoise column in the Library Filter bar's Metadata browser, select all photos that have Denoise applied.

3. Do Metadata > Save Metadata To File.

4. Repeat steps 2-3 for Has Super Resolution and Has Raw Details Only.

5. After the Save Metadata To File completes, do File > Optimize Catalog and exit LR.

6. Repeat step 1 -- the .lrcat file should have gotten much smaller, by approximately 10 to 50 MB for each photo that has Denoise or Super Resolution applied.

It's now safe again to enable Catalog Settings > Metadata > Automatically Write Changes Into XMP.  (We can conduct the religious arguments about whether to do that in another thread.)

@Sameer K, this bug appears to be have been fixed in LR 15.0.  The bug recipe no longer exhibits any of the bad symptoms.

Have any of the Denoise bugs been fixed in the October 2025 releases of Lightroom and ACR?

@Stephan Preining

What you say is not ture.

It has always been possible to get rid of all blaot in catalog by Optimising it.

Before it had to be done daily.

Now the bloat is not going to happen anymore.

LrC now saves Ai to .acr sidecar and the XMP data kept in catalog is back to be little as it was before Ai Settings.

So optimize catalog and you should be good.

Once in a while you might have to optimize to get rid of some extra MB that you don't need but is never going to be GB of bloat anymore 

The bloat has been fixed.

The situation is made even worse by the fact that the denoise information can not be deleted from the actual catalog file. By going into the history panel and selecting the last edit BEFORE the denoise, right click on it and the select "Clear History Above This Step" only the .lrcat-data file is shrinking but not the catalog file itself.

This means right now I'm stuck with a 20GB catalog file which makes it really hard to run backups.

@avalent: "I don't know if this is happening to others, but Denoise is now broken when it's a batch process followed by Adaptive Color. It will run, complete, and when I batch-apply Adaptive Color, suddenly both require updating"

Adobe recommends applying Denoise before Adaptive Color:

https://helpx.adobe.com/lightroom-classic/kb/optimize-performance-lightroom.html#OrderofDevelopoperations

If you do it in the other order, then you'll see the AI Edit Status button turn yellow and you'll need to do Update AI Settings to recompute the internal masking in Adaptive Color. (If you sync both settings at the same time, LR will apply them in the right order.)

"This doubles the time needed to Denoise"

Normally, when you apply Adaptive Color first and then Denoise to a batch, and then batch-apply Update AI Settings, the update goes very fast, recomputing Adaptive Color but not Denoise.  If you're seeing something different, I recommend starting a new thread, including a full-resolution screen recording (not a phone video) of the entire LR window showing the bad behavior you're observing:

I don't know if this is happening to others, but Denoise is now broken when it's a batch process followed by Adaptive Color.

It will run, complete, and when I batch-apply Adaptive Color, suddenly both require updating and I'm stuck in a loop. This doubles the time needed to Denoise - completely needlessly, on top of the ridiculously humongous catalog size, painfully slow backup and optimization process.

Every day a new set of issues with Adobe apps. The more of them you use the more time and nerves you lose. What a sad state of affairs that there's not good competition to get people to leave en masse.

What a joke Adobe is - not the teams behind these apps, I'm sure they're mostly aware of the issues, but those who decide what's prioritized and what gets ignored. There's so much broken it's easier to cite what isn't.

And just to note, the backend problems are made worse by both poor UI choices and by outright bugs in both ACR and Lightroom.

The road to software hell is paved with little expediencies that seemed harmless to the developers at the time.  For the current mess, the expedient paving stones are:

- Using the .lrcat-data file as both a store for the develop parameters and as a discardable cache of develop results for enhancing performance.

- Storing both develop parameters and cached results in .xmp sidecars, rather than separating them into .xmp and .acr sidecars as Camera Raw does.

- When LR saves metadata to disk, it first copies settings and cached results from .lrcat-data into the .lrcat file.

- LR stores no random seed for the random algorithms of Generative AI Remove, so its generated replacement patches must be considered as develop settings rather than as discardable computed results that are cached for performance.

I think all of these expedient paving stones have resulted in unncessary architectural compications making it harder for the developers to think clearly about the proper design and implementation of Denoise and other expensive AI commands.

DETAILED HISTORY

1. Originally, all develop settings were stored only in the SQL database (.lrcat file). The stored settings were all "parametric", describing the function to be applied to the image (e.g. slider settings or brush strokes), rather than containing the resulting pixels of the function.

1. LR 11.0 introduced the computed AI masks Subject and Sky.  It also introduced the .lrcat-data file for storing the computed pixels of these masks as well as LUTs (color lookup tables) from imported enhanced profiles.

The pre-version-11 code for saving metadata to disk found all the develop settings in the .lrcat file. But version 11 stored the subject/sky mask pixels as well as profile LUTs in the .lrcat file, with the express purpose of making the .lrcat file smaller and making it faster for the Camera Raw engine to access these relatively large binary objects ("blobs").

Rather than changing the save-metadata-to-disk code to read those settings and results from the .lrcat-file, the developers found it more expedient to copy them from the .lrcat-data file into the .lrcat file before invoking the existing save-metadata-to-disk code. This expediency didn't create huge issues, though, since the pixel masks and LUTs compress well and are relatively small.

Another architectural confusion introduced in LR 11.0: The .lrcat-data file and .xmp sidecars are used both as a cache for storing the computed results of the sky and subject masks and as a store of the develop parameters of enhanced-profile LUTs. 

The pixels of the sky and subject masks are not develop parameters -- rather, they're computed from the parameters (the presence of the masks in the Masking panel). You can throw away the computed pixel masks and LR will recompute the masks, producing the same exact pixels.  This is exactly how all the previously introduced Develop settings work.

Thus, you can throw away the .lrcat-data file and .xmp sidecars and the sky and subject masks will produce the same exact results.  For these settings. the .lrcat-data file is simply a cache for accelerating performance.

But for the LUTs of enhanced profiles, the .lrcat-data is the store of the "truth", in the same way the .lrcat file stores the truth of all the other develop settings.  If you throw away the .lrcat-data file and the enhanced profiles' .xmp files, LR isn't able to recompute the effects of the enhanced profiles because the LUTs are missing (all the other parameters of the enhanced profiles are stored in the .lrcat file). This is unlike develop presets, where you can throw away the presets' .xmp files and LR will still be able to render cataloged images, because the presets' settings are stored in the .lrcat file.

1. LR 14.0 introduced Generative AI Remove. One might think that the parameters of AI Remove are simply the brush strokes applied by the user and the index number of the chosen variant, both of which are small and can be stored in the .lrcat file without huge impact (as the strokes of the brush mask are stored). 

However, Generative AI Remove is not mathematically idempotent, like all other develop settings. That is, if you reapply the exact same brush strokes to an image, the Adobe Firefly server will return different results each time. The Firefly AI algorithms have randomness built in to them, as many image-processing algorithms do. In a better implementation, that randomness would have been controlled by a "seed" number provided by clients like LR, so they could recompute the exact same results later; but that's not how Firefly is implemented, or if it is, LR isn't using the seeds, another design flaw.

Thus, the computed replacement patches of AI Remove must be considered as parameters necessary to render the image the same way each time, not as cached results. And since those computed patches are stored in the .lrcat-data file and .xmp sidecars, the files serve as the only store for Remove parameters, rather than as a performance cache that can be discarded.

Users of the Imagen AI service discovered this the hard way when Imagen AI corrupted their .lrcat-data files. The only fix was to discard the corrupted .lrcat-data files, resulting in different Generative AI Remove results for existing cataloged photos. (This was primarily Imagen AI's fault for writing their results directly into the LR catalog rather than using the SDK APIs -- shame on them.)

1. And then LR 14.4 introduced the new implementation of Denoise, in which the computed whole-image results are stored in the .lrcat-data file. These results are huge, typically 5 to 50 MB per image, depending on the degree of detail in the image, two to three orders of magnitude larger than all the other develop settings and computed results.

But the Denoise results are not develop parameters -- they can be discarded and Denoise will recompute the same exact results. The only parameters are the checkbox and the slider. But because it takes so long to compute Denoise, it's crucial that its results get cached for performance.

Up until Denoise, it didn't matter much that saving metadata to disk copied develop settings from .lrcat-data into .lrcat before writing them to the .xmp sidecars.  The needlessly copied settings were relatively small. But the huge size of Denoise compiled with saving metadata to disk bloats the .lrcat file, negating the original purpose of the .lrcat-data file.

And if LR reserved .xmp sidecars for parameters and .acr sidecars for computed results, as Camera Raw does, the LR developers might have thought more clearly about the architectural principles sooner and implemented saving metadata to disk properly.

As I've said - I'm on LrC 12, so maybe this has been changed.

Anyways there is nothing to report as Adobe only accepts reports for latest version.

But the point that LrC does not create *.acr files for binary data when saving sidecar files still stands.

Why is behaviour different compared to ACR?

This leads to issue described in this thread.

Because reading *.xmp files back then brings all that binary data (base64 encoded) from xmp sidecar into main catalog, and not in lrcat-data as it should.