apps/lightcraft/src/main.rs: kept main's split; hunks ported (clear_color, compose_window, with_transparent); test moved to tests.rs
crates/ui-egui/src/panels/settings.rs: deleted on main; checkbox ported to dialogs/settings/performance.rs
crates/ui-egui/src/state.rs: compose_window field and default ported to state/settings.rs
crates/ui-egui/locales/*.json: main's file plus the new key
docs/gaps.md, docs/parity-checklist.md: main's header and rows plus the PR's additions; duplicated header line and blank lines dropped
A data line such as `nan 0 0` starts with a letter and was skipped as an
unknown keyword, so a file with enough other entries still parsed.
(CodeRabbit review on #2540.)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
The sam3.safetensors on community mirrors (AEmotionStudio/sam3,
1038lab/sam3) is a conversion of Meta's original sam3.pt: its tensors
keep Meta's names, and its RoPE tables are C64. Renamed to
model.safetensors, it failed to load with "unsupported dtype
Some("C64")", which read like a LightCraft limitation.
Weights::open now lists a tensor of another dtype instead of failing
the whole file; reading it fails with the dtype error (LightCraft
computes RoPE itself and never reads those tables). Sam3::load_on then
checks the format: when the backbone's first tensor in Hugging Face
naming is missing and the file has Meta's detector.backbone. or
tracker. tensors, the error says it is Meta's original checkpoint and
that model.safetensors from facebook/sam3 in the Hugging Face format
is needed. docs/ai-masks.md says so for installing by hand.
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.
UPDATE_APP (native builds; craft-update is a native-only dependency) carries our 128 px icon and accent (#f2a516, its colour in ArtCraft Launcher). The updater, the self-update
helper and craft-update's startup prompt all get them through crate::UPDATE_APP; the
prompt draws the icon, the accent and "by ArtCraft" (craft-update's default developer).
craft-update is pinned to storytold/craft-libs main at 1065653e7 (#434).
Clippy fixes for Rust 1.99 in untouched code (same logic):
- crates/engine/src/cmd/export.rs
- crates/ui-egui/src/dialogs/rules_editor/rules_move.rs
- crates/ui-egui/src/panels/detail.rs
The test's stored image and LightCraft's size of the photo were both 20 × 10, so
fitting radials to the photo's size instead of the stored image went unnoticed.
The photo is now already in the library at its shown 10 × 20, as a vertical shot
is.
The catalog's XMP is merged before the develop row, and its masks were taken as
they are, on the stored image: when the row has no masks of its own to replace
them, they stayed a quarter turn off on a vertical shot. They now go through the
same frame as the row's. A radial is fitted to the stored image before it is
turned, so its radii swap with the stored aspect and not the sidecar default.
Updating a photo already in the library keeps its Rotate Left / Right and Flip in
LightCraft, which LightCraft draws masks after, but the masks went through the
catalog's orientation only: an upright photo turned right in LightCraft got an
unturned gradient. They now go through the catalog's orientation and then the
photo's own.
With Show Pins on, Object and Describe masks had no pin on the photo, so they could only be picked in the Masking panel. An Object component's pin now sits at its first click and a Describe component's in the middle of what its segmentation selected. Clicking the pin selects the mask; dragging it changes nothing and adds no History step. Subject, Sky, Background, People, Landscape and the range masks still have no pin.
A hostile segment now lays only its end point, so five of them no longer
fill the stroke budget. The test asserts the endpoint-only count directly
and proves that a stroke which has spent its count takes no more through
push_dabs_counted, which tracks the budget across buffers.
push_dabs clamped the number of intermediate dabs of one brush segment to 1,000,000, so a
finite but extreme segment (a point 10,000,000 px away) still allocated a million dabs. A
segment that would need more than that many now keeps only its endpoints; ordinary
spacing and the segment's end point are unchanged.
Adds oversized_brush_segments_skip_intermediate_dabs, which checks both the extreme case
(2 dabs) and an ordinary feathered-brush segment (21 dabs, end point kept, spacing kept).
The docs record the fix under gap 24 and LR-MASK-BRUSH; the parity status stays partial.
An Object / Describe mask is stored as a model's logit grid (288² over the whole photo,
~20 px cells on a 24 MP export) and was enlarged by bilinear sampling alone, so its edge
spilled 1–2 px onto the background; raising the mask's Exposure turned that strip into a
bright outline in previews and exports (CPU and GPU: the GPU renderer evaluates these
shapes with the same CPU `shape_alpha`).
`sample_seg` now guided-filters the sampled logits by the photo's log luminance where the
grid is coarser than the output: the fast (subsampled) guided filter, a window of 1.5 grid
cells, so a preview and an export put the edge in the same place. Filtering logits, not
coverage, lets the confident side win (the spill goes to ≈ 0, not to a mean of ≈ 0.1).
Pixels whose window is all inside or all outside, and edges the photo has no contrast
across, keep the plain sample exactly. Refine Edges still runs afterwards on the combined
mask and finds the edges in place: no second halo, no tightening.
One implementation: `guided_cross` (Refine Edges, Auto Mask) and the new
`guided_cross_fast` share `guided_coeffs`; the subsampled form uses
`local::guided_fast_step` and a box `resize`, like `local::guided_fast`. `guided_cross`'s
output is unchanged.
Existing AI masks become 1–2 px tighter at a subject's edges, on every process; their
inside, outside and contrast-less edges are unchanged. This lands in place under the
bug-fix rule of docs/process-versions.md (output that is in neither the photo nor the
edit), noted there.
Cost per AI selection (M2 Pro, 12 cores; one shape_alpha, before → after):
24 MP 25.7 → 48.2 ms, heap peak 96.5 → 108.8 MB; 60 MP 64.1 → 109.9 ms, 239.9 → 256.7 MB;
2.7 MP preview 3.1 → 10.6 ms, 11.2 → 26.5 MB.
Tests (a dark disc on a light background, its mask on a 32² grid): ≈ 0 one and two px
outside and ≈ 1 inside, all around (1 px outside was 0.66), bit-identical away from the
edge; with Refine Edges 50 / 100 (was 0.29 outside) and the edge within 1 px of the
unrefined one; the same edge position at 256, 512 and 1024 px; a Prompt mask's window
matches the whole render.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The existing synthetic lossy RGB fixture tiles are re-declared grey by a
header edit (colour space RGB to Grey, dropping the 6-bit primaries field
a grey encoding does not carry, per the ColourEncoding bundle). Their XYB
frame data is unchanged, so they decode as one grey plane whose rendered
channels differ. The test checks decode against the gradient's BT.2100
luminance in the linear and sRGB curves.
Refs #275
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ti8KemZbjE2ZgHgV1q1BM
Lightroom Classic's HDR and panorama merges of monochrome raws store a
one-plane LinearRaw image as lossy (XYB) JPEG XL tiles whose codestream
declares a grey colour encoding (16-bit float with a linear curve, or
16-bit integer with the sRGB curve). Those were refused as "lossy JPEG XL
tile with a single colour plane", so the files opened preview-only.
A lossy grey tile is still coded as three XYB channels. It is now
restored like the RGB case: jxl-oxide renders linear sRGB (never the
declared encoding, which would clip), the single plane is the luminance
(CIE Y, D65) of that, then the declared transfer curve is applied.
One plane must be declared grey and three RGB; HDR curves, other white
points and intensity targets above 255 stay unsupported.
RENDER_CACHE_VERSION 70 -> 71: files that showed their embedded preview
before render from raw data now, under the same content key.
Refs #275
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ti8KemZbjE2ZgHgV1q1BM
aiongg