Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
BMP file format
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=== Pixel storage === 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.<ref name="Image Stride">{{Cite web|url=https://learn.microsoft.com/en-us/windows/win32/medfound/image-stride|title=Image Stride - Win32 apps|website=learn.microsoft.com}}</ref> 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: <math display="block">\text{RowSize} = \left\lceil\frac { \text{BitsPerPixel} \cdot \text{ImageWidth}}{32}\right\rceil \cdot 4 = \left\lfloor\frac { \text{BitsPerPixel} \cdot \text{ImageWidth}+31}{32}\right\rfloor \cdot 4,</math> {{block indent|left=1.5|1=''ImageWidth'' is expressed in pixels. The equation above uses the [[floor and ceiling functions]].}} The total number of bytes necessary to store an array of pixels in an <var>n</var> bits per pixel (bpp) image, with [[power of two|2<sup><var>n</var></sup>]] 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: <math display="block">\text{PixelArraySize} = \text{RowSize} \cdot |\text{ImageHeight}|</math> {{block indent|left=1.5|1=''ImageHeight'' is expressed in pixels. The absolute value is necessary because ''ImageHeight'' is expressed as a negative number for top-down images.}} ==== Pixel array (bitmap data) ==== 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.<ref name="DIBhelp" /> Unless {{mono|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).<ref name=DIBhelp/> Contemporary DIB Headers allow pixel formats with 1, 2, 4, 8, 16, 24 and 32 bits per pixel (bpp).<ref>MSDN - {{mono|BITMAPINFOHEADER}}: [http://msdn.microsoft.com/en-us/library/dd183376%28VS.85%29.aspx The member biBitCount]</ref> [[Graphics Device Interface|GDI+]] also permits 64 bits per pixel.<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/ms536393(v=vs.85).aspx|publisher=[[Microsoft Developer Network|MSDN]]|title=Types of Bitmaps|date=2012-06-03|access-date=2014-03-16}}</ref> 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.<ref name="DIBhelp" /> 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. ==== Compression ==== * [[palette (computing)|Indexed]] color images may be compressed with 4-bit or 8-bit [[Run-length encoding|RLE]] or [[Huffman coding|Huffman]] 1D algorithm. * [[OS/2]] {{mono|BITMAPCOREHEADER}}2 [[color depth|24bpp]] images may be compressed with the 24-bit RLE algorithm. * The [[color depth|16bpp]] and [[color depth|32bpp]] images are '''always stored uncompressed.''' * Note that images in all color depths can be stored without compression if so desired. ==== Pixel format ==== * 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.<ref name="DIBhelp" /> 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:<ref name="PSformats">MSDN: [http://msdn.microsoft.com/en-us/library/ms959648.aspx Windows CE - {{mono|BITMAPINFOHEADER}} Structure]</ref>). 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]].<ref name="DIBhelp" /> 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 [[Sample (graphics)|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).<ref name="DIBhelp" /> * 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 (digital image)|channel]]. The following diagram defines this mechanism: {{Plain image with caption|BitfieldsSLN.svg|Diag. 2 β The BITFIELDS mechanism for a 32-bit pixel depicted in RGBAX sample length notation|753px|center}} 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<ref name=AlphaBitFields/> ([[Windows CE]] only). {{Plain image with caption|SLNotation44440.svg|Diag. 3 β The pixel format with an alpha channel for a 16-bit pixel (in RGBAX sample Length notation) actually generated by Adobe Photoshop<ref name=PSformats2>Adobe Photoshop: [http://livedocs.adobe.com/en_US/Photoshop/10.0/WSfd1234e1c4b69f30ea53e41001031ab64-7751.html BMP Format] {{Webarchive|url=https://web.archive.org/web/20110922225022/http://livedocs.adobe.com/en_US/Photoshop/10.0/WSfd1234e1c4b69f30ea53e41001031ab64-7751.html |date=2011-09-22 }}</ref>|448px|center}} {{Plain image with caption|AllBMPformats.png|All of the possible pixel formats in a DIB|700px|center}}
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)