Navigateurs compatibles et performances de la suppression d'arrière-plan côté client

Ce que le navigateur doit fournir

Un outil de suppression d'arrière-plan côté client tourne dans une page web : chaque capacité dont il a besoin doit être exposée par le navigateur, pas installée. Quatre comptent, et un appareil à qui il en manque une seule ne peut pas faire tourner l'outil.

WebAssembly exécute le modèle dans le bac à sable du navigateur, ce qui garde les images d'un outil côté client sur votre appareil ; bgremover.ai les envoie au contraire sur nos serveurs GPU, comme l'explique comment fonctionne la suppression d'arrière-plan. L'inférence consiste surtout en multiplications de matrices : elle réclame un GPU. WebGL en expose un via une API graphique, WebGPU via une API de calcul.

Sans l'un ni l'autre, l'inférence se rabat sur le CPU. Il faut aussi quelque chose pour encoder les images finales dans un fichier : MediaRecorder, la voie la plus répandue, ou WebCodecs, la plus fine. La quatrième exigence, la mémoire pour les images décodées, est la plus sous-estimée.

Trois voies d'exécution

WebGL est un contournement plutôt qu'une vraie conception : l'API a été faite pour dessiner des triangles, et faire transiter les données par des textures prend du temps. Elle reste le choix par défaut en pratique. WASM monopolise le thread principal sauf si le travail passe dans un worker, et BEN2 exige WebGPU en FP16, donc uniquement des GPU récents sur ordinateur.

C'est la disponibilité qui décide, pas la préférence : un outil qui n'implémente que WebGPU est rapide là où il tourne et absent partout ailleurs.

Pourquoi la première exécution est plus lente

1. 1 Le modèle se télécharge une fois

   Avant le traitement de la moindre image.

2. 2 Il s'initialise et chauffe

   Puis la première image passe.

3. 3 Les vidéos suivantes sautent ces deux étapes

   Servi depuis le cache, il ne reste que l'initialisation.

Un outil côté client devrait donc charger le modèle sur une action de l'utilisateur, pas au chargement de la page : des mégaoctets de WebAssembly qui arrivent dès votre arrivée donneraient l'impression d'une page cassée à quiconque venait simplement lire.

Le calcul des images décodées

Une image vidéo décodée, ce sont des pixels non compressés : la résolution domine donc la mémoire.

Ces chiffres sont des calculs, pas des mesures, et la taille du fichier compressé est un mauvais indicateur. Rien n'exige de décoder toutes les images à la fois, mais la chaîne garde un ensemble de travail : l'image en cours de décodage, celle en cours de segmentation, son masque, la composition et le tampon de l'encodeur.

Multipliez quelques images par 33 Mo en 4K et le budget d'un onglet commence à compter, surtout sur téléphone. Si une longue vidéo en haute résolution échoue ou que l'onglet se recharge, réduisez la résolution plutôt que la durée : diviser chaque dimension par deux divise la mémoire par quatre.

Ce qui détermine le temps de traitement

Ce sont des relations, pas des chiffres : un temps mesuré sur un ordinateur portable ne dit rien d'un téléphone.

• Nombre d'imagesDurée multipliée par la fréquence d'images ; 60 i/s, c'est le double de 30 i/s.
• RésolutionPèse sur le décodage, la composition et l'encodage ; l'inférence reste fixe.
• Voie d'exécutionWebGPU, WebGL et WASM-SIMD diffèrent sur une même machine.
• Type d'appareilLes GPU d'ordinateur fixe, de portable et de téléphone sont trois machines différentes.
• Choix du modèleLe matting coûte plus cher par image que MediaPipe.
• État thermiqueUn travail GPU soutenu sur un téléphone chaud est bridé.

Matrice de compatibilité des navigateurs

Une vérification navigateur par navigateur s'impose ici avant que le site n'annonce une compatibilité universelle. Ce que nous pouvons affirmer sans test relève de l'architecture : un outil côté client a besoin de WebAssembly et d'une voie GPU, pas de WebGPU. bgremover.ai a besoin de WebCodecs, qu'il utilise pour préparer l'envoi et construire l'export.

La réalité honnête sur mobile

Pour un outil côté client, c'est la légèreté de la segmentation selfie MediaPipe qui rend les navigateurs mobiles viables. Quelques mégaoctets et des besoins mémoire modestes tiennent dans le budget d'un onglet sur téléphone ; un modèle pour GPU d'ordinateur, non. bgremover.ai contourne le problème en faisant tourner son modèle sur des serveurs GPU ; le téléphone décode et encode tout de même la vidéo.

Nous n'annoncerons pas de compatibilité mobile universelle avant d'avoir testé chaque navigateur. Le mobile est plus difficile : moins de mémoire par onglet, des onglets déchargés sans ménagement, un bridage thermique. Des vidéos plus courtes en résolution plus basse sont la voie fiable, et les photos passées dans l'outil pour supprimer le fond d'une photo ne coûtent qu'une image.

Questions fréquentes