http://code.google.com/p/libbmp/
说到图片，位图（Bitmap）当然是最简单的，它是Windows显示图片的基本格式，其文件扩展名为*.BMP。由于没有经过任何的压缩，故BMP图 片往往很大。在Windows下，任何格式的图片文件都要转化为位图格式才能显示出来，各种格式的图片文件也都是在位图格式的基础上采用不同的压缩算法生 成的。
一、下面我们来看看位图文件（*.BMP）的格式。
位图文件主要分为如下4个部分：
块名称
对应Windows结构体定义大小（Byte）
文件信息头 BITMAPFILEHEADER 14
位图信息头 BITMAPINFOHEADER 40
颜色表（调色板）RGBQUAD （可选）
位图数据（RGB颜色阵列） BYTE* 由图像长宽尺寸决定
1．文件信息头BITMAPFILEHEADER
结构体定义如下：
typedef struct tagBITMAPFILEHEADER {
UINT bfType
DWORD bfSize
UINT bfReserved1
UINT bfReserved2
DWORD bfOffBits
} BITMAPFILEHEADER
其中：
bfType 表示文件的类型，该值必需是0x4D42，也就是字符'BM'。
bfSize 表示该位图文件的大小，用字节为单位
bfReserved1 保留，必须设置为0
bfReserved2 保留，必须设置为0
bfOffBits 表示从文件头开始到实际的图象数据之间的字节的偏移量。这个参数是非常有用的，因为位图信息头
和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。
2、位图信息头BITMAPINFOHEADER
结构体定义如下：
typedef struct tagBITMAPINFOHEADER {
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，表示都重要。
3、颜色表RGBQUAD：
颜色表用于说明位图中的颜色，它有若干个表项，每一个表项是一个RGBQUAD类型的结构，定义一种颜色。 这个部分是可选的，有些位图需要颜色表，有些位图，比如真彩色图（24位的BMP）就不需要颜色表，因为位图中的RGB值就代表了每个象素的颜色。但是16位r5g6b5位域彩色图像需要颜色表。
RGBQUAD结构的定义如下:
typedef struct tagRGBQUAD {
BYTE rgbBlue// 蓝色的亮度(值范围为0-255)
BYTE rgbGreen// 绿色的亮度(值范围为0-255)
BYTE rgbRed// 红色的亮度(值范围为0-255)
BYTE rgbReserved// 保留，必须为0
} RGBQUAD
位图信息头和颜色表组成位图信息，BITMAPINFO结构定义如下:
typedef struct tagBITMAPINFO {
BITMAPINFOHEADER bmiHeader// 位图信息头
RGBQUAD bmiColors[1]// 颜色表
} BITMAPINFO
而文件信息头和位图信息组成位图文件，BITMAPFILE结构定义如下：
typedef struct tagBITMAP
{
BITMAPFILEHEADER bfHeader
BITMAPINFO biInfo
}BITMAPFILE
4. 位图数据（RGB颜色阵列）
位图数据记录了位图的每一个像素值，记录顺序是：扫描行内是从左到右,扫描行之间是从下到上。位图的一个像素值所占的字节数:
当biBitCount=1时，8个像素占1个字节
当biBitCount=4时，2个像素占1个字节
当biBitCount=8时，1个像素占1个字节
当biBitCount=24时,1个像素占3个字节
当biBitCount=32时,1个像素占4个字节
Windows规定一个扫描行所占的字节数必须是4的倍数(即以long为单位),不足的以0填充。
这部分就是图片真正的数据，比如一张图片的大小为800*600，则该部分数据的长度就应该为800*600像素，也即800*600*24/8字节（如果是24位的图片，即一个像素用24bit来存储，每个像素点上有3个字节，分别用来表示b,g,r的颜色）。
有关RGB三色空间我想大家都很熟悉，这里我想说的是在Windows下，RGB颜色阵列存储的格式其实BGR。也就是说，对于24位的RGB位图像素数据格式是：
蓝色B值
绿色G值
红色R值
对于32位的RGB位图像素数据格式是：
蓝色B值
绿色G值
红色R值
透明通道A值
透明通道也称Alpha通道，该值是该像素点的透明属性，取值在0（全透明）到255（不透明）之间。对于24位的图像来说，因为没有Alpha通道，故整个图像都不透明。
二．根据对BMP格式的说明，我们可以轻易的写出一个生成BMP图像的函数：
首先需要位图数据，然后加上文件信息头和位图信息头就可以构成一张BMP图片了。
注意1：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 表示位图最多有65536种颜色。每个色素用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 表示位图最多有1670万种颜色。这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个象素，分别对应于颜色R、G、B。
biBitCount=32 表示位图最多有2^32种颜色。这种位图的结构与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对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。
注意2：字节补齐
位图数据记录了位图的每一个像素值，记录顺序是：扫描行内是从左到右,扫描行之间是从下到上。且Windows规定一个扫描行所占的字节数必须是4的倍数(即以long为单位),不足的以0填充，所以向文件中写入的位图数据的大小应该为：
每行图像的字节数：bmppitch = ((biWidth * bitCountPerPix + 31) >>5) <<2
例如：一张24位10*10的图片，一行图像10个像素，共30字节，由于Windows规定一个扫描行所占的字节数必须是4的倍数,而不足的以0填充， 所以一行图像在文件中实际存储了32个字节（补了2字节的0）；而图片总的大小就不是54+30*10=354字节，而是54+32*10=374字节。 （见图：24-10-10.bmp）
所以：1. 在生成BMP文件时，如果一行图像的字节数不是4的倍数，则补0，而补后一行图像数据的大小的计算公式为：
bmppitch = ((biWidth * bitCountPerPix + 31) >>5) <<2
其中，biWidth--图片的宽度，bitCountPerPix--图片的位数。
struct prio_array {
unsigned intnr_active//优先级队列数据中task个数
unsignedlong bitmap[BITMAP_SIZE]
structlist_head queue[MAX_PRIO]
}
#define BITMAP_SIZE ((((MAX_PRIO+1+7)/8)+sizeof(long)-1)/sizeof(long))
//内核中long型占4个字节，一个字节8位，BITMAP_SIZE的值为5
场景：将任务加入到对应优先级队列的尾部
static void enqueue_task(struct task_struct *p, prio_array_t *array)
{
sched_info_queued(p)
list_add_tail(&p->run_list, array->queue + p->prio)
__set_bit(p->prio, array->bitmap)
array->nr_active++
p->array = array
}
场景：将任务从优先级队列中移除
static void dequeue_task(struct task_struct *p, prio_array_t *array)
{
array->nr_active--
list_del(&p->run_list)
if (list_empty(array->queue + p->prio))
__clear_bit(p->prio, array->bitmap)
}
场景：将任务移动到对应优先级队列的尾部
/*
* Put task to the end of the run list without the overhead of dequeue
* followed by enqueue.
*/
static void requeue_task(struct task_struct *p, prio_array_t *array)
{
list_move_tail(&p->run_list, array->queue + p->prio)
}
场景：将任务加入到对应优先级队列的首部
static inline void enqueue_task_head(struct task_struct *p, prio_array_t *array)
{
list_add(&p->run_list, array->queue + p->prio)
__set_bit(p->prio, array->bitmap)
array->nr_active++
p->array = array
}
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）