Discussion :

[millie]

Bonjour,

Juste pour avoir quelques retours d'avis des gens qui ont osé utilisé mon GUI.

Est-ce que vous pensez que ce serait intéressant d'ajouter une possibilité d'effectuer du traitement en masse (notamment sur les filtres classiques) : soit sur l'ensemble des images ouvertes, soit sur un dossier complet.

Sachant que les spécifications de plugins ne doivent pas changer.


A priori, ce serait sur les plugins du type GenericPluginFilter (donc tous les trucs normaux) qui auront un bouton en plus du type : "Traiter tout" (avec possibilités de désactiver la fonctionnalité). (donc il faudra déjà ouvrir une image, ouvrir une popup de filtre, mettre les paramètres puis cliquer sur : Traiter tout). Le bouton "Traiter tout" pourrait éventuellement se trouver dans le menu et non sur la popup du filtre (c'est un peu bizarre, mais ça allégerait)

[pseudocode]

Perso, je suis plutôt adepte de la ligne de commande quand il s'agit du traitement en batch. Je préfère gérer moi même la liste des fichiers via un script shell:

Code :

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

1
2
3
4
5
6
7
8
9
FOR %f in (*.jpg) DO (

  set input = %f
  set ouput = %~nf-modified.jpg

  java -jar millie.jar -load %input% -filter gauss 2 1.5 -filter resize 0.75 -save %output%

)

[millie]

En fait, comme le système de plugin est indépendant du GUI (le projet MilliePlugins dépend pas du tout de swing), rien ne m'empêcherait d'ajouter un jar (style MillieCmd) qui permettrait d'invoquer des plugins à la main.

J'avais déjà fait un test pour invoquer des plugins via des webservices, et ça marchait pas trop mal (donc indépendamment de MillieGUI)

Dans tous les cas, il y a des parties communes entre ces services/gui/application et il faudrait que je sortes quelque part des classes de MillieGUI (style ceux qui sont chargés de charger les plugins via les jar) (donc surement un nouveau projet encore )

Dans le cas des lignes de commande, ça ressemblerait a priori plutôt à :
-filter GaussianBlurPlugin rayon=2 sigma=0.5
Sachant que si 2 plugins ont le même nom, il faudra plutôt utiliser le chemin complet : -filter millie.plugins.core.blur.GaussianBlurPlugin


Après, il est même possible de créer des plugins qui appellent des plugins sur des machines distantes via ce type de commande... Mais je sais pas si ça servira beaucoup.

[pseudocode]

Après, il est même possible de créer des plugins qui appellent des plugins sur des machines distantes via ce type de commande... Mais je sais pas si ça servira beaucoup.

C'est peut-être pas utile d'aller jusqu'à ce niveau.

Juste pouvoir utiliser la ligne de commande serait suffisant pour moi. Ça me permettrait de porter/utiliser quelques uns de mes filtres usuels (seuillage, resampling, ...)

[millie]

Juste pour dire que j'ai cassé le MillieGUI en 2 projets et commencé un projet MillieCommand. En une ligne, on peut récupérer tous les plugins, donc normalement, il ne suffit plus que de faire du parsing et d'appliquer le filtre ou la série de filtre.

[millie]

J'ai fait une release avec un MillieCommand (v 1.1.3)

Ca gère les GenericPluginFilter et les NoParameterPluginFilter, ça gère tous les types de paramètres sauf Image (normalement, ça n'a pas de sens en mode console) (donc pas les AreaPluginFilter, mais c'est une évolution possible)

Exemple d'utilisation :

Code :

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

1
2
java -jar MillieCommand-1.0.0.jar -input fichier.jpg -output fichiersortie.jpg 
  -filter InvertFilter

Possibilités d'enchainer les filtres et de mettre les paramètres :

Code :

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

1
2
3
-filter MaxPlugin rayon=2 
   -filter MinPlugin rayon=3 
   -filter ScaleFilter type=bilinear h=50 v=50

Les paramètres de type Color s'écrivent sous la forme color=r,g,b, par contre, j'ai un peu oublié de testé, mais j'ai tellement confiance en mon code ^^

Je me tatais à utiliser des Annotations pour les plugins... Mais j'ai pas encore décidé (et il faut aussi prévoir l'internationalisation)

Bon test

[pseudocode]

Whoua... Ça marche au poil. Je vais pouvoir porter les 2 ou 3 filtres que j'utilise couramment, ça m'évitera de lancer eclipse juste pour retailler des images.

Petite suggestion: l'ajout de la commande help (parce que sinon faut aller à la pêche aux sources)

Code :

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

MillieCommand-1.0.0.jar -help

qui affiche la liste des options et la liste des filtres

Code :

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

MillieCommand-1.0.0.jar -help nomdufiltre

qui affiche la liste des parametres attendus par le filtre



Excellente release.

[millie]

Dans la version en cours, j'ai rajouté les commandes : -help et -help nomplugins.

[pseudocode]

Bon, je vais abuser mais si on pouvait ne PAS avoir les infos de debug en "mode commande", ca serait sympa.

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
>java -jar MillieCommand-1.0.1.jar -help

25 janv. 2009 19:14:21 millie.commons.plugins.PluginManager loadPlugins
INFO: Load Plugins From File : Z:\MillieApplication-1.1.4\plugins\MillieCoreFilter-1.1.4.jar
25 janv. 2009 19:14:21 millie.commons.plugins.PluginManager loadPlugins
INFO: Pas de fichier de filtre trouvÚ en local
Aide
Plugins disponibles
Plugin : millie.plugins.core.transform.LanczosResamplePlugin
Plugin : millie.plugins.core.transform.TextResamplePlugin
Plugin : millie.plugins.core.convolve.ConvolvePlugin
Plugin : millie.plugins.core.blur.SimpleBlurPlugin
Plugin : millie.plugins.core.blur.GaussianBlurPlugin
(...)

Et puis une version plus compacte de la liste des filtres aussi. Je verrai plus un truc du genre:

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
>java -jar MillieCommand-1.0.1.jar -help

Syntaxe:  
MillieCommand.jar -input <inputfile> -output <outputfile> [-filter <filtre> [param=value ...] ]
MillieCommand.jar -help <nom du filtre>

-input <inputfile> : nom du fichier d'entrée à lire
-output <outputfile> : nom du fichier de sortie à créer
-filter <filtre> : nom du filtre à appliquer.
param=value : nom d'un paramètre du filtre et sa valeur associée

Exemple:
MillieCommand.jar  -input photo.jpg  -output thumb.png  -filter LanczosResamplePlugin scalex=25 scaley=25 support=5

Filtres possibles:
LanczosResamplePlugin, TextResamplePlugin, ConvolvePlugin, SimpleBlurPlugin, GaussianBlurPlugin, (...)

Et, au point ou j'en suis de me faire détester, est-ce qu'on peut utiliser les filtres sans mettre tous les parametres (en utilisant les valeurs par défaut) ?

[millie]

Salut,

Ouais, je sais que mon loggin est tout pourri... J'utilise le java.util.Logger qui a un bug (et que Sun appelle une feature) qui fait qu'il faut faire un réglage super spécial pour autoriser le mode debug (qui s'appelle FINEST/FINE/FINER).
Donc soit j'utilise un autre Logger comme log4j ou je refais un petit logger correct paramétré au dessus du java.util.Logger qui sera integré à MillieCommons.

Donc voilà le dilemme

[pseudocode]

Donc voilà le dilemme

Je refais presque toujours un Logger perso au dessus des Logger existant. C'est plus souple pour gérer des signatures du genre:

void Log.warn(Throwable e);
void Log.warn(String printformat, Object... objects);
...

[millie]

Pour le java.util.Logger, j'étais obligé de faire ça pour avoir un comportement correct :

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
lass CustomFormatter extends Formatter {
 
	private DateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd hh:MM:ss");
	public String format(LogRecord record) {
 
		//contiendra ce qui sera logué
		StringBuffer sb = new StringBuffer();
 
		//récuperation de la date
		Date date = new Date(record.getMillis());
 
		sb.append(dateFormat.format(date));
		sb.append(" ");
 
		//affichage du niveau de LOG
		String level =record.getLevel().getName(); 
		sb.append(level);
		for(int i = 0; i<8-level.length();i++) { //ajout d'espace pour aligner le LOG
			sb.append(" ");
		}
 
		//affichage du message de log
		sb.append(formatMessage(record));
		sb.append("\n");
 
		return sb.toString();
	}
}
 
/**
 * Pour partager un logger
 * 
 * @author humbertf
 *
 */
public class LoggerManager {
	static private Logger getNewLogger() {
		CustomFormatter formater = new CustomFormatter();
 
		Logger l = Logger.getAnonymousLogger();
 
		//utilisation d'un handler spécifique sinon celui par défaut ne veut pas changer de Level...
		Handler h = new ConsoleHandler();
		h.setFormatter(formater);
		h.setLevel(Level.ALL);
		l.setUseParentHandlers(false);
		l.addHandler(h);
		return l;
	}
	static private Logger logger = getNewLogger();
 
	static public Logger getLogger() {
		return logger;
	}
}

Le Handler par défaut ne veut pas changer de Level et j'ai jamais compris pourquoi.

Je ferais peut être effectivement un Logger par dessus.

Je n'aime pas trop log4j, car il y a parfois des conflits lorsque plusieurs bibliothèques l'utilisent...

[millie]

Normalement, j'ai tout fait.

J'ai repompé sauvagement ton menu d'aide, faudra pas le dire ^^

[pseudocode]

J'ai repompé sauvagement ton menu d'aide, faudra pas le dire ^^

Fait gaffe, j'avais mis la liste des filtres dispo en dur.