explique : pourquoi un système d'équation linéaire ne suffirait pas  ?

par ailleurs, je penses que si le rectangle fait 6.4 4 , la fenêtre te montre x' de -3.2 à +3.2 et y' de -2 à +2

donc
x' = (x - 0.5)*6.4
y' = (y - 0.5)*4
z' = (z - 1.5)/3

ceci dit : la talle de ta fenêtre ne devrais pas influencer sur les coordonnées spatiales, mais plutôt sur la position de la caméra et des objets ... je conserverait un espace en -1/+1 sur tout les axes (ou simplement à la même proportion): la sortie de la kinect est déjà "normalisée" ...  , et jouer sur  les paramètres de position et focale de la caméra.
ne pas oublier qu'on est dans un espace 3d avec une perspective...

et tu as trituré les propriété ( sous patch [pd PROPERTIES] de l'exemple (pix_openni-help.pd) ? Y'a des histoires de coordonnées "real world" "osc style" . (Et tout un tas de bazar qui a fait que perso je suis revenu à osceleton tout simple, exit les pix_freenect, pix_openni) (enfin ... j'ai pas eu envie de fouiller trop longtemps)

Salut, en effet c'est assez compliqué de faire coincider le Z de la Kinect avec celui de l'openGL...
tu devrait pouvoir entrevoir une solution dans ce papier : http://unspecified.wordpress.com/2012/0 … rix-maths/ (regarde à la fin...)

Oui, merci pour ces liens. Je vais regarder tout ça de près. J'espérais bien trouver une courbe plutôt que d'essayer d'établir des coefficients pour chaque position de Z.

Pour ce qui est des exemples du message de sakramh, la correspondance, dans ces exemples, est très approximative malheureusement.

Je ne pense pas que l'utilisation d'OSCeleton simplifie ce problème de correspondance entre les deux espaces. (J'avoue ne pas avoir réussi à l'installer sur mon Mac car ce n'est pas simple...) Je dirais même que cela complique un peu puisque l'on ne peut plus recevoir l'image de la kinect (sauf erreur de ma part) alors qu'avec Openni, on l'obtient directement.

apres si tu  veux juste faire coincider le Z avec X et Y, comme dit gwen, tu as le mode ortho, ou bien tu peux utiliser cette formule : newX=X-((X/4)*Z) et pareil pour le Y.
++

@ pob : ben non, vu que les deux capteurs (camera genre webcam et camera "sensor") sont dans la même boîte (la kinect) . Et que déjà dans les patches d'exemples de mesure de distance de pix_freenect il y a tout un tas de pépites de chocolat, non pardon, de [expr] avec des formules empiriques pour compenser/rectifier un problème lié à libfreenect  . Maintenant c'est vrai que dans Gem on peut modifier le placement de la camera rvb .

Dernière modification par sakramh (2013-10-01 14:43:17)

Oui, merci de ces infos. Je m'en suis finalement sorti en utilisant le mode ortho et des coefficients établis expérimentalement (sinon, c'est un casse-tête impossible...). Excellente aussi l'application melon ! Le seul dommage de ces applications externes est que l'on ne peut ressortir que les coordonnées du squelette et non l'image. C'est pourquoi je retourne vers open_ni qui fournit des données assez stables.

A propos des coordonnées, je voudrais bien comprendre la relation entre ce fichu espace GEM et ce que l'on met dedans...

Par exemple :

Si on prend une simple image chargée par un pix_image et dessinée par un pix_draw. L'image dans GEM est affichée dans sa taille d'origine (la taille que l'on retrouve si on ouvre l'image dans un éditeur d'image). C'est pratique, sauf que l'on ne peut lui appliquer aucune transformation, déplacement, rotation, etc (impossible avec pix_draw).

Mais si on affiche cette même image avec un pix_texture et un rectangle (sans argument), l'image prend une taille carrée de 1x1. Après cela, c'est tout un pataquès pour lui redonner sa taille d'origine : le seul moyen que j'ai trouvé c'est d'utiliser un pix_info pour ressortir la taille de l'image en pixels, de diviser la taille en X et en Y par 125 (un chiffre magique dont la provenance m'échappe...) et de l'appliquer dans les entrées width et height du rectangle.

Auriez-vous une explication à cela ou une solution meilleure que mon usine à gaz ?