Základy zpracování obrazu přes Web Worker

By Technical specialist

Web Worker je samostatný kontext spouštění JavaScriptu, který zvládne těžké výpočty, aniž by veškerou práci dělalo hlavní vlákno editoru. U zpracování obrazu v prohlížeči to znamená, že příprava modelu a výpočet mohou běžet mimo vlákno tlačítek, progressu, štětce a překreslení obrazovky.

Výsledek není „zpracování pozadí zadarmo“. Stále počítá stejné zařízení a spotřebovává paměť. Výhoda je oddělení: těžký běh modelu méně pravděpodobně zablokuje každou odezvu rozhraní.

Hlavní vlákno má úlohu uživatelského rozhraní

Stránka prohlížeče normálně spouští JavaScript v hlavním vláknu. Toto vlákno také koordinuje rozložení, malování a vstup. Pokud jej zabere jeden dlouhý výpočet, kliknutí se mohou zdát opožděná, animace se může zastavit a prohlížeč může varovat, že stránka nereaguje.

Editor obrázků má spoustu povinností týkajících se hlavních vláken ještě předtím, než začne vyvozování:

• přijímat výběr souboru, vložit nebo upustit;
• dekódovat a zobrazit obrázek;
• aktualizovat průběh a chybové stavy;
• nakreslete náhledové plátno;
• rukojeť pohybu štětce Add and Erase;
• připravit akce stahování nebo schránky.

Vložením numerické práce segmentačního modelu do stejného vlákna by tyto úkoly přímo soutěžily. Pracovník vytváří jasnější hranici.

Hranice založená na zprávě

Editor a pracovník nesdílejí běžné proměnné. Komunikují prostřednictvím zpráv. Zjednodušený postup vypadá takto:

1. Editor vytvoří nebo znovu použije pracovníka.
2. Požádá pracovníka o inicializaci inferenčního běhového prostředí a modelu.
3. Připraví obrazová data a odešle požadavek na odvození.
4. Pracovník převede data na očekávaný vstup modelu.
5. Pracovník spustí model a vytvoří hodnoty masky.
6. Odešle masku nebo data výsledku zpět.
7. Editor složí náhled a umožní upřesnění nebo export.

Zprávy by měly obsahovat dostatek kontextu, aby odpovídaly odpovědi na správný požadavek. To je důležité, pokud si uživatel před dokončením předchozí úlohy vybere jiný obrázek. Rozhraní se musí vyvarovat zobrazení starého výsledku přes nový zdroj.

Kopírování a přenos obrazových dat

Odeslání malé textové zprávy je levné. Odesílání milionů hodnot pixelů může být drahé, pokud prohlížeč musí kopírovat celou vyrovnávací paměť. Webová rozhraní API mohou místo toho převádět vlastnictví určitých binárních vyrovnávacích pamětí. Přenesená vyrovnávací paměť bude k dispozici příjemci, aniž by na straně odesílatele zůstal použitelný duplikát.

Tato optimalizace přichází s omezením návrhu: po přenosu nemůže odesílatel nadále používat stejnou vyrovnávací paměť, jako by stále vlastnil data. Editor si může ponechat samostatnou reprezentaci zobrazení, vytvořit vyhrazenou vyrovnávací paměť nebo později rekonstruovat, co potřebuje.

Ne každá implementace používá přenos na úplně stejná místa. Obecnou lekcí je, že oddělením vláken nezmizí pohyb dat. Rozměry obrázku, velikost vyrovnávací paměti a počet převodů stále ovlivňují latenci a paměť.

Co Easy Background Remover vkládá do pracovníka

Easy Background Remover používá Web Worker s inferenčním runtime prohlížečem pro segmentaci na zařízení. Těžký krok automatického vyříznutí vytváří masku. Editor pak zobrazí složený výsledek a podporuje upřesnění štětce CPU-canvas.

Toto oddělení dává poruchám užitečnější hranici. Pokud se pracovník nemůže inicializovat nebo se během odvození zhroutí, může rozhraní hlásit chybu související s pracovníkem místo toho, aby se spoléhalo na trvale zamrzlou kartu jako jediný signál.

Udržuje také srozumitelnost požadavku místního zpracování. Odesílání pixelů ze stránky rozšíření jejímu vlastnímu pracovníkovi je komunikací v prostředí prohlížeče, nikoli nahráváním do vzdáleného rozhraní API. První relace může samostatně stáhnout aktivum opakovaně použitelného modelu; viz Proč první spuštění stáhne model.

Pracovník neprovádí výpočet okamžitě

Pracovníci zlepšují odezvu, nikoli nezpracované schopnosti zařízení. Model stále spotřebovává CPU, GPU nebo jiné runtime zdroje podle toho, co může prohlížeč poskytnout. Velký vstup může stále trvat déle a vyžadovat více paměti než malý.

Zůstává několik limitů:

• inicializace modelu má skutečné náklady;
• vyrovnávací paměti pixelů zabírají při kopírování paměť na obou stranách;
• změna velikosti a převod formátu nějakou dobu trvá;
• zařízení s nízkou pamětí se mohou potýkat s velkými obrázky;
• více pracovníků může zvýšit spor namísto jeho snížení;
• export a aktualizace plátna mohou stále zahrnovat hlavní vlákno.

Spuštění pěti inferenčních pracovníků pro pět obrázků není automaticky pětkrát rychlejší. Dělníci sdílejí stejný stroj. Paralelní úlohy mohou soutěžit o šířku pásma paměti a prostředky pro provádění, zatímco každá instance modelu může nést své vlastní náklady na paměť.

Hlášení o pokroku je kooperativní

Pracovník může posílat stavové zprávy, ale automaticky neví, jaké procento pokroku bude přesné. Stažení modelu, inicializace za běhu, příprava vstupu, odvození, převod masky a vykreslování náhledu jsou samostatné fáze s různým načasováním.

Některé fáze mají měřitelný počet bajtů. Jedno provedení modelu může odhalit pouze „zahájeno“ a „dokončeno“. Hladké procento, které postupuje rovnoměrně, proto může být spíše kosmetické než přesné měření.

Užitečné uživatelské rozhraní postupu pojmenovává fázi, pokud je to možné: příprava modelu, zpracování obrazu nebo výsledek stavby. Zvládá také selhání a zrušení namísto ponechání spinneru bez vysvětlení.

Zrušení je víc než skrytí spinneru

Pokud uživatel zavře obrázek nebo začne znovu, rozhraní může ignorovat případnou odpověď na zastaralý požadavek. Okamžité zastavení základního výpočtu může vyžadovat další podporu ze strany běhového prostředí nebo ukončení a opětovné vytvoření pracovníka.

Ukončení pracovníka je rozhodující, ale zahodí jeho inicializovaný stav. Další úloha možná bude muset znovu načíst a inicializovat model. Na krátkou operaci může být označení výsledku zašlé levnější než bourání všeho.

Správná volba závisí na tlaku paměti, době trvání operace a možnostech běhu. Z pohledu uživatele je důležité pravidlo, že zastaralá práce nesmí přepsat aktuální úpravu.

Chyby musí také překročit hranici

Výjimka uvnitř pracovníka se nestane běžnou výjimkou hlavního vlákna. Pracovník musí hlásit použitelné chyby a editor by měl naslouchat selháním na úrovni pracovníka.

Dobré zpracování chyb rozlišuje alespoň:

• modelové aktivum není k dispozici;
• inicializace modelu se nezdařila;
• dekódování obrazu nebo příprava vstupu se nezdařila;
• odvození se nezdařilo;
• pracovník se neočekávaně zastavil;
• výsledek již nepatří k aktuálnímu požadavku.

To je akčnější než obecné „něco se pokazilo“, zvláště když nastavení při prvním spuštění a normální zpracování obrazu mají různá řešení.

Výstup pracovníka je stále pouze první maskou

Architektura vlákna sama o sobě nezlepšuje nejednoznačnou hranu. Pracovník může vrátit technicky platnou masku, které ještě chybí kožešina, průhledný materiál, úzká ramínka nebo požadovaný stín. To jsou otázky segmentace a záměru.

Úloha editora se po zpracování obnoví: upravte měřítko masky do pracovního souřadnicového systému, složte náhled, nechte uživatele upřesnit a exportujte aktuální stav. Rozlišení masky vs. velikost náhledu vysvětluje, proč by se tyto souřadnicové systémy neměly zaměňovat.

Stručný mentální model

Představte si pracovníka jako místního specialistu za oknem se zprávou:

• editor vlastní interakci;
• pracovník vlastní úlohu těžkého vyvozování;
• binární obrazová data překračují definovanou hranici;
• pracovník vrací masku, nikoli hotový úsudek o každé hraně;
• editor zůstává odpovědný za aktuální stav, kontrolu, upřesnění a export.

Chcete-li zobrazit samotné pixely modelu, pokračujte částí Co vidí model výřezu na zařízení. Kompletní praktický přehled naleznete v části Jak funguje místní odstranění na pozadí.