Szukam jakiejsc szybkiej i zapewniejacej dobry wspolczynnik kompresji
bezstratnej(w ostatecznosci stratnej) metody kompresji obrazow. Jak do
tej pory skorzystalem z run-length encoding ale ta metoda daje nie
zadowalajace rezultaty. Dekompresja nie musi byc bardzo wydajna,
wystarczy ze zwykly blaszak poradzi sobie ze zdekompresowaniem
kilkanstu do dwudziestu kilku obrazow na sekunde o wymiarach 800x600.
Przydatna tez by byla metoda kompresji kolejnych klatek ale to wszystko
musi byc szybkie bo ma smigac na systemi wbudowanym.

--

do góry

On Thu, 23 Apr 2009 21:18:25 +0200 Sulsa <s...@d...me> wrote:

> Szukam jakiejsc szybkiej i zapewniejacej dobry wspolczynnik kompresji
> bezstratnej(w ostatecznosci stratnej) metody kompresji obrazow. Jak do
> tej pory skorzystalem z run-length encoding ale ta metoda daje nie
> zadowalajace rezultaty. Dekompresja nie musi byc bardzo wydajna,
> wystarczy ze zwykly blaszak poradzi sobie ze zdekompresowaniem
> kilkanstu do dwudziestu kilku obrazow na sekunde o wymiarach 800x600.
> Przydatna tez by byla metoda kompresji kolejnych klatek ale to
> wszystko musi byc szybkie bo ma smigac na systemi wbudowanym.

LZW lub LZSS + jakaś predykcja

do góry

Sulsa pisze:
> Szukam jakiejsc szybkiej i zapewniejacej dobry wspolczynnik kompresji
> bezstratnej(w ostatecznosci stratnej) metody kompresji obrazow. Jak do
> tej pory skorzystalem z run-length encoding ale ta metoda daje nie
> zadowalajace rezultaty. Dekompresja nie musi byc bardzo wydajna,
> wystarczy ze zwykly blaszak poradzi sobie ze zdekompresowaniem
> kilkanstu do dwudziestu kilku obrazow na sekunde o wymiarach 800x600.
> Przydatna tez by byla metoda kompresji kolejnych klatek ale to wszystko
> musi byc szybkie bo ma smigac na systemi wbudowanym.
>

Kompresuj i przesyłaj tylko różnice w kolejnych obrazach.
Jeśli są części wspólne w kolejnych klatkach (a zazwyczaj są) to można
sporo zaoszczędzić.
No chyba że masz deficyt pamięci w tym systemie wbudowanym.

A sama kompresja to jak Wojciech Mula napisał: LZW i pochodne.


--
Pozdrowienia,
Jaytee
* It's 5:50am. do you know where your stack pointer is?

do góry

Sulsa pisze:
> Szukam jakiejsc szybkiej i zapewniejacej dobry wspolczynnik kompresji
> bezstratnej(w ostatecznosci stratnej) metody kompresji obrazow. Jak do
> tej pory skorzystalem z run-length encoding ale ta metoda daje nie
> zadowalajace rezultaty. Dekompresja nie musi byc bardzo wydajna,
> wystarczy ze zwykly blaszak poradzi sobie ze zdekompresowaniem
> kilkanstu do dwudziestu kilku obrazow na sekunde o wymiarach 800x600.
> Przydatna tez by byla metoda kompresji kolejnych klatek ale to wszystko
> musi byc szybkie bo ma smigac na systemi wbudowanym.
>

Kompresuj i przesyłaj tylko różnice w kolejnych obrazach.
Jeśli są części wspólne w kolejnych klatkach (a zazwyczaj są) to można
sporo zaoszczędzić.
No chyba że masz deficyt pamięci w tym systemie wbudowanym.

A sama kompresja to jak Wojciech Muła napisał: LZW i pochodne.

--
Pozdrowienia,
Jaytee
* It's 5:50am. do you know where your stack pointer is?

do góry

Jaytee wrote:
> Sulsa pisze:
>> Szukam jakiejsc szybkiej i zapewniejacej dobry wspolczynnik kompresji
>> bezstratnej(w ostatecznosci stratnej) metody kompresji obrazow. Jak do
>> tej pory skorzystalem z run-length encoding ale ta metoda daje nie
>> zadowalajace rezultaty. Dekompresja nie musi byc bardzo wydajna,
>> wystarczy ze zwykly blaszak poradzi sobie ze zdekompresowaniem
>> kilkanstu do dwudziestu kilku obrazow na sekunde o wymiarach 800x600.
>> Przydatna tez by byla metoda kompresji kolejnych klatek ale to
>> wszystko musi byc szybkie bo ma smigac na systemi wbudowanym.
>>
>
> Kompresuj i przesyłaj tylko różnice w kolejnych obrazach.
> Jeśli są części wspólne w kolejnych klatkach (a zazwyczaj są) to można
> sporo zaoszczędzić.

Warto też poeksperymentować z różnicowym kodowaniem kolejnych pikseli
w linii. Różnice potem z regóły lepiej poddają się LZW i Huffmanem.

--
Paweł Kierski
n...@p...net

do góry

On Thu, 23 Apr 2009 22:25:54 +0200
Wojciech Muła <w...@p...null.onet.pl.invalid> wrote:

>
> LZW lub LZSS + jakaś predykcja
>

Z tego co czytalem to lzw nadaje sie tylko do bitmap z paleta kolorow,
kiedy jest wiecej kolorow to moze dodatkowo rodmuchac plik. Co masz na
mysli przez predykcje?


--

do góry

On Fri, 24 Apr 2009 20:51:12 +0200 Sulsa <s...@d...me> wrote:

> > LZW lub LZSS + jakaś predykcja
> >
>
> Z tego co czytalem to lzw nadaje sie tylko do bitmap z paleta kolorow,
> kiedy jest wiecej kolorow to moze dodatkowo rodmuchac plik.

Nie wiem, to trzeba sprawdzić. Z resztą można kompresować osobno
składowe R, G, B; Można kompresować nie na poziomie bajtów, ale
pikseli. Wszystko zależy od tego jakie masz te dane.

> Co masz na mysli przez predykcje?

Kompresja różnic między obliczoną wartością a rzeczywistą:
obliczenia (predykcję) dokonuje się na podstawie wartości
już zapisanych pikseli. Najlepiej pogooglaj za PNG filters;
w JPEG-LS też mają jakieś swoje metody predykcji.

w.

--
Kupię: http://wm.ite.pl/kupie.html

do góry

Paweł Kierski <n...@p...net> napisał(a):

> Jaytee wrote:
> > Sulsa pisze:
> >> Szukam jakiejsc szybkiej i zapewniejacej dobry wspolczynnik kompresji
> >> bezstratnej(w ostatecznosci stratnej) metody kompresji obrazow. Jak do
> >> tej pory skorzystalem z run-length encoding ale ta metoda daje nie
> >> zadowalajace rezultaty. Dekompresja nie musi byc bardzo wydajna,
> >> wystarczy ze zwykly blaszak poradzi sobie ze zdekompresowaniem
> >> kilkanstu do dwudziestu kilku obrazow na sekunde o wymiarach 800x600.
> >> Przydatna tez by byla metoda kompresji kolejnych klatek ale to
> >> wszystko musi byc szybkie bo ma smigac na systemi wbudowanym.
> >>
> >
> > Kompresuj i przesyĹ&#65533;aj tylko róşnice w kolejnych obrazach.
> > JeĹ&#65533;li sÄ&#65533; czÄ&#65533;Ĺ&#65533;ci wspĂłlne w kolejnych klatkach (a
zazwyczaj sÄ&#65533;) to moĹźna
> > sporo zaoszczÄ&#65533;dziÄ&#65533;.
>
> Warto teĹź poeksperymentowaÄ&#65533; z róşnicowym kodowaniem kolejnych pikseli
> w linii. Róşnice potem z regĂłĹ&#65533;y lepiej poddajÄ&#65533; siÄ&#65533; LZW i
Huffmanem.
>

Polecam przeczytać źródło bzipa. Skomplikowany program, ale mały.
Polecam również książkę Adama Drozdka.

Przed jakąś z metod kompresji dane trzeba przygotować. Są do tego celu
dwa algorytmy. Jeden z nich jest prosty, zwiększa on ilość zer w danych
po czym dane świetnie nadają się do kompresji kodami huffamna.
Drugi algorytm jest bardziej skomplikowany, sortuje boki danych
i powoduje że bloki podobne są blisko siebie, co szczególnie poprawia
kompresje metodami słownikowymi (LZW i pochodne).

Oba algorytmy są zaimplementowane w bzipie, zaimplementowana jest tam też
kompresja słownikowa, kody huffmana i o ile się nie mylę kompresja numeryczna.

Niestety z reguły dekompresja jest bardzo wydajna, a kompresja jest wydajna
tylko do pewnego momentu - im kompresor jest bliższy optymalnemu tym dłużej
działa, dlatego w praktyce stosuje się metody zachłanne, heurystyki,
ewentualnie optymalne dla małych wycinków danych.

Pozdrawiam


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

W dniu 2009.04.23 21:18, Sulsa pisze:
> Jak do
> tej pory skorzystalem z run-length encoding ale ta metoda daje nie
> zadowalajace rezultaty.

Metoda z PCXa, faktycznie szybka :)

>Dekompresja nie musi byc bardzo wydajna,
> wystarczy ze zwykly blaszak poradzi sobie ze zdekompresowaniem
> kilkanstu do dwudziestu kilku obrazow na sekunde o wymiarach 800x600.

A zwykły zip ? Tam się reguluje stopień kompresji 0-9, przy niższych
jest faktycznie szybki.

Poza tym można spróbować GIFa (czyli LZW).


--
Mar

do góry

On Wed, 29 Apr 2009 15:47:41 +0200
Mariusz <m...@s...org> wrote:

> Poza tym można spróbować GIFa (czyli LZW).

LZW przetestowalem i jest co najmniej o rzad wielkosci za wolny, a nie
mam juz pomyslu jak przyspieszyc implementacje. Jednak mysle, ze duzo
juz sie nie da wyciagnac bo lzw wyszlo mi jakies 30 razy wolniejsze od
run-length encoding, a to ostatnie to bardzo prosty algorytm. Mam
jeszcze zamiar sprobowac lz77, niby to prawie to samo co lzw ale moze
bedzie szybciej(brak slownika, ktory wydaje mi sie wszystko zpowalnia).




--

do góry