Rotation - Page 1

Comment faire la rotation d'une image j'ai déja fait ça mais le bléme c'est que ca marche que pour la moitié du cercle et en plus la vitesse de rotation n'est pas régulière.
Prgm
ClrDraw
PxlCrcl 51,119,50
ª50»x
Loop
PxlLine 51,119,int(§(ªx^2+2500))+51,x+119
If getKey()=264:Exit
PxlLine 51,119,int(§(ªx^2+2500))+51,x+119,0
x+1»x
EndLoop
DispHome
EndPrgm
Bien entencu la c'est pas une image qui tourne!!!!!!!!Mais je supose que c'est la même principe

Le mieux pour la rotation, c'est d'utiliser les nombres complexes.

lol j'ai pas apris fait chier

... les matrices de rotations

Les complexes sont plus efficaces pour du 2D.

mais bien sur... c'est tout aussi efficace que les matrices de rotations, d'ailleur c'est le meme fonctionnement #nb#

Avec votre truc la que j'ai pas appris comment je fait j'attend qu'on me l'enseigne ce truc?

Bah, t'embête pas avec ça. Tu as le rectangle de l'image. Tu lui appliques une rotation et de cette façon tu peux connaître les coordonées des coins. Avec ça, tu remplis le rectangle en utilisant l'image source -> tu fais la rotation inverse pour chaque pixel du rectangle (c'est pas très rapide, mais ça donnera le meilleur rendu visuel je pense.

Bah, t'embête pas avec ça. Tu as le rectangle de l'image. Tu lui appliques une rotation et de cette façon tu peux connaître les coordonées des coins. Avec ça, tu remplis le rectangle en utilisant l'image source -> tu fais la rotation inverse pour chaque pixel du rectangle (c'est pas très rapide, mais ça donnera le meilleur rendu visuel je pense.

En basic c'est pas terrible

comment on fait pour faire rotationner un rectangle ???

ben, tu appliques la rotation aux 4 points de ce rectangle (...)

g jamais fait de trigo.

aRf, c'est pas possible ...

KK: complexes pour la 2D et quaternions pour la 3D, c bien connu ... heuresement qu'il n'y a pas que ca ...

bah... à part les trucs de base genre -sinx+cosy=-cos+siny ou un truc du genre, g jamais fait.

je viens de penser à une autre technique: tu peux faire des rotations de 0 à 89° simplement en décalant des lignes verticales vers le haut et le bas et des lignes horizontales vers la gauche et la droite (pas n'importe comment, mais tu peux calculer de combien vers le haut/bas et de combien ver la droite/gauche avec l'angle).

Ce n'est pas une rotation, c'est une distortion. Ça peut être une bonne approximation pour les petits angles, mais c'est à oublier complètement pour les gros.

Oui mais c'est bien plus rapide qu'autre chose si on fait ça correctement.

Plus rapide, mais totalement faux...

Nombres complexes, matrices de rotation, ... vous n'avez pas plus compliqué, tant qu'à faire ?
Certes, ces deux techniques marchent très bien.
Certes, en 2D, ces deux techniques sont strictement équivalentes.
Mais comme tout le monde n'a pas votre bagage mathématiques, serait-ce vraiment dégradant pour vous d'utiliser un langage simple, à base de Sinus et Cosinus ?

Allez hop, un petit cours de Maths !

Rotation avec les nombres complexes
Soit un point de coordonnées (x;y), représenté par le nombre complexe z=x+iy.
Un rotation d'un angle @ (Theta sur TI-92, la touche à côté du 'm') autour de l'origine (0;0) est équivalente au produit de z par r=e^(i@)=Cos@+iSin@.
Les coordonnées (x';y') du point après rotation sont donc :
x'+iy' = z' = z*r = (x+iy)*(Cos@+iSin@) = xCos@+ixSin@+iyCos@-ySin@ = (xCos@-ySin@)+i(xSin@+yCos@).
Donc x'=xCos@-ySin@ et y'=xSin@+yCos@.
Note : il suffit de savoir que i*i = -1 en complexe pour comprendre le calcul précédent.

Rotation avec les matrices de rotation
Soit un point de coordonnées (x;y), représenté par le vecteur colonne Z=[x;y].
Un rotation d'un angle @ autour de l'origine (0;0) est équivalente au produit matriciel de Z par M=[Cos@,-Sin@;Sin@,Cos@].
Les coordonnées (x';y') du point après rotation sont donc :
[x';y'] = Z' = M*Z = [Cos@,-Sin@;Sin@,Cos@]*[x;y]=[xCos@-ySin@;xSin@+yCos@].
Donc x'=xCos@-ySin@ et y'=xSin@+yCos@.
Note : là, il faut connaître le produit matriciel ... voici une très bonne page que je viens de trouver à ce sujet.

Conclusion
En 2D, les deux techniques sont donc bien équivalentes ... mathémagique !
Ce n'était vraiment pas la peine de vous chamailler pour ça.
Mais au lieu de simplement donner le nom, il vous aurait suffit de dire :

Sauf qu'avec cette réponse, vous auriez perdu votre auréole d'être supérieur qui connaît plein de choses en Maths, pas vrai ?

Sur TI
Comme c'est une calculatrice, le plus rapide et efficace est bien entendu d'utiliser les fonctions mathématiques avancées comme les nombres complexes ou les matrices de rotation.
Mais quand on ne connais pas tout ça, faisont basique, utilisons les Sinus et Cosinus :

Prgm
ClrDraw
PxlCrcl 51,119,50
50->x
0->y
3°->@
cos(@)->c
sin(@)->s
Loop
PxlLine 51,119,51+x,119+y
If getKey()=264:Exit
x*c-y*s->xp
x*s+y*c->yp
PxlLine 51,119,51+x,119+y,0
PxlCrcl 51,119,50
round(xp,0)->x
round(yp,0)->y
EndLoop
DispHome
EndPrgm

Le seul problème, c'est qu'à chaque étape, on utilise les valeurs calculées précédemment, qui sont des valeurs arrondies, d'où un risque de divergence.
Ce problème est dû au fait que les valeurs de c et s sont fixées : on applique toujours la même rotation au point précédemment calculé.

Une autre méthode consiste à toujours repartir sur des bases saines, à savoir les valeurs initiales de x et y, et à modifier à chaque étape c et s, c'est-à-dire @ :

Prgm
ClrDraw
PxlCrcl 51,119,50
50->x0
0->y0
0->@
3.°->d@
round(x0*cos(@)-y0*sin(@),0)->x
round(x0*sin(@)+y0*cos(@),0)->y
Loop
PxlLine 51,119,51+x,119+y
If getKey()=264:Exit
@+d@->@
x0*cos(@)-y0*sin(@)->xp
x0*sin(@)+y0*cos(@)->yp
PxlLine 51,119,51+x,119+y,0
PxlCrcl 51,119,50
round(xp,0)->x
round(yp,0)->y
EndLoop
DispHome
EndPrgm

Attention, le point dans 3.°->d@ est très important, sinon les calculs trigonométriques sont plus ou moins longs selon la valeur de @, et la vitesse de rotation n'est plus constante.

Par contre, pour une image complète, il faut appliquer ceci à chacun de ses points, ce qui ralentit d'autant le programme ...

@++

Mais quand on ne connais pas tout ça, faisont basique, utilisons les Sinus et Cosinus :

et ça reviens donc exactement au même ...

Par contre, pour une image complète, il faut appliquer ceci à chacun de ses points, ce qui ralentit d'autant le programme ...

c bien pour ça que c mieux d'utiliser des matrices (R@, [[X][Y]], et même avec ça c très long ) étant donné que Thor veux faire tourner des images et pas un simple point. Sinon sa calculatrice n'aura plus de piles avant que l'image ait commencé à tourner

A mon avis le problème c surtout de conserver l'apparence de l'image lors de la rotation . Pour @=k.Pi/2 ya aucun problème (d'autant plus qu'on peut utiliser des tranposées ce qui est encore plus rapide ) mais si on prend @ quelquonque alors on voit plus rien du tout (hélas les pixels ne tournent pas avec l'image !)...

KK: Est-ce que les librairies standardes pour iso c99 seront dans tigcc 0.95 ? (je pense notamment à l'utilisation des complexe, types rapides etc.)

Le grand avantage des complexes est que tu calcules e^(i*theta) une fois, et tu fais toutes tes transformations de coordonnées avec une multiplication complexe, c'est-à-dire 2 multiplications réelles, une addition réelle et une soustraction réelle. Pas besoin de faire des sinus et des cosinus pour chaque pixel. C'est un gain immense, que les formules naïves de Ethanael ne montrent pas.

nEUrOO :
KK: Est-ce que les librairies standardes pour iso c99 seront dans tigcc 0.95 ? (je pense notamment à l'utilisation des complexe, types rapides etc.)

Euh, pas vraiment. Les complexes sont implémentés depuis longtemps (c'est GCC qui s'en occupe), mais il n'a pas les fonctions comme le sinus complexe etc., juste les opérations de base. Et pour le reste, ça n'y est pas encore. Tu veux dire quoi exactement par "types rapides"?

int_least8_t, int_fast8_t, etc.

Bah, je peux vous rajouter les typedef ou #define qu'il faut si tu veux (pour la compatibilité), mais je ne vois carrément pas l'intérêt pour TIGCC. On connaît nos types.

Ouep .. compatibilité iso c99 quoi ... pas vraiment d'autre intérêt

Kevin Kofler a écrit :
Le grand avantage des complexes est que tu calcules e^(i*theta) une fois, et tu fais toutes tes transformations de coordonnées avec une multiplication complexe, c'est-à-dire 2 multiplications réelles, une addition réelle et une soustraction réelle. Pas besoin de faire des sinus et des cosinus pour chaque pixel. C'est un gain immense, que les formules naïves de Ethanael ne montrent pas.

J'ai écrit :
Comme c'est une calculatrice, le plus rapide et efficace est bien entendu d'utiliser les fonctions mathématiques avancées comme les nombres complexes ou les matrices de rotation.
Mais quand on ne connais pas tout ça, faisont basique, utilisons les Sinus et Cosinus
[...] les valeurs de c et s sont fixées : on applique toujours la même rotation au point précédemment calculé.

Apparemment, tu lis trop vite : de même que tu calcules e^(i*theta) une fois, je calcule c et s une fois, pas besoin de le refaire à chaque pixel.
Et comme je m'adressais à Thor qui ne connais pas les complexes, j'ai donné les formules avec Sinus et Cosinus qui ne sont pas naïves, mais au contraire sont exactement ce que la calculatrice fait en interne pour une multiplication complexe (d'ailleurs, tu le dis toi-même) : la seule différence est qu'au lieu d'utiliser la routine de multiplication complexe implémentée dans l'AMS, j'ai écrit une partie de cette routine en TI-Basic (une partie seulement, pas besoin d'extraire les parties réelle et imaginaire), d'où une légère perte de vitesse (un peu compensée par la non-extraction de real(z) et imag(z)).
Mais, je le répète, le problème de la méthode itérative, lorsque l'on calcule une seule fois son paramètre de rotation (que ce soit le couple {c;s}, le complexe e^(i*theta), ou la matrice de rotation), est le risque de divergence, d'autant plus visible sur une image complète qui se déforme alors.

imbibinebe a écrit :
et ça reviens donc exactement au même ...

Oui oui, exactement au même, à deux différences près :
- la routine est en TI-Basic au lieu d'être en Asm (dans l'AMS), d'où une vitesse moindre ;
- pas besoin de transformer les coordonnées du point initial en complexe ou vecteur colonne, ni de retransformer le complexe final ou le vecteur final en coordonnées, d'où un léger gain de temps.
J'ai d'ailleurs fait la démonstration mathématique pour montrer que les trois méthodes (calcul trigonométrique, calcul complexe, calcul matriciel) sont mathématiquement équivalente : d'ailleurs, si deux théorèmes mathématiques appliqués au même problème donnaient des résultats différents, ça se saurait ...

imbibinebe a écrit : c bien pour ça que c mieux d'utiliser des matrices

Mais non, justement, tu te contredis : ce n'est pas mieux, puisque c'est équivalent, les deux seules et uniques différences étant celles que je viens de citer.
Ta matrice de rotation, tu est tout de même obligé de l'appliquer à chaque point.

Par contre, je crois que ma phrase de conclusion a été mal formulée, puisqu'elle ne s'appliquait pas à la méthode trigonométrique, mais à toute méthode de rotation.
J'aurai dû passer 4 ou 5 lignes et écrire quelque chose comme :
Les exemples donnés appliquent la rotation à un seul point.
Pour une image complète, il faut appliquer la rotation, quelle que soit la méthode, à chacun de ses points, ce qui ralentit d'autant le programme.
Bien entendu, tous les points tournent du même angle, pas la peine de recalculer le paramètre de rotation à chaque pixel.

Mais bon, il était 14h10, et je commençais à avoir vraiment faim : désolé de vous avoir induit en erreur.
Le but de mon post était d'exposer concrètement les 3 méthodes (mathématiquement équivalentes), en réécrivant au passage son exemple, alors que vous vous étiez contentés jusque là de dire Utilises les nombres complexes ou Utilises les matrices de rotation.
D'ailleurs, j'aurais pu faire la feignasse et dire Utilises les transformations trigonométriques ...

@++

J'ai écris: et ça reviens donc exactement au même ...

j'ai oublié de dire : mathématiquement ...

et aussi: c bien pour ça que c mieux d'utiliser des matrices

parce que c vrai (et je ne me contredit pas :P).
ma matrice de rotation je l'applique à une autre matrice, pas à chaque point , et c donc largement plus rapide. (tu comptait peut-être utiliser une boucle en basic pour calculer les coordonnées de chaque pixel à allumer?)

j'ai essayé tes algos et c vrai que ça marche très bien pour faire tourner un point ...

Thor> voilà un exemple pour faire tourner une image quelquonque autour d'un centre (xo,yo).
1) c très très lent :-\
2) c pour v200, mais tu peux l'adapter pour 89 en remplaçant (239,127) par (159,99)
3) il est optimisable en vitesse, je pense :-).
4) c toi qui commandes la rotation avec les flèches <- ->
5) tu seras sûrement déçu par le résultat


rotpic(pict,xo,yo) \pict="nom image", (xo,yo) coordonnées du centre de rotation
Prgm
Local xydim,pictmat,xpictmat,ypictmat,screen,p,q,onoff,matrot,vectmat

vertel("d save","screen",0,0,239,127,"/","d clrs","/","d size",pict,"/","e retr","xydim")
vertel("d pict",pict,xo-floor(xydim[1]/2),yo-floor(xydim[2]/2),1)

Define matrot(@)=Func
Return [[cos(@),-sin(@)][sin(@),cos(@)]]
EndFunc

Define colget(@m,@n)=Func
(@m™[@n])™
EndFunc

mat>list((newMat(xydim[2],1)) .^ 0*list>mat(seq(q,q,1,xydim[1])) .- floor(xydim[1]/2))»xpictmat

mat>list((list>mat(seq(p,p,1,xydim[2])))™*((newMat(xydim[1],1))™) .^ 0 .- floor(xydim[2]/2))»ypictmat

vertel("d test",xpictmat .+ xo-1,ypictmat .+ yo-1,"/","e retr","pictmat")

pictmat .+ 1->pictmat
augment((list>mat(xpictmat))™,(list>mat(ypictmat))™)->vectmat

0->@

Lbl t@
floor(vectmat*matrot(@))->lvectmat
mat>list(colget(lvectmat,1)) .+ xo->xpictmat
mat>list(colget(lvectmat,2)) .+ yo->ypictmat

vertel("d clrs","/","d pixl",xpictmat,ypictmat,pictmat,"/",
"t draw","j'attends ",90,90,1,"/","e paus","/","e retr","@k","/","d clrs")

If @k[1]=340 Then
@-Pi/6->@
Goto t@
ElseIf @k[1]=337 Then
@+Pi/6->@
Goto t@
Else
EndIf

vertel("d pict","screen",0,0,1)
EndPrgm

5) tu seras sûrement déçu par le résultat

cf: post 19