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

  Розпочинаємо серію статей на Хабре, присвячену відеопроцесорам TI DM368, DM369 і розробці алгоритмів на їх основі.
Pассмотрім основні блоки обробки відеопотоку від сенсора до мережевого "мовника", більш докладно зупинимося на алгоритмах автоекспозиції, балансу білого і автофокусу (3A), гамма корекції, а так само розширеному динамічному діапазоні HDR або WDR, і, нарешті, детекторі руху та аналітиці на його основі.
Приклади картинок будуть представлені для сенсора SONY IMX136 , так же алгоритм перевіряється на сенсорах Apina MT9P006 , AR0331 , MT9M034 .
          
До Після
 
Основними гравцями на процесорному ринку для ip відеоспостереження є 3 компанії TI , Ambarella і Hisilicon . У всіх з них є чіпи різного цінового діапазону, найпопулярніші зараз на ринку c можливістю кодування FHD (1920x1080) відеопотоку до 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, щоб отримати документацію і підтримку треба викласти $ 25 400.
 
Отже, повернемося до 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, це двовимірний фільтр 5x5 поліпшує контрастність зображення — це окрема тема для статті, тут наведу тільки приклади його роботи:
2D EE вимкнуто:
 
2D EE включений:
 
Тобто дуже корисна штука.
9. Resizer зменшує картинку по вертикалі і по горизонталі для другого і третього потоків, а так само перетворює YCbCr 422 в YCbCr 420 для енкодера.
 
Окремо від всього тракту обробки відео стоїть блок статистики H3A. Він потрібен для реалізації всіх алгоритмів. На основі отриманих з нього даних виставляється експозиція, коефіцієнти підсилення і зрушення.
1. Статистика для експозиції і колірного балансу виходить розподілом картинки на осередки до 56-ти по горизонталі і 128-ми по вертикалі. За кожного осередку можна отримати суму всіх піксілей для кожного кольору, мінімальне і максимальне їх значення.
2. Блок для автофокусу так само розбиває картинку на осередку до 12-ти по горизонталі і 128-ми по вертикалі. І по кожній осередку видає максимальне значення фокуса.
А ось що це таке не пояснили. Вивчення софта особливо нічого не прояснило, стало тільки відомо що це якийсь RIF фільтр, у якого можна міняти коефіцієнти і пороги, але це особливо не допомагало, і автофокус працював не стійко.
 
Отже, навіщо ми взялися за це і що нас не влаштовувало в існуючих алгоритмах? Основна проблема існуючого алгоритму — неповне використання динамічного діапазону.
Приклад роботи алгоритму похмуру погоду:
 
Вранці і ввечері, як правило, пливе баланс білого:
 
А цей приклад з нашим алгоритмом:
 
І щоб все працювало добре з різними сенсорами, ми вирішили не правити купу чужого софта, а написати свій з нуля. Ще одне завдання алгоритм повинен якомога легше переноситися на інші платформи. На удачу, у DM368 виявився дуже корисний апаратний блок, так званий Boxcar. Не що інше як усреднітель блоками 8x8 або 16x16
 
Тобто, на виході boxcar ми отримуємо зменшену в 16 разів raw картинку по кожній осі. Якщо вхідна дозвіл 1920x1080, то для статистики ми маємо 120x68.
Цей блок ми і взяли в якості джерела статистики.
 
Намалюємо блок схему роботи нашого алгоритму і перейдемо до коду.
 
Живу трансляцію з наших і чужих камер можна подивитися тут .
Далі буде…
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.