A useful tool: BMP data viewer

[NoCforMe]

Finally finished my BMP data viewer and tested it: seems to work fine with all possible BMP formats. This program is the reason I posted about aligning data to 32-bit boundaries, since all BMP bitmap data must be aligned so.

Check it out. It displays all the data in the BMP header, shows the bitmap bits, and shows the palette for those files (4- and 8-bits per pixel) that have a palette. Plus a few more bits of info: the stride and bitmap padding, whether the file has alpha-channel data (32bpp files only), and the number of unique colors in the bitmap for paletted files.

Let me know of any problems, suggestions, etc. If you don't want to wait for all that data to scroll by, uncheck the "Show bitmap data" checkbox. The info displays in an edit control so you can copy the data from it.
Fixed version attached to reply #1 below.

[NoCforMe]

Whoops, sorry: one of my buffers wasn't quite big enough, and when I tested it with a larger BMP ...

New version (that won't stall) attached.

[sinsi]

Code Select Expand

(42c4.d08): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for BMPinfo2.exe
eax=00000030 ebx=02bd0020 ecx=00000003 edx=00000001 esi=02cd0ffd edi=00cff000
eip=00262cac esp=00cfefc8 ebp=00cff0e8 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210216
BMPinfo2!ShowBitmapData+0x2ff:
00262cac ad              lods    dword ptr [esi]      ds:002b:02cd0ffd=????????
Bitmap is 1107x711x24bpp (2,363,418 bytes)

Your info

Code Select Expand

Info for file "Untitled.bmp":

BMP width: 1107
BMP height: 711
no. planes: 1
bits/pixel: 24
bitmap size: 2363364 bytes
compression: 0
horiz. res: 3778
vert. res: 3778
# colors used: 0
Bitmap stride: 3324 bytes
Bitmap padding: 3 byte(s)

--- BMP has no palette ---


[zedd151]

With the checkbox checked, and while the text is scrolling, if any user interaction with the window - the program becomes unresponsive, cannot move or minimize the window, plus the dreaded 'busy' cursor pop up.

Also for larger 24 bit bitmaps, displayed bitmap size = 0. Which obviously is wrong.
For larger indexed images, program crashes.

I will run some more tests in a little while, and possibly attach any other bitmaps that cause wrong results. (Via PostImage) I have to test first if the posted image is exactly what I had uploaded (including the bitmap headers) Not sure if PostImage does any manipulation of the uploaded files, or not...


Later:  It seems that PostImage converts the bitmap to .png image. 
I'll try to zip it, if I can get it small enough to attach here.

Two (zipped seperately) images attached. "2.bmp" uses 24 bit color and displayed "bitmap size = 0", "4.bmp" uses 256 colors and the program crashes.

[sinsi]

Buffer wasn't big enough

Code Select Expand

TheDialogProc PROC hWin:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
local bmpfilesize:DWORD   ;<<<added
;...
; Read bitmap header:
INVOKE CreateFile, ADDR fileOpenName, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL
MOV bmpFileHandle, EAX

    invoke GetFileSize,eax,0 ;<<<added
    mov bmpfilesize,eax      ;<<<added
   
INVOKE HeapAlloc, HeapHandle, 0, eax ;<<<moved from above and changed
MOV FileBuffer, EAX               ;<<<moved from above

INVOKE ReadFile, bmpFileHandle, FileBuffer, bmpfilesize, ADDR bytesRead, NULL ;<<<added bmpfilesize

BITMAPFILEHEADER partly wrong

Code Select Expand

bfOffBits DD ? ;Offset to bitmap data in file (from end of this structure)
;incorrect, it's the offset from the header start

It sure takes a long time to show the bitmap bits.

[sinsi]

A slight speed up

Code Select Expand

;before you start writing the bitmap
    invoke SendMessage,ResultsDispHandle,WM_SETREDRAW,0,0
;when you exit
    invoke SendMessage,ResultsDispHandle,WM_SETREDRAW,1,0
    invoke RedrawWindow,ResultsDispHandle,0,0,RDW_ERASE or RDW_FRAME or RDW_INVALIDATE or RDW_ALLCHILDREN


[Biterider]

Hi
This is a good idea, sinsi!
During this time you can also set the cursor to IDC_WAIT.
Alternatively, a spinner would be a nice addition.

Biterider

[NoCforMe]

Thanks for all comments so far.

Yes, I realized there was a massive problem with how long things took for really large BMPs (as well as another buffer not large enough). Which has prompted me to revamp how I display all that bitmap info.

Currently I'm just writing all that text to the edit control directly. Now, even though I bigger-ized the edit control's text buffer (by using the EM_SETLIMITTEXT message), if you watch the program's progress with Task Manager you'll see a slowly but surely increasing memory usage as the edit control tries to cope with all that incoming text. Not a good arrangement (which is also why the program becomes unresponsive).

So what I'm going to do instead is write all that text to a buffer, then at the end dump it into the edit control all at once. That should solve all these problems.

Also for larger 24 bit bitmaps, displayed bitmap size = 0. Which obviously is wrong.

Actually, no, that's correct: I'm reading the bitmap size from the BMP header, which can set that field to zero. I think that field is only used by compressed BMPs (which I don't handle).

I'll have an updated version soon. Thanks for being my guinea pigs!

[zedd151]

Also for larger 24 bit bitmaps, displayed bitmap size = 0. Which obviously is wrong.

Actually, no, that's correct: I'm reading the bitmap size from the BMP header, which can set that field to zero.

It seems wrong though, or at least misleading. Maybe you should use "Header bitmap size" for size that was read from the header, and a separate listing "Actual bitmap size" displaying the actual size of the bitmap. This would help to avoid any confusion.

[NoCforMe]

OK, latest version here.
I've pretty much fixed the unresponsiveness problem. Pretty much, but not completely: using a really big BMP (1.8MB), it goes catatonic for maybe 8-10 seconds. Not perfect but better.

Not sure what I could do to remedy this. One thing I do is to display a "wait" message in the edit control, so at least the user has some clue as to what's going on. But I really don't like that "freezing" ...

Larry: could you test this again with that file that showed a bitmap size of 0? I added code to show the actual size in that case.

Thanks to everyone for their patience! I'm trying to get the code monkeys here at NoCforMe Laboratories, GmbH, to be a bit more careful in releasing code ...

[sinsi]

File is too big (> 2MB).

Really? Why don't you dynamically allocate memory? 2MB is on the small size for an uncompressed BMP.

[zedd151]

Larry: could you test this again with that file that showed a bitmap size of 0? I added code to show the actual size in that case.

Program says: "File is too big (> 2 MB)".
It is a 5.93 MB size file.    You never know just how big a user will use the program on.

For the 256 color version of the same bitmap, the report window says... "Wait..." and I am still waiting.    It does show a miniature of the file, though.

edited later -->  It did finish and display after quite some time.

Both of those files are attached above  (the zips in post #3), for your own testing...     error correction: I orignally wrote post #8, its in post #3

[NoCforMe]

OK, dynamic memory allocation it is. I told those damned code monkeys they needed to do this, but they thought I was being silly.

Give me a couple hours here.

[NoCforMe]

One basic question, though, before I start revamping this code:
Do you think anyone's actually going to use all this bitmap data?
I'd hate to get this working all nice and perfect but to no practical use.

(The displayed text will be larger than the BMP file)

[zedd151]

One basic question, though, before I start revamping this code:
Do you think anyone's actually going to use all this bitmap data?
I'd hate to get this working all nice and perfect but to no practical use.

(The displayed text will be larger than the BMP file)

Personally, I would use a hex editor myself. But you never know about anyone else.

Speaking of hex editors, I had played around a bit with trying to write one years ago. The trick to that is to not try to display all the data at one time, but only portions of it from a small buffer... if I can find that half finished code, I might post it some day. Later: I looked for it, but did not find it.