Talk:BMP file format

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the BMP file format article.
Article policies

Contents

[edit] 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...

[edit] 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)

[edit] 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)

[edit] 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 Microsoft. 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)

[edit] 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 2n 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 2n 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)

[edit] 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)

[edit] 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)

[edit] 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)

Yes, looks like the format uses little-endian encoding. Shouldn't it be said in the article? I think so. Right now I'm programming a BMP r/w library and this article has everything I need BUT this. Also, on section BMP File Header says that "BMP magic number" is 0x424D. Well, it depends. Actually it is 0x4D42, being BMP little-endian. Either we change it to 0x4D42 and add a reference to its endianness, or say 0x42,0x4D. But 0x424D is wrong.

84.77.96.100 16:43, 24 October 2007 (UTC)

Yes, could you do it? See WP:SOFIXIT. --Kubanczyk 20:12, 24 October 2007 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] Move, merge, generalize, or something

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)

Agreed. This article should be about the bitmap concept. VMS Mosaic 23:23, 13 September 2007 (UTC)

[edit] Move Bitmap to Bitmap file format

I see a bad, unencyclopedic definition here. The fact that Microsoft or IBM calls a file a bitmap does not mean it is appropriate definition for encyclopedic article. A bitmap is quite simply a map of bits, not a map of bits stored in a file, with file having such-and-such blessed format. This article implies for example that a bitmap cannot be read to RAM, because it then ceases to be a bitmap. It becomes just... bitmap data (?!?). And what are other bitmap file formats, listed in bitmap image format storing then? --Kubanczyk 23:01, 13 September 2007 (UTC)

So I take it you're supporting what I suggested above. But do you really want a new article, or just merge it into bitmap image format? I suppose a move would be the easy way to start. Dicklyon 23:04, 13 September 2007 (UTC)
No, I oppose merging anything to "Bitmap image format". Why? Because it has a bad name, too. It should be "Bitmap image file format". I'm still supporting a move proposition. In case a move will be decided, I think the proper "bitmap" article should be written from scratch. --Kubanczyk 07:43, 14 September 2007 (UTC)
I am not strongly attached to the title of "Bitmap image format" or even to the article itself. The easiest solution might be to revert the move of Bitmap from Windows and OS/2 bitmap (the move took place in July), then create a proper Bitmap article. The "Bitmap image format" article can be renamed or even deleted. VMS Mosaic 17:34, 14 September 2007 (UTC)

Bad news after investigation of article's history. Wild renaming and re-defining:

 start as BMP page:
 07:01, 15 April 2003 Zoe (Talk | contribs) (#REDIRECT Raster graphics) (undo)
 07:03, 15 April 2003 Brion VIBBER (Talk | contribs) (Replacing misdirected redirect with stublet) (undo) 
   .BMP or .DIB (device-independent bitmap) is a bitmapped graphics format ... and a simple graphics file format ...
 14:09, 25 August 2003 ( (Talk | contribs) (text moved from BMP) (undo)       # to Windows bitmap
 07:27, 19 December 2006 Yuhong (Talk | contribs) m (moved Windows bitmap to Windows and OS/2 bitmap... 
 01:15, 20 July 2007 Pkkao (Talk | contribs) m (moved Windows and OS/2 bitmap to Bitmap Image) (undo) 
 18:48, 18 August 2007 Thumperward (Talk | contribs) m (moved Bitmap Image to Bitmap image: decap) (undo) 
 18:51, 18 August 2007 Thumperward (Talk | contribs) (13,818 bytes) (reorg intro) (undo) 
   the bitmap image format is a raster graphics format used commonly as a simple graphics file format
 19:00, 18 August 2007 Thumperward (Talk | contribs) (13,625 bytes) (bit more work) (undo)
   the bitmap image format is an image file format used for representing raster graphics
 09:45, 11 September 2007 Thumperward (Talk | contribs) m (moved Bitmap image to Bitmap over redirect: common name) (undo)

Cause of this is simple: there is no consensus what is this article about:

  • About "file format, a structure of data stored inside a BMP/DIB file"?
    • Windows and OS/2 bitmap file format is a perfect name
    • Bitmap file format is fair enough. What about other file formats (PBM, WBMP, XBM) that claim to store "bitmap"?
    • Bitmap is a disaster
  • About "data structure header + info + palette + pixel_data, whether stored inside a BMP/DIB file or in memory"?
  • About "bits, representing pixels of an graphic image"?
  • About "map of bits", not neccessarily representing any pixels?
    • No need, there is already a Bit array article.

Either way, after consensus is reached we have to point out the issues for future users. Otherwise renaming frenzy will continue.

After that, we can work on redirects and sort them out. I would support a bitmap being a redirect here, because it is a common use.

--Kubanczyk 11:16, 15 September 2007 (UTC)

Please read Wikipedia's naming conventions for articles. Please also examine the dates and actions taken regarding page moves; three moves in four-and-a-half years (one of which was a copy-edit) is not "wild renaming".
I suppose I'll go and merge in Bitmap image format, an entirely unnecessary disambig for four concepts with about 90% overlap, when I've got time. Bah. Chris Cunningham 11:32, 18 September 2007 (UTC)
To clarify, it was wild. Not because of insane frequency, but because of a great semantic difference. Same article, same content, many titles implying four wildly different subjects (I listed them above). Maybe you are right that nowadays a bitmap means commonly .bmp file. Hmmm, then I would like to boldly inform readers about a proper word definition (number 3 or 4). And point out similar file formats. I leave for a future WinAPI expert the issue of "1st vs 2nd meaning". --Kubanczyk 13:57, 18 September 2007 (UTC)
Again, please read Wikipedia's common naming guidelines. "Bitmap" is predominantly used outside of specific compsci purposes to mean a simple file format of only rudimentary compression. While there are various different formats which do this, they have a lot in common, and they've got just as valid a claim to the term "bitmap" as any other usage. We've already got bit array and raster graphics to cover specific other uses. So the only call is to whether to bother with a disambiguation page at bitmap and hoist the file formats off to bitmap image (and then later, if and only if that article gets too long, further down to Windows bitmap and other permutations), or whather to just have an otheruses tag at the top of bitmap. For now I think the latter option is the most sensible. But this is a storm in a teacup from where I'm sitting. Chris Cunningham 14:16, 18 September 2007 (UTC)
I see your point. Let's keep the name. Anyway I will add explanation of the term "bitmap" - it's not about "claiming the right", it's about what word bitmap originally meant (before bmp file was introduced). --Kubanczyk 14:33, 18 September 2007 (UTC)
I disagree. Is there any evidence that "Bitmap is predominantly used outside of specific compsci purposes to mean a simple file format of only rudimentary compression." I bet lots of people know "BMP" and only the nerds among them have any idea that it is derived from "bitmap", which is widely known among people educated in EE in the last three decades to mean an array-of-bit organization of an image, whether is a bitmap display, file format, or whatever. The file format is a much narrower topic. Dicklyon 15:26, 18 September 2007 (UTC)
As evidence of what I'm saying take a look at uses of "bitmap" in books. Very few of those are about the file format. Dicklyon 15:28, 18 September 2007 (UTC)
I already edited the article to provide meaning 3 and 4, please correct as needed. I will not debate over renaming it, it seems good enough to me now. --Kubanczyk 15:34, 18 September 2007 (UTC)
Wikipedia isn't a dictionary. If there's no particular subject which the term "bitmap" addresses, we needn't resign ourselves to leaving it for disambiguation if there are still more appropriate titles for related articles. And for four years there's been no particular noise from the EE camp about the bitmap page discussing an image format, so right now I'd take that bet.
Regarding "BMP" being the correct name for the format, BMP is an abbreviation. It's not a formal name, and unless there was reason to believe that there truly is a disconnect between people who would recognise "BMP" and those who would recognise "bitmap", I don't buy that "only the nerds" use "bitmap". Chris Cunningham 16:45, 18 September 2007 (UTC)
Further, Dicklyon's Google Books link appears to have a three-way equal split in definition on the first page. Having already established that "bitmap" to refer to a raster image in general is really just a specialist use of the same thing, that gives a 2:1 split in favour of graphics. Chris Cunningham 16:48, 18 September 2007 (UTC)
I'm not sure what point you're making by "in favour of graphics"; you mean as opposed to photographic images, or what? As to BMP being an abbreviation, I don't think so; if you google for site:microsoft.com bmp, you get 6X more hits than site:microsoft.com bmp bitmap, meaning that Microsoft seldom calls a BMP file a bitmap (though it does store a bitmap and is named for that). Dicklyon 17:17, 18 September 2007 (UTC)

I made some edits in which the generality of the term bitmap and specificity of the BMP format are both respected and better integrated. I think it works well to focus on BMP as an example bitmap file format. We should also add a section on other, including compressed, bitmap formats. Dicklyon 19:18, 18 September 2007 (UTC)

[edit] Compressed bitmaps

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)

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)
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)
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)
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)
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)
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)
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)
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)
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)

[edit] Serious style issues with new intro

Look guys, I understand that it's important to be thorough, but we need to define what this article is about, not simply use it as a dumping ground for anything that was ever called a bitmap. So let's see what the lead now discusses:

  1. Eight (!) different file formats.
  2. A dictionary etymology of the word "bitmap".
  3. A related term "pixmap", which can be assumed from the lead to be synonymous (this is true for only some meanings).
  4. Raster graphics in general.

This is unacceptable. Article leads are not there to provide disambiguation. That means one of two things:

  1. This becomes a disambiguation page.
  2. This concentrates on one meaning and punts everything else off to other articles, in a single otheruses tag, at the very top.

As of yesterday, we had a mostly-readable article on Windows bitmaps. Now we have a schizophrenic mess. Until the talk discussion dies down (the three of you still appear to have no consensus on what this article should be defining) editing the article to reflect a broader meaning simply makes it less readable. If there's no consensus on how to move forward soon I'm reverting this to discuss Windows bitmaps pending a convincing rewrite. Chris Cunningham 08:51, 19 September 2007 (UTC)

Now, surely by some mistake (!), I understand that you intend to revert good faith edits. Excuse me, could you write something that will lead to consensus instead? WP:MOS states what article leads should contain, let's use it. I see some of your points, already written about it. --Kubanczyk 12:24, 19 September 2007 (UTC)
There's nothing wrong with reverting good faith edits so long as dialogue with the involved parties has been initiated. I've already written what I think:
  1. This article should be about bitmap image file formats
  2. There's no need to use a less direct title because this is a common usage of the word "bitmap"
  3. Every single word on things which are not bitmap image file formats should either be contained in a disambiguation template at the top, or on a single line explaining the etymology of the word
If there's another line of thought, I'd like to discuss it on here. If there isn't a clear line of thought to argue with, I'd rather the article be reverted to a state where the lead has some sense of direction until there is a clear line of thought. Chris Cunningham 13:20, 19 September 2007 (UTC)
I thought it was a big improvement, myself. I would, since it was my doing, largely. But based on the discussion above, it was clear that the broader concept of a bitmap needed an article, and that moving the article on the specific BMP format to bitmap was a bad idea with little support. I proposed moving that elsewhere and making the broader article here. But, after Kubanczyk did his "change to meaning 1" edit, I saw that it was really not far from the general topic that seemed needed here. His meaning 1 was still a bit narrow, so I broadened it to bitmap images whether in a file or in memory, which is certainly not a stretch. If you object to this broader interpretation of the topic, I suggest we revert all that, move the article to a more sensible title, and then start fresh on a bitmap article. Other ideas? Dicklyon 15:42, 19 September 2007 (UTC)
By the way, I don't really agree that there are multiple meanings in play here. There's one meaning, with multiple narrower applications. Even raster graphics is way too narrow and specific, and the field of computer graphics does not traditionally apply to photographic images. Dicklyon 15:49, 19 September 2007 (UTC)
Then I you've changed from meaning 1 to 3. "Not too far"? Well, but we are suddenly out of WP:COMMONNAME. Face it, today lusers say bitmap=BMP. --Kubanczyk 20:35, 19 September 2007 (UTC)
Lusers. Wow. We are adults today. Chris Cunningham 21:43, 19 September 2007 (UTC)
Well, no hard feelings. How would you call somebody who claims bitmap=BMP (operator = means "is equal to")? --Kubanczyk 09:51, 20 September 2007 (UTC)
I'm not in the habit of calling people names. I rather think I grew out of the fifteen or twenty years ago. Chris Cunningham 11:40, 20 September 2007 (UTC)

The specific file format should not be the main point of discussion at “bitmap”. It should be moved back to a title like Windows and OS/2 bitmap, and what's left here at bitmap should either be a general discussion, or bitmap should be redirected to raster graphics. Someone typing "bitmap" into wikipedia is not going to be looking for the file format. --jacobolus (t) 18:57, 19 September 2007 (UTC)

To respond to both of you at once: at the moment we have a reasonable article on the file format and about three sentences on the other meanings (which, as are clear from the disambiguation template, are mostly covered by other articles already). The idea that the image format must be moved aside because it isn't the One True Meaning of "Bitmap" doesn't hold any water; Wikipedia isn't beholden to have an article at Phish which carefully explains that there are two valid meanings for the word: it just picks the most common usage and disambiguates the other to an equally well-named article.
As for the repeated anecdotal claim that Someone typing "bitmap" into wikipedia is not going to be looking for the file format, I have to once again point out that the article sat with this definition for four years without any apparent kick-up, so I'd assert that this is wrong. Chris Cunningham 19:31, 19 September 2007 (UTC)
Chris, my view is not far from yours: keep the name bitmap, otheruses on top, lead contains 2-3 lines about meanings 3&4, lead mentions non-Microsoft literal-bitmap-files do exist (only acronyms/links), mention "pixmap" only once, drop JPG/GIF, drop "photography issue", main part of article covers exclusively BMP, at the end various remarks about XBM&Co. Other gentlemen, what do you think? Isn't it a good consensus between "the truth" and "too confusing to the public"?
Ah, as a matter of principle, if you'll revert my good faith edit I'll get mad. Seriously. Explanation is here. --Kubanczyk 20:35, 19 September 2007 (UTC)
Article leads are not for disambiguation. End of story. This is not a combined encyclopedia and distionary. The reader is assumed to be on the right article as soon as they fail to click away during the disambig. Zero irrelevant content after that. Zero.
You can get mad if you want, but I'm not editing to hurt people's feelings. I'm editing to create a great encyclopedia. We have style guidelines for a good reason, and I'm going to stick to them. Chris Cunningham 21:42, 19 September 2007 (UTC)
A problem with the current title is that 200 or so pages link to 'bitmap' and in the great majority of cases, the links are not intended to reach a page that discusses only the Windows and OS/2 bitmap file format. My starting to redirect all those links to 'Raster graphics' or the disambiguation page I created for the various bitmap file formats is what got this discussion started. VMS Mosaic 20:13, 19 September 2007 (UTC)
Hey, don't worry, people interested in historical/scientific/programming topics e.g. Commodore PET can actually read. They will notice a proper disambig link, and will understand. On the other hand a huge mass of Windows users will quickly "correct" any "non-MS-compliant" article. --Kubanczyk 20:42, 19 September 2007 (UTC)
If this was an attempted jab at me, check my user page, and hence my employer (or, hell, check my extedned post history), to see how devoted I am to Microsoft and IBM, thanks. Chris Cunningham 21:42, 19 September 2007 (UTC)
I wouldn't worry as much if there was a "proper disambig link", but the current one is not acceptable. I think it should read "This article is about the Windows and OS/2 bitmap file format. For bitmapped graphics in general, see raster graphics. For the bit-addressed data structure, see bit array." I won't complain much if my earlier addition of "For other bitmap formats, see Bitmap image format." is left out. I seriously doubt many windows users (other than experts) have ever heard the term bitmap or have a clue what it means, so I am not at all worried in that regard. VMS Mosaic 21:31, 19 September 2007 (UTC)
So edit the dambig; an obvious style edit like that clearly isn't contentious right now. Chris Cunningham 21:42, 19 September 2007 (UTC)
I think that if we said "This article is about the Windows and OS/2 bitmap file format" we'd be ignoring what we've been doing here. I'll change it in a more accurate direction. Tell me what you think. Dicklyon 21:37, 19 September 2007 (UTC)
Much worse now. "This article is about the storage organization of raster images. For bitmapped graphics in general, see raster graphics." - perfect text for a compiler, completely unreadable for a human. It assumes a newcomer already understands "storage organization", "raster image", "raster graphics", "bitmapped graphics"... Ah, and moreover it doesn't make sense either. I like VMS Mosaic's proposition. --Kubanczyk 21:50, 19 September 2007 (UTC)
My proposition was meant for the case where this article is reverted back to be exclusively about Windows bitmaps (which I do not think should happen). VMS Mosaic 22:06, 19 September 2007 (UTC)
Why can't a comparison of the organization of bitmap file formats be located at raster graphics? I think VMS Mosaic is right that links to bitmap are not intending to hit the current definition. Those would point at BMP or similar. Again, I don't see why general information can't go at raster graphics, specific information about the format at Windows Bitmap or whatever, and Bitmap redirect to raster graphics with a disambig notice at the top. Where's the downside to such a plan? (The most "common" or "logical" use of the word "bitmap" is certainly not to refer to the format, which is generally called "windows bitmap" or "bmp" or similar) --jacobolus (t) 21:56, 19 September 2007 (UTC)
The "downside to such a plan" is that generally, the order in which Wikipedia articles are written is that first, the article is written and second, there's a big argument to rename it. Here, there's an argument to rename an existing article based on what appears to be the possibility of writing a new article with a broader scope. And it all seems to be hinged on a rather weak understanding of Wikipedia's policy towards disambiguation pages. What we need right now is either for someone to do a comprehensive job of repurposing this article, or for it to be left as-was (where it presented what was at least a fairly clear, unambiguous picture of part of the story). Chris Cunningham 22:08, 19 September 2007 (UTC)
No, I'm not suggesting anyone write a new article with a broader scope. I'm suggesting redirecting the location bitmap to raster graphics, and merging any relevant information about comparisons of bitmap storage schemes into there, and moving the information about the windows file format to an article specifically focused on that, called something like Windows Bitmap or Windows and OS/2 bitmap. If there's more information to put about bitmap storage schemes than can fit in the raster graphics article, it should be put in an article that accurately reflects its content; bitmap should still redirect to raster graphics. --jacobolus (t) 22:16, 19 September 2007 (UTC)
Fair enough, at least that's a concrete proposal. Feel free to start a move request in a new section. Chris Cunningham 07:52, 20 September 2007 (UTC)
I would support such move, too. Of course Windows and OS/2 bitmap is far better than Windows bitmap (see history of renaming).
Side note, not concerning our main discussion: I've checked most reliable source, and it's pretty clear that Microsoft is all about meaning 2. Not meaning 1. That means BMP file is just a container, and it is only if you load full content into memory (WinAPI LoadBitmap() function) when it becomes a "Microsoftian bitmap", as bitmap=header+palette+bit_array. Todo later, after cleanup. --Kubanczyk 09:34, 20 September 2007 (UTC)
It's not going to "Windows and OS/2 bitmap" because, for the umpteenth time, Wikipedia does not place articles at their most pedantic possible titles as a rule of course. And again, no move until there's a reasonable general article at bitmap or a strong consensus to point this article at raster graphics. But I eagerly await a constructive rewrite in any case. Chris Cunningham 11:40, 20 September 2007 (UTC)
Bitmap (BMP)? Isn't it a decent title for meaning_2_article? I oppose "Windows bitmap". --Kubanczyk 12:19, 20 September 2007 (UTC)
I'm tired of repeating myself. When there's a rewrite, a move / rename of what's currently here is a useful expenditure of people's time, and not until. Chris Cunningham 13:16, 20 September 2007 (UTC)
Don't we need to decide what to call this article if bitmap is going to be redirected to raster graphics. That means this article has to have a new title. You agree with someone starting a move request above, but that cannot be done until a decision is made on what to move it to. If the article goes back to being just about 'Windows bitmaps' then all that needs done is a revert and a new title (i.e., there will be no rewrite here). Or am I missing your point? VMS Mosaic 17:10, 20 September 2007 (UTC)
I don't like the premise. Raster graphics is about computer graphics, and appears to be a rather narrow stub of a messed-up article itself. Bitmaps are used not only for graphics but also for photos. What we need to decide is first whether to split out the BMP stuff from the generic bitmap stuff; if so, we need a good title for the BMP article so that we can still have a bitmap article. BMP has had several names before, so we could move it back to one of those, or pick a new one, but bitmap is not it, as the word has a much broader, older, and more well known meaning. Dicklyon 19:50, 20 September 2007 (UTC)

Well that would be fine with me. It just seems like whatever bitmap ends up being or redirecting to should have a general discussion, rather than diving immediately into the arcana of pixel storage, or into the specifics of one particular format. Raster graphics has the start of such a discussion, and though as you say, it's a pretty bad article at the moment, it could be refocussed and generalized somewhat. --jacobolus (t) 20:08, 20 September 2007 (UTC)

So, first we all need to agree that bitmap should point somewhere else. I say it should. VMS Mosaic 20:19, 20 September 2007 (UTC)
Since this discussion have been a blah-blah circle with non-decreasing diameter, I'll be back next month and I'll be bold in article improvements. --Kubanczyk 09:36, 22 September 2007 (UTC)

OK, here's what I'll do, unless I get a specific alternative real soon:

  • Move this article to BMP file format and back out the generic bitmap stuff
  • Creat a new Bitmap article and put the generic stuff into it, with a main link to BMP file format in a greatly-reduced section on the DIB and BMP stuff.
  • Add words to both bitmap and raster graphics to refer to each other and to distinguish their content. The former is about image represenation, the latter more about CG image creation techniques, I think. We can still consider a later merge if that doesn't work out.

Dicklyon 17:58, 22 September 2007 (UTC) There, I did the fork. Now we can independently work on the two articles to focus on what they're supposed to be about. Dicklyon 18:43, 22 September 2007 (UTC)

[edit] Palette error?

The text claims that the color palette size is variable, depending on the number of colors actually used in the image. Is this true? I can find no evidence for it. I placed fact tags on the portions that need to be checked and probably corrected. And is it true that the number of bytes per palette entry differs between Windows and OS/2? Strange, I though we had a standardized format... Dicklyon 16:45, 23 September 2007 (UTC)

Yes, the article is accurate. I tried to reference the items, but someone else could probably do a better job. The sentence "For each byte, a value of 0 indicates that the corresponding color (either red, green, or blue) is not used to create the current image color." is just stating that 0 means zero intensity. The next sentence then states that 255 means full intensity. I don't see any explicit mention of the meaning of 0 and 255 in the references I checked probably because it is common usage for RGB data.
If a format specified by Microsoft (excepting the OS/2 versions) can be considered a standard, then yes, it is standardized. See the section 'Bitmap information (DIB header)' which lists the five different versions of the 'standard'. VMS Mosaic 00:06, 24 September 2007 (UTC)
You seem to be missing the point. Zero for zero intensity is of course allowed in a color, such as [0,0,0] for black or [0,0,255] for blue. But it never means unused, and if it did, how would the table format vary and allow fewer bytes to be stored when fewer colors than 2^n are actually used. I think it's nonsense. Dicklyon 01:59, 24 September 2007 (UTC)
Yes, it is poorly worded. I had intended to say that it needed redone or simply deleted (given that it is a poor attempt at stating the obvious). VMS Mosaic 02:25, 24 September 2007 (UTC)
Sorry about missing that OS/2 V2 switched from three to four bytes per palette entry. I should have caught that. VMS Mosaic 02:39, 24 September 2007 (UTC)
I've done a lot of detail clarification in the sizes, specs, tables, descriptions, etc. Please check and see if I got anything wrong; I did get things wrong and reverted them a few times in the process, so might still have incorporated some misconceptions instead of accurately representing this bizarre and broken set of ancient crufty formats. Dicklyon 02:50, 24 September 2007 (UTC)

[edit] Not in proper context

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)

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)
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)
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)
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)

[edit] Byte order and bit order

"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)

[edit] Bitmap history.

Who created it, how old is it, etc. —Preceding unsigned comment added by 67.161.122.193 (talk) 07:51, 10 March 2008 (UTC)

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)

[edit] rowsize

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"[1]. 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)

  1. ^ efg's Manipulating Pixels With Delphi's ScanLine Property
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)

You are right, link has an error. I have removed eror from link. It works now , but ... your link shows blank page (?) --Adam majewski (talk) 18:42, 8 May 2008 (UTC)

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)

I have checked your link in IE and it works. It does not work in firefox ( blank page). SO how you will comment example above: compute row size for width pixel by 2 above methods and tell me what you get or where I have made an error . (:-)) --Adam majewski (talk) 06:36, 9 May 2008 (UTC)

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)