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

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

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

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

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

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

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

Концепція

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

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

Ми експериментували з маркерами доповненої реальності чотирьох типів:
— 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-маркера та під час тестування різного контенту доповненої реальності:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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