Results 1 to 3 of 3

Thread: freading a bitmap (c)

  1. #1
    Join Date
    Feb 2008
    Beans
    318
    Distro
    Ubuntu 10.04 Lucid Lynx

    freading a bitmap (c)

    So I have been working with importing bitmaps into a c/++ program and storing the data as "width," "height," and "color data." After working with the BMP files now for a while, I realized something peculiar.

    At first, I was testing with bitmaps around 10x10 and noticed that after the 54 byte header, the bitmaps followed the pattern of 3 bytes per pixel per row. However, at the end of each row, 2 blank bytes were thrown in. I thought this odd but incorporated it into my code and it imported the files correctly.

    Then I tried a larger file (256x256), and noticed that my code completely failed to parse the image in a way that almost offset some of the pixels. After some testing I found that there weren't 2 blank bytes after each row in the file. So I revised my code to the original state, but then the 10x10s didn't import correctly. After different filesize testing, I came to the explanation that BMPs under 16x16 have this 2 byte padding between rows.

    Anyone have a similar experience?

    Edit: On second look, it doesn't have to do with the bitmap's size exactly, it seems like it depends on whether the file is a 2^n x 2^n or some other resolution...

    Edit2: Turns out there must be padding to make the number of the bytes in each row of a bitmap a multiple of 4. Now I know.
    Last edited by sdlynx; December 22nd, 2010 at 04:51 AM.

  2. #2
    Join Date
    Feb 2008
    Beans
    318
    Distro
    Ubuntu 10.04 Lucid Lynx

    Re: freading a bitmap (c)

    This was a double post, oops.
    Last edited by sdlynx; December 22nd, 2010 at 04:42 AM. Reason: double post

  3. #3
    Join Date
    Sep 2007
    Location
    Christchurch, New Zealand
    Beans
    1,328
    Distro
    Ubuntu

    Re: freading a bitmap (c)

    Quote Originally Posted by sdlynx View Post
    So I have been working with importing bitmaps into a c/++ program and storing the data as "width," "height," and "color data." After working with the BMP files now for a while, I realized something peculiar.

    At first, I was testing with bitmaps around 10x10 and noticed that after the 54 byte header, the bitmaps followed the pattern of 3 bytes per pixel per row. However, at the end of each row, 2 blank bytes were thrown in. I thought this odd but incorporated it into my code and it imported the files correctly.

    Then I tried a larger file (256x256), and noticed that my code completely failed to parse the image in a way that almost offset some of the pixels. After some testing I found that there weren't 2 blank bytes after each row in the file. So I revised my code to the original state, but then the 10x10s didn't import correctly. After different filesize testing, I came to the explanation that BMPs under 16x16 have this 2 byte padding between rows.

    Anyone have a similar experience?

    Edit: On second look, it doesn't have to do with the bitmap's size exactly, it seems like it depends on whether the file is a 2^n x 2^n or some other resolution...

    Edit2: Turns out there must be padding to make the number of the bytes in each row of a bitmap a multiple of 4. Now I know.
    Yes, this is exactly right.
    It depends on your processor architecture: A 32 bit machine adresses words of 4 bytes at a time which is evidently 4 times faster than fetching them one byte at a time... so to make things easier at the end of each line they just pad it out to the next 4 byte boundary. That way it is easier to find the start of each line instead of having to try and unpack bytes from the previous line... You might have to check what happens on a 64 bit machine

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •