我需要一个16*12bmp格式的图标那位高手可以为我做一个16* - 爱问知识人
(window.slotbydup=window.slotbydup || []).push({
id: '2491531',
container: s,
size: '150,90',
display: 'inlay-fix'
我需要一个16*12bmp格式的图标
16*12像素，bmp格式
16*12像素，bmp格式
做图标可以用CDR软件也可以用AI这些平面设计软件，有心学就不难，问题是要花点时间，如果要求很精确的话，那就学AUTOCAD吧。
哥们，看看这个行不行啊，如果不行，你还有什么具体要求可以联系我哦！
把附件下载后拖到快速启动栏即可！（搞定后该文件可以删除）
该文件可以用记事本打开，内容是：
IconFile...
你已经发现问题的所在了！就是regsvr32 mshtml.dll的事情！
只要从别人机子上copy一个过去就好了！
把你邮箱给我一下...
大家还关注义项指多义词的不同概念，如的义项：网球运动员、歌手等；的义项：冯小刚执导电影、江苏卫视交友节目等。
BMP是英文Bitmap（）的简写，它是Windows操作系统中的标准图像文件格式，能够被多种Windows应用所。
分类 DDB和DIB
是Windows操作系统中的标准图像
BMP文件总体上由4部分组成
lbit、4bit、8bit及24bit
BMP(-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(有时它也会以.或.作扩展名)。
可看成由4个部分组成:位图文件头(bitmap-file header)、位图信息头(bitmap-information header)、彩色表(color table)和定义的字节(位图数据，即图像数据，Data Bits 或Data Body)阵列，它具有如下所示的形式。的组成结构名称 符 号位图文件头 (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 保留，必须设置为0000Ah 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.xF0h - 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 - 24bit32 - 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值，这将根据图像信息头中的位深度值来决定。
位图文件头
头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义:typedef struct tagBITMAPFILEHEADER { /* bmfh */UINT bfTDWORD bfSUINT bfReserved1;UINT bfReserved2;DWORD bfOffB} BITMAPFILEHEADER;其中:bfType说明文件的类型.(该值必需是0x4D42，也就是字符'BM'。我们不需要判断OS/2的位图标识，这么做看来似乎已经没有什么意义了，而且如果要支持OS/2的位图，程序将变得很繁琐。所以，在此只建议你检察'BM'标识)注意:查ascii表B 0x42,M0x4d,bfType为两个字节，B为low字节，M为high字节所以bfType=0x4D42，而不是0x424D，但注意bfSize说明文件的大小，用字节为单位bfReserved1保留，必须设置为0bfReserved2保留，必须设置为0bfOffBits说明从开始到实际的图象数据之间的字节的。这个参数是非常有用的，因为信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。
信息用BITMAPINFO结构来定义，它由位图信息头(bitmap-information header)和彩色表(color table)组成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式:typedef struct tagBITMAPINFO { /* bmi */BITMAPINFOHEADER bmiHRGBQUAD bmiColors[1];} BITMAPINFO;其中:bmiHeader说明BITMAPINFOHEADER结构，其中包含了有关位图的尺寸及位格式等信息bmiColors说明彩色表RGBQUAD结构的阵列，其中包含的真实RGB值。BITMAPINFOHEADER结构包含有的大小、压缩类型和颜色格式，其结构定义为:typedef struct tagBITMAPINFOHEADER { /* bmih */DWORD biSLONG biWLONG biHWORD biPWORD biBitCDWORD biCDWORD biSizeILONG biXPelsPerMLONG biYPelsPerMDWORD biClrUDWORD biClrI} BITMAPINFOHEADER;其中:biSize说明BITMAPINFOHEADER结构所需要的字数。注:这个值并不一定是BITMAPINFOHEADER结构的尺寸，它也可能是sizeof(BITMAPV4HEADER)的值，或是sizeof(BITMAPV5HEADER)的值。这要根据该的格式版本来决定，不过，就现在的情况来看，绝大多数的BMP都是BITMAPINFOHEADER结构的(可能是后两者太新的缘故吧:-)。biWidth说明图象的宽度，以象素为单位biHeight说明图象的高度，以象素为单位。注:这个值除了用于描述图像的高度之外，它还有另一个用处，就是指明该图像是倒向的，还是正向的位图。如果该值是一个正数，说明图像是倒向的，如果该值是一个负数，则说明图像是正向的。大多数的BMP文件都是倒向的，也就是时，高度值是一个正数。(注:当高度值是一个负数时(正向图像)，图像将不能被压缩(也就是说biCompression成员将不能是BI_RLE8或BI_RLE4)。biPlanes为目标设备说明位面数，其值将总是被设为1biBitCount说明比特数/象素，其值为1、4、8、16、24、或32biCompression说明图象数据压缩的类型。其值可以是下述值之一:BI_RGB:没有压缩;BI_RLE8:每个象素8比特的RLE压缩编码，由2组成(重复象素计数和颜色索引);BI_RLE4:每个象素4比特的RLE压缩编码，由2字节组成BI_BITFIELDS:每个象素的比特由指定的掩码决定。biSizeImage说明图象的大小，以为单位。当用BI_RGB格式时，可设置为0biXPelsPerMeter说明水平分辨率，用象素/米表示biYPelsPerMeter说明垂直分辨率，用象素/米表示biClrUsed说明实际使用的彩色表中的颜色索引数(设为0的话，则说明使用所有调色板项)biClrImportant说明对图象显示有重要影响的颜色索引的数目，如果是0，表示都重要。现就BITMAPINFOHEADER结构作如下说明:
彩色表定位
应用程序可使用存储在biSize成员中的信息来查找在BITMAPINFO结构中的彩色表，如下所示:pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo-&bmiHeader.biSize))
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对齐的，所以在内存中进行图像处理时可进行汇编级的(简单))。
如今Windows(3.x以及95，98，NT)系列已经成为绝大多数用户使用的操作系统，它比DOS成功的一个重要因素是它可视化的漂亮界面。那么Windows是如何显示图象的呢?这就要谈到(bitmap)。我们知道，普通的显示器屏幕是由许许多多点构成的，我们称之为象素。显示时采用扫描的方法:电子枪每次从左到右扫描一行，为每个象素着色，然后从上到下这样扫描若干行，就扫过了一屏。为了防止闪烁，每秒要重复上述过程几十次。例如我们常说的屏幕分辨率为640×480，刷新频率为70Hz，意思是说每行要扫描640个象素，一共有480行，每秒重复扫描屏幕70次。我们称这种显示器为位映象设备。所谓位映象，就是指一个二维的象素矩阵，而就是采用位映象方法显示和存储的图象。举个例子，图1.1是一幅普通的黑白，图1.2是被放大后的图，图中每个方格代表了一个象素。我们可以看到:整个骷髅就是由这样一些黑点和白点组成的。图1.1 骷髅图1.2 放大后的骷髅位图那么，彩色图是怎么回事呢?我们先来说说三元色RGB概念。我们知道，自然界中的所有颜色都可以由红、绿、蓝(R，G，B)组合而成。有的颜色含有红色成分多一些，如深红;有的含有红色成分少一些，如浅红。针对含有红色成分的多少，可以分成0到255共256个等级，0级表示不含红色成分;255级表示含有100%的红色成分。同样，绿色和蓝色也被分成256级。这种分级概念称为量化。这样，根据红、绿、蓝各种不同的组合我们就能表示出256×256×256，约1600万种颜色。这么多颜色对于我们人眼来说已经足够丰富了。表1.1 常见颜色的RGB组合值颜色RGB红25500蓝00255绿02550黄2552550紫2550255青0255255白255255255黑000灰128128128你大概已经明白了，当一幅图中每个象素赋予不同的RGB值时，能呈现出五彩缤纷的颜色了，这样就形成了彩色图。的确是这样的，但实际上的做法还有些差别。让我们来看看下面的例子。有一个长宽各为200个象素，颜色数为16色的彩色图，每一个象素都用R、G、B三个分量表示。因为每个分量有256个级别，要用8位(bit)，即一个(byte)来表示，所以每个象素需要用3个字节。整个图象要用200×200×3，约120k，可不是一个小数目呀!如果我们用下面的方法，就能省的多。因为是一个16色图，也就是说这幅图中最多只有16种颜色，我们可以用一个表:表中的每一行记录一种颜色的R、G、B值。这样当我们表示一个象素的颜色时，只需要指出该颜色是在第几行，即该颜色在表中的索引值。举个例子，如果表的第0行为255，0，0(红色)，那么当某个象素为红色时，只需要标明0即可。让我们再来计算一下:16种状态可以用4位(bit)表示，所以一个象素要用半个字节。整个图象要用200×200×0.5，约20k字节，再加上表占用的字节为3×16=48字节.整个占用的字节数约为前面的1/6，省很多吧?这张R、G、B的表，就是我们常说的调色板(Palette)，另一种叫法是LUT(Look Up Table)，似乎更确切一些。Windows中便用到了调色板技术。其实不光是Windows，许多图象文件格式如pcx、tif、gif等都用到了。所以很好地掌握调色板的概念是十分有用的。有一种图，它的颜色数高达256×256×256种，也就是说包含我们上述提到的R、G、B颜色表示方法中所有的颜色，这种图叫做图(true color)。图并不是说一幅图包含了所有的颜色，而是说它具有显示所有颜色的能力，即最多可以包含所有的颜色。表示图时，每个象素直接用R、G、B三个分量字节表示，而不采用调色板技术。原因很明显:如果用调色板，表示一个象素也要用24位，这是因为每种颜色的索引要用24位(因为总共有2种颜色，即调色板有2行)，和直接用R，G，B三个分量表示用的字节数一样，不但没有任何便宜，还要加上一个256×256×256×3个字节的大调色板。所以图直接用R、G、B三个分量表示，它又叫做24位色图。
有关RGB三色空间我想大家都很熟悉，这里我想说的是在Windows下，RGB颜色阵列存储的格式其实BGR。也就是说，对于24位的RGB位图像素数据格式是:蓝色B值绿色G值红色R值对于32位的RGB位图像素数据格式是:蓝色B值绿色G值红色R值透明通道A值透明通道也称Alpha通道，该值是该像素点的透明属性，取值在0(全透明)到255(不透明)之间。对于24位的图像来说，因为没有Alpha通道，故整个图像都不透明。
加载文件的目的是要得到图片属性，以及RGB数据，然后可以将其绘制在DC上(GDI)，或是生成纹理对象(3D:OpenGL/Direct3D)。这两种用途在上有点区别，我们主要按前一种用法讲，在和3D有不同的地方，我们再提出来。
//Load the file headerBITMAPFILEHEADERmemset(&header,0,sizeof(header));inf.read((char*)&header,sizeof(header));if(header.bfType != 0x4D42)这个很简单，没有什么好说的。
//Load the image information headerBITMAPINFOHEADERmemset(&infoheader,0,sizeof(infoheader));inf.read((char*)&infoheader,sizeof(infoheader));m_iImageWidth = infoheader.biWm_iImageHeight = infoheader.biHm_iBitsPerPixel = infoheader.biBitC这里我们得到了3各重要的图形属性:宽，高，以及每个像素颜色所占用的位数。
由于Windows在进行行扫描的时候最小的单位为4个字节，所以当图片宽 X 每个像素的字节数 != 4的整数倍时要在每行的后面补上缺少的字节，以0填充(一般来说当图像宽度为2的幂时不需要对齐)。里的数据在写入的时候已经进行了行对齐，也就是说加载的时候不需要再做行对齐。但是这样一来图片数据的长度就不是:宽 X 高 X 每个像素的字节数了，我们需要通过下面的方法计算正确的数据长度://Calculate the image data sizeint iLineByteCnt = (((m_iImageWidth*m_iBitsPerPixel) + 3) && 2) && 2;m_iImageDataSize = iLineByteCnt * m_iImageH
对于24位和32位的，位图数据的为sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER)，也就是说我们可以直接读取图像数据了。if(m_pImageData) delete []m_pImageDm_pImageData = new unsigned char[m_iImageDataSize];inf.read((char*)m_pImageData,m_iImageDataSize);如果你足够细心，就会发现内存m_pImageData里的数据的确是BGR格式，可以用个纯蓝色或者是纯红色的图片测试一下。
好了，数据和属性我们都有了，就可以拿来随便用了，就和吃馒头一样，爱粘白糖粘白糖，爱粘红糖粘红糖。下面是我的GDI绘制代码，仅作参考。void CImage::(HDC hdc,int iLeft,int iTop,int iWidth,int iHeight){if(!hdc || m_pImageData == NULL)BITMAPINFOmemset(&bmi,0,sizeof(bmi));bmi.bmiHeader.biSize = sizeof(BITMAPINFO);bmi.bmiHeader.biWidth = m_iImageWbmi.bmiHeader.biHeight = m_iImageHbmi.bmiHeader.biPlanes = 1;bmi.bmiHeader.biBitCount = m_iBitsPerPbmi.bmiHeader.biCompression = BI_RGB;bmi.bmiHeader.biSizeImage = m_iImageDataSStretchDIBits(hdc,iLeft,iTop,iWidth,iHeight,0,0,m_iImageWidth,m_iImageHeight,m_pImageData,&bmi,DIB_RGB_COLORS,SRCCOPY);}
如果你是想用刚才我们得到的数据生成纹理对象，那么你还要请出下面的问题。首先，用来生成纹理的数据不需要对齐，也就是说不能在每行的后面加上对齐的字节。当然在OpenGL里要求纹理图片的尺寸为2的幂，所以这个问题实际上不存在;其次，我们得到的图形数据格式是BGR(BGRA)，所以在生成纹理的时候，需指定格式为GL_BGR_EXT(GL_BGRA_EXT);否则需要做BGR-&RGB(BGRA-&RGBA)的转化。
{{each(i, video) list}}
{{if list.length > 8}}
查看全部 ${list.length} 期节目
{{if _first}}
内容来源于
{{if list && list.length}}转载BMP格式知识之二:16位,24位,32位的BMP图片算法是如何运算的
16位,24位,32位的BMP图片算法是如何运算的
if(color_byte&==&3)&&&//24位颜色图
&&&&switch&(&rgb&)&
case&0&:&tmp_color&=&buffer[count]&&3&;//为什么要右移3位呢,它表示的是什么?
color&|=&tmp_
&case&1&:&tmp_color&=&buffer[count]&&2&;//为什么要右移2位呢,它表示的是什么?
tmp_color&&&=&5&;////为什么要左移5位呢,它表示的是什么?
color&|=&tmp_color&;
case&2&:&tmp_color&=&buffer[count]&&3&;//为什么要右移3呢,它表示的是什么?
tmp_color&&&=&11&;//为什么左移11位,它表示的是什么?
color&|=&tmp_color&;
&&rgb&++&;
&&&&&if(color_byte==2)&&//16位颜色图
&&&&&&&&&&&&&&switch&(&rgb&)
case&0&:&byte1&=&buffer[count]&;//,它表示的是什么?
case&1&:&&&&
&&&&&&&&&&color&=&buffer[count]&;//它表示的是什么?
color&&=8&;
color&|=&byte1&;
&&rgb&++&;
&&&&&&else&
if(color_byte==4)&//32位颜色图
switch&(&rgb&)
&case&0&:&&byte1&=&buffer[count]&;
&case&1&:&&byte2&=&buffer[count]&;
&case&2&:&&byte3&=&buffer[count]&;
case&3&:&&tmp_color&=&byte1&&&&3&;//为什么要右移呢,它表示的是什么?
color&|=&tmp_
tmp_color&=&byte2&&&2&;//为什么要右移呢,它表示的是什么?
tmp_color&&&=&5&;
color&|=&tmp_color&;
tmp_color&=&byte3&&&3&;//为什么要右移呢,它表示的是什么?
tmp_color&&&=&11&;
color&|=&tmp_color&;
&&&rgb&++&;
这段代码的作用是将缓冲区里的24位、16位、32位的数据转换成RGB565格式的16位颜色值。
24位BMP文件：(rrrrrrrr,gggggggg,bbbbbbbb)蓝色在低地址
16位BMP文件：RGB555－xRRRRRGGGGGBBBBB，RGB565－RRRRRGGGGGGBBBBB，蓝色在低地址
32位BMP文件：(xxxxxxxx,rrrrrrrr,gggggggg,bbbbbbbb)蓝色在低地址，最高那个字节一般不处理。
你这段代码中的color应该是16位颜色，并且是RGB565格式，也就是红色5位，绿色6位，蓝色5位，RRRRRGGGGGGBBBBB。
24位转16位时，蓝色右移3位，是因为需要将8位蓝色转成5位蓝色，绿色先右移2位，是因为从8位转成6位，然后再左移5位，就是移到RGB565的16位数值的中间的位置上，00000GGGGGG00000，红色右移3位，就是8位转成5位，再左移11位，就是RRRRR。
16位转16位，直接将2字节拼接起来。
32位转16位，和24转16位类似，也是需要将8位颜色截短为5位和6位，然后拼起来。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}