压缩少量数据

时间:2008-12-22 16:04:08

标签: compression

我有一个程序,我生成大约80到150位左右的比特流,我想压缩它,因为我要将它们变成某种ASCII字符串,以便人们可以传输它们。 / p>

有没有人知道可以在这样的流上运行的一个好的,免费的位感知压缩器?我对“标准选项”的主要问题是这个流应该被视为位而不是字节,否则结构会丢失,并且它们的开销会增加任何增益。

增加:

我想压缩这些流的原因是因为用户可能会使用base64编码来剪切和粘贴它们,因此保存一些数据会很有帮助。

这是一个例子,对于那些想要看到它的人。我将添加格式以便于阅读:

110 110 - This is a 6x6 grid (the maximum is 7x7, so we only need 3 bits!)

000000
011110
010010
010010
011110
000000 - This is one layout grid

000000
000000
001000
000100
000000
000000 - This is the second layout grid

现在我们列出一些作品

010 11111111 - A piece is a 3-bit colour code, then an 8-bit list of 'on / off' bits.
001 10101010 - Another bit!
001 10101010 - Another, identical bit!

我之所以这样说的原因应该被视为'比特',当被视为比特流(特别是'网格中通常为0)时会有明显的压缩选项,当你将其视为字节时,它会消失 - 流。

12 个答案:

答案 0 :(得分:9)

你希望通过压缩150位来实现什么目标?除非你汇总这些19b消息中的几个,否则我不确定你希望获得什么。是UI问题 - 您希望用户发送/接收“代码”吗?

base 64 encoding怎么样?这将获取二进制数据并将其转换为编码字符,以便于传输或输入。

答案 1 :(得分:4)

克里斯,谢谢您发布这些样本。我认为运行长度编码是你想要的方式。这应该是非常简单的实现。

http://en.wikipedia.org/wiki/Run-length_encoding

对所有连续的0都适用。

因此压缩这些字符串的主要原因是为了使它们更容易剪切和粘贴?说得通;这听起来像一个有趣的项目。

如果你只是想让字符串更易于管理,那么听起来就像你已经完成了。如果你试图压缩它们以便它们通过线路传输更快我认为压缩小字符串的好处可能会被其他TCP问题(如MTU大小等等)所打败。 (我在那里没有经验,所以最后一点用多粒盐)

祝你好运!

答案 2 :(得分:3)

我猜想没有通用算法可以为这种数据提供很好的压缩。

您最好的办法是分析数据结构并尝试查找自定义压缩算法,或者可能自定义现有压缩算法(可能使用预先填写的字典或类似内容)。

答案 3 :(得分:2)

由于溪流很小,你能在这里张贴一些吗?

您还确定这些流中有足够的冗余甚至允许压缩吗?是否有重复的数据块?

这有点过分,但在没有任何具体答案的情况下,您可能需要查看ROM场景并查看基于盒式RPG游戏(如“Chrono Trigger”或“Final”)中文本字符串的压缩方式幻想III。“我知道文本字符串在那些游戏中被压缩(字节在那些日子里是如此珍贵)并且解开该计划对黑客来说是一个有趣的挑战。当你提到很多简短的字符串被压缩时,这就是唯一的事物。

但您的根本问题可能仍然存在。我想这些ROM中的压缩方案利用了许多字符串的冗余(即,如果“Timbuktu”出现在58个不同的字符串中),而不是在单个流中。

答案 4 :(得分:2)

我建议您考虑使用zlib。它是可下载的,许可证允许您将它用于几乎任何项目。重要的一点是,它被广泛使用,因此调试得很好。如果您的数据很重要,那么您不希望将来在随机日期调试hombrew算法中的奇数边缘情况。

我已经搞砸了一下,它确实允许面向流的压缩。我不确定当你只是一次喂它少量数据时有多好。无损压缩往往通过查找和消除模式来工作,如果你一次只给12个字节的小东西喂它,就不会有很多模式可以找到。

我不是在回答胡安的回答,因为他还建议使用GIF,这是一种有损压缩。你没有给出很多信息,但我猜你不想要任何实际上丢失数据的压缩格式。最流行的图形,音频和视频压缩算法是有损的;他们依靠人类感官能够正确地拍摄图像或声音,并将一些原始信息略微删除或修改。

答案 5 :(得分:2)

我的第一个建议是你调查range encoding。而不是

1:从位数据压缩成二进制数据然后

2:将二进制数据编码为base64 ASCII数据,

您可以将您的位直接打包到0 - N范围内(其中N是您正在使用的可打印字符数减1)然后执行简单的映射。

我的第二个建议是你研究PNG使用的过滤方法,并考虑是否可以使用类似的方法来使数据更具可压缩性。很难从两个样本布局网格中分辨出来,但很可能从你的第一个网格中看出一些方法,比如“根据上面和左边的邻居预测每个像素,然后如果它满足它的话,将每个像素转换为0预测和1,如果它违背其预测“可以给你一个更加统一的数据集,从而更大的压缩。

答案 6 :(得分:1)

CCITT用于压缩G3和G4 TIFF的Group 3 and Group 4无损编码方案在设计时考虑了二进制数据。 G4 TIFF是黑白图像,通常用于OCR和传真。想到的另一个简单方案是RLE

答案 7 :(得分:1)

JBIG可能会为您提供所需的信息。

http://en.wikipedia.org/wiki/JBIG

http://www.jpeg.org/jbig/index.html

http://www.cl.cam.ac.uk/~mgk25/jbigkit/

JBIG用于压缩1-bpp传真图像。

答案 8 :(得分:0)

zlib压缩(可能与gzip的算法相同)是免费的。它有一些设置,但我不确定你能保存多少,除非你的位有一些周期性模式。

由于png和gif图形文件基本上是位模式的表示,因此您可以找到它们使用的压缩算法。

答案 9 :(得分:0)

你想要的是无损二进制压缩。我相信如果没有大量的其他资源,还有论文或网络文章。谷歌这些条款,我怀疑你会得到你需要的。

你在谈论多少数据?您的管道是否很小或吞吐量如此之高以至于您需要压缩?

回想起来,您的数据非常小,除非您分析流量并执行自己的“压缩”(基本上只是已知位模式的映射/散列),否则您可能无法获得有价值的收益。

正如其他人所说,发布一些样本数据,之后可能会有更好的建议。

答案 10 :(得分:0)

我和蒂姆有同样的想法 - 这么少的数据似乎不值得压缩。事实上,我建议你真正想要研究的是某种ascii编码方法,比如uuencode或mime-encode(又名“Base64”)。

答案 11 :(得分:0)

只是添加到已经说过的内容,不是“压缩少量数据”本质上有点无意义?如果您可以详细说明数据,平台或可能有用的用途。

至于比特vs ascii - 我不完全确定你得到了什么,但正如迈克尔所提到的,Base64提供了一种使任意二进制文件更友好的方法。

请注意,从二进制文件到ascii的任何转换与压缩相反。