Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #28283 > unrolled thread
| Started by | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| First post | 2016-01-26 21:11 +0100 |
| Last post | 2016-01-27 06:23 -0800 |
| Articles | 4 — 3 participants |
Back to article view | Back to pl.comp.programming
Algorytm kompresji do embedded Sebastian Biały <heby@poczta.onet.pl> - 2016-01-26 21:11 +0100
Re: Algorytm kompresji do embedded JDX <jdx@onet.pl> - 2016-01-26 21:54 +0100
Re: Algorytm kompresji do embedded JDX <jdx@onet.pl> - 2016-01-26 22:05 +0100
Re: Algorytm kompresji do embedded "M.M." <mmarszik@gmail.com> - 2016-01-27 06:23 -0800
| From | Sebastian Biały <heby@poczta.onet.pl> |
|---|---|
| Date | 2016-01-26 21:11 +0100 |
| Subject | Algorytm kompresji do embedded |
| Message-ID | <n88k05$u8t$1@node1.news.atman.pl> |
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ą.
[toc] | [next] | [standalone]
| From | JDX <jdx@onet.pl> |
|---|---|
| Date | 2016-01-26 21:54 +0100 |
| Message-ID | <56a7dd20$0$22844$65785112@news.neostrada.pl> |
| In reply to | #28283 |
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-decompression-library-for-embedded-use
[toc] | [prev] | [next] | [standalone]
| From | JDX <jdx@onet.pl> |
|---|---|
| Date | 2016-01-26 22:05 +0100 |
| Message-ID | <56a7df8b$0$661$65785112@news.neostrada.pl> |
| In reply to | #28283 |
I jeszcze jeden: http://spin.atomicobject.com/2013/03/14/heatshrink-embedded-data-compression/
[toc] | [prev] | [next] | [standalone]
| From | "M.M." <mmarszik@gmail.com> |
|---|---|
| Date | 2016-01-27 06:23 -0800 |
| Message-ID | <fd28f63c-1cbe-4e2b-b5e4-c475f18f73c1@googlegroups.com> |
| In reply to | #28283 |
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
[toc] | [prev] | [standalone]
Back to top | Article view | pl.comp.programming
csiph-web