IN høsten : Oppgavesett Kompresjon og koding (løsningsforslag) (kapittel ) Tenk selv -oppgaver. Heksadesimal Sudoku Vi har en kvadratisk matrise med * elementer som igjen er delt opp i * blokker på * elementer. I hvert element står et heksadesimalt siffer som for eksempel kan være en koding for en gråtone, en farge i en fargetabell, eller rett og slett et heltall. I alle linjer, kolonner og blokker skal alle de heksadesimale sifrene være forskjellige fra hverandre, slik som i eksemplet i figuren. a) Hvor mange biter trenger vi for å løpelengdetransformere det unormaliserte histogrammet for hele matrisen? lle de heksadesimale sifrene forekommer ganger, så det unormaliserte histogrammet består av kolonner som alle har verdien. Løpelengderepresentasjonen av dette er (,), som trenger += biter. b) Hvordan ser det normaliserte histogrammet for hele matrisen ut? et normaliserte histogrammet består også av kolonner, hver med verdien fra det unormaliserte histogrammet (som var ) dividert med summen av alle kolonnene i det unormaliserte histogrammet (som er *), altså /. c) Hva er forskjellen i første ordens entropi H mellom en linje i matrisen og hele matrisen? N: Vi angir ikke her formelen for H.
Her trenger man faktisk ikke å huske hvordan første ordens entropi regnes ut, bare at den kun er basert på det normaliserte histogrammet. Og det normaliserte histogrammet for en linje er det samme som for hele matrisen. ølgelig er forskjellen i første ordens entropi lik null. d) Hvor stor er kodingsredundansen hvis vi representerer alle sifrene i matrisen med bits kodeord? egrunn svaret kort! Vi har forskjellige siffer, altså trenger vi biter per siffer hvis kodeordene er like lange. et normaliserte histogrammet består av kolonner med verdien /. et gir en første ordens entropi H=*(/)log ()=. Så kodingsredundansen ved å bruke biter per symbol er lik null. et holder også å vise til at alle symbolene er like sannsynlige, for da er kodingsredundansen ved like lange koder generelt lik.. Huffmankoding av en spesiell tekst Hvorfor kan vi si at den gjennomsnittlige lengden på kodeordene vil bli lik entropien når vi Huffman-koder utsagnet digital overalt!? Vi har i alt, men bare forskjellige, og hyppighetene er enten (i,t,a,l) eller (d,g,,o,v,e,r,!). Så alle de N= sannsynlighetene kan skrives som brøker der telleren er og nevneren er en toerpotens ( eller ). ltså kan sannsynlighetene for hvert symbol uttrykkes som for heltalls verdier av k. ntropien til hvert symbol uttrykt i biter er jo gitt som h i = - p(s i ) log (p(s i )). Setter vi inn uttrykket for p(s i ) ovenfor får vi at h i = (/ k ) log (/ k ) = (/ k ) (log () log ( k )) = (/ k ) ( k) = k/ k der k er et heltall. p( s i ) = k ermed har vi vist at i dette tilfellet blir de ideelle lengdene av kodeordene gitt ved entropien sammenfallende med de faktiske kodeordlengdene b i som alltid er heltall. ermed har vi at N N R = p( si ) bi = p( si )log( p( si )) = H i= i=
. Huffmankoding med kjente sannsynligheter Gitt en sekvens av symboler som er tilstrekkelig lang, og som inneholder de symbolene,,,,,. Symbolene forekommer med sannsynligheter Symbol Sannsynlighet...... a) inn kodeboken for en Huffman-koding av disse symbolene. b) Hva er gjennomsnittlig antall biter pr. symbol i sekvensen etter Huffman-kodingen? c) Hva er entropien til symbol-sekvensen? ørst sorterer vi symbolene etter sannsynlighet (merkert med grønt), grupperer så de to-og-to minst sannsynlige, og slår sammen sannsynlighetene (markert med blått). Tilordner så bit nedenfra og oppover(markert med rødt): Symbol Sannsynlighet.......... ette gir oss følgende tabell ofte kalt kodebok : : : : : : : Gjennomsnittlig kodelengde blir summen av produktene av sannsynlighet og kodelengde: R =.*+.*+.*+.*+.*+.* =.+.+.+.+.+. =. biter pr. symbol. ntropien er gitt fra tabellen over sannsynlighetene for hvert symbol: H=. Vi ser at gjennomsnittlig kodelengde pr symbol er større enn entropien, så er Huffman-kodingen i dette tillfellet ikke helt optimal.
. Kodeboken til en Huffmankoding inn kodeboken for en Huffman-koding av igital overalt!, og opp kodeboken som en tre-struktur. r denne forskjellig fra det du ville fått med en Shannon-ano koding? et sorterte histogrammet og kodeboken blir som vist i tabellen nedenfor I T L G O V R! Se på tre-strukturen nedenfor og sammenlign med histogrammet ovenfor. Vi slår sammen (R og!) til, (V og ) til to, (O og ^) til ( og G) til Nå har vi symboler eller sammenslåtte symboler med hyppighet. Ved fire sammenslåinger har vi fire samlinger med hyppighet. eretter får vi samlinger med hyppighet, og endelig alle symbolene på toppen av strukturen. Så setter vi bit-verdiene og på alle forgreningene, til venstre og til høyre. Og deretter kan vi lese kodeordet for hvert symbol nedenfra og oppover i trestrukturen, med bakerste bit først, for eksempel V =. Resultatet er her akkurat det samme som en av mange mulige løsninger vi ville fått med Shannon-ano. I T L G ^ O V R!
. Huffmankoding av en oppgitt tekst enne setningen skal kodes. a) Hvordan ser kodeboken for en Huffman-koding ut? b) Hva er gjennomsnittlig antall biter pr. symbol etter kodingen? c) Hvordan ser bitstrømmen for symbol-sekvensen ut etter koding? are så det er helt klart: Her er det setningen enne setningen skal kodes som skal analyseres og kodes. Vi må ta med blanke mellom ordene for at motatt bitstrøm skal bli lesbar. Tegnene forekommer med følgende HYPPIGHT: N S T I G K L O Sortert på hyppighet (vi trenger ikke regne ut sannsynligheten (relativ frekvens): N S K T I G L O Merk: Her er det mange bokstaver med lik hypplighet. vhenger av hvordan man stokker/sorterer de bokstavene som har lik hyppighet, kan vi få forskjellig kode. Kodelengdene blir imidlertid de samme (gjennomsnittlig). Vi får en kodebok som er gitt i de to første kolonnene nedenfor: symbol kode kodelengde hyppighet Produkt N S K T I G L O sum Lengden av hvert kodeord er gitt i tredje kolonne i tabellen. Multipliserer vi dette med hyppighetene for hvert symbol og summerer, kommer vi til bits. biter fordelt på symboler gir oss et gjennomsnitt på. bits/symbol. itstrømmen blir da Her er kodeordene for hvert symbol adskilt med en blank for å øke lesbarheten. I virkeligheten mottas denne setningen som
. Vi har gitt følgende bilde: a. inn Huffman-kodingen av dette bildet. Hvor mange bits blir det per piksel i gjennomsnitt etter koding hvis vi ser bort fra at vi trenger plass til å lagre kodeboken? Vi har følgende forekomster, først i rekkefølge etter symbolverdiene, deretter sortert. Slår sammen først og, så dette med, så og sammen, så dette med resten, som vist i grafen nedenfor: : : : : : : : : : : Huffman-kodene blir da (her er det flere mulige riktige løsninger!): : : : : : Og det gjennomsnittlige antall bits pr piksel etter koding blir (*+*)/=(+)/=/=. bits per piksel. b. Ved differansetransform tar vi differansen mellom et piksel og dets nabo til venstre. Siden pikslene lengst til venstre i bildet ikke har noen venstre nabo, beholder vi pikselverdien her. inn differanse-transformen av bildet ovenfor. tter differansetransform vil bildet se slik ut: - - - - - - - -
c. inn så Huffman-koden for det differansetransformerte bildet, slik at du kan beregne det gjennomsnittlige antall bits per piksel for det differansetransformerte bildet. Vi har følgende forekomster, først i rekkefølge etter symbolverdiene, deretter sortert. Slår sammen først - og, så dette med, så dette med, som vist i grafen nedenfor: : : : : : -: -: : Huffman-kodene blir da (her er det igjen flere mulige riktige løsninger!): : : -: : Og det gjennomsnittlige antall bits pr piksel etter differansetransform og Huffmankoding blir (+*+*)/=(++)/=/=... bits per piksel. ltså færre bits pr symbol ved å gjøre differansekoding først og så Huffman, enn med bare Huffman. d. ntropien til bildet vi startet med i forrige oppgave er. biter. Hvorfor ble det gjennomsnittlige antall biter per piksel større enn entropien i deloppgave a), men mindre enn. i deloppgave c)? ntropien beregnet fra histogrammet til bildet er en nedre grense for hvor kompakt bildet kan kodes, hvis vi bare ser på ett piksel av gangen. enne grensen er bare mulig å oppnå hvis alle sannsynlighetene i det normaliserte histogrammet er av typen /k, der k er et heltall. ette kravet er ikke oppfylt her. erfor er ikke Huffman-transformen optimal, og vi får et gjennomsnittlig antall bits i deloppgave a som er litt større enn entropien. I deloppgave c ser vi ikke bare på ett piksel av gangen, men på differansen mellom to og to piksler. a kan vi kode mer kompakt enn det som er gitt av entropien for enkelt-piksler.. n fax-oppgave a) nta at en telefonsamtale har en båndbredde på khz, og at det analoge signalet samples i henhold til Nyqvist-kriteriet. nta også at det er mulige lydnivåer i hvert sample. Hvor stor overføringskapasitet må vi ha på telefon-linjen, uttrykt i k/s, når vi bruker naturlig bitkoding av amplituden? Nyqvist-kriteriet sier at vi skal sample med minst det doble av den høyeste frekvensen som finnes i signalet, dvs * khz = Hz.
Vi trenger biter til en naturlig bitkode for forskjellige amplitudeverdier. Vi får da ganske enkelt sampler/s * biter/sampel = biter/s = k/s b) nta at det er G= forskjellige nivåer på amplituden til hvert sample, og at når vi sorterer dem etter hvor ofte de forekommer i en telefon-samtale, så finner vi i dette spesielle tilfellet at sannsynlighetene er ½, ¼, /, /,, /, /, /. Hvor mange slike telefonsamtaler kan vi overføre i parallell på en kbits/s ISN-linje med Huffman-koding av amplitudene? Hint : ntropien er gitt ved H = G i= essuten: Og til slutt: p i log p i ( ) log(teller/nevner) = log(teller) log(nevner) log ( n ) = n Hint : Summen ½+/+/ +/+/ + konvergerer raskt mot. Her er det ikke nødvendig å finne Huffman-koden. Vi har terpet at en Huffman-koding der alle sannsynlighetene kan skrives som brøker der telleren er og nevneren er en toer-potens er optimal i den forstand at det gjennomsnittlige antall bits per sample er lik entropien til signalet. ntropien er her gitt ved H = - (½ log (/) +/ log (/) + / log (/) + ) (se Hint ) = ½ + / + / + = (som angitt i Hint ovenfor). et gjennomsnittlige antall bits per sampel blir altså bare bits/sampel. ntall samtaler blir: bits/s /( sampler/s * bits/sampel) =. c) t ark med tekst og enkle strekinger skal sendes pr digital fax over en modemlinje med kapasitet på biter/sekund. Vi bruker en standard fax med fotosensorer per linje og linjer per side. axmaskinen gjør en terskling av bildet av siden. Hvor lang tid tar det å overføre en side uten kompresjon? tter terskling trenger vi selvsagt bit per piksel for å representere og. bit/piksel * piksler/linje * linjer/side = bits/side. bits/side / bits/sekund = sekunder = min s. d) nta at vi hadde kunnet gjøre tekstgjenkjenning på den delen av arket som inneholder tekst, og representert symboler og mellomrom med bits SII. nta at det maksimalt er pr linje og linjer pr side. nta også at vi kunne beskrevet strekingene som maksimalt rektangler per side, og at sidene på rektanglene er parallelle med kantene på siden. Gi et worst case estimat av hvor mange biter du vil trenge for å beskrive innholdet på siden med en oppløsning som svarer til faxens oppløsning, og hvor lang tid det vil ta å overføre dette over modemlinjen.
or å representere et rektangel og dets plassering trengs følgende: en koordinat for et punkt på rektanglet, f eks øverste venstre hjørne rektanglets bredde og rektanglets høyde Kordinatene for øvre venstre hjørne til et rektangel vil ligge mellom (,) og (,). et betyr at begge koordinatene krever biter (). et samme gjelder høyde og bredde. Til sammen blir dette * biter = biter. a blir regnestykket slik: rektangler biter/rektangel* rektangler = biter * * biter/ = biter Worst case er altså at vi trenger biter pr side. Med en overføringskapasitet på bits/sekund tar dette t = biter / biter/s =, sekunder. e) Vi vil gjerne undersøke hvor mye det er å spare på å separere SII fra alt annet i en fax, og sende bits SII kode for hvert, mens resten sendes ukomprimert uansett hva det er. Hvis halvparten av hver side i gjennomsnitt er SII-, hvor mye sparer vi da i forhold til ordinær fax? ( biter/ * / + bit/pixel **/ piksler)/(*) = ( + ) / =, Vi sparer altså %-.% =.%. f) Utsnittet på * piksler av et binært bilde nedenfor kan representeres med biter. Ser vi på runlength-representasjonen av det samme utsnittet, finner vi at det består av runs med lengder mellom og piksler. Hvis vi bruker biter på hver, blir dette biter. Imidlertid er det mulig å gjøre dette litt mer kompakt ved å Huffman-kode de løpelengdene. Ved løpelengdetransformasjon av binære bilder trenger vi ikke å lagre tallpar (gråtone, løpelengde) slik som for gråtonebilder. Vi trenger bare løpelengdene, for det er bare to mulige intensitetsverdier. Løpelengdene finnes i tabellen til høyre. inn Huffmann-koden til løpelengdene i tabellen til høyre over, og finn det totale antall biter etter koding av løpelengdene.
Nedenfor har vi løpelengde, lengden på hvert kodeord, kodeordet, og antall forekomster av hver løpelengde. Og helt til høyre kodetreet. Og det totale antall bits etter koding blir *+*+*+*=+++= biter. Prøv selv -oppgaver. Kompresjon med diverse JV-programmer a) Se på bildene a.png, a.png og a.png som ligger på /ifi/midgard/k/inf/www_docs/bilder/. Prøv å komprimere bildene med JV-programmene ntropy, eltancoder, HuffmanTest og RunLengthncoder. isse programmene har du tilgang til hvis du fikk satt riktig LSSPTH i tidligere oppgaver). Sammenlign entropien for de tre bildene. (java ntropy a.png) Hvilket bilde har høyest entropi? Hvordan stemmer dette med det du trodde ved å se på bildene? ildet a.png har entropi., a.png., og a.png.. ildet a.png har lite støy, så øker støyen og blir størst i a.png. ette gjenspeiler seg i entropien, som øker med graden av støy. b) Sammenlign kompresjonsraten med differansekoding (eltancoder), Huffman-koding og run-length koding for de ulike bildene. Med differansekoding får a.png kompresjonsrate på., a.png., og a.png.. Vi ser altså at a.png og a.png tar mer plass ved binærlagring av differansetransformert bilde. Merk at vi ofte kombinerer differansetransform med annen koding, f.eks. Huffman. Med Huffman-koding får a.png kompresjonsrate., a.png. og a.png.. Igjen størst kompresjonsrate for bildet med lite støy. Med Run-length-koding får vi kompresjonsrate. for a.png,. for a.png, og. for a.png. Virker altså ypperlig for det støyfrie bildet, men dårlig i støyfylte bilder.