Обработка изображения с камеры OV7670

[Sergey_57]

Здравствуйте, коллеги!
Есть одна задача с видеокамерой.
Это часть одной большой задачи. Работа связана со зрением для слепых.
При положительных итогах первого этапа, готов рекомендовать для совместной работы и трудоустройства удалённо. Сам работаю на полставки. Совещания по телефону ....
Все практически работают удалённо.
Или предложите другой свой вариант.

Суть работы 1-го этапа Захват изображения с камеры OV7670 (240*320) и Укрупнить 16(8)*16(8) = 256(64) раз и выдать на ILI9341SPI. Думаю , что STM32F103RET6 подойдёт.
Памяти всё равно не хватит записать кадр. Поэтому на проходе данных по одной строке, группироем данные по 16(8) , находим среднее арифметическое и пишем в ячейку. Их будет 40.
После принятия кадра также поступаем с 16(8) со столбцами в строках.
В итоге нужно получить массив 15(30)*20(40).
Выдать по SPI , это чисто для контроля алгоритма. Изображение можно как растянуть так и смотреть под лупой.

[mike-y-k]

OV7670 в оконном режиме (не все 640x480)?
Вывод в RAW?
240*320=76800 на каждый цвет?
Тогда 240*320*3=230400
Алгоритм усреднения для результирующего пикселя?

Использовать FPGA для такой операции не проще?
Если уж решили херить так картинку, то сильно качественней будет усреднение по результирующему пикселю 16х16/8х8 с учетом цвета.
Или нужен просто серый результат?
У камеры 30fps и нужно принимать 8-битные параллельные данные на скорости ЕМНИП 9216000, если даже QVGA, то 2304000 byte/s
MCU должен ведь их еще успеть обработать - MIPS никто не отменял, а там примерная программа в командах займет примерно по 10…30 команд для чтения и для примитивного усреднения, плюс прерывания, плюс вывод сжатого кадра,…
Посчитали нужную производительность?
А с запасом на другой алгоритм обработки?
Если уж оставлять MCU/MPU, то может стоит выбрать с нормальным RAM (2 входных кадра + 2 выходных кадра) для нормальной организации конвейерной обработки ввода, кадра и вывода)?
При изменении алгоритма ресамплинга изображения идею с STM32F103 придется полностью переделывать.

PS На досуге подумал о бикубике
Если отмести усложнения, то для максимального сжатия нужен буфер поменьше
(240*16*3)+(240/16*3)=11*565, а для минимального (240*8*3)+(240/8*3)=5850
Это уже вполне реально для МК…

PPS STM32F103C8T6 (blue pill ) вполне подойдет. И уже на плате…

[eddy]

что STM32F103RET6 подойдёт.
Памяти всё равно не хватит записать кадр

Вы в курсе, какой огромный объем ОЗУ у этого чипа?
Во всяком случае, у STM32F303CBT6 ее хватает для вывода на экран. Там-то надо всего немного: 9600 байт на пиксельный буфер + два (фон и передний план) по 1200 байт. Ну и хотя бы один буфер в "родном" для экрана формате, вмещающий одну-две строки (передача идет по DMA, в половине передачи ставим флаг и формируем первую половину буфера; по окончании передачи формируем вторую, а если первая уже готова - передаем ее).

[Sergey_57]

Здравствуйте, форумчане!
Спасибо за ответы.
Написал целую статью и всё пропало.
Это работа для облегчения жизни слепых.
Связка 2 камеры и два лидара VL53l5 дают матрицу изображения. свыше 2-х метров изображения отсекаются.
Данные передаются по радиоканалу в имплант. Имплант 8*8 точек .
разработка на 16*16.
Исполнительный орган импланта накладка на мозг. Имплант это не наша задача.
Импульсы зажигают точки. Речь о цвете не идёт. Частота кадров неизвестна,
думаю 5 хватит.
Товарищ пошёл - Камеры высокого разрешения , одноплатный компьютер на поясе кабели от лидаров , камер. Тупиковый путь. Работать будет , в серию не пойдет.
Задача ставиться собрать в очках. Или какая-то накладка типа очков по форме.

[mike-y-k]

На алгоритм обработки сильно влияет цель.
Из картинки HxV Ffps сделать (256/64)*6 ее часть просто непонятным методом усреднения картинки.
Что должна показать 16x16, а потом 8x8 матрица?
В этом может крыться серия проблем.
ЕМНИП есть камеры с готовым процессором похожей обработки для специализированных применений (контроль обстановки,…).
Это еще и энергетически значительно выгоднее.
Итоговая картинка в таких камерах может сжиматься вплоть до битовой матрицы состояния и иметь переменную частоту кадров.
Пока путь очень напоминает методы SpaceX, но при явно несопоставимом отсутствии ресурсов…

PS А у этих камер ведь тоже есть прошивка, номинальная обработка картинки (яркость, цвет, баланс, динамический диапазон,…)…
И еще одна мелочь - что будет (нужно получить) при падении освещенности, когда пойдет просто шум…

[Sergey_57]

Тему закрываю.
Придётся делать всё самому.
Взял логический анализатор на 400 мГц.
Буду дерзать.