有比JPEG更快的有损压缩吗？答案

【问题标题】：Is there a faster lossy compression than JPEG?有比JPEG更快的有损压缩吗？
【发布时间】：2010-12-29 16:50:17
【问题描述】：

是否有比 JPEG 更快但得到很好支持的压缩算法？我知道 jpeg2000，但据我所知，它并没有那么快。

编辑：用于压缩。

Edit2：它应该在 Linux 32 位上运行，理想情况下应该是 C 或 C++。

【问题讨论】：

解压还是压缩？
只是好奇，为什么图片需要压缩？多少？
@Mark Ransom：嗯，我需要将它们从具有 500Mhz CPU 和 256MB RAM 的小型人形机器人通过 UDP 发送到 PC 进行处理。我需要每秒至少获得 20 张图像，而 wifi 棒的速度不够快，无法在 1 秒内发送那么多数据，所以我使用 JPEG 来减少带宽。
视频编解码器比管理单个完整帧更合适。

【解决方案1】：

Jpeg 编码和解码应该非常快。您将很难找到更快的算法。如果速度很慢，您的问题可能不是格式，而是编码器的错误实现。在 ffmpeg 项目中尝试来自 libavcodec 的编码器。

【讨论】：

JPEG 编码是为快速解码而设计的。这并不总是意味着它也具有快速编码（事实上，很多时候它的编码速度要慢得多）。
如果您不追求最佳编码，两者都非常快。过去几年的低端 x86 应该能够以每秒 30 兆像素或更高的速率编码 jpeg（粗略估计）。
用于视频编码的编码器必然会针对速度进行优化。我知道 MJPEG 多年来一直非常快，尽管我一直认为它需要专门的硬件来实现。
嗯，我正在使用 OpenCV 将原始图像编码为 jpeg，在一个具有 500Mhz CPU 和 256MB RAM 的机器人上。现在编码一张 640*480 RGB 图像需要 0.25 秒，这是不可接受的。我需要每秒 20 多张图像。
嗯，我希望能达到 0.05 秒来编码 640*480 图像 (YUV422)，这意味着 20 fps。我希望它在 500Mhz CPU 上是现实的。

【解决方案2】：

您的目标架构上是否有可用的 MMX/SSE2 指令？如果是这样，你可以试试libjpeg-turbo。或者，您可以使用zlib 之类的东西压缩图像，然后将实际的还原卸载到另一台机器上吗？图像的实际有损压缩是否必须在嵌入式设备本身上进行？

【讨论】：

libjpeg-turbo 的许可证是 lgpl = 不适用于商业或真正/实际的开源项目。
zlib 压缩比 jpeg 压缩慢几倍。
png 使用 zlib 压缩。 zlib 对嵌入式来说很痛苦，代码不是真正的 32/64 位干净，交叉编译很差，并且在其默认配置中需要大量 ram。取决于您的嵌入程度。
您可以将busybox实现用于嵌入式系统，但我不确定它的性能如何。

【解决方案3】：

在什么情况下？在 PC 或便携式设备上？

根据我的经验，您有 JPEG、JPEG2000、PNG 和……呃，这就是在广泛的上下文中“支持良好”的图像类型（有损与否！）

（万岁，GIF 即将推出。）

【讨论】：

我什至会说 JPEG2000 不是通用的，所以列表实际上只有 JPEG 和 PNG。
LZW 的专利至少在欧洲部分地区已经过期，所以除了色彩空间有限之外，没有真正的理由避免使用 GIF。这可以被规避（虽然相当丑陋）。
用于嵌入式 linux 机器人。
tiff 不知何故仍然存在，我似乎一直在用扫描仪遇到它。也无损。
DCT 压缩图像可以放入 TIFF 容器中，因此从技术上讲，TIFF 可以是有损的，也可以是无损的。不过，这并没有改变 DCT 几乎是唯一的有损图像压缩游戏的基线观察结果。

【解决方案4】：

JPEG2000 一点也不快。使用 jpeg 的编码或解码速度是否不够快？在 jpeg 上仅执行 4x4 FDCT 和 IDCT 可能会快很多。

很难找到有关 IJG libjpeg 的任何文档，但如果您使用它，请尝试降低质量设置，它可能会使其更快，而且似乎还有一个快速 FDCT 选项。

有人提到 libjpeg-turbo 使用 SIMD 指令并与常规 libjpeg 兼容。如果这对你来说是一个选择，我认为你应该尝试一下。

【讨论】：

【解决方案5】：

我认为基于小波的压缩算法通常比使用 DCT 的压缩算法慢。也许你应该看看 JPEG XR 和 WebP 格式。

【讨论】：

【解决方案6】：

如果您不需要完整的图像保真度，您可以简单地将图像调整为更小的图像。将每个 2x2 块平均为单个像素将很快将大小减小到 1/4。

【讨论】：