Hi @dannycreations , thanks for this PR!

The idea of detecting watermark presence before removal is valuable - it could prevent unnecessary processing and avoid potential artifacts on non-watermarked images.

However, I have some concerns about making this the default behavior before the detection reliability is fully validated.

🔧 Suggested Changes

1. Make Detection Opt-in (Not Default)

Please add a --detect-mode or --skip-if-no-watermark flag to enable this feature, rather than having it enabled by default.

Rationale:

• Users explicitly requesting --remove expect the removal to happen
• Detection false negatives could cause confusion ("Why wasn't my image processed?")
• We need more real-world testing before making this default behavior
• Better detection: Consider comparing brightness/contrast with surrounding areas instead of just correlation.

# CLI usage
GeminiWatermarkTool -i input.jpg -o output.jpg --remove --detect-mode

2. Detection Algorithm Concerns

The current matchTemplate approach has some limitations:

cv::matchTemplate(gray_f, alpha_region, result, cv::TM_CCOEFF_NORMED);

Issues:

• When gray_f and alpha_region are the same size, matchTemplate outputs a 1×1 result - this works but isn't the intended use case
• Correlation with alpha map doesn't directly indicate watermark presence
• Light-colored backgrounds may cause false positives
• Textured regions with star-like patterns may also trigger false positives

3. Suggested Improved Algorithm

A more reliable detection approach would compare the watermark region against its surrounding context:

bool WatermarkEngine::detect_watermark(
    // Bounds check
    // === Method 1: Brightness Analysis ===
    // Watermark region should be brighter due to white logo blending
    // Reference region: area just above the watermark
    // Convert to grayscale
    // Calculate statistics

    // === Method 2: Alpha-weighted Brightness Check ===
    // Where alpha is high, the pixel should be closer to white (255)
    // === Decision Logic ===
    // Watermark characteristics:
    // 1. Region is brighter than surroundings (white logo blended in)
    // 2. Contrast is reduced (alpha blending "washes out" details)
    // 3. High-alpha areas should be relatively bright   
    // Require at least 2 of 3 indicators

4. Additional Suggestions

1. Return confidence score instead of boolean:

   double detect_watermark_confidence(const cv::Mat& image, ...);

This allows users to set their own threshold.

2. Add --force flag to bypass detection:

   GeminiWatermarkTool -i input.jpg -o output.jpg --remove --detect-mode --force

Summary

I really appreciate the initiative! Once these changes are made, this would be a valuable addition to the tool.
Happy to re-review after that.

@allenk already implement multi stage detection and tested with over 100+ images it success remove watermark and ignore if no watermark, im still let it enable by default because the default behaviour is override original images if the safety was opt-in then what the purpose of safety?

also i think the assets need little tweak

Hi @dannycreations, thank you for this PR — and sorry for the delayed response!
The idea of detecting watermark presence before removal is genuinely valuable. It directly inspired me to think deeply about how detection should work in practice, especially in batch processing scenarios where blindly processing non-watermarked images causes unnecessary pixel damage.
After studying the approach here, I ended up building a more comprehensive detection system that's now integrated into both the CLI and the new GUI application (just released in v0.2.0). Here's a summary of what changed:
Three-stage NCC detection algorithm (watermark_engine.cpp → detect_watermark):

• Stage 1: Spatial NCC with alpha map correlation (50% weight, circuit breaker at 0.25)
• Stage 2: Gradient NCC via Sobel edge matching (30% weight)
• Stage 3: Statistical variance analysis for white/flat region rejection (20% weight)

This addresses some of the reliability concerns with single-pass matchTemplate — particularly false positives on white backgrounds and false negatives on textured regions.
Key additions built on top of detection:

• DetectionResult struct with per-stage scores and combined confidence
• --force flag to bypass detection, --threshold for custom confidence value
• Detection enabled by default in simple/drag-and-drop mode, disabled in -i/-o mode
• GUI: interactive threshold slider (0–100%, 5% steps) with batch processing integration — thumbnail atlas shows OK/SKIP/FAIL - overlays per image

Because these changes touched the core engine API (process_image now returns ProcessResult, detect_watermark returns DetectionResult), and the codebase has been restructured (src/core/, src/cli/, src/gui/), this PR unfortunately can no longer be merged cleanly.
I've credited you in the README and in the v0.2.0 release notes for inspiring the detection feature. Your contribution is appreciated! 🙏

@allenk sure, will close the pull thanks👍