JPEG头部解析
6.3.1简介
微处理机中的存放顺序有正序(big endian)和逆序(little endian)之分。正序存放就是高字节存放在前低字节在后,而逆序存放就是低字节在前高字节在后。例如,十六进制数为A02B,正序存放就是A02B,逆序存放就是2BA0。摩托罗拉(Motorola)公司的微处理器使用正序存放,而英特尔(Intel)公司的微处理器使用逆序。JPEG文件中的字节是按照正序排列的。
JPEG委员会在制定JPEG标准时,定义了许多标记(marker)用来区分和识别图像数据及其相关信息,但笔者没有找到JPEG委员会对JPEG文件交换格式的明确定义。直到1998年12月从分析网上具体的JPG图像来看,使用比较广泛的还是JPEG文件交换格式(JPEG File Interchange Format,JFIF)版本号为1.02。这是1992年9月由在C-Cube Microsystems公司工作的Eric Hamilton提出的。此外还有TIFF JPEG等格式,但由于这种格式比较复杂,因此大多数应用程序都支持JFIF文件交换格式。
JPEG文件使用的颜色空间是CCIR 601推荐标准进行的彩色空间(参看第7章)。在这个彩色空间中,每个分量、每个像素的电平规定为255级,用8位代码表示。从RGB转换成YCbCr空间时,使用下面的精确的转换关系:
Y = 256 * E'y
Cb = 256 * [E'Cb] + 128
Cr = 256 * [E'Cr] + 128
其中亮度电平E'y和色差电平E'Cb和E'Cb分别是CCIR 601定义的参数。由于E'y的范围是0~1,E'Cb和E'Cb的范围是-0.5~+0.5,因此Y, Cb和Cr的最大值必须要箝到255。于是RGB和YCbCr之间的转换关系需要按照下面的方法计算。
(1) 从RGB转换成YCbCr
YCbCr(256级)分量可直接从用8位表示的RGB分量计算得到:
Y = 0.299 R + 0.587 G + 0.114 B
Cb = - 0.1687R - 0.3313G + 0.5 B + 128
Cr = 0.5 R - 0.4187G - 0.0813 B + 128
需要注意的是不是所有图像文件格式都按照R0,G0,B0,…… Rn,Gn,Bn的次序存储样本数据,因此在RGB文件转换成JFIF文件时需要首先验证RGB的次序。
(2) 从YCbCr转换成RGB
RGB分量可直接从YCbCr(256级)分量计算得到:
R = Y + 1.402 (Cr-128)
G = Y - 0.34414 (Cb-128) - 0.71414 (Cr-128)
B = Y + 1.772 (Cb-128)
在JFIF文件格式中,图像样本的存放顺序是从左到右和从上到下。这就是说JFIF文件中的第一个图像样本是图像左上角的样本。
6.3.2文件结构
学习这些标记最好就是用UltraEdit编辑工具打开一个.jpg或.jpeg文件,参照着格式去分析,加深对这些格式的理解。
JFIF文件格式直接使用JPEG标准为应用程序定义的许多标记,因此JFIF格式成了事实上JPEG文件交换格式标准。JPEG的每个标记都是由2个字节组成,其前一个字节是固定值0xFF。每个标记之前还可以添加数目不限的0xFF填充字节(fill byte)。下面是其中的8个标记:
- SOI 0xD8 图像开始
- APP0 0xE0 JFIF应用数据块
- APPn 0xE1 - 0xEF 其他的应用数据块(n, 1~15)
- DQT 0xDB 量化表
- SOF0 0xC0 帧开始
- DHT 0xC4 霍夫曼(Huffman)表
- SOS 0xDA 扫描线开始
- EOI 0xD9 图像结束
为使读者对JPEG定义的标记一目了然,现将JPEG的标记码列于表6-05,并保留英文解释。
表6-05 JPEG定义的标记
|
Symbol (符号) |
Code Assignment (标记代码) |
Description (说明) |
|
Start Of Frame markers, non-hierarchical Huffman coding |
||
|
SOF0 |
0xFFC0 |
Baseline DCT |
|
SOF1 |
0xFFC1 |
Extended sequential DCT |
|
SOF2 |
0xFFC2 |
Progressive DCT |
|
SOF3 |
0xFFC3 |
Spatial (sequential) lossless |
|
Start Of Frame markers, hierarchical Huffman coding |
||
|
SOF5 |
0xFFC5 |
Differential sequential DCT |
|
SOF6 |
0xFFC6 |
Differential progressive DCT |
|
SOF7 |
0xFFC7 |
Differential spatial lossless |
|
Start Of Frame markers, non-hierarchical arithmetic coding |
||
|
JPG |
0xFFC8 |
Reserved for JPEG extensions |
|
SOF9 |
0xFFC9 |
Extended sequential DCT |
|
SOF10 |
0xFFCA |
Progressive DCT |
|
SOF11 |
0xFFCB |
Spatial (sequential) Lossless |
|
Start Of Frame markers, hierarchical arithmetic coding |
||
|
SOF13 |
0xFFCD |
Differential sequential DCT |
|
SOF14 |
0xFFCE |
Differential progressive DCT |
|
SOF15 |
0xFFCF |
Differential spatial Lossless |
|
Huffman table specification |
||
|
DHT |
0xFFC4 |
Define Huffman table(s) |
|
arithmetic coding conditioning specification |
||
|
DAC |
0xFFCC |
Define arithmetic conditioning table |
|
Restart interval termination |
||
|
RSTm |
0xFFD0~0xFFD7 |
Restart with modulo 8 counter m |
|
Other marker |
||
|
SOI |
0xFFD8 |
Start of image |
|
EOI |
0xFFD9 |
End of image |
|
SOS |
0xFFDA |
Start of scan |
|
DQT |
0xFFDB |
Define quantization table(s) |
|
DNL |
0xFFDC |
Define number of lines |
|
DRI |
0xFFDD |
Define restart interval |
|
DHP |
0xFFDE |
Define hierarchical progression |
|
EXP |
0xFFDF |
Expand reference image(s) |
|
APPn |
0xFFE0~0xFFEF |
Reserved for application use |
|
JPGn |
0xFFF0~0xFFFD |
Reserved for JPEG extension |
|
COM |
0xFFFE |
Comment |
|
Reserved markers |
||
|
TEM |
0xFF01 |
For temporary use in arithmetic coding |
|
RES |
0xFF02~0xFFBF |
Reserved |
JPEG文件由下面的8个部分组成:
(1) 图像开始SOI(Start of Image)标记
(2) APP0标记(Marker)
① APP0长度(length)
② 标识符(identifier)
③ 版本号(version)
④ X和Y的密度单位(units=0:无单位;units=1:点数/英寸;units=2:点数/厘米)
⑤ X方向像素密度(X density)
⑥ Y方向像素密度(Y density)
⑦ 缩略图水平像素数目(thumbnail horizontal pixels)
⑧ 缩略图垂直像素数目(thumbnail vertical pixels)
⑨ 缩略图RGB位图(thumbnail RGB bitmap)
(3) APPn标记(Markers),其中n=1~15(任选)
① APPn长度(length)
② 由于详细信息(application specific information)
(4) 一个或者多个量化表DQT(difine quantization table)
① 量化表长度(quantization table length)
② 量化表数目(quantization table number)
③ 量化表(quantization table)
(5) 帧图像开始SOF0(Start of Frame)
① 帧开始长度(start of frame length)
② 精度(precision),每个颜色分量每个像素的位数(bits per pixel per color component)
③ 图像高度(image height)
④ 图像宽度(image width)
⑤ 颜色分量数(number of color components)
⑥ 对每个颜色分量(for each component)
- ID
- 垂直方向的样本因子(vertical sample factor)
- 水平方向的样本因子(horizontal sample factor)
- 量化表号(quantization table#)
(6) 一个或者多个霍夫曼表DHT(Difine Huffman Table)
① 霍夫曼表的长度(Huffman table length)
② 类型、AC或者DC(Type, AC or DC)
③ 索引(Index)
④ 位表(bits table)
⑤ 值表(value table)
(7) 扫描开始SOS(Start of Scan)
① 扫描开始长度(start of scan length)
② 颜色分量数(number of color components)
③ 每个颜色分量
- ID
- 交流系数表号(AC table #)
- 直流系数表号(DC table #)
④ 压缩图像数据(compressed image data)
(8) 图像结束EOI(End of Image)
表6-06表示了APP0域的详细结构。有兴趣的读者可通过UltraEdit或者PC TOOLS等工具软件打开一个JPG图像文件,对APP0的结构进行分析和验证。
表6-06 JFIF格式中APP0域的详细结构
|
偏移 |
长度 |
内容 |
块的名称 |
说明 |
|
0 |
2 byte |
0xFFD8 |
(Start of Image,SOI) |
图像开始 |
|
2 |
2 byte |
0xFFE0 |
APP0(JFIF application segment) |
JFIF应用数据块 |
|
4 |
2 bytes |
length of APP0 block |
APP0块的长度 |
|
|
6 |
5 bytes |
"JFIF"+"0" |
识别APP0标记 |
|
|
11 |
1 byte |
<Major version> |
主要版本号(如版本1.02中的1) |
|
|
12 |
1 byte |
<Minor version> |
次要版本号(如版本1.02中的02) |
|
|
13 |
1 byte |
<Units for the X |
X和Y的密度单位 units=0:无单位 units=1:点数/英寸 units=2:点数/厘米 |
|
|
14 |
2 bytes |
<Xdensity> |
水平方向像素密度 |
|
|
16 |
2 bytes |
<Ydensity> |
垂直方向像素密度 |
|
|
18 |
1 byte |
<Xthumbnail> |
缩略图水平像素数目 |
|
|
19 |
1 byte |
<Ythumbnail> |
缩略图垂直像素数目 |
|
|
3n |
< Thumbnail RGB bitmap> |
缩略RGB位图(n为缩略图的像素数) |
||
|
Optional JFIF extension APP0 marker segment(s) |
任选的JFIF扩展APP0标记段 |
|||
|
…… |
…… |
|||
|
2 byte |
0xFFD9 |
(EOI) end-of-file |
图像文件结束标记 |
JPEG头部解析的更多相关文章
- 重大漏洞!PHP multipart/form-data头部解析远程拒绝服务漏洞
"有些人看不懂,简单比喻来说吧:目前刚出的任何安全防护都不会拦,网站类专属漏洞 畸形数据包,2KB随机数据包,2M网速打死各种网站,cdn通挂!"PHP multipart/for ...
- H265Nalu头部解析
一 NALU头部解析 F: 必须为0,为1表示语法错误.整包将被丢弃 NalType:nalu包的类型,其中VCL NAL和non-VCL NAL各有32类.0-31是vcl nal单元:32-63, ...
- H264Nalu头部解析
一 NALU头部解析 F: forbidden_zero_bit. 在 H.264 规范中规定了这一位必须为 0. NRI: nal_ref_idc. 取00~11,似乎指示这个NALU的重要性,如0 ...
- 音频文件解析(一):WAV格式文件头部解析
WAV为微软公司(Microsoft)开发的一种声音文件格式,它符合RIFF(Resource Interchange File Format)文件规范,用于保存Windows平台的音频信息资源. 文 ...
- [VB.NET][C#]WAV格式文件头部解析
简介 WAV 为微软开发的一种声音文件格式,它符合 RIFF(Resource Interchange File Format)文件规范,用于保存 Windows 平台的音频信息资源. 第一节 文件头 ...
- http 请求头部解析
作者:知乎用户链接:https://www.zhihu.com/question/42696895/answer/109035792来源:知乎著作权归作者所有.商业转载请联系作者获得授权,非商业转载请 ...
- Python - 头部解析
背景 写 python 的时候,基本都要加两个头部注释,这到底有啥用呢? #!usr/bin/env python # -*- coding:utf-8 _*- print("hello-w ...
- HTTP头部解析
当我们打开一个网页时,浏览器要向网站服务器发送一个HTTP请求头,然后网站服务器根据HTTP请求头的内容生成当次请求的内容发送给浏览器.你明白HTTP请求头的具体含意吗?下面一条条的为你详细解读,先看 ...
- PHP模拟发送POST请求之一、HTTP协议头部解析
WEB开发中信息基本全是在POST与GET请求与响应中进行,GET因其基于URL的直观,易被我们了解,可POST请求因其信息的隐蔽,在安全的同时,也给开发者们模拟发送带来了麻烦.接下来的几篇博文中,我 ...
随机推荐
- Python3+Pygame实现的射击游戏,很流畅,有音效
之前看到过很多人写的飞机大战,当然了之前我也写过多个版本,总体来说功能是实现了,但总感觉不够"炫" 今天浏览Python资料的时候,意外发现了这个很好的"射击" ...
- 翻译:《实用的Python编程》06_03_Producers_consumers
目录 | 上一节 (6.2 自定义迭代) | 下一节 (6.4 生成器表达式) 6.3 生产者,消费者和管道 生成器在设置各种生产者/消费者问题(producer/consumer problems) ...
- [源码解析] 并行分布式框架 Celery 之架构 (1)
[源码解析] 并行分布式框架 Celery 之架构 (1) 目录 [源码解析] 并行分布式框架 Celery 之架构 (1) 0x00 摘要 0x01 Celery 简介 1.1 什么是 Celery ...
- Kubernetes 常用日志收集方案
Kubernetes 常用日志收集方案 学习了 Kubernetes 集群中监控系统的搭建,除了对集群的监控报警之外,还有一项运维工作是非常重要的,那就是日志的收集. 介绍 应用程序和系统日志可以帮助 ...
- 批量SSH key-gen无密码登陆认证脚本 附件脚本
# 批量实现SSH无密码登陆认证脚本 ## 问题背景 使用为了让linux之间使用ssh不需要密码,可以采用了数字签名RSA或者DSA来完成.主要使用ssh-key-gen实现. 1.通过 ssh-k ...
- 仿VUE创建响应式数据
VUE对于前端开发人员都非常熟悉了,其工作原理估计也都能说的清个大概,具体代码的实现估计看的人不会太多,这里对vue响应式数据做个简单的实现. 先简单介绍一下VUE数据响应原理,VUE响应数据分为对象 ...
- 13个精选的React JS框架
如果你正在使用 React.js 或 React Native 创建用户界面,可以试一试本文推荐的这些框架. React.js 和 React Native 是流行的用户界面(UI)开发平台,且都是开 ...
- css详解background八大属性及其含义
background(背景) 以前笔者在css盒模型以及如何计算盒子的宽度一文中提到过盒模型可以看成由 元素外边距(margin).元素边框(border).元素内边距(padding)和元素内容(c ...
- OAuth 2.0 单元测试解决方案
为什么需要单元测试 单元测试拥有保证代码质量.尽早发现软件 Bug.简化调试过程.促进变化并简化集成.使流程更灵活等优势.单元测试是针对代码单元的独立测试,核心是"独立",优势来源 ...
- pandas(5):数学统计——描述性统计
Pandas 可以对 Series 与 DataFrame 进行快速的描述性统计,方便快速了解数据的集中趋势和分布差异.源Excel文件descriptive_statistics.xlsx: 一.描 ...