v0.19.0 shipped V4 to V6 with value-noise grain, so those stay frozen and
the crystal grain becomes a process of its own. V7 is V6 plus the grain:
without grain it renders as V6 (`without_grain_v7_renders_as_v6`), and the
GPU equivalence cases now cover V6's value noise.
Merged with main's float output (`deep`, `hdr`): the value noise keeps its
clamped luminance; the crystal grain already clamps, and fades out at and
above SDR white. The finish kernel's failed-render check stays ahead of
the aux upload.
The test of unknown process numbers now takes one past the latest: 7 was
hard-coded, and is a known process now.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: colour NR v2 prototype (env LIGHTCRAFT_NR_V2, CPU only)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: colour NR v2 on by default (LIGHTCRAFT_NR_V2=0 turns it off), GPU renders read back for it
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: cache renders with the new colour NR apart from older ones
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: colour NR v2 on the GPU (fused down / apply kernels), coefficient grid sigma / 2
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: colour NR v2 on the CPU without full-size intermediates (row-streamed passes)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: report peak device-buffer use per GPU stage with LIGHTCRAFT_PROFILE
* WIP: colour NR v2 linear mode (NRV2_LINEAR=1: c - Y, additive, noise model), Jensen term, mean-drift probe
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: colour NR v2 noise model with equal-count luminance bands and a non-negative fit; probe asserts the mean over 3 noise realisations
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: colour NR v2 linear mode by default (per channel, K 64, coarse pass smooths only the coarse part); CPU on GPU renders; real-colour probe
Known: tests_window::noise_reduction_does_not_depend_on_the_window fails (the noise is measured in the
rendered window; the square-root mode failed it too).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: colour NR v2 joint guide (NRV2_JOINT=1, opt-in), luminance guide knobs, leaf-next-to-black probe, camera-look guard from 858
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: colour NR v2 reads its env knobs once (per-pixel env reads made the linear mode 11x slower); joint stage timings with LIGHTCRAFT_PROFILE
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: joint colour NR without redundant passes (fused paths + next weights, none after the last scale, delta-1 weights from the path), two-component buffers, parallel reconstruction
Bit-identical to 8b89526d (test joint_matches_the_reference_bit_for_bit against a test-only copy).
Cat 32.7 MP, CPU: 6.2 -> 5.0 s at Color 25, 7.0 -> 5.6 s at 100; working buffers 2.36 -> 1.44 GB.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: joint colour NR with separate H/V slice loops and zero-difference shortcuts (no division, weight 1 without exp)
Still bit-identical to 8b89526d. Interleaved 24 MP bench: 2.72 s vs 4.52 s for the reference.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: joint colour NR on the GPU (nrcj.wgsl), default on; whole-image noise model from samples, halo bands above 2 GB
Kernels mirror nrc_joint step for step (same scale plan, noise model fitted on the CPU from GPU samples).
Cat 32.7 MP on a Quadro M2200: wb/nr 1.2-1.3 s vs 4-5 s CPU; against the CPU max 1 LSB; bands = single.
Waits after dropping large buffers (freed memory otherwise piled up to the whole 4 GB). Cache key includes joint.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: GPU joint NR plans its bands from a budget that includes the output buffer and the device buffer limit; halo 2*sum(delta) + max delta + 8; a band that cannot fit runs only this stage on the CPU
Bands vs one piece: at most 1 LSB in a few dozen pixels (running-sum boxes round differently per band start).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: GPU joint NR budgets its bands from the free device memory where it can be asked without unsafe (nvidia-smi, amdgpu sysfs), cached 3 s; fixed 2 GB otherwise
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: docs/nr-color-v2-history.md: every approach tried, measured and dropped, speed numbers, known limits (no outlier brake yet)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: history doc: speck behaviour stated qualitatively until measured on full-size renders
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: joint colour NR speck brake: compact colour specks (chroma far past the noise, small luminance step, shift not reaching the 5x5 border) lose their colour before the guide is built; weak at Color 25, full at 100; CPU and GPU
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: joint NR CPU 5.2 -> 3.5 s (33 MP), bit for bit: guide as planes with branch-free distance rows, exponentiated paths, pilot straight into planes, speck brake in place with a min/max pre-test
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: joint NR GPU: path and weight pairs instead of quads (48 instead of 60 bytes per pixel, 33 MP in one piece), speck and pilot kernels without loop-indexed private arrays, noise fit cached for identical samples; Quadro M2200 2.15 -> 1.47 s, HD 630 5.66 -> 4.26 s
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: speck brake: compactness from the second largest border share (a line or edge crosses the 5x5 border twice; one noisy border pixel no longer protects a speck)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #815: colour noise reduction as process V3
The joint method (linear R−Y / B−Y, edge-aware guide, speck brake) is process V3 and the latest; edits on V1 and V2 keep main's blurred chromaticity. The prototype switches (LIGHTCRAFT_NR_V2, NRV2_*) and the square-root and per-channel variants they selected are gone, with their GPU kernels; nrc_params uses the former defaults as constants, so V3 renders as the prototype did. The GPU falls back to the CPU joint filter when no band fits. vram is native only (wasm build). Docs: process-versions, nr-color-joint, parity checklist, what's new.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #815: process routing test initialises its settings in place (clippy field_reassign_with_default)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #815: one GPU band plan at a time, with a reserve for every render on the device
An export batch renders two photos side by side (`export_parallelism`). Each joint colour NR planned
its bands from the device memory free at that moment and counted the shared buffer pool as its own,
so two plans made at once could together ask for more than there is. Measured on a Quadro M2200
(4 GB): two 33 MP exports side by side peaked at 3761 of 4096 MiB.
The plan and its bands now run under one lock (`BANDS`), and the budget leaves `VRAM_RESERVE` for
each render on the device (`RENDERS`), not just for this one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #815: the joint colour NR's noise fit and pilot no longer switch at a hard bound
With main's preview-scaled luminance NR (#960) the CPU and GPU renders of a 640-px preview differed
by up to 10 levels (gpu equivalence `output_spaces_match`). Their images after luminance NR differ by
9e-7 rms, but one luminance band of the noise fit sat at exactly 4 times the first fit: the CPU's
samples dropped it, the GPU's kept it, and the fitted noise came out 2.6 % apart. The pilot's axis
choice then switched at a few pixels, and the edge-aware weights carried that on.
- robust_line: a band's weight fades to 0 between 4 and 5 times the fit instead of dropping at 4
(identical below 4).
- pilot_pick: the smoother-axis mean fades in between 0.8 and 1.25 times its bound instead of
switching at it (identical outside), on the CPU, in nrcj.wgsl and in the test reference.
All 19 CPU/GPU comparisons of the equivalence suite are within 1 level again. The new test
noise_line_does_not_jump_when_a_band_crosses_the_outlier_bound uses the bands of that preview and
fails on the old fit (5.6 % jump).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #815: the joint colour NR measures the whole frame's noise and is keyed by process
A window measured the noise model on the pixels it held, so a loupe window
could smooth differently from the same pixels of the full render or the
export. The model now comes from fixed tiles of the whole frame
(`lightcraft_pipeline::colour_noise`, `nrc_joint::tiles`), the same for every
window, for the CPU and the GPU, and is kept in the stage cache.
The linear stage's cache key now includes the colour filter in use, so a
process change (Update to Current Process, undo) no longer reuses the other
filter's denoised image.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* M-NR: deep windows match the whole render; the VRAM query no longer stalls renders
- A U16 / F32 window with the joint colour NR is grown by the filter's reach and
cut back, like an 8-bit one (DeepImage::crop).
- The free device memory is refreshed in the background once the cached answer is
stale; only the first question for an adapter waits. The joint NR asks before it
takes the BANDS lock.
- nvidia-smi starts without a console window on Windows (CREATE_NO_WINDOW).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* M-NR: the VRAM query finds the right card and keeps one answer per adapter
- A card is found by its PCI address (wgpu device_pci_bus_id, nvidia-smi pci.bus_id,
the amdgpu sysfs directory) where both sides report one; else by a device id that
only one card has. Two cards of one model without an address give no answer, and
the fixed band budget applies.
- Each adapter keeps its own cached answer, so a late background refresh cannot
replace another adapter's answer. A refresh not done after 10 s is retried.
- The cache tests wait on signals instead of fixed sleeps.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* M-NR: the VRAM cache tests no longer depend on timing
The two cache tests used a 20 ms TTL: on a slow machine a refreshed answer could go
stale again between assertions and start an extra query. They now use a 30 s TTL and
age an answer explicitly (Cache::expire, test only).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* GPU: allow joint_band's eight arguments, as color_nr_joint does
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
* Presets compose on the photo's original state, not the visible edits (fixes#2159)
Applying a preset deep-merged it into the photo's current settings, so a
second preset inherited whatever an earlier one (or a manual edit) had put
in the groups it styles, and its amount interpolated against the visible
values: a B&W preset followed by a color one stayed black and white. Each
group a preset covers is now computed on the photo's original state (its
import settings) and replaces the photo's own, at any amount; groups the
preset doesn't name, and the photo's pixel repairs (masks, spots, red eye),
are kept. An unresolved profile reference still means "the photo keeps its
own profile", and the built-in color presets now name their treatment, so
applying one after a B&W preset brings the colors back. The UI's hover previews and thumbnails show the same composed
result.
* Presets change only the settings they name (#2159)
The commit before this one computed each group a preset names on the
photo's import state and replaced the whole group. A preset therefore
also reset the settings it leaves out: Blacks under Bright & Airy, the
mixer colours it does not name, and imported exposure, whites and
blacks under Crisp Landscape.
Now each setting a preset names is computed alone, from the photo's
import look when a default preset recorded one, and otherwise from its
current value, because sidecar and catalog imports record no import
look and the camera defaults are then not their import state. Every
other setting keeps the photo's value. Pixel repairs (masks, spots,
red eye) compose on the photo's own values as before, and masks are
still added by the preset.
A color preset applied after a black and white one still restores the
treatment and the settings it names. Amount 0 applies nothing to a
photo without an import look. An unresolved profile reference leaves
the photo's profile as it is. Each case has a test.
* Document that presets change only the settings they name
The presets row and the preset amount row of the parity checklist now
describe the composition: each named setting is measured from the import
look when one is recorded, otherwise from the photo's current value, and
the settings a preset does not name keep their values. The revision
history records the change; statuses are unchanged.
* Test amount 0 on a setting the preset names
The amount-0 test used a preset that does not name exposure, so it
passed even when the original was the camera defaults. Bright & Airy
names exposure, and the test now checks that the photo keeps its value
at amount 0 for that setting.
* Keep a preset's null in an option field, and never take one from the original
A preset that writes null into an option setting (a crop aspect, where
null means free) was dropped below full amount: the scaled patch
removed every null, including the ones the preset wrote. At 100 % the
same preset cleared the aspect, at 50 to 99 % the photo kept it.
Now a null the preset writes applies from half amount up, as its other
values do. A null in the original never changes the photo: below half
amount such a setting is left out, so the photo keeps its own value.
Numbers and other values behave as before. The null-removal step is
gone, since the scaled patch no longer writes nulls for settings the
amount does not reach.
Tests: a preset null clears an option field from half amount up and
leaves it below; an option that is unset in the original does not
overwrite the photo's value.
* Build a preset's scaling base only below full amount
The presets panel asks for every visible row at 100 % on every frame,
and on hover. Each of those calls serialized the photo's current
settings and its original although, at 100 %, the preset's own values
apply as they are and the original is not read.
Compose now builds the scaling base only below 100 %. The engine also
builds the import state, or copies the photo's settings, only below
100 %. Results are unchanged; the existing preset tests cover both paths.
* Preserve preset baselines and allocate safe mask IDs
Assisted-by: OpenAI Codex
---------
Co-authored-by: eliets2 <287273517+eliets2@users.noreply.github.com>
Co-authored-by: FredApps <FredApps@users.noreply.github.com>
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
* catalog: history steps and versions share segmentation grids (#2154)
Every history step stored its own copy of each segmentation grid, so a
photo with AI masks rewrote every unchanged grid (about 220 KB each) with
every slider change: on a real library, 183.6 MB of a 187.8 MB
catalog.snap was duplicated grids (830 copies of 126 distinct ones).
Snapshots now keep each distinct grid once, in Catalog.grids (a new
serialization detail, format v10), and the masks of the photo's settings,
versions and history steps refer to it by index (SegMask.grid, with the
data omitted). The table is built while the snapshot is written and is
never held in the live catalog: Journal::open resolves the references
back to inline data (Catalog::repair), so rendering, hash64, presets,
XMP and log records are unchanged, and catalogs written before v10 load
and are upgraded as before. A reference past the table (a damaged
snapshot) is cleared and reported, rendering nothing.
Measured on 90 history steps over one 1024x1024 grid: the snapshot drops
every step's copy of the grid (1.29 MB -> 0.30 MB in the fixture; on the
reporter's library, the grids shrink from 181.8 MB to the 25.9 MB of
distinct grids).
* catalog: the snapshot's shared grids cover the import look too (#2154)
A photo's import look (Photo.import_look, the settings a user default
preset gave the photo on import) can hold segmentation masks, and its
grids can be the same grids that the develop settings, versions or
history steps hold. The snapshot writer referred to such a grid by its
table index, but the table was built from the other settings holders
only and the load resolved only those, so the look's mask came back
empty with a dangling reference.
Photo::settings_holders lists every settings holder (develop settings,
versions, history steps, import look). The writer builds the table from
it and the load resolves references through the same list, so a holder
added there is covered on both sides.
New test import_look_masks_share_the_table_and_resolve_on_load: a look
whose mask shares a grid with the develop settings and a history step,
plus a grid only the look holds. It reloads exactly, and the table holds
both grids once each. Before this change the look's mask came back as
data "" with grid Some(0).
* catalog: state what a snapshot copy shares (#2154)
The snapshot writer copies the catalog to serialize it. Its photos are shared (Catalog.photos holds Arc<Photo>), so the copy is a pointer per photo, not a deep copy; the comment said so without saying which tables are copied. It now lists them, and notes that the derived indexes start empty on the copy.
* develop: a segmentation grid reference is written only by a snapshot (#2154)
The inline serialization of a mask wrote its `grid` whenever one was
set. A `grid` can be set in memory from a document: a mask given to a
command (mask.update, develop.merge) or read from a preset goes through
the derived Deserialize, and such a value stayed in the live catalog.
The next snapshot wrote it inline, and on load the index resolved to
whatever grid sat at that position in the new table, so a mask could
take another mask's grid without a repair being reported. The same
stray value also changed hash64 for identical settings.
The inline form no longer writes `grid`, so it is the pre-v10 form
again. Only the snapshot interner writes a reference, into the table it
builds, so a snapshot cannot hold an index that points elsewhere.
New tests: stray_grid_is_never_written_outside_the_interner (develop)
and stray_grid_from_a_document_is_not_written_as_a_reference (catalog: a
stray reference is not resolved to another photo's grid after a reload).
Both failed before this change: the first wrote "grid":3, the second
loaded photo one's grid into photo two.
* Address review for pull request 2203
* Format the files this pull request changes
* catalog: don't clone a grid that is already in the snapshot's table
The snapshot's grid interning indexed with `entry(m.data.clone())`:
the whole grid was copied before the map said whether it was already
there, so every history step that repeats a mask's grid paid a needless
allocation and copy on the snapshot path. The lookup is borrowed now
(`contains_key`), and a grid is cloned (into the pool and the table)
only when it is new, in the same first-appearance order.
The background snapshot also held two catalogs: `snapshot_in_background`
clones the catalog for the worker, and `write_snapshot` cloned it again
to attach the grid pool. The writer now takes the catalog by value and
the background path hands over its copy, so a snapshot in flight holds
one catalog; the synchronous path keeps its own single clone.
Not observable in behaviour: the grid tests and the catalog suite pass
unchanged.
* Tests: the hostile-mask test names the new grid field
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: eliets2 <287273517+eliets2@users.noreply.github.com>
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* LR-BEHAV-RENDER-FIDELITY: V3 camera tone curve rolls off in stops past its last knot (#1632)
A raw's camera tone curve is fitted only to camera JPEG tones below 0.85, so its last knot sits
1 to 3 stops below the sensor's white. Past it, CameraTone::apply closes on white exponentially in
linear light: the sensor's white renders at 8-bit 246-254 at Exposure 0 and 254-255 from +1, and
raising Exposure turns the top stop the sensor recorded white.
Process V3 extends the curve with CameraTone::apply_rolloff: same value and slope at the knot,
then gap / (1 + c (2^t - 1)) at t stops past it, the gap halving every stop in the end. On 11 CC0
corpus files with a fitted look, unclipped pixels rendering white drop from up to 22.5% to 0 at
+1 EV and from up to 35% to 0 at +2 EV; Exposure 0 renders change by at most 1 code on average.
V1 and V2, the fit itself, JPEGs and raws without a fitted look are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* LR-BEHAV-RENDER-FIDELITY: V3 generic raw curve rolls off in stops too; DRO-off, DNG and GPU checks (#1632)
Raws without a camera curve take ToneMap::hdr, which reached white about 1/4 stop past the
sensor's white and clipped there (o.min(1.0)). Process V3 now uses ToneMap::rolloff_hdr: from half
a stop below the white point (tone::GENERIC_KNEE_STOPS) the extended Reinhard curve hands over to
the same stop-based shoulder as the camera curve (tone::rolloff_past, shared with
CameraTone::apply_rolloff), with the same value and slope at the join. The sensor's white renders
at about 235 / 248 / 252 at Exposure 0 / +1 / +2 where V1 and V2 render 239 / 255 / 255. On 6 CC0
DNGs on the generic curve, unclipped pixels rendering white drop from up to 8.4% to 0 at +1 EV and
from up to 17.2% to 0 at +2 EV.
The DRO-off gate (look_fit::at_most) also checks the V3 shoulder; the rate bound already implies it,
so no fit changes and LOOK_VERSION stays. Tests: the generic shoulder (join, slope, monotone, below
white, no kink), a regression test that fails with the clipping curve, a DNG ProfileToneCurve under
V3, the DRO-off property tests on the V3 shoulder, and a per-process camera-curve GPU check.
Docs: process-versions, parity checklist (LR-BEHAV-RENDER-FIDELITY, LRC-DEV-PROCESS), gap 3.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* LR-BEHAV-RENDER-FIDELITY: what's new: process 3 keeps raw highlights when Exposure is raised (#1632)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* LR-BEHAV-RENDER-FIDELITY: a flat last camera-curve segment joins the V3 shoulder with its own slope (#1632)
The V3 camera shoulder took the last segment's slope with a floor of 0.1, so a flat or shallow
segment (valid for a fitted, DNG or saved curve) joined with a kink: slope 0 on the curve, about
0.1 just past it. The shoulder now keeps the segment's own slope at the knot. Below 0.1 a quadratic
term in 2^t - 1 joins the denominator: it adds no slope at the knot and makes up the 0.1 pace
further up, so a flat curve still closes on white. Segments at 0.1 or steeper are byte-identical,
and the generic curve passes no floor. Comments now say the shoulder approaches white in real
numbers and can round to it in f32. Found in an independent review of the branch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* LR-BEHAV-RENDER-FIDELITY: V4's GPU test pins V4; the corpus DRO photos keep their knots under the V5 bound (#1632)
The GPU light-operator test assumed the default process is V4; it now sets V4, since V5 is the
default. The corpus DRO test checks that dro_off's V5 bound leaves the second-last knot where
the rate bound puts it on the Sony DRO samples, so their V1 to V4 renders don't change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* LR-BEHAV-RENDER-FIDELITY: the DRO-off curve is main's again, so V1 to V4 keep it (#1632)
CodeRabbit found that the V5 bound in `dro_off` could move the second-last knot of a DRO
photo whose fitted last segment is flat, and V1 to V4 read that curve too. `dro_off` and
`at_most` are back to main's, so the camera-look fit is unchanged and LOOK_VERSION stays.
The DRO tests check the V5 shoulder where the lowered segment's slope over its squared gap
is at most the fitted one's (then it stays below), and on the Sony DRO corpus samples.
Also: `rolloff_hdr`'s doc names the HDR lift, and the release note names DNGs whose curve
already reaches white.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Main took V3 (sharpening) and V4 (calibrated Contrast and Blacks) while this was
open. Neither is in a release yet (v0.18.1's latest is V2), so the grain joins V4
rather than adding a process: V1 to V3 keep the value noise, V4 draws crystals.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: suppress isolated hot photosites in the raw mosaic (#820)
Noise model fitted to the image, candidates 5 sigma above every same-colour neighbour, kept when two or
more direct neighbours are lit (real light); adjacent hot pairs are replaced too. LIGHTCRAFT_HOT_PIXELS=0
turns it off, LIGHTCRAFT_HP_DEBUG=1 prints statistics. Renders are cached apart from older ones.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* WIP: hot pixel suppression off by default (LIGHTCRAFT_HOT_PIXELS=1 turns it on)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #1345: mosaic outlier filter: cache key no longer names the #858 comparison switch (merged upstream)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #1345: mosaic outlier filter: fixed thresholds (no LIGHTCRAFT_HP_K / _SPOT knobs), statistics under LIGHTCRAFT_PROFILE
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #1345: Remove Hot Pixels, a box in Detail ▸ Noise Reduction, on for newly imported raws
`Detail::nr_outliers` replaces single outlier photosites in the raw mosaic before demosaicing. It is
true in `DevelopSettings::for_raw` and false by default, so edits saved before the box existed keep
their look. The loaders take the flag (no more `LIGHTCRAFT_HOT_PIXELS`), a decoded source records
it, and a cached raw source decoded with the other setting is decoded again. The box shows for raws
only (`check:detail.nrOutliers`).
* #1345: Remove Hot Pixels off keeps old settings' JSON; smart previews fit either setting
- `detail.nr_outliers` is left out of the stored JSON when off, so settings saved
before it keep their hash and cached thumbnails. Copy / paste, presets (also
at an amount), preset updates and Auto Sync work on
`DevelopSettings::to_json_for_merge`, which states it, so turning the box off
still carries over.
- `DecodedSource::fits_outliers` accepts a smart preview (`from_proxy`): it has
no mosaic, so an offline raw with the box on keeps reusing the decoded proxy.
(review of #1350)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #1345: the Detail eye and Reset Detail switch Remove Hot Pixels off
`DevelopSettings::removes_hot_pixels` (the box and the Detail section's
eye) decides the raw decode in the app, the web worker and the thumbnail
bench, so a Detail section that is off contributes nothing here either.
Reset Detail resets the box to the general default (off), like the
sliders it resets.
(review of #1350)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #1345: the hot pixel limit counts only replaced photosites, and can be set
The 0.2 % limit was checked against the candidates before real light was
filtered out, so a dense star field reached it with its stars alone and
kept its hot pixels too. It now counts the photosites that would be
replaced, as the module docs say.
The limit is now a parameter (RawImage::suppress_hot_pixels_with, default
HOT_PIXEL_MAX_SHARE) and a setting: Settings > Performance > Hot pixel
limit, applied with the new command app.hotPixelLimit. Changing it forgets
the decoded sources and changes the render cache keys of photos that
remove hot pixels; at the default every key stays as it was.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* #1345: the app's default hot pixel limit is the default
The setting is an f32: 0.2 % read back as 0.2000000029… % was a new limit,
so every start forgot the decoded sources and changed the render keys of
photos that remove hot pixels. A value within a millionth of the default
now is the default.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Format the imports
* Web loader test states what it decodes with
* Format the media exports
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
* LR-BEHAV-RENDER-FIDELITY: split V3 Contrast and Blacks
Port calibrated global Contrast and Blacks with shared CPU and GPU tables.
Preserve V2 Whites, local adjustments, other source paths, and all V1 and V2
renders and persistent cache keys.
Generate the constants from public Contrast and Blacks fits. Cover numeric
references, legacy renders, keys that include the resolved process, windows
and GPU parity. Document the measurements, limits and provisional number.
Co-Authored-By: Codex <noreply@openai.com>
* LR-BEHAV-RENDER-FIDELITY: reduce V3 preview cost and sanitize fits
Compose calibrated CPU preview operators over linear input and skip unused
mix endpoints. Keep high-bit-depth exports on the original operator path.
Require three distinct photos per published error group and band, regenerate
the fit hashes, and cover the sanitizer with synthetic tests. Document release
measurements and identify the separate measurement tool proposed in #1181.
Co-Authored-By: Codex <noreply@openai.com>
* LR-BEHAV-RENDER-FIDELITY: preserve V3 luminance evaluation
Retain the original operator evaluation for luminance mixes, including
preceding Contrast, so preview interpolation cannot change the cutoff.
Keep the fused per-channel path and exact deep exports.
Add CPU and GPU regressions for both uniform cutoff fixtures. Document
the measured CPU cost of positive Blacks and the retained fused path.
Co-Authored-By: Codex <noreply@openai.com>
* LR-BEHAV-RENDER-FIDELITY: finish split-module integration
Import the persistent process-key helper directly in the session module. Keep the existing V3 operator selection and evaluation order in an inline helper so the combined finish-stage closure stays within the complexity limit.
Refresh the V1/V2 golden hashes only after the exact fixture produces identical hashes on plain current main. Keep the cross-platform legacy samples unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* LR-BEHAV-RENDER-FIDELITY: date the calibrated Light gap summary
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
* LR-EDIT-DETAIL-SHARPEN: Radius and Detail work, and sharpening acts at pixel scale (#757)
* LR-EDIT-DETAIL-SHARPEN: an enlarging export keeps every Radius step (#757)
The sharpening blur's sigma was capped at 4 px, so a 2x export rendered
Radius 2 and 3 alike (both scaled past 4 px). The cap is now the largest
sigma the Gaussian taps support, GAUSS_SIGMA_MAX (64), which the CPU and
GPU blurs share. Test: enlarged_export_keeps_radius_steps_apart.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ti8KemZbjE2ZgHgV1q1BM
* LR-EDIT-DETAIL-SHARPEN: preserve process-aware previews after rebase (#757)
Use the V3 pixel-scale blur and Masking weight for the Radius, Detail and
Masking previews on both renderers. Preserve the legacy texture-band previews
for V1/V2 and compute the same Gaussian when sharpening is disabled.
Cover process selection, radius changes, and prepared/fresh plane equivalence.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ti8KemZbjE2ZgHgV1q1BM
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>
Grain under the new process V3 is drawn from a simulated emulsion of crystal
layers, after Aurélien Pierre's crystallographic grain model (implemented from
the article's description). It fades out towards black and white as on a print,
is applied symmetrically in the display-encoded domain (no shadow darkening, no
grey specks in blown highlights), and matches Lightroom Classic's strength and
grain width at mid grey.
The emulsion is drawn once per Size / Roughness / seed on two periodic tiles in
frame coordinates and kept as summed-area tables, so each output pixel takes
the exact mean of the emulsion under its footprint: a preview is the export's
grain box-downscaled. CPU and GPU read the same tables (the GPU from the finish
kernel's aux buffer). V1 and V2 keep their value-noise grain exactly.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mask coordinates lived on the corrected frame, so a Transform, Upright or lens-correction change
moved the photo under them and the masked look stayed behind, offset from the person it was drawn
on (4.3 px on a 240 px render under Vertical 25 + Rotate 4: about 100 px at 6000 px). Rotate Left /
Right turned the crop but not the masks.
A mask's coordinates are now on the photo before the warp (Mask::on_photo, catalog format 10):
the CPU render, the GPU render, Auto Mask brush windows and the on-photo tools map them through
the warp (Frame::for_mask, Warp::from_source). Rotate Left / Right turns masks with the photo
(mask_space::turn). The AI models see the photo without lens corrections, Upright, Transform,
crop or flips, so stored Object / Prompt selections stay on their content and changing those
doesn't ask the model again. Older masks (no on_photo) render where they were and move onto the
photo, without moving, at their next edit (mask_space::attach).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every output pixel goes through every eye, and nothing limited the list:
a sidecar, preset or agent with 100,000 eyes made one preview take hours.
The render resolves the first MAX_RED_EYES and redeye.add refuses more,
as Point Color does with MAX_POINT_COLORS.
Mask ids come unchecked from develop.merge, sidecars (lc:settings) and
pastes. With a mask id of u32::MAX, next_mask_id() and Preset::apply
added 1 to it: debug builds panicked, release builds wrapped to 0, so
the second new mask got the same id as the first.
next_mask_id() now falls back to the lowest id no mask uses when the
highest is at the limit, and Preset::apply takes each preset mask's id
from it instead of counting on its own, so mask.add, mask.brushStroke,
mask.duplicate and presets with masks all get unused ids.
Render cost is pixels x samples (CPU and GPU), and only mask.add / mask.update capped the list, so a
sidecar's lc:settings, a preset, develop.merge, render --settings or a catalog / history load could
carry thousands and stall a render or lose the GPU device. MAX_COLOR_RANGE_SAMPLES moves to
lightcraft-develop and ColorRange::samples deserializes through a capped visitor (the first 64 in
order, the rest skipped as IgnoredAny); the CPU and GPU renders also take at most 64 for settings
built in code.
Found while testing crates/mcp/src/base64.rs:20 (base64_decode)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A photo that was given a creative or film profile cannot get back to its neutral look through the Profile section's reset, which is what the report describes as edits that refuse to go back to zero.
Make reset_section restore the whole profile (id and amount) when the Profile section is reset, so the section really returns to its default state.
Test: resetting_the_profile_section_restores_the_default_profile failed before the change and passes after.
Found while testing crates/develop/src/controls.rs:98 (ControlSpec::format)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Found while testing crates/develop/src/controls.rs:413 (split_indexed)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
- lensfun's data/db (CC BY-SA 3.0) is fetched by the desktop app on first
run into <config dir>/lensfun, pinned to commit 43f9e001 by name, size and
SHA-256, staged until every file is verified, with an activity row (never
bundled). LIGHTCRAFT_LENSFUN_URL lists other mirrors; LIGHTCRAFT_LENSFUN_DIR
still wins. lens.downloadDatabase / lens.databaseStatus for agents.
- The database is read per folder and again after a download; when it
changes, library raws without a profile whose lens it knows are probed in
the background and get it (untouched photos switch the correction on as
import would); ticking Enable Lens Corrections looks those photos up again
(library.refreshLensProfiles).
- EmbeddedLens records its source (file / lens database); the Optics panel
says "Profile: <lens> (lens database)", "Profile: from the file" or
"No lens profile found for <lens>." (13 locales).
- Tests: pinned download and refusal of a wrong file, the lookup and its
edited / untouched rules, and presets / Copy-Paste / Sync carrying only the
switch and amounts, each photo keeping its own lens's profile.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 773740fbb22eb66e7f62bada9cb32b594b6ff4d7)
A sidecar's lc:settings became the photo's settings through plain from_json, without the
keep_in_range that #1960 gave merged settings, and keep_in_range itself leaves a turned crop
unbounded. A crop rect of 0..1000 at any angle made the native size of a 6000 x 4000 photo
6,000,000 x 4,000,000 px, which a full-size export passes its memory check with and allocates.
- DevelopSettings::from_untrusted_json (from_json + keep_in_range), used for lc:settings.
- keep_in_range keeps the crop angle within +-45 degrees (not finite: 0).
- CropGeometry::bounded clips the crop to the bounding box of the photo turned by its angle,
which holds every crop that stays on the photo (kept bit for bit); Frame applies it, so
every source of settings is covered.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K93HTyCiwYvbRGaAkjPvXn
Task: LRC-LIB-CATALOG-IMPORT
Count offline records, Local promotions and virtual copies correctly. Keep destination, warnings and errors in a persistent import result, with Show in Library clearing filters. Preserve library-switch ownership, reimport identities, existing edits and one-step undo.
Avoid repeated missing-original probes and unnecessary staged-photo, catalog-operation and develop-patch copies. Preserve upstream phased progress and typed cancellation. Address Astra review findings with regression coverage.
Validated the combined main tree with all eight cargo xtask ci gates (3,462 passing test executions; zero failures), fresh 30k import/persistence/metadata checks, duplicate-free same-session and reopened reimports, and visually inspected headless screenshots. Historical performance comparisons apply to the f730805d production changes before main integration; native Windows import/GUI acceptance remains unqualified.
Generated with Codex.
Brush strokes record a pen pressure (0..1) per point from egui touch
force while Brush > Pen Pressure is on (default). Each dab's radius goes
from a tenth to all of the brush, and its flow is proportional to the
pressure, in the committed stroke and the live preview alike. A mouse
stroke stores no pressure, so documents and renders are unchanged. The
GPU mask kernel leaves pressure strokes to the CPU. mask.brushStroke takes
`pressure`; bad lists are refused. Also satisfies clippy 1.99's
chunks_exact_to_as_chunks in spots.rs.
Sources: own design.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
New `inpaint` crate (L1): multi-scale patch-based completion with a PatchMatch
nearest-neighbour field, seeded by a membrane fill. Deterministic, no panics on
hostile sizes, cancellable. Ported from PhotoCraft (MIT OR Apache-2.0).
Remove tool: a fourth spot mode, `fill` ("Content-Aware"), rebuilds the spot
from patches of its surroundings instead of one source; coarse-to-fine, so the
structure is chosen at a scale set by the spot size and preview and export agree
(tested). spot.add leaves its source unset.
Sources: C. Barnes et al., PatchMatch (SIGGRAPH 2009); Y. Wexler, E. Shechtman,
M. Irani, Space-Time Completion of Video (TPAMI 2007); P. Perez et al., Poisson
Image Editing (SIGGRAPH 2003) for the membrane fill; code ported from PhotoCraft
crates/algo/src/inpaint.rs + poisson.rs (a680ed22).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The highlights/shadows base (fast guided filter of log luminance, eps 0.35)
followed thin high-contrast detail, so the per-pixel shift flattened twigs,
lines and texture in bright areas (and dark ones under Shadows); Exposure
kept them.
This changes how every existing edit with Highlights or Shadows renders, so
it ships as a new rendering process (docs/process-versions.md):
- Process::V2 (version 2) is added and made LATEST. New photos and Reset get
it; existing edits stay on V1 until Update to Current Process. Settings
saved without the field still load as V1.
- From V2 the base is the same guided filter of a separable median of log
luminance (radius 0.15 % of the long edge, <= 24 px): fine detail takes its
surroundings' shift and keeps its contrast, region steps stay put (no new
halos). V1's base is untouched: local::tone_base_detail is 0 under V1 and
tone_base then is exactly guided_fast(l, sigma, BASE_EPS), as before.
- CPU (local::prepare) and GPU prepare (median_h / median_v kernels, bit for
bit with the CPU median) both branch on it via PlaneSigmas::base_detail.
- The base plane's cache key is now (sigma, process, median radius)
(local::BaseKey), so a warm cache never serves one process the other's
base. plane_at is shared with the GPU crate.
- finish::base_tone: V2 uses V1's tone map.
Tests: V2 keeps twig/local contrast (>= 0.9 of Exposure's) with no halo; V1
plane sigmas have no median and its base equals guided_fast bit for bit; V1
and V2 render alike without Highlights/Shadows; warm-cache renders across
V1/V2 switches equal fresh ones (fails if the key drops the process); GPU
matches CPU on both processes at 720 and 2400 px, cached and not.
Pentax 645D 2401 at 4000 px: main and V1 renders bit-identical (plain,
Highlights -100, Shadows +100). Highlights -100 bright rel. detail
0.095 (V1) -> 0.147 (V2), Exposure -1: 0.124; Shadows +100 dark rel. detail
0.126 -> 0.148.
RENDER_CACHE_VERSION 54 (adjust at merge).
Raws without matrices in the file (ARW, NEF, RW2, RAF, CR2, CR3, PEF, SRW,
ORF) were all edited on the relative white-balance scale (6500 K / 0 = as
shot), even when lightcraft_raw::spectral has measured matrices for the
camera. Those 52 bodies (ILCE-7M3, ILCE-7M4, D850, EOS 5D Mark III...) now
edit in Kelvin like a DNG and like Lightroom.
Design:
- One decision on both sides: spectral::find_camera("Make Model") backs
catalog::relative_wb_camera (Photo::relative_wb); files::WbScaleOf decides
the same from the decoded file. A corpus test asserts they agree.
Photo::fitted_look keeps the old predicate for smart previews.
- The matrices only convert: As Shot is the file's multipliers read through
the model's ColorMatrix1/2 (spectral::as_shot_white_through). The look
(JPEG fit / profile / spectral fallback) is unchanged, and the slider
adapts from that white with Bradford. The camera-space rebalance stays
reserved for files with their own matrices.
- Presets resolve to their Kelvin values (WbMode::preset, sources cited).
- The Color panel shows the white balance in effect (effective_wb).
- XMP: crs::Target::for_file takes the camera; matrix cameras read
crs:Temperature as Kelvin (marked "scale": "kelvin"), others keep the
#510 as-shot shift.
Migration (no look changes):
- WhiteBalance.scale: WbScale { Legacy (absent in JSON), Kelvin }. A
white balance without a scale keeps its old meaning. On a spectral-Kelvin
raw (SourceInfo.legacy_relative_wb) the pipeline composes the old
adaptation (6500 -> value) with the new one (as shot -> ...) in Bradford
cone space (local::legacy_white). Von Kries scalings compose exactly, so
the matrix matches to f32 and the pixels are identical
(pipeline legacy_relative_white_balance_renders_as_before_on_a_kelvin_raw,
media old_relative_white_balance_on_a_kelvin_camera_keeps_its_look...).
- Every white-balance writer (develop.set/adjust/quickAdjust/wb/wbPick/
reset) first runs local::normalize_wb: a legacy value becomes the Custom
Kelvin value with the same look and is marked Kelvin. Partials without a
scale (old presets, develop.merge) stay legacy.
- Catalog format 7: Op::SetAsShotWb replaces the 6500/0 as-shot recorded
by older imports when the file is next decoded or reloaded (system op,
not an undo step). Format-version test updated.
- The web wire carries legacy_relative_wb.
Docs: parity (LR-EDIT-COLOR-TEMP), camera-preview-colour, xmp-interop,
lightroom-catalog-import, control-protocol, mcp, whats-new.
- `DevelopSettings.hdr`: enabled, headroom limit (`max_ev`) and SDR-rendition
offsets (brightness, contrast, highlights, shadows, whites, clarity), with
control specs (`hdr.maxEv`, `hdr.sdr*`) and copied with the Light group.
- `ToneMap::hdr` / `display_hdr`: the SDR curve through the midtones, with
highlights lifted up to `2^max_ev`; identical to the SDR tables at peak 1.
- `OutputDepth::F32Hdr`: unclamped linear output up to the peak. The finish
stage carries the peak through highlight desaturation, gamut mapping,
encoding, curves, grain and LUT profiles; with HDR off every branch is the
SDR code path, bit for bit.
- `settings_for`: every non-HDR render (CPU and GPU) uses the SDR rendition.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
