Merge origin/main into #513 (parity row keeps main's Hasselblad/SRW notes)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/camera-preview-colour.md

@@ -1,6 +1,6 @@
 # Sony ARW, Nikon NEF, Panasonic RW2, Fujifilm RAF, Canon CR3/CR2 and Pentax PEF starting look
 
-ARW, NEF, RW2, RAF, CR3, CR2 and PEF decoding supply sensor data and camera white-balance multipliers, but currently no measured camera colour matrix. Treating camera RGB as linear sRGB produces a dark, muted default rendering. The loader now estimates a file-local starting look from that file's embedded camera JPEG, only when a usable camera matrix is absent. All output pixels still come from the RAW sensor data; there is no JPEG replacement or uniform saturation boost.
+ARW, NEF, RW2, RAF, CR3, CR2, PEF and SRW decoding supply sensor data and camera white-balance multipliers, but currently no measured camera colour matrix. Treating camera RGB as linear sRGB produces a dark, muted default rendering. The loader now estimates a file-local starting look from that file's embedded camera JPEG, only when a usable camera matrix is absent. All output pixels still come from the RAW sensor data; there is no JPEG replacement or uniform saturation boost.
 
 ## Colour and tone are separate
 
@@ -10,7 +10,7 @@ Two thirds of the usable pixels train a ridge-regularised 3×3 **chromaticity**
 
 The JPEG's colourfulness also depends on brightness, as a camera's per-channel tone curve makes it: relative to a luminance-only curve, shadows were up to 1.4× more colourful and highlights above 0.85 luminance bleached to 0.1–0.3×, so warm sunlit rock rendered cream instead of white (+4 b* in the brightest fifth of the picture). A **chroma curve** (8 nodes over display luminance, `CameraTone::chroma`) is fitted to that ratio, including the bright pixels the colour and tone fits leave out, and applied in the finish stage right after the tone map (CPU and GPU), scaling chroma toward luminance so luminance is kept. It is kept only when it lowers the held-out error; smart previews carry it in their header, and older headers load without one.
 
-Matrix-only and matrix + table looks are each completed (tone curve, then chroma curve) and compared on the held-out pixels in gamma-encoded display values: in linear values a slightly missed bright rock outweighed a clearly wrong dark shirt. The acceptance gates below still use linear values. Luminance is fitted separately: 32 equal-population bins with robust median knots and pooled-adjacent-violators isotonic regression. The curve preserves black, cannot reverse, and extends beyond observed highlights with a bounded shoulder.
+Matrix-only and matrix + table looks are each completed (tone curve, then chroma curve) and compared on the held-out pixels in gamma-encoded display values: in linear values a slightly missed bright rock outweighed a clearly wrong dark shirt. The acceptance gates below still use linear values. Luminance is fitted separately, by quantile matching: knot *i* pairs the median of the *i*-th 1/32 of the sorted scene luminances with the median of the *i*-th 1/32 of the sorted JPEG luminances. A tone curve is monotone, so it maps each scene quantile to the same JPEG quantile; this needs no pixel-exact registration and is increasing by construction. The earlier fit (the JPEG's median per scene-luminance bin, then pooled-adjacent-violators isotonic regression) broke on lens-corrected, sharpened JPEGs of busy scenes: neighbouring bins disagreed by more than the gap between them, pooling turned them into flat steps (13 of 31 segments on a CC0 Z 6II forest shot) that rendered as posterised patches with hard edges, and regression toward the mean flattened both ends of the curve (issue #475, also #211, #454). On the 1,781 files of the CC0 archive that render, 384 of the 1,023 accepted fits had at least one flat segment (1,073 in total, up to 14 of 31); with quantile matching 1,017 of the 1,023 have none. The quantile fit is slightly worse by least squares than the conditional medians (median held-out RMS 0.0331 against 0.0330, worst +0.013), and on 7 files (compacts, bridge cameras, early Micro Four Thirds) the look cleared the acceptance gates only with the old curve. The search therefore runs once with the quantile fit (all pixels, away from edges, with and without the camera profile's colour) and, only when no look passes, once more with the earlier conditional-median fit, kept as `fit_tone_conditional`; the gates are the same, so no file loses its look. Those 7 files render exactly as before, and 6 of them still have flat segments (35 in total). The curve preserves black, cannot reverse, and extends beyond observed highlights with a bounded shoulder.
 
 The matrix is applied to scene-linear sensor pixels. The curve is carried in `SourceInfo` and applied in the pipeline finish stage, after exposure/WB/local edits. It is never baked into decoded luminance or clipped to JPEG precision. CPU and GPU use the same tone LUT. Contrast, whites and blacks adjust the starting look through the display-domain controls. JPEG neutral rendering and the existing DNG colour model are unchanged.
 
@@ -85,6 +85,11 @@ An embedded JPEG with neither ICC nor EXIF metadata uses Nikon maker-note `Color
 
 Synthetic tests cover crop bounds/CFA preservation, colour-space tags, fallback transfer decoding and metadata precedence. A private Nikon Z 8 sample reports an 8256 × 5504 default crop from an 8280 × 5520 sensor. No private sample or Adobe asset is included.
 
+### Samsung SRW
+
+Samsung SRW decoding (uncompressed files) supplies the as-shot white-balance multipliers from the maker note and no colour
+matrix, so SRW takes the same fit, gates and relative white balance.
+
 ### Canon CR2 and Pentax PEF
 
 CR2 and PEF decode without a camera colour matrix too, but were left out of the fit until issue #310 (CR2 files opening

docs/gpu-pipeline.md

@@ -44,6 +44,17 @@ Overrides (read once at launch):
   the compute device always used Vulkan + DX12 (+ Metal).
 - `LIGHTCRAFT_GPU=0`: GPU rendering off for the process (the window is unaffected).
 
+**DX12 shader compiler (issue #471).** Every instance (window and compute) compiles DX12 shaders with
+FXC (`d3dcompiler_47.dll`, part of Windows; `lightcraft_gpu::backend::backend_options`). wgpu's
+default, `Auto`, loads whichever `dxcompiler.dll` the DLL search path finds first. LightCraft ships
+none, so that copy belongs to another program (a Windows SDK, a folder on `PATH`). An older copy without
+`dxil.dll` beside it (e.g. DXC 1.7) warns that the DXIL is unsigned, wgpu treats the warning as a
+compile error, its indirect-validation pipelines fail, the device is lost, and the window never opened
+(`WGPU error: Parent device is lost`). `WGPU_DX12_COMPILER=dxc | auto | fxc` (wgpu's variable) still
+chooses; with `dxc`, put `dxcompiler.dll` *and* `dxil.dll` (DXC ≥ 1.8.2502) next to `lightcraft.exe`.
+FXC builds the compute kernels somewhat slower than DXC (≈ 9 s vs 7.5 s for the GPU test suite on an
+RTX 4080), off the startup path.
+
 **Off the startup path.** The compute device is created on a background thread once the window is
 up (`gpu::warm_up` from the first frame's settings), and never while GPU rendering is off: with
 Settings ▸ Performance ▸ *Use the GPU for rendering* unchecked (applied before the window opens),

docs/localization-zh-hans.md

@@ -12,9 +12,9 @@ LightCraft 的界面支持英语、简体中文、繁体中文（台湾）和日
   `cargo::warning` 提示这一点。
 - 翻译只发生在显示层：命令 ID、照片文件名、用户输入的元数据都不做改动。
 - 尚未翻译的技术性错误、补充说明和发行说明仍以英文显示。
-- 已知限制：**网页版（wasm32）目前只内嵌日文字体**，因此浏览器里的中文仍显示为方框
-  （单个字体文件 16 MB，加上 wasm 会超过托管方 Cloudflare 的 25 MiB 单文件上限）。
-  原生桌面版不受影响。
+- 网页版将 Noto Sans CJK SC 作为独立的 `lightcraft_zh_hans.otf` 文件随站点分发，页面启动时加载；
+  这样可显示简体中文，也避免把约 16 MB 字体放进受单文件大小限制的 WASM。部署时需上传整个
+  `target/web/` 目录。未指定 `CRAFT_FONTS_DIR` 的开发构建仍缺少中文字体。
 - 日期分组标题与拍摄时间按中文格式显示（如 `2026年9月20日 星期日`）。
 
 ## 翻译的维护

docs/localization-zh-hant.md

@@ -22,7 +22,7 @@ CRAFT_FONTS_DIR=../craft-fonts cargo run --release -p lightcraft
 
 craft-fonts 目前沒有繁體中文專用字型：桌面版先以 Noto Sans CJK SC 顯示繁中文字（字形為大陸規範寫法），其次才是日文字型；不在此儲存庫新增字型檔。
 未指定 `CRAFT_FONTS_DIR` 的建置缺少 CJK 字形。
-Web 建置僅嵌入 BIZ UDPGothic Regular，尚未驗證完整繁中文字形覆蓋。
+Web 建置在 WASM 中嵌入 BIZ UDPGothic Regular，並另外載入 Noto Sans CJK SC；繁中文字形仍採用簡中規範寫法。
 
 ## 自動化與維護
 

docs/mcp.md

@@ -71,6 +71,39 @@ Every stdio MCP client takes the same shape: a `command` plus `args`. For exampl
 During development you can also point the client at `cargo run --release -p lightcraft-cli -- mcp`
 (with `"cwd"` set to the repository), at the cost of a slower start.
 
+## Shared core tools
+
+These follow the same conventions as [filmcraft #28](https://github.com/storytold/filmcraft/pull/28).
+They are listed in both full and compact mode; existing documented helpers remain listed too.
+There are no hidden compatibility aliases.
+
+| Tool | Arguments | Result |
+|---|---|---|
+| `command_list` | `filter?`, `enabled_only?` | Command catalog |
+| `command_run` | `id`, `params?` | Command result |
+| `command_batch` | `steps: [{id, params?}]`, `stop_on_error?` | Counts and per-step results; stops on error by default |
+| `doc_inspect` | none | Library state and catalog counts |
+| `render_preview` | `id?`, `max_side?`, `format?` | Image; neither changes selection nor saves a file |
+
+Each edit in a batch has its own undo step. Connect mode also lists `ui_inspect` and
+`ui_screenshot` (the latter has no output-path argument). The existing `inspect_ui`,
+`screenshot`, `list_commands`, `run_command` and `render_photo` keep their documented arguments.
+Ports and connect mode are unchanged.
+
+Every listed tool has a title and all four MCP hints. Generated command tools are conservatively
+marked as edits. Helpers with optional output paths are marked as writers; `export` is not
+idempotent because the default conflict policy chooses a new filename on repeated calls.
+Unknown helper argument keys return JSON-RPC `-32602` naming the key and accepted arguments.
+Generated `cmd_*` tools and nested command params remain free-form: the registry has prose
+parameter docs, not machine-readable schemas. Existing command validation (including strict
+export options) is preserved. Escaped tool panics return `isError: true`, and the session keeps
+serving; backend panics during resource reads or tool listing return an internal error.
+The headless backend owns its session directly, without a session mutex.
+
+`lightcraft://document` and `lightcraft://commands` contain JSON matching `doc_inspect` and
+`command_list`. Existing resources remain available. Requests declaring MCP 2026-07-28 in
+per-request `_meta` receive `resultType: complete` and list/read cache hints; reads are not cached.
+
 ## Tools
 
 ### Helpers
@@ -186,3 +219,20 @@ lightcraft-cli calibrate --max 300 ~/Pictures/2026   # camera colour profiles (d
   (`Remote`) against a stand-in control server; also import → render → JPEG export of a real file.
 - `apps/lightcraft-cli/tests/cli.rs` — spawns `lightcraft-cli mcp` with real pipes; `render`;
   `commands`.
+
+## Export progress and cancellation
+
+Headless direct `export`, `command_run` / `run_command` with `app.export`, and `cmd_app_export`
+calls report photo-count progress when `params._meta.progressToken` is a string or number.
+Notifications are strictly increasing, at most ten per second plus the final total. No token
+means no notifications. `ping` is answered at photo boundaries; other requests wait in order
+until the export ends. EOF lets a pending export finish and preserves queued requests.
+
+`notifications/cancelled` with `params.requestId` stops the matching export before its next
+photo, suppressing its response. Unknown/completed request ids are ignored. A photo already
+being processed finishes first: completed photos remain, each written with the existing atomic
+file writer, and there are no partial files to delete. Unrelated outputs and earlier exports
+are untouched. A failed export is an `isError` tool result. Transport mutexes recover poisoning.
+
+Connect mode and exports inside `command_batch` remain synchronous and do not report MCP
+progress or cancellation. Use a direct headless export call for this behavior.

docs/releasing.md

@@ -57,7 +57,9 @@ workflow, and bump it (in `release.yml`, five jobs, and `freebsd.yml`) whenever
 shipped language needs: a stale pin still builds, it just ships tofu (issue #319: v0.4.0 pinned a revision
 from before Noto Sans CJK SC, so Simplified Chinese had no glyphs). Before a release, check the pin against
 craft-fonts' `fonts/manifest.txt` and run `CRAFT_FONTS_DIR=../craft-fonts cargo test -p lightcraft-ui-egui i18n`,
-whose glyph-coverage test fails when a language's characters have no face.
+whose glyph-coverage test checks the characters in available faces. `CRAFT_FONTS_REQUIRED=1` now also makes
+the native build fail if the pinned manifest lacks Noto Sans CJK SC Regular (`Hans`) or BIZ UDPGothic Regular;
+the web build requires BIZ UDPGothic Regular and packages Noto Sans CJK SC as a separate asset.
 
 ## Signing credentials
 

docs/web.md

@@ -52,13 +52,14 @@ codecs) at opt-level 3 and the rest (egui, eframe, serde, glue) at "s". What goe
 is the brotli column: 3.1 MB, 11 % less than the old build's brotli size and 41 % less than its
 gzip size (5.25 MB). `wasm-opt -Oz`, when installed, shrinks it further.
 
-**Fonts.** The browser has no system fonts to fall back on, so Japanese text comes from
+**Fonts.** The browser has no system fonts to fall back on, so CJK text comes from
 [craft-fonts](https://github.com/storytold/craft-fonts), the optional `CRAFT_FONTS_DIR` build
 input (`CRAFT_FONTS_DIR=../craft-fonts cargo xtask web`; release builds always set it). On wasm32
-`crates/engine/build.rs` embeds only BIZ UDPGothic Regular (UI, and the watermark fallback), so
-the module stays well under Cloudflare's 25 MiB per-file limit: measured 2026-10-06, 17.1 MB
-without craft-fonts and 21.8 MB with it (brotli 3.8 MB / 6.3 MB). Without it the web build
-works, but Japanese text has no glyphs.
+`crates/engine/build.rs` embeds only BIZ UDPGothic Regular (UI and watermark fallback). The web
+bundle also ships Noto Sans CJK SC Regular as `lightcraft_zh_hans.otf` and loads it before the UI
+starts. Keeping the 16 MB Chinese face separate leaves the module under Cloudflare's 25 MiB
+per-file limit (the older Japanese-only module measured 21.8 MB). Without `CRAFT_FONTS_DIR`, the
+web build still works, but Chinese and Japanese text lack glyphs.
 
 ## Deploying: headers
 
@@ -111,9 +112,10 @@ are the same in every version, so serve them with `Cache-Control: no-cache` (not
     (`originals/<hash>/<file name>`, so an unzipped backup is browsable; entries are stored, not
     compressed; at most 4 GB). **File ▸ Restore Library from Backup…** reads such a zip into a
     new library folder (`library-restored-<time>/`; originals already stored are skipped, every
-    entry's checksum is verified) and only then switches to it (`active-library` names the
-    folder in use) and reloads: the previous library stays in storage. Both are web-only
-    (`file.backupLibrary`, `file.restoreLibrary`; the desktop library is a folder).
+    entry's checksum is verified, and each restored original must match its content hash) and
+    only then switches to it (`active-library` names the folder in use) and reloads: the previous
+    library stays in storage. Both are web-only (`file.backupLibrary`, `file.restoreLibrary`; the
+    desktop library is a folder).
   - A failed save (quota exceeded, storage cleared) is not silent: the catalog then refuses new
     writes, so commands report `saved in memory but not written`, the top bar shows the unsaved
     warning (as on the desktop, see `docs/control-protocol.md`), and saving is retried every
@@ -122,8 +124,8 @@ are the same in every version, so serve them with `Cache-Control: no-cache` (not
     a reload); a notice says why.
   - One tab at a time: the page holds a Web Lock (`navigator.locks`, `lightcraft-library`); a
     second tab or window shows "LightCraft is already open in another tab" instead of loading
-    its own copy (two copies would overwrite each other's saves). Browsers without Web Locks
-    aren't protected.
+    its own copy (two copies would overwrite each other's saves). Browsers without Web Locks, or
+    that refuse the lock request, aren't protected: the app starts without the guard.
   - If the stored library can't be opened, a notice says the session is temporary and nothing
     is saved; the stored library is left as it was.
   - A panic (wasm is built with `panic = "abort"`) replaces the page with a message saying the

docs/whats-new.md

@@ -2,6 +2,11 @@
 
 ## October 2026
 
+### Masking
+- Drag anywhere inside the selected radial gradient's ellipse to move it, including rotated
+  ellipses and radial components in compound masks. Edge and rotation handles keep their existing
+  functions, and one Undo restores the entire drag.
+
 ### Albums tree
 - Album folders fold with the same disclosure triangle as Local, By Date, Folders and Keywords.
 - Right-click a folder ▸ New ▸ Create Album… / Create Smart Album… / Create Smart Album from Filter… / Create Folder…
@@ -32,13 +37,19 @@
   belonged to another command moves to the new one. Menus show the new keys; agents use `app.setShortcut`.
 
 ### RAW decoding
+- Samsung SRW files without compression now open as raws: NX5, NX10, NX11, NX20, NX200, NX210, NX1000, NX1100, EX1
+  and WB2000. The compressed ones (NX1, NX30, NX300, NX500, NX2000, NX3000, NX3300, NX mini) still open from their
+  camera JPEG. Photos already imported pick the change up on Reload.
 - Canon CR2 and Pentax PEF raws get the same starting look fitted to the camera's own JPEG as ARW, NEF, RW2, RAF
   and CR3, instead of opening flat and desaturated (issue #310). Photos already imported pick it up when re-rendered.
 - JPEG XL compressed DNGs (DNG 1.7) now open: lossless tiles decode sample for sample (checked on synthetic files);
-  lossy tiles decode too, but no real file has checked them yet. A JPEG XL preview stored in the DNG is used like an
+  lossy tiles decode too, keeping the raw values above 1.0 instead of clipping them (checked on one real file). A tile that cannot be decoded makes the file open from its embedded
+  preview, with the reason, instead of showing a black tile. A JPEG XL preview stored in the DNG is used like an
   embedded JPEG.
 - Apple ProRAW's gain table map (its local tone mapping, `ProfileGainTableMap`) is now read and kept when a photo is
-  exported or converted to DNG. It is not applied to the render: Lightroom Classic renders ProRAW without it.
+  exported or converted to DNG. It is not applied by default: Lightroom Classic renders ProRAW without it. To see a
+  ProRAW the way the iPhone renders it, turn on Profile ▸ Camera local tone mapping (shown for photos that carry the
+  map); the option is per photo, so presets and Copy Settings carry it.
 - iPhone ProRAW and other DNGs that carry their own segmentation mattes (DNG semantic masks) use them for the Select
   Sky, Subject and Background masks instead of our heuristics, so the sky is selected where the camera found it
   (checked on one CC0 iPhone 12 Pro ProRAW). Photos without mattes are unchanged.
@@ -151,6 +162,9 @@
   ignored before) chooses the graphics backend; `off` renders on the CPU. The GPU now starts after the window
   is up, and only when Settings ▸ Performance ▸ Use the GPU for rendering is on; if LightCraft ever dies while
   starting the GPU, the next launch starts with GPU rendering off and says how to turn it back on.
+- The Windows app no longer quits at launch with "Parent device is lost" when another program's `dxcompiler.dll` is
+  on the DLL search path without its `dxil.dll` (issue #471): DirectX 12 shaders now always compile with the
+  compiler built into Windows (FXC). `WGPU_DX12_COMPILER=dxc` uses a `dxcompiler.dll` instead.
 - Exports and renders never write over a photo's original (issue #93): exporting into the photo's own folder with
   the same name and "Overwrite" (or Export with Previous repeating it), an exact output path from the control
   channel or MCP, a merge preview path or `lightcraft-cli render IMG.jpg -o IMG.jpg` is refused with a clear