Why AI inpainting is the wrong tool for a known watermark
Generative fill is the default answer to "remove this thing from my picture", and for most objects it is the right answer. For a watermark whose artwork and opacity map are both known, it throws away the one advantage you have.
What inpainting actually does
You mark a region. A model looks at everything around it, forms a view about what would plausibly be there, and paints that in. The result is judged by whether a person notices the seam.
This is a remarkable capability and it solves a genuinely hard problem: recovering information that is not present anywhere in the file. Remove a lamppost from a photograph and the wall behind it was never recorded. Nothing can retrieve it, so inventing something convincing is the best available outcome.
That reasoning is sound when the pixels are gone. The question worth asking is whether, for a composited watermark, they ever were.
The information is still there
A composited watermark does not replace the pixels underneath. It mixes with them, according to a per-pixel opacity:
watermarked = α × logo + (1 − α) × original
Where the mark is 40 percent opaque, 60 percent of the original pixel is still sitting in the file. It has been attenuated and mixed with something known, but it has not been discarded. Given the logo and the alpha map, it can be extracted:
original = (watermarked − α × logo) ÷ (1 − α)
Asking a generative model to invent that region is asking it to guess at something you could have calculated. The guess will look fine. It will not be what was there.
Four practical differences
Texture survives instead of being replaced
Fine detail is what inpainting handles worst, because plausible detail and correct detail diverge fastest at small scales. Leather grain, fabric weave, skin pores, foliage: a model produces something with the right statistics and the wrong specifics. Against a smooth gradient you will never notice. Against texture you often will, and the giveaway is a patch that looks slightly too clean or slightly too regular.
The arithmetic does not have this failure mode. It returns the grain that was there, because it never removed it.
The output is deterministic
Run generative fill twice and you get two different results. There is a seed, and usually a temperature, and both change the output. For a one-off edit that is fine. For anything where the same source has to produce the same output twice, it is a problem.
The inverse has no seed. The same input produces the same bytes every time.
It is fast, and it costs nothing to run
The removal is a few multiplications per pixel over a region a few dozen pixels across. A still image finishes in roughly the time the browser needs to decode it. There is no model to download, no accelerator to wait for, and no per-image cost.
For video this stops being a convenience and becomes the difference between feasible and not. A ten second clip at 24 frames per second is 240 frames. Running a generative model on each one, in a browser tab, is not a workable plan.
It can tell when it has failed
A generative model always produces output. Asked to fill a region it has no idea about, it fills it anyway, confidently. There is no natural signal that separates a good result from a bad one.
An inverse can be checked. Perform the subtraction, then compare the corner against the pixels around it. A correct removal leaves a region that is statistically indistinguishable from its surroundings. A wrong one leaves a seam, and the score sees it. That is what makes it possible to decline honestly rather than return damage.
Where the arithmetic needs help
Being a clean inverse in principle does not make it a clean inverse in practice, and it is worth being precise about where it strains.
The recovery divides by 1 − α. Near the solid core of the mark
that divisor approaches zero, so any error in the input is amplified on the way out. The
input always has some error, because it has been through a codec. So a light touch-up over
the mark region can genuinely improve the result.
The interesting finding is how little that touch-up needs to be. Measuring several cleanup backends over the mark region, from simple canvas-level smoothing up to a neural denoiser, they all land within about one decibel of each other once codec noise is present. The neural option is roughly ten times slower for no measurable gain.
Once the arithmetic has done its work, the residue is dominated by compression noise rather than by anything a model is good at fixing. Reaching for a heavier tool at that point costs time and returns nothing.
When a model is the right answer
None of this argues that generative fill is a bad technique. It argues that it is the wrong technique for this particular job. It is the right one whenever the information is genuinely gone:
- An unknown watermark. Without the artwork and the alpha map there is nothing to invert, and inventing a plausible fill is all that remains.
-
A fully opaque mark. Where
αis 1 the original contributed nothing to the stored pixel, so nothing can be recovered from it. - Removing an object. The original use case, and still the one it is best at.
The second case turns up here, interestingly. The NotebookLM wordmark is opaque rather than composited, so there is no blend to invert. Even there, the fix is not a generative one: the strip the mark covers is rebuilt from the pixels directly above and below it, which is cheap, local and checkable. That case is covered in the NotebookLM wordmark is a different problem.