RGB pixel formats
ADVERTISEMENTSOverview
These formats are defined below. Click on the FOURCC to be taken to its definition.
Please see "Bitmap Orientation and biHeight" for important additional information. Also, if you are interested in RGB to YCrCb conversion, you may find this page helpful.
| Label | FOURCC in Hex | Bits per pixel | Description |
| BI_RGB | 0x00000000 | 1,4,8,16,24,32 | Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples. |
| RGB | 0x32424752 | 1,4,8,16,24,32 | Alias for BI_RGB |
| BI_RLE8 | 0x00000001 | 8 | Run length encoded 8bpp RGB image. |
| RLE8 | 0x38454C52 | 8 | Alias for BI_RLE8 |
| BI_RLE4 | 0x00000002 | 4 | Run length encoded 4bpp RGB image. |
| RLE | 0x34454C52 | 4 | Alias for BI_RLE4 |
| BI_BITFIELDS | 0x00000003 | 16,24,32 | Raw RGB with arbitrary sample packing within a pixel. Packing and precision of R, G and B components is determined by bit masks for each. |
| raw | 0x32776173 | ? | Apparently "raw, uncompressed RGB bitmaps" but I have no idea how many bits per pixel (uses bpp field in header?) |
| RGBA | 0x41424752 | 16,32 | Raw RGB with alpha. Sample precision and packing is arbitrary and determined using bit masks for each component, as for BI_BITFIELDS. |
| RGBT | 0x54424752 | 16,32 | Raw RGB with a transparency field. Layout is as for BI_RGB at 16 and 32 bits per pixel but the msb in each pixel indicates whether the pixel is transparent or not. |
BI_RGB
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.
BI_RLE8
The following definition and example are quoted from the Windows 3.1 API online help file.
"When the biCompression member is set to BI_RLE8, the bitmap is compressed using a run-length encoding format for an 8-bit bitmap. This format may be compressed in either of two modes: encoded and absolute. Both modes can occur anywhere throughout a single bitmap.
Encoded mode consists of two bytes: the first byte specifies the number of consecutive pixels to be drawn using the color index contained in the second byte. In addition, the first byte of the pair can be set to zero to indicate an escape that denotes an end of line, end of bitmap, or a delta. The interpretation of the escape depends on the value of the second byte of the pair. The following list shows the meaning of the second byte:
Value Meaning 0 End of line 1 End of bitmap 2 Delta. The two bytes following the escape contain unsigned values indicating the horizontal and vertical offset of the next pixel from the current position. Absolute mode is signaled by the first byte set to zero and the second byte set to a value between 0x03 and 0xFF. In absolute mode, the second byte represents the number of bytes that follow, each of which contains the color index of a single pixel. When the second byte is set to 2 or less, the escape has the same meaning as in encoded mode. In absolute mode, each run must be aligned on a u_int16 boundary.
The following example shows the hexadecimal values of an 8-bit compressed bitmap:
03 04 05 06 00 03 45 56
67 00 02 78 00 02 05 01
02 78 00 00 09 1E 00 01This bitmap would expand as follows (two-digit values represent a color index for a single pixel):
04 04 04
06 06 06 06 06
45 56 67
78 78
move current position 5 right and 1 down
78 78
end of line
1E 1E 1E 1E 1E 1E 1E 1E 1E
end of RLE bitmap"
BI_RLE4
The following definition and example are quoted from the Windows 3.1 API online help file.
"When the biCompression member is set to BI_RLE4, the bitmap is compressed using a run-length encoding (RLE) format for a 4-bit bitmap, which also uses encoded and absolute modes. In encoded mode, the first byte of the pair contains the number of pixels to be drawn using the color indexes in the second byte. The second byte contains two color indexes, one in its high-order nibble (that is, its low-order four bits) and one in its low-order nibble. The first of the pixels is drawn using the color specified by the high-order nibble, the second is drawn using the color in the low-order nibble, the third is drawn with the color in the high-order nibble, and so on, until all the pixels specified by the first byte have been drawn.
In absolute mode, the first byte contains zero, the second byte contains the number of color indexes that follow, and subsequent bytes contain color indexes in their high- and low-order nibbles, one color index for each pixel. In absolute mode, each run must be aligned on a u_int16 boundary. The end-of-line, end-of-bitmap, and delta escapes also apply to BI_RLE4.
The following example shows the hexadecimal values of a 4-bit compressed bitmap:
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01
04 78 00 00 09 1E 00 01This bitmap would expand as follows (single-digit values represent a color index for a single pixel):
0 4 0
0 6 0 6 0
4 5 5 6 6 7
7 8 7 8
move current position 5 right and 1 down
7 8 7 8
end of line
1 E 1 E 1 E 1 E 1
end of RLE bitmap"
BI_BITFIELDS
To allow for arbitrarily packed RGB samples, BI_BITFIELDS specifies a mask field for each of the red, green and blue pixel components. These masks indicate the bit positions occupied by each colour component in a pixel. In general, the masks are passed to a driver or video API using means other than a basic BITMAPINFOHEADER (such as using the appropriate fields in a DirectDraw DDPIXELFORMAT structure) but I have heard that it is valid to append the masks to the end of the BITMAPINFOHEADER in much the same way that a palette is appended for palettised formats.
For example, 16 bit RGB 5:6:5 can be described using BI_BITFIELDS and the following bitmasks:
| Red | 0xF800 (5 bits of red) |
| Green | 0x07E0 (6 bits of green) |
| Blue | 0x001F (5 bits of blue) |
In this case, if used with a BITMAPINFOHEADER, the bitmasks are u_int16s (16 bit) since the biBitFields field is set to 16. For a 32bpp version, the bitmasks are each u_int32s.
RGBA
This format is an extension of BI_BITFIELDS where a fourth bitmask is used to define bits in the pixel which correspond to an alpha channel. When displayed on top of other images, RGBA pixels are blended with the background pixel according to the value of this alpha component.
For example, a 32bpp RGBA image would likely use the top 8 bits of each u_int32 to store the alpha component (the unused byte in normal 32bpp RGB). In this case, the masks reported would be:
| Red | 0x00FF0000 |
| Green | 0x0000FF00 |
| Blue | 0x000000FF |
| Alpha | 0xFF000000 |
giving 256 levels of blending per pixel (8 bits of alpha data).
In general, the masks used for this format are passed using a means other than a BITMAPINFOHEADER (for example, in DirectDraw, the DDPIXELFORMAT structure contains fields specifically for R,G,B and Alpha masks) but I have also heard that it is acceptable to append 4 u_int32s to the end of the BITMAPINFOHEADER structure containing the mask information.
RGBT
This format can be thought of as a simple extension to the basic 16bpp and 32bpp flavours of BI_RGB. RGBT uses the most significant bit of the pixel (unused in RGB 16bpp and 32bpp) to indicate transparency. If the bit is set, the pixel is visible, otherwise it is transparent. You can also think of this as a version of RGBA where the alpha channel comprises a single bit.
Bayer Data Formats
Recently, a collection of "Bayer" data formats have been registered. These encode images with only a single color sample at each pixel position and are frequently used in acquisition of digital images where the image is captured through a color filter array. It is not clear to me how these formats define the layout of the filter array used but it may be fair to assume that they relate to a commonly used Bayer pattern originally developed by Kodak which has builds an image out of 2x2 blocks containing green samples in the top left and bottom right positions, red in the top right and blue in the bottom left.
Silicon Imaging's web site offers further explanation here.