Facebook experimenteert met serveren van WebP-afbeeldingen

Facebook is begonnen met het serveren van afbeeldingen in WebP-formaat aan browsers die het relatief nieuwe compressieformaat ondersteunen. De sociale-netwerksite wil zo dataverkeer besparen en zijn site versnellen, maar sommige gebruikers morren.

WebP werd in november 2011 door Google als opensource vrijgegeven. Het lossy compressieformaat is bedoeld voor afbeeldingen en comprimeert volgens de zoekgigant gemiddeld 39 procent beter dan de jpeg-standaard. Aanvankelijk werd WebP slechts zeer beperkt ondersteund; alleen Chrome kon er zonder plugins mee overweg. Google zet het beeldformaat zelf in voor bijvoorbeeld afbeeldingen in de Play Store voor Android-apparaten.

Inmiddels is ook Facebook op beperkte schaal begonnen met het toepassen van WebP-compressie voor afbeeldingen. Foto's die naar de sociale-netwerksite worden verstuurd, worden opnieuw opgeslagen in het formaat. Daarnaast serveert Facebook afbeeldingen in het WebP-formaat aan browsers die het formaat herkennen. Dat zijn momenteel Chrome en Opera. Facebook kan hierdoor besparen op zijn dataverkeer, terwijl de eindgebruiker een webpagina sneller binnenkrijgt.

Het is nog niet geheel duidelijk op welke schaal Facebook WebP-afbeeldingen serveert. Wel komen er klachten van gebruikers die het bestandsformaat niet herkennen of zeggen geen software te hebben om de afbeeldingen te kunnen bewerken of delen, zo schrijft Cnet. Desondanks lijkt de ondersteuning van WebP op stoom te zijn gekomen. Inmiddels zou ook Mozilla overwegen om in Firefox Googles compressieformaat te gaan ondersteunen. Wel heerst er nog onenigheid bij browserbouwers of er een http accept header moet komen voor WebP. Daarin kan worden aangegeven of een browser overweg kan met het formaat.

Reacties (93)

Ik heb hem zelf ook maar even getest, want voorbeelden van Google zelf vertrouw ik niet. De VP8 codec is ook niet superieur aan h.264 zoals Google ons wou doen geloven met speciaal ontworpen samplefilmpjes.

Origineel: http://commons.wikimedia....rops_apiaster_feeding.jpg

Heb hem geresized naar 640*426 en poog hem tot 8KB te comprimeren, resultaat: webp comparison. Heb ook meteen JPEG2000 meegenomen en de JPEG2000 en webp plaatjes weer omgezet naar PNG gezien de nog gebrekkige browserondersteuning.

JPEG2000 is vrij crappy, de kop van de vogel in het midden is scherp en de rest veel te wazig. JPG is zoals je zou verwachten, zichtbare artefacten overal, maar alles bij elkaar in mijn ogen beter dan JPEG2000. Webp doet het duidelijk beter dan zowel JPG als JPEG2000.

[edit]
Plaatjes naast elkaar gezet, nu ook beschikbaar: Delorean comparison waar JPG2000 iets beter uitkomt, maar nog steeds zijn meerdere moet erkennen in webp.

[Reactie gewijzigd door Mentalist op 22 april 2013 23:11]

Hier een uitgebreide vergelijking tussen WebP en JPEG met onderbouwde conclusies, door gebruik te maken van de Structural Similarity index. Deze index wordt gebruikt om het verschil in kwaliteit tussen twee plaatjes te bepalen. Je kan hierdoor bijvoorbeeld de filesize en bijbehorende kwaliteit bepalen van verschillende codecs.

Overigens wordt er door @Titan_Fox een vergelijking gemaakt tussen de kwaliteitsfactors van JPEG (Q.45) en WebP (Q.76). Deze waarden kun je niet met elkaar vergelijken, aangezien deze kwaliteit een schaal is van het eigen algoritme. Het is de factor waarmee dat algoritme zijn berekeningen op moet gaan focusen, betere of slechtere kwaliteit.

Het hoeft zelfs ook niet waar te zijn dat bijvoorbeeld JPEG Q 45 een betere kwaliteit heeft dan JPEG Q 40. Uit deze grafiek (uit de blog post die ik hierboven beschreven heb) blijkt maar eens dat bij een lagere kwaliteitsfactor van JPEG een beter visueel resultaat behaald kan worden dan wanneer de kwaliteitsfactor hoger gezet is. Dus een grotere filesize, maar minder kwaliteit.

[Reactie gewijzigd door ntilborg op 23 april 2013 10:19]

Maar wat je hier hebt gedaan is filesizes naar onredelijk lage waarden persen. Welke dan beter is is nogsteeds volstrekt subjectief als je het mij vraagt. Het ligt er puur aan welke blokkerige verblurde pixelbrei het het liefst hebt...

Staat op internet ook genoeg voorbeelden waarin WebP discotabel het onderspit delft.
Feit blijft dat ik compressie onzin vind waar dat niet nodig is. Facebook kan prima bepalen of de connectie naar een bezoeker van dien snelheid is dat je zonder morren ongecomprimeerde PNG over kan brengen.
Telefoon foto´s worden ook steeds beter en word niet echt vrolijk van gare compressie alleen maar vanuit het standpunt dat de meeste foto´s gemaakt worden met kloterige camphones uit 2001.
Als ik het werk van een fotograaf die op facebook zit wil bewonderen ga ik standaard opzoek naar een site want Facebooks foto mechanisme daar gaat mijn netvlies van rotten.

Maar wat je hier hebt gedaan is filesizes naar onredelijk lage waarden persen. Welke dan beter is is nogsteeds volstrekt subjectief als je het mij vraagt. Het ligt er puur aan welke blokkerige verblurde pixelbrei het het liefst hebt...

Natuurlijk heb ik dat gedaan. En ook dan zie je dat de webp plaatjes als enige bijna-acceptabel uit de test komen.

Maar goed, prima: ik comprimeer plaatjes naar een onredelijk lage waarde. Stel eens een alternatief voor. Comprimeren naar een redelijke waarde, bijvoorbeeld 50KB ipv. 8KB? Dan zien ze er allemaal hetzelfde uit voor het menselijk oog en is de vergelijking zinloos. Maakt het sowieso amper meer uit welk formaat je kiest. Comprimeren naar dezelfde kwaliteit? Onmogelijk, de algoritmes comprimeren alle drie op een totaal andere manier. Comprimeren naar een redelijke bestandsgrootte en dan enorm inzoomen om het verschil te kunnen zien? Dat is geen realistisch scenario. Bij inzoomen worden details zichtbaar die misschien zijn gesloopt door een compressiemethode maar bij normaal formaat totaal niet opvallen.

Nog iets interessants wat mij opviel: bij het terugcomprimeren van JPEG2000 en webp naar PNG blijkt de PNG van webp steeds aanmerkelijk kleiner te zijn dan die van JPEG2000. Het resultaat van lossy webp compressie is dus beter lossless te comprimeren.

[Reactie gewijzigd door Mentalist op 23 april 2013 01:53]

Hier een alternatief: een vergelijkende test over 3 dimensies, te weten een brede selectie fotos met verschillende onderwerpen (veel detail, weinig detail, kleurovergangen of niet, enz), afgezet tegen een rijtje standaard uitsnede formaten die gangbaar zijn op het web, afgezet tegen verschillende compressie factoren.

Het resultaat van compressie is het resultaat van de omvang van de uitsnede, de compressie factor, de codec en de daadwerkelijke inhoud van de foto. Iedere test die al deze zaken niet meeneemt bewijst helemaal niets.

Ik beweer overigens niet dat je test fout is, ik beweer alleen dat deze niets bewijst.

Deze test is te simpel. Een honderd tal plaatjes met andere uitdagingen voor de codec had een compleet beeld gegeven

Ik denk dat dit een goede vooruitgang is: voornamelijk omdat de gemiddelde Facebook foto van dusdanig lage kwaliteit is dat het niet meer boeit (of ik heb niet zoveel artistieke vrienden, dat kan ook).
Het zou geniaal zijn als ze dit combineren met een algoritme dat detecteert of een foto van hoge kwaliteit (goede weergave) of van slechte kwaliteit (hoge compressie) . Dan heb je een snellere pagina met mooie plaatjes daar waar de plaatjes ook echt mooi zijn.

Web sites als Facebook schalen de foto die je upload in verschillende sizes en hierin zit een onoplosbaar probleem: de optimale compressie en verscherping (na resizen moet je altijd verscherpen) zijn afhankelijk van de inhoud van de foto. Dit is (nog) niet algorithmisch vast te stellen zover ik weet.

Er zal dus altijd een verschil zitten tussen je origineel en wat er van over blijft, tenzij men rechtstreeks het origineel laat bekijken. Verder kan het zijn dat de foto nog eens door de browser verkleind wordt, wat ook weer browser en algoritme-specifiek is.

Het is dus onzinnig om er een foto uit te pakken en deze tussen 2 formaten te vergelijken. Een zinnige vergelijking zou een divers aantal soorten foto's met elkaar vergelijkingen en dat ook nog over verschillende compressie factoren, over 2 dimensies dus.

Ik zie het verschil zo snel niet inderdaad,. maar het ligt er ook een beetje aan welke jpeg compressie je gebruikt. Dat zie ik zo 1-2-3 niet terug in het artikel. Maar ik kan het over het hoofd zien.
http://news.cnet.com/8301...mage-format-users-squawk/

De demo plaatjes worden door firefox in elk geval nog niet standaard "images" herkent.

Mwah, moet wel zeggen dat je toch wel het verschil kunt zien (meer pixelated, onscherper):

JPG 1
http://www.gstatic.com/webp/gallery/1.jpg

WEBP 1
http://www.gstatic.com/webp/gallery/1.webp

JPG 2
http://www.gstatic.com/webp/gallery/5.jpg

WEBP 2
http://www.gstatic.com/webp/gallery/5.webp

Zie niet in waarom ze een formaat willen gebruiken, waarbij de kwaliteit achteruit gaat.. zorg er dan op z'n minst voor dat je een formaat ontwikkeld waarbij de kwaliteit intact blijft maar de bestandsgrootte kleiner word.

@Haakontje : Aan je voorbeelden heb ik niet zo veel aangezien ik .webp niet geopend krijg met Firefox :-)

Vandaar dat ik je even help met een voorbeeld dat ook door niet-Chrome gebruikers te bekijken is.

http://upload.wikimedia.o..._Lossless_comparative.png

Bizar, in het voorbeeld van Titan_fox is jpg de duidelijke verliezer, dat terwijl in het voorbeeld van Haakontje jpg dan weer beter lijkt te zijn (zoals soepstengel zegt: mozaiek in de lucht)

Ik ben alleszins niet echt overtuigd van een meerwaarde op die manier, of het zou aan opera moeten liggen.

@pieterdebie : Het zal aan de sterkte en type compressie liggen. In mijn voorbeeld hebben ze ervoor gezorgd dat het bestand ongeveer dezelfde grootte heeft.

Bij JPEG staat er "Q.45" (quality) terwijl er bij WebP "Q.76" staat. Ondanks de (vrijwel) identieke grootte van deze twee compressiemethoden zorgt WebP (in dit voorbeeld) voor een kwaliteitstoename van bijna 69%.

Ik vind dat een aanzienlijke vooruitgang. Helaas kan ik niet oordelen over de bestanden van "Haakontje" omdat ik de bestanden niet geopend krijg met Firefox.

[Reactie gewijzigd door Titan_Fox op 22 april 2013 23:52]

Het allergrootste probleem is dat JPEG ontzettend veel verschillende implementaties kent, en zeker in de standaardimplementaties die vrijwel overal in gebruikt worden (libjpeg enzo), wordt het volledige potentieel van de standaard NIET benut. Ik las hier onlangs een goede blogpost over, van iemand die hier onderzoek naar gedaan heeft.
JPEG kan beduidend meer dan nu meestal ingezet KAN worden; de winst van nieuwe formaten is vooral de strakkere definitie van de standaardisatie. De reden waarom de meeste JPEG implementaties namelijk sommige geavanceerde technieken niet ondersteunen die wel in de standaardomschrijving staan, is dat die technieken niet verplicht ondersteund hoeven worden door JPEGdecoders. En het laatste wat je wilt is dat je een mooie jpeg maakt die niemand kan openen...

Edit: dit is de bewuste blog: http://goldfishforthought...ebp-jpeg-and-jpeg-xr.html

[Reactie gewijzigd door Buggle op 23 april 2013 09:03]

Ik vind de WebP afbeelding in dit voorbeeld toch echt flink beter smoelen dan de JPEG (waarvan de achtergrond een zooi artifacts is om onder de 100KB te blijven).

NIce een echte Brauner.

Wat me wel meteen opvalt is dat de de WebP iets beter oogt dan de jpeg.

Maar ik zou zeggen, zolang het niet breed ondersteund wordt, niet doorvoeren.

Ik kon ze bijvoorbeeld alweer niet openen, samen met mij nog velen denk ik.
En facebook is het alweer aan het doorvoeren (nu staat er wel op kleine schaal, maar als het bij hun goed bevalt zou het zomaar kunnen dat ze het op grotere schaal doorvoeren).

Omdat ze zoveel gebruikers hebben zouden ze dat nog kunnen doen ook, of ondersteunen of je hebt pech met je profiel.

Je kunt Facebook nu ook via HTTP en via SPDY bereiken. Straks kun je afhankelijk van je browser agent WebP en JPEG laden. Ik zie het probleem niet. Dit is juist geweldig met het oog op innovatie omdat eindelijk eens iemand het voortouw neemt. De rest volgt dan en zo krijg je sneller nieuwere technologie voorgeschoteld.

Wat mij erg opvalt is dat er veel lijnen juist behouden blijven. Zo zijn de lijnen van de bergen in de achtergrond op de eerste foto in het jpeg formaat veel korreliger dan bij het webp formaat. Daardoor lijkt het me niet zozeer dat de kwaliteit achteruit gaat, maar dat de compressie elders wordt gezocht.

Wat mij weer opvalt is dat de compressie vooral op kleur vlakken wordt gehaald. Kijk bijvoorbeeld op de eerste foto eens naar de blauwe lucht links bovenin, ik zie een aardig mosaic effect. Bij de tweede foto zie je het weer duidelijk naar voren komen in de achtergrond (op de muur en het witte op de trommels). Schijnbaar doet webp gewoon aangeven wat één kleur is, en neemt het het niet zo nauw met kleur tinten die dicht bij elkaar liggen.

Ik ben er in ieder geval totaal niet positief over!

hehe, iemand die het begrijpt.. als ze met dezelfde kwaliteit maar minder groot kunnen behalen, DAN heeft het zin om met een nieuw formaat te komen, maar dit is gewoon Yet Another Format, en zo wil google graag hun standaarden opdringen/door de strot douwen..
Je ziet het ook met WebM, de kwaliteit is beduidend slechter dan die van bv h.264, en ook bij WebM ben je mogelik niet licentievrij ondanks wat google probeert te beweren..

Ik vind het ergens jammer dat we met steeds snellere internetverbindigen en goedkopere opslag nu juist een stap terug doen in beeldkwaliteit.

Ik vind het ergens jammer dat we met steeds snellere internetverbindigen en goedkopere opslag nu juist een stap terug doen in beeldkwaliteit.

Ik vind 't vooral frappant dat er uberhaupt nog behoefte is aan dergelijke compressie?

Ik snap dat ieder beetje compressie helpt, maar jpeg's en gif waren al gemeengoed toen ik nog op 33k6 inbelde...nu is mijn bandbreedte in factor 300 groter ( ruweg 10mbit, hetgeen aan de lage kant is afaik) en is er opeens noodzaak voor nog meer compressie?

Wacht maar tot je een website gaat runnen aan miljoenen gebruikers. Het scheelt Facebook miljoenen euro's per maand als ze alles via webP konden draaien.

Dat alle verbindingen sneller worden en opslag groter wil nog niet zeggen dat compressie geen nut meer heeft.

De kosten van Facebook zitten niet in het versturen van statische content.
De meeste kosten zitten in de dynamische content.

Het grote voordeel van kleinere bestanden is dat ze net iets sneller inladen (zeker op een mobiel) dus vaker gezien worden. Het scheelt misschien een 5% op het totaal maar dat met een percentage van gebruikers dat daadwerkelijk op een advertentie klikt is elk klein beetje welkom.

Dat is natuurlijk heel leuk dat jouw bandbreedte zo groot is, maar tegelijkertijd ben je afhankelijk van wat de server jou en de andere duizenden bezoekers kan leveren... Met die vergroote bandbreedte correleert namelijk ook een steeds grotere hoeveelheid bezoekers omdat iedereen toch steeds online is. Daarmee neemt de druk op de servers onevenredig toe, zeker omdat al die mensen zoals jij zegt een factor 300 grotere bandbreedte hebben. Juist onder die omstandigheden is een goede compressietechnologie onmisbaar.

WebP heet niet voor niets zo. Het is juist voor het web bedoeld. Voor de mensen thuis biedt het weinig meerwaarde, want 20 tot 30% reductie in filesize tov jpeg, daar ligt niemand wakker van.

Goedkopere opslag? vergeet niet dat als je opslag nodig bent die een wat hogere performance en betrouwbaarheid dan een usb disk bij de mediamarkt dat opslag ineens toch nog een hoop kost...

Bij opslag denken mensen onterecht aan enkele TBs voor minder dan 100euro...

Als een facebook ineens gaat draaien op dat soort goedkope disken dan zal dat resulteren in een site die niet voor uit te branden is...

Maar wat doet dit met de kwaliteit van de foto's, in de praktijk?
Facebook blinkt absoluut niet uit in de presentatiekwaliteit van de foto's als je met iets dat een camera mag heten foto's maakt.

In de tijd van brede ADSL/Kabel/Glasvezel lijnen lijkt me de behoefte aan kwaliteit groter worden dan kleine file-sizes.

In de tijd van brede ADSL/Kabel/Glasvezel lijnen lijkt me de behoefte aan kwaliteit groter worden dan kleine file-sizes.

Dit wellicht?
Facebook’s data warehouses grow by “Over half a petabyte … every 24 hours”, according to an explanatory note The Social Network’s Engineering team has issued to explain a new release of open source code.
bron
Facebook heeft zelfs een datacenter laten bouwen voor minder gebruikte fotos, maar ik kan op de vroege ochtend niet zo snel een link vinden.

Laten we aub het milieu uit deze discussie houden...

Het heeft niets te maken met

brede ADSL/Kabel/Glasvezel

.

Plaatjes moeten geserveerd worden en dat kost dus a; opslag en b; bandbreedte.
Nu is dat laatste misschien wat minder erg, maar al met al kun je aardig wat besparen.

Bekijk het even in het wat grotere plaatje:

Stel dat je zelfs 1 bitje zou kunnen besparen, dan is dit met 100.000 views een besparing van 100kb. Reken het zelf uit voor percentages van zo'n 30%, en dan het aantal gebruikers van facebook. Dit zijn immense aantallen die hiermee bespaard kunnen worden.

We hebben niet voor niets dingen zoals caching, minified files en ga zo maar door.
Prima zaak dat er ook eens wat met images gebeurd.

Tweakers zit echter vol van fotografen die fotootjes schieten met onzin resoluties en dergelijke. Een beetje fatsoenlijke foto blijft fatsoenlijk. Wil je perse je high res foto's ergens online hebben, dan moet je al niet eens naar facebook kijken.

Een goede ontwikkeling, als je het mij vraagt.
Als ik zo naar de fotoos kijk zie ik geen kwaliteitsverschil terwijl er beduidend minder bytes worden gebruikt.

Als ik nu naar nu kijk wordt ik al een beetje droef, en met mij veel fotografen. WebP is nog erger, je scherpte gaat helemaal weg.
Dit is leuk voor de fotos die van telefoons worden geupload, maar echte fotos? Daar hoor je keuze bij te hebben. De "high quality" van nu is al bagger, en zonder exif, ook zo'n irritatie.

Hier is een gallery waar je zelf kunt vergelijken. https://developers.google.com/speed/webp/gallery1 het is duidelijk te zien dat de webp foto's van iets mindere kwaliteit zijn in noisy gebieden maar het is zeker niet zo dramatisch als jij claimed. Verder target de gallery een file-size reductie van 30% tov de JPEG afbeeldingen, ongeacht de kwaliteit. Normaal zou je verwachten dat dat andersom gedaan word, zorgen dat de compressie "gelijke" resultaten oplevert en dan kijken naar de filesize.

Verder is er op de andere gallery, https://developers.google.com/speed/webp/gallery2 te zien dat webp ook gewoon lossless compressed. De kwaliteit hoeft er dus niet op achteruit te gaan.

Zoals in het artikel staat, wil Facebook het formaat gebruiken om bandbreedte te besparen. Dat is niet zo gek, want Facebook is helemaal geen fotosite, maar een veredelde chatbox. Als Facebook een dedicated online foto-archief zou zijn, dan zou het droef zijn.

In principe is Facebook geen fotosite, maar als je kijkt naar hun recente beleidsvormingen dan zie je dat er veel focus ligt op de multimedia. Zij hebben juist foto's en video's prominentere plekken gegeven op de tijdslijnen.

Dus ja in principe zijn ze, zoals jij dat noemt een -veredelde chatbox- maar ook met een enorme focus op foto's. Om die reden kan ik het goed begrijpen dat zij overgaan tot deze maatregel, zij hadden laatst namelijk al een compleet nieuw datacenter aangelegd om al die miljarden foto's in op te slaan die minder gebruikt werden.

Om te voorkomen dat ze binnen aanzienlijke tijd weer een data centrum moeten bouwen kunnen ze niet anders dan betere compressiemethodes gebruiken (ze kunnen moeilijk mensen weigeren bepaalde foto's online te zetten, zij leven van de hits die dat oplevert).

Aan de andere kant heb je met jouw argument dat ze geen fotosite zijn in zoverre gelijk dat het gros van de gebruikers niet geeft om hoge foto kwaliteit (neem ik aan) die zijn meer uit op de gezellige familiefoto's met de hond en kids dan wel party foto's.

Voor mensen die wel geven om goede kwaliteitfoto's kunnen ze die ook op hun eigen website of andere dedicated websites zoals tumblr en stumbleupon plaatsen en dat linken als een low-res thumbnail op Facebook.

Je argument over het nieuwe datacenter is niet aan de orde. Dat datacenter wordt gebruikt om foto's te archiveren die weinig worden opgevraagd. Door te archiveren komt er ruimte vrij op de high-end servers die veel meer energie verbruiken. Het ging Facebook dus om de energierekening en de snelheid waarmee het de gebruiker kon bedienen. In dit geval geeft Facebook aan op dataverkeer te willen besparen.

In beide gevallen was de opslag van foto's dus niet het probleem. De datacentra worden dus voor andere redenen gebouwd dan die jij noemt. Sterker nog, door het dubbel opslaan van foto's in beide formaten (JPG en WebP) is er alleen maar méér schijfruimte nodig.

[Reactie gewijzigd door 3raser op 23 april 2013 11:08]

Het lijkt in eerste instantie dat jij gelijkt hebt, maar als je goed bekijkt wat je zelf zegt zie je dat zij die servers echt creeëren omdat ze een opslag en/of i/o tekort hebben vanwege een te hoge hoeveelheid data die afkomt van de grote hoeveelheid foto's:

Zij hebben veel foto's -> zorgt voor veel energieverbruik + lagere snelheid -> bouwen extra datacenter zodat er minder energie wordt verbruikt en het restant van de foto's sneller benaderd kan worden.
De opslag van de foto's was dus wel een probleem want het zorgde voor een langzamere benadering (en een te hoge energierekening).

Daarnaast breng je het argument naar voren dat ze beiden worden opgeslagen (zowel jpg als webp), dit is een valide argument. Ik weet echter niet met diezelfde zekerheid als dat jij naar voren brengt of ze beide of alleen formaat opslaan. Dat valt niet uit het artikel op te maken en daarmee slechts te beredeneren.

Mee eens. Kwaliteit degradeert enorm. Zo zijn de foto's die op Twitter worden gezet zo bedroevend dat ik er niet eens naar kijk.

Ik gebruik liever lossless compressie. Helaas blijven afbeeldingen bij PNG nog relatief groot naar mijn idee. Toch zie ik in de details verschil met JPEG (in positieve zin). Vooral afbeeldingen waarin scherpe lijnen staan of details gaan achteruit met jpeg.

Lossless compressie voor foto's? Zou ik niet doen. Het beste kan je de foto opslaan in hoge kwaliteit jpeg of webp. Je kan namelijk de kwaliteit instellen, van 1 tot 100, zie deze link.

Ik houd altijd in gedachten: Voor foto's jpeg, voor al het andere png. Werkt prima.

Lossless compressie voor foto's? Zou ik niet doen.

Waarom niet? Afgezien van de bestandsgrootte is er niks tegen lossless compressie, toch?

Omdat het niet nodig is. Lossless is alleen zinvol voor archivering, voor de rest is een lossy formaat helemaal in orde als je het goed gebruikt. Dit is een beetje vergelijkbaar met die mensen die 320kbit MP3's gebruiken. Volledige idioterie. De filesize is stukken groter; gebruik dan meteen gewoon Lossless, want transcoderen van lossy naar lossy is gewoon not-done. Wat geluidskwaliteit betreft zit je bij Lame's V4 (i.e. zo rond de 140-150kbit gemiddeld) al bij het punt waarop een encode transparant wordt voor het merendeel van de mensen. Met V2 (gemiddeld zo'n 200kbit) is het transparant voor 99% van de mensen. Als je dus muziek wilt delen om te archiveren of zelf weer verdere encodes van te maken, dan is 320kbit onzin. Dan moet dat in FLAC, APE, etc. Wil je het delen om gewoon naar te luisteren is 320kbit ook onzin. Dan heb je aan V2 of V3 al genoeg.

Hetzelfde geldt wat mij betreft ook voor foto's; rond Q90-92 zit je al aan een modus die nauwelijks nog visuele verschillen geeft als je het gewoon wilt gebruiken om te bekijken. Archiveer je het, of wil je het verder nog gebruiken voor beeldbewerking, dan is TIFF of PNG natuurlijk de enige juiste weg (RAW is natuurlijk nog beter). WebP is gewoon 'yet another goal'; het kan voor het toepassingsgebied internet en webcamsletjes (pardon my french) gewoon een zeer goede oplossing zijn omdat daar geen hoge kwaliteit nodig is - geen hoge kwaliteit gewenst is. Niemand beweert dat het bedoeld is om je vakantiefoto's te archiveren. Het draait gewoon allemaal om toepassingsgebieden.

*edit: ik moet een kleine wijziging in mijn betoog aanbrengen. Het is inderdaad zo dat sommige gecompliceerde samples voor bepaalde compressietechnieken een onoverkomelijk probleem vormen, waarbij ze echter zelfs aan 320kbit vaak nog niet genoeg hebben. Deze stellingen gaan over de overgrote meerderheid.

[Reactie gewijzigd door Buggle op 23 april 2013 12:52]

Dat is jouw mening, maar je brengt het onterecht als een feit. Zeker op een goed en groot systeem (bv. goed afgestelde ElectroVoice, Funktion One of SA) is het verschil tussen 320 Kbit en bijv. 192 Kbit prima hoorbaar.

Dan kan je ook lossless meenemen, maar bijvoorbeeld een USB-stick DJ komt daarmee in de problemen omdat wél alle apparaten MP3 ondersteunen terwijl qua lossless formaten het ene apparaat AIFF slikt (soms wel, soms niet met tags) en het andere weer FLAC.
Buiten dat is er het snelheidsvoordeel en het formaat.

320 kbit is nagenoeg lossless en derhalve voor de meeste mensen meer dan genoeg. Ik koop muziek van Beatport bijvoorbeeld alleen in WAV als het echt iets heel bijzonders is. De rest kan gewoon in 320K en is prima bruikbaar voor alle doeleinden, zelfs archivering.

Dat je het in je tekst dus hebt over "de meeste mensen" ondermijnt je opmerking "Volledige idioterie" van daarvoor.

[Reactie gewijzigd door kakanox op 23 april 2013 09:20]

Je hebt natuurlijk helemaal gelijk. Voor een audiofiel (positief bedoeld) is het kwaliteitsverschil merkbaar. Ditzelfde zal voor fotografen ook zijn met foto's.

Maar je kan met jpeg en webp zo'n grote reductie in filesize krijgen dat het voor "normaal gebruik" en ik denk ook zelfs voor archivering zeker aan te bevelen is.

Ik heb echt hele grote twijfels bij deze bewering. Als je ergens een double blind onderzoek kan vinden waar dit verschil aangetoond kan worden zou je dan een linkje willen posten? Of anders, installeer Foobar2000 met de ABX Comparator plugin en post je eigen resultaten met het verschil tussen lossless en 320 Kbit. Ik ben altijd bijzonder sceptisch tegenover dit soort beweringen. Placebo effect is erg groot als je zelf heen en weer kunt schakelen.

Daarnaast, als je het al kan horen, waar hoor je dat dan? Het enige waar ik een onderscheid kan vinden is als ik heel erg geconcentreerd naar een bekkenslag ga luisteren. En dan heb ik op 160Kbit echt al de grootste moeite.

Ikzelf vergelijk regelmatig 320 Kbs MP3'tjes een AAC uit de iTunes store en wanneer ik deze blind afwissel met de lossless versie hoor ik dat verschil direct. Sterker nog: ik kan mp3 bijna niet meer aanhoren, wanneer je weet waar je op moet letten, ervaar je het als bijzonder irritant en hoor je echt dat de kwaliteit lager is dan je gewent bent . (Gegeven dat je luistert op enigszins fatsoenlijke luidsprekers, een flat EQ en een geluidskaart met een modern s/n).

Hier hoef je echt geen audiofiel voor te zijn, wanneer hier vrienden over de vloer zijn ervaren zij het geluid echt als veel beter, en zijn ze ook overtuigd van de kwaliteit van lossless. MP3 is niet goed genoeg voor de consument, maar omdat MP3 overal is, raakt men er aan gewent en weet men niet meer hoe muziek kan klinken.

Voor wat betreft de vergelijking tussen WebP en JPEG heb ik niet genoeg (kwalitatief) vergelijkingsmateriaal om daar nu een uitspraak over te doen. Nu zag JPEG er op Facebook toch altijd al matig uit (als het al ingeladen werd, want dat duurt soms ook nog wel even). Als ze op deze manier opslag en traffic kunnen besparen is het opzich logisch dat Facebook deze stap zet. En misschien komt er wel een HQ knop voor fotos

Op zich is dat niks gek. AAC was ook bedoeld als opvolger van MP3 vanwege de redenen die jij aangeeft. Heb je ook ervaring met Vorbis? Hoe klinkt dat bij deze hogere bitrates? De wiki pagina zegt dat het vergelijkbaar is met AAC. Kan je hier iets over vertellen?

Ik heb ervaring met vorbis. Zowel positieve als negatieve. Voor mij klonk vorbis op de helft van de bitrate van mp3 ongeveer hetzeflde als de mp3. Dus een 80kbit vorbis tegenover 160kbit mp3. Je kan er dus wel degelijk winst mee behalen. Op hogere bitrates kon ik het verschil niet meer horen, maar ik verwacht eenzelfde soort resultaat.

Echter gebruik ik het tegenwoordig niet meer. De ondersteuning in apparatuur is minimaal en wat me uiteindelijk volledig van het formaat af deed stappen was dat oude bestanden niet meer goed afspeelden op nieuwere decoders, en meldingen gaven als "this file was made by a buggy encoder". Opzouten, vroeger deden ze het ook prima. Blijkbaar willen ze het niet decoden, want als het te detecteren is, is het on the fly te fixen. Door dat soort praktijken wil ik het nu nergens meer voor gebruiken en blijf ik lekker nog vele jaren bij mp3, het enige formaat dat overal in speelt.

Juist ja, de eerste reactie die je krijgt als je zo'n bewering op een serieus audiofielenforum maakt, zoals Hydrogenaudio, bestaat uit drie letters: A, B en X. Meestal met een linkje naar Foobar. Wat er vervolgens van je ge-eist wordt als je dergelijke stelling inneemt, zijn ABX logs om je gelijk te bewijzen.
Ik vind het helemaal prima hoor, dat je verschil hoort, en ik zou het helemaal geweldig vinden als je zulke gouden oren blijkt te hebben (die zijn namelijk in het afgelopen decennium nog niet gevonden). Dat meen ik serieus, dat lijkt cynisch maar dat is het niet. En het gaat mij er ook niet om om je te 'bekeren' of deze overtuiging of geloof van je weg te nemen, maar het is gewoon niet okay dat als een waarheid te verkondigen, omdat deze waarheid voor de algemeenheid niet geldt omdat hij niet objectief gestaafd is - slechts voor jou is hij geldig.

[Reactie gewijzigd door Buggle op 23 april 2013 12:49]

Ik breng het als een feit omdat het een feit is. Ik wist eigenlijk al dat er tenminste een reactie zou komen met 'ik kan het verschil horen', en dat is ook precies de reden waarom er nog steeds mensen zijn die met die 320kbit manie meedoen.
De verschillen die mensen menen te horen worden voor de volle 100% veroorzaakt door placebo-effecten of eventuele andere technische problemen buiten het gebruik van lossy formaten an sich, zoals slechte (instellingen van) encoders of decoders.
Er zijn al duizenden voor u geweest op Hydrogenaudio die hetzelfde beweerden, en keer op keer op keer op keer zijn ze met hangende pootjes afgedropen met en zonder knallende deuren.
In double blind luistertesten is het verschil niet hoorbaar. 320kbit is zinloos. Een lossyformaat voor archivering gebruiken is al helemaal een zonde. Want lossy betekent dat er geluidsinformatie verdwijnt, en dat kan artefacts veroorzaken wanneer je er iets anders mee gaat doen, zoals transcoding of filtering.
Er wordt m.a.w. helemaal niets ondermijnd. Wat je schrijft past naadloos op mijn betoog. MP3 moet je inzetten waar het voor bedoeld is, en dat kan dus inderdaad voor een DJ zijn. Daar is lossless niet voor bedoeld, en ook niet noodzakelijk. 320kbit is dat evenmin.

[Reactie gewijzigd door Buggle op 23 april 2013 12:55]

perssonlijk vind ik 1 bit rate gebruiken verkeerd, maar ok sommige toestellen kunnen niet goed overweg met VBR.
en dan mag je best coderen van 32-640 kbit.
tracks waar een seconde niets gespeeld wordt, mogen gerust op 32 gecodeerd worden.
veel variaties, mogen gerust zo hoog mogelijk gecodeerd worden.
Al bij al zie ik dan het meeste gecodeerd worden tussen de 164 & 192 kbit. en voor het afspelen op gsm & co is dit meer dan voldoende.

Als je audiofiele data wil, mag je enkel lossless werken, maar om naar te luisteren via (imho) minderwaardige apparaten (voor audio dan) speelt het geen rol.
Zeker als je dan al van die oortjes gebruikt.

Je lijkt geen waarde te hechten aan een zeer belangrijk detail: Vrijwel iedereen die iets compressed naar mp3, heeft geen idee welke encoder en welke instellingen het best gebruikt kunnen worden.
Ik ga vanavond thuis die de ABY test doen. Bij de 'standaard' geluiden verwacht ik geen verschil te horen. Als ik een liedje download in de 320Kbit en de 224Kbit versie verwacht ik het wel te horen.

Volgens mij ben jij doof, want ik hoor wel een duidelijk verschil onder de 192kbit. Om dan 140kbit als "goed genoeg" af te doen getuigt niet van weten waar je het over hebt. Zelf gebruik ik altijd de hoogste stand. Dan komt er meestal een VBR uit van rond de 230kbit. Dat zou prima moeten zijn, een goede afweging tussen size en kwaliteit. Iets lager zou nog acceptabel kunnen zijn, maar waarom? Tis niet alsof je tegenwoordig te weinig opslagruimte hebt ofzo.

Het is trouwens erg afhankelijk van het soort audio, of je de compressie hoort of niet. Vooral electrische gitaren klinken heel slecht op lage bitrate.

Waarschijnlijk vanuit het perspectief van een webdeveloper: hogere bestandsgrootte == hogere bandbreedte kosten

Ik zie gewoon mooie foto's voorbij komen op twitter en facebook anders, mischien moet je er eens naar kijken. Natuurlijk als je ze wilt kopieren en uitvergroten wordt het bagger en je kunt ze niet zo goed bewerken. Maar zijn nog steeds prima foto's zoals ze te zien zijn (uitzonderingen daar gelaten)

Aan de andere kant: FB is niet bepaald een platform om hoge kwaliteits foto's te publiceren. Als kwaliteit belangrijk is kan je beter een link in een FB bericht opnemen naar een site waar de foto in al zijn glorie te bewonderen is.

Dat is sowieso verstandig als je graag wilt dat de foto jouw eigendom blijft. Zodra je een foto op FB zet geef je ze vrij baan om te doen met jouw foto wat ze willen.

Kan de fotokwaliteit op Facebook nog slechter dan? De compressie op JPEG die door Facebook wordt gebruikt is echt waardeloos.

WebP is dan ook geen formaat voor fotografen... Je rijdt ook niet rond met een volkswagen gold in de formule 1.

Als ik nu naar nu kijk wordt ik al een beetje droef, en met mij veel fotografen. WebP is nog erger, je scherpte gaat helemaal weg.
Dit is leuk voor de fotos die van telefoons worden geupload, maar echte fotos? Daar hoor je keuze bij te hebben. De "high quality" van nu is al bagger, en zonder exif, ook zo'n irritatie.

Welke idioot upload er TIFF images naar facebook vanaf zijn dSLR anyway?
m.a.w al onze jpeg's worden hoe dan ook gecomprimeerd voor ze het web op gaan, als je mooie diashows wil geven, dan gebuik je toch geen facebook

Hoezo moet je droef worden? Als fotograaf ga je toch serieus geen foto's uploaden op facebook vanwege de kwaliteit? Daar zijn legio andere sites voor. Facebook is een social media. Het is geen fotograven bijeenkomst om kwaliteit te gaan vergelijken...

Je moet de foto's die je op Facebook zet gewoon verkleinen naar 900~1000px, dan blijft je eigen kwaliteit min of meer behouden. Nooit het volledige formaat erop zetten.

@kaaskoekie : Ik vind het moeilijk te zien op zulke kleine foto's. Het is natuurlijk fijn dat Facebook nieuwe dingen uitprobeert, maar de laatste tijd zie ik door de bomen het bos niet meer. Gesponsorde berichten, meer advertenties, een nieuwe layout (waar ik ook niet gecharmeerd van ben) en nu weer dat WebP formaat.

Ik heb al de nodige fratsen uit moeten voeren om Facebook enigermate werkbaar te krijgen (Adblock Plus, DoNotTrackMe, Social Fixer + aangepaste CCS styles) en wordt nu opgezadeld met een bestandsformaat dat Firefox (vooralsnog) niet ondersteund.

Het was beter geweest als ze bij Facebook even hadden gewacht tot alle browsers er mee overweg konden en als er afspraken waren gemaakt omtrent deze "http accept header". De enige die er op dit moment profijt van heeft is Facebook zelf, omdat de belasting op hun serverpark(en) een stuk lager wordt. Gebruikers hebben er momenteel hoofdzakelijk last van.

[Reactie gewijzigd door Titan_Fox op 22 april 2013 20:45]

Dat een grote website (zoals facebook) deze techniek gebruikt zorgt er juist voor dat browsers deze sneller zullen ondersteunen. Als er geen(of niet genoeg) browsers zijn die iets ondersteunen zullen websites het niet gebruiken, als het niet gebruikt wordt zal het ook niet ondersteund worden.

Iemand moet de eerste stap zetten, in dit geval was het facebook.

Dat een grote website (zoals facebook) deze techniek gebruikt zorgt er juist voor dat browsers deze sneller zullen ondersteunen. Als er geen(of niet genoeg) browsers zijn die iets ondersteunen zullen websites het niet gebruiken, als het niet gebruikt wordt zal het ook niet ondersteund worden.

Iemand moet de eerste stap zetten, in dit geval was het facebook.

Eigenlijk dus Google, daar deze 't ontwikkeld heeft en geïmplementeerd heeft in al zijn relevante producten...Facebook zal eerder de stuwende kracht zijn achter 't mainstream maken van dit formaat...

Dan hadden ze eeuwig kunnen wachten... Browsers zijn nou niet echt een samenhangende business die in één keer iets nieuws omarmt. Sterker nog het is echt wachten totdat Microsoft en Apple ook mee gaan.

Ik zie wel degelijk verschil, maar ik weet niet of ik het een voor- of achteruitgang vind. In deze gallerij vind ik bij de eerste foto bijvoorbeeld het water beter in WebP, maar het groen véél beter in JPEG.

Voor een echte goede vergelijking moet je het natuurlijk vergelijken met de originele ongecomprimeerde foto, nu zie je wat kleine verschillen maar je kan het niet vergelijken met het origineel

Je moet niet naar de thumbnails in de gallerij kijken maar de foto's openen in nieuwe tabbladen. Dan kun je snel heen en weer klikken om te zien wat de verschillen zijn. Die zijn in deze voorbeeldfoto's minimaal, zo niet helemaal niet te zien.
Deze voorbeeldfoto's zijn overigens wel erg clean. Ik ben juist benieuwd hoe de verschillen zijn bij foto's van mindere kwaliteit (bijv. afkomstig van phone camera's), foto's met meer ruis, foto's met grotere diversiteit aan kleuren.

Zucht, kijk eens goed naar het plaatje..

Het plaatje is een screenshot van een pagina waarin de plaatjes weergeven worden waarbij de screenshot nog eens gescaled is om het kleiner te maken en vervolgens is het plaatje in een niet al te beste vorm opgeslagen.

Maar inderdaad, op die manier zie je niet veel verschil nee..

Overigens wat ik een belangrijkere stap vind dan van jpg naar webp is dat die lelijke gifjes toch echt eens vervangen moeten worden met apng.

En terug naar de jaren '90 waarbij elke knop of link voorzien was van een lelijke geanimeerde pijl 100% van de tijd?

Nee bedankt. Kleine animaties kunnen perfect met wat CSS of een gif voor dingen zoals loading cirkels e.d.

Wil je een filmpje tonen? Gebruik dan een formaat dat daarvoor dient.

En terug naar de jaren '90 waarbij elke knop of link voorzien was van een lelijke geanimeerde pijl 100% van de tijd?

Nee bedankt. Kleine animaties kunnen perfect met wat CSS of een gif voor dingen zoals loading cirkels e.d.

Wil je een filmpje tonen? Gebruik dan een formaat dat daarvoor dient.

Dat lag vooral aan de beperkte bandbreedte én crappy internet explorers...als je maar 14k4-56k hebt, dan is het laden van een plaatje van 20-100kb al verbinding slopend. Zeker als je dan ook nog eens een browser hebt die niet meer dan 2 simultane http streams open kan hebben(zoals IE6), dan kan je dus niet meer dan 2 elementen tegelijk in laden over een stronttrage verbinding

Zeker als je dan ook nog eens een browser hebt die niet meer dan 2 simultane http streams open kan hebben(zoals IE6)

Hoeveel je ook kan zeggen over IE6, de HTTP 1.1 standaard (RFC 2616) schrijft letterlijk voor:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.

IE'tje schoppen is altijd zo makkelijk en lekker, maar ga nou niet ook nog zeiken als ze een keer de standaarden wel goed volgden in 2001 al. Je kon het via de registry ook nog gewoon disablen als je wilde.

APNG is geen standaard en is nog lang niet bij iedere browser ondersteund, laten we zwijgen over een correcte implementatie.

Liever gewoon met inline video's.

Voorbeeld: http://developer.android....ing-blocks/scrolling.html

Zou Florian Mueller van Fosspatents.com dit ook niet tegen willen houden? webp is ook vp8.

Zou Florian Mueller van Fosspatents.com dit ook niet tegen willen houden? webp is ook vp8.

VP8 is een video compressie standaard owned by...Google...

Ja, maar Florian Mueller en z'n clubje hebben patenten. En daar willen ze stoute dingen mee doen.

Misschien kan dan de kwaliteit wat omhoog tov nu, want nu is de compressie af en toe echt storend aanwezig!

Als hierdoor Facebook sneller wordt, zeg ik kom maar op met die compressie. Ik ben zelf een Chrome gebruiker dus ben benieuwd.