# Gnral Dveloppement > Algorithme & Mathmatiques > Traitement d'images >  compter le nombre de personnes prsentes

## contremaitre

Bonjour

J'aimerai,  partir d'images vido, estimer le nombre de personnes prsentes dans une zone (zone assez petite, nombre de personnes entre 0 et 3 par exemple).

Essais : 
* soustraction image actuelle / image de rfrence. Problme : trop sensible aux changement de luminosit du capteur video.

* soustraction entre deux images successives (problme : depends de la vitesse du mouvement : si peu de mouvement, diffrence trs faible voire nulle, si mouvement trop rapide, diffrence trop forte).

* detection de bord sur chaque image puis soustraction entre deux images de bord successives -> j'obtient les bords de la silhouette.

Pour estimer le nombre de personne : soit faire une estimation de la surface de prsence, soit essayer de dcouper des zones et compter (mais probleme si deux personnes trop proches).

Pour faire une estimation de la surface de prsence, le problme c'est qu'il faudrait dterminer une zone  partir de la dtection de bord par exemple.
Mais les contours ne sont pas forcment ferms, et essayer de les fermer prends trop de temps.
J'avais pens  calculer des ellipses englobant les personnes et calculer leurs surfaces, mais je n'y suis pas encore arriv.

Je bloque donc sur :
	- Dcoupage des zones de mouvement pour ensuite compter
	- Calcul d'une ellipse englobante

Et avez vous d'autres ides?

merci

----------


## ToTo13

Bonjour,

la meilleure ide est sans doute de faire de la bibliographie sur le sujet. C'est un problme encore largement trait en recherche et tu trouveras un bon nombre d'articles pour t'orienter.

Sinon, les soustractions d'images fonctionnent rarement pour toutes les raisons que tu viens de citer.
Donc comme tu l'as compris, il vaut beaucoup mieux compter le nombre de visages que tu as sur UNE image. L encore, encore plus de bibliographie disponible sur le sujet et en plus il a t trait sur le forum et PseudoCode  donn des liens me semble t-il.
Par contre, il faut faire attention au placement de ta camra : au dessus => pas de visages mais des ttes,  l'horizontale => des visages mais certains sont masqus, ... Donc dis nous dans quelle situation tu es ?

----------


## pseudocode

Pour faire une "background substraction" il faut conserver un pool d'image (circulaire dans le temps) . Le background est calcul en faisant un filtrage median sur un meme pixel au cours du temps.



```

```

----------


## contremaitre

merci pour vos premieres rponse.
Pour la situation je pensai l'avoir dit, j'ai oubli : c'est en vue de dessus, donc je ne vois pas les visages, mais c'est pour viter une personne cach derriere une autre. 

Pour le background substraction : j'ai dj essay ca aussi, c'est pas trop mal pour rgler les problme de changement de luminosits, mais une personne immobile sera trop rapidement effac. Et ca ne regle pas les problmes de comptages une fois les zones de prsences dtects.

----------


## pseudocode

> Pour le background substraction : j'ai dj essay ca aussi, c'est pas trop mal pour rgler les problme de changement de luminosits, mais une personne immobile sera trop rapidement effac.


Utilise un hystrsis: une fois que la cible est detecte (|foreground|>seuilHaut) elle reste marque jusqu'a ce qu'elle disparaisse (|foreground|<seuilBas).




> Et ca ne regle pas les problmes de comptages une fois les zones de prsences dtects.


Tu as essay quelles methodes de dtection de blob ?

----------


## contremaitre

> Tu as essay quelles methodes de dtection de blob ?


Aucune encore, je ne connaissais pas.
Laquelle me conseille tu, sachant que mon problme va etre de dtecter deux personnes assez proches? Et que la vitesse de calcul est importante.

Merci

----------


## pseudocode

> Aucune encore, je ne connaissais pas.Laquelle me conseille tu, sachant que mon problme va etre de dtecter deux personnes assez proches? Et que la vitesse de calcul est importante.


Tout dpend de tes images. 

Les detecteurs te donnent des zones (rectangulaires, elliptiques,...) qui contiennent "probablement" une cible. A toi de dcider si la zone contient en ralit 0, 1 ou plusieurs cibles.

Pour ton probleme de proximit, tu peux commencer par dfinir une taille maximum pour une zone. Si la zone est trop grande, tu peux considerer qu'il y a plusiseurs cibles dedans. 

Pour la vitesse, pas de probleme. C'est tres rapide: quelques centaines de millisecondes...

----------


## contremaitre

trs bien, je regarde ca alors.
Mais quelques centaines de millisecondes ca dpend de la taille des images par contre je suppose.
Dans une video  25 images secondes il y a seulement 40 ms pour les calculs  ::): 
Merci

----------


## pseudocode

> trs bien, je regarde ca alors.
> Mais quelques centaines de millisecondes ca dpend de la taille des images par contre je suppose.
> Dans une video  25 images secondes il y a seulement 40 ms pour les calculs 
> Merci


Il n'y a peut-etre pas besoin de raffraichir le compteur avec une rsolution de 1/25 me de seconde....  ::roll::

----------


## contremaitre

> Il n'y a peut-etre pas besoin de raffraichir le compteur avec une rsolution de 1/25 me de seconde....


effectivement.
Pour l'instant je fait des essais  10 img secondes, mais c'est vrai que je peux reflchir  descendre encore selon la mthode choisi

----------


## themadmax

Voila un petit soft, assez basic :
http://www.codeproject.com/KB/audio-...Detection.aspx
avec background auto. ( 1 niveau par image )
Fait en C# et utilise la lib AForge http://code.google.com/p/aforge/

----------


## contremaitre

Pour la dtection de blob ca semble interessant, mais la littrature que j'ai lu sur la dtection de personnes en fait rference sans l'expliquer.
Et j'ai un peu du mal avec les notions trop mathmatique comme ici : http://en.wikipedia.org/wiki/Blob_detection

De plus dans mon cas la dtection de blob n'a pas besoin d'etre trs performante car ca sera sur des images binaires (pixels  0 ou 1, grace  un seuillage). 
Mais j'aimerai que ca soit des blob elliptiques et non rectangulaires.

Si vous avez des ressources  me proposer je suis preneur.

Merci

----------


## pseudocode

Ah ces matheux de wikipedia, toujours a compliquer les trucs simples...  ::aie:: 

Bon alors en gros, un blob c'est un "paquet" de pixels a "1" au milieu d'une zone de pixels a "0".

Un exemple de dtecteur de blob simpliste, c'est un filtre avec deux cercles concentriques: 
- on compte les pixels  1 dans le cercle central
- on compte les pixels  0 dans la couronne (entre les 2 cercles)

Si ces 2 nombres sont levs, alors le contenu du cercle central est un blob (beaucoup de 1 entours par beaucoup de 0)

Aprs on peut raffiner le procd en utilisant des ratio "pixels 1 / total pixel" au lieu de comptage absolu. On peut galement pondrer la valeur des pixels suivant qu'on est proche/loin des bords des cercles. Et puis on peut faire varier le rayon des cercles pour trouver le rayon qui "maximise" la valeur des ratio.

Transcrit en langage mathmatique, vous obtenez le dtecteur DOG (difference of gaussian)... si vous regardez la forme de la courbe DOG, on peut voir les 2 zones: pixel="1" au centre (coef positif), pixel="0" dans la couronne (coef ngatif), zro ailleurs.

----------


## contremaitre

Merci,

Alors j'ai trouv un algo qui  l'air assez simple et rapide :

Le principe est de parcourir l'image ligne par ligne.
Pour chaque ligne on numrote diffrement chaque rgion ayant des pixels adjacents. Mais les rgions qui se superposent aux rgions de la ligne prcedente rcuperent le numro de la rgion prcedente correspondante.

Cet algo est expliqu ici : Blob detection V: growing regions algorithm

Et cette librairie d'opencv d'apres ce que j'ai pu comprends utilise un peu le meme principe (voir section algorithme) : CVbloblist 

De plus, je voulais pouvoir dconnecter deux rgions pas assez connects, et ca doit pouvoir etre possible en comptant le nombre de pixels par lequels elles sont connects au fur et  mesure.

Exemple 
000000
110011
111111
110011
110011
000000

Ici on pourra compter seulement deux pixels entre les regions a gauche et a droite.

Voila, que pensez vous de cette mthode d'extraction de blob, et en connaissez vous d'autres interessantes ?

Pseudocode -> quand tu parles de filtres, je suppose qu'il faut faire autant de filtres que de taille et formes de blob qu'on veut detecter?
Le problme de l'algo dont je parle ici c'est qu'il est "rigide", si il manque quelques pixels on aura deux regions, alors qu'avec un filtre on peut detecter des rgions "parsems" de pixels  1.
Exemple Cette rgion pourrait etre considr comme un blob non? :
00000000
00101010
00010100
00110110
00000000
00111010
00000000
Merci

----------


## pseudocode

> Alors j'ai trouv un algo qui  l'air assez simple et rapide :
> 
> Le principe est de parcourir l'image ligne par ligne.
> Pour chaque ligne on numrote diffrement chaque rgion ayant des pixels adjacents. Mais les rgions qui se superposent aux rgions de la ligne prcedente rcuperent le numro de la rgion prcedente correspondante.


oui, c'est une variante du "Scanline Fill".




> Pseudocode -> quand tu parles de filtres, je suppose qu'il faut faire autant de filtres que de taille et formes de blob qu'on veut detecter?


Oui, si tu utilises des filtres sous formes de masques binaires. 

Mais c'est la que la magie des mathmatiques intervient en transformant ces masques en fonctions  plusieurs parametres. Au lieu de construire des masques de toutes les tailles/orientations possibles, on fait varier les parametres de la fonction. 

Gnralement il suffit de faire varier un seul type de parametre: l'echelle ("t"). Comme la fonction est gnralement "sympathique", on peut utiliser des methodes de convergence rapide pour trouver le meilleur "t" (newton,...). Ensuite, en jouant avec les valeurs/vecteurs propres on peut calculer directement l'orientation et la forme du blob (axes et taille de l'ellipse,...).

Les mathmatiques sont nos amies.  ::mrgreen:: 




> Le problme de l'algo dont je parle ici c'est qu'il est "rigide", si il manque quelques pixels on aura deux regions, alors qu'avec un filtre on peut detecter des rgions "parsems" de pixels  1.
> Exemple Cette rgion pourrait etre considr comme un blob non? :


Oui, tout a fait. Avec un masque carr (5x5) + bordure de 1:



```

```

ratio de 1 dans le masque: 13/25 = 52%
ratio de 0 dans la bordure: 24/24 = 100%

----------


## contremaitre

ok merci  ::): 
Et connais tu des exemples d'implementation de ces fonctions, ou des articles qui les expliquent, car je vois pas trop comment le faire moi meme.

Sinon je vais dj commencer par la variante du "Scanline Fill" avec une dilatation pour essayer de boucher quelques trous.

----------


## contremaitre

Bon voil l'algo que j'ai ecrit et que je vais essayer d'implementer.
Ce qui me fait un peu peur c'est la complexit ( O(n^4) ) n = largeur = hauteur de l'image

Alors je maintient deux listes de blob lors de mon parcours ligne par ligne:
Liste de blobs courants : les blobs qui sont encore connects  ma ligne prcedente.
Liste de blobs finaux : les blobs qui ne sont plus connects.

Pour chaque blob courrant : deux listes :
LISTE1 : liste de points de dbut/fin sur la ligne precedente.
LISTE2 : liste de points de dbut/fin sur la ligne courante.

Exemple :
0123456789
0111111110 A (ligne precedente)
0100000010 B (ligne courante)

LISTE1 = 1-8
LISTE2 = 1-1 ; 8-8

Maintenant l'algo :



```

```

Pour la complexit j'ai not les pires.
Pour le O(n^2) c'est parce que la recherche du blob dans la liste courante est en O(n) (on peut avoir au maximum n/2 blob dans cette liste) et pour chaque blob il faut chercher dans la liste de debut/fin en (O(n) : ici aussi n/2 lment maximum dans cette liste).

Un point positif tout de meme : LISTE1 et LISTE2 sont automatiquement tris car j'ajoute les points dans l'ordre.

Voyez vous des amlioration  apporter ?

Sinon je suis toujours prenneur d'autres mthodes.

Merci

----------


## pseudocode

Pas mal pour un dbut... Maintenant regardons si ca marche correctement avec le cas suivant:



```

```

----------


## contremaitre

> Pas mal pour un dbut... Maintenant regardons si ca marche correctement avec le cas suivant:
> 
> 
> 
> ```
> 
> ```


Ha oui, merci. Il faut rajouter un test : si on a un blob avec un id de cr et qu'on rencontre un autre blob sur la ligne au dessus : il faut les fusionner.

Par conte je viens de tomber par hasard sur un autre algo pour rcuperer les composantes connexes, dans ce cours page 5: images binaires
Il dit de parcourir l'image de gauche a droite et de haut en bas. On affecte une etiquette pour chaque pixel  1. Cette tiquette sera : la plus petite tiquette entre le pixel haut ou gauche si ils existent, ou une nouvelle tiquette sinon.
Ensuite il faut faire une deuxieme passe : 
Pour chaque pixel on lui affecte la plus petite tiquette parmiis les voisins bas et droite.

Il reste un probleme lors de composantes en spirales : a ce moment l il faut refaire des passes tant que des numeros changent. Mais on peut fixer une limite pour pas prendre trop de temps de calcul.

Mais je me pose la question de la complexit. Ce qui parait mieux c'est que les parcours sont seulement en O(k*n^2), k le nombre de passes necessaires... il n'y a pas de listes  parcourir.

Il parle aussi d'un parcours en une seule passe que j'ai pas bien compris. Je cite :



> Il est possible de ne faire qu'un seul parcours :
> - gestion d'une table d'equivalence d'etiquettes
> - Mise a jours recursive des etiquettes lorsque 2 etiquettes se "rencontrent"

----------


## pseudocode

Bien... Je vois que tu avances a grand pas.  ::king:: 

Le problme que tu cherches a rsoudre s'appelle pompeusement "labelisation des composantes connexes" ( ::aie:: ).

Le 1er algorithme que tu dcris s'appelle le "multi-pass line scanning" (ou qqc d'approchant). Il faut le passer jusqu' ce que les labels ne changent plus.

Les variantes  1 ou 2 passe s'appellent les algorithmes "union-find" et utilisent une table d'quivalence (ou table de connexions) et des arbres de dcisions.

Pour ton problme, je te conseille le 1er algo qui est simple  mettre en oeuvre. Tu peux limiter le nombre de passe  1 ou 2... Il y a peu de chance que tu ais des spirales dans ton cas, et meme si tu en as, elles seront juste lablises comme des blobs distincts au lieu d'un seul blob.

----------


## contremaitre

ok super  ::king:: 

Et l'algo avec des listes (celui que j'ai ecrit), il  un quelconque interet?

----------


## pseudocode

> Et l'algo avec des listes (celui que j'ai ecrit), il  un quelconque interet?


heu...non. Mais on a tous commenc par faire le mme avant de se retrouver confront aux cas tordus (spirale, finger, ...).

----------


## contremaitre

J'ai un petit problme d'implementation.
Car le but  la fin est de rcuperer les composantes connexes les plusignificatives (les composantes de 3 pixels sont inutiles) avec leurs *coordonne min et max (en x et y) et/ou leurs nombres de pixel*. 

Voila ce  quoi j'ai pens : 
Une fois les deux passes effectus :
Creer une liste chain de composantes en parcourant l'image des composantes connexes.
A chaque pixel faisant parti d'une composante connexe mettre  jour cette composante dans la liste (on incremente le nombre de pixel et on met a jour les min et max si besoin), et si elle n'y figure pas encore on l'ajoute.

Problme : ca peut etre assez long, surtout si on a trop de composantes "parasites" de quelques pixels, le parcours de la liste peut devenir long.

J'ai pens  un autre truc gourmand en mmoire (O(n^2)*taille de la structure):
On declare un tableau de structure (qui contient les informations en gras ci-dessus) de taille : taille de l'image (il ne peut pas y avoir plus de composantes).

Lors de la derniere passe, on recupere le nombre composantes dans l'image en conservant l'etiquette de la composante la plus grande (il me semble que si on a n composantes, alors elles seront numerots de 1  n, je me trompe pas?).
On met  0 les structures de ces n composantes dans le tableau.

On parcours l'image et pour chaque pixel dans une composante on met  jour la structure correspondante. 
De cette facon on y accede en temps constant sans parcours de liste.

Qu'en pensez vous? D'autres ides?

----------


## pseudocode

une autre solution, pas trop cher: filtrer l'image des composantes connexes. 

Si tu passes un filtre median ou dilatation sur cette image, ca va retirer les points "isols".  :;):

----------


## contremaitre

oui, mais ca je suppose que je l'ai deja fait avant la recherche de composantes connexes mais il peut quand meme me rester beaucoup de composantes de taille moyenne qui ne seront pas filtrs. Et je dois donc trouver un moyen de repertorier toutes mes composantes pas trop couteux.
Apres je pourrai liminer celles qui seront en dessous d'une certaine taille.
Voire garder les n plus grosses.

----------


## pseudocode

J'ai pas tout capt alors je vais essayer de rsumer.

1. Tu as calcul ton image binaire de "difference" entre l'image courante et l'image de reference.

2. Tu filtres cette image binaire (suppression des points isols, dilatition des points proches, ...).

3. Tu fais la labelisation en composantes connexes (2 passes): tu obtiens donc pour chaque point dans l'image binaire un n de label.

4. Tu filtres cette image "binaire+label" (suppression des labels trop petits)

5. Tu parcours l'image "binaire+label" et tu construis la liste des blobs (un blob par n de label).

Est-ce que nous sommes d'accord jusque la ?

----------


## contremaitre

> J'ai pas tout capt alors je vais essayer de rsumer.
> 
> 2. Tu filtres cette image binaire (suppression des points isols, dilatition des points proches, ...).
> 
> 4. Tu filtres cette image "binaire+label" (suppression des labels trop petits)
> 
> Est-ce que nous sommes d'accord jusque la ?


2. Suppression des points isols ca revient  faire une rosion?

4. C'est pas deja fait dans le 2? Normalement les composantes de trs petite taille on deja t limins, mais je vois pas comment liminer celles de petites ou moyennes tailles. Tu parles de filtres mdians. Comme l ? http://xphilipp.developpez.com/artic...=page_13#LFNL1

merci

----------


## pseudocode

> 2. Suppression des points isols ca revient  faire une rosion?


oui. Ton "image des differences" est binaire, donc tu peux utiliser les filtres morpho sans problemes.




> 4. C'est pas deja fait dans le 2? Normalement les composantes de trs petite taille on deja t limins, mais je vois pas comment liminer celles de petites ou moyennes tailles.


Oui, mais dans le "4" on a une info supplmentaire: les labels. On peut donc faire un filtrage plus fin... Mais cette tape n'est pas obligatoire.




> Tu parles de filtres mdians. Comme l ? http://xphilipp.developpez.com/artic...=page_13#LFNL1


Oui. Sinon tu as aussi un exemple de filtre morpho (dilatation/erosion) dans la rubrique "contribuez"

----------


## contremaitre

J'ai un problme avec l'algo scnaline... je me retrouve avec plusieurs groupes dans une seule composante connexe qui n'est pas si tordue que ca.
Dans mon fichier attach on peut voir que lors de la passe de haut en bas et de gauche a droite la partie gauche possde le label 2. (ici pour chaque pixel on regarde le pixel  gauche et le pixel au dessus).

Mais lors de la passe de bas en haut et de drotie  gauche, la partie dans le creux  gauche ne rcupere pas le label 1 car le label 1 au dessus est mis  jour seulement aprs... (ici pour chaque pixel on regarde le pixel  droite et le pixel au dessus).

Dans cet exemple je me retrouve avec deux composantes au lieu d'une, mais j'ai eu des cas avec des structures en "escalier" ou j'en avais bien plus...

----------


## pseudocode

Hum... la numerotation a la fin de la 1ere passe (forward) me parrait bizarre.

Je verrai plus quelquechose du style:


```

```




> forward:
> label[x][y]= label[x-1][y] sinon label[x][y-1] sinon {pas de changement ou nouveau label}
> 
> backward:
> label[x][y]= label[x+1][y] sinon label[x][y+1] sinon {pas de changement ou nouveau label}


NB: Si tu penses avoir atteint les limites de l'algo scanline, tu peux passer au "union-find". Par exemple, tu peux faire 1 balayage scanline (haut->bas) tout en construisant la table d'equivalence. Ensuite tu fais un 2eme balayage pour renumeroter les labels.

----------


## contremaitre

> Hum... la numerotation a la fin de la 1ere passe (forward) me parrait bizarre.
> 
> Je verrai plus quelquechose du style:
> 
> 
> ```
> 
> ```


Le 2 en rouge est en fait un 1 car en parcourant cette ligne de gauche a droite, vu qu'on prend le min entre le pixel a gauche et le pixel audessus (qui est  1) on prends bien le label 1. Et il se propage ensuite tout le long de cette ligne, et de meme pour la ligne en dessous.

Tu parles de prendre a gauche sinon au dessus, mais moi j'avais lu prendre le min. En faisant comme tu dis ca me parait encore pire...

Je vais regarder le "union-find", merci

----------


## pseudocode

> Tu parles de prendre a gauche sinon au dessus, mais moi j'avais lu prendre le min. En faisant comme tu dis ca me parait encore pire...


Oui, tu as raison c'est mieux en prenant tout le temps le min. Moi c'etait juste pour faire la 1ere passe.

Normalement ca devrait pourtant converger assez vite. Tu peux poster ton image binaire des differences ?

----------


## contremaitre

> Normalement ca devrait pourtant converger assez vite. Tu peux poster ton image binaire des differences ?


Comme tu disais que avec 1 ou 2 passes ca devrait passer j'ai test comme ca.
Aprs en faisant plus de passe ca va converger oui, mais je me pose la question de savoir si je vais pas de nouveau tomber sur des formes qui feront que soit :
- Ca converge trop lentement si je met pas de limite
- J'ai trop de composantes connexes diffrentes si je met un nombre de passe limite.
Et meme si ca fonctionne en testant un peu, je suis pas sur que je rencontrerait pas des cas problmatiques plus tard.

Voici un exemple de bloc connexe qui m'a gnr trop de composantes (en rouge les composantes, c'est un peu fouilli car ca se chauvauche (les rectangles rouges sont dessins de maniere  etre  l'exterieur de la composante c'est pourquoi ils se chevauchent).

----------


## pseudocode

??  :8O: 

Comment tu as fait pour avoir plusieurs labels sur ce blob ?

----------


## contremaitre

Pardon j'oubliai que le bas et le haut est invers lorsque je parcours mes images, j'ai remis dans le bon sens.
Je pense que le problme est du meme genre que l'exemple prcedent.
Quand on a une forme d'escalier en haut et en bas la propagation se fait mal

----------


## pseudocode

Ah ok. Effectivement il faut 2 passes (= 4 balayages) pour que a converge.

Bienvenue dans le monde passionnant de l'tiquetage des composantes connexes !!  ::?:

----------


## contremaitre

J'ai mis en place le union find, ca marche plutot bien. Un peu moins de 100ms par image de taille 300x300 pixels sur un CPU  500Mhz pour ma premiere implmentation qui pourra ventuellement etre optimise.
Je vais maintenant voir ce que ca donne au niveau de la dtection.

----------


## pseudocode

> J'ai mis en place le union find, ca marche plutot bien. Un peu moins de 100ms par image de taille 300x300 pixels sur un CPU  500Mhz pour ma premiere implmentation qui pourra ventuellement etre optimise.
> Je vais maintenant voir ce que ca donne au niveau de la dtection.


Flicitations. Tiens nous au courant.  ::king::

----------


## contremaitre

Pour amliorer ma mthode j'ai pens  plusieurs trucs, qu'on pensez vous?
- Utilisation de la composante Hue (Teinte) du modele HSV comme le suggre bmw13fr ici pour tre moins sensible aux variations de luminosits et changements d'ouvertures du capteur de la camra.

-Appliquer un filtre (flou par exemple)  mon image de rfrence pour etre moins sensible au bruit et donc avec un seuil lors de la binarisation de la diffrence plus haut.

- Faire un seuillage dynamique au lieu d'un fixe (seuillage entropique?)


Il faudra que je regarde aussi d'autres techniques d'extraction de blob, mais quand je serais plus avanc car j'ai du mal a comprendre ce que j'ai lu la dessus pour l'instant.

----------


## pseudocode

> - Utilisation de la composante Hue (Teinte) du modele HSV comme le suggre bmw13fr ici pour tre moins sensible aux variations de luminosits et changements d'ouvertures du capteur de la camra.


Oui, tu peux galement "forcer" la composante V au maximum.




> -Appliquer un filtre (flou par exemple)  mon image de rfrence pour etre moins sensible au bruit et donc avec un seuil lors de la binarisation de la diffrence plus haut.


Il y a peut-etre des filtres mieux adapts que le flou pour ton type de bruit... Median, Deparasitage, Erosion+Dilatation, ...




> - Faire un seuillage dynamique au lieu d'un fixe (seuillage entropique?)


Oui, ca c'est un rel "plus" pour les images binaires.

----------


## contremaitre

merci, je vais essayer tout ca.

----------


## contremaitre

Alors pour le seuillage dynamique :
J'ai pens  utiliser l'histogramme des images de diffrence.

Voici 4 histogrammes des images de diffrence entre le fond et l'image courrante. 
Les valeurs de seuil optimal sont reprsentes par le petit triangle en bas (en dessous de ces valeurs je commence  avoir du bruit).
De gauche a droite : aucune zone de bouge, puis une petite zone, puis une plus grande etc... Ce qui reprsente en fait un diffrent nombre de personnes dans le champ de la camra.

A premiere vue, trouver le bon seuil ne semble pas si vident car il faut se placer un peu avant la forte augmentation du nombre de pixels. Mais ni trop prs ni trop loin. Et dans le dernier cas c'est encore plus dur.

Si vous avez d'autres ides?

----------


## pseudocode

> Si vous avez d'autres ides?


Utiliser constamment la valeur "30".  ::P:

----------


## contremaitre

ouais  ::aie:: 
Mais ca marchera bien avec cette camra et dans la piece ou je fait des tests...
Et comme ca doit marcher avec n'importe quelle camra dans n'importe quel endroit pas sur que "30" soit toujours la bonne valeur.

----------


## pseudocode

> ouais 
> Mais ca marchera bien avec cette camra et dans la piece ou je fait des tests...
> Et comme ca doit marcher avec n'importe quelle camra dans n'importe quel endroit pas sur que "30" soit toujours la bonne valeur.


Dans ce cas la, il faut faire un calibrage automatique. Il faut calculer la valeur de "seuil" optimale lorsqu'il n'y a aucun mouvement.

----------


## contremaitre

> Dans ce cas la, il faut faire un calibrage automatique. Il faut calculer la valeur de "seuil" optimale lorsqu'il n'y a aucun mouvement.


Le problme, et on le voit un peu sur les histogrammes, c'est que sans mouvement la luminosit ne change pratiquement pas, alors que avec mouvement, ca peut faire changer la luminosit totale percue par le capteur camra, donc il va lgerement s'auto ajuster (plus il fait sombre plus il s'ouvre), et donc le seuil optimal ne sera pas le meme avec personne ou avec du mouvement.



Finalement passer en espace HSV ne semble pas si bien que ca, pour deux raisons :
1- La "complexit" de la conversion YUV -> HSL

2- Si on regarde la reprsentation HSL :

On voit que si la luminosit diminue (et la raison pour laquelle je choisi cet espace c'est d'etre insensible  ce changement), l'espace de reprsentation d'une couleur est plus petit.
Donc entre deux luminosits diffrente, une mme couleur n'aura pas forcment la mme valeur en pratique, car la projection d'un couleur d'une luminosit  l'autre n'est pas bijective.
Ca parait logique de toute facon, vu que plus il fait sombre moins les couleurs sont "visibles"... il peut pas y avoir de miracle  ::):

----------


## ToTo13

Bonsoir,




> Ah ok. Effectivement il faut 2 passes (= 4 balayages) pour que a converge.
> Bienvenue dans le monde passionnant de l'tiquetage des composantes connexes !!


Dsol, j'avais lach un peu cette discussion et je viens de voir a en la regardant.

Je suis un peu tonn (peut tre n'ai je rien compris), mais j'utilise pour ma part deux algorithmes d'tiquetage des composantes connexes :
 - le premier rcursif qui ne ncessite qu'un seul balayage.
 - le deuxime itratif qui ncessite deux balayages, mais qui a l'avantage de ne pas faire exploser la pile selon les cas.

----------


## pseudocode

> Le problme, et on le voit un peu sur les histogrammes, c'est que sans mouvement la luminosit ne change pratiquement pas, alors que avec mouvement, ca peut faire changer la luminosit totale percue par le capteur camra, donc il va lgerement s'auto ajuster (plus il fait sombre plus il s'ouvre), et donc le seuil optimal ne sera pas le meme avec personne ou avec du mouvement.


Dans ce cas, comme tu le prsentais, il va falloir faire du seuillage dynamique. As tu deja essay quelques methodes de seuillage ?




> La "complexit" de la conversion YUV -> HSL


Si tes images sont deja en YUV, inutile de passer par HSL. Tu n'a qu'a forcer la composante Y  0.5.

----------


## pseudocode

> Je suis un peu tonn (peut tre n'ai je rien compris), mais j'utilise pour ma part deux algorithmes d'tiquetage des composantes connexes :
>  - le premier rcursif qui ne ncessite qu'un seul balayage.
>  - le deuxime itratif qui ncessite galement qu'un seul balayage.


Generalement les algo une-passe ne sont pas beaucoup plus performant qu'un algo deux-passes. Je ne sais pas quel est ton algo une-passe mais generalement ca revient a faire du suivi de contour ce qui coute aussi cher qu'un union-find.

----------


## contremaitre

> Dans ce cas, comme tu le prsentais, il va falloir faire du seuillage dynamique. As tu deja essay quelques methodes de seuillage ?


J'etais parti sur le seuillage par entropie mais ca ne s'applique pas vraiment  mon cas en fait, puis j'avais pens  faire un seuillage sur l'histogramme c'est pourquoi j'avais post des captures de diffrents histogramme mais ca ne semble pas la bonne solution. Je vais donc en chercher d'autres.

Pour l'espace de couleur de travail je vais regarder ca.

Merci

----------


## pseudocode

Tu peux poster les images de differences completes (pas juste les histogrammes) pour qu'on puisse t'aider ?

----------


## contremaitre

> Tu peux poster les images de differences completes (pas juste les histogrammes) pour qu'on puisse t'aider ?


Oui je pourrais lundi, mais la elles sont prises dans d'assez bonnes conditions et les amliorations que je veux apporter maintenant sont pour des cas plus difficiles.
Je les postes avant mon seuillage je suppose?

----------


## pseudocode

> Oui je pourrais lundi, mais la elles sont prises dans d'assez bonnes conditions et les amliorations que je veux apporter maintenant sont pour des cas plus difficiles.
> Je les postes avant mon seuillage je suppose?


Oui, avant le seuillage ca serait bien.  ::king::

----------


## contremaitre

> Bonsoir,
> Je suis un peu tonn (peut tre n'ai je rien compris), mais j'utilise pour ma part deux algorithmes d'tiquetage des composantes connexes :
>  - le premier rcursif qui ne ncessite qu'un seul balayage.
>  - le deuxime itratif qui ncessite deux balayages, mais qui a l'avantage de ne pas faire exploser la pile selon les cas.


L'algorithme que j'utilise finalement ncessite un balayage pour une numrotation temporaire des composantes connexes et la construction de la table d'quivalence, puis un balayge pour faire la numrotation finale.




> Si tes images sont deja en YUV, inutile de passer par HSL. Tu n'a qu'a forcer la composante Y  0.5.


J'ai essay de faire la diffrence sur u et v seulement (abs(u2-u1) + abs(v2-v1))/2 et ca marche trs mal, une personne prsente est presque fondue dans le bruit.




> Oui, avant le seuillage ca serait bien.


http://cjoint.com/data/bCkObESV3j.htm
Voila une image de diffrence, elles est intressente car le vetement de mes paules a un peu la meme teinte que le sol et il est difficile de le faire ressortir.

----------


## pseudocode

> Voila une image de diffrence, elles est intressente car le vetement de mes paules a un peu la meme teinte que le sol et il est difficile de le faire ressortir.


Et le seuillage entropique ca ne suffit pas ?

----------


## contremaitre

> Et le seuillage entropique ca ne suffit pas ?


J'ai peut etre mal compris le seuillage par entropie alors. D'aprs ce que j'ai lu (Notamment sur ce post) Cela consiste  maximiser le nombre de pixels noirs et le nombre de pixels blanc, en faisant une recherche sur tous les seuils possibles.
Donc en fait avoir une rpartition gale des pixels noirs et pixels blanc.

Ca me pose deux problmes :
* Mon but est de seulement faire ressortir des zones de prsence, donc il doit y avoir peu de pixels blanc si il y a personne ou une faible prsence
* Temps de calcul trs lev si il faut calculer 255 entropies pour une image avec 255 niveaux de gris (255 seuils possibles en thorie)

----------


## pseudocode

> J'ai peut etre mal compris le seuillage par entropie alors. D'aprs ce que j'ai lu (Notamment sur ce post) Cela consiste  maximiser le nombre de pixels noirs et le nombre de pixels blanc, en faisant une recherche sur tous les seuils possibles.
> Donc en fait avoir une rpartition gale des pixels noirs et pixels blanc.


http://www.istanbul.edu.tr/eng/ee/je...is62/62008.pdf

La formule dcrite au 2.2 a t implmente en Java dans ImageJ.




> Ca me pose deux problmes :
> * Mon but est de seulement faire ressortir des zones de prsence, donc il doit y avoir peu de pixels blanc si il y a personne ou une faible prsence


C'est un peu le principe de l'entropie.  :;): 




> * Temps de calcul trs lev si il faut calculer 255 entropies pour une image avec 255 niveaux de gris (255 seuils possibles en thorie)


Effectivement il faut calculer l'entropie pour le Noir et pour le Blanc puis chercher la meilleure sparation. Mais ce n'est pas si coteux que cela.

----------


## contremaitre

super  ::king::  l'article explique trs bien et le code en java va bien me servir  ::): 
J'avais pas reussi  trouver d'explication sur le seuillage par entrpoie.

----------


## contremaitre

Alors le suillage par entropie est pas mal du tout effectivement.
Seul petit problme : quand il n'y a pas de mouvement du tout, alors j'obtient des seuils trop bas et je capture trop de bruit.
Bon c'est sur une rosion et il n'y aurait surement plus rien, mais c'est dommage quand meme.
Ca doit venir de la mthode de maximisation de l'entropie. Et je ne veux pas fixer une limite basse  mon seuil car je retomberai sur les problmes d'un seuil fixe diffrent selon les situations.

----------


## pseudocode

> Et je ne veux pas fixer une limite basse  mon seuil car je retomberai sur les problmes d'un seuil fixe diffrent selon les situations.


Hum... ca veut dire qu'il va falloir dcider si le seuil "calcul" par l'algo du seuillage entropique est cohrent.

On pourrait evaluer la distribution de la moti haute de l'histogramme (au dessus du seuil). Si la variance est "trop" grande, alors c'est que les pixels au dessus du seuil sont du bruit.  ::?:

----------


## contremaitre

oui pourquoi pas, merci pour l'ide.
Dans un premier temps ce n'est pas prioritaire, je vais pour l'instant continuer  mettre en place l'acquisition du fond, et le comptage  partir des composantes connexes.

Merci pour l'aide en tout cas.

----------


## contremaitre

Je bloque encore sur un truc  ::): 

est ce qu'il y a un moyen de dcreter qu'il y a du mouvement dans l'image, toujours sans passer par des seuils fixes.
Donc surement la question  se poser est : est ce que mon image de diffrence ne contient que du bruit.

J'ai besoin de rpondre  cette question pour bloquer ou debloquer l'acquisition du fond :




> Utilise un hystrsis: une fois que la cible est detecte (|foreground|>seuilHaut) elle reste marque jusqu'a ce qu'elle disparaisse (|foreground|<seuilBas).

----------


## pseudocode

> est ce qu'il y a un moyen de dcreter qu'il y a du mouvement dans l'image, toujours sans passer par des seuils fixes.
> Donc surement la question  se poser est : est ce que mon image de diffrence ne contient que du bruit.


Il te faudra de toutes les faons utiliser un seuil. S'il n'est pas fixe, c'est qu'il est calcul  partir des images dont tu disposes... et forcement la methode de calcul fera intervenir une formule qui aura des "constantes"  dfinir. Donc on change un problme pour un autre: seuil <-> constantes.

----------


## contremaitre

Bon j'ai mis en place tout l'algo c'est pas mal du tout.
Je cherche maintenant  optimiser le tout, et je me pose des questions sur la dilatation/erosion.

Si on regarde l'image que tu as seuill, pseudocode, dans le message #55 de ce fil, on voit des pixels isols (le bruit), mais aussi une rgion au niveau des paules avec un nuage de pixel ne se touchant pas forcment.

Alors la dilatation seule va bien "aglomrer" cette rgion. 
L'rosion seule va bien enlever le bruit.

Mais si je fait les deux (rosion puis dilatation) j'ai peur de ne plus bien "agglomerer" les pixels d'une personne mal seuille.

J'ai pens  ca :


```

```

En esperant que le noyau plus gros pour la dilatation ratrappe les endroits ou il n'y aurait pas du avoir d'erosion.

Est ce que ca fonctionne comme je l'imagine, et y a t'il d'autres manieres de faire? (d'autres noyaux ou ordre des filtres)

merci

----------


## pseudocode

> Est ce que ca fonctionne comme je l'imagine, et y a t'il d'autres manieres de faire? (d'autres noyaux ou ordre des filtres)


Un coup de filtre mdian, c'est pas mal.   :;):

----------


## contremaitre

> Un coup de filtre mdian, c'est pas mal.


un filtre median 3x3 puis une dilatation par exemple? 
sans rosion donc.

----------


## pseudocode

> un filtre median 3x3 puis une dilatation par exemple? 
> sans rosion donc.


Perso, dans ce genre de cas, je ne fais mme pas de dilatation... 

Les points isols qui restent aprs le median ils donneront des composantes connexes toutes petites que je me ferai un plaisir d'ignorer.

Les seuls cas qui restent sont les nuages en forme de "8". Le filtre mdian risque de sparer les 2 parties du 8 et elles seront comptabilises comme 2 composantes connexes. Mais dans ton cas, ce n'est peut-etre pas plus mal...

----------


## contremaitre

merci

D'ailleur un filtre median sur une image binaire c'est assez simple, pas besoin de calculer la medianne, mais juste de regarder, pour un pixel i, si parmis ses 8 voisins plus lui mme, 5 au moins sont  '1'.

Le resultat me fait penser  un mix d'une erosion/dilatation. (sur un mini exemple sur papier que je me suis fait).

----------


## contremaitre

j'ai deux nouvelles questions :

* Si je veux travailler sur une image plus petite pour une question de ressources utilises, j'ai pens par exemple  diviser la hauteur et largeur par deux, puis pour chaque groupe de 4 pixels en prendre la moyenne. Est ce que c'est la meilleure solution?

* Au niveau du seuillage entropique, j'avais parl d'un problme lorsqu'il n'y a pas de mouvement que ca ne capture que du bruit, et j'ai aussi le problme inverse : dans le cas extrme o il y a beaucoup de mouvement (pratiquement toute l'image bouge), je ne capture plus beaucoup de mouvement car le seuillage fait comme si c'tait du bruit.

----------


## pseudocode

> * Si je veux travailler sur une image plus petite pour une question de ressources utilises, j'ai pens par exemple  diviser la hauteur et largeur par deux, puis pour chaque groupe de 4 pixels en prendre la moyenne. Est ce que c'est la meilleure solution?


Si tu as un peu de temps CPU de dispo, essaye de faire un resampling (par exemple "lancsoz"). Sinon la moyenne linaire fera l'affaire.




> * Au niveau du seuillage entropique, j'avais parl d'un problme lorsqu'il n'y a pas de mouvement que ca ne capture que du bruit, et j'ai aussi le problme inverse : dans le cas extrme o il y a beaucoup de mouvement (pratiquement toute l'image bouge), je ne capture plus beaucoup de mouvement car le seuillage fait comme si c'tait du bruit.


Et oui... c'est le principe meme de l'entropie: ne conserver que l'information "pertinente". A part utiliser des seuils haut & bas, ou faire de la calibration, je ne vois pas comment faire autrement.  ::?:

----------


## contremaitre

ok je vais tudier ca.
merci !

----------


## contremaitre

me revoil.

Donc aprs pas mal de tests les rsultats sont mitigs, il y a du bon et du moins bon.

Les points ngatifs sont :
- Difficults de "voir" certains type de vtement dont les couleurs sont trop proche de la couleur du sol.
Donc je me retrouve avec certaines personnes avec une zone bien encadr et certaines autres avec une zone bien plus faible voir parsem de petites zones au niveau des vtements. Pire : avec un essai sur un sol clair et un tapis fonc, certaines personnes devenaient "invisible" sur le tapis.

-Lorsque les personnes ont une attitude diffrente (exemple un bras lev sur le cot ou devant), la zone peut doubler, donc la comptage se plante.

Les points positifs :
Le seuillage entropique et le filtre mdian sont assez bon (trs bon mme si ce n'est le problme de couleurs trs proches avec le sol).
Le systme d'acquisition de fond progressif marche bien aussi.

----------


## pseudocode

en bref: la detection marche bien, mais la classification pose des problmes.

Il y a donc 2 approches:
A1. Conserver la classification actuelle et amliorer la dtection
A2. Conserver la detection actuelle et amliorer la classification

Ton 1er point ngatif (personnes invisibles) rentre dans l'approche A1.
Ton 2nd point ngatif (faux positifs) rentre dans l'approche A2.

Y-a-pu-ka chercher des solutions. vive  ::google::

----------


## contremaitre

> Si tu as un peu de temps CPU de dispo, essaye de faire un resampling (par exemple "lancsoz"). Sinon la moyenne linaire fera l'affaire.


*lanczos* (pour chercher sous google c'est plus facile  ::aie:: )

Sinon question annexe : quelle est la mthode de resampling (vers le bas dans mon cas) qui conserve le mieux les bords?

Lanczos sample "lisser" le signal.
Enfin si on regarde l'exemple de wikipedia - lanczos sur un signal :



> Original signal:
>   0 90  0  0 90  0  0  0 90  0  0  0 90 90 90 90 90 90 90
> Resampled signal:
>  33 .. .. 24 .. .. .. 20 .. .. 25 .. .. .. 91 .. .. .. 89

----------


## pseudocode

> *lanczos* (pour chercher sous google c'est plus facile )


Mince... pas tomb loin quand mme.  ::P: 




> Sinon question annexe : quelle est la mthode de resampling (vers le bas dans mon cas) qui conserve le mieux les bords?
> 
> Lanczos _semble_ "lisser" le signal.
> Enfin si on regarde l'exemple de wikipedia - lanczos sur un signal :


Oui, le resampling a pour effet d'attenuer les brusques changements (aliasing) et donc de faire baisser le contraste. Si tu veux conserver ces changements, il faut utiliser le plus proche voisin, bref un redimensionnement basique (arrondir au plus proche les coordonnes aprs avoir divis par le facteur de rduction)

----------


## contremaitre

Bonjour,

Pour amliorer la dtection, je pense qu'il faudrait que je ne travaille pas pixel par pixel.
Je suis tomb sur un article qui travaille par "cluster" :  En travaillant sur l'image de diffrence entre le fond et l'image courrante (delta), et en considerant tout ce qui n'est pas une personne comme un cluster, et chaque personne un cluster diffrent.

Bon le problme de cet article est qu'il est assez compliqu et fait intervenir des calculs trop complexes, mais l'ide que j'aimerai garder est la suivante :
Pour savoir si un pixel appartient au fond ou  une personne, cela fait intervenir la diffrence delta et aussi la distance entre le centre du cluster et le pixel.
Donc un pixel avec un delta pas trs important mais pas loin du centre d'un cluster aura plus de chance d'appartenir  ce cluster qu'un pixel isol.

Y'a t'il des mthodes connues qui fonctionnent sur ce principe de ne pas regarder seulement un pixel sparment avec un seuil unique pour l'image?

----------


## pseudocode

> Y'a t'il des mthodes connues qui fonctionnent sur ce principe de ne pas regarder seulement un pixel sparment avec un seuil unique pour l'image?


Regarde du cot de "Relaxation Labeling".  :;):

----------


## contremaitre

merci pour cette piste, a me fait penser  ce qu'ils utilisaient dans l'article que j'ai lu, mais je n'arrive pas  l'utiliser.

Par contre j'ai voulu chercher d'autres mthodes de seuillage, et dans imagej, le mixture modeling me permet de faire ressortir les zones que je ne vois pas avec le seuillage par entropie.
En fait a me sort un seuil trs bas, juste au pied du pic de mon histogramme qui se situe en tout dbut de l'histogramme.
(Il y a aussi isodata mais l j'ai vraiment un seuil trop proche de 0, a ne doit pas correspondre  mon problme).

Par contre a me donne pas mal de bruit galement, mais que je pourrais liminer par un filtre mdian.
Je vais faire plus d'essais car cette mthode est sense sparer un histogramme en deux :

Mais moi je n'ai qu'un seul pic dans mon histogramme (pour le bruit), le reste est presque plat, donc je suis pas sur que a marche tout le temps.

----------


## pseudocode

Un seuillage entropique de l'histogramme est dj une trs bonne chose. C'est un filtrage statistique qui permet d'liminer l'information non pertinente.

Comme tu le disais prcdemment, si tu veux avoir un meilleur filtrage, il va falloir utiliser l'information "spatiale" des pixels.

Au final, le filtrage ne fera pas tout le travail. Il faudra ajouter un traitement spcifique  ton problme (par exemple un classifieur -> intelligence artificielle)

----------


## themadmax

Oh ! c'est mon plug-in ImageJ ! Si vous avez des questions...
(Sa fait plaisir que des personnes l'utilise)

----------


## contremaitre

:;): 

j'ai russi  l'implmenter grce  votre code source et a marche trs bien !
bravo pour le travail.
Bon ca reste un peu lent pour moi (deux exponentielles  calculer (255*255) fois)

----------


## contremaitre

J'ai une autre question sur la soustraction de fond.
Dans un article ils utilisent ce qu'ils appellent "luminance contrast" :
Au lieu de faire une diffrence toute simple entre la luminance y  du fond (Yb) et y de l'image courante (Yc), ils font :
(Yc - Yb) / Yb

Je comprends pas trop l'intrt,  moins que les capteurs soient plus sensibles au changement de luminance lorsquelles sont leves ?

Et aussi, c'est quoi un "morphological erosion gradient" ?
Je connais l'rosion morphologique (sur une image binaire), mais l c'est sur une image en niveau de gris.

----------


## contremaitre

Bonjour,

Je rflchit en ce moment  une spcialisation de cet algorithme.
J'aimerai discriminer une image pour savoir si il y a une personne ou deux personnes.

Bien sr cela simplifie le problme, mais je voudrai qu'il y ai moins (aucune ?) d'erreurs.

Pour cela je peux me baser sur deux critres :

1- La taille du blob s'il n'y en a qu'un (en cas de deux personnes il sera superieur  un seuil, en thorie).
2- Si il y a plusieurs blob, la taille de deux blob au moins suprieur  un seuil pour considrer qu'il y a deux personnes distinctes

Cette solution est pas mal, mais il me reste le problme de deux personnes vraiment proche o seulement la taille du blob ne permet plus de discriminer mon problme.

Voyez vous quelque chose que je pourrais essayer pour amliorer, voir partir sur une autre mthode ?

merci

----------


## bmw13fr

bonjour,

Je suis actuellement en train de faire le mme boulot  ::D: 

Par contre moi c'est beaucoup plus simple (et alatoire aussi lol)
Je divise l'aire en mouvement par une aire reprsentant une personne (ncessit de calibrer le programme au dbut)

J'obtiens des rsultats moyen mais a cause d'un tout autre problme ...

La surface d'une personne en bord d'cran n'est pas la mme qu'au centre ...
(effet de perspective).

Bref, en tout cas je suis tes travaux avec grand intret bon courage pour la suite !


A+++

----------


## contremaitre

> bonjour,
> 
> La surface d'une personne en bord d'cran n'est pas la mme qu'au centre ...
> (effet de perspective).


j'ai eu ce problme aussi  :;): 
Surtout lorsque la surface tait calcule sur des blob circulaires, le cercle tait beaucoup plus large sur les bords.
Je l'ai en partie rsolu avec des blobs rectangulaires.
Ca dpend aussi de la hauteur de la camra par rapport au sol, plus elle est basse plus le phnomne s'accentue.

Sinon personne n'a d'autres ides que la surface pour discriminer une ou deux personnes qui seraient trop proches ?

----------


## pseudocode

> Sinon personne n'a d'autres ides que la surface pour discriminer une ou deux personnes qui seraient trop proches ?


Sur une image statique, on pourrait tenter de faire un k-mean 2D sur le blob. Ca risque d'etre long pour faire du temps-rel.

Dans la meme ide, on peut projeter les pixels du blob sur un axe (l'idal serait celui qui passe par les centres des 2 blobs) et faire un mixture modeling.

----------


## bmw13fr

Pour "contrer" le problme de la perspective
j'applique un facteur de correction a chaque pixel en mouvement.

Par exemple chaque pixel au centre de l'cran vaut 1
et chaque pixel en bord d'cran vaut 0.5

C'est un exemple bien sur, j'applique pas des valeurs aussi alatoirement !

Du coup j'ai moins de problme de perspective.  ::): 


Sinon je viens de tester une nouvelle mthode, la dtection de visage (avec OpenCV) mais cette fois en vue de 3/4 ... et a marche trs mal  ::): 


J'avais aussi (dans un prcdent post) utilis les images contour 
et la les rsultats taient pas mal (sur des vidos idales)
mais trs mdiocre sur des vidos relles.


Voila voila, c'est finalement pas si vident que je le pensais ! ::?:

----------


## contremaitre

> Sur une image statique, on pourrait tenter de faire un k-mean 2D sur le blob. Ca risque d'etre long pour faire du temps-rel.
> 
> Dans la meme ide, on peut projeter les pixels du blob sur un axe (l'idal serait celui qui passe par les centres des 2 blobs) et faire un mixture modeling.


merci pour ces nouvelles pistes !
Par contre j'aurai besoin de quelques prcisions :
Pour le k-mean, a veut dire quoi 2D ?
Et il faut l'appliquer sur quelle image ? le blob binaire, ou sur les niveaux de gris correspondants ?
D'aprs ce que j'ai compris au kmean il sert  sparer une population (ici les pixels) en k groupe.
Donc je pourrai sparer les pixels du blob en 2 groupe, mais qu'est ce qui me dira que cela correspond  2 personne distincte ou une seule ?

Quand  la projection du blob, j'ai pas compris l'histoire de l'axe qui passe par les centres des 2 blobs : a veut dire qu'il faut d'abord sparer le blob en deux puis ensuite calculer l'axe qui passe par leurs centres et ensuite faire une projection?

De la mme manire, le mixture modeling pourra sparer en deux mais comment dcider si c'est une ou deux personnes ?

merci encore

----------


## pseudocode

C'tait juste des ides comme a. Il faudrait que tu nous montre une image typique du problme pour voir s'il n'y a pas une mthode plus simple de dnombrement.

----------


## contremaitre

voici 3 exemple de blobs :
* seul
* 2 personnes plus ou moins proches

----------


## pseudocode

Vu que ton blob #1  l'air cirrculaire, on peut percevoir l'anomalie dans le blob #2 par un calcul du facteur de forme. Pour celle du blob #3, sur une image statique, ca va tre dur. 

Dans tous les cas, ca serait plus simple de travailler sur des sequences d'images et de faire du tracking.

----------


## contremaitre

> Dans tous les cas, ca serait plus simple de travailler sur des sequences d'images et de faire du tracking.


Oui j'y avais pens, mais ma zone filme est un peu petite pour faire du tracking je trouve.

Merci en tout cas pour les ides

----------

