Memory remains high after Assisted Culling in LrC 15.6

Hi ​@yairg79344582,

I’ve moved your report and its context into this separate thread so we can track the memory-retention behavior in Lightroom Classic 15.6 independently from the original 15.5 crash issue.

Just following up: could you please send me the before-restart logs, Diagnostic Report, and memory timeline you collected? You can upload the ZIP to Google Drive, Dropbox, WeTransfer, or a similar service, then click my profile name > Send Message and share the download link privately.

I’ll share the material with the product team for investigation.

Also, if Lightroom Classic does crash during any further testing and you see the Adobe Crash Reporter, please submit the report and enter the same email address associated with your Adobe Community account in the email field. That will help us locate the crash report on our backend and correlate it with this investigation.

Thanks again for helping us investigate this. Please let me know if you need any further help.

Best,
Anshul Saini

​@Anshul_Saini
Here is the separate memory-retention report you requested. I have the full before-restart logs, diagnostic report and memory timeline ready. Please let me know how to send the evidence ZIP privately. 

TAG
@Anshul_Saini

BACKGROUND
I am opening this separate report at Anshul_Saini's request:
https://community.adobe.com/bug-reports-674/p-lrc-v15-5-on-windows-assisted-culling-triggers-crash-and-memory-leaks-1637630#post7772975

The Assisted Culling / similarity-stacking workflow that previously crashed completed without a crash in my initial 15.6 test. This report concerns the remaining high memory usage; it does not establish that the original crash is fixed in all circumstances.

SYSTEM
Lightroom Classic 15.6, build 202609251514-f839cde9
Windows 11 Home, OS build 26300
Intel Core i7-12700F, 12 cores / 20 logical processors
32 GB RAM
NVIDIA GeForce GTX 1650, 4 GB VRAM
NVIDIA driver 32.0.16.1088 (610.88 Studio)
Catalog on the local C: SSD.

CURRENT PERFORMANCE SETTINGS (CAPTURED 2026-10-01)
Use Graphics Processor: Custom
GPU for display: On
GPU for image processing: On
GPU for Export: On
GPU for Preview Generation: Off
Camera Raw cache maximum: 5 GB
Original catalog's automatic catalog-wide Assisted Culling analysis: Off
The GPU/cache settings were captured before and after the new-catalog reproduction, without changing them. I did not separately record every Performance setting during the original 2026-09-30 test.
The new catalog's startup log records AICulling_enableAutoCullingAnalysisForCatalog as <nil>, while the original catalog records false. I initiated analysis manually in the new catalog.

SOURCE IMAGES
The tested source folder contains 594 Canon .CR3 files, 10.637 GiB, without subfolders or other file types.
The exact selection count during the first test was not recorded.
For the new-catalog repeat, all 594 files were imported using Add and used for the fresh culling test.

ORIGINAL OBSERVATION (2026-09-30, MAIN CATALOG)
1. Run Assisted Culling on the folder.
2. Run stacking by visual similarity.
3. The workflow completed without a crash.
4. Lightroom's working set was approximately 15.15 GiB, with 39.59 GiB of private committed memory.
5. During one 15-second sample, working set changed from 15.16 to 15.15 GiB and private committed memory from 39.60 to 39.59 GiB.
6. Close and reopen Lightroom normally.
7. Memory returned to 2.68 GiB working set / 3.31 GiB private committed memory. Culling scores persisted.

INTERPRETATION AND LIMITATIONS
Private committed memory is not physical RAM usage. The 15-second observation and reduction after restart do not prove a leak; caching or delayed release may also explain retention.
No time-series log or Task Manager screenshot was saved during that original high-memory session.
The initial baseline logs collected on 2026-10-01 are from the session AFTER the original restart and cannot be presented as logs from the original high-memory session.
The followup-new-catalog-test logs were captured from the new reproduction BEFORE any restart.
Some Camera Raw logs predate the test. The log manifest records their dates.

FOLLOW-UP TEST
Reproduced on 2026-10-01 in a separate, initially empty local catalog using the same images:
1. Import all 594 CR3 files using Add, not Copy or Move.
2. Start fresh Assisted Culling analysis for those images.
3. Wait for scoring to finish, then run Stack by Visual Similarity.
4. Confirm both operations are finished and leave Lightroom idle for five minutes.
5. Capture live logs, diagnostic report, Performance preferences and Task Manager evidence before restarting.

The retained-memory behavior also occurred in this new catalog. No Lightroom error/crash event was recorded.

Time-series measurements (GiB, sampled approximately every five seconds):
Before culling: 3.35 working set / 3.77 private committed.
Peak during workflow: 22.30 working set / 30.34 private committed.
Immediately after workflow confirmation: 17.25 working set / 30.02 private committed.
After 300.3 seconds idle: 16.88 working set / 30.01 private committed.
Average process CPU during idle: approximately 0.15% across all 20 logical processors.
System committed memory peaked at approximately 98.14% of the commit limit during the workflow.

There was a small reduction in resident memory during idle, but almost no reduction in private committed memory.
The recordings contain 212 samples spanning 12:43:05 to 13:01:53 local time (UTC+03:00).
The console log records AICulling:start / complete at 12:43:49 / 12:54:18, and again at 12:56:00 / 12:56:45.
The second pair followed the similarity-stacking step. The UI also showed "Undo Auto Stack By Visual Similarity" after the workflow.
Fine-grained culling thresholds and stack-similarity settings were not separately recorded.
Source photo filenames, sizes and modification times were unchanged after the test.
After all pre-restart evidence was collected, I relaunched Lightroom normally and returned to the original catalog. Memory was 2.92 GiB working set / 2.62 GiB private committed. This reopened a different catalog, so it is not a same-catalog restart comparison.

ATTACHMENTS
- Task Manager screenshot from the reproduced high-memory session, plus a baseline screenshot.

- Screenshots of Preferences > Performance before and after the test.

The diagnostic ZIP and raw logs may contain local paths, device identifiers, application details and photo filenames. I can provide them privately to Adobe rather than posting them publicly.
 

REQUEST
Is this degree of memory retention expected caching after Assisted Culling / similarity stacking, including in a new catalog, or does it warrant investigation? What further diagnostic data would help distinguish caching from a leak?

Hi @yairg79344582,

Thank you for the detailed testing. It’s good to hear that the original Assisted Culling crash is resolved in 15.6.

Since the remaining high memory usage appears to be separate, could you please create a new thread for this behavior and tag me (@Anshul_Saini) there so we can investigate it separately?

Please include the approximate number/file type of images, your exact Assisted Culling/Stack by Similarity workflow, and how long the memory remains high after processing. It would also be helpful to attach:

• Lightroom Classic Diagnostic Report: Preferences > General > hold Alt/Option > Generate Diagnostic Report

• Screenshot of Preferences > Performance

• Task Manager/Activity Monitor screenshot showing the memory usage

• lrc_console.log and the Camera Raw logs, preferably collected after reproducing the issue and before restarting Lightroom Classic

Lightroom logs
Windows: C:\Users\<username>\AppData\Roaming\Adobe\Lightroom\
macOS: ~/Library/Application Support/Adobe/Lightroom/

Camera Raw logs
Windows: C:\Users\<username>\AppData\Roaming\Adobe\CameraRaw\Logs\
macOS: ~/Library/Application Support/Adobe/CameraRaw/Logs/

If possible, please also let us know whether the behavior reproduces in a new catalog with the same images.

Once you’ve created the thread, tag me there, and I’ll take it forward with the team.

Thanks again for helping us investigate this.

Best,
Anshul Saini