Nový formát obrázků WebP od Google

Google přišel s novým ztrátovým formátem obrázků WebP. WebP používá stejné kompresní techniky jako formát videa VP8 a má mít podstatně lepší kompresní poměr než JPEG a JPEG 2000 (více viz studie). Kontejner je založený na RIFF. Vývojáři Chromia již pracují na jeho začlenění do WebKitu.

1.10.2010 11:41 | xm | Zajímavý software

Komentáře

[jozinzbazin]

A kde se flakaji s WebA pro novou alternativu k mp3? :D

[xm]

Tou je OGG Vorbis (součástí formátu WebM je VP8 video + Vorbis audio).

[jozinzbazin]

jenze ogg vorbis prece nepuziva ten novy cool kompresni algoritmus

[xm]

To by mě zajímalo, jak bys chtěl kompresním algoritmem na obraz komprimovat zvuk :-P

Google nevymýšlí znovu kolo, WebM používá omezený Matroska kontejner, VP8 video a Vorbis audio. Žádný NIH syndrom se nekoná.

Podobně WebP používá standardní RIFF kontejner a VP8 obraz (stejně jako jsou ve VP8 videu komprimované klíčové snímky).

[Grunt]

To by mě zajímalo, jak bys chtěl kompresním algoritmem na obraz komprimovat zvuk

Já se s tím hraju docela běžně. Třeba hudbu jsem zkoušel komprimovat JPEGem. Ale ne že by to k něčemu moc snad vedlo.

[Marek Bernát]

Akože si z tej zvukovej stopy vyrobil monochromatický 1xN pixelový obrázok? Alebo si to ešte nejako naskladal za sebou, aby každý riadok obsahoval rozumne dlhé úseky (ideálne tak, aby bol obrázok vo vertikálnom smere kváziperiodický).

[Grunt]

Čoveče, ani nevím. Prvně jsem hudbu převedl do RAW PCM a pak myslím něco ve smyslu convert -depth 8 -size 512x512 RBG:hudba.raw … Jasně, byl to jenom barevný šum, ale šlo to (ba co víc, tak do QP kolem 90 ani ten odstup S/N nebyl tak strašný).

[Grunt]

Jinak je to vhodné spíš k demonstraci.

[yac]

To by mě zajímalo, jak bys chtěl kompresním algoritmem na obraz komprimovat zvuk :-P

Signál jako signál! Místo ve dvou dimezních se to udělá v jedné a je to :)

[Marek Bernát]

Nom, nie úplne. Fourierka síce funguje rovnako, takže frekvenčná analýza bude podobná, ale vo vyšších rozmeroch má každý bod viac susedov a vďaka tomu sa toho dá podstatne viac optimalizovať.

[Grunt]

No když už nic, tak kvantizace u JPEGu a kvantizace u MPEGu funguje naprosto odlišně, takže to stejně moc nemá smysl.

[Marek Bernát]

Naprosto odlišne v zmysle, že používajú inú kvantizačnú maticu? Upozorňujem, že o MPEG neviem vôbec nič (o JPEG aspoň niečo)

Ale ja by som bol aj na video schopný použiť analóg JPEG algoritmu. Koniec koncov aj video je len obrázok, len má ďalší rozmer naviac. Zobral by som si bloky 8x8x8 a hurá na ne s DCT + kvantizáciou

[Grunt]

Naprosto odlišne v zmysle, že používajú inú kvantizačnú maticu?

Ty zvukové nepoužívají kvantizační matici, ale psychoakustický model (říká se mu tak protože se snaží simulovat podmínky přijímače – lidského ucha a mozku) při kterém se každý frame krom MDCT (nebo jen sub-band filter bankama podobné Waveltům v případě Layer II, Musepacku,… to je vcelku šumák) ještě převede FFT (viz) a přímo na konkrétním daném signále o velikosti okna se určují prahy a podle nich se teprve in/out smyčkou přidělují bity jednotlivým pásmům až do vyčerpání zásobníku (resp. v terminologii MPEG rezervoáru). Nehledě na úplně jiné maskovací křivky, absolutní práh slyšitelnosti (to u obrazu není) a pre-masking a post-masking (též u JPEGů není). Spíš bych to přirovnal k video kompresi s psy-rd optimalizacema.

Ale ja by som bol aj na video schopný použiť analóg JPEG algoritmu.

Nechci do toho kecat, ale to se také používá. Viz MJPEG.

[Marek Bernát]

Dík za kvantum informácií. Síce skoro ničomu nerozumiem, ale idem sa vzdelávať

[Grunt]

Ono to není až tak strašné. Jak máš základy Fourierovy analýzy (nejobtížnější překážka na celé věci), tak na to stačí tužka a papír a troška času.

[Marek Bernát]

Fouriérka je to jediné, čomu na tom rozumiem Nepoznám tie bežné veci, často skôr empirického než matematického charakteru. Ako prah počuteľnosti a pod.

[Marek Bernát]

Btw, ak dobre vidím, ten MJPEG je niečo úplne iné, než som mal na mysli ja. Ja som chcel robiť 3D DCT (tj. aj v časovom smere). Ale MJPEG robí 2D DCT pre každý frame zvlášť, čiže absolútne nevyužije koreláciu medzi po sebe idúcimi framemami. Čo je asi rovnako efektívne, ako keby JPEG používal 1D DCT pre každý riadok zvlášť. IMHO totálna blbosť

[Grunt]

Jasně. MPEG je skoro to stejné (jen ne DCT nebo jinou transformaci do třetího rozměru…ono by se to stejně na cosiny docela blbě mapovalo a jejich kvantizaci by psychovizuální system nemusel nést tak dobře), jen využívá právě korelaci mezi jednotlivými snímky + kompenzaci pohybu (v podobě pohybových vektorů…ale to se dá stejně vypnout) aby se ještě víc snížil obsah dat reziduálních snímků (viz příklad).

[Marek Bernát]

Netuším, jak by na to reagoval psychovizuálny systém, ale určite je možné navrhnúť kvantizačnú maticu tak, aby mu to extra nevadilo. Otázka len je, koľko bitov sa nakoniec ušetrí, ak chceme zachovať dostatok informácie. Tipujem, že to moc efektívne nebude, inak by sa to už dávno používalo

O tej kompenzácii pohybu som už počul. Celkom by ma zaujímalo, jak vyzerá algoritmus hľadania toho pohybu. Matematicky si viem predstaviť úlohu, že chcem minimalizovať rozdiel dvoch obrázkov cez všetku množinu posunutí (a tiež natočení/škálovaní?) druhého obrázku, ale priamo takto by to bolo zúfalo neefektívne. Na druhej strane, ak človek testuje posunutie v zlom smere, tak pomerne rýchlo asi príde na to, že je ten rozdiel obrovský, takže väčšina smerov sa dá asi rýchlo vyradiť a na zvyšné použiť nejakú rozumnú formu bisekcie. Prípadne netreba testovať celý obrázok, ale len dostatok náhodne zvolených pixlov. Aspoň tomu nasvedčuje ten tvoj link z wiki, kde ten obrázok rozdielu je skoro celý čierny.

[Hynek (Pichi) Vychodil]

Podobně jako se pomocí FFT dají efektivněji dělat korelace a konvoluce tak se na stejném principu dá zjistit optimální posun. Na podobném principu fungují třeba optické myši, Tamara/Ramona/Veněra a spousta dalších aplikací. Prostě se udělá FFT jednoho snímku a FFT druhého. Výsledná spektra se vynásobí nebo podělí. Tam kde je minimum případně maximum amplitudy je "rychlost" pohybu. Případně si uděláš zpětnou FFT a máš to v absolutních hodnotách. Takhle nějak. Musel bych se znova podívat na ty vzorečky, přece jen je to pěkných pár let, co jsem to musel umět přesně. Něco jako "spektrum korelace je součinem spekter a spektrum konvoluce je jejich podílem". Obdobně se dají udělat i ty ostatní kompenzace, jen jinak. Udělá se matematický model a pak se hledá extrém. Podobně jako když se kompenzují optické vady.

[Marek Bernát]

Ó, dík za pripomienku. Človek je na konvolúciu zvyknutý z hodín matiky, ale takto priamo som ju nikdy neaplikoval Pritom je to presne tá informácia, ktorú chceme: konvolúcia dvoch obrázkov ukáže smery, o ktoré sa treba posunúť, aby bol maximálny prekryv. Čo sa týka vzorčekov, tak F(f*g) = F(f)F(g), kde * je konvolúcia.

Btw, s podielom dvoch fourierovských obrazov som sa nikdy nestretol a nie je mi nejak zrejmé, že by táto operácia mala nejaký rozumný matematický zmysel. Ale asi to nespomínate len tak, takže sa s tým skúsim trochu pohrať.

[Grunt]

Btw, s podielom dvoch fourierovských obrazov som sa nikdy nestretol a nie je mi nejak zrejmé, že by táto operácia mala nejaký rozumný matematický zmysel.

WTF? Vždyť podíl dvou fourierovských obrazů je roven dekonvoluci v časové doméně, kterou je téměř nemožné konvenčně implementovat. A to nejsou moje slova:

Likewise, the process of deconvolution (or deblurring), which is hard if not impossible in the spatial domain, becomes simply a division in the frequency domain. That is, one divides the Fourier Transform of the blurred image by the Fourier Transform of the filter image that created the blurring.

[Marek Bernát]

Pojem dekonvolúcia mi bohužiaľ tiež nič nehovorí Zrejme to bude dosť data-processing špecifický pojem, ktorý sa v abstraktnej matematike nevyskytuje. Alebo nám ho proste len zatajili

[Grunt]

Prostě opak konvoluce.

Alebo nám ho proste len zatajili

Též si myslím.

[Marek Bernát]

Húm, tak som pozrel zápisok na wiki a jedná sa o triviálne pozorovanie, že rovnica

f * g = h

sa dá vyriešiť pomocou f = F^{-1} (F(h) / F(g)). Je pravda, že takúto vec som vo fyzikálnych aplikáciách riešil viac než raz, ale je to tak triviálna operácia, že som nečakal, že bude mať meno

[Grunt]

Zrejme to bude dosť data-processing špecifický pojem

Jinak to je víc než možné, protože mě nic jiného než Wienerova dekonvoluce používaná k doostřování obrazu snad ani nenapadá.

[Grunt]

Netuším, jak by na to reagoval psychovizuálny systém, ale určite je možné navrhnúť kvantizačnú maticu tak, aby mu to extra nevadilo.

^{[prove needed]} Jenom protože si myslíš, že by něco možné navrhnout tak aby mu to nevadilo ještě neznamená, že to tak i je. Ono v tomhle ohledu se chová lidský psychovizuální systém docela specificky a ty algoritmy jsou jen aproximací snahy o jeho exploitování a když je výhodné použití Fouriera ve dvou rozměrech ještě neznamená, že by to lidský mozek/oči/nervy úplně stejně akceptoval i v rozměru třetím (stejně jako rozdílně akceptuje přesnosti v obraze a zvuku…prostě v každém jinak). Z pohledu reprezentace dat, to už je jiná otázka. Ovšem ne o moc jednodušší.

Tipujem, že to moc efektívne nebude, inak by sa to už dávno používalo

Ono to i efektivnější bude (můj osobní odhad) jenže v téhle oblasti hraje jednu podstatnou roli ještě jedna důležitá věc (mnohdy důležitější než kompresní poměr): komplexnost (popř. ještě implementovatelnost) takové algoritmu. Což také může být překážkou reálnému nasazení.

O tej kompenzácii pohybu som už počul. Celkom by ma zaujímalo, jak vyzerá algoritmus hľadania toho pohybu.

Je jich víc.

Matematicky si viem predstaviť úlohu, že chcem minimalizovať rozdiel dvoch obrázkov cez všetku množinu posunutí (a tiež natočení/škálovaní?) druhého obrázku, ale priamo takto by to bolo zúfalo neefektívne. Na druhej strane, ak človek testuje posunutie v zlom smere, tak pomerne rýchlo asi príde na to, že je ten rozdiel obrovský, takže väčšina smerov sa dá asi rýchlo vyradiť a na zvyšné použiť nejakú rozumnú formu bisekcie.

Přesně takto jak popisuješ také jeden z nich také funguje. Pak už je důležitým jen směr hledání. Mně osobně to nikdy moc zajímavé nepřišlo.

Prípadne netreba testovať celý obrázok, ale len dostatok náhodne zvolených pixlov.

V případě MPEG-1 (a vlastně i všech pozdějších…jen se to různě kombinuje) se to aplikuje na makrobloky (ty jsou myslim 16x16 pro jasovou složku a poloviční pro chrominační) kde už je důležitý jen směr hledání a max. vzdálenost hledání posuvu (radius je myslím tak 16 nebo 32 pelů…záleží na kodeku) kde se to hledá pro každý makroblok a výsledný vektor se zapíše jako delta předcházejících. Takže v případě posunutí celého obrazu jedním směrem budeš mít jeden vektor a ostatní už bude jen kupa nul (která se dobře komprimuje). U MPEG-1 se (AFAIK) natočení/škálování nijak nezohledňuje (bylo by to moc náročné a residua to stejně většinou efektivně vykryjí) a u MPEG-4 se to zohledňuje jen v případě GMC.

Aspoň tomu nasvedčuje ten tvoj link z wiki, kde ten obrázok rozdielu je skoro celý čierny.

Ten je ale černá i bez jakéhokoliv použití predikce nebo kompenzace pohybu, protože rozdíly mezi dvěma po sobě jdoucími snímky už tak nejsou moc velké. S jejich použitím je jen černější (víc nul a víc lépe komprimovatelných hodnot) a proto se to používá.

[Marek Bernát]

> [prove [sic] needed]

Dôkaz je triviálny, pretože existuje kvantizačná matica, ktorá s pôvodnou informáciou neurobí nič: samé jednotky :-P Podobne sa budú chovať aj malé poruchy tejto triviálnej matice. Ale či existuje netriviálna kvantizačná matica, to je druhá otázka Podľa mňa určite áno, ale bolo by sa s tým treba pohrať.

> Komplexnost algoritmu

Tak je to obyčajný DCT (alebo iná verzia fouriera, alebo nejaké wavelety -- to už je vcelku jedno). Čo by na tom malo byť komplexné?

> Je jich víc.

Dík.

> ...moc zajímavé nepřišlo.

Podľa mňa to celkom zaujímavé je. Podobne ako automatická detekcia ľudí na videu/obraze. Teda relatívne zaujímavé; sú veci, ktoré ma zaujímajú podstatne viac

> ...pro každý makroblok...

Aha, tak to ma nenapadlo. Takže človek dostane niečo ako "tok" makroblokov, ktorým sa dajú reprezentovať ľubovoľné deformácie obrazu. To je fajn.

> Ten je ale černá [sic]...

Mne je to jasné. Dôležité ale je, že je "podstatne" černejší, kde slovíčko "podstatne" sa dá kvantifikovať napr. DC koeficientom celého obrazu (ak trochu zneužijem pojmy ).

[Grunt]

Dôkaz je triviálny, pretože existuje kvantizačná matica, ktorá s pôvodnou informáciou neurobí nič: samé jednotky :-P Podobne sa budú chovať aj malé poruchy tejto triviálnej matice. Ale či existuje netriviálna kvantizačná matica, to je druhá otázka Podľa mňa určite áno, ale bolo by sa s tým treba pohrať.

Zapomínáš na jednu velmi podstatnou věc: Kvantizační matice není zvolena jen tak šum bum z plezíru, ale je pečlivě navrhnutá tak aby zrcadlila nedokonalosti lidského psychovizuálního systému. Např. lidské oko je o něco málo citlivější na horizontální frekvence než na vertikální (asi to nějak bude souviset s jeho tvarem), což je zohledněno tak že koeficienty na stejných místech jen v horizontálním směru doprava od DC koeficientu jsou o něco málo menší než naprosto ty stejné koeficienty (resp. se stejnou vzdáleností) ve směru vertikálním pod DC v matici. Stejně je to naprosto se vším v té matici (základní předpoklad je, že lidský psychovisuální systém je méně citlivý na nepřesnosti ve vyšších frekvencích než v nižších). Rozhodně to není o tom, že by udělala DCT nějakého bloku a jen se náhodně pokřivila kvantizační matice. A to že to pro naše oko tak funguje v prostoru ještě neznamená, že naprosto stejná matice bude stejně fungovat i v čase (třeba u toho vertikálně/horizontálního posuvu jsem si naprosto jistý, že by tak určitě nefungovalo). To by se nějaký dobrák musel obětovat pro vědu a udělat ze sebe pokusného králíka, pokud chceme znát odpověď.

Tak je to obyčajný DCT (alebo iná verzia fouriera, alebo nejaké wavelety -- to už je vcelku jedno). Čo by na tom malo byť komplexné?

No 2D DCT už je i tak docela silný zabiják většiny kodeků (krále zabijáků jako deblocking nepočítám). A přidáním ještě jednoho rozměru by se tomu určitě moc nepomohlo.

Podobne ako automatická detekcia ľudí na videu/obraze.

Ono je to docela zvláštní, ale zase jde jen o emulaci toho co máme implementováno v hlavě. A zatím nejefektivnější se ukázalo dělat to přesně tak jako mozek. Včetně té kompenzace pohybu.

Aha, tak to ma nenapadlo. Takže človek dostane niečo ako "tok" makroblokov, ktorým sa dajú reprezentovať ľubovoľné deformácie obrazu. To je fajn.

Otázku jsem nepochopil, takže nevím jak odpovědět. Dostaneš nejprve tok vektorů které reprezentují posunutí všech makrobloků v obraze předchozího snímku a pak jen dostaneš tok makrobloků těch zbytků, které po pohybu zbývají k tomu aby se obraz co nejblíže blížil současnému snímku. Ta kompenzace pohybu už je spíš jen taková doplňková featura a rozhodně se pomocí ní nedají vyjádřit libovolné deformace v obraze. A jinak fajn to je, to je fakt.

DC koeficientom celého obrazu

To se nikde krom Waveletů stejně nepoužívá. Jde spíš o to že zbude míň AC koeficientů.

[Marek Bernát]

> Kv. matica

Napísal si toho dosť, ale nevidím žiadny spor s tým, čo som písal ja Proste nejaká kvantizačná matica asi existovať bude, len by ju niekto musel nájsť.

> ...silný zabiják...

Ale veď FFT beží v NlogN. To predsa nemôže byť zas tak hrozné.

> ...implementováno v hlavě...

Pekné.

> Otázku jsem nepochopil, ...

Tam žiadna otázka nebola, len som si tak nahlas premýšľal a plusmínus napísal to, čo si myslel predtým implicitne a teraz napísal explicitne o tých deformáciách.

> ...stějně nepoužívá...

O to nejde. Len som chcel presnejšie definovať, čo si predstavujem pod čiernym obrázkom. DC koeficient tú informáciu vyjadruje pomerne jasne

[Grunt]

Příloha:

• ukázka_psychoakustického_modelu_1(MPEG-1).png (40631 bytů)

Ty zvukové nepoužívají kvantizační matici, ale psychoakustický model (říká se mu tak protože se snaží simulovat podmínky přijímače – lidského ucha a mozku) při kterém se každý frame krom MDCT (nebo jen sub-band filter bankama podobné Waveltům v případě Layer II, Musepacku,… to je vcelku šumák) ještě převede FFT (viz) a přímo na konkrétním daném signále o velikosti okna se určují prahy a podle nich se teprve in/out smyčkou přidělují bity jednotlivým pásmům až do vyčerpání zásobníku (resp. v terminologii MPEG rezervoáru).

Ještě jsem ti na disku našel scan.

[Marek Bernát]

A trochu okomentovať by si ho nechcel? Neviem jak tebe, ale mne nepripadá úplne self-explanatory

[Grunt]

On je k tomu text o několika stranách a to se mi fakt opisovat nechce.

[Michal Fecko]

Kludne by som taketo alternativy bral:

WebP - obrazky 
WebA - ogg
WebV - ogv 

[Grunt]

Alternativ pro MPEG-1/2 Layer III je tady víc plný kýbl a už pěkně dlouho (třeba taková Layer II). Bohužel o ně nikdo moc nemá zájem.

[kralyk z abclinuxu]

Dost se používá AAC...

[Grunt]

Též to není nic moc.

[kralyk z abclinuxu]

No jo, ale furt lepší než mp3 a někdy lepší než ogg...

[Grunt]

furt lepší než mp3

Těžko říct.

někdy lepší než ogg...

Ještě těžší říct.

[mikirc]

tak mp3 a jeho kvalita je spise z nouze cnost

[Grunt]

^{[citation needed]}

[otula]

Kdysi v nějaké diskuzi na Lživě také jeden vykřikoval něco podobného. Vytvořil jsem mu malý test, kdy jsem prohnal kus houslového koncertu několika enkodéry a požádal ho, aby se teda předvedl a řekl (klidně i za pomoci softwareové analýzy). V tu chvíli po něm nebylo vidu ani slechu, ale zato to zkusilo pár zkušenějších. Můžeš se zeptat Marka Stopky, jak to dopadlo.

[Marek Bernát]

Otázka v tomto prípade ale je, či sa kvalitou myslí hudobná kvalita, alebo kvalita kompresného algoritmu, prípadne nejaká kombinácia oboch. Ak to druhé (a tretie), tak tiež som už počul, že mp3 súbory sú pri podobnej (hudobnej) kvalite ako napr. vorbis podstatne väčšie.

[otula]

Ohledně mp3 versus vorbis jsem četl zcela protikladné informace, a netuším, které z nich jsou pravdivější (tedy platné ve většině případů). Samozřejmě bych byl raději, kdyby byl lepší ten svobodný. Pokud jde o výsledky testu, poslechem nerozeznal výsledky nikdo, frekvenční analýzou Marek našel rozdíly, ale přesto nedokázal rozeznat, co z toho je originál. Tohle není kritika Marka - chci říct něco jiného: komprimovat hudbu pomocí MP3 s datovým tokem 128 kbps je skutečně prasárna, která bije do uší i při reprodukci malými bakelitovými repráčky. Ale pokud mi někdo chce tvrdit, že rozezná 320 kbps od originálu, tak mu neuvěřím, dokud mi to nepředvede.

[Marek Bernát]

No, neviem jak je to na skutočne kvalitnej aparatúre, tam by nejaké rozdiely byť mohli. Ale pre bežného smrteľníka 320 kbps mp3 určite stačia (sám som ich dlhú dobu používal, kým som objavil vorbis). Druhá vec ale je, že 320kbps mp3 sú fakt obrovské a rovnakú kvalitu (ktorú nerozoznám od originálu) dosiahnem s podstatne menším vorbisom. Toľko aspoň osobné skúsenosti, možno som mal len nekvalitný mp3 enkóder, alebo som ho nevedel poriadne nastaviť.

[Grunt]

No, neviem jak je to na skutočne kvalitnej aparatúre, tam by nejaké rozdiely byť mohli.

Jde o to že taková aparatura většinou kurvý frekvenční charakteristiky a prostě na některých místech vytáhne šum nad maskovací práh (alias dynamic-bass boost). Pak není divu, že je slyšet. Na to ale ani není potřeba žádná aparatura za drahé prachy. Na to bohatě stačí dva mé plastové hrčáky s všeříkající funkcí 3D, která dokurví fázi tak že šum je slyšitelný i u 128kbps MPEG-1 Layer III. A nebo trošku povytáhnout jacka u sluchátek (má to myslím rozdělené pásma). Za kvalitní aparaturu já považuju tu co má co nejplošší frekvenční odezvu a zvuk u ní zní opravdu tak jak bylo zamýšleno že bude znít.

[Marek Bernát]

Ak tá aparatúra niečo kurví, tak nie je kvalitná a o takej som sa nebavil.

[Grunt]

No bohužel, taková se v dnešní době za kvalitní považuje (pokud teda vezmeme v úvahu předpoklad, že se dá kvalita vyjádřit/a vyjadřuje se penězi).

[Grunt]

pokud teda vezmeme v úvahu předpoklad, že se dá kvalita vyjádřit/a vyjadřuje se penězi

Teda nebereme-li v úvahu, že ta aparatura s plochou frekvenční odezvou (ale není to samo jen o ní) je většinou ještě 2× tak dražší než ta kvalitní a používá se většinou jen pro vědecké účely/studiové potřeby a jiné speciální případy.

[Marek Bernát]

Nie, ja som mal skutočne na mysli kvalitu a nie "kvalitu" (čítaj cenu). Ale často kvalita s cenou výrazne koreluje a nie je potreba presnejšie rozlišovať.

[Grunt]

Ale často kvalita s cenou výrazne koreluje a nie je potreba presnejšie rozlišovať.

Má zkušenost přesně opačná.

[Marek Bernát]

Tak teraz buď klameš alebo máš veľmi podivné skúsenosti Stačí sa ísť pozrieť do ľubovoľného obchodu s elektronikou, kde si môžeš tovar nechať predviesť. Vždy s cenou rastie kvalita (samozrejme nie priamo úmerne, ale korelácia je tam silná). To isté hudobné nástroje. Za pár korún zoženieš len úplné sračky; niečo na čom sa dá hrať stojí v ráde desiatok tisíc a tie najlepšie kusy sa vyšplhajú až do milióna. To isté foťáky. To isté autá. Takže jednak to takto všade funguje a jednak je to zrejmé aj ekonomicky, lebo keby tie ceny skutočne antikorelovali, tak by ten systém pochopiteľne nebol stabilný (ak niekto teda nemá monopol), čo nepozorujem

Jediná výnimka, ktorá ma teraz napadá, je OS (ale tam je ten monopol) a vôbec softvér. Tam kvalita a cena skutočne často antikoreluje

[Martin Mareš]

Zrovna mezi audiotechnikou se najde protipříkladů spousta: třeba superdrahé elektronkové zesilovače, které objektivně nemají lepší parametry než jejich 10krát levnější transistorové protějšky. Nebo některé "HiFi" kabely...

[Marek Bernát]

Netvrdím, že sa nenájdu vynímky, ale určite to takto nemôže fungovať v globále. Ak sú tie veci skutočne rovnakej kvality ako niečo 10x lacnejšie a ľudia o tom vedia, tak pochopiteľne tú drahšiu verziu nebude nikto kupovať a výrobca skrachuje. Dôvody, prečo to takto občas funguje sú monopol (a s tým súvisiaca neinformovanosť verejnosti o lepších variantoch), prípadne servis (oprava, náhrada, etc.), ktorý pri drahých produktoch môže pokojne tvoriť väčšiu časť ceny.

[Mandarinka]

Ono MP3 v očích lidí hodně škodí to, že při těch všudypřítomných 128kbps, na které se všude hledí, je ještě obyčejně použitý cbr mód. Myslím sice, že u audia to nemá tak katastrofální důsledky jaku u videa, ale stejně to formát sráží. Takže srovnávat 128kbps MP3 a (vbr) vorbis/aac/wma s tím, že MP3 ponechám v CBR, protože to tak dělá každé ucho na webu, je vedle.

Taky mi přijde trochu od věci používat 320kbps CBR, což je taky taková hezká internetová zvyklost (jaký tam může být rozdíl proti největšímu vbr módu - samozřejmě mluvím o Lame encodéru). Ale vzhledem k tomu, kolik lidí je přesvědčených o tom, že musí mít FLAC (a při troše štěstí pak poslouchají na PC nebo konvertují do ipodu)...

[Mandarinka]

A největší hlína je FLAC pro kompresi audio stopy u filmu. Protože kvalita obrazu je 100% saturovaná do té doby, co z nebe spadl aXXo, zřejmě:)

[Grunt]

Taky mi přijde trochu od věci používat 320kbps CBR, což je taky taková hezká internetová zvyklost

To je ta největší kravina kterou jsem kdy viděl a potkat idiota co to vymyslel, bych si smlsnul.

[Grunt]

Ohledně mp3 versus vorbis jsem četl zcela protikladné informace, a netuším, které z nich jsou pravdivější

Jednoznačně Vorbis. MPEG-1 je o něco starší a také o něco méně komplexnější (+ ta debilní PQF). Pár let po MP3 boomu byl představen nový formát od Nipponnů, TwinVQ, který v základu pracuje stejně jako MPEG-1 Layer III (tzn . včetně MDCT a komprese entropie), ale ještě s přídavkem vektorové kvantizace. Čímž mohl dosahovat podobného odstupu S/N jako MP3 tak při poloviční bitrate. No bohužel byl také asi dvakrát tak náročnější na výpočetní čas (což v dobách, kdy MP3 už ždímalo výkon tehdejších kalkulaček téměř na maximum nebylo nic moc). TwinVQ se zas tak populární nestal a téměř se na něj zapomnělo, ale Vorbis pracuje téměř na stejné principu (stěžejní částí a výhodou oproti MP3 je VQ) a byl vypilován do té podoby, že za skoro transparentní se dá považovat tak rozsah 48-64kbps (stereo a v případě AoTuV – dost to záleží kus od kusu).

frekvenční analýzou Marek našel rozdíly, ale přesto nedokázal rozeznat, co z toho je originál.

To lze docela lehce pokud nerozšíříš pásmo ořezu na Nyquistovu frekvenci.

komprimovat hudbu pomocí MP3 s datovým tokem 128 kbps je skutečně prasárna

Proč? 128kbps bylo prohlášeno za transparentní už hodně dávno a s dnešníma kodekama a možnostma? Já už narazil i na MP3 o 96kbps a kdybych se nepodíval kolik to má, tak bych to ani do toho neřekl.

[otula]

Jednoznačně Vorbis.

Tomu jsem věřil, než jsem viděl zmíněný test. Už sice netuším, kde to bylo, ani zda to bylo při nižších, či při vyšších bitratech, každopádně jsem to tehdy v mysli uzavřel tak, že to asi vyjde nastejno, co člověk používá.

Proč? 128kbps bylo prohlášeno za transparentní už hodně dávno a s dnešníma kodekama a možnostma? Já už narazil i na MP3 o 96kbps a kdybych se nepodíval kolik to má, tak bych to ani do toho neřekl.

No já jsem ještě nenarazil na poslouchatelnou hudbu ve 128kbps MP3 (mluvím o hudbě, tedy o tom, co se vytváří pomocí hudebních nástrojů, nikoliv o šílenostech, kterých jsou plná mainstreamová rádia)

[Grunt]

Tomu jsem věřil, než jsem viděl zmíněný test.

Jaký test? Jediný test kterému věřím já je ten který si sám zfalšuju Jasně, bitrate a specifické použití by to mohlo ovlivnit (nehledě na to, že při určování toho co je horší nebo lepší zařazuju poněkud více kritérií než jen výsledné S/N), ale i tak…

No já jsem ještě nenarazil na poslouchatelnou hudbu ve 128kbps MP3 (mluvím o hudbě, tedy o tom, co se vytváří pomocí hudebních nástrojů, nikoliv o šílenostech, kterých jsou plná mainstreamová rádia)

To zní pomalu jako výzva. To budem muset otestovat.

[otula]

Jaký test? Jediný test kterému věřím já je ten který si sám zfalšuju

Právě proto ten můj závěr, že mezi nimi asi nebudou moc velké rozdíly

To zní pomalu jako výzva. To budem muset otestovat.

Nebráním se :)

[Joelp]

jsem pro flac ;) (samo ne na web)

[stativ]

Musepack je docela bezva.

[Grunt]

Ne, není bezva, ale je to jeden z nejlepších kodeků moderní doby (samozřejmě s přihlédnutím k určitému specifickému využití). Bohužel s jeho použitím je to ještě horší než s MPEG-2/4 Audiem.

[tomboytom-deviant]

Já se těším na WebD, má to být nový formát textového dokumentu, uvedení se chystá při příležitosti uvedené ChromeOS.

[JoHnY2]

Nepodarilo se mi vypatrat jestli bude umet RGBA a tim padem pruhlednost jako PNG. Bez rezimu s pruhlednosti je to podle me nedostatecnej pokrok.

[Filip Jirsák]

Vždyť je to ztrátový formát, tedy vhodný pro fotky. Nedovedu si představit, jak pořídím fotku s alfa kanálem…

[pavlix]

Vždyť je to ztrátový formát, tedy vhodný pro fotky. Nedovedu si představit, jak pořídím fotku s alfa kanálem…

Nedostatek představivosti vám zřejmě brání i si představit v JPEGu něco jiného než jednoduchou neupravenou fotku.

[Filip Jirsák]

Představit si dovedu ledacos. Různé bitmapové filtry, efekty a úpravy, ze kterých ovšem nikdy nezvnikne žádný alfakanál, a spoustu dalších úprav (přidání nápisů, vytvoření masky), které mají vektorový charakter a bylo by tedy vhodné je tak ukládat a přenášet ke klientovy. Ale bitmapové úpravy, které vyčarují alfakanál, mne opravdu nenapadají.

[pavlix]

Ne vždycky je dostatečný důvod do bitmapového výstupu zpětně zanášet vektorovou grafiku.

[Filip Jirsák]

Já tedy znám důvod jediný – hloupé cílové zařízení, které vektorovou grafiku neumí.

[kralyk z abclinuxu]

No a co takhle nějaké embedded a podobné, které mají malý výpočetní výkon a kreslit například celé UI z vektorové grafiky není dobrý nápad...

[pavlix]

Doporučuju odpovídat přímo na to, co se píše v komentáři, na jehož odkaz "Odpovědět" klikáte. Nepředpokládám, že byste opravdu upřímně považoval bitmapové cílové zařízení za důvod pro použití vektorové grafiky.

[Filip Jirsák]

Upřímně nepovažuju bitmapové cílové zařízení s předem známým DPI a charakteristikami pro vyhlazování za jediný možný cíl, dokonce jej považuju za velmi nepravděpodobný cíl. Daleko častěji se setkávám s tím, že je výstup určen pro mnoho různých monitorů, displejů a tiskáren, takže předčasný převod z vektorů do bitmapy výsledku jen škodí.

[pavlix]

Pane Jirsáku, zřejmě záměrně ignorujete to, že diskuze se týká právě ořezané bitmapy. Kromě toho vektor není striktně mocnější než bitmapa, a některé platformy, které by třeba i mohly být čistě vektorové, jsou dnes převážně bitmapové.

Můžeme s tím nesouhlasit, atd... ale někdy člověk není v pozici to změnit a potřebuje s danou platformou pracovat tak jak je... ať je vnitřně sebevětší idealista.

[Filip Jirsák]

Pane Jirsáku, zřejmě záměrně ignorujete to, že diskuze se týká právě ořezané bitmapy.

To ignoruju, protože ani z jednoho komentáře nic takového neplyne. Navíc i ten ořez bitmapy se ve většině případů dělá vektorově, a teprve pak se to do bitmapy převádí.

některé platformy, které by třeba i mohly být čistě vektorové, jsou dnes převážně bitmapové.

Což přináší spoustu problémů a jedinou výhodu – zpětnou kompatibilitu. Takže když už se vytváří nový formát, bylo by celkem rozumné udělat to pořádně, a ne ten problémový stav prodlužovat.

[pavlix]

To ignoruju, protože ani z jednoho komentáře nic takového neplyne.

Tak to upřesním, mimo jiné i ořezané bitmapy... sklouzl jsem myšlenkama o něco níže... ale už vy uvádíte třeba zrovna tu masku.

Což přináší spoustu problémů a jedinou výhodu – zpětnou kompatibilitu. Takže když už se vytváří nový formát, bylo by celkem rozumné udělat to pořádně, a ne ten problémový stav prodlužovat.

Tenhle postoj je idealistický a líbí se mi, ale v praxi bývají potřeba i ústupky.

[Filip Jirsák]

Maska podle mne není součástí bitmapového obrázku, ale až jeho použití. Takže při použití maskované fotky na webové stránce bych zvlášť přenášel fotku a zvlášť masku – buď vektorovou, nebo třeba jako PNG. Aspoň by to grafika trklo, co vlastně dělá – pokud bude maska součástí obrázku, udělá plynulý přechod do barvy stránky, ten pak ztrátovou kompresí pomrší a bude se divit, že tam jsou barevné fleky a bude pro fotku nastavovat zbytečně nízkou úroveň komprese, aby tím vyřešil část, která by součástí té fotky vůbec neměla být.

Tenhle postoj je idealistický a líbí se mi, ale v praxi bývají potřeba i ústupky.

Jenže na současném webu je to s těmi ústupky dotaženo ad absurdum – moderní prohlížeče složitě a s podporou nejmodernějších technologií řeší problémy toho, že se používají ty nejstarší možné technologie. Když se vytváří nový formát, který budou umět používat jenom nové prohlížeče, není podle mne důvod stavět jej na omezeních platných před dvaceti roky.

[pavlix]

Jo, JPEG je trochu mrcha, to je pravda. Nicméně navrhované řešení pomocí "třeba" PNG je zrovna bitmapová varianta.

S vaším názorem na současný web souhlasím. Nicméně i návrhář formátů by neměl zamezit jejich použití v dané době a za daných podmínek, pokud je do těch podmínek určen.

[Filip Jirsák]

To PNG bylo myšleno právě pro případ, kdy někdo chce tu masku zadávat pixel po pixelu.

Myslím, že návrhář nového formátu pro fotografie na webu v roce 2010 nezamezí použití toho formátu tím, že do jeho návrhu nezahrne alfakanál. Proti současnému stavu v žádném případě nedojde ke zhoršení. Vedle toho se může udělal návrh na maskování objektů (v CSS3 pokud vím zatím není), který bude obecný a nebude fungovat jen na tento nový formát, ale na všechny objekty.

[pavlix]

Jo to zní rozumně... a děkuju za poučnou diskuzi, málokdy se díky vám dostanu k něčemu pro mě novému... ale zrovna kombinace JPEG-like fotografie a PNG-like mapy je docela zajímavá, ale pro obecné použití by to muselo jít dostat i do jednoho kontaineru.

Jinak pořád nevidím vadu v tom nabídnout u JPEG-like formátu průhlednost, třeba kvůli amatérským "ořezům" fotek u lidí, kteří neumí nebo nemají důvod se učit práci s vrstvami/maskami, natož používat mix dvou různých formátů zároveň.

Takže ano, vidím smysl v obojím :).

[Filip Jirsák]

Pokud bych tu troubu měl hodně rozhicovat, viděl bych raději nějaký volnější kontejner na úrovni souborového systému – třeba když dnes uložíte webovou stránku i s příslušenstvím, je to několik souborů, které „patří k sobě“, podobně by to mohlo být s tím obrázkem a maskou. GUI aplikace by s tím pak pracovaly jako s kontejnerem, ale operační systém by to viděl pořád jako jednotlivé soubory.

Důvod, proč se mi nelíbí cpát různé věci do jednoho kontejneru, je variabilita implementací a možnost požádat o to, co která implementace umí. Každý prohlížeč může serveru poslat seznam mime typů, které podporuje (dokonce i s preferencemi) – což je mimochodem jeden z velmi dobrých nápadů na webu, který se bohužel skoro nepoužívá; přitom kdyby se trochu rozšířil, odpadla by spousta problémů s detekcí toho, co vlastně prohlížeč umí. Takže prohlížeč by poslal požadavek na obrázek s tím, že umí JPG, PNG a SVG, a server by mu poslal obrázek v JPG a masku v SVG. Samozřejmě byprohlížeč mohl místo požadavků na mime typy souborů posílat požadavky na složky kontejneru, ale to jepodle mne méně obecné. Obrázek v JPG by pak mohl například nějaký proxy server kešovat i pro prohlížeče podporující jen JPG a PNG, u společného kontejneru by musel kešovat dva různé soubory s velkou částí obsahu stejnou.

Ale jak říkám, to je cesta, kterou by se podle mne měl web ubírat v příštích letech, ne něco, co by bylo zítra hotové. Ale když srovnám WebP s alfa kanálem s HTML5 a podobnými současnými trendy, je vlastně WebP báječný formát s jasnou koncepcí…

[kralyk z abclinuxu]

Pokud bych tu troubu měl hodně rozhicovat, viděl bych raději nějaký volnější kontejner na úrovni souborového systému – třeba když dnes uložíte webovou stránku i s příslušenstvím, je to několik souborů, které „patří k sobě“, podobně by to mohlo být s tím obrázkem a maskou. GUI aplikace by s tím pak pracovaly jako s kontejnerem, ale operační systém by to viděl pořád jako jednotlivé soubory.

Něčím takovým je ODF - všecky ty soubory co "patří k sobě" zipuje...

[Grunt]

K tomu lze jen dodat citaci z dokumetace libjpegu:

Special color spaces
--------------------

The JPEG standard itself is "color blind" and doesn't specify any particular
color space.  It is customary to convert color data to a luminance/chrominance
color space before compressing, since this permits greater compression.  The
existing de-facto JPEG file format standards specify YCbCr or grayscale data
(JFIF), or grayscale, RGB, YCbCr, CMYK, or YCCK (Adobe).  For special
applications such as multispectral images, other color spaces can be used,
but it must be understood that such files will be unportable.

a JPEG FAQ:

A more reasonable approach is to store an alpha channel (transparency percentage) as a separate color component in a JPEG image. That could work since a small error in alpha makes only a small difference in the result. The problem is that a typical alpha channel is exactly the sort of image that JPEG does very badly on: lots of large flat areas and sudden jumps. You'd have to use a very high quality setting for the alpha channel. It could be done, but the penalty in file size is large. A transparent JPEG done this way could easily be double the size of a non-transparent JPEG. That's too high a price to pay for most uses of transparency.

The only real solution is to combine lossy JPEG storage of the image with lossless storage of a transparency mask using some other algorithm. Developing, standardizing, and popularizing a file format capable of doing that is not a small task. As far as I know, no serious work is being done on it; transparency doesn't seem worth that much effort.

JPEG samotný kanál průhlednosti nijak nespecifikuje ale ani nijak nezakazuje (nehledě na to, že JPEG je pouze metoda (implementovaná ve spoustě jiných formátu, ba co dokonce i v TIFFu) a její implementace do obrazového formátu je JFIF, který je tak jednoduchý, že možná ta jednoduchost brání implemenaci něčeho takového. Oficálně je JPEG/JFIF barvoslepý, takže nic nebrání přepnout do barevného prostoru CMYK, tři kanály vyplnit Y,Cb a Cr a do čtvrtého pastnout průhlednost. No s přenositelností čehosi takového už to asi bude horší.

[pavlix]

Good point.

[xm]

Mě napadají třeba ořezané fotky (do určitého tvaru, vyříznutá určitá část fotky která má být průhledná, vyříznuté jen postavy či nějaké objekty, atp.). Na to by se alfa kanál vskutku hodil.

[pavlix]

Jenže pan jirsák pravděpodobně odpoví (počkáme si), že ten ořez musí být nutně vektorový a přiložený k originální fotografii místo její úpravy. Zřejmě proto, že cílové zařízení to přece taky bude umět spočítat, tak proč bysme mu měli pomáhat.

[Filip Jirsák]

Pomáhat mu může nějaký mezistupeň – proxy, původní server… Cílové zařízení také klidně může být hlasový syntetizér, který by dokázal z „fotografie“ přečíst alespoň nápis, který tam ve skutečnosti je, jenže nějaký pečlivý grafik mu „pomůže“ tak, že text přemění na změť bodů.

[pavlix]

To už je fantazírování, které je sice zajímavé, ale s původním vláknem

[pavlix]

nemá nic společného.

[__dark__]

Třeba color-matrix je jeden z filtrů, který to dokáže

[xm]

Alfa kanál (průhlednost) WebP umět bude, minimálně je to plánované. Viz odkazovaný blogpost:

We plan to add support for a transparency layer, also known as alpha channel in a future update.

[Mandarinka]

RGb, těžko říct. VP8 podporuje pouze YV12 (to znamená 4:2:0 subsampling). Taky jsem přemýšlel, jestli je u něj YV12<->RGB konvertor pozměněn tak, aby byl bezeztrátový (tak to má afaik jpeg-xr a jpeg2000). Jestli prostě vzali existující konverzi určenou pro video tak asi ne. Myslím, že 4:4:4 sampling libvpx neumí.

[Mandarinka]

A kritika od obvyklých podezřelých zde.

Shrnuto: libvpx je momentálně tak mizerná, že to nemá cenu.

[xm]

To je ovšem jen otázka (ne)kvality enkodéru libvpx (který je zjevně optimalizován na PSNR, žádné psy optimalizace nemá), formát jako takový je technicky podstatně lepší než JPEG.

[xvasek]

No, určitě je zajímavé podívat se na obrázky a přečíst si technické pozadí, ale tu "politiku" (jakože proč by měl vznikat nový formát, když je tady jpeg od 1992 a nikdo ho nikdy nepřekonal v rozšířenosti) si mohl odpustit. Myslím, že výkonný, plně otevřený a univerzální formát pro obrázky, který nepostrádá žádné featury, by svět určitě potřeboval, protože žádný takový zatím nemá.

[Grunt]

univerzální formát pro obrázky

Přeju hodně štěstí při jeho vývoji. Už by se mělo někdy matematicky dokázat, že něco takového je technicky nemožné zkonstruovat.

[Vskutečnosti Saýc]

Dukaz, ze neexistuje univerzalni kompresni algoritmus je celkem znamy. Ted ho jenom rozsirit na ztravovou kompresi.

[:::]

univerzalni format neznamena ze by musel pouzivat jeden univerzalni kompresni algoritmus. Slo by treba udelat ze podle nastaveni pri ukladani by se vybral jeden z kompresnich algoritmu...

Ale jinak osobne nevidim moc rozdil mezi tim mit jeden format kde uvnitr muze byt 10 ruznych algoritmu nebo mit 10 ruznych formatu...

[Grunt]

Slo by treba udelat ze podle nastaveni pri ukladani by se vybral jeden z kompresnich algoritmu...

Ale jinak osobne nevidim moc rozdil mezi tim mit jeden format kde uvnitr muze byt 10 ruznych algoritmu nebo mit 10 ruznych formatu...

No a to je právě ten problém. Když se např. navrhoval MPEG-1 hledělo se na to aby každá vrstva byla stejná jako ta předchozí a jen měla něco navíc. Stejně jako se hledí při návrhu jakéhokoliv MPEG formátu na to aby to mělo co nejvíce stejných věcí a přidávalo se jen něco málo navíc (rozhodně ne žádný core algoritmus…též důvod proč DCT zamrzne v MPEGu už asi na věky a proč při při vybírání transformačního algoritmu museli být extra pečlivý). Např. ffmpeg má jeden soubor kde implementuje soustu věcí pro komplet celé MPEG (a to MPEG-1/2 až MPEG-4 a druhý soubor pro celou skupinu MPEG audia) a ostatní už jsou jen specifické soubory které jsou potřeba pro svůj kodek. Spousty algoritmů by neúměrně prodražilo cenu DSP čipu a určitě i ztížilo implementaci. Důvod proč většina DVD přehrávačů umí zobrazovat i JPEG obrázky i když to asi naprosto postrádá smysl je ten, že když už je v čipu implementován MPEG, tak doimplementovat JPEG je naprostá hračka a byly by blázni kdyby tak neučinili (když už nic, můžou si přidat o nálepku navíc na obálku). A to je i stejný důvod proč když už něco umí přehrát MPEG-4 AVC, tak to většinou přehraje i MPEG-4 ASP, MPEG-1/2, MPEG-1/2 Layer XXX,VC-1,JPEG, MJPEG, ale ne kupř. Theoru nebo Vorbis. Návrh takové univerzálního formátu by byl extra těžký job.

[Radovan Garabík]

Zaujímalo by ma, ako znesie porovnanie s c44 (of djvu fame). Škoda, že djvu je tak málo rozšírený, ako alternatíva k png/jfif by bol skvelý...

[l4m4]

Proč k PNG, který je bezztrátový, a má tedy úplně jiný okruh [vhodného] použití?

[Radovan Garabík]

Presne preto, že djvu môže obsahovať 3 rôzne formáty: c44 (stratový pre fotografie), jb2 (1-bitová bitmapa pre dokumenty apod., stratový aj nestratový), djvudocument (bitmapa na popredí, stratový obrázok na pozadí).

Nemáme žiadny rozšírený obrazový "formát" (ktorý by bol vnútorne rozdelený na aspoň 2 formáty, a to, ktorý sa použije by zvolil enkodér), ktorý by bol použiteľný ako pre bezstratové kresby (PNG), ako aj stratové fotografie (jpeg). Ak teda nerátame tiff a pdf, ale to je už o niečom inom...

[xm]

Pokud chci bezztrátový formát, použiji PNG (který se dá velice dobře optimalizovat). Pokud chci ztrátový formát, použiji JPEG nebo nověji WebM (až/pokud se uchytí). Nějak nevidím dostatečně velký důvod proč bych musel mít na všechny způsoby využití jediný formát (respektive kontejner). DjVu má svoje využití na scanované dokumenty či komixy (tam skutečně exceluje), ale na cokoliv jiného je to kanón na vrabce (a není k tomu ani určený/vhodný).

[xm]

Pardon, WebP, nikoliv WebM WebM na videa

[Mandarinka]

Ty optimalizátory zas tak moc místa neušetří - tedy pokud ten png neuložíte s mizernou úrovní komprese. Jak HD photo tak jpeg 2000 jsou na bezeztrátovou kompresi lepší (tedy snad až na screenshoty z aplikací s jednolitými plochami a pár čarami...)

A pro jpeg existuje jpegcrush (skript používající jpegtran), který je dokáže bezeztrátově zmenšit závisí to taky na tom, jak mizerný byl ten program co je ukládal).

[mirec]

No práve, že na nejaké tie drobnosti ako vloženie textu a nejakej tej grafiky do fotografie by sa bezstratová vrstva nad stratovou celkom hodila.

[Filip Jirsák]

Ve webovém prohlížeči se na takové věci mnohem víc hodí HTML nebo SVG.

[Grunt]

Nějak nevidím dostatečně velký důvod proč bych musel mít na všechny způsoby využití jediný formát

To ani ne, ale jejich vrstvení (ztrátová + bezeztrátová vrstva) je docela dobrý nápad. Třeba na screenshoty. V případě, že udělám screenshot nějakého okna s pozadím, tak bohužel nic není ideální. JPEG (či jiná ztrátová metoda) sice hodně dobře zakryje to pozadí (dobře ho zkomprimuje), ale rozseká se v okně, kde je hodně jednolitých ploch a téměř dokonalé hrany (které se docela blbě mapují na sin/cos či jiné vlnky). Naopak PNG/GIF (či cokoliv jiného) zas dobře zkomprimuje okno samotné (kupa stejných čísel se dá velice lehce nahradit za jedno), ale zase se rozseká na tom pozadí. A to stejné u vlnkové transformace (v případě Haara z pozadí zbudou jen pixely a v případě Daubechiesové z textů a ikon jen kupa Sinců s nehorázným ringingem). Detekovat takové místa a rozšoupat je do správných vrstev by nemusel být až tak těžké (jen nevím čím by se teda podložilo to chybějící okno v případě ztrátové vrstvy).

[petr_p]

Hlavně djvu je vicevrstvý. Takž se da udělat spodní vrstva ztrátová a vrchní bezstratová. Takže lze zkombinovat výhody obojího do jednoho souboru.

[xm]

WTF? Když už mám jednou v kontejneru uložený bezztrátový obrázek, proč bych tam ještě ukládal ztrátový a zbytečně tak plýtval další místo? Ztrátový si z bezztrátové udělám kdykoliv. Smysl má třeba textová vrstva, to je samozřejmě něco jiného.

[kralyk z abclinuxu]

Bezztrátová může být třeba jen nějaká malá část. Ale praktické použití takové věci mi uniká...

[petr_p]

Třeba již zmiňovaná manga.

Já znám tento způsob použití na archivní knihy. Samozřejmě, že je nejlepší, když se dokument takto již vyrobí. Ale i na scany to má smysl. Samozřejmě že se oddělení textu od pozadí musí pilovat ručně nebo mít dostatečně kvalitní podklad a heuristiku. Ale s tím se počítá, když se zachraňuje analogový originál.

Další využití jsou všelijaké fotky doplněné textem. Pohlednice, PF atd. Několik desítek až stovek megabajtů velký postscript jenom kvůli čtyřem slovům nad bitmapou je opravdu chuťovka. Ať už s tím pracovat nebo to tlačit do tiskárny. Vždyť i PDF tohle zvládá.

[kralyk z abclinuxu]

Třeba již zmiňovaná manga.

Jo, to máš recht, obecně pro knihy s obrázky a komixy by tohle bylo fajn...

[Aleš Kapica]

Pánové, DjVu má tyhle věci vyřešené od r. 1996. Vizte Anatomie DjVu dokumentu.

Jinak pokud jde o ten manuál o DjVu, tak ten na wikibooks už nejspíš zůstane provždy nedokončený, pokud se ho nějaká bláhová duše neujme. V jeho psaní budu pokračovat už tam kde jsem pánem já.

[finn]

Nikdo neříká, že obě vrstvy obsahují tentýž obrázek. Můžu mít ztrátově komprimovaný obrázek a přes to bezztrátově komprimované logo s alfa kanálem (nic lepšího mě nenapadlo, ale jako příklad to snad stačí).

[_dworkin]

Aby to logo slo snadneji oddelat? .)

[_dworkin]

Myslim, ze jsem nezvolil spravnou formu, omlouvam se.. tu moji myslenku slo napsat lepe.

[deda.jabko]

co resite... staci chtit mit fotku a do ni udelat textove popisky, ktere nebudou znicene nejakou DCT...

[Mandarinka]

Zkrátka formát pro softsubování mangy :)

[Marek Bernát]

No, manga samotná je dobrý príklad, kde sa brutálne ničí pôvodný text. Ale netuším, nakoľko je to spôsobené kompresiou a nakoľko nekvalitným scanom.

[xurfa]

no, ono hlavni figl DJVU je, ze kombinuje bitonalni kompresi s normalnima obrazkama...

[Aleš Kapica]

Takže pánové, aby bylo jasno..

user@stroj:~$ file -s pictures/0002717.jpg
pictures/0002717.jpg: JPEG image data, JFIF standard 1.01
user@stroj:~$ time ./webpconv pictures/0002717.jpg
processing pictures/0002717.jpg
Output file pictures/0002717.webp
Used quality=45

real    1m17.567s
user    1m24.085s
sys     0m13.149s
user@stroj:~$ time c44 pictures/0002717.jpg

real	0m8.806s
user	0m7.759s
sys	0m0.643s
user@stroj:~$ ls -alh pictures/0002717.*
-rw-r--r-- 1 user users 191K  1. říj 21.42 pictures/0002717.djvu
-rw-r--r-- 1 user users 4,5M 14. říj  2008 pictures/0002717.jpg
-rw-r--r-- 1 user users 146K  1. říj 21.44 pictures/0002717.webp
user@stroj:~$ djvudump pictures/0002717.djvu 
  FORM:DJVU [195436] 
    INFO [10]         DjVu 2592x3872, v24, 100 dpi, gamma=2.2
    BG44 [44621]      IW4 data #1, 74 slices, v1.2 (color), 2592x3872
    BG44 [49804]      IW4 data #2, 15 slices
    BG44 [100964]     IW4 data #3, 10 slices

Shrnuto: Ten nový formát se příšerně dlouho konvertuje. Soubor je sice o čtvrtinu menší než DjVu, ovšem to je oproti původnímu téměř 4,5M velkému JPG zcela zanedbatelné. Navíc DjVu má přeci jen trochu jiný účel než je zrovna archivace obrázků. Navíc si výsledek z toho nového formátu stejně v ničem nezobrazíte, takže ho musíte zase zkonvertovat zpátky do bitmapové verze.

Jen pro zajímavost. Obrázek převedený zpět na jpeg měl zhruba půl mega, a degradace kvality byla větší než u DjVu.

Pokud jde o rozšíření DjVu. Není tak malé jak si myslíte. Pokud znáte web www.archive.org, tak na něm najdete téměř vše jak v PDF, tak v DjVu. Navíc.. ledy se hýbou

[Grunt]

Ten nový formát se příšerně dlouho konvertuje.

Zas tak strašné to není. A u nepohyblivých obrázků je to ještě tolerovatelné/zanedbatelné (např s otevřenými knihovnami implementujícími JPEG2000 je to ještě horší). Problém je především k kodeku, ne ve formátu. Libvpx je napsaný strašně. I když je v Céčku, tak je tam tolik zbytečných funkcí, že víc času snad provolá než se stráví v něčem užitečném. Skoro bych až řekl, že je to snad něčím konvertované z C++ nebo C# Nehledě na to, že i ta má nějaké parametry na nastavení kompromisů (nebo trade-offů? Fuj) a všechny jsou ve výchozím stavu nastavené na *_BEST_* a druhá polovina času co se nepromrhá na něčem zbytečném se promrhá na neefektivním a zbytečném deblockingu. Já bych to přirovnal spíš k referenčním implementacím z JPEGu/MPEGu (ty jsou na tom s rychlostí podobně, jen s tím rozdílem že aspoň dají číst) a považoval to zatím za takové technologické demo. IMHO se to časem zlepší. Např. Jason a vůbec celý tým x264/ffmpeg už jednou ukázal, že to možné je, jen je potřeba aby se to chytl někdo schopnější než banda hlav nagelovaných/přiškrcených z Googlu (teda v případě nějakého, nedejbože, masovějšího rozšíření).

[Grunt]

Libvpx

A samozřejmě všechny přilehlé knihovny a různé části a … No zkrátka a dobře všechen ten přiléhající bordel.

[Jiří Němec]

Našel někdo nějaké informace ohledně podpory HDR?

[Grunt]

Něco mi uniklo? VP8 používá něco jiného než DCT, frekvenční kvantizaci a zkomprimování entopie?

[Mandarinka]

Třeba inter a intra predikci :) U klíčových snímků jenom intra, samozřejmě...

[Grunt]

Už jsem si všiml. Mezi-makrobloková predikce (za což jednoznačné plus) a deblokovací filtr (za což bych je asi nakopl – pro spravedlivé porovnání ten krám budu muset vyřadit z činnosti) a Walsh-Hadamard (alias WHT, ale přínos nedovedu posoudit – asi to souvisí nějak s tou predikcí). A ještě trošičku jiné řazení DCT bloků než je u JPEGu zvykem. Jinak ale nic nového. Dokonce se mi zdá, že jsem tam někde po cestě zahlédl Huffmana.

[Grunt]

Příloha:

• Lenna_QP10.webp.png (197856 bytů)

No tak to deblokovaní, to je fakt kvítko teda.

[Mandarinka]

Ono ho má trošku silnější, afaik.

[Grunt]

Trošku silnější, jo? No to je teda síla. Bohudík, že na to mají flag a nemusím z toho kutat celé funkce.