问题标签 [lossless-compression]

我想知道我们可以在多大程度上进行无损数据压缩；我无法找到无损算法的在线模拟器来执行一些经验测试。我可以自己做一个，但不幸的是我这段时间没有足够的时间；我仍然对我的直觉感到好奇，我将对其进行解释。

让我们只看两个更流行的算法：Huffman Coding和Run-lenght Enconding.

假设我们有一个数字A符号的字母表和该字母表中任意长的符号序列：例如：

现在，如果我们只用固定长度的n比特字对每个符号进行编码，我们就有了未压缩的序列，也就是长的N比特。

如果我们使用 Huffman 对序列进行编码，我们将使用H位而不是N位，从而节省(1-H/N)*100%位空间。

如果我们使用 RLE 编码相同的序列，我们将使用R位，节省(1-R/N)*100%.

我想知道，如果我们应用RLE + Huffman或者Huffman + RLE我们可以比只使用其中一个来节省更多空间会发生什么。

这对我来说似乎是一个非常基本的想法，但谷歌搜索我没有找到任何关于这个主题的有趣内容。

编辑：嗯，我可能没有考虑到如果我先使用 RLE，我将无法使用 Huffman，因为与单个符号的固定长度代码的对应关系会丢失；但仍然应该可以先使用 Huffman，然后再使用 RLE。

顺便说一句，我对其中的逻辑很感兴趣，我的意思是串联使用多个无损压缩算法。

编辑 2：当我在评论 Mark Adler 的回复时，我意识到我可能已经找到了我的问题的答案。就是这个：

哈夫曼，这是一个符号到符号的代码，如何影响检测？

假设我们有以下代码：AABCABAAB. 在纯二进制中，它将被编码为00 00 01 10 00 01 00 00 01（obv 空格仅出于可读性目的）。霍夫曼将其编码为0 0 11 10 0 11 0 0 11. 空格更多地显示了字符串是如何没有改变的，因此可以检测到完全相同的重复数量，假设我们正在处理这个范围内的代码（符号方面）。

这让我想到了另一点（鉴于这已经是很长的评论，我不会在这里讨论）：逐位分析代码。

所以，我实际上认为我得出了一个结论：正如我们所知，任何字典（或基于替换的）编码器将可变数量的符号分组为固定长度的码字，而 Huffman（或任何其他熵编码器）编码固定长度的符号成可变数量的比特，从而将熵逼近到最小值；因此，让霍夫曼先运行是没有意义的（而且只会浪费计算），因为另一种算法很可能会引入更多霍夫曼可以减少的冗余。

当然这只是一篇理论论文，因为在实践中我们可以考虑其他因素（例如计算时间）......更不用说要编码的字符串的不同配置可能导致不同结果的事实。但是，嗯……这对我来说很有意义。:)

我翻转一个图像（12M），发现图像大小增加到26M并且图像格式更改为png。我将它保存为带有图像格式的 jpeg，但图像大小减小到 2M。代码如下。

如果我希望新图像与原始图像大小相同，我该怎么办？

我尝试使用 EncoderParameters 保存图像，但我无法从原始图像中获取有效的 EncoderParameterList，我通过图像工具打开 image3.jpg，我发现它的质量为 75（原始图像为 100L），并且二次采样为ON（原始图像关闭，我该如何设置）。

谢谢。

我已经看到 ffmpeg 有一些编解码器（例如 H.264），它们同时被定义为无损和有损，据我了解，无损和有损是相互排斥的：压缩算法要么丢失信息，要么不丢失信息。

怎么可能同时无损和有损呢？

运行ffmpeg -codecs 2>/dev/null| grep h264，我得到：

DEV.LS代表解码器，编码器，视频，不仅帧内压缩，有损压缩，无损压缩。

我担心 Imagick 可能不支持清晰的图像大小调整。即使是最好的过滤器也会返回低于标准的模糊结果，在我看来甚至是可怕的。

这是我能从 Imagick 中获得的最佳品质：

这是使用TimThumbs调整大小的：

注意到巨大的质量差异了吗？谁能提供一个由 Imagick 产生的清晰图像的例子？

下面是用于生成第一张图片的 Imagick 代码：

我知道有类似的问题，但是对于这个图像质量问题还没有足够的答案。解决 Imagick 图像质量问题的大多数尝试都是将问题简化为“这就是缩小图像时得到的结果”。但是我在这篇文章中提供的 TimThumbs 图像示例反驳了这个假设。您可以使用 PHP 缩小图像并获得惊人的结果。

试图弄清楚如何创建一个可以基于文本文件创建对象的类。如果Readable接口有方法String asString()，而类中的Readable方法read(String s)就是根据字符串s构造一个Readable对象，这样(read(String s).asString())。等于（s），如果正在写入/读取的可读类型只有原始参数，我已经能够使用反射轻松写入读取，但我不确定如何编写它们以便在构造函数时轻松转换为字符串和从字符串转换以任意顺序获取任意数量的 Readable 类。对于仅使用原语，asString 方法如下所示：

这些符号是允许我使用 String.split 的任意字符，并且 i 和 d 给出了字段 n 和 d 的原始类型，因为 Class.forName 不适用于原始类型。这个问题需要我有大约 7 层嵌套的 Readables，然而，其中一些有任意数量的 Readables 的容器。我了解如何基于字符串编写读取方法，但是如何在保留所有必要信息的同时将对象压缩为字符串？

当使用某种无损压缩算法压缩文件时，如何能够预测执行时间和/或产生的压缩率？我特别关心本地压缩，因为如果您知道本地压缩的时间和压缩比，您可以根据当前可用的网络吞吐量轻松计算网络压缩的时间。

假设您有一些关于文件的信息，例如大小、冗余、类型（我们可以说文本以保持简单）。也许我们有一些来自实际先前测量的统计数据。还需要什么来预测执行时间和/或压缩比（即使是一个非常粗略的预测）。

对于本地压缩，文件的大小会产生影响，因为实际从存储介质（sdcard、硬盘驱动器）读取和写入数据将占总执行的更多部分。

实际压缩部分可能取决于冗余/类型，因为大多数压缩算法通过压缩小数据块（100kb 左右）来工作。例如，较大的 HTML/Javascripts 文件压缩得更好，因为它们具有更高的冗余度。

我想还有一个调度问题，但粗略估计可能会被忽略。

这是我有时想安静下来的一个问题。我想知道是否一些低开销代码（比如在服务器上）可以预测在执行实际压缩之前压缩文件需要多长时间？

我有这个类将序列化类编码和解码为字符串并返回。

现在我想在编码函数中压缩字符串并在解码函数中解压缩，因为这些数据在 URL 中使用。

我有点纠结在哪里以及如何压缩数据。我是在序列化后立即执行此操作还是仅压缩字符串？

任何帮助表示赞赏！

rg. 埃里克

我想估计一个文件、文件或文件目录在压缩后的最终大小。我正在寻找可以估计/计算的程序或脚本。

有任何想法吗？

这样的工具必须可以在命令行上访问（对于 Linux/Mac）。如果它可以与所有或大多数常用的无损压缩算法（gz、bzip2、zip等）一起工作，那将是最有用的。如果它列出了各种方法的压缩比（或等效用途，生成的文件大小），则加分。我完全希望这样的工具会在产生输出之前扫描文件，但如果可能的话，我想避免任何实际的压缩。

如果重要的话，我希望这是通用的：

• 它应该适用于任何类型的文件，包括易于压缩的 ASCII 文本文件、二进制数据以及介于两者之间的所有文件。（当然，这在很大程度上取决于压缩算法/工具。）
• 它应该与各种压缩算法/工具一起使用

下面的 BASH 脚本为一种压缩算法做了我想要的，但它不算数（我想要一个估计）：

我主要将其用于较大的文件（大于 1 GB），这就是为什么我只想要估计而不是实际压缩的原因。

我基于无限深度的哈希链实现了基于 LZ77/LZ4（无熵编码）的压缩算法。效果不错，速度还可以，但压缩比接近LZ4。从 LZ4 项目中阅读文档和浏览源代码我知道它使用深度为 1 的哈希链，但如果我将实现的深度固定为 1，LZ4 的性能将优于它。

我不明白 LZ4 匹配搜索算法（快速扫描）是如何工作的。有人可以解释一下吗？

谢谢。

当缩小或放大整部电影时，我们在按钮和其他组件中的图像会变得像素化或失真。

左边不缩放，右边缩小

我们对电影的每个图像都有以下属性：

知道会是什么吗？

谢谢。