dtourolle
bee5c5866f
Dehaze cost 22.9 ms of a 2560x1600 frame on the reference laptop RTX 3050, and 54.1 ms at 3840x2160, with the memory clock held at 810 MHz by the power cap (graphics 1762 MHz). It ran five passes: a run and a span erosion along x, the same along y, and the recovery. At those clocks a detail pass costs what it reads and writes, not what it taps: a pass with an empty body - one render-sized rgba16float read and write - measured 4.0 ms, and each dehaze pass 4.4-4.6 ms, so the taps were about 2 ms of the 22 and the four hand-offs between passes were the rest. Each axis is now one pass that takes the minimum over the whole window directly, and the recovery rides in the y pass, which already holds the veil and the pixel's own colour. That is 36 texture reads per pixel at 2560x1600 in place of 12, nearly all of them cache hits, and two passes in place of five. The picture is the same bits. A minimum is exact in any order, and the window is the one Split always covered, the surplus pixel on the far side included (Split::first and Split::width). The veil crossing the removed hand-offs was already exactly representable in rgba16float - a minimum of channels read from rgba16float, floored at zero - so storing it between passes never rounded anything that the fused form now keeps unrounded. Measured with a scratch probe that renders the synthetic 60 MP frame from examples/frame_budget.rs, only a detail parameter moving so the fused pass is reused, 30 frames per scene after six of warm-up, five runs of each binary alternated, median of the per-run p50: scene before after dehaze 2560 fit 22.88 ms 9.06 ms dehaze 2560 1:1 23.41 ms 9.52 ms dehaze 3840 fit 54.09 ms 28.12 ms all detail 2560 fit 53.11 ms 39.97 ms (NR, sharpen, clarity, all detail 2560 1:1 67.48 ms 56.42 ms texture, dehaze) every op 2560 fit 57.59 ms 44.19 ms (with film) every op 2560 1:1 71.83 ms 57.93 ms controls without dehaze (NR, sharpen, clarity, texture): within +-2% The rgba8 output hashed identically before and after for every scene - dehaze alone, all five detail operations, every operation with film, and each other detail operation alone - at fit and 1:1, at 2560x1600, 3840x2160, 1917x1203 and 333x211: 64 of 64.
DarkRoom
A non-destructive RAW photo editor and library for Linux and Android, with a GPU develop pipeline, a catalog that syncs between devices, and no account, no telemetry and no cloud of its own.
The manual shows every feature, pictured from the application itself. This page says what it is, how to get it, and what is still missing.
What it does
A library. Point it at a folder — on this machine, on a network mount, or one a Nextcloud client keeps in virtual-files mode, where a placeholder is treated as the photograph rather than as a one-byte file — or at a Nextcloud account directly. The grid is virtualised, ordered by capture time with a timeline beside it, and filtered by rating, flag, colour label, person and whether the file is here. Ratings, colour labels, keywords, collections and a trash that survives a crash mid-operation. Card ingest. Bursts fold. The same RAW catalogued twice — a dated folder and a backup beside it — is found, proved the same, and folded onto one copy with the spares in the trash. Face detection and identity, with the index syncing between devices.
Developing. Eighteen declared operations fused into one compute dispatch, plus the neighbourhood work that cannot be: clarity, texture, capture sharpening, noise reduction, lens correction, spectral film simulation. Crop, straighten and correct converging verticals, spot repair, and local adjustments over masks the model draws — click a subject or a category, then paint, subtract a gradient or keep only where two selections agree, grow or shrink the edge. Focus peaking and a raw histogram for judging what is recoverable. Named presets; XMP sidecars other editors read.
Panoramas. Select the frames, align, choose a projection, fill the ragged border rather than crop it, and the composite lands beside its sources as a DNG, with a sidecar recording what it was merged from.
From the keyboard, and with its manual. Rating, flagging and labelling
have keys in the grid and in develop, as do zoom, undo and stepping through a
shoot in develop, and none of them is keyboard-only. The help sheet (F1, or
? in develop) lists every key and gesture, generated from the code that
binds it, and links them to the sections of the manual that show them — the
manual ships with the application and opens offline.
Export. JPEG, PNG, AVIF, JPEG XL, 8- and 16-bit TIFF, with resize, output sharpening, a naming template and a colour space — to a folder here or back into the library.
On both platforms. The same core runs on a desktop and a 12-inch tablet; the interface is one layout, tuned for a wide viewport with touch targets throughout. On both, the develop view draws the compute pass's texture directly — no readback between the GPU and the screen.
Getting it
| Platform | How | State |
|---|---|---|
| Arch Linux | packaging/PKGBUILD — makepkg -si |
Built from every release |
| Android | The APK from each CI run, or ./docker/android/package.sh --install |
Runs on a tablet; F-Droid not yet submitted |
| Windows | DarkRoom-<version>-x86_64-setup.exe, cross-built by CI (windows.md) |
Verified under Wine only; unsigned |
| Flatpak | packaging/flatpak/ |
Manifest in tree; choosing a library does not yet work in the sandbox |
Or build it. Git LFS is required for the model weights, and the toolchain pins itself to 1.92.0:
git lfs install && git lfs pull
cargo run --release -p darkroom-desktop
Android, through the containerised toolchain (docker/android):
./docker/android/build.sh cargo ndk -t arm64-v8a build --release
CONTRIBUTING.md has the system packages, the four commands CI runs against what you send, and the shortest useful contribution — a develop operation is one YAML file, and it arrives with its controls, its place in the chain and its tests.
Where it stands
0.16.0, twenty-four tagged releases in. 191 numbered requirements in scope, 84% of them claimed by code and traced to it; the rest are written down rather than merely absent.
Not built: plugins (post-v1, D12), compare and survey culling, AI denoise, tiled rendering, HDR merge and focus stacking, importing a Lightroom or darktable catalog, translations beyond the launch screen, most of the Android platform integration beyond running, and the Flatpak's library chooser. The performance targets are half verified: the per-commit benchmark suite §8 requires exists for everything that does not need a frame — the catalog, the scan, the thumbnails — and not yet for the render path, so a regression there fails nothing. outstanding.md is the list, with the reasoning for each.
Documentation
docs/README.md is the index. The short version, for someone using it:
| manual | Every feature, pictured |
| gestures.md | How it is driven — generated from the code, so it cannot describe a gesture that does not exist |
For someone changing it:
| CONTRIBUTING.md | How to land a first change without reading the rest |
| requirements.md | What the software must do — the numbered register, and the decisions |
| architecture.md | How it is built — crates, the GPU pipeline, the data model, sync |
| technical-debt.md | Compromises taken deliberately, each with the condition that retires it |
| outstanding.md | What is not built, and whether that is a decision or a gap |
| code-health.md | What a contribution costs, per seam, measured |
| traceability.md | Generated: which requirement is claimed by which file |
Designs, one per subsystem: segmentation and mask editing · spot removal · panorama · faces · inference · storage and sync · catalog · display and extension · navigation · distribution · windows · benchmarks.
Licence
GPL-3.0-or-later. The photographs in the manual and the test fixtures are the author's and are there to show and test this project, nothing else. The model weights carry their own licences — models/LICENCE.md.