Discussion :

[mathieumadrid]

Sinon, je voudrais savoir si il est possible d'augmenter ou de diminuer les dimensions d'une image (par exemple, /2, /3, x2, x3...) sans passer par des calculs compliqués. La méthode setRenderingHint, il faut bien l'utiliser avec le Graphics du JPanel ?

[bouye]

Note qu'utiliser une image offscreen n'est parfois pas necessaire pour ameliorer les performances (parfois oui ca l'est). Tu peux gagner en acceleration en creant une image compatible avec ton affichage. Quelque chose dans le genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
GraphicsConfiguration configuration = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
BufferedImage result = configuration.createCompatibleImage(width, height, Transparency.OPAQUE);

Ce n'est pas une mauvaise idee que de chercher a detacher la logique de dessin de tout ce qui est affichage/controle de la souris. Cela peut te permettre de creer des sorties independantes de la surface utilisee (ecran, image memoire, imprimante, image bitmap, image vectorielle, etc...).

La methode drawImage() dispose de variantes qui prennent des parametres de tailles qui permettent d'afficher une image a une autre taille dans un Graphics (essaie de te mettre dans la tete qu'un Graphics est un "contexte graphique" : ce n'est pas forcement l'ecran ; ca peut etre une autre image, l'imprimante, voir meme un flux de sortie vers un fichier d'image vectoriel par exemple dans certaines API). On peut utiliser egalement des AffineTransform ou la methode scale() de la classe Graphics pour atteindre le meme resultat (!!!!! il faut penser a utiliser la transformation ou le scale() inverse apres coup). Tu peux donc rajouter des fonctionalites de zoom dans ton application en jouant avec l'une de ces trois solutions.

La qualite du redimensionnement d'une image peut se controller avec les indices de rendu, nottament RenderingHints.KEY_INTERPOLATION et RenderingHints.KEY_ALPHA_INTERPOLATION. Ces indices doivent etre mis sur le Graphics destination, celui qui recevra l'image. Concernant le premier (dont les effets sont immediatement visibles) :
- RenderingHints.VALUE_INTERPOLATION_NEAREST_NEIGHBOR : l'image redimensionnee est pixelisee. Dans un logiciel de dessin bitmap c'est probablement celui a utiliser quand on zoome sur une portion de l'image pour l'editer.
- RenderingHints.VALUE_INTERPOLATION_BILINEAR : offre un bon rapport vitesse/qualite. L'image est adoucie pour eviter de voir les effets de crenelage des pixels.
- RenderingHints.VALUE_INTERPOLATION_BICUBIC : est sense offrir la meilleur qualite en detriment de la perfomance. Mais bon parfois le resultat n'est pas si bon que ca. Bref, pas vraiment necessaire dans la plupart des cas.
- ces derniers temps, les gens penchent vers une solution mixte qui est une sucession de divisions de la taille de l'image par deux avec un indice mis a RenderingHints.VALUE_INTERPOLATION_BILINEAR. C'est plus rapide que le RenderingHints.VALUE_INTERPOLATION_BICUBIC et les resultats sont tres bons voir meilleurs. Tu trouveras des exemples postes par Gfx sur le forum (et son blog aussi probablement).

Une derniere note : en general, il n'est pas necessaire de passer this en parametre de drawImage(), en fait ca a meme tendance a ralentir les chose. Tu peux passer null a la place.

[mathieumadrid]

Voici ma dernière question !
C'est bien sur le Graphics du JPanel que l'on applique ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
g2d.setRenderingHint(RenderingHints.KEY_RENDERING,RenderingHints.VALUE_RENDER_SPEED);
g2d.setRenderingHint(RenderingHints.KEY_COLOR_RENDERING,RenderingHints.VALUE_COLOR_RENDER_SPEED);
g2d.setRenderingHint(RenderingHints.KEY_FRACTIONALMETRICS,RenderingHints.VALUE_FRACTIONALMETRICS_OFF);
g2d.setRenderingHint(RenderingHints.KEY_DITHERING,RenderingHints.VALUE_DITHER_DISABLE);
g2d.setRenderingHint(RenderingHints.KEY_ANTIALIASING,RenderingHints.VALUE_ANTIALIAS_ON);

Pareil pour la qualité de redimensionnement d'après votre dernière réponse. En fait, on ne travaille sur le Graphics de l'image que pour dessiner (drawLine etc...) ?
Je remercie tous ceux qui m'ont aidé (en particulier : Sanguko et bouye).

[bouye]

Alors :
- RenderingHints.KEY_QUALITY et RenderingHints.KEY_COLOR_RENDERING : concernent la qualite generale, cela s'applique a n'importe quel Graphics que tu manipules.
- RenderingHints.KEY_ANTIALIASING, RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.KEY_FRACTIONNALMETRICS , RenderingHints.KEY_STROKE_CONTROL* ainsi que le tout nouveau RenderingHints.KEY_TEXT_LCD_CONTRAST** : concernent l'anticrenelage des formes et des polices et la precision des calculs (des polices) et de l'affichage des traits, cela s'applique donc dans le Graphics dans lequel tu dessines des formes (soit via Shape soit via les primitives) ou du texte.
-RenderingHints.KEY_INTERPOLATION et RenderingHints.KEY_ALPHA_INTERPOLATION : concernent l'interpolation des couleurs principalement lors des operations de redimensionnement (scale(), drawImage(), etc...). Il y a donc des chances que dans ton cas ca soit plus utile sur le Graphics associe a l'ecran.
-RenderingHints.KEY_DITHERING : toujours pas vu d'effet flagrants donc malgres des annees de doc et de pratique je ne sais pas trop a quoi il sert. Normalemet "to dither" c'est "tergiverser" ; d'apres la description de la javadoc j'imagine donc que c'est en rapport avec l'adaptation d'un espace de couleur vers un autre (nottament quand on utilise des ecrans supportant un moins grand nombre de couleurs ou quand on imprime). Probablement a utiliser sur le Graphics de l'ecran donc.

*Uniquement Java 1.3+
**Uniquement Java 1.6+

[Sanguko]

-RenderingHints.KEY_DITHERING : toujours pas vu d'effet flagrants donc malgres des annees de doc et de pratique je ne sais pas trop a quoi il sert. Normalemet "to dither" c'est "tergiverser" ; d'apres la description de la javadoc j'imagine donc que c'est en rapport avec l'adaptation d'un espace de couleur vers un autre (nottament quand on utilises des ecrans supportant un moins grand nombre de couleurs ou quand on imprime). Probablement a utiliser sur le Graphics de l'ecran donc.

*Uniquement Java 1.3+
**Uniquement Java 1.6+

Le dithering est une technique qui sert a faire croire qu'on utilise plus de couleurs que ce dont dispose reellement.
Typiquement, on en a besoin si on essaie d'afficher une image (une photo) qui contient plusieurs millions dans un écran qui ne dispose que de 256 couleurs.
Le principe repose sur le fait que la juxtaposition de pixels de couleurs differents donne l'impression d'avoir la couleur intermediare.
Par exemple, imaginons que l'on ait que du noir et du blanc, on peut donner l'impression d'avoir du gris en dessin un pixel blanc, puis le suivant noir, plus blanc, etc ...
Les PCs sont en ARGB32, on a pas vraiment besoin de dithering.
Et c'est vrai que de toute facon, je n'ai jamais reussi à la desactiver.

[mathieumadrid]

J'ai une correction à faire par rapport à la convertion d'une couleur RGB en entier. Voici la méthode qui est l'inverse de celle qui se trouve à la page 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public static int colorToInt(Color c)
{
	return (c.getRed() << 16) | (c.getGreen() << 8) | c.getBlue();
}

Je mets ce code car j'avais eu du mal à comprendre la méthode getRGB de BufferedImage. En fait, pour récupérer la couleur d'un pixel d'une BufferedImage, on fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int couleur = image.getRGB(x,y) & 0xFFFFFF;

Et pour changer la couleur d'un pixel en blanc par exemple, on fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

image.setRGB(x,y,colorToInt(Color.WHITE));

Avec l'ancienne méthode, j'obtenais des trucs très louches.

[bouye]

Ta premiere methode etait globalement inutile car la classe Color dispose de la methode getRGB() qui retourne une couleur codee en ARGB/sRGB.

Pour avoir une couleur solide, encodee comme tu le veux, il te suffisait donc de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public static int colorToInt(Color c) {
   return c.getRGB() & 0xFFFFFF;
}

Pourquoi faut-il masquer pour obtenir une couleur sur 24-bits ? Tout simplement car une couleur opaque en ARGB donne un alpha = 255. Donc tu aurai des couleurs toujours sous la forme :

0xFF RR GG BB or apparement tu les veux sous la forme 00 RR GG BB. Si ton programme ne sait manipuler que tu 24-bits effectivement cela peut te causer des problemes. D'ou, peut-etre, tes resultats bizarres.

[mathieumadrid]

Voilà, j'ai fini les modifications de mon Paint ! Je laisse mes deux *.jar (v1.0.0 et v2.0.0) pour rigoler un peu car la première version n'était vraiment pas optimum . J'aimerais encore améliorer ce programme en ajoutant ces améliorations :
- Aperçu (exemple, un trait provisoire s'affiche lorsque l'on veut tracer une doite)
- Edition > Annuler (Ctrl Z : Revenir en arrière)
- Edition > Rétablir (Ctrl Y : Refaire l'image)
- Ancrage des JDialog ou pas
- Impression
- Sauvegarde dans un fichier JPG (via write de ImageIO)
- Nouvelles possibilités : Plus de polices, plus de configurations en générale...
- Divers outils de traitement de l'image...
Je sais déjà comment programmer ces nouveautés à part l'aperçu et l'impression. Si vous voyez encore des choses à améliorer, signalez-le moi.
Voici une archives (avec les 2 *.jar et les sources) :
http://www.cartesmagic.net/java/