How EraseMint Works

How the Image Is Loaded

Everything starts on your own device. When you choose a file, the browser decodes it straight from disk, and the decoder also applies the EXIF orientation flag — so a photo taken in portrait does not arrive sideways.

Pictures whose longest edge is over 4096 pixels are scaled down to that limit for processing. That keeps memory use predictable on ordinary laptops and phones. The original file is kept separately, so you can still export the repaired result at full resolution.

How the Brush Selection Becomes a Mask

Strokes are recorded in image pixel coordinates rather than screen coordinates. That is why the brush keeps the same physical size when you zoom in or out, and why the selection survives a window resize.

When you start a repair, the tool crops a square region around everything you painted, plus a 72-pixel margin of real context from the surrounding picture. Inside that region your strokes are rasterized into a mask, expanded by a small radius, and then measured: if the marked area covers more than 60% of the image, the tool asks you to select a smaller area instead of guessing.

Two versions of the mask are produced. The model receives a hard, binarized mask. A soft, feathered version is used only when the repaired patch is blended back into the picture — that is what keeps the seam invisible.

How the AI Repair Reconstructs the Area

The model receives a 512×512 crop of the picture together with the mask, and predicts what should be there. Two models sit behind a single interface: a larger, higher-quality one (about 208 MB) used by default, and a lighter one (about 28 MB) for a quick pass. The interface deliberately hides the model names — the tool only talks about the repair method, because which model is running is not a decision the user should have to make.

The computing backend is chosen automatically. The lightweight model prefers WebGPU when the browser supports it. The default model runs on WebAssembly instead: its architecture hits a known issue on the WebGPU execution provider where the model loads and then fails when it runs, and going straight to WebAssembly avoids a slow failure and retry. If one backend fails at run time, the tool automatically retries with the other.

Why Local Browser Processing Matters

Because the picture is decoded and repaired in the tab you already have open, there is no upload step and no server-side copy of your image to delete later. It is also why the tool stays usable on a slow connection: once the model is in the browser's cache, a repair needs no further network traffic.

The trade-off is that your own device does the work. A phone with several gigabytes of free memory handles a small picture comfortably and a very large one only with difficulty; when memory runs out, the tool reports the problem instead of crashing the tab.

What Happens When a Repair Fails

Every failure maps to a specific code and a plain-language message — twelve of them in total. Typical cases: the file format is not supported, the picture could not be decoded, the marked area is empty, the browser cannot run the model, or the device ran out of memory.

Three of those codes — a model that cannot be loaded, a WebAssembly engine that fails to start, and an out-of-memory error — trigger an automatic retry with the lighter model. You see a short notice explaining that a smaller repair method was used, and you still get a result to inspect.

Nothing about the failure is uploaded anywhere. The diagnostic panel keeps the last 50 events on your device and can copy them as a text summary; adding ?diag=1 to the address opens that panel on demand, so you can send the details to the developer if you decide to report a problem.

How Your Device Affects Processing Time

The model file is downloaded once — about 208 MB for the default model, about 28 MB for the lighter one — and the browser stores it, so later visits skip that download.

Initializing the model is a separate cost that happens on every page load: the runtime has to parse the model graph and set up its weights in memory. Measured on a laptop, that step took around seven seconds for the default model even when the file came from the cache. A refresh therefore costs a few seconds before the first repair can start.

The repair itself depends on the model and the device. The lighter model is usually a matter of seconds. The default model takes noticeably longer, because this site does not enable cross-origin isolation, which means WebAssembly runs single-threaded — a deliberate trade-off that keeps third-party assets working. Painting and editing, by contrast, are pure canvas work and stay responsive throughout.

What Is Downloaded, Cached, and Stored

• The model file is fetched from our own asset host. If that host cannot be reached, the download falls back to a mirror and then to Hugging Face.
• Each source is retried twice with a short pause before the next one is tried, and the browser checks the downloaded size against the expected byte count.
• Model files are kept in the browser's Cache Storage under the name erasemint-models-v1.
• Clearing cached data for this site removes the stored model; the next repair downloads it again.
• Only anonymous usage events such as a successful repair are recorded. Image content, masks, and file names are never included.