Bonjour à tous.

J'aimerais avoir un coup de main sur le problème suivant:
Je recherche une technique sous Python pour pouvoir suivre un objet sur l'écran (j’entends par là une image, un sprite ou quoi que ce soit de ce style) en temps réel, à l'image de ce que peut faire OpenCV pour le motion tracking sur une WebCam.

J'ai beau googler, je trouve pas, je retombe toujours sur OpenCV en ce qui concerne le motion ou object tracking en temps réel mais ça concerne uniquement les sources camera, d'où mon soucis puisque j'aimerais que le programme suive (par exemple) une balle d'un jeu de casse brique (en flash) sur mon écran.

Il n'y aucune donnée qui me parviens, à part un retour visuel (je vois uniquement la balle se déplacer, je n'ai pas de coordonnées, ni rien du genre).

Je précise que j'ai déjà essayé une technique qui est d'utiliser la PIL (Python Image Library) pour capturer l'écran tous les dixièmes de secondes et y chercher la fameuse balle mais c'est pas du tout optimale comme technique pour ce genre d'utilisation:
-Soit le programme galère car je lui demande de faire trop de captures à la seconde, soit le tracking est pas suffisant car les captures sont trop lentes, même sur une parcelle réduite de l'écran.
-Je suis bien conscient que c'est à cause du fait que le programme se sert de captures compilées comme une image, d'où ma recherche d'un système où je pourrais me servir d'une capture continue en temps réel de l'écran

Donc je m'en remet à la communauté pour trouver une nouvelle idée.

Par le traitement d'image c'est normal que ça soit lent.

Tu peux essayer de trouver un outil qui mesure que les changements d'image pour que ça prenne moins de place (comme en format mp4)

Sinon tu peux essayer avec une approche système en allant chercher dans les tréfonds de windows la position des trucs

La question est qu'est ce qui prend du temps, c'est l'acquisition du framebuffer, ou l'analyse de l'image?

Je pense que les deux sont en cause, l'acquisition sans sauvegarde en fichier est assez rapide mais l'analyse se fait (du moins c'est la manière la plus sûre que j'ai trouvé de procéder) par balayage, on part de (0,0) jusqu'au coin inférieur droit de la zone capturé et on y cherche la couleur de la balle, ce qui d'ailleurs ne fonctionne pas si la même couleur est présente dans la décor du jeu, pour palier à ça je recherche le sprite précis de la balle dans la capture mais c'est évidemment encore plus lent.
Bref, c'est beaucoup trop lent, donc l'idéal serait d'avoir une sorte de flux de capture à (par exemple) 15 fps qui me permettrait de définir la position de départ et grâce à une vitesse donnée approximativement de la balle, de la rechercher près de sa position précédente vis à vis de chaque frame:
si la balle ( de 10 pixels de diamètres) se déplace de, admettons 5 pixels/frame, je donne sa position de départ à la capture 1, je regarde la capture suivante mais recherche uniquement sa position 25 pixels autours de la précédente.
En partant de ce principe, le suivis de la balle devrait se faire assez facilement.
Le principe est là, mais je ne parviens juste pas à trouver un système me fournissant les images suffisamment rapidement pour les traiter avant la capture suivante.

Je recherche donc bien quelque chose me permettant de capturer et de traiter une l'image avant que la suivante ne soit capturer, quitte à devoir capturer à 15 ou 10 fps.

Si c'est une balle tu peux claquer une transformée de Hough et vérifier tous les centres trouvés

Bon, je passe poster un message pour vous signaler que j'ai trouvé solution à mon problème et que ça pourrait en aider d'autres par la suite:
Je suis tombé sur ce post http://www.blizzhackers.cc/viewtopic.php?f=236&t=490482 de chez BlizzHacker et le 5ème post (posté le Mon Jun 11, 2012 6:54 pm ) m'a sauvé grâce à la démarche utilisé avec Opencv 2.

Voilà, bonne continuation à tous et merci tout de même pour vos réponses !

Salut, perso j'avais utilisé Pygame pour me faire un système d'alarme maison^^
Je récupérai via pygame l'image de la webcam toutes les x millisecondes, puis via la librairie PIL je comparais l'entropie de l'image (me rappelle plus exactement comment ni pourquoi) courante avec celle de l'image précédente, et au-delà d'un certain seuil je considérais que cela signifiait que quelque chose avait bougé entre les deux images. ça marchait très très bien ; rapide, simple et efficace. Mais ton problème est carrément plus dur, vu qu'il faut traquer un objet...

Je sais que tu as resolu le probleme mais: "Je pense que les deux sont en cause" me dit que tu approchais le probleme du mauvais angle. Quand tu as un probleme de performance, il faut mesurer le temps que prenne les operation et avoir le coeur net de ce qui est rapide et de ce qui est lent.

Ne t'en fait pas godrik c'est ce que j'ai fait en relisant ton post, et c'était finalement l'analyse de l'image qui était trop longue.

C'est comme ça que j'ai pu me tourner vers cette solution, merci à toi.