Journal [GIMP] G'MIC évolue et s'internationalise

Posté par  (site web personnel) .
Étiquettes :
14
13
mai
2009
Hello à tous,

Le greffon G'MIC pour GIMP continue son petit bonhomme de chemin, avec la version 1.3.1.5 qui est sortie, et qui comporte pas mal de nouveautés, ajoutées depuis mon dernier journal sur le sujet. Je détaille ici quelques unes de ces nouvelles fonctionnalités. Pour info, G'MIC est (entre autre) un greffon libre multi-plateforme pour GIMP qui propose un grand nombre de filtres (environ une centaine) pour traiter des images de manière diverse.

  • Le greffon a été "francisé", et plus généralement il est ouvert à tous nouveau langage. Pour le moment, c'est surtout l'interface principale qui est traduite. Les paramètres des filtres devraient être traduits par la suite. N'hésitez pas, si vous maîtrisez l'Allemand, l'Italien, l'Espagnol ou autre, à me contacter si vous voulez donner un petit coup de main. A priori, il y a très peu de travail à faire (au moins pour l'interface en elle-même, ce qui est une première étape).

  • Un parseur d'équation a été intégré dans G'MIC, ce qui lui permet de générer des images ou des déformations à partir de formules directement rentrées par l'utilisateur. Il n'y a que deux filtres disponibles actuellement dans le greffon qui utilise ce parseur, soit pour modifier les intensités des pixels, ou pour créer des déformations d'image personnalisées. Mais, on peut imaginer que cette fonctionnalité très utile va être davantage utilisée par la suite.

  • J'ai essayé également d'ajouter des filtres "utiles", ou au pire moins "jouet" (une des critiques de G'MIC qui a été formulé dans les commentaires de mon précédent journal). Ma démarche a été de faire un appel à suggestions sur le forum Flickr d'utilisateurs de GIMP, et les réponses n'ont pas manquées. Bien sûr, tout n'a pas été réalisable, mais des filtres intéressants ont pu êtres ajoutés à l'issu de ce petit sondage. En vrac, on peut citer un mixeur de couleurs en base YCbCr ou HSV, un convertisseur Noir & Blanc (avec pas mal de possibilités de réglages, notamment pour l'ajout de grain), de nombreux modes additionnels de fusion de calques (qui ne sont pas disponibles dans GIMP), un mode original de fusion qui permet de préserver les détails contrastés de tous les calques dans l'image fusionnée finale (pratique pour faire du Stack-Focus par exemple). J'ai aussi mis un filtre de recalage de calques, qui tente de recaler de manière rigide ou non-rigide les contenus des images, en utilisant un algorithme d'estimation de champs de déplacement. Cet algorithme permet également de faire du morphing automatique de calques.

  • Un mode "Inpainting" a fait son apparition. C'est l'équivalent de l'algorithme de reconstruction de régions par EDP de (feu) GREYCstoration, qui permet d'enlever ou de reconstruire des zones de l'image définis par l'utilisateur (ici, défini dans un calque à part). Ca ne fait pas de miracles, mais lorsque les masques sont petits et que l'image n'est pas trop texturée, ca peut marcher pas trop mal (voir la page de démo de GREYCstoration, section Inpainting). Il y a aussi de nouveaux filtres de lissage préservant les structures, des nouveaux filtres artistiques (kaleidoscope, etc...), et l'amélioration de nombreux autres filtres qui existaient déjà. Vous pouvez aller sur ce lien, pour voir une galerie de copies d'écrans du greffon G'MIC en action.

Voilà pour les nouveautés, je finis avec quelques liens utiles pour se donner une idée de l'utilisation du greffon pour GIMP :


A noter que le greffon G'MIC fait tous ses calculs internes en utilisant des valeurs flottantes, donc devrait pouvoir passer le cap de l'arrivée du 16 bits/canal de manière assez lisse (même si du coup, ca demande parfois beaucoup de mémoire), qui arrivera un jour ou l'autre dans GIMP.

N'hésitez pas à tester. Je suis à la recherche de belles images "utilement" traitées grâce à G'MIC pour illustrer le site web.

A+.

  • # Super boulôt

    Posté par  . Évalué à 10.

    Je suis très loin d'avoir les compétences ou le talent nécessaire pour exploiter tout ça, ou contribuer, sauf peut être les filtres les plus travaillés, mais je tiens quand même à te féliciter pour ton boulot, et surtout l'écoute de tes utilisateurs et l'esprit d'ouverture de ce projet.

    Bravo, et je souhaite plein de contributions et plein d'utilisateurs, et pleins de bonnes idées à ce projet :)

    (oui, c'est complètement mielleux comme commentaire, je sais qu'on est sur trollfr, mais c'est vraiment parce que j'ai rien trouvé à critiquer)

  • # Version Catalane

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

    La traduction en Catalan a été ajoutée ce soir, et devrait être disponible dès maintenant.

  • # Impressionnant !

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

    Il faut maintenant que je trouve le temps de regarder tout ça :)

    Et niveau perf, cela se passe comment ? La concurrence utilise le vectoriel depuis longtemps, ils sont entrain de passer au GPU.

    J'imagine qu'avec un pixel sous format float (rgb ?) il devrait être possible d'utiliser du SSE. Je vais voir pour tester avec l'autovectoriser de gcc :) Je pense qu'il doit être très difficile de changer la structure de base d'une image vu la structure à plat des class de cimg.

    D'ailleurs, les images sont traiter en RGB ? Souvent, je vois que le HSV fournis de meilleurs effets. Le CIEla*b est théoriquement meilleur mais propose des calculs super lourd et pas franchement justifié. C'est possible de dire d'utiliser un espace colorimétrique plutôt qu'un autre ?

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

    • [^] # Re: Impressionnant !

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

      Niveau perf, a priori tout est fait par le CPU pour le moment. Je laisse le soin au compilateur d'optimiser tout ça avec le GPU si il en est capable (oui, ca devrait être le travail du compilo, enfin à terme c'est surement ce qui va se passer....)
      GIMP fournit des données images en mode RGB donc par défaut, c'est le mode RGB qui est utilisé. Par contre, comme G'MIC possède des routines de conversion d'espaces couleurs, il est possible de proposer ponctuellement pour des filtres particuliers de travailler dans un autre espace (ce qui est fait d'ailleurs pour certains filtres notamment traitant la couleur).
      A mon avis ca doit être fait de manière ponctuelle, car certains filtres (notamment de déformations géométriques) n'ont aucun intérêt à faire leur calcul en autre chose que RGB.

      • [^] # Re: Impressionnant !

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

        Je sais que tu aimes bien ton design à plat, mais est-ce qu'il ne serait pas souhaitable d'avoir une classe de base de gestion d'un tableau ayant des opérateurs de base réutilisé ensuite par tous les différents traitements ?

        J'avais tenté à une époque un changement d'organisation mémoire des tableaux, mais le layout même, était réparti partout. Mon but était de tenter du "tiling". Les lignes caches font de 32 à 128 octets, soit de 8 à 32 valeurs flottantes. Avec un bête tableau en C, les lignes de caches sont reparti sur les lignes de l'image. Or la plus part des traitements fonctionnent par "proximité", y compris dans la dimension vertical. Je voulais tenter de repartir un peu plus les lignes de caches, sur 2 cases verticales au lieu d'une. Je voulais aussi tenter de faire la même chose mais au niveau de cache L1, en groupant une image par bloc de 16Ko, la moitié d'un cache L1.

        Si on a une classe tableau avec des fonctions itératives de bases, il peut être facile ensuite de transformer le code pour le faire utiliser du code vectoriel. J'imagine que la suite logique est d'utiliser le gpu qui ne sait basiquement faire qu'un MAC sans dépendance mais 10x plus vite que le cpu.

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

  • # ya pas à dire...

    Posté par  . Évalué à -2.

    Qu'est-ce que c'est moche Gnome !!

Suivre le flux des commentaires

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