Cześć.

Takie zagadnienie:

Mam pliki o wielkości dziesiątek kB. Chcę je skompresować (najlepiej
narzedziem działajacym w unixie). Pliki składają się dość często z
identycznych bajtów jeden po drugim. Plik wynikowy ma być strumieniem
bez nagłówków.

Plik wynikowy będzie wciskany do pamięci Flash mikrokontrolera. Podczas
pracy uC muszę go rozpakować do strumienia bajtów. Istotne jest że
algorytm dekodowania musi mieć jak najmniejszą sygnaturę pamięciową.

Oczywiście mogę użyć napisanego na kolanie RLE. Ale zapytam, bo może
istnieje coś lepszego.

Podsumowując:
1) najlepiej kompresor w postaci lini poleceń unixa
2) dekompresor zużywający jak najmniej zasobów (każdy bajt kosztuje)

Czy znajdę coś lepszego niż RLE? Wydajnośc trzeciorzędna. Nie mogę / nie
chcę robić malloc, więc algorytmy dynamicznie manipulujące pamięcią
odpadają.

do góry

On 2016-01-26 21:11, Sebastian Biały wrote:
> Cześć.
>
> Takie zagadnienie:
Nie używałem, ale może to się nada: http://liblzg.bitsnbites.eu/

> Podsumowując:
> 1) najlepiej kompresor w postaci lini poleceń unixa
Sam sobie napiszesz.

> 2) dekompresor zużywający jak najmniej zasobów (każdy bajt kosztuje)
Podobno dekompresor ze wspomnianej biblioteki nie zużywa (istotnej
ilości) pamięci.


BTW.
http://stackoverflow.com/questions/3767640/compact-d
ecompression-library-for-embedded-use

do góry

I jeszcze jeden:
http://spin.atomicobject.com/2013/03/14/heatshrink-e
mbedded-data-compression/

do góry

On Tuesday, January 26, 2016 at 9:12:55 PM UTC+1, Sebastian Biały wrote:
> Cześć.
>
> Takie zagadnienie:
>
> Mam pliki o wielkości dziesiątek kB. Chcę je skompresować (najlepiej
> narzedziem działajacym w unixie). Pliki składają się dość często z
> identycznych bajtów jeden po drugim. Plik wynikowy ma być strumieniem
> bez nagłówków.
>
> Plik wynikowy będzie wciskany do pamięci Flash mikrokontrolera. Podczas
> pracy uC muszę go rozpakować do strumienia bajtów. Istotne jest że
> algorytm dekodowania musi mieć jak najmniejszą sygnaturę pamięciową.
>
> Oczywiście mogę użyć napisanego na kolanie RLE. Ale zapytam, bo może
> istnieje coś lepszego.
>
> Podsumowując:
> 1) najlepiej kompresor w postaci lini poleceń unixa
> 2) dekompresor zużywający jak najmniej zasobów (każdy bajt kosztuje)
>
> Czy znajdę coś lepszego niż RLE? Wydajnośc trzeciorzędna. Nie mogę / nie
> chcę robić malloc, więc algorytmy dynamicznie manipulujące pamięcią
> odpadają.

Jakbym musiał samemu robić, to bym kombinował z:
1) RLE
2) Sortowanie bloków
3) LZW i rodzina
4) Huffman

Pozdrawiam

do góry