a archivační programy

Transkript

D a v i d
M o r k e s
a archivační
programy
Jak funguje komprese
binárních, textových
a grafických dat.
Uživatelský popis
programů:
●
WinRAR
●
WinZIP
●
ARJ
●
JAR
●
ACE
Komprimační a archivační programy
David Morkes
© Computer Press®
Brno
1998
D a v i d
M o r k e s
Komprimační
a archivační
programy
Jak funguje komprese
binárních, textových
a grafických dat.
Uživatelský popis
programů:
●
WinRAR
●
WinZIP
●
ARJ
●
JAR
●
ACE
Komprimační a archivační programy
David Morkes
Copyright © 1998 Computer Press®. Vydání první. Všechna práva vyhrazena.
Vydavatelství a nakladatelství Computer Press®,
Hornocholupická 22, 143 00 Praha 4, http://www.cpress.cz
ISBN 80-7226-089-8
Prodejní kód: K0198
Jazyková korektura: Martina Mojzesová, Josef Novák
Sazba: Wlashack
Vnitřní úprava: Wlashack
Obálka: Lubomír Mojzes
Komentář na zadní straně obálky: Jiří Hlavenka ([email protected])
Vedoucí knižní a technické redakce: Ivo Magera ([email protected])
Vedoucí knižní produkce: Kateřina Vobecká ([email protected])
Tisk: MIKADA Adamov
Žádná část této publikace nesmí být publikována a šířena žádným způsobem a v žádné podobě
bez výslovného svolení vydavatele.
http://vltava.cpress.cz
Kompletní nabídka počítačové
literatury za bezkonkurenční ceny
Vaše dotazy, vzkazy, náměty,
připomínky ke knižní produkci
Computer Press přijímá 24 hodin denně
naše horká linka: [email protected]
Veškeré dotazy týkající se distribuce směřujte na:
Computer Press Brno, nám. 28. dubna 48, 635 00 Brno – Bystrc,
tel.: (05) 4612 2111, fax: (05) 4612 2112, e–mail: [email protected]
Computer Press Praha, Hodkovická 115, 142 00 Praha 4 – Lhotka,
tel.: (02) 6171 0597, (02) 6171 0642, fax: (02) 6171 0827, e–mail: [email protected]
Computer Press Ostrava, Fráni Šrámka 5, 709 00 Ostrava – Mariánské Hory,
tel.: (069) 6624 659, fax: (069) 6634 734, e–mail: [email protected]
Computer Press Bratislava, Hattalova 12/A, 831 03 Bratislava, Slovenská republika,
tel.: (00 421 7) 251 720, 5252 048, fax: (00 421 7) 5252 046, e–mail: [email protected]
Objednávkový formulář pro prodejce naší literatury: http://www.cpress.cz/dealer
Obsah
Úvod
1
Kapitola 1 – Základní seznámení
3
Kapitola 2 – Základní druhy a přístupy v kódování
7
Ztrátová a bezztrátová komprese
13
Další pojmy charakterizující druh komprimace
16
Fyzická a logická komprimace
Symetrická a asymetrická komprimace
Adaptivní a neadaptivní komprimace
Kapitola 3 – Bezztrátová komprimace
RLE (Run−lenght Encoding)
Modifikace RLE komprimace
Formát PCX
Lempel−Ziv−Welch algoritmus
LZ77
LZ78
Huffmanovo kódování
Shannon-Fanovo kódování
Aritmetické kódování
Kapitola 4 – Ztrátová komprimace
JPEG
Jakých výsledků tedy lze dosáhnout ztrátovou kompresí typu JPEG?
Různé druhy obrázků JPEG
JPEG základní a progresivní
16
17
17
19
21
23
28
32
33
34
39
42
43
51
53
54
56
56
vii
Obsah
Transparentní JPEG je problém
Bezztrátový JPEG?
Grafický formát jako standard
Kompresní algoritmus JPEG
Další metody ztrátové komprese obrazu
Vlnková transformace
Fraktální komprese (Fractal Image Compression)
Skalární a vektorová kvantifikace
64
64
66
69
JBIG
70
MPEG
71
Jak pracuje MPEG-1?
Tři vrstvy jako standardy pro kompresi zvuku
Kapitola 5 – Archivační programy
Základní možnosti archivačních programů
Archivy
Popis parametrů
Výkonové ukazatele (benchmarks)
První test (textový soubor)
Druhý test (soubor EXE)
Třetí test (soubor EXE s možností spuštění)
Čtvrtý test (soubor BMP)
Pátý test (21 různých souborů)
Šestý test (126 malých textových souborů)
WinRAR
Popis parametrů
Příkazy programu WinRAR
Přepínače programu WinRAR
viii
57
58
59
61
73
75
81
83
83
85
85
86
92
97
99
105
111
117
120
120
124
Obsah
WinZip
Prohlížení souborů
Přidávání souborů do archivu
Mazání souborů z archivu
Rozbalování souborů
Tipy pro pokročilé
ARJ
Základní funkce
Příkazy programu ARJ
Některé zajímavé vlastnosti programu ARJ
JAR
Jaký je tedy rozdíl mezi programy ARJ a JAR?
Konfigurační soubor
ACE
135
137
138
140
140
141
144
145
151
153
154
155
155
158
Kapitola 6 – Slovníček
163
Rejstřík
173
ix
Obsah
x
Úvod
Většina uživatelů počítačů se s nimi dříve nebo později setká. Říká se jim archivační, komprimační, případně pakovací programy. Existují jich stovky, ale jejich funkce je vždy stejná:
zmenšit velikost datových souborů uložených na pevném disku.
■
Proč zmenšovat (pakovat, komprimovat, archivovat) soubory?
■
Jaký to má smysl?
■
Je to bezpečné?
■
Který pakovací program je nejlepší?
■
Jak se to pozná?
■
Jaký uživatelský komfort a jaké další funkce navíc nabízejí jednotlivé komprimační
programy?
■
Jak se jednotlivé komprimační programy ovládají?
To jsou otázky, jež trápí nejednoho běžného uživatele počítače, který při své práci pociťuje
nutnost komprimování dat.
Zkušenější uživatelé by se jistě rádi dozvěděli více:
■
Jaké algoritmy a přístupy se používají při komprimaci dat?
■
Co znamenají a k čemu slouží zkratky jako JPEG, MPEG, JBIG, MHEG a další?
■
Jaké problémy mohou nastat při používání komprimačních programů?
■
Jak tyto problémy řešit?
■
Liší se nějakým způsobem komprimace textových, binárních a grafických souborů?
■
Jak se komprimuje video a zvuky?
1
Počítačová komprimace dat
Na tyto a jiné otázky vám odpoví kniha, kterou právě držíte v ruce. Kniha se zaměřuje na
všechny uživatele komprimačních programů. Srozumitelnou formou objasňuje pojmy používané v souvislosti s komprimováním, nahlíží do „kuchyně“ komprimačních algoritmů
a obsahuje i množství praktických rad a postřehů.
2
1
Základní
seznámení
Základní seznámení
Než začneme s výkladem, je třeba seznámit se s pojmem komprimačního programu. Komprimační programy jsou programy schopné zakódovat datové soubory (ať již tyto soubory
obsahují textová, grafická nebo binární data) do podoby, kdy je velikost těchto souborů
menší ve srovnání s jejich velikostí před komprimací. Komprimační program samozřejmě
musí být schopen dekódovat (dekomprimovat) data do původní podoby.
Všechny komprimační programy (stejně jako veškerý software) procházejí svým vývojem
a prakticky ve všech případech poskytují mnohem větší uživatelský komfort a více funkcí,
než jaké jsou uvedeny v definici. Tyto přídavné funkce však již v samotném komprimačním
programu nejsou nezbytně nutné. Program, který má být označen za komprimační, musí
být schopen data alespoň komprimovat a dekomprimovat.
Existuje hned několik velmi dobrých důvodů, proč data komprimovat. Prvním z nich je zálohování dat při současné úspoře místa na paměťovém médiu.
V dnešní době samozřejmě existuje velké množství rozmanitého hardwaru, určeného pro
zálohování dat (páskové zálohovače se sekvenčním přístupem k datům, vysokokapacitní
mechaniky typu Zip a mnoho dalších).
Většina uživatelů však tyto možnosti nevyužívá – důvodem může být cena těchto zařízení,
případně dat určených pro zálohování není mnoho a výše uvedený způsob by představoval
spíše „kanón na vrabce“. V takových případech je vhodné data určená pro zálohování komprimovat a v komprimované formě uchovávat na pevném disku počítače nebo na disketách
(ideálně na obou těchto médiích). Na druhé straně uživatelé, kteří potřebují zálohovat velké
množství dat, narážejí na nedostatek místa i na vysokokapacitních zálohovacích médiích.
Ale i tady přichází ke slovu komprimace dat před jejich zazálohováním na patřičné médium.
Při zálohování je možné vytvářet archivy dat složené z komprimovaných souborů, které
spolu logicky souvisejí (např. textové soubory, grafické soubory, databázová data atp.).
Odtud také pochází často používané označení „archivační program“. Moderní komprimační
programy prakticky vždy poskytují širokou škálu archivačních nástrojů pro tento účel.
Komprimování sice důležitých, ale málo používaných souborů dat navíc zvýší přehlednost
uložení souborů na pevném disku. Úspora místa v takových případech také nemusí být zanedbatelná.
5
Tip:
Soubor je na pevném disku zaznamenáván do alokačních jednotek, tzv. clusterů. Jeden
cluster je nejmenší přidělitelná jednotka paměti na nosiči. Jeho velikost je u různých nosičů různá – podle konstrukce a celkové kapacity disku. Typická velikost takového clusteru může být např. 2 KB. To znamená, že každý libovolně malý soubor zabere na disku
nejméně zmíněné 2 KB. Malé řídce používané soubory je tedy vhodné sdružovat do komprimovaných archivů.
Dalším důvodem pro komprimování je potřeba dálkového přenosu dat. Komprimovaná data
se samozřejmě v počítačových sítích přenášejí rychleji. Pokud chcete přenášet několikamegabajtový soubor po telefonních linkách za pomoci modemu, můžete předchozím komprimováním souboru ušetřit až několik desítek minut. Zároveň tím šetříte i poplatky za telefon.
Navíc se snižuje nebezpečí, že se v průběhu přenosu přeruší spojení a celou akci bude třeba
opakovat.
Dalším důvodem mluvícím jasně pro komprimaci je možnost rozdělení komprimovaných
souborů do bloků, jejichž velikost je identická s kapacitou běžné tří a půl palcové diskety.
Tuto velice užitečnou funkci dnes nabízejí prakticky všechny moderní komprimační programy. Často se jedná o jedinou možnost, jak přenést např. soubor o velikosti 2 MB z jednoho
počítače na druhý.
Myslím, že uvedené důvody jsou dostatečně pádné a dříve nebo později postaví před problém volby komprimovacího programu téměř každého uživatele počítače.
6
2
Základní druhy
a přístupy v kódování
Základní druhy a přístupy v kódování
Než začneme s popisem jednotlivých druhů kódování, je nezbytné zdůraznit, že data různého charakteru vyžadují rozdílný přístup k jejich kompresi. V této knize se budeme zabývat
komprimací datových souborů uložených v počítači – ať již textových, binárních, grafických atd. V každém případě se však bude jednat o konečné soubory dat, jejichž charakter
bude předem znám.
Tip:
Je zřejmé, že textová data se svým charakterem budou lišit např. od grafických, a že
rozdílnost těchto dat bude upřednostňovat v tom kterém případě konkrétní komprimační algoritmy.
Většinou je možné předpokládat, zda bude datový soubor obsahovat dlouhé bloky stejných
dat (např. v některých grafických souborech). V takovém případě lze použít algoritmy vyhledávající tyto dlouhé bloky dat, které jsou posléze nahrazeny jediným symbolem.
Mnohdy jsou zase známy například pravděpodobnosti, se kterými se v datech vyskytují jednotlivé symboly (je známa frekvence jednotlivých znaků v abecedách různých jazyků). Jednou z možností pak je použít s úspěchem frekvenčně závislé kódování založené na přepisu
častěji používaných prvků abecedy na kratší bitové posloupnosti a řidčeji se vyskytující
prvky na delší bitové posloupnosti.
Jaký komprimační program je tedy nejlepší? Z předcházejících řádků je zřejmé, že jednoznačná odpověď neexistuje. Každý dostupný komprimační program je založený na jednom
algoritmu a tento algoritmus bývá pro některé posloupnosti dat vhodnější a pro jiné méně
vhodný.
Tip:
Každý komprimační algoritmus je navržen tak, že hledá a využívá pro kompresi dat určitý řád v uložených datech. Tímto řádem může být opakování sekvencí znaků, frekvence
výskytu jednotlivých znaků, identifikace dlouhých bloků stejných dat a další.
9
Tip:
Samostatnou a trochu škodolibou kapitolou komprimace je test komprimačních programů
na souborech, které byly vygenerovány jako pseudonáhodná posloupnost znaků. Nalézt
v takových souborech výše zmíněný řád je prakticky nemožné a komprimovaná velikost takových souborů se většinou prakticky rovná velikosti původní. Nezřídka je komprimovaný
soubor dokonce větší než původní nekomprimovaná verze.
Hlavními parametry výkonu (anglicky je seznam takových parametrů označovaný jako
benchmarks) takových algoritmů jsou především:
■
rychlost komprese;
■
rychlost dekomprese;
■
kompresní (komprimační) poměr.
Asi nejsledovanějším faktorem je kompresní poměr. Tento parametr bývá při testování komprimačních programů vyjadřován v několika různých formách, které však při správné interpretaci vystihují totéž.
Kompresní poměr bývá udáván jako:
10
■
Poměr mezi velikostí komprimovaného a původního souboru. Podle tohoto schématu
pokud komprimační program zkomprimuje soubor o původní délce 200 KB na 50 KB,
je udáván kompresní poměr 25 %. Jedná se vlastně o procentuální vyjádření velikosti
souboru komprimovaného vzhledem k původnímu. Čím menší procentuální vyjádření,
tím lepší výsledek komprimace.
■
Někdy je tento poměr nahrazen doplňkem předcházejícího údaje do 100 %. Předcházející příklad komprimace souboru o původní délce 200 KB na 50 KB ve sbaleném
stavu by byl charakterizován kompresním poměrem 75 %. V tomto případě naopak
čím vyšší procentuální vyjádření, tím lepší výsledek komprimace.
■
Existuje také vyjádření kompresního poměru převráceným zlomkem – jedná se o poměr velikostí nekomprimovaných dat ke komprimovaným. Předcházející příklad komprimace souboru o původní délce 200 KB na 50 KB ve sbaleném stavu by byl tedy
charakterizován kompresním poměrem 4:1. V praxi se opravdu můžete setkat se všemi uvedenými definicemi kompresního poměru.
Rychlost komprimace (komprese), tedy čas potřebný pro sbalení souboru do komprimované
podoby, může být také velice důležitým faktorem. Čas potřebný pro kompresi různými
komprimačními programy se u rozsáhlých souborů liší až o celé minuty. To jistě není
zanedbatelné.
Tip:
Existuje i další parametr udávající výkon komprimačních programů, vycházející z požadavku nejlepšího kompresního poměru za „přiměřený“ čas. Jedná se o poměr rychlost
komprimace/kompresní poměr. Ačkoli se podle mého názoru jedná o velice užitečný parametr, často nebývá v testech komprimačních programů vůbec zmiňován.
Rychlost dekomprimace, tedy čas potřebný k rozbalení komprimovaného souboru do původní podoby, je ze všech tří zmíněných parametrů asi nejméně důležitý. Doba potřebná
pro dekomprimaci bývá téměř u všech komprimačních programů kratší než doba potřebná
ke komprimaci, a proto tento parametr nebývá tím omezujícím nebo kritickým faktorem při
výběru vhodného komprimačního programu.
Na výše uvedený soubor parametrů charakterizujících výkon určitého komprimačního programu ve vztahu ke konkrétnímu souboru má kromě použitého komprimačního algoritmu
vliv i mnoho dalších faktorů. Jedná se samozřejmě v první řadě o typ hardwaru, který byl
pro testování použit.
Každému je jasné, že doba komprese se bude pro stejný algoritmus i komprimovaný soubor
lišit u počítače s procesorem řady 486 pracujícím na frekvenci 50 MHz a u počítače Pentium běžícím na 233 MHz. Kromě taktování procesoru je nutné brát v úvahu i další aspekty:
■
přístupovou dobu pevného disku;
■
stav obsazení pevného disku a jeho fragmentaci;
■
velikost a přístupovou dobu paměti RAM;
■
použití nebo zakázání vyrovnávací paměti CACHE;
■
typ operačního systému, pod kterým byly komprimační soubory testovány a mnoho
dalších parametrů.
11
Tip:
Tyto parametry většinou neovlivní dosažený kompresní poměr, ale velice podstatně se podepíší na všech ostatních výkonových parametrech zahrnujících dobu potřebnou pro kompresi a dekompresi souborů.
Pokud má být zveřejňovaný test komprimačních programů opravdu použitelný, měl by kromě názvu a verze testovaných komprimačních programů obsahovat minimálně následující
údaje:
■
Především typy souborů, na kterých bylo testování prováděno. Minimálně by zde měl
být údaj o tom, zda se jednalo o soubory textové, grafické nebo binární. Nejlépe je
však testování provádět na standardních (za účelem testování speciálně vytvořených)
a všem dostupných (např. prostřednictvím Internetu) souborech.
■
Celková nekomprimovaná velikost původních souborů.
■
Údaj o uspořádání souborů do stromové struktury.
■
Typ počítače (především procesoru), na kterém byly testy prováděny.
■
Operační systém, ve kterém byl test proveden.
Tento soubor vstupních údajů představuje opravdu pouze nezbytné minimum. Pro ucelenou
informaci o výkonu jednotlivých pakovacích programů je vhodné uvádět i další informace
především o hardwaru použitého počítače.
Objektivní výkonové ukazatele komprimačních programů však nemusejí (a většinou opravdu nejsou) být jediné při volbě programu. Dalším velice důležitým aspektem je komfort
ovládání těchto programů a další archivační funkce. Mezi tyto funkce patří především:
12
■
Zda program nabízí intuitivně známé prostředí pro ovládání programu podobné např.
oblíbenému Norton Commanderu, nebo zda je nutné specifikovat mód práce programu pomocí přepínačů uvedených přímo v příkazovém řádku.
■
Typ vytvářených archivů komprimovaných dat a možnost oddělené manipulace s jednotlivými soubory komprimovaného archivu. Mezi tyto možnosti patří:
■
přidávání a odebírání jednotlivých souborů do (resp. z) komprimovaných archivů,
■
prohlížení textových a grafických souborů uložených v komprimovaných archivech,
■
spouštění komprimovaných binárních souborů,
■ vytváření tzv. volumes, tedy oddělených bloků komprimovaných dat, i když data
pocházejí např. z původně jediného souboru. (Již dříve jsme se zmínili o tom, že tato
možnost představuje často jedinou eventualitu jak přenést dlouhé soubory na diskety.)
■
Schopnost opravy vadných komprimovaných archivů.
■
Jaké pracovní módy komprimační programy nabízejí atd.
Tip:
Většina moderních komprimačních programů uživateli nabízí, aby si zvolil, zda chce vytvořit archiv s nejlepším kompresním poměrem, nejkratší kompresní dobou atd.
Ztrátová a bezztrátová komprese
Než zakončíme obecné povídání o základních principech komprimování, je nezbytné zmínit
se o tom, že v podstatě existují dva zcela rozdílné principy komprese dat.
První z nich je tzv. bezztrátová komprimace. Veškeré informace uvedené v této úvodní kapitole se týkají prakticky výhradně tohoto typu komprese. Bezztrátová komprimace (lossyless
compression) se používá – jak již sám název napovídá – tam, kde si nelze dovolit jakoukoli
ztrátu dat – u binárních a textových souborů.
Pokud se budeme snažit zodpovědět otázku, zda existuje program, jenž by dokázal bezztrátovou metodou komprimace zmenšit velikost libovolného souboru, dojdeme k zajímavému
závěru:
Žádný komprimační program nedokáže bezztrátovou metodou komprimace komprimovat všechny soubory o velikosti větší nebo rovné N bitů pro libovolné celočíselné N větší nebo rovno 0.
Než přistoupíme k důkazu tohoto zajímavého tvrzení, zdůrazněme, že za komprimaci považujeme zmenšení velikosti souboru o nejméně jeden bit.
Důkaz výše uvedeného teorému provedeme sporem. Předpokládejme, že máme
2N různých souborů, z nichž každý má velikost právě N bitů (tento předpoklad je
zcela v pořádku), a že existuje komprimační algoritmus, který každý z těchto souborů dokáže zkomprimovat bezztrátovou metodou. Aby komprimace všech souborů byla bezztrátová, musel by komprimační algoritmus vytvořit 2N různých
13
zkomprimovaných souborů, kde velikost každého zkomprimovaného souboru bude nejvýše (N-1) bitů. Pokusme se tedy tyto soubory vytvořit. Je zřejmé, že existuje maximálně 2(N-1) různých souborů o velikosti právě (N-1) bitů, 2(N-2) různých
souborů o velikosti právě (N-2) bitů, atd. až jeden soubor o velikosti 0 bitů. Součet všech členů posloupnosti 2(N-X) pro pevné N a pro X jdoucí od jedné do N je
2N-1. Tím jsme došli ke sporu, protože alespoň dva různé vstupní soubory byly
zkomprimovány do stejné podoby výstupního souboru. Z toho je zřejmé, že komprese musela být ztrátová.
Tip:
Teorém, který jsme právě dokázali, jinými slovy říká, že pro jakýkoli komprimační algoritmus lze vymyslet sadu vstupních souborů, které tento algoritmus nebude schopen
zmenšit ani o jediný bit, aniž by při tom došlo ke ztrátě původních informací. Přitom
vstupní soubor existuje alespoň jeden pro každé N, kde N je délka souboru v bitech. Tento jednoduchý avšak velice důležitý teorém je třeba mít vždy na paměti.
Tip:
Některé programy se snaží dosáhnout vysokých kompresních poměrů používáním skrytých souborů nebo dosud nevyužitých clusterů na pevném disku. Takové metody jsou ovšem velice nejisté – pokud jsou data přenesena na jiný počítač nebo pokud jsou clustery
použity jinými soubory, komprimovaná data jsou nenávratně ztracena.
Ztráta byť jediného bitu u binárního souboru vede v naprosté většině případů ke katastrofě
v podobě další nepoužitelnosti tohoto souboru. U textových nebo grafických souborů již situace tak kritická není.
Přesto všechny programy typu ZIP, RAR, ARJ a další samozřejmě používají algoritmy, jejichž podstata zaručuje, že se při komprimaci žádná data neztratí.
Popis algoritmů bezztrátové komprese bude uveden v následující kapitole.
Existují však datové soubory, ve kterých ztráta některých dat vůbec nevadí. Jedná se o tzv.
redundantní (s nadbytečným množstvím informací) soubory, jejichž komprese může být
i ztrátová (lossy compression). O jaké soubory se jedná? Jsou to především obrázky, zvuková data a video (sekvence obrázků).
14
Jistě jste si všimli, že obrázek uložený ve formátu BMP (prostá bitová mapa) zabírá na diskovém médiu více místa než stejný obrázek uložený např. formátem JPEG, PCX, GIF a další. Formáty těchto obrázků v sobě již zahrnují kompresi dat.
To je umožněno faktem, že obrazová data mají svá specifika. Většina původních obrázků
převedených do digitální formy obsahuje nadbytečné informace, které lidské oko není
schopné postihnout. Lidské oko má omezenou rozlišovací schopnost jak ve vztahu k barevné hloubce, tak k obrysovým detailům. Na světlé ploše oko těžko rozezná tmavý bod a stejně tak není schopno rozpoznat milion barevných odstínů. Barvy blízko ležících bodů oko
průměruje.
Ačkoli číselné vyjádření jednotlivých pixelů obrázku bývá zcela odlišné, komprimační formáty obrázků se snaží v těchto číselných kombinacích najít řád, který jim umožní zmenšit
náročnost obrázku na kapacitu diskového média. Ačkoli tato komprimace vede ke ztrátě
dat, kvalita obrázku měřena subjektivním lidským vjemem zůstává stále stejná. V kapitole
věnované ztrátové komprimaci uvidíme, že náročnost obrázků na paměť lze touto metodou
snížit i 30krát bez zjevné újmy na kvalitě.
Podobně jako obrázky jsou redundantní obrázkové sekvence – video. Tam často postačí
uchovávat rozdíly dvou následujících obrázků a z nich zpětně sestavovat celý film.
Stejný princip lze využít i u komprimace zvuku. Ztrátová komprimace zvuku je založena na
nedokonalosti lidského sluchu podobně jako ztrátová komprimace obrazu využívá nedokonalosti oka. Pouze díky tomu je možné směstnat na jediný datový nosič CD třeba i deset
obyčejných „audiocédéček“.
Ztrátovou komprimací se bude zabývat samostatná kapitola. Bude v ní rozebrána jak komprimace obrázků pomocí zvláštních datových formátů, tak i komprimace zvuku a videa.
Tip:
Kromě speciálního softwaru pro ztrátovou komprimaci využívají nedokonalosti lidských
smyslů i některá hardwarová zařízení. Hardwarová zařízení pak fungují tak, že zvukovou
a obrazovou informaci, kterou lidské smysly nejsou schopny rozeznat, neukládají ani nepřenášejí – ztrácejí ji „cestou“. Hardwarovou stránkou věci se však tato kniha nezabývá.
15
Ztrátová komprimace obrazu a zvuku je a bude velice důležitá již v blízké budoucnosti při
masovém nástupu digitálních obrazových technologií (obrazový telefon, televize, videokonference atd.). Tyto nástroje budou správně fungovat jedině při vysoké rychlosti přenosu
obrazu i zvuku. A to i při zvyšujících se hardwarových možnostech bude možné jen při použití komprimace přenášených dat.
Další pojmy charakterizující druh komprimace
Pojmy ztrátové a bezztrátové komprese rozdělují tuto knihu do dvou základních částí, neboť
se jedná o dva nejdůležitější obecné pojmy týkající se komprese dat. Kompresní algoritmy
je ovšem možné dělit i podle jiných kritérií. Ačkoli toto dělení není již tak důležité, je jistě
vhodné se o něm alespoň ve stručnosti zmínit.
Fyzická a logická komprimace
Všechny kompresní algoritmy bez výjimky mají tu vlastnost, že převádějí data do kompaktnější formy, jež má stejnou informační hodnotu jako původní data. To lze zajistit použitím tzv. fyzické nebo logické komprimace.
Rozdíl mezi fyzickou a logickou komprimací spočívá v tom, zda komprimační algoritmus
při komprimaci přihlíží nebo nepřihlíží k logické informační hodnotě komprimovaných dat.
Logická komprimace používá logické substituce sekvence znaků jinou, úspornější řadou.
Konkrétním příkladem jsou zkratková slova jako Čedok (nahrazující někdejší plný název
Československá dopravní kancelář) nebo Svazarm (Svaz pro spolupráci s armádou).
Fyzická komprese probíhá bez zřetele na logiku dat, se kterými se manipuluje. Vytváří se
nová sekvence znaků (bajtů, bitů apod.), jejíž vztah k původním datům lze rozpoznat výhradně s použitím dekomprimačního algoritmu. Bez znalosti tohoto dekomprimačního algoritmu je informační hodnota komprimovaných dat nulová.
Tip:
Je zřejmé, že všechny kompresní algoritmy popisované v této knize používají fyzickou
kompresi dat.
16
Symetrická a asymetrická komprimace
Rozdělení na symetrické a asymetrické komprimační algoritmy je založeno na porovnání
množství práce, která se podle algoritmu vykoná při kompresi a dekompresi dat.
Pokud doba (a tím většinou i počet a druh operací) potřebná pro kompresi i dekompresi dat
je přibližně stejná, jedná se o symetrickou kompresi.
Některé algoritmy jsou však záměrně konstruovány jako asymetrické. Většina komprimačních algoritmů provede větší množství operací při kompresi dat. Tento přístup je výhodný
tam, kde soubor dat ukládáme na disk sice v komprimované podobě, avšak často s ním pracujeme. Manipulace se souborem musí probíhat s daty v původní nezhuštěné formě, a tak
(přestože na disku je soubor uložen pouze v komprimované podobě) program musí při každém použití souboru rozbalit data nebo jejich část do operační paměti počítače. Může se
jednat o databázi předloh, často čtený dokument atd.
Asymetrické algoritmy, jejichž práce je delší při dekomprimaci, nejsou tolik rozšířené, ale
i ty mají své opodstatnění. Při vytváření záložních kopií dat lze předpokládat, že zatímco
zálohování bude probíhat v pravidelných intervalech, většina zálohovaných dat již nebude
nikdy použita. Zde se osvědčí výhoda algoritmů používajících rychlou kompresi a pomalejší dekompresi dat.
Adaptivní a neadaptivní komprimace
Adaptivní a neadaptivní komprimační algoritmy se rozlišují podle své schopnosti přizpůsobit se charakteru dat, se kterými pracují.
Neadaptivní algoritmy jsou určeny výhradně pro komprimaci specifického druhu dat. Většinou obsahují předdefinované slovníky nebo řetězce znaků, o kterých je známo, že jejich
pravděpodobnost výskytu v souborech dat je vysoká.
Tip:
Konkrétním příkladem neadaptivního komprimačního algoritmu je tzv. Huffmanovo kódování popsané dále v této knize.
Neadaptivní algoritmus určený pro komprimaci anglického textu bude obsahovat slovníkové řetězce jako „the“ nebo „of“, které bude nahrazovat předem definovaným znakem. Tento
způsob komprimace by však byl velice málo účinný na text v jiném jazyce, o obrázcích ne-
17
bo binárních datech nemluvě. Na druhou stranu použití neadaptivního algoritmu na vhodný
druh dat je velice účinné co do dosaženého kompresního poměru, ale i času potřebného pro
kompresi a dekompresi dat.
Adaptivní algoritmus je naproti tomu schopen dosáhnout určité nezávislosti na komprimovaných datech. Takové algoritmy neobsahují žádné statické slovníky řetězců. Algoritmy si budují tyto slovníky pro každý komprimovaný soubor dat znovu dynamicky v průběhu kódování.
Tip:
Příkladem adaptivního komprimačního algoritmu je Lempel-Ziv-Welch algoritmus popsaný dále v této knize.
Obecně lze říci, že adaptivní algoritmy platí za svou přizpůsobivost a větší šíři použití menší rychlostí ve srovnání se specializovanými neadaptivními algoritmy. To však jistě nikoho
nepřekvapí.
18
3
Bezztrátová
komprimace
Bezztrátová komprimace
Jak bylo uvedeno v předcházející kapitole, bezztrátovou komprimaci (lossyless compression) využívají všechny komprimační programy určené pro komprimaci souborů. Vychází se
z předpokladu, že pro většinu souborů je nepřípustná jakákoli ztráta dat v důsledku komprimačního a dekomprimačního procesu.
RLE (Run-length Encoding)
První metodou bezztrátové komprimace, která bude v této knize podrobně vysvětlena, je
tzv. algoritmus Run-length Encoding označovaný zkratkou RLE a do češtiny překládaný někdy jako proudové kódování.
Jedná se o komprimační algoritmus, který lze použít na jakýkoli druh dat. Na charakteru
těchto dat ovšem velice silně závisí dosažený kompresní poměr. Ačkoli metoda RLE se ve
většině případů nemůže pochlubit tak dobrými kompresními poměry jako jiné složitější algoritmy, jeho výhoda tkví ve snadné instalaci, jednoduchosti celého algoritmu a s tím související poměrně vysoké rychlosti komprimace a dekomprimace.
Především jednoduchost algoritmu RLE jej předurčuje k tomu, abychom začali popis konkrétních komprimačních algoritmů právě jím.
Základním principem komprimace metodou RLE je zhuštění opakovaných znaků, které se
v souboru vyskytují hned za sebou. Řetězec opakujících se znaků se nazývá proud (odtud
proudové kódování). Tento proud znaků je vždy zkomprimován do formy jednoho paketu
RLE. Paket musí vždy obsahovat dvě informace:
■
Proudové číslo udávající počet znaků proudu snížený o jedničku a následující
■
proudovou hodnotu, jež se shoduje s hodnotou opakujícího se znaku v proudu.
Tip:
Proč se proudové číslo definuje jako počet znaků proudu snížený o jedničku a ne přímo
počet znaků, bude vysvětleno později.
Pokud soubor obsahuje následující sekvenci znaků,
AAAAkkRRRRRm
21
zakóduje se tato sekvence do podoby:
3A1k4R0m
V udané posloupnosti znaků rozpozná komprimační algoritmus čtyři proudy a přiřadí jim
čtyři pakety. Tyto pakety jsou:
■
3A
■
1k
■
4R
■
0m
Prvním údajem v paketu je vždy proudové číslo (počet znaků proudu snížený o jedničku).
Tento údaj je následován proudovou hodnotou znaku.
Vidíte, že zmenšení velikosti souboru bylo dosaženo výhradně díky proudům znaků obsahujícím více než dva znaky. Pokud se proud skládá pouze z jediného znaku, komprimovaný
paket RLE je dokonce delší než původní proud.
Ačkoli v další části této kapitoly si probereme některé modifikace, které podobnému zvětšování komprimovaných souborů zamezují, je už z této základní podoby algoritmu RLE
zřejmé, na jaká data bude prakticky použitelný a na jaká nikoli.
Metoda RLE tedy nebude vhodná pro komprimaci textových souborů. Kompresní poměr by
byl v takovém případě velice špatný. Stejně neslavně by dopadla komprimace většiny binárních souborů. Zbývají tedy jen obrázky.
Metoda RLE je vhodná pro komprimaci jednoduchých obrázků s malou barevnou hloubkou
(maximálně 256 barev). Takové obrázky se vytvářejí například v programu Paintbrush (Malování). Tyto obrázky mají často jednobarevné pozadí, které zaručuje dostatečnou velikost
jednotlivých proudů. U těchto obrázků je možné dosáhnout kompresního poměru až 70 %.
(Připomeňme, že jsme již dříve zadefinovali kompresní poměr tak, že 70procentní kompresní poměr odpovídá komprimaci dat na 30 % původní velikosti.)
Naopak pro komprimaci fotografií se komprimační metoda RLE nehodí. Fotografie totiž na
první pohled nesplňují podmínku dlouhých proudů.
22
Modifikace RLE komprimace
Vzhledem k tomu, že praktický efekt má metoda RLE téměř výhradně při jejím použití na
jednoduché obrázky s malou barevnou hloubkou, zaměříme se při dalším popisu rozdílných
variant algoritmu RLE výhradně na tato grafická data.
Tip:
Metodu RLE využívá např. formát obrázku PCX, kterým se budeme podrobně zabývat dále.
Existují tři základní přístupy k praktické realizaci algoritmu RLE ve vztahu k bitovým mapám jednoduchých obrázků. Ve všech těchto přístupech jsou obvykle původní data předlohy
proudově kódována sekvenčním postupem, který přistupuje k datům jako k jednorozměrnému poli dat a nikoli jako k dvourozměrné mapě dat.
Bitová mapa se začíná číst a komprimovat od levého horního rohu a postupuje se buď po
řádcích nebo sloupcích jednotlivých pixelů až do pravého dolního rohu.
Při komprimaci je však vhodné udržovat informaci o koncích jednotlivých řádků (resp.
sloupců) bitové mapy. Tyto značky lze potom s výhodou použít, pokud je potřeba rozbalit
pouze určitou část obrázku (např. 101. až 180. řádek původní předlohy). V takovém případě
dekomprimační algoritmus nemusí dekomprimovat prvních 100 řádků obrázku pouze proto,
aby našel požadovaný začátek výřezu. Dekomprimace může začít přímo na 101. řádku. Bohužel některé programy podporující grafické formáty s kompresí RLE informaci o konci
řádků či sloupců do komprimované podoby obrázků neukládají.
Začněme tedy s konkrétním popisem jednotlivých praktických přístupů. Základní struktura
algoritmu RLE je zobrazena na obrázku 1.
23
Obr. 1
Základní schéma algoritmu RLE.
Praktické přístupy ke kódování bitových map se dělí podle typu základních datových prvků
tvořících proudy. Podle typů těchto základních prvků existují tři praktické modifikace:
■
bitová úroveň,
■
bajtová úroveň a
■
pixelová úroveň.
Bitová úroveň kódování metodou RLE rozeznává pouze dva proudy znaků – proud jedniček
a proud nul. Taková metoda je účinná prakticky pouze na monochromatické jednobitové obrázky. Tato data obsahují dostatečně dlouhé proudy jedniček i nul k tomu, aby metoda RLE
v této modifikaci dosáhla dobrých kompresních poměrů. Jak tedy vypadá paket RLE na
úrovni bitového kódování?
24
Jedná se o jediný bajt logicky rozdělený do dvou částí. Nejvýznamější bit každého bajtu určuje proudovou hodnotu (tj. 1 nebo 0) a sedm méně významných bitů představuje proudové
číslo udávající počet opakování proudové hodnoty snížený o 1. Je zřejmé, že délka proudu
musí být vždy v rozsahu 1-128 znaků, neboť do sedmi bitů lze zapsat číslo 0-127. To je také
důvod, proč se jako proudové číslo používá počet znaků proudu snížený o jedničku a nikoli
přímo počet znaků proudu. Pokud původní nekomprimovaná data obsahují proud delší než
128 znaků, musí být tento proud při kódování rozdělen na dva nebo více proudů.
Tip:
Pokud budeme bajt s hodnotou 151 interpretovat jako paket kódování RLE na bitové
úrovni, zastupuje tento paket proud jedniček dlouhý 24 znaků. Číslo 151 v desítkové soustavě má totiž ve dvojkové soustavě vyjádření 10010111. Nejvyšší bit je jednička a nižších sedm bitů představuje číslo 23 v desítkové soustavě.
Tip:
Všimněte si, že oproti základnímu schématu jsou údaje paketu RLE zapisovány obráceně
– nejprve se zapíše proudová hodnota a pak teprve proudové číslo.
Na závěr výkladu o modifikaci metody RLE na bitové úrovni je vhodné připomenout, že
při komprimaci tato metoda nerozeznává hranice jednotlivých bajtů. Ty nejsou v tomto případě zajímavé.
Druhou modifikací komprimační metody RLE je bajtová úroveň. Tato modifikace – jak již
její název napovídá – kóduje proudy opakujících se bajtových hodnot a naopak si nevšímá
dělení na bity nebo hranic šestnáctibitových (případně 32bitových) slov.
Paket RLE se v tomto případě skládá ze dvou bajtů. První bajt udává proudové číslo v rozsahu 0-255 a druhý bajt proudovou hodnotu. Její rozsah je samozřejmě opět 0-255. Zde tedy může velikost jediného proudu, kterému bude odpovídat jeden RLE paket, dosahovat
délky až 256 znaků.
25
Tip:
Pokud za sebou následují dva bajty s hodnotami 78 a 32, které budeme interpretovat jako paket RLE, znamená to, že hodnota 32 se v příslušném proudu vyskytuje 79krát.
Pro dosažení lepších kompresních poměrů bývá vhodné doplnit bajtovou metodu o schopnost ukládat přesné nekódované jednobajtové proudy do kódovaného toku dat.
V této modifikaci bajtové úrovně se pro vyjádření proudového čísla využívá pouze sedm
méně významných bitů prvního bajtu paketu. Maximální velikost proudu je tak opět snížena na 128 znaků. Nejvýznamnější bit je indikátorem typu proudu. Pokud je tento bit nastaven na 1, jedná se o klasický dvoubajtový paket RLE, kde druhý bajt obsahuje proudovou
hodnotu.
Při nastavení nejvýznamnějšího bitu prvního bajtu na hodnotu 0 následuje za proudovým
číslem přesný proud znaků, který se čte v té podobě, v jaké je zapsán. Jedná se o tzv. přímý
paket. Používáním přímých paketů se zamezí tzv. záporné kompresi, při které kódování jednobajtových proudů dat představuje větší velikost komprimovaných dat oproti jejich původní formě.
Tip:
Pokud první bajt paketu RLE obsahuje např. číslo 151 (tj. 10010111 ve dvojkové reprezentaci), jedná se o klasický dvoubajtový paket. Následující bajt představuje proudovou
hodnotu, která se v proudu opakuje 24krát. Třetí bajt je již opět interpretován jako začátek nového paketu.
Pokud však bude první bajt paketu RLE obsahovat číslo 23 (10111 ve dvojkové reprezentaci), bude se následujících 24 bajtů interpretovat jako přesný proud dat, která se při dekomprimaci souboru prostě opíší. Potom teprve začíná nový paket RLE.
Metoda RLE na úrovni bajtů je vhodná pro obrázky, které jsou uloženy ve formě jeden bajt
na pixel. Ne vždy tomu tak je, a proto se používá i třetí modifikace metody RLE na pixelové úrovni. Tato metoda se používá u složitějších obrázků, kdy je jediný pixel reprezentován
více než jedním bajtem dat.
26
Tip:
Informaci o tom, kolik bajtů uchovává informaci o vzhledu jednoho pixelu, lze získat
v hlavičce grafického souboru.
Velikost paketu RLE se v tomto případě liší podle počtu bajtů na pixel. Pokud např. obrázek podporuje schéma dat „3 bytes per pixel“ (3 bajty na pixel), bude paket RLE čtyřbajtový – první bajt jako proudové číslo a následující tři bajty jediné proudové hodnoty. Kódovací metoda zůstává stejná jako u jednobajtové úrovně a opět lze využít modifikace s indikátorem přímého paketu.
Tip:
Některé obrázky používají pro zobrazení pixelu počet bitů, který neodpovídá celým bajtům. V takovém případě lze paket RLE konstruovat na bitové úrovni a dosáhnout tím
opět zlepšení kompresního poměru.
Existuje i další modifikace metody RLE, která se snaží vyhnout záporné kompresi, která
nastává při velkém počtu jednoznakových proudů v datech předlohy. Vysvětlíme si tuto metodu na schématu bajtové úrovně.
Základní myšlenkou je použití tří bajtů jako jediného paketu RLE. První bajt v tomto případě obsahuje příznakovou hodnotu, následující dva bajty tvoří „klasický“ paket RLE. Druhý
bajt opět představuje proudové číslo a třetí proudovou hodnotu. Kódování dat předlohy probíhá tak, že pokud komprimační program zjistí jedno-, dvou- nebo tříbajtový proud, zapíší
se tyto hodnoty do komprimovaného toku dat přímo. Odpadá tak zápis dalších znaků.
Při dekomprimaci se nejprve posoudí, zda první bajt paketu RLE obsahuje příznakovou
hodnotu nebo nikoli. Pokud se jedná o příznak, expanduje se paket podle údajů proudového
čísla a proudové hodnoty. Nejedná-li se o příznak, přidá se tento bajt přímo do nekomprimované podoby souboru. Následující bajt se opět testuje, zda nejde o příznak.
K nevýhodám tohoto přístupu patří to, že minimální velikost proudu dat pro „klasický“ paket RLE se zvýší na čtyři bajty, což může negativně ovlivnit kompresní poměr některých
dat. Další problém nastává, pokud nekódovaný tok dat obsahuje hodnotu, která se shoduje
s hodnotou vyhrazenou pro příznak. Každý takový znak musí být kódován do tříbajtového
paketu s proudovým číslem 0 (odpovídající jedinému znaku). Pouze tímto způsobem lze za-
27
bránit mylné interpretaci hodnoty příznaku při dekomprimaci. Jako příznakovou hodnotu je
tudíž nutné zvolit znak s nejmenší pravděpodobností výskytu v datech předlohy, aby v důsledku jeho častého výskytu nedocházelo ke zhoršení kompresního poměru.
Poslední modifikaci komprese RLE, kterou si zde popíšeme, představuje forma tzv. vertikálních replikačních paketů neboli paketů s opakovanými vzorkovými řádky. Zlepšeného
kompresního poměru se dosahuje vyjádřením toho, zda se opakuje celý předchozí řádek. Je
zřejmé, že se tento druh kódování hodí pouze na ty druhy dat, kde se opakování celých řádků předpokládá.
Dejme tomu, že jeden řádek obrázku je složen z dat uložených do 512 bajtů a všechny pixely v něm jsou stejné. Za předpokladu maximálního kódovatelného proudu 128 bajtů při
dvoubajtovém schématu paketu RLE se tento řádek zakóduje do osmi bajtů. Pokud má stejnou barvu prvních 100 řádků předlohy, zakóduje se při použití metody RLE na bajtové
úrovni (tak jak je popsána výše) těchto 100 řádků do 800 bajtů. S metodou vertikálních replikačních paketů stačí na druhý až stý řádek jediný paket. Celkově tedy 10 bajtů.
Tip:
Metodu vertikálních replikačních paketů využívají grafické formáty WordPerfect Graphics Metafile (WPG) a GEM Raster (IMG). WPG používá dvoubajtové paketové schéma.
Pokud má první bajt paketu hodnotu 0, jde o vertikální replikační paket. Druhý bajt takového paketu udává počet opakování řádku mínus 1.
U formátu IMG se jako indikátor vertikálního replikačního paketu používá sekvence tří
bajtů 00H 00H FFH. Následující bajt udává počet opakování předcházejícího řádku mínus jedna.
Formát PCX
Pro demonstraci praktického použití jsem vybral popis komprimace a dekomprimace formátu obrázku PCX (PC Paintbrush File Format). Tento formát obrázku je jedním z nejpoužívanějších při komprimaci jednoduchých bitových map, které se tvoří např. programem
Paintbrush. Formát PCX také podporuje většina grafických aplikací.
Důležitou součástí každého souboru PCX je hlavička skládající se ze 128 bajtů. Hlavička
má následující strukturu:
28
typedef struct_PCXHeader
{
BYTE Identifier;
BYTE Version;
BYTE Encoding;
BYTE BitsPerPixel;
WORD XStart;
WORD YStart;
WORD XEnd;
WORD YEnd;
WORD HorzRes;
WORD VertRes;
BYTE Palette[48];
BYTE Reserved1;
BYTE NumBitPlanes;
WORD BytesPerLine;
WORD PaletteType;
WORD HorzScreenSize;
WORD VertScreenSize;
BYTE Reserved2[54];
} PCXHead;
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
Identifikátor PCX souboru - hodnota 0AH */
Číslo verze */
Druh kódování */
Bitů na pixel */
Levá strana obrázku */
Horní strana obrázku */
Pravá strana obrázku */
Spodní strana obrázku */
Horizontální rozlišení */
Vertikální rozlišení */
16barevná EGA paleta */
Vyhrazeno */
Počet bitových rovin */
Bajtů na skenovací řádek */
Typ palety */
Horizontální velikost obrazovky */
Vertikální velikost obrazovky */
Vyhrazeno */
Komprimace bitové mapy do formátu PCX probíhá podle schématu bajtové úrovně komprimace RLE. Původní data předlohy jsou čtena po jednom bajtu a jsou zjišťovány proudy
opakujících se hodnot bajtů, které jsou pak zaznamenávány do dvoubajtových paketů RLE.
Dva nejvýznamnější bity prvního bajtu paketu představují indikátory paketu. Pokud jsou
nastaveny na hodnotu 1, jedná se o „klasický“ dvoubajtový paket. Do zbylých šesti bitů je
zakódováno proudové číslo. Následující bajt obsahuje proudovou hodnotu.
Jsou-li nejvýznamnější bity čteného bajtu nastaveny na hodnotu 0, je celý tento bajt považován za přímou hodnotu bajtu a proud má jediný prvek.
Tip:
Maximální délka proudu je omezena šesticí bitů na 64 bajtů.
29
Tip:
Tato modifikace komprimovacího algoritmu není ideální, neboť jednobajtový proud může
obsahovat pouze hodnotu v rozmezí 0-63. Pokud je hodnota v intervalu od 64 do 255, musí být použit dvoubajtový paket RLE. Pokud obrázek obsahuje větší množství pixelových
proudů s hodnotami většími než 63, zhoršuje se výrazně kompresní poměr. U jednoduchých obrázků je však toto riziko malé, a proto bylo toto schéma kódování použito.
Pro dekódování obrázku do původní formy je zapotřebí znát několik údajů. Údaje jsou uvedeny včetně způsobu, jak je získat z hlavičky souboru:
■
šířka obrázku v pixelech (délka skenovací řádky): XEnd - XStart + 1
■
počet řádků obrázku: YEnd - YStart + 1
■
počet výplňových bajtů na konci každé skenovací řádky:
((BytesPerLine * NumBitPlanes) * (8 / BitsPerPixel)) - (XEnd - XStart) + 1)
Dekódování obrazových dat uložených ve formátu PCX probíhá podle následujícího schématu:
■
čti bajt
■
testuj 2 nejvyšší bity
■
pokud jsou dva nejvyšší bity rovny 1, udává zbylých 6 bitů proudové číslo
■
čti další bajt
■
zapiš tento bajt tolikrát, kolikrát udává proudové číslo
■
pokračuj od začátku
■
pokud jsou dva nejvyšší bity rovny 0, jedná se o hodnotu pixelu
■
zapiš hodnotu bajtu jedenkrát
Celé schéma tvoří vnitřní tělo dvou vnořených cyklů. Vnitřní cyklus se opakuje tolikrát,
aby počet zapsaných bajtů odpovídal délce skenovací řádky. Vnější cyklus se pak počtem
opakování musí rovnat počtu řádků rastrového obrázku.
Inverzní postup komprimace obrazových dat je zřejmý z předchozího výkladu a nebude zde
tudíž uveden. Převaděč bitové mapy do formátu PCX (komprimační program) jen nesmí zapomenout na zapsání 128bajtové hlavičky souboru.
30
Tip:
Plná interpretace obrazového formátu PCX vyžaduje nejen znalost komprimačního schématu, ale také další informace. Např. ukládání pixelových dat může být realizováno dvěma způsoby:
■
Po pixelech – v tomto případě jsou pixelová data uložena za sebou, jak to nastiňuje
schéma.
■
Po plochách – v tomto případě jsou data rozdělena do tří rovin červené, zelené
a modré. Skenovací řádka dat je pak uložena v těchto třech rovinách
Shrnutí
RLE představuje jeden z nejjednodušších komprimačních algoritmů. Základním
principem komprimace je to, že se každá sekvence stejného znaku původních dat
uloží ve formě nesoucí informaci, o který znak se jedná a o počtu opakování znaku.
Nevýhody:
Úzká oblast dat, na kterých tato metoda dosahuje dobré kompresní poměry.
Komprimace RLE je vhodná pouze pro jednoduché obrázky s malou barevnou
hloubkou (např. obrázky z aplikace Paintbrush). Nehodí se ani pro složitější obrázky ani pro textové nebo binární soubory.
Výhody:
Jednoduchost algoritmu a jeho snadné použití vedoucí k vysoké komprimační i dekomprimační rychlosti.
31
Lempel-Ziv-Welch algoritmus
Komprimační algoritmus Lempel-Ziv-Welch (LZW) je jednou z nejrozšířenějších komprimačních metod, kterou používají (v různé formě) jak kompresní programy (např. ARJ,
PKZIP, ZOO, LHA atd.), tak i různé grafické formáty obrázků. Jedná se o tzv. substituční
(adaptivní slovníkovou) metodu.
Základním principem tohoto kompresního algoritmu je vyhledávání stejných posloupností
bajtů v originálním souboru. Pomocí odkazů na tyto posloupnosti dat algoritmus buduje datový slovník.
Komprimace pak probíhá podle následujícího schématu:
■
Pokud se posloupnost bajtů (řetězec) ve vytvářeném slovníku nevyskytuje, je tato posloupnost přidána do slovníku a v nezměněné formě zapsána do komprimovaného
výstupního toku dat.
■
Pokud se vstupní posloupnost bajtů ve slovníku již nachází, zapíše se do výstupního
toku dat pouze zástupná slovníková hodnota odpovídající nalezené vstupní posloupnosti. Díky tomu, že zástupná hodnota je vždy menší než čtená posloupnost, dochází
ke kompresi dat.
Dekomprimace je inverzním procesem, při kterém algoritmus čte komprimovaný tok dat
a stejným způsobem vytváří datový slovník posloupností (řetězců) bajtů. Dekompresor tedy
postupně čte komprimované kódy, zapisuje na výstup příslušné řetězce a přidává nové řetězce do slovníku.
Detailnější popis komprese a dekomprese bude uveden později. Nyní si zdůrazněme jednu
ze základních vlastností algoritmu LZW.
Tip:
Pro potřeby dekomprese není nutné uchovávat datový slovník vytvářený při komprimaci.
Dekodér nepotřebuje mít tento slovník staticky uložen, ale namísto toho sám buduje duplicitní slovník v průběhu dekomprese.
Vraťme se teď trochu do minulosti a začněme se zabývat základními modifikacemi algoritmu LZW v pořadí, v jakém spatřily světlo světa.
32
Existují dvě základní schémata tohoto komprimačního algoritmu. Jeho počátky jsou spojeny se jmény Abraham Lempel a Jakob Ziv. Tito pánové vypracovali v letech 1977
a 1978 kompresní algoritmy, které vešly do povědomí pod zkratkami LZ77 a LZ78. V roce
1984 na jejich práci navázal Terry Welch, který modifikoval kompresní algoritmus LZ78
pro potřeby hardwarových zařízení, konkrétně diskových řadičů. Tak vznikla podoba Lempel-Ziv-Welch algoritmu známého pod zkratkou LZW.
LZ77
Komprimační část algoritmu LZ77 funguje tak, že se pokouší vyhledat co nejdelší opakující se posloupnosti znaků. Pokud takovou opakující se posloupnost nalezne, zapíše na výstup pouze odkaz na předcházející výskyt řetězce.
Například vstupní řetězec „Leze po železe“ se zakóduje do podoby „Leze po že[10,4]“.
Znaky [10,4] je třeba považovat za schématicky zapsaný offset udávající, že dekodér má
z předcházejících deseti znaků vybrat první čtyři.
Podstatou tohoto typu komprese je tzv. posuvné okno (sliding window), které obsahuje koncovou část již přečteného (a zkomprimovaného) textu. V tomto okně se kompresní algoritmus snaží nalézt co nejdelší podřetězec odpovídající řetězci na vstupu. Pokud se to podaří,
zakóduje jej v podobě odkazu na tento výskyt. Odkaz musí obsahovat ukazatel na začátek
podřetězce a jeho délku.
Tip:
Posuvné okno musí být samozřejmě dostatečně veliké, aby kompresní algoritmus dosáhl
dobrého kompresního poměru, ale zároveň ne tak velké, aby hledání nejdelšího řetězce
v tomto okně neúměrně neprodloužilo dobu komprimace. Ve většině případů se používá
velikost okna několik kilobajtů.
Posuvné okno obsahuje dvě části: prohlížecí okno a aktuální okno (look ahead buffer). Na
začátku algoritmus nastaví posuvné okno tak, aby začátek vstupu obsahovalo aktuální okno.
Potom pokaždé v posuvném okně najdeme co nejdelší počáteční podřetězec (předponu) řetězce z aktuálního okna začínající v prohlížecím okně. Tento podřetězec se pak zakóduje
v podobě ukazatele na počátek podřetězce v prohlížecím okně a jeho délku.
33
Zde je uveden stručný nástin algoritmu popsaného v předcházejícím odstavci:
while (aktuální okno není prázdné)
{
najdi informaci (ukazatel, délka) nejdelší předpony aktuálního okna
if (délka > minimální délka)
{
write (ukazatel, délka)
posuň posuvné okno o délku znaků doleva
}
else
{
write (první znak aktuálního okna)
posuň posuvné okno o 1 znak doleva
}
}
Tip:
Existuje několik způsobů jak rozeznat dvojici znaků nesoucí informaci o dvojici (ukazatel, délka) od jednotlivých znaků na výstupu. Nejpoužívanějším je zápis LZSS (Storer,
Szymanski): <1, ukazatel, délka> nebo <0, jednotlivý znak>. Nula na počátku signalizuje jednotlivý znak, jednička informační dvojici znaků.
Uvedený algoritmus je základním algoritmem, od kterého se odvozuje velká skupina modifikací nazývaná třída algoritmů LZ77.
Dekomprimace souboru zkomprimovaného metodou LZ77 je velice jednoduchá a rychlá.
Vždy, když dekomprimační algoritmus narazí na offset udávající ukazatel a délku řetězce,
prostě tento řetězec zkomprimuje na výstup.
LZ78
Zatímco metoda LZ77 vytváří svůj dynamický slovník pomocí odkazů do již komprimovaného textu, vylepšený algoritmus LZW patřící do třídy algoritmů LZ78 používá slovníkové
odkazy odlišně. Metoda LZW vytváří dynamicky slovník opakujících se řetězců v průběhu komprimace. Různé modifikace algoritmů třídy LZ78 se liší ve způsobu vytváření
slovníku.
34
Slovníková komprese LZW je založena na následující velmi jednoduché strategii. Algoritmus postupně rozpoznává a ukládá do tabulky řetězce znaků a tyto řetězce nahrazuje ve
výstupním textu přirozenými čísly z předem definovaného intervalu. Definice intervalu je
závislá na charakteru komprimovaných dat. Například při kódování řetězce znaků zobrazených v osmibitovém zobrazení (znaků ASCII) je prvních 255 čísel vyhrazeno pro zobrazení
samostatných znaků z původního souboru. Čísla nad 255 se pak přidělují jednotlivým nalezeným řetězcům. Přitom se vytváří slovník (tabulka) již rozeznaných řetězců, který se
v průběhu komprimace udržuje v paměti počítače.
Běh algoritmu LZW začíná s prázdným slovníkem a řetězcem W obsahujícím první znak
zdrojového souboru. Vždy po přečtení dalšího znaku c zjistí, jestli se řetězec W+c vyskytuje ve slovníku. Pokud ano, pouze prodlouží řetězec W o znak c, jinak zapíše nový odkaz na
řetězec do slovníku. Pokud řetězec W obsahuje jediný znak, bude do slovníku zanesen pouze jediný znak. Vzhledem k tomu, že do slovníku se zapisují čísla větší než 255, je nutné
i tento jediný znak zapsat v příslušné podobě. K vyjádření odkazu na řetězec se většinou
používá 12bitová hodnota.
V tomto případě tedy čísla 0–255 jsou jednotlivé znaky a čísla 256–4095 kódy řetězců do
slovníku.
Tip:
Pokud se slovník zaplní dříve, než je přečten celý soubor, je celý slovník smazán a začíná
se plnit znovu. Někdy se pro zlepšení účinnosti místo smazání slovníku používá algoritmus LRU (last-recently-used) pro odstranění nepoužívaných řetězců ze slovníku. Vzhledem k tomu, že slovník se plní od nejnižších pozic, je pro zlepšení kompresního poměru
výhodné začít kódy ukládat pouze 9bitově a teprve když se slovník více zaplní, postupně
je rozšiřovat až na 12 bitů. Slovník dekompresoru se totiž plní stejně, a tak dekompresor
snadno pozná, kdy začít kódy číst 10bitově.
Je nutné si uvědomit, že smazáním slovníku se neztrácí žádná informace, pouze se algoritmus ochuzuje o možnost využití smazaných odkazů na řetězce v průběhu pokračující
komprese.
Nástin právě popsaného algoritmu uvádějí následující řádky:
set W = NIL
While (!eof(input))
{
35
přečti znak c
if (Wc ve slovníku)
W = Wc
else
{
Zapiš kódovou hodnotu pro W
Přidej Wc do slovníku
W = c
}
}
Pro větší názornost uvedeného algoritmu si ukažme konkrétní příklad zakódování vstupního
řetězce. Mějme vstupní řetězec následujících znaků: WEB/WEB/WEB!
Řetězec W
Přečtený znak
Výstup
Nová položka ve slovníku
W
W
E
W
(256) = WE
E
B
E
(257) = EB
B
/
B
(258) = B/
/
W
/
(259) = /W
W
E
WE
B
(256)
(260) = WEB
B
/
B/
W
(258)
(261) = B/W
W
E
WE
B
WEB
!
(260)
(262) = WEB!
!
(eof)
!
Tip:
Při kompresi se velmi často zjišťuje, jestli nějaký řetězec již je ve slovníku, případně jeho
kód. Pro tento účel je nutné použít některou efektivní metodu vyhledávání, např. strom
nebo hash-table.
36
Dekompresní část algoritmu postupně čte kódy komprimovaného souboru, zapisuje příslušející řetězce na výstup a přidává nové řetězce do slovníku. Do slovníku je vždy přidán řetězec reprezentovaný předcházejícím kódem a první znak z řetězce s aktuálním kódem. Pro
případ, že by byl přečten kód, kterému ještě nebyl přiřazen řetězec (tato situace může nastat
např. pokud původní text obsahoval několik stejných znaků za sebou), je do slovníku přidán
řetězec skládající se z předcházejícího řetězce a jeho posledního znaku. Zdůrazněme, že
takto tvořený slovník bude totožný s tím, který vytvořil kompresní algoritmus.
Dekompresní schéma algoritmu LZW lze zapsat následujícím způsobem:
čti prom
zapiš prom
while (!eof(input))
{
čti code
zapiš řetězec odpovídající kódu code (tj. table[code]) – to může být přímo
znak code
přidej řetězec table[last]+první znak table[code] do slovníku
prom = code
}
Jednou z důležitých předností, kterou je třeba vyzdvihnout, je využitelnost algoritmů LZW
u takových zařízení, kterými data pouze procházejí a kde je žádoucí data zpracovat rychle.
Takovými zařízeními jsou např. modemy. Zde je totiž třeba rychlé zpracování dat a vyslání
po lince k příjemci. Výhoda komprimace LZW oproti jiným spočívá v tom, že modemy používající tuto kompresi nemusí zdrojová ani zkomprimovaná data uchovávat. Zdrojová data
se po komprimaci mohou ihned zaměnit dalšími a zkomprimovaná data se okamžitě vyšlou
příjemci.
Nezanedbatelnou výhodou je přitom fakt, že většina jiných komprimačních algoritmů pracuje po blocích, tedy že zkomprimovaná data mohou být vyslána až po kompresi celého
bloku, kdežto za použití algoritmu LZW může být proces vysílání plynulý.
37
Shrnutí
Rodina komprimačních algoritmů známá především pod označením Lempel-ZivWelch (LZW) algoritmus (také substituční nebo slovníková metoda) je velice rozšířená jak při bezztrátové komprimaci grafických, tak i binárních či textových dat.
Tento typ komprese používá např. grafický formát GIF, TIFF, programy jako jsou
ARJ nebo PKZIP. LZW je součástí modemových standardů pro přenos dat atd.
Základním principem tohoto kompresního algoritmu je vyhledávání stejných posloupností bajtů v originálním souboru. Zápisem odkazů na tyto posloupnosti dat
algoritmus buduje datový slovník. Každý další výskyt takové posloupnosti bajtů
se zakóduje buď:
■
odkazem na předcházející výskyt posloupnosti nebo
■
použitím slovníkového odkazu spojeného s příslušným řetězcem.
Výhody:
■ velmi dobrý kompresní poměr (zvláště při aplikaci některé statistické metody
na výsledný kód);
■
rychlá komprese i dekomprese a nevelké nároky na paměť;
■
adaptivní metoda vytvářející dynamický substituční slovník. Tento slovník není nutné ukládat pro potřeby dekomprese – dekompresní část algoritmu vytvoří duplicitní slovník přímo při dekompresi;
■
možnost kontinuálního vysílání zkomprimovaných dat (např. modemem) bez
nutnosti čekání na dokončení komprimace celého datového bloku.
Nevýhody:
Rychlý nárůst slovníkových kódů odkazujících na řetězce původního souboru vede v některých případech k zaplnění paměti určené pro slovníkové kódy. Z toho
pak vyplývá smazání aktuálního slovníku a jeho nové vytváření bez možnosti použití „zapomenutých“ odkazů. V případě větších slovníků zase narůstá doba vyhledání řetězce v tabulce.
38
Huffmanovo kódování je neznámějším zástupcem skupiny algoritmů, které pracují na
základě různých četností znaků v kódovaných datech. Již z této úvodní věty je zřejmé,
že Huffmanovo kódování a příbuzné komprimační techniky jsou určeny především pro
komprimaci textových souborů.
Základní myšlenku této skupiny algoritmů lze zjednodušeně popsat takto: při komprimaci
se postupuje tak, že nejprve komprimační algoritmus zjistí pravděpodobnosti výskytů jednotlivých znaků (příp. jejich kombinací) a každému znaku (kombinaci znaků) přiřadí jedinečný kód. Takovéto kódy se liší svou bitovou délkou. Tato část algoritmu je nejdůležitější
a musí být navržena tak, aby přiřazení kódů znakům respektovalo požadavek na přiřazení
bitově nejkratších kódů znakům s častějším výskytem a bitově delších kódů znakům s méně
častým výskytem. Pak již jen algoritmus postupně načítá znaky vstupního souboru, nachází
odpovídající předem přiřazené kódy a tyto kódy zapisuje na výstup.
Tip:
Jednotlivé varianty algoritmů založených na různé četnosti znaků v souborech se liší především částí přiřazující jednoznačné kódy jednotlivým znakům vstupního souboru.
Vytvoření binárního stromu si nejlépe vysvětlíme na konkrétním příkladu. Předpokládejme,
že potřebujeme zkomprimovat soubor, který obsahuje pouze znaky A, 8, 0, K a R. Dále
předpokládejme, že proběhla analýza pravděpodobnosti výskytu těchto znaků v souboru určeném pro komprimaci s následujícím výsledkem:
znak A se v souboru vyskytuje s pravděpodobností 50 %,
znak 8 se v souboru vyskytuje s pravděpodobností 12,5 %,
znak 0 se v souboru vyskytuje s pravděpodobností 6,25 %,
znak K se v souboru vyskytuje s pravděpodobností 6,25 %,
znak R se v souboru vyskytuje s pravděpodobností 25 %.
39
Binární strom podle zásad Huffmanova algoritmu potom tvoříme od koncových „listů“ stromu, tj. od znaků s nejmenší pravděpodobností (viz obr. 2). Vybereme nejprve znaky s nejmenší pravděpodobností výskytu a uděláme z nich dva koncové listy stromu. Potom vybereme znak s nejnižší pravděpodobností z dosud nezpracovaných znaků, a tak postupujeme
až ke kořeni stromu.
Obr. 2
Příklad binárního stromu Huffmanova kódování.
Tip:
Každý uzel binárního stromu představuje součet pravděpodobností všech „listů“, které
jsou ve stromové struktuře pod ním.
Vytvořením binárního stromu jsou definovány kódy přiřazené podle četnosti výskytu jednotlivým znakům souboru. Tyto znaky se přiřadí jednotlivým znakům tak, že ke každému
znaku se postupuje stromovou strukturou. Při pohybu od uzlu k uzlu zaznamenáme jedničku vždy při cestě vpravo dolů a nulu při cestě vlevo dolů.
Pokud se budeme držet binárního stromu vytvořeného na obr. 2, budou kódy přiřazené jednotlivým znakům vypadat takto:
A: 1
8: 011
0: 0100
K: 0101
R: 00
40
Tip:
Uvedený binární strom není samozřejmě jedinou možností přiřazení Huffmanových kódů
jednotlivým znakům při uvedené distribuci. Binárních stromů lze uvedeným způsobem vytvořit více, avšak celková komprimovaná délka souboru bude vždy stejná, jelikož počet
bitů přiřazených jednotlivým znakům bude ve všech případech stejný.
Komprese na základě vytvořeného binárního stromu probíhá tak, že komprimační algoritmus čte sekvenčně znaky ze vstupního souboru a do výstupního pak zapisuje jim příslušné
sekvence bitů.
Dekomprese sice vyžaduje znalost původního binárního stromu, ale je také velice jednoduchá. Pokud jsou kódy ve zkomprimované podobě souboru uloženy bezprostředně za sebou,
bude již dekomprimační algoritmus schopen rozpoznat znak příslušející ke kódu. Algoritmus bude prostě číst kód (o kterém ještě není známo, jak je dlouhý) bit po bitu a podle hodnoty bitu bude postupovat po binárním stromě od kořene až k „listu“ stromu představujícímu znak. Tento znak je již původním znakem, který byl při komprimaci zakódován.
Slabinou tohoto algoritmu je mimo jiné i to, že binární strom lze bez problémů sestavit
pouze v případě, že pravděpodobnosti výskytu všech znaků vstupního souboru jsou mocninou čísla 1/2. Pouze v tom případě každé vyšší patro vytvářeného stromu obsahuje uzel nebo list stromu s pravděpodobností výskytu dvojnásobnou oproti listům či uzlům ležícím
o patro níž. Je zřejmé, že ideálního kompresního poměru může být dosaženo pouze při dodržení této zásady. V praxi však s něčím takovým nelze počítat vlastně nikdy, a proto je zapotřebí zaokrouhlovat pravděpodobnosti výskytu jednotlivých znaků.
Zokrouhlování ovšem musí být prováděno při dodržení dvou základních zásad:
■
součet všech procentuálních hodnot musí samozřejmě dávat hodnotu 100 %;
■
zároveň je nutné dbát na to, že v každém patře vytvářeného stromu může být maximálně určitý počet listů a uzlů. Tento počet je dále omezen již vytvořenými patry stromu.
Složitosti vznikající při dodržování poslední zásady lze demonstrovat na následujícím příkladu. Předpokládejme, že máme opět stejný soubor znaků jako v předcházejícím případě,
tentokrát ovšem s jinou pravděpodobnostní distribucí:
znak A se v souboru vyskytuje s pravděpodobností 46 %,
znak 8 se v souboru vyskytuje s pravděpodobností 22 %,
41
znak 0 se v souboru vyskytuje s pravděpodobností 5 %,
znak K se v souboru vyskytuje s pravděpodobností 5 %,
znak R se v souboru vyskytuje s pravděpodobností 22 %.
Při vytváření binárního stromu podle zásad Huffmanova algoritmu nalezneme nejprve dva
znaky s nejnižší pravděpodobností (0 a K). Jejich pravděpodobnosti zaokrouhlíme na
6,25 %, což je mocnina 1/2.
Následují znaky 8 a R se stejnou pravděpodobností. Zaokrouhlení obou příslušných pravděpodobností na 25 % je nepřípustné, protože na jediný zbývající znak by zbyla pravděpodobnost 37,5 % – ta je ovšem v binárním stromě nepřípustná. Je tedy nutné pravděpodobnost
jednoho z těchto znaků zaokrouhlit na 12,5 % a pravděpodobnost druhého zaokrouhlit na
25 %. To znamená, že ačkoli oba znaky se ve vstupním souboru vyskytují se stejnou pravděpodobností, jeden z nich bude v komprimované formě reprezentován třemi bity a druhý
dvěma bity.
Tento jednoduchý příklad nedemonstruje všechny problémy spojené s tvorbou binárního
stromu, ale nastiňuje příčinu, proč se do kompresního schématu zavádějí nežádoucí nepřesnosti, které zhoršují výsledný kompresní poměr. Zároveň se algoritmus tvorby binárního
stromu se stává složitější.
Shannon-Fanovo kódování
Shannon-Fanovo kódování je velice podobné Huffmanovu. Rozdíl mezi oběma algoritmy
spočívá v konstrukci binárního stromu. Tvorba binárního stromu v Shannon-Fanově modifikaci je poněkud jednodušší. Lze ji shrnout do dvou následujících kroků:
■
Rozděl soubor symbolů na dvě skupiny se stejnou nebo co nejpodobnější celkovou
pravděpodobností znaků obsažených v obou skupinách. Pokud se vrátíme k druhému
příkladu z předcházejícího odstavce, obsahovala by po takovém rozdělení znaků jedna
skupina pouze znak A (46 %) a druhá skupina znaky 8, 0, K a R (celkem 54 %). První skupině se přiřadí binární symbol nuly a druhé skupině binární jednička.
■
Opakuj první krok na všechny dosud vytvořené skupiny, dokud každá skupina nebude
obsahovat jediný znak.
Rozdíl mezi způsoby vytváření binárních stromů v Huffmanově a Shannon-Fanově variantě
je v tom, že Huffmanovo kódování vytváří strom od koncových listů směrem ke kořenu, zatímco Shannon-Fanova metoda postupuje obráceně – od kořene k listům.
42
Zatímco Huffmanova varianta při správném použití generuje vždy optimální kódy pro jednotlivé znaky, jednodušší Shannon-Fanova metoda může v některých případech použít v některých kódech pár bitů navíc.
Tip:
Všimněte si, jakým způsobem vytvoří Shannon-Fanova varianta binární strom pro druhý
příklad z předcházejícího odstavce (viz obr. 3). Kód příslušející ke znaku A bude reprezentován jediným bitem, zatímco všem ostatním znakům bude přiřazen kód tříbitový. Zcela se tak smaže rozdíl mezi pravděpodobností výskytu znaku 5 % a 22 %.
Obr. 3:
Příklad binárního stromu vytvořeného Shannon-Fanovou metodou
Jak bylo vysvětleno výše, Huffmanovo kódování dosahovalo optimálních výsledků pouze
v případě, kdy pravděpodobnosti jednotlivých znaků byly celočíselnými mocninami 1/2.
V ostatních případech by bylo optimální na zakódování jednoho znaku použít neceločíselný
počet bitů, což však samozřejmě binární soustava neumožňuje.
Aritmetické kódování tento nedostatek odstraňuje velice zajímavým způsobem – kóduje celou zprávu jako jediné kódové slovo.
Základní myšlenku použitou v této komprimační metodě lze popsat ve stručnosti takto: aritmetické kódování reprezentuje celou zprávu jako číslo z intervalu <0,1). Na začátku kódování uvažujeme celý tento interval. Jak se zpráva prodlužuje, zužujeme postupně interval
– přibližují se k sobě i horní a dolní mez nově vytvářeného intervalu. Na konec stačí zapsat
libovolné číslo z výsledného intervalu – to samo o sobě reprezentuje celou zprávu.
Algoritmus komprese lze nastínit jako následující sekvenci kroků:
43
■
Zjištění pravděpodobností výskytu jednotlivých znaků ve zdrojovém souboru.
■
Rozdělení intervalu <0,1) na podintervaly, jejichž vzájemný poměr velikostí odpovídá
poměru pravděpodobností jednotlivých znaků (seřazených podle abecedy).
■
Uložení tohoto základního rozdělení intervalu <0,1).
■
Vlastní komprese víceznakové zprávy.
Komprese víceznakové zprávy bude probíhat tak, že se nejprve vybere první znak
vstupního souboru. Ten zúží interval <0,1) na podinterval příslušející tomuto znaku
tak, jak mu byl přidělen v druhém bodě celkového algoritmu aritmetického kódování.
Tento podinterval bude rozdělen stejným způsobem jako dříve celý interval <0,1). Po
načtení dalšího znaku bude podinterval dále zúžen podle načteného znaku. Tak to půjde dále až do načtení posledního znaku zprávy.
■
Posledním bodem je vybrání kteréhokoli zlomku náležejícího do výsledného nejjemnějšího podintervalu a jeho převedení do binární formy.
Tip:
Čím je kódovaný znak pravděpodobnější, tím se interval zúží méně.
Nejjednodušeji lze tento algoritmus pochopit na příkladu.
Naším úkolem bude za pomoci aritmetického kódování zakódovat tříbajtovou zprávu obsahující znaky „XXY“.
V souladu s prvním bodem algoritmu aritmetického kódování zjistíme, že zpráva obsahuje
pouze dva znaky:
pravděpodobnost výskytu znaku X je 2/3,
pravděpodobnost výskytu znaku Y je 1/3.
V dalším kroku rozdělíme v tomto poměru (v poměru 2:1) interval <0, 1) a rozdělení si zapamatujeme. Nyní již přistoupíme ke kódování vstupního souboru.
Načteme první znak souboru, kterým je písmeno X a zjemníme původní interval na podinterval <0, 2/3). Tento interval opět rozdělíme v poměru 2:1. Dělícím bodem bude v tomto
případě bod 4/9. Načteme další znak – je jím opět písmeno X, které nám podinterval opět
zúží na <0, 4/9). Tento interval opět rozdělíme v poměru 2:1 – dělícím bodem je v tomto
44
případě zlomek 8/27. Následujícím znakem zprávy je písmeno Y, jež opět zúží interval,
o který se budeme zajímat, na <8/27, 4/9). Vzhledem k tomu, že třetí znak je v našem
vstupním souboru také znakem konečným, je konečný i tento interval. Zbývá již jen vybrat
libovolnou hodnotu z tohoto intervalu, která převedena do binární formy bude reprezentovat
celou vstupní sekvenci. Vyberme (z důvodů, které uvedeme později) číslo 3/8.
Tip:
Pro potřeby dekomprimace zakódované zprávy je nezbytné předat dekomprimační části
algoritmu (kromě kódové hodnoty) také poměry pravděpodobností jednotlivých znaků
a počet znaků původní zprávy.
Tip:
Na obr. 4 jsou zachyceny všechny možnosti kódování tříbajtové zprávy sestávající ze znaků X a Y, jejichž poměr pravděpodobností výskytu je 2:1.
Obr. 4
Diagram všech možností kódování tříbajtové zprávy sestávající ze znaků X a Y, jejichž poměr pravděpodobností výskytu je
2:1.
45
Dekomprese zakódované zprávy do původního tvaru je prostá. Načteme rozdělení intervalu
<0, 1) na podintervaly podle poměru pravděpodobností výskytu jednotlivých znaků a počet
znaků původní zprávy. Dále budeme postupovat podle následujícího velice jednoduchého
návodu:
■
vybereme podinterval <K(i), K(i+1)) intervalu <0, 1) tak, aby kód náležel do tohoto
intervalu;
■
na výstup zapíšeme znak náležející svou pravděpodobností do tohoto intervalu
read(kód)
while (není obnovena celá zpráva)
{
kód =(kód -K(i))/P(znak)
}
P(znak) reprezentuje pravděpodobnost výskytu příslušného znaku.
Pokud se vrátíme k našemu příkladu, bude dekomprimace vypadat následovně:
Načteme kód 3/8, který reprezentuje vstupní posloupnost znaků. Tento zlomek náleží do intervalu <0, 2/3), který odpovídá znaku X. Zapíšeme tento znak na výstup. Nová hodnota
kódu bude
(3/8 - 0) / (2/3) = 4/9
Zlomek 4/9 náleží opět do podintervalu <0, 2/3). Jako druhý znak zapíšeme na výstup opět
X. Úprava kódu bude nyní následující:
(4/9 - 0) / (2/3) = 2/3
Zlomek 2/3 náleží do podintervalu <2/3, 1). Tento interval odpovídá znaku Y, který je tudíž
třetím znakem původní zprávy. Víme, že originální sekvence se skládala právě ze tří znaků,
a proto dekomprimaci ukončíme.
Tip:
Zde vidíte důležitost faktu, který zatím nebyl příliš zdůrazněn: všechny intervaly, se kterými
při aritmetickém kódování pracujeme, jsou polouzavřené zleva.
46
Tím jste se seznámili se základní myšlenkou komprimace obecně známé pod pojmem aritmetic coding (aritmetické kódování). Při převádění této chytré a jednoduché myšlenky do
počítačové praxe se však setkáváme s celou řadou problémů – nejzávažnější je asi potřeba
konverze reálných čísel na bitové vyjádření. Výsledný kód reprezentující vstupní posloupnost je zapotřebí převést do formy vyjádřitelné ve dvojkové reprezentaci. Navíc s každým reálným číslem rozdělujícím základní interval <0, 1) je nezbytné pracovat s vyloučením jakéhokoli zaokrouhlování.
Při vyjádření výsledného zlomku v bitovém vyjádření je důležitý fakt, že jmenovatel musí
být mocninou čísla 2. Jedině tak je možné jednoznačně stanovit délku výsledného bitového
vyjádření celého zlomku. Počet bitů bitového vyjádření je takový, aby pomocí nich bylo
možné vyjádřit všechny hodnoty v intervalu <0, jmenovatel-1>. Nyní tedy několik jednoduchých příkladů, jak se zlomky konvertují na svá bitová vyjádření (nejnižší bit je uveden
vpravo):
Zlomek
Bitové vyjádření
1/2
1
1/4
01
3/4
11
3/4
11
5/8
101
31/32
11111
Tip:
Takto zkonstruovaná racionální čísla mohou náležet pouze intervalu <0, 1).
Velkým problémem je u popsaného komprimačního algoritmu rychlý růst počtu platných
desetinných míst v racionálních číslech, která představují dolní a horní meze intervalů. Ve
většině případů již u souborů o deseti znacích roste počet platných cifer těchto dělících bodů na dvacet až třicet číslic. Z toho je zřejmé, že celé soubory o velikosti mnoha megabajtů
nelze kódovat jediným číslem, neboť počet platných míst u čísel v mezivýpočtech by rostl
prakticky neomezeně.
47
Je tedy nutné rozdělit každý soubor na jednotlivé bloky a ty komprimovat samostatně. Bohužel se ukazuje (viz minulé řádky), že tyto bloky většinou nemohou přesahovat 10 bajtů.
S každým blokem o deseti bajtech, který se ukládá, je spojeno několik desítek matematických operací s racionálními čísly o desetinném rozvoji jdoucím do dvaceti až třiceti platných číslic.
Tyto operace musí být navíc emulované softwarově, jelikož problém si nelze ulehčit ani pomocí matematického koprocesoru, neboť ten podporuje reálná čísla vyjádřená pouze
v 6 bajtech. To je pro aritmetické kódování nedostačující. Softwarová emulace způsobuje
poměrně dlouhou dobu zpracování. I přes rychle se rozvíjející hardwarové možnosti nelze
přehlédnout vysokou náročnost komprimačního algoritmu na zdroje počítače – především
na paměť a taktování procesoru.
Dalším problémem tohoto druhu komprimace je např. složitost způsobu zjišťování, jak dlouhé bude výsledné bitové vyjádření kódu reprezentujícího vstupní posloupnost znaků.
Ani tím však problémy s praktickou realizací algoritmu nekončí. Jako obtížný se jeví již
první krok celého algoritmu – zjištění pravděpodobnosti výskytu jednotlivých znaků. To lze
samozřejmě řešit sekvenčním načtením celého souboru a prostým výpočtem pravděpodobností z absolutního počtu jednotlivých výskytů. U rozsáhlých souborů však dojde k nepříjemnému prodloužení doby komprimace, do které je nutné čas na zjištění pravděpodobností
výskytů započítat. U dlouhých souborů je doba komprimace limitním faktorem již bez tohoto zdržení.
Pokud se bude algoritmus aritmetického kódování aplikovat na textové soubory, je možné použít statických tabulek frekvencí jednotlivých znaků v různých jazycích. Tyto údaje jsou tabelovány již několik desetiletí (viz obr. 5). To je však pohříchu ten nejméně vhodný způsob.
písmeno
A
Á
B
C
Č
D
Ď
E
É
Ě
pravděpodobnost
0.054
0.021
0.014
0.019
0.008
0.026
0.005
0.073
0.010
0.007
písmeno
F
G
H
I
Í
J
K
L
M
N
pravděpodobnost
0.002
0.002
0.020
0.034
0.025
0.022
0.033
0.034
0.029
0.040
Obr. 5
Pravděpodobnosti výskytu jednotlivých písmen v českém textu.
48
písmeno
Ň
O
Ó
P
Q
R
Ř
S
Š
T
pravděpodobnost
0.015
0.068
0.000
0.027
0.000
0.029
0.009
0.040
0.008
0.039
písmeno
Ť
U
Ú, Ů
V
W
X
Y
Z
Ž
mezera
pravděpodobnost
0.007
0.030
0.005
0.039
0.000
0.001
0.016
0.019
0.009
0.163
Jako příznivější se jeví tvorba adaptivního slovníku, kdy původní fixní tabulka pravděpodobností je upravována po každém jednotlivém výskytu kteréhokoli znaku v průběhu kódování. I tento model však pracuje pouze s pravděpodobností výskytu jednotlivých znaků
a nebere v úvahu pravděpodobnosti posloupností znaků.
Tip:
Kromě tabelace pravděpodobností výskytů jednotlivých znaků jsou dnes k dispozici také
pravděpodobnosti výskytu jednotlivých dvojic, resp. trojic znaků v různých jazycích.
Nejúčinnější metodou se dnes jeví způsob zjišťování frekvence znaků založený na markovovském zdroji dat – DMC (Dynamic Markov Coding). Má-li vstupní soubor N různých
znaků, je tento typ zdroje daný tzv. počátečním vektorem pravděpodobností:
(p(0), p(1), ..., p(N-1))
a maticí přechodových pravděpodobností:
 p(0,0) ... p(0,N-1) 


.
.


.
.


.
.


 p(N-1,0)...p(N-1,N-1) 


Obr. 6
Vektor počátečních pravděpodobností a matice přechodových pravděpodobností spolu souvisí vztahem:
p(y)= Σ p(x,y).p(x)
N-1
x=0
Obr. 7
Pravděpodobnost p(y, x) označuje pravděpodobnost, že v daném souboru se po znaku x vyskytuje znak y. Pravděpodobnost
p(x) odpovídá pravděpodobnosti, že prvním znakem sekvence bude znak x.
Matice přechodových pravděpodobností se upravuje a doplňuje v průběhu komprimace podle výskytů jednotlivých znaků ve vstupním souboru.
49
Tip:
Jasnou výhodou tohoto přístupu je fakt, že na rozdíl od statických tabulek znaků se jedná
o adaptivní variantu algoritmu, kterou lze použít i na netextová data.
Shrnutí
Huffmanovo kódování, Shannon-Fanovo kódování a nejnovější varianta aritmetické kódování tvoří rodinu příbuzných komprimačních algoritmů založených na
využití pravděpodobností výskytu jednotlivých znaků nebo jejich posloupností
v komprimovaných datech. Žádná z těchto metod se příliš nepoužívá samostatně,
ale dosahuje velmi dobrých výsledků v kombinaci s některou slovníkovou metodou (LZ77, LZ78 nebo LZW). Samostatně má toto kódování praktický význam
především při použití na textových souborech.
Aritmetické kódování svým principem obchází nevýhodu Huffmanova a Shannon-Fanova kódování, která jsou nejefektivnější pouze při hodnotách pravděpodobností výskytů jednotlivých znaků, které jsou celočíselnou mocninou čísla 1/2.
Výhody:
■ Velmi dobré kompresní poměry ve spojení se slovníkovou metodou.
■
Poměrně jednoduchý algoritmus dekomprimace.
Nevýhody:
Huffmanovo a Shannon-Fanovo kódování je nejefektivnější při hodnotách
pravděpodobnosti výskytů, jež jsou celočíselnou mocninou čísla 1/2.
■
50
■
Aritmetické kódování má vysoké nároky na technické vybavení počítače.
■
U aritmetického kódování je nutná softwarová manipulace s čísly o desetinném rozvoji na 20–30 desetinných míst, přičemž je nutné vyvarovat se jakéhokoli zaokrouhlování – relativně dlouhá doba komprese.
4
Ztrátová
komprimace
Ztrátová komprimace
Ve výkladu komprimačních algoritmů a komprimačních technik se dostáváme od bezztrátové komprimace ke komprimaci ztrátové. Připomeňme si, že veškeré v této knize dosud popsané kompresní techniky jsou bezztrátové. To znamená, že při kompresi dat nedochází
k žádným ztrátám informací obsažených v původních souborech dat a po inverzním procesu – dekompresi – jsou data zcela identická s původním souborem. Taková vlastnost kompresních schémat je zcela nezbytná při komprimaci binárních nebo textových dat.
Ačkoli se bezztrátová kompese využívá i pro komprimaci obrazových dat (vzpomeňte si na
popis a použití komprimačních algoritmů RLE a LZW), byla pro tuto oblast komprimace
vyvinuta nová, tzv. ztrátová kompresní schémata.
Ztrátové komprimační algoritmy kódují data způsobem, který nejen že nezaručuje stoprocentní obnovu dat po dekomprimaci, ale dokonce schválně některé informace při kompresi
ztrácí. Je zřejmé, že taková kompresní schémata lze použít pouze tam, kde existuje určitá
redundance (přeurčení, nadbytečnost) vstupních dat a kde ztrátou některých původních informací datový soubor neutrpí žádnou újmu. Takovými daty mohou být statické obrázky,
zvuková data, data uchovávající videosekvence atp.
Výše uvedená data jsou redundantní ve vztahu k nedokonalosti lidských smyslů, kterými tato data vnímáme. U obrázků existují detaily, které lidské oko prakticky nemůže postihnout
– především malé změny barev sousedních bodů. Stejně tak ve zvukových a videosekvenčích datových souborech je možné nalézt redundanci založenou na podobném principu.
JPEG
Jednou z nejpokrokovějších metod ve ztrátové kompresi redundantních grafických předloh
je JPEG. Tato zkratka znamená Joint Photographic Experts Group – komise pro standardy
pracující pod International Standard Organization (ISO).
Na rozdíl od ostatních kompresních schémat popsaných dosud v této knize není JPEG samotným, přesně definovaným algoritmem. Jedná se spíše o sadu kompresních metod, které
mohou být přizpůsobeny konkrétním požadavkům uživatele. Z toho je zřejmé, že JPEG
není ani přesně definovaným grafickým formátem.
53
Tip:
Pokud bude v dalším textu knihy použit výraz „formát JPEG“, bude se vždy jednat
o obecných vlastnostech množství konkrétních mutací založených na ztrátovém kompresním schématu JPEG.
Tip:
Pro kompresi videosekvencí existuje standard MPEG, příbuzný schématu JPEG používanému pro statické obrazové předlohy.
JPEG byl navržen pro práci s barevnými předlohami i s předlohami obsahujícími pouze
různé stupně šedé. JPEG je velice vhodný pro kompresi fotografií s velkou barevnou hloubkou. Horších výsledků dosahuje při práci s vektorovými obrázky a jednoduchou grafikou.
Celá komprimační technologie je založena na faktu, že lidské oko dokáže hůře rozeznat
malé změny barev blízkých bodů než rozdíly v intenzitě a jasu. Z toho důvodu je také tento
standard vhodnější pro barevné obrázky než pro černobílé předlohy skládající se pouze
z mnoha odstínů šedé.
Nezanedbatelnou výhodou při komprimaci grafických předloh metodou JPEG je možnost
volby tzv. Q faktoru. Q faktorem rozumíme nastavení kvality obrázku po kompresi. Hodnoty Q faktoru se běžně pohybují v rozsahu od 1 do 100. Menší hodnota Q faktoru znamená
menší velikost výsledného souboru zkomprimovaných dat (lepší kompresní poměr), ale zároveň (díky ztrátovosti metody JPEG) také horší kvalitu obrázku. Výsledkem použití komprese JPEG by mělo být nalezení takové hodnoty Q faktoru, který by zaručoval největší
kompresní poměr při současném zachování požadované kvality obrázku.
Jakých výsledků tedy lze dosáhnout ztrátovou kompresí typu JPEG?
Kompresní schéma JPEG díky své ztrátovosti redundantních dat dosahuje vysokých kompresních poměrů, které nejsou možné u „klasických“ neztrátových komprimačních algoritmů. Celá komprimační technologie JPEG je založena na faktu, že lidské oko dokáže hůře
rozeznat malé změny barev blízkých bodů než rozdíly v intenzitě a jasu. Kompresní standard JPEG je tedy vhodný pro kompresi složitých barevných grafických předloh (fotografií)
s velkou barevnou hloubkou – typicky 24 bitů na pixel (tj. 16 miliónů barev). Kompresní
54
poměr běžně dosahuje u takových grafických předloh hodnot 20:1 bez vizuální újmy na
kvalitě obrázku. Kompresní poměry od 30:1 mají obvykle velice ubohou kvalitu a jsou
vhodné nanejvýš jako náhledy obrázků z knihovny apod.
Tip:
Posouzení, zda je předložený obrázek v dobré kvalitě, samozřejmě záleží na rozlišení nastaveném na monitoru. Při větším rozlišení bude menší velikost jednotlivých pixelů a případné nedokonalosti obrázku budou obtížněji zjistitelné.
Je třeba zdůraznit, že uvedený kompresní poměr se opravdu týká digitálních fotografií a vůbec obrázků s velice rozmanitou skladbou, a to jak barevnou, tak i co do drobných detailů.
Poněkud horších výsledků dosahuje JPEG při aplikaci na černobílé fotografie, kde lze rozlišit pouze různé odstíny šedi. Vzhledem k tomu, že oko je na změnu intenzity a jasu citlivější než na malou změnu barvy, není jiný přístup ke ztrátové komprimaci ani možný.
Jako nevhodný se jeví formát JPEG pro jednoduché vektorové obrázky, kde se střídá pouze
několik málo barev s jednobarevným pozadím – takové obrázky lze vytvořit např. v programu Malování ve Windows. Pro tento typ dat není JPEG vůbec navržen, a proto zde také dosahuje nejhorších výsledků.
Tip:
Kromě špatného kompresního poměru zanechává JPEG na jednobarevném pozadí viditelné artefakty, které dále degradují obrázek.
Pro jednoduché kresby s malou barevnou hloubkou a velkými jednobarevnými plochami je
mnohem výhodnější použít některý z grafických formátů, které využívají jednoduché bezztrátové metody komprese (viz část o bezztrátové kompresi). Většina těchto grafických formátů pracuje pouze s barevnou hloubkou 8 bitů na pixel (256 barev), což zcela postačí. Navíc bezztrátové algoritmy jsou na podobném typu dat grafické předlohy velice úspěšné.
JPEG by neměl být nikdy použit na černobílé kresby, kde barevná hloubka je pouhý jediný
bit na pixel. Takové kresby nemají žádnou z grafických vlastností, které jsou podmínkou
úspěšné komprese. JPEG vyžaduje alespoň 16 odstínů šedé (4 bity na pixel). Poznamenejme však, že např. GIF je bezztrátový až do 256 odstínů šedé, zatímco JPEG nikoli.
55
Naopak barevná fotografie exportovaná např. do formátu GIF tedy nejprve ztratí většinu své
barevné hloubky, přičemž se dosáhne kompresního poměru 3:1. Grafický formát GIF dále
používá bezztrátovou kompresní metodu Lempel-Ziv-Welsh (LZW), která zvýší kompresní
poměr v průměru na konečnou hodnotu 5:1. Ve srovnání s kompresním poměrem 20:1
u metody JPEG je to velice málo uspokojivý výsledek, dosažený navíc za cenu ztráty většiny barevné informace.
Tip:
Při uvedení pojmu „ztrátová komprese“ mají lidé k metodám pracujícím na tomto principu nedůvěru – především co se týká „bezpečnosti“ celého komprimačního procesu. Výše
uvedený příklad však odhaluje, že ztrátový kompresní algoritmus často ztrácí méně informací než „bezztrátový“ grafický formát.
Na druhou stranu je třeba uvést, že při opakované kompresi a dekompresi grafické předlohy do formátu JPEG dochází k částečné akumulaci „ztrátovosti“ a kvalita obrázku tím
dále degraduje. (To u formátů používajících bezztrátovou kompresi samozřejmě nenastává.) Pokud tedy potřebujete v obrázku komprimovaném metodou JPEG provést nějaké
úpravy, vyexportujte jej do formátu JPEG se zcela identickým Q faktorem, s jakým byl
obrázek uložen dříve. Riziko degradace obrázku (zvláště při opakovaných úpravách) bude
sníženo na minimum.
Různé druhy obrázků JPEG
JPEG základní a progresivní
Jak jsme již naznačili v úvodu, JPEG není ani klasickým grafickým formátem, ani přesně
daným kompresním algoritmem pro komprimaci grafických dat. Nyní si rozšiřme chápání
termínu JPEG o další pojem – progresivní JPEG. Základní verze kompresního schématu
JPEG funguje tak, že celý obrázek je dekomprimovám z formátu JPEG během jediného
skenu od horního k dolnímu okraji obrázku.
Progresivní JPEG je určen speciálně pro publikování na stránkách WWW. Při použití progresivního JPEGu se celý obrázek zobrazuje v několika po sobě následujících skenovacích
přebězích, během nichž se zlepšuje kvalita obrázku. Po prvním skenu se zobrazí pouze hru-
56
bé kontury obrázku atd. Kvalita obrázku se tak progresivně zlepšuje. Výhodou tohoto přístupu je fakt, že k prvnímu náhledu na celý obrázek postačí zpracování malého zlomku celkových dat kódujících původní grafickou předlohu.
Progresivní JPEG je ohromnou výhodou při používání pomalého dial-up (po telefonní lince) připojení k serveru WWW. Již po přenesení malého množství dat uživatel vidí základní
kontury celého obrázku. Při použití tzv. základního JPEGu musí uživatel počkat na přenesení celého obrázku, aby zjistil, co grafická data zobrazují.
Určitou nevýhodou tohoto druhu kódování je fakt, že při každém jednotlivém skenovacím
přeběhu musí počítač provést prakticky stejné množství matematických operací jako při jediném přeběhu „základního“ JPEGu. Při dnešních výkonech počítačů je však limitujícím
faktorem právě přenosová rychlost modemů. Pokud se data na vstupu dekodéru objevují
dostatečně rychle, lze dekodér upravit tak, že přeskakuje některé zobrazovací přeběhy. To
znamená, že ani majitelé rychlých připojení k Internetu nebudou trpět větší matematickou
náročností při dekódování předlohy.
Transparentní JPEG je problém
Pokud hodláte vytvořit transparentní (s prosvítajícím pozadím) obrázek, vězte, že nepochodíte. Implantace této vlastnosti do komprimačního schématu JPEG je natolik složitá, že se
s ní zatím nepočítá ani do budoucna.
Důvodem je systém, jakým se transparentnosti obvykle dosahuje. Ostatní grafické formáty
vyčleňují jednu určitou barvu pro identifikaci pixelů, které mají být transparentní. Tato barva pak není v obrázcích použita (při barevné hloubce minimálně 256 barev to není zas až
tak velká ztráta). Vzhledem ke ztrátovosti formátu JPEG podobný přístup není možný. Ztrátové komprimační schéma totiž při komprimaci často průměruje barvu blízko ležících bodů,
a tak by vyčlenění jediné barvy pro identifikaci transparentních pixelů vedlo k velice špatným výsledkům co do kvality obrázku (resp. co do kvality zobrazovaného pozadí). Tento
problém lze částečně řešit použitím určitého intervalu barev jako identifikátoru transparentních pixelů. „Průhlednost“ pozadí by potom byla procentuálně odstupňovaná.
I v tomto případě by se vyskytla řada problémů. Kvalita zobrazení prosvítajícího pozadí by
se sice zlepšila, ale stále by byly patrné drobné chyby v zobrazení. Použití takového přístupu ke grafickým datům by také vedlo k podstatnému zvětšení nároků na diskovou paměť.
Transparentní obrázky JPEG by byly často dvakrát i vícekrát větší než stejné předlohy komprimované do standardní netransparentní podoby. Navíc je třeba si uvědomit, že obrázky,
u kterých se vyplatí vytvářet transparentní formu, jsou přesně ty, na které ztrátové komprimační schéma funguje nejhůře – velké jednobarevné plochy se skokovými změnami barev.
57
Z tohoto pohledu se jeví jediným možným řešením použití nějakého neztrátového algoritmu
pro uchování masky transparentního obrázku. Vývoj, standardizace a popularizace takového
formátu by však stála mnoho úsilí, které si podle expertů sdružených do Joint Photographic
Experts Group transparentní obrázky nezaslouží.
Bezztrátový JPEG?
Téma bezztrátového kompresního schématu JPEG není příliš rozšířené ani populární, ale
„patří do rodiny“ a lidé se na toto ztracené dítě občas ptají.
Tip:
Je snad na místě znovu zdůraznit, že termín „bezztrátový“ znamená, že předloha bude po
dekompresi bit po bitu shodná s původně komprimovanými daty. Tento požadavek je mnohem silnější než vizuální nerozlišitelnost obrázků před komprimací a po dekomprimaci.
Hned v úvodu je nutné zdůraznit, že JPEG, tak jak byl a bude popisován v předcházejících
a následujících kapitolách, nikdy nemůže být bezztrátový. To nezáleží na použitém Q faktoru
– již samotný princip komprese je ztrátový a tuto vlastnost nelze žádným způsobem obejít.
Na druhou stranu Joint Photographic Experts Group se zabývala i vývojem standardu, jenž
se nazýval JPEG-LS, který opravdu bezztrátový je. Tento kompresní standard pracuje dobře
s grafickými předlohami spojitě tónovaných obrázků. Není určen pro obrázky s malou barevnou hloubkou a samozřejmě trpí ve srovnání s klasickým schématem „JPEG“ mnohonásobně nižšími kompresními poměry při použití na stejná data.
Vzhledem k velice malému použití tohoto kompresního schématu Joint Photographic
Experts Group již před časem zastavila veškeré vývojové práce na bezztrátové verzi JPEG.
58
Grafický formát jako standard
Tip:
Jak již bylo uvedeno, označení JPEG není ani přesným kompresním algoritmem ani konkrétním grafickým formátem. Z tohoto důvodu bylo nezbytné standardizovat některý formát založený na ztrátové kompresi. Tímto standardem se stal JFIF (JPEG File Interchange Format). Tento formát byl upraven speciálně pro potřeby Internetu a obecně se o něm
mluví jako o „formátu JPEG“.
Většina prohlížečů formátu JFIF je schopna číst i některé ne zcela standardní formáty založené na JPEG. Přesto se mohou vyskytnout formáty nestandardní, které váš prohlížeč nebude schopen otevřít. Co dělat v takových chvílích? Uveďme si nyní několik základních charakteristik a rad týkajících se formátu JPEG.
Standardní soubor JFIF začíná čtveřicí bajtů – hexadecimálně FF D8 FF E0, následují dva
bajty, jejichž hodnota se liší soubor od souboru (většinou jsou to ale hexadecimální hodnoty
00 a 10), dalšími čtyřmi znaky je řetězec ‘JFIF’. Tyto sekvence znaků jsou tedy identifikátorem standardu pojmenovaného jako JFIF.
Některé nejstarší a znovu i nejnovější obrázky formátu JFIF sice používají počáteční čtyřbajtovou sekvenci, ale vynechávají řetězec ‘JFIF’.
Většina prohlížečů by s touto disproporcí neměla mít žádný problém, ovšem pokud se problémy vyskytnou, bude nejlépe změnit prohlížecí software.
Trochu odlišným případem je formát používaný pro počítače Macintosh – zde je standardem založeným na kompesi JPEG grafický formát PICT. Tento formát začíná několikaset
bajtovou hlavičkou (většinou se jedná o 726 bajtů), za níž následují JPEG data. Tento formát většina prohlížečů běžících na PC nepodporuje. Pokud si takový obrázek chcete prohlédnout, musíte jej upravit do podoby, která byla popsána v souvislosti s formátem JFIF.
Hledejte proto v hlavičce souboru sekvenci bajtů FF D8 FF hexadecimálně. Obyčejně lze
krátce před touto posloupností v hlavičce souboru nalézt text ‘Photo - JPEG’. Nedaleko za
uvedenou trojicí bajtů bývá značka ‘AppleMark’ nebo ‘JFIF’. Ořežte vše před trojicí bajtů
FF D8 FF a problém s konverzí je pravděpodobně vyřešen.
59
Tip:
Uvedený postup „konverze“ formátu PICT na JFIF nebude fungovat, pokud je obrázek
PICT vnitřně rozdělen na pásy, které dohromady teprve dávají celou výšku obrázku. Takové obrázky obsahují více bloků JPEG, které musí být postupně slepeny do jediného
bloku představujícího jediný datový tok. Naštěstí tento druh souboru PICT není příliš
rozšířen.
Pokud grafický soubor pochází z počítače Macintosh, může se také jednat o standard JFIF
se 128bajtovou hlavičkou připojenou před samotný „standardní“ JFIF. V tom případě stačí
oříznout prvních 128 bajtů a problém je vyřešen.
Budete-li s obrázky založenými na technice JPEG pracovat často, dříve nebo později se
pravděpodobně setkáte s případem, na který nebude fungovat žádný z výše uvedených postupů. V tom případě nezbývá než hledat v hlavičce souboru identifikátor souboru
JFIF (může to být pouze dvojice bajtů FF D8 hexadecimálně), oříznout začátek souboru až
po tuto dvojici a doufat, že to pomůže…
Tip:
Pokud vytváříte grafické soubory JPEG pro prezentaci na webu, ujistěte se, že obrázek
vytváříte z barevné předlohy RGB nebo módu různých stupňů šedé. Některé grafické programy orientované na předběžný tisk – prepress – (např. Adobe Photoshop) vytvářejí
JPEG jako čtyřkanálový CMYK JPEG, pokud je export realizován ze zobrazovacího módu CMYK. S takovými obrázky bude umět manipulovat opět pouze podobně orientovaný
software a nehodí se tak pro použití na webové stránce.
Tip:
Photoshop má zvyk připojit k vytvářenému obrázku JPEG také jeho náhled (preview).
Pokud vytváříte obrázek pro web, není náhled nijak využit a tato data naopak zbytečně
prodlužují dobu potřebnou k přenesení obrázku po datové lince. Navíc některé aplikace
tento náhled neumějí interpretovat a ohlásí chybu při čtení souboru. Pokud používáte pro
vytváření obrázku JPEG Photoshop (nebo jiný software s možností vytváření náhledů),
použijte volbu nepřipojující náhled.
60
Kompresní algoritmus JPEG
Komprimační schéma JPEG se skládá z následujících částí:
■
Transformace barev
Snímky (pokud používají jiný barevný model, např. RGB) se převedou do barevného
modelu YUV (nebo YCbCr atd.), kde je samostatně uchována jasová (Y) a dvě barvonosné složky (U a V). Tento mód je pro další zpracování daleko vhodnější než obvykle v počítači užívaný mód RGB. Důvodem je již výše zmíněná vlastnost lidského oka
lépe rozeznávat změny v intenzitě (jasu) a nikoli v malé změně barvy.
■
Redukce barev
Pro zmenšení objemu obrazových dat se používá tzv. podvzorkování barev. Jasové
složky obrazu se zachovávají všechny beze změny, ale barevné složky jsou redukovány v poměru 2:1 v horizontálním a 2:1 nebo 1:1 (beze změny) ve vertikálním směru.
Snížení počtu barev je prováděno průměrováním na menší počet hodnot. Podvzorkování barev je vhodné především u složitých barevných předloh, jak bylo vysvětleno
dříve.
Další transformace se již provádějí odděleně a nezávisle pro jasovou i obě barevné
složky.
■
Diskrétní kosinová transformace
Obraz se rozdělí do čtvercových oblastí 8x8 bodů a na každou takovou oblast se aplikuje diskrétní kosinová transformace. Tato transformace v podstatě převede amplitudovou informaci na informaci frekvenční, u které lze jednoduše rozlišit, které části informace jsou pro danou oblast obrazu dominantní (nižší frekvence), a které části popisují pouze jemné detaily (vyšší frekvence). Získáme tak opět matice 8x8. Na rozdíl od
původních matic, kde byla obrazová informace rozložena rovnoměrně (pro každý pixel jsme znali jeho barevnou hodnotu), po aplikování transformace se informace s největším vlivem dostaly do levého horního rohu a se stoupající vzdáleností od něj důležitost informací klesá. Tím se dominantní a důležitější složky obrazu reprezentované nižšími frekvencemi oddělí od drobných detailů (vyšších frekvencí) a obraz se
tak připraví k další redukci vypuštěním těchto drobných detailů.
■
Kvantifikace
Až do této fáze se v úpravách obrazu jednalo o vratné operace a nedocházelo (kromě
podvzorkování barev) ke ztrátě informací. Nyní přichází fundamentální krok: provedením kvantifikace dochází k nevratným změnám, proto je komprese JPEG nazývána
61
kompresí ztrátovou. Každá ze 64 frekvencí jednotlivých bloků po diskrétní kosinové
transformaci se vydělí kvantifikačními koeficienty (které jsou součástí předem experimentálně připravených kvantifikačních matic) a zaokrouhlí na celá čísla. Podle volby kvantifikační matice můžeme ovlivnit stupeň komprese a tím i výslednou kvalitu
obrázku.
Tip:
I při volbě minimálního kvantifikačního koeficientu (hodnota Q faktoru je 1) dochází
ke ztrátě dat při celočíselném zaokrouhlování – výsledky diskrétní kosinové transformace jsou obecně neceločíselné.
■
Kódování
Po provedení kvantifikace dostaneme řídkou matici, která kromě několika koeficientů
v levém horním rohu obsahuje samé nuly. Tuto matici převedeme do posloupnosti čísel, přičemž postupujeme po diagonálách od levého horního k pravému dolnímu rohu.
Takto získaná posloupnost se zakóduje Huffmanovým nebo aritmetickým kódováním
(viz pasáž této knihy o bezztrátové komprimaci). V části kódování tedy nedochází
k další ztrátě informací.
■
Konečná fáze
Pod pojmem konečné fáze se rozumí přidání hlavičky ke komprimovaným datům.
Aby dekompresor mohl správně rekonstruovat původní grafická data, je nutné zahrnout do hlavičky kvantifikační tabulku a tabulku Huffmanových kódů.
■
Dekomprese
Při dekompresi JPEG se používá inverzního postupu. Vzhledem k tomu, že inverzní
postup není z matematického hlediska o moc jednodušší, nebývá doba potřebná pro
dekompresi o mnoho kratší než při původním kódovacím procesu.
62
Shrnutí
Metoda kódování grafických předloh JPEG je vhodná pro kompresi složitých obrázků s velkou barevnou hloubkou. Jedná se o ztrátovou kompresi, která ke zlepšení kompresního poměru využívá redundanci grafických dat způsobenou nedokonalým vjemem lidského oka. Pro odlišení drobných detailů (jež lze při komprimaci „ztratit“) od fundamentálních tvarů v obrázcích se používá diskrétní kosinová transformace.
Výhody:
■ Mnohem lepší kompresní poměr než u bezztrátové komprese.
■
Díky výbornému kompresnímu poměru velice vhodný formát pro publikaci
obrázků na stránkách WWW. Progresivní forma standardu JPEG je vhodná
i pro uživatele s pomalým připojením přes modem.
Nevýhody:
■ Nevhodný pro jednoduché barevné předlohy s rovnými ostrými barevnými
hranami a velkými jednobarevnými plochami.
■
Poměrně značná složitost komprimačního i dekomprimačního algoritmu promítající se do poměrně dlouhé doby zpracování.
63
Další metody ztrátové komprese obrazu
Existují i další metody pro komprimování obrazu, které se rozvíjejí a používají. Ačkoli tyto
metody nejsou většinou tak propracované jako ztrátová komprimace JPEG, zaslouží si, aby
zde byly alespoň stručně vzpomenuty.
Výklad těchto metod je většinou složitější a nelze o něm hovořit s alespoň částečnou znalostí matematického aparátu, který tyto metody používají. Následující odstavce jsou maximálně zredukovány do co možná nejčtivější formy.
Vlnková transformace
První z metod je tzv. „wavelet transformation“ (vlnková transformace). Obecně se předpokládá, že se jedná o příští standard ve ztrátové kompresi obrazu. V dnešní době však standardizace této metody teprve začíná a podobné obliby, jaké se dnes těší např. JPEG, zřejmě
nedosáhne dříve než koncem následujícího desetiletí.
Tato metoda komprese je založena na matematické transformaci obrazu do formy, která byť
při určité ztrátě informací je mnohem nenáročnější na paměť média, kde je matematický
obraz původní předlohy uložen.
Obnovení původního obrazu se potom děje inverzní matematickou transformací.
Při výkladu tohoto druhu „vlnkové“ transformace začněme trochu obšírněji od podobné, ale
jednodušší Haarovy transformace. Jedná se o matematickou transformaci do jiného ortogonálního prostoru (podobně jako diskrétní Fourierova transformace), kde bázovými funkcemi je množina funkcí, které se podobají obdélníkovým pulsům – viz obr. 8.
64
Obr. 8
Množina funkcí pro osmiprvkovou 1D Haarovu transformaci.
Obr. 8 ukazuje množinu funkcí určených pro osmiprvkovou jednodimenzionální Haarovu
transformaci. Pokud máte dostatečnou představivost, nebude pro vás možná ani příliš těžké
rozšířit tuto množinu funkcí tak, aby byla použitelná do vyšších řádů a vyšších dimenzí.
Na první pohled je zřejmé, že čtyři Haarovy funkce – označené a), b), c), d) – jsou určeny
pro zakódování nejmenších detailů v nejjemnějším rozlišení obrazu. Pomocí dalších dvou
funkcí – označených e), f) – se budou kódovat hrubší detaily obrazu. Funkce označená
g) se použije pro kódování nejhrubších změn při malém rozlišení obrazu a za pomoci poslední funkce h) se bude kódovat průměrná hodnota celého obrazu.
Tip:
Haarova transformace je použitelná na kódování obrázků namísto diskrétní Fourierovy
transformace. V obrázcích s barevnou hloubkou 1 bit na pixel (tj. černobílých obrázcích)
bude výsledek vypadat lépe, protože obdélníkové tvary Haarových funkcí budou (na rozdíl od Fourierova obrazu) přesně sledovat skokové změny v obrázcích. Navíc bude Haarova transformace rychlejší. Složitější obrázky s postupnými kontinuálními změnami však
dostanou nehezký hranatý tvar. Tento nedostatek lze částečně zakrýt stínovanou maskou
překrývající obrázek. Diskrétní kosinová transformace však bude dávat konzistentnější
výsledky.
65
Nyní předpokládejme, že chceme udělat diskrétně vzorkovaný obraz spojité funkce. Lze to
provést skenováním této funkce za použití postupného „vyclonění“ funkcí [sin(x)/x].
Stejného výsledku lze dosáhnout, pokud začneme s vysokým rozlišením již diskrétně vzorkovaného obrazu funkce, který prakticky splývá s funkcí spojitou. Diferencováním obrazů
při různých rozlišeních lze sestavit množinu obrazů funkce ukazující skokové změny při
různých rozlišeních. Zpětným složením všech takto vytvořených obrazů potom získáme původní funkci (nebo grafický obrázek).
Jedná se vlastně o expanzi dat: pokud začínáte s obrázkem 1024x1024 bodů, dostanete např. obrázek 64x64 bodů s nejhorším rozlišením a další diferencované obrázky o velikosti
128x128 bodů, 256x256 bodů, 512x512 bodů a poslední o rozměrech 1024x1024 bodů.
Pokud se pozorně zamyslíte nad systémem, kterým byla tato množina obrázků konstruována, uvědomíte si, že všechny obrázky budou obsahovat znatelnou redundanci – většina hodnot v obrázcích se bude pohybovat okolo nuly. Lze tedy (na základě znalosti použitého
systému, jakým jsme sestavili jednotlivé obrázky) sestavit množinu funkcí na kterékoli
úrovni rozlišení tak, že jejich celková hodnota ze všech vyšších úrovní bude nula. Tím jsme
sestavili ortonormální množinu bázových funkcí pro transformaci obrazu. Matematická
transformace uskutečněná za pomoci této množiny transformačních funkcí se nazývá vlnková transformace (wavelet transformation).
Taková transformace se trochu podobá Haarově transformaci s tím rozdílem, že obdélníkové
funkce byly nahrazeny symetrickými funkcemi, které v nekonečnu spojitě limitují k nule.
(Haarovy funkce díky svému obdélníkovému tvaru dosahují nuly ostře a nikoli postupně.)
Na závěr je vhodné doplnit, že diskrétní vlnková transformace je co do rychlosti kódování
a dekódování srovnatelná s diskrétní kosinovou transformací používanou v kompresních
schématech JPEG, ale dosahuje dvakrát lepšího kompresního poměru pro stejné obrázky
a při stejné vizuální kvalitě.
Fraktální komprese (Fractal Image Compression)
Fraktální komprese obrazu patří mezi další rozvíjející se komprimační techniky. Jedná se
také o ztrátovou komprimaci redundantních dat, která je vhodná (jako všechny ztrátové algoritmy) pro složité předlohy s velkou barevnou hloubkou.
66
Počátky fraktální geometrie, na jejímž základě se fraktální komprese obrazu vyvinula, spadají do roku 1977. Fraktální geometrii lze ve stručnosti jedinou větou charakterizovat jako
geometrii, která se svými tvary a hraničními čarami nepodobá klasické geometrii rovných
čar a hladkých povrchů, ale spíše geometrii stromů, mraků či hor.
Matematický popis takové geometrie se opírá o teorii iteračních funkcí (Iterated Function
Theory) a především systémy iteračních funkcí (Iterated Functions Systems), které podal
Michael Barnsley v bibli fraktální geometrie Fractals Everywhere. Kniha obsahuje i důkaz
teorému známého jako Collage Theorem, který říká, jak musí vypadat systém iteračních
funkcí, aby tyto funkce mohly reprezentovat obrázek.
Od této chvíle se myšlenky začaly obracet směrem k reprezentaci „přírodě se podobajících
obrázků“ za pomoci systému iteračních funkcí a k otázce, zda by tato metoda nemohla
sloužit ke kompresi takových grafických předloh. K tomu bylo nejprve nutné vyřešit problém zpětné rekonstrukce obrazu ze systému iteračních funkcí. Barnsley, vyzbrojen znalostí
svého Collage Theoremu, publikoval řešení v roce 1988.
Řešení však mělo stále několik drobných nevýhod: zakódování barevného obrázku trvalo přibližně 100 hodin, dekódování okolo 30ti minut a oba tyto procesy byly natolik složité, že
u nich byla nezbytná asistence lidského operátora – proces se stále nedařilo zautomatizovat.
Řešení na sebe nechalo čekat až do roku 1992, kdy Arnaud Jacquin publikoval první praktický algoritmus fraktální komprese grafických dat.
Tento algoritmus lze metaforicky přirovnat ke kopírce, která pracuje jako klasická kopírka
s několika odlišnostmi.
■
V kopírce je zabudovaný systém čoček, který je následkem toho, že výstupem z kopírky jsou násobné překrývající se kopie originálu.
■
Systém čoček zmenšuje originál.
■
V kopírce funguje zpětná vazba tak, že výstup z kopírky se zároveň stává vstupem pro
další stupeň „kopírování“. Původním vstupem může být cokoli.
První bod vytváří systém funkcí, třetí bod zajišťuje, že tento systém bude iterační. Druhý
bod se obvykle vysvětluje tak, že iterační systém funkcí je kontraktivní.
Systém iteračních funkcí je tedy množinou transformací původního obrazu.
67
Pokud je tento algoritmus uplatněn na „přírodě se podobající“ obrázek, vznikne velice kompaktní forma latentního fraktálního obrazu. Kompresní poměr samozřejmě závisí na počtu
průchodů předlohy „kopírkou“. Zpětná rekonstrukce takového obrazu do původní formy
však zůstává do dnešních dní nevyřešená (zpětně rekonstruované obrázky mají pouze ubohou kvalitu), a proto bylo nutné přikročit k některým úpravám v samotném kódování.
Základní myšlenkou je rozdělení původního obrázku do několika bloků a následující transformace nikoli již celé původní předlohy, ale jejích částí odděleně. Tyto bloky musí být velice pečlivě vybrány podle kvalitativních změn na ploše celkového obrázku (k tomu slouží
právě matematický aparát fraktální geometrie, který je schopen nalézt kvalitativní, matematicky rozeznatelné odlišnosti ve struktuře jednotlivých fraktálních tvarů). Je nezbytné, aby
každý pixel původní datové předlohy náležel alespoň k jednomu z bloků, do nichž je obrázek rozdělen. Vytvářejí se tedy tzv. systémy částečných iteračních funkcí. Výhodou částečných iteračních funkcí v rámci jednoho systému (odpovídajících jednomu „typu“ fraktálního geometrického tvaru) je jejich vzájemná podobnost. A právě tato podobnost je příčinou
lepších výsledků při dekomprimaci obrazu do původní podoby. Jedná se samozřejmě o ztrátovou kompresi, a proto zpětně rekonstruovaný obrázek není identický s původní předlohou. Výsledek je samozřejmě závislý na počtu průchodů původní grafické předlohy „kopírkou“, a tudíž i na dosaženém kompresním poměru.
Tip:
Kritickou co do časové náročnosti se při fraktální kompresi stává fáze rozčlenění celkového obrazu do jednotlivých bloků. Z toho důvodu je komprese obrazu mnohem pomalejší než následná dekomprese.
Tip:
Protože transformace obrazu v průběhu fraktální komprese je prostorově kontraktivní,
jednotlivé detaily jsou zobrazovány se stále lepším a lepším rozlišením. Výsledkem je potom je fakt, že pokud „fraktální“ obrázek zvětšíte, uvidíte stále hladké tvary bez ostrých
hran, které se objevují při zvětšení prostých bitmap. Z tohoto důvodu však také nelze
předpokládat převratné kompresní poměry.
68
Tip:
Typické kompresní poměry pro fraktální kompresi obrazu se pohybují od 4:1 do 100:1.
Závěrem proveďme srovnání kvality fraktální komprese s dnes nejoblíbenějším ztrátovým
schématem JPEG. Tato kvalita bývá většinou posuzována na základě matematicky jednoduše vyjádřitelných ochylek a chyb (jako jsou poměr signálu k šumu nebo střední kvadratická
odchylka) v zobrazení jednotlivých formátů. Podle tohoto striktního metru lze obecně říci,
že JPEG poskytuje kvalitnější zobrazení při malých kompresních poměrech, vyšší kompresní poměry mluví pro fraktální kompresi. Bod obratu se samozřejmě pro jednotlivé obrázky
liší, ale většinou se pohybuje kolem kompresního poměru 40:1.
Zastánci fraktální komprese však argumentují tím, že při všech kompresních poměrech jsou
chyby a odchylky v zobrazení při použití fraktální komprese takové, že lépe zapadají do
celkové struktury obrazu (na rozdíl od výše popsaných artefaktů JPEGu) a lidské vědomí je
chápe jako jeho přirozenou součást. Takové hodnocení je samozřejmě diskutabilní a subjektivní a teprve čas ukáže, zda ospravedlní budoucí široké využití fraktální komprese v konkurenci nejen JPEGu, ale také ostatních nastupujících metod, především pak „vlnkové
transformace“.
Skalární a vektorová kvantifikace
Skalární a vektorová kvantifikace není samostatnou formou ztrátové komprese, ale většinou
se používá ve spojení s jinými metodami.
Skalární kvantifikace spočívá v tom, že skalární hodnota je reprezentována fixní podmnožinou bitů. Pokud například u obrázku s barevnou hloubkou 16 bitů na pixel reprezentujeme
každý pixel pouze významnější osmicí bitů, dochází ke komprimaci obrazu v poměru 2:1
za cenu ztráty barevné informace.
Vektorová kvantifikace se nezakládá na reprezentaci jednotlivých hodnot, ale malých polí
těchto hodnot. Např. barevný obrázek může být reprezentován 2D polem tripletů (hodnot
RGB). Ve většině obrázků nevyužívají tyto triplety celý barevný prostor RGB, ale mají tendenci koncentrovat barvy do určitých částí obrázků. Obrázek lesa bude složen především
z bodů zelené barvy. Je tedy možné vybrat relativně malou oblast a v ní aproximovat každý
triplet reprezentativní barvou. Triplet tak degeneruje ze tří bajtů na jediný bajt opět za cenu
rozumné ztráty barevné informace.
69
Shrnutí
Ačkoli diskrétní kosinová transformace používaná standardem JPEG je velice
mocnou zbraní při ztrátové komprimaci složitých obrazových předloh, není jedinou – a jak se ukazuje – ani nejlepší metodou podporující ztrátovou komprimaci
redundantních dat. Především vlnková transformace je nástrojem, který by standard JPEG (v dnešní formě) mohl postupně vytlačit. Důvodem je především lepší kompresní poměr dosahovaný metodami založenými na vlnkové transformaci.
Otázkou zůstává standardizace těchto metod a jejich budoucí podpora softwarovými firmami.
JBIG
JBIG do této kapitoly vlastně nepatří. Jedná se o grafický formát, jehož komprese není
ztrátová.
JBIG je zkratka Joint Bi-level Image Experts Group. JBIG je metoda pro bezztrátovou kompresi obrazů, které obsahují nízký počet odstínů šedi, ideálně pouze černou a bílou. Tato metoda se využívá především u faxů. Obecně je JBIG metodou pro kompresi černobílých obrázků s nejvýš osmi bity na pixel (tj. maximálně 256 odstíny šedé). Pro černobílé obrázky
používající více než 8 bitů na pixel by již tato metoda nebyla tak účinná jako metody jiné.
JBIG pro kompresi používá metody progresivního kódování.
Před samotným kódováním je obraz rozdělen do bitových rovin, kde je v každé rovině
obraz redukován na hloubku šedi jediného bitu na pixel. Pokud má již originální obrázek
pouze jediný bit na pixel, fáze rozdělení na bitové roviny odpadá.
Další rozdělení obrazu zajišťuje, že obraz bude k příjemci posílán po částech tzv. progresivní metodou. Obraz je rozdělen na několik horizontálních pruhů, které jsou kódovány postupně. Každý pruh se navíc vysílá ve vrstvách podle rozlišení. Přijímací zařízení bude obraz
rekonstruovat tak, jak jej bude přijímat od hrubších k jemnějším detailům. Tato metoda používá postupné zdvojování úrovně rozlišení.
70
Tip:
Používá se také sekvenční kódování, při kterém se naopak obraz kóduje shora dolů bez
jakéhokoliv prokládání.
Pro kompresi obrazu se používá aritmetické kódování realizované použitím Q CODERu,
což je bezztrátový adaptivní algoritmus podobný Huffmanovu kódování. V průběhu komprese se postupně vytváří adaptivní rozdělení pravděpodobností výskytu bílých a černých
pixelů. Pro pravděpodobnější symboly se potom v kompresi použije menší počet bitů než
pro symboly méně pravděpodobné.
Formát JBIG má velmi dobré výsledky především u komprese obrazů tvořených texty a jednoduchými objekty.
Shrnutí
Standard JBIG se zabývá kompresí dvoubarevných předloh (černá – bílá), které
se využívají především ve faxových strojích.
MPEG
MPEG je zkratka pro Moving Picture Expert Group, komisi, která se zabývá vývojem standardů pro komprimaci videa a připojeného audiosignálu. Skupina pracuje pod organizací
ISO – International Standards Organization.
Existuje několik norem pro kompresi videa MPEG, které vyhovují různým oblastem využití.
■
MPEG-1
Tato nejpoužívanější norma je navržena s ohledem na technologii CD tak, že nejvyšší
datový tok je až 1,5 Mb/s. V principu je norma MPEG-1 definována až do velikosti obrázku 4095x4095x60 (60 snímků za sekundu). Norma MPEG-1 sestává ze čtyř částí:
■
IS 11172-1 popisuje synchronizaci a multiplexaci videa i zvukového signálu.
■
IS 11172-2 popisuje kompresi neprokládaného videosignálu.
71
■
IS 11172-3 popisuje kompresi připojeného audiosignálu.
■
IS 11172-4 popisuje testování shody přenesených dat s původními.
■
MPEG-2
Tato norma je navržena s ohledem na využití v dálkových a satelitních přenosech signálu při zachování televizní kvality. Norma MPEG-2 umožňuje rozlišení až
do16383x16383 bodů, jediné omezení je, že výška i šířka snímku musí být dělitelná
16 pro lepší rozdělení na oblasti při komprimaci.
Tip:
Důležitým rozdílem oproti normě MPEG-1 je také to, že MPEG-1 pracuje pouze s neprokládanými celými snímky, ale MPEG-2 dovoluje vedle neprokládaných snímků také použití snímků prokládaných. To může být výhodou při použití televizních přijímačů, které
právě prokládání obrazu používají.
■
MPEG-3
Tato norma byla původně myšlena jako podpora HDTV, tedy televize s vysokým rozlišením, ovšem tuto oblast byla po úpravách schopna pokrýt i norma MPEG-2. Od normy MPEG-3 se tedy upustilo a dále se nepoužívá.
■
MPEG-4
Na rozdíl od rostoucích požadavků na datový tok v předcházejících normách je norma
MPEG-4 definována pro přenos videa a připojeného audiosignálu po pomalých linkách s rychlostí od 4800 do 64000 bitů/s, tedy převážně po modemech. Tato rychlost
je velice malá a MPEG-4 proto vychází z rozlišení 176x144 bodů při 10 snímcích za
sekundu.
Kompresi a přenos dat, videosekvencí a připojených audiosignálů je možno řešit buď softwarově nebo hardwarově. Softwarové řešení je vždy levnější, má však značně vysoké nároky na výpočetní výkon počítače. Je ale poměrně vhodné pro amatérské využití, především
tam, kde se pracuje s menšími objemy dat.
Hardwarové řešení je rychlejší, nevyžaduje tak výkonný počítač, jediným jeho nedostatkem
je relativně vyšší cena. Pro profesionální využití je tato investice nutná, protože zatímco
hardwarová komprese videa je možná v reálném čase, softwarová komprese videosouboru
zabere i na výkonném počítači často mnohonásobně delší dobu než je délka přehrání výsledného videosouboru.
72
Jak pracuje MPEG-1?
MPEG-1 je nejpoužívanější a běžným uživatelům také nejdostupnější komprimační a přenosový standard pro přenos videa a s ním souvisejícího audiosignálu.
Co se týká vlastní komprese obrazové informace, je velice podobná kompresnímu schématu
JPEG. Barevné RGB snímky jsou nejprve převedeny do formy YUV, kde jsou obě barvonosné složky později redukovány do formátu 176x120 pixelů. Důvody pro takový postup
byly vysvětleny v části zabývající se kompresním schématem JPEG. Každý snímek je rozdělen do bloků 8x8 pixelů, na tyto bloky je použita diskrétní kosinová transformace. Výsledné koeficienty transformace jsou dále kvantifikovány. (Kvantifikace vlastně znamená
dělení čísla jinou hodnotou. Tím se dosahuje snížení počtu bitů nesoucích příslušnou informaci na úkor informace obsažené v nejméně významných bitech.)
Posledním krokem je opět (stejně jako u formátu JPEG) bezztrátová komprimační část zastoupená Huffmanovým kódováním. Tato poslední část je použita jak na kvantifikované
koeficienty pocházející z diskrétní kosinové transformace, tak i na tzv. pohybové vektory,
které jsou ve schématu MPEG (ve srovnání s kódováním statických obrázků) zcela nové.
Jakým způsobem tyto pohybové vektory vznikají?
Oproti kódování jednoduchého statického obrázku musí být do videosekvence zahrnuta právě navazující sekvenčnost jednotlivých snímků. Základní myšlenka je založena na předpovědi „pohybu“ jednotlivých částí obrázku od snímku ke snímku.
Pro vyvážení kvality přehrávaného videa spolu s co možná nejlepšími kompresními poměry
používá norma MPEG-1 trochu komplikované schéma používající tři typy snímků.
■
Prvním z nich je statický snímek typu „I“ (intraframe). Tyto snímky představují statické snímky tak, jak je lze vidět, pokud rozvinete klasický film zhotovený chemickou
cestou. Tyto snímky neobsahují žádnou informaci o snímcích předcházejících. Existence takových snímků je pochopitelná – např. první snímek celého videa musí být
právě typu „I“.
Tip:
Snímky typu „I“ jsou velice důležité také pro rychlé převíjení videa, kdy na plné dekódování kompletní sekvence není čas a informace o pohybu by se jinak ztrácela.
73
■
Druhým typem je typ „P“ (predicted – předpovězený). K interpretaci tohoto snímku –
z pohledu dekompresoru – je nutná znalost předchozího dekódovaného snímku typu
„I“ nebo „P“. V obrázku typu „P“ je tedy obsažen odkaz na jeden z předcházejících
snímků a snímek sám již obsahuje i pohybové vektory, o kterých byla řeč výše. Tyto
pohybové vektory určují, jak se změnily jednotlivé detaily předcházejícího snímku,
který je již plně rekonstruován.
Tip:
Důvod pro používání pohybových vektorů namísto kódování celé sekvence jako posloupnosti statických obrázků se všemi detaily je zřejmý. Kompresní poměr bude při
použití stejného komprimačního algoritmu mnohem příznivější pro snímky typu „P“
než pro snímky typu „I“.
■
Posledním druhem snímků, které se používají v kompresní a přenosové normě MPEG-1,
je typ „B“ (bidirectional – obousměrný). Jak již název tohoto snímku napovídá, k dekódování takového obrázku je zapotřebí znalost dvou nejbližších snímků typu „I“ nebo „P“
– jednoho, který se v sekvenci snímků nalézá před a jednoho v sekvenci za příslušným
snímkem typu „B“. Při tvorbě snímku typu „B“ (z pohledu kompresního algoritmu) se
bere v úvahu „dopředný“ i „zpětný“ pohybový vektor pro každý blok kódovaného snímku a průměrováním příslušných bloků snímku „budoucího“ i „minulého“ se kódovací algoritmus pokouší dobrat nejlepšího výsledku.
Tip:
Je zřejmé, že při komprimaci snímků typu „B“ se bude dosahovat ještě lepších kompresních poměrů ve srovnání s typem „P“, a proto z hlediska komprese je vyvíjena
snaha o co největší počet snímků typu „B“ v celé sekvenci. Poměr snímků typu „P“
a „B“ se určuje experimentálně.
Celá sekvence snímků většinou vypadá tak, jak ukazuje obrázek 9.
74
Obr. 9
Sekvence snímků videa formátu MPEG-1.
Tip:
Z uvedeného schématu je zřejmé, že pro dekódování a zobrazení každého snímku typu
„B“ je nutné nejprve vyslat a dekódovat snímek typu „P“ nebo „I“, který se v sekvenci
nachází až za ním. Oba snímky typu „P“ nebo „I“ – předcházející i následující - je třeba
držet v paměti minimálně do skončení zpracování sekvence snímků „B“.
Tip:
Na základě předcházejícího tipu je zřejmé, že dekódování videa může být velice náročou
záležitostí jak na paměť počítače, tak i na početní výkon, a proto je lepší (a pro dosažení
profesionálních výsledků stále nezbytně nutné) svěřit celé toto schéma alespoň částečně
specializovanému hardwaru.
Dále je potřeba si uvědomit, že kódování celého videa trvá mnohonásobně déle než následné přehrání (dekomprese) – důvodem je hledání nejpoužitelnějších pohybových vektorů při tvorbě snímků typu „P“ a „B“.
Tři vrstvy jako standardy pro kompresi zvuku
Na začátku výkladu zaměřeného na kompresní schéma MPEG bylo řečeno, že se jedná
o kódovací schéma pro digitální přenos videa a připojeného audiosignálu. Zatím se výklad
omezil na video a nyní se dostaneme také ke kompresi zvuku.
75
IS 11172-3 normy MPEG-1 popisuje kompresi audio signálu. Existují tři kódovací schémata nazývaná Layer 1 až 3. Zvyšující se číslo „vrstvy“ vyjadřuje zvyšující se kvalitu zvuku
a tím i složitost kódovacího procesu. Pro každou vrstvu je specifikován formát datového toku a dekodér. V souladu se zvyšující se náročností a složitostí použitého algoritmu se zvyšujícím se číslem vrstvy je použita hierarchická kompatibilita vrstev. To znamená, že dekodér postavený na vrstvu N je schopen dekódovat i vrstvu s nižším číslem.
Celkový datový tok MPEG-1 může být maximálně 1,5 Mb/s – z toho je 1,2 Mb/s rezervováno pro video data a 0.3 Mb/s pro audio data. Pro srovnání: datový tok u CD (stereo,
16 bitů a 44,1 kHz) je 1,4 Mb/s. MPEG podporuje kompresní poměry od 1:2,7 až po 1:24.
Kompresní poměr 1:6 (256 kb/s) se jeví co do kvality při vhodných poslechových podmínkách podle zkušeností jako naprosto nerozeznatelný od originálu. Vyšší kompresní poměry
se již mohou projevit na kvalitě reprodukovaného zvuku, protože i v případě komprese zvuku se jedná o ztrátovou kompresi.
Důležitým pojmem pro kompresi audio dat ve formátu MPEG je psychoakustika, přesněji
psychoakustický model. (O aplikaci psychoakustického modelu se často mluví jako o „perceptual noise shaping“ nebo „perceptual subband transform coding“.) Komprese je u tohoto
ztrátového modelu založena na stejném principu jako využití redundance informací v grafických datech – kompresor vynechá detaily, jež jsou pro lidské ucho nepostižitelné. Průměrné lidské ucho je schopno zachytit zvuk přibližně v těchto mezích:
■
frekvenční rozsah 20 Hz - 20 kHz;
■
dynamický rozsah (ticho - hluk) asi 96 dB.
Citlivost je u lidského ucha nelineární a právě toho se využívá. První metoda zvaná Frequency Masking je založená na tom, že lidské ucho není schopno rozlišit v přítomnosti silného signálu signál slabší, který tak zanikne.
Druhá metoda zvaná Temporal Masking je založena na setrvačnosti vjemu zvuku. Např.
když budeme přehrávat signál 1 kHz hlasitostí 60 dB a k němu ještě tón 1,1 kHz hlasitostí
40 dB, bude druhý tón překryt a tudíž bude neslyšitelný. Poté co vypneme silnější signál,
bude tón ještě asi 5 ms neslyšitelný. Tuto prodlevu lze taktéž využít ke zjednodušení dat.
Jak již bylo uvedeno, formát MPEG definuje v základu 3 typy vrstev. Data se dělí na tzv.
frames. Každý frame se pak skládá z 384 jednotlivých vzorků.
76
■
Layer 1 – dělicí filtr pracující s critical band (poměr hlasitostí a závislost citlivostí na
frekvenci), je aplikován na jednotlivé frames a používá stejnou frekvenci. Psychoakustický model zde používá pouze Frequency Masking. Datový tok se může pohybovat
od 32 kb/s do 448 kb/s.
■
Layer 2 – oproti Layer 1 dělicí filtr pracuje s 3 framy najednou (předchozí, současný
a následující = 1152 vzorků) a je zde použito jednoduché Temporal Masking. Soubory
mají koncovku *.mp2 a datový tok je z intervalu od 32 kb/s do 384 kb/s.
■
Layer 3 – je použit lepší dělicí filtr s proměnnou frekvencí. Psychoakustický model
zde používá plně Temporal Masking a redukce vazeb mezi stereo signály. Soubory
mají koncovku *.mp3. Datový tok je z intervalu od 32 kb/s do 320 kb/s.
Tip:
■
Všechny tři vrstvy mohou používat vzorkovací frekvenci 32 kHz, 44.1 kHz nebo 48 kHz.
■
Všechny tři vrstvy používají stejnou banku akustických filtrů. Layer 3 navíc používá
diskrétní kosinovou transformaci pro zvýšení frekvenčního rozlišení.
■
V toku dat používají všechny vrstvy stejnou identifikační „hlavičku“ i celkovou strukturu datového toku.
To umožňuje dříve zmíněnou hierarchickou kompatibilitu všech tří vrstev.
Samozřejmě je možné kompresní schéma MPEG používat i pro přehrávání a kopírování
zvukových CD nosičů. Je ovšem nutné připomenout, že při tom nesmějí být porušena
práva pro šíření a kopírování nahrávek :-)
Programům, které dokáží přímo z audio CD uložit skladby do formátu WAV, se obecně říká
„grabovací programy“ (CD Rippers). Podmínkou je ovšem dobrá mechanika CD-ROM, která umožňuje načítat audio stopy na CD jako datové soubory.
Tip:
Soubory MP3 používají kompresi MPEG Audio Layer 3. Když při kompresi stereo audio
souboru typu WAV (stereo,16 bitů a 44,1 kHz) použijete parametry 128 kb/s a vzorkovací
frekvenci 44,1 kHz, získáte soubor MP3, který se kvalitou blíží audio CD.
77
Tip:
Soubory WAV v kvalitě audio CD získáte grabováním z audio CD nebo nahráváním pomocí LINE IN na zvukové kartě. Při nahrávání LINE IN však dochází ke dvěma konverzím signálu D/A a A/D, a tudíž ke zkreslení – lepší grabovací programy tento nedostatek
dokáží obejít.
Největší výhodou MP3 je velikost souboru – kompresní poměr při CD kvalitě dosahuje
12:1. Na jedno datové CD je tak možné uložit 12 až 13 klasických audio CD. Toto datové
CD je pak možné přehrávat (s použitím příslušného softwaru) v kvalitě, která se i pro cvičené ucho jeví jako nerozeznatelná od originální nahrávky.
Shrnutí
MPEG je ztrátový kompresní standard pro uchovávání a přenos digitalizovaných
videosekvencí snímků a připojeného audiosignálu. Existují tři normy určené pro
různé druhy použití:
■
MPEG-1 vytvořený s ohledem na přenosové rychlosti a využití v souvislosti
s technologií CD.
■
MPEG-2 pro využití při dálkových a satelitních přenosech vysokou rychlostí.
Na rozdíl od MPEG-1 je schopen pracovat i s prokládaným videosignálem.
■
MPEG-4 je navržen pro použití na pomalých (především modemových
linkách).
Zatímco standard MPEG-1 se zdá být – alespoň pro příští roky – vyhovující
a neočekávají se u něho žádné výrazné změny, pro MPEG-2 stále není nalezen
nejvýhodnější algoritmus a tato norma není plně standardizována.
Pro přenos audiosignálu v normě MPEG-1 slouží tři „vrstvy“ nazývané Layer1
až 3. I komprese zvuku je ztrátová a lze při ní dosáhnout kompresních poměrů
až 100:1. U nejsložitějšího záznamu za pomoci vrstvy Layer3 lze dosahovat
kompresního poměru 12:1 při zachování kvality běžného audio CD.
78
Výhody:
Možnost ztrátové komprese představuje velkou výhodu digitalizovaného videa
a audia oproti běžným analogovým technologiím.
Při kompresi sekvence videosnímků je možné použít tzv. pohybové vektory udávající, jak se změnil snímek oproti jinému snímku sekvence. Není tedy nutné
každý snímek videa kódovat jako statický – to je výhoda, která umožňuje dosáhnout ještě lepších kompresních poměrů.
U audio CD lze dosáhnout uložení 12 až 13 audio CD na jediné datové CD při
prakticky nezměněné kvalitě.
Nevýhody:
Samotná komprimace videa je složitým procesem jak na paměť, tak i na početní
výkon počítače. Ačkoli dekódování (přehrávání) je mnohonásobně jednodušší,
i zde jsou paměťové nároky a především početní výkon počítače limitující pro
čistě softwarové zpracování dat ve formátu MPEG.
K dosažení profesionálních výsledků v této oblasti je nezbytné využít přídavné
hardwarové zařízení (speciální karty pro přehrávání videa).
79
5
Archivační
programy
Archivační programy
Archivačními programy nazýváme kompresní programy určené pro bezztrátovou kompresi
dat uložených v jednotlivých souborech. Mezi českou uživatelskou veřejností jsou nejrozšířenějšími archivačními programy ARJ, ZIP a RAR. Nejsou to však zdaleka jediné a dokonce ani nejlepší existující archivační programy.
Základní možnosti archivačních programů
Názorů na to, jak hodnotit různé archivační programy, je mnoho. Každý uživatel musí nakonec sám rozhodnout, které hledisko je z jeho pohledu při volbě archivačního programu
nejdůležitější.
Těmito hledisky, podle kterých se uživatel rozhoduje, mohou být:
■
Výkonové ukazatele archivačního programu (viz dále).
■
Uživatelský komfort reprezentovaný souhrnem možností a nastavení použitelných pro
ten který archivační program.
■
Intuitivní jednoduché ovládání archivačního programu.
■
Možnost vytváření archivů na platformě Windows (včetně zachování dlouhých názvů)
a mnoho dalších.
Tip:
Archivační programy v sobě většinou kombinují různé modifikace bezztrátových komprimačních algoritmů, které byly popsány v kapitole věnované bezztrátové kompresi.
V této poměrně krátké kapitole se zaměříme na soubor nastavení a možností, které bývají
u většiny moderních archivačních programů k dispozici.
Archivy
Možnost vytváření archivů je naprosto fundamentální funkcí všech archivačních programů,
a proto je nemyslitelné, že by v některém archivačním programu tato možnost chyběla.
Moderní archivační program by však měl nabízet několik různých funkcí manipulace s archivy. Archivační programy by měly obsahovat dále popsané možnosti.
83
■
Možnost zachování stromové struktury archivovaných souborů. To znamená, že po obnovení původních dat z komprimovaného archivu zůstanou nezměněny nejen veškeré
informace obsažené v jednotlivých souborech, ale také stromová struktura, ve které
jsou tyto soubory uspořádány.
■
Možnost manipulace s jednotlivými soubory archivu. Pokud vytvoříte archiv, měli
byste mít možnost nakládat s jednotlivými soubory archivu bez toho, že by bylo nutné
nejprve dekomprimovat celý archiv. V tomto směru základními možnostmi, jež by neměly chybět dnes již v žádném archivačním programu, jsou:
■
Rozbalení jednotlivého souboru z archivu.
■
Vymazání jednotlivého souboru z archivu.
■
Přidání jednotlivého souboru do archivu.
Lepší archivační programy umožňují navíc:
■
Prohlížení jednotlivých souborů archivu.
■
U spustitelných souborů dokonce spuštění jednotlivých souborů archivu.
Obojí bez nutnosti předchozí explicitní dekomprimace tohoto souboru spojené s je
ho uložením na disk. Soubor je dekomprimován a uložen pouze v paměti RAM.
84
■
Možnost uzamčení archivu – tato možnost zakazuje jakékoli úpravy (přidává
ní souborů, přepisování) vytvořeného archivu.
■
Možnost opatření archivů heslem.
■
Možnost opravování poškozených souborů v archivu (nebo alespoň možnost pokusit se o takovou opravu).
■
Možnost tvorby samorozbalovacích (self-extracting) archivů. Samorozbalovací archiv je doplněný o spustitelný modul, který se používá pro rozbalení (dekomprimaci) archivovaných souborů mimo prostředí a bez pomoci archivačního programu,
kterým byl archiv vytvořen.
■
Možnost tvorby kompaktních archivů (solid archives). Kompaktní archiv komprimovaných dat při komprimaci nakládá se všemi soubory jako s jediným tokem dat. Výhodou tohoto druhu archivu je lepší kompresní poměr, zvláště při kompresi velkého
množství malých souborů. Nevýhodou je naopak pomalejší rozbalování jednotlivého
souboru (musí být analyzovány všechny soubory uložené v archivu) a ztráta veškerých komprimovaných dat i v případě, že je poškozen třeba jen jediný soubor archivu.
■
Možnost rozdělení dlouhých archivů na kratší bloky (volumes), aby bylo možné
komprimovaný archiv uložit např. na diskety.
■
Zachování dlouhých názvů souborů používaných systémem Windows 95 nebo NT.
■
Možnost nastavení komprimačního módu, který klade důraz na:
■
Nejlepší kompresní poměr.
■
Nejkratší dobu komprese.
■
Nejvýhodnější poměr doby komprese a kompresního poměru.
Všechny archivační programy (většinou i ty, které fungují pod systémem Windows), jsou
spustitelné z příkazové řádky, která vypadá ve většině případů následovně:
Name <command> -<switches> <archive> <files>
Popis parametrů:
■
Name – název archivačního programu.
■
Command – příkaz definující činnost archivačního programu. Např. komprimace, dekomprimace, přidání souboru do archivu, uzamčení archivu atd.
■
Switches – přepínače specifikující typ prováděné operace. Např. komprese s nejlepším
kompresním poměrem, tvorba samorozbalovacího archivu apod.
■
Archive – název archivu, který bude vytvářen, nebo se kterým se bude manipulovat.
■
Files – názvy souborů, se kterými se bude manipulovat.
Výkonové ukazatele (benchmarks)
Pokud mluvíme o výkonových ukazatelích archivačních programů, máme na mysli především následující parametry:
■
Kompresní poměr.
■
Čas potřebný pro kompresi.
■
Čas potřebný pro dekompresi.
■
Poměr času komprese a kompresního poměru.
Jak již bylo v této knize několikrát zmíněno, výkonové ukazatele jsou různé, pokud je stejný archivační program aplikován na různá data. Proto je nutné provést řadu různých testů,
aby srovnání archivačních programů bylo úplné.
85
Nikdy není možné umístit kterýkoli archivační program na jakousi absolutní stupnici definující jeho výkon. Jediné, čeho lze dosáhnout, je relativní srovnání jednotlivých programů.
Aby byly výsledky srovnávacích testů relevantní, je vždy nutné přesně uvést, za jakých
podmínek byly testy prováděny. Týká se to jak hardwaru počítače, tak i operačního systému
a jeho softwarového nastavení. Záznam o typu dat použitých pro testování je naprostou samozřejmostí.
Na následujících stránkách najdete výsledky srovnávacích testů archivačních programů z první poloviny roku 1998.
Pro všechny níže uvedené testy platí následující parametry použitého hardwaru a softwaru:
■
Byl použit počítač 486DX4-75 MHz.
■
Operační paměť RAM 20 MB.
■
Nebyla použita žádná disková cache.
■
Operační systém – MS-DOS 6.22 (výjimkou jsou označené programy pro Windows –
u těch byl použit systém Windows 95).
■
Komprese probíhala z běžného pevného disku na 2MB RAM disk.
■
Nastavení souboru CONFIG.SYS:
BUFFERS=20,0 FILES=40
První skupina testů byla provedena na jednotlivých souborech různého charakteru (testovací soubor byl vždy jen jeden).
První test (textový soubor)
Textový soubor
Nekomprimovaná velikost 768 771 bajtů
Tip:
V prvním sloupci je uveden název archivačního programu, ve druhém přepínače použité
při testování, ve třetím čas potřebný pro kompresi (minuty:sekundy.desetiny), ve čtvrtém
velikost komprimovaného archivu a v posledním kompresní poměr. Archivační programy
jsou srovnány podle dosaženého kompresního poměru od nejlepšího k nejhoršímu.
86
Archivační program
přepínače
čas
kompr. velikost
poměr
BOA 0.50b
−m15
1:32.4
211 847
72,4 %
RKIVE 1.90b1
−mt
3:43.3
217 460
71,7 %
RKIVE 1.4
−mt
1:01.8
219 676
71,4 %
X1 0.95a −>X
xem4l2
0:34.3
219 691
71,4 %
X1 0.95a −>X
xem3
0:35.2
219 827
71,4 %
RKIVE 1.4
−mtx
1:31.5
219 917
71,4 %
ACB 2.00c
(u)f
4:02.7
222 694
71,0 %
BOA 0.50b
(none)
1:17.8
224 195
70,8 %
UFA 0.03b5
−m5 −mu16
2:29.5
224 810
70,5 %
777 0.03b5
−m5 −mu16
2:31.9
224 810
70,5 %
UFA32 0.03b4
−m5 −mu16
2:32.2
224 810
70,5 %
777 0.03b4
−m5 −mu16
2:48.6
224 810
70,5 %
SZIP 1.05xe
−o10b8
0:23.5
225 475
70,7 %
ACB 2.00c
(b)f
2:43.3
225 658
70,6 %
SZIP 1.05xe
−b8
0:16.7
225 670
70,5 %
777 0.03b4
−m5
1:34.4
226 748
70,5 %
UFA32 0.03b4
−m5
1:35.0
226 748
70,5 %
777 0.03b5
−m5
1:36.7
226 748
70,5 %
UFA 0.03b5
−m5
1:37.5
226 748
70,5 %
ACB 1.14a
(b)f
2:36.8
227 416
70,4 %
ACB 2.00c
(B)f
1:54.7
231 309
69,9 %
BZIP2 0.1pl2
(none)
0:20.1
232 598
69,7 %
SZIP 1.03
(none)
0:09.0
235 437
69,4 %
SZIP 1.05xe
−o4b8
0:10.3
235 443
69,4 %
LGHA 1.1
−2
0:28.0
235 767
69,3 %
HA 0.999b
e2
0:34.8
235 767
69,3 %
BVI 1.50
(none)
3:30.1
237 382
69,1 %
BZIP2 0.1pl2
−5
0:19.7
242 662
68,4 %
BSArc 2.0.0
−++
0:46.7
244 049
68,3 %
X1 0.95a −>X
xem7
0:20.0
250 124
67,5 %
RKIVE 1.4
−mb
0:52.1
252 321
67,2 %
CODEC 3.21
−c10
0:42.4
252 375
67,2 %
RKIVE 1.90b1
−mb
1:46.4
255 424
66,8 %
87
88
přepínače
čas
kompr. velikost
poměr
JAR32 1.02
−m4
0:20.8
258 508
66,4 %
JAR32 1.02
−m3
0:20.6
258 533
66.4 %
JAR32 1.02
(none)
0:18.0
259 640
66,2 %
HAP 4.03
3
0:13.2
260 103
66,2 %
HAP 3.05bp
(none)
0:18.3
260 103
66,2 %
RKIVE 1.90b1
−mf
1:38.4
260 660
66,1 %
RKIVE 1.4
−mf
0:37.5
260 710
66,1 %
777 0.03b5
−m2 −mx
3:29.3
260 911
66,1 %
777 0.03b4
−m2 −mx
4:01.0
261 073
66,0 %
X1 0.94m −>X
xem6l2
5:21.6
262 719
65,8 %
QUANTUM 0.97
−c7 −t20
29:40.3
263 747
65,7 %
CABARC 1.0
−m LZX:21
0:42.0
264 147
65,6 %
UFA 0.03b5
−m2 −mx
1:25.2
270 133
64,9 %
UFA32 0.03b4
−m2 −mx
2:26.2
271 667
64,7 %
JAR16 1.02
−m3
0:27.4
271 898
64,6 %
JAR16 1.02
−m4
0:27.4
271 901
64,6 %
QUANTUM 0.97
−c5
11:03.7
271 960
64,6 %
UHARC 0.2
−m3 −md1024
1:23.2
272 226
64,6 %
JAR16 1.02
(none)
0:23.7
274 725
64,3 %
ERI32 3.0c3
−md4−c
1:55.2
275 292
64,2 %
ERI32 3.0c3
−m3
1:41.4
276 260
64,1 %
ERI32 3.0c3
−md3−m3
1:39.9
276 745
64,0 %
WinRAR 2.02
−m5 −md512
1:49.0
279 704
63,6 %
WinRAR 2.02
−m5 −md256
1:26.0
284 232
63,0 %
QUANTUM 0.97
−c3 −t20
2:00.1
284 721
63,0 %
QUANTUM 0.97
(none)
1:44.8
287 179
62,6 %
UHARC 0.2
−m2 −md1024
1:09.2
287 355
62,6 %
ACE 1.1b
−m5 −d1024
0:37.7
292 381
62,0 %
ACE32 1.1b
−m5 −d1024
0:38.0
292 381
62,0 %
WinRAR 2.02
−md512
0:28.8
293 003
61,9 %
ARI 2.16m
(none)
4:16.1
298 328
61,2 %
CABARC 1.0
−m LZX:15
0:29.9
298 655
61,2 %
HPACK 0.79a0
−df
0:49.7
299 072
61,1 %
přepínače
čas
kompr. velikost
po měr
RAR 2.02
−m5
0:30.4
301 306
60,8 %
ARJZ 0.15
−mp9 −jh
0:27.9
301 771
60,7 %
UC2 v3.0 PRO
(Max)
0:36.6
302 022
60,7 %
UC v2.37 beta
(Max)
0:35.5
302 026
60,7 %
ARI 2.16m
−m3
1:25.9
302 560
60,6 %
LHARK 0.4d
−tob
0:32.0
302 820
60,6 %
UHARC 0.2
−m1 −md1024
0:48.8
303 742
60,5 %
BVI 1.20
(none)
0:30.6
304 160
60,4 %
ARJZ 0.15
(none)
0:18.6
304 182
60,4 %
RAR 2.02
(none)
0:16.9
305 914
60,2 %
YAC 1.02
(none)
0:36.1
306 697
60,1 %
LHARK 0.4d
(none)
0:15.1
309 326
59,8 %
ZET 0.10b
−eh
0:20.2
309 699
59,7 %
LIMIT 1.2
−mx
0:21.6
310 872
59,6 %
LIMIT 1.2
(none)
0:20.1
311 187
59,5 %
AMGC 2.3
(Max)
0:49.0
311 274
59,5 %
SUPERPACK 2.0
(Max)
0:49.3
311 274
59,5 %
SKY 1.15
−m4
0:49.4
311 274
59,5 %
PKZIP 2.6 Win95
(Extra)
0:11.5
311 318
59,5 %
UC v2.37 beta
(Default)
0:16.4
311 412
59,5 %
UC2 v3.0 PRO
(Default)
0:17.4
311 412
59,5 %
HA 0.999b
e1
0:27.1
312 016
59,4 %
LGHA 1.1
−1
0:26.5
312 280
59,4 %
SQZ 1.08.3
−q(ALT236)
0:26.9
312 330
59,4 %
WINZIP’95 6.3
(Max)
0:17.7
312 371
59,4 %
INFO−ZIP 2.2DOS
−9 −j
0:18.1
312 389
59,4 %
INFO−ZIP 2.2NT
−9 −j
0:17.8
312 397
59,4 %
NETZIP 4.1
(Deflate)
0:19.6
312 594
59,3 %
TURBOZIP 2.1
(Level 9)
0:20.4
312 594
59,3 %
PKZIP 2.04g
−ex
0:15.1
312 604
59,3 %
PKZIP 2.6 Win95
(Norm)
0:08.8
312 906
59,3 %
GZIP 1.2.4
−9
0:23.5
312 915
59,3 %
LHA 2.67(Win32)
−wd:\
0:21.4
313 166
59,3 %
89
90
přepínače
čas
kompr. velikost
poměr
INFO−ZIP 2.2DOS
−j
0:14.6
313 484
59,2 %
INFO−ZIP 2.2NT
−j
0:14.1
313 492
59,2 %
ACE32 1.1a
−d1024
0:17.0
313 725
59,2 %
ACE 1.1b
−d1024
0:18.6
313 725
59,2 %
CODEC 3.21
(none)
0:16.2
313 787
59,2 %
BSArc 2.0.0
(none)
0:19.1
314 138
59,1 %
AIN 2.32
/m1
0:11.3
314 299
59,1 %
ESP 1.92
/m0
0:12.1
314 314
59,1 %
GZIP 1.2.4
(none)
0:18.8
314 443
59,2 %
SQZ 1.08.3
(none)
0:18.6
315 028
59,0 %
PKZIP 2.04g
(none)
0:10.4
316 113
58,9 %
QUARK 1.0beta
(none)
0:18.0
317 195
58,7 %
ESP 1.92
/m2
0:10.0
317 629
58,7 %
AIN 2.32
(none)
0:09.1
317 660
58,7 %
WINZIP’95 6.3
(Normal)
0:09.7
318 344
58,6 %
ARJ 2.60
−jm −e
0:17.9
318 939
58,5 %
ARJ 2.60
−e
0:16.7
319 163
58,5 %
NETZIP 4.1
(Method 4)
0:11.2
319 281
58,5 %
TURBOZIP 2.1
(Level 5)
0:11.3
319 281
58,5 %
ZIPSERVER 2.12
(none)
0:12.5
319 450
58,4 %
ZET 0.10b
(none)
0:09.4
321 667
58,2 %
SUPERPACK 2.0
(Normal)
0:15.4
327 641
57,4 %
AMGC 2.3
(Normal)
0:15.6
327 641
57,4 %
SKY 1.15
(none)
0:16.1
327 641
57,4 %
DEEPFREEZE 1.03
(none)
0:18.2
327 814
57,4 %
XPACK 1.67k
−a
0:37.2
331 390
56,9 %
NULIB 3.24
c5
0:05.9
334 187
56,5 %
PROPACK 2.08
d
3:18.6
334 849
56,4 %
MSXIE 1.40
(none)
0:31.3
338 941
55,9 %
LHA 2.55b
−we:
0:17.4
339 110
55,9 %
AR 1.10
(none)
0:32.4
339 110
55,9 %
SAR 1.0
(none)
0:32.3
339 118
55,9 %
ZOO 2.10
h:
0:30.9
339 245
55,9 %
přepínače
čas
kompr. velikost
poměr
CROSSEPAC 1.35
Format=Binary
0:29.9
339 419
55,8 %
PUT 3.41
(none)
0:22.4
339 642
55,8 %
ZipNAV 2.03
(Comp lvl 5)
0:19.7
340 046
55,8 %
ZipNAV 2.03
(Comp lvl 9)
0:20.4
340 046
55,8 %
HYPER 2.6
(none)
0:09.9
345 887
55,0 %
PAK 2.51
(none)
0:10.8
347 608
54,8 %
JAM − Aug1996
(none)
0:06.9
351 720
54,2 %
ARQ 3.2
(none)
0:37.8
352 950
54,1 %
DWC 5.10
z
0:07.7
362 629
52,8 %
PKARC 3.5
(none)
0:04.4
364 069
52,6 %
SQWEZ 2.2
/s
0:33.0
365 224
52,5 %
KBOOM 1.1
(none)
0:09.6
366 622
52,3 %
LZOP 0.94w
−9
0:36.6
366 883
52,3 %
ARX 1.0
(none)
0:14.4
369 545
51,9 %
ELI 5750
(none)
0:10.4
369 552
51,9 %
LHARK 0.4d
−tt
0:04.0
370 472
51,8%
PKPAK 3.61
(none)
0:07.7
370 543
51,8 %
ZIP−ARCHIV 2.0
(none)
0:11.0
370 868
51,8 %
PKZIP 2.04g
−es
0:04.1
372 386
51,6 %
DWC 5.10
(none)
0:08.1
380 299
50,5 %
TSCOMP 1.3.21
−sh
0:13.3
391 252
49,1 %
MDCD 1.0
(none)
0:05.8
391 703
49,0 %
ZOO 2.10
:
0:13.2
391 750
49,0 %
SPLINT 2.1
(none)
0:17.8
416 191
45,9 %
JRCHIVE 1.10
−v
0:09.6
416 982
45,8 %
ZIP−ARCHIV 2.0
−m
0:08.0
417 005
45,8 %
TSCOMP 1.3.21
−sm
0:11.3
418 014
45,6 %
ARC 6.02
(none)
0:05.4
418 511
45,6 %
LARC 3.33
(none)
0:10.2
424 186
44,8 %
SQUASH 1.21
(none)
0:19.5
424 209
44,8 %
MSCOMPRESS 2.0
(none)
0:19.0
424 265
44,8 %
GAS 2.0
(none)
2:00.7
438 688
42,9 %
NULIB 3.24
(none)
0:07.0
454 304
40,9 %
LZOP 0.94w
(none)
0:03.3
487 406
36,6 %
91
Výsledky testu:
Nejlepší kompresní poměr:
BOA 0.50b
Nejrychlejší komprese:
LZOP 0.94w
Nejlepší poměr času komprese a kompresního poměru:
SZIP 1.03
Druhý test (soubor EXE)
Binární spustitelný soubor EXE Nekomprimovaná velikost 425 488 bajtů
Tip:
92
přepínače
čas
kompr. velikost
poměr
777 0.03b5
−m2
2:43.2
77 290
81,8 %
777 0.03b5
−m2 −md128
3:04.5
77 304
81,8 %
777 0.03b4
−m2−md128−mx
3:56.6
77 405
81,8 %
777 0.03b4
−m2
2:47.6
77 632
81,8 %
UFA 0.03b5
−m2−md128−mx
1:22.4
83 549
80,4 %
UFA32 0.03b4
−m2−md128−mx
2:12.2
83 799
80,3 %
UFA32 0.03b4
−m2
1:06.5
83 947
80,3 %
UFA 0.03b5
−m2
0:44.6
84 081
80,2 %
ERI32 3.0c3
−1
1:12.8
84 806
80,1 %
ERI32 3.0c3
−m4 −1
1:07.2
84 827
80,1 %
ERI32 3.0c3
−m3 −1
0:40.4
85 417
80,0 %
ARI 2.16m
−1
2:37.5
87 685
79,4 %
ARI 2.16m
−m3 −1
0:31.8
88 956
79,1 %
RKIVE 1.90b1
−mt
1:25.2
91 488
78,5 %
RKIVE 1.4
−mb
0:30.2
92 203
78,3 %
přepínače
čas
kompr. velikost
poměr
CABARC 1.0
−m LZX:21
0:27.1
92 505
78,3 %
RKIVE 1.90b1
−mb
1:01.6
92 786
78,2 %
CABARC 1.0
−m LZX:15
0:17.1
93 453
78,0 %
RKIVE 1.4
−mtx
0:43.9
93 603
78,0 %
RKIVE 1.4
−mt
0:36.4
94 301
77,8 %
ACB 2.00c
(u)f
1:10.4
95 488
77,6 %
ACB 2.00c
(b)f
0:50.2
95 700
77,5 %
ACE 1.1b
−m5 −d1024
0:12.3
95 889
77,5 %
ACE32 1.1b
−m5 −d1024
0:12.5
95 889
77,5 %
ACB 2.00c
(B)f
0:36.6
96 189
77,4 %
RKIVE 1.90b1
−mf
0:47.3
96 811
77,2 %
RKIVE 1.4
−mf
0:22.3
96 886
77,2 %
QUANTUM 0.97
−c7 −t20
11:00.2
97 105
77,2 %
ACE32 1.1b
−d1024
0:08.3
97 125
77,2 %
ACE 1.1b
−d1024
0:10.2
97 125
77,2 %
QUANTUM 0.97
−c5
3:46.5
97 315
77,1 %
ACB 1.14a
f
0:43.7
97 897
77,0 %
RAR 2.02
−m5
0:15.2
98 576
76,8 %
UHARC 0.2
−m3 −md1024
0:36.0
98 719
76,8 %
WinRAR 2.02
−m5 −md256
0:21.3
98 734
76,8 %
JAR16 1.02
−m4
0:23.5
99 058
76,7 %
JAR16 1.02
−m3
0:23.5
99 062
76,7 %
UHARC 0.2
−m2 −md1024
0:24.7
98 152
76,7 %
JAR16 1.02
(none)
0:16.8
99 194
76,7 %
JAR32 1.02
−m3
0:16.4
99 419
76,6 %
JAR32 1.02
−m4
0:16.6
99 418
76,6 %
RAR 2.02
(none)
0:05.4
99 652
76,6 %
WinRAR 2.02
−md256
0:06.5
99 760
76,6 %
JAR32 1.02
(none)
0:11.2
99 869
76,6 %
UHARC 0.2
−m1 −md1024
0:20.9
100 664
76,2 %
X1 0.95a −>X
xem1
0:18.2
101 410
76,2 %
YAC 1.02
(none)
0:17.2
101 419
76,2 %
QUANTUM 0.97
(none)
0:25.2
101 443
76,2 %
93
94
přepínače
čas
kompr. velikost
poměr
YAC 1.02
(none)
0:19.9
101 448
76,2 %
QUANTUM 0.97
−c3 −t20
0:26.4
101 456
76,2 %
LGHA 1.1
−1
0:12.9
101 492
76,1 %
HA 0.999b
e1
0:14.2
101 496
76,1 %
BVI 1.20
(none)
0:09.3
101 992
76,0 %
BOA 0.50b
(none)
0:44.0
102 095
76,0 %
BOA 0.50b
−m15
0:47.4
102 339
75,9 %
QUARK 1.0beta
(none)
0:18.5
103 213
75,7 %
UC2 v3.0 PRO
(Max)
0:27.2
103 488
75,7 %
UC v2.37 beta
(Max)
0:26.6
103 508
75,7 %
LIMIT 1.2
−mx
0:13.1
103 645
75,6 %
CODEC 3.21
(none)
0:04.9
103 710
75,6 %
SUPER PACK 2.0
(Max)
0:21.6
103 806
75,6 %
AMGC 2.3
(Max)
0:21.8
103 806
75,6 %
SKY 1.15
−m4
0:20.6
103 806
75,6 %
LHARK 0.4d
−tob
0:09.3
103 828
75,6 %
PKZIP 2.6 Win95
(Extra)
0:04.1
103 830
75,6 %
GZIP 1.2.4
−9
0:18.2
103 832
75,6 %
TURBOZIP 2.1
(Level 9)
0:19.3
103 899
75,6 %
WINZIP’95 6.3
(Max)
0:14.8
103 929
75,6 %
INFO−ZIP 2.2DOS −9
−j
0:16.0
103 947
75,6 %
INFO−ZIP 2.2NT
−9 −j
0:15.9
103 955
75,6 %
LIMIT 1.2
(none)
0:04.8
104 147
75,5 %
PKZIP 2.04g
−ex
0:06.7
104 249
75,5 %
NETZIP 4.1
(Deflate)
0:08.9
104 264
75,5 %
LHARK 0.4d
(none)
0:04.0
104 500
75,4 %
AIN 2.32
/m1
0:04.7
104 858
75,4 %
ESP 1.92
/m0
0:05.3
104 901
75,3 %
ARJ 2.60
−jm −e
0:15.4
104 976
75,3 %
BSArc 2.0.0
−+1
0:17.7
105 024
75,3 %
SQZ 1.08.3
−q(ALT236)
0:30.2
105 088
75,3 %
ARJZ 0.15
−mp9
0:14.3
105 120
75,3 %
GZIP 1.2.4
(none)
0:05.9
105 196
75,2 %
přepínače
čas
kompr. velikost
poměr
LHA 2.67(Win32)
−wd:\
0:06.7
105 214
75,3 %
INFO−ZIP 2.2NT
−j
0:04.6
105 428
75,2 %
ZET 0.10b
−eh
0:13.0
105 428
75,2 %
INFO−ZIP 2.2DOS
−j
0:05.0
105 472
75,2 %
ESP 1.92
/m2
0:04.8
105 488
75,2 %
UC2 v3.0 PRO
(Default)
0:06.8
105 514
75,2 %
AIN 2.32
(none)
0:04.0
105 515
75,2 %
UC v2.37 beta
(Default)
0:06.4
105 544
75,2 %
PKZIP 2.04g
(none)
0:04.3
105 547
75,2 %
PKZIP 2.6 Win95
(Norm)
0:02.2
105 548
75,2 %
ARJ 2.60
−e
0:06.3
105 646
75,2 %
PROPACK 2.08
d
1:43.3
105 679
75,2 %
BSArc 2.0.0
(none)
0:05.1
105 732
75,2 %
MSXIE 1.40
(none)
0:15.0
105 857
75,1 %
PUT 3.41
(none)
0:09.7
105 863
75,1 %
ZIPSERVER 2.12
(none)
0:03.7
105 900
75,1 %
LHA 2.55b
−we:
0:07.1
105 949
75,1 %
AR 1.10
(none)
0:14.8
105 949
75,1 %
SAR 1.0
(none)
0:13.9
105 957
75,1 %
ARJZ 0.15
(none)
0:04.4
105 995
75,1 %
SQZ 1.08.3
(none)
0:05.5
106 023
75,1 %
ZOO 2.10
h:
0:13.2
106 084
75,1 %
CROSSEPAC 1.35
Format=Binary
0:12.4
106 258
75,0 %
CODEC 3.21
−c10
0:38.4
106 498
75,0 %
WINZIP’95 6.3
(Normal)
0:02.8
106 527
75,0 %
SZIP 1.05xe
−o8
0:10.2
106 886
74,9 %
TURBOZIP 2.1
(Level 5)
0:03.5
106 934
74,9 %
NETZIP 4.1
(Method 4)
0:03.7
106 934
74,9 %
ARQ 3.2
(none)
0:14.5
106 998
74,9 %
BZIP2 0.1pl2
−5
0:15.1
107 662
74,9 %
BZIP2 0.1pl2
(none)
0:15.4
107 662
74,9 %
HPACK 0.79a0
−df
2:38.2
107 956
74,6 %
XPACK 1.67k
−a
0:19.4
108 183
74,6 %
95
96
přepínače
čas
kompr. velikost
poměr
ZET 0.10b
(none)
0:04.0
108 507
74,5 %
AMGC 2.3
(Normal)
0:04.4
108 673
74,5 %
SKY 1.15
(none)
0:05.1
108 673
74,5 %
SUPER PACK 2.0
(Normal)
0:05.3
108 673
74,5 %
X1 0.95a −>X
xem6l2
8:38.4
108 708
74,5 %
SZIP 1.05xe
(none)
0:08.6
109 555
74,3 %
HYPER 2.6
(none)
0:04.6
109 587
74,2 %
X1 0.94m −>X
xem6l2
0:10.3
111 433
73,8 %
SQWEZ 2.2
/s
0:17.1
112 393
73,6 %
ZipNAV 2.03
(Comp lvl 9)
0:11.6
112 436
73,6 %
LGHA 1.1
−2
0:27.9
113 013
73,4 %
HA 0.999b
e2
0:39.7
113 013
73,4 %
ZipNAV 2.03
(Comp lvl 5)
0:09.8
113 439
73,3 %
SZIP 1.03
(none)
0:05.6
113 503
73,3 %
SZIP 1.05xe
−o4
0:05.5
113 508
73,3 %
DEEPFREEZE 1.03
(none)
0:10.3
113 622
73,3 %
HAP 4.03
3
0:11.4
113 738
73,3 %
HAP 3.05bp
(none)
0:20.0
113 738
73,3 %
ZIP−ARCHIV 2.0
(none)
0:10.2
114 456
73,1 %
TSCOMP 1.3.21
−sh
0:11.4
114 474
73,1 %
TSCOMP 1.3.21
−sm
0:08.5
115 379
72,9 %
ZIP−ARCHIV 2.0
−m
0:05.5
117 841
72,3 %
X1 0.95a −>X
xem4
0:38.2
118 101
72,2 %
ELI 5750
(none)
0:09.6
118 615
72,1 %
ARX 1.0
(none)
0:11.0
118 701
72,1 %
LZOP 0.94w
−9
0:23.4
118 754
72,1 %
BVI 1.50
(none)
17:53.3
121 078
71,5 %
PKZIP 2.04g
−es
0:02.5
122 592
71,2 %
PAK 2.51
(none)
0:06.8
122 829
71,1 %
LHARK 0.4d
−tt
0:02.6
123 382
71,0 %
KBOOM 1.1
(none)
0:04.5
144 836
66,0 %
LARC 3.33
(none)
0:06.6
145 522
65,8 %
SQUASH 1.21
(none)
0:12.6
145 538
65,8 %
přepínače
čas
kompr. velikost
poměr
JAM − Aug1996
(none)
0:04.0
146 269
65,6 %
MSCOMPRESS 2.0
(none)
0:14.3
148 388
65,1 %
LZOP 0.94w
(none)
0:02.3
152 766
64,1 %
DWC 5.10
(none)
0:03.9
157 188
63,1 %
JRCHIVE 1.10
−v
0:05.3
157 909
63,1 %
MDCD 1.0
(none)
0:03.5
158 402
62,8 %
ZOO 2.10
:
0:07.5
158 449
62,8 %
NULIB 3.24
(none)
0:03.5
158 955
62,6 %
DWC 5.10
z
0:04.3
159 263
62,6 %
PKARC 3.5
(none)
0:02.9
159 751
62,5 %
PKPAK 3.61
(none)
0:03.8
159 815
62,4 %
ARC 6.02
(none)
0:03.0
161 589
62,0 %
NULIB 3.24
c5
0:03.5
163 706
61,5 %
SPLINT 2.1
(none)
0:08.9
167 333
60,7 %
GAS 2.0
(none)
1:04.8
219 528
48,4 %
DPA 1.1a
(none)
0:10.1
229 567
46.0 %
Výsledky testu:
777 0.03b5
PKZIP 2.6 Win95
Nejlepší poměr času komprese a kompresního poměru:
ARI 2.16m
Třetí test (soubor EXE s možností spuštění)
Binární soubor EXE. Archiv byl vytvořen tak, aby soubor bylo možné spustit i v archivu
bez nutnosti explicitní dekomprese a uložení dekomprimovaného souboru na disk.
Nekomprimovaná velikost 341 444 bajtů
97
Tip:
V pvním sloupci je uveden název archivačního programu, ve druhém doba potřebná pro
kompresi (sekundy.desetiny), ve třetím doba potřebná pro spuštění souboru – tj. rozbalení a uložení v dynamické paměti RAM, ve čtvrtém velikost archivu. V posledním sloupci
je uveden kompresní poměr.
98
přepínače
čas
kompr. velikost
poměr
WWPACK 3.05b5 −v−
27.83
0.2107
125 422
63,3 %
WWPACK 3.05b5
27.83
0.2103
125 447
63,3 %
WWPACK 3.05b5 −f
27.05
0.1596
127 626
62,6 %
APACK 0.61b
177.50
0.2484
127 727
62,6 %
UCEXE 2.4
04.69
0.1609
129 141
62,2 %
AINEXE 2.23
03.59
0.3374
132 014
61,3 %
XPACK 1.67l −4
11.54
1.5413
132 898
61,1 %
COMPACK 4.5
05.66
0.0846
134 012
60,8 %
LGLZ 1.04b−h−u
04.48
0.2162
134 071
60,7 %
LGLZ 1.04b
04.41
0.2256
134 884
60,5 %
LGLZ 1.04b −f
04.41
0.1306
135 036
60,5 %
AVPACK 1.22
03.70
0.1205
136 672
60,0 %
COMPACK 4.5 −g
04.04
0.0897
137 420
59,8 %
XPACK 1.67l −5
08.08
0.2240
138 985
59,3 %
PKLITE 2.01
03.93
0.1528
139 731
59,1 %
PROPACK 2.08 −m1
45.93
0.3446
141 154
58,7 %
RJCRUSH 1.10
03.72
0.1866
141 187
58,7 %
PGMPAK 0.15
10.33
0.1868
142 160
58,4 %
DIET 1.45f
02.75
0.2128
142 771
58,2 %
DIET 1.45f −g
02.75
0.1710
142 874
58,2 %
ELITE 1.0bf
02.65
0.1933
143 360
58,0 %
LZEXE 1.00
04.50
0.1297
143 432
58,0 %
PACKWIN 1.0
03.91
0.1297
143 489
58,0 %
TINYPROG 3.9
16.83
0.1209
144 080
57,8 %
PROPACK 2.08 −m2
20.86
0.0844
155 224
54,5 %
přepínače
čas
kompr. velikost
poměr
CRUNCH 1.0
02.32
1.7773
218 048
36,1 %
AXE 2.2
03.41
0.3932
248 365
27,3 %
EXEPACK 4.06
01.01
0.0536
331 407
02.9 %
Výsledky testu:
WWPACK 3.05b5
CRUNCH 1.0
Nejrychlejší dekomprese:
EXEPACK 4.06
Nejlepší poměr doby komprese a kompresního poměru:
UCEXE 2.4
Čtvrtý test (soubor BMP)
Soubor BMP (24 bitů na pixel) Nekomprimovaná velikost 558 054 bajtů
Tip:
přepínače
čas
kompr. velikost
poměr
ERI32 3.0c3
−3
0:14.3
115 312
79,3 %
ERI32 3.0c3
−m3 −3
0:10.3
115 338
79,3 %
ERI32 3.0c3
−m2 −3
0:08.6
120 139
78,5 %
UFA 0.03b5
−m4 −mx
2:23.9
135 781
75,7 %
UFA32 0.03b4
−m4 −mx
4:23.8
135 891
75,6 %
UFA32 0.03b4
−m4 −mq2
0:22.5
140 240
74,9 %
UFA 0.03b5
−m4 −mq2
0:22.6
140 240
74,9 %
777 0.03b4
−m4 −mx
6:48.8
142 129
74,5 %
99
100
přepínače
čas
kompr. velikost
poměr
777 0.03b5
−m4
4:51.6
142 166
74,5 %
ESP 1.92
/m0 /mm2 /ml7
0:20.6
147 142
73,6 %
ESP 1.92
/m2 /mm2 /ml7
0:18.2
148 032
73,5 %
777 0.03b5
−m3 −md2
5:39.3
158 841
71,5 %
777 0.03b4
−m3 −md2 −mx
7:12.2
158 849
71,5 %
UHARC 0.2
−m3 −md1024
1:05.2
171 552
69,3 %
UHARC 0.2
−m2 −md1024
0:41.2
173 128
69,0 %
UHARC 0.2
−m1 −md1024
0:34.6
174 374
68,8 %
RKIVE 1.90b1
−mt
2:17.8
175 674
68,5 %
RKIVE 1.4
−mtx
1:05.4
176 883
68,3 %
RKIVE 1.4
−mt
0:52.0
176 918
68,3 %
SZIP 1.05xe
−io12b6
0:18.4
176 954
68,3 %
SZIP 1.05xe
−ib6
0:12.0
178 096
68,3 %
BOA 0.50b
−m15
1:14.0
178 665
68,0 %
BOA 0.50b
(none)
1:04.8
180 210
67,7 %
SZIP 1.05xe
−io4b6
0:07.6
182 374
67,3 %
ARI 2.16m
−c−2
2:15.8
191 486
65,7 %
RKIVE 1.90b1
−mb
1:37.5
192 315
65,5 %
RKIVE 1.4
−mb
0:50.3
192 582
65,5 %
RKIVE 1.90b1
−mf
1:31.8
194 612
65,1 %
RKIVE 1.4
−mf
0:42.4
194 825
65,1 %
ARI 2.16m
−m3−2
0:35.0
195 974
64,9 %
ARI 2.16m
−m2−2
0:30.3
198 317
64,5 %
HAP 4.03
3
0:12.6
203 223
63,6 %
UC v2.37 beta
(Max)
1:00.9
209 556
62,4 %
UC2 v3.0 PRO
(Max)
1:01.7
209 560
62,4 %
SZIP 1.03
(none)
0:09.7
210 956
62,2 %
X1 0.95a −>X
xem4l2
0:59,5
215 044
61,5 %
X1 0.95a −>X
xem3
0:59,9
216 348
61,2 %
ACB 2.00c
(u)f
2:29.5
216 909
61,1 %
UFA 0.03b5
−m3 −md2 −mx
1:59,3
217 106
61,1 %
UFA32 0.03b4
−m3 −md2 −mx
3:29.0
217 111
61,1 %
BZIP2 0.1pl2
−5
0:17.2
217 311
61,1 %
přepínače
čas
kompr. velikost
poměr
BZIP2 0.1pl2
(none)
0:17.3
217 311
61,1 %
ESP 1.9
/m0 /mm
0:08.3
219 681
60,6 %
ACB 2.00c
(b)f
1:41.0
219 760
60,6 %
ACB 1.14a
(b)f
1:25.4
223 341
60,0 %
ACB 2.00c
(B)f
1:10.6
224 829
59,6 %
X1 0.95a −>X
xem7
0:12.2
226 013
59,5 %
LGHA 1.1
−2
0:42.7
228 372
59,1 %
HA 0.999b
e2
1:02.2
228 372
59,1 %
RAR 2.02
−m5 −mmf
0:09.1
230 450
58,7 %
WinRAR 2.02
−mmf −md256
0:09.6
230 463
58,7 %
CODEC 3.21
−c10
1:01.9
238 875
57,2 %
CABARC 1.0
−m LZX:21
0:26.3
238 957
57,2 %
X1 0.95a −>X
xem6l2
3:17.7
240 022
57.0 %
QUANTUM 0.97
−c7 −t20
27:06.9
246 934
55,8 %
QUANTUM 0.97
−c5
6:34.5
249 954
55,2 %
WinRAR 2.02
−m5 −md256
0:30.3
253 092
54,6 %
ACE32 1.1b
−m5 −d1024
0:14.4
253 981
54,5 %
ACE 1.1b
−m5 −d1024
0:15.8
253 981
54,5 %
CABARC 1.0
−m LZX:15
0:19.9
254 639
54,4 %
JAR32 1.02
−m3
0:20.7
255 204
54,3 %
JAR32 1.02
−m4
0:20.9
255 204
54,3 %
WinRAR 2.02
−md256
0:13.5
255 599
54,2 %
QUANTUM 0.97
−c3 −t20
0:41.2
255 982
54,1 %
JAR32 1.02
(none)
0:15.1
257 165
54,3 %
QUANTUM 0.97
(none)
0:38.4
257 768
53,8 %
HPACK 0.79a0
−df
1:30.2
258 766
53,6 %
DEEPFREEZE 1.03
(none)
0:12.1
259 476
53,5 %
ACE32 1.1b
−d1024
0:11.6
260 513
53,3 %
ACE 1.1b
−d1024
0:13.1
260 513
53,3 %
UC2 v3.0 PRO
(Default)
0:09.8
261 852
53,1 %
UC v2.37 beta
(Default)
0:09.3
261 864
53,1 %
YAC 1.02
(none)
0:23.4
262 213
53.0 %
JAR16 1.02
−m4
0:28.0
262 372
53.0 %
101
102
přepínače
čas
kompr. velikost
poměr
JAR16 1.02
−m3
0:27.9
262 376
53.0 %
HAP 3.05bp
(none)
0:27.4
262 589
52,9 %
RAR 2.02
−m5
0:12.7
263 239
52,8 %
JAR16 1.02
(none)
0:22.3
264 380
52,6 %
AMGC 2.3
(Max)
0:21.0
264 508
52,6 %
SUPER PACK 2.0
(Max)
0:21.3
264 508
52,6 %
SKY 1.15
−m4
0:20.6
264 508
52,6 %
RAR 2.02
(none)
0:07.8
265 233
52,8 %
QUARK 1.0beta
(none)
0:16.6
265 504
52,4 %
SQZ 1.08.3
−q(ALT236)
0:18.6
266 007
52,3 %
PROPACK 2.08
d
0:55.4
266 977
52,2 %
AIN 2.32
/m1
0:06.8
267 892
52.0 %
SQZ 1.08.3
(none)
0:07.9
267 935
52.0 %
ARJZ 0.15
−mp9
0:10.8
268 173
51,9 %
LHA 2.67(Win32)
−wd:\
0:09.5
268 339
51,9 %
ZIPSERVER 2.12
(none)
0:05.0
269 072
51,8 %
AMGC 2.3
(Normal)
0:07.1
269 249
51,8 %
SUPER PACK 2.0
(Normal)
0:07.4
269 249
51,8 %
SKY 1.15
(none)
0:07.9
269 249
51,8 %
AIN 2.32
(none)
0:05.5
269 693
51,7 %
PKZIP 2.04g
−ex
0:09.7
270 073
51,6 %
ARJZ 0.15
(none)
0:06.5
270 404
51,5 %
PKZIP 2.6 Win95
(Extra)
0:08.0
270 695
51,5 %
PKZIP 2.04g
(none)
0:06.2
271 355
51,4 %
BVI 1.20
(none)
0:12.9
271 892
51,3 %
LGHA 1.1
−1
0:13.3
272 361
51,2 %
PKZIP 2.6 Win95
(Norm)
0:04.2
272 620
51,1 %
ARJ 2.60
−jm −e
0:12.0
273 371
51.0 %
CODEC 3.21
(none)
0:06.9
274 263
50,9 %
ARJ 2.60
−e
0:07.9
274 498
50,8 %
ZET 0.10b
−eh
0:19.7
276 287
50,5 %
LIMIT 1.2
−mx
0:15.3
276 374
50,5 %
HA 0.999b
e1
0:15.7
276 919
50,4 %
přepínače
čas
kompr. velikost
poměr
LIMIT 1.2
(none)
0:10.5
277 646
50,2 %
TURBOZIP 2.1
(Level 9)
0:12.6
278 086
50,2 %
WINZIP’95 6.3
(Max)
0:10.4
278 139
50,2 %
INFO−ZIP 2.2DOS
−9 −j
0:11.6
278 157
50,2 %
INFO−ZIP 2.2NT
−9 −j
0:11.4
278 165
50,2 %
NETZIP 4.1
(Deflate)
0:08.1
278 254
50,1 %
GZIP 1.2.4
−9
0:13.8
278 511
50,1 %
LHARK 0.4d
−tob
0:14.4
279 644
49,9 %
ZET 0.10b
(none)
0:06.1
279 697
49,9 %
BSArc 2.0.0
−+1
0:11.6
279 926
49,8 %
INFO−ZIP 2.2NT
−j
0:06.5
280 203
49,8 %
INFO−ZIP 2.2DOS
−j
0:07.0
280 230
49,8 %
GZIP 1.2.4
(none)
0:08.5
280 547
49,8 %
WINZIP’95 6.3
(Normal Comp)
0:05.2
281 407
49,6 %
TURBOZIP 2.1
(Level 5)
0:05.6
281 657
49,5 %
NETZIP 4.1
(Method 4)
0:05.7
281 657
49,5 %
BSArc 2.0.0
(none)
0:07.4
281 906
49,5 %
LHARK 0.4d
(none)
0:07.0
283 718
49,2 %
ZipNAV 2.03
(Comp lvl 9)
0:14.4
284 134
49,1 %
MSXIE 1.40
(none)
0:26.9
284 652
49.0 %
LHA 2.55b
−we:
0:11.0
284 728
49.0 %
AR 1.10
(none)
0:21.4
284 728
49.0 %
SAR 1.0
(none)
0:20.7
284 736
49.0 %
ZOO 2.10
h:
0:19.6
284 863
49.0 %
ZipNAV 2.03
(Comp lvl 5)
0:13.8
285 003
48,9 %
CROSSEPAC 1.35
Format=Binary
0:19.9
285 037
48,9 %
PUT 3.41
(none)
0:14.3
285 321
48,9 %
LZOP 0.94w
−9
0:18.9
292 217
48,9 %
JAM − Aug1996
(none)
0:05.6
292 502
48,9 %
SQWEZ 2.2
/s
0:18.9
294 491
48,9 %
ARQ 3.2
(none)
0:21.1
294 499
47,2 %
ELI 5750
(none)
0:08.1
298 523
46,5 %
PAK 2.51
(none)
0:07.0
299 270
46,4 %
103
přepínače
čas
kompr. velikost
poměr
HYPER 2.6
(none)
0:07.5
299 652
46,3 %
ARX 1.00
(none)
0:15.4
305 944
45,2 %
ZIP−ARCHIV 2.0
(none)
0:08.7
309 981
44,5 %
TSCOMP 1.3.21
−sh
0:09.6
309 999
44,4 %
NULIB 3.24
c5
0:05.2
311 291
44,2 %
TSCOMP 1.3.21
−sm
0:07.9
320 196
42,6 %
LHARK 0.4d
−tt
0:03.5
324 454
41,9 %
PKZIP 2.04g
−es
0:03.6
326 338
41,5 %
DWC 5.10
z
0:06.1
332 533
40,4 %
KBOOM 1.1
(none)
0:06.5
338 962
39,3 %
LZOP 0.94w
(none)
0:02.9
340 728
38,9 %
LARC 3.33
(none)
0:08.0
341 741
38,8 %
SQUASH 1.21
(none)
0:15.3
341 763
38,8 %
MSCOMPRESS 2.0
(none)
0:11.9
344 591
38,3 %
DWC 5.10
(none)
0:05.7
345 441
38,1 %
MDCD 1.0
(none)
0:04.6
352 285
36,9 %
ZOO 2.10
:
0:10.0
352 332
36,9 %
SPLINT 2.1
(none)
0:16.1
355 504
36,3 %
PKARC 3.5
(none)
0:03.4
359 046
35,7 %
PKPAK 3.61
(none)
0:06.5
359 694
35,7 %
ZIP−ARCHIV 2.0
−m
0:07.3
361 149
35,3 %
JRCHIVE 1.10
−v
0:07.4
371 531
33,4 %
ARC 6.02
(none)
0:04.1
374 737
32,8 %
NULIB 3.24
(none)
0:05.2
388 521
30,4 %
DPA 1.1a
(none)
0:13.9
393 725
29,4 %
GAS 2.0
(none)
1:50.3
429 982
22,9 %
Výsledky testu:
104
ERI32 3.0c3
LZOP 0.94w
ERI32 3.0c3
Pátý test (21 různých souborů)
Pátý test byl proveden na vstupních datech představovaných 21 soubory (binárními textovými i grafickými), které byly všechny uloženy v jediném adresáři.
Nekomprimovaná velikost všech souborů dohromady 3 255 838 bajtů
Tip:
při testování, ve třetím čas potřebný pro dekompresi (minuty:sekundy.desetiny), ve
čtvrtém čas potřebný pro kompresi, v pátém velikost komprimovaného archivu a v posledním kompresní poměr. Archivační programy jsou srovnány podle dosaženého kompresního poměru od nejlepšího k nejhoršímu.
přepínače
čas
BOA 0.50b
−m15 −s
6:03.9
kompr. velikost
poměr
775 267
76,2 %
ACB 2.00c
(u)f
ACB 2.00c
(b)f
14:50.5 14:29.6
795 714
75,6 %
10:39.5 10:21.8
805 301
75,3 %
BOA 0.50b
RKIVE 1.90b1
−s
5:09.3
807 590
75,2 %
−mt
10:45.1 12:33.9
810 071
75,1 %
RKIVE 1.4
−mtx
3:37.8
818 705
74,9 %
RKIVE 1.4
−mt
3:20.5
4:24.0
819 836
74,8 %
ACB 2.00c
(B)f
8:01.2
7:44.8
823 133
74,7 %
ACB 1.14a
(b)f
9:50.6
9:41.4
831 676
74,5 %
X1 0.95a −>X
xem4l2
3:00.3
2:45.3
836 761
74,3 %
777 0.03b5
−mg −mu16
13:06.4 28:34.6
837 103
74,3 %
X1 0.95a −>X
xem3
3:02.1
2:48.7
840 237
74,2 %
UFA 0.03b5
−mg −mu16
8:35.7
14:40.2
841 297
74,2 %
SZIP 1.05xe+TAR
−b33
1:38.0
1:31.0
872 078
73,2 %
SZIP 1.05xe+TAR
(none)
1:00.2
1:14.1
872 134
73,2 %
RKIVE 1.4
−mb
2:01.2
3:32.3
874 701
73,1 %
777 0.03b4
−m5 −mu16 –s
11:55.1 10:57.7
875 306
73,1 %
777 0.03b5
−m5 −mu16 –s
17:39.1 17:03.6
875 306
73,1 %
UFA 0.03b5
−m5 −mu16 –s
10:17.4 9:41.3
875 306
73,1 %
5:57.4
5:00.1
6:11.2
105
106
přepínače
čas
kompr. velikost
poměr
UFA32 0.03b4
−m5 −mu16 –s
11:49.4 10:01.6
875 306
73,1 %
777 0.03b4
−m2 −mx −s
9:19.5
58:17.1
875 428
73,1 %
777 0.03b5
−m2 −md512
−s 9:39.5 22:39.1
879 306
73,0 %
RKIVE 1.90b1
−mb
4:47.4
883 491
72,9 %
6:34.8
LGHA 1.1
(none)
2:04.6
3:35.6
883 649
72,9 %
HA 0.999b
e12
2:44.8
4:30.3
883 651
72,9 %
777 0.03b4
−m2 −md512 −s
9:43.6
22:53.7
883 780
72,9 %
HA 0.999b
e2
3:03.2
3:01.7
884 305
72,8 %
LGHA 1.1
−2
2:19.6
2:09.2
884 352
72,8 %
BZIP 0.21+TAR
−5
0:56.8
1:52.7
889 247
72,7 %
BZIP2 0.1+TAR
(none)
0:36.3
1:37.6
892 473
72,6 %
CABARC 1.0
−m LZX:21
0:08.6
23:17.5
897 086
72,4 %
BZIP2 0.1+TAR
−5
0:34.0
1:35.8
899 321
72,4 %
SZIP 1.03+TAR
(none)
1:11.3
0:54.3
899 432
72,4 %
UFA 0.03b5
−s
1:07.5
7:47.4
902 538
72,3 %
X1 0.95a −>X
xem6l2ob
25:21.1 24:29.4
902 837
72,3 %
RKIVE 1.90b1
−mf
5:05.0
6:00.0
904 491
72,2 %
JAR32 1.02
−m4
0:24.5
2:09.7
905 304
72,2 %
QUANTUM 0.97
−c7 −t20
1:11.6
135:27.5 905 520
72,2 %
RKIVE 1.4
−mf
1:51.9
2:32.4
906 457
72,2 %
UFA32 0.03b4
−m2 −mx −s
1:09.4
18:11.3
908 738
72,1 %
JAR32 1.02
−m3
0:24.7
1:18.8
909 588
72,1 %
JAR32 1.02
(none)
0:28.8
0:55.5
912 517
72,0 %
UFA32 0.03b4
−m2 −md512 −s
1:09.8
13:19.7
917 322
71,8 %
X1 0.95a −>X
xem7
0:31.6
0:57.1
919 255
71,8 %
UHARC 0.2
−m3 −md1024
1:00.7
6:13.9
919 891
71,7 %
CODEC 3.21
−c10
3:27.8
3:12.1
920 906
71,7 %
ERI32 3.0c
−md4−hc4k−ho
0:54.9
14:10.4
931 042
71,4 %
ERI32 3.0c3
−md4−hc4k−ho
0:40.0
15:16.5
931 084
71,4 %
QUANTUM 0.97
−c5
1:13.1
37:59,2
934 429
71,3 %
JAR16 1.02
−m4
0:45.6
1:38.8
937 184
71,2 %
ERI32 3.0c
−m3−hc4k−ho
0:57.2
6:26.1
938 861
71,2 %
ERI32 3.0c3
−m3−hc4k−ho
0:48.7
6:38.6
938 870
71,2 %
přepínače
čas
kompr. velikost
poměr
JAR16 1.02
−m3
0:45.8
1:40.8
938 914
71,2 %
ERI32 3.0c
−md3−m3−hc4k−ho
0:56.7
6:15.3
946 114
71,9 %
ERI32 3.0c3
−md3−m3−hc4k−ho
0:48.5
6:22.6
946 132
71,9 %
JAR16 1.02
(none)
0:46.1
1:12.1
947 412
71,9 %
WinRAR 2.02
−m5 –mm −md1024 −s 0:11.2
7:30.4
948 230
71,9 %
UHARC 0.2
−m2 −md1024
1:03.3
4:03.9
953 613
71,7 %
HAP 4.03
3
1:07.6
0:57.7
969 576
71,2 %
HAP 3.05bp
(none)
1:45.3
1:34.3
969 576
71,2 %
QUANTUM 0.97
−c3 −t20
1:12.5
7:09.5
972 250
71,1 %
WinRAR 2.02
−m5−mm−md1024
0:11.8
4:13.1
972 847
71,1 %
QUANTUM 0.97
(none)
1:14.0
5:11.1
981 912
69,8 %
WinRAR 2.02
−mm−md1024−s
0:11.1
1:41.1
985 965
69,7 %
ACE 1.1b
−m5 −d1024 −s
0:24.7
1:33.4
986 687
69,7 %
ACE32 1.1b
−m5 −d1024 −s
0:15.3
1:46.9
986 687
69,7 %
ARI 2.16m
−ho
0:19.1
13:52.1
995 625
69,4 %
UHARC 0.2
−m1 −md1024
1:03.8
2:55.9
997 730
69,4 %
CABARC 1.0
−m LZX:15
0:08.8
1:52.7
1 003 418
69,2 %
ARI 2.16m
−m3 −ho
0:19.1
4:53.9
1 007 091
69,1 %
RAR 2.02
−m5 −mm −s
0:17.4
1:45.1
1 011 311
68,9 %
UC2 v3.0 PRO
o25 (Max)
0:16.0
94:51.3
1 022 160
68,6 %
YAC 1.02
(none)
0:38.1
1:56.7
1 022 810
68,6 %
HPACK 0.79a0
−df
0:37.5
11:42.7
1 023 107
68,6 %
RAR 2.02
−m5
0:16.0
1:39.0
1 025 600
68,5 %
UC v2.37 beta
(Max Comp)
0:17.6
2:06.6
1 026 592
68,5 %
UC2 v3.0 PRO
(Max Comp)
0:17.7
2:08.1
1 026 612
68,5 %
CRUSH 1.8+UC2
−n −u
0:27.9
2:13.5
1 032 742
68,3 %
LHARK 0.4d
−tob
0:14.5
1:28.6
1 035 887
68,2 %
ACE32 1.1b
−d1024 −s
0:15.3
0:48.5
1 036 887
68,2 %
ACE 1.1b
−d1024 −s
0:22.7
0:48.8
1 036 887
68,2 %
ARJZ 0.15
−mp9
0:10.7
1:25.7
1 038 117
68,1 %
RAR 2.02
(none)
0:16.4
0:48.2
1 040 803
68,0 %
ARJZ 0.15
(none)
0:11.6
0:53.1
1 047 190
67,8 %
UC2 v3.0 PRO
(Default)
0:18.7
0:53.9
1 053 814
67,6 %
107
108
přepínače
čas
UC v2.37 beta
(Default)
0:16.5
LIMIT 1.2
−mx
0:13.6
1:08.0
1 054 168
67,6 %
LHARK 0.4d
(none)
0:14.3
0:41.7
1 054 477
67,6 %
HA 0.999b
e
0:35.5
1:31.8
1 054 534
67,6 %
0:53.0
kompr. velikost
poměr
1 053 828
67,6 %
LGHA 1.1
−1
0:24.7
1:22.4
1 054 998
67,6 %
LIMIT 1.2
(none)
0:13.3
0:57.2
1 056 022
67,6 %
ZET 0.10b
−eh
0:14.7
1:05.8
1 056 082
67,6 %
CRUSH 1.8+HA
−n −h
0:49.9
1:54.4
1 057 050
67,5 %
GZIP 1.2.4+TAR
−9
0:40.2
1:53.3
1 060 868
67,4 %
PKZIP 2.6 Win95
(Extra)
0:07.2
0:40.1
1 061 851
67,4 %
SQZ 1.08.3
−q(ALT236)
0:16.4
1:49.7
1 062 541
67,4 %
WINZIP’95 6.3
(Max Comp)
0:08.3
1:06.6
1 063 059
67,3 %
SKY 1.15
−m4
0:19.4
2:19.6
1 063 253
67,3 %
SUPERPACK 2.0
(Max)
0:17.4
2:22.9
1 063 253
67,3 %
AMGC 2.3
(Max)
0:19.3
2:22.9
1 063 253
67,3 %
TAR 3.20+GZIP
cvf.9
0:42.7
1:31.5
1 063 365
67,3 %
INFO−ZIP 2.2DOS
−9 −j
0:18.3
1:04.5
1 063 437
67,3 %
TURBOZIP 2.1
(Level 9)
0:14.3
1:25.5
1 063 534
67,3 %
CRUSH 1.8+ZIP
−n
0:28.0
1:18.6
1 063 540
67,3 %
INFO−ZIP 2.2NT
−9 −j
0:33.5
1:04.8
1 063 605
67,3 %
NETZIP 4.1
(Deflate)
0:12.3
1:12.0
1 064 298
67,3 %
AIN 2.32
/m1
0:14.2
0:40.3
1 064 424
67,3 %
CODEC 3.21
(none)
0:23.4
0:50.6
1 065 105
67,3 %
PKZIP 2.04g
−ex
0:12.1
0:53.0
1 065 291
67,3 %
BSArc 2.0.0
−+1
0:15.4
1:18.5
1 065 316
67,3 %
LHA 2.67(Win32)
−wd:\
0:12.8
1:06.1
1 066 725
67,2 %
ESP 1.92
/m0
0:15.2
0:40.7
1 066 976
67,2 %
PKZIP 2.6 Win95
(Norm)
0:07.4
0:29.0
1 068 653
67,2 %
QUARK 1.0beta
(none)
0:22.3
1:44.4
1 070 012
67,1 %
INFO−ZIP 2.2DOS
−j
0:18.3
0:43.8
1 070 821
67,1 %
INFO−ZIP 2.2NT
−j
0:33.2
0:43.0
1 070 911
67,1 %
BSArc 2.0.0
(none)
0:16.6
0:54.9
1 071 007
67,1 %
SQZ 1.08.3
(none)
0:17.7
0:57.7
1 073 033
67,0 %
přepínače
čas
kompr. velikost
poměr
AIN 2.32
(none)
0:14.6
0:29.6
1 073 515
67,0 %
ESP 1.92
/m2
0:15.5
0:31.5
1 075 687
67,0 %
PKZIP 2.04g
(none)
0:13.2
0:33.3
1 077 029
66,9 %
CRUSH 1.8+ARJ
−n −j
0:29.1
1:30.9
1 080 203
66,8 %
SARJ 1.20
(none)
0:23.9
1:31.0
1 080 678
66,8 %
ARJ 2.60
−jm −e
0:15.9
1:08.9
1 081 242
66,8 %
WINZIP’95 6.3
(Normal)
0:08.2
0:34.0
1 082 623
66,7 %
ARJ 2.60
−e
0:16.0
0:52.9
1 083 615
66,7 %
NETZIP 4.1
(Method 4)
0:11.9
0:35.4
1 086 421
66,6 %
TURBOZIP 2.1
(Level 5)
0:14.1
0:36.7
1 086 421
66,6 %
ZIPSERVER 2.12
(none)
0:11.7
0:43.4
1 086 764
66,6 %
ZET 0.10b
(none)
0:15.4
0:30.8
1 088 073
66,6 %
SKY 1.15
(none)
0:18.8
0:46.4
1 114 793
65,8 %
AMGC 2.3
(Normal)
0:18.1
0:46.6
1 114 793
65,8 %
SUPERPACK 2.0
(Normal)
0:19.9
0:46.6
1 114 793
65,8 %
PROPACK 2.08+TAR
d
1:09.4
19:40.9
1 121 926
65,5 %
XPACK 1.67k
−a
0:28.7
3:04.7
1 129 558
65,3 %
DEEPFREEZE 1.03
(none)
0:19.3
0:45.5
1 130 474
65,3 %
MSXIE 1.40
(none)
0:48.9
2:07.4
1 141 485
64,9 %
LHA 2.55b
−we:
0:14.3
1:04.1
1 142 342
64,9 %
SAR 1.0
(none)
0:20.5
2:15.7
1 142 363
64,9 %
CROSSEPAC 1.35
For=Binary
0:39.6
1:55.3
1 142 972
64,9 %
ZOO 2.10
h:
0:18.5
1:56.5
1 143 300
64,9 %
PUT 3.41
(none)
0:18.4
1:22.6
1 144 112
64,9 %
ZipNAV 2.03
(Comp lvl 9)
0:31.0
1:38.1
1 153 830
64,6 %
ZipNAV 2.03
(Comp lvl 5)
0:35.6
1:33.2
1 158 207
64,4 %
PAK 2.51
(none)
0:14.4
0:37.4
1 191 686
63,4 %
ARQ 3.2
(none)
0:30.1
2:20.9
1 192 279
63,4 %
HYPER 2.6
(none)
0:26.9
0:36.2
1 192 602
63,4 %
LZOP 0.94w
−9
0:06.2
1:50.8
1 225 527
62,4 %
SQWEZ 2.2
/s
0:22.8
1:53.3
1 236 777
62,0 %
ZIP−ARCHIV 2
(none)
N/A
0:53.3
1 242 525
61,8 %
ELI 5750
(none)
N/A
0:38.8
1 242 687
61,8 %
109
přepínače
čas
kompr. velikost
poměr
ARX 1.00
(none)
0:22.3
1:29.8
1 251 447
61,6 %
LHARK 0.4d
−tt
0:14.5
0:12.3
1 252 349
61,5 %
PKZIP 2.04g
−es
0:12.1
0:13.1
1 263 818
61,2 %
TSCOMP 1.3.21
−sh
0:19.0
0:59,3
1 300 547
60,1 %
JAM − Aug1996
(none)
0:35.2
0:39.4
1 355 276
58,4 %
KBOOM 1.1+TAR
(none)
0:57.9
0:54.0
1 363 852
58,1 %
TSCOMP 1.3.21
−sm
0:19.6
0:47.6
1 396 823
57,1 %
DWC 5.10
z
0:14.3
0:32.1
1 399 119
57.0 %
ZIP−ARCHIV 2
−m
N/A
0:34.6
1 426 438
56,2 %
PKARC 3.5
(none)
0:13.3
0:14.2
1 450 280
55,5 %
PKPAK 3.61
(none)
0:14.1
0:25.8
1 457 040
55,2 %
DWC 5.10
(none)
0:13.2
0:30.4
1 457 467
55,2 %
LARC 3.33
(none)
0:19.0
1:11.1
1 471 881
54,8 %
SQUASH 1.21
(none)
0:32.4
1:16.8
1 471 992
54,8 %
MSCOMPRESS 2
(none)
0:33.6
1:36.4
1 484 603
54,4 %
ZOO 2.10
:
0:29.4
0:51.6
1 494 933
54,1 %
MDCD 1.0
(none)
0:22.5
0:22.0
1 495 906
54,1 %
JRCHIVE 1.10
−c −v
1:30.2
1:27.2
1 577 544
51,5 %
JRCHIVE 1.10
−v
0:56.0
1:02.2
1 578 882
51,5 %
ARC 6.02
(none)
0:17.0
0:19.1
1 590 185
51,2 %
SPLINT 2.1
(TARed)
1:30.0
1:29.4
1 602 025
50,8 %
FQ LZOP 0.94w
(none)
0:06.3
0:08.6
1 611 862
50,5 %
Výsledky testu:
110
BOA 0.50b
LZOP 0.94w
LZOP 0.94w
SZIP 1.05xe
Poznámka:
Přepínače uvedené v tabulce platí pouze pro kompresní část testů. Dekomprese probíhá
bez použití přepínačů.
Šestý test (126 malých textových souborů)
Dalšími testovacími daty bylo 126 malých textových souborů.
Nekomprimovaná velikost všech souborů dohromady 1 410 124 bajtů
Tip:
při testování, ve třetím čas potřebný pro dekompresi (minuty:sekundy.desetiny), ve
čtvrtém čas potřebný pro kompresi, v pátém velikost komprimovaného archivu a v posledním kompresní poměr. Archivační programy jsou srovnány podle dosaženého kompresního poměru od nejlepšího k nejhoršímu.
přepínače
čas
kompr. velikost
poměr
BOA 0.50b
−m15 −s
2:21.8
2:26.5
254 362
82.0 %
ACB 2.00c
(u)f
4:34.4
4:04.3
255 696
81,9 %
ACB 2.00c
(b)f
3:17.9
2:49.7
259 238
81,6 %
RKIVE 1.90b1
−mt
3:21.4
4:08.0
259 803
81,6 %
RKIVE 1.4
−mtx
1:27.4
1:52.1
261 029
81,5 %
RKIVE 1.4
−mt
1:20.5
1:21.8
263 724
81,3 %
ACB 1.14a
(b)f
3:27.9
3:00.2
264 187
81,3 %
ACB 2.00c
(B)f
2:3j921.6 2:02.6
265 551
81,2 %
RKIVE 1.4
−mb
1:00.7
1:07.4
274 233
80,6 %
BOA 0.50b
−s
2:09.9
2:12.9
277 933
80,3 %
RKIVE 1.90b1
−mb
1:00.8
2:04.2
278 118
80,3 %
777 0.03b5
−m2 −s
3:14.4
9:58,6
281 797
80,0 %
777 0.03b4
−m2 −mx −s
3:12.7
12:00.5
283 276
79,9 %
111
112
přepínače
čas
kompr. velikost
poměr
JAR32 1.02
−m4
0:24.2
1:39.7
284 802
79,8 %
RKIVE 1.90b1
−mf
1:08.9
1:52.0
285 443
79,8 %
RKIVE 1.4
−mf
0:57.3
0:49.0
286 799
79,7 %
UFA 0.03b5
−m2 −mx −s
0:45.0
5:26.5
290 886
79,4 %
JAR32 1.02
−m3
0:24.1
0:45.3
291 132
79,4 %
QUANTUM 0.97
−c7 −t20
0:47.4
44:22.8
291 582
79,3 %
SZIP 1.05xe+TAR
−o12
0:35.2
0:52.3
291 596
79,3 %
JAR32 1.02
(none)
0:24.5
0:34.9
292 170
79,3 %
CABARC 1.0
−m LZX:21
0:09.7
1:41.7
293 273
79,2 %
UFA32 0.03b4
−m2 −mx −s
0:45.9
7:32.7
293 335
79,2 %
UHARC 0.2
−m3 −md1024
0:54.2
2:29.5
294 425
79,1 %
JAR16 1.02
−m4
0:53.3
0:59,1
294 817
79,1 %
BZIP2 0.1+TAR
(none)
0:21.9
0:47.8
299 120
78,8 %
JAR16 1.02
−m3
0:53.4
1:00.3
299 289
78,8 %
JAR 1.02
(none)
0:55.2
0:45.1
301 881
78,6 %
SZIP 1.05xe+TAR
(none)
0:30.0
0:34.5
302 649
78,5 %
UHARC 0.2
−m2 −md1024
0:53.4
1:33.2
303 480
78,5 %
777 0.03b5
−m2 −md64 −s
3:43.7
8:25.8
304 926
78,4 %
777 0.03b4
−m2 −md64 −s
3:46.2
8:43.5
305 835
78,3 %
X1 0.95a −>X
xeum7
0:44.2
1:02.6
306 626
78,3 %
X1 0.95a −>X
xeum6l2
18:15.6 17:35.4
306 872
78,2 %
BZIP2 0.1+TAR
−5
0:22.1
0:46.9
307 047
78,2 %
ERI 3.0c3
−md4−hc4k−h430−ho
0:28.9
13:10.9
308 516
78,1 %
WinRAR 2.02
−m5−md1024−s
0:10.3
2:16.1
308 592
78,1 %
UFA32 0.03b4
−m5 −mu16 −s
7:23.1
6:48.1
310 180
78,0 %
UFA 0.03b5
−m5 −mu16 −s
9:12.2
11:28.3
310 180
78,0 %
777 0.03b5
−m5 −mu16 −s
6:48.0
5:58.7
310 180
78,0 %
777 0.03b4
−m5 −mu16 −s
7:30.2
7:20.7
310 180
78,0 %
ERI32 3.0c3
−m3 −ho
0:29.6
5:08.9
311 963
77,9 %
QUANTUM 0.97
−c3 −t20
0:46.6
2:50.0
312 793
77,8 %
ERI32 3.0c3
−md3−m3−ho
0:29.6
5:01.7
314 068
77,7 %
UFA 0.03b5
−m2 −md64 −s
0:33.3
3:13.4
314 787
77,7 %
UFA32 0.03b4
−m2 −md64 −s
0:34.1
5:09.7
315 445
77,6 %
přepínače
čas
kompr. velikost
poměr
X1 0.95a −>X
xeum4l2
1:39.5
1:08.7
315 510
77,6 %
UHARC 0.2
−m1 −md1024
0:54.0
1:11.5
316 141
77,6 %
SZIP 1.03+TAR
(none)
0:29.4
0:25.1
317 215
77,5 %
SZIP 1.05xe+TAR
−o4
0:28.5
0:22.9
317 221
77,5 %
QUANTUM 0.97
(none)
0:47.3
2:08.6
317 598
77,5 %
WinRAR 2.02
−md1024 −s
0:10.6
0:43.8
319 162
77,4 %
X1 0.95a −>X
xeum3
1:37.7
1:08.1
321 287
77,2 %
ACE 1.1b
−m5 −d1024 −s
0:35.3
0:42.4
322 236
77,0 %
ACE32 1.1b
−m5 −d1024 −s
0:21.4
1:06.5
322 236
77,0 %
ARI 2.16m
−ho
0:07.7
12:30.3
329 718
76,6 %
YAC 1.02
(none)
0:43.7
0:53.9
332 211
76,4 %
ACE 1.1b
−d1024 −s
0:35.6
0:30.0
335 624
76,2 %
ACE32 1.1b
−d1024 −s
0:21.2
0:39.3
335 624
76,2 %
RAR 2.02
−m5 −s
0:45.8
0:42.4
338 585
76,0 %
BVI 1.20+TAR
(none)
0:22.3
0:51.3
341 090
75,8 %
UC2 v3.0 PRO
(Max Comp)
0:39.6
1:06.1
346 402
75,2 %
ESP 1.92
/m0
0:34.5
0:23.2
351 637
75,1 %
ESP 1.92
/m2
0:33.4
0:21.2
353 665
74,9 %
UC2 v3.0 PRO
(Default)
0:38.1
0:26.7
354 504
74,9 %
5:16.8
ARI 2.16m
−ho−z−t−e
0:10.8
BVI 1.50+TAR
(none)
12:21.1 12:40.6
358 859
74,6 %
359 317
74,5 %
CABARC 1.0
−m LZX:15
0:09.0
1:01.1
360 771
74,4 %
SARJ 1.21
(none)
0:35.9
0:39.3
368 841
73,8 %
HPACK 0.79a0
−df −u
0:33.4
1:20.5
369 574
73,8 %
CRUSH 1.8+HA
−n −h
0:45.6
0:54.0
369 675
73,8 %
CRUSH 1.8+ZIP
−n
0:35.1
0:39.0
374 088
73,5 %
AIN 2.32
/m1
0:25.5
0:18.6
376 974
73,3 %
AIN 2.32
(none)
0:26.0
0:16.3
379 248
73,1 %
GZIP 1.2.4+TAR
−9
0:15.8
0:44.2
381 657
72,9 %
HA 0.999b
e12
2:22.1
3:09.5
387 243
72,5 %
HA 0.999b
e2
2:25.5
2:34.6
387 285
72,5 %
LGHA 1.1
(none)
1:16.8
1:22.9
387 289
72,5 %
LGHA 1.1
−2
1:17.2
0:57.2
387 332
72,5 %
113
114
přepínače
čas
CRUSH 1.8+ARJ
−n −j
0:36.6
0:46.3
kompr. velikost
poměr
387 715
72,5 %
CODEC 3.21
−c10
2:01.3
1:40.4
388 924
72,4 %
PROPACK 2.08+TAR
d
0:26.0
3:49.6
404 029
71,3 %
HAP 4.03
3
0:45.9
0:28.4
404 251
71,3 %
HAP 3.05bp
(none)
0:48.6
0:30.7
404 251
71,3 %
DEEPFREEZE 1.03
(none)
0:15.9
0:24.8
414 620
70,6 %
ZET 0.10b
−eh
0:26.9
0:21.3
424 931
69,9 %
HA 0.999b
e1
0:35.5
1:04.2
430 338
69,5 %
LGHA 1.1
−1
0:33.9
0:29.3
430 601
69,5 %
HPACK 0.79a0
−df
0:34.4
0:50.2
433 956
69,2 %
ZET 0.10b
(none)
0:27.5
0:14.6
435 459
69,1 %
LIMIT 1.2
−mx
0:29.7
0:23.5
436 224
69,1 %
LIMIT 1.2
(none)
0:27.2
0:19.0
436 793
69,0 %
QUARK 1.0beta
(none)
0:53.1
0:31.2
438 482
68,9 %
LHARK 0.4d
−tob
0:49.4
0:16.0
438 832
68,9 %
SQZ 1.08.3
−q(ALT236)
0:34.5
0:40.3
438 840
68,9 %
SKY 1.15
−m4
0:51.7
0:35.1
440 188
68,8 %
AMGC 2.3
(Max)
0:30.2
0:37.0
440 188
68,8 %
SUPERPACK 2.0
(Max)
0:28.7
0:37.2
440 188
68,8 %
LHARK 0.4d
(none)
0:48.4
0:13.6
440 452
68,8 %
WinRAR 2.02
−m5 −md256
0:15.1
0:40.2
440 645
68,8 %
SQZ 1.08.3
(none)
0:32.2
0:21.9
440 930
68,7 %
RAR 2.02
−m5
0:47.6
0:22.7
441 462
68,7 %
LHA 2.67(Win32)
−wd:\
0:14.6
0:30.1
443 328
68,6 %
RAR 2.02
(none)
0:47.5
0:17.1
443 520
68,7 %
ARJZ 0.15
−mp9 −jh
0:25.7
0:26.4
444 685
68,5 %
ARJ 2.60
−jm −e
0:31.6
0:25.4
444 702
68,5 %
ARJ 2.60
−e
0:30.0
0:20.4
445 261
68,4 %
CODEC 3.21
(none)
0:30.4
0:21.1
446 404
68,3 %
PKZIP 2.04g
−ex
0:22.7
0:15.5
446 734
68,3 %
ARJZ 0.15
(none)
0:26.3
0:19.0
447 059
68,3 %
TURBOZIP 2.1
(Level 9)
0:26.9
0:29.8
447 182
68,3 %
WINZIP’95 6.3
(Max Comp)
0:10.2
0:26.7
447 184
68,3 %
přepínače
čas
kompr. velikost
poměr
NETZIP 4.1
(Deflate)
0:16.3
0:23.9
447 349
68,3 %
INFO−ZIP 2.2DOS
−9 −j
0:28.8
0:26.5
449 452
68,1 %
INFO−ZIP 2.2NT
−9 −j
2:10.8
0:32.7
450 460
68,1 %
PKZIP 2.04g
(none)
0:24.7
0:13.8
450 621
68,0 %
PKZIP 2.6 Win95
(Extra)
0:08.5
0:18.7
451 145
68,0 %
MSXIE 1.40
(none)
1:05.1
0:57.1
451 560
68,0 %
ZIPSERVER 2.12
(none)
0:25.1
0:30.6
451 966
67,9 %
INFO−ZIP 2.2DOS
−j
0:30.2
0:18.8
452 193
67,9 %
LHA 2.55b
−we:
0:23.8
0:27.7
453 009
67,9 %
SAR 1.0
(none)
0:30.0
0:57.6
453 010
67,9 %
PKZIP 2.6 Win95
(Norm)
0:08.7
0:15.9
453 071
67,9 %
INFO−ZIP 2.2NT
−j
2:09.4
0:23.9
453 183
67,9 %
PUT 3.41
(none)
0:25.5
0:38.3
453 256
67,9 %
WINZIP’95 6.3
(Norm Comp)
0:09.7
0:17.5
453 649
67,8 %
NETZIP 4.1
(Method 4)
0:16.2
0:16.5
454 374
67,8 %
TURBOZIP 2.1
(Level 5)
0:26.9
0:16.8
454 374
67,8 %
SUPERPACK 2.0
(Normal)
0:29.1
0:18.1
454 517
67,8 %
AMGC 2.3
(Normal)
0:29.4
0:18.5
454 517
67,8 %
SKY 1.15
(none)
0:50.3
0:18.4
454 517
67,7 %
CROSSEPAC 1.35
For=Binary
0:40.1
0:48.7
454 564
67,8 %
ZOO 2.10
h:
0:24.5
0:46.1
457 510
67,6 %
ARQ 3.2
(none)
1:14.3
1:04.9
466 696
66,9 %
HYPER 2.6
(none)
0:30.9
0:21.8
476 258
66,2 %
ZIP−ARCHIV 2.0
(none)
0:26.1
0:21.8
477 196
66,2 %
ELI 5750
(none)
N/A
0:26.1
489 477
65,3 %
ARX 1.0
(none)
0:30.3
1:02.6
492 937
65,0 %
SQWEZ 2.2
/s
0:36.6
0:53.6
495 451
64,9 %
PAK 2.51
(none)
0:25.0
0:21.7
495 698
64,8 %
LHARK 0.4d
−tt
0:49.4
0:10.3
498 942
64,6 %
PKZIP 2.04g
−es
0:22.1
0:10.5
507 638
64,0 %
TSCOMP 1.3.21
−sh
0:29.1
0:25.1
511 796
63,7 %
LZOP 0.94w
−9
0:06.0
0:37.1
524 589
62,8 %
KBOOM 1.1+TAR
(none)
0:17.1
0:14.3
532 484
62,2 %
115
přepínače
čas
JAM − Aug1996
(none)
0:22.7
ZIP−ARCHIV 2.0
−m
0:26.8
0:18.0
551 321
60,9 %
TSCOMP 1.3.21
−sm
0:29.4
0:23.1
553 674
60,7 %
SPLINT 2.1+TAR
(none)
0:28.2
0:35.1
575 488
59,2 %
MSCOMPRESS 2
(none)
0:36.5
0:56.1
576 620
59,1 %
LARC 3.33
(none)
0:29.7
0:26.1
576 730
59,1 %
2:22.2
poměr
547 268
61,2 %
SQUASH 1.21
(none)
1:24.2
0:42.6
576 744
59,1 %
DWC 5.10
z
0:27.2
0:30.9
613 071
56,5 %
DWC 5.10
(none)
0:29.0
0:30.5
616 664
56,3 %
PKARC 3.5
(none)
0:24.4
0:11.0
619 582
56,1 %
PKPAK 3.61
(none)
0:24.1
0:11.3
619 947
56,0 %
ZOO 2.10
:
0:28.8
0:25.0
628 259
55,4 %
MDCD 1.0
(none)
0:30.3
0:14.5
634 587
55,0 %
JRCHIVE 1.10
−c −v
1:06.4
0:55.1
644 196
54,3 %
JRCHIVE 1.10
−v
1:22.6
1:19.0
644 757
54,3 %
ARC 6.02
(none)
0:25.1
0:12.8
649 709
53,9 %
LZOP 0.94w
(none)
0:06.0
0:08.4
653 957
53,6 %
Výsledky testu:
116
kompr. velikost
BOA 0.50b
LZOP 0.94w
LZOP 0.94w
JAR32 1.02
Shrnutí
Všechny testy, jejichž výsledky jsou uvedeny na předcházejících stránkách, jsou
standardní pro zjišťování výkonových ukazatelů jednotlivých archivačních programů. Všimněte si obrovských rozdílů ve výsledcích, kterých dosáhly programy v testech. Tyto rozdíly již stojí za úvahu, který program pro archivaci dat zvolit. Na druhé straně je často třeba brát ohled i na to, aby byl daný archivační program dostupný i ostatním uživatelům.
Dále si všimněte, že ani jeden z u nás nejoblíbenějších archivačních programů
(RAR, ARJ, ZIP) nedosáhl ani zdaleka na příčky nejvyšší a to při žádném ze zvolených přepínačů.
A to nejdůležitější na závěr. Pokud chcete vyzkoušet některý z výše uvedených programů, kontaktujte některou z těchto internetových adres:
http://personal.nbnet.nb.ca
http://www.geocities.com
WinRAR
Archivační program RAR je jedním z nejoblíbenějších archivačních programů u nás. Je to
pravděpodobně způsobeno jeho příjemným uživatelským prostředím, které se velice podobá
Norton Commmanderu a má velice podobné ovládání (viz obr. 10)
117
Obr. 10
Prostředí archivačního programu RAR je skutečně „user – friendly“.
Pokud dáváte přednost intuitivnímu vytváření archivů v příjemném pracovním prostředí archivačního programu, bude pro vás jistě přínosem WinRAR, jehož poslední verze 2.02 byla
testována v kapitole zachycující výkonové ukazatele.
Tip:
Verze archivačního programu RAR pro MS-DOS (RAR 2.02) i pro systém Microsoft Windows (WinRAR 2.02) vykazují ve všech testech podobné výkonové ukazatele. Nezapomeňte však, že testy byly prováděny pouze pro případ spouštění programu WinRAR z programového řádku.
Oba tyto produkty jsou tedy přibližně srovnatelné, a proto může být možnost přechodu na
platformu Windows vítanou záležitostí.
118
Obr. 11
Pracovní prostředí programu WinRAR.
Tip:
Výhodou prostředí Windows je i u archivačních programů schopnost manipulace se soubory a zadávání příkazů pomocí techniky „Drag and drop“, používání pravého tlačítka
myši apod.
Výhody a možnosti líbivého prostředí Windows čtenář jistě odhalí sám. Zaměřme se proto
na funkce samotného archivačního programu. Ten lze spustit i přímo z programového řádku
s definovanými příkazy i přepínači specifikujícími mód činnosti programu.
Následující řádky přinášejí úplný popis těchto možností, které zároveň vyčerpávajícím způsobem popisují možnosti celého programu.
119
Příkazový řádek, ze kterého lze program WinRAR spustit, má obecně tento tvar:
WinRAR <command> [−<switch1>] [−<switchN>] <archive> [<files...>] [<@listfiles...>] [<path_to_extract\>]
Popis parametrů
■ command
udává funkci, kterou bude program vykonávat – např. archivaci,
přidání souboru do archivu, dekompresi, komentování archivu atd;
■
switch
přepínače udávající specifický typ prováděné operace – např. druh
vytvářeného archivu apod;
■
archive
název archivu, se kterým se bude pracovat;
■
files
názvy souborů, se kterými se bude pracovat;
■
listfiles
název adresáře obsahujícího soubory, se kterými se bude pracovat;
■
path_to_extract
používá se pouze při dekompresi archivu a specifikuje cílový adresář, do kterého budou soubory rozbaleny. Pokud tento adresář
neexistuje, WinRAR jej vytvoří.
Nyní se podívejme na jednotlivé příkazy (commands) a přepínače (switches) podrobněji.
Příkazy programu WinRAR
■ a – přidání souborů do archivu.
Tento příkaz se používá nejen pro přidávání souborů a složek do existujícího archivu,
ale také pro zakládání archivů nových.
Příklad:
Přidání všech souborů s příponou HLP z aktuálního adresáře do archivu help.rar.
WinRAR a help *.hlp
■
c – přidání komentáře k archivu.
Komentář je zobrazen vždy, když je s archivem manipulováno.
Tip:
Komentář může být obsažen v souboru, jehož název následuje za přepínačem –z.
120
Tip:
Maximální délka komentáře je 62 000 bajtů.
Příklad:
Komentář přidávaný k archivu Nazev.rar je obsažen v souboru info.txt.
WinRAR c -zinfo.txt Nazev
■
d – vymazat ze specifikovaného archivu určité soubory.
Příklad:
Vymazat všechny soubory s příponou BAK z archivu Obrazky.rar
WinRAR d obrazky *.bak
■
e – rozbalit soubory z archivu bez uvažované struktury adresářů.
Při rozbalování souborů se ignoruje hierarchická struktura adresářů, ve které byly soubory archivovány.
Příklad:
Rozbalit všechny soubory s příponou DOC do aktuálního adresáře, a to ze všech archivů RAR obsažených v tomto adresáři.
WinRAR e *.rar *.doc
■
f – aktualizovat soubory v archivu pouze v případě, že přidávaný soubor je novější než
soubor stejného jména, jenž je již v archivu obsažen. Viz také příkaz u.
Tip:
Příkaz f se používá stejně jako příkaz a.
■
k – zamknout archiv.
Tento příkaz má význam v tom, že zabrání jakékoli příští modifikaci archivu programem WinRAR.
121
Příklad:
Uzamknout archiv s názvem Dokumenty.rar.
WinRAR k dokumenty
■
m – přesunout soubory a složky do archivu.
Po úspěšném archivování souborů budou tyto soubory vymazány i se svou strukturou
adresářů a zůstanou pouze v komprimované formě v souboru.
Tip:
Tento příkaz se používá stejně jako příkaz a.
■
mf – přesunout soubory do archivu.
Na rozdíl od příkazu m budou v tomto případě po úspěšné archivaci vymazány pouze archivované soubory. Struktura adresářů, ve kterých byly tyto soubory uloženy zůstane nezměněna.
Tip:
■
r – opravit zničený archiv.
Pokus o opravu poničeného archivu sestává ze dvou fází. V první fázi se WinRAR pokouší najít v archivu informace, podle kterých by bylo možné archiv obnovit (viz příkaz rr). Pokud se to nepodaří, a pokud je archiv poničen tak, že není možné jej zcela
obnovit, bude ve druhé fázi obnovena pouze jeho struktura, která umožní rozbalit nepoškozené soubory.
Tip:
Pokud je druhá fáze uplatněna na kompaktní archiv (solid archive), bude obnoven
pouze první soubor archivu.
122
Tip:
Pokud je potřeba přikročit ke druhé fázi obnovy archivu, bude opravený archiv přejmenován na _recover.rar.
Příklad:
Opravit archiv vadny.rar.
WinRAR r vadny.rar
■
rr[N] – přidat k archivu informace o jeho struktuře, které budou výhodou při pokusu
o opravu archivu v případě jeho poničení (viz příkaz r). Tato informace může být uložena až v osmi sektorech, které mohou být specifikovány přímo. Pokud tento údaj
chybí, platí následující implicitní nastavení:
Velikost archivu
Počet sektorů
< 50 KB
2
50Kb−500 KB
4
> 500 KB
8
Příklad:
Přidat informace k archivu backup.rar
winrar rr backup
■
s[name] – konvertovat archiv na samorozbalovací.
WinRAR přidá k archivu SFX modul, který je specifikován parametrem name. Pokud
není tento parametr udán, použije se modul default.sfx, který je obsažen ve stejném
adresáři jako program WinRAR.
Tip:
Kromě default.sfx obsahuje WinRAR i samorozbalovací moduly např. pro systém DOS
nebo OS/2.
123
Příklad:
Připojit k archivu backup.rar samorozbalovací modul idos.sfx a připojit komentář ze
souboru script.s.
WinRAR sidos.sfx -zscript.s backup
■
t – testovat archiv.
Archiv je testován tím způsobem, že je virtuálně rozbalen. Provádějí se všechny operace
jako při rozbalování archivu, vynechán je pouze zápis dekomprimovaných dat na disk.
Příklad:
Testovat všechny archivy na disku.
WinRAR t -r \*.rar
■
u – aktualizovat archiv.
Tento příkaz stejně jako f aktualizuje soubory v archivu pouze v případě, že přidávaný
soubor je novější než soubor stejného jména, jenž je již v archivu obsažen. Na rozdíl
od příkazu f však dokáže přidávat do archivu i zcela nové soubory.
Tip:
■
x – rozbalit soubory z archivu při zachování jejich adresářové struktury.
Příklad:
Rozbalit strukturu fontů TTF z archivu Fonts.rar do adresáře NewFonts.
WinRAR x Fonts *.ttf NewFonts\
Přepínače programu WinRAR
■ -av – verifikace autenticity archivu.
Použitím tohoto přepínače při vytváření nebo aktualizování archivu se zabezpečí
uložení informace o tom, kdo archiv vytvořil, čas poslední aktualizace atp. Při každé
další manipulaci s archivem (rozbalování, testování, aktualizace, prohlížení atd.) budou tyto informace zobrazeny.
124
Tip:
Zobrazení informací uložených přepínačem -av lze potlačit přepínačem -av-.
Příklad:
Přidat všechny soubory z aktuálního adresáře do archivu backup.rar spolu s informacemi o této operaci.
WinRAR a -av backup
■
-av – zákaz verifikace autenticity archivu.
Pokud při manipulaci s archivem zvolíte tento přepínač, nebudou uložené informace
o poslední manipulaci s archivem zobrazeny.
Příklad:
Testování všech archivů v aktivním adresáři s potlačením verifikace autenticity.
WinRAR t -av- *.rar
■
-c – zabránění zobrazení komentáře připojeného k archivu.
Při manipulaci s archivem nebude zobrazeno okno s komentářem, který byl k archivu
připojen příkazem c.
Příklad:
Testování archivu backup bez zobrazení jeho komentáře.
WinRAR t -c- *.rar
■
-cfg – zabránění použití konfigurace programu WinRAR uložené v konfiguračním souboru RAR.ini. Stejně tak nebude použito nastavení programu uložené v tabulce proměnných.
■
-cl – konverze názvů všech souborů archivu na malá písmena.
Při použití tohoto přepínače budou názvy všech archivovaných souborů, se kterými
bude WinRAR manipulovat, konvertovány na malá písmena.
125
Tip:
Tato funkce může být užitečná v případě, kdy byl archiv vytvářen v operačním systému nerozlišujícím velká a malá písmena v názvech souborů (např. DOS) a soubory se budou
používat pod operačním systémem, který velká a malá písmena rozlišuje (např. UNIX).
Příklad:
Rozbalení archivu backup.rar s konverzí názvů souborů archivu na malá písmena.
WinRAR x -cl backup
■
-cu – konverze názvů všech souborů archivu na velká písmena.
Přepínač -cu funguje stejně jako předcházející -cl.
■
-ds – neřadit archivované soubory.
Tento přepínač má smysl pouze při vytváření kompaktních archivů (solid archives),
kde jsou všechny soubory brány jako jediný datový tok. Při vytváření kompaktních archivů WinRAR implicitně řadí soubory přidávané do archivu abecedně podle jejich
přípony. Toto implicitní řazení lze potlačit přepínačem -ds a definovat pořadí jiné.
Tip:
Pokud bude kompaktní archiv zničen, bude možné rozbalit pouze soubory nacházející
se v archivu mezi začátkem archivu a místem, kde došlo ke ztrátě dat.
Příklad:
Do kompaktního archivu budou přidány nejprve soubory COM, pak EXE, DOC, TXT
a potom soubory s ostatními příponami.
WinRAR
126
a
-s
-ds
tools
*.com
*.exe
*.doc
*.txt
*.*
■
-e<mask> – při následující akci ignorovat soubory s určitými atributy.
Každý soubor má ve své hlavičce udáno, zda se jedná o soubor systémový, skrytý, archiv nebo soubor pouze ke čtení, případně zda se jedná nikoli o soubor, ale o adresář.
Parametr přepínače <mask> je buď desítkové nebo osmičkové (s předponou 0) či hexadecimální (s předponou 0x) charakterizující atributy souboru. Pokud výsledek bitové operace AND mezi parametrem <mask> a atributy souboru je nenulový soubor nebude přidán do archivu.
Tip:
Místo číselné masky lze použít i písmena D (Directory = adresář), H (Hide = skrytý),
S (System = systémový), A (Archive = archiv) a R (Read-only = pouze ke čtení).
Příklad:
Oba příklady jsou totožné. Do archivu temp.rar nebudou přidány soubory nastavené
jako systémové a skryté. Nebudou přidány ani prázdné adresáře.
WinRAR a -r -e0x16 temp
WinRAR a -r -ehsd temp
■
-ep – přidávat do archivu soubory bez informace o hierarchické struktuře adresářů.
Tip:
Tento způsob vytváření archivů může vést k tomu, že v archivu bude více souborů stejného názvu.
Příklad:
Do archivu documents.rar přidat všechny dokumenty z aktuálního disku bez informací
o jejich adresářové struktuře.
WinRAR
a
-r
-ep
documents
\*.doc
127
■
-ep1 – vynechat část informace o adresářové struktuře.
Přepínač zakazuje ukládání informace o té části cesty k souborům, která je uvedena
dále na programovém řádku.
Příklad:
Do archivu zaloha.rar budou přidány všechny soubory z adresáře games. Pokud tento
adresář obsahuje další podřízené adresáře, jejich struktura zůstane zachována. Ignorovat se bude pouze název adresáře games.
WinRAR a -ep1 zaloha games\*.*
■
-f – nahradit pouze staré soubory.
Tento přepínač lze použít pouze při vytváření nebo rozbalování archivu (nikoli např.
při jeho testování příkazem t atd.) Má stejnou funkci jako příkaz f. To znamená, že
pokud se v archivu již nachází soubor stejného názvu, jako má soubor přidávaný, bude
starší soubor nahrazen novějším. Pokud je již v archivu soubor novější, do vytvářeného archivu nebude přidán žádný soubor. Soubory, které nemají v archivu svůj ekvivalent, budou také ignorovány.
Pokud je přepínač -f použit při rozbalování archivu (tj. spolu s příkazem x nebo
e), provede se rozbalení souboru pouze v případě, že archivovaný soubor bude novější
než existující. Archivní soubory, které nemají ve specifikovaném adresáři svůj ekvivalent, se nerozbalí.
Příklad:
Soubory aktuálního adresáře budou aktualizovány soubory uloženými v archiv.rar.
WinRAR e –f archiv
■
-ilog – povolení výpisu o chybách.
Použití tohoto přepínače povoluje zápis chybových hlášení při manipulaci s archivem
do souboru RAR.log, který bude uložen do stejného adresáře, ve kterém se nachází
WinRAR.
■
-isnd – povolení zvuku.
Použití přepínače povolí programu WinRAR používání zvukových efektů.
128
■
-kb – zachovat chybné soubory po rozbalení.
Pokud jsou v archivu poškozené soubory, při použití tohoto přepínače nebudou po rozbalení odstraněny.
■
-m<n> – volba kompresní metody.
Všechny moderní archivační programy umožňují uživateli zvolit si druh komprese.
WinRAR k tomu používá přepínač -m následovaný číslem metody:
Přepínač
Význam
Komentář
−m0
Zálohovat
Přidání souborů do archivu bez jakékoli komprese.
−m1
Nejrychleji
Nejkratší doba komprese nejhorší kompresní poměr.
−m2
Rychle
Rychlá komprese.
−m3
Normálně
Normální kompresní metoda.
−m4
Dobře
Metoda ve které je kladen větší důraz na dobrý kompresní poměr než na rychlost komprese.
−m5
Nejlépe
Nejlepší kompresní poměr za cenu nejpomalejší komprese.
Tip:
Pokud nepoužijete při vytváření archivu přepínač -m, WinRAR funguje stejně, jako by
byl definován přepínač -m3.
■
-md<n> – volba velikosti slovníku.
Parametr <n> je číselný údaj v kilobajtech definující velikost tzv. „slovníku“, což je
oblast paměti využívaná kompresním algoritmem. Obecně lze říci, že pro velké soubory, které chcete přidat do archivu, platí: čím větší slovník, tím lze očekávat lepší kompresní poměr, větší nároky na dynamickou paměť počítače a delší dobu komprese.
Jako velikost slovníku lze zvolit 64, 128, 256, 512 nebo 1024 kilobajtů.
Tip:
Místo výše uvedených čísel můžete také adekvátně používat písmena ‘a’, ‘b’, ‘c’, ‘d’
nebo ‘e’.
129
Tip:
Velikost slovníku je postačující pro soubor, jehož velikost je 5*<velikost_slovníku>+150 kB. Další zvětšování slovníku již nepřináší efekt.
Tip:
Při vytváření běžného archivu se velikost slovníku vztahuje k velikostem jednotlivého
souboru, při vytváření kompaktního archivu (solid archive) k celkové velikosti všech
souborů.
Příklad:
Vytvoření kompaktního archivu stuff.rar nejlepší kompresní metodou a s použitím největšího slovníku.
WinRAR a -md1024 -m5 -s
■
stuff
-mm – komprese multimédií
Použití přepínače -mm se doporučuje při kompresi multimediálního digitalizovaného
zvuku. WinRAR při komprimaci provádí „inteligentní analýzu dat“, která mu umožní
použít rozdílné kompresní metody na různé části dat. Lepší kompresní poměry tak lze
čekat např. u souborů WAV, STM, MOD apod. až do čtyř osmibitových nebo dvou
šestnáctibitových kanálů. Dobré výsledky lze očekávat i při kompresi bitových map
s velkou barevnou hloubkou (typicky 24 bitů na pixel). U těchto souborů dosahuje
WinRAR s přepínačem -mm povolujícím dodatečnou analýzu dat kompresních poměrů lepších až o 30 %.
Tip:
Dodatečná „inteligentní“ analýza dat se projeví v delší době potřebné pro komprimaci. Vzhledem k tomu, že pro obvyklá binární nebo textová data tato metoda komprese
nedosáhne lepších výsledků, používejte ji pouze při archivaci multimediálních dat.
130
Tip:
Mějte na paměti předešlý obsah této knihy – „inteligentní“ analýza multimediálních
dat je navržena pro nekomprimované soubory, jako jsou WAV, STM, MOD, BMP
(s velkou barevnou hloubkou) apod. Soubory, kde již byl uplatněn jiný druh komprese
(tj. GIF, JPEG, MP3, MID a další) nelze prakticky již vůbec zkomprimovat i při použití přepínače -mm.
Příklad:
Přidat do archivu zvuk.rar všechny soubory WAV z aktuálního adresáře.
WinRAR a -mm samples *.wav
■
-mmf – používat multimediální kompresi vždy.
Použití tohoto přepínače donutí WinRAR neprovádět výše zmíněnou „inteligentní“
analýzu dat, ale použít pro kompresi všech souborů přidávaných do archivu změněný
komprimační algoritmus přizpůsobený struktuře multimediálních dat.
Kompresní poměr u souborů jako jsou WAV nebo BMP (s velkou barevnou hloubkou)
se trochu zhorší oproti použití přepínače -mm, ale tento handicap je bohatě nahrazen
kratší dobou komprimace.
■
-o+ – přepsat existující soubory.
Přepínač při archivaci i rozbalování archivu přepisuje automaticky stejnojmenné soubory, aniž by si vyžádal svolení uživatele.
■
-o- – nepřepisovat existující soubory.
Přepínač při archivaci i rozbalování archivu automaticky přeskakuje stejnojmenné soubory. V žádném případě nedojde k přepsání souboru.
■
-p<pwd> – opatřit archiv heslem.
Bezpečnostní přepínač -p opatří vytvářený archiv heslem uvedeným jako parametr
<pwd> a toto heslo zakóduje. Při jakékoli další manipulaci s archivem musí uživatel
opět použít přepínač -p následovaný heslem. Pokud tak neučiní, WinRAR se na heslo
sám dotáže speciálním dialogem.
131
Tip:
V heslu se rozlišují velká a malá písmena.
Tip:
Kompaktní archiv (solid archive) opatřený heslem nemůže být aktualizován.
Příklad:
Přidat obsah adresáře Games do archivu secret.rar a opatřit archiv heslem
BuDuLINEk.
WinRAR a -p BuDuLINEk -r secret games\*.*
■
-r – včetně vnořených adresářů.
Pokud je použit přepínač -r, bude manipulováno se všemi soubory, které se nacházejí
v hierarchické struktuře adresářů níže, než je udaná cesta.
Tip:
Přepínač -r lze použít ve spojení s následujícími příkazy: a, u, f, m, x, e, t, c, s.
Příklad:
Přidat do adresáře Backup.rar obsah celého disku c.
WinRAR a -r Backup c:\*.*
■
-ri<p>[:<s>] – přepínač nastavení priority programu WinRAR v multitaskingovém
prostředí Windows.
Parametr <p> může být nastaven na hodnoty 0 až 15. Nula znamená předdefinovanou
prioritu procesu prováděného programem WinRAR, čísla od 1 do 15 nastavují tuto
prioritu konkrétně, přičemž priorita 1 je nejnižší, priorita 15 nejvyšší.
132
Nepovinný číselný parametr <s> udává počet milisekund, po kterých se WinRAR vrací do prostředí Windows. Povolený rozsah je od 1 do 1000 ms.
Tip:
Parametr <s> je užitečný v případě, že v systému Windows probíhá současně několik
procesů se stejnou prioritou.
■
-rr[n] – připojení obnovovacích sektorů k archivu.
Přepínač připojí obnovovací sektory, které může WinRAR využít v případě poškození
archivu. Počet sektorů je specifikován parametrem [n].
■
-s – vytvoření kompaktního archivu (solid archive).
Kompaktní archiv komprimovaných dat, který při komprimaci nakládá se všemi soubory jako s jediným tokem dat. Výhodou tohoto druhu archivu je lepší kompresní poměr, zvláště při kompresi velkého množství malých souborů. Nevýhodou je naopak
pomalejší rozbalování jednotlivého souboru (musí být analyzovány všechny soubory
uložené v archivu) a ztráta veškerých komprimovaných dat i v případě, že je poškozen
třeba jen jediný soubor archivu.
■
-sfx[name] – vytvořit samorozbalovací archiv.
Samorozbalovací archiv nepotřebuje k rozbalení svých souborů program WinRAR, ale
používá k rozbalení spustitelný modul připojený k archivu. Modul je specifikován parametrem [name]. Pokud je tento parametr vynechán, použije WinRAR modul default.sfx.
■
-tk – zachovat původní čas a datum vytvoření.
Při modifikování archivu WinRAR nezmění čas a datum původního vytvoření archivu.
Tyto údaje jsou zobrazitelné všemi programy pro manipulaci se soubory.
■
-tl – nastavit datum a čas archivu podle nejnovějšího souboru.
Použití tohoto přepínače nastaví datum a čas vytvoření archivu na shodné hodnoty
s nejnovějším souborem, který archiv obsahuje.
133
■
-u – aktualizovat archiv.
Přepínač -u má stejnou funkci jako příkaz u. Tj. aktualizace starých souborů novými
(stejnojmennými) a přidání zcela nových souborů. Přepínač -u může být použit při vytváření nebo rozbalování archivu. Při rozbalování jsou aktualizovány soubory v adresáři, do kterého je archiv rozbalován.
■
-v<n>[k|b] – vytvoření archivu po blocích.
Velice užitečná funkce – pokud je použit přepínač -v, bude archiv rozdělen do bloků,
jejichž velikost je udána parametrem n.
Implicitně je velikost udávána v tisících bajtů. Přidáním písmena „k“ se udává velikost
v kilobajtech (1024 bajtů), písmeno „b“ specifikuje udání čísla v bajtech.
První blok archivu má potom, příponu RAR, druhý R00, třetí R01 atd. Maximální počet bloků je tedy 101.
Tip:
Pokud chcete archiv posléze překopírovat na obyčejnou 3,5palcovou disketu, zvolte jeden z následujících přepínačů (disketa má kapacitu 1 457 664 bajtů):
-v1457
-v1423k
-v1457664b
■
-w<d> – definice pracovního adresáře pro ukládání dočasných souborů.
Cestu k adresáři určuje parametr d.
■
-x<f> – kromě specifikovaných souborů.
Při manipulaci se soubory budou ignorovány soubory specifikované parametrem
<f>. Mohou být použity i zástupné znaky.
Tip:
Přepínač -x může být v jednom příkazovém řádku použit i vícekrát.
134
Příklad:
Do archivu bin.RAR přidat všechny soubory EXE s výjimkou těch, které začínají písmenem „k“.
WinRAR a -xk*.* bin *.exe
■
-x@<lf> – kromě specifikovaných souborů
Parametr <lf> udává seznam souborů, které mají být při akci ignorovány. Nejsou povoleny zástupné znaky.
■
-y – automatický souhlas.
Přepínač předdefinovává kladnou odpověď na všechny případné dotazy programu
WinRAR v průběhu manipulace s archivem.
Tip:
Takovou otázkou je např. dotaz na rozbalení dalšího bloku dat, pokud je archiv rozdělen do více bloků.
■
-z<f> – přidat komentář ze souboru.
Přepínač se používá při vytváření nebo modifikaci archivu k přidání komentáře archivu. Komentář musí být obsažen v souboru, který je udán parametrem <f>.
WinZip
Jedním z nejpoužívanějších a nejoblíbenějších archivačních programů je program ZIP.
V našem přehledu archivačních programů jej nemůžeme přehlédnout již proto, že existují
jeho verze pro operační systémy Windows 3.1 i Windows 95. WinZip 6.3, který je poslední
verzí tohoto oblíbeného produktu pro kompresi souborů, se vyznačuje velkým množstvím
volitelných parametrů pro vytváření a manipulaci s archivačními soubory. Popišme si nyní
pracovní prostředí tohoto programu a jeho funkce z uživatelského hlediska. (Popisovaná
verze je určena pro 32bitové operační systémy, tj. Windows 95 nebo NT 4.0.)
135
Obr. 12
Pracovní prostředí programu WinZip.
Tip:
32bitová verze programu WinZip vyžaduje operační systém Windows 95 nebo NT
4.0. 16bitová verze je naopak určena pro Windows 3.1 nebo 3.11. Žádné další programy
nebo speciální hardware není potřebný.
WinZip lze spustit buď z menu Start systému Windows nebo poklepáním myší na ikonu zástupce, kterou instalátor umístí na pracovní plochu. WinZip se spustí také v případě, že poklepáte na archiv vytvořený programem WinZip.
Tip:
Archivy programu WinZip jsou ve všech prohlížečích Windows zobrazeny s ikonou odpovídající samotnému programu WinZip.
Po spuštění programu WinZip se zobrazí hlavní okno programu (viz obr. 12). Toto okno obsahuje (odshora) nabídku s příkazy, panel nástrojů zpřístupňující některé často používané
příkazy jediným klepnutím myši, část zobrazující soubory a stavový řádek s nápovědou nebo popisem právě prováděné činnosti.
136
Tip:
Na pravé straně stavového řádku je semafor. Pokud na tomto semaforu svítí zelená, je
WinZip připraven vykonat příkazy uživatele. Svítí-li červená, WinZip právě pracuje.
Nejdůležitější částí hlavního okna je jeho největší část zobrazující archivované soubory. Tato část svou organizací připomíná windowsové nástroje pro manipulaci se soubory. Je zde
však jeden významný rozdíl. Hlavní okno programu WinZip zobrazuje vždy pouze seznam
souborů archivovaných ve vybraném archivu.
Pokud spustíte program WinZip poklepáním na jeho ikonu nebo z nabídky Start, bude tato
část hlavního okna prázdná – uživatel nedefinoval, který archiv má být zobrazen. Pro zobrazení archivu pak můžete použít příkaz nabídky File/Open Archive.
Pokud je se spuštěnou instancí programu WinZip asociován některý archiv, zobrazí se
všechny v něm archivované soubory v hlavním okně. Údaje v každém řádku - jako např.
Date (datum vytvoření), Time (čas vytvoření), Size (nekomprimovaná velikost) – se vztahují vždy k jednotlivému konkrétnímu souboru, který je v archivu obsažen.
Parametr Ratio (kompresní poměr) se vztahuje také k jednotlivým souborům a je udáván
v procentech. Jeho číselná hodnota v tomto případě říká, kolik procent místa na disku bylo
komprimací tohoto souboru ušetřeno. Například údaj Ratio 26 % znamená, že velikost
komprimovaného souboru je 74 % z jeho původní nekomprimované podoby. Tedy čím větší
je údaj Ratio, tím lepšího kompresního poměru WinZip dosáhl.
Posledním údajem vztahujícím se k jednotlivým souborům archivu je Packed (velikost souboru po kompresi).
Prohlížení souborů
Se soubory zobrazenými v hlavním okně lze velice jednoduše manipulovat. Jednou ze základních a velice užitečných funkcí pro manipulaci se soubory archivu je jejich prohlížení.
Stačí prostě poklepat na název souboru v hlavním okně programu WinZip a soubor bude
otevřen v aplikaci, která je se souborem asociována – pokud se jedná o dokument Wordu,
je touto asociovanou aplikací Microsoft Word atd.
137
Tip:
Otevírat lze nejen textové ale všechny soubory – několikařádkový text připojený k Poznámkovému bloku lze otevřít stejně jako několika set megabajtovou databázi programu
Access. Ve všech případech navíc není soubor otevřen pouze pro čtení, ale je možné
v něm provádět jakékoli úpravy. Při zavření takového souboru se WinZip dotáže, zda má
provedené změny zanést i do archivu.
Pokud poklepáte na spustitelný soubor EXE, soubor se opravdu spustí.
Soubory archivu však můžete otevírat i v jiné než jim asociované aplikaci. Pokud soubory
otevřete nikoli poklepáním na jejich název, ale pomocí příkazu nabídky Actions/View (případně klepnutím na ikonou View z panelu nástrojů), WinZip nabídne otevření příslušného
souboru nejen v asociované aplikaci, ale také ve svém interním ASCII textovém editoru nebo můžete sami zvolit aplikaci, která má soubor otevřít.
Přidávání souborů do archivu
Pokud máte otevřený archiv v programu WinZip, je velice jednoduché do něho přidat další
soubory. Můžete to udělat hned několika způsoby.
Nejjednodušší je ten, který využívá obecné vlastnosti Windows nazývané drag and drop
(přetáhni a pusť). Znamená to, že příslušný soubor (jeho ikonu) zobrazený na pracovní ploše Windows nebo v kterémkoli programu pro manipulaci se soubory (Salamander, Explorer, Norton Commander) přetáhnete myší do hlavního okna programu WinZip. Zobrazí se
menu, ve kterém můžete definovat způsob komprese, který se má použít, možnost opatření
heslem atd.
Tip:
Pokud chcete mít při dekompresi jednotlivých souborů z archivu možnost rozbalit je do
jejich původního adresáře v hierarchické stromové struktuře adresářů, nezapomeňte zatrhnout volbu Save Extra Folder Info – cesta bude zobrazena v parametru Path
v hlavním okně programu WinZip.
138
Další možností je přidání souborů po zadání příkazu Actions/Add. Tento příkaz zobrazí dialog, který umožňuje vložit více souborů najednou. Soubory lze vybírat ze stromové struktury souborů tradičním způsobem jako ve všech jiných aplikacích operačního systému Windows. Klepnutím myší na zobrazený název souboru jej označíte pro přidání do archivu. Pokud chcete přidat souborů několik, držte při jejich označování klávesu CTRL. Klepnutím na
tlačítko Add potom provedete kompresi souboru.
Názvy souborů určené pro archivaci jsou zobrazeny v poli Název souboru. V tomto poli lze
použít i zástupné symboly, jako jsou otazník (?) nebo hvězdička (*). V tomto případě použijte tlačítko Add With Wildcards namísto Add.
Tip:
V dialogovém okně určeném pro definici přidání souborů do archivu můžete zvolit způsob komprese:
■
Maximum (nejlepší kompresní poměr - nejpomalejší)
■
Normal (normální komprese)
■
Fast (rychlá komprese – horší kompresní poměr)
■
SuperFast (superrychlá komprese – nejhorší kompresní poměr)
■
None (kopírovat soubor bez komprese)
Tip:
Pokud přidáváte soubory do archivu, nejsou nekomprimované soubory vymazány. Jestliže
hodláte uvolnit místo na disku smazáním původních souborů, zvolte možnost Move Files z
rámečku Action.
Soubory lze přidávat i do zcela nového archivu. Tento soubor založíte příkazem nabídky File/New Archive. Po zadání jeho jména se otevře výše zmíněné dialogové okno pro přidání
souborů do tohoto archivu.
139
Nevýhodou programu WinZip je omezení pro vytváření archivů rozdělených do několika
bloků. Program WinZip neumožňuje explicitní zadání velikosti jednotlivých bloků archivu.
Vytváření těchto typů archivů navíc nabízí jen při vytváření archivu na vyjímatelné medium, tj. např. přímo na disketu. V tom případě lze zvolit automatickou velikost bloků, které
se pak přesně rovnají velikosti média.
Mazání souborů z archivu
Máte možnost vymazat jednotlivý soubor nebo celou sadu souborů z archivu. Případně lze
smazat celý archiv najednou. Pokud hodláte mazat pouze soubory archivu, použijte příkaz
horizontálního menu Actions/Delete. Tento příkaz vyvolá dialog, který vám dá vybrat, co
bude smazáno:
■
Entire Archiv (celý archiv);
■
Selected Files (vybrané soubory – souborů lze vybrat i několik, pokud při jejich volbě
v hlavním okně programu WinZip držíte klávesu CTRL;
■
Files (názvy souborů určených pro vymazání zadáte explicitně do textového pole).
Pokud hodláte vymazat celý archiv a chcete přitom obejít dialogové okno Delete, zvolte
příkaz File/Delete Archive.
Rozbalování souborů
K rozbalování souborů lze (stejně jako k jejich přidávání do archivu) použít funkci drag
and drop. Prostě soubor z hlavního okna programu WinZip přetáhnete do adresáře, kam
chcete soubor rozbalit.
Můžete však také použít příkaz Actions/Extract nebo ikonu Extract z panelu nástrojů. Potom si můžete zvolit adresář, do kterého bude soubor (případně soubory) rozbalen. Pro rozbalení lze zvolit jednotlivý soubor nebo celou sadu, podobně jako při mazání.
Tip:
Adresář, do kterého budou soubory rozbaleny, nemusí existovat. Tlačítkem New Folder
jej lze založit.
140
Tip:
Pokud mají soubory uchovanou cestu k adresáři, ze kterého byly do archivu přidány a vy
chcete tuto cestu použít pro jejich rozbalení, nezapomeňte zatrhnout volbu Use Folder
Names.
Tipy pro pokročilé
V předcházejících odstavcích byly popsány základní funkce programu WinZip. Nyní se zaměřme na několik fíglů, které vám usnadní, zpříjemní a zrychlí každodenní práci s tímto
užitečným archivačním programem.
■
WinZip pro manipulaci se soubory archivu využívá adresář specifikovaný v poli
Temp Folder v dialogu, který zobrazíte příkazem nabídky Options/Folders. Pokud je
pole Temp Folder prázdné, je implicitně používán kořenový adresář disku C. Nastavte
název do pole Temp Folder a po potvrzení volby uložte nové nastavení příkazem Options/Save Settings Now.
■
Pokud chcete použít implicitní nastavení v dialogových oknech určených pro definici
parametrů pro přidávání souborů do archivu technikou drag and drop, rozbalování nebo prohlížení souborů, držte současně s prováděnou akcí klávesu SHIFT. Dialog určený pro definici parametrů se nezobrazí.
■
Používejte pravé tlačítko myši. Vždy se zobrazí místní nabídka, díky níž lze manipulovat se soubory rychleji než pomocí příkazů hlavní nabídky.
■
Pokud máte dostatečně velký RAM disk, používejte jej jako Temp Folder. Výrazně
tím urychlíte veškerou manipulaci se soubory.
■
Komprimované soubory můžete kopírovat a přesouvat mezi jednotlivými archivy tak,
že každý archiv otevřete v jedné instanci programu WinZip a soubory prostě přetáhnete. Nezapomeňte zrušit zašktrnutí u příkazu horizontálního menu Options/Reuse
WinZip Windows, aby bylo možné otevřít více instancí programu WinZip najednou.
■
WinZip můžete používat jako nástroj pro kompresi souborů posílaných programem
cc:Mail. Změňte řádek “compress=” v sekci [cc:Mail] souboru Wmail.ini tak, aby za
rovnítkem byla udaná úplná cesta k programu WinZip následovaná řetězcem "a %1 @%2"
Např.:
compress=c:\winzip\winzip.exe -a %1 @%2
141
■
Při stahování souborů ZIP z Internetu můžete použít přídavný nástroj programu
WinZip - WinZip Internet Browser. Po stažení archivu jej WinZip Internet Browser automaticky přesune do speciální složky (implicitně c:\download) a otevře jej v programu WinZip. WinZip Internet Browser není standardní součástí programu WinZip, ale
můžete si jej stáhnout z WWW stránky http://www.winzip.com/.
■
Pokud dostanete elektronickou poštou binární data ve formátu UUencode a váš software tento formát neumí interpretovat, použijte WinZip. “Textovou” zprávu obsahující
binární data pak uložte do souboru s příponou UUE. Poklepáním na tento soubor se
spustí WinZip a dekóduje data. Podobně lze binární data do formátu UUencode také
zakódovat – slouží k tomu příkaz nabídky Actions/UUencode.
■
Pokud chcete přerušit dlouho trvající akci prováděnou programem WinZip (přidávání
souboru do archivu, dekompresi atd.), klepněte myší na plochu hlavního okna programu WinZip. To vyvolá dialog, ve kterém můžete prováděnou akci zrušit, nebo povolit
její pokračování.
■
Při přidávání souboru do archivu jej můžete opatřit heslem. K zadání hesla slouží tlačítko Password v dialogu Add.
■
WinZip je schopen použít antivirový program pro kontrolu souborů, se kterými manipuluje. WinZip při své instalaci rozeznává a dokáže použít každý z následujících antivirových programů:
■
NAVWNT, NAVW and NAV, firmy Symantec
■
WNAPVIR and CPAV, distributed with Central Point Desktop For Windows
■
MSAV, součást MS-DOS 6.0
■
SCAN a WSCAN, firmy McAfee Associates
■
F-PROT, firmy Frisk Software International
■
Dr. Solomon's Anti-Virus Toolkit, firmy S&S International
■
ThunderByte's TBSCAN, firmy ESaSS B.V.
Cestu k antivirovému programu a jeho parametry lze také nastavit v dialogu zobrazeném
příkazem Options/Program Locations. Tento program pak lze spustit z nabídky programu
příkazem Actions/Virus Scan.
■
142
Vytvářejte samorozbalovací archivy příkazem Actions/Make EXE file. K jejich rozbalení nebude třeba WinZip.
■
Testujte, zda vaše archivy nejsou poničeny. Slouží k tomu příkaz Action/Test. Tento
příkaz provede stejné operace jako při rozbalování archivovaných souborů s tím jediným rozdílem, že je vynechán zápis dekomprimovaných souborů na disk.
■
Pro zrychlení práce s programem WinZip používejte klávesové zkratky:
■
Ctrl+N
Vytvoř nový archiv
■
Ctrl+O
Otevři existující archiv.
■
Ctrl+L
Zavři archiv.
■
Ctrl+F
Zobraz informace o používaném archivu.
■
F7
Přesuň archiv
■
F8
Kopíruj archiv
■
Ctrl+R
Přejmenuj archiv.
■
Ctrl+M
Pošli archiv e-mailem.
■
Ctrl+A
Přidej soubory do archivu.
■
Ctrl+D
Vymaž soubory z archivu.
■
Ctrl+E
Dekomprimuj soubory z archivu.
■
Ctrl+V
Prohlédnout soubory v archivu.
■
Ctrl+/
Vyber všechny soubory v seznamu souborů.
■
Ctrl+\
Zruš vběr všech souborů v seznamu souborů.
■
Ctrl+S
Spusť antivirový program.
■
Ctrl+T
Testuj archiv.
■
Ctrl+K
Vytvoř samorozbalovací archiv.
■
Ctrl+C
Aktivuj funkci CheckOut (seskupování souborů).
■
Šipky
Pohyb v seznamu souborů.
■
SHIFT+šipky
Vyber více souborů ze seznamu souborů.
■
ENTER
Stejná funkce jako poklepání myší na zaměřený objekt.
143
■
SHIFT+F8
Zapnutí módu v hlavním okně programu WinZip, pro označování
sady souborů, které nejsou zobrazeny za sebou. Pokud orámování
vybraného souboru bliká, můžete pomocí kurzorových kláves posunout toto orámování na jiný soubor a zvolit jej stisknutím
mezmerníku.
ARJ
Archivační program ARJ je jedním z nejznámějších a nejpoužívanějších programů pro bezztrátovou komprimaci dat vůbec. Tento kompresní nástroj má za sebou mnohaletou historii,
po kterou se vyvíjel až do verze 2.60, která představuje velice kvalitní a především vysoce
flexibilní program.
Především jeho flexibilita a schopnost přizpůsobit se nejrozmanitějším přáním a požadavkům uživatelů reprezentovaná dvaceti sedmi různými příkazy a nesčetným počtem přepínačů je zřejmě jedním z důvodů, proč se program ARJ stále drží v popředí zájmu. Přesto, že
na rozdíl od dříve popsaných archivačních programů WinRAR a WinZIP setrvává ARJ na
platformě operačního systému MS-DOS, je velice hojně používán. Je tedy zřejmé, že v operačním systému DOS je uživatel ochuzen o příjemné intuitivní ovládání. Veškeré příkazy
a přepínače musí být zadány do příkazového řádku DOSu.
Tip:
Zatímco program ARJ nepodporuje uživatelské prostředí Windows a WinZip naopak již
neumožňuje manipulaci s archivy a soubory z příkazového řádku, WinRAR je naprogramován pro oba tyto režimy, ze kterých si uživatel může vybrat. I to může hrát roli při
volbě komprimačního programu.
I program ARJ však musí držet krok s dobou, a proto verze 2.60 již podporuje dlouhé názvy
souborů. To však platí pouze v případě, že je archivační program ARJ spuštěn v dosovém
okně operačního systému Windows 95 nebo 98. To znamená, že pokud použijete ARJ 2.60
přímo v DOSu nebo dokonce i ve Windows NT, nebude podpora dlouhých názvů souborů
fungovat.
144
Tip:
Objevil se již i archivační program WinARJ, ovšem tento program nepochází z tvůrčí dílny Roberta Junga a nesouvisí nijak se společností ARJSoftware.
A nyní již bez dalších úvodů rovnou k popisu programu.
Základní funkce
Jak již bylo zmíněno, archivační program ARJ disponuje velkým množstvím přepínačů
a příkazů. Tyto možnosti však nejsou komplexně shrnuty v žádném manuálu a uživatel je
nucen si jejich syntaxi a funkce pamatovat. Ačkoli vzhledem k omezenému rozsahu knihy
ani zde nelze podat do všech podrobností vyčerpávající přehled veškerých možností, jsem
přesvědčen, že popis podaný v následujících kapitolách je dostatečný nejen pro všední použití programu, ale dává dostatek námětů i pro uživatele, kteří chtějí využít program ARJ na
profesionální úrovni.
Přesto však začněme úplnými základy, které jsou běžným uživatelům programu ARJ již většinou dostatečně známé.
Příkazový řádek, kterým se program ARJ spouští, má obecně následující tvar:
ARJ <command> [<options>] <archive_name> [<target_dir\>] [<files>]
■
ARJ představuje název souboru ARJ.EXE, tedy samotného komprimačního programu
■
command představuje jeden z 27 příkazů, které jsou detailně popsány v následující
kapitole. Příkaz udává, jakou akci bude program ARJ provádět (např. kompresi, dekompresi, kontrolu nebo opravu archivu, přidání komentářů a mnoho dalších)
■
options je nepovinný argument reprezentující jeden nebo celou sadu přepínačů. Přepínače specifikují, jak bude program provádět akci definovanou příkazem command.
(Tj. zda se bude při komprimaci přihlížet spíše k její rychlosti než kompresnímu poměru nebo naopak, zda se mají komprimovat i soubory z podadresářů zadaného adresáře a obrovské množství dalších).
145
Tip:
Parametry options není nutné udávat hned za parametrem command. Jejich syntaxe je
zcela jednoznačná, a proto tvůrce programu povoluje zapsání přepínačů kamkoli za
příkaz ARJ.
■
Archive_name je název nově vytvářeného archivu, případně archivu, se kterým se bude manipulovat. Tento parametr je povinný a neexistuje pro něj žádná implicitní zástupná hodnota.
■
Target_dir udává adresář, ve kterém se nacházejí soubory určené pro archivaci, případně kam se budou soubory rozbalovat.
■
Files je parametr, který specifikuje název jednoho či více souborů, se kterými se bude
manipulovat. Tento parametr je nepovinný – je-li vynechán, vztahuje se prováděná akce na všechny soubory aktivního adresáře (případně adresáře zadaného parametrem
Target_dir) nebo všechny soubory archivu.
Tip:
Při zadávání parametru Files jsou povoleny i zástupné znaky jako hvězdička (*) nebo
otazník (?).
Podívejme se nyní na několik konkrétních nejjednodušších příkladů, na kterých si snáze
ozřejmíme výše uvedenou syntaxi a zároveň podáme návod, pro běžné každodenní použití
archivačního programu ARJ:
■
Jak vytvořit ARJ archiv (s názvem archive.arj), který bude obsahovat všechny soubory
aktivního adresáře?
ARJ a archive
Zde jsou kromě názvu souboru ARJ použity pouze parametry command (tj. a) a archive_name (tj. archive)
■
Jak vytvořit archiv obsahující všechny soubory aktivního adresáře, který bude uložen
do adresáře D:\directory?
ARJ a D:\directory\archive
146
■
Jak vytvořit archiv obsahující všechny soubory s příponou DOC, které se nacházejí
v aktivním adresáři?
ARJ a archive *.DOC
■
Jak vytvořit archiv obsahující všechny soubory s příponou DOC nebo EXE, které se
nacházejí v aktivním adresáři?
ARJ a archive *.DOC *.EXE
■
Jak vytvořit archiv obsahující všechny soubory nacházející se v adresáři C:\directory?
ARJ a archive C:\directory\*.*
■
Jak vytvořit archiv obsahující všechny soubory adresáře directory a jeho podadresářů?
K tomu použijte parametr options –r.
ARJ a -r archive directory\*.*
■
Jak vytvořit archiv, kde názvy souborů neobsahují cestu do svého původního adresáře
(tím se mírně zmenší i velikost výsledného archivu)? Použijte přepínač –e.
ARJ a -e archive named_directory\*.*
■
Jak vytvořit archiv s nejlepším kompresním poměrem? K tomu slouží přepínač –jm
nebo -jm1.
ARJ a -r -jm1 archive named_directory\*.*
■
Pokud naopak kladete důraz na rychlost komprese oproti kompresnímu poměru, použijte přepínač –m2.
ARJ a -r -m2 archive named_directory\*.*
Tip:
Poslední dva příklady demonstrují fakt, že přepínačů může být v jednom příkazovém
řádku uveden libovolný počet (tedy více než jeden).
■
Jak vytvořit archiv obsahující soubory s plnou cestou včetně názvu disku i kořenového adresáře?
ARJ a -r -jf archive C:\top_directory\*.*
147
■
Jak komprimovat soubory do bloků, které je možné odnést na 3.5palcových disketách
(přepínač –v)?
ARJ a –v1440 archive d:\obr\*.*
Tip:
Minulý příklad ukládá všechny bloky archivu do aktivního adresáře. Pokud archivujete
soubory přímo na diskety, používejte kromě přepínače –v také přepínač –w specifikující pracovní adresář. Velice tím urychlíte kompresi. Dále se doporučuje používat
přepínač -jt, jenž vytvořený archiv ihned kontroluje.
ARJ a –v1440 -wC:\ -jt a:\archive d:\obr\*.*
■
Jak zobrazit výpis všech souborů archivu?
ARJ l archive
■
Jak zobrazit výpis všech souborů archivu tak, aby se výpis pozastavil po každé stránce?
ARJ l archive -jp
■
Jak zobrazit výpis souborů archivu s příponou DOC?
ARJ l archive *.DOC
■
Jak přesměrovat výpis souborů na disk (zapsat výpis do souboru)?
ARJ l archive > file.txt
Posledním polem výpisu je přehled atributů souboru následovaný parametrem BTPMGVX.
První čtyři znaky tohoto pole jsou vyhrazeny pro atributy:
■
Archivační příznak (A)
■
Skrytý soubor (H)
■
Systémový soubor (S)
■
Pouze pro čtení (R) nebo povolen úplný přístup (W)
Zobrazena jsou pouze ta písmena, jejichž příznaky soubor má.
148
V řetězci BTPMGVX zastupuje každé písmeno jednu vlastnost:
■
B - soubor chapter není obsažen v poslední kapitole (zastaralý soubor)
■
T - Text/Binary/Directory/Chapter/Label type (je zobrazeno jedno z těchto písmen)
■
P – je dostupná informace o cestě k souboru
■
M – kompresní metoda (je zobrazeno číslo metody – implicitní nastavení kompresní
metody je 1 = normal)
■
G – soubor je zakódován
■
V – archiv je rozdělen na bloky (volumes)
■
X – soubor je rozšířenou součástí většího souboru
■
Jak rozbalit všechny soubory archivu do aktivního adresáře?
ARJ e archive
■
Jak rozbalit všechny soubory archivu do určitého adresáře?
ARJ e archive directory\
■
Jak rozbalit všechny soubory s příponou DOC do aktivního adresáře?
ARJ e archive *.DOC
■
Jak rozbalit všechny soubory archivu se znovuvytvořením původní struktury adresářů,
tentokrát však uvnitř aktivního adresáře?
ARJ x archive
■
Jak rozbalit všechny soubory archivu s použitím úplné původní cesty souborů?
ARJ x -jf archive
■
Jak otestovat archiv, zda není poškozen, aniž by bylo nutné jej rozbalit?
ARJ t archive
149
Tip:
Testování archivu znamená kontrolu, zda obsah archivu odpovídá původním souborům. Program ARJ to provádí za použití tzv. CRC (cyclical redundancy checksumming). Pro zvýšení spolehlivosti ARJ používá 32bitový CRC.
■
Jak vytvořit samorozbalovací archiv archive.exe z již hotového archivu archive.arj?
ARJ y -je archive
■
Jak zkonvertovat archiv ZIP na archiv ARJ?
Přepněte se do adresáře s archivem typu ZIP a spusťte příkaz:
REARJ *.ZIP
Program REARJ.EXE je dodáván spolu s programem ARJ (i sharewareovou verzí).
Tip:
Program ARJ identifikuje soubory v archivech podle jejich názvu. To vede k tomu, že
soubor uložený do archivu včetně cesty je považován za odlišný od téhož souboru uloženého bez této cesty. V archivu tudíž mohou vzniknout duplicitní soubory, pokud je
archiv vytvořen např. příkazem ARJ a archive temp\*.* a potom jsou k němu přidány
soubory příkazem ARJ a archive *.*
Tip:
Pro rychlé získání nápovědy slouží příkaz ARJ /?.
Tip:
Pokud použijete v zadání cesty adresář obsahující mezeru, je nutné uzavřít cestu
do uvozovek a použít dvě zpětná lomítka. Např. takto:
ARJ a archive "C:\Program Files\*.*" –r
150
Nyní jsme probrali všechny základní funkce programu ARJ a jste připraveni pro každodenní používání tohoto archivačního nástroje. Přes to všechno se jedná pouze o zlomek všech
možností, které program ARJ nabízí. Těm z vás, kterým je úvodní kurz málo, jsou věnovány další kapitoly zabývající se jednotlivými příkazy a přepínači podrobněji.
Příkazy programu ARJ
Začněme nejprve novinkami týkajícími se poslední verze programu ARJ.
■
ac příkaz je zkratkou dřívějšího příkazu u společně s přepínači -u2 –jb. Tento příkaz
přidá do zálohovacího archivu (chapter archive) novou zálohovací kapitolu (chapter
backup). Zálohovací archiv je archiv, který obsahuje pouze různé soubory (lišící se časem vytvoření nebo svou délkou). Výhodou tohoto typu souborů je to, že do jediného
archivu můžete přidávat postupně další zálohovací kapitoly (maximální počet kapitol
v jediném zálohovacím archivu je 250) stejného adresáře (nebo i disku). Další kapitoly však obsahují pouze soubory, které byly pozměněny nebo jsou nové.
■
cc příkaz je zase zkratkou příkazu y spolu s přepínačem –jb. Příkaz cc zkonvertuje
standardní ARJ archiv na zálohovací.
■
dc příkaz je opět zkratkou, tentokrát příkazu d spolu s přepínačem –jb. Tento příkaz
vymaže specifikované soubory pouze z poslední záložní kapitoly. Např.:
ARJ dc archive *.*
■
q příkaz se používá pro pokus o opravu poškozených archivů, které byly zabezpečeny
proti poškození přepínačem –hk při vytváření (byl vytvořen také soubor s informacemi nutnými pro opravu - ARJ-PROTECT file).
■
t příkaz se používá k testování ARJ archivů (viz předcházející kapitola). Pokud je příkaz použit spolu s přepínačem –hk, bude při pozitivním výsledku testu vytvořen ARJPROTECT file.
■
y příkaz slouží ke kopírování archivu s jinými přepínači. Pokud je tento příkaz použit
spolu s přepínačem –g, odstraní z archivu dříve nastavenou ochranu heslem. Např.:
ARJ y archive -gpasswrd
Pokud je příkaz použit spolu s přepínačem –jb, překonvertuje se standardní archiv na
záložní, přepínač -jb0 naopak překonvertuje záložní archiv na standardní atd.
151
Zde končí novinky z oblasti příkazů programu ARJ verze 2.60. Další příkazy fungují stejně
jako v předcházejích verzích:
152
■
a - přidat soubory do archivu. Většinou se tento příkaz používá k vytvoření nového archivu (viz předcházející kapitola).
■
b – spustit soubor BAT nebo dosovský příkaz.
■
c – přidat komentář k archivu.
■
d – vymazat specifikované soubory z archivu.
■
e – rozbalit soubory z archivu do aktuálního adresáře.
■
f – aktualizovat soubory v archivu
■
g – opatřit existující archiv heslem
■
i – zkontrolovat integritu programu ARJ (antivirový test)
■
j – spojení dvou nebo více archivů
■
k – vymazat zastaralé soubory ze záložního archivu (chapter backup)
■
l – prohlédnout obsah archivu
■
m – přesunout soubory do archivu (z původního adresáře budou automaticky vymazány)
■
n – přejmenovat soubory v archivu
■
o – uspořádat soubory v archivu
■
p – vytisknout soubory na standardní tiskové zařízení
■
r – odstranit údaje o cestě ze souborů obsažených v archivu.
■
s – scannování textu. Program ARJ vypíše začátek zadaného souboru a zeptá se, zda
chcete číst dál.
■
u – aktualizovat soubory v archivu za jejich novější verze
■
v – zobrazit obsah archivu s konkrétnějšími údaji, než to činí příkaz l.
■
w – hledání zadaných textových řetězců v archivovaných souborech.
■
x – rozbalit soubory archivu s použitím plné cesty, pokud je dostupná.
Některé zajímavé vlastnosti programu ARJ
■
Na rozdíl od mnoha jiných archivačních programů může ARJ pracovat až s 65 000
soubory najednou a ovládat přitom velký diskový prostor.
■
ARJ poskytuje možnost komprimace dlouhých souborů (nebo jejich sad) do oddělených bloků (volumes) nezávisle na médiu, na které jsou soubory komprimovány. Navíc se soubory komprimovanými do jednoho bloku (tedy nerozdělenými do více bloků) lze manipulovat bez nutnosti použití bloků předcházejících. Slouží k tomu přepínač –v v několika podobách:
■
-vnumber – archiv bude rozdělen do bloků o velikosti number kilobajtů.
■
-va – autodetekce volného místa na přenosném médiu.
■
-vi – zákaz testu, zda byla do disketové jednotky vložena prázdná disketa
■
-vrnumber – rezervuj v prvním bloku number kilobajtů
■
-vsCMD – před vytvořením každého bloku spusť dosovský příkaz CMD.
■
-vv – pípnutí po dokončení každého bloku.
■
-vw – nerozdělovat soubory do více bloků. Každý soubor se bude nacházet právě
v jednom bloku.
Při přímé komprimaci na diskety nebo jiné přenosné médium je možné zapnout verifikaci vytvářených archivů a nastavit pracovní adresář na pevný disk nebo dokonce
RAM disk pro zrychlení celé operace.
■
-wtemp – parametr temp je název pracovního adresáře.
In addition, only ARJ allows the user to restart an aborted
■
ARJ poskytuje volitelnou ochranu archivů proti poškození. Pokud chcete této funkce
využít, použijte při vytváření archivu přepínač –hk.
■
Registrovaná verze programu ARJ umožňuje tvorbu samorozbalovacích archivů rozdělených do bloků (např. WinRAR umožňuje tuto volbu již v sharewarové verzi). Jednoblokové samorozbalovací soubory jsou tvořeny přepínačem –je).
■
ARJ poskytuje mezi všemi dostupnými archivačními programy patrně nejvyšší stupeň
flexibility při manipulaci s archivy. Např.:
■
Vyhledávání textových řetězců v souborech archivů, aniž by bylo nutné soubory dekomprimovat (příkazy w a s).
■
Dnes již více méně standardní podpora dlouhých názvů souborů.
153
■
Možnost přeuspořádání souborů uvnitř archivů (příkaz o).
■
Spojení dvou či více archivů bez nutnosti znovu komprimovat soubory v těchto archivech obsažené (příkaz j).
■
Možnost rozbalení archivů přímo na jakékoli médium a adresář (přepínač -ht).
■
Možnost astavit rychlost a kvalitu komprese (přepínače –m a -jm).
■
Možnost přidat komentáře k archivům (příkaz c a přepínač –z).
■
Možnost manipulovat se soubory archivu v závislosti na jejich datu (přepínače
–n a –o) nebo názvu (přepínač –x).
■
Možnost opatřit archivy heslem (příkaz g nebo přepínač –g).
■
Možnost verifikace archivů již při jejich vytváření (přepínač –jt).
■
Nastavit buffer pro slovník Huffmanových kódů (přepínač –jh).
■
Přejmenovat soubory archivu při rozbalování (přepínač –jw).
■
Archivační program ARJ je dosud asi nejrozšířenějším archivačním programem nejen
u nás.
■
Široká škála možností při používání zástupných znaků namísto jmen souborů:
■
* nebo *.* - znamená všechny soubory
■
*. - znamená všechny soubory bez přípony
■
*.DOC - znamená všechny soubory s příponou DOC
■
?B* - znamená všechny soubory, kde druhé písmeno názvu je ‘B’
■
?? - znamená všechny soubory s dvoupísmenným názvem
■
*1* - znamená všechny soubory, jejichž název obsahuje znak ‘1’
JAR
JAR není jen prostředek na mytí nádobí, ale je to také jeden z vysoce výkonných archivačních programů z tvůrčí dílny Roberta Junga, tedy firmy ARJSoftware, která produkuje
všechny verze výše zmíněného programu ARJ.
154
Tip:
Hned na začátku je potřeba zdůraznit, že se jedná o jiný archivační program než ARJ.
Archivy vytvořené programy JAR a ARJ tedy nejsou kompatibilní. Přípona archivů
JAR je J.
Tento mladší bratříček programu ARJ (popisována je verze JAR 1.02) nezapře podobu se
svým starším bratrem. Jedná se o program s velice podobným (téměř shodným) uživatelským rozhraním – JAR se spouští opět z příkazové řádky DOSu, i když s poněkud rozšířenou syntaxí:
JAR{16|32} <command> [<options>] <archive_name> [<target_dir\>] [<files>]
JAR je však na rozdíl od ARJ dostupný jak v 16bitové, tak i v 32bitové verzi (viz číslo v
názvu programu). 32bitová verze je určena pro operační systémy Windows 95 a NT a je samozřejmě mnohem rychlejší než dosová 16bitová verze. Stejně tak i dosahované kompresní
poměry jsou lepší u 32bitové verze.
Jaký je tedy rozdíl mezi programy ARJ a JAR?
■
Hlavním rozdílem je samozřejmě pozměněný kompresní algoritmus, který je ovšem výrobním tajemstvím Roberta Junga. Pro srovnání výkonnosti obou archivačních programů viz kapitolu popisující výkonové ukazatele jednotlivých archivačních programů.
■
Ačkoli existují určité odlišnosti v použití některých příkazů a přepínačů, je jejich použití prakticky stejné a při běžném každodenním používání programu JAR tyto odlišnosti vůbec nezjistíte.
■
Zajímavou možnost představuje konfigurační soubor JAR.cfg, který je společný pro
16ti i 32bitovou verzi. Tento soubor umožňuje uživateli nastavit implicitní hodnoty
používané programem pro práci s pamětí, implicitní nastavení přepínačů používaných
spolu s určitými příkazy a mnoho dalšího.
Konfigurační soubor
Konfigurační soubor JAR.cfg musí být umístěn do stejného adresáře jako programy JAR16
a JAR32. Tento soubor obsahuje obecná nastavení programu JAR.
155
Členění souboru je podobné jako u jiných konfiguračních a inicializačních souborů (např.
WIN.INI). Obsahuje tři druhy řetězců:
■
Komentáře začínající znakem středník (;)
■
Nastavení hodnot systémových proměnných programu JAR
<Key name>=<value>
■
Označení jednotlivých oddílů uzavřených do hranatých závorek
Např:
SwapFileDirectory=c:\tmp
[OS/2 settings]
SwapFileDirectory=d:\tmp
[Windows NT settings]
SwapFileDirectory=e:\tmp
Popišme si nyní význam jednotlivých klíčových slov, která je možné v konfiguračním souboru programu JAR použít:
■
ColoredOutput – možné hodnoty Yes/No. Použití barevného výstupu na obrazovku
■
SwapFileDirectory – nastavení pracovního adresáře používaného pro vytváření swapovacích souborů
Např.:
SwapFileDirectory=c:\tmp
■
■
FullPath – možné hodnoty Yes/No. Nastavuje přepínač –jf jako implicitní.
■
DefaultAccessProtection – možné hodnoty "Authenticate" nebo "GOST v1.01". Udává implicitní metodu ochrany dat (viz přepínač –hg).
XmsLimit a EmsLimit – nastavuje maximální velikost XMS a EMS paměti v kilobajtech. Toto nastavení používá pouze 16bitová verze JAR.
Tip:
Autor doporučuje používat nejméně 1024 kilobajtů XMS pro vyšší výkon programu.
Optimální hodnota pro EMS je okolo 4096 kilobajtů.
156
■
CheckAvailableMemory – možné hodnoty Yes/No. Povolení či zákaz empirického testu dostupné paměti před spuštěním komprese. Pokud je test povolen, program JAR nastaví ještě před kompresí limit pro používání dostupné paměti tak, aby nebyl snížen
celkový výkon programu.
■
32MemoryLimit – Nastavení omezení v používání paměti kompresním strojem programu JAR při kompresi (v kilobajtech). Nastavení využívá pouze 32bitová verze
a doporučená hodnota je 4096.
■
InteractiveCriticalErrorHandler – možné hodnoty Yes/No. Interaktivní ošetření chyb.
Vyskytne-li se při běhu programu chyba a nastavení této proměnné je Yes, zobrazí se
otázka typu Drive not ready. Abort, Retry? apod. Nastavení používá pouze 16bitová
verze.
■
ErrorsToStdout – možné hodnoty Yes/No. Je-li nastavena hodnota Yes, jsou všechna
chybová hlášení zapisována do souboru, stejně jako jiná hlášení programu JAR.
■
EmulateANSIComments – možné hodnoty Yes/No.
■
OptionsForCommand command – implicitní nastavení přepínačů pro příkaz command.
Implicitní nastavení může být v každém konkrétním spuštění programu JAR změněno. Právě tato sada možností je z uživatelského hlediska zřejmě nejpřínosnější. Chcete-li například výpisy archivů řadit podle přípony souborů, zapište do konfiguračního
souboru následující řádek:
OptionsForCommand L=-ju1
■
HideMarkedFiles - možné hodnoty Yes/No. Skrytí zprávu Marking file pro příkaz ac.
■
DefaultColor
■
ErrorColor
■
SignalColor
■
CommentColor
■
HighlightColor
Nastavení barevného výstupu programu JAR. Zde je tabulka hodnot:
černá
(0)
šedá
(8)
modrá
(1)
světle modrá
(9)
157
zelená
(2)
světle zelená
(10)
cyan
(3)
light cyan
(11)
červená
(4)
světle červená
(12)
fialová
(5)
světle fialová
(13)
hnědá
(6)
žlutá
(14)
bílá
(7)
zářivě bílá
(15)
■
HighIntensityColors - možné hodnoty Yes/No. Při nastavení Yes používá JAR pouze
intenzivnější světlé barvy.
ACE
Archivační program ACE ver. 1.2 je v testech výkonnostních ukazatelů srovnatelný s výše
uvedenými a velice oblíbenými programy typu WinRAR nebo ARJ. Navíc vyniká poměrně
krátkou dobou komprese, která je v publikovaných výkonových ukazatelích často o několik
minut kratší oproti konkurenci. ACE vytváří archivy s příponou ACE.
Navíc se jedná o zástupce těch produktů pracujících na platformě DOS, které je možné
spustit jak z příkazové řádky za pomoci příkazů a přepínačů, tak i v textovém interaktivním módu (podobně jako RAR pro DOS). ACE je navíc dostupný i v 32bitové verzi a verzi
pro OS/2.
U tohoto produktu se zaměřme pro změnu na popis funkčních kláves dostupných v interaktivním textovém módu (funkce většiny těchto kláves je shodná s funkcí kláves v programu
RAR).
158
■
F1 - Nápověda
■
F2 - Přidat vybrané soubory do archivu
■
F3 - Prohlédnout soubor
■
F4 - aktualizovat soubory druhého adresáře soubory adresáře prvního
■
F5 - kopírovat soubory do jiného adresáře. V závislosti na typu souboru (je-li či není
součástí archivu) a cílového adresáře může být soubor komprimován či dekomprimován.
■
F6 - stejná funkce jako F5, po úspěšném dokončení operace se však zdrojový soubor
smaže.
■
F7 - vytvořit nový adresář
■
F8 - smazat vybrané soubory či adresáře
■
F9 - zobrazit okno pro definování implicitních nastavení programu
Tip:
Nastavení zapnutá v okně zobrazeném klávesou F9 jsou uložena do konfiguračního
souboru ACE.cfg.
■
F10 - ukončit program ACE
■
Alt+F1 - změnit aktuální disk
■
Alt+F2 - vytvoření kompaktního archivu (solid archive)
■
Alt+F3 - vytvoření samorozbalovacího archivu
■
Alt+F4 - aktualizace druhého adresáře soubory z prvního
■
Alt+F5 - vytvoření archivu ve druhém adresáři obsahujícího označené soubory z prvního adresáře.
■
Alt+F6 - jako Alt+F5, původní soubory budou smazány
■
Alt+F7 - vytvořit nový archiv v aktivním adresáři.
■
Alt+F8 - oprava poškozeného archivu. Vytvoří soubor "REPAIRED.ACE", který bude
obsahovat všechny opravené soubory z označeného archivu.
■
Alt+F9 - přepnutí zobrazení EGA/VGA .
■
Ctrl+F1 - prohlédnout si manuálový soubor ACE.DOC
■
Ctrl+F3..Ctrl+F6 - řazení souborů v aktivním adresáři postupně podle názvu, přípony,
času, velikosti
159
Následující funkční klávesy mají odlišný význam, pokud pracujete se soubory nikoli v aktivním adresáři, ale v aktivním archivu.
Tip:
Soubory archivu zobrazíte tak, že poklepete myší (nebo použijete klávesu Enter) na název
archivu s příponou ACE.
■
F2 - rozbalit označené soubory do aktivního adresáře
■
Alt+F2 - pokud je tento příkaz aplikován na standardní archiv, je překonvertován na
kompaktní (solid archive)
■
Alt+F3 - pokud je tento příkaz aplikován na standardní archiv, je překonvertován na
samorozbalovací
■
Alt+F7 - možnost přidání hesla či komentáře k archivovanému souboru.
■
Alt+F8 - zobrazí okno, ve kterém lze změnit některé charakteristiky archivu jako celku (např. přidat komentář nikoli k jednotlivému archivovanému souboru, ale k celému
archivu.
■
Alt+F10 - test integrity archivu.
Shrnutí
Z velkého množství archivačních programů dostupných na Internetu všem uživatelům popisují předcházející kapitoly 5 vzorových programů, které vystihují různé
přístupy svých autorů co do uživatelského rozhraní a komprimačních možností.
Zbývá otázka, který archivační program si zvolit. Přístup každého uživatele bude
samozřejmě specifický, ale přesto se pokusím zdůraznit několik faktorů, které by
výběr archivačního programu měly ovlivňovat nejvíce.
■
160
Pokud budete používat program pro archivaci a zálohování svých vlastních rozsáhlých dat, bude asi nedůležitějším faktorem výkon archivačního programu. To
znamená především kompresní poměr a v závislosti na frekvenci zálohování
i doba potřebná pro kompresi. Nejnovější výkonové ukazatele jsou publikovány
na stránce http://personal.nbnet.ca/jeffg/act.html a pravidelně se aktualizují. Nezapomeňte, že výkonové ukazatele jednotlivých programů jsou silně závislé na
typu komprimovaných dat.
■
Většina z vás bude asi patřit spíše do skupiny lidí, kteří používají archivační programy proto, aby svá data mohli přenášet mezi jednotlivými počítači, ať již po
Internetu nebo prostě na disketách. V takovém případě bude vystupovat do popředí důležitost intuitivního a příjemného uživatelského prostředí a především
kompatibilita jednotlivých archivačních programů.
Tady lze asi nejvíce doporučit WinZip nebo WinRAR. Oba tyto produkty se vyznačují velice příjemným uživatelským prostředím (WinRAR lze navíc spouštět i z příkazové řádky) a akceptovatelným kompresním poměrem (i zde vede WinRAR). Ve
většině případů však WinRAR platí za lepší kompresní poměry nepřiměřeným prodloužením doby potřebné pro komprimaci (WinZIP je nezřídka o mnoho minut rychlejší).
Otázku větší kompatibility opět není možné jednoznačně zodpovědět. WinZIP je
pravděpodobně stále mnohem rozšířenějším programem, který však dokáže manipulovat z ostatních moderních archivačních programů pouze s programy ARJ, zato
však ovládá formát MIME nebo UUcode pro přenos binárních souborů.
WinRAR naproti tomu dokáže prohlížet, dekomprimovat, mazat a komentovat soubory obsažené v archivech ZIP, ARJ a LZH. Ovládá tedy i archivy svých konkurentů. Zároveň dokáže tyto archivy překonvertovat na samorozbalovací.
Jistě najdete i další argumenty pro i proti a možná nakonec vyberete za svůj oblíbený úplně jiný program. Otázka výběru archivačního programu je z velké části věcí
subjektivní. Přeji vám šťastnou ruku při jejím řešní.
161
6
Slovníček
Slovníček
Adaptivní metody
Jedná se o podmnožinu tzv. slovníkových metod. Adaptivní kompresní algoritmus je
schopen zjistit do určité míry nezávislost dosaženého kompresního poměru na komprimovaných datech. Algoritmy si budují své vlastní slovníky pro každý komprimovaný
soubor dat dynamicky v průběhu kódování. Nejčastěji se vyskytujícím posloupnostem bitů nebo bajtů je přiřazen nejkratší kódový symbol a tím se dosahuje maximálního možného kompresního poměru. Adaptivní algoritmy neobsahují žádné statické slovníky řetězců. Viz také neadaptivní metody.
Archiv
Soubor obsahující komprimovaná data souborů a jejich strukturu adresářů. Takové archivy jsou tvořeny tzv. komprimačními nebo archivačními programy (např. ARJ, ZIP, RAR
a mnoho dalších). Komprimace archivačních programů je vždy bezztrátová. Viz také
Self-extracting archiv, Solid archiv, Volume.
Aritmetické kódování kóduje celou zprávu jako jediné kódové slovo. Základní myšlenku
použitou v této komprimační metodě lze popsat ve stručnosti takto: aritmetické kódování
reprezentuje celou zprávu jako číslo z intervalu <0,1). Na začátku kódování uvažujeme
celý tento interval. Jak se zpráva prodlužuje, zužujeme postupně interval v závislosti na
pravděpodobnosti výskytu každého nového znaku – přibližují se k sobě i horní a dolní
mez nově vytvářeného intervalu. Na konec stačí zapsat libovolné číslo z výsledného intervalu – to samo o sobě reprezentuje celou zprávu.
ARJ
Archivační program pracující pod operačním systémem MS-DOS určený pro bezztrátovou archivaci souborů.
Bajt
Uspořádaná osmice bitů. Do jednoho bajtu lze uložit 256 různých hodnot.
Barevná hloubka
Barevná hloubka specifikuje počet barev na jeden pixel digitalizovaného obrázku. Barevná hloubka 1 bit na pixel se používá pro černobílé obrázky (nikoli pro obrázky s několika odstíny šedé). Barevná hloubka 8 bitů na pixel se používá pro obrázky obsahující 256
barev nebo 256 odstínů šedé atd.
165
Benchmarks
Výkonové ukazatele archivačních programů. Na základě těchto výkonových ukazatelů
lze provést porovnání výkonu těchto programů. Mezi základní výkonové ukazatele patří:
■
Kompresní poměr.
■
Doba komprese.
■
Doba dekomprese.
■
Poměr kompresního poměru a doby potřebné pro kompresi určitého druhu dat.
Bezztrátová komprimace (lossyless compression)
Bezztrátová komprimace má tu vlastnost, že data, která projdou procesem komprimace
a následné dekomprimace jsou identická s původními. Při procesu komprese se tedy neztrácí žádné informace obsažené v původních datech. Bezztrátová komprimace (lossyless
compression) se používá – jak již sám název napovídá – tam, kde si nelze dovolit jakoukoli ztrátu dat – u binárních a textových souborů a také u některých grafických souborů.
Bit
Základní jednotka informace. Může obsahovat pouze dvě různé hodnoty.
Bitová mapa
Dvourozměrné pole hodnot – pixelů – tvořících obrázek, kde každá hodnota pole nese
grafickou informaci uloženou v jednom pixelu. Viz také barevná hloubka.
CRC (Cyclic Redundancy Check)
Kompresní algoritmy odstraňující cyklickou redundanci komprimovaných dat.
DCT (diskrétní kosinová transformace)
Jeden z kroků kódovacího algoritmu, který používají ke kompresi grafických obrázků
standardy JPEG a MPEG. Diskrétní kosinová transformace v podstatě převede amplitudovou informaci na informaci frekvenční, u které lze jednoduše rozlišit, které části informace jsou pro danou oblast obrazu dominantní (nižší frekvence) a které části popisují
pouze jemné detaily (vyšší frekvence). Pro každý obrázek (nebo jeho část) se tak získá
nová matice hodnot. Na rozdíl od původní matice, kde byla obrazová informace rozložena rovnoměrně (pro každý pixel jsme znali jeho barevnou hodnotu), po aplikování transformace se informace s největším vlivem dostaly do levého horního rohu a se zvětšující
se vzdáleností od něj důležitost informací klesá. Tím se dominantní a důležitější složky
166
Slovníček
obrazu reprezentované nižšími frekvencemi oddělí od drobných detailů (vyšších frekvencí) a obraz je tak připraven pro ztrátový komprimační krok – redukci vypuštěním těchto
drobných detailů.
Fraktální komprese
Jedná se o ztrátovou kompresi. Fraktální komprese je založena na existenci tzv. fraktální
geometrie a jejího matematického popisu. Fraktální obrazce se daleko více než klasická
geometrie hladkých čar blíží „přírodním“ útvarům, jako jsou mraky, sněhové vločky
apod. Jediný matematický vzorec pak dokáže reprezentovat fraktální geometrický útvar.
Základní myšlenka fraktální obrazové komprimace spočívá ve snaze rozeznat v částech
digitalizovaných obrázků fraktální geometrický útvar a ten potom vyjádřit matematickým
vzorcem. Komprese je poměrně pomalá, neboť je důležitá důkladná analýza obrazu.
Fullcolor
Způsob ukládání barevných obrázků, který zachovává veškerou barevnou informaci. Barevná hloubka těchto obrázků je typicky 24 bitů na pixel.
Grabovací programy
Programy, které dokáží přímo z audio CD uložit skladby do formátu WAV.
Grayscale
Způsob ukládání černobílých obrázků jako bitové mapy s určitým počtem odstínů šedé.
Huffmanovo kódování je nejznámějším zástupcem skupiny algoritmů, které pracují na
základě různých četností znaků v kódovaných datech. Při komprimaci se postupuje tak,
že nejprve komprimační algoritmus zjistí pravděpodobnosti výskytů jednotlivých znaků
(příp. jejich kombinací) a každému znaku (kombinaci znaků) přiřadí jedinečný kód. Takovéto kódy se liší svou bitovou délkou.
Huffmanovo kódování patří mezi slovníkové metody, které jsou neadaptivní. To znamená, že používá statickou tabulku udávající jedinečné kódy, kterými jsou nahrazovány původní znaky nebo posloupnosti znaků.
167
JBIG
JBIG je zkratka Joint Bi-level Image Experts Group. JBIG je metoda pro bezztrátovou
kompresi obrazů, které obsahují nízký počet odstínů šedé, ideálně pouze černou a bílou.
Tato metoda se využívá především u faxů. Obecně je JBIG metodou pro kompresi černobílých obrázků s nejvýš osmi bity na pixel (tj. maximálně 256 odstíny šedé).
JPEG
Jedná se o ztrátovou kompresi redundantních grafických předloh. Zkratka JPEG znamená Joint Photographic Experts Group – komise pro standardy pracující pod International
Standard Organization (ISO).
JPEG není samotným přesně definovaným algoritmem. Jedná se spíše o sadu kompresních metod, které mohou být přizpůsobeny konkrétním požadavkům uživatele. Z toho je
zřejmé, že JPEG není ani přesně definovaným grafickým formátem.
Kompresní poměr
Nejdůležitější výkonový ukazatel (benchmark) komprimačních programů. Tento parametr bývá při testování komprimačních programů vyjadřován v několika různých formách,
které však při správné interpretaci vystihují totéž.
Kompresní poměr bývá udáván jako:
168
■
Poměr mezi velikostí komprimovaného a původního souboru. Podle tohoto schématu
pokud komprimační program zkomprimuje soubor o původní délce 200 KB na 50 KB,
je udáván kompresní poměr 25 %. Jedná se vlastně o procentuální vyjádření velikosti
souboru komprimovaného vzhledem k původnímu. Čím menší procentuální vyjádření,
tím lepší výsledek komprimace.
■
Někdy je tento poměr nahrazen doplňkem předcházejícího údaje do 100 %. Předcházející příklad komprimace souboru o původní délce 200 KB na 50 KB ve sbaleném
stavu by byl charakterizován kompresním poměrem 75 %. V tomto případě naopak
čím vyšší procentuální vyjádření, tím lepší výsledek komprimace.
■
Existuje také vyjádření kompresního poměru převráceným zlomkem -– jedná se o poměr velikostí nekomprimovaných dat ke komprimovaným. Předcházející příklad komprimace souboru o původní délce 200 KB na 50 KB ve sbaleném stavu by byl tedy
charakterizován kompresním poměrem 4:1. V praxi se opravdu můžete setkat se všemi uvedenými definicemi kompresního poměru.
Slovníček
Komprimace
Komprimace (komprese) dat je termínem vystihujícím proces zakódování původních dat
takovým způsobem, aby kódovaná podoba původních dat zabírala menší prostor na paměťovém médiu. Viz také benchmarks a kompresní poměr.
Kvantifikace
Kvantifikace vlastně znamená dělení čísla jinou hodnotou. Tím se dosahuje snížení počtu
bitů nesoucích příslušnou informaci na úkor informace obsažené v nejméně významných
bitech.
■
Skalární kvantifikace spočívá v tom, že skalární hodnota je reprezentována fixní
podmnožinou bitů. Pokud například u obrázku s barevnou hloubkou 16 bitů na pixel
reprezentujeme každý pixel pouze významnější osmicí bitů, dochází ke komprimaci
obrazu v poměru 2:1 za cenu ztráty barevné informace.
■
Vektorová kvantifikace se nezakládá na reprezentaci jednotlivých hodnot, ale malých
polí těchto hodnot. Např. barevný obrázek může být reprezentován 2D polem tripletů
(RGB hodnot). Ve většině obrázků nevyužívají tyto triplety celý barevný prostor RGB,
ale mají tendenci koncentrovat barvy do určitých částí obrázků. Obrázek lesa bude
složen především z bodů zelené barvy. Je tedy možné vybrat relativně malou oblast
a v ní aproximovat každý triplet reprezentativní barvou. Triplet tak degeneruje ze tří
bajtů na jediný bajt opět za cenu rozumné ztráty barevné informace.
Skalární a vektorová kvantifikace není samostatnou formou ztrátové komprese, ale většinou se používá ve spojení s jinými metodami.
Layers
Části kompresního standardu MPEG-1 definující ztrátovou kompresi zvuků ve videosekvencích.
LZW (algoritmus Lempel-Ziv-Welch)
Rodina komprimačních algoritmů známá především pod označením algoritmus LempelZiv-Welch (LZW) (také substituční nebo slovníková metoda) je velice rozšířená při bezztrátové komprimaci jak grafických, tak i binárních či textových dat.
Základním principem tohoto kompresního algoritmu je vyhledávání stejných posloupností bajtů v originálním souboru. Zápisem odkazů na tyto posloupnosti dat algoritmus buduje datový slovník – na rozdíl od Huffmanova kódování se jedná o adaptivní metodu.
Každý další výskyt takové posloupnosti bajtů se zakóduje buď
169
■
odkazem na předcházející výskyt posloupnosti nebo
■
použitím slovníkového odkazu spojeného s příslušným řetězcem.
MPEG
MPEG je zkratka pro Moving Picture Expert Group, komisi, která se zabývá vývojem
standardů pro komprimaci videa a připojeného audiosignálu. Skupina pracuje pod organizací ISO – International Standards Organization.
Existuje několik norem pro kompresi videa MPEG, které vyhovují různým oblastem využití. Všechny kompresní standardy jsou ztrátové.
Neadaptivní metody
Neadaptivní algoritmy jsou určeny výhradně pro komprimaci specifického druhu dat.
Většinou obsahují předdefinované slovníky nebo řetězce znaků, o kterých je známo, že
jejich pravděpodobnost výskytu v souborech dat je vysoká.
Neadaptivní algoritmus určený pro komprimaci anglického textu bude obsahovat slovníkové řetězce jako „the“ nebo „of“, které bude nahrazovat předem definovaným znakem.
Tento způsob komprimace by však byl velice málo účinný na text v jiném jazyce,
o obrázcích nebo binárních datech nemluvě. Na druhou stranu použití neadaptivního algoritmu na vhodný druh dat je nejen velice účinné co do dosaženého kompresního poměru, ale i času potřebného pro kompresi a dekompresi dat.
Palette
Způsob ukládání digitalizovaných obrázků využívající předdefinovanou paletu barev. Typická barevná hloubka těchto obrázků je 8 bitů na pixel.
Pixel
Bod, který je základní stavební jednotkou většiny grafických obrázků. Viz také bitová
mapa a barevná hloubka.
RAR
Jeden z nejoblíbenějších archivačních programů. Je určen jak pro operační systém
MS-DOS, tak i Windows (WinRAR).
Redundance
Přeurčení, nadbytečná informace obsažená ve vstupních datech. Vypuštění této nadbytečné informace je základní myšlenkou ztrátové komprimace obrazových a zvukových dat.
170
Slovníček
RLE (Run-length Encoding)
Bezztrátová komprimační technika nazývaná „proudové kódování“. Základním principem komprimace metodou RLE je zhuštění opakovaných znaků, které se v souboru vyskytují hned za sebou. Řetězec opakujících se znaků se nazývá proud (odtud proudové
kódování). Tento proud znaků je vždy zkomprimován do formy jednoho paketu RLE. Paket musí vždy obsahovat dvě informace:
■
proudové číslo udávající počet znaků proudu snížený o jedničku a následující
■
proudovou hodnotu, jež se shoduje s hodnotou opakujícího se znaku v proudu.
Tato komprese dosahuje dobrých výsledků při aplikaci na jednoduché málobarevné obrázky s velkými jednobarevnými plochami.
Self-extracting archiv (samorozbalovací)
Archiv doplněný o spustitelný modul, který se používá pro rozbalení (dekomprimaci) archivovaných souborů.
Slovníkové metody
Základním principem slovníkových (substitučních) komprimačních metod je existence
převodní tabulky (slovníku), podle které je každému znaku nebo posloupnosti znaků původních dat přiřazen jedinečný kód. Viz také adaptivní a neadaptivní metody, LZW
a Huffmanovo kódování.
Solid archiv
Kompaktní archiv komprimovaných dat, který při komprimaci nakládá se všemi soubory
jako s jediným tokem dat. Výhodou tohoto druhu archivu je lepší kompresní poměr,
zvláště při kompresi velkého množství malých souborů. Nevýhodou je naopak pomalejší
rozbalování jednotlivého souboru (musí být analyzovány všechny soubory uložené v archivu) a ztráta veškerých komprimovaných dat i v případě, že je poškozen třeba jen jediný soubor archivu.
Switch
Přepínač.
171
Vlnková transformace (wavelet transformation)
Obecně se předpokládá, že vlnková transformace bude základem příštího standardu ve
ztrátové kompresi obrazu. Jedná se o matematickou transformaci do jiného ortogonálního prostoru (podobně jako diskrétní Fourierova transformace) při vhodném výběru jeho
ortonormální báze. Pomocí bázových funkcí se obrázek expanduje do většího počtu jednodušších obrázků, které vykazují vysokou redundanci.
Volume
Velké archivy mohou archivační programy rozdělit do několika bloků (volumes), aby bylo možné komprimovaná data uložit na několik disket. Velikost jednotlivého bloku lze
většinou v archivačních programech změnit.
YUV
Barevný model, kde je samostatně uchována jasová (Y) a dvě barvonosné složky
(U a V). Tento mód je pro ztrátovou komprimaci obrázků daleko vhodnější než obvykle
v počítači užívaný mód RGB. Důvodem je vlastnost lidského oka lépe rozeznávat změny
v intenzitě (jasu) a nikoli v malé změně barvy.
ZIP
Jeden z nejoblíbenějších archivačních programů. Je určen jak pro operační systém
MS-DOS, tak i Windows (WinZIP).
Ztrátové komprimační algoritmy kódují data způsobem, který nejen že nezaručuje stoprocentní obnovu dat po dekomprimaci, ale dokonce schválně některé informace při
kompresi ztrácí. Je zřejmé, že taková kompresní schémata lze použít pouze tam, kde existuje určitá redundance vstupních dat a kde ztrátou některých původních informací datový soubor neutrpí žádnou újmu. Takovými daty mohou být statické obrázky, zvuková data, data uchovávající videosekvence atp.
Výše uvedená data jsou redundantní ve vztahu k nedokonalosti lidských smyslů.
172
Ztrátové a bezztrátové druhy komprese
173
174
Rejstřík
Rejstřík
A
D
ACE, 158
adaptivní komprimace, 17
adaptivní metody, 139
archiv, 83, 139
archivy kompaktní (solid archives), 84
aritmetické kódování, 43, 139
ARJ, 139, 144
asymetrická komprimace, 17
DCT (diskrétní kosinová transformace), 61,
70, 140
diskrétní kosinová transformace (DCT), 140
DMC (Dynamic Markov Coding), 49
Dynamic Markov Coding (DMC), 49
B
bajt, 139
barevná hloubka, 54, 65, 139
benchmarks, 10, 84, 140
bezztrátová komprese, 13, 21, 70, 140
binární strom, 40
bit, 140
bitová mapa, 140
C
CRC (Cyclic Redundancy Check), 140
Cyclic Redundancy Check (CRC), 140
F
Fractal Image Compression (fraktální komprese), 66, 141
fraktální komprese (Fractal Image
Compression), 66, 141
frekvence znaků, 49
fullcolor, 141
fyzická komprimace, 16
G
GIF, 55
grabovací programy, 141
grayscale, 141
H
Haarovy transformace, 64
Huffmanovo kódování, 17, 39, 73, 141
175
Rejstřík
J
JAR, 154
JBIG, 70, 142
JFIF, 59
JPEG progresivní, 56
JPEG základní, 56
JPEG, 53, 69, 70, 142
N
neadaptivní komprimace, 17
neadaptivní metody, 144
K
P
komprese audio dat, 76
komprese videosnímků, 79
kompresní poměr, 10, 55, 68, 78, 137, 142
komprimace obrazových dat, 53
komprimace, 143
kvalita obrázku, 54
kvantifikace, 61, 143
palette, 144
PCX, 23, 28
pixel, 144
L
Lempel-Ziv-Welsh (LZW), 32, 56
logická komprimace, 16
LZ77, 33
LZ78, 34
LZW (Lempel-Ziv-Welsh), 56
LZW, 143
M
modifikace RLE, 23
MPEG, 71, 144
MPEG-1, 71, 76
176
MPEG-2, 72
MPEG-3, 72
MPEG-4, 72
Q
Q faktor, 54
R
RAR, 118, 144
redukce barev, 61
redundance, 144
redundantní data, 54
redundantní soubory, 14
RGB, 61
RLE (Run-length Encoding), 21, 145
Run-length Encoding (RLE), 145
rychlost dekomprimace, 11
rychlost komprimace, 11
Rejstřík
S
W
samorozbalovací archiv, 84, 133
self-extracting archiv (samorozbalovací), 145
Shannon-Fanovo kódování, 42
skalární kvantifikace, 69
solid archives (kompaktní archivy), 84, 133,
145
substituční metoda, 32
symetrická komprimace, 17
WAV, 77
wavelet transformation (vlnková transformace), 64
WinRAR, 117
WinZip, 135
Z
ZIP, 146
ztrátová komprese, 13, 53, 56, 146
T
transformace barev, 61
V
vektorová kvantifikace, 69
vektorové obrázky, 55
vlnková transformace (wavelet transformation), 64, 70, 146
volume, 84, 146
177
Doporučená literatura vydavatelstvi Computer Press:
Další podrobné informace o komprimačních metodách naleznete v publikaci:
Encyklopedie grafických formátů II., James D. Murray, 1200 stran + CD-ROM, [ K0113 ]

a archivační programy

Transkript

Podobné dokumenty

Antiviry 2013

Untitled - Bianchi

PDF catalogue

Pravidla pro převod studijních materiálů do formátu EED I a EED II

příloha LZ 1/2016

(Formát PDF DOSI_MAN).

Seznam rizikových pøípon systému a aplikací