Facebook bruger billedformatet WebP - og får byge af klager

24. april 2013 kl. 07:1316
For at spare lagerplads og båndbredde er Facebook nu begyndt at bruge det Google-udviklede billedformat WebP. Men brugere, som downloader billeder fra Facebook, er stærkt utilfredse med den udvikling.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Besøger du Facebook med browserne Chrome eller Opera, kan du nu få serveret billeder i formatet WebP i stedet for det klassiske Jpeg-format. Det skriver Cnet.com.

Facebook er nemlig begyndt at bruge det nye format, som Google står bag, fordi det skulle kunne skære op mod en tredjedel af datamængden væk, uden at koste billedkvalitet. Den slags kan mærkes i Facebooks enorme datacentre, når der hver dag kommer millioner af nye billeder til.

Problemet er bare, at Chrome og Opera er de eneste browsere, som understøtter WebP-formatet, ligesom det meste software til håndtering af billeder ikke vil æde en WebP-fil. Så når en Facebook-bruger downloader et billede fra browseren og til harddisken, giver det ballade, når billedet skal åbnes lokalt igen.

En kopi af webadressen til billedet, som så bliver sendt til venner uden Chrome eller Opera som standardbrowser, er også et dødfødt projekt, og derfor er klagerne strømmet ind hos Facebook, siden WebP fik sin debut i produktion i weekenden.

Artiklen fortsætter efter annoncen

WebP kan dog få en større udbredelse snart, hvis Mozilla ændrer mening og implementerer det to år gamle format i browseren Firefox. Tidligere har Mozilla sagt nej, fordi formatet efter firmaets mening ikke var godt nok, men siden da har Google adresseret de fleste af Mozillas ønsker.

Et andet tiltag, som kan gøre brugen af WebP lettere - men som ikke umiddelbart vil hjælpe de sure Facebook-brugere - er en udvidelse af HTTP Accept-headeren, som en browser sender til webserveren. Headeren, som skal fortælle serveren, hvad browseren kan læse, bliver i dag kun brugt på et meget generelt niveau. Typisk står der blot ’ HTML, XHTML, XML’, skriver Ars Technica.

Men omvendt er flere bits i hver eneste forespørgsel fra browser til server også en farlig vej at gå, mener en Chrome-udvikler hos Google. Er det først blevet indført, får man aldrig fjernet det igen, pointerer han. Foreløbigt tester Google det i Canary-udgaven af Chrome, som er et af betatest-stadierne.

16 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
15
8. juli 2013 kl. 12:40

... og for en leverandør af en gratis tjeneste for private brugere er optimering af loadhastighed er nok at foretrække frem for skrigeriet fra horderne. Respekt til Facebook for at tage tyren ved hornene og vælge et licensfrit format, som ganske enkelt er bedre til formålet.

Hvis ingen tør springe ombord i de nye formater, bliver vi jo ved med at hænge fast i teknologisk forældede standarder i al evighed... MPEG2, H.263, AVI, MP3... Gys.

Og det er jo som bekendt selvforstærkende, for hardwareproducenterne bliver ved med at primært understøtte de gamle tekonologier, selv om de "nye", teknisk overlegne kompressioner i flere tilfælde har eksisteret i over 10 år.

12
24. april 2013 kl. 15:39

KLAGE? over hvad dog?! At Facebook opbevarer SINE EGNE billeder i et format du ikke bryder dig om? ;)

Sidst jeg havde for meget tid og læste på FBs EULA, så forærer man FB sine billeder når man uploader dem (IANAL og alt det dér).

14
25. april 2013 kl. 01:16

@Adam Tulinius For lige at undgå misforståelser: Jeg hader FB og bruger det ikke, så jeg er enig med dig :)

Jeg synes der er al grund til at klage - men du har foræret dem billederne (+ dine persondata etc), så du har næppe meget "ret" til det. FB er en stor blodsugende parasit, men når man accepterer at være produktet, så må man også acceptere håndteringen. Dét var blot min pointe :)

6
24. april 2013 kl. 10:56

Da billederne må skulle lageres i både jpeg og WebP så tar det 166% lagerplads for at spare 33% af billedbåndbredteforbruget for et subset af brugerene (ie. Chrome og opera brugere)... Bliver spændende at se hvordan det regnestykke ender med at se ud i omkostninger og besparelser...

Understøtter facebook appen eller facebook home WebP ? for på mobil kunne det måske gi mening at skifte da facebook der vil ha kontrol med 100% af den software der skal decode billedfilerne og det vil være muligt at kode en WebP -> jpeg konverter ind i appen hvis fold vil gemme et billed via appen.

Og på lavbåndbredte forbindelser som mobil net jo fra tid til anden er vil jo kunne mærke forskellen på en 1 MB fil og en 660KB fil...

9
24. april 2013 kl. 12:35

Da billederne må skulle lageres i både jpeg og WebP så tar det 166% lagerplads for at spare 33% af billedbåndbredteforbruget for et subset af brugerene (ie. Chrome og opera brugere)... Bliver spændende at se hvordan det regnestykke ender med at se ud i omkostninger og besparelser...

Langtidsbevaring i WebP-format, og præsentationskopier i jpeg. Præsentationskopierne kan man slette når de ikke længere bliver efterspurgt, og gamle filer kan konverteres til jpeg on the fly. Pladsforbruget bliver da størrelsen af alle WebP-filer + jpeg-cachen.

2
24. april 2013 kl. 09:04

Hvis facebook havde tænkt sig lidt om, havde de lavet en fallback løsning, så browsere, som tilgår et billede, præsenteres en jpg i fald de ikke understøtter WebP. Det burde vitterligt ikke være den store udfordring at indbygge denne kontrol af understøttelse i sit CDN. Om kontrollen baserer sig på en accept header, eller om den baserer sig på browser detection, er vel egentlig ligegyldig.

8
24. april 2013 kl. 11:11

Hvis facebook havde tænkt sig lidt om, havde de lavet en fallback løsning, så browsere, som tilgår et billede, præsenteres en jpg i fald de ikke understøtter WebP

Det burde ikke engang være et fallback, men helt almindelig sund fornuft og best practise.

I klassikeren Cool URIs don't change fra W3C -- som jeg håber at man også hos Facebook har læst, kender til og altid har i baghovedet -- står der under So what should I do? Designing URIs, What to leave out:

File name extension. This is a very common one. "cgi", even ".html" is something which will change. You may not be using HTML for that page in 20 years time, but you might want today's links to it to still be valid.

Og det gælder altså ikke kun URL'er som det er meningen at folk skal skrive og/eller se, som fx selve siden folk klikker sig hen til. Det gælder også resurser som fx billeder. Hvis nu Facebook undlod filendelser på deres billeders URL'er, så kunne det fint være op til serveren selv at servere et billede i det bedst mulige format, afhængigt af hvad klienten menes at kunne håndtere. Selvfølgelig kan det også lade sig gøre selvom URL'en ender på fx .jpg eller anden filtype, men det er knapt så elegant.

Forresten, som et lille kuriosum, var det engang i fordums tid sådan at vores allesammen ven, Internet Explorer, ikke kunne finde ud af at vise billeder direkte fra deres URL hvis ikke den endte med den korrekte .filtype :)

3
24. april 2013 kl. 09:34

så browsere, som tilgår et billede, præsenteres en jpg i fald de ikke understøtter WebP.

Det har de allerede gjort. Der er ingen problemer omkring at se billederne. Bøvlet kommer når nogen bruger browseres funktion til at downloade billedet (eller fiske dets URL), typisk via højreklik. Understøttelsen af WebP er ikke så bred omkring anden software til behandling af billeder.

Hvis meningen er at billederne skal kunne plukkes ud fra Facebook, kunne de lave ting som at lade billedet linke til original filen, eller lave en lille menu med options. Men mon ikke Facebook foretrækker at billederne ses on-site....

11
24. april 2013 kl. 13:07

Ehm... det har Facebook faktisk allerede:

Måske skulle jeg have været mere eksplicit. En menu som tilbyder download i alternativt format, og ikke blot den viste .webp udgave.

Der kan argumenteres for at nørden kan finde ud af at modificere url, i stedet for blot at trykke "download", men sådanne pillerier tæller ikke som brugerinterface.

5
24. april 2013 kl. 10:27

Hvis meningen er at billederne skal kunne plukkes ud fra Facebook, kunne de lave ting som at lade billedet linke til original filen, eller lave en lille menu med options. Men mon ikke Facebook foretrækker at billederne ses on-site....

Som jeg har forstået ideen bag Facebooks brug af WebP bliver billederne konverteret til dette format, når de skal gemmes, for at spare på storage-pladsen. Langt de fleste billeder bliver set et par gange og så meget sjældent derefter, men skal stadig være tilgængelige.

vh.

Jesper, Version2

7
24. april 2013 kl. 10:57

Som jeg har forstået ideen bag Facebooks brug af WebP bliver billederne konverteret til dette format, når de skal gemmes, for at spare på storage-pladsen.

I så fald skal de jo blot konvertere til fx JPG for browsere der ikke understøtter WebP, og eventuelt tilbyde at brugere på WebP-browsere får mulighed for download/links til alternativt format. Så spørgsmålet om storage ændrer ikke på den grundlæggende problematik, omkring brugere som ønsker at fiske billeder i deres vante format.

Men ok, det var da nok lidt misvisende at jeg brugte ordet "originalen", når det ser ud til at Facebook allerede for jpg laver en ret hård komprimering.

Jeg tror i øvrigt at netværks-trafikken også er et meget vægtigt argument for Facebook. Det har jo mærkbar betydning for svartiden, som er en væsentlig web design parameter.

1
24. april 2013 kl. 07:39

Firefox sender da accept headers med image præferencer:

Accept: image/png,image/;q=0.8,/*;q=0.5

Det er bare dynamisk så den kun sættes når der laves en GET efter en URL der indeholder gif mm