Jiav, étant donné que mon résultat n'est pas exactement le même pour les trois sommets, cela peut vouloir dire que mon triangle n'a pas subi une simple translation, comme vous me l'avez précisé.
Connaissez-vous une méthode avec laquelle je pourrais identifier la translation + rotation ? Peut-être en prenant 2 ou 3 points au départ, et après je pourrais comparer si je retrouve la même (translation + rotation) avec un autre couple/trio de points appartenant à un autre coin.
Merci
Ok. Tu as donc trois méthodes qui te disent toutes la même chose: "dérive nulle, à 1 ou 2 pixels près".Envoyé par aude21
Imagines que nous sommes en congrès et que tu me présentes le résultat de ton algorithme. Si tu me dis que le résultat est 0,161404126 pixels, je vais rester poli mais les chances sont que j'aille rapidement voir quelqu'un d'autre. Parce que si tu dis "le résultat est 0,161404126 pixels", moi ce que j'entendrais c'est "et je ne sais pas du tout ce que ça veut dire". Tu es en train de donner une précision au milliardième de pixel près!
C'est un point majeur: tu es en train de te perdre à analyser du bruit expérimental alors qu'il n'y a plus rien à tirer de la comparaison de ces deux images. Si tu veux choisir le meilleur algorithme parmi les différentes options sur lesquelles tu te questionnes, il faut que tu fasses autre chose.
Prend une image expérimentale "mère" et tires-en deux images "filles" un peu plus plus petites et avec un décalage de m*n pixels (ce qui simule un drift [m,n]), puis fourni ces deux images filles à tes algorithmes de détection du drift. En variant [m,n] tu pourras alors comparer les décalages trouvés par tes différents algorithmes et combinaisons d'algorithmes, et conclure sur leur niveau de précision réel ainsi que leur éventuel biais.
Quel est le problème avec soustraire -2?
Au risque de t'encourager à continuer à analyser du bruit... tu peux simplement programmer une exploration systématique de toutes les petites transformations appliquée à tes images (ajout de translation et de rotation) et prendre celle qui minimise l'erreur avec la nouvelle image. Un avantage est que tu pourras visualiser l'erreur en fonction des rotations/translation, ce qui aidera à former ton intuition de ce qui se passe avec ces algorithmes.
Je suis d'accord que cette précision peut paraître absurde, seulement mes déplacements (position2-position1) devraient être de l'ordre du 10^-8, 10^-9, et à cause de mon drift, ils sont de l'ordre de 10^-1. Si j'utilise ces déplacements, je vais trouver des forces aberrantes (forces exercées par la cellule sur le matériau), étant donné qu'elles seront beaucoup trop élevées!!
Ce pourquoi c'est un problème de soustraire -2, ce n'est pas assez précis pour ce dont j'ai besoin!
Merci pour vos idées, je vais essayer de trouver un code pouvant réaliser une exploration systématique. Sinon je pensais trouver la rotation+translation une matrice de rotation, pensez-vous que ça puisse marcher?
Le problème n'est pas que cette précision peut paraître absurde. Le problème est que cette précision est complètement, définitivement, irrévocablement, absurde. Frappe violemment le plat de ton front sur la table et répète après moi: "cette précision est absurde" "cette précision est absurde" "cette précision est absurde"
Quand tu auras fini de jouer avec la table, vérifies tes unités et répètes après moi: "ce ne devrait pas être de l'ordre du nanopixel" "ce ne devrait pas être de l'ordre du nanopixel" "ce ne devrait pas être de l'ordre du nanopixel"
Donc, c'est quoi la vrai précision dont tu as besoin? Combien de pixel par mètre pour tes images? Je soupçonne que si tu réponds à ces deux questions, ta quête sera terminée.
Effectivement vous avez raison, mes unités ne sont pas cohérentes entre mes deux codes (code1 qui traque les billes et code2 qui convertit les déplacements). Merci pour votre aide!
Je cherche donc à transformer mes pixels en mètres (ce qui est fait dans le code2 pour transformer les déplacements en forces).
Dans l'exemple fourni avec le code, la dimension de la photo utilisée est de 1024*1024 pixels, et la résolution verticale et horizontale est de 96ppp.
Au moment de fixer les paramètres, il y a : pix=116e-9 ; %size of one pixels in meters
Je ne comprends donc pas comment ils sont arrivés à ce résultat concernant la taille d'un pixel en mètre, au vu des dimensions et résolution de la photo...
Mes photos sont aussi de 96ppp, de dimension 680*512 pixels.
Si on considère que taille de pixel = 2,54/RESOLUTION (en PPP) = 2,54/96 = 0,026cm (Sachant que 1 pouce = 2,54 cm).
je devrais alors avoir la même taille que code2 pour mon pixel, puisque l'on a la même résolution...ce n'est pas le cas.
Est-ce que mon calcul est faux, ce qui me paraît probable puisque je ne prends pas en compte la dimension de la photo?
Merci
Oui, en fait la "résolution" n'a pas grand chose à voir avec la taille de l'image. Une même photo peut être en 96 ou en 96000 sans aucun changement au contenu du fichier. La "résolution" est une juste façon de dire à ton imprimante "imprime moi avec 96ppp" ou "imprime moi avec 96000ppp". Si tu augmentes la "résolution", l'impression sera plus petite. Si tu la diminues, l'impression sera plus grande. Mais cela ne dit rien sur le contenu ni sur les dimensions réelles de la photo prise.
C'est impossible de déterminer cela uniquement avec les dimensions et la résolution. Ce qu'ils ont du faire c'est photographier un objet de dimension connue, puis de compter le nombre de pixel correspondant à cette longueur, et enfin avec une simple règle de trois cela donne la taille d'un pixel en unité métrique.
Si rien n'a changé depuis cette calibration, alors tes pixels valent encore 0.116 micromètres. A vue de pif cela semble grosso modo correct (en regardant la taille de la cellule sur ta photo 3), et donc tu aurais un déplacement réel de l'ordre du dixième de micron (ce qui est très bien).
Si tu as besoin d'une précision de cet ordre, bingo c'est parfait (sauf qu'il serait prudent de vérifier tes algorithmes, par exemple Prend une image expérimentale "mère" et tires-en deux images "filles" un peu plus plus petites et avec un décalage de m*n pixels (ce qui simule un drift [m,n]), puis fourni ces deux images filles à tes algorithmes de détection du drift. En variant [m,n] tu pourras alors comparer les décalages trouvés par tes différents algorithmes et combinaisons d'algorithmes, et conclure sur leur niveau de précision réel ainsi que leur éventuel biais. mais là je radote).
Si en revanche tu as vraiment besoin de 10^-8 ou 10^-9 m (ce qui, très franchement, m'étonnerait beaucoup) alors ta conclusion devrait être que cette méthode n'est pas assez reproductible pour tracker un déplacement de cet ordre. Si c'est le cas tu pourrais toujours essayer d'améliorer tes algorithmes, mais àmha la limitation est physique (liée à la précision de ton microscope).
Hello,
Je vais faire bref: il existe déjà des tonnes d'outils pour faire ça. Il te faut absolument implémenter ta méthode ou un existant suffit ?
Dans tous les cas, je peux te suggérer quelques pistes. Déjà, il faut utiliser les bons termes (utile pour google): tu as un problème typique de racalage d'images (image registration en anglais). Maintenant, il y a principalement 2 types de recalages: affine ou non-linéaire.
Les méthodes de recalage affine supposent qu'il n'y a rien de plus qu'une translation et rotation entre tes deux images. C'est à dire qu'elles doivent se superposer parfaitement (au bruit près) si tu connais la rotation et la translation à appliquer. Les méthodes non-linéaires sont elles capables de recaler deux images entre elles même si d'importantes modifications locales sont présentes. Par exemple, si on prend une photo de toi avec un grand sourire et une photo de toi avec une expression neutre, le racalage affine alignera bien les cheveux, les yeux, le nez, mais l'alignement au niveau de la bouche sera totalement imparfait. Si tu utilises une méthode non linéaire, la bouche sera déformée de manière à avoir une correspondance quasiment parfaite entre les deux photos. C'est très utile pour tracker le mouvement par exemple...
Quoiqu'il en soit, aussi bien pour le recalage affine que non-linéaire, je ne saurais que trop te recommander le logiciel ANTs. Il est extrêmment performant, peut faire du recalage affine et non-linéaire.
http://stnava.github.io/ANTs/
Si tu tiens absolument à tout réimplémenter, eh bien c'est un bien long et fastidieux travail pour refaire ce qui a déjà été fait (et refait, et rerefait, et super optimisé... C'est un champ d'étude depuis 30 ans dans l'imagerie médicale) mais tu trouveras les références nécessaires sur le site de ANTs.
Mon psychiatre, pour quinze mille francs, il m'a débarrassé de ce que j'avais : quinze mille francs
Les lecteurs avertis auront bien sûr lu "recalage".
Ce qui se conçoit bien s'énonce clairement ; et les mots pour le dire arrivent aisément.
Oups !Les lecteurs avertis auront bien sûr lu "recalage".
J'en profite pour partager ce lien qui introduit à la problèmatique du rEcalage d'image avec matlab :
https://fr.mathworks.com/discovery/i...istration.html
Mon psychiatre, pour quinze mille francs, il m'a débarrassé de ce que j'avais : quinze mille francs
Bonjour,
Je découvre l"article "recalage d'image" dans Wiki. Il est clair et fort intéressant.
La seule chose que l'on pourrait regretter est qu'il n'est pas précisé que ce type de technique existe depuis fort longtemps, non pour des images, puisque l'imagerie informatisée n'existait pas, mais dans le domaine de la cartographie et de la photographie aérienne.
C'est en fait un très vaste domaine. On peut seulement regretter que l'article ne fasse pas référence à la visualisation 3D. En tout cas, je ne l'ai pas vu.
Ce sujet vaudrait largement l'ouverture qu'un nouveau sujet où chacun pourrait apporter ses connaissances.
Eh beh, décidément j'étais pas en forme...
La méthode de recalage affine peut inclure translation, rotation ET homothétie. En fait, c'est défini comme le nombre de degrés de liberté (DDL) qu'on donne à la transformation. Typiquement en 2D, la translation compte pour 2 DDL, la rotation pour 1 DDL, et l'homothétie pour 1 ou 2 DDL (zoom global ou zoom en X différent du zoom en Y).
Mon psychiatre, pour quinze mille francs, il m'a débarrassé de ce que j'avais : quinze mille francs
Vous oubliez l'affinité.
En fait,, personnellement j'appelle "transformation affine" une transformation qui comporte une translation, une rotation, une homothétie et une affinité. Pour la définir, en 2D on a besoin de 3 points homologues au minimum. En 3D, il nécessaire d'avoir 4 points homologues. La transformation affine ne conserve pas les angles.
Il y a lieu de remarquer qu'il y a un gros doute sur le sens de l'adjectif "affine". A mon avis, pour toute discussion employant ce terme, il est préférable de préciser le sens employé.
La transformation définie par une translation, une rotation et une homothétie serait, dans mon vocabulaire, une similitude.
Humhum... Je ne l'ai pas oublié, je ne sais simplement pas ce qu'est l' "affinité"...
Mon psychiatre, pour quinze mille francs, il m'a débarrassé de ce que j'avais : quinze mille francs
J'observe que les mêmes notions qui font appel aux mêmes choses, dans un même pays n'ayant qu'une seule langue officielle portent des noms différents. J'ai proposé un certain nombre de fois la création d'un lexique qui définirait précisément le sens des termes et leurs différentes interprétations suivant la grande quantité d'applications possibles et donc d'interprétations.
D'abord deux figures "égales" sont deux figures isométriques et de même sens.
Soit deux figures F et F' égales, Il existe une rotation et une seule qui permet de transformer la figure F en la figure F'.
Si deux figures F et F' sont semblables, c'est à dire que leurs angles sont égaux deux à deux et que chaque longueur de F' est égale à la longueur correspondante de F multipliée par un facteur k non nul, alors, la transformation s'appelle similitude. Soient deux figures F et F' répondant à ces conditions, il existe une similitude (rotation + homothétie) et une seule permettant de passer de F à F'.
Si on rajoute une translation, alors il existe une infinité de transformations, produit de translation, rotation, homothétie pour passer de F à F'.
Jusque là, je n'ai parlé que de figures égales puis semblables.
Il existe une transformation, appelée affinité qui transforme une figure F en F', tel que le rapport des abscisses est 1 et le rapport des ordonnées est lambda, différent de 1. C'est la transformation qui permet de transformer un cercle en une ellipse.
La transformation affine est la transformation qui comprend une translation, une rotation, une homothétie et une affinité. C'est celle dont vous parlez lorsque vous dites que le zoom des X et celui de Y n'est pas le même. C'est très figuré et c'est là où un lexique serait utile.
Bien-sûr, on peut renommer tout cela de la façon qu'on veut, mais il me semble que, pour se comprendre, c'est plus pratique de parler la même langue. J'ai bien remarqué que vous habitez Montréal, ma fille aussi et je ne me souviens pas qu'elle ait eu des problèmes du type "traduction". J'ai plutôt l'impression que c'est lié à la profession médicale. Il y a sur ce forum des membres qui y sont aussi très liés, peut-être les échanges seront plus faciles.
Bonne soirée.
bonsoir
en dimension 2, je suppose.
rotation composée avec une translation.
faux : en général, pour passer d'une figure F à une figure semblable F', il existe une seule similitude.
Bon PrR,
Si tu tiens absolument à rajouter une translation, c'est ton droit.
Si elle est de vecteur nul, alors c'est comme s'il n'y en avait pas. Sinon, on peut la choisir comme on veut.
Je sais bien que la géométrie n'est plus au programme, donc, on ne te l'a pas enseignée, alors au lieu de dire c'est pas vrai, demande des explications.
Bon, alors prenons deux figures égales, dans le plan naturellement, et explique comment tu calcules la transformation "translation + rotation".
Je ne fais rien, je n'ajoute pas translation : c'est toi qui parle d'isométrie, de similitude, etc... il y a là dedans des translations, tu sembles l'oublier.
justement, je t'en donne ! Mais comme d'habitude, tu ne veux rien entendre...
Déjà, le mots "égal" est très mal choisi : deux figures égales ont les mêmes points.
Mais j'ai compris que, pour toi, "deux figures égales" signifie "deux figures isométriques et de même sens."
LA transformation "translation + rotation" qui fait quoi ?
Personnellement, j'aime bien l'écriture z --> exp(i t) z + b avec t réel (angle) et b complexe (translation).
Possible aussi, la notation matricielle X --> RX+B avec R la matrice d'une rotation (pas une matrice quelconque !)...
Ce sont des conditions de géométrie élémentaire. Moi, j'y suis pour rien, c'est le cours de mathématiques de Cagnac et Thiberge.
Donc, on appelle "figures égales" des figures isométriques et de même sens. Deux figures constituées des mêmes points sont des figures identiques, ce n'est pas tout à fait la même chose.
Hypothèse : dans le plan, soient deux figures égales. Démontrer qu'il existe une rotation et une seule pour transformer l'une dans l'autre.
Démonstration : Soit F un triangle ABC quelconque et F' un triangle A'B'C' quelconque, égal au triangle ABC, c'est à dire que les longueurs homologues, côtés des triangles, sont égales, ainsi que les angles orientés.
Traçons les médiatrices des côtés joignant les points homologues. On démontre facilement que ces médiatrices se coupent en un seul point. Ce point est le centre de rotation permettant de passer de F à F'. Ceci n'est vrai que si les médiatrices se coupent, c'est à dire que les figures F et F' ne se déduisent pas l'une de l'autre par un translation.
Application : supposons (on est dans un contexte informatique) que les figures F et F' sont très loin l'une de l'autre, c'est à dire que leurs coordonnées ne sont pas du même ordre de grandeur, ce qui est très souvent le cas. Si on appliquait le calcul du centre de rotation directement, les valeurs numériques seraient très grandes, ce qui est un inconvénient majeur en matière de calcul numérique. On peut donc sans risque appliquer une translation quelconque à l'une des figures. Par exemple, un vecteur constitué de coordonnées rondes, d'autres préfèrent utiliser le centre de gravité d'une des figures. Ce choix n'a aucune importance. La transformation sera donc le produit d'une translation et d'une rotation.
Développement : Si les figures F et F' sont directement semblables (sauf translation), il existe une transformation, produit d'une homothétie et d'une rotation, et une seule pour passer de F à F'.
Si les figures ne sont pas semblables, alors il faut utiliser d'autres méthodes. Dans le cas général, la transformation affine sera utilisée.
Pardon PrR, j'ai oublié de répondre à ta question.
Soit deux figures F et F' égales dans le plan, comment fais-tu pour calculer LA transformation "translation + rotation" qui permet de passer de F à F', c'est à dire de transformer F en F' ?LA transformation "translation + rotation" qui fait quoi ?
Là, il me semble que la question est claire.
Dlzlogic,
Merci pour ton explication. J'ignorais que ça se nommait "affinité" (que je ne connaissais que sous son terme anglais shear), et en effet un autre de mes oublis
Pour revenir au sujet, en fait je parlais du nombre de DDL pour coder tout ça. En gros, l'implémentation naïve pour le recalage affine est assez simple : définir une fonction de coût (par exemple moindres carrés entre les images) et la minimiser. Les DDL n'interviennent que dans la définition de la fonction de coût. Un tels algorithme suffira peut-être à faire du bon recalage seulement si certaines conditions sont réunis (images assez proches, zones d'overlap, etc...). Mais les méthodes à disposition sur le net (comme ANTs) vont beaucoup plus loin que ça (utilisation du multi-scale par exemple, fonctions de coût plus complexes) et marchent quasiment à tous les coups
Mon psychiatre, pour quinze mille francs, il m'a débarrassé de ce que j'avais : quinze mille francs
Dlzlogic,
Merci pour ton explication. J'ignorais que ça se nommait "affinité" (que je ne connaissais que sous son terme anglais shear), et en effet un autre de mes oublis
Pour revenir au sujet, en fait je parlais du nombre de DDL pour coder tout ça. En gros, l'implémentation naïve pour le recalage affine est assez simple : définir une fonction de coût (par exemple moindres carrés entre les images) et la minimiser. Les DDL n'interviennent que dans la définition de la fonction de coût. Un tels algorithme suffira peut-être à faire du bon recalage seulement si certaines conditions sont réunis (images assez proches, zones d'overlap, etc...). Mais les méthodes à disposition sur le net (comme ANTs) vont beaucoup plus loin que ça (utilisation du multi-scale par exemple, fonctions de coût plus complexes) et marchent quasiment à tous les coups
Mon psychiatre, pour quinze mille francs, il m'a débarrassé de ce que j'avais : quinze mille francs
c'est évidemment faux puisqu'une translation est une isométrie et que deux figures translatées l'une de l'autre (en particulier "égales") ne sont pas image l'une de l'autre par une rotation .
C'est tellement élémentaire que je me demande pourquoi tu insistes à dire des bêtises pareilles.
ben non , c'est faux : elle peuvent être parallèles ! Justement quand l'isométrie utilisée est une translation.
Oui, c'est maintenant clair et la solution est totalement élémentaire.
Une translation T est donnée par le vecteur défini par les centres de gravité f et f' de F et F' respectivement : posons T(f) = f'
Ensuite, on considère un point x de F (x différent de f) , son homologue x' de F (image de x par l'isométrie envoyant F sur F') : on définit la rotation R de centre f' et d'angle < vect(f', T(x)) , vect(f', x') >
Alors F' = R o T (F)
Dernière modification par PrRou_ ; 03/02/2017 à 17h21.
Pourquoi le centre de gravité de la figure et pas l'un des points, ou un autre, ou son voisin, ou pas de translation du tout ?
oui, on peut aussi prendre un point y de F et son image y' de F' par l'isométrie, pourquoi pas.
Cela dit, les centres de gravité sont image l'un de l'autre par l'isométrie, donc il n'y a pas de souci.
...ou pas de rotation du tout dans certains cas.
Tu demandes une composée d'une rotation et d'une translation : je t'en ai donnée une. Si tu veux autre chose, alors dis-le.
@ PrRou_,
Bon, moi, je ne t'ai rien demandé, j'ai décrit et expliqué des choses que je connais fort bien, comme tous ceux qui ont à manipuler ce type de calcul.
Tu est intervenu sans cesser de répéter que je dis de bêtises. Le coup du centre de gravité, tu l'as certainement lu dans Wiki. Dans la pratique, on écrit X-Tx et Y-Ty cf les formules indiquées, Tx et Ty étant n'importe quoi, par exemple la valeur ronde des coordonnées les plus grandes. Souvent, on prend les coordonnées du premier point de la liste, pourquoi se casser la tête. Encore une fois, cela n'a aucune importance.
Ceci étant précisé, sans rentrer dans les détails, ce type de calcul se fait en résolvant le système linéaire suivant
X = Tx + C.x - S.y
Y = Ty + S.x + C.y
Tx et Ty sont les composantes d'un vecteur de translation éventuel ou nul. Ce sont des paramètres, constantes prises au hasard intelligemment, et non des inconnues.
C et S sont, dans le cas général (similitude), le produit d'un cosinus, et d'un sinus, par le facteur d'homothétie. Dans le cas de transformation affine, c'est un peu plus compliqué.
Bien sûr, le plus souvent dans la pratique, on aura plus de deux points de calage. D'où la nécessité de faire un calcul supplémentaire en appliquant la méthode des moindres carrés.
Mais cela fera l'objet d'explications plus compliquées que de simples notions de géométrie élémentaire, si tu le souhaites.
Avertissement de la modération : la petite guéguerre entre Dlzlogic et PrRou_ doit cesser car elle est exaspérante, sinon nous pourrions être amenés à prendre des mesures dommageables pour l'un et l'autre.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
La question initiale de aude21 ayant été détournée au profit d'une guerre personnelle et de longue date entre deux protagonistes c'est discussion est fermée.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
