News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

A useful tool: BMP data viewer

Started by NoCforMe, November 20, 2024, 06:32:00 PM

Previous topic - Next topic

NoCforMe

Another question, @JJ, since you've spent so much time wrestling with the RichEdit version problem:

I'm using RichEdit20A. Am I safe in assuming that most users will have that DLL installed on their systems?
Assembly language programming should be fun. That's why I do it.

sinsi

Just as a matter of interest I got rid of the buffer and wrote directly to the edit control and the window was responsive.

The new program is certainly faster for a 2002x1505x24bpp bmp (9,042,040 bytes).
Couldn't handle a 10000x10000x24bpp (300,000,054 bytes) bmp file though  :badgrin:

zedd151

#62
Quote from: NoCforMe on November 25, 2024, 10:15:50 AMI'm using RichEdit20A. Am I safe in assuming that most users will have that DLL installed on their systems?
I am not jj of couse, but I can answer that...

Yes, it should be fine to use. It has been around since the Windows xp days. It has its own issues though, as do the later versions of RichEdit.


I just tested a 23.7 MB bmp file with your program. Fast enough indeed now.

    BMP width:        3840
    BMP height:        2160
    no. planes:        1
    bits/pixel:        24
    bitmap size:        24883200 bytes
    compression:        0
    horiz. res:        3780
    vert. res:        3780
    # colors used:    0
    Bitmap stride:    11520 bytes
    Bitmap padding:    0 byte(s)
    BMP header size:    40 bytes

later: this one took several seconds to load. But fast enough for the bmp's size (155MB).  :thumbsup:
BMP width: 9600
BMP height: 5400
no. planes: 1
bits/pixel: 24
bitmap size: 155520000 bytes
compression: 0
horiz. res: 3780
vert. res: 3780
# colors used: 0
Bitmap stride: 28800 bytes
Bitmap padding: 0 byte(s)
BMP header size: 40 bytes

NoCforMe

Quote from: sinsi on November 25, 2024, 10:19:45 AMThe new program is certainly faster for a 2002x1505x24bpp bmp (9,042,040 bytes).
Couldn't handle a 10000x10000x24bpp (300,000,054 bytes) bmp file though  :badgrin:
So what happened, pray tell? Crash? Hang? Something else?

Where the bloody hell did you get a BMP file like that?

Maybe I should look at the file size, and if it's above some reasonable limit issue an error message like "What, are you nuts?".
Assembly language programming should be fun. That's why I do it.

sinsi

Good ol' Windows, just crashes instead of popping up any sort of error :rolleyes:
(fd4.4230): 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 e:\Desktop\BMPinfo2.exe
eax=0000001c ebx=0019f960 ecx=0000001c edx=0000001c esi=0019f440 edi=00000000
eip=00401fa9 esp=0019f434 ebp=0019f878 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210246
BMPinfo2+0x1fa9:
00401fa9 f3a4            rep movs byte ptr es:[edi],byte ptr [esi]

Quote from: NoCforMe on November 25, 2024, 10:38:17 AMWhere the bloody hell did you get a BMP file like that?
Start Paint, change the image properties, save as BMP

Quote from: NoCforMe on November 25, 2024, 10:38:17 AMMaybe I should look at the file size, and if it's above some reasonable limit issue an error message like "What, are you nuts?".
Some images from Hubble that you can download are pretty massive. Granted they are compressed PNGs but still can be 90MB or so...

NoCforMe

Attached is what is probably going to be the last version of this utility.

So @sinsi: I created a humongous BMP to test this, 10,000 X 10,000.
It works. And it doesn't work.
It works in that my code manages to slog through each and every pixel of that file.
But when it comes time to actually display the data (when it's dumping the text to the RichEdit control), it just sits there. Doesn't hang; the UI is responsive. But it just never fills the control. I've let it sit for 10 minutes and no go.

So I'm basically giving up on that. Here's the thing: who the hell is going to actually use this to display data from a file that big?
Yes, as you point out, huge image files do exist. For one thing, I highly doubt that any of those files will be in BMP format nowadays; more likely JPEG, or perhaps PNG, maybe even TIFF.

Besides, I have to ask: what, really, is the use of this program? I ended up using it to create that huge BMP: I took a 100x100 image and used it as a "stamp" to fill up the big file, 10,000 times. Other than that even I haven't really used it. I wrote it kind of as a challenge more than anything.

The text file generated by this BMP is about 720 megabytes (!!). You can't even load a file that big into Notepad. I was able to load it into my EdAsm editor which uses a RichEdit contol (although it reported the size as something over 600 MB), but even it struggled to display it: it would show only so much, then if you scrolled down it would show a little bit more, etc., etc. So entirely impractical to even view this data. (I tested this by writing the text data to a file instead of to the RichEdit control.)

Anyhow, it was fun while it lasted. Now on to the next obsession ...
Assembly language programming should be fun. That's why I do it.

TimoVJL

perhaps better to ask user for big files and not waste their time for junk ?
May the source be with you

daydreamer

There is enough detailed moon data + moonlander 3d model to create photorealistic moonlander game instead of good old Atari game
my none asm creations
https://masm32.com/board/index.php?topic=6937.msg74303#msg74303
I am an Invoker
"An Invoker is a mage who specializes in the manipulation of raw and elemental energies."
Like SIMD coding

NoCforMe

Quote from: TimoVJL on December 04, 2024, 11:31:36 PMperhaps better to ask user for big files and not waste their time for junk ?

That might not be such a bad idea.
Assembly language programming should be fun. That's why I do it.