Sortie de G'MIC 1.3.5

Posté par (page perso) . Modéré par tuiu pol.
23
17
mai
2010
Graphisme/photo
Je suis heureux de vous annoncer la sortie d'une nouvelle version majeure (la 1.3.5.0) de G'MIC (GREYC's Magic Image Converter), un outil de manipulation et de traitement d'images génériques (2D/3D/multi-valuées), développé dans l'équipe IMAGE du laboratoire GREYC (unité CNRS UMR 6072), depuis août 2008. Ce petit logiciel sait traiter les images couleurs « classiques » (8/16 bits par composantes), mais aussi des données plus complexes, comme les images (ou les séquences d'images) volumiques et/ou multispectrales, à type de pixels quelconques (à valeurs flottantes notamment).

NdM : Merci à David Tschumperlé pour son journal transformé en dépêche. Ce projet définit en premier lieu un langage de script assez complet et extensible (plus de 500 commandes définies à ce jour), dédié entièrement à la conception de pipelines de traitement d'images. Il permet en particulier d'exprimer des filtres ou des effets sur des images de manière très concise. Ce langage est utilisable grâce à une implémentation libre de son interpréteur, distribué actuellement sous trois formes différentes, toutes sous licence CeCILL (compatible GPL) :

  • L'outil en ligne de commande gmic permet de manipuler des images à partir d'un shell. Cet outil peut s'apparenter à la suite d'outils fournis par ImageMagick (IM) ou GraphicsMagick (GM), car il permet tout à la fois de créer, convertir, visualiser et traiter des paquets d'images. L'intégration cohérente de l'ensemble de ces fonctionnalités dans un seul et unique programme est l'une des forces de G'MIC. Une petite discussion sur les différences d'approches entre G'MIC et IM/GM est proposée dans l'un des mes précédent journaux ;
  • Le greffon gmic_gimp permet d'étendre le logiciel de retouche d'images maintenant classique qu'est GIMP, en proposant dans une interface graphique unique, une panoplie de filtres divers et variés (environ 170 à ce jour) à appliquer sur vos images. Ce greffon est actuellement la partie la plus visible et sans doute la plus utilisée de G'MIC, bien qu'étant beaucoup plus limité que la version en ligne de commande (notamment car GIMP ne permet pas encore de bien gérer les images à plus de 8 bits par composantes). Ce greffon intègre en particulier des algorithmes assez sympathiques et performants pour l'amélioration d'images (rehaussement de contours/contrastes, réduction du bruit, retouches colorimétriques, reconstruction de zones manquantes, etc...) ;
  • La bibliothèque C++ libgmic permet d'intégrer relativement facilement l'interpréteur G'MIC (et donc l'ensemble de ses possibilités de traitement) dans des programmes open-source tiers (à licences compatibles avec la GPL). C'est un des points sur lesquels j'essaie d'attirer l'attention des développeurs, car il me semble que disposer d'une telle panoplie de filtres « prêts à l'emploi » est quelque chose qui pourrait être intéressant pour tout logiciel de retouche ou de création d'images, d'autant que la bibliothèque est assez légère (environ 2,5 Mo), et que ses filtres évoluent avec le temps, que de nouveaux filtres apparaissent, sans que l'API de la bibliothèque ne soit modifiée, ce qui implique une facilité de mise à jour pour le développeur. Un premier pas a été franchi par Jos De Laender, qui semble intéressé pour intégrer la libgmic dans son logiciel de traitement des images RAW, nommé jdlRaw. C'est encourageant, car cela pourrait permettre d'avoir une interface graphique à certains filtres de G'MIC pour traiter des images couleurs à 16 bits par composantes, sans passer par la ligne de commande.
Voici un tour d'horizon rapide des nouveautés de cette dernière version 1.3.5.0, ainsi que quelques données décrivant l'état actuel et l'évolution du projet. Les nouveautés peuvent sembler assez mineures, même si un travail de fond important a été entrepris pour améliorer le langage, et stabiliser/optimiser l'interpréteur.

Nouveautés :
  • Apparition du mode projection parallèle pour le rendu d'objets 3D maillés ;
  • Nouvelles commandes -break et -continue, qui permettent de sortir/continuer des boucles de traitements, de la même manière qu'en C/C++ ;
  • Apparition d'un shell intégré, simpliste mais fonctionnel, pour la version en ligne de commande. Il est particulièrement sympa à utiliser dans un but de découverte des diverses possibilités de G'MIC, puisque l'on visualise à chaque instant l'état des images que l'on manipule ;
  • Gestion plus souple des substitutions de paramètres lors de l'appel de fonctions définis par l'utilisateur. G'MIC utilise la notation classique $1,$2,.. pour représenter les arguments des fonctions appelés, et il est maintenant possible d'exprimer des substitutions assez tordues, par exemple ${2--2}, remplacé par tous les arguments sauf le premier ($1) et le dernier ($-1) ;
  • Meilleure gestion de la fenêtre de prévisualisation dans le greffon pour GIMP. La vue n'est plus recalculée si on coche/décoche successivement le toggle button Preview, ce qui permet de comparer rapidement l'effet d'un filtre sur une image originale ;
  • Apparition d'un mode séparation horizontal ou vertical pour la prévisualisation de certains filtres du greffon pour GIMP. Cela permet également de comparer rapidement l'effet des paramètres d'un filtre sur une image donnée ;
  • Nouveau filtre de composition Shape Average, permettant de remplir séparément des régions non-connexes d'un masque avec la couleur moyenne de l'image dans ces zones. Ce mode de composition permet notamment de créer des effets mosaïques en spécifiant des formes de mosaïques quelconques ;
  • Nouveau filtre de déconvolution d'image, basé sur l'algorithme de Richardson-Lucy, pour réduire l'effet de flou isotrope dans les images ;
  • Nouveau filtre Stencil, permettant de créer des formes binaires dont les contours sont données par ceux d'une image couleur ;
  • Nouveau filtre Relief light, permettant d'ajouter une source de lumière sur une image en calculant une illumination tenant compte de la carte d'élévation donnée par l'image elle-même. Cela permet de créer des effets plastiques assez amusants.
Infos projet et perspectives :
  • G'MIC est devenu en un peu moins de deux ans un projet relativement conséquent. Il comptabilise aujourd'hui plus de 56 000 lignes de code (C++ et script), et totalise bientôt 80 000 téléchargements. Son développement a été assez rapide (dans la mesure où je suis l'unique développeur), facilité par l'utilisation de CImg, bibliothèque C++ template pour le traitement d'images, développé dans la même équipe. J'ai reçu pas mal d'aide de personnes extérieures au laboratoire, pour les tests, l'empaquetage, le design, le site web, etc. Merci à eux pour leur travail acharné ;
  • Des paquets officiels de G'MIC pour la distribution Debian sont maintenant disponibles (pour la version 1.3.4.1, et bientôt pour la 1.3.5.0), grâce au travail volontaire du mainteneur Bernd Zeimetz, déjà responsable du super paquet gimp-plugin-registry (que tout utilisateur de GIMP se doit d'installer, par ailleurs). Un grand merci à lui ! Il a notamment proposé d'ajouter G'MIC comme dépendance conseillée à l'installation de la dernière version du paquet gimp-plugin-registry, ce qui va sans aucun doute améliorer la visibilité de notre projet, ce dernier paquet étant installé et utilisé par un grand nombre de personnes ;
  • On a « fêté » l'inscription du 100ème membre au groupe Flickr dédié à G'MIC. Ça fait toujours plaisir de franchir ce type de seuil symbolique. N'hésitez pas à vous inscrire et à faire partager vos réalisations G'MICesques dans la galerie d'image collaborative prévue à cet effet :)
  • En préparation, le complètement automatique des commandes G'MIC en utilisant les mécanismes de complètement personnalisé des shells bash et zsh. Ce projet proposé à des étudiants ingénieurs de l'ENSICAEN (Ecole Nationale Supérieure des Ingénieurs de Caen) est très prometteur (de ce que j'en ai vu pour le moment), et va améliorer sans aucun doute l'utilisation de gmic en ligne de commande (la touche TAB servant à la fois à compléter les noms de commandes ainsi qu'à donner la liste des arguments possibles pour une commande invoquée). Un grand merci à Guillaume Née, doctorant de l'équipe IMAGE pour cette très bonne idée et pour le temps d'encadrement qu'il y consacre.
En espérant que la sortie estivale de cette nouvelle version de G'MIC puisse être l'occasion de vous intéresser à ce projet, et pourquoi pas (soyons fous) de devenir même utilisateur enjoué de ce sympathique logiciel !
  • # intéressant

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

    Beau travail.

    Quels sont les dépendances de G'MIC ?

    Une inclusion dans Krita serait-elle envisageable ? est-ce une bonne idée ?
    • [^] # Re: intéressant

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

      On peut voir les dépendances par exemples ici :

      pour l'outil en ligne de commande :

      http://packages.debian.org/fr/sid/gmic

      et pour le plug-in :

      http://packages.debian.org/fr/sid/gimp-gmic

      G'MIC est en fait très modulable et il est possible de le compile avec seulement un sous-ensemble des dépendances. Il conserve la plupart de ses possibilités de traitements, les dépendances étant là principalement pour la gestion des formats de fichiers images en entrée/sortie.

      Une inclusion dans Krita serait envisageable, à mon avis c'est une très bonne idée, vu que Krita sait gérer le 16bits.
      Après, personnellement je n'ai pas le temps, mais si quelqu'un est motivé, je pourrais donner un coup de main avec plaisir.
      • [^] # Re: intéressant

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

        C'était déjà inclus dans krita avant que ça ne le soit dans Gimp :).
        C'est aussi inclus dans showfoto, qui est beaucoup plus grand public.
  • # merci

    Posté par (page perso) . Évalué à  -2 .

    Encore une superbe news de patrick_g il est infatigable !!
    • [^] # Re: merci

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

      Comme indiqué dans la NdM, c'est David Tschumperlé qui a rédigé le texte.
      • [^] # Re: merci

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

        Je crois (j'espère) que c'était ironique.
        En tout cas vivement le site RoR qui corrigera cette satanée obligation d'avoir comme nom d'auteur le nom de celui qui transforme le journal en dépêche.
    • [^] # Re: merci

      Posté par (page perso) . Évalué à  -2 .

      C'est pas croyable, une vrai machine ce mec !
      Je sens que ma première journée de vacance, je vais bien l'occupée avec tout ça

      Très bon travail !
  • # Dessin vectoriel ?

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

    J'admire le travail de David et des autres intervenants sur G'MIC, que j'utilise assez souvent pour mes traitements photo.
    Dans le cadre de mon boulot, je l'ai aussi utilisé pour nettoyer des numérisations de documents devenu très peu lisibles (fax de scan de fac de scan...ou pas loin!)

    Mais j'aimerai maintenant utiliser G'MIC pour traiter en entrer de l'EPS, voir du LaTeX (des formules de maths). J'ai cherché dans la doc, et je n'ai rien trouvé. Y a t-il déjà eu des demandes en ce sens, l'évocation d'une possibilité d'implémenter la prise en charge de vectoriel EPS ou SVG ?
    • [^] # Re: Dessin vectoriel ?

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

      Non, il n'y a jamais eu de telles demandes. G'MIC est basé sur des algos de traitement d'images "classiques", vues comme des tableaux de pixels, pas comme des descriptions d'objets vectoriels, et à priori, si on veut traiter de telles images avec G'MIC, il faudra forcément les convertir un moment ou à un autre en tableaux de pixels.
  • # Packaging

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

    Bon, toujours pas empaqueté chez Mandriva, snif , snif...

    ⚓ À g'Auch TOUTE! http://agauch.fr

  • # Puissance des GPU

    Posté par . Évalué à  7 .

    Depuis quelque temps la communauté scientifique tend à utiliser de plus en plus les unités graphiques pour le calcul scientifique. Cette technique est extrêmement adaptée lorsque le problème à traiter peut simplement se décomposer en sous problèmes. Il me semble qu'une bonne partie de l'analyse d'image respecte cette contrainte. Il serait donc vraiment intéressant d'avoir accès à un outil tel que G'MIC utilisant nos GPU.

    N'étant pas un spécialiste de la compilation, je ne peux pas réellement savoir comment s'y prendre pour atteindre un tel but, mais il me semble que OpenCL est basé sur LLVM, donc peut être qu'un première étape serait de parvenir à compiler G'MIC via LLVM et clang ?

    Si j'évoque ce problème c'est parce que j'aimerais d'ici 1 ou 2 ans être capable de faire du traitement d'image en temps réel dans une optique de contrôle de machines expérimentales, bien que je sache qu'il existe OpenCV qui implémente déjà beaucoup d'algos, son architecture ne me convient pas toujours c'est pour cela que j'aimerais parfois utiliser un autre framework.

    J'ai vu qu'il existait PANDORE, et que tu travailles dessus, aussi je me demande si pandore peut profiter des évolutions de Cimg/G'MIC, et me pose la question de savoir pourquoi ne pas avoir utilisé OpenCV.

    Je serais donc vraiment intéressé par utiliser ces outils, mais j'ai besoin de pouvoir les situer dans les outils existant.
  • # Puissance des GPU

    Posté par . Évalué à  -1 .

    Depuis quelque temps la communauté scientifique tend à utiliser de plus en plus les unités graphiques pour le calcul scientifique. Cette technique est extrêmement adaptée lorsque le problème à traiter peut simplement se décomposer en sous problèmes. Il me semble qu'une bonne partie de l'analyse d'image respecte cette contrainte. Il serait donc vraiment intéressant d'avoir accès à un outil tel que G'MIC utilisant nos GPU.

    N'étant pas un spécialiste de la compilation, je ne peux pas réellement savoir comment s'y prendre pour atteindre un tel but, mais il me semble que OpenCL est basé sur LLVM, donc peut être qu'un première étape serait de parvenir à compiler G'MIC via LLVM et clang ?

    Si j'évoque ce problème c'est parce que j'aimerais d'ici 1 ou 2 ans être capable de faire du traitement d'image en temps réel dans une optique de contrôle de machines expérimentales, bien que je sache qu'il existe OpenCV qui implémente déjà beaucoup d'algos, son architecture ne me convient pas toujours c'est pour cela que j'aimerais parfois utiliser un autre framework.

    J'ai vu qu'il existait PANDORE, et que tu travailles dessus, aussi je me demande si pandore peut profiter des évolutions de Cimg/G'MIC, et me pose la question de savoir pourquoi ne pas avoir utilisé OpenCV.

    Je serais donc vraiment intéressé par utiliser ces outils, mais j'ai besoin de pouvoir les situer dans les outils existant.

Suivre le flux des commentaires

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