简单的二色差分图像压缩

发布于 2024-08-31 23:10:08 字数 236 浏览 2 评论 0原文

是否有一个高效、快速且简单的差分黑白图像压缩示例?或者甚至更好,一些简单的(但无损 - 使用有损压缩压缩时,锯齿状 1bpp 图像看起来不太令人信服)流技术可以接受多个帧作为输入?

我有一个简单的黑白图像 (320x200) 流,显示类似于 LED 显示屏的内容,使用 AJAX 大约每秒更新一次。图像在大多数情况下都非常相似,因此如果我减去它们,结果会压缩得很好(即使使用简单的 RLE)。有这样的东西吗?

Is there an efficient, quick and simple example of doing differential b/w image compression? Or even better, some simple (but lossless - jagged 1bpp images don't look very convincing when compressed using lossy compression) streaming technique which could accept a number of frames as input?

I have a simple b/w image (320x200) stream, displaying something similar to a LED display, which is updated about once a second using AJAX. Images are pretty similar most of the time, so if I subtracted them, result would compress pretty well (even with simple RLE). Is something like this available?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

绝影如岚 2024-09-07 23:10:09

除了通过 gzip 或其他无损压缩算法运行它之外,我不知道任何已经存在的库可以完成您所要求的操作。但是,由于您知道这些帧是高度相关的,因此您可以像 Conspiccious Compiler 建议的那样对帧进行异或,然后对其运行 gzip。如果帧之间的变化很少,则异或的结果应该比原始帧具有更少的熵。这将允许 gzip 或其他无损压缩算法实现更高的压缩比。

您还希望每隔一段时间发送一个关键(非差分)帧,以便在出现错误时可以重新同步。

如果您只是有兴趣了解压缩,您可以尝试在对帧进行异或之后实现 RLE。查看此处大约在页面一半处讨论的位级 RLE。它应该很容易实现,因为它只在每个字节中存储 7 位长度和 1 位值,因此如果帧之间没有变化,它可以实现 128/8=16 的最佳情况压缩比。

另一个想法是,如果变化很少,您可能只想对帧之间翻转的位位置进行编码。您可以使用 16 位整数来寻址 320x200 图像。例如,如果只有 100 个像素发生变化,您可以只存储 100 个 16 位整数来表示这些位置(1600 位),其中上面讨论的 RLE 至少需要 64000/16=4000 位(可能会高很多) 。实际上,您可以根据帧内容在此方法和 RLE 之间进行切换。

如果您想超越简单的方法,我建议使用可变长度代码来表示游程编码期间可能的游程。然后,您可以为概率最高的运行分配较短的代码。这与执行有损压缩部分(DCT 和量化)后 JPEG 或 MPEG 中使用的 RLE 类似。

I don't know of any library that already exists that can do what you're asking other than just running it through gzip or some other lossless compression algorithm. However, since you know that the frames are highly correlated, you could XOR the frames like Conspicuous Compiler suggested and then run gzip on that. If there are few changes between frames, the result of the XOR should have a great deal less entropy than the original frame. This will allow gzip or another lossless compression algorithm to achieve a higher compression ratio.

You would also want to send a key(non-differential) frame every once in a while so you can resynchronize in the event of errors.

If you are just interested in learning about compression, you could try implementing the RLE after XORing the frames. Check out the bit-level RLE discussed here about half way down the page. It should be pretty easy to implement as it just stores in each byte a 7 bit length and a one bit value so it could achieve a best-case compression ratio of 128/8=16 if there are no changes between frames.

Another thought is that if there are very few changes, you may want to just encode the bit positions that flipped between frames. You could address the 320x200 image with a 16-bit integer. For instance, if only 100 pixels change, you can just store 100 16 bit integers representing those positions (1600 bits) where the RLE discussed above would take 64000/16=4000 bits at the minimum (it would probably be quite a bit higher). You could actually switch between this method and RLE depending on the frame content.

If you wanted to go beyond simple methods, I would suggest using variable-length codes to represent the possible runs during the run-length encoding. You could then assign shorter codes to the runs with the highest probability. This would be similar to the RLE used in JPEG or MPEG after the lossy part of the compression is performed (DCT and quantization).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文