PNG – Portable Networks Graphics

pnglogo-blk-sml1.gif

Formatet PNG har mycket kort historia. Men orsakerna till dess uppkomst går lite längre bak i tiden och är något brokig. 1987 arbetade Bob Berry hos CompuServe på att ta fram ett format för bilder som skulle vara portabelt och komprimerat, formatet var GIF. Den komprimeringsalgoritm som man bestämde sig för att använda var LZW ( efter Lempel, Ziv och Welch). Detta bestämde man sig för i tron att LZW-algoritmen var öppen att använda. Men i samma veva var Unisys ute efter att ta patent på komprimeringsmetoden. CompuServe fick reda på patentförhållandet först när specifikationen för GIF var publicerad och formatet i användning. Unisys nöjde sig emellertid med, efter diverse turer, att ta betalt enbart av dem som hårdvaruimplementerade LZW-algoritmen.

Detta fick emellertid en drastisk vändning 1994. Då bestämde sig Unisys för att börja ta betalt även av mjukvaruimplementeringar av LZW. Förmodligen för att Internet vid den tiden började växa och därmed även användningen av GIF-formatet. Unisys och CompuServe ingick under julhelgen 1994 ett avtal som väckte stor ilska i olika grupperingar på Internet. Denna ilska omvandlades till handling och blev starten för en arbetsgrupp ledd av en herre vid namn Thomas Boutell, och med avsikt att ta fram ett nytt bildformat som komplement till GIF. Formatet, som kom att kallas PNG, skulle vara bättre, mindre, mer flexibelt och framför allt - GRATIS.

 Användningsområde

PNG är främst taget fram för att användas inom två områden, web-grafik och lagringsformat.
Som ett format för web-grafik är det tänkt att ersätta det alltmer föråldrade GIF-formatet, vars egenskaper och möjligheter inte i alla avseenden möter de krav som ställs idag och kan komma att ställas i framtiden på ett filformat för webbilder.
På grund av sin effektiva förlustfria komprimering är PNG dessutom utmärkt att använda som ett mellanlagringsformat vid redigering och utbyte av bilder. I detta avseende så sneglar PNG-förespråkarna främst på den marknadsandel som idag hålls av formatet TIFF och andra liknande format med ickeförstörande komprimering.

För web-grafik så har PNG några huvudsakliga fördelar mot företrädesvis GIF:

• PNG har full alphakanal (8 eller 16 bitar) med variabel transparens, till skillnad mot GIF som bara kan hantera transparent eller icke transparent. I PNG kan alltså varje pixel sättas till en mängd skilda transparensnivåer.
• PNG kan styra gammakorrektion. Med det menas att man kan reglera, via ljusintensiteten, hur bilden skall återges på bildskärmen för att se ut som den ursprungligen var tänkt att se ut. Detta är av vital betydelse eftersom allting inte alltid är vad det ser ut att vara. Två bildskärmar återger i allmänhet inte en bild så att den ser likadan ut, beroende på dels bildskärmen som sådan och dels den omgivande miljöns ljusförhållanden.
• PNG använder sig av tvådimensionell interlacing vid progressiv bildvisning, till skillnad från GIF-formatets mer linjevisa, endimensionella. En av vinsterna med interlacing är att man kan visa bilden samtidigt som man tar emot den. En tvådimensionell interlacing gör att symmetrin i bilden blir bättre vid den successiva visningen. Nackdelen är att den första bilden kan ha något grövre utseende än motsvarande första GIF-bild. Typiskt kan den första delbilden i PNG visas åtta gånger fortare än motsvarande första delbild i GIF-format.
• PNG kan även lagra en mängd övrig tilläggsinformation såsom text och annan data i bildfilen.
• En liten fördel är även att generellt sett så komprimerar PNG bättre än GIF, men bara omkring 10-30%.
• En nackdel som PNG har gentemot GIF är att PNG än så länge inte stödjer multipla bilder, det vill säga animeringar. Planer finns på att ta fram ett nytt format som kan hantera multipla bilder. Men det kommer i så fall att specificeras som ett nytt format.

Som filformat för bildeditering kan man tillskriva PNG följande för- och nackdelar:

• Helt förlustfri kompression vilket gör att man inte får någon degradering av generationskopior.
• Stödjer upp till 48 bitars färgdjup i RGB, 16 bitars djup i gråskala, indexerade färger samt full alphakanal.
• Till skillnad mot TIFF så innehåller PNG-formatet inte några delar som är begränsade av patent. Det gör att det är ett helt öppet format och som enligt specifikationen skall vara applikationsoberoende.
• När det gäller slutgiltig distribution av t.ex. truecolor-bilder så är inte PNG det bästa formatet. För det ändamålet är till exempel JPEG-formatet bättre på grund av att JPEG komprimerar med förlust och kan därmed reducera storleken väsentligt på filerna. PNG:s nackdel i detta fall är den förlustfria komprimeringen.

PNG-filens första 8 bytes innehåller en signatur, en serie av decimala tal (137 80 78 71 13 10 26 10) som talar om att detta är en PNG-fil vars innehåll är ett antal chunks, dataportioner. Efter signaturen kommer en en chunk som kallas Image HeaDeR (IHDR). Filen slutar som brukligt är i datasammanhang med en chunk vid namn ImageEND (IEND). Mellan dessa båda så finns den chunk som innehåller data, IDAT samt andra chunks med speciella syften, t ex den chunk som hanterar gammakorrektion.

 Varje chunk består av fyra delar:

• Längd - 4 bytes som anger längden av aktuell chunks datainnehåll, det vill säga längden på den del av chunken som innehåller data.
• Chunktyp – 4 bytes som talar om vilken typ det är, vad den innehåller. I formatspecifikationen finns en mängd olika typer av chunks specificerade. Vissa är nödvändiga medan vissa bara behövs för speciella tillämpningar. Specifikationen innehåller instruktioner om hur dekodrar skall reagera på chunktyper som den inte känner igen. Att dekodrar ställs inför obekanta chunktyper kan inträffa då PNG är ett fritt format, det vill säga att nya chunktyper kan läggas till. Trots detta garanteras kompabilitet mellan olika applikationer genom att kritiska chunks skall kunna läsas av alla dekodrar.
• Chunkdata – det faktiska innehållet enligt chunktyp, data för datachunk, text för textchunk m.m.
• CRC – 4 bytes CRC (Cyclic Redundancy Check) baserad på alla bytes i chunken utom längdfältet. CRC-metoden används för att upptäcka error under en dataöverföring. Dekodern räknar ut ett CRCvärde för den data den packar upp och jämför det värdet med det som enkodern har räknat ut när filen komprimerades/kodades. Om värdena misstämmer gick något fel i överföringen. CRC beräknas enligt standardiserade metoder.

IHDR är den viktigaste chunken och innehåller i olika bytes, enligt bestämda koder, följande:

• bildens bredd i pixlar - 4 bytes
• bildens höjd i pixlar - 4 bytes
• bitdjup - 1 byte. Antalet bitar per sampel vid gråskala eller RGB, eller antalet bitar per palettindex vid indexerade färger.
• färgrepresentationsmodell - 1 byte. Talar om vilken färgrepresentationsmodell man använder, gråskala, RGB eller indexerade färger. Vilka värden som är giltiga hänger intimt samman med aktuellt bitdjup. Enbart vissa kombinationer är tillåtna. Till exempel så kan man bara ha 8 eller 16 bitars djup vid RGB-färg. I denna byte specificerar också om man skall ha en alphakanal.
• kompressionsmetod - 1 byte. Än så länge kan man bara välja ingen kompression eller kompression med den enda metod som för tillfället finns i PNG-specifikationen. Formatet är förberett för att kunna hantera fler metoder, om och när detta blir aktuellt.
• filtermetod - 1 byte. Antingen ingen filtrering eller filtrering med de filterkombinationer som enkodern finner lämpligast. Formatet är utbyggbart med fler filtertyper och kombinationer.
• interlacemetod - 1 byte. Interlace med metoden Adam7 eller inte interlace.

Före komprimeringen utför man en filtrering av datan i bilden. Filtreringsfunktionen är implementerad i enkodern/dekodern och har som uppgift att möjliggöra en effektivare komprimering. I PNG finns 5 olika filtertyper specificerade; 0 – None, 1 - Sub, 2 – Up, 3 - Average, 4 – Paeth. 0 är inget filter och de övriga är olika filtervarianter. Ett krav på filtreringsmetoderna är naturligtvis att de är reversibla, så att inversfiltrering kan utföras när bilden skall presenteras efter dekomprimering.
Filtreringen sker linjevis över bilden, från vänster till höger, uppifrån och ner. Om en intelligent enkoder/dekoder används, vilket är att föredra, kan olika filter användas för varje sådan skanlinje i bilden. Metoden att välja vilket filter som passar bäst att applicera på varje rad i bilden kallas för adaptiv filtrering.
Den dataström som efter filtreringen sänds till komprimeringssteget, föregås av en byte som specificerar vilken filtertyp som använts på den aktuella skanlinjen. Trots att en extra byte för varje rad gör att datamängden ökar, blir ändå nettostorleken mindre.
Filtreringen arbetar inte på pixelnivå utan på byte-nivå. Filtrering sker på den bytesekvens som ges av varje skanlinje. Det vill säga att pixelinnehållet formerar sig till bytes och varje skanlinje ger ett visst antal bytes, enligt specifikationen för PNG-formatet. Hur pixlarna formerar sig till bytes hänger bland annat ihop med det bitdjup och den färgrepresentation man använder. Om vi har en äkta färgbild (icke indexerad) så består varje pixel av 3 sampel, ett för vardera R, G och B. Ponera sen att varje sampel består av 8 bitar. Det ger oss vad i dagligt tal kallar 24 bitars färg, och följdaktligen består då varje pixel av 3 bytes. Se figur 1. Till detta skall läggas den den eller de bytes som tillkommer om vi använder oss av en alphakanal.

Ett exempel på hur en av de specificerade filtertyperna arbetar kan se ut som följer:

Filtret är det så kallade sub-filtret, filter 1, och levererar som utvärde skillnaden mellan värdet av varje byte och värdet av motsvarande byte för föregående pixel. Formeln lyder: Sub(x) = Raw(x) - Raw(x-bpp), där x ligger i intervallet noll --> antalet bytes i varje skanlinje minus 1, Raw(x) är värdet vid den bytepositionen i skanlinjen och bpp är antalet bytes per komplett pixel. För en 24 bitars färgbild, det vill säga en bild med 3 sampel per pixel(RGB) och 8 bitar per sampel (bitdjup), är bpp=3. Som förutsättning för alla filter gäller att: för alla x < 0 antas Raw(x) = 0, samt att för de filtertyper som räknar på föregående rad så antas rader < 0 vara = 0.

För fallet då bpp=1 kan formeln ovan lätt tolkas om till det mer lätt igenkännliga Sub(x) = Raw(x) - Raw(x-1), det vill säga att Sub(x) är skillnaden mellan två närliggande pixlar.

 Övriga specificerade filter fungerar på likvärdigt sätt. Den enda skillnaden är på vilka pixlar filtret utför sina beräkningar. Paeth är det filter som skiljer sig mest åt från de övriga. Det använder sig av en linjär funktion för att beräkna utvärdet, samt att värderingen görs på bytes ur en större omgivning.
Den ström av sub-värden som bildas vid filtreringen av varje skanlinje är vad som sänds till komprimeringssteget. Som filteralgoritmen är utformad så inses, att för stora delar av bilden så kommer subvärdena inte att skilja sig åt speciellt mycket, i vissa fall kommer de till och med att vara lika. Det innebär att det är mycket lätt för en komprimeringsalgoritm av rätt sort att komprimera filen kraftigt.

Efter det att filen har dekomprimerats, packats upp, måste den inversfiltreras för att få till baka det rätta innehållet. Det görs för sub-filtret med formeln Raw(x) = Sub(x) + Raw(x-bpp). För övriga filter bildas inversen på likadant sätt.

Vid såväl filtrering som inversfiltrering av bilden används aritmetiken unsigned modulo 256.

Den komprimeringsmetod som används är bland de bästa som går att få utan att förlora information eller att behöva betala licensavgifter. Metoden är en variant av LZ77, vilken även används till packningsprogram som zip, pkzip och andra liknande program. LZ77 är en algoritm framtagen 1978 av två israeler, Lempel och Ziv. Deras modifierade variant av LZ77, LZ78, vidareutvecklades senare av en herre vid namn Welch och blev då den kanske mer bekanta komprimeringsalgoritmen LZW.

Den dataström som komprimeringen ger upphov till lagras i ett visst format bestående av:

• 1 byte som specificerar komprimeringsmetod
• 1 byte med ytterligare information
• block av komprimerad data med storleken n bytes
• 4 bytes kontrolldata

Varje datablock kan innehålla antingen okomprimerad data eller komprimerad data kodad med standard Huffman-koder eller komprimerad data kodad med skräddarsydda Huffman-koder. Huffman-koderna används för att indela och strukturera den komprimerade datan på ett effektivt sätt i nåt som liknar tabellform.

Det är denna dataström av det ovan specificerade formatet som finns i de chunks som innehåller data och som är av chunktypen IDAT.

En PNG-bild kan lagras i interlaceformat för att åstadkomma en progressiv visning av bilden, vilket innebär att den kan visas "on the fly". Det förfarandet är mycket lämpligt i Internetsammanhang, eftersom en användare då nästan omedelbart kan få se en bild, omän inte med fullständigt innehåll och kvalitet. Den initialt låga kvalitén har inte så stor betydelse eftersom människan har en häpnadsväckande förmåga att ur en liten mängd information interpolera fram det viktiga i bilden.

Den interlacingmetod som använs i PNG-formatet är tvådimensionell och kallas för Adam7 efter sin upphovsman. I stora drag så innebär den metoden att bilden visas i sju olika steg. Mönstret för i vilket steg varje pixel i bilden skall visas byggs upp genom att kopiera följande 8x8-matris över hela bilden med början i det övre vänstra hörnet:

1 6 4 6 2 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7
3 6 4 6 3 6 4 6
7 7 7 7 7 7 7 7
5 6 5 6 5 6 5 6
7 7 7 7 7 7 7 7

Varje nummer i matrisen representerar i vilket steg motsvarande pixel ska visas. Som man kan se så är det inte mycket information som visas efter det första steget, men eftersom metoden är snabb så hinner fler steg visas på en mycket kort tid. Det innebär att man som betraktare inte behöver vänta speciellt länge innan man kan se vad bilden föreställer. Enkel matematik ger att den första visningen, steg1, innehåller bra precis 1/64-del av hela bildens innehåll i pixlar räknat. Nedan följer ett starkt schematiskt exempel på hur det kan se ut. Bollarna, 64 st till antalet åskådliggör schemat enligt ovan. De två första rutorna ingår inte i Adam7-mönstret.

png-9passes-sml.gif

Eftersom formatet är relativt nytt är det svårt att sia om dess framtid och vilka möjliga tillämpningar det kan tänkas få. För web-grafik borde det på sikt kunna ersätta GIF-formatet.

Framgången för formatet är avhängigt flera olika faktorer. För det första beror framtiden på i vilken takt tillverkare av web-läsare och bildredigeringsprogram väljer att implementera formatet. En ytterligare viktig faktor är att någon skriver enkoder/dekoder som på ett smart sätt tar tillvara de möjligheter som formatet specificerar.

En viktig anledning till att PNG kan bli ett av framtidens stora bildformat är att det är ett öppet format, de metoder som idag används är än så länge inte patenterade. Det öppna formatet gör också att dess utveckling och framtid ligger delvis i händerna på dess användare. Formatet administreras av ett konsortium som hela tiden skall se till att ta in och utvärdera synpunkter på förändringar och nya funktioner. Såsom formatet är uppbyggt skall nya funktioner kunna läggas till utan att äldre enkoders/dekoders inte skall kunna tolka och hantera filer.

I dagsläget är det flera stora tillverkare av bildredigeringsprogram och web-läsare som har formatet implementerat direkt i sina nuvarande produkter, eller i sina nästkommande versioner. För den som har äldre versioner av program, men ändå vill kunna ta del av PNG-formatets möjligheter, finns en ganska rik flora av plug-ins ute på Internet. För länkar, se källförteckning.

1. Vilken är en av bakgrunderna till att PNG-formatet togs fram?
2. Vilka är de två huvudsakliga användningsområdena som PNG är avsett för?
3. PNG-formatet har många fördelaktiga egenskaper. Nämn två egenskaper inom vardera av de två områdena enligt fråga 2.
4. Vad har CRC (Cyclic Redundancy Check) för uppgift?
5. Före komprimering av en PNG-bild kan man utföra en filtrering. Vad är vinsten med detta förfarande?
6. Vilket är det grundläggande kravet på ett PNG-filter såväl som på andra filter, vid icke förstörande bildbehandling?
7. På vad (typ av data) och hur (orienteringsmässigt) i en bild arbetar filtret?
8. Vad menas med adaptiv filtrering?
9. Vari ligger vinsten med att använda interlacing vid bildvisning?
10. Vad är det speciella med PNG-formatets interlacingmetod?

1. Att Unisys fick patent på den komprimeringsalgoritm, LZW, som används i det populära bildformatet GIF, och därmed kunde ta betalt för användningen av det. Därför ville man ta fram ett nytt format som var "gratis", fritt från patent.
2. Web-grafik och ett format för mellanlagring vid bildbehandling.
3. Se stycket Fördelaktiga egenskaper
4. Se stycket uppbyggnad av en PNG-fil.
5. Att den filtrerade datan skall kunna komprimeras bättre. Se vidare stycket för filtrering.
6. Att det är reversibelt, det vill säga att den ursprungliga bilden kan återskapas med "inversen" till filtret.
7. Fitreringen arbetar på byte-nivå, ej på pixelnivå. Fltreringen sker radvis i så kallade linjeskan.
8. Att en intelligent enkoder kan själv bestämma vilket filter som lämpar sig bäst för varje rad i bilden.
9. Att man kan visa bilden progressivt, vilket gör att det kan ske samtidigt som andra händelser.
10. Att den är tvådimensionell, vilket gör att varje bildvisningssteg kan innehålla mindre data. Det gör att metoden blir kraftfull. Lite datakraft går åt till att visa förhållandevis hyggliga första delbilder.