diff --git a/Base/res/html/misc/bmpsuite.html b/Base/res/html/misc/bmpsuite.html deleted file mode 100644 index ceebd7a3ee..0000000000 --- a/Base/res/html/misc/bmpsuite.html +++ /dev/null @@ -1,902 +0,0 @@ - -
- - - -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. | -