dtourolle
4b6c110816
FR-CULL-3's remaining two bullets. What existed was a *display* histogram tagged FR-DSP-7: it binds AdjustPass's Rgba8Unorm output, recovers an 8-bit code value, and counts clipping as `r == 255`. Its own documentation says a clipped bin means "a highlight that is actually gone rather than one the transform might still recover", which is the opposite of what a culling decision needs. FR-CULL-3 asks for the histogram of the sensor data, on the explicit grounds that a rendered image "systematically lies about what is recoverable in the raw", and a readout that measures the render cannot answer that however it is presented. So this is a second instrument beside the first rather than a setting on it. Both are true; they are true about different things; the panel offers both behind a chip row and the words travel with the numbers, because a raw saturation figure drawn under a heading saying Highlights would be mislabelled exactly where the difference matters. **What is reduced over, and what it cost to decide.** ARCH §5.5 specified the pre-demosaic CFA samples. This reduces over the demosaiced scene-linear texture instead, and §5.5 is amended to record the choice rather than let the specification and the code disagree in silence. The texture is camera-native — unbalanced, unmatrixed, uncurved — and normalised by the sensor's own black and white levels, so 1.0 is saturation by construction and the distribution below it is the headroom question with no calibration to carry. Retaining the CFA samples would mean keeping the packed u32 buffer Demosaicer::run currently drops: 48 MB at 24 MP, 120 MB at 60 MP, resident per open photograph whether or not anyone looks at the histogram, on a platform §6.2 exists because memory is scarce on. Three things it therefore cannot say, written into the module docs and into §5.5 rather than left to be discovered: it counts pixels not photosites, so a saturated site drags its interpolated neighbours up and per-channel clipping is smeared by about a demosaic kernel; it cannot see above white, because demosaic.wgsl clamps each photosite at 1.0 for its own good reasons (a Canon 6D reads to 16383 against a declared 15070) so "at saturation" and "a stop past it" share a bin; and it is measured after the CFA pattern is gone, so it can name which colour clipped in the reconstructed image but not which photosite went first. The axis is stops below saturation, 16 bins per stop over 256 bins — the same bin count the display reduction uses, so the fold into drawable columns is shared and a divergence between the two plots would have to be deliberate. A linear axis spends half its width on the top stop, which is why nobody has ever drawn a useful linear raw histogram. The fourth series is the brightest channel rather than luma: these values are unbalanced, so any weighted sum of them is a number about nothing, and the brightest channel is the one that saturates first and so the one the headroom question is actually about. It is a property of the file and not of the render, which has two consequences. It is computed once per photograph and cached — nothing downstream of the demosaic can move a count in it — so a cull does not pay the display histogram's per-frame cost three thousand times. And it describes the whole frame rather than the visible region, deliberately opposite to DevelopSession::histogram: a crop changes what is on screen and changes nothing about what the sensor recorded. Tags are on the reduction, the type, its constructor and the presentation arithmetic, each of which has a test that fails if the behaviour goes. The Slint panel and the push from lib.rs keep their reasoning as prose: nothing asserts them, and a tag would claim coverage the assertions are not making.
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.