How the Gemini watermark works, and why it is reversible

Compositing, not painting

There are two ways to put a logo on an image. You can paint it in, replacing the pixels underneath, in which case the original is gone and no amount of cleverness brings it back. Or you can composite it, mixing the logo with what was already there according to a per-pixel opacity. Gemini does the second.

Alpha compositing is defined by one line of arithmetic, applied independently to each colour channel of each pixel:

Here α is the opacity at that pixel, between 0 and 1. Where the logo is fully transparent, α is 0 and the output is exactly the original. Where the logo is solid, α is 1 and the output is exactly the logo. Everything interesting happens in between, along the soft edges of the sparkle, where the output is a weighted mixture of the two.

One equation, one unknown

Look at what is known once you have the watermarked file in hand. You know watermarked, because that is the file. You know logo, because the sparkle is a fixed piece of artwork that ships with the model and does not change between images. You know α, because the logo carries its own per-pixel alpha map and that does not change either.

That leaves exactly one unknown, and it happens to be the thing you want. Rearranging for it is a line of algebra:

This is an inverse, not an estimate. It is the same relationship read in the other direction. Three things follow from that, and all three are visible in the output.

• Nothing is invented. Grain, texture and edges that sat under the mark come back as they were, because they were never destroyed. They were scaled down and mixed with the logo, and the arithmetic undoes the mixing.
• The result is deterministic. The same input always produces the same output, byte for byte. There is no sampling, no seed and no temperature, because there is no model in the loop.
• It is fast. The work is a handful of multiplications per pixel over a region the size of the logo. A still image finishes in roughly the time the browser needs to decode it.

Where the arithmetic gets delicate

The inverse is exact in theory. In practice it has two places where it strains, and both show up as the quality of the result rather than as an outright failure.

Dividing by a small number

The recovery divides by 1 − α. Near the solid core of the mark, α approaches 1, so that divisor approaches zero. Any error in the input gets multiplied by a large number on the way out.

Errors are always present, because the file you hand over has been through a codec. A JPEG or a video frame stores an approximation of each pixel, not the exact value. Where α is 0.3 that approximation error passes through roughly unchanged. Where α is 0.95 it gets multiplied by twenty. This is why residue, when it appears, appears in the middle of the mark rather than around its edges.

Pixels that hit the ceiling

Colour channels are stored in a fixed range, normally 0 to 255. If the original pixel was already bright and the logo is bright, their mixture can exceed 255 and gets clipped to 255 on the way in. Once a value is clipped, information is genuinely lost: several different originals all produce the same stored number, and the equation cannot tell you which one it was.

In practice this means the mark over a blown-out sky is harder to lift cleanly than the same mark over mid-tones. The tool detects the condition and reports low confidence rather than producing a confident-looking wrong answer.

Finding the mark before touching it

All of the above assumes the mark is exactly where the tool thinks it is. Being off by two pixels turns an exact inverse into a smear, so detection runs before removal and gets three chances to agree with itself.

1. The catalogue. Gemini emits a discrete set of output sizes rather than arbitrary dimensions, and each size implies a logo size and margin. Matching the file's dimensions against that catalogue is a far better starting guess than any ratio-based rule of thumb. The full list is in every official Gemini image output size.
2. The anchor search. The predicted position is refined by looking for the logo's own structure in the neighbourhood, which absorbs the small offsets that come from a crop or a resize.
3. The score. The candidate removal is carried out and then judged against the pixels around it. A correct removal leaves a corner that is statistically indistinguishable from its surroundings. A wrong one leaves a visible seam, and the score notices.

The strength is not always the same

One wrinkle keeps the problem from being purely a lookup. The mark is not always composited at full strength. Video in particular fades it in and out, and some image variants use a different alpha map from the one before them.

So the alpha map gives the shape of the opacity, and a single scalar gain gives its overall strength at that moment. The gain is estimated per file, and per frame for video, by trying candidate values and keeping the one whose removal scores best against the surrounding pixels. It is still not a guess about the picture, only about how strongly a known mark was applied to it.

For video this matters more than it sounds. A clip that fades in from black starts with frames where the mark is barely present at all, and treating those as full strength subtracts more than was ever added. The visible result is a dark blob in the corner for the first second, which is exactly the bug that made per-frame gain estimation necessary.

What this method cannot do

It only works on marks it has the artwork for. Given an unfamiliar logo, there is no alpha map to subtract and no equation to invert, and the tool stops rather than falling back on a generic patch. It handles the Gemini sparkle, the Veo mark and the NotebookLM wordmark, and nothing else.

It also does not touch the invisible provenance signal that Google embeds alongside the visible mark, which is a separate mechanism with separate consequences. That is worth understanding on its own terms, and it is covered in SynthID and the visible watermark are not the same thing.