Device-Independent Bitmaps (DIB)

A DIB consists of a header structure called a BITMAPINFOHEADER followed by the color palette, if one is present, followed by the bitmap (pixel) data:

BITMAPINFOHEADER

COLOR PALETTE (if any)

BITMAP DATA

The BITMAPINFOHEADER structure contains such information as the number of bits per pixel, number of pixels per row, and total number of rows in the image, as well as whether the bitmap data has been compressed for more efficient storage. Its form is shown below. Its fields are described in detail in the sections Core Component Data Types Reference and Core Component Structures Reference.

BITMAPINFOHEADER:	DWORD	biSize
	LONG	biWidth
	LONG	biHeight
	WORD	biPlanes
	WORD	biBitCount
	DWORD	biCompression
	DWORD	biSizeImage
	LONG	biXPelsPerMeter
	LONG	biYPelsPerMeter
	DWORD	biClrUsed
	DWORD	biClrImportant

A color palette is present in the DIB if the image is 1-bit, 4-bit, or 8-bit. The format of the color palette was described at the beginning of this chapter.

The format of the bitmap data is:

For 1-bit images, the first (leftmost) pixel of a row is held in the Most Significant Bit (MSB) of the first byte of the row. Subsequent bits hold subsequent pixels, at a rate of 8 pixels per byte. The row is padded with zeroes as necessary to assure a multiple of 4 bytes length for each row.
For 4-bit images, the first pixel of each row is in the 4 Most Significant Bits of the first byte of the row, and each succeeding 4 bits hold each succeeding pixel. As above, the row is zero-padded to a multiple of 4 bytes length.
For 8-bit and 24-bit images, each pixel of a row occupies exactly 1 or 3 bytes respectively, and again each row is padded with zeroes to a multiple of 4 bytes length. Note that the colors in a 24-bit pixel in a standard DIB are ordered Blue-Green-Red (not Red-Green-Blue).

It should be noted that in a DIB, the first row of the bitmap data is the row to be displayed at the bottom of the image. For historical reasons, many file formats store their bitmap data top row first (this is because most devices to which bitmap data is sent display the rows top-to-bottom. Such devices, which include most CRT display monitors, are often called raster-scan devices.).

Whenever ImageGear loads a file of a format having top-to-bottom row ordering, it automatically reverses the order of the rows, assuring bottom-to-top row ordering for all DIBs, regardless of where the image originated. Keep in mind the ordering of a DIB is therefore "upside down" relative to the convention used in much display software that the top row of a display is row 0 and row numbers increase downward. However, it is important to note, ImageGear's pixel access functions (such as IG_DIB_pixel_set()) consider the coordinates 0,0 to refer to the upper left-hand corner of the bitmap data. As with an image shown on the screen, the x values will increase toward the right, and the y values will increase toward the bottom.

See Also: