dtourolle 78cb00634e
Benchmarks / CPU and I/O (per commit) (push) Successful in 3m59s
Benchmarks / Frame budget (on demand) (push) Skipped
Build and test / android-image (push) Canceled after 0s
🐳 Android image / Build and push (push) Canceled after 0s
Build and test / Android (aarch64) (push) Canceled after 0s
Build and test / windows-image (push) Canceled after 0s
🐳 Windows image / Build and push (push) Canceled after 0s
Build and test / Windows (x86_64, cross) (push) Canceled after 0s
Build and test / Layer separation (push) Canceled after 0s
Build and test / Desktop (Linux) (push) Canceled after 16m26s
Traceability / Requirement traces (push) Canceled after 0s
Fetch the photographs around the open one ahead of the step to them
Walking the photo roll was one download per frame: every step showed
"Downloading…" over an empty canvas while tens of megabytes came down,
and moving between a pair of near-identical frames paid that a dozen
times. Now, once the opened photograph has landed, the ones around it
are fetched into the originals cache while it is being looked at, so
the next step is a disk read.

A single worker serves the latest wish only, closest first and working
outwards — next, previous, next-but-one, previous-but-one… — one file
at a time. Each open replaces the wish, so a fast walk never leaves a
trail of stale downloads competing with the one being waited on. A
process-wide in-flight registry makes a click on a photograph that is
still being fetched ahead wait for that transfer and read it from disk,
rather than start a second download of the same file.

How far each side is a setting under STORAGE — Off, 2, 5, 10 or 20,
defaulting to 5 — and it is moot while "keep originals after opening"
is off, since a fetch the cache would discard on arrival is transfer
for nothing. Nothing is fetched ahead while offline. The transfers show
in the activity list while they run and are removed when they end.
2026-09-19 10:36:50 +02:00
2026-09-19 10:15:46 +02:00
2026-08-26 10:08:51 +02:00
2026-09-19 10:15:46 +02:00
2026-09-19 10:15:46 +02:00

DarkRoom

A cross-platform, non-destructive RAW photo editor for Linux and Android.

Status: 0.9.0, and no longer a spike. A library opens, culls, develops and exports on both platforms, across eight tagged releases. What is not built is written down rather than merely absent — see docs/outstanding.md for the requirements that have no implementation and why, and docs/technical-debt.md for the compromises that were chosen.

Documentation

Document Contents
CONTRIBUTING.md How to land a first change without reading the rest
requirements.md What the software must do — 179 numbered requirements
architecture.md How it is built — crates, GPU pipeline, 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
faces.md Face detection and identity — the models, the licence problem, and what S14 measured

Building

Desktop:

cargo run -p darkroom-desktop

Android (containerised toolchain, see docker/android):

./docker/android/build.sh cargo ndk -t arm64-v8a build --release

Git LFS is required for the model weights, and the toolchain pins itself. CONTRIBUTING.md has the details and the four commands CI will run against what you send.

Current state

Working. A catalog over a local folder, a Nextcloud account, or a folder a sync client keeps in virtual-files mode — where a placeholder is treated as the photograph rather than as a one-byte file. A virtualised library grid with a capture-time timeline, ratings, labels, keywords, collections and a trash that survives a crash mid-operation. Card ingest. Face detection and identity, with the index syncing between devices. A develop pipeline of fifteen declared operations fused into a single compute dispatch, plus the neighbourhood operations that cannot be — clarity, texture, capture sharpening, noise reduction, lens correction, spectral film simulation. Crop, straighten, spot removal, gradient and subject-segmentation masks, named presets, and a generated panel that no operation in ui/ is allowed to name. Export to JPEG, PNG and 8- or 16-bit TIFF with resize and output sharpening.

The zero-copy display path works on desktop. The compute pass writes a texture that Slint composites directly, which is what ARCH §6.1 requires; the readback it forbids costs 96% of frame time at 4K, and

cargo run -p dr-gpu --example bench --features readback

still reproduces that measurement. The one exception is the Android develop view, which reads the frame back through the CPU because zero-copy there needs wgpu's Vulkan swapchain, and that tears a portrait window on a tablet whose panel is mounted landscape. It is debt, not a revision of the rule: the reasoning, the on-device measurements that forced it, and the three separate things any one of which would remove it are in technical-debt.md TD-1.

Not built. Plugins, compare and survey culling, focus peaking, burst grouping, AI denoise, tiled and progressive rendering, and most of the Android platform integration beyond running. The performance targets in §4.1 are unverified rather than unmet — the per-commit benchmark suite §8 requires does not exist, so nothing fails a build on a regression. docs/outstanding.md is the list, with the reasoning.

Licence

GPL-3.0-or-later.

S
Description
No description provided
Readme GPL-3.0
1 GiB
2026-10-07 11:27:59 +00:00
Languages
Rust 86.1%
Slint 10.3%
Python 1.1%
Shell 1%
WGSL 0.9%
Other 0.6%