文章編號: 81498 - 上次校閱: 2005年2月11日 - 版次: 2.5

dIBs 和它們的用法

中英文對照顯示按一下這裡顯示機器翻譯的中英文對照
機器翻譯檢視機器翻譯免責聲明
Retired KB Article依現狀不再更新的知識庫內容免責聲明
檢視此文章適用的產品。
系統提示本文適用於您使用的作業系統之外的作業系統。與您不相關的文章內容已停用。

在此頁中

全部展開 | 全部摺疊

結論

下列是 「 DIB 和 Their 用途"發行項的文字。本文是適用於 Windows 說明 Microsoft 軟體程式庫中，除了下面所呈現的文字中的檔案格式。
回此頁最上方

其他相關資訊

從 「 Microsoft 下載中心 」 下載下列檔案有：


Dibs2.exe (http://download.microsoft.com/download/platformsdk/article/3.1/w31/en-us/dibs2.exe)
如需有關如何下載 Microsoft 支援檔案的詳細資訊，按一下 [下列面的文件編號，檢視 「 Microsoft 知識庫 」 中的發行項]：
119591? (http://support.microsoft.com/kb/119591/EN-US/ ) 如何從線上服務取得 Microsoft 支援檔案
Microsoft 已掃描這個檔案有無病毒。Microsoft 使用已張貼檔案的日期中的 [可用的最新病毒偵測軟體。檔案儲存在安全性強化的伺服器上，以避免任何未經授權的更改至檔案。 本文將告訴您 「 從定義和結構 DIB (與裝置無關點陣圖) 概念，來使用它的 API。包含是說明某些最常見的方法來顯示和管理數位影像使用 DIB 的一個小範例應用程式。所討論的函式是 GetDIBits()、 SetDIBits()、 CreateDIBitmap()、 SetDIBitsToDevice()、 StretchDIBits() 及 CreateDIBPatternBrush()。本文不會討論使用調色盤和 DIB。
回此頁最上方

概觀

與裝置無關點陣圖 (DIB) 是用來定義中各種不同的色彩解析度的與裝置無關點陣圖格式。DIB 的主要目的是要允許從一個裝置移到另一個的點陣圖 (因此，與裝置無關部分名稱)。一個 DIB 是一個外部] 格式及相對於系統中顯示為點陣圖物件 (使用 CreateBitmap()、 CreateCompatibleBitmap()、 CreateBitmapIndirect() 或 CreateDIBitmap() 應用程式所建立) 的裝置相關點陣圖。一個 DIB 通常傳輸在中繼檔 (通常使用 StretchDIBits() 函數)、 BMP 檔和剪貼簿 (CF_DIB 資料格式)。

一個 DIB 由兩個部分組成： 本身的位元和說明的位元格式的標頭。標頭包含色彩格式]、 [色彩表] 和 [點陣圖的大小。目前的 DIB 格式支援四個色彩解析度： 1 位元、 4 位元、 8 位元及 24 位元。1 位元、 4 位元與 8 位元 DIB 像素由適當的位元解析中) 的索引定義到資料表中的色彩 ； 以 24 位元值 1 個位元組每個紅色、 綠色及藍色描述 24 位元像素。 DIB 函式是： 
   GetDIBits:           Translates a device-dependent bitmap into the DIB
                        format

   SetDIBits:           Translates a DIB's information into device-
                        dependent form

   CreateDIBitmap:      Creates a device-dependent bitmap initialized with
                        DIB information

   SetDIBitsToDevice:   Sets a DIB directly to the output surface

   StretchDIBits:       Moves a rectangle from the DIB to a rectangle on
                        the destination surface, stretching or compressing
                        as necessary

   CreateDIBPatternBrush:   Creates a pattern brush using a DIB for the
                            bitmap description
回此頁最上方

裝置的獨立性-什麼它適合?？

在 Microsoft Windows 圖形環境稍早的版本 3.0 可能不是將色彩點陣圖從一個裝置傳輸到另一個。 DIB，每個裝置會以它的色彩解析度刑罰顯示影像。應用程式可以將影像儲存在 DIB 格式，然後加以，顯示不論輸出裝置 ； 應用程式不再需要建立版本的每個影像，以每一種類型的裝置。

這個影像傳輸能力來列印半色調的影像。比方說 StretchDIBits() 函式可以是 DIB 直接傳遞至智慧型的印表機驅動程式。有了完整的色彩資訊而不只是單色版本 (傳統方法) 的影像的驅動程式可以使用半色調列印逼真的圖片。

因為公開定義 DIB 格式，應用程式可以操作它即時。在實際上應用程式可以建置不需要任何互動與 Windows 影像。如果 Windows 缺少繪圖的基本型別，應用程式可以模擬它直接將使用現有的圖形裝置介面 (GDI) 基本的 DIB。不幸的是下 Windows 版本 3.0 和 3.1，, GDI 無法執行直接到一個 DIB 輸出作業。
回此頁最上方

BMP 檔案格式

Windows DIB 檔的副檔名是 BMP。檔案是由 BITMAPFILEHEADER 結構，後面接著 DIB 本身所組成。不幸的是，因為 BITMAPFILEHEADER 結構永遠不會實際傳遞至 API，產生 BMP 檔不是每個應用程式填寫資料結構小心。若要加入此混淆，結構的適當 」 的定義是在文件和不一致。適當地，資料結構包含下列欄位： 
   bfType              A WORD that defines the type of file. It must be
                       'BM'.

   bfSize              A DWORD that specifies the size of the file in
                       bytes. The Microsoft Windows Software Development
                       Kit (SDK) documentation claims otherwise. To be on
                       the safe side, many applications calculate their
                       own sizes for reading in a file.

   bfReserved1,
   bfReserved2         WORDs that must be set to 0.

   bfOffBits           A DWORD that specifies the offset from the

                       beginning of the BITMAPFILEHEADER structure to the
                       start of the actual bits. The DIB header
                       immediately follows the file header, but the
                       actual image bits need not be placed next to the
                       headers in the file.
[DIB 標頭緊接 BITMAPFILEHEADER 結構。

程式碼範例會讀取 BMP 檔案，請參閱範例程式。
回此頁最上方

DIB 標頭

標頭實際上由兩個鄰接部分組成： 在適當的標頭與色彩表。兩者結合 BITMAPINFO 結構也就是所有 DIB API 都預期中。

Windows 3.0 版支援的標頭兩個種類： BITMAPINFOHEADER 和 BITMAPCOREHEADER。如果可能的話，應用程式應該使用只有 BITMAPINFOHEADERs。BITMAPCOREHEADER 定義根據點陣圖定義從簡報管理員版本 1.1，且支援相容性。

DIB 設定作業期間大部分的欄位已經填寫由凡是產生 [DIB。GetDIBits() 呼叫不過，提供更多的控制。標頭填入這項作業的方式定義產生 DIB 尤其是它的色彩解析度。

BITMAPINFOHEADER 包含下列欄位： 
   biSize              Should be set to sizeof(BITMAPINFOHEADER). This
                       field defines the size of the header (minus the
                       color table). If a new DIB definition is added, it
                       is identified by a new value for the size. This
                       field is also convenient for calculating a pointer
                       to the color table, which immediately follows the
                       BITMAPINFOHEADER.

   biWidth, biHeight   Define the width and the height of the bitmap in
                       pixels. They are DWORD values for future
                       expansion, and the code in Windows versions 3.0
                       and 3.1 ignores the high word (which should be set
                       to 0).

   biPlanes            Should always be 1. All DIB definitions rely on
                       biBitCount for color resolution definition.

   biBitCount          Defines the color resolution (in bits per pixel)
                       of the DIB. Only four values are valid for this
                       field: 1, 4, 8, and 24. New resolutions (16 bit,
                       for example) may be added in the future, but for
                       now only these four define a valid DIB. Choosing the
                       appropriate value when doing a GetDIBits is
                       discussed below. When performing a Set operation,
                       the value should already be defined for the bits.

   biCompression       Specifies the type of compression. Can be one of
                       three values: BI_RGB, BI_RLE4, or BI_RLE8. The most
                       common and useful choice, BI_RGB, defines a DIB in
                       which all is as it seems. Each block of biBitCount
                       bits defines an index (or RGB value for 24-bit
                       versions) into the color table. The other two
                       options specify that the DIB is stored (or will be
                       stored) using either the 4-bit or the 8-bit run
                       length encoding (RLE) scheme that Windows
                       supports. The RLE formats are especially useful
                       for animation applications and also usually
                       compress the bitmap. BI_RGB format is recommended
                       for almost all purposes. RLE versions, although
                       possibly smaller, are slower to decode, not as
                       widely supported, and extremely painful to band
                       properly.

   biSizeImage         Should contain the size of the bitmap proper in
                       bytes. I say "should" because the field is not
                       necessarily filled in. A call to GetDIBits to
                       generate a DIB fills in this field, but a DIB
                       created manually by an application might not have
                       this filled in. Calculating the size of a bitmap
                       is not hard:

                       biSizeImage = ((((biWidth * biBitCount) + 31)
                                      & ~31) >> 3) * biHeight;

                       The crazy roundoffs and shifts account for the
                       bitmap being DWORD-aligned at the end of every
                       scanline. When nonzero, this field tells an
                       application how much storage space the DIB's bits
                       need. The biSizeImage field really becomes useful
                       when dealing with an RLE bitmap, the size of which
                       depends on how well the bitmap was encoded. If an
                       RLE bitmap is to be passed around, the biSizeImage
                       field is essential.

   biXPelsPerMeter,
   biYPelsPerMeter     Define application-specified values for the
                       desirable dimensions of the bitmap. This
                       information can be used to maintain the physical
                       dimensions of an image across devices of different
                       resolutions. GDI never touches these fields. When
                       not filled in, they should both be set to 0.

   biClrUsed           Provides a way for getting smaller color tables.
                       When this field is set to 0, the number of colors
                       in the color table is based on the biBitCount
                       field (1 indicates 2 colors, 4 indicates 16, 8
                       indicates 256, and 24 indicates no color table). A
                       nonzero value specifies the exact number of colors
                       in the table. So, for example, if an 8-bit DIB
                       uses only 17 colors, then only those 17 colors
                       need to be defined in the table, and biClrUsed is
                       set to 17. Of course, no pixel can have an index
                       pointing past the end of the table.

                       Note: This field cannot be used during a GetDIBits
                       operation. GDI always fills a full-size color
                       table. The field is therefore more useful for
                       post-processing operations, when an application
                       trims down the contents of the DIB. If nonzero for
                       a 24-bit DIB, it indicates a table that the
                       application can use for color reference.

   biClrImportant      Specifies that the first x colors of the color
                       table are important to the DIB. If the rest of the
                       colors are not available, the image still retains
                       its meaning in an acceptable manner.
                       biClrImportant is purely for application use; GDI
                       does not touch this value. When this field is set
                       to 0, all the colors are important, or rather,
                       their relative importance has not been computed.
色彩資料表緊接的標頭資訊。沒有色彩資料表定義為 24 位元 DIB。表格組成 RGBQUAD 資料結構的陣列。(BITMAPCOREINFO 格式的表格會建置具有 RGBTRIPLE 資料結構)。紅、 綠，及藍色位元組位於相反順序 (紅色 swaps 位置以藍色)，從 Windows 慣例。這是另一個 leftover 從簡報管理員相容性。

色彩表的大小取決於 biBitCount 值 (並可以使用 biClrUsed 欄位覆寫 ； 請參閱上面的)： 
   if (!(nNumColors = biClrUsed))
   {

     if (biBitCount != 24)
          nNumColors = 1 << biBitCount;

   }
   nTableSize = nNumColors * sizeof(RGBQUAD);
最目前浮動的 DIB 有 biClrUsed 設為 0，但如果預計任何完整 DIB 痛是很好的作法正確設定。 如果不是零 biClrUsed，色彩表與 24 位元 DIB 有可能。GDI 不使用這個色彩] 資料表，但是應用程式可以用來判斷重要在 [DIB 中使用的色彩。

所有 DIB 功能都包括可以影響色彩表的定義的 wUsage 參數。本文可以避免 DIB，使用調色盤，並藉此假設 wUsage 永遠設定為 DIB_RGB_COLORS，而且該色彩表是因此永遠組成 RGB 值。使用 DIB_PAL_COLORS 時色彩表 WORD 值所組成是到目前選取的邏輯調色盤的索引。(本主題是在 「 使用 DIB 與調色盤"發行項中詳細討論)。
回此頁最上方

位元格式

標頭定義將位元格式，但所有格式都共用下列規則：
  • 每個 scanline 是 DWORD 對齊。scanline 緩衝來對齊方式 ； 緩衝不一定是 0。
  • scanlines 是由下儲存與第一個掃描 (掃描 0)，被最底部掃描影像中的記憶體中。(請參閱 [圖 1)。 這是另一個成品的簡報管理員相容性。GDI 自動反轉影像設定] 和 [Get 作業期間。 [圖 1]。(內嵌的影像顯示記憶體和螢幕的表示法)。
  • 不遵守 64K 區段界限 ； scanlines 可以跨越這類界限 (不同於裝置相關點陣圖格式成 64K 界限緩衝)。
每個格式有下列特性：
  • 1 位元 DIB 會儲存使用作為索引的每一個位元到資料表中的色彩。最重要的位元是最左邊的像素。
4 位元 DIB 會儲存到資料表中的色彩代表索引每 4 位元。最大顯著性 nibble 是最左邊的像素。
  • 8 位元 DIB 是最容易儲存，因為每個位元組是一個索引。
  • 24 位元 DIB 有每隔 3 個位元組代表一個色彩使用相同的 ordering 作為色彩表。此格式是特別難以處理期間處理，因為 64K 界限可以存在色彩 3 倍--必須小心處理的困難條件的中間。
回此頁最上方

使用 DIB API

回此頁最上方

GetDIBits() 和 SetDIBits()

這些兩個函式用來轉換與裝置無關點陣圖為裝置相關點陣圖，反之亦然。SetDIBits() 將一個 DIB 轉換成裝置相關點陣圖並 GetDIBits() 從裝置相關點陣圖產生一個 DIB。

hDC 傳入兩個呼叫所參考的裝置驅動程式會執行實際的轉譯。某些裝置驅動程式可能沒有這項功能 (比方說 Windows 版本 2.0 驅動程式或基本的 Windows 版本 3.0 驅動程式)。在這種情況下 GDI 模擬，轉譯，但只能在單色--色彩資訊轉換成黑白。在大多數的情況下，但是，這不是重要的考量。所有 self-respecting 顯示驅動程式支援此功能，且只有幾個印表機驅動程式不提供轉譯，通常是單色的驅動程式的 GDI 模擬夠了。

GetDeviceCaps(hDC, RASTERCAPS) 傳回 WORD 值的旗標設定指出哪些 DIB 函數驅動程式支援。RC_DI_BITMAP 表示支援 GetDIBits() 和 SetDIBits()，RC_DIBTODEV 表示支援 SetDIBitsToDevice()，RC_STRETCHDIB 表示 StretchDIBits() 支援。不支援任何函式可以被模擬，雖然模擬 (主要是因為色彩資訊遺失) 是通常不實用，作為真實的事。裝置可能無法支援完整的功能，即使有點設定。比方說裝置可能支援 StretchDIBits 但只整數類資料的大小時往兩邊延伸。不幸的是，應用程式有沒有方法可以判斷實作的完整性。 在這些情況下 GDI 會模擬函式。

參數是相同的同時 GetDIBits() 和 SetDIBits()： 
GetDIBits(hDC, hBitmap, nStartScan, nNumScans, lpBits, lpBitmapInfo,
wUsage)

SetDIBits(hDC, hBitmap, nStartScan, nNumScans, lpBits, lpBitmapInfo,
wUsage)

hDC            The device context (DC) responsible for the translation
               operation. hDC must be compatible with the hBitmap
               parameter.

hBitmap        The device-dependent bitmap from which (Get) or to
               which (Set) the DIB will be translated. Because of how
               the simulation code operates, this bitmap should not be
               currently selected into any DC.

nStartScan,
nNumScans      Define the contents of lpBits. For example, a StartScan
               of 5 indicates that lpBits points to the fifth scan of
               the DIB. A NumScans of 14 indicates that lpBits points
               to 14 scans of the DIB. Normally, nStartScan is set to
               0 and nNumScans is set to biHeight to denote that the
               whole DIB is pointed to by lpBits.

lpBits         The actual bitmap of the DIB. The pixel information is
               pointed to by this parameter.

lpBitmapInfo   The header (with color table) defining the DIB. The
               height and width in this header must match the height
               and width of the hBitmap parameter (the translation is
               always 1-to-1). The color resolution of the DIB need
               not match that of hBitmap.

wUsage         For the purposes of this article, assume this to be
               DIB_RGB_COLORS, indicating RGB colors in the color
               table.
使用 SetDIBits() 相當合理地簡單。一個 DIB 來自某處 (例如，從剪貼簿或從磁碟檔案)，而轉換成可選取到 DC 和 blted 到顯示畫面的點陣圖物件。這是最簡單的方式顯示一個 DIB。

附註許多印表機可以進行半色調，這個方法未慣用列印，StretchDIBits (討論所示) 是更有用。

下列是簡易顯示的 [到 (有沒有錯誤處理) 的 DC DIB： 
   HBITMAP hBitmap;
   HDC hMemDC;

   hBitmap = CreateCompatibleBitmap(hDC, (WORD)lpInfo->biWidth,
          lpInfo->(WORD)biHeight);

   hMemDC = CreateCompatibleDC(hDC);
   SetDIBits(hDC, hBitmap, 0, (WORD)lpInfo->biHeight, lpBits,

          lpBitmapInfo, DIB_RGB_COLORS);

   hBitmap = SelectObject(hMemDC, hBitmap);
   BitBlt(hDC, 0, 0, (WORD)lpInfo->biWidth, (WORD)lpInfo->biHeight,

          hMemDC, 0, 0, SRCCOPY);

   DeleteObject(SelectObject(hMemDC, hBitmap));
   DeleteDC(hMemDC);
使用 GetDIBits() 是更複雜，因為應用程式可以選擇何種 DIB 產生。來源點陣圖大小調節 DIB 的維度 (一段可擷取由 blting 成較小的點陣圖)，但應用程式的需要可以聽寫色彩解析度。

正常運作的 GetDIBits()，針對應用程式需要在標頭中設定下列欄位： 
   biSize = sizeof(BITMAPINFOHEADER)
   biWidth = (width of the bitmap)
   biHeight = (height of the bitmap)
   biPlanes = 1
   biBitCount = [desired color resolution (1, 4, 8, or 24)]
   biCompression = BI_RGB (For RLE information, see below.)
參閱，針對色彩表配置空間必須足以容納觀看完整大小的資料表： 
   if (biBitCount != 24)

     nSizeTable = (1 << biBitCount) * sizeof(RGBQUAD)

   else

     nSizeTable = 0;
配置為 lpBits 也必須是大到足以容納 nNumScans 資料的空間。呼叫會填入結構的下列欄位：
  • biSizeImage = DIB 資料的大小 (以位元組為單位)
  • 填滿色彩] 表格 (非 24 元情況) 適當的色彩
  • lpBits 填入 DIB 資料
如果 GetDIBits() 呼叫與 lpBits 設為 NULL 時，會傳回沒有位元，會填入 biSizeImage 及色彩表。這個選項對於具有 RLE DIB 很有用，且不值得非編碼 DIB。

[DIB 的應用程式的目標決定要選擇何種色彩解析度。一般的方法是產生可保留來源裝置相關點陣圖的色彩資訊的 DIB。選擇較低的解析度結果色彩資訊的遺失，是通常不希望發生。永遠使用 24 位元解析度是不必要的但是，因為如此一來新增沒有更多的色彩解析度如果來源有 8 位元或更少的解析度。 
   BITMAP bm;

   // get information on bitmap
   GetObject(hBitmap, sizeof(BITMAP), (LPVOID)&bm);

   BitmapRes = bm.bmPlanes * bm.bmBitsPixel;
   if (BitmapRes == 1)

     biBitCount = 1;

   else if (BitmapRes <= 4)

     biBitCount = 4;

   else if (BitmapRes <= 8)

     biBitCount = 8;

   else

     biBitCount = 24;
點陣圖的解析度計算必須列入考量的一些裝置相關點陣圖都是平面 (尤其是 EGA 和 VGA)。dIBs，另一方面，永遠 」 封裝像素，"使用每像素的只有 1 架飛機 (biPlanes = 1)。

nStartScan 和 nNumScans 參數 (簡報管理員相容性 residue) 是設計用來將用於級區構成。如果沒有足夠的記憶體可用整個 DIB 載入記憶體中一段，lpBits 可以由指向 [只有部分位元。 請參考下列範例： 
   #define MAXREAD 5
   WORD ReadXScans(LPSTR, WORD);   // Read up to X scans; return
                                   // NumRead.
   LPSTR lpBits;                   // Points to a block of memory for
                                   // MAXREAD scans.
   LPBITMAPINFOHEADER lpInfo;
   WORD nStart, nNumRead;

   for (nStart = 0; nStart >= (WORD)lpInfo->biHeight; )
   {

     nNumRead = ReadXScans(lpBits, MAXREAD);
     SetDIBits(hDC, hBitmap, nStart, nNumRead,
          lpBits, lpInfo, DIB_RGB_COLORS);
     nStart += nNumRead;

   }
「 設定程式碼會採用指定群組列、 會轉譯，並且把轉譯後的群組列放在適當的位置帳戶管理在所有時間的 「 優點上下 DIB 的本質。請注意如何 biHeight 不會改變在任何時候由於寬線放置在完整的點陣圖高度為基礎的點陣圖。nStart 根據 (由 biHeight 定義) 的完整影像的高度。
回此頁最上方

CreateDIBitmap()

下列程式碼會示範具有最常見的情況下呼叫 CreateDIBitmap()： 
   hBitmap = CreateDIBitmap(hDC, lpInfo, CBM_INIT, lpBits, lpInfo,
                            wUsage);
這相當於： 
   hBitmap = CreateCompatibleBitmap(hDC, (WORD)lpInfo->biWidth,

             (WORD)lpInfo->biHeight);

   SetDIBits(hDC, hBitmap, 0, (WORD)lpInfo->biHeight, lpBits, lpInfo,
             wUsage);
GDI 的實作如果 CBM_INIT 旗標未設定第三個參數，則略過 SetDIBits() 一部份。這個函式會讓的很好的快顯編碼的裝置相關點陣圖從 DIB 轉換。
回此頁最上方

SetDIBitsToDevice()

SetDIBitsToDevice() 允許直接將一個 DIB 設裝置介面應用程式。因為這個函式從早期開發鑑效組其介面無法。 優美可能是因為StretchDIBits() 是比 SetDIBitsToDevice() 函式更強大。StretchDIBits() 會執行所有該 SetDIBitsToDevice() 並有之前的介面。SetDIBitsToDevice() 有限它處理中繼檔，因為它不會未縮放的方式，帶狀 nStartScan 和 nNumScans 參數是非日常最佳。StretchDIBits() 不允許級區構成。

下列程式碼會使用 StretchDIBits 完整點陣圖 (沒有帶狀) 上執行 SetDIBitsToDevice() 功能： 
   StretchDIBits(hDC, x, y, (WORD)lpInfo->biWidth,

          (WORD)lpInfo->biHeight, 0, 0, (WORD)lpInfo->biWidth,
          (WORD)lpInfo->biHeight, lpBits, lpInfo, DIB_RGB_COLORS,
          SRCCOPY)
假設 nStartScan 設為 0，且該 nNumScans 設定為-> [級區 (也就沒有構成) biHeight lpInfo，函式基本上是 BitBlt 作為 [ROP SRCCOPY 與做為來源 DIB。SrcX 和 SrcY DIB 的空間中，因此顛倒相對於該 DC (Y = 0 位於影像的底端)。

處理顛倒 DIB 是棘手時進行部分的設定。如果應用程式要取得下一個 DIB 的第三個的是 w h 的個像素 (x，y) 在裝置，呼叫會如下所示，例如： 
   SetDIBitsToDevice(hDC, x, y, w, h/3, 0, h/3, 0,

          (WORD)lpInfo->biHeight, lpBits, lpInfo, DIB_RGB_COLORS);
A 裝置相關點陣圖會有的 2 h SrcY/3 下方的第三，但與優點上下的 DIB h/3 點至適當的位置相對於 Windows 的 SrcY 系統協調。
回此頁最上方

StretchDIBits()

這個函數是，請執行所有貼心裝置的介面上顯示一個 DIB。是 metafiling 和延展能力是重要的列印，尤其是不錯的。

在目前的實作中 StretchDIBits() 的一個重要洞是 StretchDIBits() 印表機驅動程式支援，而且不是由許多顯示驅動程式。因此，伸展至畫面 DIB 重複使用這個函式是比使用 SetDIBits (若要取得裝置相關點陣圖)，後面接著重複 StretchBlt() 呼叫明顯地慢。

GDI 中這個函式的實作是非常直截了當。如果裝置驅動程式能夠處理呼叫本身，會執行它。如果沒有，並呼叫是 1-1 和裝置支援 SetDIBitsToDevice()，呼叫轉換到 SetDIBitsToDevice() 呼叫到的驅動程式。(這適用於只與 SRCCOPY 作為 [ROP)。如果這些方法都不可能有，CreateDIBitmap() 用來讓在點陣圖的裝置依存版本並 StretchBlt 稱為執行實際工時。

StretchDIBits() 的參數都基本上相同至於 StretchBlt() (與來源 hDC lpBits 和 lpInfo 被取代)。這個函式不具有 nStartScan 和的其他 DIB 函數)，nNumScans 參數，讓 lpBits 永遠會指向第一個掃描的 [DIB。

當您使用這個函式進行完整的點陣圖大小時往兩邊延伸以外的其他，請記住所有來源座標 (與相關之 DIB 的) 是顛倒系統中。函式會適當地翻轉該影像，但來源矩形以 Y = 0 定義在底部及範圍移。幸運的是，x 軸座標會使用相同的慣例作為 Windows。

印表機驅動程式通常支援這項功能 (比方說 PSCRIPT 和 HPPCL) 使用半色調演算法來輸出良好的彩色影像。因此，維護 DIB 以最高的有意義的色彩解析度可能 (通常是 8 位元) 是令人滿意，即使輸出裝置是單色，因為色彩資訊仍然適用於好的輸出。不幸的是，大部分的印表機驅動程式並不支援 SRCCOPY 以外的其他任何 ROP。
回此頁最上方

CreateDIBPatternBrush()

這個函式可讓應用程式藉由指定的裝置相關點陣圖而不是 DIB CreatePatternBrush() 函式中使用時建立圖樣筆刷。使用這個函式建立筆刷會使用類似於任何其他的筆刷。[DIB 會轉換成裝置相關點陣圖 SelectObject() 次使用由裝置。這個筆刷類似標準的圖樣筆刷到裝置。
回此頁最上方

在 [剪貼簿 DIBS

將 DIB 放入剪貼簿中的兩個基本機制會使用 CF_DIB 資料格式或將 [DIB 放入中繼檔，使用 CF_METAFILEPICT 資料格式。

CF_DIB 格式使用在其位元，請遵循標頭及色彩表之後立即一個壓縮的 DIB。讀取或建立壓縮的 DIB 時, 應用程式必須適當地計算以確保在適當的地方是位元色彩資料表的大小。 因為所有 DIB 函式都預期之 DIB 為一個標頭，另一個為位元的兩個指標位元指標必須計算之前使用。(如色彩資料表大小計算請參閱上述色彩表格描述中的程式碼範例)。

將一個 DIB 放入中繼檔最簡單的方式是使用 StretchDIBits()： 
   hMetaDC = CreateMetaFile((LPSTR) NULL));
   StretchDIBits(hMetaDC, 0, 0, biWidth, biHeight, 0, 0, biWidth,

          biHeight, lpBits, lpInfo, DIB_RGB_COLORS, SRCCOPY);

   hMetafile = CloseMetaFile(hMF);
這種方法會產生一個中繼檔時播放顯示到目的地 DIB。這個方法也會縮放影像以符合目前的對應配置，如有需要。傳輸使用中繼檔可讓甚至不 DIB 感知貼上剪貼簿的內容而不會遺失 DIB 資訊的應用程式。
回此頁最上方

RLE 格式

當 DIB 的標頭中的 [biCompression] 欄位設定為任一 BI_RLE4 (biBitCount = 4) 或 BI_RLE8 (biBitCount = 8)，影像已經執行長度編碼。編碼配置的描述可在 「 Microsoft Windows 軟體開發套件參考磁碟區 2，"中找到 BITMAPINFOHEADER 」 一節 「 資料類型及結構 」 章節。基本配置牽涉到壓縮多到執行的編碼方式水平相鄰、 完全相同的像素。比方說 10 個像素的色彩索引 17 會編碼為執行和索引 17 的 10 個的長度。另外也提供了代碼對於結束掃描和 Delta 移，可在其中一個 X 和 Y 位移為提供下一個像素。

這種類型的編碼方式通常壓縮點陣圖，與也是非常好用來建立小精靈類型動畫中每個框架變更網頁時，其中只小型影像的一部分。動畫功能會藉由使用 Delta 代碼限制實際設定的像素數目達成的。略過由 Delta 移動的像素是左不變。

RLE DIB 的主要限制是應用程式不可以輕易地判斷 (以位元組為單位) 點陣圖的大小或指向特定 scanline 沒有解碼從第一個掃描點陣圖。biSizeImage 欄位是用於解決第一個問題。解碼、 編碼，和一般操作 [RLE 格式是速度較慢和較複雜比 noncompressed (BI_RGB) 格式。某些應用程式--，例如 [小畫家]--拒絕讀取 RLE DIB。雖然所有的 API 接受它們，RLE DIB 可能不會成為內文 」 普遍支援的格式。而且，因為的這些格式相對的 rarity，某些裝置驅動程式可能不具有完整的測試編碼和解碼程序的支援。

若要產生 RLE DIB，GetDIBits() 稱為與 biCompression 設為所要的編碼類型。不容易計算儲存位元所需的記憶體數量。如果 GetDIBits() 呼叫與 lpBits 設為 NULL，biSizeImage 會傳回所需的位元的記憶體數量。與 lpBits 指向正確大小的記憶體區塊的後續呼叫會傳回編碼的點陣圖。

將 RLE DIB 轉譯成裝置依存表單需要特殊的處理。Set 函式中的任何可用通常包含適當 biSizeImage 和 biCompression 值加入標頭來符合位元。
回此頁最上方

DIBS SHORTCOMINGS

可能的 DIB 最大的限制是它們是比裝置相關點陣圖更慢。將 DIB 轉譯成裝置相關表單，它們實際上可以顯示之前必須進行導致額外負荷的額外處理。在理想的世界 1-1 StretchDIBits() 會作為 BitBlt() 動作最快速度。此速度會讓應用程式邏輯點陣圖具有完整的色彩和完整存取權的實體裝置的限制而不考慮的每個像素的領域中有效地運作。

dIBs 以顛倒是相對於進行撰寫程式碼有點令並不容易瞭解的 Windows 的座標系統中。永遠記得這個 quirkiness 應該可以幫助取得點陣圖正確對齊所需的反覆運算次數的限制。

您可以取得完整的色彩使用 24 位元 DIB 但解碼、，讀寫的速度非常慢。這是如此的轉譯逐字可以採取分鐘的 8 位元調色盤裝置上。而且，十足的 24 位元 DIB 大小類病毒有點雜亂無章供一般用途使用。
回此頁最上方

在視窗 3.0 版 DIB 相關的問題

中繼檔錄製的使用 BITMAPCOREHEADER StretchDIBits() 呼叫將導致一個 UAE。將所有標頭轉換至 BITMAPINFO 樣式若要避免這個問題。這項因應措施建議用於一般 DIB 處理。

使用 SetDIBits()、 SetDIBitsToDevice() 或 StretchDIBits() 到不支援 SetDIBits() 的驅動程式時，為大於 64 K 單色 DIB SetDIBits() 模擬程式碼會會造成當機或錯誤的列印輸出。

由 Microsoft Corporation 的著作權 1992。 本電腦程式著作。
回此頁最上方
這篇文章中的資訊適用於:
  • Microsoft Windows Software Development Kit 3.1
回此頁最上方
關鍵字：?
kbmt kbdownload kbdownload kb16bitonly kbfile kbinfo kbsample KB81498 KbMtzh
回此頁最上方
機器翻譯機器翻譯
重要：本文是以 Microsoft 機器翻譯軟體翻譯而成，而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章，讓使用者可以依其使用語言使用知識庫中的所有文章。但是，機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤，就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本：81498? (http://support.microsoft.com/kb/81498/en-us/ )
回此頁最上方
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應，不負任何擔保責任。Microsoft及(或)其供應商謹此聲明，不負任何對與此資訊有關之擔保責任，包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。
Retired KB Article依現狀不再更新的知識庫內容免責聲明
本文旨在說明 Microsoft 不再提供支援的產品。因此，本文係依「現狀」提供，不會再更新。
回此頁最上方