Talk:BMP file format

Filesize

While this is not so relevevant, if you apply zlib compression to a bitmap the resulting filesize is about the same as for png. --Marco 17:55, 6 December 2005 (UTC)

No, PNG is usually smaller. It's not the compression algorithm alone that's behind PNG's superior compression, it's also the filters performed on the image before the zlib compression. That's the same reason why a FLAC file will usually be smaller than a zlib'ed WAV file.

It depends, the filters are rarely a benifit with indexed color, for truecolor you may well be correct though. Plugwash 21:58, 8 July 2006 (UTC)

I tried both zipping and 7-zipping the wikipedia logo from the example in the article, after having converted it to BMP using Windows XP's mspaint.exe. Wikipedia-logo.png is indeed ~477KB, but when I convert it to 24-bit BMP it's 4,26MB, not 3.2, like it says in the article. And when I zip the BMP, it gets down to 352KB, which is much better than PNG compression. Normal 7-z takes it down to just 226KB. Is this right? Is the mspaint.exe PNG->BMP conversion lossy? MiF86 17:20, 30 April 2007 (UTC)

I discovered that MsPaint (at least on my computer) saves the file as a 32-bit bitmap file even though the format is chosen to be 24-bit. Right click the file and choose Summary to check. That's why the resulting file size is 4.26MB. If you use Microsoft Photo Editor (or any other professional image editor software) to save it as 24-bit bitmap, the file size will be 3.20MB as described.

The fact that your ZIP file size is only 352KB does not indicate that the conversion is lossy. Both PNG->BMP and BMP->PNG are lossless. The difference is due to the efficiency of a compression algorithm when used with a particular type of data. Try the same thing for a different PNG image, the ZIP file size may no longer be smaller! Mdanh2002 14:02, 2 May 2007 (UTC)

It may well be that mspaint is doing something stupid to the image when loading it (such as trying to apply some kind of color correction) that is losing some information and hence making it more compressable but imo it is more likely the wikipedia logo was either not created using maximum compression settings or created using a tool with a poor png implementation. Plugwash 16:38, 2 May 2007 (UTC)

I agree with Mdanh2002. It is difficult to achieve optimal PNG compression. That's why there are several filter methods. The PNG specification recommends adaptive filtering (choosing different filter for each pixel row, after performing a simple analisys algorithm) as the best variant, but in rare cases using no filters (filter method 0) can give better results. This is true for indexed-color PNGs, but can also apply for truecolor images. The problem for most encoder programs is that there is still no good algorithm for choosing filters unless using slow brute-force trials as OptiPNG does. I processed the image with it and it took the file down to 369KB. It is > 352KB, but I found that the logo is in interlaced format! Images stored this way are much more difficult to compress for most compression algorithms. As noted in the specification, PNG can be better than GIF compression, but if not considering interlaced images. I transformed the logo into non-interlaced and OptiPNG produced a 303KB file (again using filter method 0, I guess this image is a very rare case and zlib compression alone works better for it). Normal Zip compression gets the 32-bit bitmap to down 352KB, and maximum - to 301KB. Considering all this I suppose there is no problem with MS Paint. It produces a 32-bit instead of 24-bit bitmap, because the logo has an alpha channel (8-bit) and the Windows XP Paint is trying to preserve it. I tried compressing a 24-bit bitmap with the logo and I got 286KB with Zip and 279KB with OptiPNG...

counting

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)

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)

Going this way, I suggest the offsets start from #0 instead of #1: most user of a file format information will be coders, and in a vast majority of programming languages the first position is #0, not #1. -- Mike 29 June 2006

I think the whole section needs to be rewritten. May be using tables to describe the headers... and some more information for coders, for example when bytes #50-53 are 0.
Something like that? If no one disagrees, I'll start editing.

Offset #	Size (bytes)	Meaning
0	2	Store the data that will be used to identify the bitmap file. Typical values for these 2 bytes are BM.
2	4	Store the size of the bitmap file using a dword.
6	2	Reserved. Actual value depends on the application that creates the image.
8	2	Same as above.
10	4	Store the offset, i.e. starting position, of the byte where the bitmap data can be found.

--Lefter 12:08, 26 February 2007 (UTC)

Thanks for the suggestions. Go ahead with your editing and do add further elaboration on the file format. Currently a lot of things are not discussed - the article just covers the basics. :) Mdanh2002 15:10, 5 March 2007 (UTC)

Well, I started with my editing. I am new at wikipedia, so please excuse me for the mess in the history page. I am planning more edits, but I'll postpone them until I make a nice version of the page offline.--Lefter 10:02, 6 April 2007 (UTC)

MIME Type?

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)

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)

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)

Developed by ?

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 Microsft. Does anybody know more about this? 16@r 13:52, 10 July 2006 (UTC)

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)

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)

n in the equation

It's very ambiguous that you must use n=3 in the first place (2^n) and n=24 in the second place (800*600*n)/8 when using the equation.

Sample values used in the equation: 54+4*2^3+(600*800*24)/8 = 1 440 086 / 1024^2 ~= 1.37 ("almost 1.4 megabytes")

I propose the equation to be edited to: 54+4*2^(n/8)+(600*800*n)/8 --Lassi Heikkinen 14:44, 24 July 2006 (UTC)

Hi, the term $4\cdot 2^{n}$ is the size of the color palette (it takes 4 bytes to describe each color, and there are totally $2^{n}$ colors). n here is the number of bits per pixel, and there is no need to divide n by 8 to get the number of bytes. In the 2nd term, $width\cdot height\cdot n \over 8$ is the size of the bitmap raw data. As 8 bits form a byte and we are calculating in bytes, we must divide by 8.

Regarding your explanation, I guess the reason why you think the formula is wrong is because the size will get extremely large if $2^{n}$ where n=24 is added into the formula. I am not too sure about this, but the Italian version of this page suggests that we use $u(15-n)\cdot 4\cdot 2^{n}$ (where u(x) is the unit step function) to describe the size of the color palette. That is, the color palette does not exist when the bitmap is 16-bit or higher! Mdanh2002 04:29, 25 July 2006 (UTC)

BGR

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)

Here is the file with the header info: [1]. 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)

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)

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: [2] --TEO 17:55, 10 September 2006 (UTC)

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)

Hex

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)

Why not... Go on ;) --TEO 19:45, 10 November 2006 (UTC)

Endianness

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)
Nevermind, I was very tired when I wrote this. They are entirely little-endian. --81.235.198.59 17:08, 19 May 2007 (UTC)

bitmap

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)

What's Different?

What is the difference between .PNG and .BMP? They look the same according the images! --  PNiddy  Go!  0 18:57, 5 August 2007 (UTC)

PNG are compressed. BMPs have ridiculously large file sizes. 205.174.22.26 01:51, 23 August 2007 (UTC)

Development history would be good to know

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)