Rotation - Page 2

et en plus le résultat ça dépend des dimensions de ton image. ça fonctionne mieux avec ximpair*yimpair pixels (le centre est plus facile à trouver )

Ethaniel :
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.

Euh, je te signale que quand il est 23:43 et qu'on paye 5 EUR par heure (Café Internet), on n'a pas vraiment envie de passer 3 heures à rédiger une explication.

En tout cas, merci d'avoir bien élaboré sur le sujet.

imbibinebe a écrit :
[...]
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?)

En effet, tu as parfaitement raison ... à un très léger détail près, mais on va dire que de la même manière que ceux qui ont balancé un nom de méthode sans rien expliquer, tu as été un peu trop concis pour être totalement compris.

Oui, ta appliques bien ta matrice de rotation à une seule autre matrice P (comme Picture) : seulement voilà, P est une matrice 2xN, avec N le nombre de pixel de l'image, chaque colonne de P étant un vecteur colonne 2x1 représentant les coordonnées d'un pixel.
Au lieu d'appliquer la matrice de rotation à chaque vecteur colonne (comme je le pensais dans mon algorithme simplifié, en utilisant effectivement une boucle Basic pour chaque pixel ), tu le fais sur la concaténation de ces vecteurs colonnes, ce qui accélère grandement le traitement.
Je n'avais pas pensé à cette méthode, et je pense que c'est effectivement la meilleure, même si on retrouve toujours le dualisme que j'avais explicité :
1/ en utilisant le produit de la matrice de rotation sur une grosse matrice, on utilise à fond l'AMS, ce qui fait gagner beaucoup de temps puisque l'Assembleur est plus rapide que le TI-Basic ;
2/ on est obligé de transformer l'image initiale en une matrice 2xN (la matrice P) en TI-Basic, et de retransformer à chaque étape la matrice P'=M*P en image à afficher, toujours en TI-Basic, ce qui fait perdre du temps.

Finalement, il y aura toujours le même dilemme, quoi que l'on fasse :
- soit la partie calculatoire est en TI-Basic, mais on travaille directement sur les coordonnées => méthode trigonométrique ;
- soit on optimise la partie calculatoire, mais il faut faire en TI-Basic la double conversion coordonnées <-> format utilisable dans le calcul (que ce soit nombre complexe, vecteur colonne ou matrice de concaténation) => méthodes complexe ou matricielle.


Pour ton algorithme, il y aura sûrement un petit problème de portage, puisque vertel, par exemple, n'existe pas qur TI-89/92/92II/92+ (il y a peut-être autre chose, mais je n'y ai jeté qu'un rapide coup d'oeil, et ce mot m'a interpellé).
Quant au mien, il ne me viendrait jamais à l'esprit de mettre quelque chose que je n'aurais pas moi-même testé en long, en large et en travers (d'où mon insistance sur le point de 3.°->d@).

@++

Kevin Kofler :
Euh, je te signale que quand il est 23:43 et qu'on paye 5 EUR par heure (Café Internet), on n'a pas vraiment envie de passer 3 heures à rédiger une explication.

En tout cas, merci d'avoir bien élaboré sur le sujet.

Houlà oui, je comprends parfaitement !
J'ai aussi testé le Cyber-Café (enfin, c'était plutôt un Cyber-McDo ) pendant mes vacances à Chamonix, et 3 Euros la 1/2 heure, ça fait mal !

Mais comme tu es souvent sur le forum, je n'ai pas imaginé un instant que tu puisses écrire d'un Cyber-Café ... toutes mes condoléances pour ton porte-monnaie qui doit souffrir .

Quant à ma dissertation, je n'ai aucun mérite, puisque j'ai tout le temps de le faire, ayant abandonné temporairement la rédaction de mon cours.

@++

tu as été un peu trop concis pour être totalement compris.

j'admet que ce n'est pas faux

Pour ton algorithme, il y aura sûrement un petit problème de portage, puisque vertel, par exemple, n'existe pas qur TI-89/92/92II/92+ (il y a peut-être autre chose, mais je n'y ai jeté qu'un rapide coup d'oeil, et ce mot m'a interpellé).

le seul problème de portage est que les écrans ont des dimensions différentes, d'où un problème de restauration de l'écran (sauf pour ceux qui utilisent bcp leur machine ...). Sinon vertel existe au moins pour v200, 89 et 92+(pour les autres je ne sais pas) et il y a même une version de vertel (vertel convert) qui résoud ces problèmes de portage

Apparemment tu ne connais pas vertel et je t'invite donc à l'utiliser (personnellement je ne peux plus m'en passer). J'pense aussi que flib n'est pas à négliger (mais c ptet parce que c la première librairie que j'ai connue ) pour certaine fct° (getline, insertline, komp) qui ne sont pas disponibles dans vertel ...

pdt ce tps g essayer d'améliorer un peu mon code pour faire "rotationner" une image:


rotpict(pict,xcsg,ycsg,d@)

1)"nom fichier pic" (pas trop grand de préférence )
2)coordonnée x (en pixels) du coin supérieur gauche de l'image
3)................ y ...................................................................
4)angle entre deux rotations (ex: 5°)

Prgm
Local xydim,pictmat,xpictmat,ypictmat,screen,p,q,matrot,colget,vectmat,lvectmat,xparit,yparit,@k,@,xo,yo

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

Define colget(@m,@n)=Func
(@m™[@n])™
EndFunc
retourne la colonne @n d'une matrice @m

vertel("d save","screen",0,0,239,127,"/","d clrs","/","d size",pict,"/","e retr","xydim","/","d pict",pict,xcsg,xcsg,1)
sauvegarde de l'écran, calcul des dimensions en pixels de l'image {xpxl,ypxl}, et affichage de l'image aux coordonnées (xcsg,ycsg)

1-(xydim[1]-2*floor(xydim[1]/2))->xparit
1-(xydim[2]-2*floor(xydim[2]/2))->yparit
tests de parité sur les dimensions en x et en y de l'image, résultats (xparit=0(1)si xpxl pair(impair))

xcsg+floor(xydim[1]/2)->xo
ycsg+floor(xydim[2]/2)->yo
(calcul (sûrement discutable ) des coordonnée du centre de rotation)

mat>list((newMat(xydim[2],1)) .^ 0*list>mat(seq(q,q,1,xydim[1])) .- floor((xydim[1]+1)/2))»xpictmat
mat>list((list>mat(seq(p,p,1,xydim[2])))™*((newMat(xydim[1],1))™) .^ 0 .- floor((xydim[2]+1)/2))>ypictmat
création de 2 listes utilisables par vertel ...
Imaginons que l'image ait pour dimensions 3*5 pixels.
On va créer avec
(newMat(xydim[2],1)) .^ 0*list>mat(seq(q,q,1,xydim[1])) .- floor((xydim[1]+1)/2)
(list>mat(seq(p,p,1,xydim[2])))™*((newMat(xydim[1],1))™) .^ 0 .- floor((xydim[2]+1)/2)
deux matrices de coordonnées (la première pour x, l'autre pour y) de chaque pixel de l'image. Ces coordonnées sont relatives au centre de rotation (xo,yo) qui ne subit aucune rotation
pour x:
-1 0 1
-1 0 1
-1 0 1
-1 0 1
-1 0 1

pour y:
-2 -2 -2
-1 -1 -1
0 0 0
1 1 1
2 2 2

ces matrices sont transformées en listes (xpictmat,ypictmat) avec mat>list pour pouvoir utiliser vertel (cf: notice de vertel, parce que la g vraimment la flemme )

vertel("d test",xpictmat .+ xcsg+floor(xydim[1]/2)-xparit,ypictmat .+ ycsg+floor(xydim[2]/2)-yparit,"/","e retr","pictmat")
2*pictmat->pictmat
ici vertel reconstitue l'image affichée au préalable sous forme de liste(encore pour pouvoir utiliser vertel par la suite), mais il faut imaginer une matrice ...
ex: si votre image 3*5 pxl ressemble à ça:

000
000
000
000
000

la matrice (virtuelle) c ça :

202
202
000
202
020

....

et donc la liste pictmat sera celle-ci:

{2,0,2,2,0,2,0,0,0,2,0,2,0,2,0}

augment((list>mat(xpictmat))™,(list>mat(ypictmat))™)->vectmat

ici on transforme les listes xpictmat et ypictmat en une matrice N*2 (vectmat) pour pouvoir (très vite ) multiplier par une matrice de rotation (matrot(@))

0°->@
initialisation de l'angle (enfin ça c'était pas nécessaire de préciser ...)

Lbl t@

Loop
début de la boucle de rotation

If getKey()=264
Goto end

@+d@->@
incrémentation de l'angle ...

exact(round(vectmat*matrot(@),0))->lvectmat
calcul des nouvelles coordonnées stockées de manière à ce que vectmat reste inchangée (cf: problème de divergence évoqué par Euthaniel)
c cette instruction là la plus longue à cause du "round"

mat>list(colget(lvectmat,1)) .+ xo->xpictmat
mat>list(colget(lvectmat,2)) .+ yo->ypictmat
"extration" des liste pour vertel (ça c pas trop long par contre )

vertel("d clrs","/","d pixl",xpictmat,ypictmat,pictmat)
tracé de l'image "rotationnée"
qui comme vous allez le voir ne ressemble à l'originale que pour @= z.Pi/2

EndLoop

Lbl end
vertel("d pict","screen",0,0,1)
restauration de l'écran
EndPrgm

imbibinebe a écrit :
[...]

Apparemment tu ne connais pas vertel et je t'invite donc à l'utiliser (personnellement je ne peux plus m'en passer). J'pense aussi que flib n'est pas à négliger (mais c ptet parce que c la première librairie que j'ai connue ) pour certaine fct° (getline, insertline, komp) qui ne sont pas disponibles dans vertel ...
[...]

Non, je ne connais pas vertel, et ma 92+ non plus ...
Ce n'est pas du TI-Basic, apparemment.
Par contre, je connais flib, et je sais que c'est une bibliothèque Assembleur.

idem :
[...]

ces matrices sont transformées en listes (xpictmat,ypictmat) avec mat>list pour pouvoir utiliser vertel (cf: notice de vertel, parce que la g vraimment la flemme )[/4]
[...]

Il faut donc bien faire une double conversion image<->matrice 2xN, mais c'est vertel qui apparemment réalise ceci.

idem :
[...]

0°->@
initialisation de l'angle (enfin ça c'était pas nécessaire de préciser ...)

[...]

@+d@->@
incrémentation de l'angle ...

exact(round(vectmat*matrot(@),0))->lvectmat
calcul des nouvelles coordonnées stockées de manière à ce que vectmat reste inchangée (cf: problème de divergence évoqué par Euthaniel)
c cette instruction là la plus longue à cause du "round"
[...]

Ce problème d'instruction la plus longue (et de longueur variable, ce qui est la pire) existait aussi dans mon second algorithme.
J'ai résolu ce problème en rendant d@ réél (d'où le point dans 3.°->d@, mais il y a une autre solution ).
Il y a pour ton algorithme deux moyen de palier à ce problème (théoriquement, puisque je n'ai pas la possibilité de le tester à cause de vertel) :
- soit tu impose que d@ soit réel ;
- soit, le plus simple, à l'initialisation de l'angle, tu fais 0.°->@.
Ainsi, au lieu d'être une fraction exacte, @ sera un réel arrondi à 14 chiffres significatifs, ce qui fait que matrot contiendra alors aussi des réels.
Ce n'est pas le round qui est long, mais le calcul avec des matrices contenant des valeurs exactes du type (racine(3)+1)*racine(2)/4 (il s'agit de Cos(15°) ).
Tu verras, je suis sûr que ce minuscule point ajouté à l'instruction d'initialisation de @ suffira à accélérer grandement le traitement.

@++

- soit tu impose que d@ soit réel ; - soit, le plus simple, à l'initialisation de l'angle, tu fais 0.°->@.

j'ai essayé ces deux méthodes mais contrairement au tiens, mon prog est 3 fois plus rapide en utilisant des valeurs exactes pour d@ et @ .....

ptit correctif: pour améliorer l'apparence de l'image, remplacer 2.pictmat->pictmat par pictmat .+ 1->pictmat

Vraiment étonnant, en effet ...
Pourtant, dans mon second algorithme, si tu enlèves le point, le résultat passe de très bon à inacceptable.

En tout cas, j'espère que Thor aura trouvé son bonheur dans ce topic !

@++

Pourtant, dans mon second algorithme, si tu enlèves le point, le résultat passe de très bon à inacceptable.

c bien ce que g remarqué aussi, mais j'pense que la valeur de d@ influe bcp sur la différence de vitesse entre les deux méthodes ...

Au fait, correction: il était 23:43 heure française, donc 00:43 ici en Grèce.

Ethaniel
:

Kevin Kofler :
Euh, je te signale que quand il est 23:43 et qu'on paye 5 EUR par heure (Café Internet), on n'a pas vraiment envie de passer 3 heures à rédiger une explication.

En tout cas, merci d'avoir bien élaboré sur le sujet.

Houlà oui, je comprends parfaitement !
J'ai aussi testé le Cyber-Café (enfin, c'était plutôt un Cyber-McDo ) pendant mes vacances à Chamonix, et 3 Euros la 1/2 heure, ça fait mal !

Toujours rien contre les 9 EUR pour la demi-heure que j'ai payés sur le bateau (en route).
Comme déjà dit, ici, ce sont 5 EUR pour l'heure entière, ça va encore...

Mais comme tu es souvent sur le forum, je n'ai pas imaginé un instant que tu puisses écrire d'un Cyber-Café ... toutes mes condoléances pour ton porte-monnaie qui doit souffrir .

Ce sont mes parents qui payent.

Warning ! Fleming's point overstepped !

Kevin Kofler a écrit :
[...]
Toujours rien contre les 9 EUR pour la demi-heure que j'ai payés sur le bateau (en route). Comme déjà dit, ici, ce sont 5 EUR pour l'heure entière, ça va encore...

Au Cyber-McDo aussi, c'était 5 Euros de l'heure (tarifs dégressifs), mais je n'avais pas besoin d'aller plus sur Internet, donc pas envie de payer 2 Euros pour rien.

idem :
[...]
Ce sont mes parents qui payent.

Raaah le p'tit saligaud !
Profite-en, alors ...

Euthaniel> t'as téléchargé vertel ?

imbibinebe a écrit : Euthaniel> t'as téléchargé vertel ?

Je ne sais pas du tout (enfin presque) ce qu'est vertel, ni où on peut le trouver : je m'intéresse assez peu à l'actualité TI pour ma 92+, je me contente de mon vieil AMS 2.03, de mon vieux DoorsOS II 0.97, et de mon vieux TXTRider v1.B9 (ce n'est pas un B, mais un beta), puisque ça fait un an que je n'y touche presque plus (elle contient encore mes penses-bête de Physique ).

Par contre, mon pseudonyme tient en 8 caractères, et c'est déjà la deuxième fois que tu me fais ce coup là ...

@++

L:-DL dsl j'avauis pas fait gaffe

elle contient encore mes penses-bête de Physique

moi j'les ai mis sur PC, ils prenaient trop de place :P

Je ne sais pas du tout (enfin presque) ce qu'est vertel, ni où on peut le trouver : je m'intéresse assez peu à l'actualité TI

justement tu trouverais ptet assez d'intérêt de t'y remettre avec vertel !
(disponible sur le site de Vertyos: http://perso.wanadoo.fr/variable/)

Ca fait longtemps que je n'ai plus touché au TI-Basic ...
Je me suis maintenant mis à l'Assembleur x86 (depuis 2 ans) et PIC (depuis 6 mois).
Et en tant que fondamentaliste de l'Asm, je n'aime pas, par éthique personnelle, les bibliothèques comme vertel (ne te fâche pas Vertyos , je n'ai rien contre ta lib en particulier, c'est très général).

En passant, je viens de trouver ce post ... ça ne vous rappelle pas quelque chose ?

@++