Сжатие на ATMega, Хаффман с фиксированой таблицей CCITT Group 3 Опции

[SasaVitebsk]

Я вот тоже думаю что спор и емоции ни о чем.
По поводу словаря: Суть CCIT Group 3 сжатия такова:

На основе метода Хаффмана для конкретного вида изображений(отсканированые документы с печатным текстом и глубиной цвета 1 бит) на основе обработки огромного количества таких изображений был сформирован словарь(таблица), которая есть в стандарте.
Каждая строка кодируется отдельно для начала она преобразовывается в длины серий(RLE), а после этого длины серий сжимаються по готовой таблице(словарю) методом замены.
допустим последовательность из 8 белых бит встречается чаще всего и ей отвечает - 10 и т.д. коды готовы для значений от 0 до 63 и далее кратно 64 до 2363 бит.
Действительно применимо к данному типу документов сжатие вероятно будет наилутшим.
НО вопрос был в том не делал ли кто-то подобных вещей и КАКИЕ идеи по организации данного алгоритма, конкретно по побитной записи в память значений с переменной длиной(2-13 бит)

Алгоритм (тот что я делал) могу привести. Я полностью согласен с Вами. Повторяю на глаз словарь не составишь и придётся передавать большое колличество инфы. Определённой инфы. Действительно если она однотипна, то после формирования словаря будет сжимать хорошо именно эти данные. В инете предустановленный словарь не нашёл. Написано что надо купить лицензию на метод.

Помню когда реализовывал проблем с хранением разнобитных данных не было. Поясню почему. Там всё байтами делается (тот что я реализовывал). Пример:
Идёт 50 нулей.
Слово 1 - 8 нулей
Слово 2 - Слово 1 + 8 нулей (16)
Слово 3 - Слово 2 + 8 нулей (24)
... 32
... 40
... 48
Слово 7 - Слово 6 + 2нуля и там 1хххх

Я конечно утрировано, но принцип такой. (В двух словах не объяснишь)

При реализации возникают другие проблемы.
И сжатие и расжимание связано с поиском в словаре и "обратном раскручивании спирали" (в приведённом примере при расжимании извлекаешь Слово7,6...1) В примере я подряд пустил, а на самом деле структура древовидная (50 нулей и 5 единиц, 50нулей и 10100 ... и т.д). Короче возникают проблемы поиска в словаре. Иногда применяют хотябы первое вычисление по ключу. Тогда словарь близкий к симметричному. Но в этом случае он не полностью заполнен. Короче проблемы связаны с формированием и поиском. А сам алгоритм достаточно прост. Реализовать - день работы.

Я долго экспериментировал со словарём. Добился сжатия в два раза на голом словаре. Естественно с предустановленном или на графике получается до 4-5. Смотря какие данные. Короче совсем немного до ARJ не дотягивает. Но уже на этапе экспериментов понял что на меге не потяну. Мне надо было на лету (115200). Ну и забросил это дело.

[singlskv]

В инете предустановленный словарь не нашёл. Написано что надо купить лицензию на метод.

NetPBM

Посмотрите файлы g3.h и pmbtog3.c , может быть поможет.