标签：
微处理机中的存放顺序有正序(big endian)和逆序(little endian)之分。正序存放就是高字节存放在前低字节在后，而逆序存放就是低字节在前高字节在后。例如，十六进制数为A02B，正序存放就是A02B， 逆序存放就是2BA0。摩托罗拉(Motorola)公司的微处理器使用正序存放，而英特尔(Intel)公司的微处理器使用逆序。JPEG文件中的字节 是按照正序排列的。
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文件中的第一个图像样本是图像左上角的样本。
JFIF文件格式直接使用JPEG标准为应用程序定义的许多标记，因此JFIF格式成了事实上JPEG文件交换格式标准。JPEG的每个标记都是由 2个字节组成，其前一个字节是固定值0xFF。每个标记之前还可以添加数目不限的0xFF填充字节(fill byte)。下面是其中的8个标记：
为使读者对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)
(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)
③ 每个颜色分量
④ 压缩图像数据(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 |
图像文件结束标记 |
Strictly speaking, JPEG files do not have formal headers, but fg_jpeghead() and fgi_jpeghead() return relevant information from the file‘s start of frame segment. We call it a header for consistency with other image file formats.
| offset
|
size
|
description
|
| 0
|
2
|
JPEG SOI marker (FFD8 hex)
|
| 2
|
2
|
image width in pixels
|
| 4
|
2
|
image height in pixels
|
| 6
|
1
|
number of components (1 = grayscale, 3 = RGB)
|
| 7
|
1
|
horizontal/vertical sampling factors for component 1
|
| 8
|
1
|
sampling factors for component 2 (if RGB)
|
| 9
|
1
|
sampling factors for component 3 (if RGB) |
A JPEG image consists of a sequence of segments, each beginning with a marker, each of which begins with a 0xFF byte followed by a byte indicating what kind of marker it is. Some markers consist of just those two bytes; others are followed by two bytes (high then low) indicating the length of marker-specific payload data that follows. (The length includes the two bytes for the length, but not the two bytes for the marker.) Some markers are followed by entropy-coded data; the length of such a marker does not include the entropy-coded data. Note that consecutive 0xFF bytes are used as fill bytes for padding purposes, although this fill byte padding should only ever take place for markers immediately following entropy-coded scan data (see JPEG specification section B.1.1.2 and E.1.2 for details; specifically "In all cases where markers are appended after the compressed data, optional 0xFF fill bytes may precede the marker").
Within the entropy-coded data, after any 0xFF byte, a 0x00 byte is inserted by the encoder before the next byte, so that there does not appear to be a marker where none is intended, preventing framing errors. Decoders must skip this 0x00 byte. This technique, called byte stuffing (see JPEG specification section F.1.2.3), is only applied to the entropy-coded data, not to marker payload data. Note however that entropy-coded data has a few markers of its own; specifically the Reset markers (0xD0 through 0xD7), which are used to isolate independent chunks of entropy-coded data to allow parallel decoding, and encoders are free to insert these Reset markers at regular intervals (although not all encoders do this).
| Short name | Bytes | Payload | Name | Comments |
|---|---|---|---|---|
| SOI | 0xFF, 0xD8 | none | Start Of Image | |
| SOF0 | 0xFF, 0xC0 | variable size | Start Of Frame (baseline DCT) | Indicates that this is a baseline DCT-based JPEG, and specifies the width, height, number of components, and component subsampling (e.g., 4:2:0). |
| SOF2 | 0xFF, 0xC2 | variable size | Start Of Frame (progressive DCT) | Indicates that this is a progressive DCT-based JPEG, and specifies the width, height, number of components, and component subsampling (e.g., 4:2:0). |
| DHT | 0xFF, 0xC4 | variable size | Define Huffman Table(s) | Specifies one or more Huffman tables. |
| DQT | 0xFF, 0xDB | variable size | Define Quantization Table(s) | Specifies one or more quantization tables. |
| DRI | 0xFF, 0xDD | 4 bytes | Define Restart Interval | Specifies the interval between RSTn markers, in macroblocks. This marker is followed by two bytes indicating the fixed size so it can be treated like any other variable size segment. |
| SOS | 0xFF, 0xDA | variable size | Start Of Scan | Begins a top-to-bottom scan of the image. In baseline DCT JPEG images, there is generally a single scan. Progressive DCT JPEG images usually contain multiple scans. This marker specifies which slice of data it will contain, and is immediately followed by entropy-coded data. |
| RSTn | 0xFF, 0xDn (n=0..7) | none | Restart | Inserted every r macroblocks, where r is the restart interval set by a DRI marker. Not used if there was no DRI marker. The low three bits of the marker code cycle in value from 0 to 7. |
| APPn | 0xFF, 0xEn | variable size | Application-specific | For example, an Exif JPEG file uses an APP1 marker to store metadata, laid out in a structure based closely on TIFF. |
| COM | 0xFF, 0xFE | variable size | Comment | Contains a text comment. |
| EOI | 0xFF, 0xD9 | none | End Of Image |
There are other Start Of Frame markers that introduce other kinds of JPEG encodings.
Since several vendors might use the same APPn marker type, application-specific markers often begin with a standard or vendor name (e.g., "Exif" or "Adobe") or some other identifying string.
At a restart marker, block-to-block predictor variables are reset, and the bitstream is synchronized to a byte boundary. Restart markers provide means for recovery after bitstream error, such as transmission over an unreliable network or file corruption. Since the runs of macroblocks between restart markers may be independently decoded, these runs may be decoded in parallel.
标签：
原文地址：http://www.cnblogs.com/sddai/p/5666747.html
