Re: working with bitmaps in C


"Ernie Wright" <erniew@xxxxxxxxxxx> wrote in message news:mIWdnWEh49TlW-7anZ2dnUVZ_gCdnZ2d@xxxxxxxxxxxxxx
Malcolm McLean wrote:

"Ernie Wright" <erniew@xxxxxxxxxxx> wrote in message

Broken for 24-bit and 32-bit, and for 4-bit old-style. See below.

No, it's been tested and basically works. It might not work on everything, but it will load the vast majority of BMPs OK.

Tested in what way?

If you loadbmp(), then savebmp() a 24-bit BMP and then examine the
output of savebmp(), you'll find that the red and blue channels have
been swapped. After seeing the relevant problem in the source code, I
actually compiled and tested it to confirm that I hadn't missed
something. I wasn't guessing.

Your code to load 24-bit pixels (with indention repaired) is

case 24:
for(i=0;i<bmpheader.height;i++)
{
for(ii=0;ii<bmpheader.width;ii++)
{
target = (i * bmpheader.width * 3) + ii * 3;
answer[target] = fgetc(fp);
answer[target+1] = fgetc(fp);
answer[target+2] = fgetc(fp);

You can see that this stores pixels in answer[] in the same BGR order as
they're written in the BMP.

You're right.
The file is a different version to the one published in the book, which has it the right way round. Obviously something has gone wrong with my versioning.

The specification claims that 4-bit old-style BMP has a 16-color palette.
It's been so long since I've encountered one of these that I wouldn't
know where to look for one now. Unless you know of users that actually
have to deal with these (they haven't been written by Microsoft code
since Windows 2.x), I'd be tempted to strip all of that cruft out of
your loader.

It is a problem testing when you don't have versions of the input. Also if degenerate files are in circulation. You get this with IFF files quite a bit - in practise the best thing is to search for the 4-byte tag sequence. The format says field sizes should be included, and you skip to the next tag, but actually you are much more likely to get a corrupt field size than a chance occurence of the tag.

The other potential problem was your code's handling of header sizes
that weren't one of the two it expects. You're most likely to run into
this if a user tries to load an OS/2 BMP, or a file that's not a BMP at
all but happens to start with the letters 'BM', but it's also a forward
compatibility issue, in the event a new version of BMP comes along with
a different header size.

That's a good point. It should be returning -1 instead of zero on an unrecognised header size, at least. Probably we should try to read it as a 40. However to do a really good job we've got to skip to the raster bits, which means a total rewrite and lots of complications.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


.

Relevant Pages

  • Re: working with bitmaps in C
    ... It might not work on everything, but it will load the vast majority of BMPs OK. ... If you loadbmp(), then savebmpa 24-bit BMP and then examine the ... Creating test images is not difficult seeing as you are using an OS that comes with a program able to save in the relevant format. ... The format says field sizes should be included, and you skip to the next tag, but actually you are much more likely to get a corrupt field size than a chance occurence of the tag. ...
    (comp.lang.c)
  • Re: BMP to JPG (again)
    ... Now i know it also can load a BMP :-) ... > Boris Nienke wrote: ... >> possible to do convertion to JPG with an in-memory bitmap. ...
    (microsoft.public.dotnet.framework.compactframework)
  • Loading and Saving a bitmap
    ... I need to load a wonderful 16 Million color .bmp from a file, ... and I don't need to display the final image). ... under the 256 video colors resolution. ...
    (microsoft.public.vb.winapi)
  • Re: Dynamic image loading
    ... component that I can use, which I can load the blob (or data stream) into, ... and the component can then figure out the type of image (bmp, jpg, gif, ...
    (borland.public.delphi.thirdpartytools.general)