Aller au contenu principal

Background Removal

Le but de ce prototype est de retirer un arrière plan à partir d'un modèle d'IA, en direct et avec plusieurs caméras différentes.

Attention

Testé uniquement sur Windows

Introduction​

Après la mise en place du prototype de Stream Camera, nous avons voulu récupérer le flux et y appliquer un traitement par intelligence artificielle afin de retirer le fond d'écran des personnes affichées. Ce prototoype doit donc permettre d'intégrer une personne dans un environnement virtuel en 3D.

Etapes​

Recherche des technologies​

Dans un premier temps, nous avons cherché les technologies qui devaient nous intéresser afin de faire un démonstrateur simple et rapide à mettre en place.

Détourage​

Nous avons pris le langage de programmation Python 3.10 pour la simplicité du prototypage.

Ensuite, nous avons dû prendre une technologie nous permettant de capturer l'image caméra. Nous avons pris OpenCV car c'est assez utilisé, simple à intégrer et efficace pour ce qu'on va faire.

Pour finir, la dernière chose qu'il nous fallait était la technologie permettant de détourer un individu. Ici, nous sommes partis sur un modèle d'inférence (donc déjà entraîné) CVZone SelfiSegmentator et MediaPipe SelfiSegmentator. Il existe plein d'autres modèles déjà entraînés et qui font ce qu'on va faire mais nous avons voulu faire simple pour comprendre le fonctionnement du détourage et l'inclusion dans un projet Unreal Engine. Les deux modèles choisis s'intègrent aisément avec Python et OpenCV, cela nous fait donc grandement gagner du temps.

[TODO => Image]

Serveur RTSP​

Une fois les technologies mise en place et l'élaboration du petit programme de détourage, on veut aller plus loin car à l'état actuel, le programme ne se lance qu'en local, son flux n'est jamais partagé.

Pour ce faire, il nous faut un serveur RTSP (Real Time Streaming Protocol). Ce type de serveur est ce qu'il a de plus intéressant pour faire un partage de flux vidéo en direct. Sauf que pour faire plus simple dans l'élaboration du prototype, on ne va pas réutiliser un media server comme Icecast2.

En fait, il existe quelque chose de plus simple, un exécutable sur Windows qui permet, en le lançant simplement, de générer un serveur RTSP sans configuration requise. Vous pouvez retrouver le lien du serveur RTSP ici : https://github.com/aler9/rtsp-simple-server/releases

Vous exécutez simplement l'exécutable Windows et votre serveur fonctionne.

Premiers tests sur Unreal Engine​

Une fois le serveur configuré et votre programme relié à votre serveur avec Ffmpeg, il ne reste qu'une chose à faire : tester sur Unreal Engine.

Ainsi, nous avons récupéré le flux vidéo depuis le serveur RTSP et nous l'avons envoyé à Unreal Engine grâce à une de ses fonctionnalités de base, un MediaPlayer. Le MediaPlayer est un outil qui permet de récupérer depuis une URL ou un fichier vidéo son contenu pour l'afficher.

Nous avons remarqué que le flux détouré n'était pas transparent. Ainsi, nous avons volontairement appliqué un fond vert au fond détouré pour le détourer sur Unreal Engine. Comme ça, c'est plus simple à gérer les histoires de transparence, chaque service peut ainsi détourer selon ses fonctionnalités le flux.

[TODO => Image]

Résultats​

Globalement, les résultats sont satisfaisants.

Mais il y a quelques petits problèmes à noter : le modèle du détourage ne prend pas les jambes et les mains en compte et la tolérance peut parfois découper un individu, ce qui peut poser des problèmes d'affichage dans Unreal Engine.

Autre chose à noter, c'est la latence toujours présente dans Unreal Engine, même si on ne passe pas par Icecast2, la latence reste présente, ce qui laisse supposer que soit le problème vient de Ffmpeg, soit il vient de Unreal Engine.

Tests sur les caméras​

Tous les tests effectués avant ont été faits avec la caméra intégrée à l'ordinateur. Donc, même qualité sur tous les modèles et des résultats quasi identiques.

Afin d'augmenter la qualité, on a voulu tester avec trois autres caméras à notre disposition : OAK-D, Kinect Xbox 360 et Kinect Xbox One.

Kinect Xbox 360​

[TODO => Image]

La Kinect Xbox 360 est la caméra externe utilisée pour la console de jeu Xbox 360. La Kinect 360 est sortie en 2010 et ce document écrit en 2022. Le problème vient tout de suite, lors des tests pour la brancher, on a vite remarqué un souci de compatibilité. Certes, la caméra fonctionne et est lisible mais elle n'est pas exploitable via le langage de programmation Python. Les bibliothèques telles que OpenCV ne permettent pas de lire des Kinect Xbox.

En effet, simplement brancher la caméra et la lire est impossible, il faut un logiciel spécifique pour pouvoir récupérer son flux vidéo : Windows SDK Kinect et Kinect Studio permettent de faire ça. Sauf que ces deux solutions sont des logiciels, on ne peut donc pas récupérer leur flux vidéo comme ça. Ils sont déjà programmés pour agir spécifiquement.

Du coup, si on tente de récupérer via un programme la caméra, il faut tenter de passer par une bibliothèque externe. Par exemple sur Python, il en existe une nommée Pykinect. Nous n'avons jamais réussi à faire fonctionner cette bibliothèque car elle n'est pas à jour. Par manque de moyens d'exploiter la caméra, nous avons abandonner l'idée d'utiliser la Kinect Xbox 360.

Kinect Xbox One​

[TODO => Image]

Cette fois-ci, on a testé la deuxième caméra la Kinect Xbox One.

Tout d'abord, celle-ci utilise des outils similaires à la Kinect Xbox 360 étant donné qu'elles viennent de deux générations différentes. Avec Windows SDK Kinect 2 et Kinect Studio 2, vous pouvez lire la Kinect Xbox One et tester des choses.

Théoriquement, la Kinect Xbox One est plus simple à intégrer que la Kinect Xbox 360, mais il n'en reste pas moins qu'il y a eu quelques soucis.

Premièrement, la Kinect Xbox One peut se brancher à Python grâce à une bibliothèque externe qui se nomme Pykinect2. Celle-ci s'installe facilement grâce à l'installeur de paquets Python et donc peut vite se greffer à du prototypage. Seulement, le problème est que rapidement nous avons remarqué que Pykinect2 a quelques soucis de compatibilité avec la dernière version de Python, Python 3.10. Certaines fonctions méritent d'être modifiées à cause de ce problème de compatibilité.

Deuxièmement, la Kinect Xbox One nécessite d'avoir la puissance nécessaire pour être alimentée. C'est un des soucis que nous avons rencontré et qui a été assez long à comprendre. Grâce au logiciel Kinect Studio 2, il est possible de vérifier l'état de la Kinect, si la Kinect est connectée, si elle est exploitable, etc. Seulement, avec certains ordinateurs, il est possible que le bus USB ne soit tout simplement pas assez puissant pour alimenter la Kinect, dans ce cas l'état de la Kinect passera toutes les secondes de connectée à non connectée. Ensuite, le second souci est le câble. Même si votre ordinateur est assez puissant pour lire la Kinect, il faut que le câble ne soit ni trop long, ni de mauvaise qualité car la transmission doit bien s'effectuer. Ici, il n'y a aucun autre remède que de trouver le bon équipement.

Et pour finir sur la Kinect Xbox One, nous avons malgré tout réussi à la faire fonctionner avec le même modèle d'IA que la caméra intégrée, on a pu constater que les résultats étaient un peu meilleurs que la caméra intégrée mais cela est dû au fait de la résolution et la qualité de l'image permettent une meilleure détection des couleurs.

Sur la Kinect nous avions la possibilité de la tester avec les caméras de profondeur intégrée. Tout d'abord le modèle d'IA utilisé ne permettait pas de prendre en compte la profondeur, ensuite, nous ne l'avons pas fait car il fallait déjà trouver le modèle adéquat et ne pas qu'utiliser OpenCV mais les fonctionnalités natives de la Kinect qui posent quelques soucis techniques supplémentaires. Pour allier simplicité et rapidité, nous n'avons pas utilisé la profondeur.

OAK-D​

[TODO => Image]

La dernière caméra a avoir été testée est la caméra OAK-D. Cette caméra se met en place avec Python assez facilement. Toujours grâce à Python, nous avons pu exploiter la caméra de couleur (centrale) et appliquer les modèles d'IA dessus.

Les résultats sont assez proches de la Kinect, la qualité de l'image est meilleure.

Pour conclure, il n'y a aucun souci rencontré avec cette caméra et les résultats restent attendus par rapport à la caméra intégrée.

Caméras virtuelles​

Nous avons testé trois caméras physiques (OAK-D, Kinect Xbox One et Caméra intégrée) mais avec chacune nous avons dû mettre en place une petite architecture réseau : client -> serveur RTSP -> client. Sauf si nous voulons faire une plateforme de production virtuelle en local, il faudrait éviter d'utiliser plusieurs services et d'aller au plus simple. D'où l'idée des caméras virtuelles qui pourraient servir localement.

À lire si vous êtes intéressé par ce prototype : Cliquez-ici.

Documentation technique​