'PHRLE' or 'Another Useless Library By Eric Cowles'

[1000101]

Well, I finished debugging and fixing up my PHRLE (Progressive Heuristic Run-Length Encoding) algorithm and it's totally sweet.

It gets better compression then standard 8-bit RLE without the fuss and complexity of LZW or huffman encoding.

Super-simple to use:

lRet = compRLE (Source, Dest, srcLen, dstLen)
lRet = decompRLE (Source, Dest, serLen, dstLen)

Worst case scenario it gets the same compression as RLE, best case is many times more.

100% assembly library can be used with any 16-bit compiler. Uses *no* memory when in the functions (everything is handled in registers except when reading/writing from/to the buffers). Only 870 bytes of code (assembled).

So, start adding PHRLE to your program today...or I'll kill you! ;P

http://uregina.ca/~cowles1e/RLEn.rar
http://uregina.ca/~cowles1e/RLEn.zip

Other junk:

http://uregina.ca/~cowles1e/

[Agamemnus]

Nice..

Ok I'm starting..

EDIT:

Ok, I tried it out.

Two things:
1) The image isn't 64K.
2) It would be nice if there was a way to uh... use it! How do I specify input and output file names?

[1000101]

1) When you load a bitmap, no matter the size, it still uses the video segment A000h, 64000 bytes as the image source (even if it's a 32x32 image), so it is 64K (or damned close).

2) rlentest filename.bmp, if it can't find it, it uses the default image.

Also, rlentest is just that, a test. Look at the source to see how to use it, etc. Use the library in your own project. It's pretty simple stuff, nothing complex about it.

[Agamemnus]

Ok, I don't want to try to figure out how to use it for hours. I did look at the source and I have no idea how to make it work.

*Does it only work for 64000 byte bitmaps??

[1000101]

You're not too bright, are you?

The TEST program which TESTs it and is not a real application because it is a TEST and thus only meant to TEST the library is assuming some things for it's TESTs.

The library will work with any block of data as you pass it a pointer to the source buffer and destination buffer as well as the length of the source buffer and length of the destination buffer.

It preforms compression of the source buffer with the compressed data being put in the destination buffer. It does this until it has gone through all the bytes specified by source length or the destination buffer is full as specified by destination length.

ie:

Code:

Dim myBuffer(0 To 255) As Long ' 1K buffer

lRet = compRLEA(&H00000000, myBuffer(0), 1024, 1024) ' Compress the system interrupt table

The TEST program happens to compress the video segment and decompress to the video segment so you can see the results of what happened. After all, what's the point of a TEST program if you don't know what's happening?

[Blitz]

So how does it work chocolate-bear?

[1000101]

heh, it's comletely explained in the include file. The source is also got enough comments to help you figure it out. But, I'm willing to cut'n'paste.

Code:

'' PROGRESSIVE HEURISTIC RLE COMPRESSION
''
''    What is 'Progressive Heuristic RLE Compression' you ask?
''
''       Well, standard  RLE  compression  uses  a  fixed data size for the
''       counter.  Either 8 or 16  bits.   This is fine for some cases, but
''       not all.  Further, RLE compression will compress data even if it's
''       more economical to store a section of the data uncompressed.  This
''       can quickly lead  to  bloat.   Also,  for  long data runs, you can
''       quickly end up with several dozen byte pairs of the same data in a
''       row (FFh 41h FFh 41h FFh 41h etc)  when  a  smarter  algorythm can
''       reduce that more intelligently.
''
''    How does RLE work?
''
''       The algoryth of RLE is quite  simple,  even those using techniques
''       to store  byte-runs  for  poorly  compressable  data.   The method
''       counts the  number  of  bytes  in  a  row  that  are  the same (or
''       different for byte-runs) and then stores a counter number followed
''       by the byte or bytes (again, for uncompressed byte runs).  So, 200
''       'A's could be reduced to C8h 41h.   Two  bytes.   This works great
''       for runs where most of  the  data  will be less then 8 bits (256).
''       For runs that are longer then 8 bits, it may be more affordable to
''       use a 16-bit counter, so  10,000  'A's would be reduced to 27h 10h
''       41h.  Three bytes.   The  problem  with  both of these methods, is
''       that you rarely have  exclusively  one or the other.  And when you
''       use a fixed-counter size, you  would end up with that messed shown
''       above (FFh 41h FFh 41h FFh 41h etc).
''
''    How does Heuristic RLE work?
''
''       Heuristic RLE works by looking  at the data and making a decission
''       as to compress it or store it as a byte run.  Once it's done this,
''       it then saves the counter and  either  stores a single byte to use
''       for replecation, or a byte-run as straight data.
''
''    Ok, what is Progressive RLE?
''
''       Progressive RLE is where the counter size is not fixed.  Like LZW,
''       it grows as needed.  This allows  the counter itself to take up as
''       little space as  possable,  allowing  for  the maximum compression
''       available through RLE.    This particular library happens to use a
''       6->13->20->28 bit growth  scheme.    The  counter starts at 6 bits
''       (64) then grows to 13 bits (8K),  20 bits (1M) and finally 28 bits
''       (256M) before starting over  again.    As you can see, this allows
''       for a much larger amount of compression over startard RLE.  Tested
''       on a small simple image  (320x200  8-bpp),  the standard 8-bit RLE
''       compression  was  able  to  compress  it  to  52,324  bytes.   The
''       Progressive Heuristic RLE Compression was able to reduce the image
''       to 37,406 bytes.  That is  18.2%  and  41.6% compression for 8-bit
''       RLE and Progressive Heuristic RLE respecively.
''

[Blitz]

So it recognizes patterns?

[1000101]

Nope, it just looks ahead to see if it should use RLE or BRUN. If there is a length of bytes which *can* be compressed but is less the 4 bytes, then it stores it uncompressed.