[bmachek]

1. Indexing exports in batches, with fixed settings

• macOS pipeline: it used one LrExportSession for the whole selection. Lightroom keeps every rendition until a session ends, so its memory climbed through long runs. It now opens one session per batch (default 25, Photos per export batch in Plug-in Manager). The producer waits while a batch's worth of JPEGs is still queued, so temp files cannot pile up.
• Windows / sequential path: before, every photo got its own session, so nothing rendered in parallel. Now the next batch is rendered in one session and consumed photo by photo. It stays a single worker.
• Pixel-relevant settings are pinned (7574d29): colour space sRGB and no enlarging of photos smaller than the export size. Two exports of the same photo then always match, instead of depending on Lightroom's defaults. Settings are built fresh per session (exportSettingsFor).
• JPEG quality on Lightroom's 0–1 scale (a383823): LR_jpeg_quality got the preference in percent unchanged, and Lightroom takes anything above 1 as full quality, so every export was written at 100% (1.44 MB vs 160 KB for a 2048 px raw at 50%). This predates the PR; Util.jpegQualityFromPercent converts it now, and the preview task passes 0.8.
• Lightroom previews are not used (dropped in caf262c). requestJpegThumbnail delivers a few and then stops answering, and it returns whatever size is cached, so embeddings drift. Reading Previews.lrdata / .lrprev directly has the same size and staleness problems, plus an undocumented format.

2. Add Missing Search Previews

• Backend:
  • POST /v1/photos/thumbnails/missing lists the indexed photos without a search-page preview.
  • POST /v1/photos/thumbnail (multipart) stores one for an indexed photo, scaled to the indexing size. Photos without an index row get 404 not_indexed.
• Plugin: a new task, Add Missing Search Previews…, makes small batched exports (512 px) and uploads them. Failures are listed in the final dialog. It sits in the Help menu since 1ae4a82, which also moved Save Edits as AI Training Examples and Deduplicate Keyword Synonyms; docs, the search page banner and messages follow that.

3. Optional AuraFace recognizer

• lrg-ml:
  • Recognizer {FaceNet, AuraFace}, each with its own face_model id.
  • AuraFace uses the existing 112×112 ArcFace crop, RGB, (v-127.5)/127.5; the input name is read from the graph.
  • detect_faces_with_model returns the id it actually used.
• API:
  • GET/POST /v1/faces/recognizer: saved next to the models and restored at start; 409 until the model is downloaded.
  • /v1/faces/recognizer/downloads: downloads fal/AuraFace-v1/glintr100.onnx (Apache-2.0) from Hugging Face, pinned to commit af6d057c9b0ec4071d4c49c80e3539258798b609 (08000d7).
• Names survive a switch: re-detection carries person assignments from the other recognizer's rows by box overlap (same YuNet detector, IoU ≥ 0.6).
• /v1/faces/search now ranks only rows of the query's model, and says in warnings how many it left out (bedb2d6): right after a switch it used to answer "ok" with no results. Find Similar Faces shows those warnings.
• Plug-in Manager: a Face recognition box to switch between FaceNet and AuraFace.
• Numerics verified (08000d7): scripts/auraface_reference.py recorded InsightFace's own embedding (InsightFace picks mean/std 127.5, as auraface.rs assumes); auraface_matches_insightface_reference passes at cosine 0.9988 (needs > 0.99).

Tested live in Lightroom 15.6 (test catalog, 197 raws, macOS)

• In-Lightroom plugin tests 24/24, catalog-write tests 4/4.
• Batched indexing: 157 photos in 7 batches, 396 s; at most 11 JPEGs in temp, none afterwards. Same run with one session (batch size 200): 405 s and the same memory (median 15 GB, p90 18 GB). At this size batching makes no measurable difference; whether it keeps memory down over thousands of photos is still open.
• Two exports of the same photo differ by at most 2–3 levels on under 0.01% of pixels.
• Search previews: missing-list and upload routes incl. every error case; 10 previews regenerated through the plugin functions, matching the originals.
• AuraFace: download 260 MB (sha256 matches the pinned commit); FaceNet → AuraFace → FaceNet with "New or unprocessed photos" re-detects all 197 photos each way, and every person keeps exactly its photos (86/86, 10/10, 6/6).

Known issue, not fixed here

• Cancel does not stop rendering. rendition:skipRender() always raises "must not be called after exportSession has started rendering" (swallowed by pcall), so on cancel Lightroom keeps rendering the rest of the batch for ~30 s and those JPEGs stay in the temp folder (15 files / 47 MB in the test). Same in exportPhotosForIndexing. The old rendition:cancel() did not work either. Fix: waitForRender() and delete the file instead.

Still to note

• Small photos: with no enlarging, photos smaller than the export size now index at their own size instead of an upscaled one. Their embeddings change slightly on the next re-index, as they do from the JPEG quality fix.
• The recognizer choice is per computer (~/.cache/lrgenius/models/face_recognizer.txt), while faces are stored per database: switching in one catalog sets aside the faces of every other catalog until it is re-indexed.
• Cluster thresholds are FaceNet's for both recognizers. In a small sample, AuraFace at the default 0.5 left 70 of 135 faces unassigned (FaceNet: 33). Named people are not affected (pinned).

Checks

• cargo fmt --check and cargo clippy --workspace --all-targets are clean.
• cargo test --workspace passes; face goldens pass with LRG_REQUIRE_GOLDENS=face,auraface.
• luacheck and stylua pass; busted 613/614 locally. The one failure, aesthetic_refine_spec, comes from the local Lua 5.5 (1.0 vs 1) and is untouched by this PR.
• scripts/check-docs.py reports no errors.

https://claude.ai/code/session_01HaMMvqfgsKcoNWQaKy3c9C

🤖 Generated with Claude Code

https://claude.ai/code/session_01HaMMvtFGGZAyc9nbCZiG6T