如何读取大位图图像的大小

Question

I'm having problems reading big bitmap images. Note that this is a 24bit BMP file. So I have an image with a size of 800x600. In the file, where it tells the width and height I get this.

Width (4 bytes):

20 03 00 00

Height (4 bytes):

58 02 00 00

I have exported both with Paint.NET and MS Paint programs. Both had the same output. It seems that when images get big, the calculations get wrong. With small images (100x100 and so) the results are what I want. I have tested changing the size manually (width=800;) and it works perfectly for what I need. What I do is sum all the bytes and put together on an integer.

Example: (I store the file on a vector called store):

unsigned int width = store[0x12] + store[0x13] + store[0x14] + store[0x15];

I then made the program create a file to tell me how width was stored.

ofstream s("hht.txt");
        s <<  width;
        s << "\n";
        s << dec << width;
        s << "\n";
        s << hex << width;
        s.close();

This is the output I get:

35
35
23

So, what am I doing wrong?

NOTE : -The width info is at location 0x12 and height is at 0x16. -The file is 800x600. -I don't know how the height is, but I know it is wrong as well.

Answer 1

There are a couple things wrong with how you're computing the width.

unsigned int width = store[0x12] + store[0x13] + store[0x14] + store[0x15];

What you are doing here with your example of width is this:

unsigned int width = 0x20 + 0x03 + 0x00 + 0x00; // width = 0x23

Which is this in decimal:

unsigned int width = 32 + 3 + 0 + 0; // width = 35

This doesn't get you the real value of 20 03 00 00 because in this case 03 isn't supposed to represent 0x03, it's supposed to represent 0x0300 (768 in decimal).

Why does this work with small numbers? The answer would be that you would be adding together one number with 3 pairs of zeros in the digits that would normally need to be multiplied to get their real values. (Example: width of 32 would be 20 00 00 00, which would add together 0x20 + 0x00 + 0x00 + 0x00 to get 0x20, which is still 32 in decimal)

If you haven't noticed yet, the bitmap holds the values in little-endian order. In other words, the value of width together would not be 0x20030000 (537067520 in decimal), it would be 0x00000320 (800 in decimal, the width of your bitmap).

width = *reinterpret_cast<uint32_t>(&store[0x12])

may work in this case, but not only might this break the aliasing rules, this will only work on your implementation if uints are little-endian as well. If they are big-endian, your width would be calculated as 0x20030000 (537067520) instead of 0x00000320 (800).