那有一种情况, 如果将你加了水印A的图片B再加入一个新的水印C得到新的图片D,那从D获取的水印是C还是A还是什么奇怪的东西?
哦. 覆盖了. 和已有开源的对比了下,楼主的稍强. 点赞点赞.
水印攻击呢？
大佬好, 小波算法承载的信息量比较少, 按你的条件准备了一张测试图片, 大小为 19KB.
添加水印并压缩之后的图片, 大小为 10KB, 这个比例压缩之后的图片已经有些糊了.
提取出来的水印, 勉强能够辨认.
调整分量比例
1赞
以下均使用开源库README中提供的方法以及参数命令实现, 选择使用离散小波或描述中带有同源算法的开源库, 还有一些使用LSB或者DFT算法的非同源开源库不在其中.
1. fire-keeper/BlindWatermark (Star 1.1k)
-k 4399 2333 32 -em -r pic/xingkong.png -wm pic/wm32.png -o out.png
-
添加有第二个水印的图片和提取的水印
-
通过本工具提取被覆盖的水印并调整分量比例
=> 
2. guofei9987/blind_watermark (Star 4.5k)
bwm = WaterMark(password_wm=1, password_img=1)
...
-
添加有第二个水印的图片和提取的水印
-
通过本工具提取被覆盖的水印并调整分量比例
=> 
3. ShieldMnt/invisible-watermark (Star 1.1k)
-a encode -t bytes -m dwtDctSvd -w 'hello' -o ./test_vectors/xingkong-out.png ./test_vectors/xingkong.png
- 添加有第二个水印的图片和提取的水印
-a decode -t bytes -m dwtDctSvd -l 40 ./test_vectors/xingkong-out.png
// hello
- 通过本工具提取被覆盖的水印
下面是传统DFT算法, 傅立叶变换.
4. zy445566/node-digital-watermarking (Star 294)
let srcFileName = getAbsolutePath("xingkong.png");
let watermarkText = "xingkong xingkong xingkong";
let fontSize = 1.1;
let enCodeFileName = getAbsolutePath("enCode.png");
...
-
添加有第二个水印的图片和提取的水印
-
通过本工具提取被覆盖的水印
下面是传统LSB算法, 最低有效位.
5. lishuaijuly/Watermark (Star 122)
img = cv2.imread('./data/xingkong.png')
wm = cv2.imread('./data/wm232.png',cv2.IMREAD_GRAYSCALE)
wmd = script.lsbwm.embed(img,wm)
...
sim = script.lsbwm.extract(wmd,wm)
...
-
添加有第二个水印的图片
-
通过本工具提取被覆盖的水印
经测试开源库均存在下面几方面的问题, 非常不安全, 请大家谨慎选择.
- 没有设置密码或标记, 带来的问题是A用户使用该工具添加的水印, B用户同样使用该工具, 可直接提取出来了A用户的水印标记.
- 没有覆盖保护, 带来的问题是A用户使用该工具添加的水印, B用户同样使用该工具, 直接覆盖了A用户的水印, A用户再也无法获取到自己的水印.
- 开源算法很容易被针对性的覆盖攻击, 让一切归零.
感谢回复， 看这个效果确实蛮赞的， 已经下单，但是我有几个确切的疑惑， 是真实的懵：
- 应用不开源是可以理解的，毕竟是方便黑盒封装
- 但是我来来去去看了说明和文档一直没弄明白是怎么操作的
- 视频也看了，总感觉少了点前置说明
- 关于水印图片的分辨率限制似乎有点大
- 测试结果如下，以下的结果测试比较匆忙，仅代表我个人浅陋之见解 ：
5.1 小白形式进入执行命令
执行失败
bwm.exe enc 31415 header-hi.png footer
[Error] Wrong wmimg: shape(212, 300)
5.2 反复推测和查看文档后， 发觉只能用32x32之类的2次幂水印图片，继续执行命令
还是执行失败
bwm.exe enc 31415 wm.png footer
[ WARN:0@0.029] global loadsave.cpp:248 cv::findDecoder imread_(‘wm.png’): can’t open/read file: check file path/integrity
‘NoneType’ object has no attribute ‘shape’
5.3 发现是图片没输入正确，改水印图片名称， 继续执行
bwm.exe enc 31415 header-hi.png footer
mkdir: footer\encode
‘NoneType’ object has no attribute ‘peekwm’
6. 综上所述，还是没弄明白是怎么使用比较好， 后面明白后再补上下对抗图片的效果
还是执行失败
兄弟，麻烦得空看下这个图片，这是我对你这个图片进行的有损压缩后的， 就不知道工具能不能看得出来那个水印了，类似你这种算法还是必须有个类似的解密秘钥才能拿到对应的水印图片：
下面这个是压缩的图片【进行的一次常规压缩】
OK啦，晚点试试看
补录效果对比图，感觉还不错
大佬可以多做一些测试, 使用上有什么问题, 我会尽力解决.
1赞
-
16*16 水印
, 支持的最小原图尺寸为135*135 -
24*24 水印
, 支持的最小原图尺寸为199*199 -
32*32 水印
, 支持的最小原图尺寸为263*263
通过测试以上三种大小的水印, 最终1.2.0版本选择使用24*24, 它相对来说比较适中. 16*16水印虽然对原图限制最小, 但是它提取出来后识别度比余下两种低一些.
v1.2.0 版本已发布, 请大家及时更新.
- 检查原图尺寸, 以防止在批量处理时意外中断.
- 增加错误命令的提示, 以方便的使用本工具.
- 将水印尺寸调整为仅支持24*24的二值化图片.
OK, 后面要是得空了, 我再更新测试下, 对了, 请问下这个是基于什么开源库写的吗 ? 我看应用程序的打包格式很类似 Python, 源码应该是 Python, 好像以前我写我这个插件的时候有看到过 Github 上有个类似的开源库，也是用的 Python 实现的，不过考虑到 Python 和 Cocos 的拓展插件的模式有点不太兼容就没加上了
参考了几乎所有开源库, 包含Python, Java, Node等等, 底层选择使用Python是因为天然的算法支持, 数据操作函数封装的很好, 我看了大佬那个LSB版本挺不错的, 使用方便承载信息量丰富, 只是抵抗攻击能力不强.
Blind Watermark - v1.3.0 版本已发布, 请大家及时更新.
- 支持提取分量数据, 可得到更加清晰的水印图片.
- 增加brz命令, 用于生成二值化水印图片.
- 增加ncc命令, 用于比较两张水印图片.
分量数据水印对攻击方式的敏感度不同, 可在复杂情况下提取出较为清晰的水印图片.
