Discussion :

[etienne007]

suite de ce sujet qui a du être fermé à cause de sa dérive sur les macros/ fonctions inlines

Je n'ai ni besoin ni de l'un ni de l'autres car j'appelle la fonction d'accès à la matrice à un seul endroit de l'objet, donc pas besoin de macro: j'ai écrit explicitement le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
bool Critere::estPeau(int i, int j, int k) {
	return (bool)(estPeauTable[i][j][k>>5] & (1<<(k & 31)));
}
 
void Critere::setEstPeauTable(int i, int j, int k, bool b) {
	if (b) { 
		estPeauTable[i][j][k>>5] |= (1 << (k & 31)); 
	} else { 
		estPeauTable[i][j][k>>5] &= ~(1 << (k & 31));
	}
}

Mmmm.... Donc, en résumé, sur les 16 millions de couleurs possibles dans ce système, tu as fais une partition entre "couleur de peau" et "autres", c'est bien ça ?

Oui c'est bien ca!

Ta matrice est-elle initialisée statiquement (ex : calcul de la plage couleur de la peau en HSV ou Yuv et conversion RGB, calculé sur des images d'étalonnage), ou dynamiquement (tu dis "cette zone est de la peau" sur une frame de la vidéo, et il stocke les valeurs dans la matrice) ?

Elle est allouée statiquement et peut être améliorée dans la partie réglage du programme, par conte elle ne bouge plus pour la partie en temps réel.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Au final, quel est (approximativement, bien sûr !) le pourcentage de "nombre de couleurs FALSE" et de "nombre de couleurs TRUE" ?
 
En fonction de ces éléments, il sera peut-être possible d'améliorer encore plus cette partie...

Je viens de faire le calcul et j'ai du 14% de TRUE (la zone 3d étant en plus connexe)
(pour le stockage d'un fichier sauvegarde, il y aura bien sur une optimisation des longues chaines de 1 et de 0, mais pour le temps réel, je doute que ca soit bon de réaliser une compression des données)

En fait je part d'un critere de peau mathématique trouvé dans la littérature sur le sujet:

R, G et B correspondent au valeurs RGB du pixel considéré.

Le reste, c'est des constantes float à déterminer au cas pas cas (dépend de la cam, de l'environnement... J'ai pu faire un programme qui s'en occupe)

La zone de l'espace de peau ainsi modélisée correspond à un cône dans l'espace RGB

L'idée est donc de faire les calculs pour les 16 millions de pixels une fois pour toute et de pouvoir peaufiner encore ce critere.

N'empêche que la vitesse d'execution est quasiment la même lorsque je lui donne le systeme précédent que lorsque je lui demande d'accéder au résultat déja calculé dans la matrice 3d.

Ca doit être lié au parcourt de l'image sous opencv qui peut être n'est pas assez performant pour un traitement pixel par pixel...

(Pour info le simple traitement du flux webcam avec cet accès à la matrice me donne du 5images par seconde sur un bon PC Windows, du 0.75 image par seconde sur un eeePC windows 600Mhz et environ 10 images par seconde lorsque le programme est compilé sous mac au lieu de Visual Studio)

Il faudra peut être que je prenne autre chose que le compilateur de Visual Studio pour les performances...

[TropMDR]

On peut voir la boucle de parcours de la matrice ?

[white_tentacle]

(pour le stockage d'un fichier sauvegarde, il y aura bien sur une optimisation des longues chaines de 1 et de 0, mais pour le temps réel, je doute que ca soit bon de réaliser une compression des données)

En fait, si. Là, ta matrice est trop grosse pour tenir dans le cache processeur (surtout avec 1 booléen sur 8 bits). Donc tu te prends des page faults à tour de bras (d'autant plus qu'il y a de couleurs sur l'image), ce qui plombe probablement tes perfs.

[TropMDR]

En fait, si. Là, ta matrice est trop grosse pour tenir dans le cache processeur (surtout avec 1 booléen sur 8 bits). Donc tu te prends des page faults à tour de bras (d'autant plus qu'il y a de couleurs sur l'image), ce qui plombe probablement tes perfs.

Ses booléens sont sur un seul bit. Mais de toutes façons, il est quand même peu probable qu'une image tienne en cache...
Et c'est justement pour ça que je lui ai demandé la boucle de parcours, pour vérifier qu'il fait ça dans le bon sens

[etienne007]

Il n'y a pas de parcourt de la matrice 3d, sauf lors du remplissage mais à ce moment la vitesse m'importe peu.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	for (int i=0; i<256; i++) {
		for (int j=0; j<256; j++) {
			for (int k=0; k<256; k++) {
				setEstPeauTable(i,j,k, estPeauCalcule(i, j, k) ); // estPeauCalcule correspond à mon systeme d'equation
			}
		}
	}

Ce qui est couteux et qui freine le temps réel c'est le parcourt de la frame webcam avec opencv:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CvScalar scal;
 
for(int x=0; x < frame->width ; x++)
{
	for(int y=0; y < frame->height; y++)
	{
		scal = cvGet2D(frame, y, x);
		if(crit->estPeau((int)scal.val[0],(int)scal.val[1],(int)scal.val[2]))
		{
		        //on marque le pixel d'une autre image "masque" en noir
		}
			else
		{
			//on marque le pixel d'une autre image "masque" en blanc
		}
	}
}

des long int de la matrice sont donc lus 0,3 millions de fois par frame.

[Joel F]

Personnellement j'éviterais le if dans la boucle for et j'utiliserais l'opérateur ternaire si l'image de destination est la même. Certains compilos vectorise tout seul ce genre de truc ou du moins émettent l'instruction correct pour ?: sans saut.

Ensuite parcours tu bien ta matrice dans le sens de la mémoire histoire de pas péter le cache ?

oh est pourquoi le cast en int ?