WEB-ДОДАТОК ДЛЯ ОБРОБКИ ЗОБРАЖЕНЬ В РЕЖИМІ РЕАЛЬНОГО ЧАСУ

Єлсуков, Артем Дмитрович

Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал: https://er.chdtu.edu.ua/handle/ChSTU/9890

Назва:	WEB-ДОДАТОК ДЛЯ ОБРОБКИ ЗОБРАЖЕНЬ В РЕЖИМІ РЕАЛЬНОГО ЧАСУ
Автори:	Прокопенко , Валентин Андрійович Єлсуков, Артем Дмитрович
Ключові слова:	web-додаток;BullMQ (на базі Redis);обробка зображень в режимі реального часу;Node.js;сервер;дизайн;PostgreSQL;Prisma
Дата публікації:	11-чер-2026
Короткий огляд (реферат):	У кваліфікаційній роботі бакалавра розроблено Web-додаток для обробки зображень в режимі реального часу. В якості інструментів для розробки вибрано Node.js, PostgreSQL, Prisma та BullMQ (на базі Redis). Обсяг пояснювальної записки кваліфікаційної роботи бакалавра складає 91 сторінка, в тому числі вступ, 3 розділи, висновки, додаток та список використаних джерел. Робота містить 25 рисунків та 50 інформаційних джерел. Перший розділ кваліфікаційної роботи присвячений аналізу предметної області розробки web сервісів для обробки зображень у режимі реального часу. Досліджено структуру та технологічні можливості. Досліджено всі бізнес-процеси, що включають трансформацію через URLпараметри, сховище та дистрибуцію, монетизацію та білінг, аналітику. Другий розділ присвячений проєктуванню архітектури web-додатку для обробки зображень в режимі реального часу. Описано принципи створення web-додатку для обробки зображень в режимі реального часу. Розроблено базу даних системи, яка є реляційною. Створено діаграму моделі даних web-додатку для обробки зображень в режимі реального часу, а також ER-діаграму. У третьому розділі здійснено огляд інструментів розробки web-додатку для обробки зображень в режимі реального часу, визначено їх переваги і недоліки. Обґрунтовано вибір комплексу інструментальних засобів розробки. Описано процес розробки та інтерфейс web-додатку для обробки зображень в режимі реального часу.
URI (Уніфікований ідентифікатор ресурсу):	https://er.chdtu.edu.ua/handle/ChSTU/9890
Розташовується у зібраннях:	126 Інформаційні системи та технології (Web-технології, web-дизайн)

Файли цього матеріалу:

Файл	Опис	Розмір	Формат
РЕП_БАК_Єлсуков _WEB-2211.pdf Restricted Access		1.2 MB	Adobe PDF	Переглянути/Відкрити Запит копії

Показати повний опис матеріалу Перегляд статистики

Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет інформаційних технологій і систем
Кафедра інформаційних технологій проектування
ПОЯСНЮВАЛЬНА ЗАПИСКА
до кваліфікаційної роботи бакалавра
на тему:
«WEB-ДОДАТОК ДЛЯ ОБРОБКИ ЗОБРАЖЕНЬ В
РЕЖИМІ РЕАЛЬНОГО ЧАСУ»

Виконав студент групи WEB-2211,
спеціальності 126 –
Інформаційні системи та
технології,
освітня програма – Web-
технології Web-дизайн,
Єлсуков А.Д.
Керівник PhD, асист. Прокопенко В.А.
Рецензент Директор ТОВ «Андерсенлаб»
Алесін О.В.
Черкаси – 2026
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
Факультет Інформаційних Технологій і Систем_____________________________________
(повна назва)
Кафедра Інформаційних Технологій Проектування__________________________________
(повна назва)
Освітньо-кваліфікаційний рівень Бакалавр_________________________________________
(назва)
Спеціальність 126 – Інформаційні системи і технології_______________________________
(шифр і назва)
ЗАТВЕРДЖУЮ
Завідувач кафедри ІТП
___________ Тетяна ПРОКОПЕНКО
«_____» ______________20___ року
З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ БАКАЛАВРА
_____________________ Єлсуков Артем Дмитрович ____________________
(прізвище, ім’я, по батькові)
1. Тема роботи Web-додаток для обробки зображень в режимі реального часу ___________
Керівник роботи Прокопенко Валентин Андрійович, PhD доктор філософії______________
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
Затверджено наказом Черкаського державного технологічного університету від «_12_»
__березня_______ 2026 року N56/03-03________
2. Строк подання здобувачем роботи _____26.05.2026___________________________
3. Вихідні дані до роботи: Загальна інформація про об’єкт дослідження, інформація про
меоди та засоби розробки, структура БД, аналіз аналогів, базові технічні характеристики
розроблюваної системи.
4. Зміст розрахунково-пояснювальної записки (перелік питань, які потрібно розробити)
Вступ________________________________________________________________________
1. Опис предметної області. ___ ___________________________________________________
2. Аналіз існуючих аналогів._____________________________________________________
3.Постановка задачі _________________________________________________
4.Розробка архітектури web-додатку.__________________________________________
5. Розробка структури бази даних________________________________________________
6. Обґрунтування технології та засобів реалізації.___________________________________
7.Вибір засобів розробки.__________________________________________
8.Рзробка дизайну web -додатку ________
Висновки._____________________________________________________________________
Перелік джерел та посилань._____________________________________________________
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів)
Презентація кваліфікаційної роботи____________________________________
6. Консультанти розділів роботи
Прізвище, ініціали, та посада
Розділ Підпис, дата
консультанта
Завдання
Завдання прийняв
видав
7. Дата видачі завдання ______________________________________________
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ Назва етапів кваліфікаційної роботи Примітка
етапів роботи
1 Опис предметної області.
2 Аналіз існуючих аналогів
3 Постановка задачі
4 Розробка архітектури web-додатку.
5 Розробка структури бази даних
Обґрунтування технології та засобів
6 реалізації.
7 Вибір засобів розробки.
8 Застосування стеку технологій
9 Розробка дизайну web-додатку
10 Висновки
Здобувач вищої освіти _______________ Артем ЄЛСУКОВ
Керівник роботи _______________________ Валентин ПРОКОПЕНКО
SUMMARY
In the bachelor's qualification work, a web application for real-time image
processing was developed. Node.js, PostgreSQL, Prisma and BullMQ (based on
Redis) were selected as development tools.
The volume of the explanatory note of the bachelor's qualification work is 91
pages, including an introduction, 3 sections, conclusions, an appendix and a list of
sources used. The work contains 25 figures and 50 information sources.
The first section of the qualification work is devoted to the analysis of the
subject area of developing web services for real-time image processing. The
structure and technological capabilities are studied. All business processes are
studied, including transformation via URL parameters, storage and distribution,
monetization and billing, and analytics.
The second section is devoted to the design of the architecture of a web
application for real-time image processing. The principles of creating a web
application for real-time image processing are described. The system database is
developed, which is relational. A data model diagram of a web application for real-
time image processing, as well as an ER diagram, was created.
In the third section, a review of the tools for developing a web application for
real-time image processing was carried out, their advantages and disadvantages were
identified. The choice of a set of development tools was justified. The development
process and interface of a web application for real-time image processing were
described.
Keywords: web application, real-time image processing, Node.js, server,
design, PostgreSQL, Prisma and BullMQ (based on Redis).
АНОТАЦІЯ
У кваліфікаційній роботі бакалавра розроблено Web-додаток для
обробки зображень в режимі реального часу. В якості інструментів для
розробки вибрано Node.js, PostgreSQL, Prisma та BullMQ (на базі Redis).
Обсяг пояснювальної записки кваліфікаційної роботи бакалавра
складає 91 сторінка, в тому числі вступ, 3 розділи, висновки, додаток та список
використаних джерел. Робота містить 25 рисунків та 50 інформаційних
джерел.
Перший розділ кваліфікаційної роботи присвячений аналізу
предметної області розробки web сервісів для обробки зображень у режимі
реального часу. Досліджено структуру та технологічні можливості.
Досліджено всі бізнес-процеси, що включають трансформацію через URL-
параметри, сховище та дистрибуцію, монетизацію та білінг, аналітику.
Другий розділ присвячений проєктуванню архітектури web-додатку для
обробки зображень в режимі реального часу. Описано принципи створення
web-додатку для обробки зображень в режимі реального часу. Розроблено базу
даних системи, яка є реляційною. Створено діаграму моделі даних web-додатку
для обробки зображень в режимі реального часу, а також ER-діаграму.
У третьому розділі здійснено огляд інструментів розробки web-додатку
для обробки зображень в режимі реального часу, визначено їх переваги і
недоліки. Обґрунтовано вибір комплексу інструментальних засобів розробки.
Описано процес розробки та інтерфейс web-додатку для обробки зображень в
режимі реального часу.
Ключові слова: web-додаток, обробка зображень в режимі реального
часу, Node.js, сервер, дизайн, PostgreSQL, Prisma та BullMQ (на базі Redis).
ЗМІСТ
ВСТУП.............................................................................................................. 4
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ.............................................................7
1.1 Опис предметної області...........................................................................7
1.2 Постановка задачі.................................................................................... 13
1.3 Огляд та аналіз існуючих аналогів.........................................................20
1.3.1 Cloudinary...............................................................................................20
1.3.2 ImgixS3......................................................................................................
1.3.3 Cloudflare Images..................................................................................26
1.4 Висновки до розділу 1.............................................................................28
2 ПРОЄКТУВАННЯ WEB-ДОДАТКУ ДЛЯ ОБРОБКИ ЗОБРАЖЕНЬ В
РЕЖИМІ РЕАЛЬНОГО ЧАСУ.....................................................................29
2.1 Розробка архітектури системи................................................................29
2.2 Структура бази даних..............................................................................35
2.3 Принципи розробки бази даних.................................................................
2.4 Створення бази даних..............................................................................43
2.5 Висновки до розділу 2.............................................................................47
3 РОЗРОБКА ПРОГРАМНОЇ ЧАСТИНИ...................................................48
3.1 Вибір засобів розробки............................................................................48
3.1.2 Вибір способу доставки результату користувачеві...........................52
3.2 Дизайн web-додатку для обробки зображень в режимі реального часу
..........................................................................................................................56
3.3 Висновки до розділу 3.............................................................................64
ЧДТУ 211982.005 ПЗ
Зм. Лист № докумемента Підпис Дата
Розроб. Єлсуков А.Д. Літ. Лист Листів
Web--додаток для обробки
Перев. Прокопенко В.А. Н 2
зображень в режимі реального часу 91
Реценз ФІТІС,
Н. .контр. Прокопенко В.А. Пояснювальна записка
кафедра ІТП, Web-2211
Затв. Прокопенко Т.О.
ВИСНОВКИ................................................................................................... 65
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ......................................................67
ДОДАТОК A 482 ЧДТУ 21982-01 Проєктування та створення web-
додатку для обробки зображень в режимі реального часу.
Специфікація………………………………………………………………...71
Арк.
ЧДТУ 211982.005 ПЗ 3
Змн. Арк. № докум. Підпис Дата
ВСТУП
В основі будь-якого креативного процесу, підсиленого технологіями,
лежить безперервний пошук нових форм. Це не просто забаганка творця, а
природний закон: від еволюції природних фракталів до алгоритмів
генеративного мистецтва, все прагне до ускладнення та досконалості. Для митця
в епоху Digital розвиток стає головним інструментом самовираження. Саме
експерименти з новими інструментами — від графічних планшетів до
нейромереж — наповнюють творчість сенсом. Без опанування нових медіа та
технік творчий потенціал згасає, перетворюючись на тиражування застарілих
шаблонів. Життя в мистецтві без постійного оновлення інструментарію
неможливе. Навіть для того, щоб зберігати впізнаваний авторський стиль у
мінливому цифровому просторі, потрібно постійно вдосконалювати технічний
стек. Оскільки програмне забезпечення (ПЗ) оновлюється, а візуальна мова
користувачів трансформується, автор повинен адаптуватися. У цьому контексті
технологічна адаптація — це і є найвищий прояв творчого розвитку, що
дозволяє ідеї залишатися живою та актуальною.
Тенденції розвитку сучасних інформаційних технологій та засобів
обробки зображень виглядає як перехід від простих фільтрів до комплексних
екосистем, що базуються на штучному інтелекті та великих даних. Ефективна
реалізація життєвого циклу розробки сучасного web-додатку детермінована
якістю попереднього системного аналізу та формалізації вимог [1].
Фундаментальною умовою створення життєздатного програмного продукту є
побудова адекватних моделей, що релевантно відображають архітектурні та
операційні особливості, серед яких створення повної та несуперечливої
функціональної моделі, що дозволяє верифікувати алгоритми обробки даних
(зокрема, графічного контенту) та мінімізувати ризики виникнення логічних
колізій на етапі імплементації коду. Інформаційне моделювання полягає у
формалізації структури даних, визначенні сутностей та встановленні стійких
зв'язків між ними. Використання нормалізованих інформаційних моделей
Арк.
ЧДТУ 211982.005 ПЗ 4
Змн. Арк. № докум. Підпис Дата
забезпечує цілісність даних та оптимізацію доступу до об’єктів системи в
умовах високого навантаження web-середовища.
Накопичений нині досвід розробки web-додатків свідчить про те, що цей
процес є інтелектуально місткою та багаторівневою інженерною дисципліною.
Висока складність сучасних систем детермінує характеристики процесу, що
пов’язані з когнітивною та логічною складністю. Проектування архітектури, яка
має забезпечувати одночасну масштабованість, безпеку та високу
продуктивність (High Load), вимагає глибокого системного мислення. Кожне
архітектурне рішення на старті критично впливає на життєздатність продукту в
майбутньому. Створення валідних функціональних та інформаційних моделей
— це не лінійний запис коду, а тривалий процес ітерацій, тестування гіпотез та
верифікації бізнес-логіки. Реалізація таких проектів потребує залучення
вузькоспеціалізованих експертів (Architects, DevOps, Full-stack developers, UI/UX
designers), здатних інтегрувати розрізнені компоненти у цілісну екосистему.
Для користувача якісне проєктування та складна архітектура Web-
додатку для обробки зображень трансформуються з абстрактних схем у
конкретний споживчий досвід (UX). Тому важливого значення набуває робота
з візуальним контентом, коли затримка навіть у пів секунди руйнує творчий
процес. Правильно спроєктована система забезпечує реактивність: користувач
рухає повзунок корекції кольору і бачить результат миттєво. Це створює
відчуття прямого маніпулювання зображенням, а не очікування відповіді від
сервера.
Якісна інформаційна модель гарантує, що при раптовому обриві зв'язку
або збоїв браузера творча робота не зникне. Для користувача важливого
значення набуває можливість автоматичного збереження ітерацій (History), а
також скасувати будь-яку дію (Undo/Redo) без втрати якості вихідного файлу
(Non-destructive editing). Можливість впровадження в додаток «розумних»
функцій економить час користувача та дозволяє автоматичне виділення об'єктів
одним кліком. Продумана архітектура гарантує, що приватні фотографії
Арк.
ЧДТУ 211982.005 ПЗ 5
Змн. Арк. № докум. Підпис Дата
користувача обробляються безпечно. Використання технологій на кшталт Client-
side processing (обробка прямо в браузері без завантаження на сервер) підвищує
рівень довіри, оскільки дані фізично не залишають пристрій власника.
Тому розробка web-додатку для обробки зображень в режимі реального
часу, що дозволяє користувачеві редагувати фото «тут і зараз», без завантаження
та інсталяції громіздкого десктопного ПЗ, є дуже важливою і актуальною
задачею. Цей програмний продукт сприяє користувачеві почати ретуш на
смартфоні в дорозі, а завершити на потужному ПК у браузері, маючи миттєвий
доступ до результатів.
Метою роботи є проєктування та розробка web-додатку для обробки
зображень в режимі реального часу, що надасть можливість користувачам
здійснювати складну корекцію та стилізацію візуального контенту
безпосередньо у браузері з миттєвим відгуком, незалежно від апаратної
потужності їхніх пристроїв.
Для досягнення мети роботи необхідно розв’язати наступні задачі:
 дослідити та проаналізувати web-додатки, які поєднують професійну
функціональність десктопних редакторів із гнучкістю та доступністю хмарних
технологій. Порівняти їх функціональність та визначити переваги та недоліки;
 розробити специфікацію вимог до майбутнього web-додатку;
 розробити архітектуру web-додатку та структуру бази даних;
 здійснити вибір мови програмування та технологій для програмної
реалізації web-додатку;
 розробити web-додаток для обробки зображень в режимі реального
часу відповідно до умов, перелічених в попередніх пунктах.
Об’єктом дослідження є процес розробки web-додатку для обробки
зображень в режимі реального часу.
Предметом дослідження є застосування сучасних інформаційних
технологій для розробки програмного продукту, який забезпечуватиме
можливість обробки зображень в режимі реального часу.
Арк.
ЧДТУ 211982.005 ПЗ 6
Змн. Арк. № докум. Підпис Дата
1 АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ
1.1 Опис предметної області
Еволюція засобів фіксації та обробки зображень складає тривалий
процес, що складається з ключових етапів, кожен з яких радикально
прискорював передачу інформації. Тисячоліттями зображення створювалися
вручну (наскельні малюнки, живопис). Першим проривом стала хімічна
фіксація світла в XIX столітті, що дозволило отримувати документальне
відображення реальності, але процес був складним, а результат — одиничним.
Поява гнучкої плівки та компактних камер зробила фотографію доступною.
Винахід Polaroid став першим кроком до «режиму реального часу», скоротивши
час між зйомкою та отриманням результату до декількох хвилин. Перехід від
хімічних процесів до напівпровідникових сенсорів (CCD/CMOS) перетворив
світло на код. Зображення стало набором даних, що відкрило шлях до
миттєвого копіювання та перших спроб цифрової ретуші.
Сьогодні фотографія — це не просто фіксація світла, а продукт роботи
алгоритмів. Смартфони та web-додатки обробляють мільйони пікселів у
реальному часі, використовуючи нейромережі для покращення якості, що
робить процес творчості безперервним та інтерактивним. Наступним кроком є
вихід за межі 2D-площини — перехід до голограм та світлових полів, де
зображення можна буде обійти навколо, а редагування відбуватиметься у
тривимірному просторі.
Сучасні редактори (як Adobe Photoshop чи інструменти Topaz) перестали
бути просто набором пензлів. Сьогодні це складні нейромережеві моделі, які
вміють «дофантазовувати» відсутні пікселі (Generative Fill), змінювати
освітлення об’єктів у 3D-просторі або автоматично відокремлювати складні
структури (волосся, скло, дим) одним кліком. Складність обробки зросла
настільки, що локальних ресурсів пристрою (особливо мобільних) часто
недостатньо. Це призвело до створення гібридних систем, де частина операцій
Арк.
ЧДТУ 211982.005 ПЗ 7
Змн. Арк. № докум. Підпис Дата
виконується на сервері, а користувач отримує лише фінальний результат у
реальному часі[2].
Сучасні ІС для фото обробляють не лише колір пікселя, а й глибину
сцени (Depth Map), динамічний діапазон (HDR) та метадані сенсорів. Камера
смартфона — це вже не оптика, а складна інформаційна система, яка робить
десятки знімків за мілісекунду та об'єднує їх у один ідеальний кадр. Для
професійної обробки великих масивів фото (наприклад, у e-commerce)
створюються цілі конвеєри, де алгоритми самостійно роблять кольорокорекцію,
видаляють фон та готують зображення під різні формати без участі людини.
Соціальні мережі стали головним каталізатором переходу обробки фото
у Web-площину, оскільки вони докорінно змінили життєвий цикл зображення.
Скорочення дистанції «Створення — Публікація» є вагомим аргументом. У
світі Instagram, TikTok та мобільних маркетплейсів час став критичним
ресурсом. Web-додатки дозволяють редагувати фото в тому ж середовищі, де
воно буде опубліковане, усуваючи зайві кроки експорту та пересилання файлів
між пристроями[3].
Формування культури «Миттєвого покращення» сприяє просуванню
контенту. Соціальні платформи впровадили моду на фільтри та AR-маски в
режимі реального часу. Це сформувало запит мільйонів користувачів на складні
алгоритми ретуші, які мають спрацьовувати за частки секунди прямо в браузері
чи мобільному клієнті.
Хмарна спільна робота (Collaboration) забезпечує можливості інтеграції.
Соціальний аспект стимулював розвиток Web-інструментів, де декілька
користувачів можуть одночасно працювати над проєктом. Браузер перетворився
на динамічне робоче середовище, доступне з будь-якого акаунта, що неможливо
реалізувати в класичному локальному ПЗ.
Економіка уваги є важливим аспектом. Щоб утримувати користувача,
платформи інтегрують редактори безпосередньо у свій інтерфейс. Це зробило
Арк.
ЧДТУ 211982.005 ПЗ 8
Змн. Арк. № докум. Підпис Дата
розробку високопродуктивних Web-додатків пріоритетом, адже будь-яка
технічна затримка (лага) призводить до втрати аудиторії.
Таким чином, соціальні мережі перетворили фотографію з «архівного
документа» на засіб живої комунікації, що вимагає максимально швидких,
хмарних та інтелектуальних інструментів обробки.
Основними категоріями існуючих web-додатків для обробки зображень,
які демонструють різні підходи до реалізації реал-тайм технологій є наступні[4]:
1. Професійні графічні редактори (Web-based):
- Photopea. Найближчий аналог Photoshop у браузері. Підтримує
шари, маски та складні інструменти ретуші. Працює переважно на
ресурсах клієнта (JavaScript), що робить його автономним, але
вимогливим до пам'яті.
- Adobe Photoshop (Web version). Хмарна адаптація легендарного
софту. Використовує технологію WebAssembly для досягнення
продуктивності, близької до десктопної, та інтегрує генеративний
ШІ (Adobe Firefly) для обробки в реальному часі.
2. Платформи з акцентом на ШІ та автоматизацію:
- Canva. Орієнтована на швидке створення дизайну. Використовує
складні хмарні алгоритми для миттєвого видалення фону,
покращення якості зображень та автопідбору композиції.
- Pixlr (X/E). Набір інструментів, що використовує GPU-
прискорення браузера для плавного накладання фільтрів та ефектів
у реальному часі.
3. Спеціалізовані AI-сервіси (Generative & Enhancement):
- ClipDrop (by Stability AI). Демонструє майбутнє еволюції —
миттєве видалення об'єктів, переосвітлення (Relight) та генерація
частин зображення за допомогою нейромереж безпосередньо у
вікні перегляду.
Арк.
ЧДТУ 211982.005 ПЗ 9
Змн. Арк. № докум. Підпис Дата
- Remove.bg. Вузькоспеціалізований, але технологічно досконалий
сервіс, що фокусується на одній операції в реальному часі за
допомогою комп'ютерного зору.
4. Розважальні та AR-платформи:
- Snapchat Camera Kit (Web). Дозволяє інтегрувати AR-лінзи та
складні маски прямо у вебсторінки, обробляючи відеопотік з
камери користувача в реальному часі за допомогою складних
математичних моделей.
Таким чином існують сервіси, однак більшість із них є або занадто
складними для пересічного користувача (як Photopea), або занадто закритими та
комерційними. Тому запропонований web-додаток для обробки зображень в
режимі реального часу може заповнити нішу швидкого, інтелектуального та
доступного інструменту, що фокусується на специфічних потребах (наприклад,
пакетна обробка для соцмереж або унікальні художні фільтри).
Для розробки високонавантаженого Web-додатка з обробкою зображень
у реальному часі вибір між React та Vue (або іншими фреймворками) визначає
не стільки швидкість піксельних обчислень, скільки стабільність інтерфейсу під
навантаженням. В табл. 1.1 наведено порівняння застосовуваних підходів при
розробці подібних додатків.
Таблиця 1.1.
Порівняння технічних підходів
Критерій React (Шлях лідерів: Adobe, Canva) Vue (Шлях гнучкості: Photopea-
style)
Архітектура Компонентно-орієнтована, Реактивна система зв'язків.
односторонній потік даних. Ідеально Легша у вивченні та швидша
для складних станів (історія змін, для прототипування інтерфейсу.
шари).
Екосистема Величезна кількість бібліотек для Менша кількість готових
роботи з WebGL та WebGPU (напр., "обгорток" для низькорівневої
react-three-fiber). графіки, але висока швидкість
рендерингу UI.
Продуктивність Virtual DOM може бути "вузьким Більш ефективне відстеження
місцем" при частому оновленні (60 залежностей "з коробки", що
FPS), потребує оптимізації корисно для динамічних
Арк.
ЧДТУ 211982.005 ПЗ 10
Змн. Арк. № докум. Підпис Дата
(Memoization). повзунків фільтрів.
Ключовий технологічний стек, що застосовують розробники для
досягнення справжнього Real-time, базується на гібридній моделі [5]:
- Core Engine (Ядро), де WebAssembly (C++/Rust) є основною
математикою обробки пікселів та виноситься до ядра. Це дозволяє
досягти швидкості десктопного додатка в браузері;
- GPU Acceleration, де WebGL 2.0 або WebGPU для миттєвого
накладання фільтрів та шейдерів безпосередньо через відеокарту
користувача;
- State Management, де Redux або Pinia для зберігання "дерева
операцій" та забезпечення функцій Undo/Redo без
перезавантаження всього зображення;
- Worker Threads (Web Workers) щоб важкі обчислення не "фрізили"
інтерфейс користувача (UI thread).
Для об'єктивного вибору архітектурного рішення розробки Web-додатку
для обробки зображень в режимі реального часу, варто проаналізувати сильні та
слабкі сторони аналогічних розробок, що допоможе зрозуміти можливі
переваги та недоліка (табл. 1.2).
Таблиця 1.2.
Порівняльний аналіз існуючих рішень
Сервіс Переваги (Strengths) Недоліки (Weaknesses)
Photopea Максимальний функціонал: Повна Перевантажений інтерфейс:
заміна Photoshop у браузері. Складний для новачків.
Підтримка форматів .PSD, .RAW. Продуктивність: При роботі з
Автономність: Працює локально на великими файлами (>50MB)
клієнті. браузер може споживати
гігабайти оперативної пам'яті.
Adobe Екосистема: Синхронізація з Creative Висока ціна: Доступний лише за
Photoshop (Web) Cloud. AI-інтеграція: Найкращі на передплатою. Залежність від
ринку інструменти генеративного мережі: Більшість складних AI-
заповнення. Стабільність: операцій виконуються на
Оптимізовано через WebAssembly. серверах Adobe, що створює
затримку (latency).
Canva Простота (UX): Ідеальний поріг Обмеженість: Не підходить для
входження. Швидкість: Величезна піксельної ретуші чи глибокої
бібліотека шаблонів та миттєва художньої обробки. Користувач
Арк.
ЧДТУ 211982.005 ПЗ 11
Змн. Арк. № докум. Підпис Дата
пакетна обробка. обмежений жорсткими рамками
інструментів.
Pixlr Доступність: Швидкий запуск, Агресивна реклама: У
багато безкоштовних фільтрів. безкоштовній версії заважає
Апаратне прискорення: Добре роботі. Обмеження по шарах:
використовує GPU браузера для Складні композиції можуть
візуальних ефектів. працювати нестабільно.
ClipDrop Інноваційність: Унікальні функції Вузька спеціалізація: Це набір
(Relight, Cleanup) на базі окремих інструментів, а не
нейромереж. Швидкість AI: Дуже цілісний редактор. Часто
швидка сегментація об'єктів. потребує вивантаження
результату для подальшої
роботи.
Розробка та впровадження спеціалізованого web-додатка для обробки
зображень у режимі реального часу забезпечують користувачам наступні
стратегічні переваги:
- висока мобільність та доступність (Anywhere, Any Device).
Користувач отримує професійний інструментарій без прив'язки до
конкретного робочого місця чи операційної системи. Робота з
контентом можлива з будь-якого пристрою, що має сучасний
браузер.
- відсутність бар'єру інсталяції (Zero Install). Виключається
необхідність завантаження важких дистрибутивів, складного
налаштування середовища та постійного ручного оновлення ПЗ.
Користувач завжди працює з актуальною версією продукту.
- інтелектуальна швидкість (Real-time Efficiency). Завдяки
використанню WebAssembly та GPU-прискорення, складні
операції (ретуш, стилізація, сегментація) відбуваються миттєво. Це
зберігає «стан потоку» творця, де результат візуалізується швидше,
ніж встигає з'явитися затримка.
- економічна вигідність. Користувачеві не потрібно інвестувати у
дороге апаратне забезпечення (high-end відеокарти чи об’ємну
RAM), оскільки значна частина ресурсномістких обчислень може
бути оптимізована або винесена у хмару.
Арк.
ЧДТУ 211982.005 ПЗ 12
Змн. Арк. № докум. Підпис Дата
- безшовна інтеграція з екосистемою Web. Можливість миттєвого
імпорту зображень із хмарних сховищ, соцмереж або веб-камер, а
також швидка публікація результату в один клік, що критично для
сучасного темпу цифрової комунікації.
- безпека та конфіденційність. Сучасні стандарти дозволяють
обробляти конфіденційні фото прямо в пам'яті браузера (Client-
side), без фактичного завантаження файлів на сервер, що гарантує
високий рівень приватності.
Таким чином, використання такого додатка перетворює складну
технологічну процедуру на інтуїтивний сервіс, адаптований до
експоненціального зростання запитів сучасного ринку.
1.2 Постановка задачі
Web-додаток для обробки зображень у режимі реального часу забезпечує
можливості редагування, видалення фону та накладання AI-фільтрів. Основними
бізнес-процесами web-додатка для обробки зображень у режимі реального часу
є наступні:
1. Завантаження та попередня обробка, коли система готує файл до
роботи. Включає:
- валідацію, тобто перевірка формату (JPG, PNG, WebP) та розміру
файлу;
- створення прев’ю, що передбачає генерацію легкої копії для
швидкого відображення в інтерфейсі, поки оригінал чекає на важку
обробку;
- черга повідомлень, якщо навантаження високе, зображення
ставиться в чергу (наприклад, через RabbitMQ або Kafka) для
передачі обробнику.
2. Ядро обробки (Processing Pipeline), де відбуваються самі маніпуляції.
Забезпечує:
Арк.
ЧДТУ 211982.005 ПЗ 13
Змн. Арк. № докум. Підпис Дата
- застосування фільтрів/алгоритмів, що передбачає безпосередню
роботу коду (OpenCV, Pillow) або AI-моделей (TensorFlow,
PyTorch);
- паралелізація, тобто розбиття складних завдань на потоки або
використання GPU для миттєвого результату;
- зворотний зв'язок (WebSocket), що забезпечує передач статусу
обробки клієнту в реальному часі (наприклад, прогрес-бар
"Обробка 45%").
3. Зберігання та дистрибуція (Storage & CDN), що передбачає зберігання
результату:
- тимчасове зберігання шляхом кешування результатів у Redis для
швидкого доступу;
- хмарне зберігання, тобто вивантаження фінальних файлів у S3-
сховище.
- CDN, що передбачає видачу зображення користувачу через
найближчий сервер для мінімальної затримки.
4. Монетизація та ліміти (Billing), тобто процес, що перетворює трафік на
гроші:
- перевірка квот, тобто контроль кількості оброблених зображень
згідно з тарифним планом;
- додавання водяних знаків шляхом автоматичного накладання
логотипа для безкоштовних версій;
- обробка платежів через підключення Stripe або PayPal для
розблокування Pro-функцій.
5. Аналітика та покращення забезпечує:
- логування помилок, тобто відстеження збоїв при обробці
специфічних форматів;
- A/B тестування на основі порівняння швидкості роботи різних
алгоритмів обробки.
Арк.
ЧДТУ 211982.005 ПЗ 14
Змн. Арк. № докум. Підпис Дата
Схематично презентацію роботи web-додатка для обробки зображень у
режимі реального часу на основі виділених бізнес-процесів представлено на
рис. 1.1.
Процес роботи з web-
додатком
Валідація Processing Pipeline Storage & CDN
Billing Аналітика
Рисунок 1.1 – Діаграма бізнес-процесів web-додатка для обробки
зображень у режимі реального часу
Користувач взаємодіє з додатком через простий і швидкий цикл дій.
Оскільки це сервіс реального часу, головний акцент зроблено на миттєвих
зворотних діях та простоті інтерфейсу. Користувач ходить через Google/Apple
або використовує гостьовий режим (якщо дозволяють ліміти). Обирає конкретну
функцію (наприклад, «Видалити фон», «Покращити якість» або «Стилізувати під
картину»). Перетягує файл прямо у вікно браузера або вставляє
посилання/картинку з буфера обміну. Бачить прев’ю зображення ще до
завершення обробки. Налаштування передбачає рух повзунки (яскравість,
інтенсивність фільтра) або обирає пресети. Виділяє пензлем об'єкт, який треба
змінити або залишити. В режимі порівняння затискає кнопку «Before/After», щоб
оцінити зміни в реальному часі. Моніторинг прогресу реалізується на основі
спостереження за анімованим прогрес-баром або «скануючою лінією» поверх
Арк.
ЧДТУ 211982.005 ПЗ 15
Змн. Арк. № докум. Підпис Дата
фото. Може скасувати процес, якщо бачить, що результат на перших етапах його
не влаштовує. Фінальний огляд передбачає перегляд результатів у високій
роздільній здатності. Вибір формату реалізується через потрібний тип файлу
(PNG, JPG, WebP) та ступінь стиснення. Зберігає файл на пристрій, відправляє в
хмару (Google Drive/Dropbox) або генерує посилання для соцмереж. Також
користувач може переглядати свої попередні роботи в особистому кабінеті, а
також може відкрити старий проєкт і змінити параметри обробки без повторного
завантаження оригіналу.
На основі рис. 1.1 розбиття на окремі бізнес-процеси дозволяє чітко
розмежувати відповідальність компонентів (мікросервісна логіка). Такий підхід
значно полегшує проектування, масштабування та підтримку web-додатка для
обробки зображень у режимі реального часу. Для реалізації процесу
«Завантаження та попередня обробка» (Ingestion & Pre-processing) варто
використовувати конвеєрну схему, представлено на рисунку 1.2. Це дозволяє
паралельно обробляти кадри, не блокуючи вхідний потік.
Stream Capture Validate Transfor Buffer
m
Core AI
Рисунок 1.2 – Схема функцій процесу завантаження та попередньої
обробки
В процесі функціонування модуль вхідного інтерфейсу (Receiver)
забезпечує встановлення з’єднання (WebSocket/WebRTC). Потім реалізується
захоплення окремого кадру з потоку. Далі здійснюється валідація MIME-типу та
заголовків.
Модуль безпеки та фільтрації (Gatekeeper) реалізує перевірку токена
доступу користувача, контроль кількості кадрів за секунду (FPS), щоб уникнути
перевантаження, а також перевірку роздільної здатності та ваги кадру
Арк.
ЧДТУ 211982.005 ПЗ 16
Змн. Арк. № докум. Підпис Дата
(відсікання занадто великих зображень). Модуль трансформації (Transformer)
здійснює перетворення (наприклад, з YUV або RGBA у RGB/Grayscale),
приведення до вхідного розміру нейронної мережі (наприклад, 640x640), базове
очищення (гауссове розмиття або медіанний фільтр). приведення значень
пікселів до діапазону [0, 1] або [-1, 1]. Модуль черги та диспетчеризації
відповідає за тимчасове зберігання кадру в оперативній пам'яті (Redis/Shared
Memory) та передачу підготовленого тензора (масиву даних) до модуля
основного процесингу (AI Inference).
Processing Pipeline реалізується на основі наступних процесів (рис.1.3).
Multi- OpenCV/ WebSocket
Orchestrator processin AI Progress
g
Рисунок 1.3 – Схема функцій Processing Pipeline.
Характеристики бізнес-процесу Storage & CDN Web-додатку для обробки
зображень у реальному часі забезпечують можливість мінімальної затримки
(latency) та високу швидкість віддачі контенту. До них відносяться[6]:
1. Характеристики Зберігання (Storage):
- тип сховища, де найчастіше використовуються об'єктні сховища
(наприклад, AWS S3, Google Cloud Storage), які дозволяють
зберігати величезні масиви медіафайлів;
- масштабованість, що характеризує здатність автоматично
розширюватися при збільшенні кількості оброблених зображень без
втрати продуктивності;
- життєвий цикл даних (Lifecycle Management) для автоматичного
видалення тимчасових результатів або перенесення старих
зображень у «холодні» (дешевші) архіви;
Арк.
ЧДТУ 211982.005 ПЗ 17
Змн. Арк. № докум. Підпис Дата
- висока доступність, тобто дублювання даних у різних зонах
доступності для запобігання втраті результатів роботи.
2. Характеристики Дистрибуції (CDN):
- кешування на межі (Edge Caching), тобто зберігання копій
оброблених зображень на серверах, що географічно найближчі до
користувача. Це критично для «реального часу»;
- динамічна оптимізація, що забезпечується сучасними CDN, які
можуть змінювати формат зображення (наприклад, з PNG у WebP)
залежно від браузера користувача;
- інвалідація кешу, що представляє механізм швидкого оновлення
зображення в мережі CDN, якщо користувач повторно відредагував
той самий файл;
- захист (Security) для використання підписаних посилань (Signed
URLs) для обмеження доступу до приватних результатів обробки.
3. Специфіка для обробки зображень:
- параметризація запитів, що забезпечує можливість передавати
параметри обробки прямо в URL (наприклад, image.jpg?
width=300&filter=blur), де CDN або інтегрований сервіс обробляє та
кешує результат;
- пропускна здатність, що характеризується високою швидкістю
передачі даних (Throughput) для швидкого завантаження «важких»
оригіналів у чергу обробки.
Монетизація та ліміти (Billing) відповідає за фінансову стійкість сервісу
та контроль витрат на інфраструктуру. Аналітика та покращення є процесом
збору даних для технічної оптимізації та розуміння потреб користувачів.
Характеристики web-додатку для обробки зображень у режимі реального
часу є наступні:
Назва додатку: “Clear Photos”.
Арк.
ЧДТУ 211982.005 ПЗ 18
Змн. Арк. № докум. Підпис Дата
Пристрої та платформи. За рахунок того, що додаток має працювати у
режимі реального часу та режимі фото чи відеозйомки, обрано найпоширеніші
пристрої з такими апаратними можливостями, а також з урахуванням зручності
програмної реалізації додатку. Такими пристроями є смартфони та планшети на
платформах Android та iOS, які і обрано для розробки мобільного додатку.
Системні вимоги. Для стабільної роботи додатку потрібен пристрій, що
відповідає вищезгаданим умовам, а також має підтримку функції доповненої
реальності.
Доповнена реальність (AR) - це уявлення про реальний, фізичний світ, в
якому користувачі знаходять елементи, покращені за допомогою комп'ютерного
введення. Дизайнери створюють вміст, починаючи від звуку до відео, від графіки
до міток GPS і багато іншого, в цифровому вмісті, який реагує в режимі
реального часу на зміни в середовищі користувача, як правило, на рух.
Функціонал. Основною задачею розроблюваного мобільного додатку є
заміщення реклами у режимі фото фото- та відео зйомки. Тобто основою даного
додатку є простий функціонал камери. Також додаток має надбудову, що працює
на технології доповненої реальності.
Алгоритм роботи додатку:
1) вмикається режим фото- чи відеозйомки;
2) знайдену рекламу додаток заміщує, на зображення, що відповідають
налаштуванням користувача;
3) після завершення фото- чи відеозйомки файл зберігається у
внутрішню пам’ять пристрою.
1.3 Огляд та аналіз існуючих аналогів
Аналіз існуючих рішень для обробки зображень у режимі реального часу
показує поділ ринку на три основні категорії: комплексні медіа-платформи,
швидкі CDN-трансформатори та хмарні інфраструктурні рішення. При цьому
досліджено наступні сервіси для обробки зображень: Cloudinary, що
характеризується повним контролем та інтелектом, Imgix, що має архів фото в
Арк.
ЧДТУ 211982.005 ПЗ 19
Змн. Арк. № докум. Підпис Дата
хмарі, Cloudflare Images— мінімальна ціна та швидка доставка базових фото.
Досліджені системи (Cloudinary, Imgix та Cloudflare Images) забезпечують
підтримку наступних ключових можливостей [7]:
1. Технічні формати та стандарти;
2. Маніпуляції в режимі реального часу;
3. Оптимізація та доставка;
4. Безпека та контроль.
Cloudinary, Imgix та Cloudflare Images, можна визначити як лідерів ринку
Image-as-a-Service, кожен з яких закриває конкретну бізнес-потребу. Всі три
системи об'єднує концепція обробки в реальному часі. Детально опис
досліджених існуючих рішень для обробки зображень у режимі реального часу
розглянуто нижче.
1.3.1 Cloudinary
Cloudinary є комплексною медіа-платформою від компанії Cloudinary
[33]. Найбільш потужний аналог, що охоплює повний життєвий цикл
зображення та забезпечує можливості редагування як фото, так і відео(рис. 1.4).
Арк.
ЧДТУ 211982.005 ПЗ 20
Змн. Арк. № докум. Підпис Дата
Рисунок 1.4 – Інтерфейс Cloudinary.
Головною особливістю Cloudinary є використовує ШІ для розумного
обрізання (face detection), автоматичного вибору формату (f_auto) та якості
(q_auto). Зберігання та дистрибуція реалізується на основі власного
інтегрованого сховища та глобальної мережі CDN. Billing реалізується на основі
складної системи кредитів, де оплата залежить від комбінації трансформацій,
обсягу зберігання та трафіку. Перевагою даного продукту є максимальний набір
функцій (видалення фону, накладання водяних знаків, робота з відео).
Недоліком є висока вартість при великих обсягах даних. Сферами застосування
є E-commerce, що передбачає автогенерацію прев'ю товарів під різні сітки сайту,
а також новинні портали, де необхідно швидка адаптація фото з місця подій під
мобільні додатки та десктоп.
Для користувачів (розробників, контент-менеджерів та кінцевих
споживачів) Cloudinary забезпечує повний набір інструментів для роботи з медіа
«під ключ». Основні можливості Cloudinary представимо за напрямками:
1. Для розробників (Автоматизація):
- трансформація через URL, тобто зміна розміру, обрізання, поворот
або застосування фільтрів просто через додавання параметрів у
посилання на зображення;
- авто-форматування (f_auto), що забезпечує користувачу можливість
отримати найсучасніший формат (WebP, AVIF), який підтримує
його браузер, що економить до 80% трафіку;
- стиснення (q_auto), тобто автоматичне зменшення ваги файлу без
візуальної втрати якості;
- SDK для всіх мов на основі бібліотек для JavaScript, Python, PHP,
Ruby, Java, Go та мобільних платформ (iOS/Android).
2. Для контент-менеджерів (Керування) передбачається:
Арк.
ЧДТУ 211982.005 ПЗ 21
Змн. Арк. № докум. Підпис Дата
- медіа-бібліотека (DAM) на основі зручного інтерфейсу для
завантаження, пошуку та впорядкування тисяч файлів за тегами або
папками;
- розумне обрізання (AI Cropping), коли система автоматично
фокусується на обличчі або важливому об'єкті, щоб при створенні
прев'ю головне не «випало» з кадру;
- водяні знаки та шари, зо забезпечує можливість автоматично
накладати логотип компанії або текст поверх будь-якого
завантаженого фото;
- видалення фону, тобто вбудований інструмент на базі ШІ, який
прибирає фон одним кліком або програмним запитом.
3. Для бізнесу та маркетингу (Ефективність) забезпечується:
- швидкість завантаження (LCP) на основі глобальної мережі CDN
(Content Delivery Network), де користувачі бачать зображення
миттєво, незалежно від того, де вони знаходяться.
- адаптивність (Responsive Images) коли один оригінал автоматично
підлаштовується під екран смартфона, планшета чи 4K-монітора;
- відео-можливості, тобто трансформація відео, створення прев'ю-
гіфок та адаптивна трансляція (Adaptive Bitrate Streaming).
1.3.2 Imgix S3.
Imgix S3 [34] є швидким CDN-трансформатором, що пропонує обробку
зображень та відео (рис. 1.5). Imgix пропонує підмножину функціональності
Cloudinary, оскільки спеціалізується на обробці медіа, тоді як Cloudinary
підтримує обробку медіа, зберігання медіа та управління медіа (функціонально
для спрощення організації та пошуку ресурсів).
Арк.
ЧДТУ 211982.005 ПЗ 22
Змн. Арк. № докум. Підпис Дата
Рисунок 1.5 – Інтерфейс Imgix S3
Особливістю Imgix S3 є можливість підключення до існуючих сховищ
(наприклад, AWS S3 або Google Cloud Storage), а не обов'язкового надання
власного сховища. Дистрибуція реалізується шляхом високої швидкості обробки
безпосередньо в мережі передачі даних. Оплата здійснюється за кількість
унікальних вихідних зображень та обсяг переданого трафіку. Перевагою є
простота інтеграції через URL-параметри, ідеально для розробників. Недоліком
вважається менша кількість функцій для керування медіа-активами (DAM)
порівняно з Cloudinary.
Як Cloudinary, так і Imgix пропонують подібний основний набір функцій
(рис.1.6).
Арк.
ЧДТУ 211982.005 ПЗ 23
Змн. Арк. № докум. Підпис Дата
Рисунок 1.6 – Порівняння функцій Cloudinary і Imgix S3.
Різниця полягає, головним чином, в інтегрованому сховищі: Cloudinary його
надає, а Imgix — ні. Це робить Cloudinary кращим для користувачів, які хочуть
отримати комплексне рішення, яке обробляє весь процес від завантаження
файлу користувачем у форму до відображення його зміненого розміру на іншій
сторінці. Набір функцій Imgix робить його більш привабливим для користувачів,
які хочуть самостійно керувати завантаженням та зберіганням файлів.
Панель інструментів Imgix характеризиується відсутністю конструктора
трансформацій, відсутністю посилань на документацію та практично повною
відсутністю адаптації. Це робить використання сервісу дуже складним як для
ознайомлення, так і після реєстрації.
Оскільки Imgix – це платформа для обробки зображень та відео, після
створення облікового запису перше, то відповідно користувачу необхідно
обробити зображення або відео. Однак, оскільки на панелі інструментів немає
очевидного способу зробити це, то користувач повинен повернутися на головну
сторінку Imgix (або до Google), щоб дізнатися, як користуватися продуктом
(рис.1.7).
Арк.
ЧДТУ 211982.005 ПЗ 24
Змн. Арк. № докум. Підпис Дата
Рисунок 1.7 – Панель керування Imgix S3.
Панель керування Cloudinary є інтуїтивно зрозуміло та містить усі пункти,
на які користувач зареєструвався, у верхній навігаційній панелі, зокрема
бібліотеку перетворення файлів та конструктор перетворень (рис.1.8).
Рисунок 1.8 – Панель інструментів Cloudinary.
Imgix найкраще підходить користувачам, які хочуть самостійно керувати
зберіганням зображень (в S3 / Azure / Google Cloud). Imgix, як і Cloudinary. є
платними сервісами, але вони мають різні підходи до безкоштовних лімітів та
розрахунку вартості. Imgix на відміну від Cloudinary орієнтований на бізнес,
тому безкоштовний варіант значно обмеженіший. Cloudinary вигідніший для
стартапів завдяки щедрому безкоштовному тарифу. Imgix часто обирають великі
медіа-ресурси, бо у них простіша модель масштабування (ви платите за кожне
Арк.
ЧДТУ 211982.005 ПЗ 25
Змн. Арк. № докум. Підпис Дата
"джерельне" фото, а кількість його варіацій/розмірів не обмежена і не здорожчує
рахунок).
1.3.3 Cloudflare Images
Cloudflare Images [35] є інфраструктурним рішенням, що орієнтовано на
швидкість та безпеку в межах екосистеми Cloudflare (рис.1.9).
Рисунок 1.5 – Інтерфейс Cloudflare Images
Особливістю даного продукт є пропозиція простого зберігання та базові
трансформації (ресайз, стиснення) за фіксовану ціну. Це є більш прозора та
передбачувана модель оплати за кількість збережених зображень та їх доставку.
Cloudflare охоплює широкий спектр послуг, від CDN, зворотних проксі-серверів,
інструментів кібербезпеки тощо. Він обробляє DNS, кешування, оптимізацію
трафіку, управління ботами та безпеку програм в одному об'єкті. З часом він
розширився до розробницьких сервісів, таких як Workers та Pages,
перетворюючи саму мережу на програмований edge.
Перевагами є низька ціна, відмінний захист від DDoS, легка інтеграція з
іншими сервісами Cloudflare (наприклад, R2 Storage). Cloudflare Images дозволяє
Арк.
ЧДТУ 211982.005 ПЗ 26
Змн. Арк. № докум. Підпис Дата
розміщувати та оптимізувати зображення та відео безпосередньо в одному
мережевому стеку, спрощуючи доставку медіа. Зручні для розробників API.
Інструменти інфраструктури, Workers KV та довговічні об'єкти дозволяють
налаштовувати кешування та обробку запитів на периферії.
Недоліком є обмежений набір складних трансформацій порівняно зі
спеціалізованими сервісами.
Таблиця 1. 3.
Порівняльна таблиця аналогів
Критерій Cloudinary Imgix Cloudflare Images
Основний фокус Повне керування Швидка Економічна доставка
медіа (DAM) трансформація через та зберігання
URL
Зберігання Власне (включено) Зовнішнє (S3, GCS) Власне (Managed)
Трансформації Просунуті (ШІ, відео) Середні (детальні Базові (ресайз,
налаштування) формати)
Модель Billing Кредитна система За унікальні об'єкти + За кількість
(комплексна) трафік зображень + трафік
Найкраще для Великих E-commerce Додатків з Бюджетних проектів
та медіа динамічним та стартапів
контентом
Розглянуті сервіси для обробки зображень мають свої характеристики,
переваги та недоліки. Cloudinary є платформою «все в одному», що забезпечує:
широкий функціонал, характеризується універсальністю та має безкоштовний
план. Ідеально підходить для старту без витрат. Автоматизаціязабезпечується
алгоритмами «розумного» стиснення та вибору формату. Недоліками є ціна при
масштабуванні та складність інтерфейсу.
Imgix є найкращий інструментом для динамічної трансформації,
перевагами якого є легка інтеграція, швидкість. Гнучкість. Серед недоліків
іідсутність власного сховища та слабкий Free Tier. Cloudflare Images найбільш
бюджетне та прозоре інфраструктурне рішення. Перевагами є фіксована ціна,
безпека та простота. Мінімалістичний набір функцій, який легко налаштувати.
Недоліками є обмеженість та відсутність гнучкості.
Арк.
ЧДТУ 211982.005 ПЗ 27
Змн. Арк. № докум. Підпис Дата
1.4 Висновки до розділу 1
У першому розділі проаналізовано предметну область розробки web
сервісів для обробки зображень у режимі реального часу. Досліджено структуру
та технологічні можливості. Досліджено всі бізнес-процеси, що включають
трансформацію через URL-параметри, сховище та дистрибуцію, монетизацію та
білінг, аналітику. Для кращого розуміння web-додатка для обробки зображень у
режимі реального часу порівняно три аналогічні продукти: Cloudinary, Imgix та
Cloudflare Images, кожен з яких характеризується функціоналом, сховищем
даних, вартістю. Після порівняння функцій досліджуваних систем, визначено
переваги та недоліки, які необхідно враховувати в процесі розробки web-
додатка для обробки зображень у режимі реального часу. Також в розділі
описані функціональні та нефункціональні вимоги до розроблюваного сервісу.
Арк.
ЧДТУ 211982.005 ПЗ 28
Змн. Арк. № докум. Підпис Дата
2 ПРОЄКТУВАННЯ WEB-ДОДАТКУ ДЛЯ ОБРОБКИ ЗОБРАЖЕНЬ
В РЕЖИМІ РЕАЛЬНОГО ЧАСУ
2.1 Розробка архітектури додатку
Для розробки архітектури web-додатку для обробки зображень у режимі
реального часу найкраще підходить комбінований підхід, в основі якого клієнт-
серверна архітектура та подієво-орієнтована мікросервісна модель. Подієво-
орієнтована мікросервісна модель дозволяє рознести важкі операції обробки та
швидку віддачу контенту користувачу. Застосування клієнт-серверної
архітектури сприяє редагуванню в режимі реального часу (зміна яскравості,
кроп, сепія).
Комбіноване застосування цих двох моделей забезпечить можливості
користувачеві отримання критичної мінімальної затримка (Latency). В подієвій
моделі запит може "висіти" в черзі, поки звільниться обробник. Це добре для
фонової обробки 1000 фото, але погано для живого інтерфейсу. У клієнт-
серверній моделі через HTTP-запит (як у вашій схемі з CDN та Lambda)
відповідь приходить одразу, як тільки процесор закінчив роботу.
Клієнт-серверна архітектура додатку застосовується в ході роботи з
базами даних та мережами та забезпечує обмін даними між цими компонентами.
Архітектура «клієнт-сервер» забезпечує наступні три основні компоненти [8]:
 сервери, які обробляють отримані запити та видають відповідний
результат;
 клієнти, які отримують доступ до серверів із запитами даних;
 мережа, яка забезпечує обмін даними між клієнтами та серверами.
Дані обробляються та зберігаються на стороні сервера, дані
відображаються, а запити на сервер надсилаються на стороні клієнта. На рис. 2.1
показано трирівневу архітектуру web-додатку.
Арк.
ЧДТУ 211982.005 ПЗ 29
Змн. Арк. № докум. Підпис Дата
Рис. 2.1. Клієнт-серверна архітектура [8].
Ключовими рівнями подієво-орієнтованої мікросервісної моделі є
наступні [9]:
1. Рівень завантаження та API (Ingestion Layer)
 API Gateway: Приймає запити від клієнта (Web/Mobile).
 Завантаження (Upload): Використання Signed URLs (підписаних
посилань). Клієнт завантажує оригінал безпосередньо в сховище (S3),
минаючи основний сервер додатка, що знімає з нього навантаження.
2. Рівень зберігання (Storage Layer)
 Original Storage: "Холодне" об'єктне сховище (наприклад, AWS S3)
для оригіналів високої якості.
 Result Storage/Cache: Швидке сховище для оброблених копій.
3. Рівень обробки (Processing Layer — "Серце" системи), реалізується
два підходи:
 On-the-fly (На льоту): Коли запит на image.jpg?width=300 приходить
вперше, Serverless-функція (наприклад, AWS Lambda або Cloudflare
Workers) обробляє фото, віддає його та зберігає в кеш.
Арк.
ЧДТУ 211982.005 ПЗ 30
Змн. Арк. № докум. Підпис Дата
 Pre-processing (Попередня обробка): Система автоматично створює
набір популярних розмірів (thumbnails) одразу після завантаження
оригіналу через чергу повідомлень (RabbitMQ/Kafka).
4. Рівень дистрибуції (Delivery Layer):
 CDN (Content Delivery Network): Критичний елемент. CDN кешує
результат обробки на "edge-серверах".
 Кеш-стратегія: Якщо файл є в кеші CDN — він віддається за
мілісекунди. Якщо немає — іде запит на рівень обробки.
5. База даних та Аналітика:
 Metadata DB (PostgreSQL/MongoDB): Зберігає посилання на файли,
теги, права доступу та логи трансформацій.
 Billing Service: Фіксує кількість операцій та обсяг трафіку для
виставлення рахунків.
Візуально схему потоку даних представлено на рис.2.2.
Запит користувача
Перевірка копії CDN
Копії не має
Запит на Image Processor
Storage
Рисунок 2.2. Схема потоку даних в подієво-орієнтованої мікросервісної
моделі
Арк.
ЧДТУ 211982.005 ПЗ 31
Змн. Арк. № докум. Підпис Дата
Дана схема реалізується наступним чином:
1. Користувач запитує фото з параметрами ?size=medium&filter=sepia.
2. CDN перевіряє наявність такої копії.
3. Якщо копії немає: Запит іде на Image Processor (Lambda/Worker).
4. Processor бере оригінал зі Storage, застосовує фільтри.
5. Результат повертається в CDN (для кешування) і Користувачу.
Для реалізації продуктивного процесора зображень у режимі реального
часу найкращим поєднанням є Node.js (як середовище), бібліотека Sharp (для
обробки) та AWS Lambda (як безсерверна інфраструктура).
Детально даний технологічний стеку можна описати наступнем
чином[10]:
 Node.js - ідеально підходить для I/O-інтенсивних завдань та
асинхронної роботи з потоками даних (Streams);
 Sharp є найшвидшою бібліотекою для Node.js (базується на libvips).
Вона у 4-5 разів швидша за ImageMagick, оскільки не створює копії всього
зображення в пам'яті, а обробляє його потоково;
 AWS Lambda дозволяє масштабуватися до тисяч одночасних
обробок без керування серверами. Ви платите лише за мілісекунди роботи
коду.
Схема роботи стеку (Архитектура):
1. Запит: Користувач звертається до URL через Amazon CloudFront (CDN).
2. Подія (Edge Logic): Якщо в CDN немає готового файлу, CloudFront
викликає Lambda@Edge або стандартну Lambda через API Gateway.
3. Обробка (The Logic):
- Lambda завантажує оригінал з S3.
- Sharp виконує операції: .resize(), .webp(), .composite() (для водяних
знаків).
- Lambda повертає Buffer (зображення) назад у CDN.
Арк.
ЧДТУ 211982.005 ПЗ 32
Змн. Арк. № докум. Підпис Дата
4. Кешування через CloudFront зберігає цей результат для наступних
користувачів.
Оптимізація та Білінг реалізується наступним чином:
 Пам'ять Lambda: Для Sharp варто виділяти від 1536 МБ RAM — це
пропорційно збільшує потужність процесора і швидкість обробки.
 Billing:
o Кількість запитів до Lambda.
o Час виконання (зазвичай 200-500 мс на фото).
o Трафік з CloudFront (вихідний трафік у мережу).
Клієнт-серверна архітектура забезпечує прямий діалог. Клієнт каже:
«Зроби це зараз», і чекає, поки сервер відповість. При цьому реалізується
синхронний зв'язок: (зазвичай HTTP). Однак існує залежність від серверу,
тобто «впав» або гальмує, клієнт теж чекає або отримує помилку. Тому
застосування подієво-орієнтованої моделі (Event-Driven) сприяє можливості
компонентам через асинхронний зв'язок побудови у спільну шину (чергу).
При цьому компоненти максимально незалежні (Decoupled). Якщо один
сервіс тимчасово вимкнено, подія просто почекає в черзі. Як приклад. Коли
користувач завантажив фото, система надає відповідь: «Фото
завантажено!». Image Processor «чує» це і починає обробку, а сервіс
сповіщень «чує» це і готує лист. Вони не знають один про одного. Логіка
наступна: «Я зробив свою частину і крикнув про це — нехай інші
реагують».
Таблиця 2.1.
Порівняльні характеристики двох моделей
Характеристика Клієнт-Сервер Подієво-орієнтована (EDA)
Взаємодія Синхронна (чекаємо Асинхронна (викинув і
відповідь) забув)
Стиль Командний ("Зроби!") Описовий ("Це сталося")
Масштабованість Важче (вузьке місце — Легше (додаємо нових
сервер) слухачів подій)
Арк.
ЧДТУ 211982.005 ПЗ 33
Змн. Арк. № докум. Підпис Дата
Надійність Якщо сервер офлайн — Якщо сервіс офлайн —
система стоїть подія обробиться пізніше
Складність Проста в реалізації Складна в налагодженні
(Debugging)
Для web додатку для обробки зображень у режимі реального часу
комбінований підхід дозволяє розділити задачі на «термінові» (те, що
користувач має побачити зараз) та «ресурсномісткі» (те, що система має
зробити у фоні). Це поєднання класичного Клієнт-Сервера (через HTTP) та
Подієво-орієнтованої моделі (через черги подій).
1. Синхронна частина (Клієнт-Сервер) — «Живе редагування», в ході
якого користувач змінює фільтр (sepia) або розмір (medium) і хоче бачити
результат негайно. Процес реалізує запит, що надходіть через CDN до
Image Processor. В результаті отримано оброблене фото, що повертається
прямо в браузер за мілісекунди. Метою є максимальна швидкість відгуку
інтерфейсу (User Experience).
2. Асинхронна частина (Подієва модель) так звана «Важка обробка»,
коли користувач натискає «Зберегти» або «Завантажити оригінал»,
вмикається фонова логіка. Процес передбачає падіння оригіналу в Storage,
де Storage генерує подію (Event): NewImageUploaded. Цю подію
підхоплюють кілька незалежних «слухачів» (Workers): Worker 1 створює 5
різних форматів (WebP, PNG, Avif) для різних пристроїв; Worker 2 аналізує
вміст через AI (розпізнає обличчя або об'єкти для тегів); Worker 3 оновлює
запис у Database, проставляючи статус «Готово». Метою є виконання
складних задач, не змушуючи користувача чекати біля "спіннера"
завантаження.
Переваги комбінованого підходу є наступні:
- стійкість. Якщо AI-сервіс тимчасово "впав", фото все одно буде
доступне користувачу, а аналіз виконається пізніше, коли сервіс
підніметься;
Арк.
ЧДТУ 211982.005 ПЗ 34
Змн. Арк. № докум. Підпис Дата
- економія. Не витрачається потужні ресурси (GPU для AI) під час
простого перегляду фото.
- масштабованість. Можливість додати 10 нових функцій
(наприклад, водяні знаки або антивірусну перевірку), просто
додавши нового "слухача" в чергу, не змінюючи основний код
додатка.
2.2 Структура бази даних
Для створення web додатку для обробки зображень у режимі реального
часу база даних повинна бути легкою та швидкою, оскільки основне
навантаження припадає на файлову систему та черги повідомлень. Тому була
обрана реляційна модель даних, оскільки забезпечує цілісність даних через
чіткі зв’язки (Foreign Keys) та транзакції. Використання реляційної моделі
(SQL) для сервісу обробки зображень на Node.js має наступні переваги
переваги [11]:
1. Цілісність та зв'язність (Data Integrity), де завдяки Foreign Keys
(зовнішнім ключам) ви застраховані від «сирітських» даних. Якщо ви
видаляєте користувача, база може автоматично видалити всі його зображення
та завдання на обробку (ON DELETE CASCADE). У NoSQL це довелося б
робити вручну на рівні коду додатка.
2. ACID-транзакції, що гарантує, що операція або виконається
повністю, або не виконається зовсім. Приклад: Коли створюється запис про
нове зображення та одночасно створюєте 3 завдання на ресайз — транзакція
гарантує, що не виникне ситуації, коли запис про файл є, а завдань до нього
немає через помилку сервера.
3. Ефективна робота з метаданими (JSONB), що для сучасних
реляційних БД (як PostgreSQL) підтримується тип JSONB. Це дозволяє
поєднувати строгу структуру (ID, дати, статуси) з гнучкістю NoSQL для
зберігання специфічних результатів обробки зображень (EXIF-дані, координати
облич, палітра кольорів).
Арк.
ЧДТУ 211982.005 ПЗ 35
Змн. Арк. № докум. Підпис Дата
4. Оптимізація через індекси, де можна створювати складні індекси для
швидкого пошуку. Наприклад, миттєво знайти «усі зображення формату PNG,
завантажені за останні 24 години, які ще не пройшли обробку». У великих
архівах зображень це працює значно швидше, ніж повне сканування колекцій.
5. Масштабованість читання. Коли для Node.js додатків, де багато
користувачів переглядають результати обробки, реляційні бази дозволяють
легко налаштувати Read Replicas. Основна база займається записом нових
завдань, а репліки — лише віддають посилання на оброблені фото.
6. Чітка схема (Type Safety) при використанні ORM (наприклад, Prisma
або TypeORM) у Node.js, реляційна схема автоматично генерує типи
TypeScript. Це мінімізує помилки в коді: ви точно знаєте, що поле status — це
рядок з конкретним переліком значень, а не випадкове число.
У процесі проєктування структури бази даних потрібно створити ER-
діаграму, SQL-схему та рівень доступу до даних (ORM). Детальний опис того,
що створено на даному етапі:
1. Логічна ER-діаграма (Entity-Relationship). Це візуальна схема, яка
визначає сутності та їх взаємозв'язки. Для даного додатка вона включає:
Один-до-багатьох (1:N): Користувач → Зображення.
Один-до-багатьох (1:N): Оригінальне зображення → Оброблені версії
(thumbnails, превью).
Один-до-одного або багатьох (1:1/1:N): Зображення → Завдання на
обробку (статус у реальному часі).
2. Фізична схема бази даних (SQL DDL) передбачає написання скрипту
створення таблиць з урахуванням специфіки Node.js та PostgreSQL. Індексація
передбачає додавання індексів на user_id та status, щоб запити «показати мої
оброблені фото» працювали миттєво.
Типи даних: Використано UUID для ідентифікаторів (це безпечніше для
API) та JSONB для зберігання метаданих зображення (ширина, висота, палітра).
Арк.
ЧДТУ 211982.005 ПЗ 36
Змн. Арк. № докум. Підпис Дата
3. Схема міграцій (Prisma або TypeORM). Оскільки використано Node.js,
найкращим підходом застосовано опис моделі мовою Prisma Schema або
TypeScript Decorators. Це дозволило:
Автоматично генерувати SQL-код.
Мати повну типізацію в коді (IntelliSense підказуватиме поля бази).
Легко змінювати структуру бази в майбутньому без втрати даних.
4. Опис статусів (Finite State Machine).Для обробки в реальному часі
важливо чітко спроєктувати поле status. Визначено перелік (Enum) станів:
UPLOADED → PROCESSING → COMPLETED / FAILED.
5. План інтеграції з Redis. Хоча Redis не є реляційною БД, у процесі
проєктування структури потрібно визначити, які дані будуть дублюватися
в кеш для Socket.io (наприклад, прогрес обробки у відсотках), щоб не
«забивати» основну базу PostgreSQL дрібними оновленнями кожну
секунду.
Оптимальна структура бази даних web-додатку для обробки зображень у
режимі реального часу база наступна:
1. Користувачі (users) - зберігає дані профілів та налаштування.
id (UUID, PK)
email (Varchar, Unique)
password_hash (Text)
created_at (Timestamp)
2. Зображення (images) - метадані файлів. Самі зображення краще зберігати в
S3-сховищі, а в БД записувати лише посилання.
id (UUID, PK)
user_id (UUID, FK)
original_name (Varchar)
s3_url (Text) — шлях до оригіналу
status (Enum: 'pending', 'processing', 'completed', 'failed')
created_at (Timestamp)
Арк.
ЧДТУ 211982.005 ПЗ 37
Змн. Арк. № докум. Підпис Дата
3. Завдання на обробку (processing_tasks) для відстеження стану обробки в
реальному часі (зв'язок з WebSocket або Polling).
id (UUID, PK)
image_id (UUID, FK)
filter_type (Varchar) — наприклад: 'resize', 'grayscale', 'ai_enhance'
parameters (JSONB) — набір параметрів для обробки (ширина, висота тощо)
result_url (Text) — шлях до обробленого файлу
error_message (Text) — для дебагу у разі помилки
4. Журнал активності (activity_log) — опціонально
id (BigInt, PK)
user_id (UUID, FK)
action (Varchar)
timestamp (Timestamp).
Для Node.js комбінація PostgreSQL (для метаданих) та Redis (для реального
часу та черг) є оптимальним варіантом. Оскільки Node.js однопотоковий,
важливо винести важку обробку зображень в окремі процеси або мікросервіси.
Адаптувати структуру та стек під Node.js можна наступним чином:
1. Застосований стек технологій:
 БД: PostgreSQL + Prisma/TypeORM (надійна схема).
 Кеш/Real-time: Redis (статуси обробки та Pub/Sub для WebSockets).
 Обробка: Бібліотека Sharp (найшвидша для Node.js) або Worker Threads.
 Зберігання: AWS S3 або Google Cloud Storage.
2. Специфічні поля в БД:
Додано наступні поля до таблиці images або processing_tasks для зручності
Node.js:
 mimetype: (Varchar) image/jpeg, image/webp — для правильних заголовків
при віддачі файлів.
 size: (BigInt) Розмір у байтах для валідації лімітів.
Арк.
ЧДТУ 211982.005 ПЗ 38
Змн. Арк. № докум. Підпис Дата
 metadata: (JSONB) Висота, ширина, EXIF-дані (Sharp автоматично їх
витягує).
3. Реалізація процесу «Реального часу» в Node.js виглядає так:
1. Клієнт завантажує фото через Multer.
2. Node.js записує в БД статус processing і кидає подію в Redis
Queue (наприклад, через бібліотеку BullMQ).
3. Worker (окремий процес) бере завдання, обробляє його через sharp і
зберігає в S3.
4. BullMQ завершує завдання, Node.js отримує сигнал і
через Socket.io відправляє клієнту посилання на готове фото.
4. Оптимізація таблиці Tasks.
Для Node.js розділено «завдання» і «результати»:
sql
CREATE TABLE image_versions (
id UUID PRIMARY KEY,
parent_id UUID REFERENCES images(id), -- посилання на оригінал
version_type Varchar, -- 'thumbnail', 'optimized', 'watermarked'
s3_url Text,
created_at Timestamp DEFAULT NOW()
);
Використання Sharp для створення Stream-трансформацій дозволяє
обробляти зображення "на льоту" без повного завантаження в оперативну
пам'ять, що критично для Node.js.
Візуальна схема бази даних для Node.js даного додатка побудована за
стандартом Crow's Foot, що чітко показує типи зв'язків (один-до-багатьох) та
ключові поля. Основний фокус зміщується на зв'язок "Користувач —
Зображення — Його копії". Схема моделі даних представлена на рисунку 2.6.
Арк.
ЧДТУ 211982.005 ПЗ 39
Змн. Арк. № докум. Підпис Дата
Users Images
id (PK)
email id (PK)
password_hash user_id
created_at s3_ key
status
metadata
Jobs
id (PK)
image_id
filter_type
status
result_url
Versions
id (PK)
parent_id
version_type
s3_url
Рисунок 2.6 – Схема даних web додатку для обробки зображень у
режимі реального часу.
Дана схема в Node.js реалізується наступни чином:
1. Таблиця Images зберігає лише посилання на оригінал, який ви
завантажили. Поле metadata (JSONB) дозволяє Node.js записати туди
ширину та висоту, які видасть бібліотека Sharp.
Арк.
ЧДТУ 211982.005 ПЗ 40
Змн. Арк. № докум. Підпис Дата
2. Таблиця Jobs є реальним часом коли Node.js починає обробку, він
створює запис зі статусом processing. Як тільки воркер Sharp
закінчив — статус стає completed.
3. В Таблицю Versions записуються посилання на всі "похідні"
зображення (наприклад, зменшена копія для прев'ю), щоб не псувати оригінал.
2.3 Принципи розробки бази даних.
Інтернет – це глобальний багатовіконний діапазон комп'ютерних баз
даних, що мають спільну інформаційну архітектуру та постійно оновлюються.
Концептуально, web є системою управління базами даних, як
«клієнт»-«сервер» [12].
Як зазначено в [13], при розробці бази даних для обробки зображень на
Node.js (де швидкість та асинхронність є пріоритетом), варто дотримуватися
п'яти ключових принципів:
1. Використання UUID замість Integer. Для id (PK) використано UUID
(v4). Це забезпечило можливість генерувати ідентифікатор на стороні Node.js
ще до запису в базу, що безпечніше для API (ніхто не вгадає ID наступного
фото) і полегшує масштабування на кілька серверів.
2. Принцип "Тонкої бази" (Storage Offloading). Безпосередньо
зображення не зберігаються в БД (у форматі BLOB). У базі зберігаються лише
метадані (назва, розмір) та S3 Key (шлях до файлу в хмарному сховищі). Це
тримає базу легкою та швидкою.
3. Гнучкість через JSONB. Для поля metadata у таблиці Images
використано тип JSONB (у PostgreSQL). Бібліотека Sharp видає багато
технічних даних (EXIF, палітра, щільність пікселів). Замість створення 20
окремих колонок, ви зберігаєте все в одному JSON-об'єкті, по якому можна
робити швидкий пошук.
4. Статусна модель (State Machine). Для обробки в реальному часі
критично мати поле status в таблиці Jobs. Завдання завжди проходить через
стадії: queued → processing → completed (або failed). Node.js підписується на
Арк.
ЧДТУ 211982.005 ПЗ 41
Змн. Арк. № докум. Підпис Дата
зміну цього статусу і через WebSockets повідомляє фронтенд, що картинка
готова.
5. Індексація зовнішніх ключів (Foreign Keys). Усі поля, що
закінчуються на _id (наприклад, user_id), повинні мати INDEX. Це пов’язано з
тим, коли користувач заходить у профіль, Node.js робить запит WHERE user_id
= .... Без індексу база буде "перетрушувати" мільйони записів, що вб'є
швидкість додатка.
Логіка роботи зі статусами в Node.js будується на принципі асинхронної
черги. Оскільки обробка зображень (ресайз, фільтри) — це ресурсомістка
операція, Node.js не повинен «чекати» її завершення всередині звичайного
HTTP-запиту.
Покрокова логіка взаємодії додатка з базою даних є наступна [14]:
1. Етап запиту (Експрес-контролер), коли користувач завантажує фото.
При цьому Node.js зберігає файл у сховище (S3/Local) і створює запис у
таблиці Images зі статусом uploaded.
Завдання: Створюється запис у таблиці Jobs зі статусом queued (в черзі).
Відповідь: Сервер одразу повертає клієнту 202 Accepted та ID завдання.
Користувач не чекає обробки, він бачить лоадер.
2. Етап фонової обробки (Worker). Для цього використано бібліотеку
BullMQ (на базі Redis). Зміна статусу: Воркер бере завдання з черги та оновлює
статус у БД на processing. Обробка: Викликається бібліотека Sharp.
Фіналізація передбачає наступне:
Якщо успішно, то статус змінюється на completed, записується
result_url.
Якщо помилка, то статус стає failed, записується текст помилки для
дебагу.
3. Етап реального часу (WebSockets), це те, що робить додаток «живим».
Node.js використовує Database Triggers або (простіше) подію в коді після
db.job.update().
Арк.
ЧДТУ 211982.005 ПЗ 42
Змн. Арк. № докум. Підпис Дата
Через Socket.io сервер відправляє повідомлення на фронтенд:
socket.emit('job_updated', { id: '123', status: 'completed' }).
Браузер отримує сигнал і замінює лоадер на готове зображення.
Приклад об'єкта статусу в БД (JSON):
json
{
"id": "uuid-123",
"status": "processing",
"progress": 45,
"started_at": "2023-10-27T10:00:05Z",
"error": null
}
Це є важливим аспектом, тому що згідно[15], стабільність передбачає
безперервну обробку. Якщо сервер матиме проблеми під час обробки, після
перезапуску Node.js знайде всі завдання зі статусом processing або queued і
запустить їх знову.
User Experience є важливим аспектом. Користувач бачить прогрес-бар
(наприклад, "30% готово"), що набагато краще, ніж просто білий екран.
2.4 Створення бази даних
Для створення бази даних у Node.js проекті (PostgreSQL) найкраще
використовувати Prisma ORM. Вона дозволяє описати схему один раз, і сама
створить таблиці, зв’язки та типи для TypeScript/JavaScript.
Покроковий процес створення бази на основі логіки статусів
представлено наступним чином:
1. Опис схеми (schema.prisma) передбачає текстовий файл, який є
"фундаментом" бази:
prisma
datasource db {
Арк.
ЧДТУ 211982.005 ПЗ 43
Змн. Арк. № докум. Підпис Дата
provider = "postgresql"
url = env("DATABASE_URL")
}
generator client {
provider = "prisma-client-js"
}
// Користувач
model User {
id String @id @default(uuid())
email String @unique
passwordHash String
images Image[]
createdAt DateTime @default(now())
}
// Оригінальне зображення
model Image {
id String @id @default(uuid())
userId String
user User @relation(fields: [userId], references: [id])
s3Key String // Шлях до файлу в сховищі
metadata Json? // EXIF, розміри від Sharp
status String @default("uploaded") // uploaded, processing, failed
jobs Job[]
versions Version[]
createdAt DateTime @default(now())
}
// Завдання на обробку (Реальний час)
Арк.
ЧДТУ 211982.005 ПЗ 44
Змн. Арк. № докум. Підпис Дата
model Job {
id String @id @default(uuid())
imageId String
image Image @relation(fields: [imageId], references: [id])
type String // наприклад: "resize", "blur"
status String @default("queued") // queued, processing, completed, failed
error String?
resultUrl String?
updatedAt DateTime @updatedAt
}
// Оброблені копії
model Version {
id String @id @default(uuid())
imageId String
image Image @relation(fields: [imageId], references: [id])
type String // "thumbnail", "preview"
url String
}
2. Команди для створення бази.
Встановлення інструментів:
bash
npm install prisma @prisma/client
npx prisma init
Будьте обачні, використовуючи код.
Створення таблиць (Міграція):
Ця команда проаналізує файл схеми та створить реальні таблиці в
PostgreSQL:
Арк.
ЧДТУ 211982.005 ПЗ 45
Змн. Арк. № докум. Підпис Дата
bash
npx prisma migrate dev --name init_image_processing
Будьте обачні, використовуючи код.
3. Логіка використання в коді (Node.js):
javascript
const { PrismaClient } = require('@prisma/client');
const prisma = new PrismaClient();
async function createProcessingJob(imageId, filterType) {
// 1. Створюємо запис у базі
const job = await prisma.job.create({
data: {
imageId: imageId,
type: filterType,
status: 'queued'
}
});
// 2. Додано завдання в чергу (BullMQ/Redis)
console.log(`Завдання ${job.id} додано в чергу`);
return job;
}
Автоматизація забезпечує можливості написання SQL-запитів. Безпека
забезпечується шляхом Prisma. Коли не можна видалити зображення, якщо у
нього є активні завдання (завдяки Foreign Keys).
Швидкість забезпечується завдяки UUID та індексам, які Prisma створює
автоматично, база працюватиме швидко навіть при тисячах завантажень.
Арк.
ЧДТУ 211982.005 ПЗ 46
Змн. Арк. № докум. Підпис Дата
2.5 Висновки до розділу 2
В розділі описано архітектуру web-додатку для обробки зображень в
режимі реального часу. Щоб краще зрозуміти архітектуру системи розроблено
схеми для відображення взаємодії користувачів та їх функцій в системі.
Описано принципи створення web-додатку для обробки зображень в режимі
реального часу. Розроблено базу даних системи, яка є реляційною. Створено
діаграму моделі даних web-додатку для обробки зображень в режимі реального
часу, що показує системні об’єкти та взаємозв’язки між ними, а також ER-
діаграму, що демонструє взаємодію між взаємозв’язками і дозволяє розпочати
програмування баз даних.
Арк.
ЧДТУ 211982.005 ПЗ 47
Змн. Арк. № докум. Підпис Дата
3 РОЗРОБКА ПРОГРАМНОЇ ЧАСТИНИ
3.1 Вибір програмних засобів розробки
Для проекту з обробки зображень у реальному часі на Node.js вибір
інструментів базується на трьох основних базових вимогах: швидкість
маніпуляції пікселями, асинхронна черга та надійна база даних.
Ось оптимальний набір ("стек") засобів розробки [16]:
1. Двигуном обробки є Sharp, що представляє стандарт для Node.js.
Основною перевагою є швидкість, тобто у 4–5 разів швидший за ImageMagick
або Jimp, оскільки використовує бібліотеку libvips на C. Забезпечує наступні
можливості: Зміна розміру, конвертація у WebP/Avif, накладання водяних
знаків та витягування EXIF-метаданих без "забивання" Event Loop.
2. Керування базою даних забезпечується на основі PostgreSQL +
Prisma ORM. PostgreSQL є реляційною базою для зберігання JSON-метаданих
(тип JSONB) та складних зв'язків між оригіналами та копіями. Prisma дозволяє
описати схему (яку ми обговорювали раніше) зрозумілою мовою та
автоматично генерує типи для TypeScript/JavaScript.
3. Менеджер черг (Real-time): BullMQ + Redis застосовується, оскільки
обробка фото — це "важка" операція, її не можна робити в основному потоці
API. BullMQ є найпотужнішою бібліотекою для Node.js, що керує чергами
завдань. Redis служить "швидкою пам'яттю" для BullMQ, де зберігаються
статуси завдань у реальному часі.
4. Трансляція статусів здійснюється за допомогою Socket.io. Коли
воркер Sharp закінчує роботу і оновлює статус у базі на completed, Socket.io
миттєво "штовхає" це повідомлення у браузер користувача. Це і створює ефект
реального часу.
5. Сховище файлів є S3-сумісне сховище. Застосовано AWS S3, Google
Cloud Storage або локальний MinIO (для розробки). Принцип забезпечує роботу
база даних, що зберігає лише посилання (URL), а файли лежать у хмарі.
Арк.
ЧДТУ 211982.005 ПЗ 48
Змн. Арк. № докум. Підпис Дата
Таблиця 3.1. Підсумок стеку
Категорія Інструмент
Runtime Node.js (LTS версія)
Обробка фото Sharp
База даних PostgreSQL
ORM Prisma
Черги BullMQ (на базі Redis)
Real-time Socket.io
Розглянутий набір дозволяє створити систему, яка витримає тисячі
завантажень одночасно, при цьому сервер функціонуватиме без збоїв.
Логіка поєднання Sharp (обробка) та BullMQ (черга) у Node.js дозволяє
серверу не "зависати", поки обробляється велике фото.
1. Налаштування воркера (worker.js).
Воркер — це окремий процес, який "слухає" чергу, бере завдання,
обробляє файл через Sharp і оновлює статус у базі.
javascript
const { Worker } = require('bullmq');
const sharp = require('sharp');
const { PrismaClient } = require('@prisma/client');
const prisma = new PrismaClient();
// Створюємо воркера для черги 'image-processing'
const worker = new Worker('image-processing', async (job) => {
const { imageId, filterType, s3Key } = job.data;
// 1. Оновлюємо статус у БД на "processing"
await prisma.job.update({
where: { id: job.id },
Арк.
ЧДТУ 211982.005 ПЗ 49
Змн. Арк. № докум. Підпис Дата
data: { status: 'processing' }
});
try {
// 2. Обробка через Sharp (наприклад, ресайз до 800px)
// У реальному проекті тут буде завантаження з S3
const processedBuffer = await sharp(s3Key)
.resize(800)
.webp({ quality: 80 })
.toBuffer();
// 3. Збереження результату (псевдокод завантаження).
const resultUrl = `https://s3.storage{imageId}.webp`;
// 4. Успішне завершення: оновлюємо статус і записуємо результат.
await prisma.job.update({
where: { id: job.id },
data: { status: 'completed', resultUrl: resultUrl }
});
// 5. Створюємо запис у таблиці Version.
await prisma.version.create({
data: {
imageId: imageId,
type: 'web-optimized',
url: resultUrl
}
});
Арк.
ЧДТУ 211982.005 ПЗ 50
Змн. Арк. № докум. Підпис Дата
return { resultUrl };
} catch (error) {
// 6. Обробка помилок
await prisma.job.update({
where: { id: job.id },
data: { status: 'failed', error: error.message }
});
throw error;
}
}, { connection: { host: 'localhost', port: 6379 } });
2. Додавання завдання в чергу (controller.js).
Коли користувач натискає "Обробити", ваш основний сервер просто
кидає "записку" в Redis.
javascript
const { Queue } = require('bullmq');
const imageQueue = new Queue('image-processing');
async function handleProcessRequest(req, res) {
const { imageId, filterType } = req.body;
// Створюємо запис у БД
const dbJob = await prisma.job.create({
data: { imageId, type: filterType, status: 'queued' }
});
// Додаємо в чергу BullMQ
await imageQueue.add('process-task', {
jobId: dbJob.id,
imageId,
Арк.
ЧДТУ 211982.005 ПЗ 51
Змн. Арк. № докум. Підпис Дата
filterType,
s3Key: 'path/to/original.jpg'
});
res.status(202).json({ jobId: dbJob.id, message: "Обробка розпочата" });
}
Перевагами такого підходу є наступні:
- Event Loop вільний. Node.js продовжує приймати нові запити,
поки Sharp (написаний на C++) працює в іншому потоці.
- Надійність. Якщо воркер "впаде", BullMQ автоматично
перезапустить завдання.
- Real-time. Коли воркер викликає prisma.job.update, ви можете
через Socket.io відправити подію клієнту.
3.2 Вибір способу доставки результату користувачеві
При виборі Polling (періодичного опитування) навантаження лягає на
базу даних, оскільки користувач буде робити запити кожні 1–3 секунди. Щоб
система не «лягла» при великій кількості користувачів, логіку в Node.js та
структуру БД треба оптимізувати.
Реалізувати даний механізм можна наступним чином [17]:
1. Оптимізація таблиці Jobs для швидкого опитування.
Щоб запити SELECT працювали миттєво, додайте індекс на комбінацію
полів. У файлі schema.prisma це виглядає так:
prisma
model Job {
id String @id @default(uuid())
status String // queued, processing, completed, failed
resultUrl String?

Арк.
ЧДТУ 211982.005 ПЗ 52
Змн. Арк. № докум. Підпис Дата
@@index([id, status]) // Індекс прискорює пошук конкретного завдання
}
2. Ендпоінт для перевірки статусу (Node.js + Express).
Клієнт надсилає GET /api/jobs/:id. Важливо повертати мінімум даних,
щоб не перевантажувати мережу.
javascript
app.get('/api/jobs/:id', async (req, res) => {
const { id } = req.params;
const job = await prisma.job.findUnique({
where: { id },
select: {
status: true,
resultUrl: true,
error: true
}
});
if (!job) return res.status(404).json({ error: 'Завдання не знайдено' });
// Якщо готово — повертаємо посилання, якщо ні — статус для лоадера
res.json(job);
});
3. Логіка на стороні клієнта (Frontend).
Необхідно використати експоненціальну затримку (або просто
стабільний інтервал), щоб не "спамити" сервер:
javascript
async function checkStatus(jobId) {
const response = await fetch(`/api/jobs/${jobId}`);
Арк.
ЧДТУ 211982.005 ПЗ 53
Змн. Арк. № докум. Підпис Дата
const data = await response.json();
if (data.status === 'completed') {
showImage(data.resultUrl); // Показуємо результат
} else if (data.status === 'failed') {
showError(data.error); // Показуємо помилку
} else {
// Якщо ще обробляється — повторюємо через 2 секунди
setTimeout(() => checkStatus(jobId), 2000);
}
}
4. Покращення через Redis (Кешування статусів).
Оскільки опитування створює багато запитів до основної бази
(PostgreSQL), у корпоративних системах статуси часто дублюють у Redis:
Воркер оновлює статус і в Postgres, і в Redis.
API спочатку перевіряє статус у Redis (це в 10 разів швидше).
Це дозволяє базі даних "відпочивати" від тисяч дрібних запитів SELECT.
Перевагами застосування Polling є наступні:
Проста реалізація (не треба налаштовувати WebSockets та тримати
постійне з'єднання).
Стійкість до розривів інтернету (клієнт просто спробує ще раз).
Недоліками даного способу є:
Зайве навантаження на сервер (багато "пустих" запитів, коли статус ще
не змінився).
Затримка (якщо картинка готова через 0.1с, а запит буде лише через 2с).
Окрім Polling (опитування), серед можливостей Node.js є два потужні
способи дізнатися про готовність зображення: WebSockets (найшвидший)
та Server-Sent Events (SSE) (найпростіший у реалізації).
Вони реалізуються наступним чином:
Арк.
ЧДТУ 211982.005 ПЗ 54
Змн. Арк. № докум. Підпис Дата
1. WebSockets (Socket.io) передбачає Real-time. Це постійне відкрите
"вікно" між сервером і браузером. Коли користувач завантажує фото, він
підключається до сокета. Як тільки воркер (Sharp) закінчив роботу, сервер сам
"штовхає" повідомлення клієнту: "Гей, твоє фото готове, тримай посилання!".
Перевагами є нульова затримка. Користувач бачить результат миттєво. Однак
недоліком є необхідність серверу тримати тисячі відкритих з'єднань одночасно,
що потребує більше оперативної пам'яті (RAM).
2. Server-Sent Events (SSE) є односторонній потік, ще предсталяє версію
сокетів. Сервер може надсилати дані клієнту, а клієнт серверу — ні. Це
реалізується наступним чином: клієнт відкриває HTTP-з'єднання, яке не
закривається. Сервер просто дописує в цей потік нові рядки тексту, коли статус
у базі змінюється. Перевагами є робота через звичайний HTTP, не потребує
спеціальних бібліотек на фронтенді. Недоліком є складність, тобто якщо вам
потрібен складний двосторонній чат або ігри.
3. Webhooks (Для B2B / API). Якщо сервіс обробки зображень
використовують інші розробники, тоді маємо ситуацію, коли обробка
завершена, ваш сервер сам робить POST-запит на сервер клієнта (на заздалегідь
вказану URL-адресу). Перевагою є можливість клієнту взагалі не треба нічого
опитувати або тримати з'єднання. Недоліком може бути робота тільки для
серверних систем, а не для звичайних користувачів у браузері.
Таблиця 3.2. Порівняльна таблиця засобів.
Метод Навантаження на БД Складність Швидкість (UX)
Polling Високе (багато Дуже низька Середня (є затримка)
запитів)
SSE Низьке Середня Висока (миттєво)
WebSockets Низьке Висока Максимальна
Арк.
ЧДТУ 211982.005 ПЗ 55
Змн. Арк. № докум. Підпис Дата
3.3 Дизайн web-додатку для обробки зображень в режимі реального
часу
Працюючи над завданням розробки web-додатку для обробки зображень
в режимі реального часу, необхідно розробити зрозумілий і легкий для
сприйняття користувачами інтерфейс, не обтяжений зайвими функціями, але
достатньо наповнений потрібною інформацією з функціональними
можливостями інтерактивної системи.
Дизайн web-додатка для обробки зображень у реальному часі поєднує
функціональність робочого простору (як у Figma чи Canva) та індикацію
фонових процесів.
Ключовими елементами дизайну, що адаптовані під Node.js архітектуру є
наступні [18]:
1. Інтерфейс завантаження (Dropzone) передбачає візуалізацію, де є
велика область для перетягування файлів з підтримкою мультизавантаження.
Логіка Node.js працює наступним чином: щойно файл обрано, він передається на
сервер, а в інтерфейсі з'являється «скелетон» (сірий прямокутник) майбутнього
зображення. Це створює відчуття миттєвої дії.
2. Панель інструментів (Sidebar) забезпечується через[]:
- фільтри та пресети, тобто список операцій (Resize, Crop, Grayscale,
AI Upscale);
- живі параметри, тобто слайдери для налаштування (якість WebP,
ступінь стиснення);
- кнопка дії "Застосувати", що ініціює створення запису в таблиці
Jobs у вашій БД.
3. Робоча область (Canvas/Viewer) містить наступні елементи:
- Before/After: Слайдер, який дозволяє порівняти оригінал з
результатом обробки;
- індикатори статусу (Polling/Real-time);
- Pending -іконка годинника або пульсуючий контур;
Арк.
ЧДТУ 211982.005 ПЗ 56
Змн. Арк. № докум. Підпис Дата
- Processing - прогрес-бар (наприклад, "Sharp обробляє... 45%")4
- Completed, що є миттєвою заміною прев'ю на готовий результат.
4. Історія версій (Gallery Rail) передбачає:
- нижня панель, що містить список усіх створених версій
зображення (з таблиці Image_Versions);
- швидкі дії, тобто кнопки "Завантажити" та "Порівняти" біля кожної
мініатюри.
5. Колірна гама та UX базується на наступних підходах:
- темна тема (Dark Mode) є стандартною для графічних редакторів,
щоб кольори зображення не спотворювалися фоном інтерфейсу;
- мікровзаємодії передбачає анімацію «успіху» (зелена галочка),
коли статус завдання в БД змінюється на completed.
З технічної точки зору використано оптимістичний UI. Коли користувач
натискає «Застосувати фільтр», дизайн має відразу показати новий елемент у
списку завдань, не чекаючи відповіді від сервера. Це робить додаток візуально
"реактивним". Для сучасних сервісів найкраще працює поєднання чистого
візуального стилю та продуманої структури (layout). Сучасні інтерфейси
тяжіють до мінімалізму, використання "м'яких" тіней, заокруглених кутів та
чіткої типографіки.
Дизайн інтерфейсу користувача web-додатка для обробки зображень в
режимі реального часу розроблено у стриманій темній кольоровій гамі, що легко
сприймається користувачами. Почуття вишуканості дизайну викликає темна
тема та трипанельна структура для фокусу на графіці. Мінімалістичний чорний
інтерфейс, де інструменти з'являються лише за потреби, легко запам’ятовується.
Структура з повзунками (sliders) справа для тонкого налаштування кольору (як у
Lightroom Web) забезпечує користувачеві зручність та розроблена за останніми
дизайнерськими віяннями у стилі Magnific. Фактично тут є уся інформація, яка
потрібна користувачам.
Арк.
ЧДТУ 211982.005 ПЗ 57
Змн. Арк. № докум. Підпис Дата
Головне меню web-додатка є основним елементом навігації, який
забезпечує доступ до ключових розділів і функцій ресурсу. Меню автоматично
змінює свій вигляд під розмір екрана (наприклад, перетворюється з
горизонтального списку на бургер-меню). Компактна кнопка (зазвичай три
горизонтальні лінії), яка при натисканні відкриває прихований список розділів.
Це стандарт для мобільних пристроїв та адаптивних сайтів (рис. 3.7). Типове
головне меню web-додатка (особливо в темних тонах) — це не просто список
посилань, а чітко структурована система, що складається з наступних
елементів:
1. Блок ідентифікації (Header/Top) передбачає логотип у вигляді клінійної
іконки або назва додатка, яка завжди повертає на головну сторінку. Перемикач
(Workspace switcher) забезпечує підтримку кількох проєктів або команд. Тут
знаходиться випадаюче меню для вибору робочої області.
2. Основна навігація (Core Navigation) включає список розділів, які
найчастіше розташовані у лівій бічній панелі (sidebar). Складається з наступних
елементів: Дашборд (Dashboard), тобто загальний огляд, графіки, головна
статистика; Операційні розділи такі, як «Завдання», «Клієнти», «Проєкти»,
«Замовлення»; Повідомлення / Вхідні, тобто внутрішня пошта або чати з
індикатором нових подій (червона крапка); Аналітика / Звіти, тобто глибокі дані
та таблиці.
3. Користувацький блок (User & Support) зазвичай знаходиться в самому
низу бічної панелі або у правому верхньому куті та включає наступні елементи:
- профіль користувача, тобто аватар, ім'я та статус (online/offline);
- налаштування (Settings), тобто керування акаунтом, безпекою та
темою інтерфейсу;
- допомога / FAQ. Що є посилання на документацію або чат
підтримки;
- Кнопка «Вихід» (Logout) для завершення сесії.
4. Інструменти швидкої дії включають:
Арк.
ЧДТУ 211982.005 ПЗ 58
Змн. Арк. № докум. Підпис Дата
- пошук (Global Search), тобто рядок або іконка лупи для швидкого
пошуку по всій системі;
- кнопка «Створити» (Action Button) – яскрава кнопка (наприклад,
«+ Новий проєкт»), що завжди під рукою.
- візуальні фішки в темних меню: активний стан, тобто пункт, що
підсвічується градієнтом або яскравою лінією збоку;
- згортання (Collapse), що забезпечує можливість приховати текст
пунктів, залишивши лише іконки, щоб звільнити місце на екрані.
Рисунок 3.7 – Головне меню.
Меню авторизації (або Login/Sign-up interface) — це критичний вузол
web-додатка, від якого залежить, чи почне людина ним користуватися. У темних
тонах воно зазвичай виглядає мінімалістично та фокусує всю увагу на полях
введення.
Структура типового меню авторизації містить заголовок та вітання, а
також короткий підзаголовок з посиланням на реєстрацію. Логін передбачає
введення Email або номер телефону та Пароль: Поле з іконкою «ока» (щоб
подивитися введений текст) та посиланням «Забули пароль?» поруч. Виконано у
темній темі, тобто поля мають темно-сірий фон, який трохи світліший за
основний фон, і яскраву рамку (border) при натисканні (фокусі).
Кнопка дії (Primary Button) є великою та контрастною. У темному
інтерфейсі вона має яскравий колір (градієнт). Альтернативний вхід (Social
Login) передбачає кнопки швидкого входу через Google, Apple ID або Facebook.
У темних темах зроблено контурними (outline), щоб вони не відволікали від
основної форми. Додатковими елементами є чекбокс «Запам'ятати мене», текст
Арк.
ЧДТУ 211982.005 ПЗ 59
Змн. Арк. № докум. Підпис Дата
про згоду з політикою конфіденційності внизу сторінки, візуальні особливості в
Dark Mode передбачають контрастність. Збоку від форми часто розміщують
абстрактну 3D-графіку або тематичне зображення в темних тонах для створення
атмосфери.
Рисунок 3.8 –Меню авторизації користувача.
Головна сторінка (Home Page / Landing Page) web-додатка в темних тонах
— це «обличчя» продукту. Вона має бути не лише красивою, а й
функціональною, щоб користувач за кілька секунд зрозумів, куди він потрапив.
Головна сторінка складається з наступних елементів:
1. Перший екран (Hero Section):
- основний заголовок (H1), тобто фраза про те, яку проблему вирішує
додаток;
- підзаголовок, тобто одне-два речення з деталями;
- кнопка заклик до дії (CTA), що представляє яскраву кнопку
(«Спробувати безкоштовно» або «Почати»), яка контрастує з темним
фоном;
- візуальний елемент у вигляді стильної 3D-ілюстрації.
2. Блок переваг (Features), що представляє короткі блоки з іконками,
що описують можливості. В темному дизайні ці картки часто мають
Арк.
ЧДТУ 211982.005 ПЗ 60
Змн. Арк. № докум. Підпис Дата
тонку світлу рамку або легкий ефект скляної поверхні
(glassmorphism).
3. Соціальне підтвердження (Social Proof):
- логотипи партнерів, тобто відомі компанії, що вже користуються
сервісом (зазвичай у сірих напівпрозорих кольорах).
- відгуки з цитатами клієнтів та їхніми фото.
4. Інтерактивні елементи (Dashboard Preview) забезпечують
демонстрацію того, як виглядає головне меню та робоча область всередині. Це
створює довіру ще до реєстрації.
5. Футер (Footer) передбачає нижню частину сторінки з посиланнями на
соцмережі, політику конфіденційності, контакти та карту сайту.
Для темного дизайну головної сторінки використано чистий чорний, а
для фону взято дуже темний синій або графітовий — це додає глибини.
Градієнти використано через м’які кольорові плями (наприклад, фіолетові або
сині) на фоні, щоб оживити макет. Типографіка виражена текстом, що є
достатньо світлим (оф-вайт), а ключові слова виділено акцентним кольором
(рис. 3.9).
Рисунок 3.9 – Головна сторінка.
Арк.
ЧДТУ 211982.005 ПЗ 61
Змн. Арк. № докум. Підпис Дата
Робота у візуальному редакторі (No-code або Drag-and-drop конструктор)
— це процес створення інтерфейсу додатка без написання коду. Реалізується з
графічними елементами, система сама генерує технічну частину. Процес
реалізується наступним чином:
1. Робоча область (Canvas) є центром екрану. Користувач бачить сторінку
додатка та може перетягувати блоки, змінювати їхній розмір та розташування
просто мишкою.
2. Панель елементів (Widget/Component Panel) знаходиться ліворуч.
Звідси взято блоки: Текст та заголовки, Кнопки та іконки, Поля введення (для
меню авторизації), Секції та контейнери (для структурування головної
сторінки).
3. Налаштування стилів (Inspector/Properties) реалізується через панель
для детального редагування обраного елемента. Тут налаштовується темна тема.
Кольори відповідають вибору фону (наприклад, глибокий графітовий #121212)
та кольору тексту. Відступи (Padding/Margin) реалізовано, щоб меню не
«злипалося». Ефекти додано через закруглення кутів, тіней або розмиття
(Glassmorphism).
4. Налаштування логіки (Interactions/Workflow) реалізується через дію
'Увійти'.
5. Адаптивність (Responsive Mode) характеризується здатністю коректно
відображатися на будь-яких пристроях: від величезних моніторів до компактних
смартфонів.
Редактор характеризується наступними перевагами та обмеженнями [19]:
- швидкість передбачає запуск продукту (MVP) займає дні або тижні
замість місяців;
- доступність характеризується можливістю створювати
універсальний дизайн;
- складні або унікальні функції вимагають переходу на Low-code (де
можна додавати шматочки коду рис. 3.10).
Арк.
ЧДТУ 211982.005 ПЗ 62
Змн. Арк. № докум. Підпис Дата
Рисунок 3.10 – Редагування Головної сторінки у візуальному редакторі
Щоб користувач побачив результат у візуальному редакторі (наприклад,
готове головне меню чи сторінку авторизації), процес проходить через три
фінальні етапи:
1. Попередній перегляд (Preview), що є режимом «чернетки» при
натисненні кнопки із зображенням «Play» або «Око» у верхньому куті
редактора. Додаток відкривається в новій вкладці браузера. Можна клікати по
кнопках, відкривати меню та перевіряти, як працює темна тема.
2. Публікація (Publish / Deploy) здійснюється з метою доступу іншим
людям за посиланням. У Webflow/Bubble необхідно натиснути Publish, і система
видає адресу (наприклад, my-app.webflow.io). Тепер будь-хто, хто має це
посилання, зможе побачити меню. У Figma достатньо поділитися посиланням
на прототип (Share), і користувач бачить інтерактивну картинку додатка.
3. Експорт (Export) передбачає передачу дизайну в програмування. При
цьому застосовано код (CSS/HTML), що копіює стилі (кольори, відступи,
шрифти) безпосередньо з панелі інспектора редактора. Графіка реалізується
через завантаження іконок та зображення у форматах SVG або PNG, щоб
вставити їх у реальний код додатка.
Арк.
ЧДТУ 211982.005 ПЗ 63
Змн. Арк. № докум. Підпис Дата
В процесі функціонування web-додатку для обробки зображень в режимі
реального часу в зображенні користувача можливі наступні зміни:
− “розмиті” області (за допомогою графічного ефекту Blur);
− анімовані графічна маски (анімованість працює тільки у режимі
відео);
− шаблони додатку (зображення та маски);
− додаткові шаблонні зображення чи медіа файли, які
використовуються зі сховища даних (рис. 3.12).
Рисунок 3.11 – Сторінки сайту в Консолі
3.3 Висновки до розділу 3
В третьому розділі обґрунтовано вибір засобів розробки web-додатку для
обробки зображень в режимі реального часу. Досліджено вибір способів
доставки даних користувачеві. Також детально описано розробку дизайну web-
додатку для обробки зображень в режимі реального часу та вибір відповідних
інструментів.
Арк.
ЧДТУ 211982.005 ПЗ 64
Змн. Арк. № докум. Підпис Дата
ВИСНОВКИ
Проведене дослідження дозволяє зробити висновок, що в даний час web-
технології швидко розвиваються, зокрема у сферах фотографування та
рекламування. Наявність інноваційної складової забезпечує можливість
соціальної користі та має перспективні плани розвитку, які принесуть значну
користь споживачам програмного продукту.
Застосування web-технологій сьогодні дозволяє створювати продукти
будь-якої складності, починаючи від простої текстової сторінки і закінчуючи
потужними графічними редакторами. У даному проекті це дає можливість
поєднати візуальну привабливість із серйозним функціоналом. Користувач може
не просто переглядати контент, а активно взаємодіяти з ним, наприклад,
замінюючи небажану рекламу на художнє розмиття або власні фотографії
безпосередньо у браузері. Завдяки інтеграції з хмарними сховищами та API,
додаток здатний миттєво підтягувати випадкові зображення або накладати
складні анімовані маски в режимі відео. При цьому бізнес-логіка дозволяє чітко
розділити базові можливості та платні послуги, як-от зйомка довгих відео чи
доступ до ексклюзивних шаблонів. Використання сучасних стандартів гарантує,
що такий інструмент буде доступним на будь-якому пристрої та зможе зберігати
оброблені матеріали прямо на карту пам’яті користувача, перетворюючи
звичайний веб-сайт на повноцінну робочу станцію.
У кваліфікаційній роботі розглядається теоретичне та практичне
дослідження процесу розробки web-додатку для обробки зображень в режимі
реального часу. В роботі було поглиблено досліджено розробку алгоритмічного
та програмного забезпечення, розробка технічного завдання, логічної структури
бази даних, розробка архітектури web-додатку для обробки зображень в режимі
реального часу, стилі для відображення компонентів web-додатку. Досліджено
робота з потоковими даними та можливості сучасних браузерів обробляти важкі
візуальні ефекти, як-от динамічний Blur або накладання анімованих масок, без
значних затримок. Важливою частиною є також проектування архітектури бази
Арк.
ЧДТУ 211982.005 ПЗ 65
Змн. Арк. № докум. Підпис Дата
даних для розмежування безкоштовного та платного контенту, де враховуються
обмеження тривалості відео та доступ до преміальних шаблонів.
Практичне дослідження переходить у площину реалізації цих ідей через
No-code або Low-code інструменти, де створюється робочий прототип
інтерфейсу. Практика включає налаштування логіки заміщення реклами
вибраними зображеннями з хмари або файлами користувача, а також тестування
швидкодії пристрою під час запису відео тривалістю понад одну хвилину. У
процесі розробки особлива увага приділяється інтеграції API для виклику
випадкових зображень та налаштуванню прямого доступу до файлової системи
пристрою для збереження результатів на карту пам’яті. Фінальна частина
дослідження підтверджує, що поєднання візуального дизайну з хмарними
сервісами дозволяє створити складний бізнес-додаток, який є одночасно
доступним для користувача та прибутковим для розробника.
Естетика продукту будується навколо робочої області, яка не
перевантажена зайвими елементами, що дозволяє користувачу зосередитися на
процесі редагування та виборі зображень із хмарних сховищ. При цьому дизайн
виконує стратегічну роль у монетизації, де платний функціонал, як-от
подовжений запис відео або преміальні шаблони, інтегрується органічно та не
заважає загальному досвіду користування. Таким чином, якісний дизайн
перетворює складну систему реального часу на доступний і привабливий сервіс,
де технологічна потужність прихована за легким та сучасним графічним
середовищем.
Таким чином, можна стверджувати, що мета роботи досягнута і всі
вимоги технічного завдання виконані у повному обсязі.
Арк.
ЧДТУ 211982.005 ПЗ 66
Змн. Арк. № докум. Підпис Дата
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Прокопенко Т. О. Теорія систем і системний аналіз : навч. посіб.
[Електронний ресурс] / Т. О. Прокопенко ; М-во освіти і науки України,
Черкас. держ. технол. ун-т. – 2-ге вид., змінене та доп. – Черкаси :
ЧДТУ, 2025. – 147 с.
2. Комп'ютерна графіка: навч.-метод, посіб. / Н. П. Тменова.- К.: ВПЦ
"Київський університет", 2017. 111 с. URL:
https://pdf.lib.vntu.edu.ua/books/2020/Tmenova_2017_111.pdf
3. Computer Graphics: Principles and Practice in C: United States Edition
(SYSTEMS PROGRAMMING SERIES) Hardcover. James D. Foley,
Andries van Dam, Steven K. Feiner, John F. Hughes (1995) Addison
Wesley. 1200 р.
4. The Essential Beginners Guide to Unreal Engine 5: 2023 Edition Paperback.
(2022) Mr Trevor Hill. The Essential Beginners Guide to. 240р.
5. Основи інтернет-маркетингу. Частина 1: навчальний посібник /Н.Р.
Кордзая. Херсон: Олді-плюс, 2018. 184 с. ISBN 978-966-289-292-5.
6. Artiom Dashinsky. The Path to Senior Product Designer: An Actionable
Growth Plan for a UX Design Career. Independently published, 2023. 284 p.
7. Frain B. Responsive Web Design with HTML5 and CSS. Develop future-
proof responsive websites using the latest HTML5 and CSS techniques. 3rd
edition. Birmingham : Packt Publishing Ltd, 2020. 384 р.
8. Гайдаржи В. І., Ізварін І. В. Бази даних в інформаційних системах.
Університет "Україна". 2018. 418 с.
9. Харів Н. О. Бази даних та інформаційні системи: навчальний посібник.
Рівне : НУВГП, 2018. 127 с.
10.Ярцев В.П. «Організація баз даних та знань». Київ: ДУТ- 2018. 214 с.
11.Берко А.Ю., Верес О.М.Технології баз даних та знань. Магнолія 2006.
2024. 636 с.
Арк.
ЧДТУ 211982.005 ПЗ 67
Змн. Арк. № докум. Підпис Дата
12.Mark Watson. Scripting Intelligence: Web 3.0 Information Gathering and
Processing Apresspod Series. Expert’s Voice in Open Source. Books for
professionals by professionals. Published in: Springer, 2009. — 392 р.
13.Методи та засоби мультимедійних інформаційних систем: навч. посіб.
[Текст] / Т. М. Басюк, П. І. Жежнич; Нац. ун-т "Львів. політехніка". –
Львів : Вид-во Львів. політехніки, 2015. – 426 c. – Бібліогр.: с. 413-416.
14.O’Reilly, Tim (2007): What Is Web 2.0: Design Patterns and Business
Models for the Next Generation of Software. Published in: International
Journal of Digital Economics, No. 65 (March 2007) — P. 17–37
15.Буйницька О.П. Інформаційні технології та технічні засоби навчання.
Навчальний посібник рекомендовано МОН України [Текст] / В-во:
ЦНЛ. – 2018. – 240 с.
16.Трофименко О. Г. Веб-технології та веб-дизайн : навч. посібник / О. Г.
Трофименко, О. Б. Козін, О. В. Задерейко, О. Є. Плачінда. – Одеса :
Фенікс, 2019. – 284 с.
17.Neumann, Gustaf; Sobernig, Stefan; Aram, Michael (February 2014).
"Evolutionary Business Information Systems". Business and Information
Systems Engineering. 6 (1): 33–36. doi:10.1007/s12599-013-0305-1
18.Бутинець Ф.Ф., Івахненков С.В., Давидюк Т.В., Шахрайчук Т.В.
Інформаційні системи бухгалтерського обліку. Підручник. [Текст] /
Житомир.: Изд. ПП „Рута”. – 2016. – 544 с.
19.Campbell, Jennifer (2017). Web Design: Introductory. Cengage Learning. p.
20.Keil, Mark; Cule, Paul E.; Lyytinen, Kalle; Schmidt, Roy C. (November
1998). "A framework for identifying software project risks".
Communications of the ACM. 41 (11): 76–83. doi:10.1145/287831.287843.
ISSN 0001-0782.
21.Salas-Zárate, María del Pilar; Alor-Hernández, Giner; Valencia-García,
Rafael; Rodríguez-Mazahua, Lisbeth; Rodríguez-González, Alejandro;
López Cuadrado, José Luis (May 2015). "Analyzing best practices on Web
Арк.
ЧДТУ 211982.005 ПЗ 68
Змн. Арк. № докум. Підпис Дата
development frameworks: The lift approach". Science of Computer
Programming. 102: 1–19. doi:10.1016/j.scico.2014.12.004
22.Du, Xiaofeng; Song, William; Munro, Malcolm (2009), Barry, Chris; Lang,
Michael; Wojtkowski, Wita; Conboy, Kieran (eds.), "Semantic Service
Description Framework for Address", Information Systems Development,
Boston, MA: Springer US, pp. 1033–1045, doi:10.1007/978-0-387-78578-
3_35, ISBN 978-0-387-78577-6, retrieved 2023-11-30
23.Hall, Heather (2022-05-01). "Web 2.0 Explained: Everything You Need To
Know". History-Computer. Retrieved 2023-12-10.
24.Козловський А.В. Комп’ютерна техніка та інформаційні технології:
Навч. посіб. Рекомендовано МОН [Текст] / Козловський А.В.,
Паночишин Ю.М., Погріщук Б.В. – В-во: Знання. – 2017. – 463 с.
25.Soni, Anuj; Gupta, Sachin; Talwandi, Navjot Singh (September 2023).
"Evolution Of Web Technologies in Recent Years" (PDF). Journal of
Emerging Technologies and Innovative Research. 10 (9). ISSN 2349-5162.
26.Mullenweg, Matt (May 27, 2003). "WordPress Now Available".
wordpress.org. WordPress. Archived from the original on July 19, 2010.
Retrieved July 22, 2010.
27.CMS Usage Statistics". builtwith.com. BuiltWith. Archived from the original
on August 6, 2013. Retrieved August 1, 2013.
28.Nick, Edward (7 September 2022). "Drupal". Data Science Central.
Retrieved 20 September 2022.
29.Jazayeri, Mehdi (2007). "Some Trends in Web Application Development".
Future of Software Engineering (FOSE '07). pp. 199–213.
doi:10.1109/fose.2007.26. ISBN 978-0-7695-2829-8. S2CID 7279594
30.ECM Enterprise Content Management, Ulrich Kampffmeyer. Hamburg
2006, ISBN 978-3-936534-09-8. Definition, history, architecture,
components and ECM suites
Арк.
ЧДТУ 211982.005 ПЗ 69
Змн. Арк. № докум. Підпис Дата
31.Managing Enterprise Content: A Unified Content Strategy. Ann Rockley,
Pamela Kostur, Steve Manning. New Riders, 2003.
32.Методичні рекомендації до підготовки кваліфікаційної роботи для
здобувачів освітнього ступеня «бакалавр» зі спеціальності 126
Інформаційні системи та технології освітньої програми «Web-
технології, Web-дизайн» усіх форм навчання [Електронний ресурс] /
[Упоряд.: Т.О. Прокопенко, Я.В. Тарасенко]; М-во освіти і науки
України, Черкас. держ. технол. ун-т. Черкаси: ЧДТУ, 2021. – 48 c.
ІНТЕРНЕТ ДЖЕРЕЛА
33.Платформа Cloudinary [Електронний ресурс]. – Режим доступу: https://
https://cloudinary.com/
34. Додаток Imgix [Електронний ресурс]. – Режим доступу:
https://www.imgix.com/
35. Додаток Cloudflare [Електронний ресурс]. – Режим доступу
https://workers.cloudflare.com/
ПРОГРАМНІ ЗАСОБИ
1. Microsoft Office Word 2010 © Корпорація Майкрософт, 2021.
2. Microsoft PowerPoint 2010 © Корпорація Майкрософт, 2021.
3. https://nodejs.org/en.
4. https://www.postgresql.org/.
5. https://www.figma.com/.
Арк.
ЧДТУ 211982.005 ПЗ 70
Змн. Арк. № докум. Підпис Дата
ДОДАТОК A
ЗАТВЕРДЖЕНО
Зав. кафедри ІТП, проф.
_________________ Прокопенко Т.О.
«____» ________________ 2026 р.
WEB-ДОДАТОК ДЛЯ ОБРОБКИ ЗОБРАЖЕНЬ В РЕЖИМІ РЕАЛЬНОГО ЧАСУ
Специфікація
482 ЧДТУ 21982-01
Листів 2
Розробник _______________ Єлсуков А.Д.
Керівник _______________ Прокопенко В.А.
Н. Контроль _______________ Прокопенко В.А.
Черкаси, 2026
2
482 ЧДТУ 21000-01
Позначення Найменування Примітка
Документація
482 ЧДТУ 21982-01 12 01 Фрагмент програмного
коду
482 ЧДТУ 21982-01 34 01 Інструкція користувачеві
WEB- ДОДАТОК ДЛЯ ОБРОБКИ ЗОБРАЖЕНЬ В РЕЖИМІ РЕАЛЬНОГО
ЧАСУ
482 ЧДТУ 21982-01 12 01
Фрагмент програмного коду
Листів 6
Розробник _____________ Єлсуков Д.А.
Н
Черкаси, 2026
2
482 ЧДТУ 21982-01 12 01
Фрагмент програмного коду web-додатку для обробки зображень в режимі
реального часу
const sharp = require('sharp');
const S3 = require('aws-sdk/clients/s3');
const s3 = new S3();
exports.handler = async (event) => {
const { width, format, key } = event.queryStringParameters;

// 1. Отримуємо оригінал з S3
const image = await s3.getObject({ Bucket: 'my-originals', Key: key }).promise();
// 2. Обробка через Sharp
const processedBuffer = await sharp(image.Body)
.resize(parseInt(width))
.toFormat(format || 'webp')
.toBuffer();
// 3. Повертаємо результат як Base64 для API Gateway/CDN
return {
statusCode: 200,
headers: { 'Content-Type': `image/${format}` },
body: processedBuffer.toString('base64'),
isBase64Encoded: true
};
3
482 ЧДТУ 21982-01 12 01
};
// Отримуємо доступ до елементів інтерфейсу
const canvas = document.getElementById('editorCanvas');
const ctx = canvas.getContext('2d');
const image = new Image();
// Функція для накладання ефекту Blur на область реклами
function applyAdReplacement(x, y, width, height, type) {
if (type === 'blur') {
// Зберігаємо поточний стан контексту
ctx.save();
// Створюємо область відсікання для ефекту
ctx.beginPath();
ctx.rect(x, y, width, height);
ctx.clip();
// Накладаємо фільтр розмиття
ctx.filter = 'blur(15px)';
ctx.drawImage(canvas, 0, 0);
ctx.restore();
} else if (type === 'placeholder') {
// Варіант із заміною на випадкове колірне зображення-заглушку
ctx.fillStyle = '#cccccc';
ctx.fillRect(x, y, width, height);
ctx.fillStyle = '#000';
ctx.fillText('Заміщено', x + 10, y + 20);
}
}
// Приклад виклику функції при завантаженні картинки
image.onload = () => {
canvas.width = image.width;
canvas.height = image.height;
4
482 ЧДТУ 21982-01 12 01
ctx.drawImage(image, 0, 0);

// Припустимо, реклама знаходиться в цих координатах
applyAdReplacement(50, 50, 200, 100, 'blur');
};
image.src = 'path_to_your_image.jpg';
// Логіка обмеження запису відео для безкоштовного тарифу
let recordingTime = 0;
const maxFreeTime = 60; // 1 хвилина
function checkRecordingLimit() {
recordingTime++;
if (recordingTime > maxFreeTime && !userIsPaid) {
stopRecording();
alert('Для запису відео довше 1 хвилини придбайте Premium');
}
}
function saveProcessedImage() {
const canvas = document.getElementById('editorCanvas');
const link = document.createElement('a');

// Перетворюємо Canvas у формат PNG (можна вибрати image/jpeg)
const dataURL = canvas.toDataURL('image/png');

link.download = 'obrobka_foto.png'; // Назва файлу, що збережеться
link.href = dataURL;

// Автоматично ініціюємо завантаження
link.click();
}
let mediaRecorder;
let recordedChunks = [];
function startVideoRecording(stream) {
recordedChunks = [];
5
482 ЧДТУ 21982-01 12 01
mediaRecorder = new MediaRecorder(stream);
mediaRecorder.ondataavailable = (e) => {
if (e.data.size > 0) recordedChunks.push(e.data);
};
mediaRecorder.onstop = () => {
// Створюємо відеофайл із зібраних фрагментів
const blob = new Blob(recordedChunks, { type: 'video/mp4' });
const url = URL.createObjectURL(blob);
const a = document.createElement('a');

a.href = url;
a.download = 'video_rezultat.mp4';
a.click();

// Очищуємо пам'ять
URL.revokeObjectURL(url);
};
mediaRecorder.start();
}
function secureSave() {
// Перевірка статусу користувача з глобальної змінної або бази даних
if (currentUser.isPremium) {
saveProcessedImage(); // Виклик функції збереження, описаної раніше
} else {
showPaymentModal(); // Показ вікна з тарифами
console.warn("Функція доступна лише для преміум-користувачів.");
6
482 ЧДТУ 21982-01 12 01
}
}
const video = document.getElementById('webcam');
const canvas = document.getElementById('outputCanvas');
const ctx = canvas.getContext('2d', { willReadFrequently: true });
// Функція циклічної обробки кадрів
function processFrame() {
// Малюємо поточний кадр з камери на полотно
ctx.drawImage(video, 0, 0, canvas.width, canvas.height);
// Отримуємо масив пікселів для маніпуляцій (наприклад, для Blur або AI-детектору)
let frame = ctx.getImageData(0, 0, canvas.width, canvas.height);

// Логіка заміщення реклами: якщо вибрано режим Blur
if (userSettings.mode === 'blur') {
ctx.filter = 'blur(10px)';
// Накладаємо розмиття лише на певну область (координати реклами)
ctx.drawImage(canvas, 100, 100, 200, 150, 100, 100, 200, 150);
ctx.filter = 'none';
}
// Логіка накладання анімованої маски (GIF/Lottie/PNG)
if (isRecording && activeMask) {
ctx.drawImage(activeMask, maskX, maskY, 150, 150);
}
// Рекурсивний виклик для наступного кадру
requestAnimationFrame(processFrame);
}
7
482 ЧДТУ 21982-01 12 01
// Запуск камери та процесу обробки
navigator.mediaDevices.getUserMedia({ video: true }).then((stream) => {
video.srcObject = stream;
video.play();
requestAnimationFrame(processFrame);
});
async function detectAndMaskAds() {
// Завантажуємо попередньо навчену модель (наприклад, MobileNet або власну)
const model = await tf.loadGraphModel('model_url/model.json');

// Отримуємо кадри з відео
const predictions = await model.executeAsync(tf.browser.fromPixels(videoElement));

predictions.forEach(prediction => {
// Якщо впевненість моделі вища за 80%
if (prediction.score > 0.8) {
const [x, y, width, height] = prediction.bbox;

// Викликаємо функцію заміщення, яку ми обговорювали раніше
applyAdReplacement(x, y, width, height, userSettings.selectedEffect);
}
});

requestAnimationFrame(detectAndMaskAds);
}
WEB- ДОДАТОК ДЛЯ ОБРОБКИ ЗОБРАЖЕНЬ В РЕЖИМІ РЕАЛЬНОГО
ЧАСУ
482 ЧДТУ 21982-01 34 01
Інструкція користувачеві
Листів 7
Розробник _____________ Єлсуков Д.А.
Н
Черкаси, 2026
2
482 ЧДТУ 21982-01 34 01
АНОТАЦІЯ
Дана інструкція містить відомості про призначення web-додатку, а також
інформацію, необхідну користувачам для застосування.
Web-додаток для обробки зображень в режимі реального часу може
працювати працювати у режимі реального часу та режимі фото чи відеозйомки,
тому необхідні найпоширеніші пристрої з такими апаратними можливостями, а
також з урахуванням зручності програмної реалізації додатку. Такими пристроями є
смартфони та планшети на платформах Android та iOS.
Системні вимоги. Для стабільної роботи додатку потрібен пристрій, що
відповідає вищезгаданим умовам, а також має підтримку функції доповненої
реальності:
1. Програмні вимоги (ОС)
Android: Версія 7.0 (Nougat) або новіша. Пристрій обов'язково має
підтримувати сервіси Google Play Services for AR (раніше відомі як ARCore).
iOS: Версія 11.0 або новіша. Підтримка фреймворка ARKit.
2. Апаратні вимоги (Залізо)
Процесор: Для плавної обробки відео 30+ кадрів/сек необхідні чипи середнього
або флагманського сегментів (наприклад, серії Snapdragon 700/800 для Android або
Apple A11 Bionic і новіші).
Оперативна пам'ять (RAM): Мінімум 3-4 ГБ. AR-додатки споживають багато
пам'яті для одночасного утримання в кеші відеопотоку та 3D-моделей/фільтрів.
Камера: Наявність автофокусу та здатність знімати відео мінімум у 1080p (Full
HD). Для професійних AR-задач на iOS перевагою буде наявність датчика LiDAR.
3. Датчики (Обов'язково)
Гіроскоп та Акселерометр: Для стабілізації зображення та відстеження нахилу
пристрою.
Магнітометр (Цифровий компас): Для правильної орієнтації об'єктів відносно
сторін світу.
3
482 ЧДТУ 21982-01 34 01
Докладному описові перерахованих питань і присвячена дана інструкція.
Web-додаток для обробки зображень в режимі реального часу представляє
собою програмне забезпечення, яке працює безпосередньо у браузері і здатне
миттєво модифікувати або аналізувати відеопотік чи графічні дані за допомогою
потужностей пристрою користувача.
З огляду на ваш перехід до мобільної розробки (Android/iOS) та вимоги щодо
AR (доповненої реальності), такий додаток функціонує за наступною схемою:
Прямий доступ до камери: Через спеціальні інтерфейси (API) додаток
отримує «сирі» дані з матриці камери.
Конвеєрна обробка (Pipeline): Кожен кадр відео проходить через алгоритми
фільтрації або розпізнавання об'єктів ще до того, як потрапити на екран.
Використання GPU та NPU: Основне навантаження лягає не на центральний
процесор, а на графічне ядро та блоки штучного інтелекту, що забезпечує плавність
картинки (30-60 кадрів на секунду).
Накладання шарів (Overlay): У режимі AR додаток зіставляє реальне
зображення з віртуальними об'єктами, використовуючи дані з датчиків
(гіроскопа/акселерометра) для точного позиціонування.
Доповнена реальність (AR) - це уявлення про реальний, фізичний світ, в
якому користувачі знаходять елементи, покращені за допомогою комп'ютерного
введення. Тому AR виступає як зв'язок між реальним зображенням з камери та
цифровими даними, які додаток генерує в режимі реального часу.
Оскільки поєднано обробку зображень у реальному часі з AR на мобільних
пристроях, функціонування додатка буде спиратися на три критичні процеси:
Трекінг (Tracking), тобто додаток аналізує відеопотік, щоб знайти опорні
точки в реальному світі (кути меблів, поверхню підлоги або риси обличчя).
Поєднання (Alignment), де завдяки гіроскопу та акселерометру цифрова
графіка «прив'язується» до цих точок. Коли користувач рухає смартфоном, графічне
накладання залишається на місці, створюючи ілюзію фізичної присутності об'єкта.
4
482 ЧДТУ 21982-01 34 01
Рендеринг (Rendering), що є безпосередньою візуалізацією змін. Якщо це
фільтр для фото — змінюються пікселі, якщо це AR-об'єкт — він відмальовується
поверх реальності з урахуванням освітлення та перспективи.
Для стабільної роботи на Android та iOS, ключовим є використання
SceneKit/RealityKit (для Apple) або SceneView (для Android), щоб ці «покращені
елементи» виглядали природно.
Функціонал. Основною задачею розроблюваного мобільного додатку є
заміщення реклами у режимі фото фото- та відео зйомки. Тобто основою даного
додатку є простий функціонал камери. Також додаток має надбудову, що працює на
технології доповненої реальності. Функціонал такого додатка базується на
поєднанні класичної камери та складного алгоритму детеювання об'єктів (Object
Detection). Працюватиме на практиці наступним чином:
1. Базовий рівень: Камера
Додаток надає стандартний інтерфейс для зйомки (кнопка затвора, запис
відео, фокусування). Головна відмінність — потік даних з камери не просто
виводиться на екран, а стає вхідними даними для нейромережі.
2. Інтелектуальне розпізнавання (AI Tracking)
Додаток має "впізнавати" рекламні площини в реальному часі:
Білборди та сітілайти: Алгоритм шукає прямокутні області з типовими
ознаками реклами.
Логотипи та бренди: Використання навченої моделі (наприклад, YOLO або
MobileNet), яка впізнає відомі бренди.
Текст: OCR-технології для ідентифікації рекламних слоганів.
3. AR-надбудова: Заміщення (Dimming/Overlay)
Після того, як рекламна площа знайдена, вступає в дію AR:
Накладання (Overlay): Замість рекламного плаката користувач бачить інше
зображення (картину, пейзаж, корисну інформацію або просто чисте полотно).
5
482 ЧДТУ 21982-01 34 01
Перспектива: AR-рушій (ARKit/ARCore) розраховує кут нахилу та відстань
до рекламного щита, щоб віртуальна "заплатка" виглядала природно при русі
смартфона.
4. Режими збереження
Фотозйомка: Додаток робить знімок і миттєво "впаює" в нього заміщене
зображення.
Відеозйомка: Обробка кожного кадру з частотою 30-60 fps, щоб заміна
реклами не "тремтіла" і не зникала при русі.
Алгоритм роботи доповнюється інструментами для сегментації та
маніпуляції будь-якими об'єктами в кадрі.
Розширений алгоритм функціонування:
Сегментація об'єктів (Instance Segmentation):
Замість простого пошуку прямокутників (реклами), нейромережа (наприклад,
Mask R-CNN або MediaPipe) розділяє кадр на шари: люди, небо, будівлі, окремі
предмети.
Додаток розуміє межі кожного об'єкта з точністю до пікселя.
Вибір об'єкта для редагування:
Користувач може торкнутися будь-якого предмета на екрані (Tap-to-select).
Додаток створює «інтелектуальну маску» навколо обраного об'єкта.
Застосування модифікацій (Редагування):
Заміна текстур: Зміна кольору стін, одягу або поверхні предметів у
реальному часі.
Видалення (Inpainting): «Вирізання» небажаного об'єкта та автоматичне
заповнення фону за ним (аналог Content-Aware Fill у Photoshop, але для відео).
Стилізація: Накладання художніх фільтрів лише на певні об'єкти (наприклад,
зробити фон чорно-білим, а людину залишити кольоровою).
Просторове закріплення (AR Persistence):
6
482 ЧДТУ 21982-01 34 01
Якщо ви змінили колір дверей, то завдяки ARCore/ARKit, навіть якщо ви
відійдете або повернетеся, двері залишаться зміненого кольору в доповненій
реальності.
Фінальна обробка (Post-processing):
Під час зйомки фото або відео додаток згладжує краї між реальним і
відредагованим зображенням, щоб перехід виглядав природним (корекція світла,
тіней та шуму).
Технічна реалізація на Android/iOS:
Для такого складного редагування критично важливо використовувати
Shaders (програми для графічного процесора). Це дозволяє змінювати мільйони
пікселів одночасно без втрати кадрів (FPS).
Реалізація всіх функцій редагування (заміна, видалення, стилізація) у
реальному часі перетворює додаток на потужний комбінований інструмент. Для
цього алгоритм працює як багатошаровий конвеєр обробки даних.
Повний технічний алгоритм функціонування такого універсального додатка:
1. Етап сегментації та розпізнавання (AI Layer)
Додаток не просто бачить картинку, він «розуміє» її геометрію та зміст:
Сегментація об’єктів: Нейромережа (наприклад, DeepLabV3 або MediaPipe)
розділяє кадр на маски: «небо», «людина», «автомобіль», «рекламний щит»,
«підлога».
Детекція глибини (Depth Sensing): Використовуючи дві камери смартфона
або LiDAR, додаток будує карту відстаней. Це дозволяє зрозуміти, які об'єкти
знаходяться ближче, а які далі, щоб коректно накладати ефекти (наприклад, сховати
віртуальний об'єкт за реальне дерево).
2. Етап обробки та редагування (Processing Layer)
Залежно від обраної дії, спрацьовує відповідний суб-алгоритм:
7
482 ЧДТУ 21982-01 34 01
Заміщення (Replacement): На місце розпізнаної маски (реклами чи предмета)
накладається нова текстура або 3D-модель, яка підлаштовується під перспективу за
допомогою гомографії.
Видалення (Inpainting): Вибраний об'єкт «вирізається», а порожнеча
заповнюється сусідніми пікселями фону або текстурою, що генерується
нейромережею в реальному часі.
Зміна атрибутів: Шейдери (GLSL/Metal) змінюють колір, яскравість або
прозорість конкретної маски об'єкта, не чіпаючи решту кадру.
3. Етап AR-стабілізації (Tracking Layer)
Щоб відредаговані елементи не «пливли» при русі:
SLAM (Simultaneous Localization and Mapping): Додаток постійно зіставляє
дані з камери та гіроскопа. Якщо ви замінили колір стіни і повернули телефон,
алгоритм перераховує позицію стіни відносно камери 60 разів на секунду.
Light Estimation: Додаток аналізує освітлення в кімнаті та автоматично
підлаштовує яскравість і тіні на відредагованих ділянках, щоб вони виглядали
природно.
4. Етап виводу (Output Layer)
Композитинг: Всі шари (реальне відео + маски + AR-об'єкти + виправлений
фон) зливаються в один фінальний кадр.
Запис: При натисканні кнопки зйомки, цей потік кодується у формат MP4 або
JPEG з високою роздільною здатністю.
Технічні виклики:
Для стабільної роботи такого широкого функціонала на Android та iOS
знадобиться динамічне керування ресурсами: якщо пристрій перегрівається, додаток
має автоматично знижувати роздільну здатність обробки, щоб підтримувати
плавність відео.
8
482 ЧДТУ 21982-01 34 01
Головне меню Web-додатку для обробки зображень в режимі реального часу,
яке знаходиться зверху, прозоре і легке для сприйняття. Зважаючи на те, що додаток
працює в режимі реального часу, всі елементи меню мають бути напівпрозорими,
щоб користувач завжди бачив, що відбувається в об’єктиві (рис. 1):
Рисунок 1. Головне меню.
Оптимальна структура головного меню для такого типу додатку:
1. Центральна робоча зона (Viewport)
Індикатор AR-стану: Маленька іконка, що показує, чи «зловив» додаток
площини та об’єкти (зелений/жовтий колір).
Сітка (Grid): Опціональна сітка для вирівнювання кадру.
2. Панель вибору режимів (Нижня частина)
Фото (Photo): Режим миттєвого знімка з уже застосованим редагуванням.
Відео (Video): Запис відео з обробкою в реальному часі.
AR-Сканер: Спеціальний режим для швидкого пошуку та автоматичного
заміщення реклами.
3. Панель інструментів редагування (Бічна або висувна)
Заміщення (Replace): Вибір контенту, який з’явиться замість реклами чи
об’єктів (галерея текстур, кольори, 3D-моделі).
Видалення (Erase): Активація інструмента «розумної гумки» для
приховування об’єктів.
Фільтри/Стилі: Накладання художніх ефектів на окремі сегменти (наприклад,
тільки на фон).
Корекція: Повзунки яскравості, контрасту та насиченості для всієї сцени.
4. Швидкі налаштування (Верхня частина)
9
482 ЧДТУ 21982-01 34 01
Спалах: Авто/Увімк/Вимк.
Перемикач камер: Перехід між основною та фронтальною (наприклад, для
AR-фільтрів на обличчі).
Налаштування (Settings): Вибір якості обробки (HD/4K), керування хмарною
синхронізацією масок реклами та параметри конфіденційності.
5. Галерея (Кутова кнопка)
Швидкий доступ до вже оброблених фото та відео.
Меню авторизації в додатку є швидким і безпечним, оскільки користувач
зазвичай хоче якнайшвидше перейти до зйомки. Для мобільного додатка на Android
та iOS використано комбінований підхід.
Структура меню авторизації:
1. Екран вітання (Welcome Screen):
Логотип додатка: Анімована іконка, що підкреслює тему AR або камери.
Слоган: Коротка фраза про те, що додаток змінює реальність.
2. Методи входу (Найважливіша частина):
Social Login (Швидкий вхід): Кнопки "Увійти з Google" та "Sign in with
Apple". Це критично для мобільних платформ, щоб користувач не вводив пароль
вручну.
Біометрія: Після першого входу додаток пропонує використовувати FaceID
або TouchID (Fingerprint) для миттєвого доступу.
Традиційний вхід: Поля для Email та пароля (з можливістю відновлення
через кнопку "Забули пароль?").
3. Реєстрація нового користувача:
Кнопка "Створити аккаунт".
Мінімальна кількість полів: Email, Пароль, Підтвердження пароля.
4. Режим гостя (Skip/Guest Mode):
Кнопка "Спробувати без реєстрації".
10
482 ЧДТУ 21982-01 34 01
Важливо: У цьому режимі можна обмежити функції (наприклад, не зберігати
історію редагувань у хмару або накладати водяний знак на відео).
5. Юридичний блок (внизу екрана):
Посилання на "Умови використання" та "Політику конфіденційності"
(особливо важливо, оскільки додаток працює з камерою).
Технічна особливість проєкту:
Оскільки додаток працює з великими обсягами графічних даних, після
авторизації можна запропонувати користувачеві синхронізацію налаштувань
(наприклад, збережені маски для заміни реклами), які будуть підтягуватися з його
профілю на будь-якому пристрої.
Головна сторінка web-додатка — це активний екран камери. Вона
максимально вільна від зайвих елементів, щоб користувач міг зосередитися на
процесі редагування реальності в реальному часі.
Детальний опис компонентів головної сторінки:
1. Фон (Active Viewport)
Живий потік з камери: На весь екран відображається зображення з камери з
уже застосованими AR-шарами (заміщена реклама, видалені об'єкти, накладені
фільтри).
2. Верхня панель (Quick Actions)
Профіль користувача: Іконка аватара (доступ до налаштувань аккаунта,
підписки).
Статус AR-системи: Колірний індикатор (зелений — поверхні розпізнано,
можна редагувати; червоний — замало світла або руху).
Керування залізом: Кнопки спалаху, перемикання між передньою та задньою
камерами та вибір роздільної здатності (наприклад, HD/4K).
3. Робочі зони редагування (Overlay)
11
482 ЧДТУ 21982-01 34 01
Смарт-виділення: При натисканні на будь-який об’єкт у кадрі (наприклад, на
рекламний щит), навколо нього з’являється тонка неонова рамка, що підтверджує
готовність до редагування.
Контекстні підказки: Текстові повідомлення, що зникають (наприклад,
"Наведіть на рекламу для заміни").
4. Нижня панель керування (Main Control)
Кнопка затвора (Shutter): Велика центральна кнопка. Одиночне натискання
— фото, тривале — запис відео.
Селектор режимів: Горизонтальна прокрутка (Свайп) між режимами:
Scan (автопошук реклами);
Edit (ручне редагування об'єктів);
Classic (звичайна зйомка).
Галерея: Маленьке віконце зліва з останнім зробленим знімком.
5. Бічне меню інструментів (Dynamic Tools)
Висувна панель справа, яка з'являється при виборі об'єкта:
Іконка «Смітник»: Миттєве видалення об'єкта (Inpainting).
Іконка «Магічна паличка»: Заміна об'єкта на вибрану текстуру або 3D-
модель.
Іконка «Пензель»: Зміна кольору або накладання художнього стилю.
Головна відмінність від Web-версії:
На смартфонах всі елементи керування розташовані в зоні досяжності
великого пальця, щоб користувач міг керувати обробкою зображення однією рукою,
тримаючи пристрій.

Репозиторій ЧДТУ