Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: simple compression mathod to code itself?
Date: Sat, 6 Apr 2024 14:28:01 +0100
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <uuril0$23mkc$1@dont-email.me>
References: <uupflr$5t1n$1@i2pn2.org>
 <XnsB14BC6028E8BAhueydlltampabayrrcom@135.181.20.170>
 <uurd34$8ga0$1@i2pn2.org> <uurefe$8i04$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 06 Apr 2024 13:28:00 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="720c88f66c1ad2d04dad0254b37d503e";
	logging-data="2218636"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/A6zrvwdE6XIA815bIyYR6"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:AVLf5e7HAAxyYB39qBlDf4gtLcE=
Content-Language: en-GB
In-Reply-To: <uurefe$8i04$1@i2pn2.org>
Bytes: 4918

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)