Formatdiskussioner utgår nästan alltid från codecen och arbetar sig utåt. Det är bakvänt. Rätt format avgörs av vad som finns i bilden, och först därefter av vad mottagarsystemet accepterar.
Fotografier: JPEG eller WebP
Bilder med mjuka övergångar — ansikten, landskap, allt med gradienter och brus — komprimeras bra med destruktiva codecar, eftersom ögat tolererar små fel i detaljrika partier. JPEG är det trygga förstahandsvalet, för allt accepterar det. Destruktiv WebP når samma upplevda kvalitet på märkbart färre byte och vinner därför så snart mottagaren tillåter det.
En reservation om du använder ToolZool till detta: vårt komprimeringsverktyg skriver WebP bara i förlustfritt läge, vilket på ett fotografi ger en fil som är flera gånger större än motsvarande JPEG. För ett fotografi med storleksgräns väljer du JPEG här. Skälet till skillnaden står på verktygets egen sida — det finns ingen destruktiv WebP-kodare vi kan leverera utan att antingen krocka med licensen eller kräva en C-verktygskedja.
Platt grafik och text: PNG
Logotyper, ikoner, diagram och skärmbilder av gränssnitt består av hårda kanter och stora ytor i exakt samma färg. Destruktiva codecar hanterar hårda kanter dåligt: du får synliga ringningar runt text, och eftersom bruset de tillför i sig är dyrt att koda blir filen ofta större än en förlustfri PNG av samma bild.
Genomskinlighet avgör valet
JPEG har ingen alfakanal. Konverterar du en genomskinlig PNG till JPEG blir de genomskinliga ytorna heltäckande — oftast svarta, ibland vita, sällan det du tänkt dig. PNG och WebP stöder båda alfa, så har bilden genomskinlighet står valet mellan de två.
Var AVIF passar in
AVIF slår WebP på filstorlek vid samma kvalitet, särskilt vid låga bittal, och alla aktuella webbläsare kan visa formatet. Kodningen är problemet: den är dramatiskt långsammare och betydligt tyngre att köra än JPEG eller WebP, vilket spelar roll när kodningen sker i en telefon i stället för på en byggserver.
ToolZool varken läser eller skriver AVIF i dag. Båda riktningarna kräver en AV1-codec, och varje underhållen sådan är ett C-bibliotek som inte går att bygga för WebAssembly — så en AVIF-fil måste konverteras någon annanstans först. Detsamma gäller HEIC, som de flesta iPhone-modeller skapar som standard.
Frågan som går före allt annat
Vad accepterar formuläret? Ett bättre format som blir nekat är inte bättre. Läs listan över tillåtna format först och optimera sedan inom den — och om en fil som borde uppfylla kraven ändå nekas går varför ett uppladdningsformulär nekar din fil igenom de fyra kontroller ett formulär faktiskt kör. Behöver du byta mellan format läser bildkomprimeringen JPG, PNG och WebP och skriver JPEG, PNG eller förlustfri WebP, så den fungerar också som konverterare inom den uppsättningen.
