Bàsics del processament d’imatge amb Web Worker
Un Web Worker és un context JavaScript separat que pot fer càlculs pesats sense carregar tot el treball al fil principal de l’editor. En el processament d’imatge al navegador, això vol dir que la preparació del model i la inferència poden passar en segon pla.
El resultat no és «processament gratuït de fons». El mateix dispositiu encara calcula i usa memòria. El benefici és la separació: una operació pesada té menys probabilitat de bloquejar cada resposta de la interfície.
El fil principal té un treball d’interfície d’usuari
Una pàgina del navegador normalment executa JavaScript en un fil principal. Aquest fil també coordina el disseny, la pintura i l’entrada. Si l’ocupa un càlcul llarg, els clics poden sentir-se retardats, l’animació es pot aturar i el navegador pot advertir que la pàgina no respon.
Un editor d’imatges té moltes responsabilitats de fil principal fins i tot abans que comenci la inferència:
- rebre una selecció de fitxer, enganxar o deixar anar;
- descodificar i mostrar una imatge;
- actualitzar els estats de progrés i error;
- dibuixar el llenç de vista prèvia;
- manejar el moviment del pinzell Afegeix i esborra;
- preparar accions de baixada o porta-retalls.
Posar el treball numèric d’un model de segmentació en el mateix fil faria que aquestes tasques competeixin directament. Un treballador crea un límit més clar.
El límit basat en missatges
L’editor i el treballador no comparteixen variables ordinàries. Es comuniquen enviant missatges. Un flux simplificat és el següent:
- L’editor crea o reutilitza un treballador.
- Demana al treballador que inicialitzi el temps d’execució i el model d’inferència.
- Prepara les dades d’imatge i envia una sol·licitud d’inferència.
- El treballador converteix les dades en l’entrada esperada del model.
- El treballador executa el model i produeix valors de màscara.
- Envia la màscara o les dades del resultat.
- L’editor crea una composició de la vista prèvia i permet el perfeccionament o l’exportació.
Els missatges han d’incloure prou context per fer coincidir una resposta amb la sol·licitud correcta. Això importa si un usuari tria una altra imatge abans que finalitzi el treball anterior. La interfície ha d’evitar mostrar un resultat antic sobre una font nova.
Còpia i transferència de dades d’imatge
Enviar un petit missatge de text és barat. L’enviament de milions de valors de píxels pot ser car si el navegador ha de copiar tot el buffer. Les API web poden transferir la propietat de determinats buffers binaris. Un buffer transferit està disponible per al receptor sense conservar un duplicat utilitzable al costat del remitent.
Aquesta optimització ve amb una restricció de disseny: després de la transferència, el remitent no pot seguir utilitzant el mateix buffer com si encara fos propietari de les dades. Un editor pot conservar una representació de visualització separada, crear un buffer d’inferència dedicat o reconstruir el que necessita més endavant.
No totes les implementacions fan servir la transferència exactament als mateixos llocs. La lliçó general és que la separació de fils no fa desaparèixer el moviment de dades. Les dimensions de la imatge, la mida de la memòria intermèdia i el nombre de conversions encara afecten la latència i la memòria.
El que Easy Background Remover posa al treballador
Easy Background Remover utilitza un treballador web amb un temps d’execució d’inferència del navegador per a la segmentació al dispositiu. El pas pesat de tall automàtic produeix una màscara. Aleshores, l’editor mostra el resultat compost i admet el refinament del pinzell del llenç de la CPU.
Aquesta separació dóna a les fallades un límit més útil. Si el treballador no pot inicialitzar-se o falla durant la inferència, la interfície pot informar d’un error relacionat amb el treballador en lloc de confiar en una pestanya permanentment congelada com a únic senyal.
També manté comprensible la reclamació de processament local. L’enviament de píxels des d’una pàgina d’extensió al seu propi treballador és una comunicació dins de l’entorn del navegador, no una càrrega a una API de retallada remota. La primera sessió pot descarregar per separat l’actiu del model reutilitzable; vegeu Per què la primera execució baixa un model.
Un treballador no fa el càlcul instantani
Els treballadors milloren la capacitat de resposta, no la capacitat del dispositiu en brut. El model encara consumeix CPU, GPU o altres recursos en temps d’execució segons el que pugui proporcionar el navegador. Una entrada gran encara pot trigar més temps i requerir més memòria que una de petita.
Queden diversos límits:
- la inicialització del model té un cost real;
- els buffers de píxels ocupen memòria a banda i banda si es copien;
- El canvi de mida i la conversió de format requereixen temps;
- els dispositius amb poca memòria poden tenir problemes amb imatges grans;
- més treballadors poden augmentar la contenció en lloc de reduir-la;
- Les actualitzacions d’exportació i llenç encara poden implicar el fil principal.
Iniciar cinc treballadors d’inferència per a cinc imatges no és automàticament cinc vegades més ràpid. Els treballadors comparteixen la mateixa màquina. Els treballs paral·lels poden competir per l’amplada de banda de la memòria i els recursos d’execució, mentre que cada instància del model pot comportar el seu propi cost de memòria.
Els informes de progrés són cooperatius
Un treballador pot enviar missatges d’estat, però no sap automàticament quin percentatge de progrés se sentirà precís. La descàrrega del model, la inicialització del temps d’execució, la preparació de l’entrada, la inferència, la conversió de la màscara i la visualització prèvia són fases separades amb un temps diferent.
Algunes fases tenen recomptes de bytes mesurables. Una única execució del model només pot exposar “iniciat” i “acabat”. Per tant, un percentatge suau que avança uniformement pot ser estètic més que una mesura precisa.
La interfície d’usuari de progrés útil anomena la fase quan és possible: preparació del model, processament de la imatge o resultat de la construcció. També gestiona el fracàs i la cancel·lació en lloc de deixar un filador sense cap explicació.
La cancel·lació és més que amagar un spinner
Si l’usuari tanca una imatge o torna a començar, la interfície pot ignorar la resposta eventual de la sol·licitud obsoleta. Aturar immediatament el càlcul subjacent pot requerir suport addicional del temps d’execució o finalitzar i recrear el treballador.
El cessament d’un treballador és decisiu, però descarta el seu estat inicialitzat. És possible que el treball següent s’hagi de carregar i inicialitzar de nou el model. Per a una operació curta, marcar el resultat obsolet pot ser més barat que enderrocar-ho tot.
L’elecció correcta depèn de la pressió de la memòria, la durada de l’operació i les capacitats d’execució. Des de la perspectiva de l’usuari, la regla important és que el treball obsolet no ha de sobreescriure l’edició actual.
Els errors també han de creuar el límit
Una excepció dins d’un treballador no es converteix en una excepció normal del fil principal. El treballador ha d’informar dels errors utilitzables i l’editor ha d’escoltar els errors a nivell de treballador.
Un bon maneig d’errors distingeix almenys:
- L’actiu del model no està disponible;
- La inicialització del model ha fallat;
- La descodificació de la imatge o la preparació d’entrada ha fallat;
- la inferència ha fallat;
- el treballador es va aturar inesperadament;
- el resultat ja no pertany a la sol·licitud actual.
Això és més actiu que un genèric “alguna cosa va sortir malament”, sobretot quan la configuració de primera execució i el processament normal d’imatges tenen remeis diferents.
La sortida dels treballadors encara és només una primera màscara
L’arquitectura de fil no millora per si mateixa una vora ambigua. El treballador pot retornar una màscara tècnicament vàlida que encara falti pelatge, material transparent, corretges estretes o una ombra desitjada. Aquestes són preguntes de segmentació i intencions.
El treball de l’editor es reprèn després de la inferència: escala la màscara al sistema de coordenades de treball, compositeu una vista prèvia, deixeu que l’usuari la perfeccioni i exporteu l’estat actual. Resolució de la màscara vs mida de la vista prèvia explica per què aquests sistemes de coordenades no s’han de confondre.
Un model mental concís
Penseu en el treballador com un especialista local darrere d’una finestra de missatge:
- l’editor és el propietari de la interacció;
- el treballador és propietari de la pesada tasca d’inferència;
- les dades d’imatge binària creuen un límit definit;
- el treballador retorna una màscara, no un judici acabat sobre cada extrem;
- l’editor segueix sent responsable de l’estat actual, la revisió, el perfeccionament i l’exportació.
Per a la vista del model dels propis píxels, continueu amb El que veu un model de retall al dispositiu. Per obtenir una visió pràctica d’extrem a extrem, vegeu Com funciona l’eliminació de fons local.