Le présent article débat des questions relatives à une technologie d'analyse d'images embarquée dans les caméras. Aujourd'hui, les applications d'analyse d'images sont de plus en plus riches (intrusion, comportement, objet abandonné, foule -comptage, panique, chutes au sol-, plaques d'immatriculation, visages, feu, fumée, ...)...

Les demandes des utilisateurs, et notamment des villes et sites de foules sont plus nombreuses, et en même temps les utilisateurs trouvent séduisante et pas chère une approche low-cost avec l'analyse d'images embarquée dans la caméra. Qu'est-ce qui est réellement possible ?

Nous faisons le point ici sur ce sujet. On connaît aujourd’hui (2017) deux types d’offres d’analyse intelligente d’images, l’analyse embarquée dans les caméras (edge) et l’analyse sur serveur (PC et/ou système à base de FPGA/DSP). L’analyse embarquée présente différents avantages sur le serveur : le prix, en général plus faible ; l’intégration à la supervision, fournie via le framework caméra ; et un déploiement plus léger, puisqu’il n’y a pas de serveur. Cependant, la situation actuelle permet-elle d’en espérer les mêmes performances ? Ce document fait le point sur cette question.

Les caméras de CCTV ont une consommation électrique limitée par différentes contraintes : la norme POE ; la compacité, et l’installation dans les caissons du marché, qui limitent la capacité de dissipation ; et enfin la plage de températures sur laquelle la caméra doit fonctionner, notamment le seuil haut (ex : 50°C ou parfois plus). En dehors du cas particulier de la fonction de dégivrage ou de la motorisation de la caméra, la consommation électrique de la partie « image » des caméras du marché est en général de l’ordre de 5 à 10 W, couvrant la partie capteur, électronique, et processeur, sachant que l’arrivée d’un processeur dans les caméras a été rendue nécessaire pour la compression du signal (notamment H.264 aujourd’hui et bientôt H.265).

La puissance disponible pour un processeur de traitement d’analyse d’images intégré dans une caméra est donc en général celle d’un processeur (avec souvent un co-processeur parallèle de type DSP/FPGA pour l’encodage) consommant entre 3 et 6 W, dont une partie est dédiée à un encodage à consommation variable, selon la taille des images et le nombre de flux mis à disposition du client. Cette contrainte donne un caractère aléatoire à la puissance de calcul (CPU) effectivement disponible (parfois, le traitement peut être incompatible avec l'émission de plusieurs flux ou de certains formats de flux).

De plus, avec cette limite de 3 à 6 W, la puissance globale de traitement du calculateur embarqué, pour traiter l'image de la caméra est aujourd'hui celle d’un ARM8 84 MIPS @ 72 MHz (Hanwa), ou d’un ARTPEC (AXIS). La puissance d'un tel calculateur n'est que de quelques pourcents (1 à 10%) de celle utilisée habituellement sur un serveur (intel core i7), même quand ce serveur traite 8 à 12 caméras.

La question qui se pose alors la suivante : Comment adapter les algorithmes d’analyse d’images pour réduire leur consommation CPU de 90 à 95% ?

Première piste : le sampling

Il s’agit ici de réduire la consommation CPU du logiciel en n’analysant pas toutes les images de la vidéo. Si cette technique peut convenir pour une fonction d’estimation de densité de personnes, ou l’analyse d’une plaque d’immatriculation ou d’un visage sur une image prise dans le flux, on peut difficilement l’appliquer à une problématique d’analyse comportementale (intrusion, contre-sens, …) qui nécessite un tracking de la cible, et un suivi continu de la situation. A raison d’une image analysée sur 10 ou sur 20, pour reporter la puissance de calcul disponible, on ne peut plus correctement suivre et apparier les cibles à l’image (cela dépend beaucoup de la vitesse des cibles, et de la taille de la zone de détection, mais on peut imaginer des véhicules à un carrefour, ou des personnes traversant un couloir de périmétrie, dont le temps de passage sera trop réduit pour pouvoir les détecter). On va manquer des cibles. Enfin, dans le cas où les silhouettes sont peu visibles (au loin) ou peu distinctes (l’imagerie thermique) comme sur la photo ci-dessus, il peut être important de connaître l’ordre des personnes, et, en ne les voyant pas se doubler du fait d’un traitement trop espacé, on perd cette information. En conclusion, des analyses photographiques ponctuelles peuvent être envisagées moyennant une synchronisation pertinente de la prise d’image pour les déclencher sur la bonne image, et pas trop souvent.

Seconde piste : la compression spatiale

Il s’agit ici de réduire la consommation CPU du logiciel en traitant une image plus petite, de façon aller plus vite. Pour pouvoir réduire le temps CPU de l’analyse de 90 ou 95 %, à partir d’une image de 352 x 288 pixels comme celle-ci-dessous à gauche, donc parvenir à une image d’environ 80 pixels par 60, ce qui revient à analyser l’image de droite :

Les cibles de la scène (en rouge), d’une taille pourtant assez importante dans l’image, même si elles ne sont pas très contrastées, deviennent très peu discernables dans l’image analysée. La personne de gauche ne représente plus que 6 ou 7 pixels. Ceci a pour effet de réduire énormément la portée de détection du logiciel, et de diminuer également la capacité du logiciel à détecter des cibles très lentes. Ainsi, pour une caméra avec une ouverture de 40° dont la portée de détection dépasserait facilement 100 m pour un utilisateur souhaitant détecter des cibles jusqu’à une surface de 20 pixels, afin d’avoir une bonne sécurité en cas de temps de brouillard, ou de cible camouflée, ce même choix, dans l’image compressée imposée par le calculateur embarqué sur la caméra, réduit la portée de la caméra de cent à une vingtaine ou une trentaine de mètres, tout au plus, si le contraste est marqué, à performances égales. De fait, en examinant les brochures de la plupart des détecteurs embarqués, on constate cette faible portée, qui implique une forte augmentation du nombre de caméras à installer, et donc un renchérissement important du système de protection, notamment parce que la caméra, le poteau, le tirage de câbles, les slots d’enregistrement sont des facteurs multiplicatifs du nombre de caméras. Une économie de 80% ou même 100% sur le logiciel d’analyse (cas du logiciel gratuit) qui augmente le nombre de caméras, ne serait-ce que de 10%, rend une installation plus chère, du fait du coût unitaire de la caméra installée (généralement entre 5 K€ et 15 K€ sur les projets), très supérieur à celui de l’analyse d’images.

Enfin, la capacité de reconnaître une activité et celle de mesurer une vitesse deviennent très faibles, du fait du format réduit de l’image. L’incertitude augmente, ainsi que le niveau de bruit de l’analyse.

Troisième piste : la détection locale

Dans cette approche, il s’agit de concentrer l’énergie disponible du petit processeur sur le tracé de la ligne ou de la zone de détection, afin de détecter un franchissement. Voici un exemple, dans le cas où on veut détecter des personnes franchissant une ligne de droite à gauche :

Dans ce cas, si la ligne ou les lignes représentent la hauteur de l’image, le maintien de quelques pixels de part et d’autre de la ligne ne pourra pas dépasser 2 ou 3 % de la surface de l’image.

Les techniques de traitement d’images utilisées sont alors très particulières :

On procède sur la zone à une analyse du mouvement des pixels pour déterminer l’existence d’un mouvement. L’analyse du mouvement des pixels est basée sur une équation de flot optique comme celle de Horn et Schunck, qui permet de relier les écarts de luminosité des pixels avec leur mouvement (et notamment la vitesse). Une fois calculée sur les pixels voisins de la ligne, cette équation indique l’existence d’un franchissement de la ligne à un endroit, sa largeur sur l’axe de la ligne, et sa vitesse. En effectuant le produit de la vitesse par la durée, on obtient une estimation de sa longueur.

On peut alors calibrer le logiciel comme sur l’image ci-contre pour définir un seuil de taille de détection adapté à la perspective, comme illustré par les gabarits rouge dessinés ci-contre. On n’a pas de perte de portée de détection comme dans la solution précédente.

L’équation présente par contre des faiblesses sur les cibles globalement peu ou pas contrastées (on ne voit alors passer que l’avant et l’arrière de la cible, par exemple dans le cas d’un camion de couleur uniforme), ou bien on voit très mal si la cible a des parties peu contrastées par rapport au fond à l’endroit où elle franchit la ligne.

N’ayant pas de recul sur le mouvement et la taille globale de la cible dans l’image, la détection du franchissement est assez bruitée et incertaine, surtout au premier plan. Les cibles effectuant une pénétration grâce à un mouvement rasant et progressif sur la ligne sont très difficilement détectées (entrée rasante). Par contre, sur une image en couleur et bien contrastée, il est possible de faire du comptage de flux de personnes ou d’objets « courts » de façon assez fiable, notamment dans le cas de personnes franchissant la ligne assez rapidement. Le cas du « lurking », c’est-à-dire de personnes se dandinant sur la ligne de comptage (un bouchon, un opérateur de contrôle), produit des écarts et réduit beaucoup la précision du comptage. Enfin, cette technique limite l’analyse d’images à la simple détection du franchissement de ligne, fonction qui est effectivement unanimement mise en avant par les solutions edge, au détriment de solutions plus sophistiquées. Cette approche couvre donc finalement l’intrusion « franche » sur une ligne, ou le comptage, avec des limites à la précision accessible.

Quatrième piste : la détection dans l’espace compressé

Dans cette approche, il s’agit d’utiliser les images compressées (hier MPEG4, aujourd’hui H.264, demain H.265) sans les décompresser pour bénéficier de certains traitements de compression, essentiellement pour ne pas mettre à jour la détection dans les zones de l’image qui ne changent pas, et pour bénéficier de l’analyse du mouvement déjà intégrée dans la compression.

Cette approche suppose un développement complet et spécifique d’un logiciel dédié. Les travaux de recherche qui ont été menés en amont par la communauté scientifique (publications) laissent espérer un gain de consommation CPU de l’ordre d’un facteur 2. Les signaux faibles, comme par exemple les toutes petites cibles, sont noyés dans le bruit, et impliqueront soit des algorithmes spécifiques, soit seront négligés.

Par ailleurs, c’est l’utilisateur qui configure les formats des flux compressés qu’il attend de la caméra. Si on impose un certain format pour l’analyse d’images, on va mobiliser la fonction de compression de la caméra pour ce format et réduire les capacités de streaming de la caméra, ou alors disposer d’une analyse d’images embarquée dont les performances dépendront du format du ou des flux requis.

Globalement, le gain en CPU semble trop faible, et les aléas de mise en œuvre trop risqués pour investir dans cette voie.

Conclusion : Attendre !

La loi de Moore qui caractérisait l’évolution en puissance des processeurs en fonction de leur taille, de leur coût, et de leur consommation électrique, a trouvé ses limites début 2016 [1] . Cependant, la puissance des calculateurs augmente encore et leur taille et consommation se réduit toujours. Il est donc vraisemblable que d’ici quelques années, des processeurs plus puissants à consommation réduite pourront être utilisés dans la fabrication des caméras, jusqu’à atteindre des niveaux où la capacité de traitement permettra de préserver les fonctionnalités et la portée de détection, et surtout de gérer en parallèle plusieurs applications (comportement, foule, visages, plaques d'immatriculations, fumée, ...) comme le souhaitent les utilisateurs.