【问题标题】:JPEG image compressionJPEG图像压缩
【发布时间】:2013-02-22 16:19:21
【问题描述】:

我正在研究将 多个 JPEG 图像存储在一起作为一个更大的图像时减少存储空间的问题。基本直觉是图像往往具有一些相似性(例如在相同位置或大约相同时间点拍摄的图像),我们可以利用这种相似性来节省空间吗?

整体流程是:输入JPGImages->每张图片转换成RGBImage Tiles->将相似的RGBtiles重组在一起->再次转换成JPG格式。自然,在检索图像时,我们需要反转该过程。

使用 Y 分量的 DC 系数作为图块重组的相似性度量,我为 10 幅图像节省了约 8% 的空间。当我为 100 张图像执行此操作时,节省的费用减少到 ~3%。

  • 如何在拼贴重组后节省成本 - 即 JPEG 编码过程的哪一部分利用了图像拼贴重组?

  • 除了 Y 分量的 DC 系数之外,还有其他一些您能想到的指标会更好地被 JPEG 编码利用


修订:

除了 JPG 之外,还有其他 other 图像格式可以在聚合多个图像时更好地利用这种 相似性 吗?比如像PNG?

【问题讨论】:

    标签: image-processing compression png jpeg libpng


    【解决方案1】:

    您会在两个方面看到好处:

    首先,当您将相似区域彼此相邻放置时(特别是如果图像的边缘完美匹配且没有不连续性 - 尽管这种情况非常罕见),DCT(频率空间) jpeg 算法的一部分通过逐步逼近大区域(不确定最大大小是多少)来工作,然后查看大区域和多个较小区域的逼近之间的误差,并产生更多的定位校正。

    我怀疑这种影响很小,除非您的图像非常相似,或者非常小(因此它们的边缘与它们的面积成比例)。

    其次,jpeg 压缩的Huffman coding 部分将受益,因为相同的位模式将出现在多个子图像中,并使用相同的(短)令牌进行压缩)。

    这方面不会取决于您压缩图像的排列方式 - 只要它们在同一个图像中。

    【讨论】:

    • 感谢您的回复!我不确定你的第一部分。但是,我认为霍夫曼编码可以在某种程度上利用这一点如果我将最终输出分成多个图像,每个图像都有相似的图块。但是,我认为这并不能解释我节省的空间。我已经改写了我的问题 - 请看一下。
    【解决方案2】:

    您很可能正在使用 JFIF 进行编码。

    我不确定您希望这种方法如何工作。如果我理解正确,您将图像拆分为图块,将它们聚合成一个巨型图像,并且“相似”的图块彼此靠近排列。

    AFAIK,JPEG 实现对图像中的每个 8x8 切片执行单独的 DCT,称为 宏块。换句话说,JPEG 无法利用相邻宏块之间的一致性(这似乎是您的压缩技术的基本假设)。

    如果您自己的图块大于宏块,除了节省图像标题空间之外,您不会看到任何改进。

    例如:将 10 个 JPG 图片标题替换为 1 可以节省 90% 的空间,但仅在标题中。当您查看整个文件时,标题只是整个文件的一小部分,因此您节省的空间是微不足道的。将 100 个图像标题替换为 1 时,您可以节省 99%,但同样仅在标题上。在这两种情况下,所有宏块仍然像以前一样被编码和存储。

    【讨论】:

    • 谢谢,这很有意义!我使用 libjpeg 进行编码和解码。由于 JPEG 在 8x8 宏块内进行 DCT,因此图块之间的相似性(大于宏块)可能没有多大帮助。但是,我认为相邻宏块的 DCT 系数是相对编码的,这可能会通过这种 tile 重组在一定程度上得到改善。我已经修改了我的问题 - 请看一下。
    • 很高兴我能帮助澄清一些事情。是的,libjpeg 是 IJG 对 JPEG 标准的参考 JFIF 实现。我不记得使用增量编码(在相邻宏块之间)的 DCT 系数。 AFAIR,每个宏块变成一个单一的 8x8 系数矩阵,然后被抽取(划分以减少存储它们所需的位数——这就是有损压缩中“损失”的来源),并以 zig 的形式读出-zag 时尚。这种排序产生长的 0 运行,通过运行长度编码有效地压缩它们(而不是存储 17 个零,我们存储 17, 0)。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-05-16
    • 2010-12-18
    • 2016-04-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-22
    相关资源
    最近更新 更多