Discussion :

[progfou]

Il existe une transformée rapide de Hough

[jlf]

Il existe une transformée rapide de Hough)

j'ai un peu regardé et effectivement dans le principe ça a l'air de bien coller à mon pbm
mais je bute toujours sur le même truc :
sachant que chaque pixel de ma bille est sensiblement différent de ses voisins (eclairage), et que chaque pixel du contour est également différent de ses voisins (fond non uniforme dans l'espace autour de la bille), comment détecter le contour, par quel genre d'algo ?

faut-il au préalable "réduire" les couleurs, pour faire en sorte par exemple que tout les pixels à dominante jaune soient colorés d'un jaune unique (je ne sais même pas si c'est possible), ou cette méthode de Hough peut-elle s'accomoder de couleurs différentes dans les cercles/elipses dont on recherche les contours ?

il y a quelque part des libs d'implémentation, voire des exemples et des commentaires du code ?

la formule que je t'ai donné cherche à savoir quel pixel (u,v) se rapproche le plus du pixel (i,j)
Ensuite p et q sont les indices de ta somme (p va de -I à +I et q de -J à +J)

oui mais tu fais un produit de deux pixels dans tes sommes, c'est le produit de quoi :
- de chacune des couches RGB (je sommerais 3 fois pour obtebir un vecteur en 3D)
- de la couleur globale prise comme un scalaire unique
- autre chose ?

et cette somme des produits de pixels deux à deux a quelle signification, pourquoi multiplier des pixels plutot que par exemple les soustraire ?
décidément cette matière m'échappe beaucoup

tu veux suivre le mouvement de ta boule dans le temps (avoir des vecteurs de déplacement dans le temps pour chaque pixel de la boule) ou simplement savoir à chaque moment où est la boule ?

je comprends pas ce que tu veux dire ?

[/quote]

[progfou]

Pourquoi tu ne passes pas du RGB au YUV pour tester ?

[jlf]

Pourquoi tu ne passes pas du RGB au YUV pour tester ?

je veux bien mais pour essayer quel algo ?

[mathieu_t]

Salut!

oui mais tu fais un produit de deux pixels dans tes sommes, c'est le produit de quoi :
- de chacune des couches RGB (je sommerais 3 fois pour obtebir un vecteur en 3D)
- de la couleur globale prise comme un scalaire unique
- autre chose ?

Si ta boule est jaune (et que les autres ne le sont pas), fais la corrélation pour une image en niveaux de gris correspondant au jaune ( I_gris = (G+B)/2 ) par exemple...

et cette somme des produits de pixels deux à deux a quelle signification, pourquoi multiplier des pixels plutot que par exemple les soustraire ?
décidément cette matière m'échappe beaucoup

C'est une multiplication car c'est de cette façon qu'on fait une corrélation : cela vient de théorèmes matheux (probas) et du traitement du signal qui décrivent le dégré de ressemblance entre deux signaux...

tu veux suivre le mouvement de ta boule dans le temps (avoir des vecteurs de déplacement dans le temps pour chaque pixel de la boule) ou simplement savoir à chaque moment où est la boule ?

Il y a 2 approches possibles au suivi temporel : déterminer le mouvement de la boule (à chaque pixel de la boule déterminer un vecteur vitesse dans chaque image), ou suivre simplement la boule (avoir par exemple un rectangle qui s'affiche sur chaque image pour dire ou est la boule)... Je disais qu'à mon avis c'était la seconde option que tu voulais...

sachant que chaque pixel de ma bille est sensiblement différent de ses voisins (eclairage), et que chaque pixel du contour est également différent de ses voisins (fond non uniforme dans l'espace autour de la bille), comment détecter le contour, par quel genre d'algo ?

Si tu te mets en niveaux de gris (moyenne pondérée des 3 couleurs), tu détecteras facilement les ellipses. Ensuite pour savoir laquelle est la bonne, fait une corrélation dans le domaine RGB ou YUV