This is an architectural model, not a disclosure of ErasePeople’s internal implementation.
At each boundary, there’s a different class of problem. Image orientation can affect coordinates. Selection can become ambiguous when people overlap. Reconstruction can introduce artifacts. Export can accidentally diverge from what the preview showed.
Keeping those concerns separate makes the system easier to reason about than treating the entire operation as one opaque "edit" button.
Stack transparency matters
The public product information describes an AI photo-removal website, not its framework, model provider, storage layer, or deployment platform. I’m keeping those implementation details out of this post rather than presenting an invented stack as a build log.
For anyone implementing a similar application, I’d evaluate the stack around image handling, asynchronous processing, error recovery, and clear data-retention behavior. Those requirements matter more than choosing a fashionable frontend.
Comparison is part of correctness
A technically successful response can still be a bad edit.
The comparison step gives users a way to inspect whether the intended person disappeared and whether important surroundings remained plausible. That makes it part of the product’s quality loop, not just a presentation feature.
I’d like feedback from developers working on image interfaces: how would you express ambiguous "background people" intent without making the user complete a complicated selection workflow? You can try the current experience at ErasePeople.
Top comments (0)