Discussion :

[Jack Sparrow]

Bonjour,

Comme il est possible d'avoir une preview (image de petit format) dans le GenericPluginFilter.

Ce serait quand même plus pratique de savoir si on est en preview pendant un calcul.
En effet, le preview peut complètement rater pour des filtres locaux. (typiquement un flou Gaussien de rayon 100 sur une image de taille 5000 va être carrément différent sur l'image réduite de taille 500).

De plus, cela permettrait de mettre en place des systèmes de cache.

[pseudocode]

Il y a quelque chose de spécial a faire pour la preview dans un GenericPluginFilter ?

J'ai juste ajouté "setWithPreview(true)" dans le constructeur et j'ai un problème. J'ai bien la preview qui s'affiche (très grande d'ailleurs), et qui se met a jour en fonction des params du filtre. Mais quand je fais "OK", l'image originale est remplacée par une surimposition de plusieurs images.

EDIT: Ah ! j'ai compris. Tu utilises la même instance du filtre pour la preview et pour le calcul final. Donc l'image passée en paramètre de "filter()" n'est pas la meme (en particulier la taille). Il faut donc faire attention si on fait des précalculs sur l'image.

[millie]

EDIT: Ah ! j'ai compris. Tu utilises la même instance du filtre pour la preview et pour le calcul final. Donc l'image passée en paramètre de "filter()" n'est pas la meme (en particulier la taille). Il faut donc faire attention si on fait des précalculs sur l'image.

Oui, il faut faire attention avec ça. J'ai voulu mettre la possibilité de savoir si on est dans une preview ou non, mais j'ai complètement oublié.

Il faudrait également connaître le "scale factor" avec l'image d'origine, car sinon, on est incapable d'évaluer par exemple le rayon pour un flou.

Il faudrait également ajouter la possibilité au filtre de donner la taille maximal de la longueur ou la largeur pour la preview (notamment si la personne qui fait le filtre pense que 700 est trop gros pour une preview).

Pour l'instant les tailles sont définis dans le fichier de config MillieGUI.properties :
gui.genericpluginwindowStartXWithPreview= 100
gui.genericpluginwindowStartYWithPreview= 100
gui.genericpluginwindowPreviewImageSize= 700


Pour résumer :

• Savoir si on est en mode preview
• Connaître le scale factor entre la preview et l'image originale
• Pouvoir configurer la taille de la preview

[pseudocode]

On peut aussi inverser le contrôle : avoir une méthode "BufferedImage previewFilter()" dans le plugin. Ca implique juste de créer une interface "Previewable" (et éventuellement de fournir deux classes : GenericPluginFilter et GenericPluginFilterWithPreview)

Code java :

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

1
2
3
public interface Previewable {
	BufferedImage previewFilter() throws Exception;
}

Code java :

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

1
2
public abstract class GenericPluginFilterWithPreview extends GenericPluginFilter implements Previewable {
}

Charge au développeur de renvoyer une image de preview.

Code java :

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
@PluginInfo(name="TestPlugin", category="test")
public class TestPlugin extends GenericPluginFilterWithPreview { 
 
	public TestPlugin() { }
 
	@Override
	public BufferedImage filter() throws Exception {
		// ...
		return output;
	}
 
	@Override
	public BufferedImage previewFilter() throws Exception {
		// ...
		return preview;
	}
 
}

[millie]

Il faut juste que je vois comment gérer correctement la taille de la boite de dialogue (car difficile de donner une taille fixe si je connais pas la taille de la preview au début )

[pseudocode]

Il faut juste que je vois comment gérer correctement la taille de la boite de dialogue (car difficile de donner une taille fixe si je connais pas la taille de la preview au début )

Tu peux toujours "forcer" la taille de l'image de preview, en allouant le bufferimage avant d'appeler la méthode preview. Charge au developpeur de remplir correctement le bufferimage passé en paramètre.

Code java :

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

1
2
3
public interface Previewable {
	void previewFilter(BufferedImage preview) throws Exception;
}

[Jack Sparrow]

Ouais mais dans ce cas, le développeur ne peut plus vraiment choisir une taille maximal.

Code java :

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

1
2
3
4
5
6
7
8
 
public interface Previewable {
             //si <=0, une valeur sera fixée (ex : 700)
             int getMaxPreviewSize();
 
             //scale factor avec getMaxPreviewSize()/max(w,h)
	void previewFilter(BufferedImage output) throws Exception;
}

Ou (mais on revient un peu au premier cas sans IOC) :

Code java :

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

1
2
3
4
5
6
7
8
9
10
 
public interface Previewable {
             //si <=0, une valeur sera fixée (ex : 700)
             int getMaxPreviewSize();
 
             //scale factor avec getMaxPreviewSize()/max(w,h)
             void previewFilter(BufferedImage output) throws Exception; 
 
             BufferedImage getPreviewImage() throws Exception;
}

[pseudocode]

Ouais mais dans ce cas, le développeur ne peut plus vraiment choisir une taille maximal.

Bof. C'est pas bien grave. Ca me parrait logique que toutes les preview aient la meme taille, et donc qu'elle soit choisie par l'utilisateur (bouton +/-) et pas par le développeur du filtre.

Par contre, j'ai oublié dans la signature de passer le 'facteur de zoom' afin de modifier les params du filtres, si necessaire.

Code java :

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

1
2
3
public interface Previewable {
	void previewFilter(BufferedImage preview, float zoomfactor) throws Exception;
}

[Jack Sparrow]

Si on part sur qqch de complet, il faudrait que j'aille jeter un oeil aux systèmes de preview qui existe.


- En général, on peut rezoomer et se déplacer dessus (lors du déplacement, c'est l'image d'origine qui est montrée).
- Avoir plusieurs système de preview (tout en preview, la partie gauche normale, la partie droite en preview, le contraire, etc.)

Ceci implique que l'image de destination a la même taille que l'image d'origine.

[millie]

Je pensais à un truc comme ça du coup (c'est une maquette) :

[pseudocode]

Si tu peux apporter toutes ces fonctionnalités avec seulement une interface comme celle du post #8, alors c'est cool.

Il ne faudrait pas complexifier plus le boulot du développeur du filtre avec une fonction Preview qui doit gérer tous les cas . C'est va déjà être galère de recalculer certains paramètres du filtre en fonction du zoom

[millie]

Il ne faudrait pas complexifier plus le boulot du développeur du filtre avec une fonction Preview qui doit gérer tous les cas . C'est va déjà être galère de recalculer certains paramètres du filtre en fonction du zoom

Il y a 2 premiers cas que l'on peut redécouper en plusieurs cas :
- l'image de destination est de même taille
- l'image de destination est de taille différente (faut voir si je prévois qqch pour ça)

Dans le cas où l'image de destination est toujours de même taille que l'image d'origine, il doit y avoir 2 cas :

- on limite à une preview complète car on a besoin de toute l'image pour calculer la preview
- on peut zoomer sur une preview car le filtre ne dépend pas d'une grande partie de l'image (après, une preview reste une preview)

Même si c'était pas ce qui était prévu au début, je préférerai laisser le boulot au dessus à faire le scale, le zoom, le positionnement etc. pour que le développeur du filtre n'ait pas à le faire

Code :

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

1
2
3
4
5
public Previewable {
   public void previewFilter(BufferedImage output, float scaleFactor);
   public boolean isZoomable();
}

Dans le cas d'un "zommable", on lui fournit directement l'image déjà zoomé, réduite et découpé (via getInput)
Dans le cas d'un non "zoomable", on fournit juste l'image réduite

Il y a dans le GenericFilterPlugin une méthode "setup" qui pourrait dégager pour être remplacé par un système de notification de changement d'input sur les preview et les input classiques (soit via une annotation comme dans les EJB3, soit via un héritage d'interface de type Listener).

Code java :

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
 
//annotation ou interface
public MonPlugin ... {
 
   @ImageChange
    public void refreshCache() {
      BufferedImage input = get...
    }  
 
 
   public BufferedImage filter() {
     BufferedImage output etc.
     filter(output);
     return output;
   }
   private void filter(BufferedImage output) {
      //filtre
   }
   public void previewFilter(BufferedImage output, float scaleFactor) {
     filter(output); //si on se moque du scale
   }
}

Mais on perd la possibilité de gérer des filtres qui donnent des images de destination de taille différent.

[pseudocode]

Il y a 2 premiers cas que l'on peut redécouper en plusieurs cas :
- l'image de destination est de même taille
- l'image de destination est de taille différente (faut voir si je prévois qqch pour ça)

Dans le cas où l'image de destination est toujours de même taille que l'image d'origine, il doit y avoir 2 cas :

- on limite à une preview complète car on a besoin de toute l'image pour calculer la preview
- on peut zoomer sur une preview car le filtre ne dépend pas d'une grande partie de l'image (après, une preview reste une preview)

Même si c'était pas ce qui était prévu au début, je préférerai laisser le boulot au dessus à faire le scale, le zoom, le positionnement etc. pour que le développeur du filtre n'ait pas à le faire

Ca fait beaucoup de truc à gérer. A ce moment là, autant laisser au développeur le soin de s'occuper de tout cela (en lui passant toutes infos) et lui fournir des méthodes pour retailler, découper l'image d'entrée.

Code java :

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

1
2
3
4
5
6
7
8
9
10
 
public interface Previewable {
   public void previewFilter(BufferedImage output, Crop info);
}
 
public class Crop {
   int x,y,w,h;
   float wfactor, hfactor;
   ....
}

Il y a dans le GenericFilterPlugin une méthode "setup" qui pourrait dégager pour être remplacé par un système de notification de changement d'input sur les preview et les input classiques (soit via une annotation comme dans les EJB3, soit via un héritage d'interface de type Listener).

Normalement, l'image d'entrée de "filter()" ne devrait pas changer, puisqu'on à la methode "previewFilter()" pour les preview. non ?

[millie]

J'avais commencé à implémenter la chose. Mais le code est devenu tellement pourri que je suis revenu en arrière le temps que je trouve une bonne idée pour simplifier un peu tout ça

Et de manière général, le code de la partie GUI est assez bordélique, mais les IHM "standard", c'est pas trop mon truc niveau conception

[millie]

Je suis en train de refactorer la partie GUI, donc cette nouveauté n'arrivera pas tout de suite

Mais il devrait y avoir la possibilité de faire des plugins plus générique qui sortent du système actuel (mais évidemment, ceux qui sont intéressé par ça devront probablement se farcir du swing).