Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
tady uz bylo tolik technologii co mely slusnou sanci na uspech ... a dneska po nich ani pes nestekne ...
a ta grcka jmenem GPL3 tomu urco pomuze k uspechu ... no aby nas ten JPEG nakonec vsechny neprezil :)
Mne by stačilo rozšíření animovaného Gifu na aspoň 1024 barev.
Zaplaťpámbu, že tomu tak není. Už teď je internet zaplaven animovanými gify olbřímích rozměrů, s 1k barvami by to bylo ještě drsnější, neb by to bylo datově větší a s ohledem na vyšší kvalitu asi i více používané. Ne, 256 barev musí v gifu stačit každému :).
Prosím ne, nechat GIF tiše zemřít by bylo lepší.
No na druhou stranu je to asi mene narocny na procesor jako stejne animovany flash.
Flash také nechat zemřít. :-D
Nemám rád samopohyblivé věci na stránkách... Ruší to od čtení.
Mam silnou neduveru v open source formaty, ktere nemaji nic co by je drzelo pohromade a zarucilo kompatibilitu (napr libre office urcuje kompatibilitu pro sve formaty). Ale u obrazku moc neverim ze se nebudou sirit vzajemne nekompatibilni verze, vzlast kdyz je vydan jeste nehotovy.
Zalezi jestli je dela nadsenec pro vedu a nebo jde o praci zastresenou treba Xiph.org. FLAC postupne ovladnul bezztratove audio mimo iTunes, OPUS se velmi dobre siri v oblasti VoIP a konferencnich systemu. Ani jeden rozhodne nema problem s nekompatibilitou. Dalsi ukazka muze byt 7zip, opet si kompatibilitu hlida a to jde v podstate o projekt jednoho cloveka.
FLIF podle me vypada dostatecne dobre na to, aby stal za zvazeni Googlu, Mozille a dalsim. I kdyby se ted rozhodli, ze pridaji podporu, tak bude trvat 5+ let, nez pujde pouzivat bez zalozniho png.
Otazka na redakciu: nechapem ako sa da porovnavat stratova a bezstratova kompresia.
Pri JPG som nikdy nikde nevidel "komprimuj bezstratovo" a aj maximalna ultra-brutal kvalita v nejakom programe produkujuca mega velke JPG subory je VZDY stratova kompresia.
Já snad někde v článku porovnávám FLIF a JPEG?
priamo s JPG nie, ale napr. s JPG2000
PNG (vylepseny GIF) je uz priamo lossless (asi ako pri zvuku FLAC)
odhliadnuc od masovosti JPG2000, lossless mód JPEG2000 nie je nieco, co by sa masovo pouzivalo
detto pri WebP a BPG - osobne som si dokonca doteraz myslel, ze JPG2000, WebP a BPG su len cisto stratove kompresie, moznost bezstratovej kompresie bola dokonca pridana aj do JPG
aspon ste ma donutili ist na wiki
JPEG technologicky umi bezeztratovou kompresi, vsechny pouzite transformace jsou reversibilni, staci vynechat "zaokrouhlovaci" krok. Ale nejsem si jisty, jestli nejaky program to skutecne uplne bez zaokrouhlovani zvladne.
Mám dojem, že klasický JPEG/JFIF je vždy ztrátový, standard jako takový sice lossless mód definovaný má, ale nikdy jsem ho neviděl implementovaný (a uvádí to i popisy). Existuje rozšíření standardu na JPEG-LS, který je navržen jako bezeztrátový a používá jiný typ transformace (je použit v DNG formátu RAWů).
Ake je praktické využitie tohto formátu pre BFU ako som ja ?
Fotím do RAW+JPEG len rodinne vylety a akcie, zatial som RAW využil asi 3x. Ale odkladam si ho pre istotu, Archivujem na 2x BR disk.
Pri audiu som "prezbrojil" na FLAC. Podporuje mi ho osobný prehrávač aj MMC v obývačke.
Zbierku DVD postupne prevádzam do H264/AAC, buď "získam" HD verziu, alebo si to prevediem sám.
Pre BFU to bude velka vyhoda az to implementuju do browserov, aplikacii a OS ako standardne kodeky.
Vyhoda je v tom, ze ked sa nacitava obrazok, tak na zobrazenie obrazku v "pozeratelnej kvalite" potrebujes len odhadom 1/3 prvych dat. Takze vo velmi kratkom case uz vidis, co je na na obrazku a v slusnej pozeratelnej kvalite. Cim dlhsie cakas na docitavanie dat, tym lepsiu kvalitu obrazku dostavas az nakoniec vidis "original".
Okrem toho, ak obrazok zobrazis na zariadeni s mensou obrazovkou (napr. smartfon), tak ti staci este vyrazne menej dat pri rovnako velkom povodnom obrazku. Podmienkou je zmensenie zobrazenej velkosti obrazku.
Mobilne aplikacie by potom mohli potencialne podporovat len nacitanie prvych X percent dat z celeho obrazku a az po jeho kliknuti sa bud len docitaju zvysne data alebo sa zobrazi v plnej velkosti a docitaju sa vsetky ostatne data.
Setri to prenesene data, cas uzivatela pri zbeznom pozerani, a ked si pocka na plne data, tak vidi obrazok v plnej kvalite (teda nie je nijako ukrateny).
skúsim si odpovedať sám:
Keby som niečo scanoval, tak by som ušetril miesto použitím FLIF-u miesto doterajšieho TIFF-u.
Ta otazka z nadpisu je trochu problematicka. Ono WebP ani BPG nemaju moc dovodov sa uchitit. Ostatne aj PNGcku to trvalo dost dlho nez vytlacil gif. V zasade, ak sa bavime hlavne o webe, sa bezstratove formaty pouzivaju akurat tak na mensie elementy (tlacitka, nadpisy) kde by stratovy jpg (alebo hocico ine) boli deformovane. A ci ma tlacitko 4kb alebo 6kb sa na vecsine webov neriesi. Aj tak dnes vecsinu trafiku robia ajaxove/jsonovske humusoviny tahane na pozadi. Bezstratove formaty su pouzivane skor na archivaciu alebo v specifickych pripadoch, kde ak je to treba uz nieco existuje (medicina napriklad) a tam sa mozno aj vyuzije ale zasa to nebude taky vyrazny tlak aby sa presadil aj na webe a medzi vecsinou.
Podla odkazu kde vysvetluje ako tento bezstratovy format funguje jasne naznacuje vyhodu tohto formatu. Ak mas totiz original obrazok 500 kB velky, tak:
- pre zobrazenie v plnom 1:1 rozliseni a v pozeratelnej kvalite ti staci prvych 180 kB dat (a vidis obrazok porovnatelne ako stratovy jpg 90%
- pre zobrazenie na zariadeni s stvrtinovym rozlisenim obrazka ti staci prvych 50 kB dat (a vidis to iste ako v bode vyssie)
Co znamena, ze mozes mat na serveri original obrazky no pritom ich nemusi browser stahovat uplne cele, pri dosiahnuti porovnatelnej obrazovej kvalite s JPG.
Aj ked na tej stranke mohli uviest aj pre porovnanie stratovy JPG.
Je otázka jestli se tohle částečné stahování dá implementovat efektivně. Předem nevíš, kolik místa v souboru zabírají jednotlivé úrovně detailů. Soubor s obrázkem by se musel stahovat nejméně na dva requesty (režie, zdržení). Nebo najednou, ale pak by se spojení muselo natvrdo utnout (další režie s jeho znovunavázním), protože http nepodporuje něco jako zastavení přenosu. HTML5 na to jde jinou cestou, že se předem vytvoří několik verzí v samostatných souborech, z nichž si browser vybere podle metadat v tagu.
Kedze to este nie je dokoncene, tak by to kludne mohlo fungovat ako html5. U flifu by som si vedel predstavit, ze doimplementuju "switch", ktory urobi nahlad podla zadanej hlbky stromu detailov, a teda vzdy dana uroven detailov bude nacitana cela.
Alebo vznikne tool, ktory vygeneruje podla nastavenej hlbky sample, ale to by sme sa uz asi vratili k situacii, co funguje doteraz - plno prace s robenim roznych velkosti obrazkov toho isteho povodneho obrazku.
Lenze na webe, pretoze budme realisti ten je zasadny na pretlacenie noveho formatu masovo, sa bezstratove formaty (png,gif) pouzivaju iba na male elemeny, nahlady a celkovo male obrazky (pokial sa fakt nejedna o nejaky specificky web kde treba velke snimky bez artefaktov). Inak vsetko ostatne "velke" bezi na jpgu. A zasa pre vecsinu webov je uplne jedno ci tlacitko, ikona a pod ma o 1kb viac alebo menej. Samozrejme pri weboch ako je Google, Amazon, Ebay a podobne s obrovskou nastevnostou aj to zavazi ale zasa browsery obrazky ukladaju do lokalnej cache. Na vsetkych ostatnych malych weboch je to proste nezaujimave. Ostane ako som pisal, aktualne asi aj tak viac trafficu robia jsony a ajaxove requesty (ktore sice mozu obsahovat aj obrazky) ako samotne obrazky.
Tak isto dnes vecsinu obrazoveho obsahu na internete generuje masa mobilnych zariadeni ktore fotia do jpegu. Takze to co je podporovane a funguje na Androide/IOS/WinM je to co asi udava smer. Proste to tak je.
Zrovna PNG je podle mě ukzákou toho, že záleží na tom jak se k tomu postaví majoritní prohlížeče. IE snad až do verze 6 nepodporoval alfakanál PNG souborů, což byl pro webdesignery celkem zásadní problém. IE5 a 6 jsou konečně v propadlišti dějin a tak konečně nic nebrání používání PNG.
FLIF je šířen pod licencí GPL3.
EH...
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.