Cookies op Tweakers

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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 226 reacties
Submitter: azortje

Google heeft een nieuw beeldformaat aangekondigd. Het WebP-formaat is opensource, en biedt een beduidend hogere compressieratio dan jpeg en jpeg 2000 bij gelijke beeldkwaliteit. Google heeft een conversietool voor WebP uitgebracht.

Volgens Google maken plaatjes en foto's ongeveer 65 procent uit van het aantal verstuurde bytes bij het laden van webpagina's. Een groot deel daarvan is afkomstig van jpeg-plaatjes. Het nieuwe WebP-beeldformaat levert volgens Google een reductie van gemiddeld bijna veertig procent op wat betreft grootte van het beeldbestand. Net als jpeg is WebP een lossy compressiemethode.

Google baseert zich bij zijn claims op een vergelijkend onderzoeken dat het heeft uitgevoerd tussen WebP, Re-JPEG en JPEG 2000. Google heeft deze drie compressiemethodes losgelaten op een dataset van in totaal 900.000 plaatjes, waarbij het grootste gedeelte bestond uit jpeg-bestanden. Bij WebP leverde dat een gemiddelde afname in bestandsgrootte op van bijna veertig procent. Re-JPEG en JPEG 2000 bleven in de test steken op een percentage van respectievelijk 14,62 en 9,71 procent. Als parameter voor de beeldkwaliteit werd de signal-to-noise-ratio aangehouden.

Het WebP-beeldformaat is gebaseerd op de VP8-codec die ook gebruikt wordt in het WebM-videoformaat van Google om de keyframes in video te comprimeren. De WebP-container is gebaseerd op RIFF en voegt slechts 20 bytes overhead toe met behoud van de mogelijkheid om in de toekomst de header uit te breiden met nieuwe metagegevens. WebP heeft een maximaal formaat van 16.383x16.383 pixels en maakt gebruik van 14bit-encodering. Google heeft een gallery online gezet waarbij de beeldkwaliteit en bestandsgrootte van originele jpeg-bestanden vergeleken kunnen worden met de WebP-versies. Volgens het Chromium-blog moet het nieuwe formaat in de toekomst ook ondersteuning bieden aan het transparante alpha-kanaal.

Google heeft een WebP-conversietool voor ontwikkelaars op zijn site gezet waarmee beeldbestanden naar het nieuwe formaat kunnen worden omgezet. De commandline-tool verkeert nog in het bèta-stadium. Het is volgens Google niet nodig om alle jpeg-plaatjes direct om te zetten naar WebP-formaat. Servers zouden namelijk on-the-fly WebP-versies van plaatjes kunnen serveren als een WebP-compatibele browser wordt herkend, zo blijkt uit een vraaggesprek van CNet met Richard Rabbat, projectleider van Google's 'Make the web faster'-project.

Google WebP beeldformat compressie voorbeeld

Moderatie-faq Wijzig weergave

Reacties (226)

1 2 3 ... 6
je kun hier een file downloaden om de verschillen tussen jpeg en webp goed te kunnen beoordelen

persoonlijk zie ik weinig verschil, maar sommige afbeeldingen lijken een vreemde 'waas' te hebben, net alsof er iemand een screenprotector over 't plaatje heeft gelegd :x
Ik dacht al dat het aan mij lag... in sommige afbeeldingen ziet het er top uit, in andere worden de kleuren dof. En dat voor ongeveer 30% winst. Ik hou het wel bij JPEG.
Inderdaad. En sommige voorbeelden (bijvoorbeeld die blinde muur in het eerste voorbeeld) verliest veel detail. Ik kijk op 100% met een HD scherm, dat zal voor het detail niveau ook wat uitmaken, maar met het oog op de toekomst kijkt straks iedereen er naar met een HD scherm.

De plaatjes uit het voorbeeld zijn origineel JPEG's, maar de WEBP afbeeldingen zijn opgeslagen als PNG's.
Wordt daarmee wel een goed beeld gecreŽerd, of is alles nog zo prematuur dat nog niemand een oordeel kan geven over WEBP?
PNG is lossless, een bestand opgeslagen in dat formaat geeft dus accuraat weer wat voor uitwerking de WebP compressie op het plaatje heeft.
PNG-24 is lossless, maar de bestandsgrootte is vele malen groter dan JPEG. Als je een JPEG op de maximale kwaliteit exporteert (100%, dus zonder kwaliteitsverlies) is het nog steeds de helft in grootte van PNG. Daarmee is PNG wat mij betreft geen goed alternatief. PNG-8 (en ook PNG-24) zijn beide beter dan GIF bij lijntekeningen, maar missen de mogelijkheid van animatie.
Bij png kan animatie aan worden gehacked, animatedpng.com.
Echter enkel ondersteunt door Firefox (andere browsers laten een stilstaand plaatje zien).

png hoeft niet noodzakelijk groter te zijn dan jpg trouwens, er zijn situaties waarbij een png beter compressed dan jpg (om een voorbeeld te noemen, bij gradients).
Het is net andersom, alleen als het een bijna strak/egaal/simpel plaatje is
zal PNG winnen. Meer detail, of meer gradients, meer foto realistisch, JPG wint.
Dan heb jij nog nooit een background gradient voor een website zo klein mogelijk proberen op te slaan (een verticale overigens, geen idee of het bij horizontal anders ligt). PNG is in dit specifieke geval superieur aan jpg.

Daarbij kan bij een 'simpel' plaatje jpg nog steeds beter zijn.

Dit is trouwens uit de tijd dat ik nog handmatig een aantal plaatjes zo klein mogelijk probeerde te maken, op het moment is het makkelijker om Smush it van Yahoo te gebruiken die elk formaat met diverse settings probeert om tot een zo klein mogelijk resultaat te komen.

[Reactie gewijzigd door Xthemes.us op 2 oktober 2010 14:37]

Met de naar png geconverteerde webp-bestanden kan de beeldkwaliteit ten opzichte van het originele bestand vergeleken worden, maar je moet niet kijken naar de bestandsgrootte van de png-files. De stap naar png is nodig omdat je browser nog geen webp-ondersteuning heeft. webp-bestanden zullen kleiner zijn dan de jpeg-originelen.
PNG is ook niet bedoeld als alternatief. PNG is gebruikt omdat bijna niemand een viewer heeft voor webp. Om toch te kunnen zien wat het resultaat van de webp compressie is hebben ze dus een pixel exacte representatie van het webp plaatje in een lossless container gestopt. Ze hadden ook een bmp kunnen doen, maar die is nog groter.
Images in the left column are JPEG originals; images in the right column are the WebP-converted equivalent. Since browsers do not currently support WebP, we used a PNG container to allow users to see these WebP images in a browser.
Hetzelfde geldt voor losse image viewers, die hebben ook geen webp ondersteuning, dus hoe zou je die plaatjes anders willen bekijken. PNG is juist de beste keuze omdat het lossless is (de png versie ziet er exact hetzelfde uit als de webp versie, zo kan je dus de beeldkwaliteit van webp beoordelen) en relatief kleine bestanden geeft.

[Reactie gewijzigd door Bonez0r op 1 oktober 2010 14:13]

daarnaast heb je uit de PNG-stal ook nog MNG: http://nl.wikipedia.org/wiki/Multiple-image_Network_Graphics al is dat nooit echt populair geworden

[Reactie gewijzigd door Hiub op 1 oktober 2010 14:45]

Ik kijk op 100% met een HD scherm, dat zal voor het detail niveau ook wat uitmaken
Bedoel je dat je het schermvullend bekijkt? Het plaatje is 800x440, door het schermvullend op een HD scherm te bekijken zie je echt niet meer detail. Je ziet hooguit de compressie-artefacten duidelijker.

Begrijp ik trouwens goed dat het origineel steeds jpeg was en ze die geconverteerd hebben naar webp? Nogal een oneerlijke vergelijking dan, omdat alle jpeg artefacten dan ook in de webp versie te zien zijn (plus eventuele webp artefacten), waardoor de webp versies er altijd slechter uitzien. Voor een goede vergelijking moet je natuurlijk lossless originelen hebben, bijvoorbeeld tiff direct uit de fotocamera en die omzetten naar zowel jpeg als webp.
Voor een eerlijke vergelijking wel (Zoals ik boven ook in een van mijn posts had getypt dus ik ben het echt wel met je eens ;)) mŠŠr voor hun doel, on the fly jpeg omzetten in WebP als de clientbrowser het aankan, zijn dit soort vergelijkingen wťl correcter. Het bootst namelijk perfect de use case die google in gedachten had na. (Daar denk ik ook pas nu aan)
Het is zijn zachtst gezegd zeer vreemd dat er met JPEG materiaal als source wordt gewerkt en niet een lossless formaat, zodat men het verschil in kwaliteit tussen JPEG en WEBIP kan vergelijken.

Als ik het voorbeeld van de amerikaanse voetballer zo zie lijken er toch aardig wat details overboord gezet.

Hogere compressie is leuk, maar kan het formaat ook hogere kwaliteit aan ? Want om een volledig geaccepteerd formaat te worden zal dat ook moeten.
Bij enorm grote websites met veel afbeeldingen kan die 30% veel uit gaan maken, dan wordt het toch een aardig groot bedrag aan dataverkeer dat minder nodig is. Zeker met grote afbeeldingen zoals een header en de afbeeldingen op je homescreen, dan kan dat veel schelen.

Neem nu de Tweakers 2009 Website van het Jaar afbeelding die links staat, die is nu 12KB groot. Als dat met 33% verminderd wordt naar 8KB scheelt dat toch aardig wat op lange termijn.
Als we uitgaan van 3 miljoen unieke bezoekers per maand kom je al uit op 36000000KB per maand, dat is 35156,25MB en 34,33GB. Dat is toch een aardig aantal dataverkeer alleen al aan unieke gebruikers, en zelfs al zou voor een groot deel van de mensen die afbeelding gecached worden, als je het met 33% kan terugdringen zal het dataverkeer dat veroorzaakt wordt door iedereen die de afbeelding de eerste keer inlaad al teruggedrongen worden naar 22.65GB.

Nu is dit niet het ideale voorbeeld misschien maar het gaat om de strekking, op grote schaal kan het nogal een impact hebben.

[Reactie gewijzigd door Tsurany op 1 oktober 2010 12:02]

Inderdaad, wat te denken van bijv. Hyves. Al die foto's zijn JPEG, en het zijn er miljoenen.
En die zouden door Hyves of Facebook automatisch op de achtergrond omgezet kunnen worden zonder dat de gebruiker het merkt.
Alhoewel dit per afbeelding wel weer een eenmalige performance impact heeft, en natuurlijk een impact op de opslag omdat ze alle plaatjes nu tweemaal op moeten slaan.

Een partij als Google kan dat wel, die hebben zo'n enorm cluster dat ze die overcapaciteit wel hebben (zie bijvoorbeeld youtube, waarin filmpjes nu in meerdere formaten en encodings opgeslagen worden). Facebook zou dat ook wel kunnen, maar voor Hyves heb ik mijn twijfels of het voor hun veel oplevert.
Nee en nee. Als je het goed regelt dan zal alleen conversie plaatsvinden als je servers niet op 100% draaien, dus geen snelheidsverlies. De bestanden die geconverteerd worden kunnen meteen vervangen worden dus van opslagverdubbeling zul je ook geen last hebben.
inderdaad, als je iedereen die niet early-adopter is een pagina vol rode kruisjes wilt voorschotelen kan dat makkelijk.
*reactie op Zigi_Samblak*

[Reactie gewijzigd door thedicemaster op 1 oktober 2010 14:10]

@thedicemaster:

Denk niet dat ze de hele database zouden gaan converteren voordat alle gangbare browsers de standaard aankunnen, jij wel?
Ehh, als je geconverteerde bestanden vervangt, hoe ga je dan 'legacy users' die geen WebP ondersteunen bedienen ? En 'on-the-fly' conversie op de server klinkt leuk, maar levert natuurlijk erg veel CPU load op; of die overcapaciteit er is om het zonder merkbare vertraging te doen blijft imho twijfelachtig ...
@SKILLa
Het resultaat van "on the fly" compressie kan natuurlijk worden gecached, zodat dit maar 1 keer hoeft te worden gedaan. Zo blijft zowel de CPU load als storage gebruik minimaal.
Facebook resized en resampled alle fotos (Hyves weet ik niet), en dat is knap irritant want alle EXIF informatie gaat verloren. Maar dat kan dus makkelijk geimplementeerd worden. De gemiddelde gebruiker zal het niet merken, totdat je meer informatie wilt.
Bij enorm grote websites met veel afbeeldingen kan die 30% veel uit gaan maken, dan wordt het toch een aardig groot bedrag aan dataverkeer dat minder nodig is. Zeker met grote afbeeldingen zoals een header en de afbeeldingen op je homescreen, dan kan dat veel schelen.

Neem nu de Tweakers 2009 Website van het Jaar afbeelding die links staat, die is nu 12KB groot. Als dat met 33% verminderd wordt naar 8KB scheelt dat toch aardig wat op lange termijn.
Als we uitgaan van 3 miljoen unieke bezoekers per maand kom je al uit op 36000000KB per maand, dat is 35156,25MB en 34,33GB. Dat is toch een aardig aantal dataverkeer alleen al aan unieke gebruikers, en zelfs al zou voor een groot deel van de mensen die afbeelding gecached worden, als je het met 33% kan terugdringen zal het dataverkeer dat veroorzaakt wordt door iedereen die de afbeelding de eerste keer inlaad al teruggedrongen worden naar 22.65GB.

Nu is dit niet het ideale voorbeeld misschien maar het gaat om de strekking, op grote schaal kan het nogal een impact hebben.
Leuk, zo'n flinke besparing, maar heb je alleen wat aan als de gebruikte browser overweg kan met het webp formaat. Zolang dat er niet is, heeft het geen zin de afbeeldingen om te zetten in webp lijkt mij.

Ik ben dus zeer benieuwd wat Google gaat doen ter promotie van WebP.

[Reactie gewijzigd door CH40S op 1 oktober 2010 13:46]

Met wat geluk zit dit heel snel in Chrome, en Firefox volgt ook wel. Daarna wordt het wachten op de grote overschakeling van MS, maar tot die tijd kan men 2 sites serveren, waardoor er alsnog een bandbreedtebesparing optreedt. Over ruimte op de server heeft men nog niet echt te klagen dacht ik :P

(Daarnaast zou Google ook een knuppel in het hoenderhok kunnen gooien en bijvoorbeeld bij de Google Images alle kleine formaten als WebP serveren. Als Microsoft het dan niet ondersteunt, gaan ze heel veel klachten krijgen ;) )
Daarnaast zou Google ook een knuppel in het hoenderhok kunnen gooien en bijvoorbeeld bij de Google Images alle kleine formaten als WebP serveren. Als Microsoft het dan niet ondersteunt, gaan ze heel veel klachten krijgen
dan zouden ze wel lekker hypocriet bezig zijn met hun "don't do evil" (als in: je eigen 'standaard' opdringen)
Sowieso is het voor een grote commerciele speler als Google niet vol te houden om zo'n motto echt altijd en in elk detail na te leven, maar ik ben het met je eens dat botweg opdringen niet in hun straatje past.
Lijkt me dan een knuppel waarmee je gelijk de helft van je "klanten" wegknuppelt.
Om nog maar te zwijgen over de snelheidswinst in interne throughput die het kan schelen bij sites als Dumpert of bijv pornosites idd :)
Lijkt mij dat het nog wel beter wordt, of is JPEG ook nooit meer geupdate na de eerste release?

De kleuren zijn naar mijn inziens ook wat minder kleurig (dof dus), er valt nog wel wat te verbeteren dus ;)
Wat ikzelf wel heel grappig vind is dat ze zeggen dat OP HET MOMENT ze jpegs kunnen recoden met +-40% winst...

Dat is allemaal leuk en aardig, maar als die webp standaard dan nog niet eens alpha channel bevat en wellicht andere dingen die JPEG wel bevat vind ik dit niet echt een nuttige uitspraak gezien je niet weet of die 40% wel intact blijft bij verdere ontwikkeling en verbetering van webp.

Overigens hebben ze het over 'slechts' 20 bytes voor de metadata.. maar dan kan er wel weer (in de toekomst) allerlei dingen aan toegevoegd worden..

Ja lekker nutteloos dus die 40% bestandsgrootte reductie bij een incompleet afbeeldingsformaat wat nog (ongetwijfeld) enorm gebloat gaat worden met meerdere functies, metadata en overhead.

Overigens vind ik zelf Jpeg ook al een rot formaat tenzei het op hoge resolutie is.

Je zou denken dat ze met de voortdurende verbetering van verbindingssnelheden en dataoverdracht/verwerking in computers zelf (incl. opslag grootte, IO operaties op nieuwe SSD harde schijven etc) wel een beetje af zouden stappen van 'less is more' en die lossy formaten langzamerhand vervangen zouden worden voor lossless formaten.

(zoals .flac tegenwoordig een mainstream vervanger is geworden voor .mp3 muziekbestanden)
Standaard JPEG kent geen alpha channel. Bovendien gebruikt waarschijnlijk 90% van de beelden op het internet geen alpha channel. Als bij gelijke kwaliteit een gemiddelde bestandsreductie van 40% kan worden gerealiseerd dan is dat winst voor een heleboel partijen.

Het 'less is more' principe blijft momenteel erg interessant, vooral bij mobiele toepassingen, en laat dat nu juist de toekomst zijn...
alpha in jpeg??
en flac een mainstream vervanger voor mp3?? op computers van sommige audiofielen misschien, maar echt niet op telefoons en mediaspelers e.d. met beperkte opslag
in deze tijd komen met een imageformaat zonder alphakanaal is 'silly'.
't zou mooi zijn als ze wel een alpha kanaal hebben, maar zonder doen ze niet onder voor het formaat dat bijna door iedereen gebruikt wordt: jpeg. Dus hoe zou dat silly zijn. Bovendien snap ik de downvotes op opmerkingen over dat alfakanaal niet. Het is een terechte opmerking: jpeg heeft ůůk geen alpha kanaal, dus voordat je webP basht zonder reden moet je een 'get your facts right' fase doorgaan. WebP heeft veel reden om nog wat kritiek te krijgen (*) maar dit is niet een van de juiste redenen. Normaal moet een post met 3 punten aan hogere standaarden voldoen.

*Kleuren zijn idd dof met momenten, en ik heb zo mijn bedenkingen bij vergelijkingen tussen raw -> jpeg en een die jpeg->webp. Ik zou liever raw->jpeg & raw->webp vergeleken zien, ben aan het nadenken of het iets uit zou maken bij de resultaten, maar het is iig zo eerlijk.
Ik weet niet zeker of de voorbeelden echt slechts een conversie van JPEG naar Webp is. Als je kijkt op de voorbeelden die google geeft oogt Webp een stuk scherper. Kijk maar eens naar een hele dunne witte rand rond het oranje en rood van de foto met de pastoor (de muur schildering). Het is allemaal wat scherper en aangezien JPEG en Webp lossy formaten zijn zou de conversie van de JPEG naar Webp het geheel niet scherper gemaakt hebben. Ik geloof daarom ook niet dat het van JPEG overgezet is maar dat het beide RAW > JPEG/Webp conversies zijn.

Ik ben het wel eens dat de kleuren iets doffer ogen, maar aangezien het een opensource formaat is moet dit niet zo'n probleem zijn te tweaken naar beter ogende kleuren. Een ander kleuren profiel gebruiken of deze aanpassen zou al enorm veel helpen. En als ze een alpha kanaal kunnen toevoegen (optioneel of niet) zonder de bestandsgrootte al te veel veranderen zal dit zeker een formaat zijn die we veel terug zullen gaan zien de komende jaren.

Dat zou zo al 10 tot misschien wel 20% van mijn dagelijkse server bandbreedte kunnen schelen. Ik ben in ieder geval altijd voorstander voor minder bandbreedte gebruik! Mits het natuurlijk niet onder doet aan de gebruikers ervaring.
Er zijn al wel een paar telefoons die Flac ondersteunen. En als je een lossless media formaat ondersteunt is dat meestal flac
(en flac klinkt wel echt beter. Lijkt bij goede speakers een "dieper" geluid te geven, en nee je plastic dure speakers zijn (waarschijnlijk) geen goede speakers. Ja ook als ze heel duur waren.)
Aha, dieper geluid... Klinkt dan ook veel beter....
Sinds wanneer bevat JPEG een alpha channel?
jpeg is al erg kaal.
voor zo ver ik zie heeft webM al vrijwel alles wat jpeg heeft.
alpha is iets dat niet ondersteund wordt in jpeg.

ik ben wel blij dat er eindelijk een lichtgewicht afbeelding formaat komt dat veel kleuren, en alpha channel ondersteund.
.gif en .png zijn de enige veel ondersteunde afbeelding formaten in browsers die een alpha channel ondersteunen, maar png is vrij zwaar en gif ondersteund maar 256 kleuren in 1 afbeelding.(.bmp kan ook als het moet transparantie aan, maar dit wordt vrijwel nergens ondersteund en BMP is alsnog ook vrij zwaar)
Gif is wel degelijk true-color, maar er zijn nauwelijks programma's die het ondersteunen.
http://phil.ipal.org/tc.html
...
Dat is allemaal leuk en aardig, maar als die webp standaard dan nog niet eens alpha channel bevat en wellicht andere dingen die JPEG wel bevat vind ik dit niet echt een nuttige uitspraak gezien je niet weet of die 40% wel intact blijft bij verdere ontwikkeling en verbetering van webp.
...
Voor zover ik weet, heeft het huidige JPEG formaat geen Alpha Channel. Iemand meer info?

[Reactie gewijzigd door Bux666 op 1 oktober 2010 13:47]

er gaat juist steeds meer verkeer over mobile devices. Dus minder is nog steeds meer, en ik zie er zeker een "markt" voor.
(zoals .flac tegenwoordig een mainstream vervanger is geworden voor .mp3 muziekbestanden)
En waar inmiddels ook alweer een lossyflac voor uitgevonden is ;)

Maar ik zit niet per se op een nieuwe 'jpeg' te wachten. Als ik hogere kwaliteit wil neem ik wel een ander formaat en voor de ruimtebesparing hoef ik het nieuwe formaat niet te hebben.

De kleuren zijn minder helder, maar dat was al gemeld.
Misschien wel omdat er godsgeklaagd veel webpagina's zijn en de meeste dataoverdracht komt door het laden van afbeeldingen. Als we allemaal zo mierenneukerig worden over onze precious beeldkwaliteit op webpagina's dan mag de wereld wel heeel hard opschieten met dat glasvezelnetwerk, want dan is het namelijk niet bij te houden.

Aangezien 99 procent van de webgebruikers geen maling zal geven om het verschil tussen jpeg en webp wat ik persoonlijk ook niet zie, is dit een goed initiatief.

Websites als facebook, waarbij de foto's toch al zo zijn verkleind dat het weinig uitmaakt, zal dit heel veel dataverkeer en dus geld schelen.

[Reactie gewijzigd door JohnAD op 2 oktober 2010 11:29]

.flag een mainstream vervanger noemen voor .mp3 leef jij alleen op deze wereld ofzo?
Ben een groot voorstander van FLAC en groot tegenstander van mp3, maar helaas is FLAC nog niet mainstream te noemen. mijn mp3 speler ondersteunt het wel maar mijn draaitafels nog niet. die ondersteunt alleen wav als lossless en dat is vervelend taggen.
Heeft dat niet iets te maken met embedded kleurprofielen?
Inderdaad, ik mag toch zeker hopen dat WebP kleurprofielen ondersteund, en we niet afhankelijk zijn van allerlei generic RGB profielen die verschillen per browser. Het gaat met browsers eindelijk de goede kant op (ze ondersteunen nu zo'n beetje allemaal embedded kleurprofielen), laten we dat lekker zo houden.
Zover ik weet ondersteund elke browser sRGB, het standaard kleurenprofiel voor gebruik op internet. Als de bron (.jpg/.png/.bmp en dergelijke) geen profiel embedded heeft ligt de fout bij de gene die het bestand gecreŽerd heeft, niet bij het bestandsformaat of de browser.
of is JPEG ook nooit meer geupdate na de eerste release?
JPEG is een beschrijving van de compressie (een standaard).
Hoe dat uitgevoerd wordt en daaruit voortvloeiend de kwaliteit hangt af van het programma die de compressie uitvoert. Dat wil dus nogal verschillen tussen verschillende programma's die plaatjes als JPEG's kunnen opslaan.
Waarmee bekijken jullie de foto's ik zie dit effecht namelijk niet. Alle afbeeldingen zien er nagenoeg exact hetzelfde uit bij mij. Zelfs ingezoomd.

@ ludOnline (hierboven ergens) - die eerste foto is best lage resolutie (heel klein afgebeeld bij 100% bekijken op een HD monitor?), zowel de jpg en de png hebben weinig detail en ik zie practisch geen verschil als ik ze over elkaar leg.

[Reactie gewijzigd door knirfie244 op 1 oktober 2010 12:15]

Ze zijn dan inderdaad klein. Wat ik probeerde te zeggen was dat ik zonder er moeite voor te doen (inzoomen, op elkaar leggen, etc.) verschil in detail kon zien.

Voorbeelden:
Kijk naar de gele blinde muur links op de eerste foto.
Als je daar op de omgeving van die donkere streep bovenaan let en je schakelt tussen de twee afbeeldingen zie ik gewoon dat de PNG/WEBP doffer is. De textuur van het stuc werk valt weg.

De tweede foto. Let eens op de rimpels op het voorhoofd van de sporter.

De volgende vraag is of dit detail verlies erg is. Maar voor een vergelijking vind ik het geen zuivere voorbeelden.
Digitenne zegt altijd dat het zonder rimpels beter is...
voor de bezoeker van een site kan ik me voorstellen dat ze de witte waas vervelend vinden, maar als bouwer van de site (of eigenlijk hoster) is het van het grootste belang om zo veel mogelijk te kunnen laten zien met zo min mogelijk datatransfer.

ik kan me wel een paar oplossingen bedenken hoe je van beide formaten optimaal gebruik kan maken, wanneer de wit achtige waas niet verdwijnt is nieuwere versies. Je zou bijvoorbeeld kunnen denken aan een overzicht pagina waar de plaatjes met WEBP compressie getoond worden, om zoveel mogelijk plaatjes in een zo kort mogelijke tijd te kunnen tonen. Vervolgens wanneer je een grotere versie van het plaatje wil zien kan je 'm tonen met JPEG compressie. toegegeven, het neemt wel meer data in op de HDD. Maar het is al jaren zo dat opslag vele malen minder kost dan datatransfer.
Ik weet niet welke plaatjes jullie bekijken, maar ik zie nergens een kleurverschil. Her en der wel wat verschil in detail, maar kleurverschil, nee :S

Ik gebruik irfanview in fullscreen en spring heen en weer tussen de jpeg en webp versies. Misschien hebben jullie ze naast elkaar open op de desktop of zo? Dan kan je minder goed de verschillen zien en het kan ook beoordelingsfouten opleveren als je een monitor met tn-paneel hebt (slechte kijkhoeken die kleurverschillen geven). Ook op niet-tn panelen is dat in mindere mate nog steeds zo.

[Reactie gewijzigd door Bonez0r op 1 oktober 2010 14:20]

Ik snap niet dat zoveel mensen de JPG's in de gallery van betere kwaliteit vinden dan de WebP's.

Als je naar de laatste 3 foto's kijkt, zie je duidelijk dat WebP veel mooier is.

- Kijk bij het stadion eens langs de rand van het stadion bij de JPG. Je ziet allemaal ruis rond de rand.
- Kijk bij de ruimte met stoelen eens naar de verste stoelen. Bij JPG allemaal puntjes/ruis en bij WebP helemaal niet.
- Kijk bij de boot eens naar de letters op de voorste boot. Veel smoother bij WebP.

En kijk dan ook nog eens naar het bord. Bij JPG zie je eigenlijk alleen Ay....ham en bij WebP zie je veel duidelijker Aylesham staan.

Dus even afgezien van alle andere discussies, vind ik de WebP voorbeelden er WEL veel beter uitzien.
Ik snap niet dat zoveel mensen de JPG's in de gallery van betere kwaliteit vinden dan de WebP's.

Als je naar de laatste 3 foto's kijkt, zie je duidelijk dat WebP veel mooier is.

- Kijk bij het stadion eens langs de rand van het stadion bij de JPG. Je ziet allemaal ruis rond de rand.
- Kijk bij de ruimte met stoelen eens naar de verste stoelen. Bij JPG allemaal puntjes/ruis en bij WebP helemaal niet.
- Kijk bij de boot eens naar de letters op de voorste boot. Veel smoother bij WebP.

En kijk dan ook nog eens naar het bord. Bij JPG zie je eigenlijk alleen Ay....ham en bij WebP zie je veel duidelijker Aylesham staan.

Dus even afgezien van alle andere discussies, vind ik de WebP voorbeelden er WEL veel beter uitzien.
Bij de stadionfoto is goed te zien dat de jpg versie scherper is. Bij WebP is de ruis gewoon wat vervaagd. Kijk maar eens naar de lichtjes aan de rechterkant van het stadion.

Bij de stoelen is goed te zien dat bij WebP de randen van de stoelen mooi egaal zijn en bij jpg blokkerig is.

Bij de ene foto is jpg beter, bij de andere Webp. Op basis van deze voorbeelden kan ik nog geen voorkeur uitspreken.

Aanvulling, wat me ook opvalt, en dat is goed te zien bij de foto's van de boten is dat de verhoudingen niet gelijk zijn. Dat hoeft niet aan het WebP-formaat te liggen maar kan bij de conversie naar png hebben plaatsgevonden. Nog een reden waarom het op deze manier niet te vergelijken valt.

Kleurverschillen zijn er niet in mijn ogen in elk geval niet.

[Reactie gewijzigd door Amorax op 1 oktober 2010 17:40]

Die scherpte bij Jpeg is natuurlijk ook juist de zwakte van het algoritme. Het is een artefact wat soms leuk uitpakt bij shitty vakantiekiekjes, maar heel storend is als je een klant laat zien wat de print gaat worden. Als je alles strak scherp hebt en print ready met een unsharp mask kan je geen stevig gecomprimeerde jpeg sturen omdat het er krankzinnig uit gaat zien.

Op vrij softe plaatjes en wat beperktere compressie werkt het soms als een ogenschijnlijke verbetering, maar ik ben er maar zelden blij mee.

Daar het menselijk oog enorm gevoelig is voor een bepaald soort scherpte namelijk edges (komt door onze evolutionair bepaalde gevoeligheid voor patroonherkenning en wijzigingen in patronen die een ´alert´ signaal afgeven wordt het door veel leken als beter gezien.

Kleur speelt in de psychologische waarneming nauwelijks een rol en zeker correcte kleur niet omdat we een ingebouwde witbalans correctie hebben in die cpu tussen onze oren. Verzet je monitor van het af fabriek paarse 9000 graden Kelvin naar normaal referentie daglicht en je neemt het plaatje waar als geel. Kijk vijftien minuten naar iets anders en dan weer naar datzelfde beeld en mijn klanten zijn er zeker van dat ik de monitor weer teruggezet heb :)

Kleur helderheid is dan helaas weer wel een evolutionair bepaald detectie mechaniek, dus vandaar dat ansichtkaarten al overgesatureerd geleverd worden. Ook hier geldt dat de professional dat heel beperkt toepast terwijl als er miniaturen voor galleries en websites geleverd moeten worden het zeer aan te raden is omdat het gewoon een ratrace is tussen wie het verst losgegaan is met de saturatie slider.

Zie ook de gemiddelde televisie shop met alles in ´winkel mode´ met maximum sharpness, 9000 kelvin tl´s settings en maximum saturatie om de tv er naast er uit te blazen. De grootste treurnis is nog wel dat mensen het ding ook zo gebruiken thuis! Als je hem dan netjes afregelt zeggen ze dat ie flets, vaag en geel is :)

Anyway dat maakt dat die vergelijkingen met kleine jpegs versus WebP een exercitie in het niets zijn en dat er in dit topic dus tegengesteld over geoordeeld wordt. Google had dit ook moeten weten en een betere presentatie techniek moeten gebruiken. Nu gaat het er toe leiden dat WebP getuned gaat worden naar de typische jpeg artefacten en daar ben ik dan bijvoorbeeld weer heel ongelukkig mee.
Ben ik niet met je eens, als ik naar die samples uit de ZIP kijk ziet het er bij veel van WebP's uit alsof er een waas overheen zit, kleuren zijn ook fletser en sommige punten zijn scherper terwijl andere minder scherp zijn.

Maar ook als de WEBP's mooier waren is dat naar mijn mening geen goed teken. De Jpeg's hier zijn namelijk het origineel en WebP wijkt (bij sommige foto's zeer duidelijk) af na de compressie dus je verliest hier consistentie.

Als WebP later een export mogelijkheid wordt vanuit Photoshop bijvoorbeeld en je begint met een RAW bestand en voert uit in WebP en in JPEG en het enige verschil is dan de grootte van het bestand. Of als WebP dan het origineel dichter weet te benaderen. Dan zie ik deze standaard wel zitten. Als blijkt dat WebP dan meer afwijkt dan de Jpeg van het origineel dan niet zo, ongeacht de winst in bestandsgrootte.
Je vergeet een belangrijk argument: toepassing. Een afbeelding hoeft niet altijd 100% correct te zijn, sterker, in veel gevallen is een benadering voldoende. Pas wanneer details een rol gaan spelen is de kwaliteit belangrijk.

Ik zou dit voor de galleries meteen willen omarmen.
Ik zie inderdaad alleen bij Foto 7 een lichtere waas. Verder zou dit natuurlijk een kleine snelheidswinst hebben, als je kijkt naar de grootte van de foto's/plaatjes. Al merk je dit beter bij wat langzamere verbindingen.
Je redeneert vanuit een gebruiker. Voor de gebruiker zal het nauwelijks verschil maken. Meeste websites laden toch "instantaneous" op onze breedbandverbindingen.

Het gaat natuurlijk veelmeer om de vereiste bandbreedte in je Datacenter als sitebeheerder. Daar maken vele kleine beetjes een groot beetje. Gezien je betaald voor je gebruik, ligt er dus een solide business case voor dit soort verbeteringen.
Niet iedereen is er even enthousiast over.

Waarschijnlijk is die mening wel wat gekleurd door het feit dat VP8 als vervanger voor H.264 gemaakt is, en deze x264 ontwikkelaar daar ook niet erg blij mee is, maar zijn opmerkingen zijn wel op feiten gebaseerd.

Google zal vermoedelijk de plaatjes die WebP in een negatief daglicht zetten niet in een vergelijking meenemen. En signal-to-noise ratio zegt niet alles over kwaliteit. Kleiner is leuk, maar als je daarmee aan kwaliteit inboet is dat m.i. onnodig.
Kleiner is leuk, maar als je daarmee aan kwaliteit inboet is dat m.i. onnodig.
Dus je vindt jpeg ook onnodig? En mp3, ook onnodig? Daar boet je namelijk ook aan kwaliteit in. Wel is er bij lossy opslag altijd een afweging tussen kwaliteitsverlies en ruimtewinst. En waarschijnlijk zal ook webp, net als jpeg, verschillende niveaus van compressie bieden. In het geval van de gelinkte galery staat duidelijk dat het om vergelijkbare kwaliteit gaat en de bestanden zijn beduidend kleiner. Daaruit kan ik alleen maar concluderen dat webp *dus* beter is.

Vergeet ook niet dat de originelen steeds jpeg plaatjes waren en die zijn geconverteerd naar webp. Ale artefacten die al in de jpeg plaatjes zaten zitten dus ook in de webp versies. Pas als web browsers en image viewers het formaat gaan ondersteunen zie je echt het verschil. Of je kan nu alvast dat programma downloaden en zelf vergelijken door originele lossless opgeslagen plaatjes om te zetten naar beide formaten en die onderling vergelijken voor een echt eerlijke vergelijking.

[Reactie gewijzigd door Bonez0r op 2 oktober 2010 13:39]

Ligt het aan mij of is dat nieuwe formaat zelfs GROTER dan zijn origineel?
Dat ligt aan jou dan. Als je kijkt op http://code.google.com/speed/webp/gallery.html dan zie je dat in alle gevallen de webp versie kleiner is dan de jpeg versie. Vaak scheelt het zelfs tientallen procenten.
De foto's 1 en 7 zijn eigenlijk de enige foto's waar ik echt verschil zie. Maar zeker goede ontwikkeling van google. Als je ook nog compressie kan instellen zodat foto's met veel contrast en kleur goed blijven kan dit wel eens een succes worden
Ik heb daar alleen last van bij het donkere plaatje (verlicht gebouw @ night). Wel apart. Daar vindt ik de jpeg er duidelijk beter uitzien.
Hm, bij al die voorbeeldplaatjes is het webp bestand (veel) groter dan de jpg, dus dat kan niet een eerlijke vergelijking zijn.

Dubieuze voorbeelden van Google,aangezien het formaat juist compacter zou moeten zijn =]
Omdat nog geen browser WebP ondersteund... is het resultaat van het WebP plaatje als png (lossless) weergegeven...
En er is geen mogelijkheid om die meuk middels een java(script) tooltje uit te pakken? 8)7
Hoe zie je dat voor je? Uitpakken, als in gezipt? En hoe wil je ze dan tonen als je nog geen software hebt die het kan tonen? Wat heeft java ermee te maken?
Hm, bij al die voorbeeldplaatjes is het webp bestand (veel) groter dan de jpg, dus dat kan niet een eerlijke vergelijking zijn.

Dubieuze voorbeelden van Google,aangezien het formaat juist compacter zou moeten zijn =]
Aha, dus jij hebt een browser die dit nieuwe formaat al aankan?
Denk even na en je snapt waarom de rechterbeelden groter zijn. Moet lukken.
Dat is niet zo heel gek, want de Webp-afbeeldingen zijn lossless opgeslagen als PNG, puur voor de vergelijking. Als ze je het (kleinere) Webp-formaat zouden sturen zou je het niet kunnen openen.
Heb jij al een webP codec op je pc staan, om de plaatjes te bekijken in het nieuwe formaat? Zeer waarschijnlijk niet. Deze zijn daarom opgeslagen in een lossless codec, zodat het resultaat te zien is met gebruik van reguliere codecs (png).
Nou ik weet het niet wat er kleiner aan is met die sample files. Ik zie original.jpg en webp.png en elke webp.png uit het voorbeeld zip is een factor 3 groter dan de originele jpg's.

Neem bijvoorbeeld 7_original.jpg (3.5mb) en 7_webp.png (13.1mb)

Of ik zie het helemaal verkeerd natuurlijk.

Update: Even bij google code gekeken het is in png formaat gezet nadat het geconverteerd is om het kwaliteit verschil te zien. Ik kan op mijn monitor geen verschil zien tussen de afbeeldingen. Maar ik heb dan ook geen ips panel...

Nou ik wacht nog even af totdat we de codec daadwerkelijk kunnen proberen en een raw image omgezet in zowel jpg als webp kunnen vergelijken.

[Reactie gewijzigd door PegOpDeWeg op 5 oktober 2010 09:46]

Ik houdt het toch lekker bij jpeg en png, laatste is klein met goede kwaliteit. En jpeg is toch echt beduidend beter dat dit nieuwe product van Google.

Uiteindelijk zal het wel wat worden, maar dit staat nog in de kinderschoenen. Om eerlijk te zijn vindt ik het beeld inderdaad een beetje flets, net of er een waas overheen zit en hij is ook niet altijd even kleurgetrouw.

Waarom eigelijk geen alternatief voor Gif met goede kwaliteit? Dan hebben we nog altijd iets voor animaties in een simpel afbeeldingsformaat ipv. flash, silverlight of iets dergelijks.

[Reactie gewijzigd door mac-er op 1 oktober 2010 11:48]

Waarom eigelijk geen alternatief voor Gif met goede kwaliteit?
Dat is er, in de vorm van MNG ( van dezelfde makers als PNG). Alleen is dat helaas nooit aangeslagen, omdat IE het verdomde te ondersteunen. ( de patenten van concurent GIF waren in handen van Unisys, en dat is/was een groter partner van Microsoft ). Toen de LZW patenten afliepen is iedereen maar gif blijven gebruiken, omdat het zo ingebakken was.

Spijtig, MNG is veel beter.
Ik houdt het toch lekker bij jpeg en png, laatste is klein met goede kwaliteit. En jpeg is toch echt beduidend beter dat dit nieuwe product van Google.
Hoe zo weet jij nu al dat JPG beter is? Ik ben erg onder de indruk na wat stoeien met dit nieuwe formaat. Laat eens wat van je testjes zien waarin het nieuwe formaat slechter is?

Vertel beste man, vertel....
Ik dacht dat PNG het open source alternatief voor JPG was?
wat is daarvan de compressiefactor?
PNG kent geen compressie, daarom is het een heerlijk formaat om te gebruiken op het web (als je, zoals ik, compressie haat), net als FLAC heb je geen last van kwaliteitsverlies of andere meuk.

Compressie is niet nodig met de breedbandverbindingen van tegenwoordig, die paar milliseconden die het langer duurt om een PNG te laden zijn het wel waard voor het kwaliteitsverschil en het alpha channel.
PNG gebruikt wel degelijk compressie, deze is alleen losless.
Daarnaast is je stelling dat compressie niet nodig is met het tegenwoordige internet ondoordacht. Mensen moeten door hebben dat het internet net als onze planeet maar een bepaalde hoeveelheid resources geeft, we moeten er zuinig op zijn.

Het argument dat computers tegenwoordig snel zijn is geen excuus om sloome, zware, loge slecht geprogrammeerde en ondoordachte programma's te maken.
It's a series of tubes!

Het internet is een resource die niet echt op kan, maar op een gegeven moment zullen wel wel de infrastructuur moeten uitbreiden omdat de servers, gateways, en pipes verzadigd raken. Als dit 30% kan schelen in de plaatjesbandbreedte is dat natuurlijk mooi meegenomen, ook al zal dit vooral voordeel bieden voor de content hosters. Ik kan wel een kwart seconde langer wachten op een jpeg.
640kb should be enough for everyone
bill gates, 1981

:)
640kb should be enough for everyone
bill gates, 1981
Is niet van Bill Gates, voor de zoveelste keer. |:(
bandbreedte wordt steeds hoger, reslouties ook. De rede voor compressie is natuurlijk meer door die bottleneck te pompen. Als we gaan van 20mbit/s naar 100mbit/s glasvezel dan kunnen we wel zuinig doen en zorgen dat onze snelle verbinding maar 1% belast wordt bij het openen van een website maar dat gaat tegenwoordig natuurlijk nergens over.

Bandbreedte zal alleen maar hoger worden en op den duur kun je prima photobucket in raw hebben. Lijkt mij iig alleen maar goed. Ook opslag gaat vooruit. 2Tb schijven zijn al vrij normaal. Over een aantal jaren is dat natuurlijk alleen maar meer.

Ik denk dat je beter vooruit kunt denken ipv stil blijven staan bij stoffige ideeen van vroeger. Gaat er tegenwoordig nog iemand geld opnemen binnen bij de bank in plaats van even te pinnen? scheelt weer een actie.

Het hele omzetten van bestanden naar 'mindere kwaliteit is ook een actie die overgeslagen kan worden en daarmee bespaar je. Het is niet zo dat je op het laden van een website minuten zit te wachten als de bestanden groter zijn. Daar hebben ze al zg thumbnails voor bedacht. En zelfs die zijn in de toekomst hopelijk niet meer nodig.

De hele rede dat een OS stapje voor stapje uitgebreider wordt, meer kan, mooier wordt is omdat de ontwikkeling van hardware erachteraan hobbelt. Windows 7 konden ze in 19 windows 95 ook, maar er was geen computer doe dat aankon.

Schijfruimte is geen probleem meer en upgraden van alle hardware tussen jou en online opslag waar de website staat blijft voor altijd nodg en geeft voor altijd vooruitgang. Het is geen race met een eindstreep maar ontwikkeling die niet zal stoppen..

Als ik zie hoe dof WEBP eruit kan zien lijkt dit geen vooruitgang maar pushen van een mogelijkheid omdat er al geld in zit. Hoe meer geld erin wordt gestopt hoe meer je het tegen zal komen. Ik ben voor open formaten. png gebruik ik als transparantie nodig is en anders .jpg met zo weinig mogelijk compressie. Als er nog mensen zijn met 1mbit/s download is dat nou eenmaal hun probleem. Ze maken ws een afweging kosten/kwaliteit en kiezen voor lage kosten. Een afbeelding van betere kwaliteit is zoals het woord al zegt kwaliteit. Windows 7 is ten opzichte van windows 95 kwaliteit simpelweg, cuz we can..

Youtube blijft ook niet stilstaan in ontwikkeling bij mini .flv maar gaat HD. als er een nieuw formaat komt welke een kleiner betand geeft maar minder mooi beeld laat men die links liggen.

In mijn ogen is WEBP dan ook geen vooruitgang te noemen, het lijkt mij niet iets waar we op zitten te wachten.
Je vergeet totaal dat een groot deel van de wereld geen 100 mbits verbinding heeft liggen. Ik heb een verbinding van 3mbits/sec down dat is in het geheel niet mijn keuze, maar het gevolg van de aanwezige infrastructuur.

Nederlanders zijn in mijn ervaring enorm verwend met hun internet verbindingen (ze zijn niet de snelste ter wereld, maar staan gelook ik nog wel in de top 10). Ik laat liever ontwikkelen in India of China omdat designkeuzes automatisch gemaakt worden vanuit het gekke idee dat de rest van de wereld ook breedband verbindingen heeft of dat het een vrije keuze van mensen is.

Ik woon gewoon in Spanje en betaal meer voor mijn 3mbits/sec dan jullie voor je 100 mbits/sec. Toch verdien ik mijn brood in high tech computer graphics, maar accepteer ik niet dat mensen galleries on line zetten waar ik gedoemd ben twintig minuten te wachten tot ik een pagina kan zien. Of nog erger de flash amateurs die nooit even getest hebben of hun site uberhaupt functioneert op een inbel verbinding.

De eigen keus van ontwerpers. Ze krijgen gewoon geen klanten omdat die al weggeklikt zijn naar de concurrentie voor het prachtige splashscreen uberhaupt geladen is.

Zinnnen als ´outube blijft ook niet stilstaan in ontwikkeling bij mini .flv maar gaat HD. als er een nieuw formaat komt welke een kleiner betand geeft maar minder mooi beeld laat men die links liggen.

In mijn ogen is WEBP dan ook geen vooruitgang te noemen, het lijkt mij niet iets waar we op zitten te wachten.´ hoor ik vaker van Nederlandse programmeurs en ontwerpers. Resultaat: ik werk met Amerikanen, Canadezen, Spanjaarden, Chinezen en Indiers die gewoon realiteitszin hebben.

Dť natuurwet is niet dat alles vooruit zal gaan, maar het omgekeerde. De verspreiding van internet, de betaalbaarheid van pc´s, het ontstaan van netbooks, tablets en smartphones leidt tot het omgekeerde. De wereld is minder overzichtelijk dan 10 jaar geleden toen we alleen in het dichtbevolkte deel van het Westen hoge snelheidsverbindingen hadden, grote schermen en snelle cpu´s met grote opslag.

Kijk voor de gein eens naar de populaire Ipad en zijn goedkope broertjes en zusjes. Geen opslag ruimte want de wereld is ´online´, geen breedband verbinding want wifi wordt gemiddeld genomen eerder langzamer dan sneller door de uitbreiding naar veel grotere regio´s en de cpu kracht is niet meer simpel af te leiden uit het Dell desktop instap modelletje-

We leven in een wereld van minischerpjes, trage verbindingen, geen interne opslag (tenzij je 2-32 MB als opslag serieus neemt), cpu´tjes die het afleggen tegen een pentium 4 van een decennium geleden, etc.

De kracht van de wereld anno 2010 ligt juist niet bij de clients, maar bij de servers die oneindige capaciteiten hebben om die trage clients te bedienen.

Server capaciteit, server bandbreedte etc optimaliseren is een ouderwetse gedachtengang. Zie bijv. als een van de weinige Nederlandse sites tweakers zelf die dat prima doorhebben, hun images gewoon uit een database trekken en op maat vanuit optimale high res beelden serveren (ofwel cpu tijd en opslag ruimte aan hun kant leveren). Die snappen het gelukkig prima. Veel van hun klanten kennelijk niet :)
Jammer dat je zo kortzichtig denkt. Je wilt wel een snellere verbindingen, maar niet minder data? Effectief komt dat op exact hetzelfde neer: minder wachten op hetgene wat je opvraagt. Zo simpel is het.

Kwaliteit staat hier geheel los van, dat is een keuze die nu ook al gemaakt moet worden, nu kan je ook lossless spul op je website zetten (of betere kwaliteit jpg) en dat gebeurd niet, en niet enkel vanwege de bandbreedte maar omdat er gewoon geen behoefte aan is.
Maar wat denk je van het mobiele internet? 4G is theoretisch ook wel aardig rap, maar enkel bij een goede verbinding. Het zou me niets verbazen, als ze dit juist voor de mobiele telefoon ontwikkelen. Vanuit dit webP kunnen ze weer een video formaat creeeren met hogere compressie...
Compressie is niet nodig met de breedbandverbindingen van tegenwoordig, die paar milliseconden die het langer duurt om een PNG te laden zijn het wel waard voor het kwaliteitsverschil en het alpha channel.
Voor de individuele gebruiker maakt het een paar miliseconden uit per plaatje. Maar sommige websites heb 200-300 plaatjes en dan loopt dat al aardig op en voor de server die het host kan het ontslellend uitmaken als jij 10000den gebruikers hebt die allemaal dat zelfde veel te grote plaatje moeten hebben.

Het is hetzelfde als zeggen: Wat maakt het nu uit dat ik een gloeilamp gebruik ipv een spaarlamp. De centrale kan mijn lampje best aan. Dat wordt een ander verhaal als je een paar miljard gebruikers hebt die ieder meerdere lampen hebben.

[Reactie gewijzigd door Ortep op 1 oktober 2010 12:15]

Volgens mij ben je een beetje in de war :)

Zowel png en flac passen compressie toe. Immers: waarom zou je anders niet alleen raw en wav gebruiken? Er vindt wel compressie plaats, maar die is lossless. Er gaat dus geen kwaliteit verloren door de compressie. Net als met .zip bijvoorbeeld. Bestand wordt (als het goed is) kleiner, maar je kunt alle originele data er weer uit halen.
En ik maar denken dat Jpeg2000 'de standaard' was voor vervangen van Jpeg.
Patenten en copyrights stonden dat in de weg.
Wel zo bedoeld, maar slaat om twee redenen niet echt aan: complexe implementatie, die zeker een factor 5 langzamere decoders oplevert, en onzekerheid rond de patenten, waardoor niemand er echt aan wil, met het .gif debacle in het achterhoofd. (Wederom een voorbeeld hoe patenten de vooruitgang blokkeren)

Ik zie het omcoderen van het ene verliesgevende (lossy) formaat naar een ander niet zo zitten: geeft meer dan dubbel verlies...

Met wat slimme trucjes is ook zonder een nieuwe verlies-gevend conversie stap ook nog wel een alternatief voor het JPEG formaat te bedenken, door zo'n formaat wel op de DCT van JPEG te baseren, maar daarna betere compressie toe te passen op het geheel. Hiermee is ook bijna 30% verbetering tov JPEG mogelijk.

[Reactie gewijzigd door jhellingman op 1 oktober 2010 11:57]

PNG is volgens mij voor vectoren, jpg voor gewone afbeeldingen?
Edit: PNG is het alternatief voor .gif (compressie zonder kwaliteitsverlies)

[Reactie gewijzigd door Atlas85 op 1 oktober 2010 11:46]

SVG is vectoren.

PNG met GIF vergelijken gaat mij ook weer wat ver, gezien kleuren in GIF maar in 8bits (256 kleuren) worden opgeslagen.
Klopt, maar PNG is wel als een vervanger voor GIF ontwikkeld omdat Compuserve moeilijk ging doen over patenten over GIF.

http://www.libpng.org/pub/png/pnghist.html
Nee. PNG is bedoeld als alternatief voor GIF (zie ook de afkorting PNG: PNG's Not GIF)

PNG is wel een open formaat, maar PNG is een lossless formaat, waar JPG/WEbP lossy formaten zijn.
PNG - Portable Network Graphics.
OfficiŽel Portable Network Graphics, onnofficiŽel PNG's Not GIF. Net als meeste recursive namen is er een leuke en serieuze versie. Met dit soort open source initiatieven is het origineel meestal de melige versie...
A January 1995 precursory discussion thread, on the usenet newsgroup "comp.graphics" with the subject Thoughts on a GIF-replacement file format, had many propositions, which would later be part of the PNG file format. In this thread Oliver Fromme, author of the popular DOS JPEG viewer QPEG, proposed the PING name, meaning PING is not GIF, and also the PNG extension for the first time
http://en.wikipedia.org/wiki/Portable_Network_Graphics

Dus voortaan als je iemand wil verbeteren misschien iets beter de achtergrond checken? ;)
PNG is JPG met een alpha-channel. Het combineerd de voordelen van GIF (alpha channel) en JPG (full-collor). Dus tot 24 bit kleur en een alpha channel. Bovendien is het lossless (lagere compressie dan JPG maar geen verlies van kwaliteit).

Ik weet niet wat ik van de zoveelste standaard vind, maar goed we zullen zien. Het zal nog wel even duren voordat WebP door alle browsers ondersteund wordt.
PNG heeft andere eigenschappen en vaak ook een ander functie dan JPG. Niet echt dus. Sla een grote JPG foto maar eens op als een PNG.
Dat heeft totaal geen zin. Die jpeg is namelijk lossy. Dat weer in een lossless formaat opslaan kost meer ruimte terwijl het je niets oplevert.

Een beetje hetzelfde als mp3 weer op cd branden; nooit meer zo mooi als de originele cd.
Als ik naar bestands grote kijk doet het met eerder aan gif denken...
PNG, of Portable Network Graphic, is de extensie voor afbeeldingen met verliesloze compressie. Hierdoor nemen PNG afbeeldingen minder ruimte in zonder verlies van kwaliteit wat wel het geval is bij JPG.

Bron: Wikipedia NL

Als ik de gallery zo bekijk moet ik eerlijk bekennen amper verschillen te zien. Als het om het publiceren van foto's gaat zou ik van Google wel een vergelijking willen zien tussen JPG en PNG.

[Reactie gewijzigd door Lex2 op 1 oktober 2010 11:54]

PNG is handig vanwege zijn ondersteuning voor alpha transparantie, maar voor foto's levert het een stuk grotere bestanden op dan jpg.
Het doel van WebP is om bandbreedte te besparen door afbeeldingen in een compacter formaat aan te bieden.
Precies, het is meer voor 'een plaatje zegt meer dan 1000 woorden' bedoeld, dan voor de fotograaf...
PNG is eerder ontwikkeld als antwoord op het propriŽtaire GIF formaat. De toenmalige licentiehouders van het in GIF gebruikte compressiealgortitme hadden geld geroken; voor implemntaties van de standaard werden licenties noodzakelijk.
Inmiddels is het octrooi op die compressie verlopen, dus is het GIF formaat ook vrij
Nope, leesvoer; http://articles.sitepoint...-jpg-png-whats-difference

If anything, dan is PNG de opvolger van GIF. Maar dat mag je eigenlijk ook niet zo zwart-wit stellen.
GIF heeft natuurlijk maar max 256 kleuren en ťťn transparante kleur (waardoor mooie transparantie overgangen niet kunnen met gif).
PNG is niet lossy. (Ofwel PNG is lossless)

Jpeg is een soort mp3 (inclusief de patenten meuk)
png is een soort flac (beiden open)
Google Chrome ondersteunt dit nog niet, de ondersteuning wordt pas bij de volgende release ingebakken.

Vraag mij werkelijk af, in hoeverre FireFox, Internet Explorer etc dit zullen oppakken. Succes hangt werkelijk af van de ondersteuning door andere Browsers.
Net als VP8/WebM, die werkt volgens mij nog steeds niet in IE9.

Je moet dus altijd met 2 formaten werken. Eentje voor browsers met ondersteuning en eentje zonder ;)
en dan neemt het ineens dubbele ruimte in (nu ja minder dan het dubbele maar dus altijd meer dan een enkele jpeg)
Google heeft dit formaat natuurlijk niet ontwikkeld om de benodigde opslagruimte te verminderen, maar om het gebruik van dataverkeer te verminderen. Opslagruimte is er genoeg Het belangrijkste voordeel van de vermindering in dataverkeer is dat websites sneller zullen laden.

Als Google gelijk heeft dat beeldmateriaal verantwoordelijk is voor 65% van het dataverkeer dan is met een aantal simpele rekensommen uit te rekenen wat de snelheidswinst is tijdens het surfen.

Met inachtneming dat de gemiddelde reductie 30% van de bestandsgrootte is, dan zal 65% van de website dus 30% sneller laden, dat is zo'n 20% op het totale verkeer. Als je daar nog extra scripttijd (browsercheck) en andere imperfecties vanaf trekt dan hou je grof geschat 15% over.

15% sneller surfen is iets waar een browserontwikkelaar normaal gesproken maandenlang voor moet werken. Dus als je 't mij vraagt is WebP een gigantische vooruitgang. Maarja, dan moet het allemaal wel aanslaan. Google's WebM is tot nu toe nog niet echt bepaald een succes...
Daar zat ik ook aan te denken! Als alleen Chrome het gaat ondersteunen wordt het niet wat! PNG en JPG is momenteel volgens mij in de meeste gevallen het beste opslag medium, mede omdat elke (moderne) browser dit goed ondersteund.
PNG is volgens mij voor vectoren, jpg voor gewone afbeeldingen?
Edit: PNG is het alternatief voor .gif (compressie zonder kwaliteitsverlies)
Er is altijd ruimte voor verbetering. Ook is het formaat opensource dus de kans dat ook FF, IE en Opera het zullen ondersteunen lijkt mij best redelijk.
Als Google echt graag wil dat dit formaat mainstream wordt zullen ze (en die middelen hebben ze) zullen ze zelf add-ons moeten schrijven voor de verschillende browsers (incl IE6,7 en 8) en fotobewerkings paketten. Anders moeten ze gaan lopen wachten totdat andere bedrijven de noodzaak gaan inzien van het ondersteunen van WebP en wordt het ivm IE6,7 en 8 al helemaal niets tot 2014.
Niet alleen hangt het succes af van de browsers, maar ook de bewerkingsprogramma's (Photoshop, PSP, GIMP, enz.)
Als er geen fatsoenlijke export komt voor die programma's en je alles via een apart programma moet omzetten wordt het ook niks, de doorsnee persoon zal dat te veel moeite vinden gok ik.
De meeste afbeeldingen passeren Photoshop of Krita niet eens. Zo vanaf camera of mobiel naar de interwebs. Als er ergens support moet komen is het in de software en processors die de compressie in de camera's uitvoeren.
Ik denk dat FireFox het wel op gaat pakken, het is tenslotte een open standaard en die worden door het FireFox team altijd snel opgepakt.

En anders kun je de server van je website altijd nog naar de useragent string laten kijken en jpg-tjes serveren als de agent het WebP formaat niet ondersteunt.
Inderdaad, maar niet alleen van de ondersteuning in die browsers, ook het upgrade gedrag van de gebruik.

Ben toevallig vandaag bezig met het Dojo framework om SVG images (grafieken) te maken, nu werkt dat in IE6 niet. Kijk je in je stats, dan zie je hoe eng veel gebruikers er nog IE6 gebruiken.

Maar ook het on-the-fly WebP serveren zie ik niet zitten, ga jij alle webmasters vertellen hoe dat werkt? De gemiddelde webmaster heeft echt geen idee hoe alles werkt, die installeert een CMS en is al blij als dat werkt.

Dus ja, het initiatief is zeker goed, maar het probleem is alleen dat het jaren duurt voordat alle browsers het er in hebben zitten en de gebruikers die browser ook gebruiken.

Zeker nu ook steeds meer Smartphones ingebouwde browsers hebben wordt dat probleem imho alleen maar groter.
Het lastigste van zo'n nieuw formaat is dat, ondanks dat het beter is, de acceptatie lang zal duren. (Bijna) alle digitale camera's leveren foto's af in JPG-formaat en het leeuwendeel van alle foto's op internet is een JPEG.

Verder moet er ondersteuning komen in applicaties enz.

Neemt niet weg dat dit een interessante ontwikkeling is, maar ik vraag me af hoe lang het duurt eer hiervoor een breed draagvlak is ontstaan.
Als je even bij google was gaan lezen dan had je geweten dat webp niet bedoeld is voor fotos. De techniek werkt het beste voor kleine beelden. Voor grotere bestanden is jpeg beter (alhoewel iedereen die fotograferen serieus neemt natuurlijk in raw fotografeert...).
wat heeft schieten in raw hiermee te maken? het gaat om publiceren op het web, dus formaten die te bekijken zijn in een browser
Ik denk dat die acceptatie sneller gaat dan je denkt. Mits deze standaard inderdaad waarmaakt wat Google belooft. De kracht van deze introductie is tot de speler achter het idee: Google. Met een eigen browser en een krachtige marketing machine kunnen ze dit eenvoudiger tot een succes maken dan welke andere speler dan ook (op Microsoft na).
Ik denk dat het google weinig uitmaakt. Ze bouwen het in chrome en gebruiken het in Google Images en hun eigen sites wanneer dit gedetecteerd wordt, en die besparing alleen al rechtvaardigt de investering.
Acceptatie gaat lang duren, maar als browsers het straks kunnen weergeven, en webservers automatisch het goede bestand serveren op basis van de Accept-HTTP-header, dan is het al interessant voor webgalleries, thumbnails e.d.

Dat zou dan weer reden zijn voor Photoshop om het te ondersteunen. En zodra dat weer het geval is gaan camerafabrikanten misschien wel een extra formaat-optie beschikbaar maken naast JPEG en RAW..

Het gaat niet vanzelf, maar ik zie wel een pad naar enige vorm van acceptatie
Wat mij opvalt is dat WEBP niet de artifacts heeft van JPEG. Dit is vooral te zien op foto 2. Kijk maar vanaf zijn linker oor en dan om zijn kale kop heen. Op de grens van van zijn hoofd en het lucht zie je bij JPEG blokkerigheid en WEBP niet. Dat is iets van JPEG waar ik met altijd aan stoor met foto's.
Het zal wel lang duren voordat het een standaard wordt (Microsoft moet het ondersteunen...). Het zou slim zijn als Google digitale camera fabrikanten kan overhalen. Zou ook interessant voor de fabrikanten kunnen zijn, ipv 1000 foto's op een kaartje, passen er 1400 op zonder verlies..
Omdat je JPG omgezet is naar WEBP lijkt het mij dat die Artifacts er als tweede detailverlies uit vallen ;)

Deze test laat zien wat je over houdt als je een JPG comprimeert.
Een beeldcompressie OP een beeldcompressie?

Het is toch lijkt mij:

ongecomprimeerd beeld (a) > gecomprimeerd beeld JPEG
ongecomprimeerd beeld (a) > gecomprimeerd beeld WEBP

En NIET > ongecomprimeerd beeld (a) > JPEG > WEBP

Dat het wel mogelijk is wil natuurlijk niet zeggen dat men dat in de voorbeelden gaat gebruiken. Echter, nagenoeg alle bestanden ZIJN jpeg dus als het enige verbetering op kan leveren in bestandsformaat dan is die mogelijkheid er wel. Maar het klinkt mij nogal vreemd in de oren.

[Reactie gewijzigd door lenny_z op 1 oktober 2010 15:52]

Klopt wat betreft die artifacts.
Diezelfde compressie artifacts zie je ook vaak bij videocompressie.

Er worden "blokken" pixels gebruikt en hiervan doet met een gemiddelde opslaan. (een gemiddelde van een aantal factoren). Dat gemiddelde is een fractie van de informatie vs de exacte informatie per pixel.
Hoe groter de "blokken" pixels, hoe hoger de (lossy) compressie.
Dit is heel kort en simpel (te simpel eigenlijk) het principe van JPEG.

Hoe WEBP werkt heb ik geen idee van, maar het ontbreken van die uiterst herkenbare "pixel ruis' bij scherpe randen en volkvlakken wat bij JPEG het geval is lijkt te duiden op een compleet andere aanpak.

Iemand een al over gelezen?
Dat vind ik ook altijd een erg vervelende artifact van jpeg. Bij kleurige plaatjes valt het al snel erg op omdat het een stuk minder scherp wordt. En als je wat minder goede decoder gebruikt wordt het zelfs blokkerig.
Gelukkig is dit vermijden door "color subsampling" uit te zetten, met als nadeel dat het bestand +/-15-25% groter wordt. Toch vind ik dat niet heel veel groter voor wat je er voor terugkrijgt.

Anywayz, jpeg is oud, jpeg2000 was niks (kwalitatief niet en patenten ook niet), dus het wordt tijd voor een nieuw formaat wat echt beter is. En als ik deze plaatjes zo zie gaat Webp dit waarmaken.
Hebben ze de compresssie toegepast op de originele ongecomprimeerde bestanden?
Of hebben ze dit op al bestaande JPG's toegepast?
Dan is het toch logisch, dat als je een bestaande JPG verder gaat comprimeren, je dit fenomeen krijgt, immers de kwaliteitsfactor neemt af).

B.v.:
Stel je neemt JPG met een redelijk goede kwaliteitsfactor ŗ 85% en gaat deze opnieuw comprimeren, dat ziet er toch ook niet uit. (kwaliteitsfactor wordt dan: 0,85x.0,85= 0,7225 oftewel 72,25%)
Met alle respect, maar 99% van de internetbevolking ziet echt niet het verschil tussen een 85% JPG of een 72% JPG.

Ik durf zelfs te beweren dat veel 'professionele' fotografen dat niet zien.

Verder is je opmerking natuurlijk erg relevant. Als ik een RAW-bestand omzet naar JPG of WebP, wat is dan het beste. Qua formaat, maar zeker ook qua kwaliteit.
Ik vraag me af hoeveel extra winst WebP oplevert in een vergelijking waarin een lossless gecomprimeerd of ongecomprimeerd bestand als uitgangspunt wordt. In de getoonde vergelijkingen neemt WebP ook de JPEG-artefacten mee, die alleen maar extra informatie aan het plaatje toevoegen als het in een ander bestandsformaat dan JPEG (met de gegeven compressiesettings) wordt weggeschreven.
Ik heb vroeger wel eens bestanden in Photoshop direct opgeslagen als JPEG en JPEG 2000. In die vergelijking haalde ik met JPEG 2000 soms wel 80% extra reductie t.o.v. JPEG. WebP zou in dat geval dus nog beter moeten scoren als Google z'n claims waarmaakt. Of zou het specifiek zijn geoptimaliseerd om beelden die al JPEG-artefacten hebben te recomprimeren? Dat kan natuurlijk ook ...
Ik neem aan dat ze een RAW formaat uit de camera hebben gehaald en dat naar een 16-bit TIFF (of iets dergelijks) hebben omgezet. Dan krijg je een 100% exacte representatie van de foto, zonder verlies. Die TIFF comprimeer je vervolgens met JPEG en met WepP.

Maar hoe presteert WepP als je bestanden laat genereren van bijv. 20% kleiner dan JPEG? Als het bij 40% kleiner al ongeveer gelijkwaardig is als JPEG, dan moet het bij 20% kleiner er een stuk beter uit zien.
JPEG is zodanig ingeburgerd dat ik niet echt geloof in een vervanger... Zeker niet als de voordelen slechts minimaal zijn.

En als WebP er dan uiteindelijk toch in zou slagen om JPEG van de troon te stoten dan denk ik dat zoiets toch wel enige tijd zal duren (jaren)
Er staat in het artikel dat webservers zullen kijken wat de browser ondersteunt. Heb je een moderne browser, dan krijg je WebP. Als je ziet dat er tegenwoordig eindelijk terug concurrentie is op browsergebied, dan kan het wel degelijk snel gaan. Als het aanslaat is 2 jaar niet zo onrealistisch denk ik.

[Reactie gewijzigd door ejabberd op 1 oktober 2010 14:06]

Ik heb het eerder over de periode dat het zal duren waarin het in allerlei software en apparaten is ondersteund (niet alleen browsers).

wat met mobiele toestellen die geen updates ontvangen bijvoorbeeld? Een volledige overgang naar dit formaat zal sowieso niet voor vandaag op morgen zijn, want anders zal er telkens een groep mensen uit de boot vallen
Levert een lossy formaat i.c.m. alpha channel geen vreemde resultaten?
een alpha kanaal is gewoon een extra kanaal vergelijkbaar met bv het rood-kanaal, blauw of groen-kanaal (bij RGB afbeeldingen).. (jpeg slaat RGB overigens op via YCbCr-kanalen, en niet in duidelijk separate kleurkanelen per kleur, hťt voordeel daarvan is dat niet artifacten op specifieke contrastpunten in verschillende kaneln elkaar tezeer 'versterken')

'lossy' levert altijd een vorm van 'ruis' of artifacten op, en die ruis kan ook ertoe leiden dat er lichte afwijken in het alpha-kanaal zitten, maar zolang eenbeeldformaat niet bv gebruik maakt van een 'vast kleurenpalet (wat veel lossless formaten doen) gebeurt het nooit dat er een complete 'kleurverspringen' optreed per pixel, hooguit juist lichtere 'verschuivingen'
Ik heb hier een beetje gemenge gevoelens bij. Het is natuurlijk goed dat google de compressie voor foto's verbeterd, maar er komt wel zo weer ff een formaat bij. Ik ben benieuwd of het gaat lopen. Had MS ook al niet een keer een nieuw jpeg-achtig iets uitgebracht? Daar hoor ik nooit meer iets over.
De goede formaten blijven vanzelf over. Bovendien is het niet zo dat elk formaat hetzelfde doel serveert; het doel van TIFF verschilt heel erg van die van JPEG, of die van PNG, of die van SVG, om maar wat te noemen.

WebP probeert JPEG te verstoten en als deze nummers kloppen en het waar is wat ze zeggen over de automatische WebP-compatible browser herkenning etc kan dat ook zo maar eens gaan gebeuren (althans, voor plaatjes gebruikt op het web).
1 2 3 ... 6

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True