Conceptos básicos de procesamento de imaxes de Web Worker

By Technical specialist

Un traballador web é un contexto de execución de JavaScript separado que pode realizar cálculos caros sen facer que o fío principal do editor faga todo o traballo. Para o procesamento de imaxes do navegador, isto significa que a configuración e inferencia do modelo poden fuxir do fío responsable dos botóns, as mensaxes de progreso, a entrada de pincel e as actualizacións da pantalla.

O resultado non é “procesamento en segundo plano gratuíto”. O mesmo dispositivo aínda realiza o cálculo e usa memoria. O beneficio arquitectónico é a separación: é menos probable que unha operación de modelo pesada bloquee todas as respostas da interface mentres se executa.

O fío principal ten un traballo de interface de usuario

Unha páxina do navegador normalmente executa JavaScript nun fío principal. Ese fío tamén coordina o deseño, a pintura e a entrada. Se un cálculo longo o ocupa, os clics poden sentirse atrasados, a animación pode deterse e o navegador pode avisar de que a páxina non responde.

Un editor de imaxes ten moitas responsabilidades de fío principal antes de que comece a inferencia:

• recibir unha selección de ficheiros, pegar ou soltar;
• decodificar e mostrar unha imaxe;
• actualizar os estados de progreso e erro;
• debuxa o lenzo de vista previa;
• xestionar o movemento do pincel Engadir e borrar;
• preparar accións de descarga ou portapapeis.

Poñer no mesmo fío o traballo numérico dun modelo de segmentación faría que esas tarefas compitan directamente. Un traballador crea un límite máis claro.

O límite baseado en mensaxes

O editor e o traballador non comparten variables comúns. Comunícanse enviando mensaxes. Un fluxo simplificado ten o seguinte aspecto:

1. O editor crea ou reutiliza un traballador.
2. Pídelle ao traballador que inicie o tempo de execución e o modelo da inferencia.
3. Prepara datos de imaxe e envía unha solicitude de inferencia.
4. O traballador converte os datos na entrada esperada do modelo.
5. O traballador executa o modelo e produce valores de máscara.
6. Devolve a máscara ou os datos do resultado.
7. O editor compoñen a vista previa e permite o refinamento ou a exportación.

As mensaxes deben incluír o contexto suficiente para facer coincidir unha resposta coa solicitude correcta. Isto importa se un usuario escolle outra imaxe antes de que remate o traballo anterior. A interface debe evitar mostrar un resultado antigo sobre unha fonte nova.

Copiando e transferindo datos de imaxe

Enviar unha pequena mensaxe de texto é barato. Enviar millóns de valores de píxeles pode ser caro se o navegador ten que copiar todo o búfer. As API web poden transferir a propiedade de determinados búfers binarios. Un búfer transferido queda dispoñible para o receptor sen conservar un duplicado utilizable no lado do remitente.

Esa optimización vén cunha restrición de deseño: despois da transferencia, o remitente non pode seguir usando o mesmo búfer coma se aínda fose propietario dos datos. Un editor pode conservar unha representación de visualización separada, crear un búfer de inferencia dedicado ou reconstruír o que necesita máis tarde.

Non todas as implementacións usan a transferencia exactamente nos mesmos lugares. A lección xeral é que a separación de fíos non fai desaparecer o movemento de datos. As dimensións da imaxe, o tamaño do búfer e o número de conversións aínda afectan á latencia e á memoria.

O que Easy Background Remover pon no traballador

Easy Background Remover usa un Web Worker cun tempo de execución de inferencia do navegador para a segmentación no dispositivo. O paso de corte automático pesado produce unha máscara. A continuación, o editor mostra o resultado composto e admite o refinamento do pincel de lenzo da CPU.

Esta separación dá aos fallos un límite máis útil. Se o traballador non pode inicializarse ou falla durante a inferencia, a interface pode informar dun erro relacionado co traballador en lugar de depender dunha pestana permanentemente conxelada como único sinal.

Tamén mantén comprensible a reclamación de procesamento local. Enviar píxeles desde unha páxina de extensión ao seu propio traballador é unha comunicación dentro do contorno do navegador, non unha carga a unha API de recorte remota. A primeira sesión pode descargar por separado o recurso do modelo reutilizable; consulta Por que a primeira execución descarga un modelo.

Un traballador non fai computación instantánea

Os traballadores melloran a capacidade de resposta, non a capacidade do dispositivo bruto. O modelo aínda consume CPU, GPU ou outros recursos de tempo de execución segundo o que poida proporcionar o navegador. Unha entrada grande aínda pode levar máis tempo e requirir máis memoria que unha pequena.

Quedan varios límites:

• a inicialización do modelo ten un custo real;
• os búfers de píxeles ocupan memoria nos dous lados se se copian;
• O cambio de tamaño e a conversión de formato levan tempo;
• os dispositivos con pouca memoria poden loitar con imaxes grandes;
• máis traballadores poden aumentar a contenda en lugar de reducila;
• As actualizacións de exportación e lenzos aínda poden implicar o fío principal.

Comezar cinco traballadores de inferencia para cinco imaxes non é automaticamente cinco veces máis rápido. Os traballadores comparten a mesma máquina. Os traballos paralelos poden competir polo ancho de banda de memoria e os recursos de execución, mentres que cada instancia do modelo pode levar o seu propio custo de memoria.

Os informes de progreso son cooperativos

Un traballador pode enviar mensaxes de estado, pero non sabe automaticamente cal é a porcentaxe de progreso que se sentirá precisa. A descarga do modelo, a inicialización do tempo de execución, a preparación da entrada, a inferencia, a conversión de máscaras e a visualización previa son fases separadas con diferentes tempos.

Algunhas fases teñen contas de bytes medibles. Unha única execución do modelo só pode expoñer “iniciado” e “acabado”. Unha porcentaxe suave que avanza uniformemente pode, polo tanto, ser cosmética máis que unha medición precisa.

A IU de progreso útil nomea a fase cando sexa posible: preparación do modelo, procesamento da imaxe ou resultado da construción. Tamén xestiona fallos e cancelacións en lugar de deixar un xiro sen explicación.

A cancelación é máis que ocultar un spinner

Se o usuario pecha unha imaxe ou comeza de novo, a interface pode ignorar a resposta eventual da solicitude desactualizada. Deter o cálculo subxacente inmediatamente pode requirir apoio adicional do tempo de execución ou finalizar e recrear o traballador.

Despedir a un traballador é decisivo, pero descarta o seu estado inicializado. É posible que o seguinte traballo teña que cargar e inicializar o modelo de novo. Para unha operación curta, marcar o resultado obsoleto pode ser máis barato que derrubar todo.

A elección correcta depende da presión da memoria, da duración da operación e das capacidades de execución. Desde a perspectiva do usuario, a regra importante é que o traballo obsoleto non debe sobrescribir a edición actual.

Os erros tamén deben cruzar o límite

Unha excepción dentro dun traballador non se converte nunha excepción normal do fío principal. O traballador debe informar de erros utilizables e o editor debe escoitar os fallos a nivel de traballador.

Un bo manexo de erros distingue polo menos:

• Activo modelo non dispoñible;
• fallou a inicialización do modelo;
• Fallou a decodificación da imaxe ou a preparación da entrada;
• fallou a inferencia;
• o traballador parou inesperadamente;
• o resultado xa non pertence á solicitude actual.

Isto é máis práctico que un xenérico “algo saíu mal”, especialmente cando a configuración de primeira execución e o procesamento normal de imaxes teñen diferentes remedios.

A saída dos traballadores aínda é só unha primeira máscara

A arquitectura de subprocesos non mellora por si só un bordo ambiguo. O traballador pode devolver unha máscara tecnicamente válida que aínda lle falte pelaje, material transparente, correas estreitas ou unha sombra desexada. Esas son preguntas de segmentación e intención.

O traballo do editor retómase despois da inferencia: escala a máscara ao sistema de coordenadas de traballo, compoñen unha vista previa, deixa que o usuario a perfeccione e exporte o estado actual. Resolución de máscara vs tamaño de vista previa explica por que non se deben confundir eses sistemas de coordenadas.

Un modelo mental conciso

Pense no traballador como un especialista local detrás dunha xanela de mensaxes:

• o editor é o propietario da interacción;
• o traballador é propietario da pesada tarefa de inferencia;
• os datos de imaxe binaria cruzan un límite definido;
• o traballador devolve unha máscara, non un xuízo acabado sobre cada bordo;
• o editor segue sendo responsable do estado actual, a revisión, o perfeccionamento e a exportación.

Para ver os propios píxeles do modelo, continúa con O que ve un modelo de recorte no dispositivo. Para obter unha visión xeral práctica de extremo a extremo, consulta Como funciona a eliminación de fondo local.