Notater fra teamet om håndverket, formater og de små valgene bak et godt resultat.
Den tapsfrie beholderen, hva PNG lagrer
PNG bruker den tapsfrie DEFLATE-algoritmen. Den lagrer hver piksels RGBA-verdier nøyaktig slik de er gitt, bruker et reversibelt filter på hver bildelinje, og komprimerer resultatet med en zlib-variant. Tapsfritt betyr at de dekomprimerte pikselverdiene er byte-identiske med originalene. For JPG-til-PNG-tilfellet er originalene pikslene som oppstår når nettleseren dekoder JPEG-en. De dekodede pikslene gjenspeiler alt allerede alle tilnærmingene JPEG gjorde under sin opprinnelige koding, så PNG lagrer trofast de tilnærmede pikslene, ikke den virkelige scenen. Målt blir en JPEG på ved 1024x768 til rundt som PNG, og en JPEG på ved 3840x2160 vokser til omtrent . Disse forholdene holder seg omtrent på tvers av innholdstyper, for forholdet følger oppløsning, ikke JPEG-kvalitetsnivå. Den tapsfrie beholderen er verdifull for det den hindrer, videre forringelse, ikke for det den gjenoppretter.
Hvorfor JPEG-kvalitet ikke kan hentes tilbake
JPEG-komprimering forkaster informasjon for godt. Kodingen bruker en diskret cosinustransform på blokker på 8x8 piksler, kvantiserer de resulterende frekvenskoeffisientene ned til et mindre sett, og lagrer de kvantiserte verdiene. Kvantiseringssteget går bare én vei, siden en koeffisient som var 47 og ble rundet til 50 ikke kan føres tilbake til 47 senere, og ingen oppføring av den opprinnelige verdien overlever i filen. Når nettleseren dekoder JPEG-en, bygger den piksler på nytt fra de kvantiserte koeffisientene, som er tilnærminger av de opprinnelige verdiene. Å kode disse tilnærmede pikslene på nytt som PNG gir et tapsfritt opptak av tilnærmingene, så PNG-en er en perfekt gjengivelse av det forringede bildet. Dette er ikke en begrensning ved PNG eller ved dette verktøyet, det er en grunnleggende egenskap ved tapsbasert komprimering, der informasjon forkastet ved koding er borte. Å forbedre JPEG-kvalitet krever at man starter fra den ukomprimerte originalen eller RAW-filen.
Målt vekst i filstørrelse
Størrelsesforholdet fra JPG til PNG varierer med bildeinnhold, men følger et forutsigbart mønster. Fotografier med kompleks tonal variasjon vokser mest, for JPEGs transform er finstilt for nettopp slikt innhold og oppnår høye komprimeringsforhold, mens PNGs tapsfrie komprimering ikke kan matche dem på støyende pikseldata. Testmålinger fra dette verktøyet viser et JPEG-foto på ved 1024x768 som gir en PNG på , rundt 6 gangers vekst, og et JPEG-foto på ved 3840x2160 som gir en PNG på , rundt 3,3 gangers vekst. For flate bilder som skjermbilder og ikoner passer JPEG dårlig til innholdet fra før, og filene har gjerne mer vekt for tilsvarende kvalitet, så PNG-en av samme innhold vokser mindre dramatisk. Den praktiske følgen er klar, betyr filstørrelsen på resultatet noe for ditt bruk, gjør det å gjøre om en JPG til PNG situasjonen verre, ikke bedre.
Gjennomsiktighet, muligheten kontra innholdet
PNG støtter en 8-bits alfakanal som en beholderfunksjon, der en fil kan inneholde gjennomsiktighetsverdier per piksel fra 0 (helt gjennomsiktig) til 255 (helt ugjennomsiktig). Når en JPG gjøres om til PNG ved omkoding gjennom den innebygde bildemotoren, settes den resulterende PNG-en til helt ugjennomsiktig, med hver piksel på en alfaverdi på 255, for kilde-JPG-en hadde ingen gjennomsiktighetsinformasjon i utgangspunktet. PNG-formatet er klart til å holde gjennomsiktighetsdata, filen inneholder bare ingen, for ingen var til stede i kilden. Å legge til gjennomsiktighet i bildet krever egen behandling, enten å maskere bakgrunnen i et redigeringsprogram eller å bruke et automatisk bakgrunnsfjerningssteg. En bakgrunnsfjerner som er trent til å kjenne igjen motivet kan gi en PNG med ekte alfa ved å nulle ut alfaverdiene på bakgrunnspikslene etter omformingen.
Håndtering av EXIF-metadata
Omkodingen stripper EXIF-, IPTC- og XMP-metadata fra PNG-resultatet i alle nettlesere. Det betyr at GPS-koordinater, kameramodell, opptaksdato, opphavsrettstekst og eventuelle egendefinerte XMP-felt i kilde-JPG-en fjernes. ICC-fargeprofiler følger en litt annen vei, der Chrome og Safari beholder sRGB ICC-profiltaggen i resultatet, mens Firefox stripper den sammen med alle andre metadata. Den praktiske følgen er sRGB-trygt resultat på tvers av nettlesere, men brede fargeprofiler som Display-P3 eller Adobe RGB går tapt i Firefox. For de fleste nett- og delingsbruk er fjerning av metadata til hjelp, for det reduserer resultatets størrelse litt og fjerner stedsdata fra bilder. For profesjonell fotografi eller arkivarbeidsflyter der innebygd metadata må bevares, håndter metadatakjeden med et eget verktøy før eller etter formatomformingen.
Personvern i praksis
Hvor konverteringen skjer avhenger av antallet filer. For ett enkelt bilde forlater ingen data nettleseren, og det er verifiserbart i sanntid. Nettverket forblir inaktivt under en enkelt konvertering. Listen forblir tom under kodingen. For to eller flere filer sender RoundCut dem til serveren vår, som konverterer, pakker resultatet og returnerer en nedlastingslenke. Den lenken og de konverterte filene slettes innen omtrent 2 timer. Veien for ett bilde kjører helt på enheten din, utenfor nettet, mens bunkeveien bytter det mot bekvemmeligheten av å konvertere mange filer på én gang. For bilder med følsomt innhold, som et skjermbilde av et personlig dokument eller et foto med posisjonsdata, holder én om gangen alt lokalt.