Перегляд вихідного коду сторінки Стиснення без втрат

'''Стиснення без втрат''' ({{lang-en|Lossless compression}})&nbsp;— [[Стиснення даних|метод стиснення даних]], при використанні якого закодована інформація може бути повністю відновлена зі стиснутих даних. Навпаки, [[стиснення з втратами]] дозволяє лише відновлення даних, які є тільки наближенням до початкових даних. Для кожного з типів цифрової інформації, як правило, існують свої оптимальні алгоритми стиснення без втрат.

Стиснення даних без втрат використовується в багатьох програмах. Наприклад, воно використовується в усіх [[Архіватор|файлових архіваторах]]. Воно також використовується як компонент в стисненні з втратами.

Стиснення без втрат використовується, коли важливо, щоб відновленні дані були ідентичні оригіналу. Типовий приклад&nbsp;— [[виконуваний файл]] або [[джерельний код]], [[текстовий файл]]. Деякі графічні файлові формати, наприклад, [[PNG]] та [[GIF]] використовують тільки стиснення без втрат, тоді як формати [[TIFF]] та [[MNG]] можуть використовувати стиснення як з втратами, так й без втрат. Формати [[Стиснення звуку#Стиснення без втрат|стиснення звуку без втрат]] використовується для архівування або виробничих цілей, в той час, як менші формати стиснення аудіо з втратами використовуються в аудіопрогравачах та в ситуаціях коли простір для зберігання інформації обмежений або нема потреби в точному відтворенні інформації.

== Стиснення та комбінаторика ==
Легко довести наступну теорему.
{{Теорема|Не існує алгоритму стиснення, такого, що для  натурального ''N'':
# Будь-який файл довжини не більше ніж ''N'' байт або залишається тієї ж довжини, або зменшується.
# Існує файл довжини не більше ніж ''N'', який зменшується хоча б на один байт.}}
'''Доведення.''' Не обмежуючи спільність, можна припустити, що зменшився файл ''A'' довжини ''N''. Позначимо алфавіт як <math>\Theta</math>. Розглянемо множину <math>\Theta^0 \cup \Theta^1 \cup \ldots \cup \Theta^{N-1} \cup \{ A \}</math>. У цій множині <math>256^0 + 256^1 + \ldots + 256^{N-1} + 1</math> початкових файлів, в той час стиснених не більше ніж <math>256^0 + 256^1 + \ldots + 256^{N-1}</math>. Тому, відповідно до [[Принцип Діріхле|принципу Діріхле]] виникає протиріччя. ■

Втім, дана теорема анітрохи не кидає тінь на стиснення без втрат. Справа в тім, що будь-який алгоритм стиснення можна модифікувати так, щоб він збільшував розмір не більше ніж на 1 біт: Якщо алгоритм зменшив файл, пишемо «1», потім стиснені дані, якщо збільшив&nbsp;— пишемо «0», потім початкові дані.

Таким чином фрагменти, які не можливо стиснути, не спричинять неконтрольованого збільшення архіву. «Реальних» файлів довжини ''N'' набагато менше, ніж <math>256^{N}</math>(кажуть, що дані мають низку [[Інформаційна ентропія|інформаційну ентропію]])&nbsp;— наприклад, малоймовірно, щоб «їїї» зустрілося в розумному тексті, а в [[Цифровий звук|оцифрованому звуці]] амплітуда не може в момент зрости з 0 до 100&nbsp;%. До того ж шляхом спеціалізації алгоритмів на деякі типи даних (текст, зображення, звук, відео та ін.) вдається досягти високого рівня стиснення: таким чином застосовані в архіваторах універсальні алгоритми стискують звук приблизно у 1,5 рази, у той час як [[FLAC]]&nbsp;— у 2,5 рази. Більшість спеціалізованих алгоритмів малопридатні для файлів іншої природи: наприклад, звук погано стискається текстовими алгоритмами.

== Метод стиснення без втрат ==
У загальних рисах значення стиснення без втрат полягає в пошуку закономірності в початкових даних і з її урахуванням генерації іншої послідовності, яка повністю описує початкову. Наприклад, для кодування бінарних послідовностей, в яких багато нулів та мало одиниць, ми можемо використати таку заміну:
 00 → 0 
 01 → 10 
 10 → 110 
 11 → 111 
В такому випадку шістнадцять бітів
 00 01 00 00 11 10 00 00
будуть перетворені у 13 бітів
 0 10 0 0 111 110 0 0
Така заміна є видом [[Префіксний код|префіксного коду]], тобто має таку особливість: якщо ми запишемо стиснений рядок без пропусків, ми все одно зможемо розставити в ній пропуски&nbsp;— а тому, і відновити початкову послідовність. Найбільш відомим префіксним кодом є [[код Хаффмана]].

Більшість алгоритмів стиснення без втрат працюють у дві стадії: на першій генерується ''статистична модель'' для вхідних даних, друга представляє вхідні дані в бітовому вигляді, використовуючи модель для отримання «ймовірнісних» даних (тобто таких, що зустрічаються часто).

Статистичні моделі алгоритмів для тексту (чи текстових бінарних даних, таких як виконувальні файли) містять:
* [[Перетворення Берроуза-Вілера|Перетворення Берроуза&nbsp;— Вілера]]
* [[LZ77 і LZ78]]
* [[Алгоритм Лемпеля — Зіва — Велча|LZW]]
Алгоритми кодування через генерування бітових послідовностей:
* [[Код Хаффмана|Алгоритм Хаффмана]]
* [[Арифметичне кодування]]

== Обмеження ==
Алгоритми стиснення без втрат не можуть гарантувати стиснення для усіх видів вхідних даних. Іншими словами, для будь-якого алгоритму стиснення без втрат, існує такий набір вхідних даних, які не зменшуються після обробки алгоритмом, а навпаки&nbsp;— збільшуються. Це було доведено раніше{{Перехід|#Стиснення та комбінаторика}}.

Будь-який алгоритм, що робить деякі файли меншими, повинен робити деякі файли більшими, але не обов'язково, що вони стануть ''дуже'' великими. Практично використовуються алгоритми, що забезпечують собі механізм «виходу», що зупиняє кодування файлів, які можуть стати більшими після дії стиснення. Теоретично, один лиш додатковий біт потрібен, щоб сказати декодеру, що кодування вимкнене для усіх вхідних даних; проте, більшість кодувальних алгоритмів використовують більше ніж один повний байт для цієї цілі. Наприклад, файли стисненні алгоритмом [[Deflate|DEFLATE]] ніколи не збільшуються більше ніж на 5 байтів на 65 535 байтів вхідних даних.

Фактично, якщо ми розглядаємо усі рівноймовірні (тобто такі, чиє існування можливе з однаковою ймовірністю) файли довжини ''N'', тоді для будь-якого стиснення без втрат, що зменшує розмір якогось файлу, очікуваний розмір стисненого файлу (в середньому серед усіх можливих файлів довжини ''N'') повинен обов'язково бути більше ніж ''N''.{{Немає джерела}} Таким чином, якщо ми нічого не знаємо про властивості даних, що збираємось стискати, нам не варто стискати їх взагалі. Алгоритми стиснення без втрат корисні тільки якщо ми швидше за все стискаємо певні види даних ніж інші; тоді алгоритм повинен бути розроблений для ефективного їх стискання.

Отже, головною думкою є не те, що можливо зробити гірше, а те, що не завжди можна отримати непоганий результат. Тоді під вибором алгоритму звичайно розуміється непрямий вибір [[Підмножина|підмножини]] з усіх файлів, що стануть корисно меншими. Це теоретична причина для того, що ми маємо мати різні алгоритми для різних видів даних: не існує такого алгоритму, що був би хорошим для будь-якого файлу.

«Трюк», що дозволяє алгоритмам стиснення без втрат (при використанні на даних для яких вони були спроектовані) послідовно стискати файли до меншого розміру, є те, що файли, для яких алгоритми спроектовані діяти, мають деяку форму легко змодельованої [[Надмірність інформації|надмірності]], яку алгоритм повинен видаляти, таким чином зменшуючи їх розмір внаслідок цієї надмірності. Алгоритми в цілому цілком конкретно налаштовані на конкретний вид файлу: наприклад, програми для стиснення аудіо не працюють на текстах і навпаки.

Зокрема, файли, що складаються з [[Випадковість|випадкових]] даних, не можуть бути успішно стиснені ні одним із розумних алгоритмів: дійсно, результат такої дії використовується для визначення концепції випадковості в [[Теорія складності обчислень|теорії алгоритмічної складності]].

Доведено, що неможливо створити [[алгоритм]], який міг би стискати без втрат будь-які дані.<ref>comp.compression FAQ list entry #9: [http://www.faqs.org/faqs/compression-faq/part1/section-8.html Compression of random data (WEB, Gilbert and others)]</ref> Втім, впродовж років компанії заявляють про досягнення «досконалого стиснення», при якому довільне число ''N'' випадкових біт можуть завжди бути стиснені до ''N −'' 1 біт. Ці заяви можуть бути надійно відкинені навіть без поглиблення у деталі реалізації схеми їх роботи. Ці алгоритми не можуть існувати через суперечність з основними законами математики, бо якщо такий алгоритм існує, він міг би використовуватись циклічно для стиснення [[Інформація|даних]] до нульової довжини. З цієї причини, нібито досконалі алгоритми часто глузливо називають «магічними».

З іншого боку, було доведено{{Немає джерела}}, що не існує жодного алгоритму визначення можливості стиснення файлу в сенсі [[Складність та ентропія конструктивних об'єктів|колмогорівської складності]]. Хоча це можливо для будь-яких конкретних даних, навіть якщо вони здаються випадковими. Вони можуть бути істотно стиснені, навіть включаючи розмір декомпресора. Як приклад можна навести цифри числа [[Число пі|<math>\pi</math>]], що виглядають випадковими, але можуть бути створені дуже маленькою програмою (для пі це пояснюється тим, що його можна уявляти у вигляді нескінченного ряду, що на комп'ютері обчислюється ітеративно). Проте, хоч не може бути визначено, чи конкретний файл нестисливий, проста [[Складність та ентропія конструктивних об'єктів#Стиснення|теорема про нестисливі рядки]] показує, що більше ніж 99&nbsp;% файлів будь-якої даної довжини не можуть бути стиснені більше ніж на один байт (включаючи розмір декомпресора)

=== Математичне тло ===
Абстрактно кажучи, [[Стиснення даних|алгоритми стиснення]] можуть бути розглянуті як [[Функція (математика)|функції]] що діють на послідовності (зазвичай [[Байт|байтів]]). Стиснення успішне, якщо результативна послідовність менша ніж оригінальна (разом з інструкціями для мапи декомпресії). Для того, щоб алгоритм стиснення був без втрат, мапа компресії має формувати [[Взаємно однозначна відповідність|взаємно однозначну відповідність]] між звичайними та стисненими послідовностями бітів.

[[Принцип Діріхле]] вказує на відсутність бієктивного відношення між колекцією послідовностей довжини ''N'' та будь-якою підмножиною послідовностей довжини ''N''&nbsp;— 1. Тому неможливо розробити алгоритм, що зменшує розмір будь-якої вхідної послідовності.

=== Психологічне тло ===
Більшість повсякденних файлів відносно «рідкісні» з точки зору [[Інформаційна ентропія|інформаційної ентропії]], але таким чином, найбільш ефективні алгоритми стиснення без втрат застосовуються звичайними людьми для непоганого стиснення своїх звичайних файлів. Це може, через неправильне застосування інтуїції, привести деяких людей до думки, що добре спроектовані алгоритми можуть стискати ''будь-які'' вхідні дані, таким чином, визначаючи їх як ''магічні.''{{Немає джерела}}

=== Практичне застосування ===
Розробники алгоритмів стиснення розуміють, що потоки високої інформаційної ентропії не можуть бути стиснені, та відповідно включають до своїх програм механізми виявлення і обробки цієї умови. Очевидним способом виявлення це використання сирого алгоритму стиснення та перевірку на стискання вихідного файлу. Іноді виявлення проводиться [[Евристика|евристикою]]; наприклад, програма стиснення може розглядати файли, що мають закінчення «.zip», «.arj» або «.lha», такими, що вже більше не можуть бути стиснені. Загальний спосіб обробки цієї ситуації&nbsp;— це «цитуючий вивід», тобто вихідні дані мають частини вхідних даних, що дозволяє мінімізувати дію злоякісного збільшення після стиснення. Для прикладу, [[zip]] формат специфікує «метод стиснення» вхідних даних, що буквально копіюються до архіву.<ref>[http://www.pkware.com/documents/casestudies/APPNOTE.TXT ZIP file format specification] {{Webarchive|url=https://web.archive.org/web/20141205201932/http://www.pkware.com/documents/casestudies/APPNOTE.TXT |date=2014-12-05 }} by PKWARE, Inc., chapter V, section J</ref>

=== Виклик на мільйон випадкових чисел ===
Марк Нельсон, у відповідь на заяви про магічні алгоритми, створив 415 241 байтовий бінарний файл, що містить дані високої ентропії, та заявив про публічний виклик з нагородою в $100 для будь-кого, хто напише програму для стиснення файлу до розміру, який разом з розміром самої програми буде меншим від розміру оригіналу, та що зможе декодувати файл без помилок.<ref>{{Cite web|url=http://marknelson.us/2006/06/20/million-digit-challenge/|title="The Million Random Digit Challenge Revisited".|last=Nelson|first=Mark|date=2006-06-20|website=|publisher=|language=|accessdate=|archive-date=2016-06-05|archive-url=https://web.archive.org/web/20160605094343/http://marknelson.us/2006/06/20/million-digit-challenge/}} {{Webarchive|url=https://web.archive.org/web/20160605094343/http://marknelson.us/2006/06/20/million-digit-challenge/ |date=2016-06-05 }}</ref>

В часто заданих питаннях ([[FAQ]]) [[Група новин|новинної групи]] по стисненню міститься виклик Майка Голдмана<ref>{{Cite web|url=http://www.faqs.org/faqs/compression-faq/part1/section-8.html|title=Compression of random data|last=|first=|date=|website=|publisher=|language=|accessdate=}}</ref>, що пропонує $5 000 за програму, що може стискати випадкові дані. Патрік Крейг взяв учать у виклику, але перед стисненням він розбив вхідні дані на окремі файли, що закінчуються на 5, яка не зберігається як частина файлу. Опускаючи цей символ, він отримав в результаті розміри файлів (також, відповідно до правил, разом з розміром програми, що збирає їх докупи) менші ніж оригінал. Проте, фактично стиснення не відбулося, та інформація зберігається під назвами, необхідними для коректного відновлення оригіналу, і ця інформація не рахувалась разом з розміром файлів. Таким чином самих файлів недостатньо для відновлення; назви файлів також необхідні. Патрік Крейг погодився, що ніякого стиснення не відбувалось, але аргументував це тим, що умова виклику цього не потребувала. Повну історію цієї події, включаючи обговорення речей, що не відносяться до технічної сторони виклику, міститься на вебсайті Патріка Крейга.<ref>{{Cite web|url=http://www.patrickcraig.co.uk/other/compression.php|title=The $5000 Compression Challenge|last=Craig|first=Patrick|date=2001-03-26|website=|publisher=|language=en|accessdate=}}</ref>

== Приклади алгоритмів ==
* Родина алгоритмів [[LZ|Лемпеля-Зіва]]
* [[RLE]]
* [[Алгоритм Шеннона-Фано]]

== Перелік форматів стиснення без втрат ==
{{2 стовпці}}
* '''універсальні:'''
** [[Zip]],
** [[7-Zip]],
** [[RAR]],
** [[gzip|GZip]],
** [[PAQ]] та ін.
* '''[[аудіо]]'''
** [[Apple Lossless]],
** [[ATRAC|Adaptive Transform Acoustic Coding]],
** [[FLAC|FLAC (Free Lossless Audio Codec)]],
** [[Monkey's Audio|Monkey's Audio (APE)]],
** [[TTA|TTA (True Audio)]],
** [[WavPack]] та ін.
* '''[[зображення]]'''&nbsp;—
** [[BMP]],
** [[GIF]],
** [[PNG]]
** [[TIFF]]
** [[JPEG 2000]]
* '''[[відео]]'''&nbsp;—
** {{Нп|Dirac (відеоформат)|Dirac||Dirac (video compression format)}}
** {{Нп|FFV1|||FFV1}}
** [[HuffYUV]]
** {{Нп|Lagarith|||Lagarith}}
</div>

== Див. також ==
* [[Стиснення з втратами]]
* [[Стиснення звуку]]
* [[Стиснення відео]]

== Примітки ==
{{reflist}}

{{compu-stub}}
{{Методи стиснення даних}}
{{Програмне забезпечення для стиснення даних}}

[[Категорія:Стиснення даних]]
[[Категорія:Алгоритми стиснення без втрат| ]]