About PictureEraser
A single-purpose page for a single operation: removing something from inside a photograph and letting the pixels around it decide what goes back.
The one thing it does
There is exactly one verb here. A region is painted, the pixels underneath it are discarded, and the surroundings are asked what belongs there instead. The frame does not change size. Nothing is separated from its background. Nothing is moved, straightened, brightened or sharpened. Every pixel outside the painted region and its soft edge is carried through to the saved file exactly as it arrived.
That narrowness is the point rather than a stage we intend to grow out of. A page that does one operation can put the whole of it on one screen, name its failure modes on the same screen, and be finished rather than configurable. A page that does eleven operations spends most of its interface helping you find the one you wanted.
Where the work happens
In the tab. The photograph is decoded into a canvas, the region is painted on the main thread so that it keeps up with a finger, and the fill runs in a worker so that the page keeps drawing while several seconds of arithmetic go past. Nothing is deployed here except files — markup, a stylesheet, some script and two typefaces — sitting on a content network with no application behind them. The endpoint a photograph could be posted to does not exist to be misused.
The consequence worth stating is the other side of that bargain: everything is bounded by the machine you are on. A thirty-megapixel frame on a phone will be offered a reduced working copy, because the alternative is a tab that dies silently. A full-resolution fill on a large scan takes longer than the preview did, because it is doing the same work on many more pixels.
Things it will not be asked to do
- It will not cut a subject away from its background. The hard part there is the edge rather than the fill, which makes it another job for another page.
- It will not adjust exposure, colour or sharpness. A fill that also quietly re-graded the picture would be impossible to judge against the original.
- It will not process a folder. Regions are drawn per photograph, and a queue that applies one region to many frames is a worse product pretending to be a faster one.
- It will not claim to recover what was behind the object. Nothing can. What it produces is a plausible continuation, and the difference between those two statements is the reason this page exists in the shape it does.
How it is paid for
Advertising will pay for it, placed by hand and described here before it exists. The arrangement is already decided and already in the build: one unit on a route that holds the tool, below the writing that sits below the working surface; three on a route that is only writing. Nothing may sit above the stage, between the two states, inside the control bar, or anywhere that has to be scrolled past to reach the thing you came for, and the build audit enforces that rather than this paragraph doing it.
None of it is on screen yet. Google has not approved this domain, so the master switch is off and every placement renders nothing at all — no band, no label, no reserved gap, because whitespace held open for an advert that cannot arrive is worse than the advert would have been. When approval comes the switch flips, the placements return exactly where they were decided, and each one holds its height from the first paint so that a unit filling three seconds late cannot shove the writing downward while you are reading it. There are no accounts, no subscription and nothing to sign up to, and that part is true today.
If something is wrong
The most useful bug report names the picture and the region: what was in it, roughly how big the painted area was as a share of the frame, which engine the readout said had run, and what the result looked like. Fills are deterministic — the same region on the same picture produces the same answer every time — so a described failure can be reproduced rather than hunted.