Що таке кадрове бачення?
Кадрове бачення фіксує сцену як цілі зображення через рівні проміжки часу, наприклад, 30, 60 або 120 кадрів на секунду. Кожен кадр містить щільну просторову інформацію, що робить звичайні камери природним пристосуванням для розпізнавання об’єктів, аналізу кольорів, перевірки, картографування та великої програмної екосистеми, побудованої навколо тензорів зображення.
Компроміс полягає в тому, що кожен кадр переміщує повне зображення через конвеєр незалежно від того, змінилася сцена чи ні. Для швидкого циклу прийняття рішень час експозиції, період кадру, зчитування датчика, перенесення, перетворення зображення та логічний висновок сприяють наскрізній затримці. Висока частота кадрів зменшує інтервал дискретизації, але зазвичай збільшує пропускну здатність, трафік пам’яті, потужність і теплове навантаження.
Що таке подійне бачення?
Зір на основі подій використовує датчик зображення на основі подій, пікселі якого асинхронно реагують на зміни яскравості. Замість того, щоб надавати прямокутне зображення з фіксованою частотою, датчик створює потік, що містить координати пікселів, полярність і точні мітки часу. Таким чином, статичні області генерують мало або зовсім не генерують даних, тоді як рухомі краї можуть створювати події з дуже високою тимчасовою роздільною здатністю.
Це представлення корисне, коли синхронізація руху має більше значення, ніж повторне отримання повного зображення. Він може підтримувати відстеження з низькою затримкою, високошвидкісну роботизацію та складні переходи освітлення, але потік подій не є звичайною фотографією. Алгоритми, інструменти візуалізації, запису та перевірки повинні бути розроблені навколо моделі даних.
Як датчик зображення на основі подій змінює шлях даних
Корисна довідкова система розкриває повний шлях від отримання датчиком через фільтрацію та обробку до вихідних даних програми. Інструментуйте ці межі, щоб можна було оцінювати вимоги щодо затримки та швидкості передачі даних.
Ключова архітектурна відмінність полягає не просто в «швидшій камері проти повільнішої». Звичайний конвеєр візуалізації часто починається з повного буфера зображення. Конвеєр на основі подій може почати обробку окремих подій або невеликих вікон подій, щойно вони надходять. Це дозволяє фільтрувати, вирівнювати мітки часу, логіку регіону інтересу та функції руху працювати поблизу датчика, не чекаючи повного кадру.
Однак дані про події можуть стати щільними в сценах з високою текстурою або під час вібрації та мерехтіння. Тому проектування системи має вимірювати частоту подій у найгіршому випадку, використання інтерфейсу та пропускну здатність пам’яті, а не припускати, що виявлення подій завжди означає низьку пропускну здатність.
Бачення на основі подій проти бачення на основі кадрів
| Розмір | Каркасне бачення | Подійне бачення |
|---|---|---|
| Вихід датчика | Щільні зображення через фіксовані інтервали | Асинхронні події зміни яскравості |
| Інформація про час | Обмежено експозицією та частотою кадрів | Точні мітки часу, пов’язані з окремими подіями |
| Дані статичної сцени | Повні кадри продовжують надходити | Невелика активність із незмінених регіонів |
| Просторовий / колірний контекст | Сильний; абсолютна інтенсивність зображення та зображення зрілого кольору | непрямий; потік подій описує зміни, а не звичайне зображення |
| Високошвидкісний рух | Потрібна відповідна експозиція та частота кадрів | Добре підходить для швидких тимчасових змін |
| Екосистема програмного забезпечення | Дуже зріле резюме та інструменти глибокого навчання | Більш спеціалізовані алгоритми, представлення та набори даних |
| Найкраще підходить | Загальне зображення, розпізнавання, текстура та зрозумілі людині зображення | Швидка динаміка, часові особливості та сприйняття руху з низькою затримкою |
Затримка: вимірюйте від датчика до рішення, а не один компонент
Камери для проведення подій часто вибирають для сприйняття з низькою затримкою, але роздільна здатність мітки часу датчика не те саме, що затримка програми. Корисна технічна метрика — це час від зміни в реальному світі до появи рішення в інтерфейсі системи. Цей шлях включає відповідь датчика, транспортування, буферизацію, попередню обробку, висновок або відстеження, програмне планування та вихідний зв’язок.
Це ж правило стосується і рамкової камери. Добре розроблений конвеєр із високою частотою кадрів із прямими шляхами пам’яті може перевершити погано інтегрований конвеєр подій. Таким чином, архітектуру слід порівнювати з репрезентативним рухом, освітленням і алгоритмами.
Програмне забезпечення бачення на основі подій і міркування SDK
Стек програмного забезпечення бачення на основі подій зазвичай потребує конфігурації пристрою, декодування подій, обробки часових позначок, фільтрації, візуалізації, запису та відтворення. Корисне бачення на основі подій SDK також має спрощувати синхронізацію зовнішніх тригерів та інших датчиків, перевіряти частоту подій і відтворювати захоплену послідовність під час розробки алгоритму.
Для виробничих систем програмне забезпечення має виходити за межі робочого столу SDK. Команди повинні визначити, як події переміщуються до ресурсів FPGA, MCU, MPU або NPU; як зберігається калібрування; як синхронізується час; і як можна відтворити польові журнали. Якщо алгоритм перетворює події на накопичені кадри, вікно накопичення стає явним компромісом між затримкою та інформацією.
Де бачення, засноване на подіях, є корисним
Типові програми бачення на основі подій включають високошвидкісне відстеження цілей, роботизоване керування, оптичний потік, аналіз вібрації або руху, швидкий промисловий огляд і автономне сприйняття сцен із великими змінами яскравості. Найсильніші випадки використання зазвичай ті, де точна часова структура безпосередньо покращує рішення, а не просто замінює звичайну камеру.
Бачення захисних і автономних платформ, засноване на подіях
У системах оборони, безпеки та автономних системах виявлення подій може бути актуальним для сигналів швидкого руху, експериментів із відстеженням, оптичних корисних навантажень із низькою затримкою та досліджень синтезу датчиків. Система все ще має відповідати вимогам платформи, таким як синхронізація, детерміновані інтерфейси, дизайн середовища, запис, кібербезпека та перевірка. Розпізнавання подій є одним із компонентів ланцюга місії, а не повним рішенням сприйняття саме по собі.
Коли гібридна архітектура камери краща
Багато практичних систем виграють від комбінування модальностей. Фрейми можуть забезпечувати семантичний контекст і зрозумілі людині зображення, а події — часові деталі. Теплові, інерційні або датчики дальності можуть підвищити надійність. Fusion особливо корисний, коли додатку потрібні і «що це?» і «коли саме і як він рухався?»
Для гібридних систем спільний час є важливим. Апаратні тригери, домени часових позначок і калібрування слід розглянути перед тим, як завершувати алгоритми.
Практична еталонна архітектура бачення на основі подій
Довідкова система може розміщувати детерміновану фільтрацію та роботу з часовими мітками в FPGA, висновки штучного інтелекту в NPU або прискорювач, служби додатків у MPU, а нагляд у MCU або ядро реального часу. Правильний розподіл залежить від частоти подій, архітектури моделі, пропускної здатності пам’яті та зовнішніх інтерфейсів. наш Посібник із вибору FPGA, NPU та MPU для Edge AI пояснює це поділ більш детально.
Контрольний список для вибору
- Визначте максимально допустиму затримку від датчика до прийняття рішення.
- Виміряйте очікувану швидкість руху, діапазон освітлення та найгіршу сцену.
- Вирішіть, чи потрібна абсолютна інтенсивність зображення, кольорове чи зрозуміле для людини відео.
- Оцініть пропускну здатність і рух пам’яті як для типових, так і для найгірших сцен.
- Підтвердьте зрілість алгоритму, набору даних і бачення на основі подій SDK.
- Плануйте синхронізацію з рамковими, тепловими, інерційними або зовнішніми джерелами запуску.
- Порівняйте весь конвеєр, перш ніж заморозити обчислення, носій і температурний дизайн.
Виберіть спостереження, яке потребує додаток
| Питання до програми | Підходьте до оцінки спочатку | Що тестувати |
|---|---|---|
| Чи правильна надрукована етикетка чи колір? | Каркасне зображення | Роздільна здатність, освітлення, експозиція та точність огляду |
| Коли край, що швидко рухається, перетнув область? | Розпізнавання на основі подій | Якість синхронізації, активність сцени, помилкові події та повна затримка виведення |
| Який об’єкт присутній і як саме він рухається? | Гібридний фрейм і конвеєр подій | Переваги калібрування, спільного часу, представлення та злиття |
| Чи працюватиме система при зміні світла чи вібрації? | Обидва кандидати на однакових представницьких умовах | Точність програми, швидкість подій або якість кадру та використання ресурсів |
Використовуйте однакові завдання та сцену, порівнюючи кандидатів. Чітка візуалізація сама по собі не є результатом виявлення, а велика кількість подій не є доказом корисної інформації. Узгодьте вихідну метрику перед записом порівняння.
Практичний спосіб створити бюджет затримки
При 60 кадрів за секунду інтервал кадрів становить приблизно 16.7 мс. Відповідно до спрощеної моделі, в якій зміна сцени відбувається рівномірно між миттєвими вибірками, середнє очікування до наступної вибірки становить близько 8.3 мс. Експозиція, зчитування, транспортування та обробка є додатковими ефектами. Ця арифметика описує інтервал вибірки; це не виміряна затримка камери.
Конвеєр подій також має варіанти дизайну, які додають затримку. Якщо програма очікує, поки вікно події 5 мс закриється перед обробкою, подія біля початку цього вікна може чекати майже 5 мс лише на цьому етапі. Точні мітки часу датчика не скасовують вибір буферизації. Використовуйте ці приклади, щоб визначити етапи, які варто вимірювати, а не претендувати на фіксовану перевагу для будь-якого датчика.
| Межа | Рамний трубопровід | Конвеєр подій |
|---|---|---|
| Спостереження | Час експозиції та вибірки | Реакція на зміну яскравості та генерація позначок часу |
| Транспорт | Буфери зчитування, посилання та хосту | Кодування подій, буфери посилань і декодера |
| Підготовка | Перетворення зображення, зміна розміру та підготовка тензора | Фільтрація, часові вікна та побудова подання |
| Рішення | Алгоритм і планування виходу | Алгоритм і планування виходу |
Виміряйте вихідний вік із дійсним співвідношенням між годинником спостереження та годинником результату. Позначка часу програмного забезпечення в кінці виклику зчитування з камери не обов’язково означає час експозиції. Так само точна позначка часу події може належати годиннику, який ще не узгоджено з хостом.
Створіть порівняння, яке може відтворити інший інженер
- Перш ніж вибрати налаштування, визначте завдання, рух цілі, дальність освітлення та необхідний вихід.
- Документуйте оптику, поле зору, налаштування датчика, версії програмного забезпечення та калібрування.
- Записуйте репрезентативні умови, у тому числі складні сцени, такі як мерехтіння або вібрація, де це необхідно.
- Разом оцінюйте точність завдання, затримку виведення, швидкість передачі даних і постійне навантаження на обробку.
- Зберігайте записи та файли конфігурації, щоб можна було порівнювати зміни алгоритму на тих самих входах.
На етапі реалізації наш програмне забезпечення камери події та посібник SDK охоплює представлення даних, запис і розгортання. Використовуйте посібник із синхронізації часу при поєднанні модальностей.
Яку камеру слід оцінити для перевірки якості?
Почніть з дефекту, який вам потрібно помітити. Відсутній компонент, надрукована етикетка чи позначка на поверхні можуть добре підійти для звичайних зображень у кадрі з контрольованою оптикою та освітленням. Якщо важливим сигналом є швидкий рух або точний час зміни, оцініть розпізнавання подій за тим самим завданням.
Запишіть найменшу релевантну функцію, швидкість об’єкта, поле зору, зміну освітлення та доступний час прийняття рішення. Зберігайте звичайні варіації виробництва в оцінці: різні партії, зміни, оздоблення поверхні та позиції деталей. Порівняйте пропущені дефекти та помилкові відхилення, а також швидкість обробки.
Розпізнавання подій є кандидатом на тестування, а не обов’язковим для кожної системи перевірки. Дивіться наш промислове бачення та рішення для контролю якості для міжкамерної інтеграції та планування пілотний проєкт.
Поширені запитання щодо бачення на основі подій
Що таке подійне бачення?
Бачення на основі подій — це підхід сприйняття, за якого пікселі повідомляють про локальні зміни яскравості асинхронно замість того, щоб чекати повного кадру зображення. Кожна подія зазвичай містить піксельні координати, полярність і позначку часу, що дозволяє інформації, пов’язаній з рухом, досягати конвеєра обробки з високою тимчасовою роздільною здатністю.
Яка різниця між баченням на основі подій і баченням на основі кадрів?
Кадрове бачення фіксує цілі зображення через фіксовані проміжки часу, тоді як бачення на основі подій повідомляє про зміни, коли вони відбуваються. Рамкові камери забезпечують щільний просторовий і колірний контекст; датчики подій можуть зменшити надлишкові дані статичної сцени та покращити синхронізацію швидкого руху. Найкраща архітектура залежить від завдання, освітлення, програмного стека та необхідної затримки прийняття рішення.
Яке програмне забезпечення або SDK потрібне для бачення на основі подій?
Програмне забезпечення бачення на основі подій має обробляти асинхронні потоки подій, а не лише звичайні тензори зображень. Практичний SDK повинен підтримувати конфігурацію датчика, фільтрацію подій, обробку часових позначок, візуалізацію, запис, відтворення, калібрування, синхронізацію та перетворення у представлення, необхідні для відстеження або конвеєрів нейронної мережі.
Де використовується подійне бачення?
Типові програми зору на основі подій включають високошвидкісну робототехніку, відстеження руху, автономні системи, промисловий моніторинг і зондування, де швидкі зміни сцени або складне освітлення роблять важливе значення часу. Він також може доповнювати звичайні камери в гібридних системах сприйняття.
Як бачення на основі подій можна використовувати в оборонних платформах?
Для захисних і автономних платформ датчики подій можуть підтримувати підказки руху з низькою затримкою, відстеження та сприйняття за високого динамічного діапазону або швидкого руху. Система, що розгортається, все ще потребує детермінованої мітки часу, надійних інтерфейсів, синхронізованого об’єднання даних сенсорів, перевіреного програмного забезпечення та ретельного вимірювання частоти подій у найгіршому випадку.
Чи завжди датчик зображення на основі подій має меншу пропускну здатність?
Ні. Статичні сцени можуть генерувати мало даних, але вібрація, мерехтіння або сильно текстурований рух можуть створювати щільні потоки подій. Таким чином, дизайн інтерфейсу та пам’яті повинен використовувати виміряні частоти подій у найгіршому випадку, а не припускати, що розпізнавання подій завжди має низьку пропускну здатність.
машинний зір, тепловізійна візуалізація і питання перевірки
Комп’ютерний зір — це широке поле вилучення корисної інформації з візуальних даних. У промисловому машинний зір система також повинна забезпечувати повторюваний результат перевірки за обмежень освітлення, руху та часу лінії. Вибирайте між розпізнаванням на основі кадрів і на основі подій, перевіряючи дефект або функцію руху, яку програма насправді повинна спостерігати.
тепловізійна візуалізація додає інший вимір вимірювання: інфрачервоне випромінювання, пов’язане з температурою поверхні. Видима камера може виявити дефекти складання або поверхні, тоді як теплова камера виявляє зміни температури. Ці методи можуть доповнювати один одного, але жоден не гарантує видимість кожної несправності. Визначте вирівнювання, умови вимірювання та правила прийняття рішень перед об’єднанням їх у систему перевірки.
Вивчіть візуальний і термічний контроль якості
Технічні довідки
- Галлего та ін.: Бачення на основі подій — опитування
- Prophesee: потокове передавання подій і віконний доступ
Приклади хронометражу є ілюстративними обчисленнями. Заяви про затримку та виявлення на рівні продукту вимагають вимірювання повної реалізації.
Оцініть бачення, засноване на подіях, у вашому фактичному циклі прийняття рішень.
Поділіться ціллю, профілем руху, інтерфейсами, середовищем і кількістю пілотний проєкт. Ми можемо відобразити вимогу в датчику, FPGA і архітектурі локального комп’ютера.