3 ms·

BMP is quite complex and poorly documented (it's a bunch of random Microsoft structs and #defines), more so than PNG. BMP has compression too (RLE and Huffman)

BMP is quite complex and poorly documented (it's a bunch of random Microsoft structs and #defines), more so than PNG. BMP has compression too (RLE and Huffman). PNG is simpler here since you can just drop a DEFLATE library straight in. Images are usually stored in memory as RGBA in scanline order. You can dump this representation straight to a PNG file (edit: this is wrong, you can't). BMPs are typically written with pixels in packed BGR order, rows going bottom to top. But not always. I think they go top to bottom if you give a negative height, and you can supply masks defining which bits the RGBA come from.

georgemcbay 5y ago
If you're going to drop a library in, sure use PNG or whatever else, but the premise of this subthread was about ease of dumping an in-memory representation of the pixels into a valid file, and BMP makes that way easier than PNG does. In a couple lines of code with no external library you can create a valid BMP file with just enough header bits to tell the BMP reader how your pixels are arranged and let it deal with the conversion. Virtually all of the complexity of BMP files is optional and can be ignored by a BMP writer and just let the BMP reader worry about it. This is not true for PNGs where you have to have a significant understanding of the file format to write a PNG file. Libraries make that not matter so much but are kind of outside of the scope of where this discussion was at the time this came up. I'm certainly not advocating for BMP over PNG and most people should just include a flexible image handling library that's relevant for their given language and be done with it, but I also understand why even today programmers working in languages like C/C++ will use BMPs just to get a simple and functional export working without dealing with the complexity of using a third party library when their needs for the file format are minimal and internal to their own use and not being exposed to users.
- edflsafoiewq 5y ago
  Well, you're right. I had thought you could write an uncompressed PNG, but I was wrong, it has to be DEFLATED. You can write a series of uncompressed DEFLATE blocks like you said (not so bad), but the Adler32 and CRC32 checksums kill you.

georgemcbay 5y ago

If you're going to drop a library in, sure use PNG or whatever else, but the premise of this subthread was about ease of dumping an in-memory representation of the pixels into a valid file, and BMP makes that way easier than PNG does. In a couple lines of code with no external library you can create a valid BMP file with just enough header bits to tell the BMP reader how your pixels are arranged and let it deal with the conversion. Virtually all of the complexity of BMP files is optional and can be ignored by a BMP writer and just let the BMP reader worry about it. This is not true for PNGs where you have to have a significant understanding of the file format to write a PNG file. Libraries make that not matter so much but are kind of outside of the scope of where this discussion was at the time this came up. I'm certainly not advocating for BMP over PNG and most people should just include a flexible image handling library that's relevant for their given language and be done with it, but I also understand why even today programmers working in languages like C/C++ will use BMPs just to get a simple and functional export working without dealing with the complexity of using a third party library when their needs for the file format are minimal and internal to their own use and not being exposed to users.

edflsafoiewq 5y ago
Well, you're right. I had thought you could write an uncompressed PNG, but I was wrong, it has to be DEFLATED. You can write a series of uncompressed DEFLATE blocks like you said (not so bad), but the Adler32 and CRC32 checksums kill you.