P: Bring back the ability of Enhance to run in the background. (LrC)

I don't mind the 25-35 seconds it takes for the AI to denoise a photo.  Nor do I really mind (that much) that the XML sidecar files get large - some as large as my original RAW file.  But what DOES have me very perturbed is the fact that my Lightroom catalog increased in size nearly 5x.

Is there anyway to keep this from happening or do I have to proceed with my original plan of re-editing the photos I used AI enhance on and just staying clear of anything AI?  Thanks.

I am not happy with the recent lightroom cc update removing the enhance function under the right-click menu. I understand the functionality is still available under raw details, but this means that i can no longer enhance batches of photos, buut instead must enhance 1 at a time which kills my workflow and slows thing way down for me. I get updating software, trying to meet peoples needs, and i get adding the raw details sections for people to tweak individual images, but leave the old enhance feature too. i feel like the majority of photographers are unhappy about this change as certain scene and shoot have very similar lighting and therefore camera settings and batch enhancing saves a lot of time and energy in these scenarios. Please return the Enhance function for batches!

Thanks

I’d like to express my dissatisfaction with the recent change in Lightroom Classic, where the Denoise feature with AI no longer works in the background.

Previously, I could apply Denoise to multiple images and keep editing others while it processed in the background. That was a huge time-saver and made my workflow much more efficient. Now, with the new system that applies Denoise directly to the original CR3 file and requires synchronous processing, I have to wait for each photo to finish before continuing — which severely slows down the entire process, especially when working with large batches of images.

I kindly ask that you consider bringing back the option to process Denoise in the background, or at least make it an optional setting. This feature makes a significant difference for professional photographers who work with high-volume editing.

Thank you for your attention and for the excellent work on the software so far. I sincerely hope this functionality will be reconsidered in future updates. 

Another critical issue with the current Denoise implementation is that I cannot choose the amount of noise reduction before applying it. It defaults to a fixed amount, and only afterthe processing is complete can I go to the Details panel and adjust it — which then requires the image to be reprocessed.

This creates a lot of unnecessary rework when applying Denoise to multiple images, especially if I need a more subtle or stronger effect.

I kindly request that Adobe brings back the ability to set the Denoise amount beforeprocessing, just like in previous versions.

I’d like to express my dissatisfaction with the recent change in Lightroom Classic, where the Denoise feature with AI no longer works in the background.

Previously, I could apply Denoise to multiple images and keep editing others while it processed in the background. That was a huge time-saver and made my workflow much more efficient. Now, with the new system that applies Denoise directly to the original CR3 file and requires synchronous processing, I have to wait for each photo to finish before continuing — which severely slows down the entire process, especially when working with large batches of images.

I kindly ask that you consider bringing back the option to process Denoise in the background, or at least make it an optional setting. This feature makes a significant difference for professional photographers who work with high-volume editing.

Thank you for your attention and for the excellent work on the software so far. I sincerely hope this functionality will be reconsidered in future updates.

For me I only created DNG files temporarily (before version 14.4), then I open those to do my heavy editing and finishing touches in Photoshop. Once I save a Tiff file back to Lightroom I delete the DNG files. I guess that's even another reason to offer the option as to not bloat the LR catalog file with Denoise information. Plus the new way in version 14.4 was actually already available in 14.3.1 by opening the raw file from Lightroom into Photoshop as a smart object then from Photoshop opening Camera Raw where you could Denoise directly without having to create a DNG. I liked how it was implemented before 14.4, just need to give the option and optimize the Denoise information if not creating a DNG. 

@ronb2: "If Lightroom stuffs all the denoise info in .lrcat-data then anyone who uses the enhance functions will see their main drive get eaten away rather quickly and without recourse. It's not like the DNG files where you could relocate them to another drive, these are stuck in a specific place."

One thing to note is that the new denoise data is significantly smaller than the old DNG representation. In my testing, it's as much as 88% smaller:

https://community.adobe.com/t5/lightroom-classic-ideas/p-bring-back-the-ability-of-enhance-to-create-a-dng-in-the-background-lrc/idc-p/15391025#M24502

The space savings varies greatly depending on the amount of incompressible detail (e.g. bare tree branches) in the photos being denoised (not very much on ISO); if lots of photos have lots of incompressible detail, the savings will be much less.

But as you observe, you can easily store the DNG files on another drive.

Opened LrC and ran Optimise Catalog and when finished, closed LrC: .lrcat file is 1.77 MB; .lrcat-data folder contains 1.12 MB in 12 files; the table in the .lrcat database is 2380 bytes in size.

 

Opened LrC again and ran Raw Details, then closed LrC: .lrcat file is 1.78 MB; .lrcat-data folder contains 74.2 MB in 13 files; the table in the .lrcat database is 2380 bytes in size

I find it kind of crazy that no one else is calling this out as an issue. If Lightroom stuffs all the denoise info in .lrcat-data then anyone who uses the enhance functions will see their main drive get eaten away rather quickly and without recourse. It's not like the DNG files where you could relocate them to another drive, these are stuck in a specific place.

In all honesty, for me this is a bigger deal breaker than the workflow issue (which was already a big one that had me roll back to 14.3.1). 

@Incredible_Explorer0544,

I filed the bug report about Denoise and Automatically Write Changes To XMP:

https://community.adobe.com/t5/lightroom-classic-bugs/automatically-write-changes-to-xmp-can-t-be-used-with-denoise-on-large-numbers-of-photos/idi-p/15393188

Building on drtonyb's reply:

"I used the raw details function for all of the photos, but the denoise only for a part of them."

Denoise, Raw Details, and Super Resolution were all part of the previous Enhance command (generating DNGs), and now they're part of the same subpanel of the Detail panel. They use the same internal representation in the .lrcat, .lrcat-data, and .xmp files.

"Performance did not ever return to normal after writing that sidecar files."

As detailed in the bug report, when Automatically Write Changes To XMP is enabled, the performance of Develop suffers, especially when making batch changes (e.g. syncing Develop sliders to other photos). In my testing, when I disable Automatically Write Changes To XMP, performance returns to normal.

"To my understanding the sidecar files are needed. ...  I conclude that this is still the case, as you only temporarily disabled them."

They're not needed except in some specialized workflows with third-party apps, as drtonyb explained. I've permanently disabled Automatically Write Changes To XMP in my main catalogs until the bug is fixed.

"The complaint of all these professional photographers with respect to the disruption of their workflow is perfectly valid, as time is money and not being able to do anything else as long as the denoise of a large number of photos is running"

I fully agree. But that's a separable issue from the bug with Denoise and .xmp sidecars.

All of the other AI commands also bring up the modal "Updating AI Settings" when you apply them to a batch of photos, preventing any other work until that completes.  It's not as big an impediment, since they generally go much, much faster (with the exception of Lens Blur). 

I suspect that LR doesn't let you do anything while Update AI Settings is running because of a design flaw in the LR internals in the way it handles asynchronicity.  For example, you can apply Auto to a large batch of photos and it takes effect immediately. But batch application of Auto has been buggy since the beginning; Adobe tried to fix one of the bugs but introduce another, which has never been fixed. I suspect that rather than try to address the internal architectural design flaw, the LR team found it more expedient to prevent the user from making any changes while Update AI Settings is running.

The old Enhance command was able to run asynchronously because it was built on top of export and import, which do reliably run asynchronously -- all the major modifications to the image were done to the exported DNG, which was separate from the catalog.

@Incredible_Explorer0544 

"To my understanding the sidecar files are needed, which is why I have that option of automatically writing switched on."

Where did you get this misunderstanding from?

You only need xmp sidecar files if you want to use ACR or LrD locally with the same edits you last saved from LrC. Another use often cited is as a buck (insurance) that things go disastrously wrong with the xmp sidecars the only way to recover.

None of these are essential for using LrC. I never save to xmp and have never had a problem with my catalog; I have been using Lr/LrC since Version 1 was released in May 2007.

@johnrellis is correct about the xmp data being written into the catalog. This includes Raw Details and Super Resolution. As he does, I also believe this is totally unnecessary and is something carried from the past into later versions of LrC after the implementation of the lrcat-data folder and its database.

I did the following test with a new catalog and importing one photo, a 64.1 MB NEF from my Nikon Z8:

After Import, did nothing and closed LrC: .lrcat file is 1.77 MB; .lrcat-data folder contains 1.11 MB in 19 files; the table in the .lrcat database is 2380 bytes in size.

Opened LrC and ran Optimise Catalog and when finished, closed LrC: .lrcat file is 1.77 MB; .lrcat-data folder contains 1.12 MB in 12 files; the table in the .lrcat database is 2380 bytes in size.

Opened LrC again and ran Raw Details, then closed LrC: .lrcat file is 1.78 MB; .lrcat-data folder contains 74.2 MB in 13 files; the table in the .lrcat database is 2380 bytes in size.

Opened LrC again and Saved Metadata to File (xmp), then closed LrC: .lrcat file is 150 MB; .lrcat-data folder contains 74.2 MB in 12 files; the table in the .lrcat database is 77912317 bytes in size; .xmp file is 91.4 MB.

Opened LrC and ran Optimise Catalog and when finished, closed LrC: .lrcat file is 76 MB; .lrcat-data folder contains 74.2 MB in 14 files; the table in the .lrcat database is 77912317 bytes in size.

What do I conclude from all this? Saving to Metadata File kills your catalog when photos are Enhanced; Optimise Catalog can reduce the catalog's size by half, but the table holding the xmp data doesn't change. A large amount of garbage is being stored somewhere in the catalog sqlite database, but I don't know where; at least optimising seems to clear it, but the catalog is still bloated.

I then continued my testing and deleted the .xmp file.

Opened LrC again and Read Metadata from File. This applied a Reset to the settings since there was no xmp file to read. Closed LrC: .lrcat file is 76 MB; .lrcat-data folder contains 74.2 MB in 18 files; the table in the .lrcat database is 2211 bytes in size.

Opened LrC and ran Optimise Catalog and when finished, closed LrC: .lrcat file is 1.78 MB; .lrcat-data folder contains 74.2 MB in 19 files; the table in the .lrcat database is 2211 bytes in size.

Opened LrC and right-clicked the History step below the Reset step and selected Clear History Above this Step; edits and catalog are back to normal.

Restoring a catalog to a normal size in this way isn't practical if 100's or 1000's of Enhanced photos have been saved to xmp.

One last test, which was a bit drastic, but would only do it on a test catalog: With my catalog back to its bloated size, I deleted the xmp data from the catalog table, then in LrC, ran Optimise Catalog. On opening the catalog again in LrC, the photo looked normal, all the settings were good and the catalog size itself was back to 1.78 MB. Running a Catalog Integrity Check didn't throw up any problems either.

All this suggests to me that the xmp data stored in the catalog is just junk, and if that is true, the development team needs to no something about cleaning up this mess.

@johnrellis Thank you very much for your investigations 👍 However, there is one fact not addressed at all so far:  I used the raw details function for all of the photos, but the denoise only for a part of them. How does that fit into your explanation?

Further on, I have several comments:

1. Performance did not ever return to normal after writing that sidecar files. 
2. To my understanding the sidecar files are needed, which is why I have that option of automatically writing switched on. From what you wrote I conclude that this is still the case, as you only temporarily disabled them.
3. The complaint of all these professional photographers with respect to the disruption of their workflow is perfectly valid, as time is money and not being able to do anything else as long as the denoise of a large number of photos is running, well, I perfectly understand their frustration and support the optional use of the previous process.
4. By the way, I found the small preview window very helpful in setting the denoise strength. This is actually more convenient than zooming in after the denoise and use the slider. Why not both? A preview window and the ability to modify later?

Looking forward to your comments and thanks again.