Convert TIFF to BMP

There is no picture-quality argument for this conversion. TIFF is the more capable format on every axis — more colour models, more bit depths, more pages, real compression options — and BMP is a Microsoft format from 1987 that stores a rectangle of pixels and almost nothing else. If you are here, a piece of software or hardware has told you what it accepts.

That is a legitimate and common situation. Laboratory and inspection applications, machine-vision tools, embedded displays, industrial controllers and a long tail of Windows programs written in the 1990s read BMP and only BMP, precisely because it is trivial to parse: a header, then the pixels, with no codec to license and no library to link. The conversion exists to satisfy that requirement, and the rest of this page is about doing it without silently damaging the image.

A 24-bit uncompressed BMP with a BITMAPINFOHEADER — the plain baseline that every reader ever written understands. Three details of the format are worth knowing if you are writing the code that consumes it: the rows are stored bottom to top, the channels are ordered blue, green, red rather than red, green, blue, and every row is padded out to a multiple of four bytes.

All three are in the specification rather than choices made here, and all three are the usual cause of an image that arrives upside down, blue where it should be red, or skewed diagonally. The resolution field is written as 2,835 pixels per metre, which is 72 dpi, and it is not carried across from the TIFF. Nothing much reads that field, but writing a zero into it makes some older viewers reject the file, so a real number goes in.

Both formats are uncompressed as they are written here, so the file size is arithmetic rather than a judgement. This site’s own 480 by 320 samples come out at 615,400 bytes as TIFF and 460,854 as BMP, every time, whatever the picture is.

The difference is the alpha channel: the TIFF written here stores four channels at 8 bits each and BMP stores three, so a quarter of the bytes disappear along with the transparency. Against a TIFF that was compressed with LZW or Deflate — which is most TIFFs from real scanners — the direction reverses sharply and the BMP can be several times larger. That is not a problem to solve, it is the format doing what it is for: a BMP is meant to be read without any decoding work at all.

BMP as produced here carries no alpha, so any transparency has to become something. The image is composited onto a solid background colour first, in the same pass as any resizing, which avoids the fringe of half-transparent pixels that flattening after a scale would leave behind.

The colour is white by default and there is a control for it. Choose it deliberately rather than accepting the default when the destination is a machine: an inspection routine that thresholds the image, or a display driver that treats one colour as its key, will behave completely differently against white than against black or magenta. If the transparency itself was the information — a mask, a segmentation, a cut-out region — then BMP cannot carry it at all and TIFF to PNG is the pair that can.

A great deal of instrument output is 16 bits per channel, and that is often where the measurement lives rather than where the picture lives. This pipeline decodes to 8 bits by keeping the high byte of each sample: measured on a 16-bit greyscale TIFF, a stored value of 30,000 comes back as 117.

For anything that will be looked at by a person, that is invisible; a screen shows eight bits. For anything that will be measured by software — densitometry, fluorescence intensity, a depth map, an elevation raster stored as a TIFF — it is a catastrophic and silent loss, and BMP could not have carried the extra bits anyway. If the destination software genuinely needs 16-bit data and genuinely only reads BMP, those two requirements are in conflict and the software is worth re-reading on the point.

TIFF is a container and holds several images per file; BMP holds one. The reader here takes page one and stops, with no error and nothing in the interface to mention that more existed. Scanners, fax gateways and records systems all produce multi-page TIFFs as a matter of course, so this is worth checking before a batch rather than after.

Splitting first is the fix — ImageMagick, IrfanView or the scanner’s own software will do it — and then each page converts to its own BMP. Layers go the same way and are flattened into the composite, which is almost always what was wanted. If the pages belong together and the destination can be persuaded to accept it, TIFF to PDF is the conversion that keeps all of them in one file.

A greyscale TIFF converts cleanly: the grey value is written into all three channels, so the BMP is grey and three times larger than it needs to be. A one-bit black-and-white scan does the same and is the worst case for size, because a fax page that occupied 40 kB as Group 4 becomes several megabytes of 24-bit pixels.

A CMYK TIFF — the kind a print workflow produces — is converted to RGB with a fixed formula rather than through the ICC profile embedded in the file. The picture is recognisable and the colours are not accurate, typically flat in the deep shadows. Since BMP has no concept of a colour profile either, there is nowhere for the correct answer to be stored even if it were computed. For anything colour-critical, do the conversion in software that honours the profile and bring the result here as an RGB TIFF.

TIFF readers disagree with each other more than any other format’s, so the coverage here was checked against files rather than against the specification. Uncompressed, LZW, Deflate, PackBits, JPEG-in-TIFF and Group 3 and Group 4 fax all decode, in colour, greyscale and one-bit black and white, tiled or in strips.

That covers essentially everything a document scanner, a camera tether or an archive produces. What it does not cover is a TIFF that is really something else wearing the extension — a camera raw file, which is structurally a TIFF and needs demosaicing rather than decoding. Those have their own pages under their own extensions. If a file is refused here, that is usually why.

Both halves run in the tab: utif2 reads the TIFF, and the BMP is written by hand in a few dozen lines because the format is a header and a block of pixels and does not justify shipping an image library. Nothing is uploaded, which matters when the images are patient records, inspection results or anything under a client agreement.

The free limit is 100 MB per file, and BMP output has no size ceiling of its own — unlike WebP, which stops at 16,383 pixels on an edge. Batches work: drop a folder, each file converts with its own progress row, and the results come back as a ZIP. Since BMP output is exactly three bytes per pixel, a batch of large scans produces a very large ZIP, which is worth knowing before starting one.