BI_RGB rgb pixel format

This is the basic RBG bitmap format which comes in all the common bits per pixel flavours. 1, 4 and 8 bpp versions of the format are palettised and 16, 24 and 32 bpp contain direct colour information. In all cases, the bitmap comprises a rectangular array of packed pixels.

1bpp

Each pixel is represented by a single bit, giving 8 pixels per BYTE in memory. A 2 entry palette defines which colours are used to display the pixel if the bit is clear (palette entry 0) or set (palette entry 1). Despite the fact that this definition is apparently pretty clear, many display adapters and graphics applications appear to reverse the definition so, in my experience, you are never entirely sure if a 1bpp bitmap will be displayed as a positive or negative image.

4bpp

Each pixel here is represented by a nibble, giving 2 pixels per BYTE in memory. The 4 bits used for the pixel give rise to 16 possible values and, hence, a 16 entry colour palette is required to display the image.

8bpp

Each pixel here is represented by a BYTE, giving 256 possible values per pixel and, hence, requiring a 256 entry palette.

16bpp

Things were pretty simple up to now but some confusion is introduced by the 16bpp format. It's actually 15bpp since the default format is actually RGB 5:5:5 with the top bit of each u_int16 being unused. In this format, each of the red, green and blue colour components is represented by a 5 bit number giving 32 different levels of each and 32786 possible different colours in total (true 16bpp would be RGB 5:6:5 where there are 65536 possible colours). No palette is used for 16bpp RGB images - the red, green and blue values in the pixel are used to define the colours directly.

As an aside, most display drivers handle both RGB 5:5:5 and 5:6:5 formats but several video codecs get confused when asked to decompress to a 5:6:5 desktop so using 5:5:5 as the default is generally safer.

24bpp

We get back to predictable ground with 24bpp. Here a pixel is represented by 3 BYTES containing a red, blue and green sample (with blue stored at the lowest address, green next then red). No padding bytes are added between pixels. Although I can't find the information in any spec I have on my machine currently, I get the feeling that 24bpp images should be stored with each line padded to a u_int32 boundary. Information on http://www.mediatel.lu/workshop/graphic/2D_fileformat/h_bmp.html also suggests that this is true.

32bpp

This is another version of 24bpp where each pixel is padded to a u_int32. Although this is inefficient from a memory standpoint, processing u_int32s is a great deal easier than handling byte triples and the format is used by many graphics accelerators because of this.

Duplicate formats: RGB