LZ77 і LZ78: відмінності між версіями
[неперевірена версія] | [перевірена версія] |
Вилучено вміст Додано вміст
м додана Категорія:Алгоритми стиснення з допомогою HotCat |
Скасування редагування користувача (обговорення): стаття вже в категорії "стиснення без втрат" |
||
Рядок 1:
'''LZ77 і LZ78''', '''алгори́тм Ле́мпеля
== Історія виникнення ==
Більше тридцяти років [[Алгоритм Хафмана|алгоритм стиснення Хаффмана]] і його варіанти залишалися найпопулярнішими методами. Проте 1977 року ізраїльскі дослідники Авраам Лемпель і Яків Зів запропонували абсолютно інший підхід до цієї проблеми, висунувши ідею формування «словника» загальних послідовностей даних.
При цьому стиснення даних здійснюється за рахунок заміни записів відповідними кодами із словника. Існують два алгоритми стиснення даних
На роботу Велча звернула увагу група програмістів [[Unix]], які використали його алгоритм в їх додатку LZW, що отримав назву compress. Вони додали декілька удосконалень і опублікували загальнодоступну версію цієї програми в телеконференції Internet, завдяки чому багато користувачів змогли почати з нею працювати.
Рядок 11:
== Метод стиснення ==
Існує багато практичних алгоритмів стиснення даних, але всі вони базуються на трьох теоретичних способах зменшення надлишковості даних. Перший спосіб полягає в зміні вмісту даних, другий
Якщо при стисненні даних відбувається зміна їх вмісту, то метод стиснення є незворотнім, тобто при відновленні (розархівуванні) даних з архіву не відбувається повне відновлення інформації. Такі методи часто називаються методами стиснення з регульованими втратами інформації. Зрозуміло, що ці методи можна застосовувати тільки для таких типів даних, для яких втрата частини вмісту не приводить до суттєвого спотворення інформації. До таких типів даних відносяться відео- та аудіодані, а також графічні дані. Методи стиснення з регульованими втратами інформації забезпечують значно більший ступінь стиснення, але їх не можна застосовувати до текстових даних. Прикладами форматів стиснення з втратами інформації можуть бути: JPEG (Joint Photographic Experts Group) для графічних даних:
*
*
Якщо при стисненні даних відбувається тільки зміна структури даних, то метод стиснення є зворотнім. У цьому випадкові з архіву можна відновити інформацію повністю. Зворотні методи стиснення можна застосовувати до будь-яких типів даних, але вони дають менший ступінь стиснення у порівнянні з незворотними методами стиснення. Приклади форматів стиснення без втрати інформації: GIF (Graphics Interchange Format), TIFF (Tagged Image File Format)
== Кодування методом Лемпеля
Візьмемо набір символів<br
У ньому двічі зустрічається поєднання АБВ, тому його можна записати в так званому словнику, а в початковому тексті тільки залишити посилання на словник. Тоді початковий текст можна перетворити, наприклад, в<br
і окремо запам'ятати, що за символом 1 насправді ховається трійця АБВ. Ясно, що якщо в тексті поєднання АБВ зустрілося не 2 а 100 або ще краще 1000 разів, то стиснення було б вельми відчутним. Проте в реальних ситуаціях на таке везіння розраховувати не слід. Треба все вичавлювати навіть з небагатьох повторень в початковому тексті. Подивимося, чи багато ми вигадали в розглянутому прикладі.
Текст стискувався на 4 символи, але і, як мінімум, 4 символи опинилися у словнику. Крім того, побудова словника зажадає введення роздільників і ін.
Але і це ще не все. А якщо в тексті вже є символи 1 ? Як зрозуміти, що це саме 1, а не посилання на словник? Як же поступити найбільш грамотно? Ось тут відповідь далеко неоднозначна. Вона і не може бути однозначна, тому що стиснення
Для визначеності вважатимемо, що кожен символ в тексті
Послідовно читаємо початковий текст і одночасно формуємо вихідний файл. Якщо чергова буква зустрілася вперше, або вона виявилася останньою в тексті, то на вихід посилаємо біт 1 і 8 бітів від самої цієї букви. Так само треба поступити, якщо символ не новий але в парі з наступним ще не зустрічався. Отже в нашому прикладі перші три символи дадуть на виході 27 бітів. Тоді при зворотній операції як тільки той, що розшифровує побачив черговий біт 1, він відразу знатиме, наступні за ним 8 бітів треба вивести, так би мовити відкритим текстом.
Рядок 36:
Якщо черговий символ в парі з наступним за ним вже зустрічався то в принципі від цієї пари можна вивести два біта 01 і вказівку на існуючу аналогічну пару. Тоді декодувальник, побачивши 01, по цій вказівці подивиться на вже розшифровану частину тексту, візьме потрібну пару і припише таку саму в кінець розшифрованої частини.
В нашому прикладі достатньо двох байт них посилань. Отже на вихід пошлемо:<br
<center>001 11</center>
Далі від букви Я по відомих правилах піде 9 бітів. Залишок тексту шифрується сімома бітами:<br
Перша група з нулів, що закінчується одиницею, означає, що раніше в тексті вже була аналогічна п'ятірка символів. Друга група представляє число одиницю, вказуюче, на якій відстані треба шукати прототип. Прототип добудовуватиметься по ходу будівництва копії з нього, але випереджаючими темпами, достатніми для того, щоб копіювання не простоювало.
Таким чином, початковий текст в стислому вигляді при декілька вільному зображенні з'явиться у вигляді:<br
<center>1 А 1 Би 1 В 001 11 00001 01</center>
Правильніше (але менш наочно) було б вписати замість А, Би і В їх восьмибітові уявлення<br
Дерево Лемпеля
<center>[[Файл:Derevo.jpg|thumb|center|700px|Дерево Лемпеля
Щоб програма розшифровки годилася не тільки для розглянутого прикладу, ще до стислого тексту треба прикласти деякі параметри: довжину стислого або розгорненого тексту, а також довжину посилань. Само дерево прикладати не треба, якщо воно підкоряється простим широкоспоживаним правилам. Отже, дерево Лемпеля—Зіва може бути достатнє складним і розлогим.
Рядок 53:
Далі приводиться алгоритм розархівування зі всіма необхідними технічними подробицями і ретельно підібраними значеннями параметрів. Річ у тому, що навіть дуже невеликі варіації параметрів різко міняють ступінь стиснення і, як правило, в гіршу сторону. А боротьба ведеться за долі відсотка. Завдання ускладнюється тим, що немає об'єктивних критеріїв, по яких можна було відразу сказати, що та або інша зміна алгоритму пішла йому на користь. Як ми знаємо, для будь-якого архіватора знайдеться сила-силенна текстів, взагалі непіддатливих стисненню.
Якщо брати тільки такі тексти, то роботу можна не починати. Оцінювати архіватор треба по ходових текстах, але ходові
Зчитається чергова серія бітів до першого одиничного біта. Нехай N
# Якщо N більше або рівне 17, то прочитуються чергові 8 бітів і поміщаються в молодші біти числа M.
Рядок 68:
<center>Якщо M>2, Z=3, то K=14, R=-4672.</center>
# Прочитуються чергові K бітів і поміщаються в молодші K бітів допоміжного цілого двобайтного числа S. Решта бітів цього числа заповнюються одиницями. Отже S<0, оскільки в старшому біті, що відповідає за знак, знаходиться одиниця.
# Визначається адреса в тексті, що випускається, звідки буде узятий потрібний фрагмент. Адреса
== Варіанти вдосконалення ==
Приведені вище деталі алгоритму і значення параметрів не можуть бути виведені якими-небудь раціональними строгими методами. У якійсь мірі в них відбиті особливості сучасного програмування і людської мови. Але автори кожного архіватора знаходять свій оптимум, і що краще
Могутні архіватори зазвичай роблять попередню оцінку початкового файлу і до кожного файлу (або до великих частин одного файлу) здійснюють індивідуальний підхід. Наприклад, перед кожним великим фрагментом стислої коди вказується його обсяг і тип стискування для цього досить 3 байти, які не псують загальної якості компресії.
Рядок 77:
Якщо файл короткий, значить, взагалі дезархіватору не знадобиться заглядати далеко назад, тоді не потрібний, скажімо випадок K=14, і біти, що звільнилися, можна використовувати з більшою користю. Проте ефект порівняно невеликий. А оскільки він виявляється тільки на малих файлах, то на загальних (зазвичай гігантських) обсягах інформації він і зовсім втрачається.
Можливі багато інших варіантів удосконалень, не пов'язаних безпосередньо з характерними для Лемпеля
Можна виділяти в початковому файлі нестискувані ділянки. Тоді збиток від кожного з них можна понизити до трьох байтів. А в представленому варіанті кожен перенесений без змін символ тягне за собою однобайтну ознаку, тобто збиток 12,5 %.
Проте викладений вище алгоритм не враховує такі деталі тому що вони відносно рідкісні, а ефект від них скромний.
Рядок 94:
[[Категорія:Алгоритми стиснення без втрат]]
[[Категорія:Криптографічні алгоритми]]
|