Traitement d'images : Quand G'MIC 1.3.0 s'invite dans GIMP

Posté par (page perso) . Modéré par baud123.
34
13
jan.
2009
Graphisme/photo
La version 1.3.0 de G'MIC (GREYC's Magic Image Converter) est sortie.

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).
  • # Remerciements pour l'empaquetage et tests.

    Posté par (page perso) . Évalué à  10 .

    Je tiens également à remercier les joyeux lurons de Linux On Root et de sa mailing list associés, ils ont été très patients et compétents pour l'empaquetage et les tests.

    Merci en particulier donc à Claude, Angelo, Jérôme, Christophe et Romain !
  • # :)

    Posté par (page perso) . Évalué à  6 .

    C'est chouette de voir une idée intéressante ainsi concrétisée.
    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 (page perso) . Évalué à  10 .

    J'ai déjà eu l'occasion de te remercier, car j'ai utilisé Greycstoration dans une chaîne de production. Mais je ne manquerais pas une occasion de te remercier même si je dois taper à peu près le même commentaire à chaque fois ;-)

    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 (page perso) . Évalué à  6 .

      J'ai apprécié Greycstoration à de nombreuses reprises. C'est un logiciel vraiment très performant. Mais j'apprécierai encore plus de le voir intégré dans Gimp, ça évitera des manipulations de fichier supplémentaires.

      Merci d'avoir fait et publié cet excellent utilitaire.
      • [^] # Re: Merci David !

        Posté par (page perso) . Évalué à  3 .

        Bonjour Pierre,

        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 (page perso) . Évalué à  3 .

    Il s'avère que sur les systèmes dont la langue est le Français, le plug-in a un petit problème. Apparemment, un souci avec les locales C++ qui ne sont pas bien ajustées.
    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 (page perso) . Évalué à  5 .

      Voilà le problème est réglé, j'ai remis à jour l'archive sur le site de Sourceforge.

      Encore désolé pour les problèmes occasionnés.

      David.
      • [^] # Re: Problème de "locale"

        Posté par . Évalué à  1 .

        Je me disais bien qu'il y avait un truc qui clochait! Je voulais en parler ici ce matin mais tu as été plus rapide!
        Par contre je vois que maintenant il n'y a plus de paquet .deb de dispo ?
  • # PA-RA-LLELE!

    Posté par (page perso) . Évalué à  5 .

    Le projet est très sympa, mais il y a quand même des trucs qui m'interpellent au niveau du vécu, n'y voyez rien de méchant, plutôt une critique constructive...

    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 . Évalué à  4 .

      Voir les différentes nouvelles et journaux de sortie de ce logiciel. à chaque fois on en parle ;-)

      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: PA-RA-LLELE!

      Posté par (page perso) . Évalué à  8 .

      Bon ce genre de question revient toujours. Je commence à avoir l'habitude. Je vais te répondre très rapidement sur le pourquoi du comment :

      - 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 (page perso) . Évalué à  4 .

        Je te remercie de ta longue réponse, je ne regrette pas d'avoir posé ces question...
        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 (page perso) . Évalué à  1 .

    Pour information, le laboratoire mixte GREYC fait partie de l'école d'ingénieur de Caen : ENSICAEN -> http://www.ensicaen.fr

    Voili A +

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.