AVIF naar JPG omzetten

AVIF verscheen in 2019 en won het argument waarvoor het gebouwd was: elke huidige browser leest het, wat ook precies verklaart waarom het bestand dat je nu in handen hebt AVIF is. Maar «elke huidige browser» is meteen ook de hele lijst. Zodra de foto ergens anders naartoe moet — een formulier met een vaste lijst toegestane bestanden, een fotogalerij, een beeldbewerker — wordt het formaat dat won ineens het obstakel.

JPEG is daar sinds 1992 het antwoord op, en er bestaat vrijwel geen software die afbeeldingen leest en JPEG niet leest. Dat is de hele ruil op deze pagina: je geeft de compressie terug die AVIF verdiende, en je krijgt een bestand dat niemand hoeft uit te leggen. Moet de bestemming een document zijn in plaats van een plaatje, dan past een PDF beter — dat is een andere pagina.

AVIF kent een lossless modus, en een afbeelding die bedoeld is om een webpagina sneller te laten laden gebruikt die niet. De foto is dus al door een lossy encoder gegaan, en de omzetting naar JPEG stuurt hem door een tweede, gebouwd op heel andere aannames.

Die tweede encoder ziet niet wat de eerste al wegliet — hij ziet alleen het resultaat en haalt er nog meer af, met een model uit 1992 toegepast op een beeld dat gevormd is door een model uit 2019. Bij een verstandige instelling is de schade beperkt en niet gelijk verdeeld: ze concentreert zich in vloeiende verlopen, onscherpe achtergronden en vlakke vlakken naast scherpe randen.

De kwaliteitsinstelling op deze pagina start op 82 — een bewust behoudende JPEG-waarde: hoog genoeg om een tweede slag onzichtbaar te maken, laag genoeg om het bestand niet nodeloos groot te maken voor iets dat alleen geopend en bekeken hoeft te worden.

De valkuil is meekomen met AVIF-reflexen. AVIF blijft overeind bij getallen waar JPEG onderuitgaat: kwaliteit 50 is bij AVIF vaak niet te onderscheiden van het origineel, en bij JPEG zichtbaar kapot. Boven ongeveer 90 groeit de JPEG snel voor een verschil dat niemand op een scherm ziet.

AVIF heeft een volledig alfakanaal, JPEG helemaal geen — dat is een vast verschil tussen de twee specificaties, geen beperking van deze omzetter. Alles wat transparant was in de bron moet dus een kleur worden, en de pagina vraagt welke, standaard wit.

Het vullen en een eventuele verkleining gebeuren in één stap over de pixels. Eerst vullen en dan schalen mengt de vulkleur in de randen; eerst schalen en dan vullen laat een waas van half-transparante pixels achter die vervolgens verdonkert tot een zichtbare rand. Ga je een uitgesneden logo op een gekleurde pagina plaatsen, stel dan hier meteen die kleur in.

AVIF kan tot twaalf bit per kanaal beschrijven en een breed kleurengamma. JPEG is acht bit, in RGB, grijswaarden of YCbCr, en dat al sinds de standaardisatie. Komt de AVIF van een moderne camera of een HDR-export, dan kan een deel van wat erin zit sowieso niet in een JPEG passen.

De verlaging gebeurt al vóór de JPEG-encoder: deze engine decodeert elke afbeelding naar een acht-bit RGBA-buffer, dus een twaalf-bit bron wordt al bij het decoderen ingekort, ongeacht het doelformaat. Voor de meeste van het web opgeslagen foto’s kost dat niets, omdat ze al acht-bit waren.

Dat verrast mensen, terwijl het logisch is. De AVIF bestaat juist omdat het het kleinste bestand was dat de browser kreeg voorgeschoteld, en een JPEG van dezelfde foto bij een kwaliteit waar hij er hetzelfde uitziet, is meestal flink groter. Omzetten voor compatibiliteit kost bytes, en die bytes zijn de prijs van die compatibiliteit.

Foto’s zijn waar AVIF het sterkst is, dus daar groeit de JPEG het meest. Bij vlakke graphics, iconen en schermafbeeldingen is het verschil klein — al is PNG voor dat soort beeld sowieso vaak het betere doel. Wil je zeker weten hoeveel het scheelt, zet dan één representatief bestand om en meet het na.

De lijst van plekken die JPEG accepteren en AVIF weigeren is lang en oninteressant, en elk item erop is iemands echte middag: een aanvraagformulier dat op extensie controleert, een fotobibliotheek die het bestand niet indexeert, een drukwerkdienst die de upload afwijst, een collega op een oudere machine.

Universaliteit is het enige voordeel dat JPEG nog heeft op AVIF, en het is genoeg, want een bestand dat de ontvanger niet kan openen is geen kleine tegenvaller — het is totaal verlies. Een iets groter, iets zachter bestand dat wél opengaat is meer waard dan een perfect bestand dat dat niet doet.

Komt de AVIF uit je eigen pijplijn, laat de JPEG dan gemaakt worden van wat de AVIF ook produceerde, niet van de AVIF zelf. Eén lossy slag vanaf een master wint altijd van twee opeenvolgende slagen, en die master staat meestal nog gewoon in de exportmap.

Heb je het bestand van iemand anders’ website opgeslagen, dan heb je geen master, is dit het best beschikbare, en kan geen enkele omzetter detail terughalen dat de site nooit meestuurde. Weten in welke van de twee situaties je zit, is dertig seconden waard.

De omzetting decodeert naar pixels en codeert opnieuw, dus het EXIF-blok komt niet mee, en niets op de pagina verandert dat. De encoder krijgt alleen een reeks pixels, dus de opnamevelden zijn al verdwenen voordat de JPEG geschreven wordt.

Voor dit paar kost dat meestal niets, want een AVIF van het web is meestal al door een verkleiningspijplijn gegaan die de camera-velden allang liet vallen. Heb je de opnamedatum of coördinaten in de JPEG nodig, dan moeten die uit het origineel geschreven worden.

jSquash decodeert de AVIF en codeert de JPEG binnen de browsertab, op je eigen processor, dus de foto verlaat de machine niet en er is geen wachtrij, account of daglimiet. Het gratis plafond is 100 MB per bestand, ver boven wat een website ooit als stilstaand beeld zal aanleveren.

De AVIF-decoder is streng: wijst hij een bestand af, dan geeft de pagina niets terug in plaats van te gokken, en meldt dat het bestand onleesbaar is. Dat is vrijwel altijd een bestand dat is omgedoopt naar .avif zonder echt omgezet te zijn. Een hele map echte AVIF-bestanden gaat in één keer door en komt terug als ZIP.