问题标签 [quantization]

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

我一直在阅读Leptonica 库中的 C 实现代码，遇到了一些我认为有点奇怪的东西。

现在我想强调一下，我远不是这个领域的专家，我不是数学头脑，所以我预测这一切都归结为我没有理解所有这些，而不是算法的实现是错误的一点也不。

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

通过定位具有中值像素（按人口）的箱，选择较长的边，并在该边的中心划分最大轴。我们可以简单地将具有中值像素的 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

总计的值为86

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

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

不是total/2意味着它正在寻找一个值大于平均值而不是中值的 bin吗？上述垃圾箱的中位数为49

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

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

对不起，如果它有点啰嗦，但我想尽可能彻底，因为它已经让我发疯了几天了；）

当我使用 Photoshop 另存为功能并选择 jpeg 文件格式时，我得到以下窗口：

如您所见，我选择基线（“标准”）格式和最高画质。当我在十六进制编辑器中打开这张图片时，我看到了几个 FF DB 标记（这是量化表的开始）。还没有问题，但让我们看下一张图片：

如上图所示，在地址行BDA开始 FFDB 标记。前两个字节是 00 84，这意味着这个标记包含 132 个字节的数据。做一些数学运算，我们可以得出结论，这个标记定义了两个量化表。第一个表的值为：0C 08 08 08 09 等...

在同一个文件中，还有另一个 FFDB 标记，从 2885 地址行开始，如图所示：

同样，前两个字节的值是 00 84，这意味着 132 个字节的数据。但是这一次，第一个量化表值是：01 01 01 等...

如何知道我应该使用哪个 FF DB 标记，以及为什么文件中有多个 FFDB 标记？

在将原始图像编码为 jpeg 图像时，8x8 数据单元被电平移动，使用 2-D DCT 进行转换，量化和霍夫曼编码。

我首先执行了行 DCT，然后执行了列 DCT，并将结果四舍五入到最接近的整数。我将此块发送到量化模块。在量化时，我使用了以下 Q 表。这些表是 IJG 推荐的品质因数 99。

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1
1 1 1
1 1 1 2 2 1
1 1 1 1 1 2 2 2
1 1 1 1 2 2 2 2
1 1 2 2 2 2 2 2
1 2 2 2 2 2 2 2

1 1 1 1 2 2 2 2
1 1 1 1 2 2 2 2
1 1 1 2 2 2 2 2
1 1 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2
2 2 2 2
2 2 2 2 2 2 2 2 2 2
2 2 2 2 2 2

在量化期间，除以“2”时，我将结果从零四舍五入。示例：11/2 = 6。因此，在解码时的去量化过程中，每个奇数都会增加 +1 的误差。

在另一个设置中，我改变了我的舍入技术。在这里，我将结果四舍五入为零。示例：11/2 = 5。因此，在解码时的去量化过程中，每个奇数都会添加一个 -1 的误差。

在第二种情况下，我得到的文件大小非常小（对于 768x512 图像，文件大小减少了近 100 kb）和更多的 PSNR。我可以通过说所有被 2 量化时为“1”的 AC 系数现在将变为 0 而不是 1 来解释较小的文件大小。因此 RLE 使文件大小更小。但我无法解释为什么编码图像质量会提高。它增加了 2-3 分贝，并且发生在我测试的所有图像中。

我的论点是因为 DCT 基本上是 A * DCTmatrix 两边的相等误差应该产生相等的损失。但这里不是这种情况。

在过去的几天里，我对 PNG 做了一些摆弄，我对我的发现感到不安。我的结论是，我的大部分结果都与压缩有关。所以这个周末我将深入研究高级压缩文章。到目前为止，我想分享我的发现。看看是否有人对实现我的目标有任何建议，并可能为我指明正确的方向。

我目前正在做一个项目，我需要在不到 15 秒的窗口内获得尽可能小的文件大小。

我正在使用的大多数图像都是具有完整 256 调色板的 PNG-8bpp。我可以用 5bpp（32 色）准确地表示这些图像中的大多数。

但是，PNG 索引仅支持 1、2、4 和 8bpp。所以我的想法是将 PNG 格式剥离为我需要的最少信息，并编写一个编码器/解码器来支持 3、5、6 或 7bpp 的 IDAT 部分。

由于我只需要六种颜色来表示图像，因此我决定使用 3bpp 对 IDAT 进行编码，以提供最多 8 种颜色的调色板。首先，我解压缩了 IDAT，得到了 368KB 的新文件大小。在对 IDAT 应用 3bpp 后，我新的未压缩文件大小为 274KB。我的开始似乎是一个好的开始……接下来我将 deflate 应用到我的新 IDAT 部分。结果... 59KB。

比使用 4bpp 大 10KB。

24 种颜色可以在 5bpp 中以 32 种颜色表示。使用上述相同的技术，我能够获得比未压缩更好的结果，但我再次在压缩时失败了。最终大小压缩... 84KB。然后我尝试了 6,7bpp... 与 8bpp 相同的结果压缩更差。

只是为了确保我保存了所有未压缩的图像并尝试了其他几种压缩算法...... LZMA、BZIP2、PAQ8......同样的结果是 8bpp 的压缩大小比 5,6 或 7bpp 更小，4bpp 的压缩大小比 3bpp 更小.

为什么会出现这种情况？我可以调整/修改压缩算法以针对使用 5,6 或 7bpp 格式的类似 PNG 的格式来进行 8bpp 压缩吗？值得花时间吗……是的，再节省 10KB 是值得的。

我已经阅读了一个文本图像，将其转换为灰度图像并应用了 sobel 运算符。现在我想“量化图像”。

在运行 Android 4.0 或 4.0.3 的模拟器上，我看到可怕的色带，我似乎无法摆脱。在我测试过的所有其他 Android 版本上，渐变看起来都很平滑。

我有一个配置为 RGBX_8888 的 SurfaceView，并且呈现的画布中不存在条带。如果我通过在渲染结束时叠加噪声模式来手动抖动图像，我可以使渐变再次平滑，但显然会以牺牲性能为代价，而我宁愿避免这样做。

因此，稍后会引入条带。我只能假设，在 4.0+ 上，我的 SurfaceView 在绘制和显示之间的某个点被量化到较低的位深度，我可以从屏幕截图中看到渐变一次步进 8 个值每个通道，建议量化为 555（不是 565）。

我在我的 Activity onCreate 函数中添加了以下内容，但没有任何区别。

我也尝试将上述内容放在 onAttachedToWindow() 中，但仍然没有任何变化。

（我相信 RGBA_8888 无论如何都是 2.2 及更高版本的默认窗口格式，因此明确设置该格式对 4.0+ 没有影响也就不足为奇了。）

这留下了一个问题，如果源是 8888 而目标是 8888，那么引入量化/条带的原因是什么，为什么它只出现在 4.0+ 上？

非常令人费解。我想知道是否有人可以提供一些启示？

所以我开始研究应用于图像的“简单”颜色减少。我花了最后一天研究它是如何工作的，并设法在这里找到似乎是一个不错的算法来试验：中值切割算法

这里的输出是 n 种颜色的调色板。我还没有确保这个算法确实有效，但我假设它确实有效。我想做的是获取该输出并将其应用于生成调色板的图像。

我不能说我精通颜色压缩格式和图像方面的所有深入知识，但我想知道如何应用调色板而不必从带有索引调色板的图像格式开始（即 GIF）。

我在想，对于每个像素，我计算当前像素的颜色与调色板中每种颜色之间的差异，并将该像素替换为差异最小的调色板颜色。这是一种可行的方法吗？

注意 - 我查看了各种库（ImageMagick），但这些似乎有点过分；我对图像处理所做的最多的事情就是减少调色板——没有比这更复杂的了。这就是为什么我认为实现这个算法将是满足我需求的最简单方法。

在 JPEG 压缩中，损失发生在量化期间和 DCT 转换期间。

为什么我们在 JPEG 图像压缩中的 DCT 变换后量化后得到许多 0。

我有一个灰度图像。我做了 8x8 块并计算了它们的每个 DCT。我想量化 DCT 系数，然后用我的秘密消息位替换它们的 LSB。我究竟如何量化系数？我应该使用JPEG使用的量化矩阵吗？如何确定这样一个量化矩阵的值？

我想用指定的颜色图保存其他图像的 .gif 转换。Image Magick 中的“-remap cmap.gif”选项

示例：convert -remap cmap.gif input.png output.gif

确实使用 cmap.gif 中的指定颜色处理 input.png，但它会更改输出颜色图中的顺序。有没有办法强制 Image Magick 使用完全相同的颜色图？

我正在尝试将新图像添加到接受 .gif 文件输入但使用固定颜色图但无法更改单个图像的颜色图的古老显示程序中。