'Modified Median Cut' 的 Leptonica 实施是否根本不使用中位数？答案

【问题标题】：Is the Leptonica implementation of 'Modified Median Cut' not using the median at all?'Modified Median Cut' 的 Leptonica 实施是否根本不使用中位数？
【发布时间】：2012-02-23 22:15:47
【问题描述】：

我正在玩一些图像处理，并决定阅读颜色量化的工作原理，经过一番阅读后，我发现了Modified Median Cut Quantization 算法。

我一直在阅读C implementation in Leptonica library 的代码，发现了一些我认为有点奇怪的东西。

现在我想强调的是，我远不是这方面的专家，我不是数学头脑，所以我预测这一切都归结为我没有理解所有这一切，而不是实施算法完全错误。

算法规定vbox应沿最长轴拆分，并应使用以下逻辑拆分

通过定位具有中值像素的 bin 来划分最大轴（按人口），选择较长的一边，并在中心划分那边的。我们可以简单地将 bin 与中值像素放在一起在较短的一边，但在细分的早期阶段，这倾向于放置低密度的集群（在细分）在同一个 vbox 中作为高密度集群的一部分将在中值 vbox 颜色中超过它，即使未来基于中值细分。这里使用的算法在早期的细分，而 3 可用于提供可见但低的人口颜色集群他们自己的vbox。这个影响不大高密度星团的细分，最终将有他们的 vbox 中的人口大致相等。

为了论证起见，我们假设我们有一个正在拆分的 vbox，并且红轴是最大的。在 Leptonica 算法中，在第 01297 行，代码似乎执行以下操作

遍历红色的所有可能的绿色和蓝色变化
对于每次迭代，它会添加到沿红轴找到的总像素（人口）数
对于每种红色，它将当前红色和之前红色的总数相加，从而为每种红色存储一个累积值

注意：当我说“红色”时，我是指沿轴被迭代覆盖的每个点，实际颜色可能不是红色，而是包含一定量的红色

所以为了说明起见，假设我们沿着红轴有 9 个“箱子”，并且它们有以下人口

4 8 20 16 1 9 12 8 8

在所有红色 bin 的迭代之后，partialsum 数组将包含上述 bin 的以下计数

4 12 32 48 49 58 70 78 86

而 total 的值为 86

一旦完成，就该执行实际的中值切割了，对于红色轴，这是在第 01346 行执行的

它遍历 bin 并检查它们的累积总和。这是算法描述中让我想到的部分。它会查找第一个值大于的 bin，而不是 total/2

total/2 不会意味着它正在寻找一个值大于 average 值而不是 median ?上述垃圾箱的中位数为 49

43 或 49 的使用可能会对框的拆分方式产生巨大影响，即使该算法随后会通过移动到较大框的中心继续进行匹配值所在的一侧..

另一件让我有点困惑的事情是，论文指定应该定位具有中值的 bin，但没有提到如果有偶数个 bin 时如何进行.. 中值将是(a+b)/2 并且不能保证任何垃圾箱都包含该人口计数。所以这就是让我觉得有一些近似值可以忽略不计的原因，因为分裂实际上是如何参与到所选 bin 较大边的中心的。

对不起，如果它有点啰嗦，但我想尽可能彻底，因为这几天让我发疯了;)

【问题讨论】：

这个问题可能更适合programmers.stackexchange.com 甚至math.stackexchange.com
嗯，可能。交叉发布的规则是什么？ =)

标签： c algorithm math colors quantization

【解决方案1】：

我不知道算法，但我会假设您的数组包含每个红色的人口；让我们用一个例子来解释一下：

假设您有四个等级的红色：A、B、C 和 D 并且您有以下红色值序列：

AABDCADBBBAAA

要找到中位数，您必须根据红色值对它们进行排序并取中间值：

    median
      v
AAAAAABBBBCDD

现在让我们使用他们的方法：

A:6 => 6 
B:4 => 10
C:1 => 11
D:2 => 13

13/2 = 6.5 => B

我认为发生不匹配是因为您在计算人口；平均颜色为：

(6*A+4*B+1*C+2*D)/13

【讨论】：

嗯，这不是与 a) 描述的实现 b) 论文中算法的描述的准确比较。它沿轴计算人口，并且由于沿轴存储每个点的累积值，因此您不必排序。
详细说明。长轴上的每个点（比如红色点）也有未知数量的绿色和蓝色值变化。这是给定点的人口。对于该点，算法将计算出的人口与当前点之前的所有点的累积人口一起存储。检查我上面的示例
顺便说一下，它在此阶段不计算平均颜色，它决定沿给定轴的位置将其分成两部分。它没有计算平均颜色（还）..我们所知道的是在那个 3d 空间中占据了“人口”数量的像素
哦，人口是从直方图中获取的，即。将其视为一个查找表，其工作方式类似于 RGB -> 与该确切颜色相关联的像素数
我已经扫描了纸张，我仍然认为同样的原则适用，即使它是 3 维而不是 1 维（即 RGB 而不是 R）；我搜索了一个很好的解释，可能在这里找到了一个：micro.magnet.fsu.edu/primer/java/digitalimaging/processing/…

【解决方案2】：

在 9-bin 示例中，49 是前 5 个 bin 中的像素数。 49 是 9 个部分和的集合中的中位数，但是我们想要 86 像素的集合中的中位数像素，即 43（或 44），它位于第 4 个 bin 中。

检查 leptonica 的 colorquant2.c 中修改的中值切割算法表明，3d 框的实际切割位置不一定出现在包含中值像素的 bin 附近。其原因在函数 medianCutApply() 中进行了解释。这是对 Paul Heckbert 原始方法的“修改”之一。另一个重要的修改是根据人口和产品（人口 * 体积）的组合来决定下一个要切割的 3d 框，从而允许分割大但人口稀少的色彩空间区域。

【讨论】：