1. compression beta, and BIG bitmaps
Howdy.
Here's a little 16/256 color WINdose bitmap compression tool I've been working
on.
... asking for some feedback from all you graphics guru's.
http://www.king.igs.net/~wolfritz/crush.zip
btw, someone asked about handling BIG bitmaps, so here's a little 'Delphi'
article that might help.
http://www.undu.com/DN970101/00000013.htm
Wolf
2. Re: compression beta, and BIG bitmaps
- Posted by tone.skoda at siol.net
Feb 22, 2002
----- Original Message -----
From: "Wolf" <wolfritz at KING.IGS.NET>
> btw, someone asked about handling BIG bitmaps, so here's a little 'Delphi'
article that might help.
>
> http://www.undu.com/DN970101/00000013.htm
WOW! Thanks. This is really great stuff.
I have found some (russian) C code for this here
http://forum.ixbt.com/ubb/Forum26/HTML/005966.html
and it really works great.
3. Re: compression beta, and BIG bitmaps
- Posted by tone.skoda at siol.net
Feb 23, 2002
I'll take that back. I tried it with 75 MB bitmap - it works slooow.
----- Original Message -----
From: <tone.skoda at siol.net>
To: "EUforum" <EUforum at topica.com>
Subject: Re: compression beta, and BIG bitmaps
>
>
> ----- Original Message -----
> From: "Wolf" <wolfritz at KING.IGS.NET>
>
> > btw, someone asked about handling BIG bitmaps, so here's a little
'Delphi'
> article that might help.
> >
> > http://www.undu.com/DN970101/00000013.htm
>
> WOW! Thanks. This is really great stuff.
> I have found some (russian) C code for this here
> http://forum.ixbt.com/ubb/Forum26/HTML/005966.html
> and it really works great.
>
>
>
>
4. Re: compression beta, and BIG bitmaps
<tone.skoda at siol.net> wrote:
> I'll take that back. I tried it with 75 MB bitmap - it works slooow.
< chuckle >
I can imagine !
A 75 MB bitmap would translate to 300 MB of Euphoria 'sequence' just for the
pixel data !
Four bytes/byte... with a *lot* of disk swapping, no doubt.
The "Remove Colors" option is, in any case, the slowest part of the program,
and almost useless for bitmaps of more
than about 32 KB, since a 256 color palette is only 1 KB to start with.
Wolf
5. Re: compression beta, and BIG bitmaps
On 23 Feb 2002, at 11:49, Wolf wrote:
>
> <tone.skoda at siol.net> wrote:
>
> > I'll take that back. I tried it with 75 MB bitmap - it works slooow.
>
> < chuckle >
> I can imagine !
> A 75 MB bitmap would translate to 300 MB of Euphoria 'sequence' just for the
> pixel data ! Four bytes/byte... with a *lot* of disk swapping, no doubt.
Sounds like we need more and more an option to eliminate that 4byte
package for special defines, Rob. Even if it's 2bytes, that saves some of us
100's of megs of memory. How about a way to "include" the included file that
loads these big files? If the "include as" syntax knows more about the
contents of the vars and procedures in that file,, can the var tags be reduced
to 2 bytes?
Alternatively, has anyone consider using objects to point into allocated byte
arrays in memory for these huge user blocks? Personally, i don't know what
would happen if you asked windoze for physical memory that wasn't there,,
or will win32lib deal with that transparently, calling a virtual allocate(),
etc?
Kat
6. Re: compression beta, and BIG bitmaps
- Posted by tone.skoda at siol.net
Feb 23, 2002
An Euphoria library could be written to have sequences (or arrays, better
word) of bits (1 bit), bytes, chars (8 bits) and shorts (16 bits).
If you have sequence of 0's and 1's in euphoria now it takes 1000 bytes for
1000 elements. With such library it would take only 32 bytes (1000 / 4 / 8)
for same 1000 elements, only 3% of size! In integer type can be stored 32
bits or 4 characters, so strings would be 4 times smaller if saved in such
array.
Now euphoria sequence has allways 4 bytes (=32 bits) for one member, that's
a waste of space.
This library could be written using bits_to_int () or and_bits() and that
stuff.
Libraries to have arrays of bits in C were already written, so that 8 bits
are saved in 1 byte, not 8 bits in 8 bytes.
You would have to use get_member () and set_member () functions for such
array, not [].
----- Original Message -----
From: "Wolf" <wolfritz at KING.IGS.NET>
To: "EUforum" <EUforum at topica.com>
Sent: Saturday, February 23, 2002 5:49 PM
Subject: Re: compression beta, and BIG bitmaps
>
> <tone.skoda at siol.net> wrote:
>
> > I'll take that back. I tried it with 75 MB bitmap - it works slooow.
>
> < chuckle >
> I can imagine !
> A 75 MB bitmap would translate to 300 MB of Euphoria 'sequence' just for
the pixel data !
> Four bytes/byte... with a *lot* of disk swapping, no doubt.
> The "Remove Colors" option is, in any case, the slowest part of the
program, and almost useless for bitmaps of more
> than about 32 KB, since a 256 color palette is only 1 KB to start with.
>
> Wolf
>
>
>
>
7. Re: compression beta, and BIG bitmaps
On Sat, 23 Feb 2002 16:19:34 -0600, Kat <gertie at PELL.NET> wrote:
>Sounds like we need more and more an option to eliminate that 4byte
>package for special defines, Rob. Even if it's 2bytes, that saves some of us
>100's of megs of memory. How about a way to "include" the included file that
>loads these big files? If the "include as" syntax knows more about the
>contents of the vars and procedures in that file,, can the var tags be reduced
>to 2 bytes?
You can always squeeze 3 bytes into each entry with ((a*256)+b)*256+c,
though obviously that means you have to unpack them before use.
If you download Mike's editor from the archives that contains
analyse.e which manages to pack four "eu-chars" into a single integer.
If there were any bugs in that code the editor would crash and burn
all the time, and it don't. Performance hit is < 5 seconds to load a
673K file, not bad - and presumably saves about 2MB of memory.
Pete
PS This is an "eu-char":
global function TextToAnalysedLine(sequence line) -- analyse text line
to an intermediate state
-- suitable for storing (compressing). Newline chars not allowed
-- result is a 1-d eu_char SEQUENCE with indici for keywords &
builtins & comments
-- plus tab is remapped
-- 1-24 index for keywords
-- 25-29 [unused]
-- 30 comment indicator
-- 31 re-mapped TAB
-- 32-127 ascii chars
-- 128-214 index for builtin routines - some excess space is here to
absorb future additions
To get 4 bytes into an integer, they must be 0..214 not 0..255.
