A useful tool: BMP data viewer

[zedd151]

I'm really starting to think that this might have something to do with the dialog manager. I was considering using IsDialogMessage(), but since I don't have a message loop that won't do much good.

Have you thought about foregoing the dialog box and using either a Window, or even writing to stdout, in a console version? - At least for only the bitmap data...

I would isolate only the bitmap processing functions (you would still have to calculate where the bitmap data starts, of course - for the different flavors of bitmaps), omitting the header info display, and the mini bitmap display, to concentrate solely on making the bitmap data processing faster (use some form of timing mechanism, to verify just how much faster one algorithm is, versus another)
You already know that your bitmap headers info processing, and miniature bitmap processing works okay.

After you get that as fast as possible, then you can finish up the GUI code.    that's my tip/suggestion of the day.

[zedd151]

## UPDATED ##
I made a little test program of my own. It simply opens a pre-defined bitmap file (included), processes the bitmap bytes, writes the data to a file then exits. It is very fast, your mileage may vary. There is a huge 24 bit bitmap file 5MB+ used for testing the program included in the zip file.

This code is only for proof of concept, and useless otherwise.   meaning, I don't want to hear anything about possible flaws/bugs in it.    just kiddin'.

stride and header size are hard coded for this test, and a table for byte to string conversion is used for speediness.

The code has been revised a bit...
Now formatted for 8 RGB sequences per line, and is finished!

a few changes made...

[sinsi]

I inserted some code at the start of ProcessBitmapData which just wrote a char to the edit window in an endless loop to simulate a busy thread and found the window was responsive :shrug:

[NoCforMe]

If anyone knows anything about either of these two things, could you reply and post what you know here? It would be much appreciated.

Can't do a comment on those 2 things, because the program crashes - feeding it with a very simple 16bpp bitmap (attached). I'm using WinXP 32bit, in a VM under Linux, though. Seems the crash is due to "TextBuffer" being too small...

Crash was due to the program being totally confused by 16bpp images. That has been added and it now works with them. New version attached here. Could you give it a whirl to check it? Thanks.

BTW, that BMP you used was originally generated by my BMPfromText program, but it's been modified. Did you use my program to create it? That program creates 32bpp BMPs, but yours somehow got converted to 16bpp: what did you use to do that? I don't think I have anything here that's capable of doing that; Paint Shop Pro only creates 24bpp BMPs.

There's another little wrinkle here: your 16bpp file has 65,536 in the "colors used" field (the biClrUsed member of the BITMAPINFOHEADER structure). Micro$oft has this to say about that member:

Bitmaps that are 16-, 24-, or 32-bpp do not require color tables, but may have them to specify colors for palettized devices. If a color table is present for 16-, 24-, or 32-bpp bitmap, the biClrUsed member specifies the size of the color table and the color table must have that many colors in it. If biClrUsed is zero, there is no color table.

Except that in the case of the file you attached, this member is not zero, and yet there is no "color table" (palette). ????? So in my code I'm just ignoring this field not being zero and assuming there's no palette in 16bpp BMPs.

Anyone know more about this?

[NoCforMe]

I inserted some code at the start of ProcessBitmapData which just wrote a char to the edit window in an endless loop to simulate a busy thread and found the window was responsive :shrug:

Interesting, and I'm sure that means something.
However, if you run it and it goes unresponsive, you can't select text in the edit window (with the mouse), which you should be able to do. So apparently it's responsive "from the inside" (i.e., from code that writes to the window) but not from "outside" (user interaction). ?????

Help! I need someone who knows a lot about Win32 threads to shed some light on this situation.

[NoCforMe]

Have you thought about foregoing the dialog box and using either a Window, or even writing to stdout, in a console version? - At least for only the bitmap data...

I ended up converting the whole program to one that uses a main window instead of using a dialog as a main window.

It still goes unresponsive. So apparently the dialog manager isn't the source of this problem.

BTW, do you realize what a pain in the ass it is to do this? Create a main-window app vs. a dialog-based one? With a dialog, you have a nice dialog editor to place all your controls in the dialog (I use my homemade one that creates dialog memory templates instead of a resource editor, but same difference). With a main window you have to figure the X-position, Y-position, width & height of each and every thing in the dialog. By hand. (WinSpy actually helps a lot here, as you can use it to move things around on screen until they look right, but you still have to do a lot of dicking around.)

You also don't get the nice dialog manager touches like applying a decent-looking font to everything in the dialog: you've got to obtain a font handle and then use WM_SETFONT to apply that font to each and every control that contains text. Otherwise they use the default font which looks like shit.

Then there's the whole thing of colors; ugh. Even if you select a plain white background, which works for some controls, it doesn't work for others, f'rinstance checkboxes which come with a default gray background. Oh, sure, you can play games with WM_CTLCOLORBTN to set the background to your liking, but that's even more work.

Now I realize why all my programs for the last couple years have been dialog-based ones.

[_japheth]

Crash was due to the program being totally confused by 16bpp images. That has been added and it now works with them. New version attached here. Could you give it a whirl to check it? Thanks.

Thanks, will do ASAP.

BTW, that BMP you used was originally generated by my BMPfromText program, but it's been modified. Did you use my program to create it? That program creates 32bpp BMPs, but yours somehow got converted to 16bpp: what did you use to do that?

I can't remember doing anything with it. Perhaps it's just because the Windows XP display driver in the VM is setup to a 1280x1024x16 resolution?

[NoCforMe]

BTW, that BMP you used was originally generated by my BMPfromText program, but it's been modified. Did you use my program to create it? That program creates 32bpp BMPs, but yours somehow got converted to 16bpp: what did you use to do that?

I can't remember doing anything with it. Perhaps it's just because the Windows XP display driver in the VM is setup to a 1280x1024x16 resolution?

I don't see how that would result in the file being rewritten in a different format.
You must have done something to make it into a 16bpp BMP. (Which seems to be quite the oddball format, BTW.)

Anyhow.

So you're really running with a 16-color display? Must be pretty ugly, eh?

[_japheth]

Ok, 16bpp bitmaps work now flawlessly.

I don't see how that would result in the file being rewritten in a different format.
You must have done something to make it into a 16bpp BMP. (Which seems to be quite the oddball format, BTW.)

Strange, since there's not much installed on that VM, not even PSP - so it must have been good old MS Paint...

So you're really running with a 16-color display? Must be pretty ugly, eh?

IMO, the difference isn't that obvious - might be an issue for certain kinds of movies, though ... 

[NoCforMe]

I don't see how that would result in the file being rewritten in a different format.
You must have done something to make it into a 16bpp BMP. (Which seems to be quite the oddball format, BTW.)

Strange, since there's not much installed on that VM, not even PSP - so it must have been good old MS Paint...

Odd; I just loaded that BMP in Paint, then went to save it:
The only options for BMP formats are monochrome (1bpp), 16 color (4bpp), 256 color (8bpp) and 24-bit (16 million+ colors). No 16bpp option.

It's a mystery ...

[zedd151]

The GIMP can save in 16 bit format. 5 bits red, 6 bits green, 5 bits blue, iirc.
A few minutes and 200+ MB later... I just reinstalled the GIMP.
Yup, I just checked. R5 G6 B5 is one of the options for 16bpp.

I am certain there is other software that can also save in that format.

[NoCforMe]

R5 G6 B5

I was wondering how you'd encode 3 colors in 16 bits.
Funky format.

[sinsi]

There also used to be 15bpp (5,5,5 plus a spare), this goes back to the early days of win 3 and the emergence of VESA.

[zedd151]

Funky format.

From back in the days of needing to reduce memory/disk space I would imagine. Unless 24 bit was not yet 'a thing'?

Anyway, I have updated my little test proggie in reply #31, if anyone is interested.

[NoCforMe]

I think the extra bit for green is because the human eye is most sensitive to this color (505 nm).