Сжатие - Бит

Я хочу сжать файл, который выглядит как BITMAP INDEX. (Файл в двоичном формате только с «0» и «1»).

При использовании байта для представления «0» или «1» сжатие имеет хороший коэффициент из-за низкой случайности.

Вместо того, чтобы использовать байт для представления «0» или «1», я хотел бы использовать бит. Пример: число 8 = 00001000 число 10 = 00001010

Таким образом, несжатый файл будет в 8 раз меньше, чем файл с битовым индексом, использующим байт для представления 0 и 1.

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

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


compression algorithm byte bit
person p.magalhaes    schedule 25.05.2011    source источник
comment
В конечном итоге каждый файл представлен только с помощью 0 и 1. Чем отличается растровый индекс?   -  person Matt Ball    schedule 25.05.2011
comment
Смущенный. Не могли бы вы привести короткий пример с несжатым вводом и сжатым выводом, который производит ваш алгоритм?   -  person Hyperboreus    schedule 25.05.2011
comment
Я не могу сказать, плохо ли вы понимаете кодировку файлов или просто не можете четко объяснить свою проблему, но в любом случае, пожалуйста, отредактируйте свой вопрос, чтобы уточнить. Единственный способ, которым вы могли бы ожидать 8-кратную степень сжатия, - это если бы у вас когда-либо было только 2 уникальных байта, которые появлялись в файле, например. если вы использовали 8 бит для представления одного из двух вариантов. Я не понимаю из вашего вопроса, как вы противопоставляете байты и биты.   -  person Mu Mind    schedule 25.05.2011
comment
Вальдхайнц понял мой вопрос. Спасибо!   -  person p.magalhaes    schedule 25.05.2011
comment
На самом деле мне было интересно, смотрят ли алгоритмы сжатия на биты или байты, и ответ хороший.   -  person netrox    schedule 08.07.2018

Ответы (2)


arrow_upward
4
arrow_downward

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

Любой разумный алгоритм сжатия на основе энтропии будет работать на уровне «битов» и, таким образом, будет демонстрировать ожидаемое поведение. При передаче ему ввода, состоящего только из байтов «00000001» и «00000000», кодировщик в каком-то смысле «видит», что ввод состоит из чертовски большого количества «0» битов, зажженных несколькими «1» — это будет адаптироваться к этой ситуации и достичь хороших коэффициентов сжатия, используя таблицы (или что-то еще, что компрессор использует для представления своего состояния) для обработки этого случая.

Если вы действительно используете все биты в байте, энтропия («случайность») ввода намного выше, поэтому, хотя у вас есть ввод, размер которого составляет всего 1/8, вы также значительно усложняете работу компрессора. тяжелее, и от этого пострадает его степень сжатия. В любом случае, я абсолютно уверен, что это правильный путь, поскольку вы не полагаетесь на компрессор, который может или не может хорошо улавливать «схему множества нулей», которую вы имеете во входных данных.

Или какие-нибудь трюки, которые я могу использовать, чтобы снизить случайность данных?

Эти «уловки» включают в себя выполнение преобразований ваших входных данных, чтобы уменьшить энтропию входных данных. То, что вы можете сделать здесь, действительно зависит от характера ваших входных данных. Если это действительно черно-белые «изображения», вы можете взглянуть на JBIG или проверить из преобразований, определенных в стандарте изображения PNG.

person Waldheinz    schedule 25.05.2011

arrow_upward
1
arrow_downward

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

Коэффициент сжатия здесь является отвлекающим маневром. Вместо этого вам следует сравнивать размеры сжатых файлов.

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

В несжатом виде файл битов как байтов будет в 8 раз больше. Однако он хорошо сжимается — теоретически до 1/8 своего размера — но не лучше, чем несжатая версия с упакованными битами.

(Я предположил, что вы пишете здесь 8-битные байты. Если вы пишете 32-битные целые числа, замените 8 на 32 выше.)

person Jonathan Lidbeck    schedule 27.08.2014