Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 44, views: 15.791 •
Submitter: Balance

Facebook heeft Firefox-ontwikkelaar Mozilla openlijk verzocht om ondersteuning voor het WebP-formaat in de browser in te bouwen. De sociale netwerksite wil meer gebruik gaan maken van het nieuwe compressieformaat, dat op dit moment alleen ondersteund wordt door Chrome en Android.

De Facebook-programmeur die de implementatie van WebP overziet, Bryan Alger, heeft Mozilla in een post op de bugtracker aangemoedigd het lossy compressieformaat te gaan ondersteunen, meldt Cnet. Mozilla was eerst geen voorstander van het WebP-formaat. Sinds vorige maand is de Firefox-ontwikkelaar zijn positie echter aan het heroverwegen.

In april begon Facebook op beperkte schaal met het nieuwe compressieformaat te experimenteren. Van foto's wordt een kopie in het WebP-formaat opgeslagen om die vervolgens te serveren aan browsers die het formaat ondersteunen. Alger geeft in zijn post aan dat de sociale netwerksite enthousiast is over het formaat. Hij noemt het zeer aannemelijk dat het gebruik van het WebP-formaat op korte termijn zal worden opgeschaald.

WebP werd in oktober 2010 door Google aangekondigd. Het formaat is bedoeld voor het opslaan van afbeeldingen en comprimeert volgens de zoekgigant gemiddeld 39 procent beter dan de jpeg-standaard. Op dit moment ondersteunen alleen producten van Google, Chrome en Android, het formaat. Als de Opera-browser overstapt op de browserrenderengine Blink zal deze het formaat vanzelf ook ondersteunen. Het formaat wordt echter nog magertjes ondersteund door grafische software, het is daarom nog steeds lastig om met bestanden in het formaat te werken. Facebook-gebruikers klaagden hier ook regelmatig over.

Reacties (44)

Dus het is vanwege de slechte ondersteuning van het WebP formaat dat Mozilla nog geen ondersteuning biedt? Tja, het begin moet toch ergens zijn en juist het web lijkt uitstekend geschikt voor dit formaat (daar is het dan ook voor bedoeld?).
Het is een afweging die gemaakt dient te worden. Aan het implementeren van een nieuwe standaard zitten veel kanttekeningen.

Op het moment wordt jpeg gebruikt, wat wereldwijd geaccepteerd is en uiterst goed ondersteund wordt. Ook vervult jpeg tot op heden zijn doel prima. De vraag is dan of je wil overstappen op een marginaal beter formaat. Het zijn namelijk niet alleen de grote browser waar een verandering op zal moeten treden. Denk bijvoorbeeld ook aan verouderde software (op mobiele telefoons, ongeupdate browser etc). Daarnaast is er ook veel andere software die op dit moment het formaat niet ondersteund. Zo is het bijvoorbeeld met een standaard windows installatie niet mogelijk om te afbeelding te tonen, laat staan aan te passen. Voor webdevelopment zal dit voornamelijk betekenen dat er meerdere formaten ondersteund zullen moeten worden, wil jij als webdeveloper het WebP-formaat gebruiken. De vraag is of jij als grote partij (lees: Mozilla) zaken wel die kant op wil sturen. Eindelijk is het zover dat alles vrij goed gestandariseerd is op het web in vergelijking met voorheen. Willen we terug naar de tijd van de oude IE verhalen, waarbij je een site bijna apart diende te ontwikkelen voor verschillende browsers? En dit alles vanwege een standaard, waarvan de voordelen toch wel enigszins discutabel zijn.


edit:
Een paar kritische reacties op de uitspraak, dat de voordelen van een implementatie van WebP disctutabel zouden zijn :) Mijn inziens is dit echter wel disctutabel.

Allereerst wordt er gesproken over een compressiewinst van 40% op afbeeldingen. Dit is niet waar. De gemiddelde winst is ongeveer 25% tot 35% (bron). Daarnaast moet je er rekening mee houden dat de afbeeldingen die onderdeel vormen van de interface van Facebook ontwikkeld zijn om gecomprimeerd te worden met GIF. Dit is een formaat dat aanzienlijk kleinere bestanden oplevert dan zowel jpeg als WebP. Daarnaast is het zo dat de winst afhankelijk is van de grootte van een afbeelding. Voor kleinere afbeeldingen (o.a. thumbnails) is de relatieve winst kleiner i.v.m. overhead door headers en dergelijken. De winst in bandbreedte zal dus behaald worden bij foto's. (Vergeet niet dat Facebook ook video's host.) In hoeverre het gebruik van WebP een reductie oplevert wat betreft bandbreedte voor Facebook is niet bekend. Wat dit vervolgens aan kostenbesparing zou opleveren is daarmee ook niet bekend.

Tot zover de besparing voor Facebook, wat ik tevens een kwalijk argument vind. Het invoeren van WebP zal namelijk voor veel partijen kosten opleveren (ontwikkeling) en ongemakken met zich meebrengen (eindgebruikers zonder ondersteunende software). Daarnaast zal de mogelijke bandbreedte reductie niet interessant zijn voor de gemiddelde website. Ik durf best de aanname te maken dat een slechts één byte besparing in de interface van Facebook voor Facebook zelf een aantoonbare besparing op zal leveren gezien het aantal gebruikers van hun diensten. Het financiële voordeel voor één bedrijf mag echter niet het argument vormen voor het invoeren van een nieuwe standaard.

Persoonlijk zou ik voor het web liever een ontwikkeling zien wat betreft vectoriële afbeeldingen. Veel webgraphics zijn begonnen als vectoriële afbeelding die velen malen kleiner was. Daarnaast zijn dergelijke afbeeldingen ook beter schaalbaar en zullen in de toekomst een nog groter verschil maken (denk aan de toenemende resoluties van beeldschermen).

[Reactie gewijzigd door DEVoTi0N op 9 mei 2013 16:41]

Aan de andere kant, laten we alles zoals het is omdat we nu eindelijk standaarden hebben die voldoende ondersteund zijn, komt er ook nooit ontwikkeling!

het is goed als browsers dit gaan ondersteunen. Webdevelopers zijn dan nog steeds niet verplicht om het ook te gaan gebruiken. Voor de webdeveloper is er dus geen enkel probleem. Voor degenen die met beeldbewerking werken is het mogelijk lastig als websites alleen webP afbeeldingen gebruiken, maar dat is niet de schuld van de implementatie door de browsers.

Ik zou het goed vinden als Mozilla dit gaat ondersteunen, mits ze voldoende mankracht hebben om niet andere ontwikkelingen te vertragen. Juist in browsers verwacht je een snelle implementatie van nieuwe ontwikkelingen, zodat nieuwe mogelijkheden snel beschikbaar komen. (wat nogmaals niet wil zeggen dat iedereen verplicht is die mogelijkheden ook te gebruiken).
Op het moment wordt jpeg gebruikt, wat wereldwijd geaccepteerd is en uiterst goed ondersteund wordt. Ook vervult jpeg tot op heden zijn doel prima. De vraag is dan of je wil overstappen op een marginaal beter formaat.
Ik ben het met je eens dat de acceptatie van WebP heel belangrijk is en eventueel een obstakel kan vormen. Zeker in het begin. Echter, gemiddeld 39% meer compressie noem ik absoluut niet marginaal. Waarschijnlijk zijn voor FaceBook foto's de grootste bandbreedte vreter. Dan is het begrijpelijk dat ze enthousiast zijn als ze gemiddeld 39% bandbreedte kunnen besparen op dat grote deel.
Al is het natuurlijk wel de vraag hoe de kwaliteit is vergeleken met JPEG. Ik kan me wel voorstellen dat voor thumbnails en kleinere afbeeldingen WebP prima voldoet.
Ik vind bijna 40% procent betere compressie niet marginaal beter. Vergeet niet dat foto's met een ruime marge de meeste bandbreedte opeisen bij het tonen van een webpagina. Dat betekent dus dat de totale bandbreedte voor het surfen op Facebook al snel met ruim 30% wordt teruggedrongen (39% minus de fixed overhead van HTML+CSS+JS+sprites).

Op de schaal waarop Facebook opereert betekent dat dat ze vele miljoenen kunnen besparen, simpelweg door een ander image format te ondersteunen. Voor de eindgebruiker zal het een merkbare snelheidswinst opleveren (zeker op mobiel!). Persoonlijk noem ik dat niet "marginaal beter" en ook niet "discutabel". Dat zijn simpelweg zeer significante besparingen.

Er zijn eigenlijk maar 2 nadelen:
- Het is voor de web developer werk om te implementeren. Maar gezien de reactie van Facebook zijn ze maar wat blij om die effort te nemen, logisch gezien de besparing.
- Het kan verwarrend zijn voor de eindgebruiker die right-click Save doet op de foto en vervolgens het formaat niet herkent. Dit is een tijdelijk probleem totdat WebP meer bekend wordt, en bovendien eenvoudig te ondervangen met een "Download original"-link.
tja, maar als je de afbeeldingen werkelijk met elkaar vergekijkt, zie je toch duidelijk een kwaliteitsverschil op dezelfde groottes, waardoor imho de toegevoegde waarde van webp zeer gering is, anders dan dat het zogenaamd licentievrij zou zijn.
tja, maar als je de afbeeldingen werkelijk met elkaar vergekijkt, zie je toch duidelijk een kwaliteitsverschil op dezelfde groottes, waardoor imho de toegevoegde waarde van webp zeer gering is, anders dan dat het zogenaamd licentievrij zou zijn.
In het geval van Facebook is de kwaliteit ( vooralsnog ) ondergeschikt aan opslagruimte.
Facebook pretendeerd niet een "gallery / showcase" te bieden, zoals Flickr of anderen dat wel doen.

FB wil foto's, niet om de foto's, maar voor klantenbinding, en met voorkeur voor geintegreerde locatiedata, om hun "diensten" nog verder uit te breiden.
Dat FB dit soort requests maakt is in mijn ogen niet meer dan normaal, elk "zichzelf respecterend" bedrijf wil zaken doen, en het liefste op zijn voorwaarden, of zo dicht mogelijk.
Niets mis mee, mijn werkgever stuurt ook verzoeken naar partners en opdrachtgevers die gunstiger voor ons ( als bedrijf ) zijn.

Omdat FB in de schijnwerpers staat, is het ineens wereldnieuws dat zij zoiets doen.
Het is geen standaard maar een formaat. Daarom is er nog minder reden om met alle haast het te ondersteunen. Laat het eerst maar volwassen worden en richting standaard gaan.

Ik vraag me wel af of Google nu ook iedereen die jpeg gebruikt een rechtszaak gaat aansmeren om zo toch hun formaat te kunnen doordrukken zoals ze met Microsoft geprobeerd hebben rond H264 om WebM te kunnen doordrukken of heeft Google geen patenten kunnen bemachtigen in de patentenpoel van jpeg?

[Reactie gewijzigd door olapola op 9 mei 2013 21:48]

Alsnog word ik ook niet vrolijk van alle lossy compressiemethoden, ik had juist gehoopt dat we inmiddels naar absoluut lossless kunnen nu bijna iedereen in nederland een internetverbinding heeft die daar niet zo'n problemen mee heeft.
In Nederland, ja, maar er zijn hele gebieden in de UK, zelfs in London (waar ik woon) waar je het moet doen met DSL over Victoriaanse kabels. En ik vrees dat ik op die manier op mijn kamer slechts zo'n 2-4mbit kan krijgen. Wifi moet je niet proberen in deze stad. Fiber to the Home of Kabel internet is ook niet mogelijk (kabel = Virgin eigenlijk exclusief, en die zijn nogal krenterig, apart primitief land dit)
Hoewel er wel wat overlap is tussen de begindagen van telefonie en de nadagen van het leven van koningin Victoria zullen de meeste aansluitingen in London toch echt post Victoria zijn.
Niet alleen in de UK, maar ook bij gebruik van mobiel internet. Ik merk dat mijn telefoon toch nog heel vaak terug valt naar GPRS of EDGE. 30-40% kleinere bestanden overdragen is dan toch écht heel fijn.

Verder is het sneller laden met een snelle verbinding ook belangrijk. Het verschil tussen 0,5sec laadtijd en 1 sec laadtijd is subjectief heel groot.
maarja als de kwaliteit dan ook een stuk minder is, dan zie ik het voordeel niet...
Die 30 tot 40% procent reductie in bestandsgrootte is bij dezelfde (subjectieve) kwaliteit.
nu bijna iedereen in nederland een internetverbinding heeft die daar niet zo'n problemen mee heeft.
Je dacht toch ook niet dat het zozeer om de eindgebruiker gaat? Een server die echter 30-35% minder bytes hoeft te verzenden zonder dat daar echt veel moeite voor genoemen hoeft te worden*, daar heeft facebook natuurlijk wel oren naar.

( * want laten we wel wezen, als ergens winst gepakt zou kunnen worden zou het wel in de pagina's zelf zijn, die 39KiB van de hoofdpagina alleen al (oningelogd) zit tjokvol onnodige (voor de eindgebruiker) troep. )
Het gaat ook niet om de gebruiker.
What do you do with an exabyte of digital photos that are rarely accessed? That was the challenge facing Jay Parikh and the storage team at Facebook.
http://www.datacenterknow...centers-for-cold-storage/

Een procent minder storage scheelt al een berg geld.... En dan hebben we het nog niet over de kosten van FBs bandbreedte gehad als WebP wordt ingevoerd.
Ze resizen je fotos nu al, met een nogal agressive setting, verwijderen de exif, etc, om de fotos zo klein mogelijk te maken.

Persoonlijk zie ik niets in WebP zolang het niet wordt ondersteund door Adobe, MS, en ga zo maar door.
Dit is een interessant artikel, waarom Google WebP belangrijk vindt.

Volgens Google bestaat 60% van het internetverkeer (alleen browsen, dus geen torrents of andere zaken) uit afbeeldingen, waarvan weer 80% comprimeerd is met jpeg. Daarnaast zou WebP een verbetering in compressie van 35% moeten opleveren t.o.v. jpeg. Een snelle rekensom levert op dat een volledige implementatie van WebP ongeveer 17% in bandbreedte zou moeten besparen. Als consument is dit misschien niet geheel interessant, maar voor elk serverpark is dit een enorm getal. Een dergelijke reductie in bandbreedte (en tevens opslag) zou een mooie besparing opleveren en het enige wat men daarvoor moet doen is een ander formaat gebruiken.

Daarnaast ben ik het ook niet eens met je argument betreffende lossless-compressie. Het idee van lossy compressie is dat brondata veel overbodige informatie zou bevatten voor de eindgebruiker. Mocht jij het materiaal opnieuw willen gebruiken voor andere doeleinden, dan alleen kan het interessant zijn om alle brondata te bezitten. Door slechts de 'belangrijke' data slim te selecteren en op te slaan kan een enorme winst geboekt worden in compressie. Ondanks een aantal stugge critici is al veelvuldige aangetoond dat een eindgebruiker lossy gecrompimeerd materiaal niet kan onderscheiden van lossless (uitgaande van het feit dat de compressie niet te hoog is). Zo kunnen mensen een 320 kpbs mp3 niet onderscheiden het orgineel. Ook een met h.264 comprimeerde video van een bluray pik zal jij deze er niet uit kunnen pikken. Het probleem bij afbeeldingen is dat je makkelijk de pixels naast elkaar kunt leggen en verschillen kan aanwijzen. Op het blote oog zal dit echter niet zichtbaar zijn. Kortom: Ik ben niet van plan om alle afbeeldingen op mijn site te gaan vervangen door de orginele raws die uit mijn camera kwamen rollen. Dit zou de prestaties van mijn site gigantisch achteruit halen en mijn hostingkosten vertienvoudigen. Stel je voor dat Facebook dit zou doen :P
Opera werkt al langer met webp. Zij gebruiken het onderandere in Opera Turbo
De kwaliteit van de fotos op Facebook zijn al bedroevend, ik zit totaal niet te wachten op nog een formaat die het nog minder doet dan de kwaliteit van de huidige JPEGs (afgaand op deze screenshots: http://webp.googlecode.com/files/webp-samples.zip, welke duidelijk waziger zijn).
Welke duidelijk waziger zijn??? Ik zie eigenlijk geen verschil. En zeker voor gebruik op een website kan ik me voorstellen dat een betere compressie zonder in kwaliteit te verliezen zo zijn voordelen heeft.
Als je geen verschil ziet dan zou je of kritischer moeten kijken, of inderdaad gewoon accepteren dat kwaliteit er voor jou niet zozeer toe doet.

Nou moet ik wel zeggen dat alleen die sample plaatjes, weer opgeslagen als PNG, niet zoveel nut heeft. Immers weten we zo niet hoe groot de WebP plaatjes zijn, of zowel JPG als WeP vanuit zelfde bron komen (JPG her-opgeslagen als WebP), etc.

Gelukkig ondersteunen IrfanView, XNView en The GIMP WebP, dus iederaan kan ook gewoon z'n eigen tests draaien. Voor veel mensen zal het echter een geval zijn van "zodra mijn mobiel/camera in WebP opslaat, zal ik het wel gebruiken".
Er is vooral meer ruis/korrel uitgehaald. Ik vraag me af of je wanneer je de korrel in fotosoftware al verwijdert/vermindert met Jpeg niet hetzelfde kunt halen.
Maar ja, al die standaard 8-10 mpixel bagger telefoonuploads stikken natuurlijk van die ruis/korrel, en die gaat niemand photoshoppen.
Facebook kan beter investeren in een slimme downsample op de server.
Als ik kijk naar de afmetingen van de samples in de Google code-voorbeelden zijn de WebP-afbeeldingen 5x zo groot (bijvoorbeeld afbeelding 1: jpeg 137 kB en WebP 576 kB). Dat is appels met peren vergelijken, zo kan ik het ook!!

Tegenvaller dat Google op deze manier geen echt goede vergelijking laat zien.

Wellicht is dit wat "eerlijker": https://developers.google.com/speed/webp/gallery1
@HDoc,

De afbeeldingen uit de voorbeelden zijn weer opgeslagen als PNG vandaar dat de bestandsgrootte een stuk groter is.
Heel wat viewers ondersteunen nog geen WebP namelijk.

Jou link laat in ieder geval in Chrome al duidelijker verschil zien. Nu nog een dergelijke vergelijking met foto's van formaat. Misschien dat er dan duidelijker verschil tussen jpeg en WebP te zien is.
Opera support WebP al sinds versie 11.10, gereleased op 27 april 2011 :)

http://www.opera.com/docs/changelogs/windows/1110/

[Reactie gewijzigd door HuRRaCaNe op 9 mei 2013 14:37]

Wat een onzin, aan de serverkant maakt het Facebook hoegenaamd niets uit. Het gaat om de verbindingen van de eindgebruiker (en denk dat niet alleen aan Nederlanders met glasvezel en kabel maar ook aan mobiele gebruikers).
Tuurlijk gaat het wel om de serverkant, anders is het sowieso een non-argument. Je praat over enkele kilobytes besparing hier, per afbeelding, niet over enkele megabytes. Voor de eindgebruiker maakt dat dus geen klap uit, zelfs niet als hij op een 56k6 modempje zit. Al die afbeeldingen bij elkaar dan heb je het opeens over gigabytes of meer, en dat kan voor Facebook dus wel degelijk interessant zijn.

Ik ben overigens geen voorstander van webp, met name omdat de techniek door Google uitgebracht is, en ze zijn momenteel al invloedrijk genoeg. Goed, het schijnt een open standaard te zijn maar zou toch liever zien dat die ergens anders uit voortkwam.
Onzin? Door de WEBP formaat heeft facebook juist minder opslagruimte te hebben en stoken ze minder dataverkeer.

En als we de cijfers van nieuws: Facebook heeft meer dan 900 miljoen actieve gebruikers bijhalen, worden er op een dag minimaal 300 miljoen foto's geüpload. Dat gaan ze echt wel merken in de opslag en dataverkeer stats.
Voorlopig is het juist méér opslagruimte en minder dataverkeer, aangezien nog niet iedereen WEBP kan ontvangen moeten ze ook JPEG's opslaan, en het bronbestand moeten ze ook opslaan, want de al gecompresde JPEG's converteren naar WEBP zal ws. ook niet echt een success zijn.
Maar volgens mij is als WebP opslaan en als jpg serveren precies wat ze nu al wel doen.
Dat is ofwel heel erg resource intensief, als elk plaatje on the fly geconverteerd moet worden naar JPEG, ofwel netto hetzelfde resultaat omdat de resultaten door de server gecached worden, waardoor alsnog de JPEG-versie op een server opgeslagen staat.
facebook is toch groot (en rijk) genoeg om een aantal programmeurs een patch te laten maken voor firefox en die te submitten.
Dat kan, maar ik neem aan dat Mozilla wel gaat overwegen of het ook daadwerkelijk in Firefox gaat komen en zo ja, hoe en wanneer.

Stel je voor dat iedere Jan Doedel dat zou doen die vindt dat er iets anders moet in Firefox, direct submitten en erin, dat zou een mooie bende worden ;) .
Niet zo zeer een bende als veel patches die gewoon niet geaccepteerd worden.
Ach, zelfde probleem als met APNG, dat ook nog bijna nergens gebruikt wordt... Omdat bijna geen software het kan exporteren, en maar een paar browsers het ondersteunen. Waaronder Firefox!! Dus het "niet gebruikt worden" van WebP is nogal een bullshit-argument van Mozilla, want dan hadden ze APNG ook niet moeten implementeren.

[Reactie gewijzigd door _Thanatos_ op 9 mei 2013 16:42]

Ik denk dat het absoluut een goede zaak zou zijn dat Firefox het WebP-formaat zou ondersteunen.

Ten eerste kan de bestandsgrootte van afbeeldingen toch met 20 à 30 percent verkleind worden. Of, misschien nog beter, kunnen er bij dezelfde filesize kwalitatief betere prentjes worden afgeleverd (of een compromis tussen deze twee uitersten).

De Gallery van Google is trouwens de moeite om eens te bekijken (best wel met een browser die WebP ondersteunt :p) Op sommige foto's zijn typische jpeg-foutjes verdwenen (zoals bijvoorbeeld de "puntjes" aan de randen van de bloemen op deze foto). Langs de andere kant gaat dat soms wel ten koste van scherpte in kleine details (bijvoorbeeld in het water rechts onderaan op deze foto) en zijn er soms "blokken" te herkennen op sommige stukken (zie bovenaan in de lucht op de WebP-variant van deze afbeelding).

WebP heeft trouwens heel wat opties om de kwaliteit van de afbeeldingen in te stellen: compressiefactor (0-100), deblocking filter (blokken versus "smoothness"), spatial noise shaping (verdeling van de hoeveelheid gebruikte bits per gebied in een afbeelding)...Het lijkt dus wel nodig om de juiste balans hierin te vinden, zeker bij een sterkere compressie.

Een tweede reden om WebP te gebruiken is de ondersteuning van transparantie. Hoewel dit eigenlijk los staat van de foto's op Facebook, is dit volgens mij wel het belangrijkste argument om dit formaat te implementeren. Op dit moment wordt vooral PNG ingezet om afbeeldingen met transparantie op het web weer te geven (o.a. dus knoppen met afgeronde hoeken en andere prentjes die niet vierkant of doorzichtig zijn). Hoewel PNG een schitterend (lossless) formaat is, levert dit wel erg grote prentjes op voor online gebruik. Op dat gebied presteert het lossy WebP-formaat gewoonweg veel beter. (en het is ook een eenvoudigere methode in vergelijking met het gebruik van een "mask" in een ander formaat als alpha-channel voor een jpeg- afbeelding). Deze argumentatie zou overigens ook gevolgd worden door Andreas Gal (vice president mobile engineering van Mozilla (http://news.cnet.com/8301...-heart-about-webp-images/).

Na wat lezen ben ik toch overtuigd van het nut van WebP, zeker omdat het als lossy (en open) formaat toch volledige ondersteuning voor transparantie biedt. Voor foto's zijn er misschien wel nog verbeteringen mogelijk, o.a. een manier om de verschillende opties (deblocking filter) op een eenvoudige manier te optimaliseren.

Op dit item kan niet meer gereageerd worden.



Populair: Desktops Vliegtuig Luchtvaart Crash Smartphones Laptops Apple Games Besturingssystemen Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013