Стоит задача сжать картинку 2048x1024x8bit (оттенки серого) и передать ее. Соответствие стандартам не требуется, т.к. на приемном конце стоит наша же аппаратура, разжимающая обратно в bmp, все упирается в быстродействие и степень сжатия.
Решил делать нечто jpeg'ообразное - DCT, RLE и Хаффман. Далее пошли вопросы:
1) Может я что-то упускаю и есть способы быстрее/лучше/проще для решения задачи? В частности, слышал, что вместо Хаффмана можно использовать алгоритм арифметик (я его, правда, не знаю ). На сколько это будет сложнее/дольше/лучше?
2) Как наиболее быстро сделать DCT? В частности, слышал про какой-то метод AA&N, который вроде хороший, но гугл мне тут не сильно помог. И сопутствующий вопрос: как уж говорил, входная картинка - 8 бит на пиксель. А что с результатом DCT - какой там диапазон выходных значений?
3) Как на плисине попроще и побыстрее сделать алгоритм Хаффмана? Может, отправите к примерам выполнения?

смотрите :
http://www.opencores.org/projects.cgi/web/jpeg/overview
http://www.opencores.org/projects.cgi/web/...ystems/overview

Спасибо. Первый я уже знаю, а вот второй не видел еще. Вот только первый достаточно медленный, а у второго указания на скорость не нашел. Просто исходникам уже 5 лет, с тех пор ничего нового не сделано в этой области?

Вот еще: JPEG compression core

Так там же корка платная. Или вы предлагаете документацию посмотреть?

быстро - медленно, это относительно, какую скорость Вы хотите достичь?

2048x1024x8 бит пожать в примерно jpeg по трудозатратам на циклоне 2 на 35 тысяч speed grade -7 желательно меньше 0.5 секунды.

video_compression_systems на опенкорах справляется и умещается
в spartan3s400, надо только сравнить с циклоном

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

Можно попробовать сжатие с вейвлет-преобразованием -
должно получиться сильнее и красивее, чем с DCT.
Это как JPEG2000.
Но, к сожалению, для него нужен буфер побольше,
который в ПЛИС может и не влезть.
Насчет пропускной способности - это смотря как плотно сжимать.
Если не более чем в 5 раз, то через вейвлеты фильтровать можно только по строкам
- то и совсем без буфера получится.

Спасибо, буду смотреть и разбираться.


Какого канала? Передачи информации? Толком не знаю, этой частью проекта не я занимаюсь. Требования по времени обусловлены требованием к готовности приема следующего кадра - пожать, записать на носитель, освободить буфер для следующего кадра. Максимальное время - 1 секунда (да и то много), запись на носитель примерно 2МБ/сек. Соответственно, если 2МБ картинки пожмется в 200-500 кил за 0.5 секунды, то я в требования укладываюсь.
А передача с носителя по каналу происходит в другой момент времени.

Знаете, 200 и 500 килобайт - это не одно и то же. 200К - это в 10 раз, и это точно JPEG или wavelet. 500K - это вчетверо, и от типа картинки можно попробовать lossless.

Такую задачу можно и на микропроцессоре решить.
Взять, к примеру, фотоаппарат.http://electronix.ru/forum/style_images/russian_butt/folder_post_icons/icon6.gif

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

Речь, конечно, скорее о 200, про 500 я погорячился.

Блин, совсем задолбался. Помогите, плиз, найти исходник программы на C, берущий bmp (или просто массив пикселей) и делающей jpg файл. Мне он нужен для примера, плюс поиграться с коэффициентами квантования для тестовых картинок. Но нигде в инете исходников проги найти не могу - все либо обрывочные описания алгоритма, либо с использованием библиотек/классов. Заранее спасибо.