SEMINARSKI RAD IZ MULTIMEDIJE |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
KOMPRESIJA SLIKA BEZ GUBITKA INFORMACIJAKOMPRESIJA SLIKEU današnje vrijeme sve su veći zahtjevi za prenosom što veće količine podataka. To se pokušava realizovati hardware-skim rješenjima, koja ipak pomalo počinju dosezati svoje realne granice (ograničenja koja nameću same tehnološke mogućnosti), pa se pribjegava software-skim rješenjima, koja nastoje sliku sažeti na što manju veličinu, da bi se moglo prenijeti više slika u jedinici vremena, preko istog ograničenog prenosnog sistema. Kompresijom podataka (slika) mogu se postići izvrsni rezultati, npr. slika dimenzija 1024 pixela x 1024 pixela x 24 bita, bez kompresije zauzima oko 3 MB memorijskog prostora i potrebno je oko 7 minuta za njen prenos koristeći brzu 64 Kbit/s ISDN liniju, dok je za sliku kompresovanu u odnosu 10:1 potrebno 300 KB memorijskog prostora, a za njen prenos je potrebno oko 30 sekundi. Prenos velikih slikovnih fajlova predstavlja usko grlo distribuiranih sistema.Kod kompresije važni su prenosivost i performance. Današnja rješenja za kompresiju su relativno prenosiva (između različitih platformi) budući da uveliko zadovoljavaju međunarodne standarde. Metode kompresije slike (“intraframe compression”) mogu se generalno podijeliti u dvije grupe: Postoje dvije vrste algoritama za kompresiju slike : - kompresija bez gubitka podataka (“lossless”) - kompresija bez gubitka podataka (“lossless”) Metode sa gubicima zasnivaju se na modelima ljudske percepcije (više kompresuju one atribute slike koji manje doprinose ukupnom izgledu slike) , one uzrokuju degradaciju slike u svakom koraku (svakim slijedećim korakom kompresije/dekompresije slika se degradira) , ali najčešće omogućuju daleko veće omjere kompresije nego metode bez gubitaka. 2. Metode kompresije bez gubitaka :Ove metode osiguravaju identičnost dekompresovane i izvorne slike. Ovo je vrlo važno u nekim područjima, npr. u medicini gdje je osim visoke razlučljivosti potrebno i osigurati nepromjenjeno arhiviranje slika, što je i zakonski regulirano. 2.1. Run-length kodovanjeTo je vrlo jednostavna metoda koja koristi činjenicu da su u mnogim fajlovima
česti nizovi istih vrijednosti (npr. jako korelirane slike). Ovaj algoritam
provjerava fajl, te ubacuje specijalne znakove (engl. ‘token’)
svaki put kad naiđe na niz od dva ili više jednakih znakova. 2.2. Huffman kodovanjeOvaj algoritam je razvio D.A.Huffman i temelji se na činjenici da se
neki znakovi pojavljuju češće nego neki drugi. Na toj osnovi algoritam
izgrađuje težinsko binarno stablo (na osnovu frekvencije pojavljivanja
pojedinih znakova). Svakom elementu tog stabla pridružuje se nova kodna
riječ određena pozicijom znaka u stablu. Najčešće ponavljani znak postaje
korjen stabla i njemu se pridružuje najkraća kodna riječ, dok kodna riječ
najrjeđe ponavljanog znaka može biti i dvostruko duža od samog znaka. 2.3. Entropijsko kodovanjeNajčešće se koristi pristup J.Ziv/Lempel (tzv. Lempel/Ziv ili LZ) koji
se zasniva na tome da koder i dekoder sadrže jednak riječnik metasimbola
od kojih svaki predstavlja cijelu sekvenciju ulaznih znakova. Ako se sekvencija
ponovi nakon što je pronađen simbol za nju, onda se ona zamjenuje tim
simbolom. Kodovani podaci ne trebaju sadržavati riječnik (nizovi znakova
= simbol) budući da je riječnik sadržan u koderu i dekoderu. Slika 3. Kodovanje kodnom tablicom
|
Lossless algoritmi |
Primjena |
Huffman |
MNP5 |
LZW (1984) |
GIF |
LZ77 |
ZIP |
LZ77, LZ78 i LZW algoritmi su algoritmi za kompresiju podataka bez gubitka informacija. LZW algoritam se koristi kod GIF kompresije slika.
Tri verzije algoritma:
OSNOVNI PRINCIP: Dictionary based kompresija. To je kompresija koja koristi listu ili rječnik u kojem pamti sekvence nekompresovanog sadržaja. Tokom kompresije kada se sekvenca iz rječnika pojavi u nekompresovanom sadržaju ona se mijenja sa kodom iz rječnika koji referencira tu sekvencu. Sa povećanjem dužine sekvenci u rječniku i povećanjem frekvencije pojavljivanja istih u nekompresovanom sadržaju povećava se i kompresija.
Implementacija rječnika:
set w = NULL
loop
read a character k
if wk exists in the dictionary
w = wk
else
output the code for w
add wk to the dictionary
w = k
endloop
read a character k
output k
w = k
loop
read a character k
entry = dictionary entry for k
output entry
add w + first char of entry to the dictionary
w = entry
endloop
Postupak kompresije LZW algoritma:
PRIMJER
Input |
Output |
New Code |
A MAN A PLAN A CANAL PANAMA |
A |
|
MAN A PLAN A CANAL PANAMA |
<SPACE> |
256='A<SPACE>' |
MAN A PLAN A CANAL PANAMA |
M |
257='<SPACE>M' |
AN A PLAN A CANAL PANAMA |
A |
258='MA' |
N A PLAN A CANAL PANAMA |
N |
259='AN' |
A PLAN A CANAL PANAMA |
<SPACE> |
260='N<SPACE>' |
A PLAN A CANAL PANAMA |
256 |
261='A' |
PLAN A CANAL PANAMA |
P |
262='A<SPACE>P' |
LAN A CANAL PANAMA |
L |
263='PL' |
AN A CANAL PANAMA |
259 |
264='LA' |
A CANAL PANAMA |
261 |
265='AN<SPACE>' |
CANAL PANAMA |
<SPACE> |
266='<SPACE>A<SPACE>' |
CANAL PANAMA |
C |
267='<SPACE>C' |
ANAL PANAMA |
259 |
268='CA' |
AL PANAMA |
A |
269='ANA' |
L PANAMA |
L |
270='AL' |
PANAMA |
<SPACE> |
271='L<SPACE>' |
PANAMA |
P |
272='<SPACE>P' |
ANAMA |
269 |
273='PA' |
MA |
258 |
274='ANAM' |
String ”A MAN A PLAN A CANAL PANAMA” ima 27 karaktera, 8
bita po karakteru, što je ukupno 216 bita za predstavljanje stringa.
LZW proces koristi 20 znakova plus rječnik, što znači da je potrebno 9
bita za predstavljanje svake LZW vrijednosti.
Ukupno je potrebno 180 bita za prestavljanje stringa, što je ušteda od
17%.
Ako ponovimo isti string dva puta, ušteda je 33%, a ako ponovimo isti
string tri puta ušteda je 41%.
Dekompresija LZW algoritmom je jednostavna, svaku kompresovanu riječ treba jednostavno prevesti iz rječnika. Kodnu tabelu nije potrebno kodirati uz kompresovani sadržaj, jer se može odrediti dinamički, upravo na osnovu kodiranog sadržaja. Jedini problem koji se može javiti je da pokušamo dekompresovati riječ koja nije definisana u rječniku, kao u sledećem primjeru.
Input |
Output |
New Code |
ABYABABAX |
A |
256='AB' |
BYABABAX |
B |
257='BY' |
YABABAX |
Y |
258='YA' |
ABABAX |
256 |
259='ABA' |
ABAX |
259 |
260='ABAX' |
X |
X |
|
Primjetimo da je kod 259 definisan u isto vrijeme kada i izlaz. Dekoder koji procesira ovu sekvencu će pročitati 259 prije nego što je kod 259 definisan. Ova kolizija se rješava na sledeći način: Izlaz neposredno prije 259 je 259 i njegova vrijednost je “AB”. Zadnji karakter prethodnog kod (258) je “A”, pa je u rječniku za 259 string “AB”+”A”=“ABA“.
Ako imamo string do 256 bajtova dovoljno je 9 bita za predstavljanje
rječnika, za veće stringove moramo koristiti 10 bita, za još veće opet
moramo povećati broj bita u rječniku. Postavlja se pitanje kako odabrati
prikladnu veličinu bita u rječniku, očigledno ćemo imati lošu kompresiju
kod velikih input stream-ova. Rješenje je u tome da se veličina
rječnika određuje i povećava po potrebi dinamički.
Na početku kompresionog procesa svaka vrijednost se pamti koristeći najmanji
broj bita (skoro uvijek 9). Kada broj kodova postane preveliki da bi se
mogao predstaviti trenutnom kodnom veličinom, ona se inkrementira za 1.
Za 9 bita se povećava na 10 kada dostigne kodnu riječ broj 512, sa 10
na 11 bita kada dostigne kodnu riječ broj 1024. Maksimum veličine kodne
riječi kod GIF formata je 12 bita. Kada se dostigne riječ broj 212-1 prestaje
se sa dodavanjem kodnih riječi u rječnik. U tom slučaju GIF koder može
izdati clear code instrukciju, koja kaže dekoderu da resetuje
dekoder u inicijalno stanje. Vrijednost clear code ne mora biti
uvijek ista tj. instrukcija ne mora uvijek biti izdata kad se dostigne
broj 212-1.
Kada se završi kodovanje koder šalje instrukciju end code da
označi kraj kompresovanog stream-a.
Do sada smo prikazivali rječnik kao niz stringova, međutim u praksi nije tako. Rječnik je prestavljen u obliku stabla, kao na primjeru riječi ABABCABD.
256=AB |
Kod može biti preveden u string obilaskom stabla od lišća prema korijenu, što u svakom prolazu daje string u obrnutom redoslijedu. Dok obilazimo stablo svaki put kada naiđemo na list odgovarajući karakter se stavlja na stek. Kada dostignemo korijen stabla vadimo sve elemente sa steka i tako dobijamo korektan redoslijed karaktera u stringu. Maksimalna veličina steka je 212.
Kompresija: O(n) gdje je n dužina teksta koji se kompresuje
Dekompresija: O(n) gdje je n dužina dekompresovanog teksta
Windows bitmap format je razvio Microsoft kao "device-independent bitmap" (.dib) fajl format, što znači da bitmap određuje boju piksela nezavisno od načina na koji displej predstavlja tu boju. Na početku je bilo više nekompatibilnih verzija, ali kako je Microsoft imao potpunu kontrolu nad formatom te verzije nikada nisu zaživjele.
Format je utvrđen sa Windows 3.0 verzijom. Od tada su napravljene neka poboljšanja, ali su potpuno kompatibilna sa predhodnim verzijama formata. Podrazumijevana ekstenzija za Windows DIB je .bmp. Koriste ga Microsoft Windows i OS/2 grafički podsistemi, i uopšteno se koristi kao jednostavan grafički format na tim platformama.
Slike se memorišu sa 2 (1-bit), 16 (4-bita), 256 (8-bita), 65,536 (16-bita) ili 16,7 miliona (24-bita) boja. 8-bitna slika može da bude siva slika (greyscale), ili indeksirana slika u boji. Alfa se smješta u odvojen fajl, slično sivoj slici. 32-bitni format sa integrisanim alfa je predstavljen sa Windows XP verzijom.
BMP fajlovi su obično bez kompresije, tako da zauzimaju dosta memorijskog prostora. Zbog toga su ovi fajlovi nepodesni za prenos preko Internet-a, ili drugih sporih ili medija malog kapaciteta. Prednost ovog formata je sama jednostavnost, kao i to što je visoko standardizovan i jako proširen.
Tipičan bit-mapirani fajl se sastoji iz 4 dijela:
To je blok bajtova koji se koristi za identifikaciju. Aplikacije ga koriste da bi utvrdile da li se radi o .bmp fajlu i da li je oštećen. Veličina ovog zaglavlja je obično 14B, a podijeljeni na sledeći način:
Sadrži informacije koje se koriste prilikom prikazivanja slike na ekranu. Postoje dva formata ovog zaglavlja, jedan je razvijen za OS/2 (veličina zaglavlja je tačno 12B), a drugi je razvijen za Windows (veličina zaglavlja je najmanje 40B). Prva 4B u oba slučaja definišu veličinu zaglavlja, tako da je lako utvrditi o kojem formatu se radi. Tipično zaglavlje za Windows je podijeljeno na sledeći način:
Paleta boja ne mora uvijek da postoji. Koriste je BMP slike koje piksel predstavljaju sa najviše 8 bita. Slike sa više od 1B/pixel su intenzitetske slike.
Tipičan BMP fajl koristi RGB model. Kada paleta boja postoji sadrži više ulaza (broj ulaza zavisi od broja boja koje se koriste), gdje svaki ulaz ima 4B. Prva tri bajta predstavljaju plavu, zelenu i crvenu boju respektivno, dok se četvrti bajt ne koristi (mor biti 0).
Ovaj blok sadrži podatke koji zapravo predstavljaju sliku. Ako broj
B kojima je predstavljena horizontalna linija slike nije djeljiv sa 4,
na kraj se dodaju nule. Recimo da imamo sliku 1071x363, koja za svaki
piksel koristi 24 bita. Znači imamo 1089B po redu. Kako 1089 nije djeljivo
sa 4 na kraj svakog reda se dodaju 3B, čija je vrijednost 0 tako da dobijamo
1092B po redu.
GIF (Graphics Intechange Format) je uveo CampuServe 1987. godine. Definiše protokol za prenos "raster" slike na način koji je nezavisan od platforme na kojoj je slika kreirana i na kojoj će se prikazivati. Koristi kompresiju sa gubitkom, i kompresiju bez gubitka (LZW algoritam). LZW algoritmom veličina fajla može znatnao da se smanji, bez gubitka u kvalitetu slike.
Postoje dvije verzije ovog formata:
- 87a verzije koja je uvedena 1987. godine i koja definiše osnovnu strukturu formata,
- 89a verzija proširuje format, omogućava komentare i smjernice.
Prilikom pisanja GIF fajla koji ne zahtijeva 89a verziju preporučuje se navođenje 87a verzije (sama verzija definiše minimalne mogućnosti koje aplikacija mora imati da bi otvorila fajl).
Pikseli su organizovani kao sekvenca blokova i podblokova u kojima su smješteni određeni podaci koji se koriste pri reprodukciji slike. GIF format podržava i animacije gdje se za svaki frejm koristi odvojena paleta.
Kako fajl može da sadrži bilo koji broj slika, i bilo koji broj proširenja, struktura samog fajla je jako kompleksna. Osnovna kompozicija fajla bi se mogla opisati na sledeći način:
Veličina ovog bloka je 7B. Sadrži sledeće parametre:
Ovaj dio može da sadrži neograničen broj slika i 89a proširenja u bilo kojem rasporedu.
Blokovi se mogu podijeliti u tri osnovne grupe: kontrolni blokovi, blokovi za tumačenje slike, i blokovi za specijalne namjene. Tip bloka se može odrediti na osnovu prvog bajta u bloku: 0x00-0x7F (0-127) kontrolni blokovi, 0x80-0xF9 (128-249) blokovi za tumačenje slike, 0xFA-0xFF (250 - 255 ) blokovi za specijalne namjene.
Blokovi slike sadrže sledeće informacije:
Minimalna veličina LZW koda zapravo odredjuje broj ulaza u inicijalnoj tabeli koje se koristi pri kompresiji i dekompresiji. GIF podržava kodove dužine do 12 bita. Podaci o pikselima su podijeljeni u podblokove, svaki podblok počinje bajtom koji određuje njegovu veličinu (tako da jedan podblok može da sadrži najviše 255B).
Deskriptor slike sadrži:
Svaka slika u GIF fajlu se sastoji iz deskriptora slike, lokalne palete (opcionalno) i podataka o pikselima. Isto tako, svaka slika mora da odgovara granicama koje određuje deskriptor logičkog ekrana.
LZW algoritam koji koristi GIF odgovara standardnom LZW algoritmu sa sledećim razlikama:
preuzmi seminarski rad u wordu » » »