Diskussioner om formater tager som regel udgangspunkt i codec’et og arbejder sig udad. Det er den forkerte vej rundt. Det rigtige format bliver afgjort af, hvad der er på billedet, og først derefter af, hvad det modtagende system accepterer.
Fotografier: JPEG eller WebP
Billeder med bløde overgange — ansigter, landskaber, alt med gradienter og støj — komprimerer godt med tabsgivende codecs, fordi øjet tåler små fejl i travle områder. JPEG er det sikre udgangspunkt, fordi alting accepterer det. Lossy WebP når den samme oplevede kvalitet på mærkbart færre bytes, så det vinder, når modtageren tillader det.
Ét forbehold, hvis du bruger ToolZool til det her: vores komprimering skriver kun WebP i lossless-tilstand, og på et fotografi giver det en fil, der er flere gange større end den tilsvarende JPEG. Til et fotografi med en størrelsesgrænse skal du vælge JPEG her. Grunden til det spring står på komprimeringens egen side — der findes ingen lossy WebP-encoder, vi kan levere med, uden enten en uforenelig licens eller en C-værktøjskæde.
Flad grafik og tekst: PNG
Logoer, ikoner, diagrammer og skærmbilleder af brugerflader består af skarpe kanter og store flader i samme farve. Tabsgivende codecs håndterer skarpe kanter dårligt: du får synlige skygger omkring tekst, og fordi den støj, de introducerer, i sig selv er dyr at kode, ender filen ofte med at være større end en lossless PNG af det samme billede.
Gennemsigtighed afgør valget
JPEG har ingen alfakanal. Konverterer du en gennemsigtig PNG til JPEG, bliver de gennemsigtige områder massive — som regel sorte, nogle gange hvide, sjældent det, du ville have. PNG og WebP understøtter begge alfa, så har billedet gennemsigtighed, står valget mellem de to.
Hvor AVIF passer ind
AVIF slår WebP på filstørrelse ved samme kvalitet, især ved lave bitrater, og alle nuværende browsere kan vise det. Problemet er kodningen: den er dramatisk langsommere og langt tungere at køre end JPEG eller WebP, og det betyder noget, når kodningen sker på en telefon frem for på en byggeserver.
ToolZool kan hverken læse eller skrive AVIF i dag. Begge veje kræver et AV1-codec, og alle de vedligeholdte er C-biblioteker, der ikke kan bygges til WebAssembly — så en AVIF-fil skal konverteres i noget andet først. Det samme gælder HEIC, som de fleste iPhones producerer som standard.
Spørgsmålet, der trumfer alt det her
Hvad accepterer formularen? Et bedre format, der bliver afvist, er ikke bedre. Læs listen over godkendte formater først, og optimér så inden for den — og bliver en fil, der ser ud til at opfylde kravene, alligevel afvist, gennemgår derfor afviser en uploadformular din fil de fire tjek, en formular reelt kører. Skal du skifte mellem formater, læser billedkomprimeringen JPG, PNG og WebP og skriver JPEG, PNG eller lossless WebP, så den fungerer også som konverter inden for det udvalg.
