×Закрыть

Експеримент із технологією доповненої реальності у вебі (front-end only)

Стаття написана у спiвавторстві з Мартою Дідич.

Якщо ви мали мінімальний досвід створення рекламних діджитал-кампаній, то, мабуть, знаєте, що сьогоднішню аудиторію, постійно спраглу нових відчуттів та вражень, складно зачепити контентом, що містить звичайні зображення, аудіо та відео. Саме тому, аби створити унікальний користувацький досвід за допомогою цифрових технологій, компанії все частіше вдаються до використання складних технологій, таких як 3D, віртуальна реальність (virtual reality — VR) та доповнена реальність (augmented reality — AR).

AR — це відносно універсальна технологія, яка поєднує реальність і цифрові дані, і дозволяє при цьому відображати різний тип контенту — зображення, 3D-моделі чи відео — поверх різноманітних маркерів, розміщених у фізичному середовищі.

Загалом, рекламні кампанії з використанням доповненої реальності бувають двох видів. Для створення першого використовують громіздке спеціалізоване обладнання, як, наприклад, у цьому кейсі з Pepsi Max:

Специфіка другого виду кампаній полягає у тому, що для занурення у доповнену реальність користувачі повинні інсталювати відповідний додаток на свій пристрій (ось як це зробили Vespa та Lexus):

Ви можете використати обидва способи, якщо ви — відомий бренд з мільйонами прихильників у всьому світі. Однак, якщо наразі ви — не надто відома компанія, то пересічний користувач навряд чи захоче інсталювати спеціальний додаток, щоби переглянути вашу рекламу, та й ви, скоріше за все, не будете готові витратити декілька мільйонів для створення спеціального обладнання.

Сьогодні все більше сервісів переходить на веб-технології, щоб користувачі могли відвідувати сайт з будь-яких пристроїв, не встановлюючи жодних додатків. Нам не вдалося знайти жодного рекламного проекту з доповненою реальністю, базованою у вебі, і тому ми вирішили самі поекспериментувати з цією технологією та перевірити, чи надається вона для широкого повноцінного використання вже сьогодні.

Концепція

Отже, нам йшлося про те, щоби знайти відповіді на такі запитання:
— Які можливості та обмеження має доповнена реальність у вебі?
— Чого ми можемо досягнути з нею, використовуючи підручні засоби?
— Чи може веб-додаток, створений на базі готових веб-бібліотек, конкурувати з оригінальними додатками з точки зору продуктивності?
— Чи готова ця технологія до комерційного використання на мобільних пристроях?

У ході проекту ми створили демо веб-додаток з доповненою реальністю і протестували його на декількох пристроях:

ПК Asus Transformer Pad TF103C (Планшет) LG Optimus L5 II E450 (Смартфон)
Windows 8 Android 5.0.1 Android 4.1
Браузер: Opera Браузер: Firefox Браузер: Firefox
CPU: Intel i5-3570 4×3.4 GHz CPU: 4×1.33 GHz CPU: 1* 1 GHz

Ми експериментували з маркерами доповненої реальності чотирьох типів:
— QR-код, інвертований QR-код;
— триколірна послідовність;
— зображення;
— гібридний маркер — зображення у чорній чотирикутній рамці.

Далі — детальніше про те, як ми проводити експеримент, і що отримали в результаті.

Трекання QR

Для створення доповненої реальності з QR-кодом у ролі маркера, ми використали js-aruco, ArUco-бібліотеку, портовану на JavaScript, що є подібним до OpenCV. Спершу, ми розробили просту демо-версію, щоби перевірити швидкодію, а тоді використали бібліотеку, щоби створити доповнену реальність з QR-кодами у ролі маркерів.

Демо-версія показала нам доволі добрі результати — в середньому 40 FPS (Frames Per Second) на комп’ютері, 8 FPS на планшеті і 6 FPS на телефоні. Js-aruco дозволив нам з легкістю визначати орієнтацію маркерів у просторі, отже як контент ми використовували статичні та анімаційні 3D-моделі, які рендерили за допомогою three.js.

Оскільки js-aruco швидко і точно знаходить чотирикутники, ми вирішили інвертувати QR-код так, щоби його легко можна було розпізнавати за зовнішнім чотирикутником:

Наш алгоритм розпізнавання був такий:
— Ми посортували усі знайдені чотирикутники — від найбільшого до найменшого. Спершу додаток знаходив найбільший чотирикутник — рамку довкола маркера. Всередині цього чотирикутника були розміщені три менші чотирикутники, з приблизно однаковою площею (в межах емпірично обраної допустимої похибки). Так ми пробували знайти обов’язкові чотирикутні елементи по кутах QR-коду;
— Тоді додаток мав визначити орієнтацію маркерів в межах розпізнаної рамки. Для цього ми обчислили кути трикутника, утвореного знайденими раніше трьома чотирикутниками. Вершину з найбільшим кутом ми обрали за верхній лівий кут маркера;
— Після того, як верхній лівий кут було знайдено, ми почали шукати вершину рамки, яка була би найближча до нього. Цю та інші знайдені точки зовнішнього чотирикутника використали для обчислення матриці повороту.

Нижче подано результати, які ми отримали під час тестування QR-маркера та під час тестування різного контенту доповненої реальності:

ПК Asus Transformer LG Optimus L5
QR35-60 FPS 7-15 FPS 1-4 FPS
QR + зображення 30-60 FPS 7-15 FPS 1-3 FPS
QR + відео 30-60 FPS 7-15 FPS 1-3 FPS
QR + 3d-модель 30-60 FPS 7-13 FPS 1-2 FPS

Ми також здійснили оптимізацію, що дозволило скоротити кількість обчислень та підвищити швидкодію: після того, як маркер знайдено, додаток запам’ятовує його розміщення та площу. У наступному кадрі, найбільший з розпізнаних чотирикутників порівнюється з площею та розміщенням маркера. Якщо вони збігаються (в межах заданої похибки), ми вважаємо, що цей чотирикутник і є попередньо знайденим маркером, і знову запам’ятовуємо його розміщення та площу. Якщо не збігаються — маркер вважається загубленим, і додаток повинен знову його шукати. Ми використали цей самий підхід і для гібридних маркерів.

Бібліотека tracking.js дає можливість досить швидко знаходити у відео елементи певних, наперед визначених кольорів. Ми вирішили використати цю властивість для створення маркера доповненої реальності. Проте одразу стало зрозуміло, що зробити маркером просто предмет певного кольору не вдасться, оскільки навколо нього можуть траплятись інші плями цього ж кольору, і передбачити чи контролювати це неможливо. Тоді ми вирішили шукати не певні кольори, а послідовності трьох кольорів.

В межах tracking.js знайдені кольорові плями описують чотирикутниками, в яких вони розміщені. Чотирикутник, у свою чергу, задається позицією верхнього лівого кута разом з його шириною і висотою. Цей чотирикутник також містить інформацію про колір.

Ми прийняли, що маркер — великий чотирикутник — це послідовність трьох чотирикутників потрібних кольорів, в яких виконуються такі умови:
1) відстань між першим і другим чотирикутниками менша, ніж діагональ першого;
2) відстань між другим і третім чотирикутниками менша, ніж діагональ другого;
3) відстань між першим і третім чотирикутниками більша, ніж діагональ першого.

Ми сформували послідовності з трьох контрастних кольорів (cyan, magenta та yellow), оскільки вони розпізнаються найкраще, хоча теоретично могли обрати будь-які інші. Наш маркер мав чотири точки (кути великого чотирикутника), кожна з яких позначалася окремою послідовністю кольорів. За координату точки, позначену послідовністю, ми прийняли центр середнього чотирикутника. Як тільки усі три точки було знайдено, вважалося, що маркер також знайдено, і таким чином відображався відповідний контент (у першому демо відео поверх маркера ми виводили за допомогою техніки «пришпилених кутів»).

Очевидно, що якість розпізнавання кольорів напряму залежить від якості вашої камери та освітлення. Якщо на десктопі пошук маркера відбувався доволі швидо (~24FPS), то на планшеті швидкодія помітно падала (до 3 FPS). Ми зрозуміли, що пошук кольорових маркерів відбувається значно повільніше, ніж пошук QR-маркерів. До того ж, кольорові маркери є доволі помітні, відповідно, вписати їх у навколишнє середовище значно складніше, що повністю нівелює їхні переваги над QR-маркерами.

Ось що ми отримали в результаті:

ПК Asus Transformer LG Optimus L5
Трекання, FPS 15-50 3-6 1-3

Демо-версію можна знайти в нашому гітхабі (run index.html).

Трекання зображення

Для трекання зображення ми використали алгоритми FAST і BRIEF, що були реалізовані в межах tracking.js. Ці алгоритми визначають унікальні точки та дескриптори на зображенні, які можна порівнювати із точками і дескрипотрами на іншому зображенні. Для того, щоб зменшити кількість помилкових пар, ми додали в алгоритм ще одну перевірку: додаток обирає послідовність точок, які утворюють полігон. Тоді, в обох зображеннях, сторони повертаються в одному напрямку. Якщо повороти збігаються — визначені точки вважаються правильними.

В оригінальних бібліотеках для пошуку маркерів використовують алгоритми подібні до SURF чи SIFT. Вони виконують значно більше обрахунків, проте є стійкими до шумів і розпізнають маркери, що обертаються та змінюються у розмірах. Проводити такі обчислення на JavaScript у real-time режимі практично неможливо, оскільки вони у 10-13 разів повільніші, ніж FAST чи BRIEF.

Ось результати, які ми отримали на різних пристроях, з одним і тим самим маркером:

ПК Asus Transformer LG Optimus L5
Пошук, FPS 50 4 2
Трекання, FPS 25-35 2-3 0-1

Використовуючи два маркери-зображення, ми помітили незначний спад швидкодії на ПК, в той час як результати на планшеті і смартфоні залишалися такими ж невтішними:

ПК Asus Transformer LG Optimus L5
Пошук, FPS 45 4 2
Трекання, FPS 10-25 2-3 0-1

Демо-версію можна знайти в нашому гітхабі (run index.html).

Трекання гібридних маркерів

Для цього виду маркерів ми вирішили об’єднати можливості js-aruco і tracking.js. Маркер складався з довільного зображення у чорній рамці. За допомогою tracking.js ми обчислили дескриптори для зображення, а рамку шукали використовуючи aruco-js. Обчислення дескрипторів вимагає багато обрахунків, відповідно, якщо проводити його у кожному кадрі, пошук маркерів відбуватиметься надто повільно. Щоб уникнути цього, ми вирішили спершу шукати рамку, а потім звіряти дескриптори зображення в рамці зі збереженими у базі дескрипторами для маркера. Якщо вони збігаються, додаток продовжує як маркер відслідковувати саму тільки рамку.

Тестуючи додаток, ми виявили, що, аби пошук дескриптора був ефективний, маркер повинен був займати усю площу екрана. Таким чином, не має значення — шукати дескриптор в межах чотирикутника маркера чи в межах усього кадру.

У результаті, демо з одним маркером працювало доволі швидко (30 FPS на десктопі), однак швидкодія суттєво падала (6 FPS на десктопі) під час обчислення дескрипторів. Тривалість порівняння дескрипторів залежала від того, скільки зображень порівнювалося. Навіть при 10 зображеннях порівняння відбувалось надто довго. З іншого боку — точність порівняння залишала бажати кращого. Оскільки для маркерів ми використовували скетчі, намальовані олівцем, під час порівняння алгоритм плутав зображення і неправильно визначав маркери.

Ось результати для одного гібридного маркера, отримані з різних пристроїв:

ПК Asus Transformer LG Optimus L5
Пошук чотирикутника, FPS 30-60 15 3
Пошук зображення, FPS 20 2-3 0-1
Трекання чотирикутника, FPS 45-60 15 3

Для двох гібридних маркерів, результати нашого експерименту були практично такі самі:

ПК Asus Transformer LG Optimus L5
Пошук чотирикутника, FPS 30-60 15 3
Пошук зображення, FPS 45-60 2-3 0-1
Трекання чотирикутника, FPS 45-60 15 3

Короткий (і дещо песимістичний) підсумок

Наше перше і головне враження — демо-версія безнадійно повільна. Веб-інструменти, які ми протестували, не здатні забезпечувати швидкодію, необхідну для життєздатності продукту. Але, незважаючи на це, ми і далі експериментуємо з технологіями доповненої реальності і сподіваємося, що в найближчому майбутньому зможемо створювати демо-продукти у вебі з доповненою реальністю, які будуть показувати пристойні результати.

LinkedIn

29 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

С другой стороны, как бы медленно не работало через браузер — устанавливать отдельное приложение дольше =)

Десь 5 років тому грамвся із AR за допомогою WebRTC, JSARToolKit.js та Three.js — відчуття були не дуже. Зараз ще є awe.js, але не доходять руки спробувати. Власне питання, чи ви тестували щось із цього, чи лише те що вказане у статті? І и одного прикладу вважаєте достатнім для того, щоб відкласти це на майбутнє?

чи ви тестували щось із цього
awe.js не пробували. Він так само як JSARToolKit і ARUco працює із квадратним маркером. По швидкодії, мабуть, так само як у статті.
І и одного прикладу вважаєте достатнім для того, щоб відкласти це на майбутнє?
Попробувати — варто, бо і браузери із js і hardware вагомо помінялися.
Щодо прикладу — головне потестувати на потрібних пристроях.
Доречі, вказаний смартфон LG є малопотужним, тому показники є низькими.
вказаний смартфон LG є малопотужним, тому показники є низькими.
Фраза из моего диплома :) у меня он был на тему AR

Движок Aspose вполне неплохо детектит QR в 3D

Ми зрозуміли, що пошук кольорових маркерів відбувається значно повільніше, ніж пошук QR-маркерів.
До кого-то дошло что поиск по одному каналу быстрее чем по трем. Так це ж Перемога. А если вы еще поищете такую тему как Color Quantization то поймете как там все интересно.
В оригінальних бібліотеках для пошуку маркерів використовують алгоритми подібні до SURF чи SIFT.
Откройте для себя OpenSurf Один из лучший для сопоставления изображений, хотя с меньшей точностью чем оригинальный.

Мабуть ви не повністю зрозуміли що стаття є про реалізацію доповненої реальності у Web (тільки front-end).
Aspose працює із Web ?
Ми використовували SURF із dlib. (конвертували C++ код у JavaScript). На Nexus5 було 2-10 FPS, і це тільки пошук точок і дескрипотрів. Потрібно їх порівнювати і рахувати матрицю повороту.

Aspose
это библиотеки на C#/Java. Если обработку данных вести на serverside, как работает тот же OK Google или Siri, то вполне. Хотя видеопоток, думаю будет забирать больший канал.

В их варианте можно гнать по каналу только фичи, а не весь поток.

Тогда посоветовал бы создать свой движок распознавания QR или лучше «Han Xin Code» с учетом технологии WebCL.

Зачем? Фичи на клиенте, на сервере распознавание.

Тогда смотрите мой ответ выше. Выделение фич это и есть 90% нагрузки на процессор для распознавания. Плюс для более точного распознавания нужно иметь доступ к самому изображению чтобы при провале текущих гипотез проводить их уточнение. Поэтому на сервер лучше кидать картинку как есть, а на клиент уже область баркода(quad) и его направление и пр.

Однопроходное распознавание или требует очень большой сложности выделения фич или обладает низкой устойчивостью к искажениям в канале данных. Небольшое размытие — и распознавание отвалилось. Хотя на стенде работать будет. Но это не стартап, а студенческая курсовая, которая на тестовых данных работает идеально, а реале просто не работает.

Это уже другое. Но всегда есть возможность часть работы скинуть на клиента.

Посчитайте сложность описка дескрипторов гауса с окном 15×15 на 5 Мпикс картинке, а там может быть и 13 Мпикс. А это база SURF. Конечно можно считить и вместо ядра гауса взять интегральное окно (summed area table) но все равно на JS это будет очень медленно.

Далее выделяются N самых мощных дескрипторов, тут можно использовать QSort, но лучше радиантную сортировку и далее сопоставление, что даёт N^2 дескрипторов для сравнения от которого никуда не уйти.

В общем на сервер картинку — на клиент данные. Будет быстрее всего. Картинку можно пожать вейвлетами (см Jpeg2000), они линейны по сложности.

Я пока в этой области слаб, но по опыту в другой знаю, что всегда можно часть работы отдать клиенту, а часть серверу.

Так клиенту еще мапить другую картинку на область баркода, а это 3D трансформация, которую правда можно сделать через WebGL. Хотя и саму предварительную картинку можно пожать через WebGL вейвлетами. Для распознавания можно использовать сжатие 1/30.

1) Під-час досліджень порахували що через мережу буде іти багато вхідного трафіку на сервер — приблизно 4 Мбіт/с на користувача (мінімум 15 fps, 640×480 відео, і компресію відео 0.1 [тут я не спеціаліст, загуглив, можливо 1/30 краще було б] ). Звичайно, що можна давати менше розширення, розумно (в потрібних місцях) стискати відеопотік, але і користувачів може бути не 10 а 500. Получилося дорогувато.

2) І час затримки не має бути більший за 0.067 секунди (15 FPS). Це: трансфер, обчислення і трансфер назад.

Ось спеціально тому і ще через азарт ми вирішили робити тільки на front-end-і. :)

Про WebCL ми не думали, але дякую за підказку ! :)
У наступній статті, мабуть, появиться WebCL і asm.js. :)

Можете попробовать WebGL, он есть почти во всех браузерах и алгоритмы можно адаптировать под него. Но это довольно сложно. Хотя поиск тех же дескрипторов Гауса для SURF просто чудесно будет реализовываться на WebGL.

Ця платформа підтримує AR у Web ?

Техническая статья на ДОУ, я был неготов! Но позже прочитаю, тема интересная

Цікава стаття, дякую:)

Я когда то занимался разработкой прожки, которая была бы путеводителем по университету. И в данной статье я мало представляю зачем это дело переносить в вэб.

Web версія для того щоб користувачам не доводилося встановлювати програму.
Так квидше, і не займає додаткового місця на смартфоні.

Говорят, браузер не самая быстрая среда выполнения.

Для того ми й досліджували, щоб взнати на скільки швидшими вони стали за останній час. :)

Просто їх легко трекати. Можна використати і інший контрастний квадрат. :)

Интересненько. Выходит, теперь надо попробовать подход с написанием собственного велосипеда. Спасибо :)

Подписаться на комментарии