|
-
Nov 8th, 2002, 01:03 PM
#1
Thread Starter
Hyperactive Member
loss-less compression and Memory
Hi
Two questions here:
PART 1
I need memory explained to me. Is it a location of all the bites or a streaming mechanism for temporary space on hard disc? If it is the former then help me understand this: I only have 56k memory and I've got 5 pics open in memory so why can't I copy this super small bmp object from memory to a super small file and read it back whenever I want using the same programming that manipulates the bits from this memory? Instead I get this bloated bmp of 1.5 mb's per pic. Please help me understand.
PART 2
I would like to find out how to compress bmps from my screen to a file. Here's what I've got.
1) Always using a scale of 600X800 pixels (640,000 total)
2) Pics made with roughly 2400 finite colors generated through program (requires full color settings though).
I figure 1,152,000,000 possible unique bites for each pic, right? for the most part my pics will never have more than 200 unique colors and thus it should be a wicked small file. Well I don't need to record the x,y's cause I can scroll through and set them I guess. How do I eliminate the duplicate consecutive bites and mark them in program so my x y loop will know to just assign the same color again? This would be a great start for what I want do do. Can anyone help?
-
Nov 8th, 2002, 03:07 PM
#2
Frenzied Member
The size of .EXE file is not the final size of the running image in memory.
Let's say you have a simple app with a picture box. The app compiles to like 100K.
(All of this ignores the VB virtual machine that has to run which uses a LOT of memory all by itself)
When the image file is run, you incur demand-zero paging. This means memory is allocated to your app to store things like strings and other data. You use more memory than 100K.
As you put data into string a, you incur demand-zero paging, for example. Memory wasn't there beforehand because the compiler had no idea how much 'stuff' was going to be placed in the string.
Next, you load the picture box. It lives in an .OCX file. The SCM maps the OCX and all of it's supoporting code into your process space, and dynamically aloocates memory to hold the image.
Voila - you're using several MB's of memory all from a 100K .EXE.

In other words, your .BMP is 1.5 MB.
-
Nov 8th, 2002, 03:13 PM
#3
Frenzied Member
Part 2:
Consider using either ZLIB or Info-Zip to compress your data.
Unless you fully undertand Hufman coding and Lev-Zempel compression use someboy else's code.
Both of these are Public Domain zip add-ons that you can call from VB.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|