GeminiWatermarkTool: offline reverse alpha blending for Gemini image watermarks

The problem: the watermark is a blend, not an overlay

A watermark that has been alpha-blended into an image is not sitting on top of it. Each covered pixel is a weighted mix of the original pixel and the logo colour, with the weight coming from a per-pixel alpha map. You cannot recover the original by painting over the region, and you cannot recover it by asking a diffusion model to imagine what was there, because the model will invent detail that was never in the file. GeminiWatermarkTool takes the third route: it inverts the blending equation using calibrated alpha masks, so the output is a computed value rather than a generated one. The README calls this "deterministic reconstruction" and pairs it with a lightweight cleanup pass. The intended user is someone with Gemini output on disk who needs the pixels back without uploading them anywhere. That covers archivists, people processing client assets under a no-upload rule, and anyone scripting a pipeline where a network round trip per image is unacceptable.

Reverse alpha blending, NCC detection and the two watermark profiles

The pipeline has three visible stages. First, detection: the README describes a "three-stage NCC detection with confidence scoring" that decides whether the image carries a watermark at all, and skips images that do not. Second, inversion: the tool applies a reverse alpha mask to the watermark region, solving for the pre-blend pixel values. Third, optional cleanup: an FDnCNN neural network running through NCNN on Vulkan clears residual artifacts left by the inversion. The masks are the load-bearing asset here, and the author states plainly in the README that he produced the calibrated 48x48 and 96x96 reverse-alpha masks himself. Everything downstream depends on those maps being right for the watermark variant in front of you. That is why the project ships two profiles. Gemini 3.5 and later use the V2 profile with a 36x36 small logo, a 96x96 large logo, and a shifted margin calibrated per aspect ratio. Pre-3.5 output uses V1: 48x48 small, 96x96 large, original margin. The README is explicit that switching profiles changes only the alpha map and the position formula, not the math. The CLI defaults to V2 and, since v0.3.1, retries with V1 when the current-profile detector returns a skip. You can pin either behaviour with --legacy or --no-legacy.

Installing GeminiWatermarkTool and running a first batch

The README's headline distribution claim is a portable executable with zero runtime dependencies, so the simplest path is to download a release build for your platform rather than compile. The repository does carry a full source tree for building from source: CMakeLists.txt, CMakePresets.json, vcpkg.json, and an external/ directory holding the submodules. The README does not spell out the configure and build commands, so treat the presets file as the starting point and read it before assuming a generator. Once you have a binary, the CLI form is short. This invocation processes one image with default settings, which means the V2 profile with automatic fallback to V1 if detection skips:

GeminiWatermarkTool image.png

If you know your files came from a pre-3.5 Gemini account, pin the legacy profile so the tool does not spend a detection pass on V2:

GeminiWatermarkTool --legacy image.png

The inverse is available too. When you want to fail loudly on mixed input rather than silently fall back, disable the retry:

GeminiWatermarkTool --no-legacy image.png

The README also documents a --threshold flag and a matching GUI slider, and v0.3.2 changed the behaviour so values above 0.35 are honoured. That matters on busy backgrounds, where a low threshold will let the detector skip an image that does carry a watermark. The GUI exposes the same choice as "Auto Detect", "Small" and "Large" radio buttons plus a "Legacy (pre-Gemini 3.5)" checkbox, and supports drag and drop, directory batch processing, preview and progress tracking.

Where the deterministic approach breaks down

The method is only as good as its mask. If Google changes the watermark geometry or alpha profile again, the shipped masks stop matching and the tool has nothing to fall back on except the legacy profile, which is also wrong for the new layout. The v0.3.1 legacy fallback is a convenience for mixed archives, not a general safety net. There is a second, quieter failure mode in that fallback: on an image where the V2 detector skips for an unrelated reason, the CLI will run the V1 profile anyway and may report an outcome for a watermark that was never there. If you need to know which profile actually did the work, --no-legacy is the honest setting. The denoise stage is a separate question. FDnCNN through NCNN and Vulkan assumes a working Vulkan driver, and the README does not document a CPU path for it, so on a headless server or a VM without GPU passthrough you should expect to run without that stage. Finally, this is an image tool. The README treats video as a different project entirely, VeoWatermarkRemover, which reuses the same blending math but adds per-frame alpha estimation and transcoder timing. Pointing this tool at a video file is not a supported use.

How it differs from generative inpainting tools

The obvious alternative is a generative inpainting remover, of which the README notes many derivative desktop apps, websites and browser extensions now exist. The difference is not quality in the abstract, it is what the output is. An inpainting model synthesises plausible pixels for the masked region. On a photograph of a face or a dense texture, plausible is not the same as correct, and the result is a fabrication that looks clean. Reverse alpha blending computes the pixel that, when re-blended with the known alpha value, would have produced the observed value. If the mask and the blend model are right, the answer is exact. If they are wrong, the error is visible and localised rather than plausible and invented. That distinction is what makes this tool usable in a pipeline where an audit trail matters, and it is also why the author can describe the masks as a specific calibrated asset rather than a trained model. The trade-off is coverage: a generative tool will handle any watermark on any image, while this one handles the Gemini profiles it was calibrated for and degrades sharply outside them.

Licence, build cost and what an upgrade actually costs you

The project is MIT licensed, which permits commercial use and ports. The README adds a specific condition for redistribution: if you ship a substantial portion of the project, including the mask assets, you must preserve the copyright notice and include the full MIT licence text, and attribution with a link back is recommended. That is a standard MIT obligation rather than an added restriction, but the mask assets make it worth reading carefully, because they are the part a derivative product would most want to copy. The source tree is not trivial: C++20, CMake, vcpkg and git submodules under external/. The README does not document the build steps, so budget time to read CMakePresets.json and vcpkg.json before you promise a build to anyone. Upgrade cost is low in the normal case, since releases are self-contained executables, but any release that changes a watermark profile changes the masks, and that is the release you should test against a known-good image before rolling it out.

Editorial conclusion

Adopt GeminiWatermarkTool if you have a batch of Gemini images on a machine that cannot send pixels to a cloud service, and you want a deterministic inverse rather than a generative guess. Do not adopt it for video: the README points to a separate project, VeoWatermarkRemover, for that. Before you build, check that your toolchain matches the C++20 requirement in CMakeLists.txt and that the Vulkan denoise path is optional on your hardware, since the README does not document a CPU fallback for FDnCNN. Then run the CLI on one known Gemini 3.5 image and one pre-3.5 image and read the reported confidence before you point it at a directory.

Frequently asked questions

Official sources

1. allenk/GeminiWatermarkTool on GitHub
2. License: MIT
3. Project website
4. README
5. Releases