Hvad der sker, når en browser komprimerer et billede

Den komprimerede fil bliver lavet om til et gitter af pixels igen. Browsere gør det i native kode, med hardwareacceleration hvor platformen tilbyder det, og de klarer JPEG, PNG, WebP og AVIF — plus HEIC på Apples platforme, fordi styresystemet i forvejen leverer den afkoder.

Afkodning er tabsfri i forhold til filen: du får præcis de pixels, filen beskriver. Tabet er allerede sket, dengang det, der lavede filen, kodede den.

Telefonkameraer gemmer sensorens rå orientering plus et separat EXIF-tag, der fortæller, hvordan billedet skal roteres. Software, der ignorerer det tag, producerer fotos, der ligger ned. At efterleve det betyder, at selve pixelgitteret bliver roteret, før noget andet rører det — og derefter er tagget overflødigt, hvilket er en del af grunden til, at genkodning fjerner metadata.

Kan målstørrelsen ikke nås i fuld opløsning, bliver billedet skaleret ned. Det er her, en stor del af den oplevede kvalitet stille og roligt bliver vundet eller tabt. Et billigt boksfilter beregner gennemsnittet af nabopixels og gør alting blødere; et Lanczos-filter vægter et bredere område og holder kanterne skarpe.

Resampling er reelt destruktivt — de pixels, der ryger, kommer ikke tilbage — men det er ofte den mindst destruktive vej til en lille målstørrelse, fordi det fjerner detaljer, som encoderen ellers ville bruge hele sit budget på at beskrive uden held.

Den tabsgivende del. JPEG konverterer til en repræsentation af lysstyrke plus farve, kasserer noget af farveopløsningen (øjet opdager det knap nok), deler billedet op i blokke på 8×8, omsætter hver blok til frekvenskomponenter og kvantiserer så — altså runder de høje frekvenser væk. Kvalitetsparameteren er, hvor groft der bliver rundet. Alt efter det er tabsfri entropikodning, og det er derfor, en optimeret Huffman-tabel eller en progressiv scanning sparer bytes gratis.

Browserens indbyggede encoder er en sort boks: du kan bede om et kvalitetstal og ikke andet. Ingen optimerede entropitabeller, intet valg mellem baseline og progressiv, ingen kontrol over resamplingfilteret og ingen måde at vide, hvor mange bytes en indstilling giver, uden at prøve.

Et codec oversat til WebAssembly giver alt det tilbage, til gengæld for de bytes, du bruger på at hente det. ToolZool kører hele pipelinen på den måde — afkodning, orientering, resampling og kodning er alt sammen Rust oversat til WebAssembly i en baggrundsworker — i stedet for at overlade afkodningen til browseren. Tre grunde, alle praktiske:

• Søgningen kræver mange kodninger. At ramme en præcis størrelse betyder, at det samme billede bliver kodet fem-seks gange. At eje encoderen er det, der gør det billigt og forudsigeligt.
• En afkoder skal kunne sige nej. En fil, der påstår at være 60.000 × 60.000 pixels, skal afvises, før der bliver allokeret hukommelse, og en afkortet fil skal fejle frem for at returnere et halvt billede. Browserens afkoder træffer sine egne beslutninger der; vores oplyser grænserne og håndhæver dem.
• Samme input skal give samme output. Browserafkodere er forskellige i deres farvehåndtering og i, hvordan de behandler defekte filer. En pipeline, der ejer begge ender, producerer de samme bytes på alle enheder, og det er det, der gør et resultat efterprøveligt.

Prisen skal siges ærligt: den motor er en download. Den bliver først hentet, når du vælger en fil, så det koster aldrig noget at læse en side som denne.

Med en given målstørrelse er forskellen mellem en god og en fremragende encoder et par procent. Forskellen mellem at gætte på en kvalitetsskyder og at søge efter den rigtige værdi er meget større, for et gæt, der lander på 60 % af din tilladte størrelse, smed en tredjedel af den kvalitet væk, du havde krav på. Det er hele idéen bag at komprimere til en præcis størrelse, og sådan rammer du en grænse på 50 KB viser, hvad søgningen giver dig i den hårdeste ende af skalaen.