An old-style color bitmap is a little more complex and extremely device dependent. A color bitmap is organized to facilitate the transfer of the bits to a particular output device. Whether the bitmap is organized as a series of color planes or as multiple color bits per pixel depends on the device for which the bitmap is suitable.
Let's look first at a bitmap that has a bmBitsPixel field of 1 (which means that it has 1 color bit per pixel) but a bmPlanes value greater than 1. A color bitmap for the EGA or VGA is a good example. Windows uses the 4 color planes of the EGA or VGA to display 16 colors, so bmPlanes is 4. The array of bits begins with the top scan line. The color planes for each scan line are stored sequentially—the red plane first, the green plane, the blue plane, and the intensity plane. The bitmap then continues with the second scan line.
A bitmap can also represent color as a multiple number of bits per pixel. Suppose a device (such as the IBM 8514/A) can represent 256 colors using 8 color bits (1 byte) per pixel. For each scan line, the first byte represents the color for the leftmost pixel, the second byte represents the color for the next pixel, and so forth. The bmWidthBytes value in the BITMAP structure reflects the increased byte width of each scan line, but the bmWidth value is still the number of pixels per scan line.
Here's the catch: Nothing in the bitmap specifies how these multiple color planes or multiple color bits correspond to actual display colors. A particular color bitmap is suitable only for an output device with display memory organized like the bitmap. For instance, suppose you have a device that stores color information using 8 bits per pixel, but the 256 values are interpreted by the device differently than on the 8514/A. This is perfectly legitimate, but a bitmap created for the 8514/A would have incorrect colors on this other device.
The device-independent bitmap solves this problem, as we'll see shortly.