СоХабр закрыт.

С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.

H Неограниченное сжатие данных: демо-версия в черновиках

image

Что значит «неограниченное» сжатие?


Какое основное ограничение существует у нынешней технологии сжатия данных? Все существующие способы сжатия данных не способны преодолеть энтропийный предел сжатия данных. А речь идет сжатии данных без потерь информации: способе сокращения размера данных, при использовании которого они могут быть восстановлены в первоначальном виде с абсолютной точностью.

Как известно, в рамках ныне существующей теории информации уплотнение данных не может быть большим некоторого теоретического предела. Теорема Шеннона об источнике кодирования без шума устанавливает предел максимального уплотнения данных без потерь информации, утверждая, что данные невозможно уплотнить так, чтобы их код (число бит на символ алфавита или цифру разрядности) в среднем значении был меньше уровнем энтропии данных. То есть всегда имеется определенный предел степени сжатия, заданный энтропией входного потока данных, у которых различают их максимальную информационную емкость и действительную энтропию (их разница — это избыточность данных).

Экспертное мнение сходится на том, что «всегда сжатие достигается за счет устранения статистической избыточности в представлении информации. Ни один компрессор не может сжать любой файл. После обработки любым компрессором размер части файлов уменьшится, а оставшейся части — увеличится или останется неизменным. […] Поэтому невозможен „вечный“ архиватор, который способен бесконечное число раз сжимать свои же архивы. […] В области сжатия без потерь, т.е. собственно сжатия, такие революции невозможны» (Ватолин Д., Ратушняк А., Смирнов М., Юкин В. Методы сжатия данных. Устройство архиваторов, сжатия изображения и видео. — М.: ДИАЛОГ-МИФИ, 2003. — 384 с. ISBN 5-86404-170-x С. 18-19). Кстати на тех же страницах этой книги (она доступна в сети) убедительно доказывается, почему энтропийное кодирование не способно преодолеть энтропийный предел сжатия.

Совсем не обязательно быть знакомым с основами теории информации, чтобы проверить верность этого утверждения. Достаточно взять любую программу для сжатия данных, например Winrar, и попробовать повторно сжать уже ранее сжатый на максимальных настройках файл. Либо степень сжатия такого файла будет ничтожно мала, либо, что более всего вероятнее, повторное сжатие файла приведет к его увеличению (поскольку программа сжатия добавит к уже имеющемуся объему данных некоторую служебную информацию). Поэтому, осуществлять повторное, а тем более многократное циклическое сжатие уже эффективно сжатых данных существующими сейчас способами кодирование невозможно.

«Революции невозможны»?


image

Итак, возможен ли вообще тип кодирования, способный преодолеть энтропийный предел сжатия?
Да возможен. Рассмотрим это на простом примере. Вот десятичные данные с уровнем энтропии близким к максимальному:

2185 десятичных цифр
19110125979454775203564045597039645991980810489900943371395127892465205302426158030120593865197398502655
86440155794462235359212788673806972288410146915986602087961896757195701839281660338047611225975533626101
00148265112341314776825241149309444717696528275628519673751439535754247909321920664188301178716912255242
10700507090646743828708514499502565861944615431835113798491336917799281274338404315492368555267835963741
02105331546031353725325748636909159778690328266459182983815230286936572873691422648131291743762136325730
32164528297948686257624536221801767322494056764281936007872071383707235530544635615394640118534849379271
95145945055082327492216058489129109451899599486861995431476669380130371761635925944797461642200508850794
69804487133205133160739134230540198872570038329801246050197013467397175909027389493923817315786996845899
79478106804282243609378394633526542281570430283244238551508231649096728571217170812323279048181726832751
01127467823174109858886837085220007117334922539133223007561471804290075276777933523062006182860124552542
43061006894805446584704820650982664319360960388736258510747074340636286976576702699258649953557976318173
90255089133122329474393034395616132833407283166349825814522686200430779908468810380418736832480090387359
62129196336025831207816736737425333228792969072054905956214068888259912445818423795978634764843156737609
23625090371511798941424262270220066286486867868710182980872802560693101949280830825044198424796792058908
81711232719230145558291674679519743054802640464685400273399386079859446596150175258696581144756851004156
86877309037124825353438392853975987494584970500382250124892840018265900562512861876299380444073401423470
62055785305325034918189589707199305662188512963187501743535960282201038211616048545121039313312256332260
76643623668829685020883949614283048473911399166962264994856368523471287329479668088450940589395110465094
41379095022765456531330186706335213230284605194343813998105614006525953007317907727110657834941746426847
20956134647327748584238274899668755052504394218232191357223054066715373374248543645663782045701654593218
154053548393614250664498585403307466468541890148134347714650315037954175778622811776585876941680908203125

Итак 2185 десятичных цифр ( = 7258.4 бит = 907.3 байт) с примерно равными частотами распределений. Что может нам дать энтропийное кодирование? Практически ничего. Сжатие, даёт по формуле Шеннона, в лучшем случае 7255.526792 бит = 906.940849 байт. То есть выигрыш сжатия всего лишь 2.886095013 бит. И при этом к сжатым данным ещё необходимо будет добавить данные о 10 частотах распределений этих цифр, а значит, получим на выходе количество данных превышающее исходное. Есть ещё идеи? Похоже, что в рамках энтропийного кодирования нет.

Нужно выйти за эти пределы. Тогда можно записать эти 2185 цифр всего 7 знаками.

5^(5^5)

То есть, расширив алфавит кодирования лишь на три знака: ), ( и ^ мы формально получаем 7*log2(13)=25.9 бит ( = 3.24 байт). Теперь выигрыш сжатия составил -7232.5 бит + необходимо будет добавить некоторые служебные данные описания нового алфавита кодирования. То есть преодолеть энтропийный предел сжатия в каких-то случаях теоретически возможно. А практически?

Способ давно был бы рабочим, если бы не колоссальное количество вычислений которое потребуют случайные данные для такого рода кодирования перебором всевозможных алгебраических комбинаций. Кроме того, несмотря на конкретный пример, я пока не знаю математического доказательства возможности кодирования любых случайных данных в более краткую форму вышеуказанным образом.
Революционерам нужны великие потрясения, а нам нужны рабочие технологии. При этом весьма желательно, чтобы вычисления подобного рода не занимали миллиард лет до конца света.

Как это работает


image

Если случайные данные с почти равными (на то они и случайные) частотами распределений и, следовательно, с уровнем энтропии близким к максимальному. Энтропийное кодирование тут бессильно.

А что если бы нам удалось уменьшить их энтропию без потерь информации? Например, изменив частоты распределений символов алфавита. Ведь достаточно изменить частоту хотя бы одного символа алфавита (например, удвоить его количество по сравнению с остальными символами алфавита), и затем вполне можно использовать энтропийное кодирование, которое отлично работает с неравномерно распределенными знаками алфавита. Вопрос только в том, как это сделать. Причём желательно сделать безнаказанно (ничего не прибавляя к первоначальному объему данных).

Идея заключается в том, чтобы использовать энтропию против энтропии. Но конечно просто перемешивать и перетасовывать данные в надежде, что в них, наконец, появится какая-то неравномерность, не вариант. На это уйдут те же самые пресловутые миллиарды лет. А нам нужен не просто хаос, но хаос управляемый.

image

Итак, порядок сжатия следующий:


1. Допустим, у нас имеются 256-ричные данные (байт-код — БК) с уровнем энтропии близким максимальному (УЭБМ) (все знаки алфавита равномерно распределены). Например, там могут быть уже ранее эффективно сжатые данные. Сжать их существующими способами сжатия не получается поскольку у них УЭБМ и соответственно их избыточность близка к нулю.

2. В этом БК выбираем какой-либо знак алфавита. Поскольку количество всех знаков в БК примерно равно, не столь важно какой знак мы выберем. И для примера, выберем самый последний символ с кодом 255 (обозначим с255).

3. Сохраняем код расположения с255 среди всех остальных символов, после чего его удаляем. Полученные данные без с255 уже представляет собой 255-ричный алфавит.

4. С оставшимися данными производим n раз последовательное сложение по модулю 256, в результате чего в данных опять появляется с255 в количестве примерно равном количеству каждого вида символов (они равновероятны).

5. Теперь согласно коду расположения по пункту 3 вставляем ранее удаленные с255 на их первоначальные места. Теперь количество с255 примерно удвоено по сравнению с остальными символами алфавита.

6. Теперь можно применять энтропийное кодирование. Подсчитаем, какой выигрыш нам это даст: Допустим, всего БК по пункту 1 было 100 миллионов байт. Среднее количество каждого вида по 390625 байтов. В результате вышеуказанных операций мы примерно удвоили количество с255 и получили в среднем 781250 с255. После энтропийного сжатия этих закодированных данных получаем 99972649.54 байт. Выигрыш в результате такого кодирования составляет -27350.46 байт за один проход. И таким образом можно сжимать ранее сжатые данные и дальше.

image

MD5: 2b38fa5d2d6a9fd5c7cb11ae75ac05f0
SHA256: 62773affb5aa1739fd66bd5061469eaf82dc728df454ac823626b811bfca45c3
Вот демо-версия программы (гарантированно работает с файлами до 60 Мб)

Порядок обратного восстановления данных:


image

1. Разжимаем энтропийным декодером сжатые данные по пункту 6 порядка сжатия.

2. Далее, поблочно, например, с длиной блока m=2560 байт восстанавливаем исходные данные в следующем порядке:

3. Поскольку данные о расположение старых и новых с255 по пункту 5 порядка сжатия мы не сохранили, производим последовательный перебор всех комбинаций с255 (старые-новые). Среднее количество с255 при m=2560 примерно равно 20. Количество всех комбинаций старые-новые с255 равно 2^20=1048576.

4. При вышеуказанном переборе комбинаций, для каждой комбинации удаляем из блока предположительно старые с255 и производим операцию обратную произведённой по пункту 4 порядка сжатия (в обратном порядке выполняем вычитание по модулю 256 для восстановления исходных данных).

5. В случае нахождения верной комбинации все с255 исчезают, поскольку мы восстанавливаем данные в их первоначальном виде как они были по пункту 3 порядка сжатия и представляли собой 255-ричный алфавит (среди них отсутствовал с255).

6. Перебор комбинаций в текущем блоке прекращаем и продолжаем операции восстановления данных по пунктам 4-5 с остальными блоками данных пока не будут восстановлены все исходные данные.

Таким образом, кодер сжимает вообще несжимаемые данные достаточно быстро, а восстановление происходит достаточно медленно из-за операций перебора комбинаций вот такого своеобразного хеша, который позволяет нам найти верную комбинацию и восстановить исходные данные.

Подсчитаем время на восстановление данных всех блоков путем переборов вышеуказанных комбинаций:
При 1048576 комбинациях указанного блока, если осуществлять перебор при помощи достаточно мощной видеокарты (ATI Radeon HD 5870 Eyefinity или AMD Radeon HD 7970 (x3)) со скоростью 2000 MH/S то получаем среднее время полного перебора всех комбинаций блока длиной m=2560 0.000524288 с. Для вышеуказанного примера суммарное общее время составит 20.48 с для одного прохода.

Таким образом, например можно многократно циклические сжимать файлы видео с мобильных устройств, уличных камер для пересылки их при помощи мобильного интернета в облака. А уже в дата центрах эти многократно сжатые файлы могут быть при необходимости восстановлены на мощных серверах, в том числе с использованием соответствующих ASIC.

комментарии (12)

–3
sim-dev ,   * (был изменён)
Помнится в детстве я читал небольшой фантастический рассказик, где инопланетянин утверждал, что сможет увезти к себе на планету знания человечества целиком и без потерь, и вся информация будет сождержаться в единственной риске на сапфировом стержне длиной в 1 метр…
— Как это возможно, ведь это миллиарды страниц, миллионы фото-фидеопленок?!
— Я закодирую все данные в числа… потом запишу все эти числа в виде непрерывной, но конечной цепочки и допишу в начале 0, — в итоге получится десятичная дробь… пусть число знаков после запятой будет исчисляться миллиардами знаков — технологии моей планеты это с легкостью смогу обработать. Затем эту десятичную дробь я переведу в простую и подберу известными методами (технологии моей планеты позволяют) числитель и знаменатель, с нужной мне точностью представляющие исходную десятичную дробь. Затем я беру сапфировый стержень в 1 метр длиной и наношу на нем единственную риску так, что части стержня будут соотноситься ровно в той пропорции простой дроби, о которой говорил ранее. И этот стержень с единственной риской я увезу к себе на планету…

К чему это я? Интересный метод, требующий очень много вычислений на этапе сжатия, но дающий коэффициенты сжатия, близкие к бесконечности (в теории). Сущность этого фантастического метода можно обобщить так: поиск математического выражения, описывающего заданный числовой ряд в виде (бес)конечной дроби. Согласитесь, одним-единственным знаком «пи» мы кодируем бесконечное количество информации… разве это не здорово?! Никакой 7Zip с такой степенью сжатия не сравнится.
+3
+4 –1
napa3um ,   * (был изменён)
Это арифметическое кодирование (интервальное кодирование), и «бесконечность сжатия» тут, конечно, ненастоящая (в вашем примере не сжатие информации, а способ физического кодирования, ограниченного в пределе неопределённостью Гейзенберга).
+1
zeronice ,  

Может так оказаться, что для описания этого огромного числа нужны два числа сравнимой длины, так что Шеннон таки окажется прав;-)

+5
napa3um ,  
Архиватор Бабушкина.
0
ibessonov ,  
Поскольку данные о расположение старых и новых с255 по пункту 5 порядка сжатия мы не сохранили, производим последовательный перебор всех комбинаций с255 (старые-новые)

В случае нахождения верной комбинации все с255 исчезают, поскольку мы восстанавливаем данные в их первоначальном виде

И как вы собрались определять, что комбинация верная?

+1
+2 –1
OldFisher ,  
Предлагаю несложный эксперимент. Сжимаем по этому алгоритму все возможные файлы длиной 4 байта настолько, насколько возможно. Их 2^32, около 4 миллиардов, общий объём исходной информации 16 гигабайт. Распаковываем каждый сжатый файл и сравниваем результат с оригиналом. Подсчитываем общий объём сжатых файлов. Делимся статистикой.
0
+1 –1
OldFisher ,  
Если результаты этой стадии придутся по нраву, переходим ко второй: берём файл побольше, разбиваем на группы по 4 байта, сжимаем в новый файл. Сравниваем объём. Распаковываем сжатый файл, сравниваем с оригиналом. Делимся результатами.
0
vin2809 ,   * (был изменён)
1,
Кстати на тех же страницах этой книги (она доступна в сети)
Она еще доступна в книжных магазинах.
2.
Поэтому, осуществлять повторное, а тем более многократное циклическое сжатие уже эффективно сжатых данных существующими сейчас способами кодирование невозможно.
Может быть все же нецелесообразно.
0
NYMEZIDE ,   * (был изменён)
Кто-нибудь, выложите статистику сжатия файлов (разных типов) до 60 мб в виде таблицы, в сравнении с Zip, 7z, Rar методами и вышеупомянутым супер бесконечным архиватором.
Чувствую автор занимается подгонкой чисел под удобные ему значения.

Фактически там вычисляется хеш, который затем нужно методом перебора восстановить? Где-то это я уже видел.
+5
alexxisr ,  
предположим, что мы научились сжимать любые n бит в n-1, тогда получим:
кол-во возможных последовательностей из n бит — 2^n,
а кол-во возможных последовательностей из n-1 Бит — 2^(n-1) (в 2 раза меньше).
соответвенно существуют разные исходные данные, которые будут сжиматься в одинаковые архивы — как их различать?
а придумать как сильно сжать только некоторые последовательности не проблема — можно просто пронумеровать файлы и потом по номеру читать из словаря.
+4
Cryvage ,  
Строго говоря, ваш способ не является способом сжатия без потерь. Ведь есть вероятность коллизии. В частности, в пункте 4 алгоритма восстановления данных, вы можете получить комбинацию, которая выглядит как верная (все c255 исчезли), но при этом верной она являться не будет. То что вы предлагаете это примерно как сохранить sha256 и исходный размер файла, и считать это архивом. А для «извлечения» из такого архива надо перебрать все комбинации байт заданной длины, равной размеру исходного файла, вычислить sha256 на каждом шаге, и сравнить с sha256 исходного файла. Сравнение, конечно, утрированное, но суть передаёт.
0
Temmokan ,   * (был изменён)
Чувствую, не зря программа дана без исходников.

В пункте 5 есть одна маленькая загвоздка: отсутствие доказательства, что существует один и только один вариант «восстановленных» данных. Помимо чисто статистического опровержения возможности безусловного сжатия произвольной последовательности байт.

Напоминает мне старинную шутку, что, поскольку в десятичной записи числа π есть любая наперёд заданная последовательность байт, то достаточно кодировать любые данные двумя параметрами: где она начинается в десятичной записи π, и какой она длины.

(то, что дистанция до начала нужной последовательности может быть слишком большой, мы скромно умолчим).