Assuming the simplest case where you''re reading 24bit uncompressed bmps,(lower bit counts have colour maps between the info header and pixel data, and if you want compression then use PNG the image is stored as 8bit per channel BGR triplets from the bottom up (i.e. last triplet of file == top left pixel of image). You''re right to use the bOffBits value, as there are sometimes padding bytes after the colourmap.

Oh, and all the rows are 4byte aligned, so the size of a row in bytes will be (pixels_per_row + 0x3) & ~0x3. For more information, take a look at the bmp specification in MSDN, or from wotsit.org.

Hope that helps!
Jim

I suggest you get hold of a copy of FileWalk.EXE, it''s an old tool from Micro$oft''s Video for Windows days. It displays a BMP, WAVes, etc, as the list of structures (and their names) which you can double click on to expand and see all the members and their offsets into the file.

Also, from the same tool set, BitEdit.EXE/PalEDIT whic are brillant for editing palettes of BMPs.

I found a copy resently on the net (but can''t remember the URL), try using an ftp searcher looking for the compressed file bitedit.ex_ which can be uncompressed using the standard expand utility.

> the image is stored as 8bit per channel BGR triplets from the bottom up.

This is true if Height is +ve, but a few editors store BMP top-down (left to right), you check for this by checking Height<0, where abs(Height) is the height of the bitmap.