Formatdiskusjoner starter som regel med kodeken og jobber seg utover. Det er baklengs. Riktig format bestemmes av hva som er i bildet, og først deretter av hva mottakersystemet godtar.
Fotografier: JPEG eller WebP
Bilder med jevne toneoverganger — ansikter, landskap, alt med gradienter og støy — komprimeres godt med tapsbaserte kodeker, fordi øyet tåler små feil i travle partier. JPEG er det trygge standardvalget, rett og slett fordi alt godtar det. Tapsbasert WebP når samme opplevde kvalitet på merkbart færre byte, og vinner derfor hver gang mottakeren tillater det.
Ett forbehold hvis du bruker ToolZool til dette: komprimeringen vår skriver WebP bare i tapsfri modus, og på et fotografi gir det en fil som er flere ganger større enn JPEG-en ville vært. Har fotografiet en størrelsesgrense, velg JPEG her. Årsaken til det gapet står på verktøyets egen side — det finnes ingen tapsbasert WebP-koder vi kan levere uten enten en uforenlig lisens eller en C-verktøykjede.
Flat grafikk og tekst: PNG
Logoer, ikoner, diagrammer og skjermbilder av brukergrensesnitt består av harde kanter og store flater med nøyaktig samme farge. Tapsbaserte kodeker håndterer harde kanter dårlig: du får synlig ringing rundt tekst, og fordi støyen de innfører i seg selv er dyr å kode, ender filen ofte opp større enn en tapsfri PNG av det samme bildet.
Gjennomsiktighet avgjør valget
JPEG har ingen alfakanal. Konverterer du en gjennomsiktig PNG til JPEG, blir de gjennomsiktige partiene fylt — som regel svarte, iblant hvite, sjelden det du var ute etter. Både PNG og WebP støtter alfa, så har bildet gjennomsiktighet, står valget mellom de to.
Hvor AVIF passer inn
AVIF slår WebP på filstørrelse ved samme kvalitet, særlig ved lave bitrater, og alle dagens nettlesere kan vise det. Kodingen er problemet: den er dramatisk tregere og langt tyngre å kjøre enn JPEG eller WebP, og det betyr mye når kodingen skjer på en mobil framfor på en byggeserver.
ToolZool verken leser eller skriver AVIF i dag. Begge veier krever en AV1-kodek, og alle vedlikeholdte er C-biblioteker som ikke bygger for WebAssembly — så en AVIF-fil må konverteres et annet sted først. Det samme gjelder HEIC, som de fleste iPhoner lager som standard.
Spørsmålet som overstyrer alt dette
Hva godtar skjemaet? Et bedre format som blir avvist, er ikke bedre. Les listen over godtatte formater først, og optimaliser innenfor den — og hvis en fil som ser ut til å kvalifisere likevel blir avvist, går hvorfor et opplastingsskjema avviser filen din gjennom de fire sjekkene et skjema faktisk kjører. Trenger du å bytte mellom formater, leser bildekomprimeringen JPG, PNG og WebP og skriver JPEG, PNG eller tapsfri WebP, så den fungerer også som konverterer innenfor det settet.
