Bases du traitement d’images Web Worker

By Technical specialist

Un Web Worker est un contexte d’exécution JavaScript distinct qui peut effectuer des calculs coûteux sans que le thread principal de l’éditeur fasse tout le travail. Pour le traitement des images du navigateur, cela signifie que la configuration et l’inférence du modèle peuvent s’éloigner du thread responsable des boutons, des messages de progression, de la saisie au pinceau et des mises à jour de l’écran.

Le résultat n’est pas un « traitement en arrière-plan gratuit ». Le même appareil effectue toujours le calcul et utilise la mémoire. L’avantage architectural est la séparation : une opération de modèle lourde est moins susceptible de bloquer chaque réponse d’interface pendant son exécution.

Le thread principal a un travail d’interface utilisateur

Une page de navigateur exécute normalement JavaScript sur un thread principal. Ce fil coordonne également la mise en page, la peinture et la saisie. Si un long calcul l’occupe, les clics peuvent sembler retardés, l’animation peut s’arrêter et le navigateur peut avertir que la page ne répond pas.

Un éditeur d’images a de nombreuses responsabilités en matière de thread principal avant même que l’inférence ne commence :

• recevoir une sélection de fichier, coller ou déposer ;
• décoder et afficher une image ;
• mettre à jour les états de progression et d’erreur ;
• dessiner le canevas d’aperçu ;
• gérer le mouvement du pinceau Ajouter et Effacer ;
• préparer les actions de téléchargement ou de presse-papiers.

Placer le travail numérique d’un modèle de segmentation sur le même fil rendrait ces tâches directement en concurrence. Un travailleur crée une frontière plus claire.

La limite basée sur les messages

L’éditeur et le travailleur ne partagent pas de variables ordinaires. Ils communiquent en envoyant des messages. Un flux simplifié ressemble à ceci :

1. L’éditeur crée ou réutilise un travailleur.
2. Il demande au travailleur d’initialiser le moteur d’exécution et le modèle d’inférence.
3. Il prépare les données d’image et envoie une demande d’inférence.
4. Le travailleur convertit les données en entrée attendue du modèle.
5. Le travailleur exécute le modèle et produit des valeurs de masque.
6. Il renvoie le masque ou les données de résultat.
7. L’éditeur compose l’aperçu et permet l’affinement ou l’exportation.

Les messages doivent inclure suffisamment de contexte pour faire correspondre une réponse à la demande correcte. Cela est important si un utilisateur choisit une autre image avant la fin du travail précédent. L’interface doit éviter d’afficher un ancien résultat sur une nouvelle source.

Copie et transfert de données d’image

Envoyer un petit message texte ne coûte pas cher. L’envoi de millions de valeurs de pixels peut s’avérer coûteux si le navigateur doit copier l’intégralité du tampon. Les API Web peuvent à la place transférer la propriété de certains tampons binaires. Un tampon transféré devient disponible pour le destinataire sans conserver de duplicata utilisable du côté de l’expéditeur.

Cette optimisation s’accompagne d’une contrainte de conception : après le transfert, l’expéditeur ne peut pas continuer à utiliser le même tampon comme s’il possédait toujours les données. Un éditeur peut conserver une représentation d’affichage distincte, créer un tampon d’inférence dédié ou reconstruire ce dont il a besoin ultérieurement.

Toutes les implémentations n’utilisent pas le transfert exactement aux mêmes endroits. La leçon générale est que la séparation des threads ne fait pas disparaître le mouvement des données. Les dimensions de l’image, la taille du tampon et le nombre de conversions affectent toujours la latence et la mémoire.

Ce que Easy Background Remover met chez le travailleur

Easy Background Remover utilise un Web Worker avec un runtime d’inférence de navigateur pour la segmentation sur l’appareil. La lourde étape de découpe automatique produit un masque. L’éditeur affiche ensuite le résultat composé et prend en charge le raffinement du pinceau CPU-canvas.

Cette séparation donne aux échecs une limite plus utile. Si le travailleur ne peut pas s’initialiser ou plante pendant l’inférence, l’interface peut signaler une erreur liée au travailleur au lieu de s’appuyer sur un onglet gelé de manière permanente comme seul signal.

Cela permet également de rendre compréhensible l’affirmation relative au traitement local. L’envoi de pixels d’une page d’extension à son propre travailleur est une communication au sein de l’environnement du navigateur, et non un téléchargement vers une API de découpe à distance. La première session peut télécharger séparément l’actif de modèle réutilisable ; voir Pourquoi la première exécution télécharge un modèle.

Un travailleur ne rend pas le calcul instantané

Les employés améliorent la réactivité, et non les capacités brutes des appareils. Le modèle consomme toujours du CPU, du GPU ou d’autres ressources d’exécution en fonction de ce que le navigateur peut fournir. Une entrée volumineuse peut toujours prendre plus de temps et nécessiter plus de mémoire qu’une petite entrée.

Plusieurs limites demeurent :

• l’initialisation du modèle a un coût réel ;
• les tampons de pixels occupent la mémoire des deux côtés s’ils sont copiés ;
• le redimensionnement et la conversion de format prennent du temps ;
• les appareils disposant de peu de mémoire peuvent avoir des difficultés avec les images volumineuses ;
• un plus grand nombre de travailleurs peut accroître les conflits au lieu de les réduire ;
• Les mises à jour d’exportation et de canevas peuvent toujours impliquer le thread principal.

Démarrer cinq opérateurs d’inférence pour cinq images n’est pas automatiquement cinq fois plus rapide. Les ouvriers partagent la même machine. Les tâches parallèles peuvent rivaliser pour la bande passante mémoire et les ressources d’exécution, tandis que chaque instance de modèle peut avoir son propre coût en mémoire.

Les rapports d’avancement sont coopératifs

Un travailleur peut envoyer des messages de statut, mais il ne sait pas automatiquement quel pourcentage de progression sera précis. Le téléchargement du modèle, l’initialisation de l’exécution, la préparation des entrées, l’inférence, la conversion du masque et le rendu de l’aperçu sont des phases distinctes avec un timing différent.

Certaines phases ont un nombre d’octets mesurable. Une seule exécution de modèle ne peut exposer que « commencé » et « terminé ». Un pourcentage lisse qui avance uniformément peut donc être une mesure cosmétique plutôt qu’une mesure précise.

L’interface utilisateur de progression utile nomme la phase lorsque cela est possible : préparation du modèle, traitement de l’image ou résultat de la construction. Il gère également les échecs et les annulations au lieu de laisser un spinner sans explication.

L’annulation est plus que cacher une roulette

Si l’utilisateur ferme une image ou recommence, l’interface peut ignorer la réponse éventuelle de la requête obsolète. L’arrêt immédiat du calcul sous-jacent peut nécessiter une prise en charge supplémentaire de la part du moteur d’exécution ou l’arrêt et la recréation du travailleur.

Terminer un travailleur est décisif, mais cela supprime son état initialisé. La tâche suivante devra peut-être charger et initialiser à nouveau le modèle. Pour une opération de courte durée, marquer le résultat comme obsolète peut être moins coûteux que de tout démolir.

Le choix correct dépend de la pression de la mémoire, de la durée de l’opération et des capacités d’exécution. Du point de vue de l’utilisateur, la règle importante est que le travail obsolète ne doit pas écraser la modification actuelle.

Les erreurs doivent également franchir les limites

Une exception à l’intérieur d’un travailleur ne devient pas une exception normale du thread principal. Le travailleur doit signaler les erreurs utilisables et l’éditeur doit écouter les échecs au niveau du travailleur.

Une bonne gestion des erreurs distingue au moins :

• actif modèle indisponible ;
• L’initialisation du modèle a échoué ;
• le décodage de l’image ou la préparation de l’entrée a échoué ;
• l’inférence a échoué ;
• le travailleur s’est arrêté de manière inattendue ;
• le résultat n’appartient plus à la requête en cours.

C’est plus exploitable qu’un générique « quelque chose s’est mal passé », en particulier lorsque la configuration de première exécution et le traitement normal de l’image ont des solutions différentes.

La sortie du travailleur n’est encore qu’un premier masque

L’architecture des threads n’améliore pas en elle-même un bord ambigu. Le travailleur peut restituer un masque techniquement valable auquel manque encore de la fourrure, du matériau transparent, des bretelles étroites ou une ombre souhaitée. Ce sont des questions de segmentation et d’intention.

Le travail de l’éditeur reprend après l’inférence : redimensionnez le masque dans le système de coordonnées de travail, composez un aperçu, laissez l’utilisateur l’affiner et exportez l’état actuel. Résolution du masque par rapport à la taille de l’aperçu explique pourquoi ces systèmes de coordonnées ne doivent pas être confondus.

Un modèle mental concis

Considérez le travailleur comme un spécialiste local derrière une fenêtre de message :

• l’éditeur est propriétaire de l’interaction ;
• le travailleur est propriétaire de la lourde tâche d’inférence ;
• les données d’image binaires franchissent une limite définie ;
• le travailleur rend un masque, et non un jugement fini sur chaque bord ;
• l’éditeur reste responsable de l’état actuel, de la révision, du perfectionnement et de l’exportation.

Pour voir la vue du modèle sur les pixels eux-mêmes, continuez avec Ce que voit un modèle de découpe sur l’appareil. Pour un aperçu pratique de bout en bout, consultez Comment fonctionne la suppression de l’arrière-plan local.