Прошу прощения у модератора за повтор темы от AVR.
Проектируем плату для обработки и передачу чб фото с видеокамеры.
Входная часть от ПАЛ на АЦП и плисине сделана, надо медленно передать фото очень далеко
по медленному радиоканалу. Хотелось бы это все сжать. Какие решения на этот счет есть?
Почему?: не хотим поиметь гемр из-за вероятности ошибки и большой времени передачи,
а рядом еще идет и телеметрия.

LPC не очень то, плисины те что пошустрее очень.

Плисина занимается только оцифровкой видео в любой момент времени,
и записью быстро в озу. А стоит еще море задач и мешать ей нельзя

Дык фото или видео?

Если у AVR хватает силёнок сжать фото кадр, то любой кортекс в 10 раз быстрее может.

Раз в ~5 мин сформировать сжатое фото в чб пале. Вот и спрашиваю про алгоритм и время его выполнения

Опять забавно чб пал, нет там пала. Просто видео сигнал. Пал - это цвет, с поднесущими в спектре видео и тд итп.
Если ч/б это просто видео. Сжать без потери качества трудно, но можно. все зависит от требований к мелким деталям. Выбор алгоритма тоже.
Ставьте еще плисину, дешевле и быстрее. LPC под компрессию видео не заточены, ни ARM-7, ARM-9, Cortex-ы просто медленны и бесполезны для сжатия видео.
Либо видео процы с DSP либо плисина.

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

а весело читающий blackfin что про блекфин чего говорит?
любая ифо нужна.

Да всё просто - сроки убийственные... LPC знаю, кортекс нет. На это дело, хоть и хоршее, времени нет.
А всё наладить, развести и запрограммировать, увести и поставить ... Мне уже до этой скорости. Просто спрашиваю
в этих рамках - реализуемо аль нет. Да вот и всё. Собственно разговор был просто о сжатии файла, а потом его разжать...

С задачей сжатия одного ч/б кадра 720*576 за 5 мин. справится любой МК, и даже AVR.
Кроме того, на форуме работает функция поиска: JPEG.
И, наконец, сайт ADI дает глубокий повод для раздумий: JPEG Encoder.

Вопрос: объясните бестолковому - сжать, передать без абсолютного потери качества!!!
и потом восстановить - это подойдет?

Да вся проблема не голых баб наблюдать, а снежные лавины у ЖД РФ, вот и советуюсь...

Огласите плс. числа - скорость канала, сколько раз в час нужно кадры передавать, качество оцифровки видео. А то как-то трудно без этого советы давать

Жмите кадр в джипег, передавайте. В чем проблема то? Кортекс прекрасно справится, только внешней памяти надо побольше.

Утомился. Есть подход сжать и весело посмотреть. А есть подход реально детально рассмотреть.
Это разные вещи: делитанские или любительские.
Поэтому промышленное оборудование - одна цена а... другая
JPEG можно без потери качества восстановить в первоиссточник???
Блин вопрос был про алгоритм типа зип и унзип и на си

Какой Кортекс?

Да, может. При правильных настройках.


Алгоритмы типа зип не дадут существенного сжатия картинки с камеры.

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

1 кадр видео с качеством 8бит 15МГц передается на скорости 115200 бит/сек прибл. 41 секунду (если я не ошибся в расчетах). С полным качеством и безо всякого сжатия за 5 минут. Вопрос - зачем себе городить проблемы со сжатием и распаковкой JPEG на AVR или еще на чем, если для этого нужно время >41 сек.+ время на передачу этого сжатого кадра? Просто пишите кадр в буфер и передавайте себе спокойно. Быстрее передать на меньшей скорости, чем кодировать и раскодировать видео на микроконтроллерах. И к тому же еще и дешевле будет. И еще не понятно, каким образом это видео в цифру кодируется - простым АЦП, или как?

Меняйте АРМ- STM32F2xx (именно F2) имеет параллельный интерфейс видео входа- до 14 бит 30 Мгц. Можно сразу видео АЦП цеплять. DMA разложит кадр в память, а дальше-программно. ОЗУ только маловато для работы с кадром- прийдется экономить или поджимать на-ходу по строчкам.

А кто будет заниматься синхронизацией, уовнями белого черного итд.?
Вы сами хоть делали такое, перед тем как советовать.
Вот вот озу мало, поджимать, то есть о сжатии потока можно забыть.
MPEG для чего то придумали, ну и как его на F2 сделать?

Вообще то видео-ацп обычно имеет схемы синхронизации внутри. И уровни белого-черного тоже он привязывает. Именно на STM32F2xx- нет, не делал. Семплы только недавно приехали, юзерманул только появился, а аппликух по DCMI (Digital Camera Interface) тоже еще нет. Пока макетную плату разводим на свой страх и риск. Чтобы MPEG жать надо внешнюю память ставить. Для этого у STM32F2xx есть FSMC - прийдется внешнюю SRAM цеплять. Для наших задач оно ненадо, поэтому не разводим.

Да нет STM32F2xx никакого MPEG или H264, непотянет, нет в них видео ацп, медленный проц, архитектура проца вообще для работы с обработкой видео потока не годиться.
Какая там еще внешняя память, если проц не тот. Если не хочется делать то можно и готовый чип купить.

Можно сжать раз в 5 и на глаз не отличить от оригинала. На кортексе.
Только как уже все задавали вопрос - зачем сжимать, если со скоростью 19200 бод можно свободно передавать картинку 768*576 ч/б в несжатом виде.

Но это же долго. При большом расстоянии, как указывалось, большая вероятность потери данных. Передавать желательно за короткое время.
Сжимать раз 20...100 желательно. Это позволяет и MPEG и H264 и ряд других алгоритмом. В 5 раз не очень интересно. Потери части информации не избежать.
Просто нужно оговорить, какие потери информации приемлемы. Обычно это мелкие детали на ч/б изображении.

Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр.

Это не верно. Вы просто не знаете как это упаковывается, распаковывается. Вообщето если это чб картинка, то лучше подходит формат GIF или TIFF или RAW.
В JPEG при потери пары байт вы получите несколько 8x8 квадратиков с неправильными пикселями по ярости.
И то это маловероятно в канале передаче, где есть коды исправляющие ошибки.

для черно-белой картинки хорошо должна подойти простенькая RLE компрессия.
http://en.wikipedia.org/wiki/Run-length_encoding

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


Опять-таки -- только если это графика без полутонов. На любой нормальной фотографии JPEG будет работать существенно лучше. Он был сделан именно для компресссии фоток, в отличии от гифа, который вообще не в курсе, что сжимаемый поток байтов -- картинка.

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

ar__systems чёт не то пишет.
GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью. GIF хорош тем, что можно потерять более половины картинки (кадра), но распознавание сюжета остается высокое, в отличии от JPEGа.
... сжимаемый поток..., вообще не отсюда. Причем сдесь это, если говорим о стандартах сжатия.
LPC и обработка видео как то не стыкуются все же. Не для этого LPC_шки разрабатывали.

Какие потери байт? О чем вы?
Передача данных разве не подразумевает протокол?
Пакеты, кадры, CRC. итд итп.

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

Вы, извините, что-то где-то слышали, но понятия не имеете, о чем говорите. Да, гиф 8 бит, JPEG 24. Ну и что? Вы для начала тупо возьмите и поэксперементируйте, как сжимает Гиф и JPEG. Например, следующая картинка:



После того как я ее в черно-белую переделал и сконвертил в GIF, JPEG -- 17KB, GIF -- 150KB. И меньше гиф уже никак не станет, а JPEG eще может жать и жать, при 17КB никаких артефактов еще нет.

А после экспериментов почитайте как они оба сжимают, чтобы не писать в следующий раз нелепицу.


+1.

Удивительно - что только не советуют кроме того что было специально разработано для таких целей
http://en.wikipedia.org/wiki/Portable_Network_Graphics

Ага.. По Вашей же ссылке:

А Вы отмотайте тему на пару страниц - речь идет о ч/б изображении - на них jpeg вообще теряет все свои преимущества в компрессии.

Все же я не прав похоже, нашел сравнение как раз по теме в гугле
Lossless Compression of Grayscale Medical Images - Effectiveness of Traditional and State of the Art Approaches

там jpeg нахваливают

Вы сами придумали эту чушь?

GIF - алгоритм сжатия без потерь (качества).
JPEG - алгоритм сжатия с потерями. В нём применяется дискретное косинусное преобразование (DCT). Из всех преобразований оно имеет наиболее быстро спадающие коэффициенты, поэтому обеспечивает наибольшее сжатие среди алгоритмов, разбивающих изображение на квадраты 8х8 точек.

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

Сходите-ка в FAQ
http://www.faqs.org/faqs/jpeg-faq/part1/