Talk:BMP file format

message: the header of a file should be callled a signature. If you look up closely you may find a name when reading a signature. In the case of BMP files if you don't have the two starting bits to tell you how to interpret the next bytes, including size, it won't tell you it's a BMP. So I propose to use the HEADER term to acces the next structure, where is the information on the 'details' of the image. ANy program acceses the BMP file and first search it to find out it's BMP it's looking at. Then looks up at the 4-17 bytes to read the information on the image properties.
Would anyone agree Header refferes to the first two bytes, and the rest of the bytes up to the 17 are coding the BMP's <private> signature ? "Private" because there may be two signatures for BMPs, but can be only one header.
Paul188.25.52.8 (talk) 12:42, 6 January 2011 (UTC)
replies: text: Please don't mess with the commonly accepted terminology. —Ippopotamus (talk) 23:09, 6 January 2011 (UTC)
thread_title: header vs signature

message: I think it would improve readability to not start counting from one again after the header.  Saying "It starts at byte #15 of the file" and then saying "Bytes #1-4 specify the header size." doesn't really make sense. --Trent Arms 13:53, 2 June 2006 (UTC)
replies: text: Hi. I agree with your suggestion. I think it makes more sense to count continuously from 1 to 54. Thanks for taking the efforts to make the necessary changes! --Mdanh2002 14:01, 6 June 2006 (UTC)

text: Happy new year 2011 ! Paul188.25.52.8 (talk) 12:52, 6 January 2011 (UTC)
thread_title: counting

message: Is there a preferred MIME Type for Windows bitmaps?  Out of all that I've seen, "image/x-windows-bmp" is the least ambiguous, but it doesn't follow the same pattern as ICO's "image/vnd.microsoft.icon".  —TheMuuj Talk 23:02, 9 July 2006 (UTC)
replies: text: Preferred by who? Microsoft prefers image/bmp, although this lacks the x- prefix that is (if I remember rightly) required for unofficial MIME media types. --Zundark 12:32, 10 July 2006 (UTC)
replies: text: For one, what do most browsers expect?  I know IE doesn't really care about MIME types anyway, so that's not important.  I was trying to configure a web application to properly serve Windows bitmaps and I checked Wikipedia (since pages for other formats have mime-types), but this article does not list a mime-type.  I'm not very fond of image/bmp as it's unofficial, although I guess the format is used enough for that to be acceptable.  But to be fair, this is not the only format to have ever used the ".bmp" extension.  Anyway, if there is a overall consensus on the mime-type it should be in the article, even if it is qualified with "(unofficial)" I suppose. —TheMuuj Talk 20:49, 10 July 2006 (UTC)
thread_title:  MIME Type? 

message: It seems that IBM also worked on this file format, but it's not reported here. It is only said that BMP was developed by Microsoft. Does anybody know more about this? 16@r 13:52, 10 July 2006 (UTC)
replies: text: It's possible, as IBM and Microsoft used to work together quite a bit.  I do remember that IBM had their own "bmp" format for OS/2.  I don't know if they share the same origin, though, or even what the differences are.  Plus, I haven't seen an OS/2 bitmap in years.  —TheMuuj Talk 20:51, 10 July 2006 (UTC)
replies: text: See http://netghost.narod.ru/gff/graphics/summary/os2bmp.htm for OS/2 bitmap info. Note that OS/2 V1 and Windows V2 bitmaps are identical.VMS Mosaic 00:32, 11 July 2006 (UTC)
thread_title:  Developed by ? 

message: Usually bitmap files are in Blue-Green-Red format, as described in the page. However, I've noticed that the screenshots that Guild Wars outputs are actually... Green-Red-Blue. The Windows viewer shows them correctly, so I guess there is something in the header that defines this. Which bytes are responsible for the RGB order? If it is already mentioned in the page, I'm sorry for asking such a dumb question. ;)
:I would guess they are bitfield bitmaps which are not mentioned in the article (actually there is a lot not discussed in the article; it only covers the basics).  Can you make one of the screenshots available on the web so that I can tell you for sure what the format is? VMS Mosaic 00:03, 9 September 2006 (UTC)
replies: text: Here is the file with the header info: . The file doesn't seem to be compressed, as you can see. About the picture now, notice that the status bars are (starting from top): Green, Red, Blue. But, if you load the file with the usual BGR order, you'll see that the bars are Blue, Green, Red respectively (so, in some way, you can determine the order of the colors in the file with these bars, heheh). --TEO 12:28, 9 September 2006 (UTC)
replies: text: I don't have a Windows system and the file appears to be in some Windows' archive format.  I might be able to local a Windows system somewhere, but a raw BMP file or a more common archive format (e.g., zip, tar, gzip) would be okay.VMS Mosaic 21:59, 9 September 2006 (UTC)
replies: text: Sorry about that... I uploaded it as an achive to include the header in TXT. I thought of using imageshack for the image file, but I wasn't sure whether sites like that keep the original format or perform any kind of compression. So, here's the new link, ZIP this time:  --TEO 17:55, 10 September 2006 (UTC)

text: It appears to be a normal non-bitfield image.  The problem is that there is a two byte gap after the header which causes the image data to be shifted two bytes.  Most viewers can deal with "non_standard" headers, but a few cannot. The start of the image data is specified in bytes 10-13. VMS Mosaic 22:34, 10 September 2006 (UTC)
thread_title:  BGR 

message: I think it would be really useful to have the hexadecimal position of different parts of the header in addition to the decimal one.  If no one disagrees, I'll go ahead and add it.
203.79.95.93 10:15, 26 September 2006 (UTC)
replies: text: Why not... Go on ;) --TEO 19:45, 10 November 2006 (UTC)
replies: text: Well, I don't think it would be useful, and it would lower the signal to noise ratio of the article. Shinobu (talk) 16:10, 19 December 2008 (UTC)

text: the rank assumed when this details gets confusing for some readers, but you are welcome to cross link to the mp3-article secondary articles.Paul188.25.52.8 (talk) 16:12, 6 January 2011 (UTC)
thread_title: Hex

message: As I was writing a program to output bitmaps I noticed that MS Paint saves them using big endian. My program uses little endian, so the bitmaps my program produced could not be viewed by Win XP preview or MS Paint. The successfully identified dimensions and header data, they just didn't display them. --81.235.198.59 01:18, 15 May 2007 (UTC)
replies: text: Yes, could you do it? See WP:SOFIXIT. --Kubanczyk 20:12, 24 October 2007 (UTC)
thread_title:  Endianness 

message: Windows and/or OS/2 bitmap as graphical file format may be just "bitmap", but "bitmap" is not only way to represent graphical files. --Yonkie 06:07, 27 May 2007 (UTC)
thread_title:  bitmap 

message: What is the difference between .PNG and .BMP? They look the same according the images! --  PNiddy  Go!  0 18:57, 5 August 2007 (UTC)
replies: text: PNG are compressed. BMPs have ridiculously large file sizes. 205.174.22.26 01:51, 23 August 2007 (UTC)
thread_title:  What's Different? 

message: I read the article and noticed that it mentions Windows and OS2.
How long ago was it developed?
Who developed the format? Was it Microsoft or someone else?
Was it used for Windows 3.1? ( I assume so, am I correct?)
Perhaps a "History" section be added to the article to answer those and other questions.
Regards,
JohnI 22:45, 29 August 2007 (UTC)
replies: text:  I came here looking for the same thing, a history is much needed in the article, all the other formats have one. Spladam (talk) 07:14, 15 August 2015 (UTC)
thread_title:  Development history would be good to know 

message: We have two articles on file formats: bitmap and bitmap image format.  But no article on the generic concept of a bitmap, which way predates these file formats.  Why not merge bitmap into bitmap image format, and write an article here on generic bitmaps.  If you look at what links here, that would make a lot more sense for most of them.  Opinions?  Dicklyon 22:50, 13 September 2007 (UTC)
replies: text: Agreed.  This article should be about the bitmap concept. VMS Mosaic 23:23, 13 September 2007 (UTC)
thread_title: Move, merge, generalize, or something

message: The article has begun to discuss compressed bitmap file formats, but Kubanczyk has objected, removing JPEG, PNG, GIF, and TIFF, which are among the most commonly used file formats for storing and transferring bitmaps.  Maybe we need a clearer distinction between file format for bitmaps and file formats that are literally bitmaps? Dicklyon 21:37, 18 September 2007 (UTC)
replies: text: Glad that you have noticed that. I try really hard to keep WP:COMMONNAME in mind. Happy editing. --Kubanczyk 21:51, 18 September 2007 (UTC)

text: I have a bit of a problem with JPEG as a bitmap.  It is a lossy format.  It does not contain a map of bits (compressed or uncompressed) which have a one-to-one (or several to one in the case of pixmaps) relationship with the image pixels. If you use JPEG to store a bitmap, you cannot get that bitmap back (you can only get an approximation of it back). VMS Mosaic 23:20, 18 September 2007 (UTC)
replies: text: JPEG contains a bitmap (in the sense of a raster), it's just a slightly different bitmap than before compression :))  Still I don't see a reason to mention JPEG/GIF/... at all. This is covered in Raster graphics. --Kubanczyk 07:21, 19 September 2007 (UTC)
replies: text: No, it's not covered there.  And the JPEG specification does allow for a lossless form, if that's what you need (as do all the others mentioned). Dicklyon 15:50, 19 September 2007 (UTC)

text: Is this article about image file formats which store images internally using a bitmap or is it about formats which store raster graphics?  If the former, then JPEG does not belong because a "standard baseline" (i.e., lossy) JPEG does not in any real sense contain a bitmap (or even, in a strict sense, a raster). A JPEG instead contains a set of mathematical relationships generated from a bitmap. I believe this article should be limited to image file formats which store images internally using a bitmap. VMS Mosaic 17:18, 19 September 2007 (UTC)
replies: text: And I believe the article should be about bitmaps, including ways of storing them.  It is certainly not uncommon to speak of JPEG files as containers for bitmaps (see for example this page or this book or this other book).  We shouldn't support the restriction of the generic term bitmap that Microsoft has promulgated. Dicklyon 17:50, 19 September 2007 (UTC)
replies: text: In that case this article needs completely redone into a much more general discussion of the 'bitmap' concept.  Having a specific method of storing a 'bitmap' using a 'bitmap' intermixed with a generic discussion of the term 'bitmap' in relation to raster graphics will be nothing but a confused misleading mess. The current article leads the reader to believe that "standard baseline" JPEGs store images as bitmaps using bitmaps, which is wrong.  Note that the JPEG article uses the term 'bitmap image' in comparison to 'JPEG image'. VMS Mosaic 18:19, 19 September 2007 (UTC)
replies: text: How does "Most other image file formats, such as JPEG, TIFF, PNG, and GIF, to name just a few, also do ultimately store bitmap images (as opposed to vector images), but they are not as often called bitmaps, since they use compressed formats internally" mislead anyone?  I agree the article needs more work, to finish the generalization from one format to the more general concept, unless we decide to go the other way, as mentioned in the section below. Dicklyon 18:23, 19 September 2007 (UTC)
replies: text: Would "Many other image file formats, such as JPEG, TIFF, PNG, and GIF, to name just a few, are used to store bitmap images (as opposed to vector images), but they are not usually referred to as bitmaps, since they use compressed formats internally." be acceptable?  Actually, it is still inaccurate given that GIF does use an actual bitmap that is data compressed, just as the bitmap in a BMP can be data compressed using RLE (GIF simply uses a better type of data compression). VMS Mosaic 20:02, 19 September 2007 (UTC)
thread_title: Compressed bitmaps

message: This page is clearly not in proper context. It needs a lot of re-phrasing now. With all due respect, I would propose non-experts to temporarily restrain from editing. I'll repeat an important link to Microsoft documentation. It's pretty clear that Microsoft is all about meaning 2. Not meaning 1. That means BMP file is just a container, an auxiliary thing. It is only if you load full content into memory (WinAPI LoadBitmap() function) when it becomes a "Microsoftian bitmap", being bitmap=header+palette+bit_array. It is a "bitmap", and not a "BMP", what is a crucial component of API. --Kubanczyk 08:03, 24 September 2007 (UTC)
replies: text: Sorry, but "meaning 2" is bit too indirect at this point, since I can't find a numbered list.  But feel free to work on it.  When the bitmap from a BMP file in is memory, it's called a DIB, by the way, so let's use that in preference to the generic term bitmap where it applies. Dicklyon 14:17, 24 September 2007 (UTC)

text: The expert tag is not likely to help unless you say more here about what you think is wrong or what is needed.  It seems to me that the article does a good job of covered the topic spelled out in the title and lead.  If you're saying you want the topic expanded to be more about DIBs in memory, then say so clearly, or just do it; you may want to move the article again if that's what you have in mind.  And the link you provided as a clue just gets me a Microsoft server error. Dicklyon 14:22, 24 September 2007 (UTC)
replies: text: I'm sorry, I'm not an expert myself. I only programmed GUI in API for about a year and it was long time ago. I'll try to refresh my info, but I'm a bit busy now. What you call "DIBs in memory" is the key point here, not an expansion anyway. Link corrected. --Kubanczyk 16:22, 24 September 2007 (UTC)

text: I think the article content matches the title. I support non-Windows web browser code which handles all five versions of this format (and maintain the web page of example BMP images linked to by the article). I believe the audience for this article is anyone who wants/needs to understand the internal format of BMP files (i.e., it is not intended specifically for Windows programmers), therefore it should not have a Windows centric viewpoint as might be provided by a Windows 'expert'. VMS Mosaic 21:25, 24 September 2007 (UTC)
thread_title:  Not in proper context 

message: "all integers are stored in little-endian format": O RLY? This may be true for the order in which the bytes of words and dwords in the header are stored, however, for the actual pixels the story is entirely different. For two-colour images, the bits should be read from most significant to least. Similarly, in 16 colour images the most significant halves precede the least. Similarly, for true-colour images, the order is blue, green, red. Considering that the standard Windows colour definition is ffbbggrr16 where ff are two hex digits containing flags, bb two hex digits containing the blue value, etc. Would you save this as little-endian, it would appear like rr, gg, bb, ff. Note that ff is not saved to bitmaps since it's only used when specifying system colours and such, which are converted to RGB-only colours when drawn. So it appears that the actual image data saved is big-endian. (See ms-help://MS.PSDKXPSP2.1033/gdi/bitmaps_1rw2.htm in the Platform SDK for confirmation.) Shinobu (talk) 23:11, 17 February 2008 (UTC)
thread_title:  Byte order and bit order 

message: Who created it, how old is it, etc.  —Preceding unsigned comment added by 67.161.122.193 (talk) 07:51, 10 March 2008 (UTC)
replies: text: Yep, that certainly needs to be there. I recommend this article that goes into a lot of detail, including the evolution of the various structures. I think we can use that as a cite when we add information to this article. Shinobu (talk) 04:16, 14 March 2008 (UTC)
replies: text: Where are any references to a specification for the Windows .bmp file format? Links to copies of the original spec aren't good enough if they don't cite their sources. What happened to 'verifiability'? I can't verify these copies against an original. Compare with the article on GIF for instance which does give a link to the specification. Nick 3216 (talk) 10:06, 28 July 2008 (UTC)

text: Well, if I understand correctly, the BMP format got started as a simple dump of a bitmap structure + data, preceded by a header. So that would mean the original specification would be the relevant structure (BITMAPCOREHEADER) in the relevant OS/2 and Windows header files, the documentation for which is now at ms-help://MS.PSDKXPSP2.1033/gdi/bitmaps_7jaq.htm in the Platform SDK. (This format was extended several times.) Before that only device dependent bitmaps were used, which were also essentially just a simple dump of a bitmap structure, this time BITMAP (the documentation for which is now at ms-help://MS.PSDKXPSP2.1033/gdi/bitmaps_2h6a.htm) except instead of the pointer to the data the data is written to the file. That, and books etc. written by third parties, is as close as we're going to get. Remember that we're writing 1985 here. Shinobu (talk) 16:04, 19 December 2008 (UTC)
thread_title:  Bitmap history. 

message: Hi. For 1 bit bitmap rowsize should be : "The width of a pf1bit Scanline in bytes is Bitmap.Width DIV 8 if the width is a multiple of 8. If width is not a multiple of 8, use the following to calculate the number of bytes: 1 + (Bitmap.Width-1) DIV 8" efg's Manipulating Pixels With Delphi's ScanLine Property. For example for Width = 1000 this gives 125 ( good result), while  equation floor((Width+31)/32)*4;  gives 128 ( bad result). What do you think ? --Adam majewski (talk) 16:17, 8 May 2008 (UTC)
replies: text: Your ref is a dead link.  Microsoft says the scanlines are dword aligned, so the formula in the article is correct and yours if wrong, if that's so. Dicklyon (talk) 17:58, 8 May 2008 (UTC)

text: The bit you quote does not appear to be talking about BMP format, but about some other structure. The MS link works for me. Dicklyon (talk) 20:34, 8 May 2008 (UTC)

text: You have not made an error; but the formula you're using may not apply to BMP format. Dicklyon (talk) 07:07, 9 May 2008 (UTC)
thread_title:  rowsize 

message: Please see the discussion at Talk:Image file formats#Naming_conventions_for_image_file_formats on naming conventions for articles on image file formats. Dcoetzee 00:47, 25 October 2008 (UTC)
thread_title:  Naming conventions for image file formats 

message: User:71.32.43.159 asks me via off-wiki email re his edit that I largely undid:
:I was wondering why you removed my most of my edit http://en.wikipedia.org/wiki/BMP_file_format#Bitmap_data ?
:Is it that you do not wish people to easily understand how to access data?
:If my information is incorrect fine but you removed the information that I found the hardest to locate on the web so I thought it would be helpfully to have it available to all.
:Please respond I am interested in improving my post.
In my edit summarized as "remove prescriptive advice and copyedit the new material," I took out the code examples and statements like "To access the data simply read each char and then grab the first 4 bits and then the second 4 bits" as being too prescriptive.  See WP:NOTHOWTO.  I also tried to fix a lot of redundancy and poor expository order.  If I dropped anything important, please do put it back. Dicklyon (talk) 16:33, 15 December 2008 (UTC)
replies: text: For this sort of thing we should really either provide tables or link appropriate specifications. It doesn't make sense to describe how to parse a file format in English prose. Dcoetzee 02:48, 16 December 2008 (UTC)
replies: text: Also not so helpful in C code, in my opinion.  I think there's plenty of info in the article already, so anyone competent could write code as needed; and the relevant docs are referenced already. Dicklyon (talk) 03:00, 16 December 2008 (UTC)

text: I've added an explicit English statement of the endianness of pixels within bytes, with link to the doc that says so.  If I got this right, the code that I removed for the 1-bit case was probably wrong, as it appears to assume that 32-bit values are big-endian in the file, which is backwards, no?  Was the code tested?  Do I misunderstand it? Dicklyon (talk) 03:12, 16 December 2008 (UTC)
thread_title:  Prescriptive advice removed 

message: The support of per-pixel-alpha in BMP files and in CF_DIB or CF_DIBV5 bitmaps on the Windows clipboard (which are supposed to have an identical format to BMP files, just without the BMPFILEHEADER) is very vaguely documented by Microsoft, and it is hard to find sample files. Anybody have any pointer to some definite documentation and sample files?
I have been hacking on support for copy-pasteing of images with alpha between GTK+ and other apps on Windows this weekend, and am really getting sick of this. It seems that when copying an image with alpha (from a PNG) from Firefox or IE7 to the clipboard, the 32-bit DIB one then in another app gets from the clipboard is of 32-bit BI_RGB type, and the "extra" bytes are in fact alpha. However, the alpha is premultiplied in the rgb bytes! Nowhere is this documented as far as I know?
I have not managed to programmatically produce any kind of trivial test bmp file with partial transparency that would look correct when inserted into Word or Powerpoint 2007, or viewed in Explorer, IE7 or Firefox. Not even files with 32-bit V5 (BITMAPV5HEADER) data in BI_BITFIELDS format that to the best of my knowledge should be the only BMP or DIB format that documentedly and unambiguously can store per-pixel-alpha work. Sigh...
Oh well, luckily at least MS Office 2007 also offers images copied to the clipboard in unambiguous PNG format. TorLillqvist (talk) 22:17, 18 January 2009 (UTC)
replies: text: You might be interested in wikia:vb:How to draw the mouse pointer dynamically.frm. It dynamically creates a bitmap with per-pixel-alpha for use as a cursor. Additionally, you could take apart Windows theme files, they are DLL's that contain images with per-pixel-alpha. As you mention BMP uses premultiplied alpha, this is common in the case where it's likely that they have to be drawn without hardware accelleration. For extensive information on BMP files, the corresponding objects in memory, and the concepts and functions involved, please consult the Platform SDK, it has a chapter on bitmaps. Oh, and as a footnote, that Windows supports something doesn't necessarily mean that (badly written) applications support it. 82.139.87.41 (talk) 14:21, 13 March 2009 (UTC)

text: I just discovered that Windows' SystemParametersInfo function doesn't support new style bitmaps. :-) 82.139.87.182 (talk) 22:39, 4 October 2009 (UTC)
thread_title:  Per-pixel-alpha? 

message: To me the most unusual characteristic of the BMP format is that the pixel lines are stored in bottom up order.
Years ago I wrote a program to convert .IMG scan files produced by WIPS software for a Xerox Datacopy 730 scanner to .PCX run length encoded for file export via floppy diskette. I added support for .BMP and .RLE formats. The first thing I discovered was that the "first" scan line in the .BMP file is the bottom line of pixels in the image (whereas in the .IMG and .PCX format the first scan line in the file is the top line). Naaman Brown (talk) 14:57, 24 September 2009 (UTC)
thread_title:  BMP line order 

message: Should I add an 4x2 Pixel, 32bits (BGRA) bitmap example? 110.174.48.248 (talk) 06:05, 30 October 2010 (UTC)
replies: text: Added it anyways Xp ~kotarou3 07:45, 30 October 2010 (UTC)
replies: text: Very nice, I could use it for "Portable Arbitrary Map" (PAM) format on Netpbm. –Be..anyone (talk) 15:54, 11 March 2014 (UTC)
thread_title:  4x2 Pixel, 32bit Bitmap Example 

message: The image is interesting, but I'm not sure how to interpret it: Apparently the 2nd part matches the 4th part, and the 3rd part matches the 5th part. Part 4+5 explain that the different header formats correspond to compression BI_ALPHABITFIELDS vs. BI_BITFIELDS. So actually there are only three variants for the purposes of this image, V2 without alpha mask needs BI_BITFIELDS, V3 with alpha mask needs BI_ALPHABITFIELDS, and V4 can handle everything.  The EGFF page has V3 as "version 3 for NT", and explains that compression has to be 3 if bitfield masks are used. EGFF also has V4, adding alpha mask bits + color space fields. 
A Mozilla BMPFileHeaders.h page claims 4 instead of 3, that sounds plausible — 3 vs. 4 bit field masks corresponding to format version 3 vs. 4, and maybe also Windows NT 3 vs. NT 4. But the article says BI_ALPHABITFIELDS 6, with JPEG 4 and PNG 5. EGFF is too old for this detail. For the GIMP value 4 and all alpha code was removed with extreme prejudice in 2012, because they found no working BMP using this feature in the wild. Well, and I find no official header file with the exact value. I've added a citation request for now.
Assuming that BI_ALPHABITFIELDS exists outside of dead CE platforms, and is in fact 6 (or 4, whatever works), the image here could be trimmed to its parts 1+4+5 (parts 2+3 would be redundant) and added to the article, full width. –Be..anyone (talk) 19:35, 11 March 2014 (UTC)
replies: text: It seems the Chrome clipboard function doesn't even handle this properly; it dumps a DIB on the clipboard which has the 40-byte BITMAPINFOHEADER, and uses BI_BITFIELDS, and yet puts alpha into the image data itself. In such an image there is no way to distinguish RGB from ARGB, and a programmer just has to pray that the alpha bytes are either all cleared to zero so they are detectable, or used as alpha, and not just never-overwritten memory junk from the saving process. What a gigantic mess. -Nyerguds (talk) 10:53, 18 September 2017 (UTC)
thread_title:  BI_ALPHABITFIELDS sanity check 

message: The lead is too general for a file format and need to include a summary of the rest of the article.
The lead did a very good job of not telling what the file format is, which fails Wikipedia:Manual of Style (lead section)'s lead "The lead should define the topic and summarize the body of the article with appropriate weight.". The file format has a proper lead that says it is a particular way data are stored. However the lead of this article goes into details about where the file format is supported, what can be stored in the format, without definding what the file format actually is? A definition should be able to distingush itself from its peeers, and besides the names everyone knew about, the lead can be applied to basically every other image file format. Quote: "The BMP File Format is capable of storing 2D digital images of arbitrary width, height, and resolution, both monochrome and color, in various color depths, and optionally with data compression, alpha channels, and color profiles.". It is like saying a person in the United States is capable of driving and speak English in the person's wikipedia article. 
I made an attempt to put a summary of the rest of article with due weight of their usage freqency in the lead but got reverted for giving up details and duplicating with the rest of the article. So I give up, and let the rest of you decide how best to fix the lead.--Skyfiler (talk) 23:03, 22 May 2011 (UTC)
thread_title: Lead section

message: On February 8 user David D Allen made a revision in the description of DIB header changing the BITMAPCOREHEADER2/OS22XBITMAPHEADER to a variable size.
Specifically he changed the BITMAPCOREHEADER2 / BITMAPCOREHEADER2 size from 64 to 12-64 bytes making it indistinguishable from the following header types:
BITMAPCOREHEADER / OS21XBITMAPHEADER - 12 bytes 			
BITMAPINFOHEADER - 40 bytes 
BITMAPV2INFOHEADER - 52 bytes
BITMAPV3INFOHEADER - 56 bytes
...because these header types are differentiated by their size, not by their contents.
Programs that would follow this badly revised documentation would be unable to distinguish between the above DIB Headers. This would generate serious bugs in implementations. Especially for DIBs in memory where the Bitmap File Header is absent.
As someone who created most of this article (and the main illustration), I am announcing my intent to revert this revision, if someone does not provide a good argument or documentation for keeping the DIB header size ambiguity within a week.
Please, note that I will not accept an explanation in the style that "some program XYZ treats some BITMAPCOREHEADER2 fields as optional" as this does not prove anything and individual implementations do not constitute documentation.  Even Adobe Photoshop makes serious implementation errors with Alpha channels.
Verpies (talk)  —Preceding undated comment added 10:47, 27 March 2012 (UTC)
replies: text: I say go for it. The less ambiguity and conflicting info, the better. The article has gotten so confusing, I have trouble understanding some of it (and I support a decoder which handles all of the possible BMP formats including the alpha channel). VMS Mosaic (talk) 04:41, 12 April 2012 (UTC)
replies: text:  Verpies (talk)Verpies  Done.  As the #1 contibutor to this article I am curious which part of the article is still confusing.  I also developed a C code for processing this format.  —Preceding undated comment added 11:50, 19 April 2012 (UTC)
replies: text: For example, the DIB header (bitmap information header) section commentary after the table is confusing and makes little sense in one place even if the bad punctuation is ignored. I say this as someone who has edited this article since 2006. This article reads like a technical standard instead of an encyclopedic article. BTW, I just restored the overly detailed tag. VMS Mosaic (talk) 03:37, 9 May 2012 (UTC)
thread_title:  BITMAPCOREHEADER2 Size and optionality 

message: The 1058 Pixel Wikipedia-logo is a grayscale image, so it i a bad example for a 24bit-BMP, because there is no reason for storing a grayscale image as a 24bit-Full-color BMP instead as a 8bit-grayscale-BMP, it's just a waste of storage space. --MrBurns (talk) 19:56, 2 July 2012 (UTC)
thread_title:  Wikipedia logo 

message: These actually just refer to specific variants of the normal BITMAPINFOHEADER, where the Compression field in the header is set to BI_BITFIELDS. When the BI_BITFIELDS is specified, officially you are allowed to designate the positions of the bits for the RGB values. The remaining bits are unused. Because this required 3 additional 4byte-integer fields in the header (the 3 bit masks), the header is now 12 bytes longer than normal BITMAPINFOHEADER, and therefore requires the header size field in the header to be set at 52, rather than the normal 40. Therefore BITMAPV2INFOHEADER is actually within the official Microsoft specification for BITMAPINFOHEADER, and is not a new or undocumented form of header.
BITMAPV3INFOHEADER is the same as BITMAPV2INFOHEADER in that the compression field in the header is set for BI_BITFIELDS. The difference is that BITMAPV3INFOHEADER has its header size field set to 56 to accommodate one extra bit mask. This 4th bit mask is for alpha channel (often used as transparency/opacity data in image processing software like Photoshop). Keep in mind that this is NOT officially allowed according to Microsoft documentation for the BITMAPINFOHEADER http://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx which specifies that in BITMAPINFOHEADER which has its Compression field set to BI_BITFIELDS, only the 3 color channels (and not an alpha chennel) are to be specified. So unlike BITMAPV2INFOHEADER which is actually part of the BITMAPINFOHEADER specification, BITMAPV3INFOHEADER is an entirely separate and undocumented bitmap header. However it is a logical extension of the previous version of bitmap header.
The first version of bitmap header to be publicly documented and support an alpha channel is the BITMAPV4HEADER. However it also has a lot of extra fields for gamma, color space, and XYZ absolute color values for image calibration. As such, it has a lot of extra info that is only needed for high-end image processing. This seems to be a bit overkill for just getting an alpha channel stored in your BMP file, which is why Microsoft probably released the BITMAPV3INFOHEADER. Of course because Microsoft loves trade secrets, they kept the easy to use, yet quite powerful (due to alpha channel support), BITMAPV3INFOHEADER a proprietary specification. Adobe (which uses it) probably had to pay lots of money to get a copy of it from Microsoft. Fortunately an Adobe employee posted it on their forums https://forums.adobe.com/message/3272950#3272950 in response to someone writing a complaint that Adobe was using unofficial bitmap header specs in their BMP files. I just wonder whether or not it was legal for them to post that in their forum, or if this leak constitutes some violation of non-disclosure agreement between Adobe and Microsoft. So yes, it appears to be an official spec from Microsoft, just not a publicly documented one.
As a result, BITMAPV3INFOHEADER may not be properly loaded by 3rd party software, that is neither from Microsoft nor Adobe, that is capable of loading BMP images. So if you create software that can write BITMAPV3INFOHEADER BMP files, don't be surprised if standard image viewers like ACDSee, XnView, or IrfanView have problems correctly displaying them.
A better way to create an alpha channel in a BMP file is to use BITMAPV4HEADER, and just make sure that the field for the color space is to the constant sRGB (which has a numerical value of 0x73524742 or 0x00000000 depending on where you read the info) so that it will ignore the remaining color calibration information (the XYZ endpoints and RGB gamma). Because BITMAPV4HEADER is publicly documented, it is more likely that 3rd party image viewers will properly display it, although since the plain BITMAPINFOHEADER is most common bitmap header, there are probably many software packages out there that won't recognize a a BMP file with a BITMAPV4HEADER (but the main image viewers like ACDSee, XnView, and IrfanView will probably work with BITMAPV4HEADER, and might even work with the not-publicly-documented BITMAPV3INFOHEADER if the developers had previously reverse engineered it, had looked at the Adobe forum post I mentioned here, or had independently written it as a logical extension of the BITMAPINFOHEADER).
And this brings up an entirely new problem. There is a significant discrepancy between the Microsoft docs http://msdn.microsoft.com/en-us/library/cc250396.aspx and other docs I've found.
Microsoft defines these constants for the color space field for BITMAPV4HEADER:
LCS_CALIBRATED_RGB = 0x00000000
LCS_sRGB = 0x73524742
LCS_WINDOWS_COLOR_SPACE = 0x57696E20
and gives these descriptions:
LCS_CALIBRATED_RGB: Color values are calibrated red green blue (RGB) values.
LCS_sRGB: The value is an encoding of the ASCII characters "sRGB", and it indicates that the color values are sRGB values.
LCS_WINDOWS_COLOR_SPACE: The value is an encoding of the ASCII characters "Win ", including the trailing space, and it indicates that the color values are Windows default color space values.
Meanwhile http://www.herdsoft.com/ti/davincie/bmpv4ype.htm defines the constants like this:
LCS_CALIBRATED_RGB = 0
LCS_DEVICE_RGB = 1
LCS_DEVICE_CMYK = 2
And it gives these descriptions:
LCS_CALIBRATED_RGB: The DIB uses the normalized sRGB colour space defined by ICM.
LCS_DEVICE_RGB: The DIB uses the device dependent RGB colour space defined by a display device. This is the definition used by the older BITMAPINFOHEADER.
LCS_DEVICE_CMYK: The DIB uses the device dependent CMYK colour space defined by a printer.
Notice that in Microsoft's definition, there is a clear difference between calibrated and sRGB color spaces, but in this other documentation the two seem to be the same. From this other source there is no mention of LCS_sRGB or LCS_WINDOWS_COLOR_SPACE constants, but there are two constants that the Microsoft documentation does not have, LCS_DEVICE_RGB and LCS_DEVICE_CMYK.
The LCS_CALIBRATED_RGB is the only constant who's numerical value is the same in both documents, but the second document seems to treat this as sRGB, whereas Microsoft has sRGB being a completely separate constant.
This document seems to have a more complete list of all possible values for the color space field than any other single document I've found from Microsoft or anywhere else http://fileformats.archiveteam.org/wiki/BMP#Symbol_definitions
And just to be sure everything worked right, I'd probably go with the Microsoft specs on color space constants, because the BMP format and its constants are creations of Microsoft.
And by the way, I've also seen BITMAPV2INFOHEADER called BITMAPV2HEADER, and BITMAPV3HEADER called BITMAPV3INFOHEADER.
As for Adobe, they do have a slightly incorrect BMP image file. Specifically, Adobe appends two extra 0x00 bytes to the end of the file. For example a 640x480 32bpp image should have 1,228,800 bytes, but Photoshop's output for this same image has 1,228,802 bytes.
Benhut1 (talk) 22:42, 29 June 2014 (UTC)
thread_title:  I think I figured out the BITMAPV2INFOHEADER and BITMAPV3INFOHEADER 

message: Should this article not be titled “BMP (file format)”? ―PapíDimmi (talk | contribs) 20:00, 1 May 2017 (UTC)
thread_title:  Rename? 

message: Is BMP raster data really stored upside-down, or is it vandalism? — Preceding unsigned comment added by Verdana Bold (talk • contribs) 16:56, 1 October 2018 (UTC)
replies: text: Yes, but "upside-down" is the wrong way to say it.  The image is typically stored bottom-up, starting with the bottom raster line and proceeding upwards. -- Elphion (talk) 03:01, 2 October 2018 (UTC)
replies: text: both way , topdown and downtop are possiblehttps://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-wmf/567172fa-b8a2-4d79-86a2-5e21d6659ef3— Preceding unsigned comment added by 85.149.83.125 (talk) 15:56, 21 May 2019 (UTC)
replies: text: Yes, obviously; but the default is bottom-up (as are the vast majority of native BMPs). -- Elphion (talk) 16:20, 21 May 2019 (UTC)
thread_title:  Really? 

message: When I was trying to calculate to ensure I fully understand the workings and file structure of the BMP file structure. My calculations are different from what was displayed in the table. 
In example 1
At the row 02h offset, I calculated the size of BMP file to be 70 bytes, but it was (64 + 6) not (54 + 16), can I know where did I go wrong with my calculation steps? 
Steps: 
1. '46 00 00 00' are the hex values 
2. 6 * 160 + 4 * 161 = 6 + 64 
At the row 26h, how was the value 2835 pixels calculated? The formula 72DPI X 39.3701 inches wasn't explained quite clearly. My own calculations gave me 4875 pixels using the steps similar to the one above. 
Thank you for your time and help. 210.19.13.180 (talk) 15:17, 22 March 2023 (UTC)
thread_title:  Example 1 and 2 table enquiries