如何在图像卷积过程中使用预乘来解决alpha出血问题？

Question

我正在尝试对透明图像应用框模糊，并且在边缘周围出现“暗光晕”。

Jerry Huxtable 简短地提到了该问题，并提供了一个很好的演示来显示问题的发生：

但我一生都无法理解“预乘 alpha” 是如何实现的解决问题。现在举一个非常简单的例子。我有一张 3x3 图像，包含一个红色和一个绿色像素：

实际上，其余像素是透明的：

现在我们将对图像应用 3x3 框模糊。为了简单起见，我们只计算中心像素的新值。 由于我们有一个 9 位置的正方形（3x3，称为内核），我们取内核中每个像素的 1/9，并将其相加：

框模糊的工作方式是， sstatic.net/cHyJg.png" alt="在此处输入图像描述">

因此

finalRed =   1/9 * red1 + 1/9 * red2 + 1/9 * red3+ ... + 1/9 * red9
finalGreen = 1/9*green1 + 1/9*green2 + 1/9*green3+ ... + 1/9*green9
finalBlue =  1/9* blue1 + 1/9* blue2 + 1/9* blue3+ ... + 1/9* blue9
finalAlpha = 1/9*alpha1 + 1/9*alpha2 + 1/9*alpha3+ ... + 1/9*alpha9

，在这个非常简化的示例中，计算变得非常简单：

finalRed =   1/9 * 255
finalGreen = 1/9 * 255
finalBlue =  0
finalAlpha = 1/9*255 + 1/9*255

这给出了最终颜色值：

finalRed =   28
finalGreen = 28
finalBlue =  0
finalAlpha = 56 (22.2%)

此颜色太暗。当我在 Photoshop 中对同一个 3x3 像素图像执行 3px 框模糊时，我得到了我所期望的结果：

在白色上显示时更清晰：

---

实际上，我正在包含透明的位图上执行框模糊文本，并且文本在边缘周围获得明显的黑色：

我从 GDI+ 开始采用 PixelFormat32bppARGB 格式的位图

---

应用 3x3 卷积核时如何使用“预乘 alpha”？

任何答案都必须包括新的论坛，因为：

final = 1/9*(pixel1+pixel2+pixel3...+pixel9)

让我得到错误的答案。

---

编辑：一个更简单的示例是：

我将使用 0..1 范围内的颜色和 alpha 值执行此数学运算：

我将把框模糊卷积滤镜应用到中间像素：

ARGB'
      = 1/9 * (0,1,0,1) + 1/9 * (0,0,0,0) + 1/9 * (0,0,0,0) + 
        1/9 * (0,1,0,1) + 1/9 * (0,0,0,0) + 1/9 * (0,0,0,0) + 
        1/9 * (0,1,0,1) + 1/9 * (0,0,0,0) + 1/9 * (0,0,0,0);

      = (0, 0.11, 0, 0.11) + (0,0,0,0) + (0,0,0,0) +
        (0, 0.11, 0, 0.11) + (0,0,0,0) + (0,0,0,0) +
        (0, 0.11, 0, 0.11) + (0,0,0,0) + (0,0,0,0)

      = (0, 0.33, 0, 0.33)

这会产生相当透明的深绿色。

这不是我期望看到的。相比之下，Photoshop 的框模糊是：

如果我假设 (0, 0.33, 0, 0.33 ) 是预先相乘的 alpha，并且取消相乘，我得到：

(0, 1, 0, 0.33)

看起来对于我的完全不透明的例子来说是正确的；但当我开始涉及部分透明像素时，我不知道该怎么办。

另请参阅

• 纹理过滤：Alpha 剪切
• < a href="http://blogs.msdn.com/b/shawnhar/archive/2009/11/06/premultiplied-alpha.aspx">预乘 alpha

Answer 1

tkerwin 有已经提供了正确答案，但似乎需要进一步解释。

您在问题中显示的数学直到最后都是绝对正确的。正是在那里，您错过了一个步骤 - 结果仍然处于预乘 Alpha 模式，并且必须“未相乘”回到 PixelFormat32bppARGB 格式。乘法的反面是除法，因此：

finalRed = finalRed * 255 / finalAlpha;
finalGreen = finalGreen * 255 / finalAlpha;
finalBlue = finalBlue * 255 / finalAlpha;

您已经表达了对除法可能会产生严重超出范围的结果的担忧，但这不会发生。如果您进行数学计算，您会发现由于预乘步骤的原因，红色、绿色和蓝色值不能大于 alpha 值。如果您使用的过滤器比简单的框模糊更复杂，则可能是这样，但即使您不使用 Alpha，情况也会如此！正确的反应是限制结果，将负数转为 0，将大于 255 的任何值转为 255。

Answer 2

按照链接中的建议，您在模糊之前进行预乘，并在模糊后取消预乘。在您的示例中，预乘实际上没有任何作用，因为没有半透明像素。您进行了模糊，然后您需要通过以下方式进行非预乘（假设标准化颜色值从 0 到 1）：

RGB' = RGB/A  (if A is > 0)
A' = A

这将为您提供非预乘的模糊最终图像。

Answer 3

正确的数学，错误的运算

这里两个答案都出现错误，并且您在示例中得到了正确的数学，只是不是过度运算。

使用正确的混合公式，根据波特达夫的说法是：

FG.RGB + (1.0 - FG.Alpha)*BG.RGB

不确定其余答案来自哪里，但是哇。

alpha 编码决定了过度运算。

正确编码后，RGBA 代表发射和遮挡

您必须在图像中关联 Alpha 的原因是 RGB 值始终代表发射。在这种情况下，RGB代表像素的发射，而alpha代表遮挡程度。

也就是说，如果您进行线性插值，就像您的框模糊一样，这些值必须指示排放。在最简单的情况下，考虑一个像素发射 100%，我们在每个增量处线性插值 25%。

在这里，每个 RGB 的发射量应减少 25%，这样我们就有 100%、75%、50%、25%，最后是 0%。请注意，每次增量时，发射都会随着遮挡程度而缩放，这样 alpha 将在相同的值下保持完美同步。只需将 RGBA 卷积作为发射和遮挡的一个单元即可。最重要的是，混合配方必须是这个答案中的第一个。

现在考虑不相关的 alpha 情况，它实际上根本没有编码。这里，发射与遮挡程度完全无关，因此过度操作将发射的缩放捆绑到第一步中，其中不相关的发射乘以遮挡程度。

FG.RGB * FG.A + (1.0 - FG.A) BG.RGB

但是，如果有人愚蠢地尝试执行完全相同的线性插值、旋转、模糊、涂抹或任何其他操作，会发生什么情况对于这样完全未编码的值？好吧，让我们看看...

在不相关的 alpha 示例中，我们的发射率为 100%，但我们的遮挡程度为 75%。现在向下插值 25%。请注意光传输的基本数学在这里是如何失败的。我们最终会得到与发射完全不同步的 alpha 表示。 100%RGB-75%A、75%RGB-56.25%A、50%RGB-28.125%A 等。

但是等等，还有更多黑暗...

最后一个难题是您正在使用引用的非线性编码显示价值观。也就是说，当使用为 sRGB 显示器编码的值时，它们会被非线性压缩，而这又会被显示器的 EOTF 恢复为显示器的线性光输出。这意味着我们的代码值不代表从显示器发出的类似辐射的比率。因此，发射和遮挡的线性数学运算将失败，就像对压缩 MP3 值执行音频数学运算将失败一样。

因此，在我们简单的线性插值示例中，我们可以看到数学从根本上很快就崩溃了。

我们的第一个增量是 100% 排放量，第二个增量是 75%，依此类推。但是，如果我们使用 sRGB 非线性编码值从 100% 线性插值到 25%，则实际发射的光量甚至与这个简单的数学无关，并且我们的 alpha 将以与不关联的 alpha 编码崩溃的方式非常相似的方式产生边缘。 。解决这个问题的唯一方法是使我们的过程分为三个步骤：

1. 撤消像素上的非线性压缩 sRGB 传输函数。
2. 进行我们的数学计算。
3. 根据目标传递函数（在本例中为 sRGB）重新应用非线性 sRGB 编码。

正确的答案，错误的公式

不过，你的盒子模糊数学在第一个例子中是足够正确的，你的半透明绿色的发射率为 33%，alpha 遮挡为 33%。根本问题是他的运算过度，也就是上面的公式。也就是说，在绿色覆盖完整发射背景的情况下：

  FG.RGB + (1.0 - FG.A) * BG.RGB
  [0.0 0.33 0.0] + ((1.0 - 0.33) * [1.0 1.0 1.0])
  [0.0 0.33 0.0] + [0.77 0.77 0.77]
  [0.77 1.0 0.77]

但请注意，如果您要将示例合成在纯 100% sRGB 红色发射上，即使使用正确的数学，您也会得到较暗的结果，因为非-辐射编码值。您选择的 sRGB 绿色和红色是完美的示例，它们会加剧将要发生的非线性数学变暗，特别是当您在完全发射的绿色背景之上对红色对象执行模糊时。尽管使用非线性压缩的 sRGB 代码值进行数学计算，但以下合成完全正确：

补充阅读

一些相关的引述。 首先来自 Autodesk 的 Zap Andersson，在臭名昭著的 Adob​​e Alpha 线程中，由 Alpha 通道的创建者 Alvy Ray Smith 确认：

这里的错误是 Chris 从字面上解释了“预乘”这个词。很多人都这样做，但都是错误的。实际上，我真的很讨厌这个词，因为它让你相信它的字面意思，即某物已与“之前”的某物相乘（即“之前”某物）。
那是错误的。这完全是对“预乘”含义的误解。

科学院科技成就奖获得者 Larry Gritz：

在这一点上，我将继续进行一些宗教咆哮，只是说相关的 alpha（预乘颜色）是唯一有意义的选择。这是渲染器可能自然生成的唯一东西，这是合成和任何其他图像处理数学工作的唯一方式，并且在我看来，这是存储任何图像的唯一合理形式。

还值得注意的是，关联的 alpha 可以表达非关联的 alpha（未预乘颜色）无法表达的 RGBA 值。这只是生活的一个事实

（格里茨先生在这里通过他的“不能”声明所指的一个例子是火焰或反射之类的情况，它没有遮挡，只有发射，或者 Alpha 为零的 RGB。这是根本上不可能使用不关联的 alpha 运算来表达。）

科学院科技成果获得者杰里米·塞兰：

首先，我是预乘的“支持者”。尽我所能
理解，预乘是自然表示
带 alpha 的像素；最令人困惑的是它的名字。

Answer 4

对于将来阅读这篇精彩帖子并尝试在多通道模糊上取消预乘颜色的人 - 仅在最后一次传递时执行一次。
经过4个小时的反复尝试，终于学会了。