Přímo ze zmínky v článku mě napadá ještě jedna výhoda oproti JPEG: alpha průhlednost (teda pokud se s ní u webP opravdu počítá). Ta občas u JPEG chybí, PNG to sice jistí, ale za cenu většího objemu dat (bezztrátová komprese). Čili škvíra na trhu, kam by se webP mohl vecpat je "transparentní bitmapa se ztrátovou kompresí". Ovšem moc velká poptávka po tom podle mě asi nebude.
žiadny to nepodporuje, ale upravený jpeg kodek som použil vo svojom grafickom formáte *.ada v programe http://ipremiere.eu/apps/PhotomaniaDX676-SK.exe ktorý som kedysi nakódil... keby niekto chcel môžem mu poslať aj zdrojáky.
ta diera na trhu je, ale alpha transparency (aj ked je fakt, ze chyba, ale nijak zasadne). Ta diera sa ukaze velmi skoro, ked pridu 3D displaye a budu coraz rozsirenejsie. Fotaky uz sa predavaju s 3d. Konzola 3DS sa bude predavat zaciatkom roka. A 3d fotky na web? Taky format, co to zvladne nepoznam.
podla mna by malo zmysel urobit webovy format obrazkov, ktory by nahradil vsetky pouzivane - teda jpg i png. napriklad png ma vyhody v priehladnosti, a to aj ciastocnej. jpg je male. urobit teda nieco, co by bolo male, malo by moznost pouzitia plnej kvality, ostre tvary by nerozmazavalo... o by bolo nieco. naprikald to spominane rozmazavanie sposobuje, ze sa obrazky v JPG blbo upravuju v grafickom programe...
stavim sa, ze MS bude proti. ako vzdy...
1. minulost nas naucila ze spoliehat sa na jeden *cokolvek* nie je vhodne
2. z hovna bic neupleties - bud je image nekvalitny a zabera malo, alebo je kvalitny a zabera vela. Kvalitny obrazok bez "rozmazavania" mozes mat aj v JPEG a mozes spokojne editovat.
3. nevidim jediny dovod preco by mal byt proti zrovna MS - ak tym myslis spolocnost microsoft. Format obrazkov sa jej dotyka mozno podporou v prehliadacoch IE a na image search v bingu. Ak bude existovat codec, implementacia je ... primitivna. Ak sa mame bavit o principialnom odmietani, tak vietor bude fukat od nahryznuteho jablka
Ad 2. - Mýlíte se. Dovedu si snadno představit formát, kde si podle typu obrazových dat zvolíte, zda chcete kompresi bezztrátovou nebo ztrátovou (a dost bych se divil, kdyby něco takového už nebylo, minimálně na úrovni nějaké diplomky). Myslím, že současny PNG by se na to dal použít jako kontejner. Ostatně existuje specifikace JNG, která PNG kontejner používá pro obalení JPEG dat. Čili z hovna bych bič upletl poměrně snadno.
Obrázek bez "rozmazávání" JPEG poskytnout, AFAIK, neumí. To "rozmazávání" (artefakty vzniklé DCT) je jeho základní vlastností. Bez ní to není JPEG.
Ale takovy format uz ty je roky ;-))
.... chvilka napeti .... ano je to TIFF
umi bez komprimace, umi bezztratove komppromace a to dokonce nekolik a umi i jpeg komprimaci ... Jtiff,Jiff ... a dokonce umi i vrstvy, takze tam by asi pruhledny jpeg sel udelat ;-))
problem tiffu je ten, ze je to takovy dost univ. kontejner, ze tam muzze byt asi cokoliv ... a tak ne kazdy prohlizec a hlavne editor umi vse ... ale dnes uz se to celkem ustalilo.
Dalsi takovy fotmat je .ps a .pdf ... zase umi bez komprese, komprezi ala zip a ukladani jpegu ...
DCT sama o sobe teoreticky ztratova neni, akorat se potom koeficienty, ktere se pomoci ni vypoctou, vahuji, takze zde by bylo nutne upravit kvantovaci tabulky v norme JFIF.
Prvni ztrata v JPEGu nastava jiz pri konverzi barvoveho prostoru, kdy se barvonosne slozky (vetsinou) podvzorkovavaji a nasledne se vahuji a kvantuji vysledky DCT.
Nicmene jiz skupina JPEG definovala IMHO minimalne tri bezeztratove formaty (JPEG-LS) kde se namisto DCT pouziva DPCM, tady google nenasel nic noveho :-)
Microsoft je samozřejmě pro, dokonce takový formát navrhl a podporuje ho v IE9 :)
djvu má vynikajúci kompresný algoritmus pre bitonálne obrazy, v ktorých sa opakujú elementy (typický príklad: scan dokumentu). Ak si zoberiete hocijaký náhodne sa vyskytujúci bitonálny obraz, verím tomu, že často png bude na tom lepšie.
Niekoľko desaťtisíc strán som do djvu už previedol, na začiatku som sa dosť hral s čistením a nastavením úrovní čiernej a bielej, aby som dosiahol najlepší kompresný pomer v png (ako fallback, pre ľudí neochotných/neschopných si nainštalovať djvu). Bezstratové cjb2 na normálnom texte dosahuje 1.5-2× lepšiu kompresiu ako png, stratové je samozrejme ešte lepšie.
Ak pustíte cjb2 s parametrom -verbose, pozrite si položku X shapes after matching - ak je toto číslo príliš vysoké, blíži sa k počtu css, tak djvu nie je vhodné pre daný obrázok.
Naprosto souhlasím s předposledním odstavcem. Lidi jsou líní a změny se provádí jen tam, kde se to projeví opravdu výrazně.
Postupně se přechází od MPEG4 ASP (DivX, XviD, ...) k MPEG4 AVC (x264). Šetři to gigabajty a je to znát. Naopak OGG, Flac, ... jsou spíše fanouškovskou záležitostí, ale spotřební elektronika to spíše ignoruje. Co mi z o něco málo lepší kvality při stejném bitrate, když to většina HW přehrávačů nepřehraje a málo kdo ten rozdíl pozná. U JPEGu to bude podobné. Foťáky u něj stejně zůstanou a to je většina objemu statických dat na webu, ne xychtík stránky.
Předpokládám, že budou existovat programy, které to otevřou nebo pro ten formát bude doplněna podpora do těch stávajících. Minimálně v Chrome to určitě časem půjde :-). Řekl bych, že Google nebude mít problém přihodit případně pád dolarů tvůrcům nejběžnějších prohlížečů/editorů fotek, aby to implementovali nebo přijít s vlastním "Google Image Viewerem".
Spíš si myslím, že se většina těchto problémů vyřeší docela jednoduše - během půl přijde Microsoft se super mega inovativním formátem, jehož princip bude podobný WebP, ale bude mít jinou hlavičku. Pokud se zadaří, přidá tám i něco patentovatelného. Jelikož si je budou moct uživatelé stáhnout do Windows, rychle si vynutí podporu jak u 3rd-party SW, tak HW...
"rychle si vynutí podporu jak u 3rd-party SW, tak HW"
toho bych se zase tolik nebal, vzhledem k tomu, ze uz se MS pokusil nahradit MP3 a JPEG, celkem neuspesne.
Spise to vidim tak, ze Google si udelal nejaky format a ted co? Proste nic. Problem velkych firem je, ze spolu spatne spolupracuji. Uspesny bude ten format, na kterem se domluvi nekolik velkych spolecnosti a zacnou jej spolecne tlacit k zakaznikum.
Striktne matematicke hodnotenie, typu PSNR alebo Q.. vyzera pekne, ale iba na papieri. Prikladom moze by fraktalova kompresia, ktora da PSNR velmi dobre, ale subjektivny dojem je horsi. Takze ak najdu dobrovolnikov, ktori ohodnotia tych milion obrazkov subjektivne, urcite by ma vysledky zaujimali viacej.
Kde to zapasuje je Opera Mini alebo Turbo mod. To si viem pekne predstavit. Ale neviem si predstaviť záťaž tých serverov. Asi bude väčia ako pri konverzii z jpeg 100% na jpeg 50%. A ak by sa WebP konvertoval do mensej kvality, tak vysledná velkost obrázka by bola minimalna.
Tiež ako obrázok do navigácii a do GoogleEarth. Ja v tom vidím široké použitie, nie len na webe, kde Youtube vysiela vo FullHD to nemá velky zmysel.
Taky mě to napadlo. Zátěž serveru neumím posoudit. Další otázka u Opery Mini je výkon: implementace bude muset být v Javě (aspoň zpočátku, ale IMHO ještě dlouhou dobu) a výkon různých implementací Javy se liší. Interpret dnes již snad prakticky vymizel, ale i tak tu máme aspoň tři používané implementace: JIT, AOT, Jazelle.
AOT je používáno hlavně v "hloupých" Sony Ericssonech a jde o kompilaci byetcode do nativního kódu (typicky před prvním spuštěním - u SE je zobrazen onen "teplotoměr").
JIT je používáno hlavně na smartphonech. Jde o kompilaci za běhu. Ačkoli nabízí lepší optimalizace (např. brzká vazba u virtuálních metod), ihned po spuštění je výkon obvykle nižší, není-li výsledek JIT cacheován, a to z několika důvodů (verifikace a kompilace).
Jazelle je používáno na mnohých "hloupých" telefonech, typicky S40. (Pravda, některé archaické S40 mají interpret, ale tyto už asi nemají význam.) Jde o HW implementaci, ale patrně není tak výkonná jako AOT a při pohledu na strukturu bytecode jen tak nemůže být výkonnější. Nutnost verifikace při startu zde (narozdíl od AOT) patrně neodpadá a ačkoli některé instrukce (např. invokevirtual) odpovídají více instrukcím strojového kódu, někdy to je naopak (např. kód i++ se do Java bytecode přeloží do tří instrukcí, například aload_1, iinc, astore_1), ale ve strojovém kódu by šlo o jednu instrukci.
Flash aspoň přináší nějakou funkčnost, kterou webové standardy neumí. WebP naproti tomu přináší jen kvalitativní posun v určité oblasti, proto to bude mít horší. Zadavatel se zeptá webdesignera - proč na mě tady vyskočilo to okno, že musím nainstalovat to a to? Nešlo by to jinak? Webdesigner řekne: No v podstatě by to šlo jinak... a skončí se u JPEGu. U Flashe některé věci (kamera, apod.) prostě jinak nejdou (proto ho používá i YT).
Pokud se tím dá opravdu tolik ušetřit, tak po tom jako první skočí provozovatelé webových galerií jako je Flickr, Facebook, Picasa... Snížení trafiku o 39% je, podle mě, pro takové giganty velmi lákavé. Takže první krok je podpora prohlížečů. Pak na to přejdou webové galerie , a protože minimálně polovina majitelů digitálních foťáků nějaké takové galerie používá, vytvoří se i poptávka po podpoře ve foťácích a jiném HW..... WebP si najde místo na slunci.
Teda ještě velkou roli sehraje kvalita fotek ve WebP - po kvalitě fotek je veliká poptávka. Taky to musí být kvalitní na tisku, protože z digiťáků se fotky tisknou stále častěji. Věřím, že Google nevypustí nic , co by objektivně zhoršovalo kvalitu fotek (kvalitu měřitelnou lidskými smysly).
U PC je to asi bezpredmetne, ale v pripade mobilnich zarizeni (notebooky, smartphony, atd...) by me zajimala vypocetni slozitost dekompresniho algoritmu. JPEG 2000 se neprosadil prave kvuli vyssi narocnosti, coz v pripade napr. fotoaparatu znamenalo v praxi vyznamne snizenou kapacitu baterie...
Tohle je prece zavadejici jako prase. Jediny vysledek ktery tim zjistili je, ze vetsina obrazku na internetu neni dostatecne optimalizovana. Kdyz budou lidi na web davat 2MB velke JPEG fotky, ktere se jinak daji JPEGem ulozit do 500KB bez vyrazne ztraty kvality, tak bude JPEG o 400% lepsi nez JPEG.
Vysledek testu je nula. Podle me je to absolutni misinterpretace.
Částečně máte pravdu. Viz http://code.google.com/intl/cs-CZ/speed/webp/docs/c_study.html
Ony byly i ty originální JPEG obrázky znovu podrobeny JPEG kompresi a vůči tomu originálu se pak porovnávala výsledná komprese.
WebP měl 41.30, respektive 39.80 % a "re-JPEG " 22.37, respektive 14.62 % (podle toho jestli z testu vylučovali obrázky, kdy při kompresi došlo naopak ke zvětšení velikosti obrázku).
Takže při opětovné rekompresi tech JPEGů do téhož formátu získali úsporu až 22 %.
Jen se opravím, tím "originální JPEG obrázky" a "opětovné rekompresi tech JPEGů do téhož formátu" jsem nemyslel jen JPEGy, ale i těch zbylých 10 % (PNG, GIF, ...).
A ještě s tím související reakce na příspěvek od "benzin" níže, že přišoupnutím PNG a GIF pomohli WebP - stejně tak tím ale pomohli i JPEGu. Myslím, že ten poměr 90:10 (JPEG:ostatní obrázky) odpovídá zastoupení těch formátů na webu.
P.S.: Samozřejmě je mi jasné, že když si Google sám vypracuje studii na svůj vlastní formát, že to musí vyjít dobře :-) a vím, že statistikou se dá manipulovat. Nechci se Google zastávat, jen se dobrat k rozumnému závěru.
Nejprve potřebujete stabilní nástroje které s tímto formátem bude možné používat - Gimp, imagemagick. Než to probublá do stabilních vydání, tak to tak 4-5 roky vezme. To to pomalu začnou interně používat služby co masivně ukládají obrázky, protože jim to uspoří místo.
Tou dobou to začne být podporované v nezanedbatelné části prohlížečů. A první lidé si s tím začnou hrát. To zabere tak 4 roky.
Takže tak dejme tomu za 8 let bychom mohli začít vidět nějaké signifikantní (tj. alespoň 1 procento ve statistikách) používání WebP.
Podívejte se například na historii PNG. Specifikace vznikla v roce 1995. V roce 2000 to teprve podporovala vetšina prohlížečů a řekl bych že tak od roku 2004 se to přestali lidé bát dávat na stránky.
Takže za 8 let uvidíme. Ale znáte to - předvídání je obtížné - zejména pokud se jedná o budoucnost.
Jasne, je to jen navrh, udelaji se knihovny, doladi se problemy a zacne se to prosazovat.
O prohlizece se nebojim, ty otevrou i RGB a jine exoticke formaty, ktere nikdo nikdy nevidel ... vzdyt jich mnohe prohlizece umi i pres 200 ... jeden navic je trivialita.
O editory se taktez nebojim tam je to podobne ... stejne si to da do svojeho formatu ... a exportovat to snad taky bude umet.
Co je otazka jsou browsery ... Chrome/Mozilla je jasna ... asi i Opera ... zase google ma moznost to prosadit ... staci, kdyz do toho da picasu ci prohledavani fotek ... a ono to muze i fungovat, staci davat vyzvy k instalaci pluginu ... flash si taky kazdy instaluje ... no a presvtedcit pornoprumysl a je vymalovano.
Fotaky, to je jina, nejde jen o to co chce, ale o to, ze vetsinou neumi pocitat destinne cisla, tedy jen celociselne vypocty ... a taky to chce pocitat rychle ... a o tom to je, HW RISC chip, ktery nebude brzdit fotak ...
Podle obrázku, který je přiložený v tomto článku (lidi na parníčku), zcela jasně a zřetelně je vidět, že JPEG je lepší.
Stačí, když se zaměříte na červené plochy - když se podíváte na 100% přiblíženou fotku na oblast červené čepice, hlavně na jejich okraje, tak to co tam provede WebP je prasárna neuvěřitelná. Totéž je i vpravo nahoře u červeného komínu. Takže Google, znovu a lépe prosím.
A to jsem to prohlédl opravdu jenom zběžně...
JPEG to nikdy nenahradi. Vemte si priklad MP3, je tu uz delsi odbu spolu s OGG, kterej je uspornejsi i kvalitnejsi (umi 24bit a vysoky rejty) a nestalo se. PNG melo nahradit plnobarevnost oproti GIFu a nestalo se. WebP zrovna tak nenahradi JPEG. Google to jiste protlaci miimalne na webu vsude nebo spis si vyrobce prohlizece nedovoli to tam nepodporovat, ale ty dva formaty tu maximalne budou spolu jako u jinych, dnes jiz rozsirenych, alternativ.
Pokud se velikost obrazku snizi o 40% mohlo by se sdat, ze se rychlost nacistani take snizi jen o 40%. Neni tomu tak, prinos je vyssi, doba se muze zkrati vice, protoze na webovy server bude nizsi napor.
Ano, vedlejsim efektem mensi velikosti obrazku je snizeni zateze webovych serveru a naroku na pripojnou linku. Tato zmena neni tedy jen o koncovyh uzvatelich vetsi dopad (pozitivni) pociti poskytovatele obsahu. Obrazky take zaberou mene mista v ruznych "cache", takze se jich tam vejde vice, atd...
Hlavnim problemem je v soucasne dobe kompatibilita, bude chvili trvat nez se novy format usadi a prosadi. Napad se mi to zda vyborny a drzim WebP formatu palce!
V tomto prispevku se rozebira, jaky dopad ma snizeni velikosti DEB balicku o 3% a jaky to ma dopad na servery. I pouha uspora 3% se vypati...
https://lists.ubuntu.com/archives/ubuntu-devel/2009-July/028534.html
Nevzpominam si, kdy jsem naposledy videl aplikaci pro obecne/masove pouziti, ke ktere jsou k dispozici binarky pro linux a nikoliv pro win. Teda ne, ze by me chybely ... :-)
Dale je mi zahadou, ze mega-firma jako google, uvadi s velkou slavou neco radoby revolucniho a pritom neni schopna vydat k tomu SW soucasne portovany do vsech uvazovatelnych platforem...
Nebo myslite, ze kompilace pro x64-linux je dramaticky jednodussi nez pro 32-bit, Win, Mac, atd...? Leda, ze by si google myslel, ze uzivatele Win a Mac stejne nebudou schopni tu konverzni utilitu pouzit ani dle navodu...
Myslím si že Google klidně toto nasadí jako formát pro svůj datový sklad kam si syslí vše možné od picasa alba až po náhledy obrázků z webu. Tím už dost ušetří. Mohl by to už při vstupu u uživatelů převádět do svého formátu a s ním pracovat, uživateli by pak nazpátek poskytoval do chromu WebP a ostatním jpg. Navíc by do toho mohl nasadit nějaké stream funkce kdy bude jen jeden soubor originál a bude ho možné zoomovat a plynule načítat a ne ukládat to ve třech a více velikostech souborů.
I když denně miliony foťáků chrlí jpg, nebude WebP problém.