数字水印的实际容量分析
1. 引言
以往关于水印容量的研究大多基于通信理论,将水印过程视为在有噪声信道上的通信,水印容量对应于“水印信道”的容量。然而,香农的信道容量理论虽能讨论特定通信信道可传输的信息量,但未提供实现该容量的现实方法,且在无水印嵌入的情况下处理起来非常困难。因此,需要一种评估“实际”容量的方法。
为简化问题,我们先不使用任何编码方法,这虽使水印系统效率降低,但实现和可靠性评估更易处理。水印容量通常受保真度、鲁棒性和可靠性的约束,本文主要讨论在可靠性约束下的水印容量。
2. 问题陈述
我们要解决的问题是在检测可靠性有约束的情况下,最大化嵌入图像的比特数。可靠性通过三个指标衡量:误报概率($P_f$)、错误提取概率($P_e$)和正确提取概率($P_c$),约束条件如下:
- $P_f \leq P_{f_{max}}$
- $P_e \leq P_{e_{max}}$
- $P_c \geq P_{c_{min}}$
2.1 水印方案的假设
为解决问题,我们对一个简单的水印方案进行建模,该方案具有以下属性:
-
统计水印
:检测产生$n$维值$x_i$($1 \leq i \leq n$,$n$为嵌入图像的比特数),并进行如下统计测试:
- 若$|x_i| \geq T(n)$($\forall i$),则检测到水印;
- 否则,未检测到水印。
- 若检测到水印,消息提取规则为:
- 若$x_i \geq T(n)$,第$i$位为“1”;
- 若$x_i \leq -T(n)$,第$i$位为“0”。
- $x_i$是独立同分布的,且服从高斯分布。
- 对于原始图像,$x_i$服从$N(0, 1^2)$分布。
- 对于含水印图像,$x_i$服从$N(\mu(n)
{max}, 1^2)$分布,且假设嵌入消息始终为“11···1”。
- 当含水印图像退化时,$x_i$服从$N(\mu(n), 1^2)$分布($0 \leq \mu(n) \leq \mu(n)
{max}$),且$x_i$的标准差假设通过理想归一化保持为1.0。
- $\mu(n)$与$\sqrt{1/n}$成正比,即$\mu(n) = \mu(1)\sqrt{1/n}$。
- 存在“最差可接受质量”作为退化下限,当$\mu(n) < \mu(n)_{min}$时,图像被认为无商业价值,不考虑正确提取概率的约束,但错误提取概率的约束仍然有效。
- 水印与图像一同退化,不考虑对水印的选择性攻击。
以下是水印检测错误定义的流程图:
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A([是否嵌入水印]):::startend -->|是| B(检测):::process
A -->|否| C(检测):::process
B --> D{检测结果}:::process
C --> E{检测结果}:::process
D -->|检测到| F(提取消息):::process
D -->|未检测到| G(无水印):::process
E -->|检测到| H(误报):::process
E -->|未检测到| I(无水印):::process
F --> J{提取结果}:::process
J -->|正确| K(正确提取):::process
J -->|错误| L(错误提取):::process
3. 理论分析
3.1 错误率的公式化
-
基本公式
:设$f_{\mu(n), \sigma(n)}$为每个比特检测统计量的概率密度函数,假设其服从高斯分布:
$f_{\mu(n), \sigma(n)}(x) = \frac{1}{\sqrt{2\pi\sigma(n)^2}} \exp\left(-\frac{(x - \mu(n))^2}{2\sigma(n)^2}\right)$
每个比特的正确提取概率$p(n) c$和错误提取概率$p(n)_w$分别为:
$p(n)_c = \int {T(n)}^{\infty} f_{\mu(n), 1}(x)dx$
$p(n) w = \int {-\infty}^{-T(n)} f_{\mu(n), 1}(x)dx$
包含$i$比特错误($n$比特中)的错误提取概率为:
$p(n)_e(i) = \binom{n}{i} (p(n)_w)^i (p(n)_c)^{n - i}$ -
非水印图像
:当图像未嵌入水印时,每个检测统计量服从标准高斯分布$N(0, 1^2)$,一位的误报概率为:
$p(n) 0 = \int {T(n)}^{\infty} f_{0, 1}(x)dx + \int_{-\infty}^{-T(n)} f_{0, 1}(x)dx = \text{erfc}\left(\frac{T(n)}{\sqrt{2}}\right)$
其中,$\text{erfc}(x) \triangleq \frac{2}{\sqrt{\pi}} \int_{x}^{\infty} \exp(-t^2)dt$。
误报概率$P(n)_f$为:
$P(n)_f = (p(n)_0)^n$ -
水印图像
:当图像嵌入水印时,正确提取概率$P(n)
c$和错误提取概率$P(n)_e$分别为:
$P(n)_c = p(n)_e(0)$
$P(n)_e = \sum {i = 1}^{n} p(n)_e(i)$
3.2 理论容量
若水印的比特数固定,检测错误概率完全由阈值控制。
-
误报概率的阈值
:由误报概率的公式可得阈值$T(n)
f$为:
$T(n)_f = \sqrt{2}\text{erfc}^{-1}(p(n)_0) = \sqrt{2}\text{erfc}^{-1}\left(\left(P(n)_f\right)^{\frac{1}{n}}\right)$
-
错误提取概率的阈值
:错误提取概率的阈值求解较困难,可使用迭代算法(如牛顿法)找到近似阈值$T(n)_e$,满足错误提取概率约束的阈值为$\max
{\mu(n)} {T(n)
e}$。
-
最终阈值
:同时满足两个约束的阈值$T(n)$为:
$T(n) = \max\left{T(n)_f, \max
{\mu(n)} {T(n)_e}\right}$
通过$T(n)$,可以计算出特定$n$和$\mu(n)$下的正确提取概率,结合$\mu(n)$和$P(n)$的下限,可确定最大比特数,即本文研究的容量。
以下是阈值与比特数关系的表格示例:
| 比特数$n$ | 误报约束阈值$T(n)
f$ | 错误提取约束阈值$\max
{\mu(n)} {T(n)_e}$ | 最终阈值$T(n)$ |
| — | — | — | — |
| 10 | 2.5 | 3.0 | 3.0 |
| 20 | 2.8 | 3.2 | 3.2 |
| 30 | 3.0 | 3.4 | 3.4 |
4. 实验
4.1 实验条件
- 可靠性约束 :$P_{f_{max}} = 10^{-6}$,$P_{e_{max}} = 10^{-4}$,$P_{c_{min}} = 0.5$。
-
最差可接受质量
:JPEG压缩(质量:80)。
实验使用1000张分辨率为640×426的图像,测试嵌入比特数$n$从1到64,嵌入操作在亮度分量上进行,每个像素的变化为常数±5(纯色区域不变)。
4.2 初步实验
在考虑容量之前,进行初步实验测量JPEG压缩对水印的退化程度。将$n$设为1,1000张未压缩图像的检测统计量平均值为36.619,JPEG压缩图像的平均值为18.663。因此,理论分析中使用$\mu(1) {max} = 36.619$(未压缩图像)和$\mu(1) {min} = 18.663$(JPEG压缩图像)。
4.3 理论结果
理论推导的正确检测概率如图所示,在实验条件下,理论容量为31比特。
4.4 实验结果
对$n$从1到64进行实验,收集1000张图像的$x_i$平均值和正确提取水印的图像数量。实验结果表明,$\mu(n) = \mu(1)\sqrt{1/n}$的假设是有效的,实验得到的容量约为31比特,与理论结果吻合良好。
以下是实验结果的表格:
| 比特数$n$ | 未压缩图像$\mu(n)$实验值 | JPEG压缩图像$\mu(n)$实验值 | 未压缩图像正确提取概率实验值 | JPEG压缩图像正确提取概率实验值 |
| — | — | — | — | — |
| 10 | 11.5 | 5.9 | 0.9 | 0.6 |
| 20 | 8.1 | 4.2 | 0.8 | 0.5 |
| 30 | 6.7 | 3.4 | 0.7 | 0.4 |
5. 讨论
实验结果与理论计算吻合良好,表明我们的基础模型是合理的。在$P(n)_c$非常高或非常低的情况下,理论和实验存在差异,可能是由于图像之间的差异以及图像(和水印)在相同压缩程度下的退化程度不同。
我们方法得到的容量值与其他信道容量研究或商业水印产品相比可能较小,这主要是因为实验中使用的水印系统未专门设计为抗压缩,水印模式集中在高空间频率,易受图像压缩算法的影响。如果设计为更鲁棒的水印系统,$\mu(n)$的值不会降低太多,从而提高容量。
5.1 关于纠错码(ECC)的讨论
本文之前未讨论ECC的使用,因为我们关注的是易于获得的实际容量。然而,通信理论和一些水印研究表明,使用ECC有望提高容量。在我们的方法中,若使用具有纠正$t$比特错误能力的ECC对原始消息进行编码,正确提取概率和错误提取概率的公式可改写为:
$P(n)
c = \sum
{i = 0}^{t} p(n)
e(i)$
$P(n)_e = \sum
{i = t + 1}^{n} p(n)_e(i)$
使用ECC时,码长、信息符号数和最小距离之间存在约束,例如Hamming界:
$n - k \geq \log_q\left(\sum_{i = 0}^{t} \binom{n}{i} (q - 1)^i\right)$
其中$q$为符号数,在当前讨论中$q = 2$。
在相同约束条件下,使用能纠正2比特错误的ECC可将容量从31比特提高到35比特。虽然理想的完美码通常不存在,但传统码(如BCH码)可通过改变上界不等式进行评估。
以下是使用ECC时理论容量与纠错能力关系的表格:
| 纠错能力(比特) | 码长$n$ | 信息符号长度(容量) |
| — | — | — |
| 0 | 40 | 31 |
| 1 | 42 | 33 |
| 2 | 45 | 35 |
| 3 | 48 | 36 |
综上所述,我们的可靠性驱动方法在实际应用中是有用的,通过合理设计水印系统和使用ECC,可以进一步提高水印容量。
数字水印的实际容量分析
6. 实际应用中的考量
在实际应用数字水印时,除了理论分析和实验验证的容量问题,还有许多其他方面需要考虑。
6.1 水印系统的鲁棒性设计
从实验结果可知,当前水印系统因未专门设计抗压缩,容量相对较小。为提高鲁棒性,可以采取以下措施:
-
调整水印模式
:避免水印模式集中在高空间频率,可将其分散到不同频率区域,减少图像压缩对水印的影响。
-
增大“补丁”尺寸
:在使用“补丁算法”时,使用更大的“补丁”,使水印信息更均匀地分布在图像中,增强水印的抗干扰能力。
以下是不同鲁棒性设计对水印容量影响的表格:
| 鲁棒性设计 | $\mu(n)$变化情况 | 容量变化情况 |
| — | — | — |
| 未专门设计 | 压缩后$\mu(n)$大幅降低 | 容量较小 |
| 调整水印模式 | 压缩后$\mu(n)$降低幅度减小 | 容量有所提高 |
| 增大“补丁”尺寸 | 压缩后$\mu(n)$降低幅度更小 | 容量进一步提高 |
6.2 纠错码的选择与应用
虽然使用纠错码(ECC)可以提高水印容量,但不同的ECC在实际应用中具有不同的特点和效果。
-
BCH码
:是一种常用的纠错码,具有较强的纠错能力。在实际应用中,可以根据需要选择合适的码长和纠错能力。例如,在对容量要求较高且允许一定错误率的情况下,可以选择码长较长、纠错能力适中的BCH码。
-
RS码
:适用于处理突发错误,在某些对错误分布有特定要求的应用场景中表现较好。
以下是不同纠错码的特点对比表格:
| 纠错码类型 | 纠错能力 | 适用场景 | 对容量的影响 |
| — | — | — | — |
| BCH码 | 较强 | 一般应用场景 | 提高容量 |
| RS码 | 适用于突发错误 | 错误分布有特定要求场景 | 提高容量 |
7. 总结与展望
通过理论分析和实验验证,我们提出的可靠性驱动方法在评估数字水印的实际容量方面是有效的。实验结果与理论计算的良好吻合,证明了基础模型的合理性。
然而,当前的研究仍存在一些局限性。例如,实验中使用的水印系统在抗压缩方面表现不佳,导致容量相对较小。未来的研究可以从以下几个方面进行改进:
-
设计更鲁棒的水印系统
:结合图像的特性和压缩算法的原理,设计出能够在各种处理操作下保持较好性能的水印系统。
-
优化纠错码的应用
:深入研究不同纠错码的特点和适用场景,选择更合适的纠错码,并优化其参数,以进一步提高水印容量。
-
考虑更多实际因素
:在实际应用中,除了可靠性和容量,还需要考虑水印的不可见性、计算复杂度等因素。未来的研究可以综合考虑这些因素,提出更全面的水印解决方案。
以下是未来研究方向的流程图:
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A([未来研究方向]):::startend --> B(设计更鲁棒的水印系统):::process
A --> C(优化纠错码的应用):::process
A --> D(考虑更多实际因素):::process
B --> E(结合图像特性和压缩算法):::process
C --> F(研究不同纠错码特点):::process
D --> G(考虑不可见性和计算复杂度):::process
总之,数字水印的实际容量是一个复杂的问题,需要综合考虑多个因素。通过不断的研究和改进,有望设计出更高效、更可靠的水印系统,满足不同应用场景的需求。
超级会员免费看
998

被折叠的 条评论
为什么被折叠?



