S
smallbee
Unregistered / Unconfirmed
GUEST, unregistred user!
如上，求购jpeg和bmp的图像格式。
（即一个jpeg或者bmp文件的内部格式－－文件头、压缩比之类……）
（即一个jpeg或者bmp文件的内部格式－－文件头、压缩比之类……）
您正在使用一款已经过时的浏览器！部分功能不能正常使用。
请尝试升级或使用 其他浏览器。
请尝试升级或使用 其他浏览器。
D
duducat
Unregistered / Unconfirmed
GUEST, unregistred user!
我有啦……先给分吧！
http://www.delphibbs.com/delphibbs/dispq.asp?lid=1677564
本人曾经花了很长时间研究了大量的编码和解码算法
以及各种经典的和非经典的加密解密算法（数字签名等），总共加起来有50多种
并拥有其C++和Delphi版本的源代码（90%自写或改良）,
有意者跟我联系！！！
http://www.delphibbs.com/delphibbs/dispq.asp?lid=1677564
本人曾经花了很长时间研究了大量的编码和解码算法
以及各种经典的和非经典的加密解密算法（数字签名等），总共加起来有50多种
并拥有其C++和Delphi版本的源代码（90%自写或改良）,
有意者跟我联系！！！
惨
惨不忍睹
Unregistered / Unconfirmed
GUEST, unregistred user!
看这个网站对你有没有用
http://www.csdn.net/Dev/Format/
http://www.csdn.net/Dev/Format/
峻
峻祁连
Unregistered / Unconfirmed
GUEST, unregistred user!
http://www.gischina.com
里面的“文件格式”里有关于栅格图的，包括bmp
里面的“文件格式”里有关于栅格图的，包括bmp
S
smallbee
Unregistered / Unconfirmed
GUEST, unregistred user!
duducat,
你好，我地分数肯定是送人地。
这次出400分就是为了请高手相助！
如果你能将jpeg和bmp的格式和转化源代码给我。
我必将400分双手奉上！绝不食言。
小bee 我的email：smallbee@std.uestc.edu.cn
你好，我地分数肯定是送人地。
这次出400分就是为了请高手相助！
如果你能将jpeg和bmp的格式和转化源代码给我。
我必将400分双手奉上！绝不食言。
小bee 我的email：smallbee@std.uestc.edu.cn
H
heipi2003
Unregistered / Unconfirmed
GUEST, unregistred user!
好象是由WINOWS完成的，反正是由JPEG单元定义过的，费劲干什么？
procedure Jpg2Bmp(JpgFile, BmpFile: String);
//將Jpg文件轉換為Bmp文件
var
MyJPEG : TJPEGImage;
MyBMP : TBitmap;
begin
MyJPEG := TJPEGImage.Create;
with MyJPEG do
try
LoadFromFile(JpgFile); //妳的圖片位置
MyBMP := TBitmap.Create;
with MyBMP do
begin
Assign(MyJPEG);
SaveToFile(BmpFile);//保存路徑
Free;
end;
finally
Free;
end;
end;
procedure Bmp2Jpg(BmpName, JpgName: String);
//將bmp文件轉換為jpg文件
var
MyJPEG : TJPEGImage;
MyBMP : TBitmap;
begin
MyBMP := TBitmap.Create;
with MyBMP do
try
LoadFromFile(BmpName); //妳的圖片位置
MyJPEG := TJPEGImage.Create;
with MyJPEG do
begin
Assign(MyBMP);
CompressionQuality:=60; //壓縮比例 1..100
Compress;
SaveToFile(JpgName);//保存路徑
Free;
end;
finally
Free;
end;
end;
procedure Jpg2Bmp(JpgFile, BmpFile: String);
//將Jpg文件轉換為Bmp文件
var
MyJPEG : TJPEGImage;
MyBMP : TBitmap;
begin
MyJPEG := TJPEGImage.Create;
with MyJPEG do
try
LoadFromFile(JpgFile); //妳的圖片位置
MyBMP := TBitmap.Create;
with MyBMP do
begin
Assign(MyJPEG);
SaveToFile(BmpFile);//保存路徑
Free;
end;
finally
Free;
end;
end;
procedure Bmp2Jpg(BmpName, JpgName: String);
//將bmp文件轉換為jpg文件
var
MyJPEG : TJPEGImage;
MyBMP : TBitmap;
begin
MyBMP := TBitmap.Create;
with MyBMP do
try
LoadFromFile(BmpName); //妳的圖片位置
MyJPEG := TJPEGImage.Create;
with MyJPEG do
begin
Assign(MyBMP);
CompressionQuality:=60; //壓縮比例 1..100
Compress;
SaveToFile(JpgName);//保存路徑
Free;
end;
finally
Free;
end;
end;
D
duducat
Unregistered / Unconfirmed
GUEST, unregistred user!
jpeg和bmp的图像格式与上面的代码有关嘛？……
另外，不好意思
不知道楼主到底是求一个过程，还是一个结果！？
如果是一个结果的话，……恭喜你已经找到答案了！：P
…………
另外，不好意思
不知道楼主到底是求一个过程，还是一个结果！？
如果是一个结果的话，……恭喜你已经找到答案了！：P
…………
H
huazai
Unregistered / Unconfirmed
GUEST, unregistred user!
bmp的格式：
BMP文件格式分析
本来不想写这篇东西，因为介绍BMP文件结构的资料太多了，都有些滥了。但刚写完BMP的读写模块，又不想不留下点什么，所以就写了，全当是学习笔记吧。自己以后查资料时也方便一些，也许对某些初哥还会有点用^_^
注：本文参考了林福宗老师的有关BMP文件格式的文章，在此声明。
简介
BMP(Bitmap-File)图形文件是Windows采用的图形文件格式，在Windows环境下运行的所有图象处理软件都支持BMP图象文件格式。Windows系统内部各图像绘制操作都是以BMP为基础的。Windows 3.0以前的BMP图文件格式与显示设备有关，因此把这种BMP图象文件格式称为设备相关位图DDB(device-dependent bitmap)文件格式。Windows 3.0以后的BMP图象文件与显示设备无关，因此把这种BMP图象文件格式称为设备无关位图DIB(device-independent bitmap)格式（注：Windows 3.0以后，在系统中仍然存在DDB位图，象BitBlt()这种函数就是基于DDB位图的，只不过如果你想将图像以BMP格式保存到磁盘文件中时，微软极力推荐你以DIB格式保存），目的是为了让Windows能够在任何类型的显示设备上显示所存储的图象。BMP位图文件默认的文件扩展名是BMP或者bmp（有时它也会以.DIB或.RLE作扩展名）。
6.1.2 文件结构
位图文件可看成由4个部分组成：位图文件头(bitmap-file header)、位图信息头(bitmap-information header)、彩色表(color table)和定义位图的字节阵列，它具有如下所示的形式。
位图文件的组成
结构名称
符号
位图文件头(bitmap-file header) BITMAPFILEHEADER bmfh
位图信息头(bitmap-information header) BITMAPINFOHEADER bmih
彩色表(color table) RGBQUAD aColors[]
图象数据阵列字节 BYTE aBitmapBits[]
位图文件结构可综合在表6-01中。
表01 位图文件结构内容摘要
偏移量
域的名称
大小
内容
图象文件
头
0000h 文件标识 2 bytes 两字节的内容用来识别位图的类型：
‘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”就行。
0002h File Size 1 dword 用字节表示的整个文件的大小
0006h Reserved 1 dword 保留，必须设置为0
000Ah Bitmap Data Offset 1 dword 从文件开始到位图数据开始之间的数据(bitmap data)之间的偏移量
000Eh Bitmap Header Size 1 dword 位图信息头(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，而是应该从具体的文件中读取这个值。这样才能确保程序的兼容性。
0012h Width 1 dword 位图的宽度，以象素为单位
0016h Height 1 dword 位图的高度，以象素为单位
001Ah Planes 1 word 位图的位面数（注：该值将总是1）
图象
信息
头
001Ch Bits Per Pixel 1 word 每个象素的位数
1 - 单色位图（实际上可有两种颜色，缺省情况下是黑色和白色。你可以自己定义这两种颜色）
4 - 16 色位图
8 - 256 色位图
16 - 16bit 高彩色位图
24 - 24bit 真彩色位图
32 - 32bit 增强型真彩色位图
001Eh Compression 1 dword 压缩说明：
0 - 不压缩 (使用BI_RGB表示)
1 - RLE 8-使用8位RLE压缩方式(用BI_RLE8表示)
2 - RLE 4-使用4位RLE压缩方式(用BI_RLE4表示)
3 - Bitfields-位域存放方式(用BI_BITFIELDS表示)
0022h Bitmap Data Size 1 dword 用字节数表示的位图数据的大小。该数必须是4的倍数
0026h HResolution 1 dword 用象素/米表示的水平分辨率
002Ah VResolution 1 dword 用象素/米表示的垂直分辨率
002Eh Colors 1 dword 位图使用的颜色数。如8-比特/象素表示为100h或者 256.
0032h Important Colors 1 dword 指定重要的颜色数。当该域的值等于颜色数时（或者等于0时），表示所有颜色都一样重要
调色板数据 根据BMP版本的不同而不同 Palette N * 4 byte 调色板规范。对于调色板中的每个表项，这4个字节用下述方法来描述RGB的值： 1字节用于蓝色分量
1字节用于绿色分量
1字节用于红色分量
1字节用于填充符(设置为0)
图象数据 根据BMP版本及调色板尺寸的不同而不同 Bitmap Data xxx bytes 该域的大小取决于压缩方法及图像的尺寸和图像的位深度，它包含所有的位图数据字节，这些数据可能是彩色调色板的索引号，也可能是实际的RGB值，这将根据图像信息头中的位深度值来决定。
构件详解
1. 位图文件头
位图文件头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义：
typedef struct tagBITMAPFILEHEADER { /* bmfh */
UINT bfType;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
其中：
bfType
说明文件的类型.（该值必需是0x4D42，也就是字符'BM'。我们不需要判断OS/2的位图标识，这么做现在来看似乎已经没有什么意义了，而且如果要支持OS/2的位图，程序将变得很繁琐。所以，在此只建议你检察'BM'标识）
bfSize
说明文件的大小，用字节为单位
bfReserved1
保留，必须设置为0
bfReserved2
保留，必须设置为0
bfOffBits
说明从文件头开始到实际的图象数据之间的字节的偏移量。这个参数是非常有用的，因为位图信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。
2. 位图信息头
位图信息用BITMAPINFO结构来定义，它由位图信息头(bitmap-information header)和彩色表(color table)组成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式：
typedef struct tagBITMAPINFO { /* bmi */
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO;
其中：
bmiHeader
说明BITMAPINFOHEADER结构，其中包含了有关位图的尺寸及位格式等信息
bmiColors
说明彩色表RGBQUAD结构的阵列，其中包含索引图像的真实RGB值。
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结构所需要的字数。注：这个值并不一定是BITMAPINFOHEADER结构的尺寸，它也可能是sizeof(BITMAPV4HEADER)的值，或是sizeof(BITMAPV5HEADER)的值。这要根据该位图文件的格式版本来决定，不过，就现在的情况来看，绝大多数的BMP图像都是BITMAPINFOHEADER结构的（可能是后两者太新的缘故吧:-）。
biWidth
说明图象的宽度，以象素为单位
biHeight
说明图象的高度，以象素为单位。注：这个值除了用于描述图像的高度之外，它还有另一个用处，就是指明该图像是倒向的位图，还是正向的位图。如果该值是一个正数，说明图像是倒向的，如果该值是一个负数，则说明图像是正向的。大多数的BMP文件都是倒向的位图，也就是时，高度值是一个正数。（注：当高度值是一个负数时（正向图像），图像将不能被压缩（也就是说biCompression成员将不能是BI_RLE8或BI_RLE4）。
biPlanes
为目标设备说明位面数，其值将总是被设为1
biBitCount
说明比特数/象素，其值为1、4、8、16、24、或32
biCompression
说明图象数据压缩的类型。其值可以是下述值之一：
BI_RGB：没有压缩；
BI_RLE8：每个象素8比特的RLE压缩编码，压缩格式由2字节组成(重复象素计数和颜色索引)；
BI_RLE4：每个象素4比特的RLE压缩编码，压缩格式由2字节组成
BI_BITFIELDS：每个象素的比特由指定的掩码决定。
biSizeImage
说明图象的大小，以字节为单位。当用BI_RGB格式时，可设置为0
biXPelsPerMeter
说明水平分辨率，用象素/米表示
biYPelsPerMeter
说明垂直分辨率，用象素/米表示
biClrUsed
说明位图实际使用的彩色表中的颜色索引数（设为0的话，则说明使用所有调色板项）
biClrImportant
说明对图象显示有重要影响的颜色索引的数目，如果是0，表示都重要。
现就BITMAPINFOHEADER结构作如下说明：
(1) 彩色表的定位
应用程序可使用存储在biSize成员中的信息来查找在BITMAPINFO结构中的彩色表，如下所示：
pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize))
(2) biBitCount
biBitCount=1 表示位图最多有两种颜色，缺省情况下是黑色和白色，你也可以自己定义这两种颜色。图像信息头装调色板中将有两个调色板项，称为索引0和索引1。图象数据阵列中的每一位表示一个象素。如果一个位是0，显示时就使用索引0的RGB值，如果位是1，则使用索引1的RGB值。
biBitCount=4 表示位图最多有16种颜色。每个象素用4位表示，并用这4位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，它表示有两个象素，第一象素的颜色就在彩色表的第2表项中查找，而第二个象素的颜色就在彩色表的第16表项中查找。此时，调色板中缺省情况下会有16个RGB项。对应于索引0到索引15。
biBitCount=8 表示位图最多有256种颜色。每个象素用8位表示，并用这8位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，这个象素的颜色就在彩色表的第32表项中查找。此时，缺省情况下，调色板中会有256个RGB项，对应于索引0到索引255。
biBitCount=16 表示位图最多有216种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或64K色。它的情况比较复杂，当biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量，中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555 16位位图。如果biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows 95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（当然还要再经过适当的左右移操作）。在NT系统中，则没有格式限制，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于游戏软件）。
biBitCount=24 表示位图最多有224种颜色。这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个象素，分别对应于颜色R、G、B。
biBitCount=32 表示位图最多有232种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板，32位中有24位用于存放RGB值，顺序是：最高位—保留，红8位、绿8位、蓝8位。这种格式也被成为888 32位图。如果 biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows 95(or 98)中，系统只接受888格式，也就是说三个掩码的值将只能是：0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。
(3) ClrUsed
BITMAPINFOHEADER结构中的成员ClrUsed指定实际使用的颜色数目。如果ClrUsed设置成0，位图使用的颜色数目就等于biBitCount成员中的数目。请注意，如果ClrUsed的值不是可用颜色的最大值或不是0，则在编程时应该注意调色板尺寸的计算，比如在4位位图中，调色板的缺省尺寸应该是16＊sizeof(RGBQUAD)，但是，如果ClrUsed的值不是16或者不是0，那么调色板的尺寸就应该是ClrUsed＊sizeof(RGBQUAD)。
(4) 图象数据压缩
① BI_RLE8：每个象素为8比特的RLE压缩编码，可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式可在同一幅图中的任何地方使用。
编码方式：由2个字节组成，第一个字节指定使用相同颜色的象素数目，第二个字节指定使用的颜色索引。此外，这个字节对中的第一个字节可设置为0，联合使用第二个字节的值表示：
第二个字节的值为0：行的结束。
第二个字节的值为1：图象结束。
第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置的偏移量。
绝对方式：第一个字节设置为0，而第二个字节设置为0x03～0xFF之间的一个值。在这种方式中，第二个字节表示跟在这个字节后面的字节数，每个字节包含单个象素的颜色索引。压缩数据格式需要字边界(word boundary)对齐。下面的例子是用16进制表示的8-位压缩图象数据：
03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01
这些压缩数据可解释为 ：
压缩数据
扩展数据
03 04 04 04 04
05 06 06 06 06 06 06
00 03 45 56 67 00 45 56 67
02 78 78 78
00 02 05 01 从当前位置右移5个位置后向下移一行
02 78 78 78
00 00 行结束
09 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
00 01 RLE编码图象结束
② BI_RLE4：每个象素为4比特的RLE压缩编码，同样也可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式也可在同一幅图中的任何地方使用。这两种方式是：
编码方式：由2个字节组成，第一个字节指定象素数目，第二个字节包含两种颜色索引，一个在高4位，另一个在低4位。第一个象素使用高4位的颜色索引，第二个使用低4位的颜色索引，第3个使用高4位的颜色索引，依此类推。
绝对方式：这个字节对中的第一个字节设置为0，第二个字节包含有颜色索引数，其后续字节包含有颜色索引，颜色索引存放在该字节的高、低4位中，一个颜色索引对应一个象素。此外，BI_RLE4也同样联合使用第二个字节中的值表示：
第二个字节的值为0：行的结束。
第二个字节的值为1：图象结束。
第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置的偏移量。
下面的例子是用16进制数表示的4-位压缩图象数据：
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01
这些压缩数据可解释为 ：
压缩数据
扩展数据
03 04 0 4 0
05 06 0 6 0 6 0
00 06 45 56 67 00 4 5 5 6 6 7
04 78 7 8 7 8
00 02 05 01 从当前位置右移5个位置后向下移一行
04 78 7 8 7 8
00 00 行结束
09 1E 1 E 1 E 1 E 1 E 1
00 01 RLE图象结束
3. 彩色表
彩色表包含的元素与位图所具有的颜色数相同，象素的颜色用RGBQUAD结构来定义。对于24-位真彩色图象就不使用彩色表（同样也包括16位、和32位位图），因为位图中的RGB值就代表了每个象素的颜色。彩色表中的颜色按颜色的重要性排序，这可以辅助显示驱动程序为不能显示足够多颜色数的显示设备显示彩色图象。RGBQUAD结构描述由R、G、B相对强度组成的颜色，定义如下：
typedef struct tagRGBQUAD { /* rgbq */
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
其中：
rgbBlue
指定蓝色强度
rgbGreen
指定绿色强度
rgbRed
指定红色强度
rgbReserved
保留，设置为0
4. 位图数据
紧跟在彩色表之后的是图象数据字节阵列。图象的每一扫描行由表示图象象素的连续的字节组成，每一行的字节数取决于图象的颜色数目和用象素表示的图象宽度。扫描行是由底向上存储的，这就是说，阵列中的第一个字节表示位图左下角的象素，而最后一个字节表示位图右上角的象素。（只针对与倒向DIB，如果是正向DIB，则扫描行是由顶向下存储的），倒向DIB的原点在图像的左下角，而正向DIB的原点在图像的左上角。同时，每一扫描行的字节数必需是4的整倍数，也就是DWORD对齐的。如果你想确保图像的扫描行DWORD对齐，可使用下面的代码：
(((width*biBitCount)+31)>>5)<<2
jpg格式：
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 文件结构
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
and Y densities>
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
图像文件结束标记
BMP文件格式分析
本来不想写这篇东西，因为介绍BMP文件结构的资料太多了，都有些滥了。但刚写完BMP的读写模块，又不想不留下点什么，所以就写了，全当是学习笔记吧。自己以后查资料时也方便一些，也许对某些初哥还会有点用^_^
注：本文参考了林福宗老师的有关BMP文件格式的文章，在此声明。
简介
BMP(Bitmap-File)图形文件是Windows采用的图形文件格式，在Windows环境下运行的所有图象处理软件都支持BMP图象文件格式。Windows系统内部各图像绘制操作都是以BMP为基础的。Windows 3.0以前的BMP图文件格式与显示设备有关，因此把这种BMP图象文件格式称为设备相关位图DDB(device-dependent bitmap)文件格式。Windows 3.0以后的BMP图象文件与显示设备无关，因此把这种BMP图象文件格式称为设备无关位图DIB(device-independent bitmap)格式（注：Windows 3.0以后，在系统中仍然存在DDB位图，象BitBlt()这种函数就是基于DDB位图的，只不过如果你想将图像以BMP格式保存到磁盘文件中时，微软极力推荐你以DIB格式保存），目的是为了让Windows能够在任何类型的显示设备上显示所存储的图象。BMP位图文件默认的文件扩展名是BMP或者bmp（有时它也会以.DIB或.RLE作扩展名）。
6.1.2 文件结构
位图文件可看成由4个部分组成：位图文件头(bitmap-file header)、位图信息头(bitmap-information header)、彩色表(color table)和定义位图的字节阵列，它具有如下所示的形式。
位图文件的组成
结构名称
符号
位图文件头(bitmap-file header) BITMAPFILEHEADER bmfh
位图信息头(bitmap-information header) BITMAPINFOHEADER bmih
彩色表(color table) RGBQUAD aColors[]
图象数据阵列字节 BYTE aBitmapBits[]
位图文件结构可综合在表6-01中。
表01 位图文件结构内容摘要
偏移量
域的名称
大小
内容
图象文件
头
0000h 文件标识 2 bytes 两字节的内容用来识别位图的类型：
‘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”就行。
0002h File Size 1 dword 用字节表示的整个文件的大小
0006h Reserved 1 dword 保留，必须设置为0
000Ah Bitmap Data Offset 1 dword 从文件开始到位图数据开始之间的数据(bitmap data)之间的偏移量
000Eh Bitmap Header Size 1 dword 位图信息头(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，而是应该从具体的文件中读取这个值。这样才能确保程序的兼容性。
0012h Width 1 dword 位图的宽度，以象素为单位
0016h Height 1 dword 位图的高度，以象素为单位
001Ah Planes 1 word 位图的位面数（注：该值将总是1）
图象
信息
头
001Ch Bits Per Pixel 1 word 每个象素的位数
1 - 单色位图（实际上可有两种颜色，缺省情况下是黑色和白色。你可以自己定义这两种颜色）
4 - 16 色位图
8 - 256 色位图
16 - 16bit 高彩色位图
24 - 24bit 真彩色位图
32 - 32bit 增强型真彩色位图
001Eh Compression 1 dword 压缩说明：
0 - 不压缩 (使用BI_RGB表示)
1 - RLE 8-使用8位RLE压缩方式(用BI_RLE8表示)
2 - RLE 4-使用4位RLE压缩方式(用BI_RLE4表示)
3 - Bitfields-位域存放方式(用BI_BITFIELDS表示)
0022h Bitmap Data Size 1 dword 用字节数表示的位图数据的大小。该数必须是4的倍数
0026h HResolution 1 dword 用象素/米表示的水平分辨率
002Ah VResolution 1 dword 用象素/米表示的垂直分辨率
002Eh Colors 1 dword 位图使用的颜色数。如8-比特/象素表示为100h或者 256.
0032h Important Colors 1 dword 指定重要的颜色数。当该域的值等于颜色数时（或者等于0时），表示所有颜色都一样重要
调色板数据 根据BMP版本的不同而不同 Palette N * 4 byte 调色板规范。对于调色板中的每个表项，这4个字节用下述方法来描述RGB的值： 1字节用于蓝色分量
1字节用于绿色分量
1字节用于红色分量
1字节用于填充符(设置为0)
图象数据 根据BMP版本及调色板尺寸的不同而不同 Bitmap Data xxx bytes 该域的大小取决于压缩方法及图像的尺寸和图像的位深度，它包含所有的位图数据字节，这些数据可能是彩色调色板的索引号，也可能是实际的RGB值，这将根据图像信息头中的位深度值来决定。
构件详解
1. 位图文件头
位图文件头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义：
typedef struct tagBITMAPFILEHEADER { /* bmfh */
UINT bfType;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
其中：
bfType
说明文件的类型.（该值必需是0x4D42，也就是字符'BM'。我们不需要判断OS/2的位图标识，这么做现在来看似乎已经没有什么意义了，而且如果要支持OS/2的位图，程序将变得很繁琐。所以，在此只建议你检察'BM'标识）
bfSize
说明文件的大小，用字节为单位
bfReserved1
保留，必须设置为0
bfReserved2
保留，必须设置为0
bfOffBits
说明从文件头开始到实际的图象数据之间的字节的偏移量。这个参数是非常有用的，因为位图信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。
2. 位图信息头
位图信息用BITMAPINFO结构来定义，它由位图信息头(bitmap-information header)和彩色表(color table)组成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式：
typedef struct tagBITMAPINFO { /* bmi */
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO;
其中：
bmiHeader
说明BITMAPINFOHEADER结构，其中包含了有关位图的尺寸及位格式等信息
bmiColors
说明彩色表RGBQUAD结构的阵列，其中包含索引图像的真实RGB值。
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结构所需要的字数。注：这个值并不一定是BITMAPINFOHEADER结构的尺寸，它也可能是sizeof(BITMAPV4HEADER)的值，或是sizeof(BITMAPV5HEADER)的值。这要根据该位图文件的格式版本来决定，不过，就现在的情况来看，绝大多数的BMP图像都是BITMAPINFOHEADER结构的（可能是后两者太新的缘故吧:-）。
biWidth
说明图象的宽度，以象素为单位
biHeight
说明图象的高度，以象素为单位。注：这个值除了用于描述图像的高度之外，它还有另一个用处，就是指明该图像是倒向的位图，还是正向的位图。如果该值是一个正数，说明图像是倒向的，如果该值是一个负数，则说明图像是正向的。大多数的BMP文件都是倒向的位图，也就是时，高度值是一个正数。（注：当高度值是一个负数时（正向图像），图像将不能被压缩（也就是说biCompression成员将不能是BI_RLE8或BI_RLE4）。
biPlanes
为目标设备说明位面数，其值将总是被设为1
biBitCount
说明比特数/象素，其值为1、4、8、16、24、或32
biCompression
说明图象数据压缩的类型。其值可以是下述值之一：
BI_RGB：没有压缩；
BI_RLE8：每个象素8比特的RLE压缩编码，压缩格式由2字节组成(重复象素计数和颜色索引)；
BI_RLE4：每个象素4比特的RLE压缩编码，压缩格式由2字节组成
BI_BITFIELDS：每个象素的比特由指定的掩码决定。
biSizeImage
说明图象的大小，以字节为单位。当用BI_RGB格式时，可设置为0
biXPelsPerMeter
说明水平分辨率，用象素/米表示
biYPelsPerMeter
说明垂直分辨率，用象素/米表示
biClrUsed
说明位图实际使用的彩色表中的颜色索引数（设为0的话，则说明使用所有调色板项）
biClrImportant
说明对图象显示有重要影响的颜色索引的数目，如果是0，表示都重要。
现就BITMAPINFOHEADER结构作如下说明：
(1) 彩色表的定位
应用程序可使用存储在biSize成员中的信息来查找在BITMAPINFO结构中的彩色表，如下所示：
pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize))
(2) biBitCount
biBitCount=1 表示位图最多有两种颜色，缺省情况下是黑色和白色，你也可以自己定义这两种颜色。图像信息头装调色板中将有两个调色板项，称为索引0和索引1。图象数据阵列中的每一位表示一个象素。如果一个位是0，显示时就使用索引0的RGB值，如果位是1，则使用索引1的RGB值。
biBitCount=4 表示位图最多有16种颜色。每个象素用4位表示，并用这4位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，它表示有两个象素，第一象素的颜色就在彩色表的第2表项中查找，而第二个象素的颜色就在彩色表的第16表项中查找。此时，调色板中缺省情况下会有16个RGB项。对应于索引0到索引15。
biBitCount=8 表示位图最多有256种颜色。每个象素用8位表示，并用这8位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，这个象素的颜色就在彩色表的第32表项中查找。此时，缺省情况下，调色板中会有256个RGB项，对应于索引0到索引255。
biBitCount=16 表示位图最多有216种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或64K色。它的情况比较复杂，当biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量，中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555 16位位图。如果biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows 95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（当然还要再经过适当的左右移操作）。在NT系统中，则没有格式限制，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于游戏软件）。
biBitCount=24 表示位图最多有224种颜色。这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个象素，分别对应于颜色R、G、B。
biBitCount=32 表示位图最多有232种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板，32位中有24位用于存放RGB值，顺序是：最高位—保留，红8位、绿8位、蓝8位。这种格式也被成为888 32位图。如果 biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows 95(or 98)中，系统只接受888格式，也就是说三个掩码的值将只能是：0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。
(3) ClrUsed
BITMAPINFOHEADER结构中的成员ClrUsed指定实际使用的颜色数目。如果ClrUsed设置成0，位图使用的颜色数目就等于biBitCount成员中的数目。请注意，如果ClrUsed的值不是可用颜色的最大值或不是0，则在编程时应该注意调色板尺寸的计算，比如在4位位图中，调色板的缺省尺寸应该是16＊sizeof(RGBQUAD)，但是，如果ClrUsed的值不是16或者不是0，那么调色板的尺寸就应该是ClrUsed＊sizeof(RGBQUAD)。
(4) 图象数据压缩
① BI_RLE8：每个象素为8比特的RLE压缩编码，可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式可在同一幅图中的任何地方使用。
编码方式：由2个字节组成，第一个字节指定使用相同颜色的象素数目，第二个字节指定使用的颜色索引。此外，这个字节对中的第一个字节可设置为0，联合使用第二个字节的值表示：
第二个字节的值为0：行的结束。
第二个字节的值为1：图象结束。
第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置的偏移量。
绝对方式：第一个字节设置为0，而第二个字节设置为0x03～0xFF之间的一个值。在这种方式中，第二个字节表示跟在这个字节后面的字节数，每个字节包含单个象素的颜色索引。压缩数据格式需要字边界(word boundary)对齐。下面的例子是用16进制表示的8-位压缩图象数据：
03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01
这些压缩数据可解释为 ：
压缩数据
扩展数据
03 04 04 04 04
05 06 06 06 06 06 06
00 03 45 56 67 00 45 56 67
02 78 78 78
00 02 05 01 从当前位置右移5个位置后向下移一行
02 78 78 78
00 00 行结束
09 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
00 01 RLE编码图象结束
② BI_RLE4：每个象素为4比特的RLE压缩编码，同样也可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式也可在同一幅图中的任何地方使用。这两种方式是：
编码方式：由2个字节组成，第一个字节指定象素数目，第二个字节包含两种颜色索引，一个在高4位，另一个在低4位。第一个象素使用高4位的颜色索引，第二个使用低4位的颜色索引，第3个使用高4位的颜色索引，依此类推。
绝对方式：这个字节对中的第一个字节设置为0，第二个字节包含有颜色索引数，其后续字节包含有颜色索引，颜色索引存放在该字节的高、低4位中，一个颜色索引对应一个象素。此外，BI_RLE4也同样联合使用第二个字节中的值表示：
第二个字节的值为0：行的结束。
第二个字节的值为1：图象结束。
第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置的偏移量。
下面的例子是用16进制数表示的4-位压缩图象数据：
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01
这些压缩数据可解释为 ：
压缩数据
扩展数据
03 04 0 4 0
05 06 0 6 0 6 0
00 06 45 56 67 00 4 5 5 6 6 7
04 78 7 8 7 8
00 02 05 01 从当前位置右移5个位置后向下移一行
04 78 7 8 7 8
00 00 行结束
09 1E 1 E 1 E 1 E 1 E 1
00 01 RLE图象结束
3. 彩色表
彩色表包含的元素与位图所具有的颜色数相同，象素的颜色用RGBQUAD结构来定义。对于24-位真彩色图象就不使用彩色表（同样也包括16位、和32位位图），因为位图中的RGB值就代表了每个象素的颜色。彩色表中的颜色按颜色的重要性排序，这可以辅助显示驱动程序为不能显示足够多颜色数的显示设备显示彩色图象。RGBQUAD结构描述由R、G、B相对强度组成的颜色，定义如下：
typedef struct tagRGBQUAD { /* rgbq */
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
其中：
rgbBlue
指定蓝色强度
rgbGreen
指定绿色强度
rgbRed
指定红色强度
rgbReserved
保留，设置为0
4. 位图数据
紧跟在彩色表之后的是图象数据字节阵列。图象的每一扫描行由表示图象象素的连续的字节组成，每一行的字节数取决于图象的颜色数目和用象素表示的图象宽度。扫描行是由底向上存储的，这就是说，阵列中的第一个字节表示位图左下角的象素，而最后一个字节表示位图右上角的象素。（只针对与倒向DIB，如果是正向DIB，则扫描行是由顶向下存储的），倒向DIB的原点在图像的左下角，而正向DIB的原点在图像的左上角。同时，每一扫描行的字节数必需是4的整倍数，也就是DWORD对齐的。如果你想确保图像的扫描行DWORD对齐，可使用下面的代码：
(((width*biBitCount)+31)>>5)<<2
jpg格式：
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 文件结构
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
and Y densities>
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
图像文件结束标记
H
huazai
Unregistered / Unconfirmed
GUEST, unregistred user!
说明。以上资料非本人撰写，属网友所有
S
smallbee
Unregistered / Unconfirmed
GUEST, unregistred user!
huazai大哥
可否直接寄到我信箱？
分数自当奉上。因为感觉里面少了点图象。^_^
smallbee@std.uestc.edu.cn
打搅你了。谢谢你的帮助。
可否直接寄到我信箱？
分数自当奉上。因为感觉里面少了点图象。^_^
smallbee@std.uestc.edu.cn
打搅你了。谢谢你的帮助。
H
huazai
Unregistered / Unconfirmed
GUEST, unregistred user!
已经发送
S
smallbee
Unregistered / Unconfirmed
GUEST, unregistred user!
信件已经收到。谢谢。。
Similar threads
- 回复
- 4
- 查看
- 4K