Bitmap handler

[Zack]

I'm trying to code a bitmap routine by hand as opposed to using BLOAD, and it's giving me trouble.

Code:

type bitmap_header
    bfType          as ushort
    bfsize          as uinteger
    bfReserved1     as ushort
    bfReserved2     as ushort
    bfOffBits       as uinteger
    biSize          as uinteger
    biWidth         as uinteger
    biHeight        as uinteger
    biPlanes        as ushort
    biBitCount      as ushort
    biCompression   as uinteger
    biSizeImage     as uinteger
    biXPelsPerMeter as uinteger
    biYPelsPerMeter as uinteger
    biClrUsed       as uinteger
    biClrImportant  as uinteger
end type
type rgb_24bit
    b as ubyte
    g as ubyte
    r as ubyte
end type
dim bmp_header as bitmap_header
dim image(bmp_header.biWidth*bmp_header.biHeight) as rgb_24bit
open "infile.bmp" for binary as #1
get #1,,bmp_header
get #1,,image()
close #1
print bmp_header.biWidth,bmp_header.biHeight
sleep

infile.bmp is 20x20, but when I run the program it prints 1310720 and 65536. What am I doing wrong - do I have the bitmap_header TYPE incorrect?

[TheAdventMaster]

Fixed: All you had to do was input the field = 1

Code:

type bitmap_header field = 1
    bfType          as ushort
    bfsize          as uinteger
    bfReserved1     as ushort
    bfReserved2     as ushort
    bfOffBits       as uinteger
    biSize          as uinteger
    biWidth         as uinteger
    biHeight        as uinteger
    biPlanes        as ushort
    biBitCount      as ushort
    biCompression   as uinteger
    biSizeImage     as uinteger
    biXPelsPerMeter as uinteger
    biYPelsPerMeter as uinteger
    biClrUsed       as uinteger
    biClrImportant  as uinteger
end type
type rgb_24bit
    b as ubyte
    g as ubyte
    r as ubyte
end type
dim bmp_header as bitmap_header
dim image(bmp_header.biWidth*bmp_header.biHeight) as rgb_24bit
open "bmp.bmp" for binary as #1
get #1,,bmp_header
get #1,,image()
close #1
print bmp_header.biWidth,bmp_header.biHeight
sleep

[Radical Raccoon]

What does "field = 1" do? :???:

[Zack]

Thanks, I didn't know about that.
Hahahah! In fact, look at the very example in the FBWiki...
http://www.freebasic.net/wiki/wikka.php?...KeyPgField
The example has to do with bmp headers!
Here's the code. It's way slower than bload.

Code:

type bitmap_header field=1
    bfType          as ushort
    bfsize          as uinteger
    bfReserved1     as ushort
    bfReserved2     as ushort
    bfOffBits       as uinteger
    biSize          as uinteger
    biWidth         as uinteger
    biHeight        as uinteger
    biPlanes        as ushort
    biBitCount      as ushort
    biCompression   as uinteger
    biSizeImage     as uinteger
    biXPelsPerMeter as uinteger
    biYPelsPerMeter as uinteger
    biClrUsed       as uinteger
    biClrImportant  as uinteger
end type
type rgb_24bit field=1
    b as ubyte
    g as ubyte
    r as ubyte
end type
dim bmp_header as bitmap_header
open "infile.bmp" for binary as #1
get #1,,bmp_header
redim image((bmp_header.biWidth*bmp_header.biHeight)-1) as rgb_24bit
get #1,,image()
close #1
screenres 320,200,24
for y=(bmp_header.biHeight-1) to 0 step -1
    for x=0 to (bmp_header.biWidth-1)
        pset (x,y),rgb(image(p).r,image(p).g,image(p).b)
        p+=1
    next
next
sleep

[Radical Raccoon]

I see.

[TheAdventMaster]

The example has to do with bmp headers!
Here's the code. It's way slower than bload.

Guess who posted the example there . . . about, a few hours ago? :winkwink:

[Anonymous]

The reason you have to use field=1 is because fb puts padding around TYPEs to make them dword-aligned. it's because the processor is 32-bit, so it's faster to make everything line up on 32's, noone care about an occasional wasted byte when compared to the performance boost.

But in your case, you're writing to/from a file directly, so it's reading the values with padding, and you'll misinterpret the data in this way.

You'll see that if you read from a file one elemnt of the TYPE at a time, the results will be correct.

Code:

Type bar

  As Byte x, y, z
  
End Type

? len( bar )
sleep

added an extra byte to line up on 32bit boundaries

[yetifoot]

One thing to remember when coding a BMP loader is to check odd sized images (ie 21x21)

This is because in BMP scanlines are padded to multiples of 32bit (IIRC) if necessary. I suffered much embarassment once by forgetting to code for this.

There are many useful files re: BMP on wotsit.org

[Zack]

Really? I didn't see that anywhere. Colour tables for bpp<=8 are padded to 32bits, though.

[yetifoot]

Its been a long while since i did one, maybe it is just for lower bitdepths, its worth checking in the specs though. I think it wasn't odd dimensioned that was the problem, but image widths that weren't a multiple of 4.