Convert ICO to BMP

Both come from Microsoft and they were designed together. The original icon format did not wrap a separate image at all: each entry held a bitmap header followed by colour data and a one-bit mask saying which pixels to leave alone. An ICO was, quite literally, bitmaps in a directory with a stencil attached.

The two then diverged. Icons gained a proper eight-bit alpha channel with Windows XP and the ability to carry a PNG payload with Vista, which is what modern icon files use for their large entries. The bitmap written by this converter is the 24-bit baseline, which never gained either. Converting one to the other is therefore a step backwards in capability, undertaken because something on the other end needs it.

The encoder writes 24 bits per pixel: eight of blue, eight of green, eight of red, and nothing else. There is a BMP header variant that defines an alpha channel, and files using it exist, but almost nothing reads it reliably — which is exactly the reliability problem BMP is usually chosen to avoid.

So the transparency has to go somewhere before the encoder runs, and the background setting decides where. White is the default. Choose the colour of whatever surface the bitmap will be drawn on: an installer banner background, the panel colour on an embedded display. On a test icon with transparent corners the result read 255,255,255 in the corner, which is correct and is also the wrong answer if the panel is dark grey.

This is not a fault and it is the whole reason BMP exists. Every pixel occupies three bytes regardless of what it is, so the file size is arithmetic rather than a result: width times three, rounded up to a multiple of four, times height, plus 54 bytes of header.

For a 256-pixel square that is 768 bytes per row and 196,608 bytes of pixels, giving 196,662 in total. Measured against the 8,471-byte test icon it came from, the bitmap is more than twenty-three times the size. If the destination has a size limit, do that multiplication before you convert rather than after.

The largest one in the file. Decoding is done by your browser’s icon reader, which returns the biggest entry in the directory — checked by building a file with 16, 32, 48 and 256 pixel drawings in four different colours and converting it with the directory written in three different orders. The 256-pixel drawing came out every time.

The smaller entries are not written anywhere and there is no setting that reaches them. If the software you are feeding wants a 32-pixel bitmap and the icon holds a 32-pixel entry, an icon editor such as GIMP will export that layer directly, which is a better result than scaling the 256-pixel version down.

Two details worth knowing if you are reading the bytes rather than opening the file. BMP stores its rows from the bottom of the image upwards, and it stores each pixel as blue, then green, then red. Both are in the specification and both regularly surprise somebody parsing one for the first time.

Each row is also padded to a multiple of four bytes, which matters at odd widths: a 33-pixel-wide bitmap has 99 bytes of colour per row and one byte of padding, making the stored row 100. At 256 pixels the row is 768 bytes and no padding is needed, which is one reason icon-sized bitmaps are easy to work with by hand.

Because reading one requires no decoder. A microcontroller driving a small display can copy bytes from a file into a framebuffer with a loop and a header offset; adding a PNG decoder to that firmware means adding a decompressor, a memory allocator and a chunk parser to a device that may have 32 KB of RAM.

The same reasoning applies to installer resources, to older Windows controls that load resources through the platform’s own bitmap functions, and to test fixtures that want to compare images byte for byte without a codec in the way. In all of those, predictability is worth far more than size.

Both formats are lossless, and this path has no quality setting because there is nothing to trade. Every pixel that survives the flattening is bit for bit what the icon stored, so converting the same file twice gives identical output and there is no generation loss to worry about if it passes through the step again later.

The two things that are genuinely lost are the alpha channel, replaced by the background colour, and the other entries in the container. Neither is recoverable from the bitmap afterwards, which is the argument for keeping the original icon file rather than replacing it.

If the destination is modern software with a stated preference rather than a hard requirement, a PNG is smaller by two orders of magnitude and keeps the transparency. The same test icon was 1,737 bytes as a PNG against 196,662 as a bitmap — a difference large enough to be worth one email asking whether BMP is genuinely required.

Where the answer is yes — firmware, an installer script, a fixture with a byte-level comparison — the bitmap is correct and the size is the price of being readable without a decoder. Say that in the commit message, because a 200 KB file for a small icon looks like a mistake to whoever reviews it next.

Drop the whole set. Each file is decoded, flattened onto the same background colour and written out separately, with everything returned as a ZIP. A shared background across the batch is usually what these destinations need, since the images are being composited onto one surface.

Check the dimensions in the result rather than assuming they match. Icon sets built up over years mix entries that reach 256 pixels with ones that stop at 32, and the bitmaps inherit that spread — with a factor of sixty-four between the file sizes at the two extremes.