1 pointby heftykoo3 hours ago2 comments
  • heftykoo3 hours ago
    When Google Gemini started adding a watermark to generated images (including Nano Banana images), I wanted a way to download the original outputs without cropping or post-processing.

    Over a few iterations I tried three approaches:

    1) OpenCV heuristics Fixed-position detection + color estimation + inpainting. Fast, but fragile: works on flat backgrounds, fails on textured images.

    https://geminiwatermarkcleaner.com/changelog/v1-1-0.html

    2) LaMa inpainting High-quality reconstruction using a local LaMa model. Very accurate, but slow (~30s/image on CPU) and heavy to ship.

    https://geminiwatermarkcleaner.com/changelog/v2-0-0.html

    3) Lightweight watermark-specific algorithm Inspired by community implementations and optimized for Gemini’s logo pattern: geometry-aware detection + edge-preserving fill, no neural model. • Binary < 2MB • Millisecond latency • Runs fully locally in browser

    https://geminiwatermarkcleaner.com/changelog/v3-0-0.html

    I packaged this into a Chrome extension and a local web Gemini Watermark Remover tool: https://geminiwatermarkcleaner.com/gemini-watermark-remover....

    Everything runs locally; images never leave the machine.

    I also used this as a small experiment in building a paid micro-utility: payments, licensing, and basic marketing turned out harder than the algorithm itself.

    Happy to answer questions about detection, inpainting tradeoffs, or browser-side image processing.

  • heftykoo3 hours ago
    For clarity: the final algorithm isn’t novel research — it’s inspired by watermark-removal implementations shared in the community, then adapted specifically to Gemini’s logo geometry and optimized for browser-side execution.

    The main engineering challenge for me wasn’t detection quality, but finding a point that balanced:

    • reliability on textured images • millisecond latency • small binary size • zero server-side processing

    I also made the extension paid mostly as an experiment to understand pricing, payments, and distribution for small developer tools. Building the payment/licensing flow took more time than the algorithm itself.

    If anyone is curious, I’m happy to share more details about the detection heuristics and fill strategy.