diff --git a/Base/home/anon/LaunchServer.ini b/Base/home/anon/LaunchServer.ini index afee2ab19f..9615345d47 100644 --- a/Base/home/anon/LaunchServer.ini +++ b/Base/home/anon/LaunchServer.ini @@ -1,6 +1,7 @@ [FileType] png=/bin/QuickShow gif=/bin/QuickShow +bmp=/bin/QuickShow html=/bin/Browser wav=/bin/SoundPlayer txt=/bin/TextEditor diff --git a/Base/res/html/misc/bmpsuite.html b/Base/res/html/misc/bmpsuite.html new file mode 100644 index 0000000000..ceebd7a3ee --- /dev/null +++ b/Base/res/html/misc/bmpsuite.html @@ -0,0 +1,902 @@ + +
+ + + +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. | +