Názory k článku
BPG: nový obrázkový formát, který chce nahradit JPG
-
Ondra Satai NekolaZlatý podporovatelNějak se v tom neorientuju, tohle je akce Mozilly? Já to pochopil tak, že jenom dělali srovnání. Ale do hloubky jsem nešel...
-
Anonymus Bimbas (neregistrovaný)
Ta zmínka o Mozille asi vznikla z toho, že web BPG odkazuje na starší studii Mozilly, v níž intra komprese HEVC zvítězila nad konkurencí. Žádná přímá spojitost jinak není.
Podle Bellarda je jinak BPG ještě lepší než HEVC, protože má o něco menší hlavičku = komprese BPG bude o něco málo lepší než to, co bylo tehdy v té studii.
-
Petr (neregistrovaný)
Detail ne. Třeba já na eshopu řeším obrázky pro mobilní verzi, kde potřebuji docela velké rozlišení (paradoxně často větší, než na PC) kvůli displayům s velkým ppi, žádný bordel okolo kromě pár kilo js se netahá a rád bych i při pěkných obrázcích zajistil rychlé načítání nejen na LTE a nechci štvát lidi velkým žraním jejich FUP. Bohužel než bude za 10 let rozšířená podpora toho formátu, tak bude LTE to nejpomalejší na trhu a FUPy budou asi taky jinde, takže pak si řekneme to "chtělo to tak před deseti lety" :)
-
Ondra Satai NekolaZlatý podporovatel
Zkusil bych, jak si ten js dekodér poradí s těmi obrázky třebas v mobilním Safari. Dekodér by mělo jít cacheovat...
-
Petr (neregistrovaný)
To jsme si možná nerozuměli, žádný js dekodér nemám, myslel jsem to tak, že se na těch stránkách tahá jen html, css a trocha js, žádný flash, videa a miliony reklam, tj. stále ty obrázky jsou to nejobjemnější a vyplatilo by se je mít menší při zachování kvality. Samozřejmě jen za předpokladu široké podpory toho formátu v prohlížečích. Nejsem Google aby se mi vyplatilo testovat každý prohlížeč a podle toho posílat obsah, který tu budu mít připravený v X formátech, bez podpory tam prostě pošlu jpeg a lidi mají smůlu.
-
strepty (neregistrovaný)
Existuje zakon zachovania informacie. Je podobny zakonu zachovania energie. Volne interpretovany znie informaciu na informacii neusetris. Cize 100KB bude niest 15 krat menej informacie ako 1.5MB (ostrost farba...) co v buducnosti pri 5k monitoroch moze viest k tomu ze si budete buchat hlavou o stenu.
-
Pavel TišnovskýZlatý podporovatelOtázka tedy zní, kolik je v té fotce skutečné informace :-)
Uvedu příklad ze života (trošku násilně ohnutý) - máme dva CCD snímaže se stejnou plohou, jeden má 1mpx, druhý 10mpx. Uděláme stejný snímek na 1/50 sekundy. Tím na oba snímače dopadne stejné množství fotonů a - teď to zjednodušme - se získá stejné množství informace. Jenže to jakoby vypadá , že 10mpx čip získal 10x informace, což není pravda, protože bude jen víc zašumělý (v každém pixelu se již projeví jednotlivé fotony + další jevy) a s menší dynamikou (což jen zvýrazní problémy v postprocesoru).
Další extrémnější příklad - bitmapa 2048x2048 pixelů, která obsahuje bílé pozadí a uprostřed červené kolečko. Informace je tam pramaličko, v SVG by to zabralo řekněme 100 znaků, ve vektorovém formátu 20 bajtů.
-
strepty (neregistrovaný)
Cervene koliecko je pekny priklad na pokusy, vyrobil som jedno na poloche 1920x1200 hrube 10px. Pri pokuse ulozit ale program ukazal inteligenciu a vyrobil JPG 1428x1428 velky 672kB. Ulozil som to aj ako BMP a dostal som 2.99MB subor, zaujimave je ze ked som BMP zbalil do zip ziskal som 15kB subor. Co by som povedal ze je informacia toho obrazka. Ale po zbaleni jpg ma zip subor az 427kB. Urobit BPG subor sa mi nepodarilo ani na XP ani na Win 7 asi mi nie je sudene spoznat ten format.
-
Filip JirsákStříbrný podporovatelA co tohle?
<?xml version="1.0" standalone="no"?> <svg width="1920" height="1200" viewBox="0 0 1920 1200" xmlns="http://www.w3.org/2000/svg" version="1.1"> <rect x="0" y="0" width="1920" height="1200" fill="white" /> <circle cx="960" cy="600" r="10" fill="red" /> </svg>Má to 272 bajtů. A je to opravdu červené kolečko uprostřed bílé plochy. Když se podíváte na to vaše, zjistíte, že má ve skutečnosti zubaté okraje, takže se ta vaše informace o kolečku někam ztratila.
-
hmmm (neregistrovaný)
Je obtizne doplnovat jeste neco do diskuze s p. Tisnovskym, ale zkusim to. :)
Odborne se tomu rika "entropie" a kdysi davno jsem cetl clanek, kde se pokouseli tuto hodnotu pro nejakou mnozinu dat spocitat a mimodek dosli k tomu, ze hodnota entropie se prave dost podoba velikosti vystupu z kompresnich algoritmu (bezeztratovych, ostatne tenkrat snad jpeg jeste ani nebyl tak znamy).
O to ze to ze Filip Jirsak dokaze nacpat do 200 bajtu SVG je super, ale trochu mimo tema. Nevim, jak efektivne by v SVG popsal tu holku ve spodnim pradle v reklame vpravo. (Nebo Lenu pro ty, co maji vypnutou reklamu, ale za to cetli skvely serial prave p. Tisnovskeho. Ostatne zrovna pri cteni teto zpravicky me napadlo, ze by si p. Tisnovsky mohl udelat prestavku v psani encyklopedie pocitacovych her a popsat pro nas hloupejsi a linejsi tyto dva nove formaty, tj. BPG a WebP. I kdyz mozna by bylo lepsi pockat, jak tyto formaty prorazi do sveta, viz napr. JPEG200, pouziva to nekdo?)
-
Filip JirsákStříbrný podporovatel
SVG by byl při ukládání bitmapového obrázku asi tak stejně efektivní, jako JPG při ukládání hudby.
Podstatné je totiž to, že se při ukládání informací do souborů vždy ukládá jen to, co je pro nás v tu chvíli podstatné, a drtivá většina informací se ztrácí. Pokud mám namalovat červené kolečko na bílém pozadí, je vektorový formát nejúspornější (i ukecané SVG vyhrálo na celé čáře). Pokud to samé uložím do bitmapy, ta informace o červeném kolečku se ztratí, je to jen shluk teček, který lidskému mozku ze všeho nejvíc připomíná červené kolečko, tak to nazývá červeným kolečkem. Všimněte si, že se informace ztratila, ale objem uložených dat vzrostl - protože je tam uložena spousta nezajímavých informací.
Dál můžeme pokračovat bezeztrátovou kompresí, která tu původní bitmapu dokáže zmenšit, i když zachová všechny informace. Část informací je totiž uložena přímo v (de)kompresním algoritmu, který funguje tak, že ty informace, které se vyskytují často, dokáže uložit v menším objemu dat - a ty méně časté naopak ve větším. Takže třeba u obrázků víte, že sousední body bývají velmi často podobné nebo dokonce stejné, takže místo ukládání plné barvy pro každý bod můžete ukládat jen kratší informaci o rozdílu barev, případně kolik sousedních bodů má stejnou barvu. Kdybyste si vygeneroval všechny možné obrázky a zkomprimoval je, bude výsledek větší, než jejich nezkomprimovaná varianta. Ale my většinou zacházíme jenom s těmi obrázky, pro které je komprimační algoritmus optimalizován, takže objem dat ušetříme.
Další v pořadí je ztrátová komprese. Ty pracuje s tím, že v té bitmapě je spousta informací, které jsou pro člověka zbytečné. Například proto, že si je lidský mozek snadno dokáže domyslet, jak jsem psal výše.
Takže Strepty měl ve velmi obecné rovině pravdu, ale zapomněl na to, že se někdy s informacemi ukládá i balast, který je možné odstranit; že je možné kompresní algoritmus optimalizovat tak, aby úsporněji ukládal ty obrázky, které reálně používáme, a málo úsporné uložení si ponechal pro ty, které se reálně nevyskytují; a že některé informace je možné vypustit, protože je člověk nedokáže rozlišit nebo jejich vypuštění neovlivní to, jak obrázek vnímá. Všechny tři jsou to variace téhož, pracuje se s tím, že různé informace jsou různě důležité.
Pokud se tedy někomu podaří vytvořit takový formát, který některou z těch tří věcí zvládá lépe, uloží stejný obrázek do menšího souboru, ale pro pozorovatele tam k žádné ztrátě informací nedojde. -
Pavel TišnovskýZlatý podporovatel
Zdravím :-) Pomalu se skutečně chystám něco napsat o novějších formátech. Kromě těch zmíněných (WEBP má asi největší šanci na prosazení, ale uvidíme), které jsou vhodné pro fotografie a obecně barevnou grafiku, by se možná hodilo i popsat formáty pro monochromatické skeny textů (JBIG, JBIG2, JB2). Možná i zmínka o knihovně Fiasco, no uvidíme :-)
A ještě jsem před lety slíbil i popis DjVu, uff to bude práce :-)
-
-
Karel (neregistrovaný)
Ano, ten zákon existuje. Ale asi ho neznáte. Viz příklad:
"22 / 7" (dvacet dva sedmin)
"3.1428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571428571"
Zabrané místo nesrovnatelné, ale přitom ten kratší zápis je přesný kdežto delší zápis musí být zaokrouhlený.
Jiný příklad je obrázek v rozlišení 8000 x 16000 pixelů, kdy jeho pravá část je bílá a levá část černá. Dokonale jsem vám ho tady v pár znacích specifikoval i přesto, že jako bitmapa by vám to zabralo možná i čtvrt GB na disku.
Takže se zákonem opatrně. On vám totiž říká, že informace sama od sebe nevznikne. Vezměte nějakou informaci a nafukujte ji klidně donekonečna, stejně jí nepřibude. Zde se pak aplikuje postup opačný - informace se upouští bez toho, aby se vlastně ztrácela. Pokud jde balon nafouknout, tak ho lze i vyfouknout.
U fotek pak bývá úsměvné, když se i laické veřejnosti vnucují postupy, které dokonale uchovávají původní kvalitu, místo aby se použily metody, které působí chyby v podání barev, které jsou ale hluboce pod schopností snímačů ve fotoaparátu. On i .jpg je i při své ztrátovosti natolik přesný, že zkušený pracovník fotolabu pozná, jakým fotoaparátem a s jakým problém byla fotka dělána. Rozpoznají optický a digitální zoom, i u optického poznají podle nesouladu barev jak velký byl, zda s objektivem nebo bez, jak velký byl chip, zda kompakt, "skoro zrcadlovka" nebo zrcadlovka atd. Zkrátka současná technika vám do fotek zanáší takové chyby, že ztrátová komprese už vlastně nemá jakou informaci zničit. Prostě je tam šum, ne informace.
-
Pavel TišnovskýZlatý podporovatel
Tretina pixelu znamena pri stejne plose cipu o dost mensi sum oproti cipu, ktery se honosi silene vysokou hodnotou mpx :)
-
To je ale celkem jedno. Z kompaktu to, diky kvalite optiky, stejne lze tisknout tak leda na mensi formaty, megapixely sem, megapixely tam. Takze pri tisku se to zprumeruje do nejakeho bodu velikosti, kterou zvlada tiskarna a pak se to jeste zprumeruje v oku divaka. Takze ty megapixely akorat cloveka stoji ulozne misto. Jedina vyhoda tech novejsich cipu je lepsi citlivost v podminkach nizkeho osvetleni, kde starsi fotak zaznamena tmu, novejsi pak spoustu svetelek a odrazu.
-
j (neregistrovaný)
Prave ze to jedno neni.
Zrcadlovka s prumernym objektivem muze davat v provedeni nejakych 8Mpx daleko lepsi vysledky, nez za stejnych podminek telo s 30Mpx. Proc? Protoze uplne jednoduse na kazdy px dopadne nejake, objektivem dane, mnoztvi svetla. Cim vice px, tim mene svetla, a tim horsi vysledek.
V pripade vsemoznych obrazkodelacu, kde zadny objektiv neni, je to pochopitelne jeste radove horsi, protoze svetla je radove min.
Pokud by se to dotahlo ad absurdum, slo by rekneme odelat chip s par Gpx, ktery by ale nevyfotil vubec nic, protoze mnoztvi svetla ktere by dopadlo na snimac by bylo tak male, ze by snimac nic nezaznamenal.
-
NA (neregistrovaný)
Může, ale většinou nedává. Ono záleží zda to množství světla není víc než dostatečné, velikosti čipu a třeba jak velkou chci hloubku ostrosti.
Vyjádřeno stejně absurdně, může být málo pixelů beznadějně přesvětleno a mnoho vykreslit krásný obraz. Nebo pár pixelů roztažených na obrovitém čipu dá rozmazaný flek, ale desetinásobek na desetinovém ostrý obraz.
Digitální fotografování pracuje s velkým počtem proměnných a není možné to takhle zjednodušit. -
Pavel TišnovskýZlatý podporovatel
Však se bavíme o porovnání čipů se stejnou plochou a různým počtem pixelů. Navíc - přesvětlení se snáze vyřeší právě u menšího počtu pixelů, neboť takový čip bude mít větší buňky s mnohem větší dynamikou (počet dopadajících fotonů v ideálním případě bude odpovídat počtu excitovaných elektronů).
S větším počtem pixelů dosáhneš tohoto:
1) budou menší buňky, tudíž se zhorší šumové vlastnosti
2) zhorší se dynamika, což na jedné straně souvisí se šumem, na straně druhé s maximálním množstvím elektronů, které lze exitovat
3) málo světla (focení v noci) - mizerný poměr signál/šum
4) moc světla - vetší pravděpodobnost, že spousta buněk excituje všechny elektrony - přepálení pixelu/ů
5) *ale* zvětší se magické čísílko před Mpx udávané v cenících a katalozích :-)Řešení jak dosáhnout vyššího rozlišení a zachovat dynamiku a snížit šum je několik:
1) větší čipy
2) chlazení, ale to si může dovolit třeba nějaký vědecký tým, ale ne někdo s normální zrcadlovkou -
OMG (neregistrovaný)
tak schvalne - kolik tech fotek mate? pres milion aby vam to zaplnilo bezny levny 2terovy disk? Jestli ma foto 1,5mb nebo ~100kb na disku opravdu neresim. Kvuli uspore mistem nebudu mesic konvertovat fotky do nejakyho zatim nestandardniho formatu... Pouziti pro web? V budoucnu mozna. Pouziti doma? V budoucnu mozna.
-
Bravo, Fabrice! Tohle by mohlo způsobit revoluci. Kvalita, efektivita, univerzálnost, bitová hloubka, HW akcelerace zadarmo, ... zní to jako sen!
Při každé diskusi nad novým a úžasným formátem jsem se ptal "a co JPEG2000"? Jenže BPG je zde jasně lepší.
Pevně doufám v rozšíření. Jen ten název mohl být více cool... :-)
-
http://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
Zakomponovani h265 HEVC do novych procesoru je jen otazka casu.
SW podpora je vec jina...
-
snehuliak (neregistrovaný)
Tak som si teda na tu "srovnavaci" linku klikol a dobru chvilu som porovnaval...
Pri porovnani "small" bpg vs jpg jednoznacne vyhrava bpg, ale ked som si porovnal "large" format, tak uz to take jednoznacne nebolo. Subjektivne sa mi bpg a jpg obrazky zdali rovnake a rozdiel jasny rozdiel v prospech bpg som videl az ked som si dal 3x zvacsenie (pull down menu pod obrazkom).
Moj zaver - ak mi raz da moj automaticky fotak moznost ukladat fotky v bpg tak to urcite vyuzijem, dovtedy budem nadalej pouzivat jpg (moj fotak nepodporuje bmp ani raw - a ani ich pre moju potrebu nepotrebujem).
