Ve Firefoxu lze částečně nastavit chování u animovaných obrázků. Položka konfigurace: image.animation_mode. Paramtery jsou normal, none, a once. Ovšem ani jeden nesníží miniální delay animace na nulu. Klávesou ESC se pak animovace gifu dá zastavit v jejím průběhu - užitečné u psychadelických stránek.
No a co by jsi čekal od "takyprogramátorů", kteří se domnívají, že Xresources je datové úložiště, kam si ukládat několikamegová data, nebo že když chci spustit nějaký softlink, tak to chci spustit z cílem toho softlinku v argv[0]. Mozilla team je banda debilů, kreténů a naprostých omezených čůráků.
Výborně napsaný článek - velmi čtivý při zachování příjemné struktury. Mimo skvělého zpracování také množství přínosných a málo (alespoň mně) známých informací.
Osobně si myslím, že GIF je trochu passé, ale není mnoho obrázkových editorů(a ani prohlížečů), které umí mng.
Po pravde, ani s tou podporou animovanych gifu to v linuxu neni tak slavne. Nektere programy na to kaslou uplne, jine podporuji pouze nektere gify a u jinych se jim pokazi paleta ...
Nedodrzovani nulove prodlevy je ve skutecnosti vlastnost. Existuji stranky, ktere pouzivaji animovane gify s nulovou prodlevou, aby takove silene efekty jako plameny, vybuchy a podobne nesmysly vypadaly co "nejlepe". Prohlizec snazici se animovat takovy gif plnou rychlosti samozrejme pak vytizi CPU na 100% ...
Nezlobte se na me, ale neni to vlastnost - je to chyba nebo lez, kterou tvrdi vyrobce prohlizece svym uzivatelum/zakaznikum (a samozrejme zneuziti technologie temi, kdo ty vybuchy apod. vytvari). Pokud o sobe prohlizec tvrdi, ze podporuje zobrazovani GIFu, mel by je zobrazovat presne tak, jak to rika specifikace. Neni to nic tezkeho, naopak je tezsi detekovat nulove prodlevy a nahrazovat je nejakou "vhodnou" nenulovou hodnotou. Pokud neni v GIFu smycka, tak se zadne vytizeni na dlouhou dobu nekona.
Prekvapuje me, ze vyrobci prohlizecu stoji pred celkem jednoduchym ukolem - zobrazovat korektne GIFy, PNGcka a JPEGy. Znam dost prohlizecu, ale ani jeden to nezvlada dobre na 100%, asi nejhorsi je to kupodivu u JPEGu (problemy IE+PNG jsou zname).
Nevim jestli mate originalni text od CompuServe, ktery ma prvnich pet radku prazdnych a na sestem napsane:
Cover Sheet for the GIF89a Specification
(existuje vice verzi, nektere jsou predelane do HTML apod.)
Pokud ano, muzu napsat i cisla radku, kde se ty informace vyskytuji.
---
Nejprve je tam uveden dulezity pozadavek na dekoder:
The decoder has the following primary responsibilities.
- Process each graphic in the Data Stream in sequence, without
delays other than those specified in the control information.
...
A potom u popisu rozsirujiciho bloku:
v) User Input Flag - Indicates whether or not user input is
expected before continuing. If the flag is set, processing will
continue when user input is entered. The nature of the User input
is determined by the application (Carriage Return, Mouse Button
Click, etc.).
Values : 0 - User input is not expected.
1 - User input is expected.
When a Delay Time is used and the User Input Flag is set,
processing will continue when user input is received or when the
delay time expires, whichever occurs first.
vii) Delay Time - If not 0, this field specifies the number of
hundredths (1/100) of a second to wait before continuing with the
processing of the Data Stream. The clock starts ticking immediately
after the graphic is rendered. This field may be used in
conjunction with the User Input Flag field.
Ehm, _je_ to vlastnost. Jestli se to tam da umyslne, je to vlastnost.
> Pokud o sobe prohlizec tvrdi, ze podporuje zobrazovani GIFu, mel by je zobrazovat presne tak, jak to rika specifikace.
Jak pravil Goethe, sediva je teorie a vecne zeleny je strom zivota. Chtel bych videt jedinou realnou aplikaci, ktera to tak dela, u cehokoliv netrivialniho. Sice by to bylo hezke, ale zivot je zly, co se da delat.
> Neni to nic tezkeho
To je s prominutim tezka naivita.
> naopak je tezsi detekovat nulove prodlevy a nahrazovat je nejakou "vhodnou" nenulovou hodnotou
delay = max( delay, 10 );
> Pokud neni v GIFu smycka, tak se zadne vytizeni na dlouhou dobu nekona.
Ta smycka u tech problematickych gifu samozrejme je, o tom je ten problem.
Nemůžu si pomoct, ale trošku to s tím zeleným stromem života přeháníte :-) Když je to vlastnost, je někde popsaná? Pokud ne, tak já - vhledem k tomu, že se prohlížeč nechová tak, jak mu předepisuje specifikace - to považuji za chybu a ne za vlastnost. Zrovinka tím uvedeným kódem:
delay=max(delay, 10);
si do budoucna zaděláváte na spoustu problémů.
Prvním je, že až se uživatelé budou divit, proč některé animace vypadají jinak, než v dalších prohlížečích, asi tuto "vychytávku" budete muset v kódu znovu vyhledat, upravit a dát tam nějaké jiné magické číslo.
Zadruhé, ta destítka je odněkud zjištěná, nebo je to zrovna číslo, které se Vám líbí? Nepamatuji se, že by se podobná konstanta někde ve specifikaci či alespoň v diskusních skupinách o souborových formátech objevila. Trošku mi to připomíná chování velkých SW firem, které si také standardy ohýbají podle své "nálady" (aby to za několik let zase změnily).
Vím dobře o čem mluvím, protože podobné vychytávky se nám v minulosti vymstily - taky se trošku ohnul a "domyslel" standard a všichni byli (chvíli) spokojeni, ale jen do té doby, než uživatelé/zákazníci globálně přešli na vyšší verzi WWW prohlížeče a ty vychytávky se musely opravit (nemluvě o tom, že opravu většinou dělá někdo jiný než autor).
jj, tiez sa pripajam... :-) najma teda PNG, ale ostatne sa tiez velmi zidu... ;-)
PS: tak ma napadlo... najake podobne clanocky, ale o hudobnych formatoch... ak by to teda bolo mozne.. :-)
Tak jste me premluvili a clanky o grafickych formatech budou :-). Dekuji za zajem.
Hudebni formaty - to neni nic pro me, na neco slozitejsiho, nez je klasicky MOD (a jeho varianty), VOC ci WAV jsem rezignoval :-) Tu teorii ohledne MPEG Layer 3 jeste chapu, ale nic blizsiho.
Obecne ne, po implementaci na realny stroj (tj. s omezenou presnosti) uz IMHO ano. A co se tyce te trochy, tak uz mizive stopy psychoakustickeho modelu zajistuji stlacovani, ale cim vic, tim lip to pak zni.
To jsou pouze ilustracni obrazky, jak by se mohl GIF pomoci ramcu upravit v pripade pouziti optimalizacniho programu. Nakonec jsem (kvuli sedemu pozadi a oramovani) oba obrazky vytvoril v jednom ramci, proste tak, jak to vyexportoval graficky editor. (stejne tak i prvni obrazek je "jednoramcovy", pouze s nakreslenymi obdelnicky).
Po sakra dlhej dobe som cital vynikajuci clanok! Fakt pochvala autorovi!
Kedysi este v casoch dosu som sa pohraval s programovanim grafiky a jednym z mojich - ale marnych, resp, asi na 50% uspesnych pokusov bolo citanie a ukladanie formatu gif... (bol som 3. na strednej) Tento clanok mi ozivil vela spomienok a objasnil odvtedy dost nejasnych informacii! Dufam ze po ukonceni clankov formatu gif sa autor bude venovat aj inym formatom! fakt PNG by sa bodlo. Este raz vdaka!
Tak tomuhle říkám opravdu skvěle zpracovené téma:) a hlavně přehledně.
BTW: JPG screeny jsem někde viděl, ale nevzpomenu si, kdo to dělal:) Screeny jedině GIF (když někde publikovat). Jinak si na kompu všechno ukládám do truecolor bitmapy a až pak následně ukládám do formátu se ztrátou informací o barvách...
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
Jj, JPEG bol navrhnuty na fotky, ktore nemaju "ostre hrany", tj. vysoke frekvencie. Tiez nemam rad screenshoty v jpg, sice ked je rozlisenie dost velke, tak to az tak nevadi, lenze ten format na to nebol urceny.
V době plynulých přechodů a prostorových efektu v dekoracích oken a s nedejbože JPEG obrázkem na ploše je uložení screenshotu v 256 barevném GIFu _mnohem_ hnusnější než JPEG s pár artefakty. Screenshoty tedy spíš v PNG, když už...
Pokud jsem si všiml, byla tu řeč o screenshotech ve smyslu aplikačních oken či grafů ze spreadsheetu s 16 barvami, pokud se někdo předvádí plochou desktopu s polonahou babou na pozadí a milionama barev všude možně, samozřejmě je na to lepší JPEG.
Připojuji se k pochvale, pěkný článek. Ale chybí mi tu jedna podstatná informace. Jak v gimpu (nebo něčem jiném) vytvořit vícerámcový gif, třeba právě pro ten dokument v TeXu.
GIMP to - alespon co jsem zkousel - neumi, stejne jako vetsina dalsich komercnich i OS nastroju :-) Existuje nekolik optimalizacnich programu pro GIFy, ktere nabizi vic metod zmensovani vyslednych obrazku a mezi nimi je i hledani vhodnych ramcu. Tyto programy jsou vsak (ty ktere znam) pouze pro Windows.
Ja osobne pouzivam Gif89Encoder, coz je knihovna pro Javu :-(, ktera s ramci pracovat dokaze, ale ja generuji obrazky programove (nacitanim souradnic objektu z databaze), takze si ramce vytvarim sam a nemusi se pouzivat zadna heuristika.
Jeste me napadlo, ze GIMP by to nakonec i mohl umet, a to pomoci animaci - kazdy ramec by byl tvoren polickem animace, ale jeho velikost a umisteni by byla mensi, nez cely logicky obrazek (podobne jako na prikladech). Po sestaveni animace (je tam na to nejaky skript) by se nastavilo nulove delay a bylo vymalovano. Ale ted to nemuzu vyzkouset, na jediny Linux v okoli se pripojuju pomoci Putty, takze zadna grafika :-)
Proč se ty ukázky TrueColor GIFů zobrazují postupně? Je to ta chyba s nedodržením 0-vé prodlevy mezi rámci (prohlížeč SeaMonkey 1.0.4) nebo je to schválně?
(Mimochodem, v SeaMonkey je animovaná i ikona v záhlaví Tabu.)
Pokud to takto funguje i u posledniho obrazku, je to chyba v SeaMonkey (nebo nejake knihovny pod ni). Delaye jsou nastaveny na nulu, resp. by se vubec nemely brat v uvahu - na to existuje v rozsirujicim grafickem bloku jeden wordik :-). Bezi ta animace porad dokola, nebo se pomalu zobrazi pouze jednou?
btw: kdyz si stahnete posledni obrazek (ten je nejsrozumitelnejsi), muzete v nem narazit na mnoho (pres 150) sekvenci bytu:
21 F9 04 04 00 00
Kazdou touto sekvenci zacina novy rozsirujici graficky blok, tj. obrazek obsahuje pres 150 ramcu. Vyznam one sekvence bytu:
21 - znacka zacatku bloku
F9 - jmenovka, vzdy nastaveno na F9
04 - delka bloku, vzdy nastaveno na 04
04 - bitove pole (tady zvolena jedna metoda prekresleni pozadi)
00 00 - ono zminovane Delay Time v setinach sekundy
... dal nas to nemusi (prozatim) zajimat
Ty predchozi "animovane" obrazky vubec rozsirujici graficky blok pred ramci nemaji, ale muzete tam najit zacatky ramcu, treba:
2C 00 00 FE 00:
2C - zacatek ramce
00 00 - x-ova souradnice leveho okraje
FE 00 - y-ova souradnice horniho okraje (ta na obrazcich postupne klesa z FF na 00).
To jsem rad, ze to opravili, Irfan je jinak dost dobry. Zkousel jsem to ve verzi 3.36 (to je verze, kde si staci prenaset jeden spustitelny soubor bez dalsich knihoven), tam to opravdu animuje. Uvidime, jak se Irfan popere s obrazky uvedenymi v dalsi casti tohoto serialu, ta verze 3.36 s nemi take mela problemy.
Ifran 3.97 (+ balik pluginu) a posledni gif animuje (dokonce ve smycce), ostatni jsem nezkousel.
Je to nejake divne.
Zkousel jsem i XNView 1.82.4 (posledni verze), ale tan to ani neumi poradne zobrazit (a animuje taky). Chova se to, jako by mel pro vsechny gif (pro cely obrazek) jen globalni paletu a tu pri nacitani jednotlivych ramcu prepisoval lokalni paletou. Blbe se to popisuje, je to ale zajimavy efekt.
Neco ano, ale TIFF je pekne slozity format. Neznam program, ktery by dokazal korektne nacist vsechny druhy TIFFu a naopak pravdepodobne neexistuje program, ktery by je dokazal korektne generovat. Nicmene zaklad TIFFu a kodovani (LZW, JPEG a CCITT) bych popsat mohl.
Jde mi jen o konstrukci.. tifu.. vim ze je velice slozity a proto neni moc obvykly.. (a pdf k nemu ma 120 stran :)
Pokud by jste byl ochoten neco sepsat, byl bych v8m velice vdecny... dekuji
Ještě mě napadla jedna možnost jak úkládat víc barviček do rámců - totiž s pomocí průhledných pixelů. První rámac nacucne 255 nejpoužívanějších barev a za ostatní vloží průhledný bod. Další rámec vezme dalších nejpoužívanějších 255 barev a tak dál... Jestli by došlo k ušetření místa, nevím. Jen mě to tak napadlo.
To záleží na tom, jak by konkrétně vypadat ukládaný obrázek = v reálných obrázcích by to mělo smysl. Ty testovací příklady (kromě posledního) jsou udělané tak, aby se v každém řádku obrázku zobrazilo 256 barev, tj. nemá smysl rámce vytvářet větší než 256x1 pixel. Samozřejmě je možné mít všechny rámce o rozměrech 256x256 pixelů a v každém vybarvit pouze 255 (zbylý index je na průhlednost), ale - alespoň v těchto testovacích příkladech - by se velikost zvětšila a tu sekvenci 255x256=65280 bytů (ty by se samozřejmě zkomprimovaly, ale ne na nulovou délku).
GIFy s více než 256 barvami má smysl používat tak do 4000 barev, tj. počet průchodů (zpoždění v nekorektních prohlížečích) je ještě malé. Pro mnoho aplikací do dostačuje.
no asi zalezi co na tom screenshotu je a v jake je kvalite. pokud chci vystavit screen sve pracovni plochy v plnem rozliseni 1280x1024, a na obrazku mi jde primarne o verne zobrazeni true color pozadi plochy, tak bych asi delal screenshot v JPEGu, nicmene obyc. screenshoty kde nejsou "plnobarevne obrazky", ale jen nejake menu, trocha textu, male ikonky, tak bude asi lepsi GIF.
Přesně tak. Nejlepší jsou obrázky grafu z Excelu, kde je celkem 16 barev, uložené v JPEGu, kvůli čemuž jsou pak titěrné popisky skoro nečitelné, jelikož zrovna černý text na světelém podkladu je to, co JPEG zprací dokonale.
Celkem dobre napsany clanek. Dekuji.
Vidim tu nejaky rozpor:
1. veta clanku "Pripad GIF" z 10.8. rika "Dne 11.8.2006 vyprší platnost posledního patentu".
2. veta 1. kapitoly tohoto clanku z 17.8. rika "ohledně dvou současně platných patentů".
Tak jak je to tedy?
Dale pisete, ze v pripade, ze neni pritomna ani Global ani Local Color table, mel by prohlizec dodat systemovou paletu
nebo web-safe 216 barev+odstiny sedi. Jiz zde jednou citovana
originalni specifikace od Compuserve (napr. http://www.wotsit.org/download.asp?f=gif89a) rika toto:
"if there is no Global Color Table in the Data
Stream, the active color table is a color table saved from a previous Data
Stream, or one supplied by the decoder." To znamena, ze se
ma pouzit paleta z predchoziho souboru GIFu (!!!) nebo defaultni, jakou autor prohlizece prohlasil
za vhodnou.
A ted k te prodleve. Jsem autorem PictView, nejprve DOSovskeho prohlizece, pak i okenniho
prohlizece a konvertoru a v posledni dobe hlavne pluginu
do file manageru Servant Salamander (http://www.altap.cz).
V minulosti jsme skutecne nulovou prodlevu interpretovali
jako nulovou. Pak nas ale uzivatele zacali bombardovat
soubory s tim, ze v jejich oblibenem web browseru
neni ta prodleva nulova, ale "nejaka prijatelne defaultni".
Tim nas donutili zavest vlastni defaultni prodlevu.
Nevim, zda autor clanku programuje, ale ve specifikacich
lecceho je zcela bezne, ze nulova hodnota nejakeho parametru
znamena default, takze to neni az tak prekvapujici:
Opet cituji specifikaci: "Delay Time - If not 0, this field specifies the number of
hundredths (1/100) of a second to wait before continuing with the
processing of the Data Stream".
Zatim jsem se nesetkal s tim, ze by nekdo pouzival vice
ramcu pro 1 snimek kvuli optimalizaci velikosti souboru.
Naopak kvuli sbirce souboru pocitajicich s defaultni prodlevou,
kdyz je zadana nula, neplanujeme prechod na puvodni chovani.
Takže jestli to chápu správně, potom gif nikde neukládá informaci o tom, že jde o animace, uživatelem řízené slideschow nebo jeden obrázek složený z rámců. Tak to potom záleží na uživateli, jak se na gif bude chtít dívat. Dal bych mu k dispozici kontextové menu, aby si vybral. I když už je to všechno asi trochu zbytečné.
ten rozpor možná vznikl na základě mnou nepříliš jasně napsané věty. Nepíšu tam o dvou _v_současnosti_platných patentů, ale o dvou patentech na stejnou věc, které _byly_ platné současně - ve stejný čas (a vypršely před dvěma lety, letos šlo o třetí patent, který vlastnila firma IBM).
PictView mi jménem něco připomíná, nebyla to (v době DOSu) aplikace běžící v textovém režimu s tmavomodrým pozadím?
Právě že dost programuji a tak jsem zvyklý na různé nejasnosti vyskytující se ve specifikacích (hlavně se to týká chování různých API funkcí v okrajových podmínkách). Ale ve specifikaci ke GIFu se jasně píše, že prohlížeč má obrázky zobrazovat bez zbytečných delayů (už jsem text pastnul do předchozích odpovědí):
The decoder has the following primary responsibilities.
- Process each graphic in the Data Stream in sequence, without
delays other than those specified in the control information.
Pokud to uživatelé opravdu vyžadují, pak samozřejmě záleží na vás, jak budete danou věc implementovat - buď se držet specifikace, nebo se "podřídit" :-). Pokud se však podřídí všichni, tak se nemůžeme divit, že se vícerámcové GIFy moc nepoužívají, což je škoda.
Tak jsem nakonec ten PictView našel na svém druhém cédéčku (společně s Vimem čtyřkou - to byla doba). Je to verze 1.67 DM (to jako kvůli Dementovi?) a kupodivu mi šla i na moderním stroji spustit :-)
Ještě k těm defaultním hodnotám: první tři "truecolor" GIFy uvedené v článku nemají ani rozšiřující grafický blok, takže žádné delay by se konat nemělo. Ale chápu, že uživatelé zvyklí na nějaké chování animací v IE/Netscape/Firefox a spol. vás donutí k vytvoření stejně funkčního programu. Jaké je tedy "defaultní delay" - 10ms?
Ano, verze DM byla kvuli Dementove Parenisti a jeho formatu X.
Aktualni verze pro DOS, lec nekolik let neaktualizovana, je vicemene 1.95, ma mj. nekolik vylepseni kvuli modernim strojum ;-)
Koukam, ze s tou defaultni prodlevou jsem mystifikoval sam sebe.
Hodnekrat jsme to pretrasali, ale nakonec to zustalo s tak
malou prodlevou, jak jen to HW a OS dovoli.
Koukam, ze tam mam jeden (opravdicky) bugik: dalsi frame hledam podle GCE, ale v tech vasich souborech se vesmes nevyskytuje :-(
Chci se jeste zeptat na ten autoloop - kde a jak je to dokumentovano? Nemohu to najit...
Pravda, v prvnich ctyrech obrazcich se GCE nevyskytuje, ve skutecnosti by se mohlo jednat i o GIFy87a (ale ted me napada, ze by to mozna nektere prohlizece asi rozhodilo vic, nez ten nulovy delay :-). Ten posledni obrazek s ramci o ctvercovem tvaru uz GCE ma.
S autoloopem muze byt trosku problem, protoze se nejedna o vec, ktera by byla zminovana primo ve specifikaci GIFu (ani 87a ani 89a). Ale uz nekolik let - tusim od roku 1995 +-2 roky - je snad vsemi web prohlizeci a mnohymi "off-line" prohlizeci podporovano aplikacni rozsireni puvodne pochazejici od Netscape. To ma hlavicku "NETSCAPE", oznaceni aplikace "2.0" a vlastne jen jeden menitelny udaj - pocet opakovani smycky 1-(2^16-1). Pokud je tam 0, jde o nekonecnou animaci.
Prakticky to vypada tak, ze se v GIFu za globalni barvovou paletou nachazi tato sekvence bytu:
33 ff 0b 4e 45 54 53 43 41 50 45 32 2e 30 03 01 LO HI 00
V LO a HI max. hodnota pocitadla smycky, takze vetsinou 00 00 (oblibena nekonecna smycka). Na netu jsem vsak nasel nekolik malo GIFu, ktere maji treba pouze tri opakovani - to se mi docela libi, sice je na strance neco pohybliveho, co zaujme pozornost, ale po chvilce to prestane otravovat, takze obe strany mohou byt spokojeny a uzivatel se nebude namahat s blokovanim reklam apod.
Tedy nevim, jak je to s tim Konquerorem, ale pri pokusu zobrazit GIF s vice jak 256 barev (trik s lokalnimi paletami), totalne zklamal...
Autor se asi myli, kdyz tvrdi, ze to Konqueror zobrazi korektne.
Mě Konqueror zobrazil všechny obrázky (jenom poslední šachovnicový se jednou animoval) v pořádku. Mám KDE 3.5.4 v Kubuntu Dapper, ale protože Pavel má Sarge, tak pochybuji, že by se jednalo o nějakou novou featurku.
Mám tam KDE 3.3.2 a GIFy se zobrazují takto: náhled (ikona) je špatně, tj. pouze jeden rámec a po doubleclicku se již obrázek zobrazí správně bez delayů. Nevím, jak vyšší verze, ale ona 3.3.2 si s těmi "truecolor" GIFy tedy poradí.
Popsal jsem jen to, co jsem videl :-))) Mam ted nove nainstalovany Sarge bez jakychkoli updatu a Konqueror s temi GIFy opravdu nema problemy - ale dalsi aplikace pro KDE kupodivu ano. Michal Vyskocil se nad tim podivoval (rikal neco na zpusob, ze ty programy pouzivaji stejnou knihovnu ci API), ale ja KDE do strev nevidim.