Основи обробки зображень Web Worker

By Technical specialist

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

Результат не є «безкоштовною фоновою обробкою». Той самий пристрій все ще виконує обчислення та використовує пам’ять. Архітектурна перевага полягає в розділенні: важка операція моделі з меншою ймовірністю заблокує кожну відповідь інтерфейсу під час роботи.

Головний потік має завдання інтерфейсу користувача

Сторінка браузера зазвичай запускає JavaScript у головному потоці. Цей потік також координує макет, малювання та введення. Якщо його займає одне довге обчислення, клацання може відбутися із затримкою, анімація може припинитися, а браузер може попередити, що сторінка не відповідає.

Редактор зображень має багато обов’язків основного потоку ще до початку висновку:

• отримати вибір файлу, вставити або скинути;
• декодувати та відображати зображення;
• оновлення прогресу та станів помилок;
• намалювати полотно попереднього перегляду;
• обробка руху пензля Add і Erase;
• підготувати дії щодо завантаження або буфера обміну.

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

Межа на основі повідомлень

Редактор і працівник не мають спільних звичайних змінних. Вони спілкуються, надсилаючи повідомлення. Спрощений потік виглядає так:

1. Редактор створює або повторно використовує воркер.
2. Він просить працівника ініціалізувати середовище виконання висновків і модель.
3. Він готує дані зображення та надсилає запит на висновок.
4. Працівник перетворює дані в очікувані вхідні дані моделі.
5. Працівник запускає модель і створює значення маски.
6. Він надсилає маску або дані результату назад.
7. Редактор комбінує попередній перегляд і дозволяє вдосконалення або експорт.

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

Копіювання та передача даних зображення

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

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

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

Що Easy Background Remover вкладає в робітник

Easy Background Remover використовує Web Worker із середовищем виконання висновків браузера для сегментації на пристрої. Важкий автоматичний крок вирізання створює маску. Редактор потім відображає складений результат і підтримує уточнення пензля CPU-полотна.

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

Це також робить заяву про локальну обробку зрозумілою. Надсилання пікселів зі сторінки розширення до її власного робочого елемента є зв’язком у середовищі браузера, а не завантаженням у віддалений API вирізу. Під час першого сеансу можна окремо завантажити ресурс моделі багаторазового використання; див. Чому перший запуск завантажує модель.

Воркер не робить обчислення миттєво

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

Залишається кілька обмежень:

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

Запуск п’яти робочих висновків для п’яти зображень не є автоматичним у п’ять разів швидшим. Робітники використовують одну машину. Паралельні завдання можуть конкурувати за пропускну здатність пам’яті та ресурси виконання, тоді як кожен екземпляр моделі може мати власну вартість пам’яті.

Звітування про хід є кооперативним

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

Деякі фази мають вимірну кількість байтів. Одне виконання моделі може показувати лише «розпочате» та «закінчене». Плавний відсоток, який рівномірно змінюється, може бути радше косметичним, ніж точним вимірюванням.

Корисний інтерфейс прогресу називає фазу, коли це можливо: підготовка моделі, обробка зображення або результат створення. Він також обробляє невдачу та скасування замість того, щоб залишати спінер без пояснень.

Скасування - це більше, ніж приховування лічильника

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

Завершення робітника є вирішальним, але воно відкидає його початковий стан. Для наступного завдання може знадобитися знову завантажити та ініціалізувати модель. Для короткої операції позначення результату несвіжим може бути дешевшим, ніж усе зносити.

Правильний вибір залежить від обсягу пам’яті, тривалості роботи та можливостей виконання. З точки зору користувача, важливим правилом є те, що застаріла робота не повинна перезаписувати поточне редагування.

Помилки теж повинні перетинати межі

Виняток усередині робочого елемента не стає звичайним винятком основного потоку. Воркер повинен повідомляти про придатні для використання помилки, а редактор повинен прислухатися до помилок на рівні робочого.

Хороша обробка помилок відрізняє принаймні:

• модель активу недоступна;
• не вдалося ініціалізувати модель;
• помилка декодування або підготовки введення зображення;
• висновок не вдалося;
• працівник несподівано зупинився;
• результат більше не належить до поточного запиту.

Це більш дієво, ніж загальне «щось пішло не так», особливо коли налаштування під час першого запуску та звичайна обробка зображення мають різні способи усунення.

Робочий вихід - це лише перша маска

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

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

Коротка ментальна модель

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

• редактор володіє взаємодією;
• робітник володіє важким завданням висновку;
• дані бінарного зображення перетинають визначену межу;
• робітник повертає маску, а не закінчене судження про кожну грань;
• редактор залишається відповідальним за поточний стан, перегляд, уточнення та експорт.

Щоб переглянути модель самих пікселів, перегляньте Що бачить модель вирізу на пристрої. Щоб отримати наскрізний практичний огляд, перегляньте Як працює локальне фонове видалення.