2.1 KiB
Photo Pipeline documentation
One local application that takes a photo library from discovery to a verified Immich upload: duplicate detection, safety review, content analysis, album naming, guarded renaming, upload, and archive — one visible, resume-safe workflow.
These pages are readable three ways, and they are the same files each time: in the
repository under docs/, on Gitea, and inside the running application under
Docs. There is no separate copy to fall out of date.
Read in this order
- Overview — what the application does, the stages it moves a photo through, and the rules it will not break.
- Installation and operations — host and container installation, every setting, the first-run checklist, upgrades, backup and restore, and what each refusal at startup means.
- A guided first pass — one library from scan to verified upload, with the point of no return named in each stage.
- Architecture — the context and runtime diagrams, what each module owns, the three journals a restart reads, and where every invariant is enforced.
The stages, one page each
Every page answers the same four questions: what the stage is for, what you decide, what it changes on disk or on the server, and what it refuses.
- Inventory and discovery
- Duplicate review
- Safety review
- Analysis
- Album proposals
- Renames
- Upload
- Archive
- Diagnostics and library statistics
When something goes wrong
- Errors and refusals — every error code, what caused it, what to do.
- Recovery — what the application resolves by itself, and what needs you.
Conventions
A page tells you what a stage changes on disk or on the server before it tells you how to run it. Refusals are documented as intentional: this application would rather stop and explain than guess about somebody's photographs.