General was 970 pt wide and the other tabs about 600, because a row of
controls never wrapped and the widest row set the window's width; the
window was also as tall as each tab's content, so it moved up and down
between tabs and the tabs moved under the pointer. In a 900 pt wide app
window the row labels and the Close button of General were off screen at
the left, and a long library path made the window wider than the screen.
- settings::window draws the tab bar, which stays put, above the page of the
open tab, which scrolls: 560 pt wide and up to 640 pt tall whatever the
page holds, less when the app window is smaller. Each page keeps a scroll
position of its own, and one that goes on below shows its scroll handle
without the pointer on it. It is still drawn in the scroll area every
dialog has, which has nothing to scroll; in a window with under 120 pt for
the page (far below the desktop minimum) that area scrolls tabs and page
together, as before.
- A row's controls wrap in the room beside the label, further lines starting
under the first control, and a label longer than its column wraps in it
(Forget unchanged photos pushed its choices 8 pt out of line).
- Paths are one line, shortened from the front after either kind of
separator, with all of the path in a tooltip only when it was cut: Library
> Location, the folder Auto Import watches (it wrapped over several lines),
the smart previews folder (it lost its end, and had two tooltips) and a
monitor profile's file.
row(), choices() and TABS keep their signatures, the match on the tab is
where it was and the shared dialog code changes by one call, so the open
pull requests that add tabs and rows still merge. Below 640 pt of app
window a row holding a 240 pt field can still be wider than the page.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Without a path, file.addFromDevice took the first device found, so with
two cards connected the album menu imported from whichever came first.
Like File ▸ Import from Device, the album's Import from Device is now a
submenu with one entry per camera or card (or "No Camera or Card
Found"), each passing its path along with the album.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An album's context menu gets Import ▸ with File ▸ Import's ways in
(Import Photos…, Import from Folder…, Import from Device). file.addPhotos,
file.addFolder and file.addFromDevice take {album}; the scan task carries
it and the review chooses it when the scan is done, if it still offers
that album (not deleted, not a folder or smart album).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
library.up / library.down (Up / Down) go to the cell above / below in the
grids (nearest by position in justified rows; the top / bottom row stays
put), and step one photo in the filmstrip.
Sources: own design.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
New Album always put the selection into the new album. Like Lightroom's
Create Collection, the dialog now has an "Include selected photos"
checkbox: ticked by default (today's behaviour), shown only when
something is selected and never for a folder. dialog.newAlbum takes
includeSelected; album.create already had addSelected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Go to History Step (and new Previous/Next History Step commands) loads the
step's settings and moves a per-photo cursor (`Photo.history_cursor`,
`Op::SetHistoryCursor`, catalog format v8; older catalogs open at the latest
step) instead of appending "History: …". Later steps stay listed, greyed in
the History panel, and can be returned to; a new edit made behind the end
drops them first. Each move is one undo step; undoing an edit restores the
dropped steps and the cursor. `history.list` returns `cursor`.
Also: spots.rs uses as_chunks (clippy chunks_exact_to_as_chunks).
Sources: own design (Lightroom Classic / Photoshop History panel behaviour, observed).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Cause: Settings > General > "Confirm before moving photos to Recently
Deleted" defaulted to off, so Delete never asked unless the person found
the setting; and the grid/filmstrip photo menu's Delete Photo ran
photo.delete directly, skipping menus::confirm_delete even with the
setting on.
Fix: the setting is on by default; the photo menu's Delete Photo goes
through menus::confirm_delete like the key and the menu bar. The setting
is now saved as `askBeforeDelete`: every earlier version wrote
`confirmDelete: false` for people who never opened Settings, so that key
is no longer read and those installs ask too. Turning it off still works
and survives a restart. ui.menu.invoke / engine.execute (agents) still
run the command directly.
Test: tests_panels::deleting_a_photo_asks_first_from_the_key_the_menu_and_
the_right_click_menu (failed: off by default, then the right-click menu
deleted without asking) and tests_appearance::delete_asks_first_by_default_
also_for_settings_saved_by_earlier_versions (failed: default off).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A drag renders drafts, which have no HDR histogram, so an HDR edit's histogram dropped to the
SDR layout until the drag ended. Now, during a drag of an HDR edit, a small full-quality render
(Slot::HdrHistogram, 192 px, its own stage cache) runs beside the drafts and feeds the panel at
its own pace: the drafts don't wait for it. The panel also keeps an HDR edit's last HDR histogram
when a render without HDR bins arrives (a draft, a cached thumbnail or stand-in), so it never
swaps to the SDR layout mid-drag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The idle trim (3 s without renders) released the shared device copy of the original a zoom
window is cut from, so pausing between pans made the next pan upload it again: 800 MB for a
64 MP raw, ~1.4 s of "gpu sample" measured (5 ms when it is still there). While a Detail window
texture is held the renderer is not idle; once the windows are gone (zoomed out, another photo,
or another view, which now frees the Detail view's windows) the trim runs as before.
Folds the parts of #995 that #999 lacked into #999:
- engine/media.rs: with a display profile, a diagnostic view keeps the
photo's histogram (taken before the overlay is drawn) and stays out of the
view cache; the clipping previews test sRGB values and are converted for
the display afterwards. Before, holding Alt on a P3 display swapped the
histogram for the clipping view's (mean luma 0.59 -> 0.999).
- Noise Reduction Luminance / Detail / Contrast show greyscale while
Alt-dragged (Overlay::for_control).
- Tests: diagnostic_views_keep_the_photos_histogram (P3 display; fails
without the media.rs change), an end-to-end headless drag that presses
and releases Alt mid-drag and checks the loupe pixels
(tests_alt_preview.rs), and every Alt-mapped id is a real control.
- Docs: NR row, What's New and ui-parity note; parity summary refreshed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Before window waited for the original only when the After's window job was already pending,
but side by side the Before is asked for first in the frame, so both decoded the 64 MP raw at
once; and a window asked for again while the first was still decoding (a pan, the layout
settling at startup) started another full decode beside it (three decodes seen at startup).
Any window now waits while a window job is pending and the original isn't held, and follows
from the decoded original.
A decoded 64 MP original (Sony A7R VI: 9984×6656 linear float, 797 MB) is bigger than the
default cache share (half of 1.5 GiB). MediaCache::enforce_budget evicted it as soon as the
render handed it over, so every pan of a 1:1 view and every slider move while zoomed decoded
the raw again (and lost the shared GPU copy, keyed by the CPU Arc).
The frontend now tells the cache which photo Detail shows (MediaCache::set_on_screen, set per
frame in panels::compare::prepare); that photo's original is not evicted for the budget and is
let go as soon as another photo or view is shown. Keying it on "no newer preview of another
photo" instead does not work: the neighbour prefetch stores previews after the original.
The decoders keep the alpha plane, but to_working converted only the
colour, so transparent pixels kept the black most encoders store under
them: renders, previews, exports and contact sheets showed it. The
working image is now flattened onto white, in linear light like the
rest of the pipeline.
- Files with no capture date in their metadata or sidecar (e.g. exports saved without
metadata) take the file's modification time, as Lightroom does, instead of all landing
under "Unknown Date" (the loupe overlay showed the import date for them). The import
review and its folder/rename templates use the same date.
- The import review counted files with the same bytes as another file in the source as
"already in the library" (8 on a brand-new, empty library); they are now shown apart as
"identical copies".
- View > Grid Info captions are drawn on Square Grid only; choosing one from Photo Grid now
switches to Square Grid instead of seeming to do nothing.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
View > Right Panel (view.rightPanel, F8) hides the right panel and shows the one that was
there again (Edit when nothing was remembered; Crop, Remove, Masking and Red Eye end when
hidden and come back as Edit). View > Hide All Panels (view.allPanels, Shift+Tab) hides the
left sidebar, the right panel, the Presets column and the filmstrip; the next press brings
back exactly what was shown, so a panel that was already hidden stays hidden. Showing any
panel by hand while they are hidden makes the snapshot stale: the next Shift+Tab hides again
instead of resurrecting old state. Both commands take an optional show / hide parameter and
are checked in the View menu while they apply. The top bar and tool strip stay.
Shift+Tab is also egui's "focus previous widget", set when the pass begins and without
consuming the key; with nothing focused it focused the loupe. The shortcut consumes the key
and cancels the traversal. In a focused text field neither key is a shortcut, and Shift+Tab
keeps moving focus as before. On a Mac keyboard F8 is Play/Pause unless fn is held or
"Use F1, F2, ... as standard function keys" is on.
Docs: KEYC-PANELS is partial (Tab, T, F5 and solo remain; F6 / F7 are in PR #1078), KEYC-HELP
is done (F1), KEYC-RATING's missing list drops the already implemented [ ] keys, two View
menu rows are added, gap 28 shrinks, and the parity summary is refreshed with
cargo xtask parity --write (it was already stale on main).
The native menu leaves Shift+Tab to egui (no accelerator, so the macOS menu shows no key hint) and
the native_menu accelerator test lists it with the other keys egui handles.
With XMP auto-write on, photo.readMetadataFromFile committed what it read
and the command handler then wrote the sidecar back, adding lc:settings to
a sidecar that had only another app's crs: settings. Later reads prefer
lc:settings, so LRTimelapse's next crs: edits were ignored. The read now
sets the existing one-command skip_auto_write switch (as photo.removeRegion
does); edits made afterwards are still auto-written.
Tests: a read leaves the sidecar byte for byte and a later develop edit is
still written; the issue's crs:Exposure2012 0.5 -> 1.2 round trip is read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The wheels had Shift (keep the hue, change saturation). Lightroom's other
two modifiers are now there too:
- Cmd/Ctrl-drag keeps the puck's saturation and changes only the hue, so it
moves round its circle; the circle is drawn as the guide, as Shift draws
the spoke. Shift wins when both are down (keeping both would freeze the
puck).
- Alt/Option-drag fine-adjusts: the puck moves a tenth as far as the pointer
from where it was grabbed (the slider's fine-adjust factor), counted from
the press so no travel is lost to egui's drag threshold. It combines with
Shift and Cmd/Ctrl.
- Pressing or releasing a modifier mid-drag re-grabs the puck as it is at
that moment (WheelGrab); wheel_pick takes a WheelLock (Hue / Sat) and
returns finite values for any input.
- A puck at the centre has no hue, so a Shift-drag from there now takes the
angle where the pointer pressed, not where egui first reported a drag.
- The wheel has a hover tooltip naming the modifiers.
Shift-drag already kept the puck's own hue whenever its saturation was 1 or
more; shift_drag_keeps_the_pucks_hue_wherever_the_pointer_grabs pins that.
Tests (tests_grading.rs) drive the wheel through ui.dragWidget with each
modifier and check the develop values and one undo step per drag, plus unit
tests of wheel_pick (lock, clamp, centre, NaN/inf) and WheelGrab.
Hands each selected photo's original file itself (a raw stays a raw: no
render, no copy, nothing added to the library) to the editor set in
Settings ▸ External Editing ▸ Other editor, e.g. DxO PhotoLab. Also on a
photo's right-click menu (Edit In).
- `photo.openOriginalInExternal {ids?, app?}` (UI command, menus.rs): up to
50 photos; demo photos and missing files are skipped with the reason; when
none has a file it fails saying why (toast + error, no panic). Enabled when
the active photo has a file and the host can start programs (not the web).
- Several photos go to one start of the editor (`Services::open_all_with`,
editors.rs `open_all_with`): a single-window editor such as DxO PhotoLab
drops the files that arrive while it is still starting when started once
per file. The system default ("" editor) still opens them one by one.
- Settings hint, translations of the two new toasts, parity rows
LR-EXP-PSD / MENU-FILE-PHOTOSHOP.
Tested by hand on Windows with DxO PhotoLab 8 (one and several raws).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Found using the app on a real library: a folder of 8,700 files on a network share takes about a
minute to scan, the dialog says to go on working, and any rating, label or keyword given to one
of the folder's photos in that minute made the finished scan count as stale. Synchronize then
refused it and scanned again, every time.
A scan is current while the folder holds the same photos (virtual copies aside), each the same
file in the same place. What the person does to those photos does not change which files are
new, missing or moved. It matters only for a photo whose sidecar the scan found news in:
reading that would go over the work, so there nothing may have changed, as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Library-wide caches that don't read develop state (folder/keyword trees,
keyword chips/ticks/names, counts, person names, By Date, filter-bar values,
suggestions, smart-album problems, the Missing count, face hints) key on the
library revision; people, album counts and the rule dialog's count key on
the view revision. The justified grid layout adds the catalog revision to
its key since crops and rotations change cell shapes without changing the
list. The filmstrip shares the visible list instead of copying it per frame.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The equivalence of `header_plan` / `preview_plan` broke for the corpus's
ARW6 pair: a Compression-32766 strip was holed behind its first 64 KiB
prefix, but the header probe validates more there - `parse_tile_header`
walks the 13 stream header words of every tile, `stream_halves` reads
each stream's index table, and `first_half_shift` decodes the residual
stream's first half, which sits behind the earlier streams' data. The
probe read zeros (and 0xFF) there and failed with "ARW6 first-half row
count outside 2..=7" where the whole file decodes (first corpus case:
arw6-sony-ilce7rm6-apsc-land-hq.arw; the corpus is git-ignored, so CI
never saw it).
`tiff_plan` now asks `arw6_keep` (crates/raw/src/sparse.rs) for those
scattered ranges when `image()` reports Compression 32766 for one strip:
the tile table, then per tile, in staged rounds so each ask sits in one
`Need`, the picture/group tables, the stream header words (positions
from the new `arw6::stream_header_positions`, mirroring the group-table
walk), then with the real `parse_tile_header` run, the 13 index tables
and finally each residual first half (its length A is its index's first
entry). A layout that cannot be walked - a corrupt ARW6 - reads whole:
`arw6::decode` stops at the same validation of loaded bytes, so the
probe is still identical. `parse_tile_table`/`parse_tile_header`/`u16_be`
/`u24_be` are now `pub(crate)` for the walker, and `Want::pending_plan`
(renamed from `into_plan`) takes `&mut self` so the walk can keep asking
after the IFD walk answered.
The full-size JPEG these files carry as a `JPEGInterchangeFormat` image
(compression 6/7, where 0x0201/0x0202 are the interchange tag and its
length and `image()` therefore declines) reached no hole at all and made
the plan read it whole: together with the strip work, the header plan
now reads 26-28% -> ARW corpus average 1.7% (the two ARW6 files read
2 / 1%); nothing reads the interchange image in header mode, and under
`preview_plan` `embedded_preview` wants it, so the hole is header-mode
only (the corpus test's 0 / 0xFF fills guard both).
Tests: without the corpus, sparse.rs's synthetic single- and two-tile
ARW6 files (residual stream past the prefix, Qis::REAL) assert the plan
reads past the 512 KiB prefix and probes as the whole file does, for
both fills; with it, `sparse_corpus` passes for both real files, both
fills, both plans, and the ARW6 decode-sum corpus tests are unchanged.
Gates: fmt, clippy -D warnings, heif, parity (+ refreshed summary),
layers, assets and wasm all pass; `cargo test --workspace` has no
failure that clean main doesn't show on this Windows machine (engine
sidecar's 20 fs-fault and ui-egui's denoise-model tests fail there
identically with the fix stashed).
Co-Authored-By: GLM 5.3 Flash <noreply@z.ai>
Compare and Reference View are where focus is checked at 1:1, and their panes show the same
stand-ins as the loupe: a thumbnail while the photo renders, the last render after an
edit, the magnified frame under a window not in yet. Each pane now shows the loupe's
"Rendering…" pill once that has lasted half a second with nothing new (widget
`compare:rendering:<pane>`), and its failed pill ("This photo can't be opened", or
"Original offline · no smart preview", the reason on hover) when the render failed behind
a thumbnail (`compare:renderFailed:<pane>`). Survey's small fit tiles don't.
Compare panes have no draft renders, so a slider drag on the photo would leave its pane
saying "Rendering…" for the whole drag: the photo being dragged doesn't count until the
drag ends. Each pane's wait belongs to the photo in it, so one that moves in (swap, Make
Select) starts its own. A retry of a failed render keeps the failed pill, as in the loupe.
Co-Authored-By: Claude <noreply@anthropic.com>
A photo whose render failed while the loupe showed its embedded JPEG or a thumbnail kept
that stand-in up as if it were the photo; "This photo can't be opened" only showed when
nothing at all could be drawn. Now a caution pill at the "Rendering…" spot says so:
"Original offline · no smart preview" when that is why, else "This photo can't be opened",
with the reason on hover and for screen readers (widget `loupe:renderFailed`). Agents see
it as `ui.inspect` → `loupe.failed`, so one waiting for a finished loupe knows when there
won't be one.
A library change retries failed renders; while the retry of the same key runs, the pill
stays and "Rendering…" doesn't take over. The renderer remembers which photo a failure
belongs to (`failure_of`): the centre message no longer shows the previous photo's error
for a moment after a step. Tests share one render offload (`headless::RenderGate`) that
holds renders and can fail chosen slots.
Co-Authored-By: Claude <noreply@anthropic.com>
ci.yml exists, but main does not pass it yet. The #989 fixes and the
Windows ones (#1052) are still outstanding, so the entry stays open:
6-12 h -> 2-4 h. Headline numbers are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The GPU stage cache mirrors the CPU's: per-mask alpha buffers keyed by
masks::alpha_key, copied into the combined alpha buffer on a hit (no
readback for CPU-evaluated shapes). GpuStages::bytes counts them and the
chromaticity buffer it left out.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`Gpu::new` refuses software adapters (llvmpipe / lavapipe, WARP): the CPU
pipeline is faster. CI runners have nothing else, so the CPU <-> GPU
equivalence tests have always skipped there.
`LIGHTCRAFT_GPU_ALLOW_SOFTWARE=1` admits them. The app never sets it and
the default is unchanged. On lavapipe all 134 compared renders stay within
max 1 LSB, mean <= 0.0003 LSB, the same as Metal on an M4 Pro.
The two big-source window tests used a 24 MP (288 MB) source. That is over
lavapipe's 128 MiB storage binding (the WebGPU default), so geometry ran on
the CPU and nothing was uploaded: one test failed and the other passed
without checking anything. They now use 3200 x 3200 (117 MiB): above
RETAIN_SOURCE_BYTES, so the source is still shared, and uploaded on every
adapter.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A panic inside RenderJob::run or QuickJob::run (a raw decoder or pipeline bug) unwound the
job pool's worker without sending a result. The slot stayed pending and its key was never
asked for again, so the loupe or the thumbnail rendered forever; and the pool never
replaces a dead worker, so after as many such panics as it has workers (2–6) no photo
rendered until LightCraft was restarted.
Both now catch the panic (guard::catch) and return it as the job's failure, answering the
request it came from, so the renderer records it like any failed render: no retry until
the catalog changes, and the workers live on. run() is the one place every render goes
through (the pool, export, Build Previews, contact sheets, face and AI-mask workers);
callers that had their own guard keep working, and the watermark preview's, now
redundant, is gone. The web build aborts on panic, so nothing changes there.
Co-Authored-By: Claude <noreply@anthropic.com>
A new Help item next to Send Feedback… (which stays a plain new issue). The
dialog takes what happened, hides the home folder and photo file names by
default, can add the two previous runs' logs, and previews the issue. Create
Report writes lightcraft-report-<time>.txt next to the logs (what happened,
the System Info rows and the logs, each up to its last 4 MB), reveals it, and
opens a new GitHub issue pre-filled with the same and the end of this run's
log; the link is kept under 8,000 characters. Nothing is sent by the app.
Without a log (web, --memory) the issue holds the system info only.
The System Info rows move to `bug_report::system_rows`, shared by both dialogs.
`app.reportBug {create: true}` does it without the dialog (agents, tests).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The scan already ran on a worker thread, but its dialog was modal and closing
it stopped the scan, so a large folder on a network share held the app for
minutes. While the folder is scanned the dialog's button is now Continue in
Background: the dialog closes and the scan goes on under its activity row.
When it is done nothing pops up. A notice in the activity stack says how many
changes were found (or that the folder isn't there); a click opens the dialog
with that result and what was ticked, without scanning again, and ✕ lets go of
it. A scan that found nothing to do only says so in a toast. Cancel and the
row's ✕ stop the scan as before.
One folder at a time: Synchronize Folder on another folder is refused while a
background scan runs or its notice waits, so minutes of scanning are not
thrown away unasked. Another library opened lets go of the scan. A result
looked at later can be stale: Synchronize already refuses a scan whose
folder's photos changed meanwhile and scans again.
The dialog's one button reads Continue in Background and then Synchronize, so
Synchronize is unavailable for 0.6 s after the scan ends: a click meant for
the first can't start the second.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Photo Merge decoded each raw itself and wrote the reference frame's own colour
tags into the merged DNG. A CR2 (and NEF, ARW and the other raws whose colour is
fitted from the camera JPEG) has none, so an HDR merge of CR2s rendered with no
camera colour: green and about 16 L* dark.
`lightcraft_merge::load_frame_with` takes the raw's colour tags from the caller,
and the engine passes `starting_colour_tags`: the colour the raw opens with
(`starting_colour`) as DNG tags. That is one forward matrix with a colour matrix
and AsShotNeutral that agree with it at the as-shot white, the look's hue/sat
table as ProfileHueSatMap and its tone curve as ProfileToneCurve. Raws with
their own matrices (DNG) keep their tags. The look's chroma curve has no DNG
tag and is left out.
On two CC0 CR2s (EOS 550D, 40D) an HDR merge of three copies against the photo
alone: mean CIE76 dE 26.15 -> 1.07 and 22.89 -> 0.47.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
expand_paths kept its own PHOTO_EXTENSIONS list, which had fallen behind
lightcraft_engine::import::EXTENSIONS. It now filters with
import::is_supported, so folder walks and library.import take the same files.
Fixes#1080
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Settings > Import > Auto Import gains Include subfolders (off by default:
the watched folder's top level only, as before). On, the scan also lists
its subfolders' photos: hidden entries, links to folders and the library's
own folder (where copy-mode arrivals go) are skipped; at most 16 levels and
200,000 entries, with a warning when a bound is hit. An unreadable
subfolder or a non-Unicode name is skipped with a warning.
library.autoImport takes subfolders; library.autoImportScan reports it and
listingWarnings.
First non-Apple GPU verification: 16 tests / 135 cases pass, 124 at
max 1 LSB, 10 bit-identical, one at max 2 LSB (0.0002% of pixels), worst
mean 0.0003 LSB. Recorded in gpu-pipeline.md, hardware-parity.md and
gaps.md. Also as_chunks in spots.rs for the newer clippy lint.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Version 66 keeps version 64's as-shot white balance and black level
offsets; its word 661 is below where the sensor clips, so the white
level stays measured from the data. Checked on 33 R6 Mark III files
from 12 shoots: all now open with their as-shot white balance, black
levels match the masked columns.
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017JKdR4oZ3jRSPPwMLLTa2U
On Wayland a window on a hidden workspace or minimized gets no frame
callbacks, so queued control requests waited 60 s and then ran when the
window came back, doubling retried work. The server now abandons a request
the app hasn't started after 5 s without a frame, says why, and the app
skips abandoned requests. Running requests keep the full 60 s. Also
as_chunks in spots.rs for the newer clippy lint.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
New command `photo.renderToDng` (Photo menu): each selected photo (at most
500) is rendered with its edits as a linear 16-bit float DNG
`<name>-Rendered.dng` next to its original (never overwriting; a demo photo
needs `dir`), added to the library stacked on top of the original, and the new
photos are selected. Colour space proPhoto by default (rec2020, adobeRgb,
displayP3, srgb). A batch holds a cancellable `renderDng` activity row with
progress; cancelling stops between photos and keeps the copies made so far;
a failing photo in a batch is listed and the rest carry on.
Stacked on #1047.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
While no monitor profile is chosen, the Linux app reads the profile the
desktop assigns to the display in colord (org.freedesktop.ColorManager,
system bus, via zbus) on a background thread every 3 s, and shows
previews through it. With several displays it is used only when they all
share one profile; without colord the view stays sRGB. Windows' WCS
needs FFI and stays manual. Also satisfies clippy 1.99's
chunks_exact_to_as_chunks in spots.rs.
Sources: the colord D-Bus API documentation; own design.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
New export format `rendereddng` (export dialog: Format DNG, "DNG of: Rendered
photo"; `app.export`; MCP export tool): the rendered photo, with the edit,
crop, size, output sharpening and watermark baked in, written by the new
`lightcraft_raw::write_rendered_dng` as a LinearRaw DNG of 16-bit float Deflate
tiles in the export colour space. ColorMatrix1 (XYZ -> space), ForwardMatrix1
(space -> XYZ D50), a neutral AsShotNeutral and an identity ProfileToneCurve
make raw converters show it as rendered. HDR edits keep highlights above white.
Bad input (wrong sample count, zero or huge sizes, NaN/inf, out of half-float
range) gives an error or is clamped, never a panic.
Also fixes the Rust 1.99 clippy lint chunks_exact_to_as_chunks in
pipeline/spots.rs that fails `cargo xtask ci` on main.
Sources: Adobe DNG Specification 1.4+ (LinearRaw, ColorMatrix/ForwardMatrix,
ProfileToneCurve); own design.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The \0MRM block container: PRD sensor size, storage and Bayer cell; WBG
as-shot gains in cell order; TTW TIFF for Exif and orientation. Black 0,
white from the saturation plateau. 4 CC0 samples pinned in RAW_SAMPLES;
DiMAGE 7, 7Hi, A1, A2, A200 and Dynax / Maxxum 7D verified. Also fixes
clippy::chunks_exact_to_as_chunks in pipeline/spots.rs.
Sources: public prose description of the MRW layout (Dalibor Jelinek's
MRW notes) and own black-box analysis of the CC0 samples.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The header-only path added in #755 answers for a Fuji RAF, whose preview pointer sits in the first
bytes. A Canon CR3 keeps its preview in a JPEG track, and a TIFF raw (CR2, ARW, DNG, RW2, 3FR …) can
keep its preview tag in an IFD the prefix cuts short: both fell back to `std::fs::read` of the whole
file — tens of megabytes for a JPEG of a few, on the format of the largest bucket in gaps.md (Canon,
33 % of photographers).
`preview_window` now asks `lightcraft_raw::sparse::preview_plan` — the module #961 added for the
import path, which had no production caller — which ranges `embedded_preview` reads, and reads
exactly those: `planned_preview` fills a buffer of the file's length, reads the ranges the plan names
and asks again until it says `Ready`. The buffer is the file's length, which the memory gate counted
already, and its untouched pages stay zero, so what this path costs is the bytes read — on macOS a
freed buffer of that size may sit in the allocator's cache rather than go back to the OS (measured on
a 38k-photo import, #832). The loop gives up past 60 % of the file, the bound step 2's partial read
uses, and a plan that does not fit, a file past 1 GiB or a window that does not decode all end in the
whole-file fallback.
The quick path hands the JPEG to the decoder alone, so two container facts the whole-file path applies
have to be visible in the bytes it is handed, or the file declines and the whole file keeps the
preview:
- a preview colour space of Adobe RGB (`decode_raw_preview` applies it; a JPEG-only decode has the
JPEG's own space, else sRGB). A container that says sRGB does not decline — that is what the decode
assumes anyway, and declining it took the fast path away from a real Sony ARW;
- the file's own EXIF orientation, when the preview JPEG carries none of its own: the plan's header is
a bounded 64 KiB (the header route grows its prefix to the preview's declared extent instead), and
an orientation tag it cannot see would show the preview unrotated.
Measured over the whole CC0 corpus (111 raws): 52 files take this route, reading a median 7.8 % of
their bytes (0.9-27.7 %) — RW2 3.3 %, Leica RWL 4.1 %, ARW 7.5 %, CR3 8.4 %, DNG 9.7 %, CR2 14.3 % —
while the 21 RAFs stay on the header route (median 4.5 %). The other 38 read whole: NEF, NRW, ORF, PEF
and SRW because the planner does not describe them (an SRW plans to the whole file, which the 60 %
budget then declines), plus the ARWs, CR2s, CR3s and DNGs that declare Adobe RGB or whose plan wants
more than that budget — the bytes they read are the ones the plan would have read anyway. Across all
111 files the plan handed on the same preview as the whole file, with the skipped bytes zeroed and
again 0xFF. `LIGHTCRAFT_PROFILE=1` prints
[profile] preview …/arw-sony-a7rm4a-compressed.arw: read 688128 of 61832192 bytes (plan, window 483441)
Tests: a synthetic TIFF/DNG whose preview only its tags locate (identical pixels to the whole-file
path, the CFA strip unread), the same structure without the tag that makes it a raw, a file whose
orientation only the whole file shows, and a file that states Adobe RGB against one that states sRGB;
the opt-in real-file test reports which path answered.
Co-Authored-By: DeepSeek V3.2 <noreply@deepseek.com>
A raw's embedded JPEG, a thumbnail, the previous render after an edit or the magnified
frame under a 1:1 window all look like the finished photo. Once a render has been on its
way for 0.5 s with nothing new on screen, a pill at the bottom of the photo (widget
`loupe:rendering`) says so; above the Navigator when that is in the way.
The wait starts when the render starts coming (an idle app draws no frames), so a quick
render never shows it, nor does a drag whose drafts keep up; once up it stays until
nothing is coming, so slow drafts don't make it blink. It watches what is on screen: the
After or the Before, and the windows in use. Not an activity row: it says the pixels
aren't final (docs/background-tasks.md).
Co-Authored-By: Claude <noreply@anthropic.com>
A Lightroom collection imported whole (11 113 presets, a 42 MB presets.json)
made every interaction take seconds:
- Session::persist ran after every command and serialized the whole preset
list to compare it with the last write: 609 ms per slider tick (release,
the real collection). Session::presets is now a PresetList whose generation
changes on mutable access; persist serializes only when it (or the profile
lists) changed, and skips the write when the bytes hash the same.
develop.set: 609 ms -> 2.3 ms; preset.apply: 598 ms -> 3.1 ms.
- The Presets panel deep-cloned every preset into a BTreeMap, built a row,
widget id and (with thumbnails) a variant render job for each of them every
frame. Grouping is cached per generation and only rows in view are laid
out: 5041 -> ~20 rows a frame, 2.3 ms with 5000 presets.
- The preset pickers (Import dialog, Settings > Import) build only the rows
in view.
- add_presets and opening a library compared every preset with every other
(quadratic); both use hash indexes now. Opening no longer serializes the
list once just to remember it.
Tests: develop commands don't re-serialize unchanged presets (and a change
is still saved), generation semantics, a 20 000-preset import, and the
panel building only visible rows (fails on the old code: 5041 rows).
An ignored bench (presets_scale_bench, LIGHTCRAFT_BENCH_PRESETS) times a
real presets.json.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tests/accessibility.rs walks the AccessKit tree headless in every view,
Develop tool and 13 dialogs and fails on unnamed controls, sliders without
value/range and untitled dialogs. Fixes what it found: text fields are
named by caption or hint, develop sliders expose min/max/step/value text
and take Increment/Decrement, Tab-focused sliders take the arrow keys,
Auto Stack's slider is named. Also as_chunks in spots.rs for the newer
clippy lint. Docs: ui-parity audit section, checklist, gaps, ROADMAP.
Sources: own design.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
AVIF HDR export takes hdrTransfer = pq | hlg (export dialog: HDR curve;
MCP export schema lists it). HLG writes CICP transfer 18 and no clli box.
The window logs whether it shows HDR; today always SDR (eframe configures
an 8-bit surface), with the platform / surface format / headroom / opt-out
rules unit-tested. Also satisfies clippy 1.99's chunks_exact_to_as_chunks
in spots.rs.
Part of #868.
Sources: ITU-R BT.2100 (HLG OETF, inverse OOTF with system gamma 1.2),
ITU-R BT.2408 (203 cd/m2 reference white at 75 % HLG); own design for
the display decision.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Preserve page-backed large-catalog import while integrating upstream catalog and documentation changes. Adapt only the sparse test fixture to the shared upstream fixture helper.
Use the equivalent complete RGB-triple iterator required by Rust 1.99 Clippy; the same lint failure was reproduced on the exact upstream baseline.
Validation: 47 catalog tests, nine spot tests, exact sparse regression, all eight CI gates, and an original synthetic headless import/selection check passed.
Generated with Codex.
Smart collections whose rules all have an equivalent (rating, pick, label,
edited, ISO/focal/aperture, text rules, nested groups) become smart albums;
others stay static with the unmappable rule named in the report. Folder
stacks keep Lightroom's order and collapsed state; reimport skips photos
already stacked. Report gains smartAlbums, smartAsStatic and stacks.
Also satisfies clippy 1.99's chunks_exact_to_as_chunks in spots.rs.
Part of #197.
Sources: own design, from the Lua rule literal structure in public prose
write-ups of the catalog format and synthetic test catalogs.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Photos that tie on the sort key (equal ratings, one import batch, a
burst within a second) now sort by file name before id, in
Catalog::query, Recently Added and auto-stack. Split out of #641.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
