Strange Keyboard (take 2)

From: Jules Richardson <julesrichardsonuk_at_yahoo.co.uk>
Date: Sun Mar 14 05:45:16 2004

On Sun, 2004-03-14 at 00:48, Dan Williams wrote:
> >I tried, but they all cause bmptoppm to crash. (For others: the zip
> >file contains four files, keyboard%d.bmp for %d from 1 thorugh 4.)
> >
> >[Sparkle] 1701> bmptoppm < keyboard1.bmp > keyboard1.ppm
> >bmptoppm: Windows BMP, 637x825x24
> >bmptoppm: cbFix: 40
> >bmptoppm: cx: 637
> >bmptoppm: cy: 825
> >bmptoppm: cPlanes: 1
> >bmptoppm: cBitCount: 24
> >bmptoppm: warning: offBits is 54, expected 67108918

54 looks fine - offbits is the byte offset after the file header where
the image data begins. The image header itself (giving width, height
info etc.) is always 54 bytes in length, so an offset of 54 is quite
normal, implying the image data begins right after the image header.

An expected offset over 60MB in size seems extremely wrong :)

> I managed to view them fine with xv under solaris, is there a problem
> with bmptoppm ?

Here's a theory...

Run hexdump -C on the file:

Bytes 0 and 1 should have the ascii characters 'BM'.

Bytes 2,3,4,5 give the size in 4 byte units of the file.

Bytes 6,7,8,9 are reserved - I've only ever seen these set to zero.

Bytes 10,11,12,13 give the offbits value, least significant byte first.
It's found 54, so is obviously reading that correctly.

Bytes 14,15,16,17 are within the image header itself and give the size
of the image header - 12 bytes for an OS/2 bmp file, 40 bytes for a
Windows bmp, and no expected other values. Maybe this is set wrong in
the bmp files Lyos created for some reason - I could see that some image
decoders might be really strict about this value (and bail because
offbits is less than the image header size + the file header size)
whilst others might be sloppy (i.e. "if it isn't set to 12 then simply
assume a 40 byte Windows header"). bmptoppm extracts the
width/height/colour-depth info from the image header though, so it's
obviously seems to assume Windows format and read 40 bytes at that
point; looks like it only sanity-checks the header size against the
offbits value after this and then breaks.

I haven't got a copy of the zipfile that Lyos sent to try otherwise I'd
take a look...

cheers

Jules
Received on Sun Mar 14 2004 - 05:45:16 GMT