WebP

Hvad det er

WebP er et rasterformat til billeder, udgivet af Google, gemt i filer med endelsen .webp og serveret med den registrerede medietype image/webp. Ét format dækker opgaver, der før krævede tre: fotografier, som blev sendt som JPEG; flad grafik med skarpe kanter og gennemsigtighed, som blev sendt som PNG; og korte animerede løkker, som blev sendt som GIF. Navnet skrives med stort W og stort P, og på disken er det blot .webp-filen.

Indvendigt er en WebP-fil en RIFF-beholder, den opdelte struktur, som WAV-lydfiler også bruger, og den rummer én af tre slags indhold. En VP8-blok bærer data med tab, kodet med nøglebilledmetoden fra videocodecen VP8: koderen forudsiger hver blok af pixel ud fra naboer, den allerede har afkodet, og gemmer kun forskellen. En VP8L-blok bærer tabsfri data fra en separat koder, skrevet til billeder, der skal komme tilbage bit for bit. En VP8X-header markerer den udvidede form, som tilføjer en alfakanal, animationsbilleder, en ICC-farveprofil og metadata i EXIF eller XMP. Google dokumenterede formatet sammen med sit eget bibliotek, og siden er det udgivet som RFC 9649, en informativ RFC fra november 2024.

Det er den udvidede form, der gør formatet til mere end en mindre JPEG. Et billede med tab kan have en separat alfakanal, så et fotografi med en blød, gennemsigtig kant slipper for at være en tung tabsfri fil. Animation ligger i samme beholder, billede for billede, og hvert billede kodes med eller uden tab, alt efter hvad der passer.

Grænserne er skrevet ind i bitstrømmene. Hver side af et billede gemmes i 14 bit, så den højst kan være 16.383 pixel for data med tab og 16.384 for tabsfri data, og en hel fil holder sig lige under 4 GiB. Hver farvekanal gemmes i 8 bit, hvilket passer til billeder beregnet til en skærm og taber den ekstra dybde i en original på 16 bit.

Hvorfor det betyder noget

Billeder er som regel de tungeste bytes på en side, og formatet afgør, hvor mange af dem der er. Googles egen sammenligning placerer tabsfri WebP 26 % under PNG og WebP med tab 25–34 % under JPEG ved samme SSIM, et mål for strukturel lighed mellem to billeder. En WebP med tab og alfakanal fylder typisk en tredjedel af den PNG, den erstatter. Færre bytes når hurtigere frem på en langsom forbindelse, koster mindre at levere og efterlader plads i sidens budget til det, læseren kom efter.

Den beslutning, et team står over for, handler mindre om, hvorvidt det skal bruge WebP, end om hvilket format der skal udgives for hvilket billede, og om der skal udgives mere end ét. Dér holder de offentliggjorte gennemsnit op med at hjælpe. De er gennemsnit over et testkorpus, mens filerne på et rigtigt site er et logo, en håndfuld fotografier og nogle skærmbilleder, og rækkefølgen kan falde forskelligt ud for hver af dem. AVIF, det nyere format, er den sædvanlige rival, og på papiret komprimerer det hårdere. På et bestemt site, ved de størrelser det site viser, kan det tabe.

Den anden beslutning er, hvor konverteringen sker. Konverterer man i hånden én gang, står man tilbage med en mappe filer, der glider væk fra deres kilder. Konvertering ved bygning, ud fra en original i repositoriet, gør hver udgivet størrelse reproducerbar og gør det billigt at ændre kvalitetsindstillingen, eller formatet, senere.

Den tredje er alt uden for browseren. Et billedes adresse rejser: ind i feeds, e-mail, forhåndsvisninger i chat, kontordokumenter og billedredigeringsprogrammer, og hver af dem afgør selv, hvilke formater den læser. Et site, der flytter alle billeder til WebP, lærer, hvilke modtagere der accepterer det, af den første læser, der ser et ødelagt billede, medmindre det kontrollerer hver vej på forhånd.

Sådan ser det ud i praksis

Kolofonen opgiver dette websteds billeder som WebP- og PNG-billeder, skaleret ved bygning. Skabelonerne viser, hvad det betyder. Fotografier, avatarer og brandmærket går alle gennem én fælles partial, der skalerer originalen til flere bredder, hver kodet som WebP, og skriver ét img-element med en srcset, så browseren vælger bredden, og sitet allerede har valgt formatet.

Det format er en måling og ikke en standardindstilling. Sitets Hugo-version kan kode AVIF, så det var en mulighed at levere begge gennem et picture-element. Ved de størrelser, sitet faktisk viser, kom AVIF ud 30–36 % større end WebP for hjernemærket og 3–7 % større for avatarerne; det vandt kun på portrættet, med 13 %, og knap nok på kontorfotografierne, med 3 %. Et picture-element vælger sin kilde efter rækkefølge og efter, hvad browseren understøtter, aldrig efter størrelse, så hvis AVIF stod først, ville hver moderne browser have fået omtrent en tredjedel flere bytes for logoet på hver side. Med ét format, der er værd at udgive, bruger skabelonen img med srcset og slet intet picture.

Den samme partial rummer en lektie mere. Hugo koder et billede om, også når det bliver bedt om at skalere det til den bredde, det allerede har, og det giver en ekstra omgang med tab og en ekstra udgivet fil. Når en ønsket bredde er lig originalens, peger partialen derfor direkte på originalen.

WebP holder op ved grænsen for, hvad anden software læser. RSS-feedet peger sit image-element på en PNG, fordi RSS 2.0 kun accepterer GIF, JPEG og PNG dér og begrænser billedet til 144 gange 400 pixel: delingskortet i WebP, 1.280 pixel bredt, fik en advarsel fra W3C’s feedvalidator, og apple-touch-ikonet på 144 pixel, en PNG i præcis den største tilladte bredde, tog dets plads. De skærmbilleder, som det engelske og det danske manifest giver til Chromiums installationsdialog, er derimod WebP, et bredt og et smalt til hvert, og en lint-opgave fejler, når de er ældre end de stylesheets eller skabeloner, de viser.

Hvor det går galt

En konverteret JPEG mister detaljer to gange. Når en eksisterende JPEG laves om til WebP med tab, afkodes én generation med tab, og en ny kodes, og artefakterne fra begge overlever. Hugos omkodning ved samme bredde er en stillere udgave af den samme fælde. Hold en tabsfri original eller en original i fuld kvalitet i repositoriet, og kod hver udgivet fil ud fra den.

Farverne bliver matte efter konverteringen. cwebp, referencekoderen, kopierer ingen metadata, medmindre den bliver bedt om det, så ICC-profilen fra et fotografi med bred farveskala bliver efterladt, og browseren behandler pixelene som sRGB. Angiv -metadata icc, eller konverter billedet til sRGB før kodningen.

En feedlæser viser et ødelagt billede. Software skrevet før formatet, eller bundet til en ældre specifikation, behandler en WebP som en ukendt fil. RSS 2.0 er det tydeligste tilfælde: dets image-element nævner tre formater, og WebP står uden for dem. Følg hvert sted, et billedes adresse rejser hen, og lever PNG eller JPEG, hvor modtageren kræver det.

Et langt skærmbillede standser koderen. En helsidesoptagelse af en lang artikel kommer let over 16.383 pixel i højden, og bitstrømmen har ikke plads til en højere side, så koderen slutter med en dimensionsfejl. Del optagelsen op, eller skaler den ned først.

Den større fil vinder picture-elementet. Står et nyere format først, sendes det til hver browser, der kan afkode det, uanset om det er mindre for netop det billede. Mål hver kandidat ved de størrelser, siden viser, før en kilde tilføjes, som dette site gjorde med AVIF.

Læs mere

• WebP — Googles side for formatet: kompressionsundersøgelsen bag de offentliggjorte procenter, biblioteket libwebp og dets værktøjer.
• RFC 9649: WebP Image Format — beholderen, de tre bitstrømme og størrelsesgrænserne, udgivet som informativ RFC.
• cwebp — alle referencekoderens indstillinger, herunder -q, -lossless og -metadata.
• Hugo: Image processing — hvordan et Hugo-site skalerer og konverterer billeder, WebP inklusive, ved bygning.
• HTML Standard: Images — hvordan srcset, sizes og picture lader browseren vælge mellem kandidatfiler.
• RSS 2.0 Specification — image-elementet, de tre formater det accepterer, og dets størrelsesgrænser.