图片格式介绍：BMP,jpeg,png,gif......

工作中用到图片，故将格式搜集整理在这里，以备以后使用时查看。。。

参考：

     

图片格式有很多中这类暂时只整理几种常见的格式：bmp,jpeg,png,gif...

一、bmp图像格式 ：

BMP是一种与硬件设备无关(在windows3.0后是设备无关位图格式DDB；在windows3.0之前是设备相关位图格式DIB；)的图像文件格式，使用非常广。它采用位映射存储格式，除了图像深度可选以外，不采用其他任何压缩，因此，BMP文件所占用的空间很大。BMP文件的图像深度可选lbit、4bit、8bit及24bit。BMP文件存储数据时，图像的扫描方式是按从左到右、从下到上的顺序。BMP文件格式是Windows环境中交换与图有关的数据的一种标准，因此在Windows环境中运行的图形图像软件都支持BMP图像格式。

BMP 是 Windows 位图可以用任何颜色深度（从黑白到 24 位颜色）存储单个光栅图像。Windows 位图文件格式与其他 Microsoft Windows 程序兼容。它不支持文件压缩，由于BMP文件所占用的空间很大故不适用于 Web 页。

优点：BMP 支持 1 位到 24 位颜色深度。BMP 格式与现有 Windows 程序（尤其是较旧的程序）广泛兼容。在嵌入式中可以不用转换而直接写显存，避免了转换的时间，但占用了较大的存储空间。

缺点： BMP 不支持压缩，这会造成文件非常大，占用存储空间。

典型的BMP图像文件由四部分组成：

1：bitmap file header 位图头文件数据结构，它包含BMP图像文件的类型、显示内容等信息；

2：bitmap infomation header 位图信息数据结构，它包含有BMP图像的宽、高、压缩方法，以及定义颜色等信息；

3：color table 调色板，这个部分是可选的，有些位图需要调色板，有些位图，比如真彩色图（24位的BMP）就不需要调色板；

4：位图数据阵列，这部分的内容根据BMP位图使用的位数不同而不同，在24位图中直接使用3byte的RGB，而其他的小于24位的使用调色板中颜色索引值。

具体格式如下：

下面是一中bmp格式图片的16进制显示：

那么文件头及位图信息有0x36 Bytes 组成，即是地址 0x0000--0x0035的数据；

<1>、bitmap file heade-位图头信息：偏移量：0x0000，长度：27bytes

0x0000--0x0001: 42 4d 文件标识 这里指示是文件格式为：BM

两字节的内容用来识别位图的类型：

                'BM' ： Windows 3.1x, 95, NT, ...

                'BA' ：OS/2 Bitmap Array

                'CI' ：OS/2 Color Icon

                'CP' ：OS/2 Color Pointer

                'IC' ： OS/2 Icon

                'PT' ：OS/2 Pointer

                注：因为OS/2系统并没有被普及开，所以在编程时，你只需判断第一个标识"BM"就行。

0x0002--0x0005: 56 ca 00 00 文件长度 用字节表示的整个文件的大小，这里的文件的16进制的长度是0x00 00 ca 56 BYTES的长度（51798字节长度）；(高字节在后)

0x0006--0x0009: Reserved

0x000A--0x000D: 36 00 00 00 : Bitmap Data Offset 位图数据(bitmap data)的偏移量 这里是 0x36;(高字节在后)

<2>、bitmap information heade-位图信息头：偏移量：0x000E，长度由0x0e--0x11 的信息指定；这里是0x28,所以bitmap data 阵列从 0x28 + 0x0e = 0x36 开始；

0x000e--0x0011: 28 00 00 00 : bitmap header size 位图信息头(Bitmap Info Header)的长度，用来描述位图的颜色、压缩方法等。下面的长度表示：

                28h - Windows 3.1x, 95, NT, ...

                0Ch - OS/2 1.x

                F0h - OS/2 2.x

                注：在Windows95、98、2000等操作系统中，位图信息头的长度并不一定是28h，因为微软已经制定出了新的BMP文件格式，其中的信息头结构变化比较大，长度加长。所以最好不要直接使用常数28h，而是应该从具体的文件中读取这个值。这样才能确保程序的兼容性。

0x0012--0x0015: B0 00 00 00 width 位图的宽度，以象素为单位; 这里是：0x00 00 00 b0 = 176

0x0016--0x0019: 62 00 00 00 height 位图的高度，以象素为单位; 这里是：0x00 00 00 62 = 98 ； 故而此bitmap的分辨率是：176 x 98;

0x001a--0x001b: 01 00 planes 位图的位面数（注：BMP的该值将总是1）

0x001c--0x001d: 18 00 bits per pixel 每个象素的位数 这里是 0x18 = 24 bits per pixel,

                1 - 单色位图（实际上可有两种颜色，缺省情况下是黑色和白色。你可以自己定义这两种颜色）

                4 - 16 色位图

                8 - 256 色位图

                16 - 16bit 高彩色位图 ；每个pixel 占用 2bytes 数据 16bit(R5G6B5)；

                24 - 24bit 真彩色位图 ；每个pixel 占用 3bytes 数据 RGB；

                32 - 32bit 增强型真彩色位图；每个pixel 占用 4bytes 数据 xRGB；

0x001e--0x0021: 00 00 00 00 compression 压缩说明：

                0 - 不压缩 (使用BI_RGB表示)

                1 - RLE 8-使用8位RLE压缩方式(用BI_RLE8表示)

                2 - RLE 4-使用4位RLE压缩方式(用BI_RLE4表示)

                3 - Bitfields-位域存放方式(用BI_BITFIELDS表示)

0x0022--0x0025: 20 ca 00 00 bitmap data size 用字节数表示的位图数据的大小。比如是24bpp的：那么就是 分辨率*3 bytes；16bpp(每个像素2bytes)是 分辨率* 2bytes；

0x0026--0x0029: H resolution 用象素/米表示的水平分辨率 ； 这里是无效值

0x002a--0x002d: V resolution 用象素/米表示的垂直分辨率 ； 这里是无效值

0x002e--0x0031: colors 位图使用的颜色数。如8-比特/象素表示为100h或者 256；24bpp的真彩色这里的值无效值；

0x0032--0x00xxxx: impartant colors 指定重要的颜色数。当该域的值等于颜色数时（或者等于0时），表示所有颜色都一样重要；（此处的终止长度由"0x000e--0x0011: bitmap header size 的数值来决定的，这里是0x28 那么这里的结束的值是0x0036;" ）

0x00xxxx--0x00xxxx: palette : 调色板 这个由"0x000A--0x000D: Bitmap Data Offset"和"0x000e--0x0011: bitmap header size" 的数值公头决定； Bitmap Data Offset 减去 bitmap header size得出此处的长度，偏移量由bitmap header size 决定；这里是24bbpp的真彩色，所以没有此处数据；

0x00xxxx-- end of file: bitmap data : 真正的像素的数据（0x0002--0x0005：File Size 减去 0x000A--0x000D：Bitmap Data Offset 得出的数据），这里是24bpp，故这个数据的长度是 分辨率 * 3bytes；如果是 16bpp 则是：分辨率 * 2bytes；

参考：http://blog.csdn.net/carson2005/article/details/6227047

下面是网上的一个对BMP文件处理的例子，下面的内容来自上面这个链接：

(1)文件信息头BITMAPFILEHEADER

结构体定义如下： （这里UINT 是16bit；DWORD 是32bit）

typedef struct tagBITMAPFILEHEADER {        /* bmfh */

UINT bfType; 
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;

} BITMAPFILEHEADER;

其中：

bfType：说明文件的类型，该值必需是0x4D42（十六进制ASCII码4D代表“B”，42代表“M”），也就是字符'BM'。

bfSize 说明该位图文件的大小，用字节为单位

bfReserved1 保留，必须设置为0

bfReserved2 保留，必须设置为0

bfOffBits 说明从文件头开始到实际的图象数据之间的字节的偏移量。这个参数是非常有用的，因为位图信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。

(2)位图信息头BITMAPINFOHEADER

结构体定义如下：

typedef struct tagBITMAPINFOHEADER { /* bmih */

DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;

} BITMAPINFOHEADER;

其中：

biSize 说明BITMAPINFOHEADER结构所需要的字数。

biWidth 说明图象的宽度，以象素为单位。

biHeight 说明图象的高度，以象素为单位。注：这个值除了用于描述图像的高度之外，它还有另一个用处，就是指明该图像是倒向的位图，还是正向的位图。如果该值是一个正数，说明图像是倒向的，如果该值是一个负数，则说明图像是正向的。大多数的BMP文件都是倒向的位图，也就是说，高度值是一个正数。

biPlanes 为目标设备说明位面数，其值将总是被设为1。

biBitCount 说明比特数/象素，其值为1、4、8、16、24、或32。我们平时用到的图像绝大部分是24位和32位的

biCompression 说明图象数据压缩的类型，同样我们只讨论没有压缩的类型：BI_RGB。

biSizeImage 说明图象的大小，以字节为单位。当用BI_RGB格式时，可设置为0。

biXPelsPerMeter 说明水平分辨率，用象素/米表示。

biYPelsPerMeter 说明垂直分辨率，用象素/米表示。

biClrUsed 说明位图实际使用的彩色表中的颜色索引数（设为0的话，则说明使用所有调色板项）。

biClrImportant 说明对图象显示有重要影响的颜色索引的数目，如果是0，表示都重要。

------------------------------------------------

bitmap data 说明：

对于 biBitCount  = 1,4,8 时 一般是使用 调色板(palette)的，bitmap data 一般是调色板的序号，这类暂时不做详细介绍。《《《《《《《《》》》》》》》》》

对于 biBitCount  = 16， 24，32时，一般针对的是真彩色的bitmap data，是不用调色板的。

biBitCount  = 16 ：表示位图最多有65536种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或64K色。它的情况比较复杂，当 biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量，中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555-16位位图。如果biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（还要再经过适当的左右移操作）。在NT系统中，则没有格式限制，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于嵌入式系统中）。

biBitCount=24：    表示位图最多有2的24次方，大约1670万种颜色。我们称之为真彩色，这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个象素，分别对应于颜色R、G、B，故而bitmap data的长度是3 的倍数的字节(byte)数。

biBitCount=32 ：表示位图最多有2的32次方种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板，32位中有24位用于存放RGB值，顺序是：最高一个字节保留，红8位、绿8位、蓝8位。这种格式也被成为888--32位图，这里最高字节 通常为透明通道，该值是该像素点的透明属性，取值在0（全透明）------255（不透明）之间。对于24位的图像来说，因为没有Alpha通道，故整个图像都不透明。     如果 biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows95(or 98)中，系统只接受888格式，也就是说三个掩码的值将只能是：0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD（4字节）对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单）），那么他的 bitmap data 的长度是4 的倍数的字节(byte)数。 
===============================================

下面这段没有明白，怎么会不对其呢？先放在这里

BMP图像数据区在读取时，位图数据的偏移量为sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER)。由于Windows在进行行扫描的时候最小的单位为4个字节，所以当 　　图片宽 X 每个像素的字节数 ！= 4的整数倍 　　时要在每行的后面补上缺少的字节，以0填充（一般来说当图像宽度为2的幂时不需要对齐）。位图文件里的数据在写入的时候已经进行了行对齐，也就是说加载的时候不需要再做行对齐。但是这样一来图片数据的长度就不是：宽 X 高 X 每个像素的字节数 了，我们需要通过下面的方法计算正确的数据长度： 　　//Calculate the image data size 　　int iLineByteCnt = (((m_iImageWidth*m_iBitsPerPixel) + 31) >> 5) << 2; 　　

m_iImageDataSize = iLineByteCnt * m_iImageHeight;

==============================================================

一、jpeg图像格式 ：

这里有很详细的介绍：http://blog.csdn.net/bluesky_sunshine/article/details/6182682

                  

                   http://www.blogjava.net/wilsonny/archive/2005/07/01/7000.aspx

对于jpeg是格式是一种有损压缩，和bmp的无损数据相比较，图片的数据会有损失，而且这种损失是累加的。

********************************************************************

下面的内容来自：http://blog.csdn.net/bluesky_sunshine/article/details/6182682

JPEG格式
格式：JFIF(JPEG档的交换格式)
压缩：JPEG(灰阶影像压缩比约为10:1；彩色影像约为20:1)
以JPEG文件格式保存的图像实际上是2个不同格式的混合物：JPEG格式规范本身，用来定义图像的压缩方法，并且被包在定议分辨率和颜色模式的图像数据格式之中。Photoshop和实际上每个能读取和写入JPEG文件格式的其他应用程序，以 JFIF文件格式(JPEG文件交换格式， JPEG File Interchonge Format）或与JFIF格式非常象的其他格式保存图像数据。JFIF文件格式只是将一种图像格或环绕JPEG压缩的一种简单方法，它们没有其他的更多功能。
最初的JFIF文件格式规范史允许8位灰度图像和24位RGB图像；但是Adobe『修改」了此种格式，使之也能处理32位CMYK模式的数据。但是，多数版面设计应用程序实际上不能将 CMYK模式的JPEG图像分离开，所以 Adobe所做的这个修改的意义并不大。JPEG文件格式允许用可变压缩的方法，保存8位、24位、32位深度的图像。例如，当以JPEG格式保存一幅 Photoshop图像时，Photoshop给出了多种保存选项：低压缩率，中等压缩率，高压缩率及最好的分辨率等级别。实验证明，当进行印刷或在显示器上观察时，JPEG一般可将图像压缩为原大小的十分之一而看不出明显差异。图像会分解成8×8像素图像单元的小方块。这种JPEG失真有时会在新闻图片中发现，这些图片在进行电子传输前被大大地压缩了，随後又以高放大倍率进行了印刷。
JPEG使用了有损压缩格式，这就使它成为迅速显示图像并保存较好分辨率的理想格式。也正是由於JPEG格式可以对扫描或自然图像进行大幅度的压缩，利於储存或通过调制解调器进行传送，所以在Internet上得到了广泛的应用。
JPEG格式有一个特殊的变种，名为 「Progressive JPEG」。在创建Progressive JPEG 文件肘，数据是这样安排的：在装入图像时，开始只显示一个模糊的图像，随着数据的装入，图像逐步变得清晰。
JPEG格式的主要不足之处也正是它的最大优点。也就是说，有损压缩算法将JPEG只局限於显示格式，而且每次保存JPEG格式的图像时都会丢失一些数据。因此，通常只在创作的最後阶段以JPEG格式保存一次图像即可。

JPEG简介
微处理机中的存放顺序有正序(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.299R + 0.587G + 0.114 B
　　 　    Cb = - 0.1687R - 0.3313G + 0.5B + 128
　　　    Cr =    0.5R - 0.4187G - 0.0813B + 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个标记：
1.        SOI　 0xD8　　　　　　　　　　　图像开始
2.        APP0 0xE0　　　　　　　　　　　JFIF应用资料块
3.        APPn 0xE1 - 0xEF　　　        其他的应用资料块(n, 1～15)
4.        DQT　 0xDB　　　　　　　　　　　量化表
5.        SOF0 0xC0　　　　　　　　　　　帧开始
6.        DHT　 0xC4　　　　　　　　　　　霍夫曼(Huffman)表
7.        SOS　 0xDA　　　　　　　　　　　扫描线开始
8.        EOI　 0xD9　　　　　　　　　　　图像结束
爲使读者对JPEG定义的标记一目了然，现将JPEG的标记码列於表6-05，并保留英文解释。
表6-05 JPEG定义的标记
Symbol
(符号)        Code Assignment
(标记代码)        Deforbiddenion
(说明)
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)
o        ID
o        垂直方向的样本因数(vertical sample factor)
o        水平方向的样本因数(horizontal sample factor)
o        量化表号(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)
③ 每个顔色分量
o        ID
o        交流系数表号(AC table #)
o        直流系数表号(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        　                主要版本号(如版本1.02中的1)
12        1 byte        　                次要版本号(如版本1.02中的02)
13        1 byte        　         and Y densities>        X和Y的密度单位
units=0：无单位
units=1：点数/英寸
units=2：点数/厘米
14        2 bytes        　                水平方向图元密度
16        2 bytes        　                垂直方向图元密度
18        1 byte        　                缩略图水平图元数目
19        1 byte        　                缩略图垂直图元数目
　        3n        　        < Thumbnail RGB bitmap>        缩略RGB点阵图(n爲缩略图的图元数)
　        　        　        Optional JFIF extension APP0 marker segment(s)        任选的JFIF扩展APP0标记段
　        ……        　        ……        　
　        2 byte        0xFFD9        (EOI) end-of-file        图像文件结束标记

////////////////////////////////////////////////////

 

jpg格式分析

偏移	长度	内容	块的名称	说明
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			主要版本号(如版本1.02中的1)
12	1 byte			次要版本号(如版本1.02中的02)
13	1 byte		and Y densities>	X和Y的密度单位 units=0：无单位 units=1：点数/英寸 units=2：点数/厘米
14	2 bytes			水平方向像素密度
16	2 bytes			垂直方向像素密度
18	1 byte			缩略图水平像素数目
19	1 byte			缩略图垂直像素数目
	3n		< Thumbnail RGB bitmap>	缩略RGB位图(n为缩略图的像素数)
			Optional JFIF extension APP0 marker segment(s)	任选的JFIF扩展APP0标记段
	……		……
	2 byte	0xFFD9	(EOI) end-of-file	图像文件结束标记

 

下表表示了APP0域的详细结构。有兴趣可通过UltraEdit或者PC TOOLS等工具软件打开一个JPG图像文件，对APP0的结构进行分析和验证。

********************************************************************

下面内容来自：

JPEG文件格式介绍

　　JPEG文件使用的数据存储方式有多种。最常用的格式称为JPEG文件交换格式（JPEG File Inter

　　change Format，JFIF）。而JPEG文件大体上可以分成两个部分：标记码(Tag)和压缩数据。

　　标记码由两个字节构成，其前一个字节是固定值0xFF，后一个字节则根据不同意义有不同数

　　值。在每个标记码之前还可以添加数目不限的无意义的0xFF填充，也就说连续的多个0xFF可以被

　　理解为一个0xFF，并表示一个标记码的开始。而在一个完整的两字节的标记码后，就是该标记码

　　对应的压缩数据流，记录了关于文件的诸种信息。

　　整个文件的大体结构

　　JFIF格式的JPEG文件(*.jpg)的一般顺序为：

　　SOI(0xFFD8)

　　APP0(0xFFE0)

　　[APPn(0xFFEn)]可选

　　DQT(0xFFDB)

　　SOF0(0xFFC0)

　　DHT(0xFFC4)

　　SOS(0xFFDA)

　　压缩数据

　　EOI(0xFFD9)

　　常用的标记有SOI、APP0、DQT、SOF0、DHT、DRI、SOS、EOI。

　　注意，SOI等都是标记的名称。在文件中，标记码是以标记代码形式出现。例如SOI的标记代

　　码为0xFFD8，即在JPEG文件中的如果出现数据0xFFD8，则表示此处为一个SOI标记。

　　本文附录列出一张完整的JPEG定义的标记表，供读者查阅。这里仅列出几个常用标记的标记

　　代码、占用字节长度和表示的意义。

　　SOI，Start of Image，图像开始

　　标记代码 2字节 固定值0xFFD8

　　APP0，Application，应用程序保留标记0

　　标记代码 2字节 固定值0xFFE0

　　包含9个具体字段：

　　① 数据长度 2字节 ①~⑨9个字段的总长度

　　即不包括标记代码，但包括本字段

　　② 标识符 5字节 固定值0x4A46494600，即字符串“JFIF0”

　　③ 版本号 2字节 一般是0x0102，表示JFIF的版本号1.2

　　可能会有其他数值代表其他版本

　　④ X和Y的密度单位 1字节 只有三个值可选

　　0：无单位；1：点数/英寸；2：点数/厘米

　　⑤ X方向像素密度 2字节 取值范围未知

　　⑥ Y方向像素密度 2字节 取值范围未知

　　⑦ 缩略图水平像素数目 1字节 取值范围未知

　　⑧ 缩略图垂直像素数目 1字节 取值范围未知

　　⑨ 缩略图RGB位图 长度可能是3的倍数 缩略图RGB位图数据

　　本标记段可以包含图像的一个微缩版本，存为24位的RGB像素。如果没有微缩图像（这

　　种情况更常见），则字段⑦“缩略图水平像素数目”和字段⑧“缩略图垂直像素数目”的值均为

　　0。

　　APPn，Application，应用程序保留标记n，其中n=1～15(任选)

　　标记代码 2字节 固定值0xFFE1~0xFFF

　　包含2个具体字段：

　　① 数据长度 2字节 ①~②2个字段的总长度

　　即不包括标记代码，但包括本字段

　　② 详细信息 数据长度-2字节 内容不定

　　例如，Adobe Photoshop生成的JPEG图像中就用了APP1和APP13两个标记段分别存储

　　了一幅图像的副本。

　　DQT，Define Quantization Table，定义量化表

　　标记代码 2字节 固定值0xFFDB

　　包含9个具体字段：

　　① 数据长度 2字节 字段①和多个字段②的总长度

　　即不包括标记代码，但包括本字段② 量化表 数据长度-2字节

　　a) 精度及量化表ID 1字节 高4位：精度，只有两个可选值

　　0：8位；1：16位

　　低4位：量化表ID，取值范围为0～3

　　b) 表项 (64×(精度+1))字节 例如8位精度的量化表

　　其表项长度为64×（0+1）=64字节

　　本标记段中，字段②可以重复出现，表示多个量化表，但最多只能出现4次。

　　SOF0，Start of Frame，帧图像开始

　　标记代码 2字节 固定值0xFFC0

　　包含9个具体字段：

　　① 数据长度 2字节 ①~⑥六个字段的总长度

　　即不包括标记代码，但包括本字段

　　② 精度 1字节 每个数据样本的位数

　　通常是8位，一般软件都不支持 12位和16位

　　③ 图像高度 2字节 图像高度（单位：像素），如果不支持 DNL 就必须 >0

　　④ 图像宽度 2字节 图像宽度（单位：像素），如果不支持 DNL 就必须 >0

　　⑤ 颜色分量数 1字节 只有3个数值可选

　　1：灰度图；3：YCrCb或YIQ；4：CMYK

　　而JFIF中使用YCrCb，故这里颜色分量数恒为3

　　⑥颜色分量信息 颜色分量数×3字节（通常为9字节）

　　a) 颜色分量ID 1字节

　　b) 水平/垂直采样因子 1字节 高4位：水平采样因子

　　低4位：垂直采样因子

　　（曾经看到某资料把这两者调转了）

　　c) 量化表 1字节 当前分量使用的量化表的ID

　　本标记段中，字段⑥应该重复出现，有多少个颜色分量（字段⑤），就出现多少次（一

　　般为3次）。

　　DHT，Difine Huffman Table，定义哈夫曼表

　　标记代码 2字节 固定值0xFFC4

　　包含2个具体字段：

　　①数据长度 2字节 字段①和多个字段②的总长度

　　即不包括标记代码，但包括本字段

　　② 哈夫曼表 数据长度-2字节

　　a) 表ID和表类型 1字节 高4位：类型，只有两个值可选

　　0：DC直流；1：AC交流

　　低4位：哈夫曼表ID，

　　注意，DC表和AC表分开编码

　　b) 不同位数的码字数量 16字节

　　c) 编码内容 16个不同位数的码字数量之和（字节）

　　本标记段中，字段②可以重复出现（一般4次），也可以致出现1次。例如，Adobe Phot

　　oshop 生成的JPEG图片文件中只有1个DHT标记段，里边包含了4个哈夫曼表；而Macromedi

　　a Fireworks生成的JPEG图片文件则有4个DHT标记段，每个DHT标记段只有一个哈夫曼表。

　　DRI，Define Restart Interval，定义差分编码累计复位的间隔

　　标记代码 2字节 固定值0xFFDD

　　包含2个具体字段：

　　①数据长度 2字节 固定值0x0004，①~②两个字段的总长度。即不包括标记代码，但包括本字段

　　②MCU块的单元中的重新开始间隔

　　2字节 设其值为n，则表示每n个MCU块就有一个

　　RSTn标记。第一个标记是RST0，第二个是

　　RST1等，RST7后再从RST0重复。

　　如果没有本标记段，或间隔值为0时，就表示不存在重开始间隔和标记RST

　　SOS，Start of Scan，扫描开始 12字节

　　标记代码 2字节 固定值0xFFDA

　　包含2个具体字段：

　　①数据长度 2字节 ①~④两个字段的总长度

　　即不包括标记代码，但包括本字段

　　②颜色分量数 1字节 应该和SOF中的字段⑤的值相同，即：

　　1：灰度图是；3： YCrCb或YIQ；4：CMYK。

　　而JFIF中使用YCrCb，故这里颜色分量数恒为3

　　③颜色分量信息

　　a) 颜色分量ID 1字节

　　b) 直流/交流系数表号 1字节 高4位：直流分量使用的哈夫曼树编号

　　低4位：交流分量使用的哈夫曼树编号

　　④ 压缩图像数据

　　a)谱选择开始 1字节 固定值0x00

　　b)谱选择结束 1字节 固定值0x3F

　　c)谱选择 1字节 在基本JPEG中总为00

　　本标记段中，字段③应该重复出现，有多少个颜色分量（字段②），就出现多少次（一

　　般为3次）。本段结束后，紧接着就是真正的图像信息了。图像信息直至遇到一个标记代码

　　就自动结束，一般就是以EOI标记表示结束。

　　EOI，End of Image，图像结束 2字节

　　标记代码 2字节 固定值0xFFD9

　　这里补充说明一下，由于在JPEG文件中0xFF具有标志性的意思，所以在压缩数据流(真正

　　的图像信息)中出现0xFF，就需要作特别处理。具体方法是，在数据0xFF后添加一个没有意义

　　的0x00。换句话说，如果在图像数据流中遇到0xFF，应该检测其紧接着的字符，如果是

　　1）0x00，则表示0xFF是图像流的组成部分，需要进行译码；

　　2）0xD9，则与0xFF组成标记EOI，则图像流结束，同时图像文件结束；

　　3）0xD0~0xD7,则组成RSTn标记，则要忽视整个RSTn标记，即不对当前0xFF和紧接的0xDn两

　　个字节进行译码，并按RST标记的规则调整译码变量；

　　3）0xFF，则忽视当前0xFF，对后一个0xFF再作判断；

　　4）其他数值，则忽视当前0xFF，并保留紧接的此数值用于译码

********************************************************************

 

++++++++++++++++++++++++++++++++++++++++++++++++

未完，待续。。。。。。