Discussion :

[AliJava]

Bonjour,

Je souhaite optimiser ma méthode pour la rotation des images voyez vous dans mon code (que je partage avec vous) quelques choses de méchant ?

Merci par avance.

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
18
19
20
21
22
23
24
25
 
	public BufferedImage rotation(BufferedImage bi, int degrees) {
		degrees = degrees % 360;
		if (degrees > 180)
			degrees = 180 - degrees;
		double angle = (degrees * Math.PI) / 180.0f;
		if (angle == 0.0)
			return bi;
		// TODO une vrai rotation pour calculer la taille exacte de l'image
		// après rotation
		int sx = bi.getWidth();
		int sy = bi.getHeight();
		if (degrees == 90 || degrees == -90) {
			sx = bi.getHeight();
			sy = bi.getWidth();
		}
		BufferedImage rot = new BufferedImage(sx, sy, bi.getType());
		AffineTransform at = new AffineTransform();
		at.translate(sx / 2, sy / 2);
		at.rotate(angle);
		at.translate(-bi.getWidth() / 2, -bi.getHeight() / 2);
		AffineTransformOp ato = new AffineTransformOp(at,
				AffineTransformOp.TYPE_NEAREST_NEIGHBOR);
		return ato.filter(bi, rot);
	}

[dinobogan]

Utilise un tableau pour la conversion degré -> radian. Tu pré-calcul un tableau de 360 double.

[AliJava]

Utilise un tableau pour la conversion degré -> radian. Tu pré-calcul un tableau de 360 double.

Merci mais je n'ai pas bien compris.

[tchize_]

Utilise un tableau pour la conversion degré -> radian. Tu pré-calcul un tableau de 360 double.

Excellent, je suis plié pour le reste de la journée (indice quelle est le rapport de temps entre 1 multiplication et sx*sy applications d'un matrice 3x3?)

Sérieusement, faudrais déjà voir ce que Alijava recherhe comme optimisation. Tu compte faire tourner une image en continu et tu veux pouvoir faire X rotations par secondes? Tu compte faire tourner de X degrés 50.000 images d'un coup? Pour voir comment tu peux optimiser, faudrait déjà qu'on aie un shéma type d'utilisation

[dinobogan]

Excellent, je suis plié pour le reste de la journée (indice quelle est le rapport de temps entre 1 multiplication et sx*sy applications d'un matrice 3x3?)

Eh ! T'es un peu gonflé de m'insulter ! Il veut de l'optimisation à tout prix, alors je lui donne le premier truc qui me saute aux yeux pour optimiser
Précalculer, jusqu'à preuve du contraire, permet d'optimiser, même si ce n'est pas grand chose.

[AliJava]

En effet, j'ai oublié de préciser qu'est ce que je veux en faire.
J'ai un répertoire en entrée qui contient n images sauf que ces images ne sont pas droit.
Pour que cela ne se voit pas dans mon projet il faut tout simplement les faire tourner avant de les afficher à l'utilisateur.
C'est un livre, vous avez PAGE 1 / PAGE 2 donc deux panels qui affichent respectivement les images n et n-1 (à l'envers)

Et avec ma méthode le temps de charger le répertoire qui contient les images du livre scanné prend beaucoup de temps avec la rotation (30/20 secondes) de même quand je fais avancer vers les pages (images) suivantes.

voilou

[tchize_]

Alors l'optimisation la plus simple et la plus efficace dans ton cas, tu redresse toutes les pages une fois pour toutes et tu les sauves sur le disque une fois pour toute, comme çà plus de problème. Si ce sont des pages scannées, j'en conclue que t'as un truc du style 2500 pixels x 4500 pixels à tourner via une matrice, donc ton plus gros problème de perfs se situerais à l'application du filtre. Si t'as vraiment besoin de faire çà "au vol", tu peux peut etre regarder à faire de ta "page" une texture openGL et afficher un polygone opengl utilisant la page, polygone tourné de N degrés. Ca nécessite de passer par openGL evidement, mais tu délègue à la carte graphique, et pour ce que je connais des jeux vidéos, la carte graphique sais afficher plein de polygone dans plein d'orientations très vite.

Autre optimisation possible, ajouter un scale à la matrice, l'appliquer sur le Graphics de l'écran, pour ne faire la rotation *que* pour les points visibles à l'écran de l'utilisateur (plus performant, mais moins réactif au niveau de l'interface peut etre)

Vu le nombre de pixels impliqués, les opérations autres que l'application du filtre, dans ton cas, n'ont qu'un cout très limité et à peine perceptible. (pour la taille indiquée, le calcul matriciel devrait impliquer plus ou moins 112 millions d'opérations flottantes (en supposant 10 opérations par application de la matrice d'après la doc de affinetransform...)

Pour dinobogan, je suis désolé, mais non, jusqu'à preuve du contraire, faire une addition d'un index avec vérification de ses limites, puis utiliser cet index pour rappatrier une donnée depuis une autre zone mémoire n'a aucune raison d'etre plus rapide qu'une multiplication au sein des registres de la jvm. De plus, comme tu sais pas sur quelle machine réelle tournera la jvm, tu peux pas en conclure sur les performances des accès mémoire par rapport au calculateur flottant.

[AliJava]

Merci pour ta réponse.

En effet, avec OpenGl on peut optimiser largement les calculs mais ce n'est pas possible dans mon cas ou encore pourquoi ne pas le faire avec le shading pour faire mieux.
OpenGl avec Java .. jamais fait et je ne veux pas m'aventurier la dessus (je pense pas que j'en ai besoin pour ce que j'ai envie de faire c'est une simple image).
Là ce que je cherche est tout simplement une optimisation du temps de rotation sachant que la contrainte de le faire en Java n'est pas négociable.
Donc si c'est possible de me guider par rapport à l'API classique Java 1.5 pour faire mieux ça sera bien aimable. Désolé de ne pas avoir dis cela puisque je pense que j'ai bien éviter le forum Algo.
Ou sinon si quelqu'un à une autre idée pour contourner cela avec seul donnée Java 1.5 et sans biblio externes, je suis preneur.

Un grand merci à tous (et à toutes ?).

aa

[tchize_]

Tu affiche 2 pages à la fois? Si oui, tu peux peut être "précalculer" la page précédente et la page suivante, histoire de gagner en rapidité de l'interface (pas en perfs malheureusement), tu peux aussi faire plutot l'opération dans le paint() plutot que dans un bufferedimage (si l'image est grosse çà va évite de faire une belle occupation mémoire) d'un composant custom. Avantage, tu ne calcule que les pixels visible et pas toute l'images (imaginons un écrant 1024x768, ton calcul est limité à 790.000 pixels (je part toujours d'une image de départ beaucoup plus grande que l'écran)