即时无损图像压缩
我有一个嵌入式应用程序，其中图像扫描仪发送 16 位像素流，随后将其组合成灰度图像。由于我需要在本地保存这些数据并将其转发到网络接口，因此我想压缩数据流以减少所需的存储空间和网络带宽。
是否有一种简单的算法可以用来无损压缩像素数据？
我首先想到计算两个连续像素之间的差异，然后用霍夫曼代码对该差异进行编码。不幸的是，像素是无符号的 16 位量，因此差异可能在 -65535 .. +65535 范围内的任何位置，这会导致潜在的巨大码字长度。如果连续出现几个非常长的代码字，我将遇到缓冲区溢出问题。
更新：我的平台是FPGA
I have an embedded application where an image scanner sends out a stream of 16-bit pixels that are later assembled to a grayscale image. As I need to both save this data locally and forward it to a network interface, I'd like to compress the data stream to reduce the required storage space and network bandwidth.
Is there a simple algorithm that I can use to losslessly compress the pixel data?
I first thought of computing the difference between two consecutive pixels and then encoding this difference with a Huffman code. Unfortunately, the pixels are unsigned 16-bit quantities so the difference can be anywhere in the range -65535 .. +65535 which leads to potentially huge codeword lengths. If a few really long codewords occur in a row, I'll run into buffer overflow problems.
Update: my platform is an FPGA
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
PNG 使用标准工具以标准格式提供免费、开源、无损的图像压缩。 PNG 使用
zlib作为其压缩的一部分。还有一个libpng。除非您的平台非常不寻常，否则将此代码移植到该平台应该不难。PNG provides free, open-source, lossless image compression in a standard format using standard tools. PNG uses
zlibas part of its compression. There is also alibpng. Unless your platform is very unusual, it should not be hard to port this code to it.您的嵌入式平台上有多少可用资源？
您可以移植 zlib 并进行 gzip 压缩吗？即使资源有限，您也应该能够移植类似 LZ77 或LZ88。
How many resources do you have available on your embedded platform?
Could you port zlib and do gzip compression? Even with limited resources, you should be able to port something like LZ77 or LZ88.
有多种可用的图像压缩库。例如，此页面仅列出 PNG 图像的库/工具包。哪种格式/库最适合您很可能取决于您正在工作的特定资源限制（特别是您的嵌入式系统是否可以执行浮点运算）。
There are a wide variety of image compression libraries available. For example, this page lists nothing but libraries/toolkits for PNG images. Which format/library works best for you will most likely depend on the particular resource constraints you are working under (in particular, whether or not your embedded system can do floating-point arithmetic).
无损压缩的目标是能够根据先前的像素预测下一个像素，然后对预测与像素的实际值之间的差异进行编码。这是您最初想要做的，但您仅使用前一个像素并预测下一个像素将是相同的。
请记住，如果您拥有所有先前的像素，那么您将获得比前一个像素更多的相关信息。也就是说，如果您尝试预测 X 的值，则应该使用 O 像素：
..OOO...
..OX
此外，在以下情况下，您不希望使用流中的前一个像素 B 来预测 X：
OO...B <-- 行结束
X <- 下一行的开始
相反，您将根据 Os 进行预测。
The goal with lossless compression is to be able to predict the next pixel based on previous pixels, and then to encode the difference between your prediction and the real value of the pixel. This is what you initial thought to do, but you were only using the one previous pixel and making the prediction that the next pixel would be the same.
Keep in mind that if you have all of the previous pixels, you have more relevant information than just the preceding pixel. That is, if you are trying to predict the value of X, you should use the O pixels:
..OOO...
..OX
Also, you would not want to use the previous pixel, B, in the stream to predict X in the following situation:
OO...B <-- End of row
X <- Start of next row
Instead you would make your prediction base on the Os.
您需要多“无损”？
如果这是一台真正的扫描仪，则带宽/分辨率存在限制，因此即使它可以发送 +/-64K 值，相邻像素的差异超过 8 位也可能是不物理的。
在这种情况下，您可以为每行计算起始像素值，然后计算每个像素之间的差异。
这会抹掉峰值，但无论如何，任何超过“N”位的峰值都可能是噪声。
How 'lossless' do you need?
If this is a real scanner there is a limit to the bandwidth/resolution so even if it can send +/-64K values it may be unphysical for adjacent pixels to have a difference of more than say 8 bits.
In which case you can do a start pixel value for each row and then do differences between each pixel.
This will smear out peaks but it may be that any peaks more than 'N'bits are noise anyway.
一个好的 LZ77/RLE 混合体可以得到美妙的压缩，并且解压缩相当快。由于缺乏库开销，它们对于较小的文件来说也会是更大、更糟糕的压缩器。要获得良好的 GPLd 实现，请查看 PUCrunch
A good LZ77/RLE hybrid with bells and wwhistles can get wonderful compression that is fairly quick to decompress. They will also be bigger, badder compressors on smaller files due to the lack of library overhead. For a good, but GPLd implentation of this, check out PUCrunch