技術解析 · Field Manual 2026-05-30 版本快照
github.com/wiltodelta/remove-ai-watermarks · 2.7k ★
id
AI Provenance / Watermark Robustness

AI 來源標記與浮水印的韌性測試工具。

remove-ai-watermarks 是一個 Python CLI 與函式庫,用來辨識、清理與測試 AI 生成影像中的可見浮水印、不可見浮水印與來源 metadata。這份手冊把它當成 provenance 韌性研究工具來看:它能拆哪些訊號、怎麼分層、需要哪些依賴,以及什麼情境下不能拿來規避標示義務或欺騙平台。

2.7k
GitHub Stars
0.6.12
Project Version
Python
Primary Language
MIT
License
01
工具定位與範圍

針對 AI 生成影像的來源訊號辨識與清理工具。

這個 repo 的 README 把範圍寫得很直白:它針對 AI 生成圖片裡的可見標記、不可見標記與 provenance metadata,包含 SynthID、C2PA Content Credentials、EXIF/XMP 的 AI 標籤、PNG 文字區塊,以及特定平台的可見角標。它把 AI 來源揭露系統本身當成待測物,與一般修圖工具的目的不同。

架構上,它把問題拆成幾層:辨識來源與訊號處理已知可見標記以區域擦除處理任意可見物件以 diffusion regeneration 對抗不可見浮水印移除 AI 相關 metadata。CLI 對應的命令包含 `identify`、`visible`、`erase`、`invisible`、`metadata`、`all` 與 `batch`。

這個題目有明確法律與倫理邊界。README 自己也說作者不支持欺騙、詐欺或違法用途,並列出中國、印度、南韓、歐盟、美國州法與美國聯邦草案等差異。這份手冊因此不把它寫成「如何隱藏 AI 身分」的操作指南,而是從工程角度解讀它對 AI provenance 生態的意義與風險。

Signal Stack · What It Reads
C2PA EXIF/XMP PNG Chunks Visible Mark Invisible Mark Verdict
02
安裝與依賴

核心依賴輕量,GPU 擴充依功能按需安裝。

`pyproject.toml` 顯示專案要求 Python 3.10 以上,核心依賴只有 Pillow、piexif、NumPy、OpenCV headless、Click、Rich 與 python-dotenv。這代表「來源辨識、metadata 檢查、已知可見標記處理」可以在 CPU 上跑。optional extras 的依賴較重:`gpu` 會拉 torch、diffusers、transformers、accelerate、ultralytics 等 diffusion 相關依賴;`detect`、`trustmark`、`lama` 分別對應更多偵測或區域修補能力。

# 安裝為隔離 CLI,適合做來源辨識與合法稽核 pipx install git+https://github.com/wiltodelta/remove-ai-watermarks.git # 或用 uv tool uv tool install git+https://github.com/wiltodelta/remove-ai-watermarks.git # 先做辨識,不修改檔案 remove-ai-watermarks identify sample.png remove-ai-watermarks metadata sample.png --check
這裡故意先從 identify 與 metadata check 開始。對內容團隊、平台治理、法務稽核或安全研究而言,第一步應該是知道檔案帶了哪些來源訊號,而不是直接移除。任何移除、重編碼或發布行為都應先確認你對圖片有權利,且不違反所在地法律與平台規則。
03
模組地圖

各訊號層對應獨立處理模組

01 · Identify

來源與標記盤點

`identify.py` 匯總 C2PA 發行者、IPTC AI 標籤、生成器 tags、嵌入參數、已知可見標記、開放浮水印偵測與 caveats,輸出平台與標記清單。

02 · Metadata

EXIF、XMP、C2PA 層

`metadata.py` 與 `noai/c2pa.py` 處理 AI 相關 metadata,README 也提到 PNG、JPEG、AVIF、HEIF、JPEG-XL,以及部分影音容器的 metadata 層。

03 · Visible Registry

已知可見標記

`watermark_registry.py`、`gemini_engine.py`、`doubao_engine.py` 針對已知標記建立偵測與 alpha 反推流程。這是特定標記,不是萬用修圖。

04 · Region Eraser

任意區域擦除

`region_eraser.py` 提供 box-based inpainting。預設 cv2,`lama` extra 可用 big-LaMA via onnxruntime,品質較好但依賴與記憶體成本更高。

05 · Invisible Engine

Diffusion regeneration

`invisible_engine.py` 與 `noai/ctrlregen` 對應不可見浮水印。README 說預設 SDXL pipeline,原生解析度處理,必要時才用 `max-resolution` 限制長邊。

06 · Face Protection

臉部保護

`face_protector.py` 在 diffusion 前抽取臉部,之後以柔邊遮罩混回,降低臉部被再生成流程扭曲的風險。

07 · Text Protection

文字區域保護

`text_protector.py` 與 README 提到 PP-OCRv3 text detector,用於在 SDXL 流程中保護小字、CJK 字形與其他文字區域。

08 · Humanizer

類比痕跡後處理

`humanizer.py` 對應 film grain 與 chromatic aberration。README 明確說這會提高一般分類器難度,但不保證法證上不可偵測。

09 · Tests

測試模組覆蓋

repo 有 `tests/test_metadata.py`、`test_identify.py`、`test_gemini_engine.py`、`test_doubao_engine.py`、`test_region_eraser.py`、`test_text_protector.py` 等測試檔。

04
讀 repo 的方式

README 關鍵位置與各查詢點的對應說明

你想知道 先看哪裡 重點
CLI 表面能力 `src/remove_ai_watermarks/cli.py` 命令分成辨識、metadata、顯性、區域、不可見、全流程、批次。Click options 也能看出依賴邊界。
法律定位 `README.md` 的 Legal 與 Threat model 作者強調合法使用、使用者自負責任,並列出多個司法管轄區的標示義務與移除限制。
不可見浮水印現況 Roadmap、`data/synthid_corpus/README.md`、`scripts/synthid_pixel_probe.py` README 說本地 SynthID pixel detector 目前不可行,這比「能移除」更值得注意。
依賴重量 `pyproject.toml` optional dependencies 核心很輕,GPU、TrustMark、LaMA、detect 都是分開 extra,部署前要明確選。
倫理邊界 Won't fix 與 Legal README 明確拒絕移除 Nightshade、Glaze、PhotoGuard,因為那是藝術家防禦性擾動。
05
安全使用範例

唯讀盤點為起點的稽核流程。

合法與合規流程應該從「不修改檔案」開始:先辨識影像帶了哪些來源訊號,再把結果交給內容、法務或治理流程判斷。這也符合 `identify` 命令的設計精神:沒有本地訊號時,它回報 unknown,而不是把檔案宣稱為 clean。

# 1. 來源與標記盤點:不修改檔案 remove-ai-watermarks identify sample.png --json # 2. 檢查 AI metadata:不修改檔案 remove-ai-watermarks metadata sample.png --check # 3. 把輸出交給內容治理流程,不把「無訊號」等同於「非 AI」 policy decision: owner rights + local law + platform rule + disclosure intent
刻意不在這份手冊中提供規避平台標示的操作配方。如果你在做安全研究、平台防禦或誤標修正,應保留原始檔、處理紀錄與決策理由。若用途是把 AI 生成內容偽裝成真人作品,這不屬於合理使用範圍。
06
先看清楚這些

技術操作之外的法律與使用限制

  • 某些地區明確禁止移除 AI 標籤。README 的法律表格指出中國與印度規則明確禁止修改、壓制或移除 AI 標籤與 provenance metadata。其他地區也可能依用途追究。
  • DMCA 類型風險取決於意圖。README 提醒美國 DMCA 17 U.S.C. 1202 涉及移除 copyright management information 且意圖隱瞞或促成侵權的情境。
  • 移除本地副本不會抹掉服務端紀錄。Threat model 指出,若原始生成曾經經過 Google 或其他平台控制的系統,平台可能仍有帳號、工作階段或生成紀錄。
  • 不可見浮水印不是唯一 trace。README 也提到 watermark-removal pipelines 可能留下可偵測處理痕跡,不能把處理後影像當成法證上不可追蹤。
  • 「unknown」不是「乾淨」。`identify` 的設計刻意避免在沒有訊號時宣稱 clean,因為重新編碼、截圖、上傳平台都可能移除或破壞可讀 metadata。
  • 模型與偵測器持續演進。SynthID、C2PA、TrustMark、平台驗證工具與法規都會變,這類工具需要不斷重新驗證。
  • 不要用在藝術家防禦標記。README 的 Won't fix 明確排除 Nightshade、Glaze、PhotoGuard,理由是那些是藝術家保護作品免於被訓練資料擷取的防禦措施。
07
進階路徑

以合規防禦評估為導向的進階應用路徑。

1. 做平台防禦評估

把 `identify` 與 metadata 檢查接進內容審核流程,記錄每個供應商輸出的 provenance 訊號。核心目標是確認哪些訊號會在壓縮、截圖、上傳與轉檔後消失。

2. 建立合法誤標修正流程

若人類照片被平台誤標為 AI,先保存原始檔與編修紀錄,再由權利人或內容治理負責人確認能否清理 metadata。不要讓工程工具直接替代政策判斷。

3. 做 watermark robustness 測試集

README 的 roadmap 提到 SynthID v2 regression test、local SynthID pixel detector、reference corpus 等未完成工作。這些方向適合研究者用來評估「標記是否真的穩健」。

4. 拆分輕量與重型部署

辨識與 metadata 檢查可做成輕量服務;GPU diffusion、TrustMark、LaMA 則應獨立排程,避免讓所有上傳都進入高成本流程。

5. 把法律政策寫進產品

若你把這類功能放入內部工具,UI 應要求使用者選擇目的、確認權利、保留原始檔,並明確禁止詐欺、冒充、深偽傷害、侵權與規避法定 AI 標示。