G'MIC est un interpréteur de macros de traitements d'images : il permet de charger, convertir, visualiser, traiter des données images 2D, 3D et multi-spectrales. Un de ses principaux attraits est sa grande flexibilité dans l'enchaînement de commandes, permettant d'élaborer des pipelines de traitements divers et complexes sur des données images génériques. G'MIC est développé dans l'équipe IMAGE du laboratoire GREYC (CNRS UMR 6072) de Caen en France.
La grande nouveauté de cette version 1.3.0 est l'intégration de G'MIC dans un greffon pour le logiciel de retouche d'images GIMP. Les fonctionnalités de G'MIC s'ouvrent donc à un public plus large, pas forcément adepte de la ligne de commande.
Ce greffon permet non seulement d'appliquer divers effets et filtres sur des images, mais il est surtout extensible : chacun peut très facilement créer ses propres filtres comme des enchaînements de macros G'MIC, et les ajouter à la liste des filtres disponibles. L'écriture de tels filtres G'MIC se réalise en général en quelques lignes seulement.
G'MIC est multi plate-forme, et distribué sous licence libre CeCILL.
- Extensibilité : comment ça marche ?
G'MIC définit un ensemble de commandes de bases pouvant s'enchaîner, éventuellement avec des contrôles simples (boucles, tests). Ces commandes regroupent la plupart des actions classiques en traitement d'images (filtrage, déformations géométriques, etc.). Un enchaînement de commandes s'écrit dans un fichier de macros G'MIC, qui définit ainsi de nouvelles commandes utilisables par la suite.
À chaque lancement du greffon, le fichier de macros $HOME/.gmic4gimp va être lu (s'il existe), et les nouveaux filtres définis dans ce fichier vont être alors ajoutés dans la liste des filtres disponibles. Par exemple, on peut créer le fichier texte .gmic4gimp suivant :
#@gimp Ma Television : ma_tele, ma_tele, Vertical step = int(2,1,10), Brightness = float(0.5,0,2)
ma_tele : -s y -*[0--1:$1] $2 -a y -cut 0,255
Un nouveau filtre Ma television apparaît alors dans la liste des filtres disponibles, simulant un effet de "scanline" sur une image. Le point intéressant, c'est que le greffon génère l'interface graphique de réglage des paramètres de manière dynamique. Comme la syntaxe G'MIC n'est pas excessivement compliquée à maîtriser, on peut ainsi écrire des filtres accessibles dans GIMP en très peu de lignes ! Même les non-programmeurs peuvent s'y mettre. Les filtres déjà présents sont d'ailleurs définis de cette façon. De même, les mises à jour du greffon se font via un fichier .gmic4gimp_def qui peut se télécharger sur le réseau : aucune recompilation ni réinstallation n'est donc nécessaire pour mettre à jour et corriger les définitions des filtres disponibles.
Ces mécanismes permettent au greffon G'MIC d'être très ouvert et extensible. En espérant que cela amène des contributions par la suite...
- G'MIC et l'amélioration d'images bruitées
GREYCstoration est un algorithme de débruitage d'images développé dans la même équipe que celle où G'MIC a été réalisé.
G'MIC inclut bien sûr GREYCstoration, le filtre correspondant étant disponible dans le greffon par le menu Image denoising and enhancement/Anisotropic smoothing. À terme, le greffon initial de GREYCstoration ne devrait plus évoluer, car la flexibilité de G'MIC permet beaucoup plus de choses. En particulier, on peut tout à fait imaginer ajouter des entrées pour des profils de bruits particuliers, avec un minimum de paramètres à régler, tout cela pouvant se réaliser en quelques lignes de macros G'MIC seulement...
On peut d'ailleurs conseiller dès maintenant d'utiliser G'MIC plutôt que GREYCstoration, puisque l'évolution va se faire plus rapidement. G'MIC intègre d'ailleurs d'autres algorithmes d'améliorations (sharpening) que ne possède pas GREYCstoration.
- Le futur…
La communauté d'utilisateurs de GIMP est large et variée. Nous espérons avoir un maximum de retours sur l'utilisation de ce greffon. N'hésitez pas à l'utiliser, le packager sur des systèmes exotiques (G'MIC est multi plate-forme).
La compilation de la version "ligne de commande" de G'MIC est assez longue et gourmande, mais par contre, générer le greffon est très rapide : il vous suffit de charger l'archive source, d'aller dans gmic-1.3.0/src/ et de taper make gmic4gimp. Les seuls pré-requis étant d'avoir les paquets libgimp2.0-dev et libfftw3-dev installés. Une archive des exécutables greffon pourra être régulièrement mise à jour sur le site. N'hésitez pas à nous envoyer le résultat de vos compilations.
Dans un futur assez proche, de nouveaux filtres vont faire leur apparition. Il suffira de mettre à jour le fichier de configuration pour en profiter (ou d'appuyer sur le bouton Update filters pour les utilisateurs sous Unix).
À noter pour finir, que G'MIC est maintenant utilisable comme une bibliothèque C++ de fonctions, qui peut donc être appelée à partir de n'importe quel autre programme. Si l'intégration des possibilités de G'MIC vous intéresse, n'hésitez pas à nous contacter également (la lecture du fichier source gmic4gimp.cpp vous donnera de bonnes informations).
Aller plus loin
- Page web de G'MIC. (43 clics)
- Exemples de traitements réalisables. (35 clics)
- L'équipe IMAGE du laboratoire GREYC. (36 clics)
- Dépêche LinuxFR : Présentation de G'MIC. (18 clics)
- Copie d'écran : le greffon G'MIC en action… (26 clics)
# Remerciements pour l'empaquetage et tests.
Posté par David Tschumperlé (site web personnel) . Évalué à 10.
Merci en particulier donc à Claude, Angelo, Jérôme, Christophe et Romain !
[^] # Re: Remerciements pour l'empaquetage et tests.
Posté par David Tschumperlé (site web personnel) . Évalué à 10.
# :)
Posté par jm trivial (site web personnel) . Évalué à 6.
Je pense que les utilisateurs avertis de Gimp seront heureux d'avoir à leur disposition un outil aussi flexible, qui est un bon intermédiaire entre le logiciel WYSIWIG à la Gimp, et des outils plus « métier » comme la librairie C++ CImg.
Le choix est vraiment large…
# Merci David !
Posté par brunus (site web personnel) . Évalué à 10.
Nous utilisons Greycstoration pour améliorer la qualité d'images imprimés, photocopiées, re-numérisés, réimprimées que seul des profs peuvent inclurent dans des énoncés d'examens, comme le bac ou le brevet, sans se poser de questions. Comme nous éditons des annales du bac et du brevet, je me retrouve souvent à tenter d'améliorer la lisibilité de ces images...tout en plaignant de tout cœur les pauvres candidats qui se sont arrachés les yeux sur les légendes, les courbes, les typos illisibles, en se demandant si ils vont pas foirer leur examen parce qu'ils ne sont pas certain d'interpréter correctement le pâté qu'on daigne leur fournir.
Au moins dans les annales, pendant leurs révisions, si ils ont acheté nos publications, ils ont accès à des images amoureusement corrigées, et en partie avec Greycstoration !
Bon par contre c'est mort...les annales que nous éditerons en 2009 ne contiendront plus d'images corrigées...question de stratégie de production, de personnel etc...
[^] # Re: Merci David !
Posté par Pierre Jarillon (site web personnel) . Évalué à 6.
Merci d'avoir fait et publié cet excellent utilitaire.
[^] # Re: Merci David !
Posté par brunus (site web personnel) . Évalué à 3.
De mon coté il est intégré dans Gimp. J'ajoute le plugin certes, mais le résultat est là, je charge mon image et j'ai accès à Greycstoration par le menu des filtres.
Mais là je vais tester G'MIC.
# Problème de "locale"
Posté par David Tschumperlé (site web personnel) . Évalué à 3.
Je travaille sur ce problème, en espérant le corriger aussi vite que possible.
Désolé si vous rencontrez ce problème pour le moment.
Une solution (provisoire) : Passer le système en langue anglaise, et ça doit marcher.
[^] # Re: Problème de "locale"
Posté par David Tschumperlé (site web personnel) . Évalué à 5.
Encore désolé pour les problèmes occasionnés.
David.
[^] # Re: Problème de "locale"
Posté par gpe . Évalué à 1.
Par contre je vois que maintenant il n'y a plus de paquet .deb de dispo ?
# PA-RA-LLELE!
Posté par case42 (site web personnel) . Évalué à 5.
Hier soir j'ai compilé G'MIC sur mon Core i7 flambant neuf (oui tout cette histoire n'est qu'un alibi pour me la péter avec ma machine de bourrin).
Une fois le configure exécuter, je me dis que ça sera compilé en deux temps trois mouvement grace à un vigoureux "make -j 16", qui lancera la compilation de 16 objets en parallèle (c'est le paramétrage que j'utilise pour compiler des kernels et ça se passe très bien).
Quel ne fut pas ma déception en me rendant compte que tout le projet se trouve dans 2 fichiers CPP, ce qui fait que make n'a pu lancer que 2 compilations en parallèle, compilations qui du coup ont pris une plombe.
De plus, gcc monopolisait une quantité invraisemblable de RAM...
En y regardant de plus près, tous le projet tiens en deux fichiers CPP de respectivement 1000 et 3000 lignes ainsi que d'une poignée de headers, dont le pantagruélique CImg.h qui fait tout de même plus de 36000 lignes...
Alors sans compter le fait qu'on m'a inculqué à l'école de segmenter mes projets en un maximum de petits fichiers pour des raisons d'organisation, le fait est que les outils de compilation aussi préfèrent s'attaquer à une multitude de petit fichier (je suis certain qu'en segmentant Cimg.h, on mangerait beaucoup moins de ram, et en segmentant les fichiers CPP, on pourrait exploiter plusieurs processeurs à la compilation).
Je n'ai que survolé le code (j'ai vu qu'il y avait pleins de choses dans Cimg.h qui ( d'après ce qu'on m'a appris toujours ) n'ont rien faire dans un .h mais devrait être dans un .cpp...), et sans doute y a-t-il une raison technique qui a imposé cette organisation atypique. Je serais positivement ravis qu'un des développeur de ce projet nous l'explique (ceci n'est PAS, je répète, PAS de l'ironie) si c'est le cas...
[^] # Re: PA-RA-LLELE!
Posté par 2PetitsVerres . Évalué à 4.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: PA-RA-LLELE!
Posté par jm trivial (site web personnel) . Évalué à 2.
http://cimg.sourceforge.net/reference/group__cimg__faq.html#(...)
[^] # Re: PA-RA-LLELE!
Posté par David Tschumperlé (site web personnel) . Évalué à 8.
- D'abord, G'MIC se compile très bien en parallèle, je le fais comme ça chez moi :
dtschump@gemino:~/work/src/gmic/src$ make -j
make "CFLAGS+=-Dcimg_display=1 -I/usr/X11R6/include" "LDFLAGS+=-L/usr/X11R6/lib -lX11 -lpthread -lswscale" "STRIP_EXE=1" gmic
g++ -o gmic4gimp.o -c gmic.cpp -Dgmic_minimal -Dcimg_display=0 -Wall -W -O3 -ffast-math -fno-tree-pre -Dcimg_use_fftw3
make "CFLAGS+=-Dcimg_display=1 -I/usr/X11R6/include" "LDFLAGS+=-L/usr/X11R6/lib -lX11 -lpthread" "STRIP_EXE=1" gmic
make[1]: Entering directory `/users2/prof/dtschump/work/src/gmic/src'
g++ -o gmic_bool.o -c gmic.cpp -Dgmic_separate_compilation -Dgmic_bool -Dcimg_display=1 -I/usr/X11R6/include -Wall -W -O3 -ffast-math -fno-tree-pre -Dcimg_use_xshm -Dcimg_use_xrandr -Dcimg_use_png -Dcimg_use_jpeg -Dcimg_use_tiff -I/usr/include/ffmpeg -Dcimg_use_ffmpeg -Dcimg_use_zlib -Dcimg_use_magick -Dcimg_use_fftw3
g++ -o gmic_uchar.o -c gmic.cpp -Dgmic_separate_compilation -Dgmic_uchar -Dcimg_display=1 -I/usr/X11R6/include -Wall -W -O3 -ffast-math -fno-tree-pre -Dcimg_use_xshm -Dcimg_use_xrandr -Dcimg_use_png -Dcimg_use_jpeg -Dcimg_use_tiff -I/usr/include/ffmpeg -Dcimg_use_ffmpeg -Dcimg_use_zlib -Dcimg_use_magick -Dcimg_use_fftw3
g++ -o gmic_char.o -c gmic.cpp -Dgmic_separate_compilation -Dgmic_char -Dcimg_display=1 -I/usr/X11R6/include -Wall -W -O3 -ffast-math -fno-tree-pre -Dcimg_use_xshm -Dcimg_use_xrandr -Dcimg_use_png -Dcimg_use_jpeg -Dcimg_use_tiff -I/usr/include/ffmpeg -Dcimg_use_ffmpeg -Dcimg_use_zlib -Dcimg_use_magick -Dcimg_use_fftw3
... et j'en passe (j'ai également 16 coeurs sur cette machine).
La compilation prend alors environ 10 minutes sur un P4, 3Ghz à 16Go de RAM. On n'a pas mis la compilation parallèle par défaut car ca prend effectivement beaucoup de RAM (mais pas pour les raisons que tu invoques). Bref, essaye d'aller dans 'gmic/src' et de lancer 'make -j', ca devrait le faire, y a pas de raison : G'MIC a été prévu pour être compilé en parallèle.
Quant à CImg, sa structure parait bizarre à beaucoup de monde, mais c'est finalement très logique quand on ne fait pas juste survoler le truc : c'est une bibliothèque massivement "template", donc ne pouvant pas se 'pré-compiler' facilement en objets (puisque l'ensemble des fonctions et des types à compiler n'est connue que lors de la compilation du programme l'utilisant). Par ailleurs, pré-compiler toutes les fonctions pour les types les plus courants n'étant pas une bonne idée non plus, étant donné le nombre important de fonctions (qui ne seront pas toutes utilisées de toute facon), et la taille des fichiers objets qui en résulteraient.
Je ne remets pas en cause ce que tu as appris à l'école, mais le cas des bibliothèques template en C++ est un truc un peu particulier de ce point de vue (voir la STL ou Boost).
Pour finir, on pourrait très bien diviser le fichier CImg.h en pleins de petits fichiers. Je ne le fais pour les raisons suivantes :
Ca n'irait pas plus vite à compiler (les classes de CImg étant dépendantes les unes des autres, contrairement à la STL, tous les headers de CImg ainsi divisés seraient nécéssaires à la compilation du projet de toute façon. Il faudrait juste faire 20 includes au lieu d'un seul).
De même ca ne prendrait pas moins de RAM (pour les mêmes raisons).
Ca ne serait pas spécialement plus facile à maintenir (CTRL+S dans Emacs ou n'importe quel IDE C++ digne de ce nom permet d'aller à la définition d'une fonction rapidement, c'est pas un souci. Par ailleurs, le fichier est très bien structuré si tu regardes bien).
Au final, aucun avantage donc à diviser ce fichier, à part faire plaisir à quelques personnes aux préjugés un peu tenaces sur la "beauté" de ce que doit être un code (ce terme revient souvent, ca me fait doucement rigoler).
G'MIC existe grâce à CImg, et à profite de sa généricité. G'MIC peut lire et traiter des images de bool, float, int, etc... Avec à chaque fois des fonctions de traitements spécialisés pour chaque type (un blur d'une image de char ne vas pas avoir besoin de convertir d'abord l'image en float puis la recaster en char). Ce sont des propriétés essentielles au fait que G'MIC soit générique. On ne peut pas avoir le beurre et l'argent du beurre : cette généricité se paye par un temps de compilation un peu plus important que pour des projets plus classiques.
Après j'aurais pu baser G'MIC sur autre chose que CImg, mais bon, moi j'aime bien CImg, c'est pratique à utiliser, c'est beau, c'est top moumoute :), et ca permet de faire pleins de choses en quelques lignes (G'MIC ne fait 'que' 3825 lignes, c'est très faible par rapport au nombre de choses qu'il sait faire).
Après, si tu veux t'amuser, tu peux toujours essayer de décomposer dans tous les sens, si tu gagnes 1/100 de seconde sur le temps de compilation ou sur la RAM utilisée, fais moi signe, ça m'intéresse.
David.
[^] # Re: PA-RA-LLELE!
Posté par case42 (site web personnel) . Évalué à 4.
Effectivement, l'argument "parce que templates", et recevable.
Ceci dit j'ai tout de même quelques remarques :)
(bon alors ça se voit pas, mais c'est au moins la 4ieme fois que je reprends ce messages, au fur et a mesure que j'avance dans la compréhension du code...)
Bon pour CImg.h, je rends les armes. Effectivement le coté template fait qu'on ne peut pas y faire grand chose. Mais c'est à la fois sa force et son talon d'achile: je ne connaissais pas CImg.h, mais ce que je sais c'est que si un jour je dois choisir une librairie de manipulation d'image, elle viendra en dernier sur ma liste (sauf si je dois gérer des images dont les éléments sont de type ChuckNorris, la on pourra discuter), parce que les pénalités que j'ai déjà décrites ne sont contrebalancés que dans certains cas très particulier...
Pour gmic.cpp, effectivement je ne vois pas de moyen d'accélérer le projet dans son ensemble, MAIS j'en vois une qui allègera le boulot de compilation pour le développeur, en permettant un semblant de compilation incrémentale (oui parce actuellement, si tu touche à un iota de gmic.cpp ou CImg.h, tu recompile tout du début... )
Je propose de faire des classes "wrapper" autour de CImg
(je pense que ces wrappers pourront facilement être généré automatiquement par un script dans la chaine de compilation pour chaque type géré par gmic)
J'en ai fait un bout qui marche, avec juste un constructeur et une méthode, à l'arrache:
CImgUC.h :
#include "CImg.h"
class CImgUC
{
protected:
#ifdef _CIMG_UC_
cimg_library::CImg<unsigned char> *img;
#else
void *img;
#endif
public:
CImgUC(const char *const filename);
CImgUC& blur(const float sigma, const bool cond=true);
};
CImgUC.cpp
#define _CIMG_UC_
#include "CImgC.h"
CImgUC::CImgUC(const char *const filename)
{
img = new cimg_library::CImg<unsigned char>(filename);
}
CImgUC& CImgUC::blur(const float sigma, const bool cond)
{
img = &img->blur(sigma, cond);
return(*this);
}
Une fois qu'on a ça, on peut tranquillement compiler un cimg_uc.o contenant cette classe, classe qu'on utilisera dans gmic.cpp , mais comme on masque complètement CImg.h, on a un gros gain à la compilation.
Quelques temps:
#test.cpp : utilise directement CImg.h
$ time g++ test.cpp -lX11 -lpthread
real 0m5.353s
user 0m5.016s
sys 0m0.320s
#test2.cpp fait la même chose en utilisant la classe CImgUC compilée par CImgC.cpp
$ time g++ -c -o cimgc.o CImgC.cpp
real 0m5.183s
user 0m4.780s
sys 0m0.356s
$ time g++ cimgc.o test2.cpp -lX11 -lpthread
real 0m0.200s
user 0m0.144s
sys 0m0.052s
Voila, en temps que développeur, à a la première compilation ma version est pénalisée... Mais si je change le code de test2.cpp, le temps de compilation du projet total reste à 0.2s au lieu de 5s dans l'autre cas...
J'avais d'autres choses à dire pour soutenir mon argumentaire, mais j'ai plus guère de temps...
# Information suplémentaire
Posté par pr_bond . Évalué à 1.
Voili A +
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.