Запрос комментариев к сжатию Хаффмана - PullRequest
1 голос
/ 18 ноября 2009

Реализация файловых компрессоров, которые я видел, всегда сжимала массивы байтов.

Но вместо этого он может сжимать массивы шорт или даже целые числа.

Если каждый символ в двоичном дереве Хаффмана представляет байт, мы можем сжать максимум 8 бит в одном бите, когда это оптимально.

Если каждый символ в дереве Хаффмана представляет собой короткое замыкание, мы можем сжать не более 16 битов в одном бите, когда это оптимально.

Это правильно?

Может ли кто-нибудь обновить Википедию с помощью этой дополнительной информации о кодировании Хаффмана?

Ответы [ 6 ]

7 голосов
/ 18 ноября 2009

Оптимальное сжатие - обрабатывать весь файл как один токен и сжимать его, используя код Хаффмана нулевой длины. Это дает вам бесконечную степень сжатия. К сожалению, описание кода Хаффмана будет довольно большим.

6 голосов
/ 18 ноября 2009

Это правильно, но это не так удивительно, как звучит.

Для декодирования потока байтов в кодировке Хаффмана необходимо передать два фрагмента данных. Требуется закодированный поток (конечно), но также и словарь, который позволит вам правильно построить дерево Хаффмана для выполнения декодирования.

Использование больших токенов для кодирования ваших данных всегда приведет к меньшему потоку кодирования. К сожалению, если у вас нет данных с некоторыми довольно специфическими и особыми характеристиками, более крупные токены также приведут к неожиданному увеличению размера словаря. Вырожденный случай (на который указывает ответ Марка Байерса) приведет к тому, что весь несжатый поток данных будет одним токеном, а закодированный поток - одним битом, что приведет к абсолютному отсутствию сжатия.

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

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

1 голос
/ 18 ноября 2009

Арабкодер, ваши предположения верны.

В качестве примечания: многие 8-битные кодеки Хаффмана не только сжимают 256 натуральных символов байта. У них также есть один или несколько специальных символов. Они используются для обнаружения конца потока Хаффмана или для переключения с одного дерева Хаффмана на другое ...

0 голосов
/ 19 ноября 2009

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

0 голосов
/ 18 ноября 2009

Хаффман довольно старый метод сжатия и не используется как таковой. Он включен в основные методы сжатия, преподаваемые в курсе. С учетом того, что многие файлы, такие как JPEG, PDF или JAR, уже сжаты, простое сжатие Хаффмана не даст вам много.

Я говорю это, потому что я сделал это. И это применимо, даже если вы много оптимизируете таблицу символов.

0 голосов
/ 18 ноября 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...