• simple compression mathod to code itself?

    From fir@21:1/5 to All on Fri Apr 5 20:24:51 2024
    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half
    but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David LaRue@21:1/5 to fir on Fri Apr 5 23:28:12 2024
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half
    but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all bytes
    as you scan them from the input. The compressed output is a reference to
    the table you just built (wnhem repeated byte strings are found, otherwise
    feed the input to the compressed image so that the expansion method can
    build the sme dynamic table the encoder built. The table generally has a
    limit on the number of entries (usually a good size) and allows the table
    of bytes to dynamically change as new patterns are read from the input.

    This is a well known and documented compression/expansion algorithm. PKZIP
    and other engines use this as one of their compression methodz. Look for
    the description of that if you need more details to figure out what you
    need to write.

    Expansion is the reverse. Read the source (now the compressed image) and
    build the compression table from the bytes. As encoded references to the compression table are read from the compressed image output the source byte sequences. The output should be the same as what your encoder originally
    read.

    A good check on the final code is to compare the original input with the eventual output and make sure they agree exactly.

    Have fun,

    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to David LaRue on Fri Apr 5 21:18:01 2024
    On 4/5/2024 7:28 PM, David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half
    but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all bytes
    as you scan them from the input. The compressed output is a reference to
    the table you just built (wnhem repeated byte strings are found, otherwise feed the input to the compressed image so that the expansion method can
    build the sme dynamic table the encoder built. The table generally has a limit on the number of entries (usually a good size) and allows the table
    of bytes to dynamically change as new patterns are read from the input.

    This is a well known and documented compression/expansion algorithm. PKZIP and other engines use this as one of their compression methodz. Look for
    the description of that if you need more details to figure out what you
    need to write.

    Expansion is the reverse. Read the source (now the compressed image) and build the compression table from the bytes. As encoded references to the compression table are read from the compressed image output the source byte sequences. The output should be the same as what your encoder originally read.

    A good check on the final code is to compare the original input with the eventual output and make sure they agree exactly.

    Have fun,

    David


    Some people have written compression codes, purely for educational purposes. That's why I got a copy of this, some years ago. For fun.

    https://github.com/grtamayo/RLE

    gtrle35.c # Run Length Encoding, one of the simpler compressors

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From fir@21:1/5 to Paul on Sat Apr 6 13:48:38 2024
    Paul wrote:
    On 4/5/2024 7:28 PM, David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half
    but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all bytes >> as you scan them from the input. The compressed output is a reference to
    the table you just built (wnhem repeated byte strings are found, otherwise >> feed the input to the compressed image so that the expansion method can
    build the sme dynamic table the encoder built. The table generally has a
    limit on the number of entries (usually a good size) and allows the table
    of bytes to dynamically change as new patterns are read from the input.

    This is a well known and documented compression/expansion algorithm. PKZIP >> and other engines use this as one of their compression methodz. Look for
    the description of that if you need more details to figure out what you
    need to write.

    Expansion is the reverse. Read the source (now the compressed image) and
    build the compression table from the bytes. As encoded references to the
    compression table are read from the compressed image output the source byte >> sequences. The output should be the same as what your encoder originally
    read.

    A good check on the final code is to compare the original input with the
    eventual output and make sure they agree exactly.

    Have fun,

    David


    Some people have written compression codes, purely for educational purposes. That's why I got a copy of this, some years ago. For fun.

    https://github.com/grtamayo/RLE

    gtrle35.c # Run Length Encoding, one of the simpler compressors

    Paul

    rle i think i could write by hand but i would like something a bit more eleborate than this - not much but somewhat

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From fir@21:1/5 to David LaRue on Sat Apr 6 13:53:14 2024
    David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half
    but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all bytes
    as you scan them from the input. The compressed output is a reference to
    the table you just built (wnhem repeated byte strings are found, otherwise feed the input to the compressed image so that the expansion method can
    build the sme dynamic table the encoder built. The table generally has a limit on the number of entries (usually a good size) and allows the table
    of bytes to dynamically change as new patterns are read from the input.

    This is a well known and documented compression/expansion algorithm. PKZIP and other engines use this as one of their compression methodz. Look for
    the description of that if you need more details to figure out what you
    need to write.

    Expansion is the reverse. Read the source (now the compressed image) and build the compression table from the bytes. As encoded references to the compression table are read from the compressed image output the source byte sequences. The output should be the same as what your encoder originally read.

    A good check on the final code is to compare the original input with the eventual output and make sure they agree exactly.

    Have fun,

    David

    this could be good but i dont quite understood that .. but eventually
    could be good...

    i thinged something abut that if rle search for repetitions of 1
    byte then maybe after that search for repetitions of 2 bytes, then 3
    bytes, 4 bytes and so on.. then do some "report" how many found and then
    find a way to encode that

    need to think a bit becouse if rle only stores repetitions that are
    one after another then this method should store repetitions that have
    various distances among them


    i also do nto want to spend a much time on this 1-2 days eventually

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From fir@21:1/5 to fir on Sat Apr 6 14:16:51 2024
    fir wrote:
    David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half
    but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all
    bytes
    as you scan them from the input. The compressed output is a reference to
    the table you just built (wnhem repeated byte strings are found,
    otherwise
    feed the input to the compressed image so that the expansion method can
    build the sme dynamic table the encoder built. The table generally has a
    limit on the number of entries (usually a good size) and allows the table
    of bytes to dynamically change as new patterns are read from the input.

    This is a well known and documented compression/expansion algorithm.
    PKZIP
    and other engines use this as one of their compression methodz. Look for
    the description of that if you need more details to figure out what you
    need to write.

    Expansion is the reverse. Read the source (now the compressed image) and
    build the compression table from the bytes. As encoded references to the
    compression table are read from the compressed image output the source
    byte
    sequences. The output should be the same as what your encoder originally
    read.

    A good check on the final code is to compare the original input with the
    eventual output and make sure they agree exactly.

    Have fun,

    David

    this could be good but i dont quite understood that .. but eventually
    could be good...

    i thinged something abut that if rle search for repetitions of 1
    byte then maybe after that search for repetitions of 2 bytes, then 3
    bytes, 4 bytes and so on.. then do some "report" how many found and then
    find a way to encode that

    need to think a bit becouse if rle only stores repetitions that are
    one after another then this method should store repetitions that have various distances among them


    i also do nto want to spend a much time on this 1-2 days eventually


    though maybe i should start from RLE indeed..in fact ihis shouldnt be so
    bad as for some of my eventuall funny needs - also it maybe seem ok to
    be first step until something more elaborate

    if someone want to talk on compression adn how to code it i could like
    to read it (as reading net articles on this may be seem to hard for my
    old sick head and posts are much are easier to get into it)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bart@21:1/5 to fir on Sat Apr 6 14:28:01 2024
    On 06/04/2024 13:16, fir wrote:
    fir wrote:
    David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half >>>> but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all
    bytes
    as you scan them from the input.  The compressed output is a
    reference to
    the table you just built (wnhem repeated byte strings are found,
    otherwise
    feed the input to the compressed image so that the expansion method can
    build the sme dynamic table the encoder built.  The table generally
    has a
    limit on the number of entries (usually a good size) and allows the
    table
    of bytes to dynamically change as new patterns are read from the input.

    This is a well known and documented compression/expansion algorithm.
    PKZIP
    and other engines use this as one of their compression methodz.  Look
    for
    the description of that if you need more details to figure out what you
    need to write.

    Expansion is the reverse.  Read the source (now the compressed image)
    and
    build the compression table from the bytes.  As encoded references to
    the
    compression table are read from the compressed image output the source
    byte
    sequences.  The output should be the same as what your encoder
    originally
    read.

    A good check on the final code is to compare the original input with the >>> eventual output and make sure they agree exactly.

    Have fun,

    David

    this could be good but i dont quite understood that .. but eventually
    could be good...

    i thinged something abut that if rle search for repetitions of 1
    byte then maybe after that search for repetitions of 2 bytes, then 3
    bytes, 4 bytes and so on.. then do some "report" how many found and then
    find a way to encode that

      need to think a bit becouse if rle only stores repetitions that are
    one after another then this method should store  repetitions that have
    various distances among them


    i also do nto want to spend a much time on this 1-2 days eventually


    though maybe i should start from RLE indeed..in fact ihis shouldnt be so
    bad as for some of my eventuall funny needs - also it maybe seem ok to
    be first step until something more elaborate

    What sort of data are you compressing?

    If it is computer generated imagery with no noise or artefacts, then RLE
    will probably work well.

    If it is a noisy image captured from a camera then it'll be rubbish.

    Stuff like text files will likely be mildly compressed, but probably not
    enough to be worth the trouble.

    Decent compression is hard; you're not going to come up with anything in
    1-2 days that will give worthwhile results across a range of inputs.

    if someone want to talk on compression adn how to code it i could like
    to read it (as reading net articles on this may be seem to hard for my
    old sick head and posts are much are easier to get into it)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From fir@21:1/5 to bart on Sat Apr 6 16:02:12 2024
    bart wrote:
    On 06/04/2024 13:16, fir wrote:
    fir wrote:
    David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half >>>>> but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all
    bytes
    as you scan them from the input. The compressed output is a
    reference to
    the table you just built (wnhem repeated byte strings are found,
    otherwise
    feed the input to the compressed image so that the expansion method can >>>> build the sme dynamic table the encoder built. The table generally
    has a
    limit on the number of entries (usually a good size) and allows the
    table
    of bytes to dynamically change as new patterns are read from the input. >>>>
    This is a well known and documented compression/expansion algorithm.
    PKZIP
    and other engines use this as one of their compression methodz.
    Look for
    the description of that if you need more details to figure out what you >>>> need to write.

    Expansion is the reverse. Read the source (now the compressed
    image) and
    build the compression table from the bytes. As encoded references
    to the
    compression table are read from the compressed image output the source >>>> byte
    sequences. The output should be the same as what your encoder
    originally
    read.

    A good check on the final code is to compare the original input with
    the
    eventual output and make sure they agree exactly.

    Have fun,

    David

    this could be good but i dont quite understood that .. but eventually
    could be good...

    i thinged something abut that if rle search for repetitions of 1
    byte then maybe after that search for repetitions of 2 bytes, then 3
    bytes, 4 bytes and so on.. then do some "report" how many found and then >>> find a way to encode that

    need to think a bit becouse if rle only stores repetitions that are
    one after another then this method should store repetitions that have
    various distances among them


    i also do nto want to spend a much time on this 1-2 days eventually


    though maybe i should start from RLE indeed..in fact ihis shouldnt be
    so bad as for some of my eventuall funny needs - also it maybe seem ok
    to be first step until something more elaborate

    What sort of data are you compressing?

    If it is computer generated imagery with no noise or artefacts, then RLE
    will probably work well.

    If it is a noisy image captured from a camera then it'll be rubbish.

    Stuff like text files will likely be mildly compressed, but probably not enough to be worth the trouble.

    Decent compression is hard; you're not going to come up with anything in
    1-2 days that will give worthwhile results across a range of inputs.

    if someone want to talk on compression adn how to code it i could like
    to read it (as reading net articles on this may be seem to hard for my
    old sick head and posts are much are easier to get into it)

    at the initial idea i want to add this as a method to my "bytes"
    microcontainer (where you could put or load anything)

    i just tried to think what usebale metods i could add and some
    pack/unpack method caould be handy

    though even i dont know if to do it todaye/tomorrow or maybe more in future..discussing something abut it would be interesting imo

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David LaRue@21:1/5 to fir on Sat Apr 6 15:39:11 2024
    fir <fir@grunge.pl> wrote in news:uurd34$8ga0$1@i2pn2.org:

    David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half
    but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all
    bytes as you scan them from the input. The compressed output is a
    reference to the table you just built (wnhem repeated byte strings are
    found, otherwise feed the input to the compressed image so that the
    expansion method can build the sme dynamic table the encoder built.
    The table generally has a limit on the number of entries (usually a
    good size) and allows the table of bytes to dynamically change as new
    patterns are read from the input.

    This is a well known and documented compression/expansion algorithm.
    PKZIP and other engines use this as one of their compression methodz.
    Look for the description of that if you need more details to figure out
    what you need to write.

    Expansion is the reverse. Read the source (now the compressed image)
    and build the compression table from the bytes. As encoded references
    to the compression table are read from the compressed image output the
    source byte sequences. The output should be the same as what your
    encoder originally read.

    A good check on the final code is to compare the original input with
    the eventual output and make sure they agree exactly.

    Have fun,

    David

    this could be good but i dont quite understood that .. but eventually
    could be good...

    i thinged something abut that if rle search for repetitions of 1
    byte then maybe after that search for repetitions of 2 bytes, then 3
    bytes, 4 bytes and so on.. then do some "report" how many found and then
    find a way to encode that

    need to think a bit becouse if rle only stores repetitions that are
    one after another then this method should store repetitions that have various distances among them


    i also do nto want to spend a much time on this 1-2 days eventually


    Hello fir,

    The method above can do the same thing for each repetition of a single
    byte. Alone it has the advantage that compression and decompression are
    single pass operations. It is similar to RLE but allows for more
    variations to be used along the way. The encoder also needs some table searching to determine best matches, new byte sequences, and improved
    length sequences. An ordered table of byte strings is typically used.
    I've also seen more advanced search methods that use branch tables to
    represent the encoded sequences with the final entry being the value to put
    in the compressed output. Very easy to search and gives some improvements
    to the basic search design to make performance better. This can be done in
    a few days or less, depending on how much time you spend on deciding the
    table size and so on. I've also seen the search part as a coding
    requirement for a one hour test to see how the coder breaks the idea down.

    I like all the ideas you have.

    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David LaRue@21:1/5 to fir on Sat Apr 6 16:09:55 2024
    fir <fir@grunge.pl> wrote in news:uurefe$8i04$1@i2pn2.org:

    fir wrote:
    <snip>

    if someone want to talk on compression adn how to code it i could like
    to read it (as reading net articles on this may be seem to hard for my
    old sick head and posts are much are easier to get into it)

    There are several good books on search and compression methods that provide examples of complexity and discussions about the complexity and performance.
    I have book on just algorithms that I bought years ago. One of the first chapters discussed the absurdaty of an OS/App requiring seperate Account and Password entries when only one is needed. The result is the same and takes
    one less character to enter. I found that book in a Barnes and Noble years
    ago and loved reading and trying to understand the suggestions they made. A great place to look for such books is in a college book store; the one for books that are used for the second year or higher students. I've not found much online EXCEPT for the papers and examples published by Nicholas Wirth or by Knuth. Knuth's publications are best if you don't mind reading for a
    while and then deciding what is best to code/do. Wirth had books on
    algorithms and for specific languages. Much easier to read for a beginner.

    The Knuth discussions are well organized and usually available for free
    online. He covered an enormous variety on topics in his many books/papers. They have complete descriptions about why something was done and then
    discusses how to improve them. Again this is deep material but well worth
    the effort once you've mastered a language or two. C gives the ideas needed
    to read and und1erstand his comments about angorithms and language design.
    Very good stuff, IMHO.

    David

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to David LaRue on Sat Apr 6 16:41:54 2024
    David LaRue <huey.dll@tampabay.rr.com> writes:
    fir <fir@grunge.pl> wrote in news:uurefe$8i04$1@i2pn2.org:

    fir wrote:
    <snip>

    if someone want to talk on compression adn how to code it i could like
    to read it (as reading net articles on this may be seem to hard for my
    old sick head and posts are much are easier to get into it)

    There are several good books on search and compression methods that provide >examples of complexity and discussions about the complexity and performance.

    https://en.wikipedia.org/wiki/Lossless_compression

    One of the earliest:

    https://en.wikipedia.org/wiki/Huffman_coding

    Former colleague wrote this one:

    https://en.wikipedia.org/wiki/Gzip

    This was once under patent to a former employer:

    https://en.wikipedia.org/wiki/LZ77_and_LZ78

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From fir@21:1/5 to David LaRue on Sat Apr 6 21:57:13 2024
    David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uurd34$8ga0$1@i2pn2.org:

    David LaRue wrote:
    fir <fir@grunge.pl> wrote in news:uupflr$5t1n$1@i2pn2.org:

    i not code at all in recent years
    (recently i coded half of my compuler with a plan to write second half >>>> but its to ambitious to lazy coding mood i got recently)
    but recently i started this slamm coding modd and found
    ite pleasurable

    searching for lazy side things i could code in such mood
    i thought maybe i wopuld like to have compression routine
    but i would like to write it myself sortla like i use quicksort
    or so but i also want to write it myself

    so is there maybe some method i could use i mean some simple
    routine that compresses and uncompresses an array of bytes but
    maybe something a bit more complex than RLE (rune length encoding)
    - only thing i know from this domain


    Hello fir,

    A method a bit more complex that you might try builds a table of all
    bytes as you scan them from the input. The compressed output is a
    reference to the table you just built (wnhem repeated byte strings are
    found, otherwise feed the input to the compressed image so that the
    expansion method can build the sme dynamic table the encoder built.
    The table generally has a limit on the number of entries (usually a
    good size) and allows the table of bytes to dynamically change as new
    patterns are read from the input.

    This is a well known and documented compression/expansion algorithm.
    PKZIP and other engines use this as one of their compression methodz.
    Look for the description of that if you need more details to figure out
    what you need to write.

    Expansion is the reverse. Read the source (now the compressed image)
    and build the compression table from the bytes. As encoded references
    to the compression table are read from the compressed image output the
    source byte sequences. The output should be the same as what your
    encoder originally read.

    A good check on the final code is to compare the original input with
    the eventual output and make sure they agree exactly.

    Have fun,

    David

    this could be good but i dont quite understood that .. but eventually
    could be good...

    i thinged something abut that if rle search for repetitions of 1
    byte then maybe after that search for repetitions of 2 bytes, then 3
    bytes, 4 bytes and so on.. then do some "report" how many found and then
    find a way to encode that

    need to think a bit becouse if rle only stores repetitions that are
    one after another then this method should store repetitions that have
    various distances among them


    i also do nto want to spend a much time on this 1-2 days eventually


    Hello fir,

    The method above can do the same thing for each repetition of a single
    byte. Alone it has the advantage that compression and decompression are single pass operations. It is similar to RLE but allows for more
    variations to be used along the way. The encoder also needs some table searching to determine best matches, new byte sequences, and improved
    length sequences. An ordered table of byte strings is typically used.
    I've also seen more advanced search methods that use branch tables to represent the encoded sequences with the final entry being the value to put in the compressed output. Very easy to search and gives some improvements
    to the basic search design to make performance better. This can be done in
    a few days or less, depending on how much time you spend on deciding the table size and so on. I've also seen the search part as a coding
    requirement for a one hour test to see how the coder breaks the idea down.

    I like all the ideas you have.

    David

    okay though i will answer to it alter as i decided to do it but not
    today yet

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)