Библиотека кодирования изображений

Question

Есть ли хорошая библиотека для кодирования/декодирования без потерь, которая имеет степень сжатия, более или менее похожую на PNG, но декодирование на необработанные растровые данные RGB будет намного быстрее, чем PNG?

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

Оригинальная проблема заключается в медленности чтения и декодирования PNG-файлов на iPhone с использованием стандартных библиотек. Очевидным и простым решением было бы хранение необработанных RGB-данных растровых изображений, но тогда размер распакованного ipa слишком велик - в 4 раза больше, чем PNG-файлы. Итак, я пытаюсь найти компромиссное решение.

Answer 1

До тех пор, пока вам не нужно сжать на iPhone, декодирование Lempel-Ziv довольно быстро. Однако, если вы получите хорошее сжатие, другой вопрос. Ваш первый шаг должен состоять в том, чтобы сбросить изображение в формате raw ppm и сжать его gzip. Я пробовал это на нескольких снимках экрана SO, и поскольку количество цветов относительно невелико, результирующие файлы примерно того же размера, что и PNG (немного меньше). Тест

pngtopnm so.png | gzip -v9 | wc -c 

Если этот тест производит что-то достаточно мало для вашего приложения, вы хорошо идти — только запустить GZIP на необработанных растровых изображениях и использовать крошечный факт libz декодера в вашем iPhone приложении. Если это не так быстро, вы можете попробовать еще быстрее декодеры на основе Lempel-Ziv.

Если у ваших изображений много цветов, и это не сработает, вам может потребоваться некоторая форма сжатия с потерями.

Answer 2

Почему бы просто не использовать исходные необработанные данные RGB (A) и сжать и распаковать его с помощью zip, RLE, huffman и т. Д.?

Answer 3

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

Сжатие PNG использует методы энтропийного кодирования под обложками, поэтому повторное внедрение этого, по вашему мнению, вряд ли поможет.

Вы можете использовать какое-то программное решение, которое «скрывает» медленность от пользователя путем ленивой загрузки изображений в отдельный поток.

Answer 4

PNG-сжатие - это основное предсказание (соседние пиксели), за которым следует сжатие Zip. Если вам действительно нужно сжатие без потерь с низкими требованиями к памяти и процессору, эту стратегию трудно превзойти ... амунизируя, что у вас есть достойная библиотека создания PNG. Узким местом кодирования является сжатие zip. (И, как заметил другой, учтите, что декодирование происходит намного быстрее, чем кодирование). Чтобы просто закрепить необработанное изображение, будет только немного быстрее, и (за исключением очень конкретных изображений) значительно снижают эффективность сжатия.

Answer 5

Ваши лучшие быстрые и грязные результаты исходят от использования 7zip SDK для декодирования необработанных данных изображения, которые были отформатированы как ABGR (малое число). Затем вы можете пролистывать данные этого изображения на экран с помощью API UIKit. Если вы хотите взглянуть на пример кода iOS, выполните поиск Google на «AVAnimator iOS», и вы найдете библиотеку с открытым исходным кодом, которая реализует этот подход. Главное, что вам нужно сделать, - убедиться, что каждый пиксель графических данных уже отформатирован оптимальным образом для iOS, это в основном то, что делает xcode, когда он готовит PNG-файлы для использования в проекте iOS.