Merci pour cet article car je pense que beaucoup fantasme les capacités d'analyse des caméras et/ou des logiciels de vidéosurveillance.
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.

La voie prise est de réutiliser l'infrastructure de capture vidéo déjà en place et de profiter de l'avancée sur l'IA en matière de reconnaissance pour justement pouvoir gérer toutes ces fluctuations.

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).

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.

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).

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.

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

Une infra d'analyse centralisée à aussi un cout: matériel, infra, énergie, foncier, maintenance et support..

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.