G’MIC 2.3.4 : traiter ses images, en se disant « déjà 10 ans ! »

Posté par (page perso) . Édité par Davy Defaud, Benoît Sibaud et Xavier Teyssier. Modéré par Xavier Teyssier. Licence CC by-sa.
122
21
août
2018
Graphisme/photo

L’équipe IMAGE du GREYC est heureuse de pouvoir fêter avec vous les dix années d’existence du logiciel G’MIC, son cadriciel libre (sous licence CeCILL), générique et extensible pour le traitement des images.
Le GREYC est un laboratoire de recherche publique en sciences du Numérique, situé à Caen en Normandie, et chapeauté par trois tutelles : le CNRS (UMR 6072), l’Université de Caen et l’ENSICAEN.

G’MIC-Qt
  G’MIC-Qt, l’interface utilisateur principale du projet libre G’MIC.

Cet anniversaire décennal nous donne l’occasion rêvée, d’une part, d’annoncer la sortie d’une nouvelle version de ce logiciel libre (numérotée 2.3.4), et d’autre part, de partager avec vous (comme à notre habitude) un résumé des dernières fonctionnalités notables ajoutées depuis la dernière dépêche sur G’MIC, publiée sur LinuxFr.org en février 2018.

Sommaire

N. D. A. : Cliquez sur les images de la dépêche pour en visualiser des versions à meilleure résolution.

1. Retour sur dix années de développement

G’MIC est un logiciel multi‐plate‐forme (GNU/Linux, macOS, Windows…) fournissant différentes interfaces utilisateur pour la manipulation de données image génériques, à savoir des images ou des séquences d’images hyperspectrales 2D ou 3D à valeurs flottantes (incluant donc les images couleur « classiques »). Plus de mille opérateurs différents de traitement d’images sont inclus, nombre extensible à l’envi puisque les utilisateurs peuvent ajouter leurs propres fonctionnalités via l’utilisation d’un langage de script intégré.

C’est fin juillet 2008, que les premières lignes de G’MIC sont rédigées (en C++).
À l’époque, j’étais le principal développeur impliqué dans CImg, une bibliothèque C++ open source légère pour le traitement d’images, et je réalisais le constat suivant :

  • l’objectif initial de CImg, qui était de proposer une bibliothèque « minimale » de fonctionnalités pour aider les développeurs C++ à élaborer des algorithmes autour du traitement d’images, était globalement atteint :
    • la plupart des algorithmes que je considérais comme « essentiels » en traitement d’images y étaient intégrés,
    • CImg était initialement conçue pour rester légère, et je ne souhaitais donc pas y inclure ad vitam æternam de nouveaux algorithmes, qui seraient trop lourds ou trop spécifiques et qui trahiraient le concept initial de la bibliothèque ;
  • cette satisfaction faisait néanmoins place à une certaine déception ; quel dommage de n’avoir pu toucher qu’un public finalement assez restreint, possédant à la fois des connaissances en C++ et en traitement d’images ! Une des évolutions naturelles du projet, consistant à créer des bibliothèques de liaison (bindings) de CImg pour d’autres langages de programmation, ne m’ouvrait pas de perspectives très réjouissantes, du point de vue de l’intérêt que j’y trouvais en développement informatique ; sans compter que ces bindings potentiels ne concernerait, là encore, qu’un public ayant une expertise en développement.

Mon envie prenait donc progressivement forme : il fallait proposer un moyen d’utiliser les fonctionnalités de traitement d’images de CImg pour les non‐programmeurs. Et pourquoi pas, dans un premier temps, en élaborant un outil utilisable en ligne de commande (à la façon du fameux convert d’ImageMagick) ? Une première tentative, en juin 2008 (inrcast, qui avait été présentée dans un journal LinuxFr), se révéla infructueuse mais me permit de mieux cerner les spécificités que se devait de posséder ce genre d’outils, pour traiter confortablement des images en ligne de commande.
Il m’apparut en particulier que la concision et la cohérence de la syntaxe commandant l’outil devaient être les deux piliers principaux sur lesquels il fallait se reposer. Ces aspects sont ceux qui m’ont demandé le plus d’efforts en recherche et développement (les fonctionnalités de traitement d’images proprement dites étant déjà implémentées dans CImg). En fin de compte, cela m’amènera bien plus loin que ce qui était prévu initialement, puisque G’MIC se dotera successivement d’un interpréteur de son propre langage de script, puis d’un compilateur à la volée (JIT) pour l’évaluation d’expressions mathématiques et d’algorithmes de traitement d’images travaillant au niveau pixel.

Fin juillet 2008, je me mettais donc au travail avec les idées (presque) claires, et étais heureux d’annoncer ici même, quelques jours plus tard, la sortie d’une première ébauche de G’MIC. Le projet était officiellement en marche !

Logo G’MIC  Fig. 1.1 : Logo du projet G’MIC, cadriciel libre pour le traitement d’images, et sa mignonne petite mascotte « Gmicky » (illustrée par David Revoy).

Quelques mois plus tard, en janvier 2009, enrichi par mon expérience précédente de développement du logiciel GREYCstoration (outil libre pour le débruitage et l’interpolation non linéaire d’images, dont un greffon existait pour GIMP), et dans l’espoir de toucher un public encore plus large, je diffusais une version de G’MIC se déclinant sous forme d’un greffon GTK pour GIMP.
Cette étape s’est avérée déterminante pour le projet G’MIC, le faisant passer de hautement confidentiel à doucement populaire :), comme l’illustre le saut significatif visible dans les statistiques de téléchargements mensuels de l’époque, présentées ci‐dessous (le projet était alors hébergé sur Sourceforge).

Statistiques téléchargements  Fig. 1.2 : Statistiques de téléchargement mensuels de G’MIC, entre juillet 2008 et mai 2009 (arrivée du greffon pour GIMP en janvier 2009).

Cet intérêt soudain pour le greffon de la part d’utilisateurs différents de GIMP (photographes, illustrateurs et autres artistes en tout genre…) fut en effet une vraie rampe de lancement pour le projet, avec l’apparition rapide de contributions et suggestions extérieures diverses et variées (pour le code, la gestion des forums, des pages Web, l’écriture de tutoriels, la réalisation de vidéos…). L’effet communautaire bénéfique du logiciel libre, souvent idéalisé, survenait finalement assez rapidement ! Avec aussi pour conséquence d’amener certains utilisateurs‐développeurs à s’intéresser plus en détails au fonctionnement de l’interface originelle en ligne de commande et à son langage de script associé (qui n’intéressait pas grand monde jusque‐là, il faut bien l’avouer !). De là, plusieurs d’entre eux franchirent le pas et commencèrent à élaborer et implémenter de nouveaux filtres de traitement d’images en langage G’MIC, intégrés progressivement au greffon pour GIMP (aujourd’hui, ces contributions représentent quasiment la moitié des filtres disponibles dans le greffon).

En parallèle, les apports importants et répétés de Sébastien Fourey, collègue de l'équipe IMAGE du GREYC (et développeur C++ chevronné s'il en est) ont permis d'améliorer significativement le confort d'utilisation de G'MIC. Sébastien est en effet à l'origine du développement des interfaces graphiques principales du projet, à savoir :

  • le service Web G’MIC Online (qui a plus tard été réorganisé par le service « développement » du GREYC) ;
  • Le logiciel libre ZArt, une interface graphique, basé sur la bibliothèque Qt, pour l’application de filtres G’MIC sur des séquences vidéos (provenant de fichiers ou de flux de caméras numériques) ;
  • et surtout, Sébastien s’est attaqué, fin 2016, à la réécriture complète du greffon G’MIC pour  GIMP sous une forme plus générique, dénommée G’MIC-Qt ; ce composant, basé également sur la bibliothèque Qt (comme son nom l’indique), se présente sous la forme d’un greffon unique qui fonctionne de manière équivalente sous GIMP et Krita, deux des logiciels libres de référence pour la retouche photographique et la peinture numérique. G’MIC-Qt a aujourd’hui complètement supplanté le greffon GTK d’origine grâce à ses nombreuses fonctionnalités : moteur de recherche de filtres intégré, meilleure prévisualisation, interactivité supérieure, etc. C’est aujourd’hui l’interface la plus aboutie et la plus utilisée du projet G’MIC, et nous espérons d’ailleurs pouvoir la décliner dans le futur pour d’autres logiciels hôtes (contactez‐nous si vous êtes intéressés par ce sujet !).

Interfaces graphiques de G’MIC  Fig. 1.3 : Différentes interfaces graphiques du projet G’MIC, développées par Sébastien Fourey : G’MIC-Qt, G’MIC Online et ZArt.

L’idée de cette dépêche n’étant pas de rentrer trop en détails dans l’historique du projet, affirmons simplement que l’on n’a pas vraiment eu le temps de s’ennuyer ces dix dernières années !
Aujourd’hui, Sébastien et moi‐même sommes les deux mainteneurs principaux du projet G’MIC (Sébastien, majoritairement pour ce qui concerne les aspects « interface », et moi‐même pour le développement et l’amélioration des filtres et du cœur de calcul), ceci, en complément de notre activité professionnelle principale (la recherche, l’enseignement et l’encadrement).

Avouons‐le, gérer un projet libre comme G’MIC prend un temps considérable, malgré sa taille modeste (≈ 120 000 lignes de code). Mais l’objectif de départ a été atteint : des milliers d’utilisateurs non‐programmeurs ont l’occasion d’utiliser librement et aisément nos algorithmes de traitement d’images, et ce, dans de nombreux domaines différents : retouche photographique, illustration et peinture numérique, traitement vidéo, illustration scientifique, génération procédurale, glitch art… La barre des 3,5 millions de téléchargements totaux a été dépassée l’an dernier, avec une moyenne actuelle d’environ 400 téléchargements journaliers effectués depuis le site officiel (chiffres en baisse constante depuis quelques années car G’MIC est de plus en plus téléchargé et installé via des sources alternatives extérieures).
Il est parfois difficile de garder un rythme soutenu de développement et la motivation qui doit aller avec, mais on s’accroche, en repensant aux utilisateurs heureux qui partagent de temps à autre leur enthousiasme pour ce projet !

On ne peut évidemment pas nommer tous les particuliers, contributeurs à G’MIC, que l’on souhaiterait remercier, et avec qui on s’est régalé à échanger durant ces dix années, mais le cœur y est ! Remercions également le laboratoire GREYC et l’institut INS2I du CNRS qui affichent un fort soutien à ce projet libre. Un grand merci également à l’équipe de LinuxFr.org qui n’a pas rechigné à relire et publier nos propositions régulières de dépêches sur G’MIC ;).

Mais cessons de ressasser de vieux souvenirs et passons maintenant aux choses sérieuses : les nouveautés apparues depuis la dernière version majeure 2.2 !

2. Illumination automatique de dessins colorisés en aplats

G’MIC s’est récemment doté d’un filtre assez étonnant, nommé « Illuminate 2D shape », dont l’objectif est d’ajouter automatiquement des zones d’illumination et des ombres propres sur des dessins 2D colorisés en aplats, pour leur donner un aspect 3D.

Dans un premier temps, l’utilisateur fournit un objet à illuminer, sous la forme d’une image sur fond transparent (typiquement un dessin de personnage, ou d’animal). En analysant la forme et le contenu de l’image, G’MIC tente alors d’en déduire une carte d’élévations 3D concordante (« bumpmap »). La carte d’élévations obtenue est évidemment non exacte, puisqu’un dessin 2D colorisé en aplats ne contient pas d’informations franchement explicites sur sa structure 3D associée ! À partir des élévations 3D estimées, il est aisé d’en déduire une carte de normales (« normalmap ») qui est utilisée dans un second temps pour générer un calque d’illumination associé au dessin (suivant un modèle d’ombrage de Phong).

Illuminate 2D shape  Fig. 2.1 : Le filtre « Illuminate 2D shape » de G’MIC en action, pour ombrer un dessin de scarabée (résultat d’ombrage à droite).

Ce nouveau filtre est très flexible et permet à l’utilisateur d’avoir un contrôle assez fin sur les paramètres d’éclairage (position et type de rendu de la source lumineuse), et d’estimation des élévations 3D. Par ailleurs, le filtre laisse à l’artiste le loisir de retravailler le calque d’illumination généré, ou même directement les cartes d’élévations et de normales 3D estimées. La figure ci‐dessous illustre le processus dans son ensemble : à partir de l’image de scarabée colorisé en aplats (en haut à gauche), le filtre estime de manière complètement automatique une carte de normales 3D associée (en haut à droite), ce qui lui permet de générer des rendus d’illumination du dessin (ligne du bas, avec deux styles de rendus différents : lisse et quantifié).

Estimation d’une carte de normales  Fig. 2.2 : Le fonctionnement du filtre « Illuminate 2D shape » de G’MIC passe par l’estimation d’une carte de normales 3D pour générer l’illumination automatique d’un dessin.

Malgré la difficulté inhérente au problème de conversion d’une image 2D en informations d’élévations 3D, l’algorithme utilisé s’avère étonnamment efficace dans pas mal de cas, l’estimation de la carte d’élévations 3D obtenue étant suffisamment cohérente pour générer automatiquement des illuminations de dessins 2D plausibles, comme illustré par les deux exemples ci-dessous, obtenus en quelques clics seulement !

Exemple d’illumination 1
Exemple d’illumination 2   Fig. 2.3 : Deux exemples d’illuminations complètement automatiques de dessins 2D, générés par G’MIC.

Il arrive, bien sûr, que la carte d’élévations 3D estimée ne corresponde pas tout à fait à ce que l’on pourrait souhaiter. Qu’à cela ne tienne, le filtre permet à l’utilisateur de fournir des « guides », sous la forme d’un calque additionnel composé de traits colorés, donnant des informations plus précises à l’algorithme sur la structure du dessin à analyser. La figure ci‐dessous illustre l’utilité de ces guides pour un exemple d’illumination d’un dessin d’une main (en haut à gauche) : l’illumination obtenue de manière complètement automatique (en haut à droite) ne prend pas en compte les informations de lignes de la main. Inclure ces quelques lignes dans un calque additionnel de « guides » (en rouge, en bas à gauche) permet d’aider l’algorithme à illuminer le dessin de manière plus satisfaisante.

Utilisation de  guides  Fig. 2.4 : Utilisation d’un calque de « guides » pour améliorer le rendu d’illumination automatique généré par G’MIC.

Si l’on analyse plus précisément les différences obtenues entre les cartes d’élévations 3D estimées avec et sans « guides » (illustrées ci‐dessous sous forme d’objets 3D symétrisés), il n’y a pas photo : on passe d’une grosse moufle boudinée à une estimation 3D de main nettement plus détaillée !

Élévations avec et sans guides  Fig. 2.5 : Élévations 3D estimées pour le dessin précédent de la main, avec et sans utilisation de « guides ».

Notons pour finir que ce filtre dispose également d’un mode de prévisualisation interactif, permettant à l’utilisateur de faire bouger la source lumineuse (à la souris) et d’avoir un aperçu du dessin illuminé en temps réel. En modifiant les paramètres de position de la source lumineuse, il est ainsi possible d’obtenir le type d’animations ci‐dessous en très peu de temps, qui donne une idée assez précise de la structure 3D estimée par l’algorithme à partir du dessin d’origine.
Animation lumière  Fig. 2.6 : Modification de la position de la source lumineuse et rendus d’illumination associés, calculés de manière automatique par G’MIC.

Une vidéo montrant les différentes possibilités d’édition de l’illumination permises par ce filtre est visible sur YouTube. Espérons que cette nouvelle fonctionnalité de G’MIC permette aux artistes d’accélérer l’étape d’illumination et d’ombrage de leurs futurs dessins !

3. Projection stéréographique

Dans un tout autre genre, nous avons également ajouté à G’MIC un filtre implémentant la projection stéréographique, très précisément nommé « Stereographic projection ». Ce type de projection cartographique permet de projeter des données images définies sur une sphère, sur un plan. Il faut savoir que c’est la projection usuelle utilisée pour générer des images de « mini‐planètes » à partir de panoramas équirectangulaires, comme celui illustré sur la figure ci‐dessous.

Panorama équirectangulaire  Fig. 3.1 : Exemple de panorama équirectangulaire (réalisé par Alexandre Duret‐Lutz).

Si, sur ce panorama, on lance le greffon G’MIC et que l’on sélectionne le filtre « Stereographic projection », on obtient :
Filtre « Stereographic projection »  Fig. 3.2 : Le filtre « Stereographic projection » de G’MIC en action dans le greffon pour GIMP ou Krita.

Le filtre permet des réglages précis du centre de projection, de l’angle de rotation et du rayon de la sphère considérée, tout ça de manière interactive directement sur la fenêtre de prévisualisation (nous y reviendrons par la suite). En quelques clics, et après application du filtre, nous obtenons la « mini‐planète » désirée :

Mini‐planète  Fig. 3.3 : « Mini‐planète » obtenue après projection stéréographique.

Il est d’ailleurs cocasse de constater qu’en inversant simplement l’axe vertical des images, on transforme une « mini‐planète » en un « maxi‐tunnel » !

Maxi‐tunnel  Fig. 3.4 : « Maxi‐tunnel » obtenu par inversion de l’axe vertical puis projection stéréographique.

Là encore, nous avons réalisé cette petite vidéo qui montre ce filtre en conditions réelles d’utilisation. À noter que G’MIC possédait déjà un filtre similaire (dénommé « Sphere »), qui pouvait être utilisé pour la création de « mini‐planètes », mais avec un type de projection moins bien adapté que la projection stéréographique, qu’il est maintenant possible d’utiliser.

4. Toujours plus de possibilités pour la manipulation des couleurs

Triturer les couleurs des images est une occupation récurrente chez les photographes et les illustrateurs, et G’MIC possèdait déjà plusieurs dizaines de filtres destinés à cette unique activité, regroupés dans une catégorie dédiée (à savoir « Colors/ », pour faire original !). Cette catégorie s’étoffe encore, avec deux nouveaux filtres fraîchement apparus.

4.1. Le filtre « CLUT from after‐before layers »

Le filtre « **CLUT from after‐before layers_ » cherche à modéliser la transformation colorimétrique qui a été effectuée entre deux images (que l’on possède). Supposons par exemple que nous ayons la paire d’images suivante :
Paire d’images  Fig. 4.1 : Paire d’images où une transformation colorimétrique inconnue a été appliquée sur l’image du haut, pour obtenir celle du bas.

Problème : On ne se rappelle plus du tout comment on a fait pour passer de l’image originale à l’image modifiée, mais on voudrait absolument ré‐appliquer le même processus sur une autre image. Eh bien, plus de soucis, appelons G’MIC à la rescousse ! Le filtre en question va chercher à modéliser au mieux la modification des couleurs sous la forme d’une HaldCLUT, qui se trouve être une façon classique de représenter une transformation colorimétrique quelconque.

Filtre « CLUT from after‐before layers »  Fig. 4.2 : Le filtre modélise la transformation colorimétrique entre deux images sous forme d’une HaldCLUT.

La HaldCLUT générée par le filtre va pouvoir être sauvée et ré‐appliquée sur d’autres images, avec la propriété désirée que l’application de cette HaldCLUT sur l’image originale redonne bien l’image modèle cible dont on s’est servi pour que le filtre apprenne la transformation couleur produite.
À partir de là, nous sommes capables d’appliquer une modification de couleurs équivalente, sur n’importe quelle autre image :
HaldCLUT ré‐appliquée sur une autre image  Fig. 4.3 : La transformation colorimétrique estimée sous forme de HaldCLUT est ré‐appliquée sur une autre image.

Ce filtre permet donc in fine de créer des HaldCLUT « par l’exemple », et pourrait donc intéresser de nombreux photographes (notamment ceux qui diffusent des compilations de fichiers HaldCLUT, librement ou non !).

4.2. Filtre « Mixer [PCA] »

Un deuxième filtre de manipulation de couleurs, nommé « Mixer [PCA] » a été aussi récemment intégré à G’MIC. Il agit comme un classique mixeur de canaux couleurs, mais plutôt que de travailler dans un espace couleur prédéfini (comme sRGB, HSV, Lab…), il agit sur l’espace couleur « naturel » de l’image d’entrée, obtenue par analyse en composante principale (ACP) de ses couleurs RVB. Ainsi à chaque image sera associé un espace couleur différent.
Par exemple, si nous prenons l’image « lion » ci‐dessous, et que l’on regarde la distribution de ses couleurs dans le cube RVB (image de droite), on s’aperçoit que l’axe principal de variation des couleurs est défini par une droite allant du orange foncé au beige clair (axe symbolisé par la flèche rouge sur la figure).

gmic_mix_pca2  Fig. 4.4 : Distribution des couleurs de l’image « lion » dans le cube RVB, et axes principaux associés (colorisés en rouge, vert et bleu).

L’axe de variation secondaire quant à lui (flèche verte) va du bleu jusqu’à l’orange, et l’axe tertiaire (flèche bleue) du vert au rose. Ce sont ces axes de variations (plutôt que les axes RVB) qui vont donc définir la base de couleurs utilisée dans ce filtre de mixage de canaux.

Filtre « Mixer [PCA] »  Fig. 4.5 : Le filtre « Mixer [PCA] » est un mixeur de canaux agissant sur les axes de variations de couleurs « naturels » de l’image.

Il serait malhonnête d’affirmer qu’il soit toujours meilleur de considérer la base couleur obtenue par ACP pour le mixage des canaux, et ce nouveau filtre n’a évidemment pas vocation à être le mixeur « ultime » qui remplacerait tous les autres. Il a simplement le mérite d’exister et de proposer une alternative aux outils usuels de mixage de canaux couleur, alternative dont les résultats se sont avérés effectivement intéressants sur plusieurs images de tests utilisées lors du développement de ce filtre. Cela ne coûte rien d’essayer en tout cas…

5. Méli‐mélo de filtres

Cette section présente pêle‐mêle quelques autres nouveaux filtres et améliorations diverses qui ont été intégrés récemment à G’MIC et qui méritent qu’on les mentionne, sans s’y attarder outre mesure.

5.1. Le filtre « Local processing »

Ce filtre permet d’appliquer un processus de normalisation ou d’égalisation de couleurs sur des voisinages locaux d’image (avec éventuellement du recouvrement entre voisinages). C’est un filtre supplémentaire permettant de faire ressortir des détails dans des photographies initialement surexposées ou sous‐exposées, mais qui peut parfois créer des « halos » disgracieux.

Filtre « Local processing »  Fig. 5.1 : Le filtre « Local processing » permet de rehausser les détails dans des photographies sur ou sous‐exposées.

5.2. Le filtre « Blend [standard] »

Vous trouvez que vous n’avez pas assez de modes de fusion de calques à votre disposition dans GIMP ou Krita ? Vous rêvez de pouvoir définir votre propre formule de fusion ? Alors le filtre « Blend [standard] » est fait pour vous ! Ce filtre, déjà existant auparavant, s’enrichit de la fonctionnalité « Custom formula » qui permet à l’utilisateur de spécifier sa propre formule mathématique de fusion de calques. Toutes les fantaisies deviennent possibles !

Filtre « Blend (standard) »  Fig. 5.2 : Le filtre « Blend [standard] » permet maintenant de définir ses propres formules mathématiques de fusion de calques.

5.3. Le filtre « Sketch »

Signalons aussi la ré‐implémentation complète du sympathique filtre « Sketch », qui existait depuis plusieurs années, mais qui pouvait s’avérer un peu lent sur de grosses images. La nouvelle implémentation est beaucoup plus rapide, tirant notamment parti du calcul multicœur quand c’est possible.

Filtre » Sketch »  Fig. 5.3 : Le filtre « Sketch » a été réimplémenté et exploite maintenant tous les cœurs de calcul disponibles.

5.4. Le filtre « Mandelbrot - Julia sets »

Un gros travail de ré‐implémentation a été également réalisé sur le filtre « Mandelbrot - Julia sets », puisque l’interface de navigation a été entièrement repensée, rendant l’exploration de l’ensemble de Mandelbrot bien plus confortable (comme l’illustre cettevidéo). De nouvelle options pour le choix des couleurs sont également apparues.

Filtre « Mandelbrot - Julia sets »  Fig. 5.4 : Le filtre « Mandelbrot - Julia sets » et sa nouvelle interface de navigation dans l’espace complexe.

5.5. Le filtre « Polygonize [Delaunay] »

Le filtre « Polygonize [Delaunay] » qui génère des rendus polygonisées d’images couleurs se dote d’un nouveau mode de rendu, utilisant des couleurs interpolées linéairement dans les triangles de Delaunay produits.

Filtre « Polygonize (Delaunay) »  Fig. 5.5 : Les différents modes de rendu du filtre « Polygonize [Delaunay] ».

6. Autres faits marquants du projet

6.1. Améliorations de l’interface du greffon

Bien sûr, les nouveautés dans G’MIC ne concernent pas seulement les filtres de traitement d’images proprement dits ! Un travail considérable a été par exemple réalisé sur l’interface graphique du greffon G’MIC-Qt.

Les filtres du greffon ont désormais la possibilité de spécifier un nouveau type de paramètre point(), qui se matérialise sous la forme d’un petit disque coloré que l’on peut manipuler directement à la souris au‐dessus de la fenêtre de prévisualisation. En pratique, cela permet de rendre cette fenêtre de prévisualisation interactive, et ce n’est pas rien ! De nombreux filtres utilisent maintenant cette capacité, ce qui les rend beaucoup plus agréables et intuitifs à utiliser (voir cette vidéo pour quelques exemples). L’animation ci‐dessous montre par exemple comment ces points interactifs sont utilisés dans le nouveau filtre « Stereographic projection », que nous avons décrit précédemment.

Fenêtre de prévisualisation interactive  Fig. 6.1 : La fenêtre de prévisualisation du greffon G’MIC-Qt s’enrichit de nouvelles possibilités d’interactions pour l’utilisateur.

L’introduction de cette fonctionnalité a de ce fait permis d’améliorer les modes de division de prévisualisation (« split preview »), utilisés par un grand nombre de filtres pour afficher côte à côte les images « avant / après » lors de la prévisualisation d’un filtre dans le greffon. Il est maintenant possible de déplacer la zone frontière des images « avant / après », comme illustré par l’animation ci‐dessous. Deux nouveaux modes de division, en damier, ont d’ailleurs été ajoutés à cette occasion.

Division de prévisualisation interactive  Fig. 6.2 : Les modes de division de la prévisualisation possèdent maintenant une frontière « avant / après » déplaçable.

Plein d’autres petites améliorations ont été faites dans le code du greffon : une prise en charge du dernier GIMP 2.10, de la version Qt 5.11, une meilleure gestion des messages d’erreurs s’affichant dans la fenêtre de prévisualisation, un design général plus épuré, et tout un tas de petites choses par forcément visibles mais participant néanmoins au confort de l’utilisateur (un système de cache d’images pour la fenêtre de prévisualisation par exemple). Bref, que du bon !

6.2. Perfectionnement du cœur du logiciel

De nouvelles améliorations ont également été apportées dans les couches internes de G’MIC.

La « bibliothèque standard » du langage de script G’MIC évolue, avec l’apparition de nouvelles commandes pour le calcul des fonctions hyperboliques inverses (acosh, asinh et atanh), ainsi que de la commande tsp (travelling salesman problem) qui estime une solution « acceptable » au problème bien connu du voyageur de commerce, et ceci pour un nuage de points de dimension et de taille quelconque.

Voyageur de commerce en 2D  Fig. 6.3 : Estimation du circuit le plus court entre plusieurs centaines de points 2D, par la commande tsp de G’MIC.

Voyageur de commerce en 3D  Fig. 6.4 : Estimation du circuit le plus court entre plusieurs couleurs du cube RVB (en 3D donc), grâce à la commande tsp de G’MIC.

L’interface de démonstration, qui se lance lorsque l’on invoque gmic sans arguments à partir de la ligne de commande, a également été refaite en repartant de zéro.
Interface de démonstration  Fig. 6.5 : La nouvelle interface de démonstration de gmic, l’outil en ligne de commande de G’MIC.

Le compilateur JIT d’expressions mathématiques intégré n’est pas non plus en reste et s’enrichit de nouvelles fonctions permettant de tracer des polygones (fonction polygon()) ou des ellipses (fonction ellipse()) dans des images. Ces expressions mathématiques peuvent en réalité définir de véritables petits programmes (possédant des variables locales, des fonctions utilisateur et des structures de contrôle). On peut ainsi générer des images synthétiques facilement, avec de simples lignes de commande, comme le montrent les deux exemples ci‐dessous.

$ gmic 400,400,1,3 eval "for (k = 0, k<300, ++k, polygon(3,u([vector10(0),[w,h,w,h,w,h,0.5,255,255,255])))"

Résultat :
Fonction « polygon() »  Fig. 6.6 : Utilisation de la nouvelle fonction polygon() du compilateur à la volée de G’MIC, pour générer une image synthétique aléatoire.

$ gmic 400,400,1,3 eval "for (k=0, k<20, ++k, ellipse(w/2,h/2,w/2,w/8,k*360/20,0.1,255))"

Résultat :
Fonction « ellipse() »  Fig. 6.7 : Utilisation de la nouvelle fonction ellipse() du compilateur à la volée de G’MIC, pour générer une image synthétique florale.

Notons également une meilleure gestion des valeurs NaN lors des calculs réalisés par le cœur du logiciel, ce qui permet à G’MIC d’avoir un comportement cohérent même lorsqu’on le compile avec l’optimisation -ffast-math. Ainsi, G’MIC est maintenant compilable sans soucis avec le niveau d’optimisation maximal -Ofast du compilateur g++, alors que nous étions restreints dans le passé à utiliser « seulement » -O3. L’amélioration en vitesse de calcul se fait clairement ressentir pour certains filtres !

6.3. Supports de diffusion

Pas mal de changements ont aussi eu lieu sur les supports de diffusion utilisés par le projet.

Tout d’abord, les pages Web du projet (qui en passant utilisent maintenant des connexions sécurisées HTTPS par défaut) s’enrichissent d’une nouvelle galerie d’images. Cette galerie montre à la fois des résultats d’application de différents opérateurs de traitement d’images disponibles dans G’MIC, mais aussi la façon de les reproduire (à partir de la ligne de commande). Notons d’ailleurs que ces pages de galerie sont générées automatiquement par un script G’MIC dédié à cette tâche, ce qui nous assure que la syntaxe donnée pour chaque exemple est exacte.

Galerie d’images  Fig. 6.8 : La nouvelle page de galerie d’images du site Web de G‘MIC.

Cette galerie est découpée en plusieurs sections, suivant le type de traitements effectué (Artistique, Noir & blanc, Déformation, Filtrage, etc.). La dernière section « Code sample  » est personnellement celle que je trouve la plus amusante, puisqu’elle présente de petites séquences d’images (sous forme de GIF animés qui bouclent) entièrement générées par des scripts courts en langage G’MIC. Une façon un tout petit peu exotique d’utiliser G’MIC, mais qui montre son potentiel pour l’art génératif.

Code sample1 Code sample2
Exemple 1  Exemple 2

Fig. 6.9 : Deux exemples d’animations GIF générées par des scripts en langage G’MIC, visibles dans la galerie d’images.

Et puis, nous avons déménagé le dépôt source git principal du projet vers Framagit, en gardant néanmoins un miroir synchronisé sur GitHub au même emplacement qu’auparavant (pour profiter en particulier du fait que de nombreux développeurs sont présents sur GitHub et peuvent plus facilement créer un dépôt divergent (fork) et nous faire des rapports de bogues sur cette plate‐forme).

7. Conclusions et perspectives

Voilà ! Notre tour des nouveautés (des six derniers mois d’activité) du projet G’MIC s’achève enfin.

Nous sommes heureux d’avoir pu vivre dix belles années d’émotions informatiques avec la naissance et l’évolution de ce projet libre, et de pouvoir partager à notre manière, avec tous les utilisateurs, des techniques de traitements d’images avancées. On espère surtout repartir de plus belle pour de nombreuses années ! Les soutiens se font de plus en plus présents autour de nous, donc on se dit que ça doit pouvoir se faire (à ce propos, si vous voulez contribuer au projet de quelque manière que ce soit, vous êtes les bienvenus !).
Notons que l’année prochaine, on fêtera également les vingt ans d’existence de CImg, la bibliothèque C++ de traitement d’images qui est directement à l’origine du projet G’MIC (et qui, elle, est née en novembre 1999, ça ne nous rajeunit pas ma bonne dame…). Preuve s’il en est que l’intérêt du logiciel libre, c’est qu’il s’inscrit dans la durée !

Et en attendant la prochaine dépêche sur G’MIC, n’hésitez pas à tester ce logiciel, à jouer et triturer vos images de la manière la plus libre et créative possible !

Aller plus loin

  • # Bon anniversaire et merci

    Posté par . Évalué à 7.

    Voila,
    Bon anniversaire et merci. Je lisais déjà Linuxfr en 2008, mais je n'ai retenu G'MIC qu'à partir du moment où tu as présenté des images des filtres…

    Je me demande s'il est possible d'exporter le model de la main en 3D (facettes) ? pour une réutilisation dans blender par exemple.

    • [^] # Re: Bon anniversaire et merci

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

      Je me demande s'il est possible d'exporter le model de la main en 3D (facettes) ? pour une réutilisation dans blender par exemple.

      On peut a priori juste sauver une triangulation réalisée par G'MIC sous la forme d'un fichier .off. Après, importer ça sous Blender je ne sais pas si c'est facile, j'avoue que je n'ai jamais essayé.

      • [^] # Re: Bon anniversaire et merci

        Posté par . Évalué à 10. Dernière modification le 21/08/18 à 19:26.

        Salut messieurs Tschumperlé et Jaguenaud.

        Note préliminaire : moi aussi, comme pour Pierre Maziere (cf. son témoignage plus bas), ces dépêches me ravissent, bien que je ne sois pas utilisateur de G'MIC, du coup j'ai recréé un compte pour participer.

        Après une rapide recherche, voici ce que je peux en dire :

        • il y a une extension pour Blender qui permet d'importer / exporter des fichiers au format .OFF — son nom est Blender OFF Addon (lien vers la page Github) ;
        • on en trouve une référence dans la section des scripts Python pour Blender 2.6 sur le site Blender.org — note : le Release Log de cette page n'est pas à jour car la dernière version est la 0.3.1 du 3 novembre 2017 (d'après la page Github, dans le readme.md) ;
        • c'est utilisable depuis l'interface graphique ou directement depuis un script Python — il faut faire attention à l'axe qui pointe vers toi (axe Y dans Blender, alors que c'est l'axe Z dans beaucoup d'applications) et ajuster le paramètre axis_forward en conséquence — source : page titrée « How to import “.off” object file using python code » sur le site Stack Exchange.

        PS : une coquille s'est glissée dans la dépêche, c'est évidemment acosh (le cosinus hyperbolique inverse) et non pas acohs. J'aurais du me relire avant de passer le papier à David (je blague) ---> [ ]

        • [^] # Re: Bon anniversaire et merci

          Posté par . Évalué à -1. Dernière modification le 22/08/18 à 15:18.

          Je vois que la coquille a été corrigée. Aucun remerciement, laissant penser que j'ai écrit des conneries, pouvant justifier le "moinsage"… Le mépris continue. Je l'ai découvert aussi sur la tribune où le grand jeu est de déclencher la cabale explicitement (en usant de ce mot) et de "moinser" mes contributions (d'où le -3). Bravo Single< et gle< et au troisième blaireau…. Continuez à tolérer ces comportements, chez les autres ou en vous-mêmes, vous êtes sur la bonne voie pour faire de Linuxfr.org le vecteur de l'arrivée de l'année de Linux sur le desktop

          Je n'ai évidemment aucune envie de contribuer sur Linuxfr dans ces conditions. Je ferme donc ce compte. Zero Heure, fais-toi plaisir et censure ce commentaire, je sens que ça te démange.

          • [^] # Re: Bon anniversaire et merci

            Posté par . Évalué à 5.

            Ça fait bizarre de comprendre tes commentaires… :)

          • [^] # Re: Bon anniversaire et merci

            Posté par . Évalué à 10.

            C'est vrai que je trouve vraiment dommage de moinsser un contenu du fait de ce que l'on pense de l'auteur. C'est en fait réellement une cabale : entente secrète de plusieurs personnes dirigée contre quelqu'un.

            C'est un des points vraiment négatif du site, je trouve. Il serait vraiment intéressant que les avis ne soient pas anonymes. Le système pourrait être simplement que lorsque l'on clic sur la note d'un commentaire, on voit qui a pertinenté et qui a inutilé.

            Personnellement, je ne trouve pas cela marrant de démotiver à ce point des gens qui peuvent être de bonne volonté et contribuer au site. La contribution de SamWang-8 sur le .off était réellement pertinente, il a fait l'effort d'aller chercher comment faire et a retranscrit les méthodes de manière claire et détaillée. Je ne comprends pas comment on peut trouver cela inutile ! C'est donc une attaque personnelle et je trouve regrettable que le site permette cela.

            Après je trouve dommage que SamWang-8 accuse des membres sans preuve, mais c'est le système de notation qui engendre ça …

            • [^] # Re: Bon anniversaire et merci

              Posté par . Évalué à -2.

              Sais-tu pourquoi il s'appelle SamWang-8 ? parce qu'il y a eu de multiples comptes.

              Attendons le SamWang neuf

              • [^] # Re: Bon anniversaire et merci

                Posté par . Évalué à 10.

                Sais-tu pourquoi il s'appelle SamWang-8 ? parce qu'il y a eu de multiples comptes.

                Oui, je comprends bien, mais même si sur pleins de sujets il est en désaccord avec la majeure partie des gens et que parfois certains de ses commentaires puissent être confus, il se trouve qu'il insiste en revenant avec le même non incrémenté. Je pense que cela prouve qu'il a eu envie jusqu'ici de participer. Et lorsqu'il fait des participations pertinentes, il serait correct de prendre le temps de les lires et non de moinsser directement parce-que c'est lui !

            • [^] # Re: Bon anniversaire et merci

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

              Alors premièrement, le commentaire est clairement en positif, il y a 3 moinsage, on n'est loin d'une grande cabale organisée. Entre, une ou deux erreur de clique (ça m'est déjà arrivé plus d'une fois sur smartphone), ça ne laisse pas beaucoup de place à l'entente secrète. Surtout qu'on peut comprendre que certain lui en veulent vu les messages qu'il a déjà laisser sur certaines personnes.

              Ensuite, le message suivant, il dit clairement qu'on s'attaque à lui parce qu'on a corrigé une erreur sans le remercier (alors qu'elle très bien pu être découverte autrement). Il s'attaque aux modérateurs sans raison.

              Après je trouve dommage que SamWang-8 accuse des membres sans preuve, mais c'est le système de notation qui engendre ça …

              Il ne parle pas du système de notation, mais il s'attaque à un modérateur nominativement parce qu'il pense que ce dernier a supprimé des commentaires sans raisons (commentaires qui étaient hors charte).

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Bon anniversaire et merci

                Posté par . Évalué à 5.

                Alors premièrement, le commentaire est clairement en positif, il y a 3 moinsage, on n'est loin d'une grande cabale organisée. Entre, une ou deux erreur de clique (ça m'est déjà arrivé plus d'une fois sur smartphone), ça ne laisse pas beaucoup de place à l'entente secrète.

                Honnêtement, cet argument me parait être la solution de facilité qu permet de récuser ce problème dans le site. Qu'il y ait une erreur ok, mais 3 sur 12 ? non.

                Il souligne aussi le fait de se faire publiquement agresser sur la tribune, personnellement, je n'en sais rien, je n'ai pas moyen de vérifier. Mais j'ai déjà assisté à des ententes de personnes voulant me faire taire et en parlant sur la tribune en des termes peu flatteurs pour moi. Donc, l'ayant vécu, je n'ai pas de mal à croire SamWang.

                Il ne parle pas du système de notation, mais il s'attaque à un modérateur nominativement parce qu'il pense que ce dernier a supprimé des commentaires sans raisons (commentaires qui étaient hors charte).

                Ok, je ne cautionne certainement pas cette attitude, mais beaucoup sur ce site arrivaient à comprendre la lassitude du développeur de weboob lorsque l'on lui reparlait de la polémique associée à ces errements passés, il me semble facile de comprendre la lassitude de quelqu'un qui essaye de faire un effort, fasse un commentaire constructif et se retrouve moinssé. Alors certes avec le temps la balance de son commentaire constructif est clairement positive et c'est bien. Mais je pense que ses "haters" ont dû arriver très rapidement sur le site pour le moinsser, mais je n'ai pas de moyen de le vérifier. Du coup sa réaction peut paraître totalement exagérée au regard de sa note actuelle mais est peut être compréhensible lorsque l'on se met à sa place.

                Ce n'est pas toujours évident sur ce site de penser autrement, les attaques peuvent être très violentes avec même parfois des menaces. Il est donc logique que des gens "pètent un cable" parfois et deviennent aigris.

                Évidemment, cela n'excuse pas l'attaque directe de SamWang sur un modérateur, mais permet peut-être de comprendre comment un contributeur peut se radicaliser à la suite d’événements traumatiques arrivés sur ce site.

                Personnellement, lorsque ça m'arrive, je fais en sorte d'en profiter pour essayer d'améliorer ma communication, mais parfois c'est vraiment dur, très dur.

                Donc je pense que du côté modérateurs, il ne faut pas non plus prendre cela trop à cœur.

              • [^] # Re: Bon anniversaire et merci

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

                Alors premièrement, le commentaire est clairement en positif, il y a 3 moinsage, on n'est loin d'une grande cabale organisée. Entre, une ou deux erreur de clique (ça m'est déjà arrivé plus d'une fois sur smartphone)

                J'ai été un des premiers à le plusser sur ce commentaire alors qu'il était déjà en négatif dans les minutes qui ont suivi sa publication et qu'il avait déjà pris ses trois moinssages qui ont été ses toutes premières évaluations (bot ?)… Moi aussi j'ai déjà inutilé par mégarde un message sur smartphone, c'était je ne sais même plus quand et c'était par hasard le post de SamWang et c'était pas fortuitement le meilleur post qu'il ait jamais écrit et je n'ai jamais malencontreusement trébuché avec trois comptes en même temps. J'ai d'ailleurs plussé ce message d'abord pour contrebalancer le moinssage incompréhensible, même si le contenu méritai largement un plus c'est par révolte que j'ai plussé parceque ce n'est pas normal de voir un post moinsé à vue.

                Si tout message d'un utilisateur donné doit être supprimé par défaut alors c'est aux admins de bannir le compte. Si les admins jugent qu'il n'y a pas besoin d'aller jusque là et que d'autres le font par des moyens détournés on est en présence d'une situation grave de non respect de l'autorité et c'est potebtiellement plus grave et sournoisement plus toxique qu'un postalacon ou qu'un profil ouvertement problématique.

                ce commentaire est sous licence cc by 4 et précédentes

                • [^] # Re: Bon anniversaire et merci

                  Posté par (page perso) . Évalué à 2. Dernière modification le 23/08/18 à 19:44.

                  hmmmm je voulais dire:

                  et ce n'était pas par hasard le post de SamWang

                  et il y a quelques fautes surprenantes ici ou là (je suis précisemment sur smartphone) mais j'imagine que l'idée générale est passée.

                  ce commentaire est sous licence cc by 4 et précédentes

                • [^] # Re: Bon anniversaire et merci

                  Posté par . Évalué à 4.

                  ses trois moinssages qui ont été ses toutes premières évaluations (bot ?)…

                  Ce n'est pas un bot. C'est Single<, gle< et un troisième blaireau

                  splash!

  • # inutile donc indispensable…

    Posté par . Évalué à 10. Dernière modification le 21/08/18 à 11:09.

    … pas G'MIC, mais mon commentaire !

    Depuis ces 10 ans que je te lis sans pouvoir commenter faute de contenu pertinent à proposer, tu n'imagines pas le bonheur que j'ai à lire tes dépêches: je ne suis pas graphiste, et encore moins utilisateur de G'MIC, mais ce mélange d'algo et d'effets graphiques dans tes présentations me donne la banane à chaque fois que je découvre une nouvelle itération de ton projet. La figure 6.9 résume mon ressenti: nostalgie des années démos !

    merci !

  • # Aperçu

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

    Une des nouveautés que je préfère dans GIMP 2.10 est l'aperçu des filtres directement sur le canvas. Est-ce que cela est possible avec les filtres de G'MIC ?

    Quid des calques d'effets et de l'édition non destructive qui devraient arriver un jour ?

    • [^] # Re: Aperçu

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

      Une des nouveautés que je préfère dans GIMP 2.10 est l'aperçu des filtres directement sur le canvas. Est-ce que cela est possible avec les filtres de G'MIC ?

      Non ce n'est pas possible. Le greffon possède déjà une grande fenêtre de prévisualisation, donc on ne voit pas trop la valeur ajoutée d'autoriser l'aperçu on-canvas (on peut déjà agrandir la fenêtre de prévisualisation et/ou zoomer l'image dans celle-ci si besoin est).
      Au contraire, la prévisualisation on-canvas n'est clairement pas adaptée pour les filtres de traitements un peu complexes, qui nécessitent pas mal de calculs, car cela nuit in fine à l'interactivité générale. Il vaut mieux dans ce cas pouvoir effectuer les traitements plutôt sur de petites portions d'images pour prévisualiser le résultat.

      Pour ma part, je trouve donc que l'idée d'adopter systématiquement une prévisualisation on-canvas n'est pas excellente. Je préfère avoir un widget de prévisualisation dédié à cette tâche, de taille réglable, qui permet bien plus de flexibilité.

      Quid des calques d'effets et de l'édition non destructive qui devraient arriver un jour ?

      L'édition non-destructive aura a priori le même genre de limitations. Tant qu'on restera sur des effets "simples", peu coûteux en temps de calcul (genre mixeur de canaux couleurs ou déformations simples), alors ça va pouvoir se gérer. Mais pour des traitements d'images complexes ("inpainting", débruitage d'images avec des algos avancés, etc.), on va surement pas trop avoir envie de proposer ça en non-destructif, où je me dis que l'expérience utilisateur deviendra catastrophique : attendre 5-10 minutes qu'un calque non-destructif se remettre à jour est surement pas quelque chose qu'un utilisateur est prêt à supporter :)

      • [^] # Re: Aperçu

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

        Perso je pense que la prévisu sur canevas serait super utile, même pour les traitements lents.

        Pour ma part, je trouve donc que l'idée d'adopter systématiquement une prévisualisation on-canvas n'est pas excellente.

        La prévisualisation n'a pas à être activée par défaut. ;-)

        Il vaut mieux dans ce cas pouvoir effectuer les traitements plutôt sur de petites portions d'images pour prévisualiser le résultat.

        GIMP donne aussi la priorité au rendu de la partie visible à l'écran, et le mipmapping aide aussi beaucoup si un zoom (avant ou arrière) est fait. Et je sens que les choses vont s'améliorer encore dans le futur pour optimiser la sensation de fluidité (ou du moins de pas avoir une expérience trop désagréable), même avec des traitements lents.

        L'édition non-destructive aura a priori le même genre de limitations.

        Ce sera clairement utile pour l'édition non-destructive également. Faire un changement dans les paramètres d'un effet peut te prendre 10 minutes, mais dans tous les cas, tu devras le refaire (ton effet). Dans le cas de l'édition non destructive, au moins tu pourras voir les paramètres utilisés précédemment et repartir de là. Dans le cas de l'édition destructive, tu as intérêt à avoir bien gardé une copie du calque d'origine et tu ne sais même pas l'ensemble des traitements faits, et avec quels paramètres, à part si tu les as notés bien consciencieusement (ce que certains font dans le nom du calque par exemple).

        Pour moi, il n'y a rien d'équivoque là. Mais je crois qu'on a déjà eu cette discussion et qu'on pourra encore l'avoir à l'avenir. ;-)

        Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # Génial, mais on peut pas télécharger !

    Posté par . Évalué à 2.

    Merci pour ces 10 ans de G'MIC et e dépêches géniales ! (non, mais vraiment, ça doit demander un temps fou à écrire !).

    Par contre petit souci : quand je vais sur la page https://gmic.eu/download.shtml et que je clique sur .zip archive de Linux 64 bits (tested with Debian Sid) de GIMP 2.10, je tombe sur une triste 404 https://gmic.eu/files/linux/gmic_gimp2.10_qt_2.3.0_debian_sid_amd64.zip

    Dommage ! J’aurais bien aimé tester !

    Sinon pour les francophones anglophiles une traduction est en cours là : https://hackmd.io/B-p-lsJ5QEm2cdcXupVCtQ?both

    • [^] # Re: Génial, mais on peut pas télécharger !

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

      Ha oui, je crois que c'était le seul lien cassé, merci de l'avoir remarqué :). Ca devrait être corrigé maintenant !

      Pour la traduction, on essaye effectivement d'avoir une version anglaise de l'article pour publication sur le site de nos amis de Pixls.us. Toute aide est plus que bienvenue !

      • [^] # Re: Génial, mais on peut pas télécharger !

        Posté par . Évalué à 2.

        Merci pour la correction du lien, ça marche maintenant !

      • [^] # Re: Génial, mais on peut pas télécharger !

        Posté par . Évalué à 3.

        Je sais que le bin est prévu pour un Debian ID, mais je viens d'essayer avec une Mageia 6, avec le dernier GIMP (2.10.6) issu de flathub (oui, je cumule les difficultés), et au lancement le greffon plante avec cette erreur :

        .var/app/org.gimp.GIMP/config/GIMP/2.10/plug-ins/gmic_gimp_qt: error while loading shared libraries: libfftw3_threads.so.3: cannot open shared object file: No such file or directory
        Alors que libfftw est installée en 32 et 64bits et que libfftw3_threads.so.3 est bien présent (dans /usr/lib64)

        • [^] # Re: Génial, mais on peut pas télécharger !

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

          OK, alors mauvaise nouvelle : on a jamais réussi à faire tourner le greffon G'MIC-Qt pour GIMP 2.10 installé avec flatpak.
          Pour ma part, je fais mes tests avec une install de GIMP 2.10 fourni sous Ubuntu avec ce PPA, et le greffon G'MIC-Qt fonctionne bien avec GIMP 2.10 (mais j'avoue aussi que je le recompile moi-même sur ma machine).
          Donc on sait que ça fonctionne pour GIMP 2.10 sous Linux (et Windows également).

          Mais avec une install Flatpak de GIMP, on ne sait pas ce qui se passe, il y a des soucis au niveau des bibliothèques. C'est embêtant car on sait qu'il y a pleins de personnes qui ont installés GIMP 2.10 avec Flatpak, du fait que la version 2.10 n'est pas disponible dans les dépôts des distributions en général.

          Donc pour le moment, j'ai pas de solutions, j'en suis bien désolé !

          • [^] # Re: Génial, mais on peut pas télécharger !

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

            Oui c'est malheureusement un des trucs (le flatpak de GIMP et les plug-ins) sur lesquels il faudrait bosser plus. :-/

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Génial, mais on peut pas télécharger !

            Posté par . Évalué à 3.

            Oui je me rends compte que c'est complexe comme situation ! Pour moi ce n'est pas très grave, j'ai pu tester avec le GIMP 2.8 de ma distrib. Je voulais juste savoir si cette question avait été envisagée et je lis (dans ta réponse et celle de Jehan) qu'il y a encore du chemin !

          • [^] # Re: Génial, mais on peut pas télécharger !

            Posté par . Évalué à 3.

            C’est peut être envisageable de faire un flatpack avec gimp + gmic de base :)

            • [^] # Re: Génial, mais on peut pas télécharger !

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

              Non ce n'est pas envisageable. De même que notre installeur Windows ne contient pas G'Mic (pas plus que tout autre plug-in tiers), ni notre DMG pour macOS.

              Les builds officiels de GIMP ne contiennent (et ne contiendront toujours) que les plug-ins core de GIMP, c'est à dire ceux maintenus par les développeurs de GIMP. On a déjà bien suffisamment de boulot (avec très peu de développeurs) pour ne pas non plus se donner plus de travail. En outre si quelqu'un fournit un paquet, il est de-facto responsable de son contenu (or on ne développe/maintient pas G'Mic). Pour G'Mic, c'est un logiciel suffisamment complexe et élaborée pour qu'on se rende bien compte que si David venait à arrêter demain (on touche du bois pour que ça ne soit pas le cas!), on ne serait pas à même de le maintenir à sa juste valeur.
              Donc non, on ne peut pas.

              De même que David, je pense qu'il préfère garder l'indépendance dans ses sorties, etc. et ne pas dépendre de nos choix de sortie.

              La tendance est plus à la création d'un système d'extension (voir ma news pour GIMP 2.10.6 qui devrait être publiée d'ici quelques jours) qui permettra d'installer facilement G'Mic et autres plug-ins, tout en laissant les développeurs de ces plug-ins en garder la main complète. Tout le monde y gagne. Et je sais, de source sûre, que David aime l'idée. ;-)

              D'ailleurs une fois que cela sera en place, il est même possible que certains des plug-ins core actuels puissent devenir des extensions à leur tour (toujours maintenus par nous, mais avec un rythme de développement parallèle), ce qui permettrait des menus moins touffus de fonctions que peu de monde utilisent par exemple. À voir…

              Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

              • [^] # Re: Génial, mais on peut pas télécharger !

                Posté par . Évalué à 2.

                La gestion des extensions est très ambitieuse, mais ça me fait un peu peur pour vous. Quand tu gère des extensions du deviens responsable au moins en parti d'elles. Regarde l'actualité récente de Mozilla… De plus ça demande une infrastructure de pki. Actuellement rien ne cloisonne les extensions, donc tu veux faire de la revue et le build chez toi.

                C'est super comme idée, mais je crains que ça ne consomme toute ton énergie (je serais heureux de me tromper !)

                • [^] # Re: Génial, mais on peut pas télécharger !

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

                  C'est le mode de diffusion des extensions avec un dépôt central qui peut nécessiter une infrastructure spécifique lourde.
                  Si Gimp ne diffuse que ses propres extensions - comme est diffusé l'application - et laisse le soin aux auteurs tiers de diffuser les leurs à leur convenance (site perso, packages des distributions Linux…), alors l'équipe Gimp n'ont pas à assumer la responsabilité du contenu des extensions tiers et de leur mode de diffusion.

                  Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                • [^] # Re: Génial, mais on peut pas télécharger !

                  Posté par . Évalué à 3.

                  C'est super comme idée, mais je crains que ça ne consomme toute ton énergie (je serais heureux de me tromper !)

                  Il faut donc que le potentiel de développeur et mainteneurs d’extensions de gimp soit à la hauteur de l’effort engagé

                • [^] # Re: Génial, mais on peut pas télécharger !

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

                  Quand tu gère des extensions du deviens responsable au moins en parti d'elles.

                  On ne les gèrera pas. On les hébergera. Mais oui tu as raison quand même qu'on aura notre part de responsabilité.

                  Actuellement rien ne cloisonne les extensions, donc tu veux faire de la revue et le build chez toi.

                  Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.

                  C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.

                  C'est super comme idée, mais je crains que ça ne consomme toute ton énergie (je serais heureux de me tromper !)

                  Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques. Des gens comme Pat David et Elle Stone seront parfaitement capables de gérer le quotidien (et de sélectionner les futur modérateurs si le contenu grossit vite).

                  Aussi on pourra y aller lentement. Si les gens sont pas contents du temps de revue, ce n'est pas notre problème. L'un des énormes avantages que l'on a est qu'on n'essaie pas de faire du business. Nos actions ne sont pas dirigées par des contraintes économiques. Ça rend GIMP très résistant aux problèmes car personne ne peut nous forcer à rien ni nous presser.

                  Bon j'arrête là. Cette dépêche est au sujet de G'Mic pas de GIMP! :P

                  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                  • [^] # Re: Génial, mais on peut pas télécharger !

                    Posté par . Évalué à 1. Dernière modification le 23/08/18 à 16:05.

                    On ne les gèrera pas.

                    Tu me reprends sur la distinction entre manager et gérer ? :)

                    Même si GIMP lançait des sandbox, la revue et compilation doivent être faites de notre côté. Héberger aveuglément un binaire d'inconnus complets est une aberration.

                    Ça se discute. Tu pensais faire des revues pour les brosses par exemple ? Ce sont des vecteurs d'attaque eux aussi. On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox et c'est régulièrement un vecteur d'attaque.

                    C'est la raison pour laquelle les plug-ins compilés ne seront pas acceptés tant qu'on n'aura pas l'infra. Certains bénéficieront d'exception évidente comme G'Mic. C'est expliqué dans mon article.

                    Je sais lire :) c'est moi qui ai mis le lien.

                    Je ne prévois pas de gérer le site. Je suis développeur pas animateur de communautés. Nous avons une très grosse communauté avec des gens très actifs et même pas mal plutôt techniques.

                    C'est cool je n'avais pas cette vision :)

                    Ça rend GIMP très résistant aux problèmes[…]

                    Alors c'est pas si simple, je sais que ce n'est même pas le début du projet, mais ça rend publique toute une politique et ça vous expose à du bad buzz (grand publique ou de communauté), des discussions interminables, etc. Même sans être community manager ça te touchera/concernera. Je n'ai aucun doute que j'aurais toujours accès au code de GIMP, mais est-ce que les développeurs auront suffisamment la foie pour ne jeter l'éponge ? Je n'espère pas. Et c'est bien pour ça que je me permet de faire mes remarques. Je préfère t'avertir de mes craintes, pour que tu sois moins surpris si (malheureusement) ça arrive.

                    • [^] # Re: Génial, mais on peut pas télécharger !

                      Posté par (page perso) . Évalué à 5. Dernière modification le 23/08/18 à 18:39.

                      Tu me reprends sur la distinction entre manager et gérer ? :)

                      Tu parles du fait que c'est de la gestion d'extension dans GIMP? Si oui, bien sûr que là on parle de gestion (c'est même le titre), mais il s'agit du fait d'installer, désinstaller, mettre à jour et afficher des infos sur des extensions. C'est la partie côté cliente.
                      Ça veut pas dire qu'on gère l'extension au sens de vraiment s'en occuper. Si elle est bourrée de bugs, si elle marche pas même, c'est pas notre problème au delà de fournir des outils (pas immédiatement, mais probablement rapidement) pour que les gens puissent indiquer une extension qui fonctionne ou pas sur telle ou telle version de GIMP. Et si l'extension n'est pas maintenue, on ne s'en occupera pas plus.

                      Je dirais que c'est notre problème si on découvre des malware et là oui, on intervient et on vire l'extension. À ce moment, quand il y a intention malfaisante évidente (ou grosse faille de sécurité très dangereuse), il est évidemment de notre responsabilité de réagir. Mais ça s'arrête là. C'est en ce sens là qu'on ne gère pas les extensions (côté serveur) au delà de proposer aux gens de les héberger.

                      Ça se discute. Tu pensais faire des revues pour les brosses par exemple ? Ce sont des vecteurs d'attaque eux aussi. On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox et c'est régulièrement un vecteur d'attaque.

                      Les données inertes (brosses, images splash, thèmes, icônes, dégradés, etc.) ne subiront en effet pas de revue préalable, contrairement aux données exécutées (plug-ins) qui doivent être évidemment validées avant d'être diffusées.

                      Ensuite bien sûr que des vecteurs d'attaques peuvent exister avec des données inertes. Cela a toujours existé et existera toujours. On a tous entendu parler de failles permettant d'exécuter du code caché dans des images par exemple.
                      Néanmoins cela n'est pas un comportement normal, et ainsi dire "On peut voir le chargement d'un fichier comme une exécution d'un programme dans une sandbox" est faux, en tous cas pour le type de fichiers que tu cites (brosses) ou que je cite (images) [bien sûr, il existe des fichiers avec du code fait pour être exécutés, comme les fameuses macros de traitement de texte; de tels fichiers doivent donc être considérés comme du code]. Donc non, charger une bosse ou une image n'est pas la même chose qu'exécuter un programme. Ce sont des données inertes faites pour une utilisation donnée, pas pour exécuter du code tiers. Quand cela arrive, c'est un comportement anormal, autrement dit un bug (le plus souvent dans le logiciel, parfois dans le format lui-même) et qui doit alors être corrigé.

                      Aussi cela n'a rien à voir avec les extensions. Ce type de bug, quand il existe, existerait déjà dans GIMP et pourrait déjà se produire. Les extensions ne sont qu'un conteneur supplémentaire (ajoutant un peu de sémantique au contenu, indiquant de quoi il s'agit, un nom, une description, des liens annexes, une version, etc.).

                      Alors c'est pas si simple, je sais que ce n'est même pas le début du projet, mais ça rend publique toute une politique et ça vous expose à du bad buzz (grand publique ou de communauté), des discussions interminables, etc.

                      Les haters ont toujours existé et existeront toujours. Je le sais bien, je parle moi-même régulièrement sur Linuxfr de cela. Soyons clair, ça me touche et c'est dur. Mais je ne vois pas en quoi faire ou non des extensions pourrait changer quoi que ce soit à cela.

                      En fait par rapport aux comportements inadéquats, ma politique perso est de rester neutre (si possible, parfois c'est dur de tenir) et d'expliquer aux gens justement ce que je disais: GIMP est un logiciel libre, le logiciel libre, ça ne marche pas comme ils semblent le penser. En plus on n'est pas une entreprise, et on développe de façon volontaire. Et non, on ne réagit pas bien aux menaces et insultes. Par contre on est heureux d'aider les gens agréables, et tout ce qu'on demande, c'est que ces gens comprennent aussi ce qu'il en est, et qu'on contribue principalement bénévolement, souvent sur du temps libre.
                      Eh ben, tu me croiras peut-être pas, mais être clair (et poli) désamorce pas mal de situations. Les gens se rendent compte qu'ils ont un peu été des malotrus, se calment, parfois même (ça arrive!) s'excusent.

                      Ensuite oui, ça n'est pas du 100%. Et certains sont juste là pour haïr, comme je disais. On ne peut rien pour cela. Mais encore une fois, je vois pas le rapport avec les extensions. Ces personnes trouveront de quoi redire pour chaque nouvelle fonctionnalité qu'on apportera. On va quand même pas s'arrêter d'améliorer nos logiciels pour ces gens là! En tous cas, perso, c'est pas pour eux que je développe. :-)

                      est-ce que les développeurs auront suffisamment la foie pour ne jeter l'éponge ?

                      Je crois que tu cherches des problèmes là où y en a pas. :-)
                      Pourquoi qui que ce soit jetterait l'éponge pour quelques aigris? Si ça devait arriver, crois moi, ça serait arrivé y a trèèèès longtemps (comme tout gros logiciel connu, on collectionne quelques aigris).

                      Au pire du pire, si vraiment ça se passait super mal, on pourra toujours arrêter notre système d'extensions tiers (et n'héberger que nos propres extensions, voire un choix très restreint d'extensions sélectionnées au cas par cas, comme quelqu'un le propose plus haut). Perso je trouverais cela un peu dommage, mais si on devait en arriver là, c'est pas la mort.
                      Soyons clair, je ne pense pas qu'on en arrivera là. Je vois aucune raison à cela.

                      Ah oui, et:

                      bad buzz

                      Encore une fois, du vocabulaire de startup hipster. On s'en fout du "bad buzz". Je dirais même qu'on vit dans un monde où cela n'existe pas. Il y a des gens sympas, des gens moins sympas, ça s'arrête là. Si ce prétendu grand méchant bad buzz devait avoir eu raison de nous, ça serait arrivé y a très longtemps.

                      Je préfère t'avertir de mes craintes, pour que tu sois moins surpris si (malheureusement) ça arrive.

                      Merci beaucoup de t'inquiéter pour nous.
                      Je pense perso que tu te fais du mouron pour rien. :P

                      Si le type de problème dont tu parles devait arriver, je pense pas que ce soit parce qu'on ait ajouté un système de gestion d'extension dans GIMP. Ahahahah!

                      Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)

                      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                      • [^] # Re: Génial, mais on peut pas télécharger !

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

                        Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)

                        Qui sera bientôt très facile à installer dans GIMP apparemment, grâce au nouveau gestionnaire d'extensions :)

                        Comme je le disais, G'MIC a doit beaucoup à GIMP (et Krita), donc avoir des infos directs de la source, c'est plutôt sympa.

              • [^] # Re: Génial, mais on peut pas télécharger !

                Posté par . Évalué à 3. Dernière modification le 23/08/18 à 09:43.

                Totalement sans rapport : J'aime utiliser GIMP 2.8 pour faire des scans sur un vieux PC sous Windows XP.

                J'aurais bien voulu le faire passer à GIMP > 2.8 (juste pour le temps de démarrage plus rapide), mais je trouve que des versions Win64 (ou en fait uniquement pour Windows >=7) à télécharger sur le site.

                Je veux bien le compiler, mais c'est possible de le compiler en 32 bits pour XP (et un CPU Pentium3) avec Visual Studio (MSVC), ou faut obligatoirement utiliser un autre système de build ?

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Génial, mais on peut pas télécharger !

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

                  Salut,

                  je trouve que des versions Win64

                  Nos installeurs contiennent la version 32 et 64-bit et installent la version appropriée. C'est écrit juste sous le bouton de téléchargement. Donc prends simplement l'installeur unique et ça te mettra la bonne version.

                  ou en fait uniquement pour Windows >=7

                  Ça oui par contre. C'est pas qu'on veut pas prendre en charge de plus vieux Windows, mais on n'a quasi aucun dév Windows (approximativement 0) alors on fait ce qu'on peut. Prendre en charge de vieilles versions veut dire plus de boulot car on doit contourner des problèmes de manières plus compliquées (même si des versions récentes ont peut-être amené des solutions simples).

                  Notre ligne directrice pour savoir si on prend en charge un OS (Windows ou macOS), c'est que cette version de l'OS doit au moins être encore pris en charge par son éditeur. Windows XP, y a plus de support depuis avril 2014 (d'après Wikipédia) et on parle quand même d'un système sorti en 2001, soit y a 17 ans!
                  Il est peut-être temps de mettre à jour. Et si le matériel est juste trop ancien, on peut mettre un Linux avec bureau léger. Ou si vraiment on est nostalgique des vieilles années et qu'on veut garder l'OS d'époque absolument (faire attention à l'accès internet, etc. dans ce cas), ben on prend sur soi et on garde aussi les vieux logiciels (y compris GIMP 2.8). :-)

                  Enfin bon, tout cela pour dire qu'il n'y a pas vraiment de solutions miracle, désolé. On peut pas prendre en charge indéfiniment un système, surtout si même son éditeur ne veut plus le prendre en charge. Ce serait vraiment se tirer une balle dans le pied.

                  Je veux bien le compiler, mais c'est possible de le compiler en 32 bits pour XP (et un CPU Pentium3) avec Visual Studio (MSVC), ou faut obligatoirement utiliser un autre système de build ?

                  Tout est possible. Ensuite je crois que la plupart des gens qui compilent GIMP pour Windows le font depuis un Linux (même notre build officiel est cross-compilé, il me semble). Donc ce sera clairement cela le plus simple.

                  Et je suis pas certain que ce build fonctionnera de toutes façons. Ne pas prendre en charge Windows XP, ça veut surtout dire qu'on a peut-être (probablement) utilisé des APIs Windows qui n'existaient pas encore dans XP. Donc tu te retrouveras à devoir patcher le code en fonction des parties qui poseront problème. Si tu le fais sans perte de fonctionnalité ni rendre le code surcompliqué (et avec un code propre), on veut bien le patch (on n'est pas absolument contre Windows XP, on ne le prend pas officiellement en charge, c'est tout).

                  Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                • [^] # Re: Génial, mais on peut pas télécharger !

                  Posté par . Évalué à 2.

                  C'est tout bête mais passer cette bécane sous Linux résoudrait certains soucis non ?

                  Après, j'imagine que tu y as déjà réfléchi. Personnellement je comprends qu'il faille à un moment arrêter de courir après des updates pour un système déprécié, ca me semble contre-productif; mais je sais qu'on trouve toujours de ces machines où tout fonctionne très (trop) bien, et qu'on ne souhaite surtout pas toucher :D

                  • [^] # Re: Génial, mais on peut pas télécharger !

                    Posté par . Évalué à 3.

                    Pour tout dire, c'est une machine pour tester/ripper/scanner des vieux jeux DOS et Windows, avec le matos pour ça (GeForce 4, Sound Blaster AXE64, 512 Mo de SDRAM-PC100, 3DFX Voodoo 2, …), et les systèmes pour ça (Windows 98SE et Windows XP), et in-fine mettre tout sur sur Abandonware-France.org.

                    Mettre Linux n'aurait pas de sens (rien ne bat la compatibilité avec les vieux jeux que d'utiliser MS-DOS et Windows 9X. Et DOSBox est trop lent là dessus. Quant à Wine, il est loin d'être parfait, surtout quand SecuROM ou Safedisc sont de la partie).

                    Le scanner fonctionne au mieux avec Windows 7 32 bit, et pas au delà.
                    Pas sûr du tout qu'il fonctionne sous Linux.

                    Au delà de ça, pour avoir des pilotes graphiques qui fonctionnent (= proprios nvidia) il faut rester sur Xorg 1.12 ou quelque chose comme ça. C'est de plus en plus difficile de nos jours.

                    Et le temps de démarrage d'un Xorg est risible face à la vitesse d'un Windows 98SE ou XP sur ce pauvre PC. ;-)

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # J'aime beaucoup !

    Posté par . Évalué à 2.

    Je vous suis depuis le début, c'est un plaisir de voir que ca bouge toujours autant (et que ca évolue).

    • le greffon pour GIMP/Krita est un MUST have <3
    • l'utilitaire en ligne de commande va sans doute me faire me détourner de ImageMagick / Nconvert pour utiliser G'MIC si je peux faire la même chose (je n'en doute pas). J'ai quelques projets à modifier pour me faire la main :D
    • le service web est vraiment difficile à utiliser compte tenu de la richesse de l'interface, sur des filtres un peu sympa

    Une piste, développer une API web pour automatiser les traitements (et profiter de la puissance de calcul de vos serveurs :D) avec un abonnement - éventuellement en produit d'appel une version gratuite de quelques images par mois ? Je n'ai pas à court terme ce besoin mais c'est une solution séduisante qui n'existe pas à ma connaissance (du moins, pas avec toute l'étendue de votre savoir faire).

    En tous cas… bravo à toute l'équipe :)

Suivre le flux des commentaires

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