Názory k článku
Má nový formát WebP od Google šanci nahradit JPEG?

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.

a pritom zakódovať obrázok s JPEG stratovou kopresiou a alfa kanálom je úplne jednoduché. stačí rozdeliť obrázok na dva obrázky jeden bude obsahovať RGB kanály a druhý iba alfa kanál a obidve časti zakódovať ako JPEG a pri načítaní obrázku obidva obrázky spojiť.

A ktory prehliadac to teda podporuje?

ž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.

tak toto zvladne uplne vsetko, staci mat dva subory...

Staci jeden JPEG soubor a oba obrazy posadit vedle sebe, jako to delaji 3D objektivy pro fotaky. Tohle opravdu neni problem.

No to problém klidně může být, jelikož je to o 80% větší než by mohlo být.

Úplně vám nerozumím a popravdě mne ani nějaké teoretické možnosti nezajímají. Pošlete jediný odkaz, kde se toto skutečně používá. Průhledná PNG jsou běžná, průhledné JPG jsem nezaznamenal. Pokud takový odkaz neexistuje, evidentně to JE problém.

Ja odpovidal na 3D...

Stereoskopie proces zaznamu 3D obrazu... a ja mluvim o ulozeni 3D obrazu porizeneno stereoskopii do JPEG souboru...
JPEG Stereo (.jps) je JPEG kde sou oba obrazy posazeny vedle sebe... cili vicemene to, o cem sem mluvil...

Úplně vám nerozumím a popravdě mne ani nějaké teoretické možnosti nezajímají. Pošlete jediný odkaz, kde se toto skutečně používá. Průhledná PNG jsou běžná, průhledné JPG jsem nezaznamenal. Pokud takový odkaz neexistuje, evidentně to JE problém.

Cpat pruhlednost do ztratoveho formatu je podle me k nicemu. Ztratova komprimace masky nedava moc dobre vysledky. Podle me to ani nikdo moc nechce.

Asi ten Microsoft, ne?

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 ...

TIFF není formát! A psát o Postscriptu a PDF pokud jde o webovou grafiku může leda šílenec.

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 :-)

Google jen "objevil", ze lidi pouzivaji nevhodne nastroje (a/nebo nevhodne pouzivaji vhodne nastroje).

Neni mi ale jasne, jak by ten jeho nastroj zarucil, ze ho lidi budou pouzivat spravne.

Microsoft je samozřejmě pro, dokonce takový formát navrhl a podporuje ho v IE9 :)

bez jakékoliv znalosti té informace začnu tipovat:
že ono je to licenčně ošetřeno tak, aby nikdo bez obav do toho nemohl jít?

Microsoft has patents on the technology in HD Photo -> JPEG XR.

K tomu se sluší ještě uvést jaká je licence za použití.

http://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise

Také už existuje, volá sa djvu... a má aj iné milé vlastnosti, ako napríklad podporu textovej vrstvy, podporu nestratovej vrstvy nad stratovým pozadím, vynikajúci kompresný algoritmus pre bitonálne obrazy atď...

Len sa veľmi neujal.

Tvrdíte, že djvu má "vynikajúci kompresný algoritmus pre bitonálne obrazy", ale když jsem pár takových souborů převedl do obvyklého PNG formátu, tak jsem dosáhnul ještě menší velikosti souborů. Takže marketingovým blábolům o zázračném djvu formátu nevěřím.

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/nes­chopný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.

Nikdo. A dnes?

No vidíš a já bych skoro řekl, že když Chrome začínal, tak řada lidí říkala, že to znamená konec Firefoxu :)

Firefoxu urcite ne, spise bych rekl konec IE. Osobne jsem dal firefoxu sbohem a presel na Chrome(win) a Chromium(linux). A jinak uz jit nehodlam.

Já myslím, že to šanci má. 30-40 % úspory je docela dost. Může se z toho udělat konkurenční výhoda, něco ve stylu: "S naším foťákem XY můžete vyfotit až o 40 % více fotek než u jiných značek".

ked tu fotku nikde neotvori a uz vobec nie v starom upiratenom photoshope, tak ten fotak skoncil

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...

a preco by ju ako nemal otvorit? preco vsetci mudujete ako to nejde a odvolavate sa na stav teraz? ak ho bude goole naozaj chciet pretlacit, urobi vsetko preto aby ten format bol pouzitelny v kazdodennom zivote, ssiu na to ma..

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.

... co by se to tak velké společnosti, jako je Google, nepodařilo s nečím inteligentním. Flash si taky musí všichni uživatelé doinstalovávat a když jim wokenní Firefox řekne "Klepni sem a budeš mít Flash", může jim zrovna tak říct "Klepni sem a budeš mít WebM+WebP".

Ale WEPM uz je ... treba v opere a nemuzu si ho vynachvalit na YT, pokud tam existuje video v danem formatu.
Flash a adobe to je jen takove svinsto zamorujici web ...

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).

"Zadavatel se zeptá webdesignera
Tohle má na starosti kodér a ten to udělá tak, jako v dobách, kdy PNG byl nový formát:

<object data="obrazek.webp" height="600" width="800" type="image/webp">
    <img src="obrazek.jpg" height="600" width="800">
</object>

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...

Pouzivat JPEG2000 ve fotoaparatech by bylo plytvani, nebot JPEG je pro vysoka PSNR lepsi.

Je mi líto, ale na Rootu bych alespoň čekal nástin toho, jak to funguje, ne manažerské úvahy o tom jak a co. Petra si dávám do black listu. Možná zbytečný výkřik, ale muselo to ven :-(

Možná by stačilo si to přečíst, ne?

Čá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.

JJ persne tak. Nehlede na to ze takhle spatlali dokopy nekolik ruznych pristupu. Asi kdyby tim zmensovaly jenom cisty JPEG, nebyl by ten vysledek tak uzasny, tak tam radsi prisouply i PNG a GIF.

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ě...

Koukal jsem opravdu pečlivě a žádné výrazné rozdíly nevidím. Ta fotka je stejně mizerná v obou verzích.

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.

Tvrdíte, že "PNG melo nahradit plnobarevnost oproti GIFu a nestalo se."
Chtěl bych se zeptat, na které planetě a ve kterém století žijete?

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

Google akorat prokazal, ze spousta zejmena malickych souboru je na webovych strankach nevhodne kodovana a ze prekodovavat obrazky ulozene v JPEGu JPEGem2000 je nesmysl.

Takhle se vysledky komprimacnich algoritmu neprezentuji. Takhle se dela marketing.

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...

V historii nevyhrával ten kdo byl nejlepší, ale většinou ten kdo byl dostatečně dobrý a přitom levnější (v tomto případě menší). A to myslím WebP je.

O kolik je levnější WebP?

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.

JPG je tu už celkem dlouho a když to sníží objem dat, tak jedině dobře. Ikdyž stále budou chytráci, co na webu budou mít obrázek 300 x 200px zmenšení z 2000 x 1500px

snadno upravim aplikaci tak aby servirovala WebP tem prohlizecum ktere to umi a ostatnim poskytla stary jpeg ... usetrim i tak spoustu bandwitch ktery musim platit.