Bärbar nätverksgrafik -
Portable Network Graphics

Från Wikipedia, den fria encyklopedin

PNG -transparensdemonstration 1.png

En PNG-bild med en 8-bitars transparenskanal, överlagrad på en rutig bakgrund, som vanligtvis används i grafikprogram för att indikera transparens
Filnamnstillägg
.png
Internetmedietyp
bild/png
Skriv kod PNGf
PNG
Uniform Type Identifier (UTI) public.png
UTI -konformation offentlig bild
Magiskt nummer 89 50 4e 47 0d 0a 1a 0a
Utvecklad av PNG Development Group (donerad till W3C )
Initial release 1 oktober 1996
; 25 år sedan
 (
1996-10-01
)
Typ av format Bildformat utan förlust
Förlängd till APNG , JNG och MNG
Standard ISO / IEC 15948 , IETF RFC 2083
Ja
(GIF).

PNG stöder palettbaserade bilder (med paletter med 24-bitars RGB- eller 32-bitars RGBA- färger), gråskalebilder (med eller utan en alfakanal för transparens) och icke-palettbaserade RGB- eller RGBA-bilder i fullfärg. PNG-arbetsgruppen utformade formatet för överföring av bilder på Internet , inte för tryckgrafik i professionell kvalitet. därför stöds inte färgrymder som inte är RGB, t.ex. CMYK . En PNG -fil innehåller en enda bild i en utökningsbar struktur av bitar , som kodar de grundläggande pixlarna och annan information, såsom textkommentarer och integritetskontroller som dokumenteras i RFC 2083.

PNG -filer använder filtillägget PNG eller pngoch tilldelas MIME -medietyp image/png. PNG publicerades som informativ RFC 2083 i mars 1997 och som en ISO/IEC 15948 -standard 2004.

Historia och utveckling

-forum.

Den fullständiga specifikationen för PNG släpptes under godkännande av W3C den 1 oktober 1996 och senare som RFC 2083 den 15 januari 1997. Specifikationen reviderades den 31 december 1998 som version 1.1, som behandlade tekniska problem för gamma- och färgkorrigering . Version 1.2, som släpptes den 11 augusti 1999, lade till iTXtdelen som specifikationens enda ändring, och en omformaterad version av 1.2 släpptes som en andra upplaga av W3C -standarden den 10 november 2003 och som en internationell standard ( ISO/IEC 15948: 2004 ) den 3 mars 2004.

Även om GIF tillåter animering , beslutades det att PNG ska vara ett enbildsformat. År 2001 publicerade utvecklarna av PNG formatet Multiple-image Network Graphics (MNG), med stöd för animering. MNG uppnådde måttligt applikationsstöd, men inte tillräckligt bland vanliga webbläsare och ingen användning bland webbplatsdesigners eller utgivare. År 2008 vissa Mozilla utvecklare publicerade Animated Portable Network Graphics (APNG) format med liknande mål. APNG är ett format som stöds av Gecko - och Presto -baserade webbläsare och används ofta för miniatyrbilder på Sonys PlayStation Portable -system (med det vanliga PNG -filtillägget). År 2017 antog krombaserade webbläsare APNG -stöd . I januari 2020 Microsoft Edge blev Krom baserat därmed ärva stöd för APNG . Med detta stöder alla större webbläsare nu APNG.

PNG -arbetsgrupp

Den ursprungliga PNG -specifikationen var författad av en ad hoc -grupp av datorgrafiksexperter och entusiaster. Diskussioner och beslut om formatet fördes via e -post. De ursprungliga författarna som listas på RFC 2083 är:

Filformat

PNG -bilden PNG-Gradient.pngvisas med en hex -editor för Ubuntu .

Filhuvud

En PNG-fil börjar med en 8- bytes signatur (se hexredigerarens bild till höger):

.
Värden ( hex ) Ändamål
89 Har den höga biten inställd på att upptäcka överföringssystem som inte stöder 8-bitars data och för att minska risken att en textfil av misstag tolkas som en PNG, eller vice versa.
50 4E 47 I ASCII , bokstäverna PNG , så att en person enkelt kan identifiera formatet om det kan ses i en textredigerare.
0D 0A
1A En byte som stoppar visningen av filen under DOS när kommandot typ har använts-the end-of-file karaktär.
0A En linjeavslutning (LF) i Unix-stil för att upptäcka konvertering av linjeavslutning i Unix-DOS.

"Chunks" i filen

Efter rubriken kommer en serie bitar , som var och en förmedlar viss information om bilden. Bitar förklarar sig själva som kritiska eller kompletterande , och ett program som stöter på en extra bit som det inte förstår kan säkert ignorera det. Denna bit-baserade lagringsskiktstrukturen, liknande koncept som en container format eller till Amiga

'
s IFF , är utformad så att den PNG-format för att utvidgas samtidigt som kompatibiliteten med äldre versioner-det ger framåtkompatibilitet , och denna samma filstruktur ( med olika signaturer och bitar) används i tillhörande MNG- , JNG- och APNG -format.

En bit består av fyra delar: längd (4 byte, big-endian ), bittyp/namn (4 byte), bitdata (längdbyte) och CRC (cyklisk redundanskod/kontrollsumma; 4 byte). CRC är en nätverks-byte-order CRC-32 som beräknas över klumptypen och bitdata, men inte längden.

Längd Chunk -typ Chunk data CRC
4 bytes 4 bytes Längd byte 4 bytes

Chunk typer får en fyra bokstäver bokstäver ASCII typ / namn; jämför FourCC . Fallet med de olika bokstäverna i namnet (bit 5 i teckenets numeriska värde) är ett bitfält som ger avkodaren viss information om arten av bitar som den inte känner igen.

Fallet med den första bokstaven indikerar om delen är kritisk eller inte. Om den första bokstaven är versal är delen avgörande; om inte, är delen extra. Kritiska bitar innehåller information som är nödvändig för att läsa filen. Om en avkodare stöter på en kritisk del som den inte känner igen måste den avbryta läsningen av filen eller ge användaren en lämplig varning.

Fallet med den andra bokstaven indikerar om klumpen är "offentlig" (antingen i specifikationen eller registret för särskilda ändamål) eller "privata" (inte standardiserade). Versaler är offentliga och gemener är privata. Detta säkerställer att offentliga och privata bitnamn aldrig kan komma i konflikt med varandra (även om två privata bitnamn kan komma i konflikt).

Den tredje bokstaven måste vara stor för att överensstämma med PNG -specifikationen. Det är reserverat för framtida expansion. Avkodare bör behandla en bit med en liten tredje bokstav på samma sätt som alla andra okända bitar.

Fallet med den fjärde bokstaven indikerar om delen är säker att kopiera av redaktörer som inte känner igen den. Om det är små bokstäver kan bitarna kopieras säkert oavsett omfattningen av ändringar av filen. Om det är versaler kan det bara kopieras om ändringarna inte har berört några kritiska bitar.

Kritiska bitar

En avkodare måste kunna tolka kritiska bitar för att kunna läsa och återge en PNG -fil.

  • IHDRmåste vara den första delen; den innehåller (i denna ordning) bildens bredd (4 byte); höjd (4 byte); bitdjup (1 byte, värden 1, 2, 4, 8 eller 16); färgtyp (1 byte, värden 0, 2, 3, 4 eller 6); komprimeringsmetod (1 byte, värde 0); filtermetod (1 byte, värde 0); och sammanflätningsmetod (1 byte, värden 0 "ingen sammanflätning" eller 1 " Adam7 -sammanflätning ") (totalt 13 databyte). Som anges i World Wide Web Consortium definieras bitdjupet som "antalet bitar per prov eller per palettindex (inte per pixel)".
  • PLTEinnehåller paletten : en lista med färger.
  • IDATinnehåller bilden, som kan delas mellan flera IDAT -bitar. Sådan uppdelning ökar filstorleken något, men gör det möjligt att generera en PNG på ett strömmande sätt. IDAT -delen innehåller den faktiska bilddata, som är komprimeringsalgoritmens utflöde.
  • IENDmarkerar bildänden; datafältet för IEND -delen har 0 byte/är tomt.

Den PLTEbit är väsentligt för färgtyp 3 ( indexerad färg ). Det är valfritt för färgtyperna 2 och 6 (santfärg och santfärg med alfa) och det får inte visas för färgtyperna 0 och 4 (gråskala och gråskala med alfa).

Tilläggsbitar

Andra bildattribut som kan lagras i PNG -filer inkluderar gammavärden , bakgrundsfärg och textinformation om metadata . PNG stöder också färghantering genom införande av ICC färgrymdprofiler.

  • bKGDger standard bakgrundsfärg. Den är avsedd att användas när det inte finns något bättre val, till exempel i fristående bildvisare (men inte webbläsare; se nedan för mer information).
  • cHRMger kromatiska koordinaterna för bildskärmsprimär och vitpunkt .
  • dSIG är för lagring av digitala signaturer.
  • eXIflagrar Exif -metadata.
  • gAMAanger gamma . GAMA -delen innehåller endast 4 byte, och dess värde representerar gammavärdet multiplicerat med 100 000; till exempel beräknar gammavärdet 1/3.4 till 29411.7647059 ((1/3.4)*(100.000)) och konverteras till ett heltal (29412) för lagring.
  • hIST kan lagra histogrammet eller den totala mängden av varje färg i bilden.
  • iCCPär en ICC -färgprofil .
  • iTXtinnehåller ett nyckelord och UTF-8- text, med kodningar för möjlig komprimering och översättningar markerade med språktagg . Den Extensible Metadata Platform (XMP) använder denna bit med ett sökord 'XML: com.adobe.xmp'
  • pHYshåller den avsedda pixelstorleken (eller pixelformatet); pHYs innehåller "pixlar per enhet, X -axel" (4 byte), "pixlar per enhet, Y -axel" (4 byte) och "enhetsspecifikator" (1 byte) för totalt 9 byte.
  • sBIT(signifikanta bitar) anger färgnoggrannheten hos källdatan; denna bit innehåller totalt mellan 1 och 13 byte.
  • sPLT föreslår en palett att använda om hela färgutbudet inte är tillgängligt.
  • sRGBindikerar att standard sRGB -färgutrymme används; sRGB -delen innehåller endast 1 byte, som används för "rendering intention" (4 värden - 0, 1, 2 och 3 - är definierade för rendering avsikt).
  • sTERstereobildindikatorbit för stereoskopiska bilder.
  • tEXtkan lagra text som kan representeras i ISO/IEC 8859-1 , med ett nyckel-värdepar för varje bit. "Nyckeln" måste vara mellan 1 och 79 tecken lång. Separator är en null karaktär. "Värdet" kan vara vilken längd som helst, inklusive noll upp till den högsta tillåtna bitstorleken minus sökordets och separatorns längd. Varken "nyckel" eller "värde" kan innehålla nulltecken. Ledande eller bakre utrymmen är inte tillåtna.
  • tIME lagrar tiden då bilden senast ändrades.
  • tRNSinnehåller transparensinformation. För indexerade bilder lagrar det alfakanalvärden för en eller flera palettposter. För bilder i verkliga färger och gråskalor lagrar det ett enda pixelvärde som är att betrakta som helt transparent.
  • zTXtinnehåller komprimerad text (och en komprimeringsmetodmarkör) med samma gränser som tEXt.

Den första bokstaven i de små bitarna indikerar att de inte behövs för PNG -specifikationen. Den sista bokstaven med små bokstäver i vissa bitar indikerar att de är säkra att kopiera, även om den berörda applikationen inte förstår dem.

Pixelformat

PNG -färgtyp
Färgtyp Kanaler Bits per kanal
1 2 4 8 16
Indexerad 1 1 2 4 8
Gråskala 1 1 2 4 8 16
Gråskala och alfa 2 16 32
Truecolor 3 24 48
Truecolor och alfa 4 32 64

Pixlar i PNG -bilder är siffror som antingen kan vara index för provdata i paletten eller själva provdata. Paletten är ett separat bord i PLTE -delen. Provdata för en enda pixel består av en tupel mellan ett och fyra nummer. Oavsett om pixeldata representerar palettindex eller uttryckliga provvärden, kallas siffrorna för kanaler och varje nummer i bilden kodas med ett identiskt format.

De tillåtna formaten kodar varje nummer som ett osignerat heltal med ett fast antal bitar, som i PNG -specifikationen kallas bitdjupet . Lägg märke till att detta inte är detsamma som färgdjup , vilket vanligtvis används för att referera till det totala antalet bitar i varje pixel, inte varje kanal. De tillåtna bitdjupen sammanfattas i tabellen tillsammans med det totala antalet bitar som används för varje pixel.

Antalet kanaler beror på om bilden är gråskala eller färg och om den har en alfakanal . PNG tillåter följande kombinationer av kanaler, kallade färgtypen .

0 (000 2 ) gråskala
2 (010 2 ) rött, grönt och blått: rgb/truecolor
3 (011 2 ) indexerad: kanal som innehåller index till en färgpalett
4 (100 2 ) gråskala och alfa: opacitet för varje pixel
6 (110 2 ) rött, grönt, blått och alfa

Färgtypen anges som ett 8-bitars värde men endast de låga 3 bitarna används och även då är endast de fem kombinationerna som anges ovan tillåtna. Så länge färgtypen är giltig kan den betraktas som ett bitfält som sammanfattas i den intilliggande tabellen:

PNG -färgtyper
Färg
typ
namn Binär Masker
  A C P
0 Gråskala 0 0 0 0  
2 Truecolor 0 0 1 0 Färg
3 Indexerad 0 0 1 1 färgpalett
4 Gråskala och alfa 0 1 0 0 alfa
6 Truecolor och alfa 0 1 1 0 alfa, färg
  • bitvärde 1: bilddata lagrar palettindex. Detta gäller bara i kombination med bitvärde 2;
  • bitvärde 2: bildproverna innehåller tre kanaler med datakodning av trikromatiska färger , annars innehåller bildproven en kanal med datakodning av relativ luminans ,
  • bitvärde 4: bildproverna innehåller också en alfakanal uttryckt som ett linjärt mått på pixelns opacitet. Detta är inte giltigt i kombination med bitvärde 1.

Med indexerade färgbilder lagrar paletten alltid trikromatiska färger på ett djup av 8 bitar per kanal (24 bitar per palettpost). Dessutom kan en valfri lista med 8-bitars alfa-värden för palettposterna inkluderas; om den inte ingår, eller om den är kortare än paletten, antas de återstående palettposterna vara ogenomskinliga. Paletten får inte ha fler poster än bildbitens djup tillåter, men den kan ha färre (till exempel om en bild med 8-bitars pixlar bara använder 90 färger behöver den inte palettposter för alla 256 färger). Paletten måste innehålla poster för alla pixelvärden som finns i bilden.

Standarden tillåter indexerade färg -PNG: er att ha 1, 2, 4 eller 8 bitar per pixel; gråskala bilder utan alfakanal kan ha 1, 2, 4, 8 eller 16 bitar per pixel. Allt annat använder lite djup per kanal på antingen 8 eller 16. Kombinationerna detta tillåter ges i tabellen ovan. Standarden kräver att avkodare kan läsa alla färgformat som stöds, men många bildredigerare kan bara producera en liten delmängd av dem.

Transparens i bilden

PNG erbjuder en mängd olika transparensalternativ. Med bilder i äkta färger och gråskala kan antingen ett enda pixelvärde deklareras som transparent eller en alfakanal kan läggas till (vilket gör det möjligt att använda en procentandel av delvis genomskinlighet). För paletterade bilder kan alfavärden läggas till i palettposter. Antalet sådana värden som lagras kan vara mindre än det totala antalet palettposter, i vilket fall de återstående posterna anses vara helt ogenomskinliga.

Skanning av pixelvärden för binär transparens är tänkt att utföras innan någon färgreducering sker för att undvika att pixlar blir oavsiktligt transparenta. Detta är troligtvis ett problem för system som kan avkoda 16-bitars-per-kanal-bilder (som krävs för att uppfylla specifikationen) men bara mata ut med 8 bitar per kanal (normen för alla utom de högsta ändsystemen) .

Alfa lagring kan "associerad" ( " förmultipliceras ') eller 'oassocierade', men PNG standardiserat på 'oassocierade'(' icke-förmultipliceras") alfa, vilket innebär att bildspråk inte är alfa kodade ; de utsläpp som representeras i RGB är inte utsläppen på pixelnivån. Detta innebär att överoperationen kommer att multiplicera RGB -utsläppen med alfa, och kan inte representera utsläpp och ocklusion korrekt.

Kompression

Exempel med flera typer av bildinnehåll
Representation av bitkostnad per pixel för ovanstående PNG -fil (röd = dyr, blå = billig)

PNG använder en tvåstegskomprimeringsprocess:

  • förkomprimering: filtrering (förutsägelse)
  • komprimering: DEFLATE

PNG använder DEFLATE , en icke patenterad förlustfri datakomprimering algoritm som involverar en kombination av LZ77 och Huffmankodning . Tillståndslicensierade DEFLATE-implementeringar, till exempel zlib , är allmänt tillgängliga.

Jämfört med format med förlorad komprimering som JPG , väljer du en komprimeringsinställning som är högre än genomsnittet fördröjer bearbetningen, men resulterar ofta inte i en betydligt mindre filstorlek.

Filtrering

PNG: s filtermetod 0 kan använda data i pixlarna A, B och C för att förutsäga värdet för X.
En PNG med 256 färger, som bara är 251 byte stor med förfilter. Samma bild som en GIF skulle vara mer än tretton gånger större.
för att transformera data för att göra den mer effektivt komprimerbar. Filtertypen som används för en skanningslinje är förberedd till skanningslinjen för att möjliggöra inkomprimering.

Det finns bara en filtermetod i den nuvarande PNG -specifikationen (betecknad metod 0), och i praktiken är det enda valet vilken filtertyp som ska tillämpas på varje rad. För denna metod förutsäger filtret värdet för varje pixel baserat på värdena för tidigare angränsande pixlar och subtraherar pixelns förutsagda färg från det verkliga värdet, som i DPCM . En bildrad som filtreras på detta sätt är ofta mer komprimerbar än vad den råa bildlinjen skulle vara, särskilt om den liknar raden ovan, eftersom skillnaderna från förutsägelse generellt kommer att samlas kring 0, snarare än att spridas över alla möjliga bildvärden. Detta är särskilt viktigt för att relatera separata rader, eftersom DEFLATE inte har någon förståelse för att en bild är en 2D -enhet, och istället bara ser bilddata som en ström av byte.

Det finns fem filtertyper för filtermetod 0; varje typ förutspår värdet för varje byte (av bilddata före filtrering) baserat på motsvarande byte för pixeln till vänster ( A ), pixeln ovan ( B ) och pixeln ovanför och till vänster ( C ) eller någon kombination därav och kodar skillnaden mellan det förutsagda värdet och det verkliga värdet. Filter tillämpas på bytevärden, inte pixlar; pixelvärden kan vara en eller två byte, eller flera värden per byte, men aldrig korsa bytegränser. Filtertyperna är:

Skriv byte Filternamn Förutsett värde
0 Ingen Noll (så att råbytevärdet passerar genom oförändrat)
1 Sub Byte A (till vänster)
2 Upp Byte B (ovan)
3 Genomsnitt Medelvärde för byte A och B , avrundat nedåt
4 Paeth A , B eller C , vilket som är närmast
p = A + B - C

Paeth -filtret är baserat på en algoritm av Alan W. Paeth . Jämför med versionen av DPCM som används i förlustfri JPEG och med den diskreta wavelet -transformen med 1 × 2, 2 × 1 eller (för Paeth -förutsägaren) 2 × 2 fönster och Haar -vågor .

Komprimeringen förbättras ytterligare genom att välja filtertyper anpassat rad för rad. Denna förbättring, och en heuristisk metod för att implementera den som vanligtvis används av PNG-skrivande programvara, skapades av Lee Daniel Crocker , som testade metoderna på många bilder under skapandet av formatet; valet av filter är en komponent i filstorleksoptimering, som diskuteras nedan.

Om interlacing används filtreras varje steg i interlacing separat, vilket innebär att bilden gradvis kan återges när varje steg tas emot; emellertid gör sammanflätning i allmänhet komprimering mindre effektiv.

Interlacing

En illustration av Adam7 sammanflätning över en 16 × 16 bild.

PNG erbjuder ett valfritt 2-dimensionellt, 7-pass interlacing- schema- Adam7-algoritmen . Detta är mer sofistikerat än GIF: s 1-dimensionella, 4-pass-schema, och tillåter en tydligare lågupplöst bild att synas tidigare i överföringen, särskilt om interpoleringsalgoritmer som bikubisk interpolering används.

Emellertid tenderar 7-pass-schemat att minska dataens komprimerbarhet mer än enklare scheman.

Animering

En APNG -fil (animerad PNG) (visas som statisk bild i vissa webbläsare )

PNG i sig stöder inte animering. MNG är en förlängning till PNG som gör; den designades av medlemmar i PNG -gruppen. MNG delar PNG: s grundläggande struktur och bitar, men det är betydligt mer komplext och har en annan filsignatur, vilket automatiskt gör det inkompatibelt med vanliga PNG -avkodare, vilket ledde till att MNG nästan inte hade något stöd eller stöd tappat av de flesta webbläsare eller applikationer.

Komplexiteten i MNG ledde till förslaget om APNG av utvecklare av Mozilla Foundation. Den är baserad på PNG, stöder animering och är enklare än MNG. APNG erbjuder återställning till enbildsvisning för PNG-avkodare som inte stöder APNG. Idag stöds APNG -format för närvarande i stor utsträckning av alla större webbläsare. APNG stöds i Firefox 3.0 och senare, Pale Moon (alla versioner) och den senaste versionen av Opera stöder APNG sedan motorn ändrades till Blink. Den senaste versionen av SafariiOS 8 och Safari 8 för OS X Yosemite , de använder WebKit -motor som stöder APNG. Chromium 59.0 har lagt till APNG -stöd och det följdes av Google Chrome. Microsoft Edge stöder nu APNG med den nya krombaserade motorn.

PNG -gruppen beslutade i april 2007 att inte omfamna APNG. Flera alternativ diskuterades, ANG, aNIM/mPNG, "PNG i GIF" och dess delmängd "RGBA i GIF". Men bara APNG har för närvarande stöd av alla större webbläsare.

Exempel

Struktur för en mycket enkel PNG -fil
89 50 4E 47 0D 0A 1A 0A
PNG -signatur
IHDR
Bildrubrik
IDAT
Bilddata
IEND
Bildens slut

89 50 4E 47 0D 0A 1A 0A
00 00 00 0D 49 48 44 52

00 00 01 00 00 00 01 08 02 00 00 00 90 77 53

DE
00 00 00 0C 49 44 41 54 08 D7 63 F8 CF C0 00

00 03 01 01 00 18 DD 8D B0
00 00 00 00 49 45 4E

44 AE 42 60 82

.PNG ....
.... IHDR

.............. wS

.
.... IDAT..c ....

.........
.... IEN

D.B`.

Innehåll i en minimal PNG -fil som representerar en röd pixel
Hex Som karaktärer
IHDR Chunk
Offset i bit Hexvärde Decimalvärde Text Menande
0 0x0D 13 IHDR -bit har 13 byte innehåll
4 0x49484452 IHDR Identifierar en rubrikbit
8 0x01 1 Bilden är 1 pixel bred
12 0x01 1 Bilden är 1 pixel hög
16 0x08 8 8 bitar per pixel (per kanal)
17 0x02 2 Färg typ 2 (RGB/truecolor)
18 0x00 0 Komprimeringsmetod 0 (endast accepterat värde)
19 0x00 0 Filtermetod 0 (endast accepterat värde)
20 0x00 0 Inte sammanflätad
21 0x907753DE CRC av bitens typ och innehåll (men inte längd)
IDAT Chunk
Offset i bit Hexvärde Menande
0 0x0C IDAT -delen har 12 byte innehåll
4 0x49444154 Identifierar en Databit
8 0x08 DEFLATE komprimeringsmetod med ett 256-byte fönster
9 0xD7 ZLIB FCHECK -värde, ingen ordlista används, maximal komprimeringsalgoritm
10 0x63F8CFC00000 Ett komprimerat DEFLATE -block med den statiska Huffman -koden som avkodas till 0x00 0xFF 0x00 0x00
16 0x03010100 ZLIB -kontrollvärdet: Adler32 -kontrollsumman för okomprimerade data
20 0x18DD8DB0 CRC av bitens typ och innehåll (men inte längd)

Visas som hexredigerare , med bytevärden på vänster sida i hexformat och på höger sida motsvarande tecken från ISO-8859-1 med okända och kontrolltecken ersatta med punkter. Dessutom är PNG -signaturen och enskilda bitar markerade med färger. Observera att de är lätta att identifiera på grund av deras mänskliga läsbara typnamn (i detta exempel PNG, IHDR, IDAT och IEND).

Fördelar

Anledningar till att använda denna internationella standard kan vara:

  • Bärbarhet : Överföring är oberoende av mjukvaru- och hårdvaruplattformen.
  • Fullständighet : det är möjligt att representera sanna färger, indexfärger och gråskala bilder.
  • Kodning och avkodning i serie : gör det möjligt att generera och läsa dataströmmar i serie, det vill säga formatet på dataströmmen används för att generera och visualisera bilder för tillfället genom seriell kommunikation.
  • Progressiv presentation : att kunna överföra dataflöden som initialt är en approximation av hela bilden och gradvis förbättras när dataflödet tas emot.
  • Säkerhet för överföringsfel : upptäcker överföringsfelen i dataströmmen korrekt.
  • Förlustlöshet : Ingen förlust: filtrering och komprimering bevarar all information.
  • Effektivitet : varje progressiv bildpresentation, komprimering och filtrering söker effektiv avkodning och presentation.
  • Komprimering : bilder kan komprimeras effektivt och konsekvent.
  • Enkelhet : implementeringen av standarden är enkel.
  • Utbytbarhet : alla PNG -avkodare som följer standarderna kan läsa alla PNG -dataströmmar.
  • Flexibilitet : tillåter framtida tillägg och privata tillägg utan att påverka föregående punkt.
  • Rättsliga begränsningar : de algoritmer som används är gratis och tillgängliga.

Jämförelse med andra filformat

Graphics Interchange Format (GIF)

  • På små bilder kan GIF uppnå större komprimering än PNG (se avsnittet om filstorlek nedan).
  • På de flesta bilder, förutom fallet ovan, har en GIF -fil en större storlek än en indexerad PNG -bild.
  • PNG ger ett mycket bredare utbud av transparens alternativ än GIF, inklusive alfakanal transparens.
  • Medan GIF är begränsat till 8-bitars indexerad färg , ger PNG ett mycket bredare färgdjup, inklusive 24-bitars (8 bitar per kanal) och 48-bitars (16 bitar per kanal) truecolor , vilket möjliggör större färgprecision, jämnare bleknar etc. När en alfakanal läggs till är upp till 64 bitar per pixel (före komprimering) möjliga.
  • Vid konvertering av en bild från PNG -formatet till GIF kan bildkvaliteten drabbas av posterisering om PNG -bilden har mer än 256 färger.
  • GIF har stöd för animerade bilder. PNG stöder animering endast via inofficiella tillägg (se avsnittet om animering ovan).

PNG -bilder stöds i mindre utsträckning av äldre webbläsare. I synnerhet har IE6 begränsat stöd för PNG.

JPEG

Kompositbild som jämför komprimerad förlust i JPEG med förlustfri komprimering i PNG: JPEG -artefakterna kan lätt synas i bakgrunden av denna typ av bilddata, där PNG -bilden har enfärgad färg.

Den JPEG -format (Joint Photographic Experts Group) kan producera en mindre fil än PNG för fotografisk (och foto-liknande) bilder, eftersom JPEG använder en förstörande kodningsmetod särskilt utformade för fotografiska bilddata, som typiskt domineras av mjuka, låg kontrast övergångar och en mängd buller eller liknande oregelbundna strukturer. Att använda PNG istället för en högkvalitativ JPEG för sådana bilder skulle resultera i en stor ökning av filstorlek med försumbar kvalitetsökning. Som jämförelse kan PNG -formatet komprimera bilddata mer än JPEG när du lagrar bilder som innehåller text, linjekonst eller grafik - bilder med skarpa övergångar och stora områden med enfärgad färg. Dessutom är PNG förlustfri, medan JPEG producerar visuella artefakter runt områden med hög kontrast. (Sådana artefakter beror på inställningarna som används i JPG-komprimeringen; de kan vara ganska märkbara när en inställning av hög kvalitet [högkomprimering] används.) Om en bild innehåller både skarpa övergångar och fotografiska delar måste man välja mellan de två effekterna. JPEG stöder inte transparens.

JPEGs förlustkomprimering lider också av generationsförlust , där upprepade gånger avkodning och omkodning av en bild för att spara den igen orsakar förlust av information varje gång, vilket försämrar bilden. Eftersom PNG är förlustfri är den lämplig för lagring av bilder som ska redigeras. Även om PNG är någorlunda effektivt vid komprimering av fotografiska bilder, finns det förlustfria komprimeringsformat utformade speciellt för fotografiska bilder, förlustfri WebP och Adobe DNG (digital negativ) till exempel. Men dessa format stöds antingen inte allmänt eller är proprietära. En bild kan lagras förlustfritt och konverteras till JPEG -format endast för distribution, så att det inte sker någon generationsförlust.

Även om PNG-specifikationen inte uttryckligen innehåller en standard för inbäddning av Exif- bilddata från källor som digitalkameror, är den föredragna metoden för att bädda in EXIF-data i en PNG att använda den icke-kritiska tilläggsstyckeetiketten eXIf.

Tidiga webbläsare stödde inte PNG -bilder; JPEG och GIF var de viktigaste bildformaten. JPEG användes vanligtvis vid export av bilder som innehåller lutningar för webbsidor, på grund av GIF: s begränsade färgdjup. JPEG -komprimering gör dock att en gradient suddas något. Ett PNG -format återger en gradient så exakt som möjligt för ett givet bitdjup, samtidigt som filstorleken hålls liten. PNG blev det optimala valet för små lutningsbilder eftersom webbläsarstöd för formatet förbättrades. Inga bilder behövs alls för att visa lutningar i moderna webbläsare, eftersom lutningar kan skapas med hjälp av CSS .

JPEG-LS

JPEG-LS är ett bildformat av Joint Photographic Experts Group , även om det är mycket mindre allmänt känt och stödt än det andra förlustfria JPEG-format som diskuterats ovan. Den är direkt jämförbar med PNG och har en standard uppsättning testbilder. På Waterloo Repertoire ColorSet, en standarduppsättning testbilder (utan samband med JPEG-LS-överensstämmelsestestet), fungerar JPEG-LS i allmänhet bättre än PNG, med 10–15%, men på vissa bilder fungerar PNG betydligt bättre, på ordning på 50–75%. Om båda dessa format är alternativ och filstorlek är ett viktigt kriterium, bör de därför övervägas, beroende på bilden.

TIFF

Tagged Image File Format (TIFF) är ett format som innehåller ett extremt brett utbud av alternativ. Även om detta gör TIFF användbart som ett generiskt format för utbyte mellan professionella bildredigeringsprogram, gör det att lägga till stöd för det till applikationer till en mycket större uppgift och därför har det lite stöd i applikationer som inte rör bildmanipulation (t.ex. webbläsare). Den höga utökningsgraden innebär också att de flesta applikationer endast tillhandahåller en delmängd av möjliga funktioner, vilket potentiellt kan skapa användarförvirring och kompatibilitetsproblem.

Den vanligaste generella, förlustfria komprimeringsalgoritmen som används med TIFF är Lempel – Ziv – Welch (LZW). Denna komprimeringsteknik, som också används i GIF, omfattades av patent fram till 2003. TIFF stöder också komprimeringsalgoritmen som PNG använder (dvs. Compression Tag 0008 16 ' Adobe -style') med medelhög användning och stöd av applikationer. TIFF erbjuder också komprimeringsalgoritmer för speciella ändamål som CCITT Group IV , som kan komprimera bilevel-bilder (t.ex. fax eller svartvit text) bättre än PNG: s komprimeringsalgoritm.

PNG stöder endast icke-fördubblat alfa medan TIFF också stöder "associerad" (förmultiplicerad) alfa.

Programvarusupport

Den officiella referensimplementeringen av PNG -formatet är programmeringsbiblioteket libpng . Den publiceras som gratis programvara under villkoren i en tillåtande licens för fri programvara . Därför finns det vanligtvis som ett viktigt systembibliotek i gratis operativsystem.

Bitmap -grafikredigerare stöd för PNG

PNG-formatet är ett brett stöd av grafikprogram, inklusive Adobe Photoshop , Corel 's Photo-Paint och Paint Shop Pro , den GIMP , Graphic , Helicon Filter , ImageMagick , Inkscape , Irfanview , Pixel bildredigerare, Paint.NET och Xara Photo & Grafisk formgivare och många andra. Vissa program levereras med populära operativsystem som stödjer PNG inkluderar Microsofts 's Paint och Apple ' s foton / iPhoto och förhandsgranskning , med GIMP också ofta som levereras med populära Linux- distributioner.

Adobe Fireworks (tidigare Macromedia ) använder PNG som sitt ursprungliga filformat, så att andra bildredigerare och förhandsgranskningsverktyg kan se den platta bilden. Fireworks lagrar dock som standard också metadata för lager, animering, vektordata, text och effekter. Sådana filer ska inte distribueras direkt. Fyrverkerier kan istället exportera bilden som en optimerad PNG utan extra metadata för användning på webbsidor etc.

Webbläsarstöd för PNG

PNG-stöd visades först 1997, i Internet Explorer 4.0b1 (32-bitars endast för NT) och i Netscape 4.04.

Trots samtal från Free Software Foundation och World Wide Web Consortium (W3C), verktyg som gif2png och kampanjer som Burn All GIF, gick PNG -antagandet på webbplatser ganska långsamt på grund av sent och buggigt stöd i Internet Explorer, särskilt när det gäller transparens .

PNG -kompatibla webbläsare inkluderar: Apple Safari , Google Chrome , Mozilla Firefox , Opera , Camino , Internet Explorer 7 (fortfarande många problem), Internet Explorer 8 (fortfarande några problem), Internet Explorer 9 och många andra. För fullständig jämförelse, se Jämförelse av webbläsare (stöd för bildformat) .

Speciellt versioner av Internet Explorer (Windows) under 9.0 (släppt 2011) har många problem som hindrar den från att korrekt återge PNG -bilder.

  • 4.0 kraschar på stora PNG -bitar.
  • 4.0 inkluderar inte funktionaliteten för att visa .png -filer, men det finns en registerkorrigering.
  • 5.0 och 5.01 har brutit OBJECT -stöd.
  • 5.01 skriver ut palettbilder med svart (eller mörkgrå) bakgrund under Windows 98, ibland med radikalt förändrade färger.
  • 6.0 visar inte PNG -bilder på 4097 eller 4098 byte.
  • 6.0 kan inte öppna en PNG-fil som innehåller en eller flera IDAT-bitar med nollängd. Det här problemet åtgärdades först i säkerhetsuppdatering 947864 (MS08-024). Mer information finns i den här artikeln i Microsoft Knowledge Base: 947864 MS08-024: Kumulativ säkerhetsuppdatering för Internet Explorer.
  • 6.0 förlorar ibland helt möjligheten att visa PNG, men det finns olika korrigeringar.
  • 6.0 och nedan har brutet stöd för alfakanals transparens (visar istället standardbakgrundsfärgen).
  • 7.0 och nedan kan inte kombinera 8-bitars alfatransparens OCH elementets opacitet ( CSS- filter: Alpha (opacitet = xx)) utan att fylla delvis transparenta sektioner med svart.
  • 8.0 och senare har inkonsekvent/trasigt gamastöd.
  • 8.0 och senare har inte stöd för färgkorrigering.

Operativsystemstöd för PNG -ikoner

PNG -ikoner har stöds i de flesta distributioner av Linux sedan minst 1999, i skrivbordsmiljöer som GNOME . 2006 introducerades Microsoft Windows -stöd för PNG -ikoner i Windows Vista . PNG -ikoner stöds också i AmigaOS 4 , AROS , macOS , iOS och MorphOS . Dessutom använder Android omfattande PNG -filer.

Filstorlek och optimeringsprogram

PNG -filstorleken kan variera avsevärt beroende på hur den kodas och komprimeras; detta diskuteras och ett antal tips ges i PNG: The Definitive Guide.

Jämfört med GIF

Jämfört med GIF -filer är en PNG -fil med samma information (256 färger, inga bitar/metadata), komprimerad av en effektiv kompressor normalt mindre än en GIF -bild. Beroende på filen och kompressorn kan PNG variera från något mindre (10%) till betydligt mindre (50%) till något större (5%), men är sällan betydligt större för stora bilder. Detta tillskrivs prestanda för PNG: s DEFLATE jämfört med GIF: s LZW , och eftersom det extra förkomprimeringsskiktet i PNG: s prediktiva filter tar hänsyn till den 2-dimensionella bildstrukturen för att ytterligare komprimera filer; eftersom filtrerade data kodar för skillnader mellan pixlar, tenderar de att samlas närmare 0, snarare än att spridas över alla möjliga värden, och därmed lättare komprimeras av DEFLATE. Vissa versioner av Adobe Photoshop , CorelDRAW och MS Paint ger dock dålig PNG -komprimering, vilket skapar intrycket av att GIF är mer effektivt.

Filstorleksfaktorer

PNG -filer varierar i storlek på grund av ett antal faktorer:

färgdjup
Färgdjupet kan variera från 1 till 64 bitar per pixel.
tilläggsbitar
PNG stöder metadata - detta kan vara användbart för redigering, men onödigt för visning, som på webbplatser.
sammanflätning
Eftersom varje pass i Adam7 -algoritmen filtreras separat kan detta öka filstorleken.
filtrera
Som ett förkomprimeringssteg filtreras varje rad av ett prediktivt filter, som kan ändras från rad till rad. Eftersom det ultimata DEFLATE-steget fungerar på hela bildens filtrerade data kan man inte optimera denna rad för rad; valet av filter för varje rad är således potentiellt mycket varierande, även om det finns heuristik.
kompression
Med ytterligare beräkning kan DEFLATE -kompressorer producera mindre filer.

Det finns alltså en filstorleksavvägning mellan högt färgdjup, maximala metadata (inklusive information om färgutrymme, tillsammans med information som inte påverkar displayen), sammanflätning och komprimeringshastighet, som alla ger stora filer, med lägre färgdjup, färre eller inga kompletterande bitar, ingen sammanflätning, och avstämda men beräkningsmässigt intensiva filtrering och komprimering. För olika ändamål väljs olika avvägningar: en maximal fil kan vara bäst för arkivering och redigering, medan en avskalad fil kan vara bäst för användning på en webbplats, och på samma sätt föredras snabb men dålig komprimering vid upprepade gånger redigering och sparande av en fil, medan långsam men hög komprimering föredras när en fil är stabil: vid arkivering eller publicering. Interlacing är en avvägning: det påskyndar dramatiskt tidig återgivning av stora filer (förbättrar latens), men kan öka filstorleken (minska genomströmningen) för liten vinst, särskilt för små filer.

Förlorad PNG -komprimering

Även om PNG är ett förlustfritt format kan PNG -kodare förbehandla bilddata på ett förlorande sätt för att förbättra PNG -komprimering. Till exempel kan kvantifiera en sant färg PNG till 256 färger att den indexerade färgtypen kan användas för en sannolik minskning av filstorlek.

Bildredigeringsprogram

Vissa program är mer effektiva än andra när de sparar PNG -filer, detta avser implementering av PNG -komprimering som används av programmet.

Många grafikprogram (till exempel Apples Preview programvara) Spara PNG med stora mängder metadata och färgkorrektionsdata som är allmänt onödigt för Web visning. Ooptimerade PNG -filer från Adobe Fireworks är också ökända för detta eftersom de innehåller alternativ för att göra bilden redigerbar i redigerare som stöds. Också CorelDRAW (åtminstone version 11) producerar ibland PNG -filer som inte kan öppnas av Internet Explorer (version 6–8).

Adobe Photoshop prestanda på PNG -filer har förbättrats i CS Suite när du använder Save For Web -funktionen (som också tillåter explicit PNG/8 -användning).

Adobes Fireworks sparar som standard större PNG -filer än många program. Detta härrör från mekaniken i dess Spara -format: bilderna som produceras av Fireworks sparfunktion inkluderar stora, privata bitar som innehåller fullständig lager- och vektorinformation. Detta möjliggör ytterligare förlustfri redigering. När de sparas med alternativet Export är Fireworks PNG -filer konkurrenskraftiga med de som produceras av andra bildredigerare, men kan inte längre redigeras som något annat än platta bitmappar. Fyrverkerier kan inte spara storleksoptimerade vektorredigerbara PNG-filer.

Andra anmärkningsvärda exempel på dåliga PNG -kompressorer inkluderar:

  • Microsofts Paint för Windows XP
  • Microsoft Picture It! Photo Premium 9

Dålig komprimering ökar PNG -filstorleken men påverkar inte bildkvaliteten eller filens kompatibilitet med andra program.

När färgdjupet för en santfärgad bild reduceras till en 8-bitars palett (som i GIF) är den resulterande bilddatan vanligtvis mycket mindre. Således är en färgfärgad PNG vanligtvis större än en färgreducerad GIF, även om PNG kan lagra den färgreducerade versionen som en palettiserad fil med jämförbar storlek. Vissa verktyg, när du sparar bilder som PNG-filer, sparar dem automatiskt som riktiga färger, även om originaldata bara använder 8-bitars färg, vilket gör att filen blir onödig. Båda faktorerna kan leda till missuppfattningen att PNG -filer är större än motsvarande GIF -filer.

Optimera verktyg

Olika verktyg finns tillgängliga för att optimera PNG -filer; de gör detta genom att:

  • (valfritt) ta bort tilläggsbitar,
  • minska färgdjup, antingen:
    • använd en palett (istället för RGB) om bilden har 256 färger eller färre,
    • använd en mindre palett om bilden har 2, 4 eller 16 färger, eller
    • (valfritt) förlora förlorat några av data i originalbilden,
  • optimera rad-för-rad filterval, och
  • optimera DEFLATE -komprimering.

Verktygslista

  • pngcrush är den äldsta av de populära PNG -optimerarna. Det möjliggör flera försök med filterval och komprimeringsargument och väljer slutligen det minsta. Denna arbetsmodell används i nästan alla png -optimerare.
  • OptiPNG inspirerades av pngcrush, men iterates över ett större antal komprimeringsparametrar och utför tester i minnet för snabbare körning. Det huvudsakliga syftet med optipng är att minska storleken på PNG IDAT dataströmmen genom att försöka olika filtrerings- och komprimeringsförfaranden. Det utför också automatiskt bitdjup, färgtyp och färgpalettreducering där det är möjligt och kan korrigera vissa dataintegritetsfel i inmatningsfiler. (pngcrush har möjlighet att göra färgreducering i en senare version.)
  • advpng och liknande advdef -verktyg i AdvanceCOMP -paketet komprimerar om PNG IDAT. Olika Deflate implementeringar tillämpas beroende på den valda komprimeringsnivå, handel mellan hastighet och filstorlek: zlib på nivå 1, libdeflate på nivå 2, 7-zip 's LZMA DEFLATE på nivå 3, och zopfli på nivå 4.
  • pngout gjordes med författarens egen tömning (samma som författarens zip -verktyg, kzip), samtidigt som alla funktioner för färgreduktion / filtrering behölls. Men pngout tillåter inte att använda flera tester på filter i en enda körning. Det föreslås att man använder sin kommersiella GUI -version, pngoutwin, eller används med en omslag för att automatisera försöken eller för att komprimera om med sin egen tömning medan filtret behålls rad för rad.
  • zopflipng gjordes också med en egen-egen deflater, zopfli. Den har alla optimeringsfunktioner som optipng och pngcrush har (inklusive automatiserade försök) samtidigt som den ger en mycket bra, men långsam tömning.

En enkel jämförelse av deras funktioner listas nedan.

Optimizer Borttagning av bitar Färgreducering Filtrering Återanvänd filter Flera tester på filter i en enda körning Deflater
advpng Ja Nej 0 Nej Ej tillgängligt (flera olika)
advdef Nej Nej Återanvänder tidigare filteruppsättning Alltid Ej tillgängligt (flera olika)
OptiPNG Ja Ja 0–4 eller adaptiv Nej Ja zlib
pngcrush Ja Ja 0–4 eller adaptiv Nej Ja zlib
pngout Ja Ja 0–4 eller adaptiv Ja Nej kzip
zopflipng Ja Ja 0–4 eller adaptiv med 2 olika algoritmer, eller med ett brutalt sätt Ja Ja zopfli

Innan zopflipng var tillgängligt är ett bra sätt i praktiken att utföra en png -optimering att använda en kombination av 2 verktyg i följd för optimal komprimering: ett som optimerar filter (och tar bort tilläggsbitar) och ett som optimerar DEFLATE. Även om pngout erbjuder båda, kan endast en typ av filter specificeras i en enda körning, därför kan det användas med ett omslagsverktyg eller i kombination med optipng eller pngcrush , som fungerar som en återdeflaterare, som advdef.

Tilläggsborttagning

För att ta bort extra bitar har de flesta PNG -optimeringsverktyg möjligheten att ta bort alla färgkorrigeringsdata från PNG -filer (gamma, vitbalans, ICC -färgprofil, standard RGB -färgprofil). Detta resulterar ofta i mycket mindre filstorlekar. Till exempel uppnår följande kommandoradsalternativ detta med pngcrush:

pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB InputFile.png OutputFile.png

.

Filteroptimering

OptiPNG, pngcrush, pngout och zopflipng erbjuder alla alternativ som tillämpar en av filtertyperna 0–4 globalt (med samma filtertyp för alla rader) eller med ett "pseudofilter" (numrerat 5), som för varje rad väljer en av filtertypen 0–4 med hjälp av en adaptiv algoritm. Zopflipng erbjuder 3 olika adaptiva metoder, inklusive en brute-force-sökning som försöker optimera filtreringen.

pngout och zopflipng ger ett alternativ för att bevara/återanvända den rad-för-rad-filteruppsättning som finns i inmatningsbilden.

OptiPNG, pngcrush och zopflipng ger alternativ för att prova olika filterstrategier i en enda körning och välja det bästa. Freeware -kommandoradsversionen av pngout erbjuder inte detta, men den kommersiella versionen, pngoutwin, gör det.

DEFLATE -optimering

zopfli och LZMA SDK använder DEFLATE -implementeringar som ger högre kompressionsförhållanden än zlib -referensimplementeringen till priset av prestanda. AdvanceCOMP : s advpngoch advdefkan använda någon av dessa bibliotek för att åter komprimera PNG-filer. Dessutom PNGOUT innehåller sin egen proprietära genomförande DEFLATE.

advpnghar inte möjlighet att använda filter och använder alltid filter 0 globalt (lämnar bilddata ofiltrerat); Därför ska den inte användas där bilden tjänar avsevärt på filtrering. Däremot advdefhandlar det från samma paket inte om PNG-struktur och fungerar bara som en återdeflaterare och behåller eventuella befintliga filterinställningar.

Ikonoptimering

Eftersom ikoner avsedda för Windows Vista och senare versioner kan innehålla PNG -delbilder kan optimeringarna också tillämpas på dem. Åtminstone en ikon editor , Pixelformer , kan utföra en speciell optimering pass samtidigt som du sparar ICO -filer, vilket minskar deras storlek. FileOptimizer (nämns ovan) kan också hantera ICO -filer.

Ikoner för macOS kan också innehålla PNG -delbilder, men det finns inget sådant verktyg.

Se även

Anteckningar

Referenser

Vidare läsning