Transport for London (TfL, qui gère les réseaux de bus et de métro de la capitale britannique) a utilisé un logiciel de machine learning pour analyser en temps réel le flux de vidéos enregistrées par les caméras de surveillance de la station de Willesden Green, au nord-ouest de la ville. Le but : tenter de détecter les comportements agressifs, les cas dans lesquels des armes à feux ou des couteaux seraient brandis par des usagers, les chutes sur les rails et les cas de fraude.
Selon des documents obtenus par Wired, l’entreprise a testé une dizaine d’algorithmes de vision assistée par ordinateur d’octobre 2022 à septembre 2023 pour réaliser ces analyses.
Wired explique que les documents montrent comment les modèles d'IA ont été utilisés pour détecter les fauteuils roulants, les poussettes, les fumeurs, les personnes accédant à des zones non autorisées ou se mettant en danger en s'approchant du bord des quais de gare.
Ils indiquent aussi les erreurs relevées au fil des tests : des enfants qui suivent leurs parents signalés comme potentiels fraudeurs, l’impossibilité de discerner des vélos non pliables de leur pendant pliant, etc.
Avant la pandémie, Willesden Green brassait plus de 25 000 personnes par jours.
En décembre, TfL a déclaré qu’elle prévoyait d’étendre ses tests à d’autres stations londoniennes
Commentaires (8)
#1
Les tests sont nombreux et pointent tous dans la même direction: la fiabilité des algo et des filtres de traitements est plutôt faible compte tenu de l'objectif en terme de sûreté et de sécurité publique.
La faute à la source (le flux vidéo) dont la qualité est très variable et qui ne permet pas d'avoir une analyse homogène. La caméra est d'abord conçue et mise en œuvre pour ce cas d'usage de transmission d'un flux vidéo destiné à être enregistré et/ou affiché sur un moniteur. Le cas d'usage de l'analyse vidéo, est une surcouche qui repose sur un analyse des images produites sur un flux compressé (H26x) en temps réel/différé dont l'algo doit exclure un grand nombre de caractéristiques (pénombre, bruit, B/P frames incomplètes, définition, ..) de limitation optique ( géométrie, focale, sensibilité,.. ) que l'on peut qualifier de bruit.
La voie prise est donc celle du 2 en1 mais cela ne fonctionne simplement pas.
A mon avis, lorsque les caméras auront leur propre capteur/moteur dédié à l'analyse, les choses seront sans doute différentes.
#1.1
L'article ne laisse pas supposer que ça ne fonctionne pas. Il n'y a pas de chiffre indiquant le rapport de faux positifs ni si ça a impacté négativement le travail des agents de sécurité. On reste sur des systèmes d'alertes à destination d'opérateurs humains, les faux positifs ne sont pas un problème en soi. Au pire, les agents n'en tiendront plus compte si c'est beaucoup trop fréquent et ils bosseront "à l'ancienne".
Le fait de ne pas pouvoir distinguer un vélo non-pliable d'un pliable n'est pas une preuve que le système ne peut pas fonctionner. Juste que le modèle de l'IA n'a pas été entraîné pour ça encore.
#1.3
L'infra peut rester commune, c'est parfait pour ça. Non le soucis est bien dans la conception de la caméra elle-même dont le capteur est conçu pour un usage précis produire des images pour générer un flux vidéo.
Un second capteur dédié à l'analyse m'apparait bien plus pertinent pour traiter et mettre à disposition d'un logiciel d'autres types d'informations (spectrales, doppler, ..).
Dans ce cas, de plus, cela permettrait de répartir la charge global du calcul de l'analyse sur tous les équipement sources et ainsi d'éviter d'avoir à recourir à de l'infra dédiées par exemple (note que c'est déjà le cas pour certains fabricants qui propose une ouverture de leur produit vers des solutions type plugin embraqué sur l'analyse d'image).
Ce n'est pas un problème d'IA mais bien d'image source qui n'est pas souvent appropriée à ce type d'analyse et de scenarios attendus. Exemple, dans le cadre d'une solution de comptage du type A->B B<-A.
Le meilleur résultat sera sans doute de positionner une caméra qui perpendiculaire au sol, de tracé une ou deux lignes virtuelles (ie: avec zone blanche de discrimination) pour délimiter les zones A et B. Il y a déjà pas mal de paramètres optique à prendre en compte (contraste, luminosité,..), puis propre au contexte d'analyse (enfants, animaux,..) et scénarios (entrée et sortie rapide, objets positionnés sur le ligne de partage de zone, etc etc). Dans tous les cas, le gout global pour ce cas d'étude sera de plusieurs milliers d'euros.
Et cela dans le but de remplacement une cellule photo électrique dont le coût est de 10-15€ avec une fiabilité supérieure (en terme de comptage on est d'accord).
#1.7
Forcément, oui pour faire de la détection de passage, y a plus adapté mais ce n'est pas du tout le sujet de la news ^^
#1.2
Mais je dirais que plus il est complexe, plus il a intérêt à être fait hors caméra surtout dans un cadre de vidéosurveillance de ville ou de toutes manières tous les flux sont enregistrés avec des durées légales.
La compression est efficace, les réseaux aussi, pas de raison de se priver des évolutions rapides côté traitement en collant cela sur des caméras qui seront alors toutes à mettre à jour (logiciellement, avec un % d'échec/briquage à chaque fois ; voir matériellement sous 2 ou 3 ans si on veut rester au top) individuellement.
Désolé, mais c'est vraiment un cadre qui justifie un traitement temps réel centralisé.
Le traitement dans la caméra ne se justifie que pour des cas d'usage de particulier surveillant sa baraque, visant à ne récupérer que "l'info utile" (séquences de captures via envoi mail ou NAS/FTP local existant, typiquement intégrés dans les cam IP) ce qui évite de charger son LAN avec un streaming permanent, sauf à faire un double réseau via un NVR.
#1.4
Si l'enregistrement sur voie publique est encadré par la Loi, je ne crois pas que l'analyse vidéo le soit compte tenu notamment du résultat des différents pilotes menés notamment par les "villes intelligentes" . L'analyse vidéo est quand même un sujet qui, depuis au moins 15 ans, a monopolisé bien des discussions mais sans réel avancée en raison d'une efficacité opérationnelle qui est loin d'être satisfaisante à part dans les présentation des éditeurs qui laisse penser que l''IA' c'est ce qu'il manquait au produit pour être utilisable.
C'est bien la preuve que la voie de la mutualisation du flux vidéo aux fins d'analyses n'est pas une réussite.
C'est pourquoi, une autre voie me semble plus pertinente à utiliser et rien n'empêchera d'ajouter de synchroniser les flux vidéos et les flux d'analyse issues de capteurs spécialisés* sous la forme de métadonnées exploitables en terme d'interface graphique et/ou de base de données.
Donc oui à la mutualisation mais dans un objectif opérationnel qualifié.
* par capteurs spécialisés, comprendre : capteurs ajoutés à une caméra ou un capteurs externes dont les données traitées peuvent être pertinentes dans un contexte de vidéo surveillance
#1.5
Historique des modifications :
Posté le 16/02/2024 à 09h27
Je ne pense pas qu'ajouter des capteurs aux caméras installées soit réaliste: D'abord car cela aura un coût (achat et installation contre système centralisé d'analyse) puis si analyser par l'image des scènes complexes n'est pas une si grande réussite (au moins chez nous) je peine à imaginer quelque chose qui puisse faire mieux... D'ailleurs, la Chine qui semble inspirer certains y arrive et cela alimente leur riant système de crédit social. Quand ils éprouvent le besoin d'en faire plus, pour les minorités surveillées, c'est l'espion que chacun porte désormais avec lui qui est mis à contribution avec une appli traçage et écoute obligatoire! Orwell l'a prophétisé, Tonton Xi l'a fait.
#1.6
Le surcoût 'analyse' ajouté à une caméra et compte tenu des composants et logiciels mis en œuvre, ce ne devrai pas être plus de +20%. Sachant que ce qui coûte le plus cher est souvent l'installation et la mise en œuvre, ce poste étant mutualisé, il ne coûte rien de plus ou peut être un peu de main d'oeuvre pour tests et réglages mais pas de moyen supplémentaire de levage, de génie civil et autres joyeusetés.
Donc en bout de ligne, si on compare une infra complété par l'analyse d'image et un modèle embarqué, je pense que ce serait plutôt en faveur de la caméra en fait. A voir.