Journal [Imagerie] Sortie de G'MIC 1.3.2.1

Posté par  (site web personnel) .
Étiquettes :
11
13
août
2009
Salut à tous,
En ces temps de vacances d'été, on a rarement envie de rester le nez collé devant un écran d'ordinateur, pour programmer ou faire du traitement d'image. Mais si vous êtes comme moi, et que vous travaillez en Normandie (à Caen), alors c'est différent, car il vaut mieux de toute façon être au sec à l'intérieur, que dehors sous la pluie. Comme dirait un collègue, l'été en Normandie, cette année, c'était le 20 juillet.

Bref, du coup, ça laisse un peu le temps de bosser, et je suis heureux de vous annoncer la sortie de la version 1.3.2.1 de G'MIC (GREYC's Magic Image Converter), qui est un système ouvert et libre pour le traitement d'image (et pas seulement pour les normands). J'ai déjà eu l'occasion de parler de G'MIC sur linuxfr, ici et ici. Pour résumer :
  • G'MIC définit un langage rudimentaire (et simple) pour définir des enchaînements (pipelines) d'algorithmes de traitement d'images sur des listes d'images d'entrées. Ces pipelines peuvent être réutilisés par la suite, et viennent donc enrichir le langage. Un exemple de fichier de définitions de fonctions personnalisées peut être vu ici. On peut illustrer ce fait en considérant par exemple qu'un effet cartoon sur une image pourrait être obtenu en combinant le résultat d'une détection de contours et d'une quantification de couleurs, la détection de contours pouvant elle même être estimée par un seuillage binaire d'une norme de gradient, etc.... Créer de tels pipelines donnent des possibilités (presques) infinies en termes d'effets ou de filtres que l'on peut obtenir sur des images.

  • G'MIC fournit le code source d'une implémentation libre d'un interpréteur de ce langage, qui peut être ainsi utilisé dans n'importe quel programme extérieur, pour profiter rapidement de tous les traitements disponibles dans G'MIC.

  • G'MIC fournit également deux interfaces utilisateurs pour utiliser cet interpréteur : l'une sous forme d'un exécutable gmic à appeler depuis la ligne de commande, et l'autre sous forme d'un greffon pour GIMP, comprenant une interface graphique utilisable par tout un chacun. La version ligne de commande est donc idéologiquement assez proche de l'utilitaire convert de la suite ImageMagick. Le greffon est plus original, et se rapproche dans l'idée de l'excellent greffon Mathmap dont les fonctionalités sont par contre uniquement disponibles à l'intérieur de GIMP.
G'MIC est donc une plateforme de traitement d'image très ouverte, qui se veut utilisable aussi bien par l'utilisateur final que par le programmeur soucieux d'intégrer des batteries de filtres/d'effets de traitement d'image dans son propre programme sans avoir à tout reprogrammer.

La version 1.3.2.1 de G'MIC apporte de nombreuses corrections de bugs et d'améliorations du langage, permettant d'avoir notamment de nouveaux filtres/effets disponibles dans le greffon pour GIMP. G'MIC est un projet encore jeune (moins d'un an), et qui se stabilise petit à petit.

Parmi les filtres nouveaux, intéressants ou originaux, on peux noter :
  • De nombreux mixeurs de couleurs, dans des espaces divers et variés (RGB,YCbCr,Lab,HSV,CMYK) comme ici par exemple.
  • Un rehausseur de contraste local qui permet de faire des effets amusants, en rehaussant les couleurs ou les structures.
  • L'inclusion de filtres morphologiques rapides.
  • L'extraction d'isophotes dans des images, comme ici par exemple.
  • L'amélioration de nombreux filtres déjà existants comme "Polaroid" et "Reflection" qui permettent de créer ce genre d'effets en 3 clics.
En tout, une centaine de filtres est déjà disponible, chacun étant la plupart du temps paramétrable à souhait. De quoi s'amuser pour les longues soirées d'hiver d'été normand. Certains diront que beaucoup de ces filtres ont déjà leur équivalent soit déjà dans GIMP, soit dans des packs de scripts à installer (comme l'excellent Fx-Foundry), et ils n'auront pas complètement tort, bien que de nombreux filtres disponibles dans G'MIC n'ont pas (à ma connaissance) d'équivalents ailleurs, comme par exemple les filtres de débruitage GREYCstoration. Mais comme j'ai essayé de vous l'expliquer ici, G'MIC n'est de toute manière pas uniquement un greffon pour GIMP, mais un système complet, ouvert et évolutif, dont une des instances se trouve être un greffon pour GIMP. A noter que pour les amateurs de traitement d'image par batch, tous les effets disponibles dans le greffon sont par exemple utilisables via gmic en ligne de commande. J'espère également à terme que des gens seront intéressés pour intégrer l'interpréteur G'MIC dans leur propre projet.

A noter également que le greffon de G'MIC est traduit en 4 langues (Français, Italien, Catalan et Anglais), et que vous êtes plus que bienvenus si vous souhaitez aider à la traduction de l'interface (les filtres eux, ne sont pas traduits, le travail requis pour la traduction est donc très réduit).

Pour conclure, pas de grands bouleversements dans cette version 1.3.2.1, mais de petites améliorations et des nouveautés qui je l'espère apporteront de la fraicheur aux traiteurs d'image de toute sorte, infographistes, artistes ou programmeurs.

Bonne rentrée à tous !
  • # Niveau compilation

    Posté par  . Évalué à 4.

    Est-ce que c'est toujours aussi horrible à compiler ? La dernière fois que j'ai essayé, ça a échoué en bouffant toute ma RAM pendant 30 minutes (et pourtant j'ai 2Gio de RAM + 2Gio de swap...).
    • [^] # Re: Niveau compilation

      Posté par  (site web personnel) . Évalué à 6.

      Oui, c'est même encore pire qu'avant.
      La réponse peut paraitre crue, mais c'est malheureusement vrai.

      Nous avons fait quelques tests ici pour déterminer la cause, et il s'avère que g++ bouffe une quantité gigantesque de RAM lors de la phase d'optimisation. En supprimant les optimisations '-O0' à la place de '-O3', G'MIC se compile sans problème même avec 512Mo de RAM en un temps tout à fait acceptable (quelques minutes). Il doit y avoir un flag magique à trouver, je vais peut-être essayer avec d'autres compilo (icc) qui m'ont l'air moins gourmand en ressource pour l'optimsation.


      David.
      • [^] # Re: Niveau compilation

        Posté par  (site web personnel) . Évalué à 4.

        Peut-être signaler le problème sur la mailing-list GCC en demandant de l'aide ?
        • [^] # Re: Niveau compilation

          Posté par  (site web personnel) . Évalué à 4.

          En fait, j'essaye dans un premier temps de bien comprendre le problème avant effectivement de poster une question sur un forum g++, qui si elle est trop vague ne va pas faire avancer le schmilblick.
          J'avais fait un bug report g++ (pour un truc mineur surement facile à corriger) qui a mis plus d'un an avant d'être corrigé, donc je suppose qu'il vaut mieux arriver avec le maximum d'indices pour espérer quelque chose de concret (en même temps je les comprend un peu!)

          David.
          • [^] # Re: Niveau compilation

            Posté par  (site web personnel) . Évalué à 1.

            Ou alors tu l'ouvres rapidement, et ils te demanderont ce dont ils ont besoin pour diagnostiquer... En général ouvrir un bug tard, c'est une mauvaise idée. Vu le temps moyen de correction, autant l'ouvrir le plus tôt possible avant d'être vraiment arrivé à un stade où le problème est vraiment très très pénalisant.
            • [^] # Re: Niveau compilation

              Posté par  (site web personnel) . Évalué à 3.

              Je suis d'accord, mais tant que possible j'essaie d'avoir une idée la plus précise possible du problème, dans la mesure de mes maigres compétences sur le sujet. De toute façon, il faudra certainement faire les tests que je compte faire, un moment ou un autre, donc autant les faire avant de poster. Je suis quand même pas à une ou deux semaines près non plus (surtout si il faut un an d'attente ensuite :) ), et puis c'est quand même plus respectueux de leur travail à eux.

              David.
              • [^] # Re: Niveau compilation

                Posté par  . Évalué à 2.

                D'un autre côté, en parler sur un IRC ou une Ml appropriée auparavant ça peut t'aider aussi ... genre on pourra te dire que c'est tel algo d'optimisation qui coute beaucoup en temps de calcul avec ton code parce que t'es dans un mauvais cas, au premier coup d'euil ...

                Si je me souviens bien ta bibliothèque tient dans un header, ça doit être pénible si t'es obligé de tout recompiler à chaque fois.
          • [^] # Re: Niveau compilation

            Posté par  (Mastodon) . Évalué à 2.

            Au contraire, signale toi, tu as un exemple de code qui met beaucoup de temps, c'est largement mieux que le gars qui vient et qui dit "j'ai un code, que je peux pas vous filer, qui met du temps à compiler". Je pense que tu peux ouvrir ton bug, tu as toutes les informations pour qu'ils reproduisent le bug et résolvent le problème.
  • # Mise à jour : G'MIC 1.3.2.2

    Posté par  (site web personnel) . Évalué à 1.

    Bon , j'ai procédé à une petite mise à jour vers la 1.3.2.2, avec deux bugs corrigés et surtout la possibilité de rendre certains filtres 'animés', où le greffon est capable de générer une suite de fichiers ou de layers qui partent d'un jeu de paramètre de départ, vers un jeu de paramètre de fin.

    Des copies d'écran de cette nouvelle possibilité sont disponibles à [http://www.flickr.com/photos/90104203@N00/3820657222] et [http://www.flickr.com/photos/90104203@N00/3820657084/].

    Un exemple de gif animé généré par ce procédé est visible ici : [http://www.greyc.unicaen.fr/~dtschump/cube3d.gif].

Suivre le flux des commentaires

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