Platform & SaaS · 2026
re-pics — an image algorithm platform for phone camera pipelines
A re-implementation of a phone image post-processing chain: upload, analyse, apply several processing routes in parallel, compare before and after, download. Python algorithm core, Node BFF, React web, ONNX models on CPU.
The situation
Phone camera quality is decided less by a single model than by the order and interaction of several post-processing steps: super-resolution, noise reduction, beauty, night mode, portrait segmentation. Each step has parameters, each parameter interacts with the next one, and the result is judged by a human eye.
That makes this an unusually awkward engineering brief. The deliverable is not a model with an accuracy figure. It is a chain, a set of parameters, and a way for people to disagree about the output productively. The client also needed to be able to see the algorithm work on an ordinary machine, in front of a customer, without a GPU cluster.
The call we made
Deliver the chain and the harness, not one model. The platform runs the algorithms in parallel and in series, with parameters exposed and a before-and-after comparison on the same pixels. A single “best” output would have hidden exactly the thing the client needed to evaluate: what each stage contributes. Comparison is not a UI nicety here, it is the measuring instrument.
CPU-first, ONNX. Every model runs on ONNX on CPU. This was a deliberate constraint, not a limitation we accepted late. A GPU-only chain cannot be demonstrated on a laptop, cannot be handed to engineers who do not own that hardware, and makes each iteration expensive enough that people stop iterating. The cost is real: large images take longer, and mobile execution remains constrained. We took the iteration speed.
Turn subjective judgement into a recorded first pass. Each style output carries a 0–100 art check score with a written explanation, plus a recommended marker. The score is not a claim that a number equals quality — taste is not measurable — but it gives reviewers a comparable starting point across images and styles, and it forces the system to state why, rather than returning five images and letting the loudest opinion win. This is the same rule we apply elsewhere: a conclusion without its basis is not deliverable.
The algorithm code needs a reading manual. Alongside the platform there is a walkthrough manual for the algorithm code. A pipeline whose core only its author can read is not transferable, and transferability is the difference between a demo and a delivered system. This is also why the analysis output breaks down subject, light and colour instead of emitting a single verdict: it teaches the reader how the chain thinks.
Phase 2 means the link runs, not that every algorithm is production-grade. Scope was fixed at upload, analyse, process, compare, download, with batch handling and export. Some processing routes are strong; some are demonstrators. Saying which is which is part of the delivery.
What we built
- Upload and analysis. A vision model returns structured recommendations — subject content, lighting conditions, colour conditions — with a suggested style rather than one opaque score.
- Parallel processing routes. Five styles produced per image (master natural, cinematic, commercial, film, artistic), each with its own parameters.
- Comparison. Original and result side by side, sliding comparison between versions, pixel-level inspection.
- Scoring. Per-style 0–100 art check with explanation and a recommendation marker, so a batch of thirty images can be triaged before a person looks at them.
- Batch and export. Multi-image processing, result download with size handling.
- Delivery material. The algorithm walkthrough manual, plus the parameter documentation that makes the chain reproducible.
The architecture separates the algorithm core (Python) from the backend-for-frontend (Node.js) and the web client (React), because the algorithm core is the part that will be replaced by the client’s own models, and it should be replaceable without touching the application.
Result
The full path — upload, process, compare, download — runs, and it runs on a CPU-only machine that can be carried into a meeting. Phase 2 is complete and demonstrable.
The honest limits: large-image processing latency is still the weakest number in the system; the effect of each style is ultimately a subjective judgement that the harness makes reviewable rather than objective; and mobile-side execution is constrained by device compute, which no amount of web-side engineering changes. Those three are the reasons the platform is positioned as a development and comparison environment, not a shipping camera pipeline.
Technology
| Stack | Python · Node.js · React · ONNX · PostgreSQL |
|---|---|
| Delivery model | Phase 2 complete, demonstrable |
| Client | Consumer electronics |
| Status | MVP / pilot |
What we cannot show
Screens are from the running system with sample images. Algorithm internals are described by function; the code walkthrough manual is delivered separately.
Similar problem?
If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.