|
LPC для обработки видео |
|
|
|
Mar 30 2011, 12:55
|
Участник

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586

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

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586

|
Плисина занимается только оцифровкой видео в любой момент времени, и записью быстро в озу. А стоит еще море задач и мешать ей нельзя
|
|
|
|
|
Mar 30 2011, 13:42
|
Участник

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586

|
Раз в ~5 мин сформировать сжатое фото в чб пале. Вот и спрашиваю про алгоритм и время его выполнения
|
|
|
|
|
Mar 30 2011, 14:20
|
Участник

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586

|
Согласен. Но из-за через ж-ной задачи плисина уберает цвет (пока) из пал камеры и хотелось бы сжать это всё оставшееся без потерь качества. Да это мы всё и сделали. Вот советуюсь по поводу компресси остатка от пала чб сигнала. Понимаю что всё... Просто идеи
а весело читающий blackfin что про блекфин чего говорит? любая ифо нужна.
|
|
|
|
|
Mar 30 2011, 14:46
|
Участник

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586

|
Да всё просто - сроки убийственные... LPC знаю, кортекс нет. На это дело, хоть и хоршее, времени нет. А всё наладить, развести и запрограммировать, увести и поставить ... Мне уже до этой скорости. Просто спрашиваю в этих рамках - реализуемо аль нет. Да вот и всё. Собственно разговор был просто о сжатии файла, а потом его разжать...
|
|
|
|
|
Mar 30 2011, 15:02
|
Гуру
     
Группа: Свой
Сообщений: 3 106
Регистрация: 18-04-05
Пользователь №: 4 261

|
Цитата(kiv121 @ Mar 30 2011, 17:20)  а весело читающий blackfin что про блекфин чего говорит? С задачей сжатия одного ч/б кадра 720*576 за 5 мин. справится любой МК, и даже AVR. Кроме того, на форуме работает функция поиска: JPEG. И, наконец, сайт ADI дает глубокий повод для раздумий: JPEG Encoder.
|
|
|
|
|
Mar 30 2011, 15:25
|
Участник

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586

|
Вопрос: объясните бестолковому - сжать, передать без абсолютного потери качества!!! и потом восстановить - это подойдет?
Да вся проблема не голых баб наблюдать, а снежные лавины у ЖД РФ, вот и советуюсь...
|
|
|
|
|
Mar 30 2011, 15:55
|
Местный
  
Группа: Участник
Сообщений: 306
Регистрация: 11-11-04
Из: Москва
Пользователь №: 1 106

|
Цитата(kiv121 @ Mar 30 2011, 15:55)  надо медленно передать фото очень далеко по медленному радиоканалу Огласите плс. числа - скорость канала, сколько раз в час нужно кадры передавать, качество оцифровки видео. А то как-то трудно без этого советы давать
|
|
|
|
|
Mar 31 2011, 08:34
|
Участник

Группа: Участник
Сообщений: 65
Регистрация: 12-11-09
Пользователь №: 53 586

|
Утомился. Есть подход сжать и весело посмотреть. А есть подход реально детально рассмотреть. Это разные вещи: делитанские или любительские. Поэтому промышленное оборудование - одна цена а... другая JPEG можно без потери качества восстановить в первоиссточник??? Блин вопрос был про алгоритм типа зип и унзип и на си
Сообщение отредактировал kiv121 - Mar 31 2011, 08:39
|
|
|
|
|
Mar 31 2011, 09:02
|
Гуру
     
Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136

|
Цитата(kiv121 @ Mar 31 2011, 12:34)  JPEG можно без потери качества восстановить в первоиссточник??? Да, может. При правильных настройках. Цитата(kiv121 @ Mar 31 2011, 12:34)  Блин вопрос был про алгоритм типа зип и унзип и на си Алгоритмы типа зип не дадут существенного сжатия картинки с камеры. Это не обсуждение, а какое-то переливание из пустого в порожнее. Сказано же, любой процессор справится с сжатием кадра в JPEG за 5 минут. Лишь бы памяти хватало.
|
|
|
|
|
Mar 31 2011, 09:39
|
Местный
  
Группа: Участник
Сообщений: 306
Регистрация: 11-11-04
Из: Москва
Пользователь №: 1 106

|
Цитата(scifi @ Mar 31 2011, 12:02)  Да, может. При правильных настройках.
Алгоритмы типа зип не дадут существенного сжатия картинки с камеры.
Это не обсуждение, а какое-то переливание из пустого в порожнее. Сказано же, любой процессор справится с сжатием кадра в JPEG за 5 минут. Лишь бы памяти хватало. 1 кадр видео с качеством 8бит 15МГц передается на скорости 115200 бит/сек прибл. 41 секунду (если я не ошибся в расчетах). С полным качеством и безо всякого сжатия за 5 минут. Вопрос - зачем себе городить проблемы со сжатием и распаковкой JPEG на AVR или еще на чем, если для этого нужно время >41 сек.+ время на передачу этого сжатого кадра? Просто пишите кадр в буфер и передавайте себе спокойно. Быстрее передать на меньшей скорости, чем кодировать и раскодировать видео на микроконтроллерах. И к тому же еще и дешевле будет. И еще не понятно, каким образом это видео в цифру кодируется - простым АЦП, или как?
Сообщение отредактировал andrewkrot - Mar 31 2011, 09:44
|
|
|
|
|
Mar 31 2011, 10:54
|

Гуру
     
Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463

|
Цитата(khach @ Mar 31 2011, 13:41)  Меняйте АРМ- STM32F2xx (именно F2) имеет параллельный интерфейс видео входа- до 14 бит 30 Мгц. Можно сразу видео АЦП цеплять. DMA разложит кадр в память, а дальше-программно. ОЗУ только маловато для работы с кадром- прийдется экономить или поджимать на-ходу по строчкам. А кто будет заниматься синхронизацией, уовнями белого черного итд.? Вы сами хоть делали такое, перед тем как советовать. Вот вот озу мало, поджимать, то есть о сжатии потока можно забыть. MPEG для чего то придумали, ну и как его на F2 сделать?
|
|
|
|
|
Mar 31 2011, 11:58
|
Гуру
     
Группа: Свой
Сообщений: 3 439
Регистрация: 29-12-04
Пользователь №: 1 741

|
Цитата(Aner @ Mar 31 2011, 12:54)  А кто будет заниматься синхронизацией, уовнями белого черного итд.? Вы сами хоть делали такое, перед тем как советовать. Вот вот озу мало, поджимать, то есть о сжатии потока можно забыть. MPEG для чего то придумали, ну и как его на F2 сделать? Вообще то видео-ацп обычно имеет схемы синхронизации внутри. И уровни белого-черного тоже он привязывает. Именно на STM32F2xx- нет, не делал. Семплы только недавно приехали, юзерманул только появился, а аппликух по DCMI (Digital Camera Interface) тоже еще нет. Пока макетную плату разводим на свой страх и риск. Чтобы MPEG жать надо внешнюю память ставить. Для этого у STM32F2xx есть FSMC - прийдется внешнюю SRAM цеплять. Для наших задач оно ненадо, поэтому не разводим.
|
|
|
|
|
Apr 5 2011, 13:31
|
self made
   
Группа: Свой
Сообщений: 855
Регистрация: 7-03-09
Из: Toronto, Canada
Пользователь №: 45 795

|
Цитата(pofikus @ Apr 5 2011, 08:04)  для черно-белой картинки хорошо должна подойти простенькая RLE компрессия. http://en.wikipedia.org/wiki/Run-length_encodingВы попробуйте для начала, прежде чем советовать. RLE подойдет если у вас что-то типа гравюры - т.е. есть всего два цвета -- черный, и белый. Ни для каких нормальных фоток и видео с полутонами RLE работать не будет. Цитата(Aner @ Apr 1 2011, 05:49)  Это не верно. Вы просто не знаете как это упаковывается, распаковывается. Вообщето если это чб картинка, то лучше подходит формат GIF. Опять-таки -- только если это графика без полутонов. На любой нормальной фотографии JPEG будет работать существенно лучше. Он был сделан именно для компресссии фоток, в отличии от гифа, который вообще не в курсе, что сжимаемый поток байтов -- картинка.
Сообщение отредактировал ar__systems - Apr 5 2011, 13:32
|
|
|
|
|
Apr 5 2011, 19:04
|
Участник

Группа: Участник
Сообщений: 22
Регистрация: 8-12-10
Пользователь №: 61 494

|
Цитата(ar__systems @ Apr 5 2011, 16:31)  Вы попробуйте для начала, прежде чем советовать. RLE подойдет если у вас что-то типа гравюры - т.е. есть всего два цвета -- черный, и белый. Ни для каких нормальных фоток и видео с полутонами RLE работать не будет. пробовал, по этому и советую.... но предварительно надо подготовить картинку.... В данном случае так как радио канал наверно зашумлен, я бы картинку не компресировал, а редко передавал бы полную картинку, а в промежутках изменения происшедшие с момента передачи полной картинки....
Сообщение отредактировал pofikus - Apr 5 2011, 19:49
|
|
|
|
|
Apr 5 2011, 19:42
|
Группа: Участник
Сообщений: 6
Регистрация: 16-12-05
Пользователь №: 12 291

|
Цитата(M_Andrey @ Mar 31 2011, 23:59)  Если в BMP потерять пару байт - получим пару битых пиксел, а если в JPEG (или подобных) - получим битый кадр. Какие потери байт? О чем вы? Передача данных разве не подразумевает протокол? Пакеты, кадры, CRC. итд итп.
|
|
|
|
|
Apr 5 2011, 19:46
|
Участник

Группа: Участник
Сообщений: 22
Регистрация: 8-12-10
Пользователь №: 61 494

|
Цитата(Aner @ Apr 5 2011, 22:19)  ar__systems чёт не то пишет. GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью. GIF хорош тем, что можно потерять более половины картинки (кадра), но распознавание сюжета остается высокое, в отличии от JPEGа. ... сжимаемый поток..., вообще не отсюда. Причем сдесь это, если говорим о стандартах сжатия. LPC и обработка видео как то не стыкуются все же. Не для этого LPC_шки разрабатывали. у автора сжатие потока - глобальная задача, а ваши GIF, TIF, JPEG - тоже методы сжатия потока...
|
|
|
|
|
Apr 5 2011, 20:49
|
self made
   
Группа: Свой
Сообщений: 855
Регистрация: 7-03-09
Из: Toronto, Canada
Пользователь №: 45 795

|
Цитата(Aner @ Apr 5 2011, 14:19)  GIF то что надо, поскольку по стандарту 255 градаций серого (если чб), JPEG проигрывает избыточностью. Вы, извините, что-то где-то слышали, но понятия не имеете, о чем говорите. Да, гиф 8 бит, JPEG 24. Ну и что? Вы для начала тупо возьмите и поэксперементируйте, как сжимает Гиф и JPEG. Например, следующая картинка: После того как я ее в черно-белую переделал и сконвертил в GIF, JPEG -- 17KB, GIF -- 150KB. И меньше гиф уже никак не станет, а JPEG eще может жать и жать, при 17КB никаких артефактов еще нет. А после экспериментов почитайте как они оба сжимают, чтобы не писать в следующий раз нелепицу. Цитата(NetTracer @ Apr 5 2011, 14:42)  Какие потери байт? О чем вы? Передача данных разве не подразумевает протокол? Пакеты, кадры, CRC. итд итп. +1.
Сообщение отредактировал ar__systems - Apr 5 2011, 20:46
|
|
|
|
|
Apr 6 2011, 13:05
|

Профессионал
    
Группа: Свой
Сообщений: 1 121
Регистрация: 14-01-05
Из: Москва
Пользователь №: 1 952

|
Цитата(sasamy @ Apr 6 2011, 08:42)  А Вы отмотайте тему на пару страниц - речь идет о ч/б изображении - на них jpeg вообще теряет все свои преимущества в компрессии. Вы сами придумали эту чушь? GIF - алгоритм сжатия без потерь (качества). JPEG - алгоритм сжатия с потерями. В нём применяется дискретное косинусное преобразование (DCT). Из всех преобразований оно имеет наиболее быстро спадающие коэффициенты, поэтому обеспечивает наибольшее сжатие среди алгоритмов, разбивающих изображение на квадраты 8х8 точек. Большее сжатие может обеспечить лишь вейвлет-алгоритм, но только потому, что обрабатывает всё изображение целиком, не разбивая на квадраты. А коэффициенты вейвлет-алгоритма спадают медленнее, чем у DCT.
|
|
|
|
|
Apr 6 2011, 17:24
|
Знающий
   
Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858

|
Цитата(etoja @ Apr 6 2011, 17:05)  Вы сами придумали эту чушь? Сходите-ка в FAQ http://www.faqs.org/faqs/jpeg-faq/part1/Цитата Gray-scale images do not compress by such large factors. Because the human eye is much more sensitive to brightness variations than to hue variations, JPEG can compress hue data more heavily than brightness (gray-scale) data. A gray-scale JPEG file is generally only about 10%-25% smaller than a full-color JPEG file of similar visual quality. But the uncompressed gray-scale data is only 8 bits/pixel, or one-third the size of the color data, so the calculated compression ratio is much lower. The threshold of visible loss is often around 5:1 compression for gray-scale images.
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|