Jump to content
  • Advertisement
Sign in to follow this  
deadimp

Wierd Bitmap Format? (New Question)

This topic is 4843 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am trying to read the first line of a bitmap's data using simple file I/O, and the header information works fine, yet I seem to run into a logical error: When I read the bitmap using a hex editor, I found out it started on the first pixel of the last line... Are the rows being stored in a flipped order? How do I properly access the first row? Bitmap: 1081x9 24-bit EDIT: The new question is in my latest post [Edited by - deadimp on August 13, 2005 7:26:50 PM]

Share this post


Link to post
Share on other sites
Advertisement
The short answer is, yes, the rows are stored starting with the bottom row first. To read in the image, you just read it one row at a time, copying the first row to the bottom row of your surface and working your way up.

PS - I haven't the slightest idea why Microsoft made Bitmap formats work this way. If someone would enlighten us, I would appreciate it.

Share this post


Link to post
Share on other sites
Quote:
Original post by nimrand
The short answer is, yes, the rows are stored starting with the bottom row first. To read in the image, you just read it one row at a time, copying the first row to the bottom row of your surface and working your way up.

PS - I haven't the slightest idea why Microsoft made Bitmap formats work this way. If someone would enlighten us, I would appreciate it.


if i remember correctly that was adopted because it was slightly faster to process and has some connection the the OS-2 compatibility era.

Share this post


Link to post
Share on other sites
The bitmap structure allows data to be stored both ways top to bottom and bottom to top, from what I remember when we covered bitmaps there should be a tag bit somewhere that lets you know which way the data is stored, check the docs on msdn.

Share this post


Link to post
Share on other sites
The sign of the height of the bitmap determines how whether or not the bitmap is top down or bottom up.

Quote:
From MSDN
If biHeight is positive, the bitmap is a bottom-up DIB and its origin is the lower-left corner. If biHeight is negative, the bitmap is a top-down DIB and its origin is the upper-left corner.

If biHeight is negative, indicating a top-down DIB, biCompression must be either BI_RGB or BI_BITFIELDS. Top-down DIBs cannot be compressed.

Share this post


Link to post
Share on other sites
New Question: How do I determine the Pitch (Width in bytes) of a bitmap using the data from the bitmap's file? For some reason, I am also getting some padding in the image, around 8 extra pixels on the row... (IMG: 811x9, biHeight is negative)

Share this post


Link to post
Share on other sites
Bitmap files in Windows NT and later are required to have the lines to be DWORD aligned, i.e. evenly divisible by 4 unless it is RLE encoded.

Share this post


Link to post
Share on other sites
Thanks for the help. (I'm about to test it)

EDIT: Holy crap... It worked! Thanks for all of y'alls help.
Resulting code:
ULONG Pitch=Width*3;
if (Pitch % 4!=0) Pitch=(Pitch/4)*4+4; //Make sure it is aligned


[Edited by - deadimp on August 14, 2005 12:55:16 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!