Используем флешку для хранения картинок. Картинки - битмапки в 16 битном формате. Очень расточительно хранить несжатыми во флешке. Хотелось бы расжимать и класть в SDRAM (благо ее полно) на этапе инициализации.

Если кто подобное делал - посоветуйте, пожалуйста, быстренький простенький алгоритм без потери качества для реализации на АРМе.

Спасибо.

Как говорится, выберите любые два пункта...

Ну вот я и выбрал . Про степень сжатия молчу...

Тогда реализуйте RLE - пишется за пару часов, работает быстро.
Впрочем, на распаковке LZ тоже имеет хорошую скорость.

Нажмите для просмотра прикрепленного файлаиспользую lzw , даже на avr . вот пакет с всем необходимым.

И еще три варианта LZ (SS, Хаффман и арифметическое сжатие). Нажмите для просмотра прикрепленного файла

А как с этим работать? fseek(...), fwrite(...), getc(infile)... Файловой системы нету, есть просто массив данных в памяти. Много переписывать в ваших исходниках. Или можно сделать проще? Компилятор использую IAR.

Наверное, "творчески переработать". Неужели стандартные функции ввода-вывода вызывают такие проблемы? Много переписывать это не аргумент - и так все на блюдечке.

Прогнал через компрессор BMP 256х256, было 64К стало 74.
После декомпрессии файл отличается от исходного и не видится Paint-ом.
И кому нужны такие исходники.

Точно... А еще поработать в хорошем графическом редакторе над сокрашением количества цветов в палитре... Тогда можно и не 16 бит пользовать, а, скажем 8...

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

Для графики годится - LZW используется в GIF'ах, для фотографий - увы, нет.

Сначала скажите, какого рода картинки предполагается сжимать. Потом, возможно, придётся решить, можно ли сжимать с потерями.

кстати, в μC/GUI есть поддержка jpg.
Ищется в гугле по ключевым словам "uC-GUI" "uCGUI" "uC/GUI" "μC/GUI"

Картинки должны хорошо сжиматься без всяких потерь. Там черный фон, на котором красиво, с полутонами и анимацией (последовательность битмапок) написаны сообщения об ошибках и т.п. Т.е. 80% - это два цвета. Я попробовал сжать rar-ом с самой маленькой степенью сжатия. Сжалось в 15 раз.

Если битмапы одинаковых размеров, и, как было указано, имеют на 80% два цвета.

на PC:
-объединить их в один массив
-пройтись по нему статическим алгоритмом Хаффмена
-получаем словарь и сжатый массив

на МК:
- по словарю и сжатому массиву восстанавливаем исходный массив в память
- по известным параметрам битмапов вычленяем их из массива по необходимости

Ссылка на исходники и прочее: http://webcenter.ru/~xander/

Или в архиве.

Тогда адаптированный Хафман.
ОднознАчно (с)

А можно и пару раз Хафманом пройти...
Тестовый рисунок ужался с 400к до 59к, потом 59к до 19к.
Итого в два прохода - 20 раз. И без RAR.

Для рисунков - самое оно...

P.S. Сорри, RAR до 3к ужал...

Попробовал зажать экзешником, что лежит в архиве. Сжало чуть-чуть получше, чем в 2 раза. Не совсем приемлимо - zip жмет в 13 раз. Смотрю в сторону гнушных gzip'а и bzip2.

Братта, смотри мой мессадж выше.
Можно пару раз пройтись. Универсальный не нужен ведь?
Попробуй с готовым exe на своей картинке.
Здесь довольно узкая задача.
Не спорю, что на ПиСи есть и получше архиваторы.
Они таки используют много методов.
Но на ЭмСи есть проблема - эффективность архиватора/размер кода архиватора.