Discussion :

[Traroth2]

Bonjour,

Pour améliorer les performances d'une application qui fait du resize et de l'encodage d'image en JPEG (on balance une image GIF, PNG ou JPEG d'un coté, ça crache une image resizée en JPEG de l'autre), j'envisage d'utiliser JOGL, ce qui permettrait de faire faire le travail au GPU. Malheureusement, j'ai l'impression que l'utilisation de cette API nécessite une bonne connaissance d'OpenGL, ce qui n'est pas mon cas. Est-ce que quelqu'un pourrait m'indiquer les classes et méthodes à utiliser, ou au moins où trouver une doc valable (la doc sur https://jogl.dev.java.net/ est plutôt primaire, la javadoc en particulier se contente d'indiquer quelle appel OpenGL est wrappé par chaque méthode, ce qui ne m'aide pas beaucoup).

Merci d'avance pour toute aide.

[Traroth2]

A moins que quelqu'un connaisse un autre moyen d'utiliser l'accélération des GPU pour ces opérations, en Java (ou exploitable en Java, par JNI ou autre) ?

[eclesia]

Je pense que tu fais fausse route.

JOGL est une api de rendue 3D, et c'est pour ca que la carte graphique est faite.
Et non tu ne trouvera rien dans JOGL pour faire du traitement d'image.

Pour faire du traitement d'image utilise JAI et ImageIO/.

[sinok]

Euh plus ou moins, on eut faire pas mal de travail 2D avec OpenGL (penser par exemple compositing sous linux, KWin4, Compiz &cie).

Ensuite dans le cas présent, la JVM a déjà certains accès à la CG pour les manipulations d'images de par son pipeline (OpenGL ou DirectX dans les dernières versions de java), le redimensionnement est réalisé en hardware si l'on s'y prend bien (lire ne pas utiliser Image.getScaledInstance).

Pour tout ce qui concerne le redimensionnement d'images en java, il est plus que préférable de lire attentivement le lien suivant: http://today.java.net/pub/a/today/20...dinstance.html

Bref dans ton cas, pas besoin d'OpenGL.

[Traroth2]

Intéressant. Tu aurais plus d'infos concernant l'accélération hardware des opérations graphiques en Java (surtout 2D) ?
J'ai lu récemment qu'ajouter ce type d'accélération serait justement une des modifs majeures de Java 6 update 10...

Pour ma part, j'utilise un algo de bilinear filtering codé maison pour resizer, afin d'avoir un meilleur rendu. C'est un peu ce qui est problématique :
-Lire le fichier avec ImageIO et instancier un BufferedImage (ce qui permet de lire une vaste variété de formats d'images)
-extraire les pixels sous forme de tableau avec BufferedImage.getRGB()
-appliquer l'algo de resize au tableau
-sauvegarder

Le problème, c'est que cette méthode ne permet pas l'accélération matérielle, en l'état.

Bon, je vais lire l'article que tu m'as indiqué en détail, déjà, et je verrais après. Si quelqu'un a plus d'infos, je suis toujours preneur !

[natha]

J'ai lu récemment qu'ajouter ce type d'accélération serait justement une des modifs majeures de Java 6 update 10...

Si t'as une source de cette info, ça m'intéresse !

[Traroth2]

Si t'as une source de cette info, ça m'intéresse !

Bien volontiers : sur le site java.sun.com

Cela dit, ça concerne Windows uniquement. Le nouvel update contient un tout nouveau pipeline Direct3D.

[sinok]

En fait il existe depuis java 5 un pipeline OpenGL, c'est le pipeline direct3D qui est une nouveauté. Et si la CG le supportait sous Windows, tu pouvais déjà l'utiliser.

Sinon pour le resize tu pourrais voir du coté du mip mapping, cf ce post de Romain Guy.

Cette méthode a d'ailleurd été introduite dans la classe GraphicUtilities de SwingX

[Traroth2]

Merci, avec ça, je dois déjà pouvoir avancer.

Encore une question (les GPU ne sont pas ma spécialité ) : Cette solution permet d'augmenter la vitesse du resize, mais est-ce que ça permet d'accélerer l'encodage ? En principe, l'encodage d'une JPEG, c'est une opération qui convient particulièrement bien à un processeur vectoriel comme un GPU : refaire X fois la même opération sur des données différentes. Existe-il un moyen d'utiliser le GPU pour ça ?

Le resize, ça consomme déjà des ressources, mais l'encodage, c'est vraiment problématique, dans un contexte web : chaque image doit être décompressée, donc la consommation mémoire est considérable, et avec X traitements concurrents, ça fait littéralement exploser la consommation mémoire.

[Traroth2]

Effectivement, j'ai peur que ça soit effectivement le resize la partie vraiment critique de l'algorithme : j'ai comparé les temps d'exécution de 100 cycles lecture-resize-écriture, et le resize prend tellement peu de temps dans ce cycle qu'on ne voit pas de différence de durée d'exécution entre mon algorithme actuel ou en utilisant la méthode GraphicsUtilities.createThumbnail() de SwingX (projet très sympa par ailleurs, je retiens ). Donc, ma question tient toujours : y a-t-il un moyen de faire faire l'encodage par le GPU ? Merci pour toute réponse...

[Traroth2]

Bon, en fait, c'était ma mesure de performance qui était mauvaise. La méthode avec SwingX va 2 fois plus vite, grosso-modo, que mon algo actuel. C'est déjà un progrès. Pour l'instant, je fais ça :

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
 
imageSource = ImageIO.read(new File(path));
imageDest = GraphicsUtilities.createThumbnail(imageSource,800,600);
ImageWriter writer = null;
Iterator iter = ImageIO.getImageWritersByFormatName("jpg");
if (iter.hasNext()) {
    writer = (ImageWriter)iter.next();
}
ImageOutputStream ios = ImageIO.createImageOutputStream(new File("c:\\tmp\\titi\\renardSX.jpg"));
writer.setOutput(ios);
 
ImageWriteParam iwparam = new JPEGImageWriteParam(null);
iwparam.setCompressionMode(ImageWriteParam.MODE_EXPLICIT) ;
iwparam.setCompressionQuality(0.8f);
writer.write(null, new IIOImage(imageDest, null, null), iwparam);
 
ios.flush();
writer.dispose();
ios.close();

Si quelqu'un voit encore un moyen d'améliorer la performance de ce code...