David Tschumperlé a écrit 340 commentaires

Pour répondre plus simplement, le problème de ton raisonnement, consistant à affirmer :

Parce que cela est extrêmement energivore et destructeur de l'environnement ?

c'est que ça ne prend pas en compte la notion d'utilité de l'action, mais seulement son coût environnemental en valeur absolue, qu'on serait censé devoir absolument minimiser. C'est un raisonnement fallacieux. C'est le coût environnemental relatif au bénéfice de l'action qu'il faut considérer, car sinon tu en arrives à des conclusions du type :

• Une requête à un agent IA est énergivore → N'utilisons pas les agents IA, pour préserver l'environnement.
• Laisser son ordinateur allumé est énergivore → Eteignons tous les ordinateurs, pour préserver l'environnement
• Prendre l'avion est énergivore → Supprimons tous les vols en avion, pour préserver l'environnement
• Manger de la viande est énergivore → Arrêtons d'élever des animaux, pour préserver l'environnement
• Produire de l'électricité est énergivore → Arrêtons les centrales nucléaires, pour préserver l'environnement

Tu comprends bien qu'en cherchant à minimiser le coût environnemental à tout prix, on en arriver facilement à la conclusion que, pour un humain, juste vivre est tellement énergivore et destructeur d'environnement que la solution la plus naturelle serait d'éradiquer tous les humains sur Terre. Alors oui, ça résoudrait probablement le problème du réchauffement climatique, mais bon… Ca ne me parait pas être une bonne solution.

Pour revenir sur l'utilisation d'agents IA : Il m'est arrivé, pour mon propre projet open-source que je détecte un jour un bug en estimant très sincèrement que ça allait me prendre une bonne journée de travail pour corriger ce bug. C'était un bug impliquant un code vieux de 15 ans sur un algorithme de décomposition matricielle que je ne maitrise plus aujourd'hui. Juste par curiosité, j'ai soumis le bug à Claude.ai, qui m'a trouvé le bug en 3 minutes. Devine quoi : j'ai pu corriger, éteindre mon ordinateur et aller randonner le reste de la journée. Dans ce cas, il est évident que cette requête a été positive, non seulement pour moi, mais aussi pour l'environnement !

Parce que cela est extrêmement energivore et destructeur de l'environnement ?

Il serait intellectuellement assez malhonnête (ou simpliste) d'affirmer qu'écrire quelques requêtes à Claude ou ChatGPT de temps en temps fait de l'utilisateur quelqu'un qui détruit l'environnement. Je n'imagine pas qu'un développeur de projet open-source en ait une utilisation à ce point abusive.

On peut rester raisonnable dans l'utilisation de ces agents IA, et avoir un bilan carbone individuel correct (bien moins élevé que certains ne les utilisant pas, mais qui prennent l'avion 2 ou 3 fois par mois pour faire des vols A/R dans la journée, pour le travail par exemple). Calculer un bilan carbone se fait en prenant en compte l'ensemble des usages de chacun. Ce n'est pas trivial, ni à réaliser, ni à analyser.

Après, s'accorder sur le fait que les sociétés qui entrainent ces gros modèles d'IA devraient avoir le droit de le faire ou pas, pour des raisons écologiques, c'est une autre histoire, qui dépasse largement le sujet initial de ce journal. Ne mélangeons pas tout, et ne rejettons pas la faute sur les utilisateurs occasionnels de ces agents IA. Le vrai problème écologique n'est pas vraiment dû à l'inférence de ces réseaux (leur entrainement est largement plus énergivore, à des ordres de grandeurs autrement plus grand que leur inférence).

Pour reprendre ton analogie : on peut-être OK avec le fait de monter au sommet d'une montage en hélicoptère, si cela permet de gagner du temps et de sauver par exemple quelqu'un enseveli sous une avalanche. Le contexte de l'objectif est à prendre en compte pour mesurer si le rapport 'coût écologique / utilité de l'action' est favorable ou pas.

Je voudrais contrebalancer la réponse de Jehan.

Je n'aime pas cette idée d'essayer de convaincre les développeurs ou les créateurs de ne pas utiliser d'agents IA ou d'IA génératives (et plus généralement, de travailler comme ceci ou comme cela), ou même de les culpabiliser (même indirectement), s'ils le font.
L'utilisation de ces outils relève d'un choix personnel et le développeur d'un projet libre est toujours le mieux placé pour savoir si ces outils sont adéquats pour lui et son projet.

Cela dit, cela ne date pas de l'arrivée des IAs. Les développeurs de LL le savent : il y a toujours eu des donneurs de leçons extérieurs aux projets qui viennent expliquer qu'il faudrait faire plutôt comme ci, surtout pas comme ça, etc. et 99.9999% du temps, c'est du bullshit (ou quand on leur demande de proposer un PR, y a plus personne). Du coup, pas vraiment plus pertinent que les PRs générés par des IAs…

Les agents IA sont des outils, avec certes pas mal de défauts, mais aussi des qualités, et ce n'est plus à démontrer que pour certaines tâches ils peuvent être très utiles/performants et faire gagner du temps au développeurs/créateurs pour peu qu'on prenne le temps de vérifier ce qui est généré (ce temps de relecture est effectivement parfois plus court que de réaliser la tâche soi-même à partir de zéro).

Bref, ce n'est pas si simple.

En particulier, tous les projets ne sont pas les mêmes (en taille, en nombre de contributeurs, en objectifs, etc.) : Les projets libres sont suffisamment divers (et la façon de travailler de leurs développeurs aussi), pour ne pas pouvoir prétendre connaitre "la bonne façon de travailler" et donner ce genre de leçons.

Chacun choisit sa méthode, et si quelqu'un trouve son compte dans l'utilisation de agents IA, ma foi, pourquoi pas ? L'important au final, c'est que les projets libres avancent dans le sens que leur créateur souhaite.

Bref, si toi, Laurent, tu penses que les IA conversationnels permettent d'enrichir la rédaction du Frido, tu as probablement raison : étant donné ce que tu as déjà produit sur ce projet, je pense qu'on peut totalement te faire confiance sur la méthode de travail que tu as choisi d'appliquer.
Bravo à toi pour ce beau travail en tout cas.

Pour en revenir aux PRs générés par IA : je vois ça un peu comme le tri des spams avec les mails. C'est certes un peu pénible, mais on finit quand même par pouvoir gérer ça avec les outils ou heuristiques adéquates. Ca ne m'inquiète pas plus que ça.

Pour info, après avoir lu les commentaires, j'ai testé la création d'un package G'MIC pour Debian 13 Trixie (donc pour GIMP 3.0.0-RC3). Ca m'a l'air de fonctionner pas trop mal, donc n'hésitez pas à tester, et à me dire ce qu'il en est.

Lien de téléchargement : https://gmic.eu/download.html

Bonjour,

Oui à priori nous sommes en train de tester une version du plug-in G'MIC pour gimp 3.
Une première version est en cours de test : https://discuss.pixls.us/t/on-the-road-to-3-5/44490/40
(sous Windows par contre).

Il y a des bugs qui restent mais ça devrait déjà être utilisable. Et on espère pouvoir avoir des contributeurs par la suite qui peuvent proposer des améliorations.

Donc en tout cas, on a bon espoir d'avoir un G'MIC qui tourne pour gimp 3 correctement un de ces jours :)

Perso, j'ai interprété comme ceci "Y a le Frido qu'est là" -> "Y a le Frida Kehlo", qui est presque "Frida Kahlo" (https://fr.wikipedia.org/wiki/Frida_Kahlo).
Mais peut-être que j'ai eu un peu trop d'imagination sur le coup :)

Et bravo pour le titre de la dépêche qui est bien contrepèteriesque !

Je tiens à remercier encore chaleureusement Claude pour ses contributions à G'MIC. Je vois bien que ses filtres ont un franc succés auprès des utilisateurs !

J'ai fait un petit test rapide d'application du filtre sur une vidéo :

https://youtu.be/wMISHmr5Slc

J'ai utilisé les paramètres par défaut, et la version de gmic en ligne de commande, compilée avec le support d'OpenCV, avec la commande:

$ gmic w apply_video big_buck_bunny_720p_stereo.ogg,\"cl_comic 0,2,0,1,1,15,15,1,10,20,6,2,0,0,0,0,0,0,50,50\",2000,4000,1,bbb.jpg

La commande crée un ensemble de 2000 frames que je transforme ensuite en vidéo (avec ffmpeg par exemple).
Ce n'est pas très user-friendly, mais ça donne une idée du résultat possible sur une vidéo (et disons le aussi, c'est assez long à calculer !).

Au nom de l'équipe de développement de G'MIC, je voulais remercier chaleureusement cli345 (alias Claude), d'abord pour ce chouette filtre (et tous les autres qu'il a fait et dont il n'a pas parlé ici !), et aussi pour cette dépêche très détaillée.

Le code de ce filtre est arrivé de manière tout à fait inattendue, et ça a été une sacré bonne surprise pour nous. Ce n'est pas souvent qu'on reçoit des contributions sympas comme ça, qui ont l'air de tomber du ciel :)

Donc merci encore Claude !

C'est pas tellement la tête qu'il nous casse, pour rester poli.

Merci pour le compliment.

• Concernant la traduction de la documentation : oui, ça serait chouette d'avoir des traductions en français ou dans d'autres langues. Mais ça représente un travail énorme (la doc en format .pdf fait 659 pages…).

• Pour la fenêtre d'acceptation des cookies : je l'ai enlevé. À ma connaissance nous n'utilisons plus de système qui génère des cookies. On utilisait Statcounter pour avoir des statistiques de visite, mais ce service ne fonctionne plus depuis un moment.

Bonjour,
Question très intéressante, merci.

Pour les avantages d'une licence libre, en plus de l'idée scientifiquement satisfaisante de construire un bien commun numérique, on a pu apprécier le fait d'avoir un nombre d'utilisateurs qui a augmenté assez vite, dès le départ du projet (plus lié à l'aspect "gratuit" qu'à l'aspect "libre" surement). Et ça a donc été intéressant d'avoir assez vite des retours qui ont permis de perfectionner / déboguer le logiciel, probablement plus rapidement qu'avec une licence fermée. Et bien sûr, comme tout projet libre, la possibilité d'avoir pleins de petites contributions extérieures ponctuelles sur le code, le packaging, la documentation, des dérivations intéressantes (plug-ins OpenFX et greffon pour hôtes supportant l'API 8bf notamment), etc. G'MIC reste cependant un "petit" projet avec peu de développeurs réguliers (on est deux à assurer le développement du plus gros des nouvelles fonctionnalités).

Pour la part inédite propre à la recherche, je maintiens une page des publications scientifiques associées aux algorithmes originaux que nous avons développés, issus de nos travaux de recherche et qui ont été intégrés à G'MIC : https://gmic.eu/reference/scientific_publications.html
Vous pouvez cliquer sur les liens pour lire les publications (au format .pdf).

En ce qui concerne la communication autour du projet : c'est globalement difficile d'être visible :) L'écriture d'une dépêche comme celle-ci m'a demandé 6 jours de travail, quasiment à 100%, donc je ne peux pas me permettre de faire ce genre de choses très souvent. Je comprends que les projets libres ne puissent pas forcément investir beaucoup de temps sur l'aspect communication.

D'accord, je me disais aussi qu'avec une méthode d'inpainting basée sur du Navier-Stokes (l'algo d'OpenCV), les résultats paraissaient quand même un peu trop propres :)

Par ailleurs, j'aime beaucoup G'MIC, c'est un superbe logiciel.

C'est gentil ça ! Merci.

Bonjour,
Oui, actuellement il existe plusieurs filtres d'inpainting dans G'MIC.

Je pensais que la nouveauté avec Lama-cleaner, c'était d'utiliser des techniques d'inpainting basées réseaux de neurones, mais d'après la page, ça utiliserait un vieil algo par défaut dans OpenCV. Je n'en suis pas sûr quand même, car j'ai vu de très beaux résultats de reconstruction avec ce plug-in, donc il faudrait quand même creuser un peu la chose.

A noter également que le pionner des algos d'inpainting (capable de reconstruire des textures) dans un logiciel de retouche d'images , ça doit être Resynthetizer, qui marche encore très bien a priori : https://github.com/bootchk/resynthesizer

Texte également rédigé à l'aide de ChatGPT (et corrigé par mes soins) :

G'MIC est un outil de traitement d'images en ligne de commande qui propose une large gamme de filtres et d'effets pour traiter et modifier des images. Il peut être utilisé en ligne de commande, mais aussi via une interface graphique, avec un plug-in disponible pour des logiciels comme GIMP ou Krita.

Voici quelques exemples d'utilisation de G'MIC en ligne de commande :

• Appliquer un effet de flou gaussien sur une image : gmic image.jpg -blur 3
• Appliquer un effet de flou médian sur une image : gmic image.jpg -median 3
• Appliquer un effet de dessin au crayon sur une image : gmic image.jpg -pencilbw 0.3
• Fusionner plusieurs images en une seule : gmic image1.jpg image2.jpg blend alpha,0.5 -o output.jpg
• Appliquer une correction de couleur sur une image : gmic image.jpg -adjust_colors 20,20

Il existe de nombreux autres filtres et effets disponibles dans G'MIC, qui peuvent être consultés dans la documentation en ligne ou en utilisant la commande gmic -help pour obtenir une liste complète des options disponibles.

Fin de l'été,
Reine enterrée,
Poireaux à planter.

Ce n'est pas parce que l'on est pas coiffeur que l'on ne peut pas critiquer une coiffure, ou critiquer une maison, si l'on n'est pas maçon

Comme je l'ai déjà écrit, tout le monde peut évidemment avoir son avis.
Mais la pertinence d'un avis est à moduler en fonction de l'expérience de la personne qui le formule dans le domaine concerné. Mon avis sur les coupes de cheveux, j'espère bien qu'aucun coiffeur n'en tiendra jamais compte.

L'utilisabilité d'un logiciel et les principes d'ergonomie existent aussi pour les langages et ne se limitent pas aux IHM (principe de moindre surprise, principe de moindre mémorisation, nom prononçable,…).

A ce stade, plutôt que nous commentions ad vitam æternam, et si tu as le temps pendant les vacances de fin d'année, essaye de te mettre au langage G'MIC pour des problématiques de traitement d'images, compare avec l'existant pour faire le même genre de tâches, et peut-être changeras-tu d'avis ? (ou pas…).
Pour ma part, étant en vacances, je m'arrêterai là.
Bonnes fêtes à tout le monde.

Je pense que tu es dans le cas ultime ou le langage est adapté au hardcore user les plus extrêmes : les créateurs du langage.

Si tu prends l'exemple de sed : les millions de gens qui utilisent sed de temps en temps ne sont pas tous les créateurs du langage associé, ni des hardcore users (loin de là!). Pour autant, c'est tellement plus pratique d'utiliser sed pour faire un remplacement rapide de texte dans un fichier, que de dégainer n'importe quoi d'autre…

Ces utilisateurs là (je m'inclus dedans) ont juste pris le temps de regarder comment combler un besoin spécifique avec sed, et ça marche pour eux. A la limite, il y a même pas besoin de comprendre la syntaxe en profondeur, mais c'est pas grave, ça fait le taf efficacement. Et on se doute qu'on peut faire des choses très complexes avec.

python, java, ocaml, rust, C, golang, Javascript, il y a plein de possibilités. Si gmic était une lib pour Python, il aurait 100x plus d'utilisateurs, c'est sûr (et je n'aime pas python).

Le langage G'MIC rajoute une de ces possibilités dans ta liste (et si tu as lu la dépêche, tu as vu qu'il y a un début de binding G'MIC pour Python qui existe maintenant).

Un langage informatique a toujours plusieurs niveaux d'utilisation et plusieurs niveaux d'utilisateurs. C'est illusoire d'avoir un avis tranché et pertinent sur un langage de programmation sans être passé par toutes les catégories d'utilisateurs (impossible dans les faits). En général, il vaut mieux faire confiance aux créateurs du langage, qui ont réfléchi à la question plus longuement.

Perso, il ne me viendrait pas à l'idée de décréter que SQL c'est mal, parce que je comprend pas facilement ce qui se passe lorsque je lis une requête. Ca serait vraiment naïf de ma part (ou pédant au choix). Au contraire, je me dis plutôt que si des gens qui sont experts en BDD ont élaboré le langage de cette façon, c'est surement qu'il y a une bonne raison (que je ne suis pas apte à comprendre, avec le niveau en BDD que j'ai).

Après, évidemment rien n'empêche d'avoir son propre avis.
Mais connaissant bien le domaine du traitement d'image, les syntaxes d'ImageMagick/GraphicsMagick ou de G'MIC sont tout à fait justifiables, pour l'usage pour lesquels ils ont été créés.

J'ai un raisonnement différent : si dans l'histoire de l'informatique, des langages jugés "peu lisibles" ont été créés, existent depuis des dizaines et des dizaines d'années, et continuent à être utilisés, c'est pas juste parce que les auteurs de ces langages sont pas doués et n'ont pas compris qu'un langage de programmation, ça devait être "lisible" et "verbeux".

C'est plus probablement parce que de tels langages ont des avantages tels (concision, rapidité, facilité d'interprétation, et j'en passe …) que l'inconvénient du peu de lisibilité (et encore, vu par le prisme du non-initié) passe clairement au second plan.

Ayant pratiqué le traitement d'images en C++ depuis plus de 20 ans, je peux affirmer que programmer en langage G'MIC me fait gagner un facteur de temps d'au moins x10 sur le développement de prototypes et de nouveaux algorithmes, par rapport au C++ (et je pratique régulièrement les deux). Et apparemment, la maintenance et l'évolution de l'ensemble du code écrit en langage G'MIC n'a pas vraiment posé de problèmes depuis le début du projet, en 2008 (et cela, malgré le fait que les spécifications du langage ont changé entre temps!). Je ne souhaiterais vraiment pas être obligé de réécrire ces algos de manière équivalente en C++, ça me semblerait vraiment lourd, chronophage et peu pratique. Je peux même affirmer que si tous les filtres de G'MIC avait été écrit en C++, il y en aurait probablement 2 ou 3 fois moins disponibles.

Par ailleurs, je pense que quelqu'un de motivé, qui a un intérêt à utiliser ce type de langages métiers n'aura pas forcément plus de difficulté qu'avec un autre langage. Comme je l'ai écrit tout à l'heure, il suffit d'avoir la volonté de s'y mettre et l'ouverture d'esprit pour accepter un paradigme de programmation un peu différent. Avec un peu d'expérience, tout langage devient lisible pour celui qui le maîtrise un tant soit peu. C'est valable pour tous les langages cités précédemment (ajoutons l'ASM en passant, ayant commencé le Z80 assez jeune, sur Amstrad CPC, j'ai eu aussi une expérience similaire pour ce "langage"). On ne peut pas attendre que tous les langages ressemblent au Basic Python (ça serait d'une tristesse!).

La lisibilité d'un langage, ça peut être bien. Mais prendre cette propriété seule pour juger du niveau d'aboutissement ou de la praticité d'un langage, c'est vraiment pas une bonne idée (pour pas dire que c'est foireux).

Je suis le projet depuis longtemps, je l'ai utilisé à l'époque où c'était encore un énorme .h de 6 Mo.

Non, G'MIC n'a jamais été un gros .h de 6 Mo. Tu veux parler de CImg peut-être ? Ce n'est pas du tout le même projet.

C'est une "A quite naive way of doing" an histogramme. Qui comprend ce que fait le code d'un coup d'oeil ?!

Je ne sais pas où tu as pris cet exemple, mais il est obsolète.
Aujourd'hui, on l'écrirait de manière équivalente, plutôt comme ça :

my_histogram :
256 eval.. ++i[#-1,i]


Tu vas me dire que ce n'est pas tellement plus clair. Et je serai d'accord.
Mais il faut bien comprendre que le but du langage G'MIC n'a jamais été d'être lisible, mais juste efficace et concis (ce dernier point n'étant pas forcément toujours compatible avec la clarté de lecture de code).

En encore, ce "problème" se pose si, en tant que développeur, tu souhaites implémenter tes propres algorithmes de traitement personnalisés en langage G'MIC. Ca concerne au final assez peu de monde.
Si, en tant qu'utilisateur de gmic en ligne de commande, tu souhaites juste utiliser les algorithmes existants, alors tu vas écrire des pipelines de commandes, beaucoup plus simples (pour l'exemple de l'histogramme ci-dessus, il faudrait juste utiliser la commande histogram :) ).

Le langage G'MIC est un langage métier, très différent des langages "classiques" généralistes. Il a été imaginé pour créer des pipelines potentiellement complexes de traitement d'images, pas pour initier des gens à la programmation.
C'est un peu comme si tu me disais que la syntaxe de sed n'est pas lisible pour le traitement des chaines de caractères : c'est vrai, c'est pas lisible, mais c'est concis et efficace. Et c'est utilisé par des milliers (millions) de personnes.
Par ailleurs, si tu regardes du côté de la "concurrence" (ImageMagick), c'est exactement pareil (voir les exemples d'utilisation sur leur site : https://legacy.imagemagick.org/Usage/thumbnails/ ). Illisible pour le néophyte.

J'imagine qu'on pourrait trouver plein d'autres exemples, avec l'utilisation de langages métiers très spécialisés dans leur domaine. Tiens au hasard, le SQL, j'ai jamais réussi à comprendre des requêtes de plus de deux lignes. C'est normal, c'est comme tout, il faudrait juste s'y mettre (mais je n'en ai jamais eu besoin pour ma part).

Pour ceux qui auraient besoin de se mettre au langage G'MIC, on a des pages de référence et de tutoriels pour cela. Quelques développeurs s'y sont mis et proposent aujourd'hui des filtres personnalisés pour G'MIC.

Mais je dirais que dans notre projet, on veut permettre surtout à des utilisateurs d'accéder facilement à des ensembles de filtres et de traitements d'images, plutôt que de rallier des développeurs à l'utilisation du langage G'MIC.
On ne vise pas majoritairement le public des développeurs.

Pour markdown je ne suis pas sûr de comprendre, la traduction markdown → html est faite dans gmic et pas dans une étape de construction ?

La commande gmd2html de G'MIC permet de convertir du texte en format Markdown sous la forme de pages HTML. Elle peut s'utiliser comme ceci par exemple :

$ gmic it monfichier.gmd gmd2html 0 ot output.html

où monfichier.gmd est un fichier en format G'MIC Markdown.
C'est d'ailleurs comme ceci que les pages de tutoriel et de la documentation de référence sont générés par le script de build de G'MIC.

De la même manière, la commande gmd2ascii permet de convertir le texte en Markdown sous la forme de texte ASCII (éventuellement coloré) pour affichage de l'aide sur le terminal. C'est typiquement ce qui est utilisé quand on demande l'aide à partir du terminal :

$ gmic -h

(aide globale), ou

$ gmic -h blur

(aide pour une commande particulière).

Comme le parseur Markdown est maintenant directement intégré dans G'MIC, il peut être utilisé à la volée pour générer la doc pour l'affichage sur le terminal. C'est très pratique.

Merci pour le retour sympathique.

Petite question : les filtres sont pour la plupart algorithmiques, doit-on s'attendre à plus de filtre à base de réseau neuronal ?

Oui, on va essayer d'aller vers plus de filtres à base de réseau, c'était le but du développement de nn_lib.

C'est assez difficile d'apporter une réponse générale, car cela dépend vraiment des filtres. Quelquefois, un filtre né de l'implémentation stricte d'un papier, d'autres fois, c'est juste inspiré par des lectures de papier, et d'autre fois encore, c'est le fait d'avoir eu le temps de tester rapidement des idées originales.

Deux justifications :
- La version d'avant était la 2.9.9, et on garde les numéros de version sur 3 chiffres.
- Et comme on savait qu'on allait passer de la 2.9.9 à la 3.0.0, et que la 2.9.9 marchait bien, on a du coup prit le temps pour soigner particulièrement cette version 3.0.0, ce qui en fait effectivement une version majeure :)

G'MIC est de toute façon un logiciel qui évolue constamment avec des sorties fréquentes (environ une tous les deux mois je dirais).