亚洲精品视频一区,久久久久9999亚洲精品,伊人色综合久久天天

BMP��d��(�?OpenGL中位囄��操作(glReadPixels�Q�glDrawPixels和glCopyPixels应用举例)

Let me see see — Wed, 02 Jun 2010 03:02:00 GMT

原文地址�Q?/p>

http://blog.csdn.net/ghost129/archive/2009/08/04/4409565.aspx

1�?nbsp; BMP文�g格式��单介�l?/p>

BMP文�g是一�U�像素文�Ӟ��它保存了一�q�图象中所有的像素。这�U�文件格式可以保存单色位图�?6色或256色烦引模式像素图�?4位真彩色图象�Q�每�U�模式种单一像素的大��分别�ؓ1/8字节�Q?/2字节�Q?字节�?字节。目前最常见的是256色BMP�?4位色BMP。这�U�文件格式还定义了像素保存的几种�Ҏ��Q�包括不压羃、RLE压羃�{�。常见的BMP文�g大多是不压羃的�?br>�q�里��Z��单�v见，我们仅讨�?4位色、不使用压羃的BMP。（如果你��用Windows自带的画囄��序，很容易绘制出一个符合以上要求的BMP�Q?br>Windows所使用的BMP文�g�Q�在开始处有一个文件头�Q�大��ؓ54字节。保存了包括文�g格式标识、颜色数、图象大��、压�~�方式等信息�Q�因为我们仅讨论24位色不压�~�的BMP�Q�所以文件头中的信息基本不需要注意，只有“大小”�q�一��对我们比较有用。图象的宽度和高度都是一�?2位整敎ͼ�在文件中的地址分别�?x0012�?x0016�Q�于是我们可以��用以下代码来��d��图象的大��信息：

GLint width, height; // 使用OpenGL的GLint�c�d��Q�它�?2位的�?br>                                     // 而C语言本��n的int则不一定是32位的�?br>FILE* pFile;
// 在这里进�?#8220;打开文�g”的操�?br>fseek(pFile, 0x0012, SEEK_SET);         // �U�d��?x0012位置
fread(&width, sizeof(width), 1, pFile); // ��d��宽度
fseek(pFile, 0x0016, SEEK_SET);         // �U�d��?x0016位置
                                        // �׃��上一句执行后本就应该�?x0016位置
                                        // 所以这一句可省略
fread(&height, sizeof(height), 1, pFile); // ��d��高度

54个字节以后，如果�?6色或256色BMP�Q�则�q�有一个颜色表�Q�但24位色BMP没有�q�个�Q�我们这里不考虑。接下来��是实际的像素数据了�?4位色的BMP文�g中，每三个字节表�C�Z��个像素的颜色�?br>注意�Q�OpenGL通常使用RGB来表�C�颜�Ԍ��但BMP文�g则采用BGR�Q�就是说�Q�顺序被反过来了�?br>另外需要注意的地方是：像素的数据量�q�不一定完全等于图象的高度乘以宽度乘以每一像素的字节数�Q�而是可能略大于这个倹{��原因是BMP文�g采用了一�U?#8220;寚w��”的机�Ӟ��每一行像素数据的长度若不�?的倍数�Q�则填充一些数据��它是4的倍数。这样一来，一�?7*15�?4位BMP大小��应该是834字节�Q�每�?7个像素，�?1字节�Q�补充�ؓ52字节�Q�乘�?5得到像素数据总长�?80�Q�再加上文�g开始的54字节�Q�得�?34字节�Q�。分配内存时�Q�一定要��心�Q�不能直接��?#8220;图象的高度乘以宽度乘以每一像素的字节数”来计��分配空间的长度�Q�否则有可能��D��分配的内存空间长度不��I��造成��界讉K��Q�带来各�U�严重后果�?br>一个很��单的计算数据长度的方法如下：

int LineLength, TotalLength;
LineLength = ImageWidth * BytesPerPixel; // 每行数据长度大致为图象宽度乘�?br> // 每像素的字节�?br>while( LineLength % 4 != 0 ) // 修正LineLength使其�?的倍数
++LineLenth;
TotalLength = LineLength * ImageHeight; // 数据总长 = 每行长度 * 图象高度

�q��ƈ不是效率最高的�Ҏ��Q�但�׃��q�个修正本��n�q�算量�ƈ不大�Q��用频率也不高�Q�我们就不需要再考虑更快的方法了�?br>2、简单的OpenGL像素操作
OpenGL提供了简�z�的函数来操作像素：
glReadPixels�Q�读取一些像素。当前可以简单理解�ؓ“把已�l�绘制好的像素（它可能已�l�被保存到显卡的昑֭�中）��d��到内�?#8221;�?br>glDrawPixels�Q�绘制一些像素。当前可以简单理解�ؓ“把内存中一些数据作为像素数据，�q�行�l�制”�?br>glCopyPixels�Q�复制一些像素。当前可以简单理解�ؓ“把已�l�绘制好的像素从一个位�|�复制到另一个位�|?#8221;。虽然从功能上看�Q�好象等价于先读取像素再�l�制像素�Q�但实际上它不需要把已经�l�制的像素（它可能已�l�被保存到显卡的昑֭�中）转换为内存数据，然后再由内存数据�q�行重新的绘�Ӟ��所以要比先��d��后绘制快很多�?br>�q�三个函数可以完成简单的像素��d��、绘制和复制��d��Q�但实际上也可以完成更复杂的��d��。当前，我们仅讨��Z��些简单的应用。由于这几个函数的参数数目比较多�Q�下面我们分别介�l��?/p>

3、glReadPixels的用法和举例
3.1 函数的参数说�?br>该函数��d��有七个参数。前四个参数可以得到一个矩形，该矩形所包括的像素都会被��d��出来。（�W�一、二个参数表�C�Z��矩�Ş的左下角横、纵坐标�Q�坐标以�H�口最左下角�ؓ�Ӟ��最右上角�ؓ最大��|��W�三、四个参数表�C�Z��矩�Ş的宽度和高度�Q?br>�W�五个参数表�C��取的内容�Q�例如：GL_RGB��׃��依次��d��像素的红、绿、蓝三种数据�Q�GL_RGBA则会依次��d��像素的红、绿、蓝、alpha四种数据�Q�GL_RED则只��d��像素的红色数据（�c�M��的还有GL_GREEN�Q�GL_BLUE�Q�以及GL_ALPHA�Q�。如果采用的不是RGBA颜色模式�Q�而是采用颜色索引模式�Q�则也可以��用GL_COLOR_INDEX来读取像素的颜色索引。目前仅需要知道这些，但实际上�q�可以读取其它内容，例如深度�~�冲区的深度数据�{��?br>�W�六个参数表�C��取的内容保存到内存时所使用的格式，例如�Q�GL_UNSIGNED_BYTE会把各种数据保存为GLubyte�Q�GL_FLOAT会把各种数据保存为GLfloat�{��?br>�W�七个参数表�C�Z��个指针，像素数据被读取后�Q�将被保存到�q�个指针所表示的地址。注意，需要保证该地址有��够的可以使用的空��_��以容�U��取的像素数据。例如一�q�大��ؓ256*256的图象，如果��d��其RGB数据�Q�且每一数据被保存�ؓGLubyte�Q��d��就是：256*256*3 = 196608字节�Q�即192千字节。如果是��d��RGBA数据�Q�则��d��就�?56*256*4 = 262144字节�Q�即256千字节�?/p>

注意�Q�glReadPixels实际上是从缓冲区中读取数据，如果使用了双�~�冲区，则默认是从正在显�C�的�~�冲�Q�即前缓�Ԍ��中读取，而绘制工作是默认�l�制到后�~�冲区的。因此，如果需要读取已�l�绘制好的像素，往往需要先交换前后�~�冲�?/p>

再看前面提到的BMP文�g中两个需要注意的地方�Q?br>3.2 解决OpenGL常用的RGB像素数据与BMP文�g的BGR像素数据��序不一致问�?br>可以使用一些代码交换每个像素的�W�一字节和第三字节，使得RGB的数据变成BGR的数据。当然也可以使用另外的方式解决问题：新版本的OpenGL除了可以使用GL_RGB��d��像素的红、绿、蓝数据外，也可以��用GL_BGR按照相反的顺序依�ơ读取像素的蓝、绿、红数据�Q�这样就与BMP文�g格式相吻合了。即使你的gl/gl.h头文件中没有定义�q�个GL_BGR�Q�也没有关系�Q�可以尝试��用GL_BGR_EXT。虽然有的OpenGL实现�Q�尤其是旧版本的实现�Q��ƈ不能使用GL_BGR_EXT�Q�但我所知道的Windows环境下各�U�OpenGL实现都对GL_BGR提供了支持，毕竟Windows中各�U�表�C�颜色的数据几乎都是使用BGR的顺序，而非RGB的顺序。这可能与IBM-PC的硬件设计有兟�?/p>

3.3 消除BMP文�g�?#8220;寚w��”带来的媄�?br>实际上OpenGL也支持��用了�q�种“寚w��”方式的像素数据。只要通过glPixelStore修改“像素保存时对齐的方式”��可以了。像�q�样�Q?br>int alignment = 4;
glPixelStorei(GL_UNPACK_ALIGNMENT, alignment);
�W�一个参数表�C?#8220;讄��像素的对齐�?#8221;�Q�第二个参数表示实际讄��为多��。这里像素可以单字节寚w��Q�实际上��是不��用对齐）、双字节寚w��Q�如果长度�ؓ奇数�Q�则再补一个字节）、四字节寚w��Q�如果长度不是四的倍数�Q�则补�ؓ四的倍数�Q�、八字节寚w��。分别对应alignment的��gؓ1, 2, 4, 8。实际上�Q�默认的值是4�Q�正好与BMP文�g的对齐方式相��d��?br>glPixelStorei也可以用于设�|�其它各�U�参数。但我们�q�里�q�不需要深入讨��Z��?/p>

现在�Q�我们已�l�可以把屏幕上的像素��d��到内存了�Q�如果需要的话，我们�q�可以将内存中的数据保存到文件。正��的对照BMP文�g格式�Q�我们的�E�序��可以把屏幕中的图象保存为BMP文�g�Q�达到屏�q�截囄��效果�?br>我们�q�没有详�l�介�l�BMP文�g开头的54个字节的所有内容，不过�q�无伤大雅。从一个正��的BMP文�g中读取前54个字节，修改其中的宽度和高度信息�Q�就可以得到新的文�g头了。假设我们先建立一�?*1大小�?4位色BMP�Q�文件名为dummy.bmp�Q�又假设新的BMP文�g名称为grab.bmp。则可以�~�写如下代码�Q?/p>

FILE* pOriginFile = fopen("dummy.bmp", "rb);
FILE* pGrabFile = fopen("grab.bmp", "wb");
char BMP_Header[54];
GLint width, height;

/* 先在�q�里讄��好图象的宽度和高度，即width和height的��|��q�计��像素的总长�?*/

// ��d��dummy.bmp中的�?4个字节到数组
fread(BMP_Header, sizeof(BMP_Header), 1, pOriginFile);
// 把数�l�内容写入到新的BMP文�g
fwrite(BMP_Header, sizeof(BMP_Header), 1, pGrabFile);

// 修改其中的大��信�?br>fseek(pGrabFile, 0x0012, SEEK_SET);
fwrite(&width, sizeof(width), 1, pGrabFile);
fwrite(&height, sizeof(height), 1, pGrabFile);

// �U�d��到文件末��，开始写入像素数�?br>fseek(pGrabFile, 0, SEEK_END);

/* 在这里写入像素数据到文�g */

fclose(pOriginFile);
fclose(pGrabFile);

我们�l�出完整的代码，演示如何把整个窗口的图象抓取出来�q�保存�ؓBMP文�g�?/p>

#define WindowWidth 400
#define WindowHeight 400

#include
#include

/* 函数grab
* 抓取�H�口中的像素
* 假设�H�口宽度为WindowWidth�Q�高度�ؓWindowHeight
*/
#define BMP_Header_Length 54
void grab(void)
{
    FILE*    pDummyFile;
    FILE*    pWritingFile;
    GLubyte* pPixelData;
    GLubyte BMP_Header[BMP_Header_Length];
    GLint    i, j;
    GLint    PixelDataLength;

    // 计算像素数据的实际长�?br>    i = WindowWidth * 3;   // 得到每一行的像素数据长度
    while( i%4 != 0 )      // 补充数据�Q�直到i是的倍数
        ++i;               // 本来�q�有更快的算法，
                           // 但这里仅�q�求直观�Q�对速度没有太高要求
    PixelDataLength = i * WindowHeight;

    // 分配内存和打开文�g
    pPixelData = (GLubyte*)malloc(PixelDataLength);
    if( pPixelData == 0 )
        exit(0);

    pDummyFile = fopen("dummy.bmp", "rb");
    if( pDummyFile == 0 )
        exit(0);

    pWritingFile = fopen("grab.bmp", "wb");
    if( pWritingFile == 0 )
        exit(0);

    // ��d��像素
    glPixelStorei(GL_UNPACK_ALIGNMENT, 4);
    glReadPixels(0, 0, WindowWidth, WindowHeight,
        GL_BGR_EXT, GL_UNSIGNED_BYTE, pPixelData);

    // 把dummy.bmp的文件头复制为新文�g的文件头
    fread(BMP_Header, sizeof(BMP_Header), 1, pDummyFile);
    fwrite(BMP_Header, sizeof(BMP_Header), 1, pWritingFile);
    fseek(pWritingFile, 0x0012, SEEK_SET);
    i = WindowWidth;
    j = WindowHeight;
    fwrite(&i, sizeof(i), 1, pWritingFile);
    fwrite(&j, sizeof(j), 1, pWritingFile);

    // 写入像素数据
    fseek(pWritingFile, 0, SEEK_END);
    fwrite(pPixelData, PixelDataLength, 1, pWritingFile);

    // 释放内存和关闭文�?br>    fclose(pDummyFile);
    fclose(pWritingFile);
    free(pPixelData);
}

把这�D�代码复制到以前��M��评��的样例程序中�Q�在�l�制函数的最后调用grab函数�Q�即可把图象内容保存为BMP文�g了。（在我写这个教�E�的时候，不少地方都用�q�样的代码进行截囑ַ�作，�q�段代码一旦写好，�q�行��h��是很方便的。）
4、glDrawPixels的用法和举例
glDrawPixels函数与glReadPixels函数相比�Q�参数内容大致相同。它的第一、二、三、四个参数分别对应于glReadPixels函数的第三、四、五、六个参敎ͼ�依次表示图象宽度、图象高度、像素数据内宏V��像素数据在内存中的格式。两个函数的最后一个参��C��是对应的�Q�glReadPixels中表�C�像素读取后存放在内存中的位�|�，glDrawPixels则表�C�用于绘制的像素数据在内存中的位�|��?br>注意到glDrawPixels函数比glReadPixels函数��了两个参数�Q�这两个参数在glReadPixels中分别是表示图象的�v始位�|�。在glDrawPixels中，不必昑ּ�的指定绘制的位置�Q�这是因为绘制的位置是由另一个函数glRasterPos*来指定的。glRasterPos*函数的参��C��glVertex*�c�M��Q�通过指定一个二�l?三维/四维坐标�Q�OpenGL��自动计��出该坐标对应的屏幕位置�Q��ƈ把该位置作�ؓ�l�制像素的�v始位�|��?br>很自然的�Q�我们可以从BMP文�g中读取像素数据，�q��用glDrawPixels�l�制到屏�q�上。我们选择Windows XP默认的桌面背景Bliss.bmp作�ؓ�l�制的内容（如果你��用的是Windows XP�pȝ��Q�很可能可以在硬盘中搜烦到这个文件。当然你也可以��用其它BMP文�g来代替，只要它是24位的BMP文�g。注意需要修改代码开始部分的FileName的定义）�Q�先把该文�g复制一份放到正��的位置�Q�我们在�E�序开始时�Q�就��d��该文�Ӟ��从而获得图象的大小后，�Ҏ��该大��来创徏合适的OpenGL�H�口�Q��ƈ�l�制像素�?br>�l�制像素本来是很��单的�q�程�Q�但是这个程序在骨架上与前面的各�U�示例程序稍有不同，所以我�q�是打算�l�出一份完整的代码�?/p>

#include

#define FileName "Bliss.bmp"

static GLint    ImageWidth;
static GLint    ImageHeight;
static GLint    PixelLength;
static GLubyte* PixelData;

#include
#include

void display(void)
{
// 清除屏幕�q�不必要
// 每次�l�制�Ӟ��画面都覆盖整个屏�q?br> // 因此无论是否清除屏幕�Q�结果都一�?br> // glClear(GL_COLOR_BUFFER_BIT);

    // �l�制像素
    glDrawPixels(ImageWidth, ImageHeight,
        GL_BGR_EXT, GL_UNSIGNED_BYTE, PixelData);

// 完成�l�制
glutSwapBuffers();
}

int main(int argc, char* argv[])
{
    // 打开文�g
    FILE* pFile = fopen("Bliss.bmp", "rb");
    if( pFile == 0 )
        exit(0);

    // ��d��图象的大��信�?br>    fseek(pFile, 0x0012, SEEK_SET);
    fread(&ImageWidth, sizeof(ImageWidth), 1, pFile);
    fread(&ImageHeight, sizeof(ImageHeight), 1, pFile);

    // 计算像素数据长度
    PixelLength = ImageWidth * 3;
    while( PixelLength % 4 != 0 )
        ++PixelLength;
    PixelLength *= ImageHeight;

    // ��d��像素数据
    PixelData = (GLubyte*)malloc(PixelLength);
    if( PixelData == 0 )
        exit(0);

fseek(pFile, 54, SEEK_SET);
fread(PixelData, PixelLength, 1, pFile);

// 关闭文�g
fclose(pFile);

    // 初始化GLUT�q�运�?br>    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA);
    glutInitWindowPosition(100, 100);
    glutInitWindowSize(ImageWidth, ImageHeight);
    glutCreateWindow(FileName);
    glutDisplayFunc(&display);
    glutMainLoop();

    // 释放内存
    // 实际上，glutMainLoop函数永远不会�q�回�Q�这里也永远不会到达
    // �q�里写释攑ֆ�存只是出于一�U�个��Z��?br>    // 不用担心内存无法释放。在�E�序�l�束时操作系�l�会自动回收所有内�?br>    free(PixelData);

return 0;
}

�q�里仅仅是一个简单的昄��24位BMP图象的程序，如果读者对BMP文�g格式比较熟悉�Q�也可以写出适用于各�U�BMP图象的显�C�程序，在像素处理时�Q�它们所使用的方法是�c�M��的�?br>OpenGL在绘制像素之前，可以对像素进行若�q�处理。最常用的可能就是对整个像素图象�q�行攑֤�/�~�小。��用glPixelZoom来设�|�放�?�~�小的系敎ͼ�该函数有两个参数�Q�分别是水��^方向�p�L��和垂直方向系数。例如设�|�glPixelZoom(0.5f, 0.8f);则表�C�水�q�x��向变为原来的50%大小�Q�而垂直方向变为原来的80%大小。我们甚臛_��以��用负的系敎ͼ�使得整个图象�q�行水��^方向或垂直方向的��{�Q�默认像素从左绘制到叻I��但翻转后��从右绘制到左。默认像素从下绘制到上，但翻转后��从上绘制到下。因此，glRasterPos*函数讄��?#8220;开始位�|?#8221;不一定就是矩形的左下角）�?br>5、glCopyPixels的用法和举例
从效果上看，glCopyPixels�q�行像素复制的操作，�{��h于把像素��d��到内存，再从内存�l�制到另一个区域，因此可以通过glReadPixels和glDrawPixels�l�合来实现复制像素的功能。然而我们知道，像素数据通常数据量很大，例如一�q?024*768的图象，如果使用24位BGR方式表示�Q�则需要至��?024*768*3字节�Q�即2.25兆字节。这么多的数据要�q�行一�ơ读操作和一�ơ写操作�Q��ƈ且因为在glReadPixels和glDrawPixels中设�|�的数据格式不同�Q�很可能涉及到数据格式的转换。这对CPU无疑是一个不��的负担。��用glCopyPixels直接从像素数据复制出新的像素数据�Q�避免了多余的数据的格式转换�Q��ƈ且也可能减少一些数据复制操作（因�ؓ数据可能直接由显卡负责复�Ӟ��不需要经�q�主内存�Q�，因此效率比较高�?br>glCopyPixels函数也通过glRasterPos*�p�d��函数来设�|�绘制的位置�Q�因��Z��需要涉及到��d��存，所以不需要指定数据在内存中的格式�Q�也不需要��用�Q何指针�?br>glCopyPixels函数有五个参敎ͼ��W�一、二个参数表�C�复制像素来源的矩�Ş的左下角坐标�Q�第三、四个参数表�C�复制像素来源的举行的宽度和高度�Q�第五个参数通常使用GL_COLOR�Q�表�C�复制像素的颜色�Q�但也可以是GL_DEPTH或GL_STENCIL�Q�分别表�C�复制深度缓冲数据或模板�~�冲数据�?br>值得一提的是，glDrawPixels和glReadPixels中设�|�的各种操作�Q�例如glPixelZoom�{�，在glCopyPixels函数中同��h��效�?br>下面看一个简单的例子�Q�绘制一个三角�Ş后，复制像素�Q��ƈ同时�q�行水��^和垂直方向的��{�Q�然后羃��ؓ原来的一半，�q�绘制。绘制完毕后�Q�调用前面的grab函数�Q�将屏幕中所有内容保存�ؓgrab.bmp。其中WindowWidth和WindowHeight是表�C�窗口宽度和高度的常量�?/p>

void display(void)
{
// 清除屏幕
glClear(GL_COLOR_BUFFER_BIT);

    // �l�制
    glBegin(GL_TRIANGLES);
        glColor3f(1.0f, 0.0f, 0.0f);    glVertex2f(0.0f, 0.0f);
        glColor3f(0.0f, 1.0f, 0.0f);    glVertex2f(1.0f, 0.0f);
        glColor3f(0.0f, 0.0f, 1.0f);    glVertex2f(0.5f, 1.0f);
    glEnd();
    glPixelZoom(-0.5f, -0.5f);
    glRasterPos2i(1, 1);
    glCopyPixels(WindowWidth/2, WindowHeight/2,
        WindowWidth/2, WindowHeight/2, GL_COLOR);

    // 完成�l�制�Q��ƈ抓取图象保存为BMP文�g
    glutSwapBuffers();
    grab();
}

��结�Q?br>本课�l�合Windows�pȝ��常见的BMP图象格式�Q�简单介�l�了OpenGL的像素处理功能。包括��用glReadPixels��d��像素、glDrawPixels�l�制像素、glCopyPixels复制像素�?br>本课仅介�l�了像素处理的一些简单应用，但相信大家已�l�可以体会到�Q�围�l�这三个像素处理函数�Q�还存在一�?#8220;外围”函数�Q�比如glPixelStore*�Q�glRasterPos*�Q�以及glPixelZoom�{�。我们仅使用了这些函数的一��部分功能�?br>本课内容�q�不多，例子��_��丰富�Q�三个像素处理函数都有例子，大家可以�l�合例子来体会�?/p>

附录(其它位色的BMP文�g��?:

BMP文�g�l�成
　　BMP文�g由文件头、位图信息头、颜色信息和囑�Ş数据四部分组成�?
　　 BMP文�g�?
　　BMP文�g头数据结构含有BMP文�g的类型、文件大��和位图起始位置�{�信息�?
　　其结构定义如�?　　
　　typedef struct tagBITMAPFILEHEADER
　　{
　　WORDbfType; // 位图文�g的类型，必须为BM
　　DWORD bfSize; // 位图文�g的大��，以字节�ؓ单位
　　WORDbfReserved1; // 位图文�g保留字，必须�?
　　WORDbfReserved2; // 位图文�g保留字，必须�?
　　DWORD bfOffBits; // 位图数据的�v始位�|�，以相对于位图
　　// 文�g头的偏移量表�C�，以字节�ؓ单位
　　} BITMAPFILEHEADER;
　　

位图信息�?
　　
　　BMP位图信息头数据用于说明位囄��寸�{�信息�?br>　　typedef struct tagBITMAPINFOHEADER{
　　DWORD biSize; // 本结构所占用字节�?br>　　LONGbiWidth; // 位图的宽度，以像素�ؓ单位
　　LONGbiHeight; // 位图的高度，以像素�ؓ单位
　　WORD biPlanes; // 目标讑֤�的��别，必须�?
　　WORD biBitCount// 每个像素所需的位敎ͼ�必须�?(双色),
　　// 4(16�?�Q?(256�?�?4(真彩�?之一
　　DWORD biCompression; // 位图压羃�c�d��Q�必��L�� 0(不压�~?,
　　// 1(BI_RLE8压羃�c�d��)�?(BI_RLE4压羃�c�d��)之一
　　DWORD biSizeImage; // 位图的大��，以字节�ؓ单位
　　LONGbiXPelsPerMeter; // 位图水��^分��L率，每米像素�?br>　　LONGbiYPelsPerMeter; // 位图垂直分��L率，每米像素�?br>　　DWORD biClrUsed;// 位图实际使用的颜色表中的颜色�?br>　　DWORD biClrImportant;// 位图昄��q�程中重要的颜色�?br>　　} BITMAPINFOHEADER;
　　

颜色�?
　　颜色表用于说明位图中的颜�Ԍ��它有若干个表��，每一个表��Ҏ��一个RGBQUAD�c�d��的结构，定义一�U�颜艌Ӏ�RGBQUAD�l�构的定义如�?
　　
　　typedef struct tagRGBQUAD {
　　BYTErgbBlue;// 蓝色的亮�?��D��围�ؓ0-255)
　　BYTErgbGreen; // �l�色的亮�?��D��围�ؓ0-255)
　　BYTErgbRed; // �U�色的亮�?��D��围�ؓ0-255)
　　BYTErgbReserved;// 保留�Q�必��Mؓ0
　　} RGBQUAD;
　　颜色表中RGBQUAD�l�构数据的个数有biBitCount来确�?
　　当biBitCount=1,4,8�Ӟ��分别�?,16,256个表��?
　　当biBitCount=24�Ӟ��没有颜色表项�?br>　　位图信息头和颜色表组成位图信息，BITMAPINFO�l�构定义如下:
　　typedef struct tagBITMAPINFO {
　　BITMAPINFOHEADER bmiHeader; // 位图信息�?br>　　RGBQUAD bmiColors[1]; // 颜色�?br>　　} BITMAPINFO;

位图数据
　　位图数据记录了位囄��每一个像素��|��记录��序是在扫描行内是从左到�?扫描行之间是从下��C��。位囄��一个像素值所占的字节�?
　　
　　当biBitCount=1�Ӟ��8个像素占1个字�?
　　当biBitCount=4�Ӟ��2个像素占1个字�?
　　当biBitCount=8�Ӟ��1个像素占1个字�?
　　当biBitCount=24�?1个像素占3个字�?
　　Windows规定一个扫描行所占的字节数必��L��
　　4的倍数(即以long为单�?,不��的以0填充�Q?br>　　一个扫描行所占的字节数计��方�?
　　DataSizePerLine= (biWidth* biBitCount+31)/8;
　　// 一个扫描行所占的字节�?br>　　DataSizePerLine= DataSizePerLine/4*4; // 字节数必��L��4的倍数
　　位图数据的大��?不压�~�情况下):
　　DataSize= DataSizePerLine* biHeight;

Let me see see 2010-06-02 11:02 发表评论

BMP��d��(�?

Let me see see — Sat, 29 May 2010 03:22:00 GMT

在读取BMP囑փ�的时候，主要处理�?4位和32位图像，在处�?4位BMP囑փ�的时候，BMP囑փ�的数据已�l�被修改以便4字节自动寚w��Q?br> 对于24位BMP囑փ�而言�Q�最需要注意的一�Ҏ��Q�规定了每条行扫描线的数据大��必��L��4的整数倍，如果不是4的整数倍，那么需要在行末�?/span>�q�行�?�Q�否则数据读取将出现偏移�Q�直接导致的�l�果�Q?span style="COLOR: red">会加载出一张倾斜的图�?/span>。这个补0的操作叫做数据宽度对齐�?br> 很抽象？举个例子�Q�对�?00×400�?4位BMP囑փ�而言�Q�行扫描�?00px�Q�是4的整数倍，那么无需�q�行�?操作。如果是30×38�Q�本��每张麻��牌素材的尺寸）�Q�那么行扫描昄��不是4的整数倍。对�?4位BMP而言�Q�一个像素由RGB三字节组成，那么一个行扫描的total字节�?0 × 3 = 90字节�Q�进行数据宽度对齐之后，行扫描的实际total字节�?0 × 3 + 2 = 92字节。如此，才能�?整除。换句话��_��每一行多�?个无用的字节。这在编�E�中�Q�需要进行处理丢弃，否则囑փ�再次变�Ş

            int channel= 0;
            if ( texture->bpp == 24 ){
                channel = 3;
                texture->imageType = GL_RGB;
            }else{
                channel = 4;
                texture->imageType = GL_RGBA;
            }
            int biWidth = 0;                                                //每行补齐字节�?如果�?4位的话需要补齐成4字节的倍数
            if ( (texture->width*channel) % 4 != 0 )
                biWidth = 4 - ( (texture->width*channel) % 4 );

我们求出每行自动填充的字节数�Q�先��d��数据�Q�然后蟩�q�自动添加的字节敎ͼ�再接着��d��下一行数�?/span>

            for( int i = 0; i < height; i++ ){
                GLubyte* pdest = texture->imageData + i * width * channel;
                fread( pdest, 1, width * channel,file );

                for( int j = 0; j < width* channel; j+=channel ){
                    pdest[ j ] ^= pdest[j+2] ^= pdest[j] ^= pdest[j+2];                //��BGR转�ؓRGB,BMP数据从左下角到右上角的方式存�?/span>
                }

                fseek( file, biWidth, SEEK_CUR );                                    //丢弃补��字节�Q�开始填充下一�?nbsp;
            }

��d��数据完毕�Q�可以打印检验一下，用WINHEX打开看下�Q�NoPropblem
因�ؓ我读取的囄��不全�?12*512,256*256,.......,所以我用OPENGL生成�U�理的时候用了个gluBuild2DMipmaps

BOOL bRes = gluBuild2DMipmaps( GL_TEXTURE_2D, texture->bpp/8, texture->width,texture->height, texture->imageType, GL_UNSIGNED_BYTE, texture->imageData );

��d��来后又成斜着的图像了�Q�数据也没问题，只能说是生成MipMap 的时候读取数据跨度有问题�Q�但是我传递的�?2位图像的时候，生成的MIPMAP没�Q何问题，即��囑փ�大小不能�?整除�Q�即�?12*512,256*256,.......
所以我做了个比较恶心的做法

    if ( bMipmap ){
        if ( texture->imageType == GL_RGB ){
            GLubyte* data = new GLubyte[texture->width*texture->height*4 ];
            int counter = 0;
            for( int i = 0; i < texture->width*texture->height*3; i+=3 ){
                data[i+counter] = texture->imageData[i];
                data[i+1+counter] = texture->imageData[i+1];
                data[i+2+counter] = texture->imageData[i+2];
                data[i+3+counter] = 1.f;
                counter++;
            }
            BOOL bRes = gluBuild2DMipmaps( GL_TEXTURE_2D,  4, texture->width,texture->height, GL_RGBA, GL_UNSIGNED_BYTE, data );
            delete[] data;
        }else{
            BOOL bRes = gluBuild2DMipmaps( GL_TEXTURE_2D,  texture->bpp/8, texture->width,texture->height, texture->imageType, GL_UNSIGNED_BYTE, texture->imageData );
        }

        glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR_MIPMAP_LINEAR );
        glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);

��?4位的囑փ�生成�U�理的时候，我把数据转换�?2位的��没问题了，一直没更好的办法，请大家不吝指�?br>
题外文章�Q?br>BMP文�g的结构，从大的分�c�L��看，可以分成2部分�Q�头部信息区和图像数据区。其中头部信息区中，保存了图像的各种属性，如文件格式，囄��宽度�Q�调色板�{�等。过了头部信息区之后�Q�就是用来呈现图像的真正的数据区了。BMP文�g属于像素文�g�Q�也��是��_��数据��Z��的数据，其实��是记录了图像中每一个像素的颜色�Q�以32位BMP囄��来说�Q�每一个像素由ARGB四个字节保存光��Ԍ��其中A是透明度。那么，一�?00×400�?2位BMP囑փ��Q�就�?60000个像素组成，则，数据区大��?160000×4byte = 640000byte = 640kb�Q�所以也不难怪，BMP囑փ�文�g�l��h的印象就是文仉��常大�?

那么��BMP文�g中的像素逐个��d��数据�~�冲再显�C�，是否��p��正常昄��了呢�Q�显然不是的。前面说了，在文件开头有一块头部信息区�Q�如果把�q�些数据也一赯��q�缓�Ԍ��那么囑փ�是无法最�l�显�C�的。因此，通常载入BMP囑փ�的首要�Q务是要知道这块头部信息区的大��，也就是数据区的偏�U�量offset�Q�再利用fseek��d��到这个位�|�，再进行逐个像素的解析。而头部信息区的大��D��似在头部信息区的某个字节中有的，只需要读取该字节�Q�便可知道。对�?4位和32位的BMP囑փ�而言�Q�这个offset��gؓ0x36�Q�也��是头部信息区的大小�?4个字节�?/p>

如果你要把加载图像的函数做的通用一些的话，那么囄��的宽度和高度也是需要获取的�Q�对�?4位BMP囑փ��Q�这两个值可以分别在0x12�?x16�q�行��d��得到�Q�注意fread需要读双字�Q�即4字节�Q�否则会出错�?/p>

对于24位BMP囑փ�而言�Q�最需要注意的一�Ҏ��Q�规定了每条行扫描线的数据大��必��L��4的整数倍，如果不是4的整数倍，那么需要在行末端进行补0�Q�否则数据读取将出现偏移�Q�直接导致的�l�果�Q�会加蝲��Z��张倾斜的图像。这个补0的操作叫做数据宽度对齐�?/p>

很抽象？举个例子�Q�对�?00×400�?4位BMP囑փ�而言�Q�行扫描�?00px�Q�是4的整数倍，那么无需�q�行�?操作。如果是30×38�Q�本��每张麻��牌素材的尺寸）�Q�那么行扫描昄��不是4的整数倍。对�?4位BMP而言�Q�一个像素由RGB三字节组成，那么一个行扫描的total字节�?0 × 3 = 90字节�Q�进行数据宽度对齐之后，行扫描的实际total字节�?0 × 3 + 2 = 92字节。如此，才能�?整除。换句话��_��每一行多�?个无用的字节。这在编�E�中�Q�需要进行处理丢弃，否则囑փ�再次变�Ş�?/p>

最后一个需要注意的��细节是�Q�BMP囑փ�的原点坐标，都是以左下角为基准，向右、向上增加。所以，在编�E�时�Q�需要对y轴数据做一些小变换。否则将会得��C��q�颠倒的囑փ��Q�此外，BMP的三原色��序是BGR�Q�注意编�E�中的处理�?/p>
原文地址�Q�BMP文�g的结构，从大的分�c�L��看，可以分成2部分�Q�头部信息区和图像数据区。其中头部信息区中，保存了图像的各种属性，如文件格式，囄��宽度�Q�调色板�{�等。过了头部信息区之后�Q�就是用来呈现图像的真正的数据区了。BMP文�g属于像素文�g�Q�也��是��_��数据��Z��的数据，其实��是记录了图像中每一个像素的颜色�Q�以32位BMP囄��来说�Q�每一个像素由ARGB四个字节保存光��Ԍ��其中A是透明度。那么，一�?00×400�?2位BMP囑փ��Q�就�?60000个像素组成，则，数据区大��?160000×4byte = 640000byte = 640kb�Q�所以也不难怪，BMP囑փ�文�g�l��h的印象就是文仉��常大�?

最后一个需要注意的��细节是�Q�BMP囑փ�的原点坐标，都是以左下角为基准，向右、向上增加。所以，在编�E�时�Q�需要对y轴数据做一些小变换。否则将会得��C��q�颠倒的囑փ��Q�此外，BMP的三原色��序是BGR�Q�注意编�E�中的处理�?/p>
原文地址�Q?a >http://naozifangde.blog.163.com/blog/static/1280042642009101614938531/

Let me see see 2010-05-29 11:22 发表评论

BMP��d��(�?

Let me see see — Fri, 28 May 2010 06:14:00 GMT

摘要: ��d��BMP主要分�ؓ��d��1. //位图文�g�?nbsp;BITMAPFILEHEADER header;2.. //位图信息�?nbsp;BITMAPINFOHEADER info;3.��d��数据 BMP的数据格式是BGR�Q�所以我们要转换为RGB格式�Q�同时注意，BMP囑փ�中存储的数据是从左下角开始存储的�Q�到右上角结束，也就是最后一行是正常的第一行，... 阅读全文

Let me see see 2010-05-28 14:14 发表评论

BMP��d��(一)

Let me see see — Fri, 28 May 2010 03:00:00 GMT

摘要: BMP文�g格式分析 - [] Tag: BMP文�g格式分析 tc昄��真彩一、BMP囄��的文件结构BMP文�g的数据在��盘上是按以下顺序存储的�Q��E位图文�g头TBitmapFileHeader�Q��E位图信息头TBitmapInfo�Q��E图象数据BGRA�Q�每�D늚�具体内容如下�Q�TBitmapFileHeader= packed record ... 阅读全文

Let me see see 2010-05-28 11:00 发表评论

TGA��d��(�?

Let me see see — Wed, 26 May 2010 02:05:00 GMT

摘要: 实例LoadTGA.rar下蝲Image.h #ifndef _IMAGE_H_#define _IMAGE_H_#pragma once// These defines are used to tell us about the type ... 阅读全文

Let me see see 2010-05-26 10:05 发表评论

TGA��d��( 一 )

Let me see see — Wed, 26 May 2010 01:40:00 GMT

摘要: 常用TGA��d��主要分�ؓ压羃和非压羃的格式，他们又分�?4位和32位读取，切记 TGA格式采用BGR或BGRA逆OPenGL的格式，所以我们用OPenGL��d��的时候要转换成�ؓRGB或RGBA的格式，��一三位互换不全面的原因�?TGA 包含了超�q�六�U�图像文件格式，而其中的几种较�ؓ常用�?我选择了我现在使用的格式�ƈ在本文中加以详解�?如果你需要本文中没有包含的格式说明，你可以与你的 truevision... 阅读全文

Let me see see 2010-05-26 09:40 发表评论

亚洲精品视频一区,久久久久9999亚洲精品,伊人色综合久久天天

BMP��d��(�?OpenGL中位囄���操作(glReadPixels�Q�glDrawPixels和glCopyPixels应用举例)

BMP��d��(�?

BMP��d��(�?

BMP��d��(一)

TGA��d��(�?

TGA��d��( 一 )

BMP��d��(�?OpenGL中位囄��操作(glReadPixels�Q�glDrawPixels和glCopyPixels应用举例)