Сжатие данных из песочницы

Этим вопросом начал интересоваться достаточно давно. Идея экономия памяти, места на дисках витала давно и наверно у всех. Первая попытка написать свой алгоритм сжатия схожий на алгоритм RLE была в 2000 году, затем было еще несколько оригинальных концепций сжатия, но дальше предварительных тестов дело не пошло. В 2005 году взялся за идею сжатия всерьёз. Спустя 6 лет делюсь некоторыми выдержками из исследований.

Чтобы понять и осмыслить данную статью введем некоторую терминологию:
  • N — Натуральное число
  • Слово — N Bit то есть N бит с группировано в слово (байт это 8 битное слово)
  • Комбинаций в слове — 2^N (два в степени N) (в байте 256 комбинаций)
  • Блок (предложение) — N*2^N (Слово*Комбинаций слов)
  • Комбинаций в блоке — 2^(N*2^N)
  • Уникальных слов в блоке — 2^N
  • Таблица распределений блоков — N строк (в строке количество комбинаций блоков с N уникальным словом)
  • Таблица вхождений — N строк (в строке количество вхождений блоков с N уникальным словом)
  • Входящий поток — конечное количество байт в фрагменте информации

Определение уникальных слов в блоке — количество не повторяющихся комбинаций слов в блоке. Пример:
1 1 1 1 1 1 1 1 одно уникальное слово
8 8 8 8 8 8 8 8 одно уникальное слово
1 8 2 5 1 5 1 2 четыре уникальных слова
4 6 7 3 3 3 3 3 четыре уникальных слова

Нахождение уникальных слов в блоке при N=3

Перебрав все комбинации в блоке получаем таблицу распределений блоков. Пример:
1 4
2 84
3 144
4 24

Сумма 256 (8 бит) Комбинаций в блоке - 2^(N*2^N)

Таблица распределений блоков N=2

01 16
02 7864080
03 23996064960
04 7504175995680
05 574579238688000
06 15768930151054080
07 189225474428390400
08 1111400775560275200
09 3407360398041600000
10 5630409646557696000
11 5045340384103219200
12 2403608358767616000
13 577538743541760000
14 62977597562880000
15 2510734786560000
16 20922789888000

Сумма 18446744073709551616 (64 бита) Комбинаций в блоке - 2^(N*2^N)

Таблица распределений блоков N=4

При N=4 и более таблицу распределений блоков методом перебора за несколько секунд уже не получить.

Первая часть алгоритма состоит в анализе входящего потока (создании Таблицы вхождений). Входящий поток делится на блоки, которые проверяются на количество уникальных слов. Номер уникального слова принимается за номер строки в Таблице вхождений. Значение в строке наращивается на единицу. Получив Таблицу вхождений можно увидеть некоторые свойства. Привожу пару примеров:
Different types of files
Построение графика по Таблице вхождений при N=8, файлы можно скачать здесь

Different degree of aggressiveness of the compression
Построение графика по Таблице вхождений при N=8, файлы можно скачать здесь

Different cryptographic algorithms
Построение графика по Таблице вхождений при N=8, файлы можно скачать здесь

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

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


Демонстрация спецального алгоритма

Видео создано продемострировать возможность улучшения сжатия данных на данных «без избыточности». Это специальный алгоритм создающий избыточность в исходных данных.

P.S. Первый алгоритм выполняется слишком долго, видео его работы не стал делать. Второй алгоритм показан на видео. Работает примерно на той же идеи что и BTW алгоритм, то есть сначала подготавливает данные, а потом эти данные сжимаються классическим алгоритмом.
+15
16 августа 2011, 14:28
20
Boctopr 12,9 G+

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

+3
ertaquo #
А можно просто сравнительную таблицу? Например, сжатие файла, содержащего случайные данные (dd if=/dev/random of=./datafile bs=4096 count=1024), вашим архиватором и архиваторами ZIP, RAR, 7Zip с максимальной степенью сжатия?
0
Boctopr #
Предоставьте файл.
+1
gribozavr #
0
Boctopr #
На предоставленном файле, сжатие происходит каждый мегабайт на 1 — Один бит, при файле 4 мегабайта сжатие будет 4 бита плюс словарь + 256 бит, что значит сжатия данных не происходит. при генерации файла таким же методом в 257 мегабайт будет выигрыш в 1 бит.
0
ertaquo #
Попробуйте этот файл: http://test.nizarium.com/udatafile. 8 мегабайт случайных символов (32-127). ZIP при максимальной степени сжатия выдает файл размером 6,6 мегабайт (6978032 байт).
0
Boctopr #
7826246 байт + 256 бит словарь. Чуда конечно не случилось. Хотя цель этого алгоритма другая.
Второй алгоритм (который на видео) при параметрах по умолчанию давал схожий результат (6,6 мегабайт) но при некоторой оптимизации, возможно, удастся ужать на пару байт лучше, но это займет значительно время для подбора удачной комбинации.
0
Boctopr #
Кстати если взять основание системы счисления 96 (128-32 символа) то получиться 6904834 байт что на 73198 байта лучше сжимается, тут конечно не учитываются служебные данные, но они не настолько большие.
0
maxout #
в конце видео есть вполне наглядная сравнительная таблица, посмотрели бы сначала…
0
orionll #
Все равно в статье пару-тройку диаграмм не помешало бы
0
Calvrack #
Какой смысл в тесте на случайных данных?
0
Boctopr #
В том что их можно сжать?
+1
Fil #
Вот именно. Энтропия же максимальна.
–1
Boctopr #
Ты внимательно читал статью и комментарии?
+3
LevNNN #
Плохо, что в Вашей статье нет никаких количественных данных о результатах работы алгоритмов. Взяли бы стандартный Calgary Corpus и привели бы свои результаты сжатия.
+1
Boctopr #
Уточните пожалуйста ссылки.
0
LevNNN #
0
k06a #
Иными словами вы уменьшаете значения байтов.
Перенумеровывая, только встречающиеся, так?
0
Boctopr #
Смысл верный, но не значение «байтов» (числа), а их разрядность в системе счисления.
+3
eresik #
1. А смысл в таких «практических» изысканиях, если всё уже разжёвано в теоретических исследованиях? Это же не физика, а математика. Новых открытий от таких экспериментов ждать не приходится.
2. Помнится в компьютерре (кажется) была первоапрельская заметка о новейшей разработке — алгоритме сжатия без потерь, сжимающем любые файлы в 100-200 раз :)
–1
Boctopr #
Во все возможных википедиях черным по белому сказано, что нельзя сжимать уже сжатые данные или шифрованные. Данная статья доказывает что можно (при больших файлах более гигабайта). Хочу заметить, что это достаточно новый виток в этой области и данные алгоритмы далеки от совершенства.
0
LevNNN #
Эффективнее не повторно сжимать уже сжатые данные, а сначала декодировать, а потом повторно сжать другим более эффективным алгоритмом. Это справедливо конечно только в случае сжатия без потерь
0
Boctopr #
Представим, что у вас имеется большое хранилище данных. В него поступают только архивы с паролем или шифрованные данные (это одно и то же в рассматриваемом случае). У вас нет никакой возможности перекодировать данные в исходный вариант и закодировать более удобным для вас методом. Тогда можно применить данный алгоритм.
+1
Calvrack #
Я не понимаю, вы что претендуете на построение биекции из 1..2^n в 1..K, где K < 2^n? Или это эмпиричсекий результат? Если эмпирический, то интересны исследования становится с выборок в >>500 примеров, причем с жестким контролем за источником этих примеров.
+1
Boctopr #
В корне не верно. Суть всего происходящего не в преобразовании всех чисел в меньшее значение, а взять только определенную группу.
0
Calvrack #
Вы не поняли что я спрашиваю. Если средний размер сжатой последовательности для всех положим мегабайтных последовательностей (а их 2^20) меньше мегабайта, то это эквивателнтно введению более компактной нумерации на множестве 1..2^20, что невозможно. Именно из этого простого соображения вытекает бесполезность попыток сжать случайную последовательеность.

Сжать результат ZIP или 7Z для типовых файлов может и возможно, но это надо исследовать на очень больших выборках.
0
Boctopr #
Это рассуждение для линейного алгоритма, не имеющего ветвления.
Практический пример:
0 0 0 0 0 0 0 0 у нас есть 8 байт с нулевыми значениями, сожмем эти 8 байт методом RLE
8,0 получиться 2 байта первый байт количество повторений байта, значением второго байта заполняем цепочку.

второй случай
0 1 2 3 4 5 6 7 у нас есть также 8 байт. Кодируем тем же алгоритмом.
1,0 1,1 1,2 1,3 1,4 1,5 1,6 1,7 получаем 16 байт

но что если применить другой алгоритм на тех же исходных данных
8,0,1 получиться 3 байта первый байт длина цепочки, второй байт стартовое значение, третий байт команда алгоритму инкрементировать стартовое значение при каждом шаге.

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

P.S. Это уже вольное начало другой моей статьи которая будет немного позже.
0
Calvrack #
Мое рассуждение нигде не использует факта наличия или ветвления в алгоритме сжатия. Я говорю о результате в виде битовой последовательности, а что у нее внутри — биты выбора алгоритма и потом данные, мета-код для порождения сжатой последовательности на машине Тьюринга или даже url со сжатым файлом в интернете совершенно неважно.

Но следующей статьи с интересом подожду.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.