Concepts¶
The load-bearing ideas behind krites. The master design spec is the authoritative source; this is the orientation.
The shoot is the state; krites is stateless¶
krites keeps no state of its own. The unit of work is a shoot — a
directory of imported originals/ plus a .krites/ sidecar (manifest, analysis
cache, verdicts, edit records, previews) and an export/ output. krites operates
on whatever shoot it's handed. There is no cross-shoot catalog or library — that's
Lightroom's job. This is what keeps krites reusable and disposable.
Non-destructive by construction¶
Originals are immutable inputs. Every judgement and edit is a reversible
record in the sidecar, never a change to a pixel. Only export writes
pixels — it renders the records into a fresh export/ set. So a cull, a
straighten, a crop, a look, or an object removal can always be undone
(krites reset), and the export is deterministic:
the same records produce the same output.
The pipeline¶
Value is delivered in order, certainty decreasing and cost/privacy increasing down the line:
- Cull flags out-of-focus/blur, exposure, closed eyes/blinks and near-duplicate bursts, giving each frame a keep / maybe / reject verdict with reasons.
- Develop straightens, composition-crops and applies a colour look to the keepers.
- Object removal inpaints an unwanted distraction.
- Export bakes everything:
removals → straighten → crop → look.
Judgement and aesthetic are config, not code¶
The judgement — per-signal thresholds, hard gates vs soft penalties, dedup
aggressiveness — lives in a cull profile catalog. The aesthetic — white
balance, tone, grade/LUT — lives in a look catalog. Both are config,
hot-reloaded, seeded by krites init as starting points you tune (never hardcoded
Go constants). See 0006 and
0007.
Local-first, pluggable providers¶
Every heavy backend — RAW decode + image ops, face/eye + aesthetic scoring, generative inpainting — sits behind a narrow Go interface, chosen from config. Every cloud-capable provider is off by default, opt-in per capability, with disclosure before any pixels leave the machine. See the components overview.
Three surfaces¶
The same workspace is driven from three surfaces: the CLI, the studio (the
primary, browser-based surface), and MCP (krites' commands exposed as tools).
Pixel-producing commands (export, remove, xmp write) are gated off MCP —
they stay CLI/studio-only (0002
R-MCP-2).
Fits Lightroom¶
krites reads and writes XMP sidecars, so a krites cull surfaces in a Lightroom catalog — cull in krites, finish in Lightroom. (Object removals can't be represented in Camera-Raw XMP, so they live only in krites' own export.)