dtourolle
c78b798cf0
Seven names are two or three live people on both devices: Ian (756 confirmed faces, and a second Ian with none), Jessie three times, Claudine, Mathias, Noemi, Pascal and PJ. Each was typed on its own device and carried across by sync, which keys people on their uuid and so keeps both. Each half of a person shows half their photographs. dedup_people::run, in one transaction: - Same-name people (trimmed, case-folded as the Identity screen folds them) merge into the one with the most confirmed faces, ties to the smaller uuid, through faces::merge_people_within, so confirmations, rejections and the survivor's name are kept. A person holding no faces at all merges: there is nothing to compare or to carry. Anyone else needs >= 2 confirmed faces per shared embedder on both sides and centroids at cosine >= 0.7 in each. A face confirmed as one and rejected as the other keeps them apart. Unnamed and set-aside people are never merged by name. - Faces held twice (one image, one embedder, IoU >= 0.5, cosine >= 0.7) keep the stronger detector's row (FaceDetector::outranks), then the confirmed one, then the older. The survivor takes the confirmed assignment and both rows' rejections. A pair confirmed as two different people is left and counted. - Judgements still on a merged-away person move to the person at the end of its redirects, and a redirect cycle (two devices merging one pair in opposite directions) is broken at the smaller uuid. Measured on copies of the desktop catalog and the tablet's server snapshot, w600k_mbf, confirmed faces only: - Centroids of differently named people: 2,699 pairs, median 0.02, 99.9th percentile 0.41. One pair reaches 0.70 (0.700 desktop, 0.705 tablet), "Michelle Casanonve" and "Michelle Casanova", one person typed two ways. Next is 0.62/0.64, "Boris Jost" and "Boris". The highest pair that is plainly two people is 0.43/0.44. - One person split in random halves: minimum 0.69, median 0.91 over 72 people. Four faces against twenty-two reach 0.7 in 97% of draws. One face against twenty of somebody else's reached 0.74 in 3,000 draws, and two faces reached 0.61, hence the two-face minimum. - Pascal (22 and 4 confirmed) is at 0.57 and PJ (14 and 7) at 0.50, under 0.7 on both devices, so both pairs stay apart and are logged. The desktop's second Ian holds 4 suggestions and no confirmations, at 0.38 against Ian's centroid, and stays apart. On the tablet it holds nothing and merges. Why a merge made here survives a peer on 0.17.0: the merged-away person stays as a merged_into redirect with a bumped revision, which the catalog merge has always taken on revision. The peer hides the duplicate and never sends it back as a live person. Its own confirmations of that person stay on the redirect, because a merge never overwrites a local confirmation. The manual merge has always left them there too. They follow the redirect when the peer runs this job. A test syncs two catalog files through the previous merge code and back, and the people converge and stay converged. Once a catalog is clean the job reads 80 redirects, the named people, and the face boxes from the covering faces_box index. That is ~10 ms on the reference library. There is no schema change. The index is created IF NOT EXISTS, as the merge already does.
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; a photograph that is only on the server opens on its thumbnail with the download's progress over it. 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. Presets, with a collection shipped in the application — everyday corrections, and a look for each measured colour, cinema and black-and-white stock — and Lightroom presets imported as looks that leave a photograph's own corrections alone. 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 — into albums: named export folders on this machine or on the server, never inside the library, which remember the photograph behind each file and sync between devices as collections do.
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; folders are chosen through the portal, but no Flatpak has been built to prove it |
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.17.0, twenty-five tagged releases in. 192 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 a Flatpak actually built and run in its sandbox. 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.