I found this anomaly when running peek, then confirmed with gdb that bi.biSizeImage is getting set to 4294966864 when it should be 432.


Ah, but it is not random at all! In fact, it's almost correct!

It looks like you are unaware of a couple features that are going on. I bet that the actual hex number that you're seeing for biSizeImage is FFFFFE50. Two things are at work here.

First, you're seeing a two's complement representation of a negative number. (If you want to know, google two's complement. It's too long to explain here.) The actual value you are seeing in decimal is -432, not 4294966864.

So where does the negative number come from? Go back and read the spec on bitmaps. The sign of biHeight tells the system whether the bitmap starts at the top or the bottom of the image. Most of the files start at the top and have a negative biHeight. So, assuming the actual calculation is correct, your code is almost right. You just need to use the absolute value of biHeight.

If this answer makes you happy, please accept it so that the question is removed from the unanswered question pool. Let's keep up on forum maintenance. ;-)

  • Duh! Thanks so much!
    – jhschwartz
    Jun 12 '15 at 21:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .