For BMP Suite version 2.6
This document describes the images in BMP Suite, and shows what I allege to be the correct way to interpret them. PNG and JPEG images are used for reference.
It also shows how your web browser displays the BMP images, but that’s not its main purpose. BMP is poor image format to use on web pages, so a web browser’s level of support for it is arguably not important.
File | Ver. | Correct display | In your browser | Notes |
---|---|---|---|---|
g/pal1.bmp | 3 | 1 bit/pixel paletted image, in which black is the first color in the palette. | ||
g/pal1wb.bmp | 3 | 1 bit/pixel paletted image, in which white is the first color in the palette. | ||
g/pal1bg.bmp | 3 | 1 bit/pixel paletted image, with colors other than black and white. | ||
q/pal1p1.bmp | 3 | 1 bit/pixel paletted image, with only one color in the palette. The documentation says that 1-bpp images have a palette size of 2 (not “up to 2”), but it would be silly for a viewer not to support a size of 1. | ||
q/pal2.bmp | 3 | A paletted image with 2 bits/pixel. Usually only 1, 4, and 8 are allowed, but 2 is legal on Windows CE. | ||
q/pal2color.bmp | 3 | Same as pal2.bmp, but with a color palette instead of grayscale palette. | ||
g/pal4.bmp | 3 | Paletted image with 12 palette colors, and 4 bits/pixel. | ||
g/pal4gs.bmp | 3 | Paletted image with 12 grayscale palette colors, and 4 bits/pixel. | ||
g/pal4rle.bmp | 3 | 4-bit image that uses RLE compression. | ||
q/pal4rletrns.bmp | 3 | or or |
An RLE-compressed image that uses “delta” codes to skip over some pixels, leaving them undefined. Some viewers make undefined pixels transparent, others make them black, and others assign them palette color 0 (purple, in this case). | |
q/pal4rlecut.bmp | 3 | or or |
An RLE-compressed image that uses “delta” codes, and early EOL & EOBMP markers, to skip over some pixels. It’s okay if the viewer’s image doesn’t exactly match any of the reference images. | |
g/pal8.bmp | 3 | Our standard paletted image, with 252 palette colors, and 8 bits/pixel. | ||
g/pal8-0.bmp | 3 | Every field that can be set to 0 is set to 0: pixels/meter=0; colors used=0 (meaning the default 256); size-of-image=0. | ||
g/pal8gs.bmp | 3 | An 8-bit image with a palette of 252 grayscale colors. | ||
g/pal8rle.bmp | 3 | 8-bit image that uses RLE compression. | ||
q/pal8rletrns.bmp | 3 | or or |
8-bit version of q/pal4rletrns.bmp. | |
q/pal8rlecut.bmp | 3 | or or |
8-bit version of q/pal4rlecut.bmp. | |
g/pal8w126.bmp | 3 | Images with different widths and heights. In BMP format, rows are padded to a multiple of four bytes, so we test all four possibilities. | ||
g/pal8w125.bmp | 3 | |||
g/pal8w124.bmp | 3 | |||
g/pal8topdown.bmp | 3 | BMP images are normally stored from the bottom up, but there is a way to store them from the top down. | ||
q/pal8offs.bmp | 3 | A file with some unused bytes between the palette and the image. This is probably valid, but I’m not 100% sure. | ||
q/pal8oversizepal.bmp | 3 | An 8-bit image with 300 palette colors. This may be invalid, because the documentation could be interpreted to imply that 8-bit images aren’t allowed to have more than 256 colors. | ||
g/pal8nonsquare.bmp | 3 |
or |
An image with non-square pixels: the X pixels/meter is twice the Y pixels/meter. Image editors can be expected to leave the image “squashed”; image viewers should consider stretching it to its correct proportions. | |
g/pal8os2.bmp | OS/2v1 | An OS/2-style bitmap. This format can be called OS/2 BMPv1, or Windows BMPv2. | ||
q/pal8os2-sz.bmp | OS/2v1 | Some OS/2 BMP specifications say that the size field in the file header should be set to the aggregate size of the file header and infoheader, instead of the total file size. For OS/2v1, that means it will always be 26. BMP decoders usually ignore this field, so it shouldn’t cause a problem. | ||
q/pal8os2-hs.bmp | OS/2v1 | Some OS/2 BMP specifications define the fields at offsets 6 and 8 to be a “hotspot” (for cursor graphics). Though the fields are not used in BMP files, they are sometimes, as in this file, set to nonzero values. This should cause no problems, except that it could prevent some programs from detecting this file as a BMP file. | ||
q/pal8os2sp.bmp | OS/2v1 | An OS/2v1 with a less-than-full-sized palette. Probably not valid, but such files have been seen in the wild. | ||
q/pal8os2v2.bmp | OS/2v2 | An OS/2v2 bitmap. | ||
q/pal8os2v2-16.bmp | OS/2v2 | An OS/2v2 bitmap whose header has only 16 bytes, instead of the full 64. | ||
q/pal8os2v2-sz.bmp | OS/2v2 | An OS/2v2 bitmap. Like q/pal8os2-sz.bmp, the size field is set to the size of the headers (78), instead of the size of the file. | ||
q/pal8os2v2-40sz.bmp | OS/2v2 | An OS/2v2 bitmap, with a 40-byte header. Like q/pal8os2-sz.bmp, the size field is set to the size of the headers (54), instead of the size of the file. Except for that, this file cannot be distinguished from a Windows BMPv3 file. | ||
q/rgb24rle24.bmp | OS/2v2 | An OS/2v2 bitmap with RLE24 compression. This image uses a limited number of colors, just to make it more compressible. | ||
q/pal1huff.bmp | OS/2v2 | My attempt to make a BMP file with Huffman 1D compression. It is quite possibly incorrect. Even if everything else about it is correct, I have no way to know whether it is black/white reversed, and/or flipped vertically. | ||
g/pal8v4.bmp | 4 | A v4 bitmap. I’m not sure that the gamma and chromaticity values in this file are sensible, because I can’t find any detailed documentation of them. Note that bmpsuite v2.4 and earlier had the gamma set differently (and probably incorrectly). | ||
g/pal8v5.bmp | 5 | A v5 bitmap. Version 5 has additional colorspace options over v4, so it is easier to create, and ought to be more portable. | ||
g/rgb16.bmp | 3 | A 16-bit image with the default color format: 5 bits each for red, green, and blue, and 1 unused bit. The whitest colors should (I assume) be displayed as pure white: (255,255,255), not (248,248,248). | ||
g/rgb16bfdef.bmp | 3 | Same format as rgb16.bmp, but with a BITFIELDS segment. | ||
g/rgb16-565.bmp | 3 | A 16-bit image with a BITFIELDS segment indicating 5 red, 6 green, and 5 blue bits. This is a standard 16-bit format, even supported by old versions of Windows that don’t support any other non-default 16-bit formats. The whitest colors should be displayed as pure white: (255,255,255), not (248,252,248). | ||
g/rgb16-565pal.bmp | 3 | A 16-bit image with both a BITFIELDS segment and a palette. | ||
q/rgb16faketrns.bmp | 3 | or maybe |
Same idea as q/rgb32fakealpha.bmp. The default 16-bit color format has one unused bit per pixel, and in this image some of the unused bits are set to 1. It’s possible that some viewers will interpret this image as having transparency. | |
q/rgb16-231.bmp | 3 | An unusual and silly 16-bit image, with 2 red bits, 3 green bits, and 1 blue bit. Most viewers do support this image, but the colors may be darkened with a yellow-green shadow. That’s because they’re doing simple bit-shifting (possibly including one round of bit replication), instead of proper scaling. | ||
q/rgb16-3103.bmp | 3 | Similar to q/rgb16-231.bmp, with 3 red bits, 10 green bits, and 3 blue bits. | ||
q/rgba16-4444.bmp | 5 | A 16-bit image with an alpha channel. There are 4 bits for each color channel, and 4 bits for the alpha channel. It’s not clear if this is valid, but I can’t find anything that suggests it isn’t. | ||
q/rgba16-5551.bmp | 5 | Similar to q/rgba16-4444.bmp, with 5 red bits, 5 green bits, 5 blue bits, and a 1-bit alpha channel. | ||
q/rgba16-1924.bmp | 5 | Similar to q/rgba16-4444.bmp, with 1 red bit, 9 green bits, 2 blue bits, and 4 bits for the alpha channel. | ||
g/rgb24.bmp | 3 | A perfectly ordinary 24-bit (truecolor) image. | ||
g/rgb24pal.bmp | 3 | A 24-bit image, with a palette containing 256 colors. There is little if any reason for a truecolor image to contain a palette, but it is legal. | ||
q/rgb24largepal.bmp | 3 | A 24-bit image, with a palette containing 300 colors. The fact that the palette has more than 256 colors may cause some viewers to complain, but the documentation does not mention a size limit. | ||
q/rgb24prof.bmp | 5 | My attempt to make a BMP file with an embedded color profile. | ||
q/rgb24prof2.bmp | 5 | This image tries to test whether color profiles are fully supported. It has the red and green channels swapped, and an embedded color profile that tries to swap them back. Support for this is uncommon. | ||
q/rgb24lprof.bmp | 5 | My attempt to make a BMP file with a linked color profile. Supporting linked profiles may be a bad idea, as it can lead to security vulnerabilities. | ||
q/rgb24jpeg.bmp | 5 | My attempt to make BMP files with embedded JPEG and PNG images.
These are not likely to be supported by much of anything (they’re
intended for printers). These image are stored in top-down order, with a positive bV5Height field. This might not be correct. The documentation is very confusing on this issue. |
||
q/rgb24png.bmp | 5 | |||
g/rgb32.bmp | 3 | A 32-bit image using the default color format for 32-bit images (no BITFIELDS segment). There are 8 bits per color channel, and 8 unused bits. The unused bits are set to 0. | ||
g/rgb32bfdef.bmp | 3 | Same format as rgb32.bmp, but with a BITFIELDS segment. | ||
g/rgb32bf.bmp | 3 | A 32-bit image with a BITFIELDS segment. As usual, there are 8 bits per color channel, and 8 unused bits. But the color channels are in an unusual order, so the viewer must read the BITFIELDS, and not just guess. | ||
q/rgb32h52.bmp | (52) | Similar to g/rgb32bf.bmp, but with a 52-byte “BITMAPV2INFOHEADER”. This is an uncommon version of BMP, and I can’t confirm that this file is correct. | ||
q/rgb32-xbgr.bmp | 5 | Color channels are the same size and order as rgb32bfdef.bmp, but they use the highest available bits, instead of the lowest (or vice versa, depending on your byte-order perspective). | ||
q/rgb32fakealpha.bmp | 3 | or |
Same as g/rgb32.bmp, except that the unused bits are set to something other than 0. If the image becomes transparent toward the bottom, it probably means the viewer uses heuristics to guess whether the undefined data represents transparency. Reportedly, in ICO icon format, a 32-bit image has transparency if any of the could-be alpha samples are nonzero. Some BMP decoders probably use the same algorithm for BMP. | |
q/rgb32-111110.bmp | 3 | A 32 bits/pixel image, with all 32 bits used: 11 each for red and green, and 10 for blue. As far as I know, this is valid, but it is unusual. | ||
q/rgb32-7187.bmp | 3 | A 32 bits/pixel image, with 7 bits for red, 18 for green, and 7 for blue. | ||
q/rgba32-1.bmp | 5 | A BMP with an alpha channel. Transparency is barely documented, so it’s possible that this file is not correctly formed. The color channels are in the usual order. | ||
q/rgba32-2.bmp | 5 | Same as q/rgba32-1.bmp, but with the color channels in an unusual order, to prevent viewers from passing this test by making a lucky guess. | ||
q/rgba32-1010102.bmp | 5 | A 32 bits/pixel image, with 10 bits for red, 10 for green, 10 for blue, and 2 for alpha. | ||
q/rgba32-81284.bmp | 5 | A 32 bits/pixel image, with 8 bits for red, 12 for green, 8 for blue, and 4 for alpha. | ||
q/rgba32-61754.bmp | 5 | A 32 bits/pixel image, with 6 bits for red, 17 for green, 5 for blue, and 4 for alpha. | ||
q/rgba32abf.bmp | 3 | An image of type BI_ALHPABITFIELDS. Supposedly, this was used on Windows CE. I don’t know whether it is constructed correctly. | ||
q/rgba32h56.bmp | (56) | Similar to q/rgba32-2.bmp, but with a 56-byte “BITMAPV3INFOHEADER”. This is an uncommon version of BMP, and I can’t confirm that this file is correct. | ||
x/ba-bm.bmp | OS/2v2 | This image uses the OS/2v2 “Bitmap Array” (BA) container format. Although a BA file may contain multiple images, this file has only one. | ||
b/badbitcount.bmp | 3 | N/A | Header indicates an absurdly large number of bits/pixel. | |
b/badbitssize.bmp | 3 | N/A | Header incorrectly indicates that the bitmap is several GB in size. | |
b/baddens1.bmp | 3 | N/A | Density (pixels per meter) suggests the image is much larger in one dimension than the other. | |
b/baddens2.bmp | 3 | N/A | ||
b/badfilesize.bmp | 3 | N/A | Header incorrectly indicates that the file is several GB in size. | |
b/badheadersize.bmp | ? | N/A | Header size is 66 bytes, which is not a valid size for any known BMP version. | |
b/badpalettesize.bmp | 3 | N/A | Header incorrectly indicates that the palette contains an absurdly large number of colors. | |
b/badplanes.bmp | 3 | N/A | The “planes” setting, which is required to be 1, is not 1. | |
b/badrle4.bmp | 3 | N/A | An invalid RLE4-compressed image that tries to cause buffer overruns. | |
b/badrle4bis.bmp | 3 | N/A | Another invalid RLE4-compressed image that tries to cause buffer overruns. | |
b/badrle4ter.bmp | 3 | N/A | Another invalid RLE4-compressed image that tries to cause buffer overruns. | |
b/badrle.bmp | 3 | N/A | 8-bit version of b/badrle4.bmp. | |
b/badrlebis.bmp | 3 | N/A | 8-bit version of b/badrle4bis.bmp. | |
b/badrleter.bmp | 3 | N/A | 8-bit version of b/badrle4ter.bmp. | |
b/badwidth.bmp | 3 | N/A | The image claims to be a negative number of pixels in width. | |
b/pal8badindex.bmp | 3 | N/A | Many of the palette indices used in the image are not present in the palette. | |
b/reallybig.bmp | 3 | N/A | An image with a very large reported width and height. | |
b/rgb16-880.bmp | 3 | (?) |
A 16-bit image with a BITFIELDS segment indicating 8 red, 8 green, and 0 blue bits. The documentation doesn’t say whether undefined channels are legal, or how they should be handled. | |
b/rletopdown.bmp | 3 | N/A | An RLE-compressed image that tries to use top-down orientation, which isn’t allowed. | |
b/shortfile.bmp | 3 | N/A | A file that has been truncated in the middle of the bitmap. |