reverse-SynthID: a spectral-analysis toolkit for studying and removing Gemini's image watermark

What reverse-SynthID actually solves, and for whom

Google's SynthID embeds an invisible pattern into every image Gemini generates. The pattern is imperceptible, the encoder is proprietary, and there is no public decoder. That combination leaves researchers and engineers with two questions they cannot answer from documentation: what does the mark look like as a signal, and how fragile is it to ordinary image transformations?

reverse-SynthID answers both without access to Google's encoder. The README describes the project as reverse-engineering SynthID using only signal processing and spectral analysis, and the repository is organised around that claim: a detector, a set of bypass pipelines, a codebook of carrier frequencies, and validation images. The intended reader is someone comfortable with FFTs, phase coherence and PSNR, not someone looking for a one-click web tool.

The fork adds a desktop application for the V3 bypass, described in the README as drag and drop with no command line needed after setup. That widens the audience to people who want to test the removal stages on their own images without learning the script names. It does not change the underlying method.

How the watermark is found: carrier frequency and cross-color phase consensus

The core insight is that a SynthID carrier is image-content-independent. Its phase at a given frequency bin should stay consistent no matter what the image depicts. Content-driven energy does not behave that way, because different colours and textures randomise the phase.

V4 turns that into a mask. For each frequency bin (fy, fx) and channel ch, the repository computes a consensus value from the mean of the complex phase across solid-colour backgrounds. Values near 1.0 mean the phase is locked across every colour, which the README argues is only true for the watermark. Content bins collapse below 0.3. On the V4 codebook, the README states that 99% or more of content bins fall below the default tau=0.60 cutoff, so the dissolver leaves them alone. That threshold is the main knob controlling the fidelity-versus-removal trade-off.

The codebook itself is built from six consensus colours (black, white, blue, green, red, gray) per model per resolution, with gradient and diverse images as content baselines. Two model profiles are named: gemini-3.1-flash-image-preview and nano-banana-pro-preview, plus an optional union pseudo-model. The build step is scripts/build_codebook_v4.py, which writes artifacts/spectral_codebook_v4.npz.

Installing the toolkit and running a first analysis

The README states Python 3.10 or newer. Dependencies are pinned as minimum versions in requirements.txt, including numpy, scipy, opencv-python, PyWavelets, scikit-learn, Pillow, matplotlib, tqdm, and for the VAE stage torch, diffusers, safetensors and accelerate. The Gemini API client google-genai and python-dotenv are listed for reference image generation.

Install from the repository root:

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Expect a long install, because torch and diffusers dominate the download. If you only want the spectral stages and the detector, the README does not describe a reduced dependency set, so the full requirements file is the documented path.

The repository ships a generate_references.py script at the top level. The README does not document its arguments, so read the file before running it. The V4 codebook is expected at artifacts/spectral_codebook_v4.npz; if that file is absent, the codebook must be rebuilt with scripts/build_codebook_v4.py against a dataset the README refers to as reverse-synthid-dataset but does not describe in detail.

For the fork's desktop path, the README points to gui/README.md for setup and usage of the V3 bypass. That file is the authority on the GUI, and its instructions are not reproduced in the main README.

What Round 06 changed, and why the earlier rounds failed

The repository publishes its own failure history, which is unusual and useful. Five rounds failed before Round 06 passed. Round 01 used conservative spectral subtraction. Round 02 made the subtraction aggressive and added JPEG. Round 03 targeted absolute bins based on a blog post. Round 04 extracted phase from denoise residuals. Round 05 tried diffusion-VAE re-generation plus a geometric warp. Round 06 combined VAE re-generation, elastic deformation, squeeze, colour changes and JPEG in one pipeline.

The stated breakthrough was treating Gemini's own published failure-mode text as an attack specification. That text says the detector may struggle when an image is part of a complex collage, layered behind other elements, or covered with many textures and patterns. The elastic deformation stage simulates that condition at the pixel level: a low-frequency random warp field gives each roughly 50-pixel neighbourhood its own sub-pixel offset, fragmenting the phase consensus without visible distortion.

Read that sequence as a warning about fragility. The method is tuned against a specific detector version on two named models. Nothing in the README claims the same parameters transfer to other Google models, to video, or to a future detector revision.

Limitations, failure modes and the wrong use cases

The licence is the first problem. The repository reports NOASSERTION, and the README badge reads Research rather than an SPDX identifier. There is a LICENSE file at the top level, but the metadata does not resolve it to a known licence. Treat the terms as unverified until you read that file yourself. This article is not legal advice.

The second problem is hardware and dependency weight. The VAE re-generation stage pulls in torch, diffusers, safetensors and accelerate. The README does not state a minimum GPU, a VRAM figure, or a runtime estimate, so you cannot size a machine from the documentation alone.

The third is calibration. V4 includes what the README calls a human-in-the-loop calibration loop: a codebook field named carrier_weights is updated from manual Gemini-app detection tallies. That means someone has to generate images, run them through the Gemini app, record whether the detector fired, and feed those results back. It is not an unattended pipeline, and its accuracy depends on how many tallies you collect.

The fourth is scope. This is a research tool for images. If you need to prove provenance, sign assets, or comply with a platform's disclosure rules, removing a watermark is the opposite of what you want, and a detector that reports 90% accuracy is not an evidentiary instrument. The README gives no false-positive or false-negative breakdown, so the 90% figure should be read as a headline, not a specification.

The realistic alternative: provenance metadata instead of pixel surgery

The closest thing to a real alternative is C2PA-style content credentials, the signed provenance metadata that several camera and editing vendors attach to files. The difference in approach is fundamental. reverse-SynthID attacks the pixels, altering the image so the statistical carrier no longer survives detection. Provenance metadata never touches the pixels; it travels alongside the file as a signed manifest that a viewer can verify or strip.

That difference decides which tool fits. If your goal is to study how fragile an invisible watermark is, you need pixel-level analysis and there is no metadata substitute. If your goal is to tell downstream viewers where an image came from, metadata is the mechanism designed for it, and spectral subtraction destroys the very signal you would want to preserve. A third option, regenerating the image through a different model, changes the content itself and is not comparable to either.

The repository does not discuss C2PA or provenance metadata at all. That silence is worth noting, because the project's own framing is adversarial: it treats the watermark as a target, not as one layer in a provenance system.

Maintenance, upgrade cost and what the release history implies

The repository is not archived. The last push was on 2026-07-17. Two releases are listed: v3 (v3.1) on 2026-04-21 and v4 on 2026-04-23. The gap between the v4 release and the last push suggests the codebase continued to change after v4 was tagged, so pinning to the tag and pinning to main are different decisions.

Upgrade cost is dominated by the codebook, not the Python package. A new detector version or a new Gemini model means a new dataset, a new build with scripts/build_codebook_v4.py, and a fresh round of manual calibration for carrier_weights. The round table shows how expensive that loop can be: six rounds of adversarial development to reach a passing result on two models. Anyone planning to keep this working against a moving target should budget for that cycle, not for a dependency bump.

On licensing, the only safe statement is that the repository metadata does not declare a recognised licence and the README labels the project Research. If you intend to use the output commercially, resolve that question before you build anything on top of it.

Editorial conclusion

Adopt it if you are doing watermark research and can read the code before trusting it, or if you want the V3 bypass through the drag-and-drop GUI without touching the command line. Do not adopt it if you need a stable, licensed product, a hosted service, or any guarantee about the V4 pipeline's behaviour on images the authors never tested. Before running anything, verify three things: the LICENSE file, since the repository reports NOASSERTION and the badge says Research rather than an SPDX identifier; whether the V4 codebook at artifacts/spectral_codebook_v4.npz is present or must be rebuilt from a dataset you do not have; and whether your hardware can run the torch and diffusers stages, because the README does not state a minimum GPU. The round-by-round table is the honest part of this project: five strategies failed before Round 06 passed, and that record is the best guide to how much tuning the bypass still needs.

Frequently asked questions

Official sources

1. aloshdenny/reverse-SynthID on GitHub
2. Issues
3. Project website
4. README
5. Releases