JPEM压缩原理

本文介绍JPEG压缩技术的原理,对于DCT变换、Zig-Zag扫描和Huffman编码,给出一个较为清晰的框架。


1. JPEG压缩的编解码互逆过程:

  • 编码


  • 解码






2. 具体过程:(这里仅以编码为例,解码过程为其逆过程)

       

  A. 将原始图像分为8*8的小块, 每个block里有64pixels:




     



    B. 将图像中每个8*8的block进行DCT变换:

数据压缩中有很多变换,比如KLT(Karhunen-Loeve Transform),这里我们用的是DCT离散余弦变换。和FFT一样,DCT也是将信号从时域到频域的变换,不同的是DCT中变换结果没有复数,全是实数。每8*8个original pixels都变成了另外8*8个数字,变换后的每一个数都是由original 64 data通过basis function组合而得的,如下图所示为DCT谱中6个元素的由来。


低频部分集中在每个8*8块的左上角,高频部分在右下角所谓JPEG的有损压缩,损的是量化过程中的高频部分。为什么呢?因为有这样一个前提:低频部分比高频部分要重要得多,romove 50%的高频信息可能对于编码信息只损失了5%。




    



    C. 量化:

所谓量化就是用像素值÷量化表对应值所得的结果。由于量化表左上角的值较小,右上角的值较大,这样就起到了保持低频分量,抑制高频分量的目的。JPEG使用的颜色是YUV格式。我们提到过,Y分量代表了亮度信息,UV分量代表了色差信息。相比而言,Y分量更重要一些。我们可以对Y采用细量化,对UV采用粗量化,可进一步提高压缩比。所以上面所说的量化表通常有两张,一张是针对Y的;一张是针对UV的。

通过量化可以reducing the number of bits and eliminating some of the components,达到通低频减高频的效果,如下图所示就是两张量化表的例子. 


比如左边那个量化表,最右下角的高频÷16,这样原先DCT后[-127,127]的范围就变成了[-7,7],固然减少了码字(从8位减至4位)。



    


    D. 编码分类:

编码信息分两类,一类是每个8*8格子F中的[0,0]位置上元素,这是DC(直流分量),代表8*8个子块的平均值,JPEG中对F[0,0]单独编码,由于两个相邻的8×8子块的DC系数相差很小,所以对它们采用差分编码DPCM,可以提高压缩比,也就是说对相邻的子块DC系数的差值进行编码。

另一类是8×8块的其它63个子块,即交流(AC)系数,采用行程编码(游程编码Run-length encode,RLE)。这里出现一个问题:这63个系数应该按照怎么样的顺序排列?为了保证低频分量先出现,高频分量后出现,以增加行程中连续“0”的个数,这63个元素采用了“之”字型(Zig-Zag)的排列方法,如下图所示。






    E. 编码格式:

上面,我们得到了DC码字和 AC行程码字。为了进一步提高压缩比,需要对RLE编码结果再进行熵编码,这里选用Huffman编码。Huffman编码具体不讲啦,详细地看我以前的这篇Huffman编码——原理与实现吧





Reference:

1. http://jilie0226.blog.163.com/blog/static/36792254200902072746964/

2. http://www.stat.ncsu.edu/people/martin/courses/st783/JPEG%20(Transform%20compression).htm

3. http://fourier.eng.hmc.edu/e161/lectures/klt/node3.html

4. http://tomjark.blog.163.com/blog/static/14600788201010137309298/

5. http://blog.chinaunix.net/uid-24517893-id-3074462.html

### ### 报文格式的组成部分 报文格式通常由两个主要部分组成:**报头(Header)** 和 **有效载荷(Payload)**。报头包含控制信息,用于网络传输和处理,而有效载荷则承载实际的数据内容。 #### ### 报头字段的含义 报头字段用于描述报文的元数据,包括源地址、目标地址、序列号、校验和等控制信息,确保数据能够正确传输和解析。不同协议的报头字段有所不同,以下是几种常见协议的报头字段说明。 #### ### RTP 报文头部字段 RTP(Real-time Transport Protocol)报文头部包含以下字段: - **V(Version)**:占2位,表示RTP协议的版本号,当前为2[^1]。 - **P(Padding)**:占1位,如果P=1,则在报文尾部填充一个或多个额外的八位组,这些不是有效载荷的一部分。 - **X(Extension)**:占1位,如果X=1,则在RTP报头后跟有一个扩展报头。 - **CC(CSRC Count)**:占4位,指示CSRC标识符的个数,可以有0~15个。 - **M(Marker)**:占1位,标记字段,对于视频标记一帧的结束,对于音频标记会话的开始。 - **PT(Payload Type)**:占7位,用于说明RTP报文中有效载荷的类型,如GSM音频、JPEM图像等。 - **序列号(Sequence Number)**:占16位,用于标识发送者所发送的RTP报文的序列号,每发送一个报文,序列号增1。 - **时间戳(Timestamp)**:占32位,反映RTP数据包中第一个字节的采样时刻。 - **SSRC(Synchronization Source)**:占32位,用于标识同步信源,该标识符是随机选择的,参加同一视频会议的两个同步信源不能有相同的SSRC。 - **CSRC(Contributing Source)**:每个CSRC标识符占32位,用于标识包含在该RTP报文有效载荷中的所有特约信源。 #### ### TCP 报文头部字段 TCP(Transmission Control Protocol)报文头部包含以下字段: - **源端口(Source Port)**:呼叫端端口号。 - **目的端口(Destination Port)**:被叫端端口号。 - **序列号(Sequence Number)**:分配给报文的序号,用于跟踪报文通信顺序,确保无丢失。 - **确认号(Acknowledgement Number)**:所期待的下一个TCP报文的序列号,并表示对此序列前报文正确接收的确认。 - **报头长度(HLEN)**:报文头部的字节数。 - **保留域(Reserved)**:设置为0。 - **编码位(Code Bits)**:控制功能(如TCP连接的建立和终止)。 - **窗口(Window)**:发送者同意接收的字节数。 - **校验和(Checksum)**:报头和数据字段的校验和。 - **紧急指针(Urgent Pointer)**:指示紧急数据段的末尾。 - **选项(Option)**:当前定义TCP段的最大值。 - **数据(Data)**:上层协议数据。 #### ### UDP 报文头部字段 UDP(User Datagram Protocol)报文头部相对简单,仅包含以下字段: - **源端口(Source Port)**:可选字段,表示发送方的端口号。 - **目的端口(Destination Port)**:必须字段,表示接收方的端口号。 - **长度(Length)**:表示UDP报文的总长度(包括头部和数据)。 - **校验和(Checksum)**:用于校验UDP报文头部和数据的完整性。 #### ### HTTP 报文头部字段 HTTP(Hypertext Transfer Protocol)报文头部包含请求行、状态行和多个头部字段,每个字段以 `<CR><LF>` 结尾: - **Host**:区分虚拟主机,在HTTP/1.0中可选,HTTP/1.1中强制。 - **User-Agent**:客户端标识信息。 - **Content-Type**:指定发送的数据类型。 - **Content-Length**:指定发送数据的长度。 - **Cookie**:存储在客户端的会话信息,用于服务器识别用户。 #### ### 数据链路层报文头部字段(如MAC头部) 在使用 `SOCK_RAW` 套接字时,报文头部还包括 MAC 地址信息: - **目的MAC地址(Destination MAC Address)**:接收方的物理地址。 - **源MAC地址(Source MAC Address)**:发送方的物理地址。 - **类型(Type)**:指示上层协议类型,如 IPv4、IPv6 等。 #### ### 报文格式的结构示例 ```c // RTP Header Example struct rtp_header { uint8_t version:2; uint8_t padding:1; uint8_t extension:1; uint8_t csrc_count:4; uint8_t marker:1; uint8_t payload_type:7; uint16_t sequence_number; uint32_t timestamp; uint32_t ssrc; uint32_t csrc[]; }; ``` ```c // TCP Header Example struct tcp_header { uint16_t source_port; uint16_t dest_port; uint32_t sequence_number; uint32_t ack_number; uint8_t data_offset:4; uint8_t reserved:4; uint8_t flags; uint16_t window; uint16_t checksum; uint16_t urgent_pointer; uint8_t options[]; }; ``` ```c // UDP Header Example struct udp_header { uint16_t source_port; uint16_t dest_port; uint16_t length; uint16_t checksum; }; ``` ```c // Ethernet MAC Header Example struct eth_header { uint8_t dest_mac[6]; uint8_t source_mac[6]; uint16_t eth_type; }; ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值