红外编码压缩

红外编码压缩

       由于产品需要将红外学习的编码进行压缩,此前对压缩没有研究,网上找了一些资料,发现LZW算法对数字串的压缩比较好,而且思路简单,容易理解,而且找到一个开源的项目QuickLZ,号称压缩速度很快,所以尝试将它移植到单片机中。

        先转载一篇文章,讲解一下QuickLZ算法

Quicklz压缩算法

  以前对压缩算法一无所知,只是知道哈弗曼编码能做这种事情,但是感觉这样的方法奇慢无比。昨天下午看了下号称世界上最快的压缩算法Quicklz,对压缩的基本思路有了一定的了解。一般的压缩程序的要求读入文件之后以便压缩一边输出,而不是去先分析整个文件中的情况之后才做决定采取哪种算法。

  Quicklz也不例外也是争取利用文件中重复出现的字节来进行压缩,管理结构如下:

在压缩的过程中不断地读入3个字节,然后根据这3个字节得到一个hash值,根据这个hash值就可以找到offset,这个offset就是上次这个hash值出现的位置,而通过cache可以判断出这次出现的和最近一次出现相同hash值的时候的3个字节是不是相同(可能hash相同而实际的值不同)。

  如果相同的长度在3到18之间,那么这些情况可以用4个位来表示。而大于18小于255的情况则需要8位来表示,刚才用于表示长度的低4为则全部变为0,以区别两种情况。在Level=1的时候就只有这两种情况了。在压缩的过程中用4个字节来记录压缩操作,如果有压缩则为1,否则为0。下面是level=1时候的情况:

红外编码压缩_第1张图片

  level=1的时候有个很明显的问题是只记录了一个hash相同时候的cache,这样的话只能等到与上次的值相同才能压缩,而与以前的值相同也不行。在level=2和level=3的时候弥补了这个缺陷,但是代价就是压缩的时间变长。在level=2的时候保存了4个offset(相同hash的位置),然后在这四个中取到重复字节长度最长的一个作为压缩选项(这个值保存在最低的2位中),而重复的长度信息保存在接下来的3个位中(如果够的话,不然初始化这3个位为0,在hash值后面的一个字节中保存),其他的地方就和level=1的时候相同了。压缩后文件的格式如下:

  在上面的情况中我们发现如果是3个字节相同的话只能把它压缩成2个字节。而在level=3的时候弥补了这个缺陷,在level=3的时候与前两个的不同之处是最低的两位统一作为标志,记录进行了什么操作,具体的代码如下:

复制代码
if(matchlen == 3 && offset <= 63)
{
*dst = (unsigned char)(offset << 2);
dst++;
}
else if (matchlen == 3 && offset <= 16383)
{
ui32 f = (ui32)((offset << 2) | 1);
fast_write(f, dst, 2);
dst += 2;
}
else if (matchlen <= 18 && offset <= 1023)
{
ui32 f = ((matchlen - 3) << 2) | ((ui32)offset << 6) | 2;
fast_write(f, dst, 2);
dst += 2;
}
else if(matchlen <= 33)
{
ui32 f = ((matchlen - 2) << 2) | ((ui32)offset << 7) | 3;
fast_write(f, dst, 3);
dst += 3;
}
else
{
ui32 f = ((matchlen - 3) << 7) | ((ui32)offset << 15) | 3;
fast_write(f, dst, 4);
dst += 4;
}
复制代码

虽然最后的两种情况的最低两位都是11,但是从下面的格式图中一眼就能看出区别(对应上面的代码看):

  这里知道了文件被压缩后保存的存储格式,下面考虑一下怎么解压。在level=3的时候解压方法还是很好理解的。但是在level=1和level=2的时候怎么解压呢?毕竟压缩文件中只是存储了hash值,而没有指出重复的字节串,甚至连offset都没有给出。这里其实很好理解,因为第一次遇到一个hash的时候当然是不会去压缩它的,那么在解压程序中我们就得到了offset的值,并且随着解压的进行,hash和offset的值与压缩时候的变化是相同的,所有不必保存这些值也能保证正确的解压。




你可能感兴趣的:(算法,UI,cache,存储,产品,DST)