JPEG解码——(3)文件头解析,JPEG解码--(1)JPEG文件格式概览

Linux常用命令:文件操作命令

  与具体的编码数据空间相比,jpeg文件头占据非常小乃至可以忽略不计的大小。

  仍然拿JPEG解码--(1)JPEG文件格式概览中的《animal park》这张图片来举例,从跳过SOS(FF DA)的TAG开始——0x153,

就真正进入了编码数据区域,如下图所示:

  其占据的比例为:0x153/0x9721 = 339/38689 = 0.876%,还不到1%,其他jpeg图片也是类似情况。

  但是,就是这么小的数据区域,却是至关重要的地方,某些关键的地方一个字节出错了的话,解码就会出错(例如huffman table

中数据),或者重建出的yuv图像异常(例如quantization table中数据)!

  本篇博客主要介绍jpeg头信息解析,其中除了huffman table重建较复杂外,其他TAG的解析都比较容易。

1. APP0——FF EO

  先贴出这段区域:

  从ASCII值可以看出,保存了JFIF——JPEG File Interchange Format(JPEG文件交换格式),后面的几个字节应该是version信

息吧,没深究。

2. DQT——FF DB

  量化表有两个,上面贴图只高亮了其中一个表。

  从offset=0x16开始的两个字节(0x00 43)为这段区域的size=67,后面的一个字节为表的ID——0x00=0(可以看到第二张表中对

null调整为not null default xxx,不得不注意的坑

应位置offset=0x5D处为0x1)。

  跳过前面三字节从offset=0x19处开始的64字节,即为量化表中量化值。其中需要说明的是,量化值是固定为64字节的,因为按8X8

进行DCT变换的。

  工具解析的结果如下:

  需要补充两点:

  A.亮度信号的Y分量使用DQT表一,UV分量使用表二。

  B.亮度信号通常采用细量化(量化值较小),对应位置处,表一通常比表二值要小。此量化原因是人眼对亮度信号比较敏感,采用颗粒度

较细来量化,细量化引入的一个问题会消耗更多的数据空间。

3. SOF——FF C0

  在该JPEG解码系列中第一篇已经详细介绍过了,不再赘述。工具解析如下:

4. DHT——FF C4

  共有四张表,上面只贴出第一张表。

  DHT表的重建有些复杂,涉及底层更多关于数据压缩领域的知识,可以参考“范式霍夫曼编码”相关材料,本博文不再做介绍该编码原理。

图解|网络究竟是如何运作的?

相关推荐

发表评论

路人甲

网友评论(0)