上线隐形水印工具：调研了六种方案后，选了一个诚实的折中方案

隐形水印是什么，为什么要做它

图片加水印这件事，最常见的方式是在角落盖个半透明 Logo。但这有个问题——影响美观，而且只要稍加裁剪或修图，水印就没了。

隐形水印解决的是另一件事：把信息藏进图片里，肉眼看不到，但事后能提取验证。用途不是「防止被盗用」，而是「被盗用后能证明来源」。

几个典型场景：机构颁发的电子证书，接收方想验证是否为原图；摄影师给自己的作品留下不可见的版权标记；企业内部文件分发，不同渠道嵌入不同标记，泄漏后追溯来源。

我们上线了这个工具，提供两种模式，用起来很简单：上传图片、输入要藏的文字和密码、下载带水印的 PNG，验证时同样上传图片输入密码，一秒出结果。

两种模式，用图说话

先看最直接的问题：加了水印之后，图片会变样吗？

原图	文字嵌入模式	抗旋转/缩放模式

三张图肉眼看不出区别——这是隐形水印的基本前提，两种模式都做到了。

然后是关键问题：图片被各种方式「处理」之后，水印还能验证吗？

编辑方式	编辑后效果	文字嵌入	抗旋转/缩放
亮度 +30		❌	✅ 60%
遮挡 80×80		❌	✅ 73%
旋转 90°		❌	✅ 80%
缩放往返 75%		✅	✅ 64%
裁剪 90%		❌	✅ 51%
裁剪 50%		❌	❌

两种模式的定位由此清晰：

• 文字嵌入模式：能读出你藏进去的文字（版权声明、你的名字），但对改动比较敏感。适合「原图 PNG 直接分发」的场景，比如机构颁发的电子证书。
• 抗旋转/缩放模式：不能读文字，只验证「有没有水印」，但抗改动能力强得多。适合图片可能被转发、旋转、截取的场景。

两种模式可以叠加使用——先嵌文字，再嵌指纹，互不干扰，可分别独立验证。

有一点要提前说清楚：截图之后通常无法可靠验证。截图不是复制原始像素，而是经过屏幕渲染和重新编码的，这个过程会破坏水印信号。这个工具最适合「发送原图 PNG 文件」的链路，不是截图溯源的工具。这不是为了降低预期而说的，是我们实测得到的真实结论。

做工具之前，调研了六种方案

上面说的「我们选定了 DWT-DCT-SVD 算法」，但为什么是它？我们调研了六种方案，把这个过程整理出来，也许对你理解这类工具的能力边界有帮助。

方案一：经典频域算法 DWT-DCT-SVD

这是学术和工程界应用最广的开源方案。原理是把图片分解成频率层次，把水印信息嵌入到低频系数里——人眼对低频变动不敏感，所以水印不可见；提取时也只需要带水印的图，不需要原图对比。

优点：完全开源、可在浏览器实现、真正的「盲」提取。缺点：对旋转和高强度 JPEG 压缩比较脆弱。

腾讯云和阿里云的文字盲水印服务底层大概率用的就是这个算法族——官方文档的限制（最小尺寸、长宽比要求）和这个算法的块结构要求完全对应。

方案二：简单 FFT 差值法（伪盲水印）

GitHub 上有一些「盲水印」项目用的是这个思路：把水印图的频域叠加到原图频域上，提取时做差还原。

看起来很聪明，但不是真正的盲水印——提取时必须持有原图才能做差。腾讯云的图片水印（type1/type2）用的就是这个，本质是「有原图才能验证」的留底方案，不适合我们要做的场景。

方案三：让水印能抗旋转——实验结果让我们放弃了这个方向

DWT-DCT-SVD 有个软肋：图片一旦被旋转，内部的块结构对不上，水印提取就失败。一个自然的想法是「同时埋一层定位模板，提取时先估出旋转角度、把图摆正、再提取」。

我们认真做了实验，用三张真实照片跑了完整测试，结论是：调门要么开不够，要么开太大。

原图

叠加定位模板后——肉眼已可见条纹

定位模板信号弱时，旋转后找不到模板，摆正失败；强到能用时，图片已经出现肉眼可见的条纹。即使开到最大强度，旋转 8° 只有 1 张图能恢复，旋转 15° 全部失败，旋转加 JPEG 组合则全军覆没：

旋转 8° 后（提取失败）

几何摆正后——仍然提取失败

算法确实能估出「转了 7.8°」，把图摆正了——但真实照片经过重采样和 JPEG 编码，信号损耗已经超出了能恢复的范围。这个方向不上线。

方案四：开源项目 BlindWatermark 的示例看起来效果很好，但有隐藏前提

调研过程中我们也看了 GitHub 上颇受欢迎的 BlindWatermark（fire-keeper）和 blind_watermark（guofei9987），README 展示的效果图很惊艳——旋转、截图、JPEG 之后都能还原水印图案。我们拆解了一下，发现有几个关键前提没有被明显标出：

旋转等几何攻击的「成功」，需要精确的逆操作。 打开 blind_watermark 的示例代码，每个「攻击成功」的测试都有对应的还原步骤：旋转了 60° 就反向旋转 -60°，缩放到 400×300 就用原图尺寸缩放回去：

att.rot_att(input_filename='output/embedded.png', ..., angle=60)
att.rot_att(input_filename='output/旋转攻击.png', ..., angle=-60)  # ← 精确反转
wm_extract = bwm1.extract('output/旋转攻击_还原.png', ...)

截图攻击需要同时持有原图。 estimate_crop_parameters 函数的参数里明确写着 original_file='output/embedded.png'——用 SIFT 特征点把截图对齐回原图，本质是「非盲」操作。

成功标准不同。 这些项目嵌入的是一张黑白水印图，提取出来即使有失真，人眼仍能辨认图案。我们嵌入的是精确文字 bit 串，一个 bit 错误就会导致 UTF-8 解码失败——「要么完全正确，要么完全失败」，门槛高得多。

说这些不是否定这些项目，算法本身是扎实的，README 也坦承了自己的「现在的问题」章节。只是评估一个工具的真实能力时，需要区分「已知攻击参数下能还原」和「真实未知场景下盲提取」——这是两件不同的事。

方案五：Google SynthID

Google DeepMind 2025 年发表的方案，已处理超 20 亿张图片，鲁棒性远超所有频域方案。

技术路线完全不同：端到端训练的神经网络，训练时主动对水印图施加随机 JPEG、旋转、裁剪攻击，编码器被迫学习把信号藏在这些变换都动不了的地方。

对我们来说，现阶段引入不现实——模型闭源，且我们的定位是完全离线的免费工具。

方案六：TrustMark（Adobe，ICCV 2025）

开源的深度学习水印方案，有 ONNX 版本，理论上可以在浏览器通过 WebGPU 运行，模型约 3 MB。

这个方向值得后续评估，「浏览器只做验证，嵌入仍离线处理」的模式在技术上是可行的。已列入我们的技术路线图。

为什么选 DWT-DCT-SVD，而不是云 API

调研完这六种方案，再来看云厂商的服务就清楚多了：

MeTool 最大的差异化是：完全离线、免费、支持任意中文文本。 云 API 架构上做不到这三点——用户必须上传图片，有隐私顾虑、有费用、有网络延迟。在能力相近的情况下，这三点就是我们的理由。

这次开发最大的收获不是上线了一个工具，而是搞清楚了「这个工具在哪里会失效」。把这件事写清楚、放在工具页的显眼位置，是比功能本身更值得做的事。

现在就试试隐形水印工具