сжатие изображения без потерь

Question

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

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

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

Update: моя платформа является FPGA

Answer 1

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

..OOO ...
..OX

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

OO ... B < - Конец строки
X < - начало следующей строки

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

Answer 5

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

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

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

Answer 6

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