Сжатие изображений без потерь на лету - PullRequest
5 голосов
/ 13 апреля 2010

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

Сначала я подумал о вычислении разницы между двумя последовательными пикселями, а затем о кодировании этой разницы с помощью кода Хаффмана.К сожалению, пиксели являются беззнаковыми 16-битными величинами, поэтому разница может быть где угодно в диапазоне -65535 .. +65535, что приводит к потенциально огромным длинам кодового слова.Если в строке появятся несколько действительно длинных кодовых слов, я столкнусь с проблемами переполнения буфера.

Обновление: моя платформа - FPGA

Ответы [ 6 ]

8 голосов
/ 14 апреля 2010

PNG обеспечивает бесплатное сжатие изображений с открытым исходным кодом без потерь в стандартном формате с использованием стандартных инструментов. PNG использует zlib как часть своего сжатия. Существует также libpng. Если ваша платформа не является очень необычной, нетрудно перенести этот код на нее.

3 голосов
/ 14 апреля 2010

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

3 голосов
/ 13 апреля 2010

Сколько ресурсов у вас есть на встроенной платформе?

Не могли бы вы портировать zlib и выполнить сжатие gzip? Даже при ограниченных ресурсах вы сможете портировать что-то вроде LZ77 или LZ88 .

2 голосов
/ 16 апреля 2010

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

Имейте в виду, что если у вас есть все предыдущие пиксели, у вас есть более релевантная информация, чем только предыдущий пиксель. То есть, если вы пытаетесь предсказать значение X, вы должны использовать O пикселей:

.. ООО ... * * 1005 ..OX

Кроме того, вы не хотите использовать предыдущий пиксель B в потоке для прогнозирования X в следующей ситуации:

OO ... B <- Конец строки <br> X <- начало следующего ряда </p>

Вместо этого вы бы сделали свою базу прогнозов на основе ОС.

1 голос
/ 20 апреля 2010

Хороший гибрид LZ77 / RLE с колокольчиками и свистками может получить прекрасное сжатие, которое довольно быстро распаковать. Они также будут больше, хуже компрессоров для небольших файлов из-за отсутствия библиотечных накладных расходов. Для хорошего, но GPLd это проверить, PUCrunch

1 голос
/ 16 апреля 2010

Насколько «без потерь» вам нужно?
Если это настоящий сканер, существует ограничение полосы пропускания / разрешения, поэтому, даже если он может отправлять значения +/- 64 КБ, для соседних пикселей может быть нефизично иметь разницу, превышающую, скажем, 8 бит.

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

Это размазывает пики, но может случиться так, что любые пики больше, чем 'N' биты, в любом случае являются шумом.

...