A drag tick requested the loupe's draft and the frame ended; the draft,
done in 1.5-3 ms on the GPU, was picked up at the start of the next frame,
a frame after the slider moved. Now, in a drag, the loupe waits up to 40 %
of a frame for its draft when the last loupe render took well under that
(not with a render offload, nor zoomed in, where what changes on screen is
the window's draft). A CPU render, which would only make the frame late, is
not waited for.
JobPool::wait waits for the next finished job, which try_recv then hands
out; Renderer::poll's collection of finished jobs is split out so the wait
can turn the draft into the texture.
Co-Authored-By: Claude <noreply@anthropic.com>
The semibold family had a semibold Inter but, for other scripts, the same
regular craft-fonts faces as regular text, so a heading or the chosen tab
in Arabic was drawn at regular weight beside bold Latin.
A fallback face with a weight axis (today Noto Sans Arabic, 100 to 900)
is now registered a second time for the semibold family at weight 600,
through epaint's FontTweak::coords. The bytes are borrowed from the
embedded font, not copied. Faces with one fixed weight, regular and
monospace text, the order of fallbacks and Latin are unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With GPU rendering on and no graphics adapter at all (wgpu: "no GPU adapter among …", e.g. no
Vulkan loader: a `cargo run` outside `nix develop` on NixOS), every render ran on the CPU, much
slower, and only Settings ▸ Performance, Help ▸ System Info and `perf.gpuReason` said why.
The desktop app now queues one start-up notice per session once the device has been tried
(`gpu::ready()`, never blocking): "No graphics processor found: LightCraft renders on the CPU, which
is much slower. Details in Help → System Info.", on Linux with "On NixOS, start it from `nix
develop`." (→, not ▸: no installed font paints ▸.) `panels::notices::gpu_notice` decides from the
reason: nothing when the GPU was turned off (preference, LIGHTCRAFT_GPU, LIGHTCRAFT_GPU_BACKEND=off),
only a software adapter was skipped, or it failed later. Headless sessions and tests never show it
(`app.gpu_notice` is set by the desktop app only). Translated in all nine catalogs; one README
sentence in the Nix section.
Co-Authored-By: Claude <noreply@anthropic.com>
The A7 III's raw-IFD 0x7037 tables were refused until their geometry was checked. Measured against
the camera's own JPEG of the same exposure (Lens Comp. Distortion: Auto) on 27 RAW+JPEG pairs from
one body with the FE 16-35 F4 ZA, FE 28-70 and FE 50 F1.8 (strong barrel to strong pincushion,
compressed and uncompressed, TV and monitor checkerboards): corrected board corners sit 0.06-0.44 px
(median, 6000 px frame) from the JPEG's, against 0.8-26 px uncorrected; LightCraft applies the
camera's amount of correction within 2 %; corrected rows and columns are as straight as the JPEG's.
Sony's crop and the default crop agree on this body, so the warp is centred on the image.
A unit test pins the warp from three of these tables to the camera's fitted geometry; the model
boundary tests now accept ILCE-7M3 and still refuse its neighbours. RENDER_CACHE_VERSION is bumped.
The measurement script handles screen moiré (X-corner check, duplicate corners, consensus lattice
vectors). The corpus test's two ILCE-7M3 samples now expect one warp; raw.pixls.us is not reachable
from this environment, so that test was skipped here.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015gRtdWF1E9358FfzhzYqCS
MediaCache::enforce_budget never evicts the original of the photo on screen (set_on_screen), but it still
counted it. A 64 MP original (Sony A7R VI: 9984×6656 linear float, 760 MiB) nearly fills the default cache
share (768 MiB) alone, so the loop evicted everything else instead: the photo's preview and thumbnail sources,
the rendered previews and the prefetched neighbours. Every edit at 1:1 (the whole-frame render and the
thumbnail), every zoom out and every step to the next photo then decoded the raw again.
The pinned original is now left out of what is compared with the budget. The rest still fits the share; the
original sits over it, as the first commit of this PR already allowed.
Co-Authored-By: Claude <noreply@anthropic.com>
Each drag tick changed the edited photo's settings, so the filmstrip asked
for a new thumbnail render every frame. For an unedited raw shown with its
embedded preview, the thumbnail-level source had never been decoded, so each
of those renders decoded the whole raw (a 64 MP ARW: over a second), several
side by side, and the loupe's drafts queued behind them.
- The edited photo's thumbnail is not re-rendered during a slider drag while
it has one; it follows once the drag ends.
- A thumbnail of a photo whose preview-level source is decoded (the one in
the loupe) is cut from that source (SourceRef::Fit) instead of decoding the
file again; not when the photo has a denoised picture.
Co-Authored-By: Claude <noreply@anthropic.com>
Sony ARWs of cameras without measured colour matrices were edited on the
relative scale (6500 K / 0 = as shot). Their SR2SubIFD stores the
multipliers of the camera's presets at 2500, 3200, 4500, 6000 and 8500 K;
lightcraft_raw::kelvin_presets reads the as-shot multipliers on the curve
through them and they take the spectral matrices' place in the #730
design (as-shot Kelvin and tint only; look, Bradford adaptation and the
pixel-identical legacy upgrade unchanged).
Covered: ILCA-99M2, ILCA-77M2, SLT-A33, DSC-RX10, ILCE-3500, ILCE-7S.
Kelvin-dial shots read back 3400 -> 3396, 5200 -> 5193, 4700 -> 4708,
5600 -> 5594 K; Shade 7493 K. Off-curve constants (isotherm tilt 0.74,
tint spacing 1) measured from the 14 Sony bodies with both spectral
matrices and presets.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Use separate luminance pairs for tone fitting so the camera look follows
its JPEG into deep shadows. Keep colour pairs and holdouts unchanged.
Require enough correlated shadow samples and lower held-out error, with
noise and compression floors and the existing median curve fit.
Add synthetic regressions, bump look and render cache versions, and
record the public multi-make and private numeric validation in the docs.
Fixes#1307
Co-Authored-By: Codex <noreply@openai.com>
An uncompressed Leaf Aptus 22 MOS keeps its 16-bit mosaic in IFD0
(compression 1, BlackIsZero, one sample per pixel) with no Make tag and
no CFA photometric, so `probe` returned None and the file imported as a
greyscale image of the mosaic. Leaf's data block, tag 0x8606 (LeafData
in the ExifTool EXIF tag-name documentation), now marks such an IFD0 as
a raw: OtherTiff, preview only with the reason, as the lossless-JPEG MOS
already is. A rendered RGB image that kept the block stays an image.
The Hasselblad Lunar is a Sony NEX-7 that writes an ARW under Make
HASSELBLAD; only SONY files reached the ARW reader, so it opened as its
preview. A HASSELBLAD file with Sony's raw coding (an IFD with
compression 32767 or the tone-curve tag 0x7010, which no 3FR / FFF has)
now goes there and decodes like a NEX-7: black 512, the SR2SubIFD white
balance. The Tag2010 white-balance fallback, the one table arw.rs keys
by model, takes the body from the maker note's SonyModelID (0xb001)
when the file is not Sony-branded.
Docs: the Lunar is verified in docs/raw/evidence.tsv (236 verified),
raw-parity.md, parity-checklist.md, gaps.md and whats-new.md.
RENDER_CACHE_VERSION 61 -> 62: a Lunar's thumbnails were rendered from
its preview.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One widget drew the tab bar and every row of choices: on General the
languages read as a second tab bar. What was chosen differed from what was
not by its fill alone, 1.35 to 1.56:1 in the four themes, and a tab or choice
reached with Tab showed nothing (the frame with and without the focus was
the same, pixel for pixel).
- widgets::tab_button: a tab is its name on the window, a size up from the
headings inside a page, the open one in the text colour over a 2 pt line
of that colour; no border, no fill. Each line of tabs stands on a 1 pt
line the width of the window, so the open tab's line never hangs over the
names below when the tabs take two lines (a narrow window, or Russian at
full width).
- widgets::choice_button, used by settings::choices: the chosen option keeps
its fill and is outlined in the label colour (5.5:1 or more against its
fill, a button and the window in every theme), and is a radio button to a
screen reader. The Export dialog's own rows of choices are as they were.
- Both, and text_button wherever it is used, show a ring while they have the
keyboard focus: 2 pt in the text colour with a 1 pt line of the surface's
colour inside it, within their rect. A double line, where a chosen option
has a single thin one, so the two are told apart by shape. Tab, the arrow
keys, Space and Return already worked.
Widget ids are as they were (button:settingsTab-{id}, button:{id}-{index}).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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.
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>
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>
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>
bflatastic