Journal Nouvelles du projet G'MIC : Version 1.5.1.2

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
32
19
avr.
2012

Sommaire

Salutations,
A l'occasion de la sortie de la version 1.5.1.2 du projet G'MIC (GREYC's Magic Image Converter), je propose ici de donner quelques nouvelles récentes sur son développement, mon dernier journal sur ce sujet datant d'octobre 2011. Attention, on parle ici de traitement d'images, donc il va y avoir des images :) !

Description du projet

G'MIC est un projet libre (licence CeCILL) qui définit un langage de script minimal et concis pour la définition de pipelines de traitements d'images, propose un interpréteur (écrit en C++) de ce langage, et des binaires/bibliothèques utilisables par tous intégrant cet interpréteur, plus particulièrement :

  • gmic : Outil utilisable en ligne de commande pour convertir/visualiser/traiter des images (à la manière de convert/mogrify/display d'ImageMagick, ou de gm de GraphicsMagick). Il est capable gérer les séquences d'images, les images volumiques et les images multi-spectrales, à valeur entières ou flottantes. C'est un outil très générique, une sorte de couteau suisse du traitement d'image, que l'on peut même enrichir avec des propres fonctions.

G'MIC en ligne de commande

  • gmic_gimp : Plug-in pour GIMP proposant une liste de filtres et d'effets originaux (env. 300 à ce jour) à appliquer sur vos images. C'est l'un des composants de G'MIC les plus utilisés par le grand public, avec une communauté très active (via le forum Flickr, mais également via le site GimpChat). C'est un peu la vitrine du projet, même si dans les faits, il n'utilise qu'une petite partie de ses possibilités (GIMP étant limité aux images 2d, 4 canaux maximum RGBA, et surtout 8bits / composante).

G'MIC dans GIMP

  • ZArt (nouveau!) : Plateforme de démonstration permettant d'appliquer des effets G'MIC sur des images provenant de la webcam. C'est l'une des nouveauté récente qui est apparue dans G'MIC. Il est basé sur Qt4 pour l'interface graphique. Pratique pour illustrer quelques rudiments de traitement d'images à un public varié (étudiants, visiteurs aux fêtes de la sciences, etc…).

G'MIC dans GIMP

  • libgmic : Bibliothèque C++ permettant d'intégrer facilement à un programme les possibilités de l'interpréteur G'MIC (donc tous les effets/filtres d'images en particulier). Cette bibliothèque n'est pas vraiment utilisée actuellement, mais j'espère qu'elle le sera dans un futur proche.

Nouveautés

Le nombre de nouveauté et d'améliorations qui ont été appporté depuis la dernière version 'majeure' 1.5.0.0 est assez important (Changelog complet).
On peut en particulier noter les points suivants :

  • Nouvelle galerie d'images dédiée aux effets disponibles dans le plug-in pour GIMP.
  • Mise à disposition d'un manuel de référence (fichier .pdf d'env. 300 pages). Ce manuel présente l'ensemble des commandes/traitements disponibles, avec pour la plupart un ou plusieurs exemples d'utilisation. Il y a actuellement plus de 750 opérations disponibles pour traiter vos images !
  • Arrivée de ZArt comme un composant de G'MIC (voir ci-dessus).
  • Beaucoup de nouveaux filtres et effets pour le plug-in GIMP ont vu le jour. Quelques uns sont illustrés ici, dans l'ordre de gauche à droite et de haut en bas : Cube frame, Colormap, Dices, Solidify, Light rays, 8bits oldskool, Superformula, Truchet, Circlism, Color Abstraction, Painting, Shadebobs.

Nouveaux filtres dans GIMP

  • Quelques nouvelles démonstrations des possibilités du langage, en tant que commandes à lancer en ligne de commande (avec gmic donc) : Plasma, 3d reflection, Minesweeper, Fireworks, Whirl, 3d rubber.

Nouvelles commandes dans 'gmic'

  • Communauté d'utilisateurs grandissante : de plus en plus d'utilisateurs se font connaitre, et proposent leurs services, notamment pour l'empaquetage (rpm,deb,dmg), l'écriture de tutoriaux, et la création de nouveaux filtres. J'ai beaucoup travaillé sur le plug-in pour le munir d'un mécanisme permettant d'activer des sources externes de filtres, et certains contributeurs ont déjà proposé des filtres/effets divers et variés, notamment pour convertir des images et des vidéos en 3D stéréoscopiques (voir ici). C'est vraiment agréable de voir des gens intéressés qui prennent le temps d'apprendre les rudiments du langage pour créer leurs propres effets.
  • Les possibilités de G'MIC sont aujourd'hui prises au sérieux par plusieurs développeurs de logiciels extérieurs, et j'ai des contacts pour l'intégration de filtres/effets G'MIC dans d'autres logiciels. C'est déjà le cas dans EKD (voir la récente dépêche le concernant), et en projet/ébauche pour Delaboratory et Krita. Si vous pensez que certaines possibilités de G'MIC peut être utile dans votre logiciel, n'hésitez pas à me contacter !
  • Des slides de présentation (.pdf, en français) du projet ont été réalisés et présentés lors d'une demi-journée sur le logiciel libre ayant eu lieu au laboratoire GREYC. Ils donnent plus d'information sur la création et l'historique du projet.

Et après ?

G'MIC est un projet actif, et de nombreuses pistes peuvent être explorées par la suite.
J'espère qu'encore d'autres personnes rejoindront le projet, ou souhaiteront intégrer G'MIC dans leur propre logiciel. La version 1.5.1.2 est stable, et je ne peux que vous conseiller de l'installer / la mettre à jour si vous êtes un tant soit peu intéressé par le traitement ou la retouche d'images.
G'MIC est disponible pour Linux (paquets .deb, .rpm à venir), Mac et Windows.

  • # coeur ?

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

    Est-ce que le coeur de cimg a changé pour espérer un jour voir utiliser les instructions SIMD, ou le multi coeur (avec openmp), voir l'usage d'opencl ? La dernière que j'avais regardé, c'était pas trop imaginable.

    "La première sécurité est la liberté"

    • [^] # Re: coeur ?

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

      On essaye de se mettre tout doucement à OpenMP dans CImg pour multi-threader les opérations.
      Je ne suis pas trop spécialiste, mais c'est une solution pas trop intrusive qui a l'air prometteuse.

      • [^] # Re: coeur ?

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

        Il faut pour cela fournir des boucles qui garantissent qu'il n'y a pas de dépendance entre 20 itérations de la boucle. Ce n'est pas aussi simple que cela en à l'air.

        "La première sécurité est la liberté"

        • [^] # Re: coeur ?

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

          Sur une image c'est généralement possible de faire un calcul distribué pour différentes parties de l'image, c'est là dessus qu'on se base.

        • [^] # Re: coeur ?

          Posté par  . Évalué à 2.

          Ça dépend tu peut faire des réductions avec openmp par exemple :

          int res = 0;
for(int i = 0; i < 100; ++i) {
    res += methode_supra_lourde(i);
}

          Peut s'écrire :

          int res = 0;
#pragma omp parallel for reduction(+:res)
for(int i = 0; i < 100; ++i) {
    res += methode_supra_lourde(i);
}

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: coeur ?

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

            à part "plus" tu as d'autre manière de faire des réductions ?

            Dans un traitement d'image comme les exemples de cimg, tu as l'algorithme du painter : les objets au fond dessiné en premier, puis les objets au premier plan. Dans le cas d'une boucle omp for, l'ordre n'est plus respecté. Dans l'exemple des "triangles qui tournent" cela fait un effet de clignotement assez moche.

            "La première sécurité est la liberté"

            • [^] # Re: coeur ?

              Posté par  . Évalué à 1.

              Je ne dis pas le contraire. Juste que dans des cas de dépendances simples (l'ordre n'a pas d'importance et la réduction et une arithmétique simple), OpenMP peut encore être utile.

              Quand tu as de la synchronisation entre tes calculs, tu es à mon avis obligé de gérer toi même tes threads, je pense. Mais quand on peut faire les choses de manière simple autant éviter d'ajouter de la complexité.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: coeur ?

        Posté par  . Évalué à 1.

        C'est vrai que par expérience, OpenMP est facile à mettre en place. Par contre il est plus efficace de mettre ces instructions de parallélisation dans le programme fait par le programmeur plutôt que dans la librairie CImg, e.g. dans le cas boucles imbriquées. C'est même parfois contre-productif de paralléliser certaines fonctions…

  • # Magnifique

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

    C'est le genre de projet qui donne aux solutions libres un véritable aspect professionnel.

    C'est une très bonne chose que c'est filtres puissent intégrer plusieurs projets tels que Krita qui commence à être réputé.

  • # libgmic

    Posté par  . Évalué à 1.

    libgmic : Bibliothèque C++ permettant d'intégrer facilement à un programme les possibilités de l'interpréteur G'MIC

    C'est quoi la différence avec cimg?

    • [^] # Re: libgmic

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

      La libgmic contient l'implémentation de l'interpréteur G'MIC, qui lui même est basé sur CImg (mais aussi sur d'autres choses).

      • [^] # Re: libgmic

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

        Pourquoi ne pas avoir utilisé un langage de script connu pour G'MIC ? Je pense à lua qui est assez apprécié et facile à intégrer.

        "La première sécurité est la liberté"

        • [^] # Re: libgmic

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

          Note qu'un plug-in permettant de coder en LUA pour faire des traitements d'images en GIMP existe déjà : http://pippin.gimp.org/gluas/

          Le but de G'MIC, ce n'était pas de faire une bibliothèque de traitement d'images accessible depuis un langage de script. C'est plutôt d'essayer de définir un langage de script minimal et surtout concis pour faire des opérations sur les images (et pour ne faire que ça). C'est assez différent dans l'esprit.
          Je suis bien conscient que le résultat ne te plait pas trop (voir les précédents journaux sur G'MIC, où tu me poses souvent la même question), mais je le redis, ça n'a pas pour vocation d'être un langage généraliste tel que Python ou Lua. A la limite, on pourrait comparer ça au 'langage' utilisé dans 'sed'. Ca a une fonction bien précise, c'est pas forcément très clair, mais c'est concis et c'est prévu pour faire de la manipulation de données (d'images pour gmic, de texte pour sed).

          • [^] # Re: libgmic

            Posté par  (site web personnel) . Évalué à -6. Dernière modification le 19 avril 2012 à 14:54.

            Je trouve que c'est du gachi (doublé d'un syndrome NIH), c'est tout. Même dans un langage minimaliste comme gmic, tu as toujours des trucs de gestion comme les conditionnels, les boucles, l'extraction de paramètres externes, etc… Pourquoi encore réinventer la roue ? Cela m'agace car je trouve cimg très pratique.

            Je parie que lua supporte l'ajout d'accès à des fonctions externes, voir l'ajout d'un type opaque "image" qui aurait pu recevoir les appels au fonctions de cimg.

            sed est un bon exemple. "Des gens" ont créé perl pour se passer d'outils comme sed et awk. L'usage actuel de sed est une habitude pour exercer une expression régulière sur un fichier, bien qu'il puisse faire bien plus de choses (de façon totalement illisible). Cet usage de sed peut être remplacé par un one liner perl de la même façon.

            "La première sécurité est la liberté"

            • [^] # Re: libgmic

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

              Ce que est important in fine, c'est d'avoir le choix.

              Personne n'utilise des outils de la même façon. Pour remplacer une expression dans un fichier texte, je suis de ceux qui trouve que sed est très pratique (je ne me vois pas apprendre perl juste pour faire ça).
              De la même manière, quand je vois le plug-in Lua pour GIMP, je suis bien content de pas faire du lua pour traiter mes images. J'écris la même chose en une ligne alors qu'en lua, il en faut 20 (au moins sur l'exemple du screenshot de l'url que je t'ai donné).

              Je crois pas que ça soit du gachis d'avoir le choix.

              • [^] # Re: libgmic

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

                L'exemple est plus gros, car les opérations sont décrites complètement. J'imagine que G'MIC propose un tas de fonctions prédéfinis. Si c'était la même chose en Lua, cela prendrait aussi 1 ligne. Je parlais uniquement d'utiliser Lua pour faire le lien entre les objets cimg, pas de tout faire en lua.

                "La première sécurité est la liberté"

            • [^] # Re: libgmic

              Posté par  . Évalué à 3.

              sed est un bon exemple. "Des gens" ont créé perl pour se passer d'outils comme sed et awk. L'usage actuel de sed est une habitude pour exercer une expression régulière sur un fichier, bien qu'il puisse faire bien plus de choses (de façon totalement illisible). Cet usage de sed peut être remplacé par un one liner perl de la même façon.

              je te retourne l'argumentaire : pourquoi faire perl pour faire la même chose que awk ou sed ?

              par ce que tu en as soit besoin dans un autre cadre soit envie et que tu n'as peut-être pas la syntaxe qui te plaît dans le langage proposé.

              • [^] # Re: libgmic

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

                Parce que perl permet de faire bien plus de chose, plus facilement et plus proprement. Mais je suis d'accord que pour une personne connaissant déjà sed, il faut faire l'effort d'apprendre autre chose.

                "La première sécurité est la liberté"

  • # X11

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

    Il y a toujours la dépendance à la libX11 ?

    Sur les serveurs web et remplacer imagemagick (convert principalement), ne pas avoir cette dépendance serait un plus.

    • [^] # Re: X11

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

      On peut tout à fait enlever la dépendance à libX11, il suffit de compiler en commentant les lignes suivantes dans le Makefile : 

      X11_CFLAGS = -Dcimg_display=1 -Dcimg_appname=\\\"gmic\\\" -I/usr/X11R6/include #-Dcimg_use_xrandr
X11_LDFLAGS = -L/usr/X11R6/lib -lX11 -lpthread #-lXrandr

  • # Greykstoration

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

    Je me souviens avoir commencé à utiliser cet outil quand il était nommé ainsi.

    Il n'y avait pas encore d'interface graphique, des lignes de commandes à rallonge et une plombe pour chaque itération, mais Mâtin, quels résultats :)

Suivre le flux des commentaires

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