Google utfordrer JPEG

[Sutekh]

Mer blokk-artifakter på JPEG, mer utsmøring/mindre detaljer på WebP. Litt for hardt komprimert begge to for å titte på i 100%.

Enig i at WebP ser mer utsmørt ut, men det reelle detaljnivået er ikke noe dårligere. Artifactingen i jpeg-bildet ødelegger alt av detaljer, det gir bare illusjonen av å være mer detaljert fordi det er hardere kontraster i deler av bildet.

[knutinh]

Mer blokk-artifakter på JPEG, mer utsmøring/mindre detaljer på WebP. Litt for hardt komprimert begge to for å titte på i 100%.

Enig i at WebP ser mer utsmørt ut, men det reelle detaljnivået er ikke noe dårligere. Artifactingen i jpeg-bildet ødelegger alt av detaljer, det gir bare illusjonen av å være mer detaljert fordi det er hardere kontraster i deler av bildet.

Skulle gjerne ha sett original-bildet...

 

Se på den bakerste jenta. For JPEG og h264 så ser vi at hun har en mønstrete kjole. For WebP så er ikke det mulig å se.

 

Se også på gresset mellom menneskene og vannet. Hva som er "rett" vet vi ikke, men for mine sanser så er JPEG og h264 mer like og detaljerte, mens WebP er mer utsmørt.

 

JPEG har fremdeles grove blokk-artifakter, spesielt i skyggen som skogen kaster i vannet.

-k

[007CD]

@knutinh

 

Den vanlige mannen i gata ser ikke dette så lett, men hvor jeg jobber og når man skal kjøre plotting på banner og man får levert bildet i JPEG så ser jeg med en gang artifactsene, er ikke vanskelig å se at det er JPEG, selv om oppløsningen er over 2500 x 2500 for eksempel

[ATWindsor]

Mer blokk-artifakter på JPEG, mer utsmøring/mindre detaljer på WebP. Litt for hardt komprimert begge to for å titte på i 100%.

Enig i at WebP ser mer utsmørt ut, men det reelle detaljnivået er ikke noe dårligere. Artifactingen i jpeg-bildet ødelegger alt av detaljer, det gir bare illusjonen av å være mer detaljert fordi det er hardere kontraster i deler av bildet.

Skulle gjerne ha sett original-bildet...

 

Se på den bakerste jenta. For JPEG og h264 så ser vi at hun har en mønstrete kjole. For WebP så er ikke det mulig å se.

 

Se også på gresset mellom menneskene og vannet. Hva som er "rett" vet vi ikke, men for mine sanser så er JPEG og h264 mer like og detaljerte, mens WebP er mer utsmørt.

 

JPEG har fremdeles grove blokk-artifakter, spesielt i skyggen som skogen kaster i vannet.

-k

 

 

Det er jo ganske tydelig at Webp er mye mer utsmurt på de bildene, det hadde vært fint å se orginalen, men akkurat det ser man jo glatt bare av å se på bildene.

 

AtW

[Epp]

Og hvilke musikkformater er det som gir en betydlig bedre kvalitet enn mp3?

 

Lossy: ogg vorbis

Lossless: Flac

 

 

 

Det er jo ganske tydelig at Webp er mye mer utsmurt på de bildene, det hadde vært fint å se orginalen, men akkurat det ser man jo glatt bare av å se på bildene.

 

AtW

 

WebP virker litt som bildene fra Fujifilm FinePix kompaktkamera... Jeg mener utsmørt for å se bedre ut.

[ATWindsor]

Og hvilke musikkformater er det som gir en betydlig bedre kvalitet enn mp3?

 

Lossy: ogg vorbis

Lossless: Flac

 

Om man holder seg til det antallet kanaler mp3 støtter, så er ikke det riktig, mp3 har som oftest like god, eller så godt soom like god kvalitet som flac, ogg har ikke speselt mye lavere bitrate for transprent kvalitet.

 

AtW

[del_diablo]

x264 - http://x264.nl/developers/Dark_Shikari/imagecoding/x264.png

VP8/WebP - http://x264.nl/developers/Dark_Shikari/imagecoding/vp8.png

JPEG - http://x264.nl/developers/Dark_Shikari/imagecoding/jpeg.png

 

Alle bildene ble komprimert til omtrentlig samme størrelse, som dere ser er Jpeg bedre enn WebP.

 

Hurr durr durr.

Kan noen ta et pent PNG bilde, på "normal størrelse, og hive det på samme testen?

Altså f.eks screencap fra anime nedskalert, meme bilder, eller annet?

 

PS: Du mangler kilde forresten;

http://x264dev.multimedia.cx/archives/541

Og for å sitere:

For x264, I encoded with --tune stillimage --preset placebo. For libvpx, I encoded with --best

Og kildebildet er veldig kornete.

Biasert kilde? Yupp.

 

Og hvilke musikkformater er det som gir en betydlig bedre kvalitet enn mp3?

 

Lossy: ogg vorbis

Lossless: Flac

 

Om man holder seg til det antallet kanaler mp3 støtter, så er ikke det riktig, mp3 har som oftest like god, eller så godt soom like god kvalitet som flac, ogg har ikke speselt mye lavere bitrate for transprent kvalitet.

 

AtW

 

Mp3 er ikke LOSSLESS, og Ogg støtter høyere bitrate samt kanaler.

[Ueland]

Jeg er forøvrig rimelig imponert over hvor kjapt bilder laster f.eks når man blar i album på Facebook. Så er egentlig bildestørrelse et så stort problem for brukeropplevelsen? Det jeg irriterer meg mest over er trege servere og mange forespørsler til forskjellige plasser (som noen andre nevnte tidligere). Facebook viser jo ganske tydelig at ren bildevisning kan gjøres veldig kjapt og greit med god koding (AJAX).

Grunnen til hastigheten der er den tekniske løsningen til Facebook (Varnish, nok servere + båndbredde) og ikke bildene i seg selv.

Men når bildene i seg selv har neglisjerbar lastetid, betyr ikke det at de i grunnen er små nok? Poenget mitt er at man kanskje ikke bør fokusere så hardt på å redusere filstørrelsen (og beholde dagens kvaliteten), men heller øke kvaliteten (og beholde dagens filstørrelse). Selvfølgelig i tillegg til det tidligere nevnte om å redusere alt det unødvendige våset rundt.

 

Eller driver nettleseren min og AJAX precaching av bilder når jeg blar gjennom et album på Facebook?

Er nok noe precaching og inne i bildet.

 

Kan love deg at surfingen der langtfra er kjapp når man bruker en tregere linje enn normalt

[knutinh]

@knutinh

 

Den vanlige mannen i gata ser ikke dette så lett, men hvor jeg jobber og når man skal kjøre plotting på banner og man får levert bildet i JPEG så ser jeg med en gang artifactsene, er ikke vanskelig å se at det er JPEG, selv om oppløsningen er over 2500 x 2500 for eksempel

Det er vel et spørsmål om:

1. Printstørrelse i forhold til seeravstand

2. Kompresjonsgrad

3. Innhold. JPEG er ikke egnet for vektor-grafikk og lignende.

 

JPEG ved 'quality' 95 ser vanligvis veldig bra ut.

 

Et banner på 1x4 meter ser vel bra ut fra stor avstand.

 

-k

[se#]

Jeg forstår ikke at det kan være noen tvil om at en 39% gjennomsnittelig reduksjon i bildestørrelse ville være bra for så og si alle som bruker internett. Noen sider går "raskt nok", men alt som gjøres på nettet konkurrerer om bådbredden og sitter du for eksempel med et 3G-modem som må ned i GPRS-hastighet pga dekningen vil nesten alle sider oppleves som trege.

 

Sett på nett-TV eller en 1Mbps video som hakker litt selv på en 3Mbps ADSL linje eller noe ennå raskere? Flaskehalsen er ikke hos deg, men på en server eller linje på veien. Og alt som kan redusere trafikken reduserer sjansen for problemer.

 

8 bits pr kanal? Personlig synes jeg det er dumt å innføre en ny standard uten støtte for større bitdybde, men pr i dag har det minimalt å si. Det finnes knapt nok en PC-skjerm med mer enn 1:1000 i kontrastforhold og da holder 24-bits farger lenge. Det er først og fremst under bearbeideingen av bilder man har glede av 12 eller 16 bit i dag. Når bildet først er ferdig prosessert og kun skal vises på en nettside holder det med 8 bits, og selv en GIF med bare 256 farger gir ofte respektable bilder i små formater. Skjermenes kontrastforhol kan, og vil nok til en viss grad endre seg og det burde det vært tatt høyde for. Kanskje er det det også? Jeg har bare lest artikkelen og ikke standarden. Microsofts JPG XR har jo det, og er kanskje et vel så bra alternativ slik sett.

[ATWindsor]

 

 

 

 

Om man holder seg til det antallet kanaler mp3 støtter, så er ikke det riktig, mp3 har som oftest like god, eller så godt soom like god kvalitet som flac, ogg har ikke speselt mye lavere bitrate for transprent kvalitet.

 

AtW

 

Mp3 er ikke LOSSLESS, og Ogg støtter høyere bitrate samt kanaler.

 

Jeg snakker om kvaliteten, lossy eller ikke, høyere bitrate eller ikke, mp3 har like god, eller så godt som like god kavalitet som både flac og ogg vorbis. Mp3 har et problem med kanalstøtte, men dette poengterte jeg jo også i innlegget mitt.

 

AtW

[knutinh]

Jeg forstår ikke at det kan være noen tvil om at en 39% gjennomsnittelig reduksjon i bildestørrelse ville være bra for så og si alle som bruker internett. Noen sider går "raskt nok", men alt som gjøres på nettet konkurrerer om bådbredden og sitter du for eksempel med et 3G-modem som må ned i GPRS-hastighet pga dekningen vil nesten alle sider oppleves som trege.

 

Sett på nett-TV eller en 1Mbps video som hakker litt selv på en 3Mbps ADSL linje eller noe ennå raskere? Flaskehalsen er ikke hos deg, men på en server eller linje på veien. Og alt som kan redusere trafikken reduserer sjansen for problemer.

Eller så vil forbedret kompresjon bare føre til at folk laster ned flere bilder, og så blir total-lasten uendret =)

 

39% reduksjon i størrelse for uendret kvalitet er i seg selv interessant. Kritikken er vel at enda bedre reduksjoner er mulig med annen teknologi, og at måten formatet tilbys på ikke er veldig fornuftig.

Microsofts JPG XR har jo det, og er kanskje et vel så bra alternativ slik sett.

Jeg er usikker på hva WebP tilbyr som JPEG XR ikke tilbyr. Men jeg har inntrykk av at JPEG XR henvender seg til fotografer, mens Google tilbyr seg til vanlige nettsider.

 

-k

[se#]

Og alt som kan redusere trafikken reduserer sjansen for problemer.

Eller så vil forbedret kompresjon bare føre til at folk laster ned flere bilder, og så blir total-lasten uendret =)

 

Enhver ryggsekk blir full, uansett størrelse. Alle harddisker blir fulle og all båndbredde brukes opp. Slik er verden, men en reduksjon i bildefilstørrelse vil likevel være prositivt. Alle får gjort litt mer enn de ville uten forbedringen.

 

 

39% reduksjon i størrelse for uendret kvalitet er i seg selv interessant. Kritikken er vel at enda bedre reduksjoner er mulig med annen teknologi, og at måten formatet tilbys på ikke er veldig fornuftig.

Microsofts JPG XR har jo det, og er kanskje et vel så bra alternativ slik sett.

Jeg er usikker på hva WebP tilbyr som JPEG XR ikke tilbyr. Men jeg har inntrykk av at JPEG XR henvender seg til fotografer, mens Google tilbyr seg til vanlige nettsider.

 

Det viktige er vel egentlig at det kommer et nytt format som er bedre enn JPG. Jeg har ingen problemer med hverken Googles eller Microsofts forslag. Microsofts virker jo som en mer komplett løsnign, helt fra RAW-ekvivalent funksjonalitet i kamera til Web-sider, mens Googles virker mer begrenset og rettet mot bruk på Web - i hvertfall slik det fremstilles i artiklene jeg har lest.

 

Kanskje Google har større sjanse for å få noe gjennom fordi det ikke prøver å løse alt (og heter Google og ikke Microsoft). Jeg er pragmatisk og tar imot forbedringer uansett hvem som "vinner".

[Revolution]

x264 - http://x264.nl/developers/Dark_Shikari/imagecoding/x264.png

VP8/WebP - http://x264.nl/developers/Dark_Shikari/imagecoding/vp8.png

JPEG - http://x264.nl/developers/Dark_Shikari/imagecoding/jpeg.png

 

Alle bildene ble komprimert til omtrentlig samme størrelse, som dere ser er Jpeg bedre enn WebP.

 

Hurr durr durr.

Kan noen ta et pent PNG bilde, på "normal størrelse, og hive det på samme testen?

Altså f.eks screencap fra anime nedskalert, meme bilder, eller annet?

 

PS: Du mangler kilde forresten;

http://x264dev.multimedia.cx/archives/541

Og for å sitere:

For x264, I encoded with --tune stillimage --preset placebo. For libvpx, I encoded with --best

Og kildebildet er veldig kornete.

Biasert kilde? Yupp.

 

Og hvilke musikkformater er det som gir en betydlig bedre kvalitet enn mp3?

 

Lossy: ogg vorbis

Lossless: Flac

 

Om man holder seg til det antallet kanaler mp3 støtter, så er ikke det riktig, mp3 har som oftest like god, eller så godt soom like god kvalitet som flac, ogg har ikke speselt mye lavere bitrate for transprent kvalitet.

 

AtW

 

Mp3 er ikke LOSSLESS, og Ogg støtter høyere bitrate samt kanaler.

 

Om du ser et par poster over min post har jeg kilden der, poenget er jo at x264 har psy optimaliseringer som gjør at det ser mange ganger bedre ut enn WebP.

 

Og for dere som klager over at WebP er utsmurt, så er det deblocking filteret som gjør, noe som JPEG ikke har. Riktig at jpeg kan se verre ut, men de stedene det har detalj syns jeg det er mye bedre enn WebP.

 

 

Da jeg snakket med Dark_Shikari om sammenligningen mente han det ikke var nødvendig å bruke en annen kilde, x264 vil vinne hver gang pga. PSY-optimaliseringene.

 

Uansett er det et latterlig forsøk fra google, formatet er ubrukelig.

Endret 5. oktober 2010 av Revolution

[knutinh]

Enhver ryggsekk blir full, uansett størrelse. Alle harddisker blir fulle og all båndbredde brukes opp. Slik er verden, men en reduksjon i bildefilstørrelse vil likevel være prositivt. Alle får gjort litt mer enn de ville uten forbedringen.

Hvis du leser nøyere posten jeg kommenterte så ble det påstått at bedre bildekompresjon ville redusere total-lasten på nettet slik at alle fikk bedre ytelse. Jeg kommenterte at det ikke nødvendigvis er slik (alle ryggsekker når smertegrensen).

Det viktige er vel egentlig at det kommer et nytt format som er bedre enn JPG.

Hva er galt med JPEG? Det har kommet mange nye formater som er "bedre" enn JPEG, bl.a. JPEG2000. Av ymse årsaker har konsumenter og produsenter reagert med unisone gjesp.

 

-k

[knutinh]

Om du ser et par poster over min post har jeg kilden der, poenget er jo at x264 har psy optimaliseringer som gjør at det ser mange ganger bedre ut enn WebP.

 

Og for dere som klager over at WebP er utsmurt, så er det deblocking filteret som gjør, noe som JPEG ikke har. Riktig at jpeg kan se verre ut, men de stedene det har detalj syns jeg det er mye bedre enn WebP.

 

Da jeg snakket med Dark_Shikari om sammenligningen mente han det ikke var nødvendig å bruke en annen kilde, x264 vil vinne hver gang pga. PSY-optimaliseringene.

 

Uansett er det et latterlig forsøk fra google, formatet er ubrukelig.

Jeg tolker Shikari som at han først og fremst kritiserer enkoder-implementasjonen til Google. Formatet i seg selv tillater visst "smarte" enkoder med psy-optimalisering.

 

Forøvrig har vi vel ingen andre kilder enn nevnte Shikari på at det er psy som er problemet (og et par andre påstander). Fyren er sikkert kunnskapsrik men det kan jo tenkes at han tar feil?

 

Forøvrig har også h264 deblocking filter, uten å gi utsmøring.

 

-k

[se#]

Enhver ryggsekk blir full, uansett størrelse. Alle harddisker blir fulle og all båndbredde brukes opp. Slik er verden, men en reduksjon i bildefilstørrelse vil likevel være prositivt. Alle får gjort litt mer enn de ville uten forbedringen.

Hvis du leser nøyere posten jeg kommenterte så ble det påstått at bedre bildekompresjon ville redusere total-lasten på nettet slik at alle fikk bedre ytelse. Jeg kommenterte at det ikke nødvendigvis er slik (alle ryggsekker når smertegrensen).

Det viktige er vel egentlig at det kommer et nytt format som er bedre enn JPG.

Hva er galt med JPEG? Det har kommet mange nye formater som er "bedre" enn JPEG, bl.a. JPEG2000. Av ymse årsaker har konsumenter og produsenter reagert med unisone gjesp.

 

-k

Jeg tror jeg leste nøye nok. Totallasten for å gjøre en viss "jobb" redueres, det kompenserer gjerne brukerne med å gjøre mer, du når taket uansett, men sitter likevel igjen med nettogevinsten av at alle får gjort litt ekstra, eller det samme på litt kortere tid.

 

Det er jo ikke noe galt med JPG utover at andre teknologier (hevder) de gir samme bildekvalitet med mindre filstørrelse. Er det korrekt får vi en gevinst ved å bytte. Det er selvsagt ikke helt smertefritt å bytte, men hvis Safari, Firefox, Chrome, IE og Opera implemeterer støtte for et nytt format vil ikke brukerne merke stort til det. JPG2000 hadde visstnok noe ytelsesproblemer da det ble lansert (muligens også fortsatt), men JPG XP ikke skal ha det, og jeg antar Google har tenkt på det samme.

Endret 5. oktober 2010 av se#

[Revolution]

Om du ser et par poster over min post har jeg kilden der, poenget er jo at x264 har psy optimaliseringer som gjør at det ser mange ganger bedre ut enn WebP.

 

Og for dere som klager over at WebP er utsmurt, så er det deblocking filteret som gjør, noe som JPEG ikke har. Riktig at jpeg kan se verre ut, men de stedene det har detalj syns jeg det er mye bedre enn WebP.

 

Da jeg snakket med Dark_Shikari om sammenligningen mente han det ikke var nødvendig å bruke en annen kilde, x264 vil vinne hver gang pga. PSY-optimaliseringene.

 

Uansett er det et latterlig forsøk fra google, formatet er ubrukelig.

Jeg tolker Shikari som at han først og fremst kritiserer enkoder-implementasjonen til Google. Formatet i seg selv tillater visst "smarte" enkoder med psy-optimalisering.

 

Forøvrig har vi vel ingen andre kilder enn nevnte Shikari på at det er psy som er problemet (og et par andre påstander). Fyren er sikkert kunnskapsrik men det kan jo tenkes at han tar feil?

 

Forøvrig har også h264 deblocking filter, uten å gi utsmøring.

 

-k

Det er også helt rett at WebP har potensiale, men de lanserer jo en dødfødt unge. Encoderen suger = slår ikke ann.

H.264 gir utsmørning i like stor grad om faktiske blocking forekommer, noe de ikke gjør, ergo blir de ikke deblocket. Pga. encoderen faktisk er god.

 

Og at han tar feil, haha, det tviler jeg sterkt på. Han er tross alt utvikleren av den beste H.264 encoderen som finnes.

Endret 5. oktober 2010 av Revolution

[knutinh]

Og at han tar feil, haha, det tviler jeg sterkt på. Han er tross alt utvikleren av den beste H.264 encoderen som finnes.

UtviklerEN eller en av mange?

x264 was originally developed by Laurent Aimar' date=' who stopped development in 2004 after being hired by ATEME. Loren Merritt then took over development. Today, x264 is primarily developed by Loren Merritt, Jason Garrett-Glaser, Steven Walters, Anton Mitrofanov, David Conrad, and Guillaume Poirier.

[/quote']

Jeg har hørt at selv smarte, kunnskapsrike folk tar feil en gang i blandt. Jeg husker tilogmed engang å ha tatt feil selv.

 

Bakgrunnen gir ham betydelig kredibilitet, men han er ingen ekspert på Googles stillbildeformat.

 

-k

[Revolution]

Nå har jo han tross alt vært med å skrive dekoderen til Vp8 for ffmpeg. Så hans meninger er nok basert på langt høyere kunnskap om det enn de fleste. Såklart er han en av mange, men han blir sett på som "the main" guy.

Endret 5. oktober 2010 av Revolution