<output id="qn6qe"></output>

    1. <output id="qn6qe"><tt id="qn6qe"></tt></output>
    2. <strike id="qn6qe"></strike>

      亚洲 日本 欧洲 欧美 视频,日韩中文字幕有码av,一本一道av中文字幕无码,国产线播放免费人成视频播放,人妻少妇偷人无码视频,日夜啪啪一区二区三区,国产尤物精品自在拍视频首页,久热这里只有精品12

      足跡

      能看不盡景,始是不凡人

       

      BMP文件格式詳解(BMP file format)

      BMP文件格式,又稱為Bitmap位圖)或是DIB(Device-Independent Device,設備無關位圖),是Windows系統中廣泛使用的圖像文件格式。由于它可以不作任何變換地保存圖像像素域的數據,因此成為我們取得RAW數據的重要來源。Windows圖形用戶界面(graphical user interfaces)也在它的內建圖像子系統GDI中對BMP格式提供了支持。

      下面以Notepad++為分析工具,結合Windows的位圖數據結構對BMP文件格式進行一個深度的剖析。

      BMP文件的數據按照從文件頭開始的先后順序分為四個部分:

      ?         bmp文件頭(bmp file header)提供文件的格式、大小等信息

      ?         位圖信息頭(bitmap information)提供圖像數據的尺寸、位平面數、壓縮方式、顏色索引等信息

      ?         調色板(color palette)可選,如使用索引來表示圖像,調色板就是索引與其對應的顏色的映射表

      ?         位圖數據(bitmap data)就是圖像數據啦^_^

      下面結合Windows結構體的定義,通過一個表來分析這四個部分。

       

      我們一般見到的圖像以24位圖像為主,即RGB三種顏色各用8bit來表示,這樣的圖像我們稱為真彩色,這種情況下是不需要調色板的,也就是所位圖信息頭后面緊跟的就是位圖數據了。因此,我們常常見到有這樣一種說法:位圖文件從文件頭開始偏移54個字節就是位圖數據了,這其實說的是2432位圖的情況。這也就解釋了我們按照這種程序寫出來的程序為什么對某些位圖文件沒用了。

        下面針對一幅特定的圖像進行分析,來看看在位圖文件中這四個數據段的排布以及組成。

        我們使用的圖像顯示如下:

                      

       

         這是一幅16位的位圖文件,因此它是含有調色板的。

         在拉出圖像數據進行分析之前,我們首先進行幾個約定:

         1. BMP文件中,如果一個數據需要用幾個字節來表示的話,那么該數據的存放字節順序為“低地址存放低位數據,高地址存放高位數據”。如數據0x1756在內存中的存儲順序為:

           

                                        

      這種存儲方式稱為小端方式(little endian) , 與之相反的是大端方式(big endian)。對兩者的使用情況有興趣的可以深究一下,其中還是有學問的。

      2.  以下所有分析均以字節為序號單位進行。

         下面我們對從文件中拉出來的數據進行剖析:

        

       

      一、bmp文件頭
      Windowsbmp文件頭定義了如下結構體:

        

       

      typedef struct tagBITMAPFILEHEADER 
      {  
      UINT16 bfType;    
      DWORD bfSize; 
      UINT16 bfReserved1; 
      UINT16 bfReserved2; 
      DWORD bfOffBits;
      } BITMAPFILEHEADER; 

       

      其中:

        

       

       對照文件數據我們看到:

       

      1-2  424dh = 'BM',表示這是Windows支持的位圖格式。有很多聲稱開頭兩個字節必須為'BM'才是位圖文件,從上表來看應為開頭兩個字節必須為'BM'才是Windows位圖文件。

      3-5  00010436h = 66614 B = 65.05 kB,通過查詢文件屬性發現一致。

      6-9  :這是兩個保留段,為0

      A-D00000436h = 1078。即從文件頭到位圖數據需偏移1078字節。我們稍后將驗證這個數據。

      共有14個字節。

      二、位圖信息頭
      同樣地,Windows為位圖信息頭定義了如下結構體:

       

        

      代碼
      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;
       

       

      對照數據文件: 

       

      0E-1100000028h = 40,這就是說我這個位圖信息頭的大小為40個字節。前面我們已經說過位圖信息頭一般有40個字節,既然是這樣,為什么這里還要給一個字段來說明呢?這里涉及到一些歷史,其實位圖信息頭原本有很多大小的版本的。我們看一下下表:

       

                      

          出于兼容性的考慮,大多數應用使用了舊版的位圖信息頭來保存文件。而 OS/2 已經過時了,因此現在最常用的格式就僅有V3 header了。因此,我們在前面說位圖信息頭的大小為40字節。

      12-1500000100h = 256,圖像寬為255像素,與文件屬性一致。

      16-1900000100h = 256,圖像高為255像素,與文件屬性一致。這是一個正數,說明圖像數據是從圖像左下角到右上角排列的。

      1A-1B0001h, 該值總為1

      1C-1D0008h = 8, 表示每個像素占8個比特,即該圖像共有256種顏色。

      1E-2100000000hBI_RGB說明本圖像不壓縮。

      22-2500000000h,圖像的大小,因為使用BI_RGB,所以設置為0

      26-2900000000h,水平分辨率,缺省。

      2A-2D00000000h,垂直分辨率,缺省。

      2E-3100000100h = 256,說明本位圖實際使用的顏色索引數為256,與1C-ID得到的結論一致。

      32-3500000100h = 256,說明本位圖重要的顏色索引數為256,與前面得到的結論一致。

       

      三、調色板
      下面的數據就是調色板了。前面也已經提過,調色板其實是一張映射表,標識顏色索引號與其代表的顏色的對應關系。它在文件中的布局就像一個二維數組palette[N][4],其中N表示總的顏色索引數,每行的四個元素分別表示該索引對應的BGRAlpha的值,每個分量占一個字節。如不設透明通道時,Alpha0。因為前面知道,本圖有256個顏色索引,因此N = 256。索引號就是所在行的行號,對應的顏色就是所在行的四個元素。這里截取一些數據來說明:

                                 

       

       

      索引:(藍,綠,紅,Alpha)

      0號:(fefafd00)

      1號:(fdf3fc00)

      2號:(f4f3fc00)

      3號:(fcf2f400)

      4號:(f6f2f200)

                                                                 5號:(fbf9f600) 等等。

       一共有256種顏色,每個顏色占用4個字節,就是一共1024個字節,再加上前面的文件信息頭和位圖信息頭的54個字節加起來一共是1078個字節。也就是說在位圖數據出現之前一共有1078個字節,與我們在文件信息頭得到的信息:文件頭到文圖數據區的偏移為1078個字節一致!

      四、位圖數據

      下面就是位圖數據了,每個像素占一個字節,取得這個字節后,以該字節為索引查詢相應的顏色,并顯示到相應的顯示設備上就可以了。

      注意:由于位圖信息頭中的圖像高度是正數,所以位圖數據在文件中的排列順序是從左下角到右上角,以行為主序排列的。

       

              

      也即我們見到的第一個像素60是圖像最左下角的數據,第二個人像素60為圖像最后一行第二列的數據,…一直到最后一行的最后一列數據,后面緊接的是倒數第二行的第一列的數據,依此類推。

       如果圖像是24位或是32位數據的位圖的話,位圖數據區就不是索引而是實際的像素值了。下面說明一下,此時位圖數據區的每個像素的RGB顏色陣列排布:

      24RGB按照BGR的順序來存儲每個像素的各顏色通道的值,一個像素的所有顏色分量值都存完后才存下一個下一個像素,不進行交織存儲。

      32位數據按照BGRA的順序存儲,其余與24位位圖的方式一樣。

      像素的排布規則與前述一致。

      對齊規則

      講完了像素的排列規則以及各像素的顏色分量的排列規則,最后我們談談數據的對齊規則。我們知道Windows默認的掃描的最小單位是4字節,如果數據對齊滿足這個值的話對于數據的獲取速度等都是有很大的增益的。因此,BMP圖像順應了這個要求,要求每行的數據的長度必須是4的倍數,如果不夠需要進行比特填充(以0填充),這樣可以達到按行的快速存取。這時,位圖數據區的大小就未必是圖片寬×每像素字節數×圖片高能表示的了,因為每行可能還需要進行比特填充。

      填充后的每行的字節數為:

            ,其中BPPBits Per Pixel)為每像素的比特數。

      在程序中,我們可以表示為:

      int iLineByteCnt = (((m_iImageWidth * m_iBitsPerPixel) + 31) >> 5) << 2;

      這樣,位圖數據區的大小為:

        m_iImageDataSize = iLineByteCnt * m_iImageHeight;

      我們在掃描完一行數據后,也可能接下來的數據并不是下一行的數據,可能需要跳過一段填充數據:

        skip = 4 - ((m_iImageWidth * m_iBitsPerPixel)>>3) & 3;

      五、拾遺

      至此,我們通過分析一個具體的位圖文件例子詳細地剖析了位圖文件的組成。需要注意的是:我們講的主要是PC機上的位圖文件的構成,對于嵌入式平臺,可能在調色板數據段與PC機的不同。如在嵌入式平臺上常見的16r5g6b5位圖實際上采用的掩模的方式而不是索引的方式來表示圖像。此時,在調色板數據段共有四個部分,每個部分為四個字節,實際表示的是彩色版規范。即:

        第一個部分是紅色分量的掩模

        第二個部分是綠色分量的掩模

       第三個部分是藍色分量的掩模

       第四個部分是Alpha分量的掩模(缺省為0

      典型的調色板規范在文件中的順序為為:

        00F8 0000 E007 0000 1F00 0000 0000 0000

      其中

          00F8 0000FB00h=1111100000000000(二進制),是藍紅分量的掩碼。
        E007 0000 07E0h=0000011111100000(二進制),是綠色分量的掩碼。
         1F00 0000001Fh=0000000000011111(二進制),是藍色分量的掩碼。
          0000 0000設置為0

      將掩碼跟像素值進行運算再進行移位操作就可以得到各色分量值。看看掩碼,就可以明白事實上在每個像素值的兩個字節16位中,按從高到低取565位分別就是rgb分量值。取出分量值后把rgb值分別乘以848就可以補齊每個分量為一個字節,再把這三個字節按BGR組合,放入存儲器,就可以轉換為24位標準BMP格式了。

      這樣我們假設在位圖數據區有一個像素的數據在文件中表示為02 F1。這個數據實際上應為F102

       r = (F102 AND F800) >> 8 = F0h = 240

       g= (F102 AND 07E0>> 3 = 20h = 32
        b=(F102 AND 001F) << 3 = 10h =16

      至此我們就可以顯示了。(本文結束)

      參考資源:

      1.      wiki百科 bmp file format  

      http://en.wikipedia.org/wiki/BMP_file_format

      2.      gwwgle的專欄 BMP格式詳解 http://blog.csdn.net/gwwgle/archive/2009/11/06/4775396.aspx

      3.      匿名 BMP格式圖像文件詳析http://www.thethirdmedia.com/pc/200407/20040722117029.shtm

      4.      Singler的專欄位圖文件(BMP)格式分析以及程序實現http://blog.csdn.net/yyfzy/archive/2006/06/10/785945.aspx

      posted on 2009-12-02 14:01  姚偉峰  閱讀(55357)  評論(12)    收藏  舉報

      導航

      主站蜘蛛池模板: 超清无码一区二区三区| 国产精品视频不卡一区二区| 97人人添人人澡人人澡人人澡| 国内精品一区二区不卡| 高清中文字幕一区二区| 97午夜理论电影影院| 精品国产91久久粉嫩懂色| 临泉县| 国产一区二区三区不卡视频| 精品国产乱码久久久久久婷婷| 国产91麻豆视频免费看| 精品av综合导航| 九九热视频在线观看精品| 4hu44四虎www在线影院麻豆| 国产一区二区不卡在线| 午夜一区二区三区视频| 粗壮挺进邻居人妻无码| 久久大香线蕉国产精品免费| 偷拍精品一区二区三区| 人妻影音先锋啪啪av资源| 精品一区二区三区在线观看l| 国产精品偷伦费观看一次| 特黄少妇60分钟在线观看播放| 亚洲欧美日韩在线不卡| 国产口爆吞精在线视频2020版| 国产黄色精品一区二区三区| 99久久久国产精品免费无卡顿| 国产三级精品三级在线区| 国产成人午夜福利精品| 黑森林福利视频导航| 国产精品中文字幕综合| 亚洲av成人在线一区| 国厂精品114福利电影免费| 亚洲精品日韩在线丰满| 久久午夜私人影院| av中文无码韩国亚洲色偷偷| 国产精品无卡毛片视频| 国产精品va无码一区二区| 东京热高清无码精品| 性色av极品无码专区亚洲| 亚洲中文字幕五月五月婷|