Ordbokskodning. Enkel variant av kodning med variabelt antal insymboler och fixlängds kodord. (Jfr tunstallkodning)

Transkript

1 Datakompression fö 6 p.1 Ordbokskodning Enkel variant av kodning med variabelt antal insymboler och fixlängds kodord. (Jfr tunstallkodning) Man skapar en ordbok som innehåller 2 b olika sekvenser av symboler från alfabetet och kodar med kodord av längd b. Statiska ordböcker kan fungera bra om man bara kodar sekvenser med välkänd statistik, annars vill man ha någon metod för att adaptivt bygga upp sin ordbok.

2 Datakompression fö 6 p.2 Exempel, minnesfri binär källa A = {x, y}, p(x) =0.9, p(y) =0.1. Låt b =3. Låt ordboken bestå av de två enstaka symbolerna, plus de 6 mest sannolika sekvenserna av längd 4. Denna kod har datatakten Sekvens kodord x 000 y 001 xxxx 010 xxxy 011 xxyx 100 xyxx 101 yxxx 110 xxyy 111 R = =

3 Datakompression fö 6 p.3 Lempel-Zivkodning Koda symbolsekvenser genom referenser till vad som hänt tidigare i sekvensen. Det finns två huvudtyper: Använd en historiebuffert, koda en delsekvens som en pekare till när sekvensen uppträdde senast (LZ77). Bygg upp en ordbok av alla unika delsekvenser som uppträder, koda referenser till tidigare ord (LZ78).

4 Datakompression fö 6 p.4 Lempel-Zivkodning, forts. Kodaren och avkodaren behöver inte känna till källans statistik. Prestanda kommer asymptotiskt att gå mot entropigränsen. En sådan kodningsmetod kallas universell. Lempel-Zivkodning i dess olika varianter är de mest använda metoderna för filkomprimering och -arkivering, t.ex. zip, gzip, ARJ och compress. Bildkomprimeringsstandarderna GIF och PNG använder Lempel-Ziv. Standarden V.42bis för komprimering av modemtrafik använder Lempel-Ziv.

5 Datakompression fö 6 p.5 LZ77 Lempel och Ziv Betrakta sekvensen som ska kodas genom ett glidande fönster. Fönstret delas i två delar, en del som innehåller redan kodade symboler (search buffer), en del som innehåller symboler som ska kodas härnäst (look-ahead buffer). Hitta den längsta sekvens i search buffer som matchar den sekvens som börjar i look-ahead buffer. Kodordet är en trippel <o,l,c>där o är en pekare till var i search buffer sekvensen börjar (offset), l är längden av sekvensen, och c är nästa symbol som inte matchade. Denna trippel kodas med ett fixlängds kodord. Antalet bitar som krävs är log S + log W + log N där S är storleken på search buffer, W storleken på look-ahead buffer och N är alfabetets storlek.

6 Datakompression fö 6 p.6 Förbättringar av LZ77 Det är onödigt att skicka en pekare och en längd om vi inte hittade en matchande sekvens. Dessutom behöver vi bara skicka en ny symbol då vi inte hittade någon matchande sekvens. Inför istället en extra flaggbit som talar om om vi hittade en match eller inte. Antingen skickar vi alltså < 1,o,l>eller < 0,c>. Denna variant av LZ77 brukar kallas LZSS (Storer och Szymanski, 1982). Beroende på buffertstorlekarna kan det även löna sig att koda korta sekvenser som ett antal enstaka symboler istället för en match. I början av kodningen, innan historiebufferten blivit fylld, kan man använda kortare kodord för o och l. Alla o, l och c är inte lika sannolika, så man kan få ytterligare kompression genom att koda dem med variabellängdskoder (t.ex. huffmankoder).

7 Datakompression fö 6 p.7 Buffertstorlekar I princip får man bättre kompression ju större historiebuffert man använder. Av praktiska skäl så brukar man nöja sig med buffertstorlekar runt Det är inte så vanligt med väldigt långa matchlängder, så man kan oftast nöja sig med att låta den maximala matchlängden vara ett eller par hundra symboler. Exempel: LZSS-kodning av tecken från bibeln.txt, buffertstorlek Histogram för matchlängder:

8 Datakompression fö 6 p.8 DEFLATE Deflate är en variant av LZ77 som använder huffmankodning. Det är den metod som används i zip, gzip och PNG. Indata som kodas är bytes. Datat kodas i block av godtycklig storlek (undantaget okomprimerade block som kan vara max bytes). Blocket kan kodas antingen okomprimerat eller med hjälp av LZ och huffmankodning. Matchlängderna kan vara mellan 3 och 258. Offset kan vara mellan 1 och Huffmankodningen är antingen fix (fördefinierade kodord) eller dynamisk (kodorden skickas som sidoinformation). Två huffmankoder används: en kod för enstaka symboler (literals) och matchlängder och en kod för offset.

9 Datakompression fö 6 p.9 Symboler och längder Huffmankoden för symboler och längder använder alfabetet {0, 1,...,285} där värden tolkas som symboler, värdet 256 markerar blockslut och värden används för att koda längder tillsammans med extra bitar: extra extra extra bitar längd bitar längd bitar längd , , , ,

10 Datakompression fö 6 p.10 Offset Huffmankoden för offset använder alfabetet {0,...,29}. Extrabitar används för att specificera offset extra extra extra bitar offset bitar offset bitar offset , ,

11 Datakompression fö 6 p.11 Fixa huffmankoder Kodord för symbol/längd-alfabetet: värde antal bitar kodord Det reducerade offsetalfabetet kodas med en fembitars fixlängdskod. Exempelvis kodas alltså en match av längd 116 på offset 12 med kodorden och

12 Datakompression fö 6 p.12 Dynamiska huffmankoder Kodordslängderna för de olika huffmankoderna skickas som extra information. För att få ytterligare kompression skurlängdskodas sekvensen av kodordslängder först och huffmankodas sen (!). Kodordslängderna för denna huffmankod skickas som som trebitars fixlängdskodord. Algoritmen för att konstruera kodorden från kodordslängderna är specificerad i standarden.

13 Datakompression fö 6 p.13 Kodning Det som är standardiserat är syntax för den kodade sekvensen och hur den ska avkodas, däremot är det inte hårt specificerat hur en kodare ska fungera. Det finns en rekommendation om hur man kan konstruera en kodare: Sökningen efter matchande sekvenser görs inte med uttömmande sökning i hela historiebufferten, utan med hjälp av hashning. Ett hashvärde räknas fram från de tre första symbolerna som ska kodas härnäst. I hashtabellen håller man reda på de offset där sekvenser med samma hashvärde startar (förhoppningsvis sekvenser där de tre första symbolerna stämmer överens, men det kan man inte garantera). De offset som har samma hashvärde söks igenom för att hitta den längsta matchningen, med början från den senaste adderade. Hittas ingen match kodas den första symbolen som en enstaka symbol. Man begränsar även sökdjupet för att få en snabbare kodning, på bekostnad av kompressionen. T.ex. styr komprimeringsparametern i gzip hur noga man söker.

14 Datakompression fö 6 p.14 Dokument Se även: ftp://ftp.uu.net/pub/archiving/zip/ ftp://ftp.uu.net/graphics/png/

15 Datakompression fö 6 p.15 LZ78 Lempel och Ziv En ordbok av unika sekvenser byggs upp. Storleken på ordboken är S. I början är ordboken tom, sånär som på index 0 som betyder ingen match. Varje ny sekvens som kodas skickas som tupeln <i,c>där i är index i ordboken för den längsta matchande sekvens vi hittar och c är nästa tecken i indata som inte matchade. Antalet bitar som krävs är log S + log N Avkodaren kan bygga en identisk ordbok.

16 Datakompression fö 6 p.16 LZ78, forts. Vad gör man när ordboken blir full? Det finns några olika alternativ: Släng bort ordboken och börja om. Fortsätt koda med ordboken, men skicka bara index och lägg inte till några nya ord. Som ovan, men bara så länge som kompressionen är bra. Om den blir för dålig, släng ordboken och börja om. I detta fall kan man behöva lägga till en extra symbol i alfabetet som talar om för avkodaren när man ska börja om.

17 Datakompression fö 6 p.17 LZW LZW är en variant av LZ78 (Welch, 1984). Istället för att skicka en tupel <i,c>skickar man bara index i till ordboken. För att det ska fungera måste startordboken innehålla alla enstaka symboler i alfabetet. Hitta den längsta matchande sekvensen i ordboken och skicka indexet som ett kodord. Den matchande sekvensen plus nästa symbol läggs som ett nytt ord i ordboken.

18 Datakompression fö 6 p.18 GIF (Graphics Interchange Format) Två standarder: GIF87a och GIF89a. Man specificerar en virtuell skärm. På denna skärm läggs rektangulära bilder in. För varje liten bild skickas position och storlek. Man använder färgtabeller om maximalt 256 färger. Varje delbild kan ha sin egen färgtabell, men kan även använda en global färgtabell. Färgtabellsindex för pixlarna kodas med LZW. Två extra symboler används i alfabetet: ClearCode, som markerar att vi ska kasta ordboken och börja om, och EndOfInformation, som markerar att kodströmmen är slut. Interlace: Först skickar man linje 0, 8, 16,...sen linje 4, 12, 20,...sen linje 2, 6, 10,...och sist linje 1, 3, 5,... I GIF89a har man lagt till saker som animering och transparens.

19 Datakompression fö 6 p.19 PNG (Portable Network Graphics) Togs fram delvis som ersättare till GIF eftersom LZW var patenterad (patenten har nyligen gått ut). Använder deflate som komprimeringsmetod. Färgdjup upp till 3 16 bitar. Alfakanal (generell transparens). Möjlighet att utnyttja beroende mellan bildpunkter (gör en prediktion från omgivande bildpunkter och koda skillnanden mellan prediktionen och det riktiga värde), vilket gör det enklara att koda naturliga bilder.

20 Datakompression fö 6 p.20 PNG, forts. Stödjer 5 olika prediktorer (kallade filter): 0 Ingen prediktion 1 Î ij = I i,j 1 2 Îij = I i 1,j 3 Îij = (I i 1,j + I i,j 1 )/2 4 Paeth (välj den av I i 1,j,I i,j 1 och I i 1,j 1 som ligger närmast I i 1,j + I i,j 1 I i 1,j 1 )

21 Datakompression fö 6 p.21 Testbild Goldhill Vi kodar testbilden Goldhill och jämför med tidigare resultat: GIF PNG 7.81 bitar/bildpunkt 4.89 bitar/bildpunkt JPEG-LS Lossless JPEG 4.71 bitar/bildpunkt 5.13 bitar/bildpunkt GIF fungerar inte särskilt bra på naturliga bilder, eftersom den har svårt att utnyttja den typ av beroende som finns där.