压缩软件课程设计报告课件Word格式.docx
《压缩软件课程设计报告课件Word格式.docx》由会员分享，可在线阅读，更多相关《压缩软件课程设计报告课件Word格式.docx（16页珍藏版）》请在冰豆网上搜索。
1.2国内外研究现状5
1.3课程设计的主要研究工作6
2系统需求分析与总体设计7
2.1系统需求分析7
2.2系统总体设计7
3系统详细设计8
3.1有关数据结构的定义8
3.2主要算法设计9
4系统实现与测试11
4.1系统实现11
4.2系统测试11
5总结与展望13
5.1全文总结13
5.2工作展望13
6体会14
附录15
1引言
1.1课题背景与意义
信息如何被高效存储和传递的问题一直是计算机研究的一个重要课题,而解决这一问题的最常用的就是数据压缩技术。
计算机为什么需要数据压缩技术呢?
一是因为容量的限制,促使各程序员开始开发各种压缩软件对软件进行压缩。
二是信息通讯量的限制,人们希望在网上下载的软件越小越好。
随着数码技术的发展,压缩技术也在不断发展,因为硬盘和光盘的空间毕竟是有限的,而游戏、音频、视频、图片在计算机中应用中越来越普遍,但它们又非常占据空间,所以压缩技术前景非常广阔并且不断在发展。
与压缩相关的有两个步骤:
第一个步骤是压缩,第二个步骤则是解压缩。
在计算机中所有信息都是以二进制代码形式存在的,这些信息具体形式可以是声音、图像、软件,因此我们把只用二进制编码的像片、音频等可以称为数码像片或数码音频。
以数码图片为例,压缩就是要把的图像的二进制代码中冗长的、重复的代码遵循一定的算法用简短的代码来代替。
如果把软件中的冗长的、重复的代码如果都按一定的算法用简短的代码来替换的话,最后重新生成的软件一定会小得多。
这个过程,就叫做压缩。
一般而言,被压缩的文件是不能直接运行的,那是因为它的代码都被简化了。
被压缩了的文件只是变小了空间而已,是不能直接使用的。
要想再使用这些压缩过的文件,就必须解压缩。
解压缩文件要用到对应的压缩软件。
解压缩的过程正好和压缩的过程相反,即通过算法将简短的压缩代码还原为程序的真正代码。
在多媒体应用中，数字化信息的数据量相当庞大，对存储器的存储器的存储容量、网络带宽以及计算机的处理速度都有较高的要求，完全通过增加硬件设施来满足现实需求是不可能的，必须采用有效的压缩技术。
多媒体数据之所以能够进行压缩时因为原始数据存在以下三种形式的冗余：
（1）编码冗余。
如频率相差很大的像素用相同长度的代码进行编码；
（2）像素间冗余。
如相邻像素间具有时域或空域相关性；
（3）视觉信息冗余。
即人的视觉图像边缘急剧变化不敏感，对色彩的分辨能力弱，只对图像的亮度敏感，对经压缩和解压缩后的图像失真难以察觉或影响甚微。
这些数据本身的冗余和人的感官特性构成了多媒体数据压缩的基础，同时也确定了数据压缩的研究方向。
1.1.1数据压缩标准
从20世纪80年代开始，世界上已有几十家公司纷纷投入到多媒体计算机系统的研制和开发工作。
20世纪90年代已有不少精彩的多媒体产品问世，诸如荷兰菲利浦和日本索尼联合推出的CD-I，苹果公司Macintosh为基础的多媒体功能的计算机系统，Intel和IBM公司联合推出的DVI。
此外，还有Microsoft公司的MPC及苹果的QuickTime等，这些多媒体计算机系统各具特色，丰富多彩，竞争异常激烈。
具有人机交互特色的多媒体技术，使计算机进入普通家庭，进入人们的生活、学习、娱乐及人们的精神生活领域。
人们像使用家用电器一样地使用计算机。
计算机能听懂人的话语；
计算机成为能讲话的实用型产品进入市场，也为时不远了。
Internet技术的迅猛发展与普及，推动了世界范围的信息传输和信息交流。
在色彩缤纷、变幻无穷的多媒体世界中，用户如何选择产品，如何自由地组合、装配来自不同厂家的产品部件，构成自己满意的系统，这就涉及一个不同厂家产品的兼容性问题，因此需要一个全球性的统一的国际技术标准。
国际标准化协会（InternationalStandardizationOrganization，ISO）、国际电子学委员会（InternationalElectronicsCommittee，IEC）、国际电信协会（InternationalTelecommunicationUnion，ITU）等国际组织及CCITT，于20世纪90年代领导制定了多个重要的多媒体国际标准。
如H.261、H.263、JPEG和MPEG等标准。
H.261是被可视电话、电视会议中采用的视频、图像压缩编码标准，由CCITT制定，1990年12月正式批准通过；
JPEG是由ISO与CCITT成立的“联合图片专家组（JointPhotographicExpertsGroup，JPEG）”制定的，用于灰度图、彩色图的连续变化的静止图像编码标准，于1992年正式通过；
MPEG是以H.261标准为基础发展而来的。
它是由IEC和ISO成立的“运动图像专家组（MovingPictureExpertsGroup，MPEG）”制定的，于1992年通过了MPEG-1，并在后来的几年中，陆续推出了MPEG-2、MPEG-4、MPEG-7等标准。
1.1.2数据压缩评价
（1）压缩比,即压缩前后的数据量之比,一般来说,压缩比要在一定的质量主观满意度基础上尽可能的大。
（2）算法的复杂性和运算速度,实现压缩的算法要简单,以便在有限的硬件资源上加快压缩解压缩的速度,尽可能地实时压缩解压缩。
（3）失真度,即解压后数据的恢复质量要好,尽可能地完全再现原始数据。
1.2国内外研究现状
从国际数据压缩技术的发展尤其是MPEG的发展可以看出，基于内容的图像压缩编码方法是未来编码的发展趋势。
它不仅能满足进一步获得更大的图像数据压缩比的要求，而且能够实现人机对话的功能。
另外，任意形状物体的模型建立的关键问题还没有解决，这严重影响其应用的广泛性。
因此，视频编码将朝着多模式和跨模式的方向发展。
通过元数据进行编码也是今后编码的发展方向。
元数据是指详细的描述音/视频信息的基本元素，利用元数据来描述音视频对象的同时也就完成了编码，因为此时编码的对象是图像的一种描述而不再是图像本身。
从另一个角度来说，进一步提高压缩比，提高码流的附属功能（码流内容的可访问性、抗误码能力、可伸缩性等）也将是未来的编码的两个发展方向。
当前，压缩域处理技术作为新兴的技术还远未成熟，许多问题有待解决，其中缺乏统一的理论支持是主要问题。
未来的研究工作主要集中在四个方面：
设计新的压缩算法，支持对压缩域数据直接操作；
研究用小波、矢量量化、分形等压缩算法的多媒体数据的压缩处理算法；
设计专用的压缩域数据处理芯片；
如何将用于多媒体内容的传输和使用的各种标准结合起来，形成一个用于多媒体的统一的体系结构。
未来多媒体数据压缩技术的发展趋势将是基于内容的压缩。
另外，图像压缩技术、视频技术与网络技术相结合的应用前景十分可观，如远程图像传输系统、动态视频传输（可视电话）、电视会议系统等已经开始商品化，MPEG标准与视频技术相结合的产物——家用数字视盘机、VideoCD系统等已进入市场。
可以预计，这些技术和产品的发展将对21世纪的社会进步产生中大影响。
1.3课程设计的主要研究工作
本次课程设计主要研究如何在无损的前提下实现数据的压缩，并用不同的压缩策略分别对数据进行压缩时间优先和压缩率优先两种压缩。
具体实现中，我使用了LZW算法和Huffman编码算法对数据进行压缩，对于较小的文件，LZW算法压缩时间短，Huffman编码算法压缩率低，而对于较大的文件，前者压缩率低，后者压缩时间短。
----------------------------------------
2系统需求分析与总体设计
2.1系统需求分析
本课程设计编写的压缩软件要求压缩解压过程保证无损，并实现两种压缩策略，第一种压缩文件后缀名记为.CS，要求在保证一定的压缩率的情况下体现压缩速率；
第二种压缩文件后缀名记为.SCS，强调压缩率，但时间也需要比较合理。
同时压缩文件中保存了需要解压的全部信息。
另外，软件要具有图形化进度条显示压缩过程和解压过程的进度和显示估计剩余时间的功能，还要具有图形化选项选择将编码信息输出到指定磁盘目录的功能
2.2系统总体设计
本软件使用Huffman编算法和LZW算法，基于Qt图形用户界面，总体结构如下流程图所示：
3系统详细设计
3.1有关数据结构的定义
1.Huffman树节点：
huffman_node_tag，huffman_node
结构成员
数据类型
成员定义
isLeaf
unsignedchar
标记该节点是否为叶子节点
count
unsignedlong
记录哈夫曼树节点总个数
parent
huffman_node_tag*
记录该节点的父节点
zero
union
记录该节点的左孩子
one
记录该节点的右孩子
symbol
该节点对应的字符
2.Huffman编码：
new_code_tag，new_code
numbits
编码位数
bits
unsignedchar*
编码
3.栈节点：
node
c
char
栈节点储存的字符
next
node*
指向下一结点
4.栈：
stack
length
int
栈内数据个数
SP
指向栈顶
3.2主要算法设计
（1）Huffman编码算法：
（2）LZW算法：
4系统实现与测试
4.1系统实现
本次课程设计压缩软件的编写基于Qt环境，采用C++语言。
具体实现见附录。
4.2系统测试
对本软件的测试，主要将文件分为不同大小和格式来进行测试。
下标为具体测试数据：
测试文件
文件格式
文件大小/KB
压缩算法
压缩文件大小/KB
压缩率
压缩时间/s
测试文件1
txt
22
Huffman编码
13
59%
<
1
LZW
9
41%
1.4
标准压缩软件
5
22.7
测试文件2
10524
8128
77.2%
12
8063
76.6%
3
4912
46.7%
2
测试文件3
pdf
1914
1913
99.9%
4
2710
141.6%
1796
93.8
测试文件4
MP4
350081
-
508005
145.1%
88
348884
99.7%
25
测试文件5
jpg
597
857
143.6%
100%
（说明：
表中对测试文件4运用huffman算法进行压缩时，由于软件占用空间太大且压缩时间过长而舍弃）
由以上测试数据可得以下结论：
（1）对于较小的文本文档，Huffman编码压缩速度较快，但压缩率较高；
（2）对于较大的文本文档，LZW压缩速率较快，且二者压缩率相近；
（3）对于文本文档的压缩，相较于标准压缩软件，这两种算法在压缩率和压缩时间上都有缺陷；
（4）对于jpg、pdf、mp4这些文件本身冗余信息较少的格式，无论何种压缩算法都不能实现较低的压缩率，甚至会越压越大。
算法时间渐进复杂度分析：
（1）Huffman编码算法，压缩：
T（n）=2cn+c’
=O（n）
（2）Huffman编码算法，解压：
T（n）=c
+c’nlog256=O（n）
（3）LZW算法，压缩：
T（n）=cn=O（n）
（4）LZW算法，解压：
T（n）=O（n）
5总结与展望
5.1全文总结
在本次课程设计中，我主要完成了以下工作：
（1）实现了运用Huffman编码算法和LZW算法对文件进行压缩；
（2）了解了数据压缩算法的一般思想；
（3）进一步熟悉了运用Qt进行简单的图形用户界面编写；
（4）学会了如何在Qt中开多线程以防止GUI假死。
5.2工作展望
在今后的研究中，围绕着如下几个方面开展工作以改进算法的性能：
（1）在LZW中使用二分查找树储存字典，这样虽然压缩过程中对编码的查找复杂度由O
（1）变为O（log4096），但解压过程中对编码的查找却由O（40962）变为O（4096log4096）,整体速率上升；
（2）尝试更多不同的压缩算法，总结分析各种算法的特点，对现有算法进行改进；
6体会
最初看到这个课设题目的时候，其实觉得会很难，因为心中没有任何压缩数据的概念，但是在查阅了部分资料之后，心中有了大概的方向，于是觉得这个题目很简单。
然而，就是由于这种轻敌心理，导致我分配给这次课设的时间过少，以至于软件编写时间紧张。
可是，正是由于时间紧张，我的压力才能够转化为足够的动力，成功地在规定时间内完成了任务，编程的过程中遇到的很多困难也得以一一解决。
其中，我认为解决问题的能力非常重要，因为为了解决某一个bug，我会查阅非常多的资料，从中学到更多的知识。
因此有时候解决问题的过程甚至比编写程序的过程更有意义。
再者，我认识到，做一个产品时不仅要做得好，还要能将产品最成功、最精彩的一面展示给用户，这样的产品才能称为“成功的产品”。
因此，个人的归纳总结以及表达能力也是至关重要的。
今后我会努力弥补这方面的不足。
附录
头文件mainwindow.h
#ifndefMAINWINDOW_H
#defineMAINWINDOW_H
#include<
QMainWindow>
QString>
QFileDialog>
QMessageBox>
huffman.h>
QTime>
QThread>
lzw.h>
externint*f;
externchar*openfileName;
externchar*savefileName;
externunsignedintfilesize;
externintprogress;
externintchannal;
namespaceUi{
classMainWindow;
}
classThread:
publicQThread
{
Q_OBJECT
protected:
voidrun（）;
public:
Thread（QObject*parent=0）;
~Thread（）;
signals:
voidUpdateSignal（intprogress）;
voiderror（QString）;
unsignedlong
numbytes_from_numbits（unsignedlongnumbits）;
unsignedchar
get_bit（unsignedchar*bits,unsignedlongi）;
void
reverse_bits（unsignedchar*bits,unsignedlongnumbits）;
huffman_code*
new_code（consthuffman_node*leaf）;
huffman_node*
new_leaf_node（unsignedcharsymbol）;
new_nonleaf_node（unsignedlongcount,huffman_node*zero,huffman_node*one）;
free_huffman_tree（huffman_node*subtree）;
free_code（huffman_code*p）;
free_encoder（SymbolEncoder*pSE）;
init_frequencies（SymbolFrequencies*pSF）;
unsignedint
get_symbol_frequencies（SymbolFrequencies*pSF,FILE*in）;
staticint
SFComp（constvoid*p1,constvoid*p2）;
build_symbol_encoder（huffman_node*subtree,SymbolEncoder*pSF）;
SymbolEncoder*
calculate_huffman_codes（SymbolFrequencies*pSF）;
int
write_code_table（FILE*out,SymbolEncoder*se,uint32_tsymbol_count）;
read_code_table（FILE*in,unsignedint*pDataBytes）;
do_file_encode（FILE*in,FILE*out,SymbolEncoder*se）;
huffman_encode_file（FILE*in,FILE*out）;
huffman_decode_file（FILE*in,FILE*out）;
lzw_encode_file（FILE*in,FILE*out）;
lzw_decode_file（FILE*in,FILE*out）;
intlzw（FILE*in,FILE*out）;
intfind（unsignedshortdic[4096][256],ints,intcur_mark,stack*S）;
voidreset（stack*）;
voidpush（charvar,stack*stk）;
charpop（stack*stk）;
intempty（stack*stk）;
inthuffman（FILE*in,FILE*out）;
};
classMainWindow:
publicQMainWindow
explicitMainWindow（QWidget*parent=0）;
~MainWindow（）;
QTimetime;
floatrest_time;
publicslots:
voidOpenFile_triggered（）;
voidSaveFile_triggered（）;
voidcomClicked（）;
voiddecomClicked（）;
voidMode（）;
voidUpdateProgress（intprogress）;
private:
Ui:
:
MainWindow*ui;
Thread*myThread;
voidhuffman（）;
voidlzss（）;
#endif//MAINWINDOW_H
头文件huffman.h
#ifndefHUFFMAN_HUFFMAN_H
#defineHUFFMAN_HUFFMAN_H
stdio.h>
stdint.h>
unistd.h>
typedefstructhuffman_node_tag
unsignedcharisLeaf;
unsignedlongcount;
structhuffman_node_tag*parent;
union
{
struct
structhuffman_node_tag*zero,*one;
};
unsignedcharsymbol;
}huffman_node;
typedefstructhuffman_code_tag
unsignedlongnumbits;
unsignedchar*bits;
}huffman_code;
#defineMAX_SYMBOLS256
typedefhuffman_node*SymbolFrequencies[MAX_SYMBOLS];
typedefhuffman_code*SymbolEncoder[MAX_SYMBOLS];
#endif
头文件lzw.h
typedefstructnode{
charc;
structnode*next;
}node;
typedefstructstack{
intlength;
node*SP;
升级会员 