WebP - új képformátum a webre a Google-től

Címkék

A Google saját bevallása szerint azon dolgozik már egy ideje, hogy gyorsabbá tegye a webet. Ebbéli törekvésének legújabb jeleként vezette elő tegnap a WebP névre hallgató képformátumot, amelyet kifejezetten webes felhasználásra szán.

A formátum mögött egy, a vállalat által nemrég nyílt forrásúvá tett VP8 codec-re alapuló képtömörítő áll. A Google állítja, hogy az új formátummal jelentősnek mondható fájlméretcsökkenést érhető el. Hogy igazolják a feltevésüket, 1 000 000 darab képet gyűjtöttek össze véletlenszerűen a webről (többnyire jpg, illetve néhány png és gif), majd átkódolták WebP-be úgy, hogy a kép vizuális paraméterei ne nagyon változzanak. Az eredmény átlagosan 39%-os fájlméret-csökkenés lett. Google létrehozott egy galériát, ahol jpeg és WebP képeket hasonlít össze.

A bejelentés itt olvasható.

Hozzászólások

Jol latom, hogy kontrasztosabb, de fakobbak a szinek?
10-20 evente erdemes ranenzni a regi szabvanyokra (jpg, gif) azertan javitani rajtuk :)
(jpeg, elso release 1992 ... huh)

+1

A PNG az egyik legjobb formátum. Nem kicsi, de tömörített, veszteségmentes, 255 fokozatú alfa és tud animációt is. Sajnos sok esetben nagyon ocsmány tud lenni a JPEG. Hiába nagyon jó a fotó, ha azt teljesen elcsúfítja a tömörítés. Ha már az adattárolók kapacitása és a net sebessége ekkorát fejlődött, kár ilyennel vesződni.

Miért kell a G-nek..
Azért mert ha mindig mindenki elfogadná, azt amit már egyszer valakik kitaláltak, és meg sem próbálna, helyette mást vagy másképp, akkor még most is Gophert használnánk.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

Csak G esetén ez már kényszeres. Vannak, akik kitalálnak egyvalami helyett valami újabbat, amiről később kiderül, hogy jobb az eredetinél. Aztán vannak azok, akik azt hiszik, bármit találnak ki, minden jobb lesz, mint ami eddig volt. Lásd G Wawe, mekkora rohadt nagy jóság volt, le is nyomta az emailt, pont ahogy jósolták. Szerintem ez utóbbi elég balf hozzáállás.
Szerintem.

Ez mondjuk lehet attól is, hogy a jpeg-et tömörítették újra.

Ezek a példák szarok, ez nem összehasonlítás. Ettől még lehetne a webp jó, bár annyival nem tud jobb lenni, hogy érdemes legyen lecserélni a jpeg-et, tekintve, hogy a matematikai alapjai (tudtommal) megegyeznek.

Inkább jpeg2000 irányában kéne a Google-nek kapirgálni, vagy kitalálni valami tényleg újat.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Az meglehet. Mindenesetre nekem egyszerű internetfelhasználónak (aki sokszor kicsi sávon is ül és sokszor használ mobil készülékeket) ha döntenem kéne, inkább a sebesség, mint a minőség. Ritkán nézek Mona Lisa-t nagy felbontásban a weben. Tegyék ki inkább kisebb méretben és "még elég jó" minőségbe, aztán ha érdekel tegyék ki a linket a 2048x1536-ba jpg-be, majd letöltöm és megnézem.

Most nem a WebP mellett érvelek, hanem a kisebb méret mellett. Nekem tök mindegy mivel csinálják meg.

--
trey @ gépház

Egyreszt azert nembaj ha a nepek nem a tragya minoseget szokjak meg. A kisebb meret okes, de azt az eddigi technologiakkal is el lehet erni sokszor ennel jobb minosegben. Az, hogy ez nem tortent meg nem a technologia, hanem a tartalomszolgaltato hibaja, h nem gondolta at ezeket az aspektusokat is. Nem veletlen letezik mar a jpeg(2000)-nel is a quality factor opcio.

---
pontscho / fresh!mindworkz

A Google, hogy ezen pörög, elősegítheti a gyorsabb webet. Látszik, hogy ez a sebességfetisizmus azóta van leginkább, hogy a Chrome a színre lépett. Most minden böngészőgyártó abban méri az epenis-ét, hogy mennyivel gyorsabb a másiknál. Nekem tök mindegy mivel éri el, hogy gyorsuljon az internet. Ha csak azt érik el ezzel, hogy más szolgáltatókat is arra sarkallnak, hogy foglalkozzanak ezzel a témával, akkor már nyertem.

--
trey @ gépház

+ mondtak, hogy minek egy uj browser (chrome) vagy minek egy (sok) uj O/S (maemo, android) aztan csak nem haltak el.

ahogy nezem, a jpeg egy oskovulet. az egesz formatuma, bedrotozott algoritmusa megerett egy eroteljes renovaciora, ami akkora lenne, hogy egyszerubb teljesen ujbol kezdeni.

nem is szolva arrol, hogy szerintem a google arra is figyel, hogy a dekodolas is gyors legyen, nem csak a file meret szamit.

A jpeglib-be így lehet tömörítést állítani:

#define JPEGQUALITY 75
jpeg_set_quality( &cinfo, JPEGQUALITY, TRUE );

Általában mindenki 75-re állítja mert az még kellemes. 50-nél már akkor a file mérte mint a guglié, nem sokkal szarabb minőségbe (az általam tesztelt képeken).

A Gugli sztem mocskosul mellé fogott ezzel. A jpeg-et senki sem fogja lecserélni az ő szabványára. Máris mehet a Buzz mellé a cucc. :D

--
GPLv3-as hozzászólás.

WTF!? Vannak "jó" színek és "rossz" színek?

Lehet, hogy vak vagyok, de a képekre nagyítva (compiz enhanced desktop zoom-ot használtam, lehet, hogy ez negatívan befolyásolja a megfigyelést) én nem vettem észre színkülönbséget. Azt viszont észrevettem, hogy a kontúrokat a WebP nem keni szét, és nem keveri össze olyan ocsmányul, mint a JPG. Igaz, ugyan, hogy látható módon "csempékre" bontja a képet, és a csempehatárokon döccennek a kontúrvonalak, de ez a JPG-nél is így van, csak ott a teljesen szétkent kontúrok miatt ez nem látszik annyira.

A userek (és az 1 kattintásos programok alapbeállításai) a jpeg lehetőségeit sem nagyon használják ki. Sokakanak az is meglepő, hogy megfelelő beállításokkal jpeg-ben is lehet produkálni 30%-os méretkülönbséget látható különbségek nélkül.

Erre nagyon jó példa egy-két fotós oldal, ahol méretkorlát van a feltölthető fotókra... mindenhol sokan nyígnak hogy az nem lehet betartani :P

Miert, a bongeszod tud WebP-t? :) Ha nem, akkor hogy nezned meg az eredmenyt, amig nincs browser, ami tamogatja? Nyilvan atkodoltak WebP-be majd az amugy lathato eredmenyt (amit latnal ha WebP-ben neznel) azt pl vesztesegmentes tomoritessel attoltak png-be, hogy te is meg tudd nezni azert, amig nincs ra support az elterjedtebb browser-ekben.

Na oké, de szerintem így nem teljesen jó összehasonlítani.
Bevallom nem is értettem, hogy miért jelenik meg egy olyan formátum ami még nincs sehol sem támogatva, de aztán arra gondoltam, hogy egy meglévő formátum tömörítési algoritmusán módosítottak, úgy, hogy ez a megjelenítéssel kompatibilis maradt.

Pedig tényleg. A png pontosan de 100% pontossággal azt mutatja, amit kapott.
Tehát ha a webp formátumot mint bmp-t veszed (tehát a normál felbontásban megjeleníted, majd veszed az egyes pixelek színét) akkor is problémád van vele? Mert a png pont ugyan ez, csak sokkal kisebb.
----
Hülye pelikán

Bullshit szaga van... Ha tömörítettből tömörítettbe konvertálsz, romlik a minőség, ilyet nem szabad csinálni. Ha romlik a minőség, akkor meg nem meglepő, hogy kisebb a méret.
Persze ettől még lehet akár jó is a formátum, de ez az "igazolás" elég meredek, és semmit nem mond el.

Kipróbáltam az egyik galériás képen.
A RIOT és tudott az eredetin a minőség jelentős romlása nélkül ~30%-ra összenyomni. Ráadásul maradt JPG.

RIOT alapbeállítások, 6.jpg 62K -> 19K-ra. - Mielőtt valaki megkérdezi.

Feltételezem ez a kép volt a forrás: parrot.

77%-os minőséggel konvertálva (ahogy a RIOT-ban látszik) a WebP kép mérete 24,5KB.
Ezt visszakonvertáltam PNG-be, hogy nézhető legyen: parrot 2.

A WebP-nél nincs az a JPG-re jellemző "aura" a papagáj feje körül. Helyette viszont vannak pici négyzetek, de azt se felejtsük el, hogy majdnem fele akkora lett.

[ OFF ]

Hmmm... bár aktívan HUP-ozom, erről a policy change-ről lemaradtam, és lenne egy-két kérdésem ezzel kapcsolatban:

(Kisebb képeket) miért ne? Teljesítmény problémákat okoz-e? Milyen hátrányai vannak? Ha megszegem a szabályt, mi a büntetés? Miért nincs letiltva az opció alapból?

A válaszokat, vagy az azokat tartalmazó linket szívesen fogadom (a keresődoboz nem segített)

"(Kisebb képeket) miért ne?"

FAQ

"Ha megszegem a szabályt, mi a büntetés?"

Ez egy kérés. Nem szoktam szólni, magam szoktam javítani. Nem vagyok kifejezetten büntető típus.

"Miért nincs letiltva az opció alapból?"

Mert ugyan kiszedhetném a lehetőséget, de akkor az olvasók oda sem tudnának betenni képet, ahol nincs vele semmi baj (fórumtopik szülő post, blogbejegyzés).

--
trey @ gépház

ennek semmi köze a formátumhoz, a felhaszálók ugyanúgy fognak 192kbites mp3-at készíteni 64kbit-ből, az automata programok enem fognak tökéletes beállítással működni, tehát:
- vagy mindegy ebből a szempontból amit mondasz
- vagy kell egy olyan formátum amivel nem lehet a kelleténél nagyobbat előállítani

(jpegnél ugye az van előírva hogyan kell_ki_tömöríteni a képet, azaz rengeteg olyan betömörítő létezik ami nem ideálisan működik, ha ezt akár egy nyílt más formátumú másik betömörítővel helyettesíti is, akkor is sokáig túl bonyolult lesz hogy megbabrálják;

ettől fügetlenül _szerintem_ baromság ahogy van, mindegy milye jó, ha új funkciót nem hoz lehet akármilyen istenkirály formátum, nem fog elterjedni)

Első ránézésre annyival jobb, hogy nincs az a tipikus JPG zaj (galériában pl. a második kép).

ekkora baromsagot...
keptomoritesre wavelet a legjobb, a tudomany mai allasa szerint. konturokat megtartja, sot ha jol van megcsinalva meg nagyitani is lehet pixelesedes nelkul.
a jpeg2000 sajnos nem terjedt el, gondolom a licenszdij miatt, de ettol meg csinalhatnanak valami free wavelet alaput inkabb...

A'rpi

szeritem _web_en nem nagyon akar senki nagyítgatni, inkább a kisebb eszközön kisebb képet, aminél igencsak jól jöhet hogy kisebb felbontásnál nem kell az egész képet letölteni hanem csak az elejét (azaz funkcióban hasonlít progressive tömörítés, de nem teljesen erre gondolok, azt nem lehet erre jól használni)
nem tudom a wave-lettel vagy akár ezzel a webp-vel lehetne-e, ahogy kicsit átfutottam nem találtam erre utalást

Van aki akar, van aki nem.

Ilyen kezi eszkozokre (okostelefon meg butanetpad, stb) az a jo, ha kicsi, de meg lathato. Amikor viszont a weboldal desktopon valo nezesre van tervezve, es fontos, hogy jo minosegu legyen a gep (de azert betoltodjon belathato idon belul, ami kb kizarja a lossless tomoritest), akkor viszont ugye az a fo cel, hogy jo minosegu legyen.

Nem biztos, hogy mindket esetre ugyanaz a formatum a megfelelo.

Ugyanakkor az emberek lustak, es nem fognak N kulonbozo formatumot hasznalni ugyanarra a kepre, attol fuggoen, hogy a T user eppen milyen eszkozzel nezi. Sot, ugy egyatalan minel kevesebb formatumot szeretnenek, mert abbol nincs baj.

Igy marad a jpeg, es nem sok ertelmet latom ennek a webp-nek. Biztos van haszna, valahol, de... attol meg maradhat felesleges faszveres: nyilvan az is jolesik, de nem lesz tole szebb es jobb a web :)

az a normál méretre hozás (jelen esetben!)
tehát pl eredetileg nagyobb a kép csak össze lett nyomva hogy beférjen
ha azért nagyítasz hogy elolvasd a képen a szöveget vagy olyan részletet nézz meg ami egyébként nem látszik.. lehet hogy a te általad említett nagyítással szebb lesz (tehát a wavelet miatt) de hogy plusz információhoz nem jutsz hozzá az biztos
ami pedig mondjuk úgy rossz szem miatti nagyítást illeti:
- vagy mindegy a nagyítás minősége
- vagy nem a képformátum dolga jól interpolálni hanem a böngészőé

tehát az nem nagyítás

Attól függ mit tömörítesz.
Például képernyőkép tömörítésre általában sokkal jobb a png, mint a jpeg. Veszteségmentes és ráadásul általában még kisebb is a fájlméret, mint jpeg-nél.
Ez válasz egy kicsit arra is, hogy miért kell annyi formátum.

Ize.
Es hogy vesznek ra mondjuk engem, hogy ezt a formatumot hasznaljam?
Oke, ahol megemlitette valaki, majd a picassa ebben lesz. En meg letoltok egy ff plugint, (+10mb memoriahsznalat fullenkent) ami onnan is alapbol jpg-be ment, hiszen, a os-em kepnezegetoje azt tamogatja, a mobiltelefonom is, es a macskam is csak azt latja.
Szoval, zsenialis otlet, csak "minek?"

Kulonosen annak a fenyeben, hogy ez csak egy bejelentes, megcsak nem is kesz, hasznalhato termek.

--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."

nem mondta senki hogy téged, mint aki a boltban megveszi a tejet érdekelni fog hogy a tejüzem áttért hagyományos izzókról a kompaktokra

ha nem érdekel vagy nem érint, ne olvass ilyen híreket ;)

nyílván nem leváltani akarják a jpeg-et, hanem ahol lehet belső funkcióként működne, ogy _ha_ a kliens tudja, pl egy konkrét program, akkor majd "tömörítve" küldi az adatot, mint a mostani böngészőknél is van egy olyan header hogy "Accept-Encoding: gzip, deflate"

Dehat, kell hogy erintsen, mert en vagyok az _user_ es a google bacsi nekem gyorsitja a nettet vagy nem?
Mert hogy nem a profeszionalis felhasznaloknak szol a dolog, az biztos.
Szoval, komolyan nem ertem a dolgot, de tenyleg lehet, hogy csak azert, mert nekem ennyire nincs ralatasom a dologra, nekem kep-kep. Van kicsi kep, van nagy, van, ami jo hatterkepnek, van ami nem, esatobbi. Es nem kepezgetek annyit, hogy akar 39%-al gyorsabb kepletoltes meghasson. Ha zavarna, akkor gyorsabb nettet vennek. :P

--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."

érint közvetve, mert a kasszánál ugyanazért a tejért kevesebbet kell majd fizetned, de közvetlen akkor ezek szerint nem érint téged, pl nem fogsz ezt használó programot fejleszteni, tehát marad amit írtam ;)

neked mint felhasználónak _lehet_ transzparens, tehát a picasaban/firefoxban, miután lejött a kép a jobklikk saveas-nél már lehet úgy implementálni hogy már jpeg-ként (is) menti, az hogy ilyet nem akarsz (mert mondjuk nem lesz bit/bit egyezőség sőt a minőség is romlik) az másodlagos, mert NEM ez a célja, hanem egy-egy weboldal gyorsabb _megjelenítése_, nem pedig képmegosztás, ha lementeni akarsz képet akkor mondjuk a képre kattintva lejön a nagyobb felbontású eredeti formátumú kép

Feltételezés volt és nem kijelentés.

Ha jpeg-et, gif-et, png-t töltesz fel, szépen átkonvertálják és meg is van oldva.
YouTube sincs tele mpg, divx, mkv, wmv formátumú videókkal.
A böngészők meg kénytelenek lesznek alapból támogatni, ahogy az összes elterjedt képformátumot, mert ha a Google oldalai átállnak WebP-re, akkor a világnak mennie kell utána, mert most a Google nyakában van a kolomp.
Az egyszeri user nem azt mondja majd, hogy hülye google és keres helyette mást, hanem azt, hogy hülye firefox és lecseréli chrome-ra, mert azzal jön a google.

És ahogy korábban az MS-t, most a Google-t sem érdekli, hogy mit gondol a világ. Megcsinálják amit akarnak, aztán ha bejön örülnek, ha nem jön be, akkor próbálkoznak mással.

Biztos hulye kerdes, de miert nem a JPEG-hez fejlesztenek okossagokat? Minek egy N+1 formatum?
--


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ha az Internet 90%-a pornó (ahogy a városi legenda állítja), és a pornóképek nagyrészt jpeg-ben vannak, akkor ez jelentős megtakarítást eredményezhet. :-)

De mit szenvednek itt egyesek? Lesz 1 plusz lib a gépeken, az új böngészők majd támogatják, kész. Ha tényleg csúnyább lesz, nem fogják használni. Én örülök, hogy legalább próbálkoznak. Ha könnyen lehetne, ki is próbálnám saját képeimen.

Már miért? Win alatt még érthető a dll-hell, *NIX alatt kell +50 sor a jpglibekbe, nem is kell new lib.

A másik lehetőség meg az, hogy a browserírók saját 150 soros libet okádnak össze neki, azt' hadd szóljon, majd beolvasztódik valahová, ha jó (ez mondjuk nem optimális). Amúgy nem néztem meg a webp licencelését, de gondolom opensource buherátort lehet hozzá írni.

Mikor a MS sok-sok ev utan volt hajlando _normalis_ tamogatast adni a PNG-hez, ami pedig mainstream formatum, ne akarjuk mar azt hinni, hogy majd az uj WebP, az bezzeg amikor kijon, mar fullos supporttal fog rendelkezni. Ird es mondd egy darab bongeszo fogja ismerni: a Chromium. A tobbiek meg vagy tamogatjak majd, vagy nem. Az eloallitasa/konvertalasa megint egy erdekes kerdes. Jo esetben egyebkent a kijoveteltol szamitva olyan ketto-harom even belul fogja minden tamogatni. Szerintem.
--


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A microsoft pár év lépéselőnyben van ugye ;) :
http://en.wikipedia.org/wiki/JPEG_XR

De ez nem nagyon látszik. Úgy tűnik a jpg olyan kompromisszumot képez a sebesség-hatékonyság-elterjedtség háromszögben amit nehéz felülmúlni...

Egyébként mások a céljaik is, a Microsoft elsősorban a fotófeldolgozásra koncentrál (értsd: pár éven belül az ő formátumába mentsenek alapértelmezetten f.gépek) ehhez olyan extrákat nyújt mint pl. 8 bitesnél nagyobb színmélység, CMYK színtér, lebegőpontos RGB értékek, a kép régiokra bontása (nem kell az egészet memóriában tárolni), metadata, lossless operations, stb. ott a wiki;)

Míg a google célja a gyorsabb web: egy kicsi, gyors, és buta formátumot akarnak csinálni - már ahogy leveszem a bejelentésből...

Ez igaz. Mondjuk a JPEG XR az új windows verziókban támogatott, szabványosították, tényleg sok hasznos kiterjesztés van benne, innentől kezdve a kérdés az, hogy van-e f.gép gyártó, aki meg meri lépni a bevezetést, és ha igen akkor mikor? Esetleg harmadlagos formátumként a jpg és raw közé pozícionálva felsőbb kategóriás gépekben. (gyors sorozatkép de mégis 12 bites színmélység lehet a niche)

Mivel a nem hozzáértők általában nem törődnek a formátumokkal azt használják amit kapnak, a hozzáértők meg általában kerülik a transcoding-ot, ezért ebben esetben elég gyorsan elterjedhetne.