2016-05-11 2 views
0

В настоящее время я пытаюсь сжать очень простое изображение. Изображение использует 2 набора цветов, а также 1 символ на «пиксель». каждый набор цветов может быть 1 из 16 вариантов. Из-за этого я уже объединил оба цвета в 1 байт на пиксель, представляющий их оба. Я уже реализовал методы кодирования MTF и BWT, чтобы помочь в RLE. Я уверен, что могу получить еще больше компрессии, но я не уверен, какой алгоритм использовать. Я пробовал huffman, однако из-за того, что изображение имеет тенденцию быть маленьким уже, и RLE сжимает большую часть из-за отсутствия энтропии, хаффман в два раза увеличивает размер, добавляя свою таблицу декодирования в файл. Обратите внимание, что это также будет работать на более медленной системе, поэтому любые действительно тяжелые алгоритмы могут не работать.Хороший алгоритм сжатия для изображения с низкой энтропией

+0

Использует ли пользовательский алгоритм сжатия вариант? Это похоже на конкретную проблему с конкретным случаем. – apokryfos

+0

Это может быть вариант Да, но у меня нет опыта в этом, чтобы на самом деле создать специальный алгоритм для этого. – HDeffo

+0

Я не понимаю, что «использует 2 набора цветов» - вы имеете в виду, что каждый пиксель имеет 2 цвета, каждый из которых является 1 из 16 возможностей? Или каждый пиксель имеет один цвет, который находится либо из набора # 1, либо из набора # 2 (так что всего 32 возможности)? Если последнее, вам нужно всего 5 бит вместо полного байта. –

ответ

1

Во-первых, похоже, что вы должны сжимать фоновое изображение и цветные изображения персонажей отдельно. Во-вторых, вы говорите, что «цвета не меняются слишком часто с пикселя на пиксель». Некоторые цвета «ближе» друг к другу, чем другие? I.e., когда цвет изменяется от цвета x, более вероятно, что он изменится на небольшое подмножество оставшихся цветов? Если это так, вы можете сопоставить цвета, чтобы они были более смежными с теми, с которыми они могут измениться, и с учетом различий перед кодированием. Затем пробеги одного цвета становятся прогонами нулей, а изменения в «следующем» цвете становятся единичными.

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

+0

Не могли бы вы объяснить свои аргументы в пользу сжатия обоих цветов отдельно? Насколько я могу судить об их объединении, обещает, по крайней мере, 50% степень сжатия перед попыткой любых основных алгоритмов. – HDeffo

+0

Я не видел изображения, но из описания «фон» и «символ» они звучат некоррелированно. Если они некоррелированы, то сжатие будет более эффективным, чем смешанное. Что касается упаковки в байты, для чего предназначен zlib. Последовательность байтов, содержащих только значения 0..15, будет сжиматься примерно до четырех бит на каждый байт по zlib. –

+0

его не то, что они некоррелированы. «character» накладывает «фон» на каждый пиксель. так как каждый может быть 1 из 16 символов. так как максимум, что будет 15 или 1111 в битах, тогда вместе они могут быть не более 11111111 или один байт. Так как эти оба имеют тенденцию к изменению вместе, их объединение немного снижает мой текущий метод RLE. как и для zlib, к сожалению, я делаю это на платформе без современных методов сжатия, поэтому мне нужно либо реализовать, либо реализовать все самостоятельно. – HDeffo

Смежные вопросы