Files
DarkRoom/docs
dtourolle d430ec9528 Drop a detail pass that changes nothing when it sits between two others
Capture sharpening at a scale too coarse to draw its radius emits one pass
with an empty body (`nothing_to_sharpen`), so that a chain still ends in
something that performs the output transform. At fit on any modern sensor
that is most of the time. When another neighbourhood operation follows it
- dehaze, clarity, texture - the pass is not last and does nothing: it
reads the rgba16float intermediate and writes the same texels to the other
one. It still cost a full render-sized read and write every frame:

  scene                           before     after
  sharpen+clarity 2560x1600 fit   18.66 ms   14.16 ms
  sharpen+clarity 3840x2160 fit   37.93 ms   27.88 ms
  every operation 2560x1600 fit   71.80 ms   67.24 ms
  clarity alone   2560x1600 fit   14.23 ms   14.20 ms  (control)
  sharpen+clarity 2560x1600 1:1   23.01 ms   22.97 ms  (control: resolves)

(Laptop RTX 3050 held at 420/810 MHz by its power cap, synthetic 60 MP
source, median of five alternated runs of forty frames each.)

`compose_detail_with` now drops such a pass where dropping it is exact:
not the last pass, whose output transform would otherwise move onto the
previous pass's f32 result and round differently; and not a pass right
after a reduced one, because a full-resolution pass is what closes the
reduced chain for the operation after it. `DetailPass::is_identity` says
what "changes nothing" means: full size, nothing bound at binding 3, and a
body with no code in it.

The rgba8 output is bit-identical: every scene above hashed the same
before and after, and the sharpen+clarity frame hashes the same as clarity
on its own, which is the claim in one line. A new dr-pipeline test pins
the three cases - dropped ahead of another operation, kept when last, kept
when alone.
2026-09-26 07:10:41 -04:00
..

Documentation

Two audiences, two folders. Most people want the first table and never the second.

Using DarkRoom

The manual Every feature, pictured from the application itself — opening a library, rating and filing, developing, local masks, repair, film, panoramas, export
How it is driven Every gesture and shortcut, by screen. Generated from the code, so it cannot describe one the application does not have

The top-level README says what DarkRoom is, how to get it on each platform, and what is still missing.

Changing DarkRoom

Everything under dev/ is for someone working on the code. Start with CONTRIBUTING.md, which says how to land a first change without reading the rest.

The register and the record. What must be built, how it is built, and how far along it is.

requirements.md What the software must do — the numbered register, the decisions (D-numbers) and the spikes (S-numbers)
architecture.md How it is built — crates, the GPU pipeline, the data model, sync
traceability.md Generated: which requirement is claimed by which file. Never edited by hand
outstanding.md What is specified and not built, and whether that is a decision or a gap
technical-debt.md Compromises taken deliberately, each with the condition that retires it
code-health.md What a contribution costs, per seam, measured

Designs, one per subsystem. Each is the specification the code was built to, kept current as the code moved.

catalog.md The index, the library view, incremental scan, the job queue
storage.md Storage backends: the seam a folder, a sync client and a Nextcloud account share
faces.md Face detection, identity, clustering and the eye-state models
segmentation.md How the application finds the regions a local mask snaps to
mask-editing.md Painting, erasing and combining masks
spot-removal.md Clone and heal as parameters in the edit graph
panorama.md Alignment, projection, the chunked composite and the border fill
inference.md The neural runtime and model chosen per device, with the measurements
display-and-extension.md The display contract, and why the fused pipeline is already most of a plugin format
view-composition.md A controller for the display layer
ui-navigation.md Finding things in the interface once there are many

Measurements. Numbers committed so a regression is a diff rather than a recollection.

benchmarks.md The per-commit suite: what it covers, what it does not, how to read a failure
bench-baseline.json The committed numbers the suite checks against
frame-budget.md What a frame costs on each device, and the decision those figures settled

Platforms and distribution.

distribution.md Which channels v1 targets and what each one constrains
windows.md The Windows installer, cross-built from the Linux CI
android-signing.md Which key signs the APK, and keeping it

Archive. Kept as the record of what was asked for, not as plans.

milestone-v0.1.md The first milestone, delivered 2026-08-30 and superseded
ui-refinement.md How the interface should look; succeeded by ui-navigation.md

Conventions

Two files here are generated and must not be edited by hand: gestures.md and dev/traceability.md. Both come from cargo run -p traceability and the pre-commit hook keeps them in step with the tree. The manual's pictures are recorded by tools/manual and live in LFS.

A design document links to the requirements it satisfies and to the code that satisfies them. When the code moves, the link moves with it; a document that has stopped being true goes to dev/archive/ with a note saying what replaced it, rather than being deleted.