字体压缩！ RLE或Huffman还是一无所有？

我正在开发嵌入式项目（ARM7）。在我的应用程序中，我必须存储大量浪费大约300k闪存的中文字符。当前的字体编码是Unicode，每个字符包含22个字节，因为每个字形都是12 * 12加左边和底部的一行空间，这使得它成为169像素（22字节）（请参阅示例）。作为一个例子，Unicode的这个中国字符 enter image description here 字体压缩！ RLE或Huffman还是一无所有？

如下： /* unicode5939 */ 0x40的，0x44进行，0x4c，0x54，0x64，0xFF时，为0xFF，0x44进行， 0x54，0x4c，0×44， 0x40，0x0，0x8，0x11，0x11， 0x0,0x8,0x82,0x20,0x4,0x0。

当前的Unicode是这样的：字形的高8行完全等于Unicode的前13个字节（基于列而不是基于行，从右上侧）。剩余的9个字节表示字形的底部5行（查看左侧的右侧，逐列放置0和1，直到字节变满，等等）。

如果我们对此Unicode进行RLE压缩（按位），则结果需要超过22个字节来存储每次运行的重复次数（就我手工操作而言）。所以我想做另一种类型的压缩。任何线索？

来源

2013-10-01 Django

选自Y我们的要求看起来像lz4或其他lz *是适当的。嵌入式世界有许多实现。 – domen

我在字符和数据集之间没有看到任何关系。这不是一个位图 - 或者它？我假设你错误地使用术语“Unicode”，你需要在诸如“字符编码是每个字符包括22个字节的Unicode”的句子中使用它之前查看它。 – usr2564301

感谢您的意见！实际上我已经给出了字符图像以及那些代码（在文件中声明为unicode）。它似乎是根据文件头由XML2c转换工具自动生成的。图像是12 * 12，但似乎在字符的右侧和底部使用了更多空间，所以代码为13 * 13字形。 – Django

字体压缩甚至可以每个使用例如/字形基础来处理算术编码用说4位附近：

[ 4 ] [ 3 ] [ 2 ] 
[ 1 ] (x)

像素P1，P2，P3，P4码X == 0的VS X == 1，这是该位的 'x' 后进行更新的概率中的每一个附近被处理;与霍夫曼编码器不同，算术编码器能够以较小的单位压缩符号而不是一位，这是香农信息理论给出的限制。

Context, count    bits per symbol 
Zeros[ 0] = 45 Ones[ 0] = 4 19.987 
Zeros[ 1] = 7 Ones[ 1] = 4 10.402 
Zeros[ 2] = 6 Ones[ 2] = 0 0.000 
Zeros[ 3] = 2 Ones[ 3] = 2 4.000 
Zeros[ 4] = 6 Ones[ 4] = 5 10.934 
Zeros[ 5] = 0 Ones[ 5] = 1 0.000 
Zeros[ 6] = 2 Ones[ 6] = 0 0.000 
Zeros[ 7] = 9 Ones[ 7] = 4 11.576 
Zeros[ 8] = 5 Ones[ 8] = 13 15.343 
Zeros[ 9] = 1 Ones[ 9] = 3 3.245 
Zeros[10] = 4 Ones[10] = 0 0.000 
Zeros[11] = 1 Ones[11] = 3 3.245 
Zeros[12] = 2 Ones[12] = 2 4.000 
Zeros[13] = 1 Ones[13] = 0 0.000 
Zeros[14] = 1 Ones[14] = 5 3.900 
Zeros[15] = 3 Ones[15] = 3 6.000 
Total 92.634 bits = 12 bytes 
vs. no context, 
Zeros = 95   Ones = 49  133.212 bits = 17 bytes

的明显的问题是如何初始化数组：

1）使用一个固定的，即频率的静态模型
2）使用完全自适应模型，假设开始时有50:50的机会
3）使用固定模型的集合（2-256？），最能表征字形
4）以来自预先计算的集合和更新的某些模型

完整的模型需要32个字节来编码0..169的值，因此除非非常强（并且巧妙地）压缩，否则不能与字符一起传递。

EDIT 如果单个（或非常少的全局静态表用于），还可以放大表格5,6,7 -pixel街区，或嵌入的像素位置信息表中（该方法失败来编码条件 'x是在底线'）：

[ B ] [ C ] [ D ],   where A,B,C,D = 00 for 'white' 
[ A ] (x)         11 for 'black' 
              01/10 for pixel outside canvas 

or 
[ 1 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]  + [ x is next to border? ] 
[ 0 ] [ 2 ] (x)

进一步阅读：
- Fax Compression/JBIG
- Arithmetic Coding

来源

2013-10-03 13:03:23

（不是真正的答案，但我需要一个比一个评论更多的空间）

好吧，至少13 * 13能装下22个字节（这是169位，因此21个1/8字节）。当作为字节摆出来，它看起来像这样：

01000000 01000 00010 
01000100 01000 00010 
01001100 00100 00100 
01010100 00010 01000 
01100100 00001 10000 
11111111 00000 00000 Reordered by groups of five bits, 
11111111 00000 <- 00000 <--------------------------+ 
01000100 00001 10000 flipped again    | 
01010100 00010 01000       | 
01001100 00100 00100       | 
01000100 01000 00010       | 
01000000 01000 00010       | 
00000000 00000 00000       | 
00001000 -> 00010000 <- Bottom 9 bytes reversed: \ | 
00010001 -> 10001000        | | 
00010001 -> 10001000        | | 
00000000 -> 00000000        | | 
00001000 -> 00010000        +--+ 
10000010 -> 01000001        | 
00100000 -> 00000100        | 
00000100 -> 00100000        | 
00000000 -> 0  (only one useful bit)  /

至少前13个字节肯定看起来像前8行的字符（在右上方）的。对于底部的9个字节，一旦颠倒过来，它们可以由5位组来布局，并且看起来像底部。

或者其可读性，这一切都像这样编码： Glyph storage diagram

现在回答实际问题，我敢肯定，试图压缩字形分别是一个灾难。由于缺乏存储未压缩数据的空间，因此无法在一个块中压缩全部。因此，压缩需要在X字形块中完成，并且需要一个用于解压缩块的高速缓存系统。

来源

2013-10-02 07:54:57 Medinoc

谢谢，总数约为900个字形。所以完全是20K的东西。 – Django

@ user1469187：如果数据压缩到16K并且解压缩代码本身是3K长，那会是一种改进吗？换句话说：您将为复杂的代码交易（易于解析）数据（加上运行时问题，例如处理临时解压缩内存，以及解压缩本身的开销）。另外，20K不是很多 - 你有多少块？ – usr2564301

@jongware感谢您的评论。实际上整个数据大约是300K。我的任务正在处理其中的一部分（22K），以查看压缩是否正常工作。如果压缩完美无缺，那么它将在其他数据上完成。闪光灯剩下大约30万个空间。如果我们无法压缩数据，闪光灯会有点充满， – Django

通过不存储每个字形的空白行，您将获得将近20％的提升。

12×12 13×13代替= 18个字节，而不是22

来源

2013-10-03 10:12:00 Roddy

字体压缩！ RLE或Huffman还是一无所有？

回答

相关问题