Basic windows bitmap format

This article is about the file format. For the data structure/type of image, see Bitmap graphics.

Windows Bitmap

The BMP file format, or bitmap, is a raster graphics image file format used to store bitmap digital images, independently of the display device (such as a graphics adapter), especially on Microsoft Windows^[2] and OS/2^[3] operating systems.

The BMP file format is capable of storing two-dimensional digital images in various color depths, and optionally with data compression, alpha channels, and color profiles. The Windows Metafile (WMF) specification covers the BMP file format.^[4]

Microsoft has defined a particular representation of color bitmaps of different color depths, as an aid to exchanging bitmaps between devices and applications with a variety of internal representations. They called these device-independent bitmaps or DIBs, and the file format for them is called DIB file format or BMP image file format.

According to Microsoft support:^[5]

A device-independent bitmap (DIB) is a format used to define device-independent bitmaps in various color resolutions. The main purpose of DIBs is to allow bitmaps to be moved from one device to another (hence, the device-independent part of the name). A DIB is an external format, in contrast to a device-dependent bitmap, which appears in the system as a bitmap object (created by an application…). A DIB is normally transported in metafiles (usually using the StretchDIBits() function), BMP files, and the Clipboard (CF_DIB data format).

The following sections discuss the data stored in the BMP file or DIB in detail. This is the standard BMP file format.^[5] Some applications create bitmap image files which are not compliant with the Microsoft documentation. Also, not all fields are used; a value of 0 will be found in these unused fields.

The bitmap image file consists of fixed-size structures (headers) as well as variable-sized structures appearing in a predetermined sequence. Many different versions of some of these structures can appear in the file, due to the long evolution of this file format.

Referring to the diagram 1, the bitmap file is composed of structures in the following order:

A bitmap image file loaded into memory becomes a DIB data structure – an important component of the Windows GDI API. The in-memory DIB data structure is almost the same as the BMP file format, but it does not contain the 14-byte bitmap file header and begins with the DIB header. For DIBs loaded in memory, the color table can also consist of 16-bit entries that constitute indexes to the currently realized palette^[8] (an additional level of indirection), instead of explicit RGB color definitions. In all cases, the pixel array must begin at a memory address that is a multiple of 4 bytes. In non-packed DIBs loaded in memory, the optional color profile data should be located immediately after the color table and before the gap1 and pixel array (unlike in diag. 1).

When the size of gap1 and gap2 is zero, the in-memory DIB data structure is customarily referred to as «packed DIB» and can be referred to by a single pointer pointing to the beginning of the DIB header. In all cases, the pixel array must begin at a memory address that is a multiple of 4 bytes. In some cases it may be necessary to adjust the number of entries in the color table in order to force the memory address of the pixel array to a multiple of 4 bytes.^[8] For «packed DIBs» loaded in memory, the optional color profile data should immediately follow the pixel array, as depicted in diag. 1 (with gap1=0 and gap2=0).
«Packed DIBs» are required by Windows clipboard API functions as well as by some Windows patterned brush and resource functions.^[9]

This block of bytes is at the start of the file and is used to identify the file. A typical application reads this block first to ensure that the file is actually a BMP file and that it is not damaged. The first 2 bytes of the BMP file format are the character «B» then the character «M» in ASCII encoding. All of the integer values are stored in little-endian format (i.e. least-significant byte first).

This block of bytes tells the application detailed information about the image, which will be used to display the image on the screen. The block also matches the header used internally by Windows and OS/2 and has several different variants. All of them contain a dword (32-bit) field, specifying their size, so that an application can easily determine which header is used in the image. The reason that there are different headers is that Microsoft extended the DIB format several times. The new extended headers can be used with some GDI functions instead of the older ones, providing more functionality. Since the GDI supports a function for loading bitmap files, typical Windows applications use that functionality. One consequence of this is that for such applications, the BMP formats that they support match the formats supported by the Windows version being run. See the table below for more information.

Windows and OS/2 bitmap headers

OS/2 1.x bitmaps are uncompressed and cannot be 16 or 32 bpp.

The Windows 2.x BITMAPCOREHEADER differs from the OS/2 1.x BITMAPCOREHEADER (shown in the table above) in the one detail that the image width and height fields are signed integers, not unsigned.^[13]

Versions after BITMAPINFOHEADER only add fields to the end of the header of the previous version.
For example: BITMAPV2INFOHEADER adds fields to BITMAPINFOHEADER, and BITMAPV3INFOHEADER adds fields to BITMAPV2INFOHEADER.

An integrated alpha channel has been introduced with the undocumented BITMAPV3INFOHEADER and with the documented BITMAPV4HEADER (since Windows 95) and is used within Windows XP logon and theme system as well as Microsoft Office (since v2000); it is supported by some image editing software, such as Adobe Photoshop since version 7 and Adobe Flash since version MX 2004 (then known as Macromedia Flash). It is also supported by GIMP, Google Chrome, Microsoft PowerPoint and Microsoft Word.

For compatibility reasons, most applications use the older DIB headers for saving files. With OS/2 no longer supported after Windows 2000, for now the common Windows format is the BITMAPINFOHEADER header. See next table for its description. All values are stored as unsigned integers, unless explicitly noted.

The compression method (offset 30) can be:

An OS/2 2.x OS22XBITMAPHEADER (BITMAPINFOHEADER2 in IBM’s documentation) contains 24 additional bytes:^[3]

The halftoning algorithm (offset 60) can be:

The color table (palette) occurs in the BMP image file directly after the BMP file header, the DIB header, and after the optional three or four bitmasks if the BITMAPINFOHEADER header with BI_BITFIELDS (12 bytes) or BI_ALPHABITFIELDS (16 bytes) option is used. Therefore, its offset is the size of the BITMAPFILEHEADER plus the size of the DIB header (plus optional 12-16 bytes for the three or four bit masks).
Note: On Windows CE the BITMAPINFOHEADER header can be used with the BI_ALPHABITFIELDS^[6] option in the biCompression member.

The number of entries in the palette is either 2ⁿ (where n is the number of bits per pixel) or a smaller number specified in the header (in the OS/2 BITMAPCOREHEADER header format, only the full-size palette is supported).^[3][5] In most cases, each entry in the color table occupies 4 bytes, in the order blue, green, red, 0x00 (see below for exceptions). This is indexed in the BITMAPINFOHEADER in the structure member biBitCount.

The color table is a block of bytes (a table) listing the colors used by the image. Each pixel in an indexed color image is described by a number of bits (1, 4, or which is an index of a single color described by this table. The purpose of the color palette in indexed color bitmaps is to inform the application about the actual color that each of these index values corresponds to. The purpose of the color table in non-indexed (non-palettized) bitmaps is to list the colors used by the bitmap for the purposes of optimization on devices with limited color display capability and to facilitate future conversion to different pixel formats and palettization.

The colors in the color table are usually specified in the 4-byte per entry ARGB32 format. The color table used with the OS/2 BITMAPCOREHEADER uses the 3-byte per entry RGB24 format.^[3][5] For DIBs loaded in memory, the color table can optionally consist of 2-byte entries – these entries constitute indexes to the currently realized palette^[8] instead of explicit RGB color definitions.

Microsoft does not disallow the presence of a valid alpha channel bit mask^[15] in BITMAPV4HEADER and BITMAPV5HEADER for 1bpp, 4bpp and 8bpp indexed color images, which indicates that the color table entries can also specify an alpha component using the 8.8.8.[0-8].[0-8] format via the RGBQUAD.rgbReserved^[16] member. However, some versions of Microsoft’s documentation disallow this feature by stating that the RGBQUAD.rgbReserved member «must be zero».

As mentioned above, the color table is normally not used when the pixels are in the 16-bit per pixel (16bpp) format (and higher); there are normally no color table entries in those bitmap image files. However, the Microsoft documentation (on the MSDN web site as of Nov. 16, 2010^[17]) specifies that for 16bpp (and higher), the color table can be present to store a list of colors intended for optimization on devices with limited color display capability, while it also specifies, that in such cases, no indexed palette entries are present in this Color Table. This may seem like a contradiction if no distinction is made between the mandatory palette entries and the optional color list.

The bits representing the bitmap pixels are packed in rows (also known as strides or scan lines). The size of each row is rounded up to a multiple of 4 bytes (a 32-bit DWORD) by padding.^[18]

For images with height above 1, multiple padded rows are stored consecutively, forming a Pixel Array.

The total number of bytes necessary to store one row of pixels can be calculated as:

Картинка с сайта: en.wikipedia.org

The total number of bytes necessary to store an array of pixels in an n bits per pixel (bpp) image, with 2ⁿ colors, can be calculated by accounting for the effect of rounding up the size of each row to a multiple of 4 bytes, as follows:

ImageHeight is expressed in pixels. The absolute value is necessary because ImageHeight is expressed as a negative number for top-down images.

The pixel array is a block of 32-bit DWORDs, that describes the image pixel by pixel. Usually pixels are stored «bottom-up», starting in the lower left corner, going from left to right, and then row by row from the bottom to the top of the image.^[5] Unless BITMAPCOREHEADER is used, uncompressed Windows bitmaps also can be stored from the top to bottom, when the Image Height value is negative.

In the original OS/2 DIB, the only four legal values of color depth were 1, 4, 8, and 24 bits per pixel (bpp).^[5]
Contemporary DIB Headers allow pixel formats with 1, 2, 4, 8, 16, 24 and 32 bits per pixel (bpp).^[19] GDI+ also permits 64 bits per pixel.^[20]

Padding bytes (not necessarily 0) must be appended to the end of the rows in order to bring up the length of the rows to a multiple of four bytes. When the pixel array is loaded into memory, each row must begin at a memory address that is a multiple of 4. This address/offset restriction is mandatory only for Pixel Arrays loaded in memory. For file storage purposes, only the size of each row must be a multiple of 4 bytes while the file offset can be arbitrary.^[5] A 24-bit bitmap with Width=1, would have 3 bytes of data per row (blue, green, red) and 1 byte of padding, while Width=2 would have 6 bytes of data and 2 bytes of padding, Width=3 would have 9 bytes of data and 3 bytes of padding, and Width=4 would have 12 bytes of data and no padding.

• Indexed color images may be compressed with 4-bit or 8-bit RLE or Huffman 1D algorithm.
• OS/2 BITMAPCOREHEADER2 24bpp images may be compressed with the 24-bit RLE algorithm.
• The 16bpp and 32bpp images are always stored uncompressed.
• Note that images in all color depths can be stored without compression if so desired.

• The 1-bit per pixel (1bpp) format supports 2 distinct colors, (for example: black and white). The pixel values are stored in each bit, with the first (left-most) pixel in the most-significant bit of the first byte.^[5] Each bit is an index into a table of 2 colors. An unset bit will refer to the first color table entry, and a set bit will refer to the last (second) color table entry.
• The 2-bit per pixel (2bpp) format supports 4 distinct colors and stores 4 pixels per 1 byte, the left-most pixel being in the two most significant bits (Windows CE only:^[21]). Each pixel value is a 2-bit index into a table of up to 4 colors.
• The 4-bit per pixel (4bpp) format supports 16 distinct colors and stores 2 pixels per 1 byte, the left-most pixel being in the more significant nibble.^[5] Each pixel value is a 4-bit index into a table of up to 16 colors.
• The 8-bit per pixel (8bpp) format supports 256 distinct colors and stores 1 pixel per 1 byte. Each byte is an index into a table of up to 256 colors.
• The 16-bit per pixel (16bpp) format supports 65536 distinct colors and stores 1 pixel per 2-byte WORD. Each WORD can define the alpha, red, green and blue samples of the pixel.
• The 24-bit per pixel (24bpp) format supports 16,777,216 distinct colors and stores 1 pixel value per 3 bytes. Each pixel value defines the red, green and blue samples of the pixel (8.8.8.0.0 in RGBAX notation). Specifically, in the order: blue, green and red (8 bits per each sample).^[5]
• The 32-bit per pixel (32bpp) format supports 4,294,967,296 distinct colors and stores 1 pixel per 4-byte DWORD. Each DWORD can define the alpha, red, green and blue samples of the pixel.

In order to resolve the ambiguity of which bits define which samples, the DIB headers provide certain defaults as well as specific BITFIELDS, which are bit masks that define the membership of particular group of bits in a pixel to a particular channel. The following diagram defines this mechanism:

Картинка с сайта: en.wikipedia.org

Diag. 2 – The BITFIELDS mechanism for a 32-bit pixel depicted in RGBAX sample length notation

The sample fields defined by the BITFIELDS bit masks have to be contiguous and non-overlapping, but the order of the sample fields is arbitrary. The most ubiquitous field order is: Alpha, Blue, Green, Red (MSB to LSB). The red, green and blue bit masks are valid only when the Compression member of the DIB header is set to BI_BITFIELDS. The alpha bit mask is valid whenever it is present in the DIB header or when the Compression member of the DIB header is set to BI_ALPHABITFIELDS^[6] (Windows CE only).

Картинка с сайта: en.wikipedia.org

Diag. 3 – The pixel format with an alpha channel for a 16-bit pixel (in RGBAX sample Length notation) actually generated by Adobe Photoshop^[22]

Картинка с сайта: en.wikipedia.org

All of the possible pixel formats in a DIB

The BITFIELD mechanism described above allows for the definition of tens of thousands of different pixel formats, however only several of them are used in practice,^[22] all palettized formats RGB8, RGB4, and RGB1 (marked in yellow in the table above, defined in dshow.h.MEDIASUBTYPE names):

Uncompressed RGB Video Subtypes^[23]

Bit fields for ten RGB bits^[23]

In version 2.1.4 FFmpeg supported (in its own terminology) the BMP pixel formats bgra, bgr24, rgb565le, rgb555le, rgb444le, rgb8, bgr8, rgb4_byte, bgr4_byte, gray, pal8, and monob; i.e., bgra was the only supported pixel format with transparency.^[24]

Following is an example of a 2×2 pixel, 24-bit bitmap (Windows DIB header BITMAPINFOHEADER) with pixel format RGB24.

Following is an example of a 4×2 pixel, 32-bit bitmap with opacity values in the alpha channel (Windows DIB Header BITMAPV4HEADER) with pixel format ARGB32.

Note that the bitmap data starts with the lower left hand corner of the image.

The simplicity of the BMP file format, and its widespread familiarity in Windows and elsewhere, as well as the fact that this format is relatively well documented and has an open format, makes BMP a very common format that image processing programs from many operating systems can read and write. ICO and CUR files contain bitmaps starting with a BITMAPINFOHEADER.

Many older graphical user interfaces used bitmaps in their built-in graphics subsystems;^[25] for example, the Microsoft Windows and OS/2 platforms’ GDI subsystem, where the specific format used is the Windows and OS/2 bitmap file format, usually named with the file extension of .BMP.^[26]

While most BMP files have a relatively large file size due to lack of any compression (or generally low-ratio run-length encoding on palletized images), many BMP files can be considerably compressed with lossless data compression algorithms such as ZIP because they contain redundant data. Some formats, such as RAR, even include routines specifically targeted at efficient compression of such data.

The X Window System uses a similar XBM format for black-and-white images, and XPM (pixelmap) for color images. There are also a variety of «raw» formats, which save raw data with no other information. The Portable Pixmap (PPM) and Truevision TGA formats also exist, but are less often used – or only for special purposes; for example, TGA can contain transparency information.

• Bitmap File Structure, at digicamsoft.com
• An introduction to DIBs (Device Independent Bitmaps), at herdsoft.com
• A simple bitmap loader C++ class, at kalytta.com (A2R10G10B10 not yet supported)
• The BMP File Format, Part 1 By David Charlap at Dr. Dobb’s journal of software tools (drdobbs.com), March 1995

BMP file format

Applies to:

BG1, BG1: TotS, BG2, BG2: ToB, PST, IWD, IWD:HoW, IWD:TotL, IWD2

General Description

http://www.daubnet.com/formats/BMP.html

Table of Contents

• Basic Description
• Basic File Format
• Raster Data Encoding
• Portability
• Trademarks, Patents and Royalties
• Cross Checking Software
• Resources
  • Online
  • Paper

Last updated: Jan 14. 1998

Basic Description
This file format is the MS-Windows standard format. It holds black&white-,
16-color, 256-color and Truecolor images. The palletized 16-color and 256-color
images may be compressed via run length encoding. Notice there is also a OS/2-BMP format.

Basic File Format

Portability
Although BMPs were invented by Microsoft for its Windows platform,
a lot of programs on other platforms are capable of reading and
writing them. Notice the Intel order in 2byte and 4-byte integer values
(Least significant byte first). The 16bit BMPs have been introduced to
Windows after the others, still puzzling many applications.

Trademarks, Patents and Royalties
To my knowledge: None.

Cross-Checking Software
This section is for programmers, who wish to cross-check their implementation
with others. This is an incomplete list of programs, which are available as
freeware / shareware / try-before-buy etc.

The following software is able to decode BMP files

• easiest: Make the file the MS-Windows’ background.
• MS-Paint / Paintbrush
• JASC Paint Shop Pro

The following software is able to encode BMP files

• JASC Paint Shop Pro
• MS-Paint / Paintbrush

Online Resources
http://www.dcs.ed.ac.uk/~mxr/gfx/

Paper Resources
MS-Windows SDK
[German:] Referenzhandbuch Dateiformate by Günter Born.

The following suggestions are from the Graphics Fileformats FAQ:

• Inside Windows File Formats, Tom Swan, Sams Publishing 1993.
  ISBN 0-672-30338-8 $24.95 softcover, 337 pages and 1 disk (3.5 in.).
  Order: Sams Publishing, 2201 West 103rd Street, Indianapolis,
  IN 46290 
• Luse, Marv. «The BMP File Format,» Dr. Dobb’s Journal, #219 September
  1994 (Vol 9, Issue 10), pp. 18-22.
  code available at: ftp://ftp.mv.com/pub/ddj/1994/1994.09/bmp.zip
• The BMP File Format: Part I+II, Dr.
  Dobb’s Journal, David Charlap, #228+#229
  March+April 1995 (Vol. 20, Issue 3+4).
  code available at: ftp://ftp.mv.com/pub/ddj/1995/1995.03/bmp.zip

Private Sub Command1_Click()
'объявим переменные с типами наших структур
Dim bmpInfo As BITMAPINFOHEADER
Dim bmpType As BITMAPFILEHEADER
'откроем файл для двоичного доступа
Open App.Path & "\untitled.bmp" For
Binary As #1
'читаем первую структуру (14 байт от начала файла)
Get #1, , bmpType
'читаем вторую структуру (40 байт) с 15-го байта, т.е.
с байта, на котором остановилась первая структура
Get #1, , bmpInfo
' закрываем файл и выводим нашу информацию в Text1
Close #1
Text1 = "Тип изображения " & bmpType.bfType & vbCrLf
Text1 = Text1 & "Размер файла=" & bmpType.bfSize & vbCrLf
Text1 = Text1 & "Ширина картинки=" & bmpInfo.biWidth &
vbCrLf
Text1 = Text1 & "Высота картинки=" & bmpInfo.biHeight &
vbCrLf
End Sub

На всякий случай скачать
исходник этого кода можно здесь.

Private Sub Command1_Click()
'Сначала объявим переменные
Dim FileName As String
'имя открываемого файла
Dim TypeOfFile As String
'тип файл (BM)
Dim b As Byte
Dim RazmW As String
'ширина изображения
Dim RazmH As String
'высота изображения
Dim RazmF As String
'размер файла в байтах
Dim x As Long
'установим имя файла
FileName = App.Path & "\untitled.bmp"
'и откроем его
Open FileName For Binary
As #1
'Первым делом, нам надо установить, что это файл BMP,

' в противном случае, считываемая информация будет неверна. Первые два байта
должны
' содержать символы "BM". Считываем эти 2 байта в переменную TypeOfFile.
TypeOfFile = String(2, " ")
Get #1, , TypeOfFile
'Проверяем, эти ли символы
If TypeOfFile = "BM" Then
'если да, то выводим в Text1 соответствующий текст
Text1 = "BMP-файл" & vbCrLf

Далее, читаем размер файла.
Он находится в байтах 3, 4, 5 и 6. Однако порядок записи данных в формате BMP
таков, что старший байт находится в младшем, т.е нам наши четыре байта надо
читать наоборот, с 6-го по 3-й. Сделаем это в цикле.

For x = 6 To 3 Step
-1
Get #1, x, b

С каждым тактом цикла в переменную
b будет считываться один байт. Он будет в десятичной системе счисления
(0, 1, 59,128). Но из этого мы не можем получить число, соответствующее размеру
файла. Нам нужны данные в шестнадцатеричной форме. Перевести можно с помощью
функции Hex. Но и этого недостаточно. Если у нас в байте было число,
например 0D, то при переводе оно превратится в D, а это недопустимо, так как
полностью исказит результат. Поэтому я здесь применил такую лихую формулу. Смысл
ее в том, что в случае, если полученное шестнадцатеричное число состоит из одного
знака, мы вперед добавляем ноль.

RazmF = RazmF & String((Len(Hex(b))
— 2) * -1, 0) & Hex(b)

Таким образом, наши десятичные
числа b преобразуются в строковые шестнадцатеричные и, сцепляясь в переменной
RazmF образуют строковое шестнадцатеричное число: RazmF = «00» &
«01» & «3B» & «80» = «13B80».
Это и есть искомый размер файла. Нам надо только перевести его в десятичную
систему счисления. Для этого можно использовать функцию ConvertDec() в стандартном
модуле Модуль1. Подробное описание алгоритма и кода функции можно прочитать
в статье «Шестнадцатеричное представление
числа. Перевод из шестнадцатеричной системы счисления в десятичную».

Next
x
'Переводим число в десятичное и получаем как раз 80768
байт - размер файла. Выводим это в Text1
Text1 = Text1 & "Размер файла = " & ConvertDec(RazmF) &
" bytes" & vbCrLf
'ширину получаем точно также
For x = 22 To 19 Step
-1
Get #1, x, b
RazmW = RazmW & String((Len(Hex(b)) - 2) * -1, 0) & Hex(b)
Next x
Text1 = Text1 & "Ширина изображения = " & ConvertDec(RazmW)
& " pixels" & vbCrLf
'аналогично получаем и высоту
For x = 26 To 23 Step
-1
Get #1, x, b
RazmH = RazmH & String((Len(Hex(b)) - 2) * -1, 0) & Hex(b)
Next x
Text1 = Text1 & "Высота изображения = " & ConvertDec(RazmH)
& " pixels" & vbCrLf
Else
' если файл начинается не с BM выводим соответствующий
текст
Text1 = "Это не BMP-файл"
End If
Close
End Sub

Вот, в общем, и вся реализация.
Скачать исходник примера «InfoBMP» можно вверху страницы.
Продолжение практического анализа графических форматов GIF и JPG (JFIF) смотри
в следующих статьях.

Chances are you’ve created or seen a bitmap file before, it’s a binary file so it won’t be easily deciphered by a plain text editor but at its core it’s basically a large array of pixel data. We’ll examine the structure of bitmap files and write a small function to create one. We are using the bitmap format because of how simple it is, there are simpler more archaic formats such as ppm which can actually be created with a text editor but requires a 3rd party program to view.

Bitmaps aren’t very common especially when we have made such advancements in image compression technology over the last few decades, such things as pngs, mozilla jpeg and bulky formats such as psd.

What we will be writing is a function to save a 24 bit bitmap without compression. This tutorial is also more about implementing a file format from specifications as opposed to creating images as there are faster formats such as PPM.

Bitmap format

Basically a bitmap file has a header (or two depending on how you class them) and then a body, the rest are optional and not really needed if you just want to get something out. See BMP_file_format#/File_structure.

Notice 3 structures that aren’t optional, those are what we need. They are Bitmap file header, DIB/image header and pixel array. Also note the size restriction(s), the file header has to be 14 bytes while our pixel array can be as large as we want. A larger image will lead to a larger file size as we will see soon.

Again, the file header has exactly 14 bytes split into 5 fields

Implementation

Let’s start by creating a struct to hold some simple RGB data.

struct rgb_data {
    float r, g, b;
};

Next we create the function definition

void save_bitmap(const char *file_name, int width, int height, int dpi, rgb_type *pixel_data);

As input we take a filename, a width, height, dpi (dots per inch) and our array of pixels that we want to use to construct the image.

// create a file object that we will use to write our image
FILE *image;
// we want to know how many pixels to reserve
int image_size = width * height;
// a byte is 4 bits but we are creating a 24 bit image so we can represent a pixel with 3
// our final file size of our image is the width * height * 4 + size of bitmap header
int file_size = 54 + 4 * image_size;
// pixels per meter https://www.wikiwand.com/en/Dots_per_inch
int ppm = dpi * 39.375;

// bitmap file header (14 bytes)
// we could be savages and just create 2 array but since this is for learning lets
// use structs so it can be parsed by someone without having to refer to the spec

// since we have a non-natural set of bytes, we must explicitly tell the
// compiler to not pad anything, on gcc the attribute alone doesn't work so
// a nifty trick is if we declare the smallest data type last the compiler
// *might* ignore padding, in some cases we can use a pragma or gcc's
// __attribute__((__packed__)) when declaring the struct
// we do this so we can have an accurate sizeof() which should be 14, however
// this won't work here since we need to order the bytes as they are written
struct bitmap_file_header {
    unsigned char   bitmap_type[2];     // 2 bytes
    int             file_size;          // 4 bytes
    short           reserved1;          // 2 bytes
    short           reserved2;          // 2 bytes
    unsigned int    offset_bits;        // 4 bytes
} bfh;

// bitmap image header (40 bytes)
struct bitmap_image_header {
    unsigned int    size_header;        // 4 bytes
    unsigned int    width;              // 4 bytes
    unsigned int    height;             // 4 bytes
    short int       planes;             // 2 bytes
    short int       bit_count;          // 2 bytes
    unsigned int    compression;        // 4 bytes
    unsigned int    image_size;         // 4 bytes
    unsigned int    ppm_x;              // 4 bytes
    unsigned int    ppm_y;              // 4 bytes
    unsigned int    clr_used;           // 4 bytes
    unsigned int    clr_important;      // 4 bytes
} bih;

// if you are on Windows you can include <windows.h>
// and make use of the BITMAPFILEHEADER and BITMAPINFOHEADER structs

memcpy(&bfh.bitmap_type, "BM", 2);
bfh.file_size       = file_size;
bfh.reserved1       = 0;
bfh.reserved2       = 0;
bfh.offset_bits     = 0;

bih.size_header     = sizeof(bih);
bih.width           = width;
bih.height          = height;
bih.planes          = 1;
bih.bit_count       = 24;
bih.compression     = 0;
bih.image_size      = file_size;
bih.ppm_x           = ppm;
bih.ppm_y           = ppm;
bih.clr_used        = 0;
bih.clr_important   = 0;

image = fopen(file_name, "wb");

// compiler woes so we will just use the constant 14 we know we have
fwrite(&bfh, 1, 14, image);
fwrite(&bih, 1, sizeof(bih), image);

// write out pixel data, one last important this to know is the ordering is backwards
// we have to go BGR as opposed to RGB
for (int i = 0; i < image_size; i++) {
   rgb_data BGR = data[i];

   float red   = (BGR.r);
   float green = (BGR.g);
   float blue  = (BGR.b);

   // if you don't follow BGR image will be flipped!
   unsigned char color[3] = {
       blue, green, red
   };

   fwrite(color, 1, sizeof(color), image);
}

fclose(image);

Now let’s render out a sample image

int width  = 400,
    height = 400,
    dpi = 96;

rgb_data *pixels = new rgb_data[width * height];

for (int x = 0; x < width; x++) {
    for (int y = 0; y < height; y++) {
        int a = y * width + x;

        if ((x > 50 && x < 350) && (y > 50 && y < 350)) {
            pixels[a].r = 255;
            pixels[a].g = 255;
            pixels[a].b = 5;
        } else {
            pixels[a].r = 55;
            pixels[a].g = 55;
            pixels[a].b = 55;
        }
    }
}

save_bitmap("black_border.bmp", width, height, dpi, pixels);

Voila, you’ve created a bitmap.

Картинка с сайта: ricardolovelace.com

You can take it the next step and probably look at the compression field and see if you can make any changes to the filesize or reverse the save_bitmap(...) function to read one instead and use some SetPixel() function in a library such as SDL to draw a bitmap on screen.