Алгоритмы обработки видео на процессоре TI DM368

Начинаем серию статей на Хабре, посвященную видеопроцессорам TI DM368, DM369 и разработке алгоритмов на их основе.
Pассмотрим основные блоки обработки видеопотока от сенсора до сетевого “вещателя”, более подробно остановимся на алгоритмах автоэкспозиции, баланса белого и автофокуса (3A), гамма коррекции, а так же расширенном динамическом диапазоне HDR или WDR, и, наконец, детекторе движения и аналитике на его основе.
Примеры картинок будут представлены для сенсора SONY IMX136, так же алгоритм проверен на сенсорах Apina MT9P006, AR0331, MT9M034.

До	После

Основными игроками на процессорном рынке для ip видеонаблюдения являются 3 компании TI, Ambarella и Hisilicon. У всех из них есть чипы разного ценового диапазона, самые популярные сейчас на рынке c возможностью кодирования FHD(1920×1080) видеопотока до 30 кадров в секунду DM368(TI), A5(Ambarella), Hi3516(Hisilicon) по цене от 10$ до 20$ и более мощные до 60 кадров в секунду DM385(TI), A7(Ambarella), Hi3517(Hisilicon) по цене от 20$ до 40$. Характеристики этих чипов примерно одинаковые.
Так как TI довольно открытая компания, вся документация по железу есть на сайте, то с ними работать проще всего. Чтобы получить софт и весь дизайн достаточно купить камеру у Appro за 1000$ и вперед. Для получения документации от HiSilicon надо подписать NDA, а стоимость поддержки и референсной платы составляет 5000$. Самая дорогая оказалась Ambarella, чтобы получить документацию и поддержку надо выложить $25400.

Итак, вернемся к DM368:

Как видно на схеме, у процессора есть все, что нужно для ip камеры и не только для нее. Обработкой видео занимается Video Processing Subsystem (VPSS), в свою очередь он состоит из двух блоков Video FE (Front End) и Video BE (Back End). Video FE отвечает за ввод видео сигнала и его обработку, а Video BE за кодирование и вывод на различные устройства. Аппаратная поддержка 3A алгоритмов находится в Video FE модуле.

Рассмотрим его по подробней:

На вход IPIPEIF (Image Pipe Interface ) поступает “сырая” raw 12 битная картинка в Bayer формате из сенсора. Сам этот блок особо полезного ничего не делает, главным образом он служит для синхронизации работы ISIF и IPIPE, также может вычитать из каждого нового фрейма “темновой” хранящийся в памяти, но мы это не используем.
Image Sensor Interface (ISIF) может преобразовывать Bayer в различные форматы, умножать, вычитать и т.д., более подробно с возможностями можно ознакомиться в документации. Мы из этого блока для своих алгоритмов используем:
1. “Вычитатель” постоянного значения из всех цветов, у наших двух сенсоров при полной темноте выдается не 0, а константа, для SONY 176, а для Aptina 172. Это необходимо учитывать для правильной балансировки цветов, особенно в темное время.
2. Gain and Offset — им мы делаем баланс белого. Для каждого цвета можно задавать свой коэффициент умножения от 0 до (7 + 511/512), в стандартном для всех аппаратных “умножителей” формате: OUT = IN*G>>9, где IN входное значение цвета, G “умножитель” от 0 до 4095.
Следующий блок Image Pipe (IPIPE) — используется нами для всего остального.

Начнем по порядку:
1. Defect Correction может обрабатывать “битые” пиксели, правда перед тем как обработать он должен знать их координаты, а чтобы задать их, нужно калибровать в темноте каждый сенсор, что сильно усложняет производство. Не так уж много бракованных сенсоров попадается, а если попался — легче заменить.
2. Следующий блок White Balance состоит из 3-х умножителей и 3-x вычитателей по одному для каждого цвета, мы его используем как глобальный коэффициент умножения и вычитатель порога, одинаковый для всех цветов.

формат такой же как и в ISIF блоке, только диапазон умножения в два раза больше.
3. CFA Interpolation преобразует из формата Bayer

в RGB

Какой алгоритм интерполяции применяется мы так и не нашли.
4. RGB2RGB blending module пропускает каждый пиксель RGB через матрицу

где gain может меняться от -8 to +7.996 с шагом 1/256 = 0.004, a offset от -4096 до 4095.
Причем этих блоков оказалось два, один за другим, и мы их оба используем в своих алгоритмах. Каждый производитель дает таблицы для своих сенсоров. Честно сказать, я не совсем понимаю, как это работает, и как цвета могут смешиваться, но картинка действительно становится лучше. Скоро все увидите сами.

5. Блок гамма коррекции состоит из 3-х LUT (look-up-table) по одной для каждого цвета.

Можно выбирать размер таблицы от 512 до 64 значений, мы используем 512. Каждый элемент таблица состоит из двух 10 битных слов Offset и Slope.

На вход поступают 12 битные данные IN, затем они разбиваются на две части HIGH = IN>>3, LOW = IN&7, верхние 9 бит и нижние 3 бита. Выходное значение вычисляется по следующей формуле OUT = (Offset[HIGH] <<3) + (Slope[HIGH]>>3)*LOW. То есть гамма кривая аппроксимируется кусочно гладкой функцией.

6. Блок RGB2YCbCr переводит цветовое пространство RGB в YCbCr.
7. 4:2:2 Conversion Module уменьшает вдвое цветовые составляющие Cb и Cr
по горизонтали.

8. 2D Edge Enhancer, это двумерный фильтр 5×5 улучшающий контрастность изображения — это отдельная тема для статьи, здесь приведу только примеры его работы:
2D EE выключен:

2D EE включен:

То есть очень полезная штука.
9. Resizer уменьшает картинку по вертикали и по горизонтали для второго и третьего потоков, а так же преобразует YCbCr 422 в YCbCr 420 для энкодера.

Отдельно от всего тракта обработки видео стоит блок статистики H3A. Он нужен для реализации всех алгоритмов. На основе полученных с него данных выставляется экспозиция, коэффициенты усиления и сдвиги.
1. Статистика для экспозиции и цветового баланса получается делением картинки на ячейки до 56-ти по горизонтали и 128-ми по вертикали. По каждой ячейки можно получить сумму всех пиксилей для каждого цвета, минимальное и максимальное их значение.
2. Блок для автофокуса так же разбивает картинку на ячейки до 12-ти по горизонтали и 128-ми по вертикали. И по каждой ячейки выдает максимальное значение фокуса.
А вот что это такое не объяснили. Изучение софта особо ничего не прояснило, стало только известно что это некий RIF фильтр, у которого можно менять коэффициенты и пороги, но это особо не помогало, и автофокус работал не устойчиво.

Итак, зачем мы взялись за это и что нас не устраивало в существующих алгоритмах? Основная проблема существующего алгоритма — неполное использование динамического диапазона.
Пример работы алгоритма пасмурную погоду:

По утрам и вечерам, как правило, плывет баланс белого:

А этот пример с нашим алгоритмом:

И чтобы все работало хорошо с разными сенсорами, мы решили не править кучу чужого софта, а написать свой с нуля. Еще одна задача алгоритм должен как можно легче переноситься на другие платформы. На удачу, у DM368 оказался очень полезный аппаратный блок, так называемый Boxcar. Не что иное как усреднитель блоками 8×8 или 16×16

То есть, на выходе boxcar мы получаем уменьшенную в 16 раз raw картинку по каждой оси. Если входное разрешение 1920×1080, то для статистики мы имеем 120×68.
Этот блок мы и взяли в качестве источника статистики.